From Sagi.Bar at sandisk.com  Tue Jul  1 06:56:31 2014
From: Sagi.Bar at sandisk.com (Sagi Bar)
Date: Tue, 1 Jul 2014 13:56:31 +0000
Subject: [nvmewin] Issues with sending NVME IDENTIFY command using the
	community driver
Message-ID: <E5B55DF4CB9A114395C0A6E7895C3B6721E49672@SACMBXIP02.sdcorp.global.sandisk.com>


Hello All,

My name is Sagi and I am quite new to NVME, actually making my first steps.


I am currently trying to send an NVME IDNTIFY command to the device, but unfortunately I keep getting "The request could not be performed because of an I/O device error.".

The code I am using is largely taken from PT_IOCTL document.
   #define NVME_PT_TIMEOUT 240


         BOOL Status = 0;
         DWORD Count = 0;
         DWORD InputBufLen = 0;
         DWORD OutputBufLen = 0;
         PNVME_PASS_THROUGH_IOCTL pInBuffer = NULL;
         PNVME_PASS_THROUGH_IOCTL pOutBuffer = NULL;
         DWORD size_of_identify_buffer =0x1000; //4k

         /* Allocate input buffer to accommodate size of NVME_PASS_THRUGH_IOCTL only */
         InputBufLen = sizeof(NVME_PASS_THROUGH_IOCTL);
         pInBuffer = (PNVME_PASS_THROUGH_IOCTL) malloc(InputBufLen);

         /* Allocate output buffer to accommodate size of NVME_PASS_THRUGH_IOCTL and data */
         OutputBufLen = sizeof(NVME_PASS_THROUGH_IOCTL) + size_of_identify_buffer - 1;
         pOutBuffer = (PNVME_PASS_THROUGH_IOCTL) malloc(OutputBufLen);


         if (pInBuffer == NULL || pOutBuffer == NULL)
         {
                  cout<<"ERROR allocating buffers for identify command \n";
                  return ERROR_INVALID_PARAM;
         }

         /* Zero out the buffers */
         memset(pInBuffer, 0, InputBufLen);
         memset(pOutBuffer, 0, OutputBufLen);


         /* Populate SRB_IO_CONTROL fields in input buffer */
         pInBuffer->SrbIoCtrl.ControlCode = (ULONG)NVME_PASS_THROUGH_SRB_IO_CODE;
         pInBuffer->SrbIoCtrl.HeaderLength = sizeof(SRB_IO_CONTROL);

         memcpy((UCHAR*)(&pInBuffer->SrbIoCtrl.Signature[0]), NVME_SIG_STR, NVME_SIG_STR_LEN);
         pInBuffer->SrbIoCtrl.Timeout = NVME_PT_TIMEOUT;
         pInBuffer->SrbIoCtrl.Length = InputBufLen - sizeof(SRB_IO_CONTROL);

        pInBuffer->Direction = NVME_FROM_DEV_TO_HOST;

         pInBuffer->NVMeCmd[0]=0x6;
         pInBuffer->NVMeCmd[10]=0x1;


         pInBuffer->DataBufferLen = ByteSizeTX;
         pInBuffer->ReturnBufferLen=OutputBufLen;

         Status = DeviceIoControl(
                  disk_handle,                                  /* Handle to \\.\scsi device via CreateFile */
                  IOCTL_SCSI_MINIPORT,   /* IO control function to a miniport driver */
                  pInBuffer         ,                      /* Input buffer with data sent to driver */
                  InputBufLen,                          /* Length of data sent to driver (in bytes) */
                  pOutBuffer,                             /* Output buffer with data received from driver */
                  OutputBufLen,                       /* Length of data received from driver */
                  &Count,                                  /* Bytes placed in DataBuffer */

                  NULL);                                   /* NULL = no overlap */



In addition, I have launched "DebugView" on the test machine and I seem to get the following messages, produced by sending the IOCTL

"

55461250000 - STORMINI: NVMeProcessIoctl: Code = 0xe0002000, Signature = 0xNvmeMinið

55461250000 - STORMINI: NVMeGetPhysAddr: <Error> Invalid phys addr.

"

Can you please help me to understand what am I doing wrong ?



Thank you,




Sagi Bar
Test & Tools Staff FW Engineer
[cid:image001.png at 01CEA3CD.FE1957E0]
7 Atir Yeda St, Kfar - Saba 44425, Israel
T: +972-9-7632774  | M: +972-54-7665567
F: +972-3-5488666
sagi.bar at SanDisk.com<mailto:sagi.bar at SanDisk.com>


________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140701/99ef83b3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2139 bytes
Desc: image001.png
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140701/99ef83b3/attachment.png>

From Sagi.Bar at sandisk.com  Tue Jul  1 23:51:46 2014
From: Sagi.Bar at sandisk.com (Sagi Bar)
Date: Wed, 2 Jul 2014 06:51:46 +0000
Subject: [nvmewin] Issues with sending NVME IDENTIFY command using the
 community driver
In-Reply-To: <49158E750348AA499168FD41D88983606319002F@fmsmsx117.amr.corp.intel.com>
References: <49158E750348AA499168FD41D88983606319002F@fmsmsx117.amr.corp.intel.com>
Message-ID: <E5B55DF4CB9A114395C0A6E7895C3B6721E4D98D@SACMBXIP02.sdcorp.global.sandisk.com>

Hello Raymond,

Thank you very much for your suggestion.
Alex Chang has already sent me the application and will start reviewing it soon.

This is a great help since I was quite lost with the issue :)

So thanks again,

Sagi Bar
Test & Tools Staff FW Engineer
[cid:image001.png at 01CEA3CD.FE1957E0]
7 Atir Yeda St, Kfar - Saba 44425, Israel
T: +972-9-7632774  | M: +972-54-7665567
F: +972-3-5488666
sagi.bar at SanDisk.com<mailto:sagi.bar at SanDisk.com>

From: Robles, Raymond C [mailto:raymond.c.robles at intel.com]
Sent: Tuesday, July 01, 2014 11:16 PM
To: Sagi Bar; nvmewin at lists.openfabrics.org
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: [nvmewin] Issues with sending NVME IDENTIFY command using the community driver

Hello Sagi,

I just submitted a sample application that sends pass through IOCTLs to this distribution. Alex Chang from PCMS (the NVMe Windows maintainer) will be adding it to the repo soon.

In the meantime, I've attached it here (zip password is intel1234). The sample app is very basic and just has an example of how to discover the SCSI address of your controller and send an Identify Controller via a pass through IOCTL.

Thanks,
Ray

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sagi Bar
Sent: Tuesday, July 01, 2014 6:57 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Issues with sending NVME IDENTIFY command using the community driver


Hello All,

My name is Sagi and I am quite new to NVME, actually making my first steps.


I am currently trying to send an NVME IDNTIFY command to the device, but unfortunately I keep getting "The request could not be performed because of an I/O device error.".

