[nvmewin] Bug Check 133

Thu Jul 3 09:52:24 PDT 2014

Hi,

If you have seen this Bugcheck in Windows Server 2012 then please try below
KB
http://support.microsoft.com/kb/2789962

Thanks,
Abhijit.

On Thu, Jul 3, 2014 at 1:36 PM, cheng.peng at memblaze.com <
cheng.peng at memblaze.com> wrote:

> Hi Alex,
>
> Do you think something is wrong with the device ?
>
> Could you offer me some advice ?
>
> Thanks
>
> ------------------------------
> cheng.peng at memblaze.com
>
>
> *From:* Alex Chang <Alex.Chang at pmcs.com>
> *Date:* 2014-07-03 00:18
> *To:* cheng.peng at memblaze.com; nvmewin <nvmewin at lists.openfabrics.org>
> *Subject:* RE: Re: [nvmewin] Bug Check 133
>
> Hi Cheng,
>
>
>
> From our previous experience, it’s very likely your device is stuck in
> reset procedure when the while loop persists.
>
>
>
> Thanks,
> Alex
>
>
>
> *From:* cheng.peng at memblaze.com [mailto:cheng.peng at memblaze.com]
> *Sent:* Wednesday, July 02, 2014 12:11 AM
> *To:* Alex Chang; nvmewin
> *Subject:* Re: Re: [nvmewin] Bug Check 133
>
>
>
> Hi Alex,
>
>
>
> I find out something by disassembling.
>
>
>
> Call Site
> nt!KeBugCheckEx
> nt! ?? ::FNODOBFM::`string'
> nt!KeUpdateRunTime
> hal!HalpTimerClockInterrupt
> nt!KiInterruptDispatchLBControl
> *nvme+0x40c3  <--- in the while loop of function: NVMeWaitForCtrlRDY*
> *nvme+0x417d  <--- nvmeStd.c: 2063 (function: RecoveryDpcRoutine)*
>
> nt!KiExecuteAllDpcs
> nt!KiRetireDpcList
> nt!KxRetireDpcList
> nt!KiDispatchInterruptContinue
> nt!KiDpcInterrupt
> storport!RaidUnitSubmitResetRequest
> storport!RaUnitScsiIrp
> storport!RaDriverScsiIrp
> storport!RaSendIrpSynchronous
> storport!RaidUnitResetUnit
> storport!RaidUnitHierarchicalReset
> storport!RaidHierarchicalResetWorkRoutine
> nt!IopProcessWorkItem
> nt!ExpWorkerThread
> nt!PspSystemThreadStartup
> nt!KiStartSystemThread
>
>
>
> I'd like to know the reason why the while loop is too much.
>
>
>
> I need your help, thanks.
>
>
>  ------------------------------
>
> cheng.peng at memblaze.com
>
>
>
> *From:* cheng.peng at memblaze.com
>
> *Date:* 2014-07-01 10:04
>
> *To:* Alex Chang <Alex.Chang at pmcs.com>; nvmewin
> <nvmewin at lists.openfabrics.org>
>
> *Subject:* Re: RE: [nvmewin] Bug Check 133
>
> Hi Alex,
>
>
>
> I appreciate you reply.
>
>
>
> 1. I build the driver by VS2013 and WDK 8.1 in the trunk\source dirctory,
> and I don't change any thing
>
> 2. I use 16 workers with 32 outstanding IOs, assigned access 32K; 50%Read;
> 0% random.  there are 4 logical cores on the test system
>
> 3. the bug check is triggered after 6 hours, but I have launched IOMeter
> for 18 hours, it isn't seen again.
>
>
>
> Thanks
>
>
>  ------------------------------
>
> cheng.peng at memblaze.com
>
>
>
> *From:* Alex Chang <Alex.Chang at pmcs.com>
>
> *Date:* 2014-07-01 00:09
>
> *To:* cheng.peng at memblaze.com; nvmewin <nvmewin at lists.openfabrics.org>
>
> *Subject:* RE: [nvmewin] Bug Check 133
>
> Hi Cheng,
>
>
>
> Although I’ve never seen the problem before with the driver, like to ask
> you some questions:
>
> 1.       Did you add any changes to the driver?
>
> 2.       How many workers you use in IOMeter? How many logical cores
> running on your test system?
>
> 3.       How long will the bug check be triggered after launching IOMeter?
>
> Thanks,
>
> Alex
>
>
>
> *From:* nvmewin-bounces at lists.openfabrics.org [
> mailto:nvmewin-bounces at lists.openfabrics.org
> <nvmewin-bounces at lists.openfabrics.org>] *On Behalf Of *
> cheng.peng at memblaze.com
> *Sent:* Monday, June 30, 2014 2:07 AM
> *To:* nvmewin
> *Subject:* Re: [nvmewin] Bug Check 133
>
>
>
> 2: kd> vertarget
> Windows 8 Kernel Version 9200 MP (4 procs) Free x64
> Product: Server, suite: TerminalServer SingleUserTS
> Built by: 9200.16384.amd64fre.win8_rtm.120725-1247
> Machine Name:*** ERROR: Module load completed but symbols could not be
> loaded for srv.sys
>
> Kernel base = 0xfffff801`54087000 PsLoadedModuleList = 0xfffff801`54351a60
> Debug session time: Mon Jun 30 15:05:08.789 2014 (UTC + 8:00)
> System Uptime: 0 days 5:24:55.498
>
>
>
>   ------------------------------
>
> cheng.peng at memblaze.com
>
>
>
> *From:* cheng.peng at memblaze.com
>
> *Date:* 2014-06-30 17:04
>
> *To:* nvmewin <nvmewin at lists.openfabrics.org>
>
> *Subject:* Bug Check 133
>
> Hi All
>
>
>
> I get a BSOD when I run IOMeter
>
>
>
> the driver is built by myself and Unfortunately I miss the .pdb file
>
>
>
> following the detail of BSOD:
>
>
>
> *******************************************************************************
>
> * *
> * Bugcheck Analysis *
> * *
> *******************************************************************************
>
>
> DPC_WATCHDOG_VIOLATION (133)
> The DPC watchdog detected a prolonged run time at an IRQL of
> DISPATCH_LEVEL
> or above.
> Arguments:
> Arg1: 0000000000000000, A single DPC or ISR exceeded its time allotment.
> The offending
> component can usually be identified with a stack trace.
> Arg2: 0000000000000281, The DPC time count (in ticks).
> Arg3: 0000000000000280, The DPC time allotment (in ticks).
> Arg4: 0000000000000000
>
> Debugging Details:
> ------------------
>
>
>   ADDITIONAL_DEBUG_TEXT:
> You can run '.symfix; .reload' to try to fix the symbol path and load
> symbols.
>
> MODULE_NAME: nvme
>
> FAULTING_MODULE: fffff80154087000 nt
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 53ac04c7
>
> DPC_TIMEOUT_TYPE: SINGLE_DPC_TIMEOUT_EXCEEDED
>
> DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
>
> BUGCHECK_STR: 0x133
>
> CURRENT_IRQL: 0
>
> ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) amd64fre
>
> LAST_CONTROL_TRANSFER: from fffff8015425b5df to fffff80154102040
>
> STACK_TEXT:
> fffff880`02c959f8 fffff801`5425b5df : 00000000`00000133 00000000`00000000
> 00000000`00000281 00000000`00000280 : nt!KeBugCheckEx
> fffff880`02c95a00 fffff801`5412cf11 : ffffffff`ffd0d9a0 fffff880`02c65180
> fffff880`02c95b60 fffff780`00000320 : nt!XIPDispatch+0x1437f
> fffff880`02c95a80 fffff801`5403de84 : ffffffff`ffd0d9a0 fffffa80`0ca00202
> fffffa80`0ca00210 00001f80`00000200 : nt!KeUpdateRunTime+0x51
> fffff880`02c95ab0 fffff801`540fb4ae : 01cf9431`a0b7c658 fffffa80`0c76d010
> fffffa80`0ca00210 00000000`0000005a : hal!HalSetTimeIncrement+0x3f54
> fffff880`02c95ae0 fffff880`00f030c3 : 00000000`00000000 fffffa80`0c76d010
> 01cf9431`a06ddd2b 01cf9431`a0ba289d : nt!KeSynchronizeExecution+0xa6e
> fffff880`02c95c70 fffff880`00f0317d : 00000000`00460000 fffffa80`0d4b9330
> 00000000`0000005a 00000000`00000001 : nvme+0x40c3
> fffff880`02c95ca0 fffff801`540f8498 : fffff880`02c67f00 fffffa80`0c76e240
> fffff880`02c95e00 fffffa80`0c9ec5e8 : nvme+0x417d
> fffff880`02c95d00 fffff801`54128d50 : fffff880`02c65180 0000002c`bd2e6172
> fffffa80`0d9f64c0 00000000`00000025 : nt!ObfDereferenceObject+0x7f8
> fffff880`02c95e40 fffff801`54128745 : e0015431`1e3070e7 fffff880`02c65180
> fffff880`02dec6b0 fffffa80`0d94cc00 : nt!KeWaitForSingleObject+0x1180
> fffff880`02c95fb0 fffff801`54128549 : fffff880`02dec670 fffff880`00ebf301
> 00000000`00000002 fffff880`00ebe39b : nt!KeWaitForSingleObject+0xb75
> fffff880`02dec600 fffff801`541c3398 : fffffa80`0d4b9330 fffffa80`0d4b9330
> fffff880`02dec670 fffffa80`0c76d010 : nt!KeWaitForSingleObject+0x979
> fffff880`02dec630 fffff880`00ecb1b2 : 00000000`00000000 00000000`00000001
> fffffa80`0d94cc00 fffff880`0197b8be : nt!wcsncat_s+0x1f8
> fffff880`02dec7c0 fffff880`00ed71c8 : fffff880`009ed180 00000000`00000000
> fffffa80`0d4b9330 fffff801`5402dbb9 : storport!StorPortPause+0xb4a2
> fffff880`02dec860 fffff880`00eac6b5 : 00000000`00000001 fffff801`5410b770
> fffffa80`0d94cc00 00000000`00000058 :
> storport!StorPortConvertUlongToPhysicalAddress+0x9784
> fffff880`02dec9a0 fffff880`00ec6fe6 : fffffa80`0d94cc00 fffffa80`0c9f0940
> fffffa80`0d4b9330 fffff880`00ec66f6 :
> storport!StorPortQuerySystemTime+0xe55
> fffff880`02dec9e0 fffff880`00ec8d4d : 00000000`00000000 fffffa80`0c9f0940
> fffffa80`0d4b9330 fffffa80`0c9ec1a0 : storport!StorPortPause+0x72d6
> fffff880`02deca40 fffff880`00ecd6a2 : fffffa80`00000000 fffffa80`0c9f0940
> fffffa80`0c9f0ee0 00000000`80040081 : storport!StorPortPause+0x903d
> fffff880`02deca90 fffff880`00ec8082 : fffffa80`0e0a3b90 fffff801`00000000
> fffffa80`0e0a3b90 00000000`00000000 : storport!StorPortPause+0xd992
> fffff880`02decac0 fffff801`540ed45b : fffffa80`0e0a3b90 00000000`00000000
> fffff880`00ec801c fffffa80`0c780ef0 : storport!StorPortPause+0x8372
> fffff880`02decb10 fffff801`5413a391 : fffff801`5430b080 fffffa80`0c70bb00
> fffff801`540ed3fc fffff801`5430b000 :
> nt!FsRtlDoesNameContainWildCards+0x50b
> fffff880`02decb80 fffff801`540a9521 : 00000000`00000000 00000000`00000080
> fffff801`5413a250 fffffa80`0c70bb00 : nt!IofCompleteRequest+0x151
> fffff880`02decc10 fffff801`540e7dd6 : fffff880`02c65180 fffffa80`0c70bb00
> fffff880`02c70e40 fffffa80`0c7ee980 : nt!KeQueryMaximumGroupCount+0x187d
> fffff880`02decc60 00000000`00000000 : fffff880`02ded000 fffff880`02de7000
> 00000000`00000000 00000000`00000000 : nt!_misaligned_access+0x36
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> nvme+40c3
> fffff880`00f030c3 83e001 and eax,1
>
> SYMBOL_STACK_INDEX: 5
>
> SYMBOL_NAME: nvme+40c3
>
> FOLLOWUP_NAME: MachineOwner
>
> IMAGE_NAME: nvme.sys
>
> BUCKET_ID: WRONG_SYMBOLS
>
> FAILURE_BUCKET_ID: WRONG_SYMBOLS
>
> ANALYSIS_SOURCE: KM
>
> FAILURE_ID_HASH_STRING: km:wrong_symbols
>
> FAILURE_ID_HASH: {70b057e8-2462-896f-28e7-ac72d4d365f8}
>
> Followup: MachineOwner
> ---------
>
>
>
>
>   ------------------------------
>
> cheng.peng at memblaze.com
>
>
> _______________________________________________
> nvmewin mailing list
> nvmewin at lists.openfabrics.org
> http://lists.openfabrics.org/mailman/listinfo/nvmewin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140703/1cf0f93e/attachment.html>