[nvmewin] Bug Check 133

Alex Chang Alex.Chang at pmcs.com
Thu Jul 3 11:07:56 PDT 2014


Thank you, Abhijit.

Alex

From: Abhijit Khande [mailto:abhijit.khande at gmail.com]
Sent: Thursday, July 03, 2014 9:52 AM
To: cheng.peng at memblaze.com
Cc: Alex Chang; nvmewin
Subject: Re: [nvmewin] Bug Check 133

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<mailto:cheng.peng at memblaze.com> <cheng.peng at memblaze.com<mailto: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<mailto:cheng.peng at memblaze.com>

From: Alex Chang<mailto:Alex.Chang at pmcs.com>
Date: 2014-07-03 00<tel:2014-07-03%C2%A000>:18
To: cheng.peng at memblaze.com<mailto:cheng.peng at memblaze.com>; nvmewin<mailto: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> [mailto: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<mailto:cheng.peng at memblaze.com>

From: cheng.peng at memblaze.com<mailto:cheng.peng at memblaze.com>
Date: 2014-07-01 10<tel:2014-07-01%C2%A010>:04
To: Alex Chang<mailto:Alex.Chang at pmcs.com>; nvmewin<mailto: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<mailto:cheng.peng at memblaze.com>

From: Alex Chang<mailto:Alex.Chang at pmcs.com>
Date: 2014-07-01 00<tel:2014-07-01%C2%A000>:09
To: cheng.peng at memblaze.com<mailto:cheng.peng at memblaze.com>; nvmewin<mailto: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> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of cheng.peng at memblaze.com<mailto: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<mailto:cheng.peng at memblaze.com>

From: cheng.peng at memblaze.com<mailto:cheng.peng at memblaze.com>
Date: 2014-06-30 17<tel:2014-06-30%C2%A017>:04
To: nvmewin<mailto: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<mailto:cheng.peng at memblaze.com>

_______________________________________________
nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto: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/c92f54d4/attachment.html>


More information about the nvmewin mailing list