The code I am using is largely taken from PT_IOCTL document.
   #define NVME_PT_TIMEOUT 240


         BOOL Status = 0;
         DWORD Count = 0;
         DWORD InputBufLen = 0;
         DWORD OutputBufLen = 0;
         PNVME_PASS_THROUGH_IOCTL pInBuffer = NULL;
         PNVME_PASS_THROUGH_IOCTL pOutBuffer = NULL;
         DWORD size_of_identify_buffer =0x1000; //4k

         /* Allocate input buffer to accommodate size of NVME_PASS_THRUGH_IOCTL only */
         InputBufLen = sizeof(NVME_PASS_THROUGH_IOCTL);
         pInBuffer = (PNVME_PASS_THROUGH_IOCTL) malloc(InputBufLen);

         /* Allocate output buffer to accommodate size of NVME_PASS_THRUGH_IOCTL and data */
         OutputBufLen = sizeof(NVME_PASS_THROUGH_IOCTL) + size_of_identify_buffer - 1;
         pOutBuffer = (PNVME_PASS_THROUGH_IOCTL) malloc(OutputBufLen);


         if (pInBuffer == NULL || pOutBuffer == NULL)
         {
                  cout<<"ERROR allocating buffers for identify command \n";
                  return ERROR_INVALID_PARAM;
         }

         /* Zero out the buffers */
         memset(pInBuffer, 0, InputBufLen);
         memset(pOutBuffer, 0, OutputBufLen);


         /* Populate SRB_IO_CONTROL fields in input buffer */
         pInBuffer->SrbIoCtrl.ControlCode = (ULONG)NVME_PASS_THROUGH_SRB_IO_CODE;
         pInBuffer->SrbIoCtrl.HeaderLength = sizeof(SRB_IO_CONTROL);

         memcpy((UCHAR*)(&pInBuffer->SrbIoCtrl.Signature[0]), NVME_SIG_STR, NVME_SIG_STR_LEN);
         pInBuffer->SrbIoCtrl.Timeout = NVME_PT_TIMEOUT;
         pInBuffer->SrbIoCtrl.Length = InputBufLen - sizeof(SRB_IO_CONTROL);

        pInBuffer->Direction = NVME_FROM_DEV_TO_HOST;

         pInBuffer->NVMeCmd[0]=0x6;
         pInBuffer->NVMeCmd[10]=0x1;


         pInBuffer->DataBufferLen = ByteSizeTX;
         pInBuffer->ReturnBufferLen=OutputBufLen;


         Status = DeviceIoControl(
                  disk_handle,                                  /* Handle to \\.\scsi<file:///\\.\scsi> device via CreateFile */
                  IOCTL_SCSI_MINIPORT,   /* IO control function to a miniport driver */
                  pInBuffer         ,                      /* Input buffer with data sent to driver */
                  InputBufLen,                          /* Length of data sent to driver (in bytes) */
                  pOutBuffer,                             /* Output buffer with data received from driver */
                  OutputBufLen,                       /* Length of data received from driver */
                  &Count,                                  /* Bytes placed in DataBuffer */

                  NULL);                                   /* NULL = no overlap */



In addition, I have launched "DebugView" on the test machine and I seem to get the following messages, produced by sending the IOCTL

"

55461250000 - STORMINI: NVMeProcessIoctl: Code = 0xe0002000, Signature = 0xNvmeMinið

55461250000 - STORMINI: NVMeGetPhysAddr: <Error> Invalid phys addr.

"

Can you please help me to understand what am I doing wrong ?



Thank you,




Sagi Bar
Test & Tools Staff FW Engineer
[cid:image001.png at 01CEA3CD.FE1957E0]
7 Atir Yeda St, Kfar - Saba 44425, Israel
T: +972-9-7632774  | M: +972-54-7665567
F: +972-3-5488666
sagi.bar at SanDisk.com<mailto:sagi.bar at SanDisk.com>


________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140702/c62ffcbc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2139 bytes
Desc: image001.png
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140702/c62ffcbc/attachment.png>

From cheng.peng at memblaze.com  Wed Jul  2 00:11:16 2014
From: cheng.peng at memblaze.com (cheng.peng at memblaze.com)
Date: Wed, 2 Jul 2014 15:11:16 +0800
Subject: [nvmewin] Bug Check 133
References: <2014063017043810636219@memblaze.com>, 
	<2014063017063155639420@memblaze.com>, 
	<E1729D5DBAB9E948BA87B76FDFA1298A0C8A227B@BBYEXM02.pmc-sierra.internal>,
	<2014070110044647748612@memblaze.com>
Message-ID: <2014070215111538291315@memblaze.com>

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; nvmewin
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
Date: 2014-07-01 00:09
To: cheng.peng at memblaze.com; nvmewin
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] 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140702/8dc5ebe7/attachment.html>

From Alex.Chang at pmcs.com  Wed Jul  2 09:18:28 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Wed, 2 Jul 2014 16:18:28 +0000
Subject: [nvmewin] Bug Check 133
In-Reply-To: <2014070215111538291315@memblaze.com>
References: <2014063017043810636219@memblaze.com>,
	<2014063017063155639420@memblaze.com>,
	<E1729D5DBAB9E948BA87B76FDFA1298A0C8A227B@BBYEXM02.pmc-sierra.internal>,
	<2014070110044647748612@memblaze.com>
	<2014070215111538291315@memblaze.com>
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C8A24AA@BBYEXM02.pmc-sierra.internal>

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

From: cheng.peng at memblaze.com<mailto:cheng.peng at memblaze.com>
Date: 2014-07-01 10: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: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: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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140702/0bc17ead/attachment.html>

From judy.brock at ssi.samsung.com  Wed Jul  2 17:58:45 2014
From: judy.brock at ssi.samsung.com (Judy Brock-SSI)
Date: Thu, 3 Jul 2014 00:58:45 +0000
Subject: [nvmewin] Release 1.4 Plan and schedule
In-Reply-To: <03D88B383FA04244AA514AA931F7B1290D33DC3A@BBYEXM02.pmc-sierra.internal>
References: <03D88B383FA04244AA514AA931F7B1290D33DC3A@BBYEXM02.pmc-sierra.internal>
Message-ID: <36E8D38D6B771A4BBDB1C0D800158A516B636673@SSIEXCH-MB3.ssi.samsung.com>


Hi,

FYI, Suman Prakash will be driving the development work and submissions on behalf of Samsung.  Both Suman and I will support the integration and acceptance of these submissions.

Thanks a lot,
Judy

From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Kwok Kong
Sent: Monday, June 30, 2014 3:12 PM
To: nvmewin at lists.openfabrics.org
Subject: [nvmewin] Release 1.4 Plan and schedule

All,

I am happy to announce that we now have a solid plan with commitment from a few companies to contribute to the 1.4 release of the driver by Nov 2014.  Thanks to all the companies who contribute resource to make it happen.  The plan is to follow as:


Code commit order and Feature                               By                                           Date                                      Note


1.       Migrate to VS2013, WDK 8.1                        Tom Freeman at hgst       end of July

2.       WHQL Certification test                                 Alex Chang at PMC           early Aug                             include suggestion by Samsung

3.       buglist as suggested by Samsung (attached)        Judy @Samsung               Mid Aug

4.       WPP Tracing/WMI  processing                   Tom Freeman at hgst       end of Aug

5.       NVMe format enhancement                      Alex Chang at PMC           early Sep

6.       Bus reset enhancement                               Judy at Samsung                Mid Sep

7.       Hot plug/swap                                                  Judy @Samsung               End of  Oct

Release 1.4 will be tested with  VS2013, WDK 8.1 only. Older version of the tools may work but not be verified by the working group.
Let's focus on getting release 1.4 out by Nov 2014. Go team Go.

Thanks

-Kwok


Here is the meeting note for the May 21 2014 meeting:

====== ==

NVMe OFA Windows Driver Meeting Note (May 21, 2014)

Meeting Status
==============


1.            Reviewed 1.3 release
                - No further comment from the group.

2.            The group agreed on the following features for the 1.4 Release

                - Driver Trace feature (WPP tracing) - Tom Freeman at hgst
                - WMI commands processing - Tom Freeman at hgst
                - Migrate to VS2013, WDK 8.1 - Tom Freeman at hgst
                - WHQL Certification test - Alex Chang at PMC
                - NVMe format enhancement / bug fix - Alex Chang at PMC

3.            Expected release date for 1.4 is Nov 2014

4.            Hot plug (graceful hot add/remove) and hot swap (surprised hot add/remove)
                features were discussed. Austin bolen from Dell said that surprise hot add/remove
                had been in the PCIe standard since version 1.  We should support it in future
                release of the driver.

                We would consider adding hot plug/swap support in future release of the driver.

5.            The group reviewed the bug list / new features per suggestion from Judy @ Samsung.
                - We agreed that everything on the list should be fixed.
                - Need volunteers to work on the fix with the 1.4 release
                - Judy was going to check with her management team if she could submit patches to fix
                  all these problems.



Features that are not supported currently
=========================================

                NVMe 1.1 support:
                - multi-path
                - SGL
                - Get/Set feature update
                                - Autonomous power state transition
                                - Host Identifier
                                - Reservation Notification Mask
                                - Reservation Persistence
                - identify structure update
                - write zeros command

                End to End Protection

                Hot Plug (graceful hot add/remove)

                Hot Swap (surprised hot add/remove)





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140703/5ab5f4f2/attachment.html>

From Alex.Chang at pmcs.com  Wed Jul  2 18:02:15 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Thu, 3 Jul 2014 01:02:15 +0000
Subject: [nvmewin] Release 1.4 Plan and schedule
In-Reply-To: <36E8D38D6B771A4BBDB1C0D800158A516B636673@SSIEXCH-MB3.ssi.samsung.com>
References: <03D88B383FA04244AA514AA931F7B1290D33DC3A@BBYEXM02.pmc-sierra.internal>
	<36E8D38D6B771A4BBDB1C0D800158A516B636673@SSIEXCH-MB3.ssi.samsung.com>
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C8A2551@BBYEXM02.pmc-sierra.internal>

Thank you, Judy and Suman. Looking forward to working with you both!

Regards,
Alex

From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Judy Brock-SSI
Sent: Wednesday, July 02, 2014 5:59 PM
To: Kwok Kong; nvmewin at lists.openfabrics.org
Subject: Re: [nvmewin] Release 1.4 Plan and schedule


Hi,

FYI, Suman Prakash will be driving the development work and submissions on behalf of Samsung.  Both Suman and I will support the integration and acceptance of these submissions.

Thanks a lot,
Judy

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Kwok Kong
Sent: Monday, June 30, 2014 3:12 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Release 1.4 Plan and schedule

All,

I am happy to announce that we now have a solid plan with commitment from a few companies to contribute to the 1.4 release of the driver by Nov 2014.  Thanks to all the companies who contribute resource to make it happen.  The plan is to follow as:


Code commit order and Feature                               By                                           Date                                      Note


1.       Migrate to VS2013, WDK 8.1                        Tom Freeman at hgst       end of July

2.       WHQL Certification test                                 Alex Chang at PMC           early Aug                             include suggestion by Samsung

3.       buglist as suggested by Samsung (attached)        Judy @Samsung               Mid Aug

4.       WPP Tracing/WMI  processing                   Tom Freeman at hgst       end of Aug

5.       NVMe format enhancement                      Alex Chang at PMC           early Sep

6.       Bus reset enhancement                               Judy at Samsung                Mid Sep

7.       Hot plug/swap                                                  Judy @Samsung               End of  Oct

Release 1.4 will be tested with  VS2013, WDK 8.1 only. Older version of the tools may work but not be verified by the working group.
Let's focus on getting release 1.4 out by Nov 2014. Go team Go.

Thanks

-Kwok


Here is the meeting note for the May 21 2014 meeting:

====== ==

NVMe OFA Windows Driver Meeting Note (May 21, 2014)

Meeting Status
==============


1.            Reviewed 1.3 release
                - No further comment from the group.

2.            The group agreed on the following features for the 1.4 Release

                - Driver Trace feature (WPP tracing) - Tom Freeman at hgst
                - WMI commands processing - Tom Freeman at hgst
                - Migrate to VS2013, WDK 8.1 - Tom Freeman at hgst
                - WHQL Certification test - Alex Chang at PMC
                - NVMe format enhancement / bug fix - Alex Chang at PMC

3.            Expected release date for 1.4 is Nov 2014

4.            Hot plug (graceful hot add/remove) and hot swap (surprised hot add/remove)
                features were discussed. Austin bolen from Dell said that surprise hot add/remove
                had been in the PCIe standard since version 1.  We should support it in future
                release of the driver.

                We would consider adding hot plug/swap support in future release of the driver.

5.            The group reviewed the bug list / new features per suggestion from Judy @ Samsung.
                - We agreed that everything on the list should be fixed.
                - Need volunteers to work on the fix with the 1.4 release
                - Judy was going to check with her management team if she could submit patches to fix
                  all these problems.



Features that are not supported currently
=========================================

                NVMe 1.1 support:
                - multi-path
                - SGL
                - Get/Set feature update
                                - Autonomous power state transition
                                - Host Identifier
                                - Reservation Notification Mask
                                - Reservation Persistence
                - identify structure update
                - write zeros command

                End to End Protection

                Hot Plug (graceful hot add/remove)

                Hot Swap (surprised hot add/remove)





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140703/55856b39/attachment.html>

From cheng.peng at memblaze.com  Thu Jul  3 01:06:32 2014
From: cheng.peng at memblaze.com (cheng.peng at memblaze.com)
Date: Thu, 3 Jul 2014 16:06:32 +0800
Subject: [nvmewin] Bug Check 133
References: <2014063017043810636219@memblaze.com>, 
	<2014063017063155639420@memblaze.com>, 
	<E1729D5DBAB9E948BA87B76FDFA1298A0C8A227B@BBYEXM02.pmc-sierra.internal>,
	<2014070110044647748612@memblaze.com>, 
	<2014070215111538291315@memblaze.com>, 
	<E1729D5DBAB9E948BA87B76FDFA1298A0C8A24AA@BBYEXM02.pmc-sierra.internal>
Message-ID: <2014070316063164889516@memblaze.com>

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
Date: 2014-07-03 00:18
To: cheng.peng at memblaze.com; nvmewin
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; nvmewin
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
Date: 2014-07-01 00:09
To: cheng.peng at memblaze.com; nvmewin
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] 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140703/43e90428/attachment.html>

From abhijit.khande at gmail.com  Thu Jul  3 09:52:24 2014
From: abhijit.khande at gmail.com (Abhijit Khande)
Date: Thu, 3 Jul 2014 22:22:24 +0530
Subject: [nvmewin] Bug Check 133
In-Reply-To: <2014070316063164889516@memblaze.com>
References: <2014063017043810636219@memblaze.com>
	<2014063017063155639420@memblaze.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C8A227B@BBYEXM02.pmc-sierra.internal>
	<2014070110044647748612@memblaze.com>
	<2014070215111538291315@memblaze.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C8A24AA@BBYEXM02.pmc-sierra.internal>
	<2014070316063164889516@memblaze.com>
Message-ID: <CAF5Wg=6UVciQQLWO9aw7PAuJmaopSKO6YEaddqFZsrL=R2Nkhw@mail.gmail.com>

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>

From purush.gupta at nutanix.com  Thu Jul  3 10:13:43 2014
From: purush.gupta at nutanix.com (Purush Gupta)
Date: Thu, 3 Jul 2014 10:13:43 -0700
Subject: [nvmewin] nvmewin Digest, Vol 31, Issue 6
In-Reply-To: <mailman.865.1404374170.381.nvmewin@lists.openfabrics.org>
References: <mailman.865.1404374170.381.nvmewin@lists.openfabrics.org>
Message-ID: <CAN7X1U=MVj8g+de4pBLB9vpvUNuppbQOdH-aWhyEJn+UaVNiPg@mail.gmail.com>

One place to start debug is dumping the registers of the device and look
for race conditions.

Thanks,
Purush


On Thu, Jul 3, 2014 at 12:56 AM, <nvmewin-request at lists.openfabrics.org>
wrote:

> Send nvmewin mailing list submissions to
>         nvmewin at lists.openfabrics.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.openfabrics.org/mailman/listinfo/nvmewin
> or, via email, send a message with subject or body 'help' to
>         nvmewin-request at lists.openfabrics.org
>
> You can reach the person managing the list at
>         nvmewin-owner at lists.openfabrics.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of nvmewin digest..."
>
>
> Today's Topics:
>
>    1. Re: Bug Check 133 (cheng.peng at memblaze.com)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 3 Jul 2014 16:06:32 +0800
> From: "cheng.peng at memblaze.com" <cheng.peng at memblaze.com>
> To: "Alex Chang" <Alex.Chang at pmcs.com>,         nvmewin
>         <nvmewin at lists.openfabrics.org>
> Subject: Re: [nvmewin] Bug Check 133
> Message-ID: <2014070316063164889516 at memblaze.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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
> Date: 2014-07-03 00:18
> To: cheng.peng at memblaze.com; nvmewin
> 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; nvmewin
> 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
> Date: 2014-07-01 00:09
> To: cheng.peng at memblaze.com; nvmewin
> 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] 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
> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140703/43e90428/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> nvmewin mailing list
> nvmewin at lists.openfabrics.org
> http://lists.openfabrics.org/mailman/listinfo/nvmewin
>
>
> End of nvmewin Digest, Vol 31, Issue 6
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140703/8f248fe9/attachment.html>

From Alex.Chang at pmcs.com  Thu Jul  3 10:33:55 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Thu, 3 Jul 2014 17:33:55 +0000
Subject: [nvmewin] Sample Application Using IOCTL Pass Thru
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C8A25AE@BBYEXM02.pmc-sierra.internal>

Hi all,

Thank you, Ray from Intel, for sharing the application.
Under "release" directory, you may find a folder called "IOCTL_Sample_App", where all the necessary source files, solution file, etc. are located.
Should you have any questions, please reply this message.

Thanks,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140703/b399b044/attachment.html>

From Alex.Chang at pmcs.com  Thu Jul  3 11:07:56 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Thu, 3 Jul 2014 18:07:56 +0000
Subject: [nvmewin] Bug Check 133
In-Reply-To: <CAF5Wg=6UVciQQLWO9aw7PAuJmaopSKO6YEaddqFZsrL=R2Nkhw@mail.gmail.com>
References: <2014063017043810636219@memblaze.com>
	<2014063017063155639420@memblaze.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C8A227B@BBYEXM02.pmc-sierra.internal>
	<2014070110044647748612@memblaze.com>
	<2014070215111538291315@memblaze.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C8A24AA@BBYEXM02.pmc-sierra.internal>
	<2014070316063164889516@memblaze.com>
	<CAF5Wg=6UVciQQLWO9aw7PAuJmaopSKO6YEaddqFZsrL=R2Nkhw@mail.gmail.com>
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C8A25C6@BBYEXM02.pmc-sierra.internal>

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>

From cheng.peng at memblaze.com  Thu Jul  3 19:19:15 2014
From: cheng.peng at memblaze.com (cheng.peng at memblaze.com)
Date: Fri, 4 Jul 2014 10:19:15 +0800
Subject: [nvmewin] Bug Check 133
References: <2014063017043810636219@memblaze.com>, 
	<2014063017063155639420@memblaze.com>, 
	<E1729D5DBAB9E948BA87B76FDFA1298A0C8A227B@BBYEXM02.pmc-sierra.internal>,
	<2014070110044647748612@memblaze.com>, 
	<2014070215111538291315@memblaze.com>, 
	<E1729D5DBAB9E948BA87B76FDFA1298A0C8A24AA@BBYEXM02.pmc-sierra.internal>,
	<2014070316063164889516@memblaze.com>, 
	<CAF5Wg=6UVciQQLWO9aw7PAuJmaopSKO6YEaddqFZsrL=R2Nkhw@mail.gmail.com>, 
	<E1729D5DBAB9E948BA87B76FDFA1298A0C8A25C6@BBYEXM02.pmc-sierra.internal>
Message-ID: <201407041019081285240@memblaze.com>

Thanks very much for all of you



cheng.peng at memblaze.com
 
From: Alex Chang
Date: 2014-07-04 02:07
To: Abhijit Khande; cheng.peng at memblaze.com
CC: nvmewin
Subject: RE: [nvmewin] Bug Check 133
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 <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
Date: 2014-07-03 00:18
To: cheng.peng at memblaze.com; nvmewin
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; nvmewin
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
Date: 2014-07-01 00:09
To: cheng.peng at memblaze.com; nvmewin
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] 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
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/20140704/e4d2e110/attachment.html>

From mikeb at bustrace.com  Tue Jul  8 07:47:59 2014
From: mikeb at bustrace.com (Mike Berhan)
Date: Tue, 8 Jul 2014 08:47:59 -0600
Subject: [nvmewin] Add SCSI SSD Log Page Support
Message-ID: <010901cf9abb$9d4d1470$d7e73d50$@bustrace.com>

I don't know if this has been brought up before but I wanted to bring up the
topic of SCSI SSD Log Page support.

Request #1 - NVMe SCSI Translation Reference - Add SCSI SSD Log Page 11h

The NVM_Express_-_SCSI_Translation_Reference-1_2_03172014.pdf specification
only details support for log page 00h, 0Dh, and 2Fh.  All others shall fail
with an invalid field in CDB check condition.  This is what the current NVMe
Windows driver does in its SntiTranslateLogSense() handler.

I would like to see the next revision of this specification add support for
log page 11h (Solid State Media log page) as defined in the SBC-3
specification.  Parameter code 0001h would be supported (Percentage Used
Endurance Indicator).  The required information would come from the NVMe
SMART / Health Information page (Log Identifier 02h).  The NVMe "Percentage
Used" indicator (Byte 5) matches the definition used by the SBC-3 log page.

I'll send this email separately to info at nvmexpress.org to request this
change.

Request #2 - Update Windows miniport driver to support SCSI SSD Log Page 11h

Modify the SntiTranslateLogSense() and SntiTranslateLogSenseResponse()
routines to add SCSI log page 11h support.  There is already code present to
retrieve the SMART/Health log so adding support seems relatively simple.
I'd offer to make the code change but unfortunately I do not yet have an
NVMe drive to validate against.

The reason for my request is that this change allows host software to
determine the EOL state of an NVMe drive using industry standard CDBs.  I
realize that an NVMe pass through command could be used to perform the same
task.  I just believe it should be part of the CDB mapping.  It also allows
a more "seamless transition" to NVMe as detailed in the current
specification's Theory of Operation:

"There are existing applications and software infrastructure built upon the
SCSI architectural model defined by T10. The purpose of this document is to
define a mapping between SCSI and NVM Express specifications to enable a
seamless transition to NVM Express by preserving existing software
infrastructure investments."

Mike Berhan
busTRACE Technologies





From carolyn.d.foster at intel.com  Tue Jul  8 13:10:26 2014
From: carolyn.d.foster at intel.com (Foster, Carolyn D)
Date: Tue, 8 Jul 2014 20:10:26 +0000
Subject: [nvmewin] NVMe OFA Patch Update for CPU Learning Mode
Message-ID: <B3A485AFDDB1DD4598621E85E8EB67A83AB7768E@FMSMSX105.amr.corp.intel.com>

Hi Everyone,
I have a patch for review with some fixes for the recent CPU patch that I submitted.  Please send feedback by Tuesday, July 15th.  The password is intel123

Problem statement:
There were scenarios observed where the CPU core to MSI vector mapping weren't assigning the IO queue pairs appropriately.  We would see that queue pairs weren't being assigned in a unique manner during the learning mode phase.  There were also cases when an NVMe Reset would clear out the core table mapping that was set up during the initial learning mode.  The incorrect mapping resulted in IOs not being completed, which could result in crashes or slow performance.

Changes made:
The original algorithm relied on the initial queue assignment, which wasn't guaranteed to be unique.  The fix was to use a counter to track the IO queues that had already been mapped to a logical CPU core and MSI vector.  Now when a CPU core is mapped to an MSI vector, we assign the IO queue pair using the current counter value and increment the counter.

Files changed:
nvmeInit.c

-          In InitSubQueue there was a bug where we would go into shared mode because the number of queues allocated was less than the number of cores, it should have been comparing the number of queues allocated to the maxCore variable.

-          In InitCplQueue we come through this function after a reset.  Learning mode is already complete, so we don't need to reset the core table message ID in this case.

-          In InitCallBack when learning mode is complete, there's a check to make sure we mapped all the queues to MSI vectors, if we didn't, then we'll go back to shared mode.
nvmeStat.c

-          There were a few places where LearningCores was assigned the wrong value, LearningCores should always be the number of active cores, that's how it's clear that learning mode is complete.
nvmeStd.c

-          The main change here is in the IoCompletionDpcRoutine, during learning mode.  We now track if an MSI vector has been learned, and if it hasn't then we set up the mapping of CPU core, to MSI vector, to IO queue pair.  We also assign the queue pair using the new counter, NumIoQMapped.

Unit tests
Win 7, Win8.1, Server 2012 r2, server 2008 r2
Boot
Hibernate
Enable/Disable Controller
Iometer/SDStress
SCSI compliance
Client and Server Platforms
IO timeouts with resets
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140708/abdd26fd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IntelCpuPatch2_v1_07072014.zip
Type: application/x-zip-compressed
Size: 172687 bytes
Desc: IntelCpuPatch2_v1_07072014.zip
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140708/abdd26fd/attachment.bin>

From Alex.Chang at pmcs.com  Tue Jul  8 14:03:42 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Tue, 8 Jul 2014 21:03:42 +0000
Subject: [nvmewin] NVMe OFA Patch Update for CPU Learning Mode
In-Reply-To: <18325_1404850237_53BC503D_18325_14313_1_B3A485AFDDB1DD4598621E85E8EB67A83AB7768E@FMSMSX105.amr.corp.intel.com>
References: <18325_1404850237_53BC503D_18325_14313_1_B3A485AFDDB1DD4598621E85E8EB67A83AB7768E@FMSMSX105.amr.corp.intel.com>
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C8A298A@BBYEXM02.pmc-sierra.internal>

Hi all,

Firstly, thank you, Carolyn, for adding the changes.
Please review/test the patch as soon as possible and I will start to collect approvals after July 15.

Thank you all,
Alex

From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Foster, Carolyn D
Sent: Tuesday, July 08, 2014 1:10 PM
To: nvmewin at lists.openfabrics.org
Subject: [nvmewin] NVMe OFA Patch Update for CPU Learning Mode


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Everyone,
I have a patch for review with some fixes for the recent CPU patch that I submitted.  Please send feedback by Tuesday, July 15th.  The password is intel123

Problem statement:
There were scenarios observed where the CPU core to MSI vector mapping weren't assigning the IO queue pairs appropriately.  We would see that queue pairs weren't being assigned in a unique manner during the learning mode phase.  There were also cases when an NVMe Reset would clear out the core table mapping that was set up during the initial learning mode.  The incorrect mapping resulted in IOs not being completed, which could result in crashes or slow performance.

Changes made:
The original algorithm relied on the initial queue assignment, which wasn't guaranteed to be unique.  The fix was to use a counter to track the IO queues that had already been mapped to a logical CPU core and MSI vector.  Now when a CPU core is mapped to an MSI vector, we assign the IO queue pair using the current counter value and increment the counter.

Files changed:
nvmeInit.c

-          In InitSubQueue there was a bug where we would go into shared mode because the number of queues allocated was less than the number of cores, it should have been comparing the number of queues allocated to the maxCore variable.

-          In InitCplQueue we come through this function after a reset.  Learning mode is already complete, so we don't need to reset the core table message ID in this case.

-          In InitCallBack when learning mode is complete, there's a check to make sure we mapped all the queues to MSI vectors, if we didn't, then we'll go back to shared mode.
nvmeStat.c

-          There were a few places where LearningCores was assigned the wrong value, LearningCores should always be the number of active cores, that's how it's clear that learning mode is complete.
nvmeStd.c

-          The main change here is in the IoCompletionDpcRoutine, during learning mode.  We now track if an MSI vector has been learned, and if it hasn't then we set up the mapping of CPU core, to MSI vector, to IO queue pair.  We also assign the queue pair using the new counter, NumIoQMapped.

Unit tests
Win 7, Win8.1, Server 2012 r2, server 2008 r2
Boot
Hibernate
Enable/Disable Controller
Iometer/SDStress
SCSI compliance
Client and Server Platforms
IO timeouts with resets
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140708/bf6b5753/attachment.html>

From Alex.Chang at pmcs.com  Mon Jul 14 13:19:34 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Mon, 14 Jul 2014 20:19:34 +0000
Subject: [nvmewin] Intel Patch Review
In-Reply-To: <e751855c5332c1d29dfd4195068ca4ff@mail.gmail.com>
References: <E1729D5DBAB9E948BA87B76FDFA1298A398E6C5E@BBYEXM02.pmc-sierra.internal>
	<e751855c5332c1d29dfd4195068ca4ff@mail.gmail.com>
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A398E6C8B@BBYEXM02.pmc-sierra.internal>

Thank you, Rick.

Alex

From: Rick Knoblaugh [mailto:rick.knoblaugh at avagotech.com]
Sent: Monday, July 14, 2014 1:08 PM
To: Alex Chang
Subject: RE: Intel Patch Review

Hi Alex,

                     I had on my to do list for today to respond back on that one. We are good with this patch.

Thanks,

                  -Rick

From: Alex Chang [mailto:Alex.Chang at pmcs.com<mailto:Alex.Chang at pmcs.com>]
Sent: Monday, July 14, 2014 11:46 AM
To: rick.knoblaugh at avagotech.com<mailto:rick.knoblaugh at avagotech.com>
Subject: Intel Patch Review

Hi Rick,

Hope you’re doing well. Carolyn sent out a patch last week, I plan to push it as soon as possible. Please let me know when you’ll approve it.

Thanks,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140714/3893dfd7/attachment.html>

From Alex.Chang at pmcs.com  Fri Jul 18 14:06:50 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Fri, 18 Jul 2014 21:06:50 +0000
Subject: [nvmewin] NVMe Windows DB Is LOCKED - Pushing Patch From Intel For
 Core Mapping Changes
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A398E72EA@BBYEXM02.pmc-sierra.internal>

Locking NVMe Windows DB.

Thanks,
Alex

nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140718/b3fd6285/attachment.html>

From Alex.Chang at pmcs.com  Fri Jul 18 14:45:52 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Fri, 18 Jul 2014 21:45:52 +0000
Subject: [nvmewin] NVMe Windows DB Is UNLOCKED - Pushing Patch From
 Intel For Core Mapping Changes
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A398E7302@BBYEXM02.pmc-sierra.internal>

Hi all,

Thank you for reviewing/testing the patch contributed by Carolyn from Intel. Thank you! Carolyn.
The patch had been pushed into the source base and a new tag called "Patch#26_CPU_MSI_Map_Learning_Fixes_Part#2" had been created under tags directory.
Next scheduled patch will be "Migrate to VS 2013 and WDK 8.1" from HGST. Should you have any questions, please reply to the email listed below.

Thanks,
Alex

nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140718/711c917d/attachment.html>

From Alex.Chang at pmcs.com  Fri Jul 18 14:52:16 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Fri, 18 Jul 2014 21:52:16 +0000
Subject: [nvmewin] Patch From HGST
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A398E7315@BBYEXM02.pmc-sierra.internal>

Hi Tom and Moji,

Intel patch had been pushed into the trunk and it's ready for you to re-base your changes. You may send out your patch for the community to review/test when you're ready. Thank you very much for your contribution.

Have a great weekend!
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140718/e37f0045/attachment.html>

From Sagi.Bar at sandisk.com  Tue Jul 22 05:20:48 2014
From: Sagi.Bar at sandisk.com (Sagi Bar)
Date: Tue, 22 Jul 2014 12:20:48 +0000
Subject: [nvmewin] Implementing a debug purpose Read/Write using
	IOCTL_SCSI_MINIPORT
Message-ID: <E5B55DF4CB9A114395C0A6E7895C3B67232A7683@SACMBXIP01.sdcorp.global.sandisk.com>


Hello Guys,

I would like to implement a debug purpose flow of performing NVME disk IO bypassing the StorPort under Windows 8.1.

I thought about implementing it using "IOCTL_SCSI_MINIPORT" on host side and adding code under "NVM_WRITE/ NVM_READ" on the target side.

I wonder whether anyone here has done it before and can share insights.

Moreover, Is there any particular reason why NVME READ/WRITE commands are not implanted via IOCTL interface, except security ?

Thank you,

Sagi Bar
Test & Tools Staff FW Engineer
[cid:image001.png at 01CEA3CD.FE1957E0]
7 Atir Yeda St, Kfar - Saba 44425, Israel
sagi.bar at SanDisk.com<mailto:sagi.bar at SanDisk.com>


________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140722/8650789a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2139 bytes
Desc: image001.png
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140722/8650789a/attachment.png>

From Alex.Chang at pmcs.com  Tue Jul 22 16:35:29 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Tue, 22 Jul 2014 23:35:29 +0000
Subject: [nvmewin] Implementing a debug purpose Read/Write
	using	IOCTL_SCSI_MINIPORT
In-Reply-To: <E5B55DF4CB9A114395C0A6E7895C3B67232A7683@SACMBXIP01.sdcorp.global.sandisk.com>
References: <E5B55DF4CB9A114395C0A6E7895C3B67232A7683@SACMBXIP01.sdcorp.global.sandisk.com>
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A398E74C3@BBYEXM02.pmc-sierra.internal>

Hi Sagi,

Yes, you're right that it's due to security reasons and, in addition, you may access the associated storage as a physical or formatted drive with Windows supported APIs for your debugging purposes, like IOMeter does.

Thanks,
Alex

From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sagi Bar
Sent: Tuesday, July 22, 2014 5:21 AM
To: nvmewin at lists.openfabrics.org
Cc: Roman Goldshtein
Subject: [nvmewin] Implementing a debug purpose Read/Write using IOCTL_SCSI_MINIPORT


Hello Guys,

I would like to implement a debug purpose flow of performing NVME disk IO bypassing the StorPort under Windows 8.1.

I thought about implementing it using "IOCTL_SCSI_MINIPORT" on host side and adding code under "NVM_WRITE/ NVM_READ" on the target side.

I wonder whether anyone here has done it before and can share insights.

Moreover, Is there any particular reason why NVME READ/WRITE commands are not implanted via IOCTL interface, except security ?

Thank you,

Sagi Bar
Test & Tools Staff FW Engineer
[cid:image001.png at 01CEA3CD.FE1957E0]
7 Atir Yeda St, Kfar - Saba 44425, Israel
sagi.bar at SanDisk.com<mailto:sagi.bar at SanDisk.com>


________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140722/870b3327/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2139 bytes
Desc: image001.png
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140722/870b3327/attachment.png>

From Sagi.Bar at sandisk.com  Thu Jul 24 03:23:14 2014
From: Sagi.Bar at sandisk.com (Sagi Bar)
Date: Thu, 24 Jul 2014 10:23:14 +0000
Subject: [nvmewin] Implementing a debug purpose Read/Write
	using	IOCTL_SCSI_MINIPORT
In-Reply-To: <E1729D5DBAB9E948BA87B76FDFA1298A398E74C3@BBYEXM02.pmc-sierra.internal>
References: <E5B55DF4CB9A114395C0A6E7895C3B67232A7683@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A398E74C3@BBYEXM02.pmc-sierra.internal>
Message-ID: <E5B55DF4CB9A114395C0A6E7895C3B67232A7CB4@SACMBXIP01.sdcorp.global.sandisk.com>

Hello Alex,

Thank you for your answer.
I see that the driver has a readily implemented NVMePreparePRPs(...) so adding an extra command shouldn't be an issue.

I might need this feature in order to prevent the StorPort driver from dividing the request into smaller SRBs (debug purposes).

Thank you,


Sagi Bar
Test & Tools Staff FW Engineer
[cid:image001.png at 01CEA3CD.FE1957E0]
7 Atir Yeda St, Kfar - Saba 44425, Israel

sagi.bar at SanDisk.com<mailto:sagi.bar at SanDisk.com>

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Wednesday, July 23, 2014 2:35 AM
To: Sagi Bar; nvmewin at lists.openfabrics.org
Cc: Roman Goldshtein
Subject: RE: [nvmewin] Implementing a debug purpose Read/Write using IOCTL_SCSI_MINIPORT

Hi Sagi,

Yes, you're right that it's due to security reasons and, in addition, you may access the associated storage as a physical or formatted drive with Windows supported APIs for your debugging purposes, like IOMeter does.

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 Sagi Bar
Sent: Tuesday, July 22, 2014 5:21 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Cc: Roman Goldshtein
Subject: [nvmewin] Implementing a debug purpose Read/Write using IOCTL_SCSI_MINIPORT


Hello Guys,

I would like to implement a debug purpose flow of performing NVME disk IO bypassing the StorPort under Windows 8.1.

I thought about implementing it using "IOCTL_SCSI_MINIPORT" on host side and adding code under "NVM_WRITE/ NVM_READ" on the target side.

I wonder whether anyone here has done it before and can share insights.

Moreover, Is there any particular reason why NVME READ/WRITE commands are not implanted via IOCTL interface, except security ?

Thank you,

Sagi Bar
Test & Tools Staff FW Engineer
[cid:image001.png at 01CEA3CD.FE1957E0]
7 Atir Yeda St, Kfar - Saba 44425, Israel
sagi.bar at SanDisk.com<mailto:sagi.bar at SanDisk.com>


________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140724/744aaa73/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2139 bytes
Desc: image001.png
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140724/744aaa73/attachment.png>

From Sagi.Bar at sandisk.com  Thu Jul 24 03:33:18 2014
From: Sagi.Bar at sandisk.com (Sagi Bar)
Date: Thu, 24 Jul 2014 10:33:18 +0000
Subject: [nvmewin] Implementing Arbitration in the community driver
Message-ID: <E5B55DF4CB9A114395C0A6E7895C3B67232A7CCE@SACMBXIP01.sdcorp.global.sandisk.com>


Hello,

I am currently reviewing the community driver and have the following question:

I would like to experiment with Weighted Round Robin arbitration.

I see that I can set the arbitration using the community driver implementation of the NVME "Set Features" command.

However, in order to use a weighted RR, queue priority should be set.

AFAIK, the only time you can set the Submission Queue priority is during the Queue creation, which is done automatically by the driver.

The field is defined in the "ADMIN_CREATE_IO_SUBMISSION_QUEUE_DW11" structure.

    /*
     * [Queue Priority] This field indicates the priority service class to use
     * for commands within this Submission Queue. This field is only used when
     * the weighted round robin with an urgent priority service class is the
     * arbitration mechanism is selected. Refer to section 4.7. Value 00b ==
     * Urgent, Value 01b == High, Value 10b == Medium, Value 11b == Low.
     */
    ULONG   QPRIO   :2;


My question is :

It appears that the only way to actually set the WRR priority is to delete all Submission Queues, initially created by the driver and re-create them with the correct weight assigned.
This is due to the fact that I don't see a way of settings Submission Queue priority after the queue is created.

Do you think that there is an easier way to do that ?

Sagi Bar
Test & Tools Staff FW Engineer
[cid:image001.png at 01CEA3CD.FE1957E0]
7 Atir Yeda St, Kfar - Saba 44425, Israel

sagi.bar at SanDisk.com<mailto:sagi.bar at SanDisk.com>


________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140724/1f698a61/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2139 bytes
Desc: image001.png
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140724/1f698a61/attachment.png>

From mikeb at bustrace.com  Thu Jul 24 10:41:30 2014
From: mikeb at bustrace.com (Mike Berhan)
Date: Thu, 24 Jul 2014 11:41:30 -0600
Subject: [nvmewin] Implementing a debug purpose
	Read/Write	using	IOCTL_SCSI_MINIPORT
In-Reply-To: <E5B55DF4CB9A114395C0A6E7895C3B67232A7CB4@SACMBXIP01.sdcorp.global.sandisk.com>
References: <E5B55DF4CB9A114395C0A6E7895C3B67232A7683@SACMBXIP01.sdcorp.global.sandisk.com>	<E1729D5DBAB9E948BA87B76FDFA1298A398E74C3@BBYEXM02.pmc-sierra.internal>
	<E5B55DF4CB9A114395C0A6E7895C3B67232A7CB4@SACMBXIP01.sdcorp.global.sandisk.com>
Message-ID: <010801cfa766$8125bab0$83713010$@bustrace.com>

Sagi,

 

The disk class driver is the one that divides reads and writes into smaller
requests.  It determines how to divide the request by querying the
STORAGE_ADAPTER_DESCRIPTOR.  STORPORT gets the information for this
structure from the miniport's PORT_CONFIGURATION_INFORMATION structure
(MaximumTransferLength and NumberOfPhysicalBreaks).

 

In reviewing the NVMe source code, it sets these values to max 128K with a
registry override available.  The INF file sets the override but it too
defaults to 128K:

 


HKR, Parameters\Device, MaxTXSize, %REG_DWORD%, 0x00020000 ; max trasnfer
size

 

Mike Berhan

busTRACE Technologies

1-208-629-4773 (Office)

 

From: nvmewin-bounces at lists.openfabrics.org
[mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sagi Bar
Sent: Thursday, July 24, 2014 4:23 AM
To: Alex Chang; nvmewin at lists.openfabrics.org
Cc: Roman Goldshtein
Subject: Re: [nvmewin] Implementing a debug purpose Read/Write using
IOCTL_SCSI_MINIPORT

 

Hello Alex,

 

Thank you for your answer.

I see that the driver has a readily implemented NVMePreparePRPs(.) so adding
an extra command shouldn't be an issue.

 

I might need this feature in order to prevent the StorPort driver from
dividing the request into smaller SRBs (debug purposes).

 

Thank you, 

 

 

Sagi Bar
Test & Tools Staff FW Engineer

7 Atir Yeda St, Kfar - Saba 44425, Israel

sagi.bar at SanDisk.com <mailto:sagi.bar at SanDisk.com> 

 

From: Alex Chang [mailto:Alex.Chang at pmcs.com] 
Sent: Wednesday, July 23, 2014 2:35 AM
To: Sagi Bar; nvmewin at lists.openfabrics.org
<mailto:nvmewin at lists.openfabrics.org> 
Cc: Roman Goldshtein
Subject: RE: [nvmewin] Implementing a debug purpose Read/Write using
IOCTL_SCSI_MINIPORT

 

Hi Sagi,

 

Yes, you're right that it's due to security reasons and, in addition, you
may access the associated storage as a physical or formatted drive with
Windows supported APIs for your debugging purposes, like IOMeter does.

 

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 Sagi Bar
Sent: Tuesday, July 22, 2014 5:21 AM
To: nvmewin at lists.openfabrics.org <mailto:nvmewin at lists.openfabrics.org> 
Cc: Roman Goldshtein
Subject: [nvmewin] Implementing a debug purpose Read/Write using
IOCTL_SCSI_MINIPORT

 

 

Hello Guys,

 

I would like to implement a debug purpose flow of performing NVME disk IO
bypassing the StorPort under Windows 8.1.

 

I thought about implementing it using "IOCTL_SCSI_MINIPORT" on host side and
adding code under "NVM_WRITE/ NVM_READ" on the target side.

 

I wonder whether anyone here has done it before and can share insights.

 

Moreover, Is there any particular reason why NVME READ/WRITE commands are
not implanted via IOCTL interface, except security ?

 

Thank you,

 

Sagi Bar
Test & Tools Staff FW Engineer

7 Atir Yeda St, Kfar - Saba 44425, Israel
sagi.bar at SanDisk.com <mailto:sagi.bar at SanDisk.com> 

 

 

  _____  


PLEASE NOTE: The information contained in this electronic mail message is
intended only for the use of the designated recipient(s) named above. If the
reader of this message is not the intended recipient, you are hereby
notified that you have received this message in error and that any review,
dissemination, distribution, or copying of this message is strictly
prohibited. If you have received this communication in error, please notify
the sender by telephone or e-mail (as shown above) immediately and destroy
any and all copies of this message in your possession (whether hard copies
or electronically stored copies).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140724/6c7313f7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2139 bytes
Desc: not available
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140724/6c7313f7/attachment.png>

From thomas.freeman at hgst.com  Sat Jul 26 12:33:59 2014
From: thomas.freeman at hgst.com (Thomas Freeman)
Date: Sat, 26 Jul 2014 19:33:59 +0000
Subject: [nvmewin] Changes for Visual Studio 2013/WDK 8.1 - Ready for Review
Message-ID: <5d84f241049a4a258f87ef025e8e790c@BLUPR04MB673.namprd04.prod.outlook.com>


I've attached the driver changes for updating the driver to run on Visual Studio 2013/WDK 8.1
Please review and respond with comments by August 4. The password for the attachment is "hgst1234"

By opening the driver solution under with Visual Studio 2013/WDK 8.1, the following files were updated:
nvme.vcxproj, nvme.vcxproj.filters, nvme.vcxproj.user
nvmePackage.vcxproj, nvmePackage.vcxproj.filters, nvmePackage.vcxproj.user

In the attachment, the file VS2013WDK81.patch details the changes made to each file.

Using a mixture of real hardware and QEMU, we ran the following tests on Windows 7, 8 and 8.1 (x64 only):
Quick & slow formatting - MBR and GPT, sdstress and IOMETER
There were errors running scsi compliance - those results are documented in the attached zip file.
These errors existed prior to these changes. Alex is aware of these errors and working to address them.


Tom Freeman
Thomas.Freeman at hgst.com<mailto:Thomas.Freeman at hgst.com>
507-322-2311

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140726/bcdf3a6a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 1117 bytes
Desc: image001.gif
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140726/bcdf3a6a/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VS2013WDK81Changes.zip
Type: application/x-zip-compressed
Size: 60549 bytes
Desc: VS2013WDK81Changes.zip
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140726/bcdf3a6a/attachment.bin>

From Sagi.Bar at sandisk.com  Sun Jul 27 03:44:53 2014
From: Sagi.Bar at sandisk.com (Sagi Bar)
Date: Sun, 27 Jul 2014 10:44:53 +0000
Subject: [nvmewin] Implementing a debug purpose
	Read/Write	using	IOCTL_SCSI_MINIPORT
In-Reply-To: <010801cfa766$8125bab0$83713010$@bustrace.com>
References: <E5B55DF4CB9A114395C0A6E7895C3B67232A7683@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A398E74C3@BBYEXM02.pmc-sierra.internal>
	<E5B55DF4CB9A114395C0A6E7895C3B67232A7CB4@SACMBXIP01.sdcorp.global.sandisk.com>
	<010801cfa766$8125bab0$83713010$@bustrace.com>
Message-ID: <E5B55DF4CB9A114395C0A6E7895C3B67232A7F87@SACMBXIP01.sdcorp.global.sandisk.com>

Hello Mike,

Thank you for the pointer.

I am currently designing a driver for device production/integration phase.

So my goal is to bypass all OS designed functionality and actually run the command "as is".

In any case, I see that the community driver is very well designed modularity wise.

Namely, the driver already has all routines I need in order to issue Read/Write using PASSTHROUGH - I just need to "glue" them.

Once I am done, if this will be of interest to the community, I will gladly  share my debugging version of the driver.

Sagi Bar
Test & Tools Staff FW Engineer
[cid:image001.png at 01CEA3CD.FE1957E0]

sagi.bar at SanDisk.com<mailto:sagi.bar at SanDisk.com>

From: Mike Berhan [mailto:mikeb at bustrace.com]
Sent: Thursday, July 24, 2014 8:42 PM
To: Sagi Bar; nvmewin at lists.openfabrics.org
Cc: Roman Goldshtein
Subject: RE: [nvmewin] Implementing a debug purpose Read/Write using IOCTL_SCSI_MINIPORT

Sagi,

The disk class driver is the one that divides reads and writes into smaller requests.  It determines how to divide the request by querying the STORAGE_ADAPTER_DESCRIPTOR.  STORPORT gets the information for this structure from the miniport's PORT_CONFIGURATION_INFORMATION structure (MaximumTransferLength and NumberOfPhysicalBreaks).

In reviewing the NVMe source code, it sets these values to max 128K with a registry override available.  The INF file sets the override but it too defaults to 128K:

HKR, Parameters\Device, MaxTXSize, %REG_DWORD%, 0x00020000 ; max trasnfer size

Mike Berhan
busTRACE Technologies
1-208-629-4773 (Office)

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sagi Bar
Sent: Thursday, July 24, 2014 4:23 AM
To: Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Cc: Roman Goldshtein
Subject: Re: [nvmewin] Implementing a debug purpose Read/Write using IOCTL_SCSI_MINIPORT

Hello Alex,

Thank you for your answer.
I see that the driver has a readily implemented NVMePreparePRPs(...) so adding an extra command shouldn't be an issue.

I might need this feature in order to prevent the StorPort driver from dividing the request into smaller SRBs (debug purposes).

Thank you,


Sagi Bar
Test & Tools Staff FW Engineer
[cid:image001.png at 01CEA3CD.FE1957E0]
7 Atir Yeda St, Kfar - Saba 44425, Israel
sagi.bar at SanDisk.com<mailto:sagi.bar at SanDisk.com>

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Wednesday, July 23, 2014 2:35 AM
To: Sagi Bar; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Cc: Roman Goldshtein
Subject: RE: [nvmewin] Implementing a debug purpose Read/Write using IOCTL_SCSI_MINIPORT

Hi Sagi,

Yes, you're right that it's due to security reasons and, in addition, you may access the associated storage as a physical or formatted drive with Windows supported APIs for your debugging purposes, like IOMeter does.

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 Sagi Bar
Sent: Tuesday, July 22, 2014 5:21 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Cc: Roman Goldshtein
Subject: [nvmewin] Implementing a debug purpose Read/Write using IOCTL_SCSI_MINIPORT


Hello Guys,

I would like to implement a debug purpose flow of performing NVME disk IO bypassing the StorPort under Windows 8.1.

I thought about implementing it using "IOCTL_SCSI_MINIPORT" on host side and adding code under "NVM_WRITE/ NVM_READ" on the target side.

I wonder whether anyone here has done it before and can share insights.

Moreover, Is there any particular reason why NVME READ/WRITE commands are not implanted via IOCTL interface, except security ?

Thank you,

Sagi Bar
Test & Tools Staff FW Engineer
[cid:image001.png at 01CEA3CD.FE1957E0]
7 Atir Yeda St, Kfar - Saba 44425, Israel
sagi.bar at SanDisk.com<mailto:sagi.bar at SanDisk.com>


________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140727/a2d1cc91/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2139 bytes
Desc: image001.png
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140727/a2d1cc91/attachment.png>