From beanhay at gmail.com Mon Jun 9 05:56:40 2014 From: beanhay at gmail.com (Sean Chen) Date: Mon, 9 Jun 2014 20:56:40 +0800 Subject: [nvmewin] DeviceIOControl Error Message-ID: Hi All I study PT_IOCTL.doc to implement NVMe command for windows. But DeviceIControl return "The request could not be performed because of an I/O device error." The following is my code: // ================ Get Device ================ char driveName[256]; Select_choice = ComboBox->GetCurSel(); sprintf(driveName, "\\\\.\\scsi%d:", Select_choice); DeviceHandle = CreateFile(driveName, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); if (DeviceHandle == INVALID_HANDLE_VALUE) { MessageBox("Cannot open device.", "Device Error", MB_OK|MB_ICONERROR); return FALSE; } // ================ NVME Test ================ int ByteSizeTX = 256; BOOL status = 0; DWORD count = 0; DWORD InputBufLen = 0; DWORD OutputBufLen = 0; PNVME_PASS_THROUGH_IOCTL pInBuffer = NULL; PNVME_PASS_THROUGH_IOCTL pOutBuffer = NULL; // From Device to Host // 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) + ByteSizeTX; pOutBuffer = (PNVME_PASS_THROUGH_IOCTL) malloc(OutputBufLen); // Confirm we have buffers allocated successfully if (pInBuffer == NULL || pOutBuffer == NULL) return; // Zero out the buffers memset(pInBuffer, 0, InputBufLen); memset(pOutBuffer, 0, OutputBufLen); // Populate SRB_IO_CONTROL fields in input buffer pInBuffer->SrbIoCtrl.ControlCode = 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 = 40; pInBuffer->SrbIoCtrl.Length = InputBufLen - sizeof(SRB_IO_CONTROL); pInBuffer->DataBufferLen = ByteSizeTX; pInBuffer->ReturnBufferLen = OutputBufLen; //pInBuffer->Direction = NVME_FROM_DEV_TO_HOST; // Fill in pInBuffer->NVMeCmd here pInBuffer->NVMeCmd[0] = 0x0A; // OpCode pInBuffer->NVMeCmd[1] = 0x01; // Namespace ID pInBuffer->NVMeCmd[10] = 0x01; // Fill pInBuffer->DataBuffer here when transferring data to device status = DeviceIoControl( DeviceHandle, // 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 free(pInBuffer); free(pOutBuffer); // ==================================================== May I have anything wrong? Thanks for your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at pmcs.com Mon Jun 9 09:09:44 2014 From: Alex.Chang at pmcs.com (Alex Chang) Date: Mon, 9 Jun 2014 16:09:44 +0000 Subject: [nvmewin] DeviceIOControl Error In-Reply-To: References: Message-ID: Hi Sean, You’re send Get Features Command for Arbitration, which doesn’t involve data transfer via separate buffer and ByteSizeTx should be zero. In other words, the sizes of input and output buffer should be the same as size of NVME_PASS_THROUGH_IOCTL. Thanks, Alex From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sean Chen Sent: Monday, June 09, 2014 5:57 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] DeviceIOControl Error Hi All I study PT_IOCTL.doc to implement NVMe command for windows. But DeviceIControl return "The request could not be performed because of an I/O device error." The following is my code: // ================ Get Device ================ char driveName[256]; Select_choice = ComboBox->GetCurSel(); sprintf(driveName, "\\\\.\\scsi%d:", Select_choice); DeviceHandle = CreateFile(driveName, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); if (DeviceHandle == INVALID_HANDLE_VALUE) { MessageBox("Cannot open device.", "Device Error", MB_OK|MB_ICONERROR); return FALSE; } // ================ NVME Test ================ int ByteSizeTX = 256; BOOL status = 0; DWORD count = 0; DWORD InputBufLen = 0; DWORD OutputBufLen = 0; PNVME_PASS_THROUGH_IOCTL pInBuffer = NULL; PNVME_PASS_THROUGH_IOCTL pOutBuffer = NULL; // From Device to Host // 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) + ByteSizeTX; pOutBuffer = (PNVME_PASS_THROUGH_IOCTL) malloc(OutputBufLen); // Confirm we have buffers allocated successfully if (pInBuffer == NULL || pOutBuffer == NULL) return; // Zero out the buffers memset(pInBuffer, 0, InputBufLen); memset(pOutBuffer, 0, OutputBufLen); // Populate SRB_IO_CONTROL fields in input buffer pInBuffer->SrbIoCtrl.ControlCode = 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 = 40; pInBuffer->SrbIoCtrl.Length = InputBufLen - sizeof(SRB_IO_CONTROL); pInBuffer->DataBufferLen = ByteSizeTX; pInBuffer->ReturnBufferLen = OutputBufLen; //pInBuffer->Direction = NVME_FROM_DEV_TO_HOST; // Fill in pInBuffer->NVMeCmd here pInBuffer->NVMeCmd[0] = 0x0A; // OpCode pInBuffer->NVMeCmd[1] = 0x01; // Namespace ID pInBuffer->NVMeCmd[10] = 0x01; // Fill pInBuffer->DataBuffer here when transferring data to device status = DeviceIoControl( DeviceHandle, // 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 free(pInBuffer); free(pOutBuffer); // ==================================================== May I have anything wrong? Thanks for your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikeb at bustrace.com Wed Jun 25 14:00:08 2014 From: mikeb at bustrace.com (Mike Berhan) Date: Wed, 25 Jun 2014 15:00:08 -0600 Subject: [nvmewin] Potential BSOD if DataTransferLength < Allocation Length Message-ID: <011401cf90b8$72dbbfa0$58933ee0$@bustrace.com> I recently joined this reflector. Advanced apologies if this has already been covered. I've been perusing the latest NVMe OFA source code. The NVMe Win source indicates a potential BSOD on a poorly formatted SPTI/SRB/CDB. For the sake of discussion, I'll limit this to the Report LUNs CDB but it's applicable to a variety of other CDBs the driver handles. Here is a sample SRB/CDB to consider: _SCSI_REQUEST_BLOCK ULONG DataTransferLength 00000100h PVOID DataBuffer 0000006C`801D0A50h UCHAR Cdb[16] A0 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 The key items to consider are the DataTransferLength at 100h and the CDB Allocation Length at 1000h. This is likely a bug in the calling software as the DataTransferLength should be greater than or equal to the CDB allocation length. In this example, this probably doesn't cause a problem as the return data is likely less than 100h bytes anyway so the caller would never see any failure. However, when executed on the NVMe driver, several problems can occur. In reviewing the source code, the Report LUNs CDB gets routed to the SntiTranslateReportLuns() function. The code retrieves information about the command as you see here: pResponseBuffer = (PUCHAR)GET_DATA_BUFFER(pSrb); allocLength = GET_REPORT_LUNS_ALLOC_LENGTH(pSrb); selectReport = GET_U8_FROM_CDB(pSrb, REPORT_LUNS_SELECT_REPORT_OFFSET); >From our example above, the following values are extracted from the SRB/CDB: pResponseBuffer = 0000006C`801D0A50h allocLength = 1000h selectReport = 00h (i.e. RESTRICTED_LUNS_RETURNED) The following code then gets executed: if ((selectReport != ALL_LUNS_RETURNED) && (selectReport != ALL_WELL_KNOWN_LUNS_RETURNED) && (selectReport != RESTRICTED_LUNS_RETURNED)) { } else { memset(pResponseBuffer, 0, allocLength); <<<--- BSOD!?!?!? } Several potential problems are seen in walking through the source code. Problem #1 - Driver overrunning data buffer The miniport driver received a 100h byte buffer. However, because the CDB allocation length was set to 1000h, the miniport driver is going to overflow the buffer and zero out 1000h bytes of data. At best you're looking at a BSOD. At worst memory is corrupted. It's also not checking for a NULL SRB Data buffer pointer or the SRB data direction flags. Problem #2 - Miniport writing to buffer when it shouldn't A storage device should only alter the data buffer that has actual data. For example, if I send down a request with a 256 byte buffer, but the device only returns 16 bytes, the remainder of the buffer (i.e. the tail 240 bytes) should not be altered. The DataTransferLength field in the SRB would be returned as 16 indicating that only 16 bytes were transferred. In the sample cited above, the miniport driver is attempting to zero out the entire data buffer passed in when it should only zero out the portion of the data buffer that it will actually return data in (max DataTransferLength). Not that this is a particularly critical issue but it is worth noting and would make the driver more robust. Mike From Alex.Chang at pmcs.com Wed Jun 25 15:23:43 2014 From: Alex.Chang at pmcs.com (Alex Chang) Date: Wed, 25 Jun 2014 22:23:43 +0000 Subject: [nvmewin] Potential BSOD if DataTransferLength < Allocation Length In-Reply-To: <011401cf90b8$72dbbfa0$58933ee0$@bustrace.com> References: <011401cf90b8$72dbbfa0$58933ee0$@bustrace.com> Message-ID: Hi Mike, You did bring up couple of good points. From my experience, the DataTransferLength is always equal or greater than the allocLength of CDB and I am sure it's up to upper layer software when they package the SRB. In order to avoid the potential BSOD, I'd agree to do sanity check on them. As for the 2nd one, with the sanity check in place, it should be fine to zero out the allocated buffer in the length specified by SRB. Please let me know what you think. Thanks, Alex -----Original Message----- From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Mike Berhan Sent: Wednesday, June 25, 2014 2:00 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Potential BSOD if DataTransferLength < Allocation Length I recently joined this reflector. Advanced apologies if this has already been covered. I've been perusing the latest NVMe OFA source code. The NVMe Win source indicates a potential BSOD on a poorly formatted SPTI/SRB/CDB. For the sake of discussion, I'll limit this to the Report LUNs CDB but it's applicable to a variety of other CDBs the driver handles. Here is a sample SRB/CDB to consider: _SCSI_REQUEST_BLOCK ULONG DataTransferLength 00000100h PVOID DataBuffer 0000006C`801D0A50h UCHAR Cdb[16] A0 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 The key items to consider are the DataTransferLength at 100h and the CDB Allocation Length at 1000h. This is likely a bug in the calling software as the DataTransferLength should be greater than or equal to the CDB allocation length. In this example, this probably doesn't cause a problem as the return data is likely less than 100h bytes anyway so the caller would never see any failure. However, when executed on the NVMe driver, several problems can occur. In reviewing the source code, the Report LUNs CDB gets routed to the SntiTranslateReportLuns() function. The code retrieves information about the command as you see here: pResponseBuffer = (PUCHAR)GET_DATA_BUFFER(pSrb); allocLength = GET_REPORT_LUNS_ALLOC_LENGTH(pSrb); selectReport = GET_U8_FROM_CDB(pSrb, REPORT_LUNS_SELECT_REPORT_OFFSET); >From our example above, the following values are extracted from the SRB/CDB: pResponseBuffer = 0000006C`801D0A50h allocLength = 1000h selectReport = 00h (i.e. RESTRICTED_LUNS_RETURNED) The following code then gets executed: if ((selectReport != ALL_LUNS_RETURNED) && (selectReport != ALL_WELL_KNOWN_LUNS_RETURNED) && (selectReport != RESTRICTED_LUNS_RETURNED)) { } else { memset(pResponseBuffer, 0, allocLength); <<<--- BSOD!?!?!? } Several potential problems are seen in walking through the source code. Problem #1 - Driver overrunning data buffer The miniport driver received a 100h byte buffer. However, because the CDB allocation length was set to 1000h, the miniport driver is going to overflow the buffer and zero out 1000h bytes of data. At best you're looking at a BSOD. At worst memory is corrupted. It's also not checking for a NULL SRB Data buffer pointer or the SRB data direction flags. Problem #2 - Miniport writing to buffer when it shouldn't A storage device should only alter the data buffer that has actual data. For example, if I send down a request with a 256 byte buffer, but the device only returns 16 bytes, the remainder of the buffer (i.e. the tail 240 bytes) should not be altered. The DataTransferLength field in the SRB would be returned as 16 indicating that only 16 bytes were transferred. In the sample cited above, the miniport driver is attempting to zero out the entire data buffer passed in when it should only zero out the portion of the data buffer that it will actually return data in (max DataTransferLength). Not that this is a particularly critical issue but it is worth noting and would make the driver more robust. Mike _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin From mikeb at bustrace.com Wed Jun 25 15:59:09 2014 From: mikeb at bustrace.com (Mike Berhan) Date: Wed, 25 Jun 2014 16:59:09 -0600 Subject: [nvmewin] Potential BSOD if DataTransferLength < Allocation Length In-Reply-To: References: <011401cf90b8$72dbbfa0$58933ee0$@bustrace.com> Message-ID: <003c01cf90c9$132c2480$39846d80$@bustrace.com> Alex, I do a lot of boundary testing which is why I come up with these esoteric bugs. Regarding the issues cited, I use this type of code to determine the maximum amount of data to transfer. ULONG nMaxTransferLen = (pDataBuffer ? min(nDataTransferLength,nCdbAllocationLength) : 0); That covers a NULL pointer as well as the DataTransferLength < CDB Allocation length issue. I then determine the amount of data I would like to ideally transfer in an nDesiredTransferLen variable. For example, let's say 16 bytes is the actual length of the Report LUNs structure to return. I then determine the actual amount of data I'm going to transfer by performing this comparison: ULONG nTransferLength = min(nDesiredTransferLen, nMaxTransferLen); Now I know the exact number of bytes I'm going to transfer. I'll only work within that memory space and that is the value returned in DataTransferLength. The last thing to do is accurately report SRB_STATUS_SUCCESS or SRB_STATUS_DATA_OVERRUN depending on the inbound and outbound data lengths. Mike -----Original Message----- From: Alex Chang [mailto:Alex.Chang at pmcs.com] Sent: Wednesday, June 25, 2014 4:24 PM To: Mike Berhan; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Potential BSOD if DataTransferLength < Allocation Length Hi Mike, You did bring up couple of good points. From my experience, the DataTransferLength is always equal or greater than the allocLength of CDB and I am sure it's up to upper layer software when they package the SRB. In order to avoid the potential BSOD, I'd agree to do sanity check on them. As for the 2nd one, with the sanity check in place, it should be fine to zero out the allocated buffer in the length specified by SRB. Please let me know what you think. Thanks, Alex -----Original Message----- From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Mike Berhan Sent: Wednesday, June 25, 2014 2:00 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Potential BSOD if DataTransferLength < Allocation Length I recently joined this reflector. Advanced apologies if this has already been covered. I've been perusing the latest NVMe OFA source code. The NVMe Win source indicates a potential BSOD on a poorly formatted SPTI/SRB/CDB. For the sake of discussion, I'll limit this to the Report LUNs CDB but it's applicable to a variety of other CDBs the driver handles. Here is a sample SRB/CDB to consider: _SCSI_REQUEST_BLOCK ULONG DataTransferLength 00000100h PVOID DataBuffer 0000006C`801D0A50h UCHAR Cdb[16] A0 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 The key items to consider are the DataTransferLength at 100h and the CDB Allocation Length at 1000h. This is likely a bug in the calling software as the DataTransferLength should be greater than or equal to the CDB allocation length. In this example, this probably doesn't cause a problem as the return data is likely less than 100h bytes anyway so the caller would never see any failure. However, when executed on the NVMe driver, several problems can occur. In reviewing the source code, the Report LUNs CDB gets routed to the SntiTranslateReportLuns() function. The code retrieves information about the command as you see here: pResponseBuffer = (PUCHAR)GET_DATA_BUFFER(pSrb); allocLength = GET_REPORT_LUNS_ALLOC_LENGTH(pSrb); selectReport = GET_U8_FROM_CDB(pSrb, REPORT_LUNS_SELECT_REPORT_OFFSET); >From our example above, the following values are extracted from the SRB/CDB: pResponseBuffer = 0000006C`801D0A50h allocLength = 1000h selectReport = 00h (i.e. RESTRICTED_LUNS_RETURNED) The following code then gets executed: if ((selectReport != ALL_LUNS_RETURNED) && (selectReport != ALL_WELL_KNOWN_LUNS_RETURNED) && (selectReport != RESTRICTED_LUNS_RETURNED)) { } else { memset(pResponseBuffer, 0, allocLength); <<<--- BSOD!?!?!? } Several potential problems are seen in walking through the source code. Problem #1 - Driver overrunning data buffer The miniport driver received a 100h byte buffer. However, because the CDB allocation length was set to 1000h, the miniport driver is going to overflow the buffer and zero out 1000h bytes of data. At best you're looking at a BSOD. At worst memory is corrupted. It's also not checking for a NULL SRB Data buffer pointer or the SRB data direction flags. Problem #2 - Miniport writing to buffer when it shouldn't A storage device should only alter the data buffer that has actual data. For example, if I send down a request with a 256 byte buffer, but the device only returns 16 bytes, the remainder of the buffer (i.e. the tail 240 bytes) should not be altered. The DataTransferLength field in the SRB would be returned as 16 indicating that only 16 bytes were transferred. In the sample cited above, the miniport driver is attempting to zero out the entire data buffer passed in when it should only zero out the portion of the data buffer that it will actually return data in (max DataTransferLength). Not that this is a particularly critical issue but it is worth noting and would make the driver more robust. Mike _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin From Alex.Chang at pmcs.com Wed Jun 25 16:23:32 2014 From: Alex.Chang at pmcs.com (Alex Chang) Date: Wed, 25 Jun 2014 23:23:32 +0000 Subject: [nvmewin] Potential BSOD if DataTransferLength < Allocation Length In-Reply-To: <003c01cf90c9$132c2480$39846d80$@bustrace.com> References: <011401cf90b8$72dbbfa0$58933ee0$@bustrace.com> <003c01cf90c9$132c2480$39846d80$@bustrace.com> Message-ID: Hi Mike, I can't agree more on the boundary checking you mentioned, including the case of data over-run/under-run reporting in the end. We will include this as part of next release. Thanks, Alex -----Original Message----- From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Mike Berhan Sent: Wednesday, June 25, 2014 3:59 PM To: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Potential BSOD if DataTransferLength < Allocation Length Alex, I do a lot of boundary testing which is why I come up with these esoteric bugs. Regarding the issues cited, I use this type of code to determine the maximum amount of data to transfer. ULONG nMaxTransferLen = (pDataBuffer ? min(nDataTransferLength,nCdbAllocationLength) : 0); That covers a NULL pointer as well as the DataTransferLength < CDB Allocation length issue. I then determine the amount of data I would like to ideally transfer in an nDesiredTransferLen variable. For example, let's say 16 bytes is the actual length of the Report LUNs structure to return. I then determine the actual amount of data I'm going to transfer by performing this comparison: ULONG nTransferLength = min(nDesiredTransferLen, nMaxTransferLen); Now I know the exact number of bytes I'm going to transfer. I'll only work within that memory space and that is the value returned in DataTransferLength. The last thing to do is accurately report SRB_STATUS_SUCCESS or SRB_STATUS_DATA_OVERRUN depending on the inbound and outbound data lengths. Mike -----Original Message----- From: Alex Chang [mailto:Alex.Chang at pmcs.com] Sent: Wednesday, June 25, 2014 4:24 PM To: Mike Berhan; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Potential BSOD if DataTransferLength < Allocation Length Hi Mike, You did bring up couple of good points. From my experience, the DataTransferLength is always equal or greater than the allocLength of CDB and I am sure it's up to upper layer software when they package the SRB. In order to avoid the potential BSOD, I'd agree to do sanity check on them. As for the 2nd one, with the sanity check in place, it should be fine to zero out the allocated buffer in the length specified by SRB. Please let me know what you think. Thanks, Alex -----Original Message----- From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Mike Berhan Sent: Wednesday, June 25, 2014 2:00 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Potential BSOD if DataTransferLength < Allocation Length I recently joined this reflector. Advanced apologies if this has already been covered. I've been perusing the latest NVMe OFA source code. The NVMe Win source indicates a potential BSOD on a poorly formatted SPTI/SRB/CDB. For the sake of discussion, I'll limit this to the Report LUNs CDB but it's applicable to a variety of other CDBs the driver handles. Here is a sample SRB/CDB to consider: _SCSI_REQUEST_BLOCK ULONG DataTransferLength 00000100h PVOID DataBuffer 0000006C`801D0A50h UCHAR Cdb[16] A0 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 The key items to consider are the DataTransferLength at 100h and the CDB Allocation Length at 1000h. This is likely a bug in the calling software as the DataTransferLength should be greater than or equal to the CDB allocation length. In this example, this probably doesn't cause a problem as the return data is likely less than 100h bytes anyway so the caller would never see any failure. However, when executed on the NVMe driver, several problems can occur. In reviewing the source code, the Report LUNs CDB gets routed to the SntiTranslateReportLuns() function. The code retrieves information about the command as you see here: pResponseBuffer = (PUCHAR)GET_DATA_BUFFER(pSrb); allocLength = GET_REPORT_LUNS_ALLOC_LENGTH(pSrb); selectReport = GET_U8_FROM_CDB(pSrb, REPORT_LUNS_SELECT_REPORT_OFFSET); >From our example above, the following values are extracted from the SRB/CDB: pResponseBuffer = 0000006C`801D0A50h allocLength = 1000h selectReport = 00h (i.e. RESTRICTED_LUNS_RETURNED) The following code then gets executed: if ((selectReport != ALL_LUNS_RETURNED) && (selectReport != ALL_WELL_KNOWN_LUNS_RETURNED) && (selectReport != RESTRICTED_LUNS_RETURNED)) { } else { memset(pResponseBuffer, 0, allocLength); <<<--- BSOD!?!?!? } Several potential problems are seen in walking through the source code. Problem #1 - Driver overrunning data buffer The miniport driver received a 100h byte buffer. However, because the CDB allocation length was set to 1000h, the miniport driver is going to overflow the buffer and zero out 1000h bytes of data. At best you're looking at a BSOD. At worst memory is corrupted. It's also not checking for a NULL SRB Data buffer pointer or the SRB data direction flags. Problem #2 - Miniport writing to buffer when it shouldn't A storage device should only alter the data buffer that has actual data. For example, if I send down a request with a 256 byte buffer, but the device only returns 16 bytes, the remainder of the buffer (i.e. the tail 240 bytes) should not be altered. The DataTransferLength field in the SRB would be returned as 16 indicating that only 16 bytes were transferred. In the sample cited above, the miniport driver is attempting to zero out the entire data buffer passed in when it should only zero out the portion of the data buffer that it will actually return data in (max DataTransferLength). Not that this is a particularly critical issue but it is worth noting and would make the driver more robust. Mike _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin From parag.sheth at avagotech.com Wed Jun 25 17:12:26 2014 From: parag.sheth at avagotech.com (Parag Sheth) Date: Wed, 25 Jun 2014 17:12:26 -0700 Subject: [nvmewin] Potential bug in OFA driver 1.3 Message-ID: Hi All, With the latest 1.3 driver, STORAGE_REQUEST_BLOCK support has been added for windows 8 and up. Is this the only configuration allowed with Windows 8 or SCSI_REQUEST_BLOCK + windows 8 combination is allowed as well? If allowed, than there are couple of bugs in the way srbhelper (from wdk) is being used. Specifically SrbSetScsiData() and SrbGetScsiData() from srbhelper do not handle SCSI_REQUEST_BLOCK properly and will cause command failure. Thanks Parag Sheth -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at pmcs.com Wed Jun 25 17:17:39 2014 From: Alex.Chang at pmcs.com (Alex Chang) Date: Thu, 26 Jun 2014 00:17:39 +0000 Subject: [nvmewin] Potential bug in OFA driver 1.3 In-Reply-To: References: Message-ID: Hi Parag, When you compile the driver for Windows 8 and up, STORAGE_REQUEST_BLOCK will be used rather than SCSI_REQUEST_BLOCK. I wonder how you can have SCSI_REQUEST_BLOCK + Windows 8 combination? And srbhelper is only compiled in for Windows 8. Thanks, Alex From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Parag Sheth Sent: Wednesday, June 25, 2014 5:12 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Potential bug in OFA driver 1.3 Hi All, With the latest 1.3 driver, STORAGE_REQUEST_BLOCK support has been added for windows 8 and up. Is this the only configuration allowed with Windows 8 or SCSI_REQUEST_BLOCK + windows 8 combination is allowed as well? If allowed, than there are couple of bugs in the way srbhelper (from wdk) is being used. Specifically SrbSetScsiData() and SrbGetScsiData() from srbhelper do not handle SCSI_REQUEST_BLOCK properly and will cause command failure. Thanks Parag Sheth -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag.sheth at avagotech.com Wed Jun 25 17:22:53 2014 From: parag.sheth at avagotech.com (Parag Sheth) Date: Wed, 25 Jun 2014 17:22:53 -0700 Subject: [nvmewin] Potential bug in OFA driver 1.3 In-Reply-To: References: Message-ID: <39384368489db02f6ea8f25904b730ea@mail.gmail.com> Hi Alex, To the best of my understanding, STORAGE_REQUEST_BLOCK will not be enabled just by building a windows 8 version of driver. We need to add hwInitData.SrbTypeFlags = SRB_TYPE_FLAG_STORAGE_REQUEST_BLOCK; line to our DriverEntry routine. If we omit this line (in the current 1.3 version of driver this line is omitted), driver will use SCSI_REQUEST_BLOCK. Thanks Parag Sheth *From:* Alex Chang [mailto:Alex.Chang at pmcs.com] *Sent:* Wednesday, June 25, 2014 5:18 PM *To:* Parag Sheth; nvmewin at lists.openfabrics.org *Subject:* RE: [nvmewin] Potential bug in OFA driver 1.3 Hi Parag, When you compile the driver for Windows 8 and up, STORAGE_REQUEST_BLOCK will be used rather than SCSI_REQUEST_BLOCK. I wonder how you can have SCSI_REQUEST_BLOCK + Windows 8 combination? And srbhelper is only compiled in for Windows 8. Thanks, Alex *From:* nvmewin-bounces at lists.openfabrics.org [ mailto:nvmewin-bounces at lists.openfabrics.org ] *On Behalf Of *Parag Sheth *Sent:* Wednesday, June 25, 2014 5:12 PM *To:* nvmewin at lists.openfabrics.org *Subject:* [nvmewin] Potential bug in OFA driver 1.3 Hi All, With the latest 1.3 driver, STORAGE_REQUEST_BLOCK support has been added for windows 8 and up. Is this the only configuration allowed with Windows 8 or SCSI_REQUEST_BLOCK + windows 8 combination is allowed as well? If allowed, than there are couple of bugs in the way srbhelper (from wdk) is being used. Specifically SrbSetScsiData() and SrbGetScsiData() from srbhelper do not handle SCSI_REQUEST_BLOCK properly and will cause command failure. Thanks Parag Sheth -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag.sheth at avagotech.com Wed Jun 25 17:31:36 2014 From: parag.sheth at avagotech.com (Parag Sheth) Date: Wed, 25 Jun 2014 17:31:36 -0700 Subject: [nvmewin] Potential bug in OFA driver 1.3 In-Reply-To: 39384368489db02f6ea8f25904b730ea@mail.gmail.com References: 39384368489db02f6ea8f25904b730ea@mail.gmail.com Message-ID: <4873c259490c18924125a274bec423da@mail.gmail.com> HI Alex, And just to add on top of it is another related BSOD in IO_StorPortNotification() in nvmestd.c. The StorportDebugPrint statement tries to dereference pCdb structure. And while using STORAGE_REQUEST_BLOCKs, pCdb might be NULL in some cases. This will straight away cause a blue screen while loading the driver (unless it is using SCSI_REQUEST_BLOCK). Thanks Parag Sheth *From:* Parag Sheth [mailto:parag.sheth at avagotech.com] *Sent:* Wednesday, June 25, 2014 5:23 PM *To:* 'nvmewin at lists.openfabrics.org' *Subject:* RE: [nvmewin] Potential bug in OFA driver 1.3 Hi Alex, To the best of my understanding, STORAGE_REQUEST_BLOCK will not be enabled just by building a windows 8 version of driver. We need to add hwInitData.SrbTypeFlags = SRB_TYPE_FLAG_STORAGE_REQUEST_BLOCK; line to our DriverEntry routine. If we omit this line (in the current 1.3 version of driver this line is omitted), driver will use SCSI_REQUEST_BLOCK. Thanks Parag Sheth *From:* Alex Chang [mailto:Alex.Chang at pmcs.com ] *Sent:* Wednesday, June 25, 2014 5:18 PM *To:* Parag Sheth; nvmewin at lists.openfabrics.org *Subject:* RE: [nvmewin] Potential bug in OFA driver 1.3 Hi Parag, When you compile the driver for Windows 8 and up, STORAGE_REQUEST_BLOCK will be used rather than SCSI_REQUEST_BLOCK. I wonder how you can have SCSI_REQUEST_BLOCK + Windows 8 combination? And srbhelper is only compiled in for Windows 8. Thanks, Alex *From:* nvmewin-bounces at lists.openfabrics.org [ mailto:nvmewin-bounces at lists.openfabrics.org ] *On Behalf Of *Parag Sheth *Sent:* Wednesday, June 25, 2014 5:12 PM *To:* nvmewin at lists.openfabrics.org *Subject:* [nvmewin] Potential bug in OFA driver 1.3 Hi All, With the latest 1.3 driver, STORAGE_REQUEST_BLOCK support has been added for windows 8 and up. Is this the only configuration allowed with Windows 8 or SCSI_REQUEST_BLOCK + windows 8 combination is allowed as well? If allowed, than there are couple of bugs in the way srbhelper (from wdk) is being used. Specifically SrbSetScsiData() and SrbGetScsiData() from srbhelper do not handle SCSI_REQUEST_BLOCK properly and will cause command failure. Thanks Parag Sheth -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag.sheth at avagotech.com Wed Jun 25 16:57:53 2014 From: parag.sheth at avagotech.com (Parag Sheth) Date: Wed, 25 Jun 2014 16:57:53 -0700 Subject: [nvmewin] Potential bug in OFA driver 1.3 Message-ID: <8b4a1b7c1a6766de0c6b24e1e7826ee6@mail.gmail.com> Hi All, With the latest 1.3 driver, STORAGE_REQUEST_BLOCK support has been added for windows 8 and up. Is this the only configuration allowed with Windows 8 or SCSI_REQUEST_BLOCK + windows 8 combination is allowed as well? If allowed, than there are couple of bugs in the way srbhelper (from wdk) is being used. Specifically SrbSetScsiData() and SrbGetScsiData() from srbhelper do not handle SCSI_REQUEST_BLOCK properly and will cause command failure. Thanks Parag Sheth -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at pmcs.com Thu Jun 26 09:19:35 2014 From: Alex.Chang at pmcs.com (Alex Chang) Date: Thu, 26 Jun 2014 16:19:35 +0000 Subject: [nvmewin] Potential bug in OFA driver 1.3 In-Reply-To: <8b4a1b7c1a6766de0c6b24e1e7826ee6@mail.gmail.com> References: <8b4a1b7c1a6766de0c6b24e1e7826ee6@mail.gmail.com> Message-ID: Hi Parag, When we added supporting SRB Extension for Windows 8 and up, there is no plan that supports Windows 8 + SCSI_REQUEST_BLOCK. To be more specific, we need to indicate that via SrbTypeFlags of HW_INITIALIZATION_DATA. However, Windows 8 always sends down STORAGE_REQUEST_BLOCK when SrbTypeFlags is set to zero. Is that what you’re seeing on your testing? Thanks, Alex From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Parag Sheth Sent: Wednesday, June 25, 2014 4:58 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Potential bug in OFA driver 1.3 Hi All, With the latest 1.3 driver, STORAGE_REQUEST_BLOCK support has been added for windows 8 and up. Is this the only configuration allowed with Windows 8 or SCSI_REQUEST_BLOCK + windows 8 combination is allowed as well? If allowed, than there are couple of bugs in the way srbhelper (from wdk) is being used. Specifically SrbSetScsiData() and SrbGetScsiData() from srbhelper do not handle SCSI_REQUEST_BLOCK properly and will cause command failure. Thanks Parag Sheth -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag.sheth at avagotech.com Thu Jun 26 11:29:40 2014 From: parag.sheth at avagotech.com (Parag Sheth) Date: Thu, 26 Jun 2014 11:29:40 -0700 Subject: [nvmewin] Potential bug in OFA driver 1.3 In-Reply-To: References: <8b4a1b7c1a6766de0c6b24e1e7826ee6@mail.gmail.com> Message-ID: <1c0e4b81e9217065ca4f556e8dacbbce@mail.gmail.com> Hi Alex, What I have seen during my testing is that windows 8 sends down SCSI_REQUEST_BLOCK if we don’t set any value for SrbTypeFlags. And that is probably the reason nobody got into the blue screen that I mentioned in my previous email. Thanks Parag Sheth *From:* Alex Chang [mailto:Alex.Chang at pmcs.com] *Sent:* Thursday, June 26, 2014 9:20 AM *To:* Parag Sheth; nvmewin at lists.openfabrics.org *Subject:* RE: [nvmewin] Potential bug in OFA driver 1.3 Hi Parag, When we added supporting SRB Extension for Windows 8 and up, there is no plan that supports Windows 8 + SCSI_REQUEST_BLOCK. To be more specific, we need to indicate that via SrbTypeFlags of HW_INITIALIZATION_DATA. However, Windows 8 always sends down STORAGE_REQUEST_BLOCK when SrbTypeFlags is set to zero. Is that what you’re seeing on your testing? Thanks, Alex *From:* nvmewin-bounces at lists.openfabrics.org [ mailto:nvmewin-bounces at lists.openfabrics.org ] *On Behalf Of *Parag Sheth *Sent:* Wednesday, June 25, 2014 4:58 PM *To:* nvmewin at lists.openfabrics.org *Subject:* [nvmewin] Potential bug in OFA driver 1.3 Hi All, With the latest 1.3 driver, STORAGE_REQUEST_BLOCK support has been added for windows 8 and up. Is this the only configuration allowed with Windows 8 or SCSI_REQUEST_BLOCK + windows 8 combination is allowed as well? If allowed, than there are couple of bugs in the way srbhelper (from wdk) is being used. Specifically SrbSetScsiData() and SrbGetScsiData() from srbhelper do not handle SCSI_REQUEST_BLOCK properly and will cause command failure. Thanks Parag Sheth -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at pmcs.com Thu Jun 26 11:45:43 2014 From: Alex.Chang at pmcs.com (Alex Chang) Date: Thu, 26 Jun 2014 18:45:43 +0000 Subject: [nvmewin] Potential bug in OFA driver 1.3 In-Reply-To: <1c0e4b81e9217065ca4f556e8dacbbce@mail.gmail.com> References: <8b4a1b7c1a6766de0c6b24e1e7826ee6@mail.gmail.com> <1c0e4b81e9217065ca4f556e8dacbbce@mail.gmail.com> Message-ID: Thanks, Parag. Let me confirm that first. By the way, could you please let me know how you build the driver for Windows 8? Alex From: Parag Sheth [mailto:parag.sheth at avagotech.com] Sent: Thursday, June 26, 2014 11:30 AM To: Alex Chang; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Potential bug in OFA driver 1.3 Hi Alex, What I have seen during my testing is that windows 8 sends down SCSI_REQUEST_BLOCK if we don’t set any value for SrbTypeFlags. And that is probably the reason nobody got into the blue screen that I mentioned in my previous email. Thanks Parag Sheth From: Alex Chang [mailto:Alex.Chang at pmcs.com] Sent: Thursday, June 26, 2014 9:20 AM To: Parag Sheth; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Potential bug in OFA driver 1.3 Hi Parag, When we added supporting SRB Extension for Windows 8 and up, there is no plan that supports Windows 8 + SCSI_REQUEST_BLOCK. To be more specific, we need to indicate that via SrbTypeFlags of HW_INITIALIZATION_DATA. However, Windows 8 always sends down STORAGE_REQUEST_BLOCK when SrbTypeFlags is set to zero. Is that what you’re seeing on your testing? Thanks, Alex From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Parag Sheth Sent: Wednesday, June 25, 2014 4:58 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Potential bug in OFA driver 1.3 Hi All, With the latest 1.3 driver, STORAGE_REQUEST_BLOCK support has been added for windows 8 and up. Is this the only configuration allowed with Windows 8 or SCSI_REQUEST_BLOCK + windows 8 combination is allowed as well? If allowed, than there are couple of bugs in the way srbhelper (from wdk) is being used. Specifically SrbSetScsiData() and SrbGetScsiData() from srbhelper do not handle SCSI_REQUEST_BLOCK properly and will cause command failure. Thanks Parag Sheth -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag.sheth at avagotech.com Thu Jun 26 11:51:12 2014 From: parag.sheth at avagotech.com (Parag Sheth) Date: Thu, 26 Jun 2014 11:51:12 -0700 Subject: [nvmewin] Potential bug in OFA driver 1.3 In-Reply-To: References: <8b4a1b7c1a6766de0c6b24e1e7826ee6@mail.gmail.com> <1c0e4b81e9217065ca4f556e8dacbbce@mail.gmail.com> Message-ID: <9ccb99560c7374cdcac88c8e0c915b5a@mail.gmail.com> Hi Alex, I use VS 2012 for the build. Thanks Parag Sheth *From:* Alex Chang [mailto:Alex.Chang at pmcs.com] *Sent:* Thursday, June 26, 2014 11:46 AM *To:* Parag Sheth; nvmewin at lists.openfabrics.org *Subject:* RE: [nvmewin] Potential bug in OFA driver 1.3 Thanks, Parag. Let me confirm that first. By the way, could you please let me know how you build the driver for Windows 8? Alex *From:* Parag Sheth [mailto:parag.sheth at avagotech.com ] *Sent:* Thursday, June 26, 2014 11:30 AM *To:* Alex Chang; nvmewin at lists.openfabrics.org *Subject:* RE: [nvmewin] Potential bug in OFA driver 1.3 Hi Alex, What I have seen during my testing is that windows 8 sends down SCSI_REQUEST_BLOCK if we don’t set any value for SrbTypeFlags. And that is probably the reason nobody got into the blue screen that I mentioned in my previous email. Thanks Parag Sheth *From:* Alex Chang [mailto:Alex.Chang at pmcs.com] *Sent:* Thursday, June 26, 2014 9:20 AM *To:* Parag Sheth; nvmewin at lists.openfabrics.org *Subject:* RE: [nvmewin] Potential bug in OFA driver 1.3 Hi Parag, When we added supporting SRB Extension for Windows 8 and up, there is no plan that supports Windows 8 + SCSI_REQUEST_BLOCK. To be more specific, we need to indicate that via SrbTypeFlags of HW_INITIALIZATION_DATA. However, Windows 8 always sends down STORAGE_REQUEST_BLOCK when SrbTypeFlags is set to zero. Is that what you’re seeing on your testing? Thanks, Alex *From:* nvmewin-bounces at lists.openfabrics.org [ mailto:nvmewin-bounces at lists.openfabrics.org ] *On Behalf Of *Parag Sheth *Sent:* Wednesday, June 25, 2014 4:58 PM *To:* nvmewin at lists.openfabrics.org *Subject:* [nvmewin] Potential bug in OFA driver 1.3 Hi All, With the latest 1.3 driver, STORAGE_REQUEST_BLOCK support has been added for windows 8 and up. Is this the only configuration allowed with Windows 8 or SCSI_REQUEST_BLOCK + windows 8 combination is allowed as well? If allowed, than there are couple of bugs in the way srbhelper (from wdk) is being used. Specifically SrbSetScsiData() and SrbGetScsiData() from srbhelper do not handle SCSI_REQUEST_BLOCK properly and will cause command failure. Thanks Parag Sheth -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at pmcs.com Fri Jun 27 12:10:10 2014 From: Alex.Chang at pmcs.com (Alex Chang) Date: Fri, 27 Jun 2014 19:10:10 +0000 Subject: [nvmewin] Potential bug in OFA driver 1.3 In-Reply-To: <9ccb99560c7374cdcac88c8e0c915b5a@mail.gmail.com> References: <8b4a1b7c1a6766de0c6b24e1e7826ee6@mail.gmail.com> <1c0e4b81e9217065ca4f556e8dacbbce@mail.gmail.com> <9ccb99560c7374cdcac88c8e0c915b5a@mail.gmail.com> Message-ID: Hi Parag, I’ve confirmed that the setting for SrbTypeFlags is required in order to receive STORAGE_REQUEST_BLOCK. In addition, I did see that SrbGetCdb macro provided by srbhelper returns NULL pointer and fixed it already. If SrbTypeFlags is used and set to receive STORAGE_REQUEST_BLOCK only for Windows 8 and up, SrbGetScsiData and SrbSetScsiData will only be called to handle STORAGE_REQUEST_BLOCK in our implementation. Will that solve your problem? Thanks, Alex From: Parag Sheth [mailto:parag.sheth at avagotech.com] Sent: Thursday, June 26, 2014 11:51 AM To: Alex Chang; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Potential bug in OFA driver 1.3 Hi Alex, I use VS 2012 for the build. Thanks Parag Sheth From: Alex Chang [mailto:Alex.Chang at pmcs.com] Sent: Thursday, June 26, 2014 11:46 AM To: Parag Sheth; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Potential bug in OFA driver 1.3 Thanks, Parag. Let me confirm that first. By the way, could you please let me know how you build the driver for Windows 8? Alex From: Parag Sheth [mailto:parag.sheth at avagotech.com] Sent: Thursday, June 26, 2014 11:30 AM To: Alex Chang; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Potential bug in OFA driver 1.3 Hi Alex, What I have seen during my testing is that windows 8 sends down SCSI_REQUEST_BLOCK if we don’t set any value for SrbTypeFlags. And that is probably the reason nobody got into the blue screen that I mentioned in my previous email. Thanks Parag Sheth From: Alex Chang [mailto:Alex.Chang at pmcs.com] Sent: Thursday, June 26, 2014 9:20 AM To: Parag Sheth; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Potential bug in OFA driver 1.3 Hi Parag, When we added supporting SRB Extension for Windows 8 and up, there is no plan that supports Windows 8 + SCSI_REQUEST_BLOCK. To be more specific, we need to indicate that via SrbTypeFlags of HW_INITIALIZATION_DATA. However, Windows 8 always sends down STORAGE_REQUEST_BLOCK when SrbTypeFlags is set to zero. Is that what you’re seeing on your testing? Thanks, Alex From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Parag Sheth Sent: Wednesday, June 25, 2014 4:58 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Potential bug in OFA driver 1.3 Hi All, With the latest 1.3 driver, STORAGE_REQUEST_BLOCK support has been added for windows 8 and up. Is this the only configuration allowed with Windows 8 or SCSI_REQUEST_BLOCK + windows 8 combination is allowed as well? If allowed, than there are couple of bugs in the way srbhelper (from wdk) is being used. Specifically SrbSetScsiData() and SrbGetScsiData() from srbhelper do not handle SCSI_REQUEST_BLOCK properly and will cause command failure. Thanks Parag Sheth -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag.sheth at avagotech.com Fri Jun 27 12:23:55 2014 From: parag.sheth at avagotech.com (Parag Sheth) Date: Fri, 27 Jun 2014 12:23:55 -0700 Subject: [nvmewin] Potential bug in OFA driver 1.3 In-Reply-To: References: <8b4a1b7c1a6766de0c6b24e1e7826ee6@mail.gmail.com> <1c0e4b81e9217065ca4f556e8dacbbce@mail.gmail.com> <9ccb99560c7374cdcac88c8e0c915b5a@mail.gmail.com> Message-ID: Hi Alex, Yes that should fix one problem. In addition to that we need to modify DebugPrint statement in IO_StorPortNotification function in nvmestd.c (while enabling STORAGE_REQUEST_BLOCK) to avoid a blue screen. See attached email for the description. Since this is the first time we are testing driver with STORAGE_REQUEST_BLOCK enabled, we will have to go through a detailed testing. Thanks Parag Sheth *From:* Alex Chang [mailto:Alex.Chang at pmcs.com] *Sent:* Friday, June 27, 2014 12:10 PM *To:* Parag Sheth; nvmewin at lists.openfabrics.org *Subject:* RE: [nvmewin] Potential bug in OFA driver 1.3 Hi Parag, I’ve confirmed that the setting for SrbTypeFlags is required in order to receive STORAGE_REQUEST_BLOCK. In addition, I did see that SrbGetCdb macro provided by srbhelper returns NULL pointer and fixed it already. If SrbTypeFlags is used and set to receive STORAGE_REQUEST_BLOCK only for Windows 8 and up, SrbGetScsiData and SrbSetScsiData will only be called to handle STORAGE_REQUEST_BLOCK in our implementation. Will that solve your problem? Thanks, Alex *From:* Parag Sheth [mailto:parag.sheth at avagotech.com ] *Sent:* Thursday, June 26, 2014 11:51 AM *To:* Alex Chang; nvmewin at lists.openfabrics.org *Subject:* RE: [nvmewin] Potential bug in OFA driver 1.3 Hi Alex, I use VS 2012 for the build. Thanks Parag Sheth *From:* Alex Chang [mailto:Alex.Chang at pmcs.com] *Sent:* Thursday, June 26, 2014 11:46 AM *To:* Parag Sheth; nvmewin at lists.openfabrics.org *Subject:* RE: [nvmewin] Potential bug in OFA driver 1.3 Thanks, Parag. Let me confirm that first. By the way, could you please let me know how you build the driver for Windows 8? Alex *From:* Parag Sheth [mailto:parag.sheth at avagotech.com ] *Sent:* Thursday, June 26, 2014 11:30 AM *To:* Alex Chang; nvmewin at lists.openfabrics.org *Subject:* RE: [nvmewin] Potential bug in OFA driver 1.3 Hi Alex, What I have seen during my testing is that windows 8 sends down SCSI_REQUEST_BLOCK if we don’t set any value for SrbTypeFlags. And that is probably the reason nobody got into the blue screen that I mentioned in my previous email. Thanks Parag Sheth *From:* Alex Chang [mailto:Alex.Chang at pmcs.com] *Sent:* Thursday, June 26, 2014 9:20 AM *To:* Parag Sheth; nvmewin at lists.openfabrics.org *Subject:* RE: [nvmewin] Potential bug in OFA driver 1.3 Hi Parag, When we added supporting SRB Extension for Windows 8 and up, there is no plan that supports Windows 8 + SCSI_REQUEST_BLOCK. To be more specific, we need to indicate that via SrbTypeFlags of HW_INITIALIZATION_DATA. However, Windows 8 always sends down STORAGE_REQUEST_BLOCK when SrbTypeFlags is set to zero. Is that what you’re seeing on your testing? Thanks, Alex *From:* nvmewin-bounces at lists.openfabrics.org [ mailto:nvmewin-bounces at lists.openfabrics.org ] *On Behalf Of *Parag Sheth *Sent:* Wednesday, June 25, 2014 4:58 PM *To:* nvmewin at lists.openfabrics.org *Subject:* [nvmewin] Potential bug in OFA driver 1.3 Hi All, With the latest 1.3 driver, STORAGE_REQUEST_BLOCK support has been added for windows 8 and up. Is this the only configuration allowed with Windows 8 or SCSI_REQUEST_BLOCK + windows 8 combination is allowed as well? If allowed, than there are couple of bugs in the way srbhelper (from wdk) is being used. Specifically SrbSetScsiData() and SrbGetScsiData() from srbhelper do not handle SCSI_REQUEST_BLOCK properly and will cause command failure. Thanks Parag Sheth -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: unknown sender Subject: no subject Date: no date Size: 16045 URL: From Alex.Chang at pmcs.com Fri Jun 27 12:34:13 2014 From: Alex.Chang at pmcs.com (Alex Chang) Date: Fri, 27 Jun 2014 19:34:13 +0000 Subject: [nvmewin] Potential bug in OFA driver 1.3 In-Reply-To: References: <8b4a1b7c1a6766de0c6b24e1e7826ee6@mail.gmail.com> <1c0e4b81e9217065ca4f556e8dacbbce@mail.gmail.com> <9ccb99560c7374cdcac88c8e0c915b5a@mail.gmail.com> Message-ID: I did fix the one in IO_StorPortNotification as well. Thanks, Alex From: Parag Sheth [mailto:parag.sheth at avagotech.com] Sent: Friday, June 27, 2014 12:24 PM To: Alex Chang; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Potential bug in OFA driver 1.3 Hi Alex, Yes that should fix one problem. In addition to that we need to modify DebugPrint statement in IO_StorPortNotification function in nvmestd.c (while enabling STORAGE_REQUEST_BLOCK) to avoid a blue screen. See attached email for the description. Since this is the first time we are testing driver with STORAGE_REQUEST_BLOCK enabled, we will have to go through a detailed testing. Thanks Parag Sheth From: Alex Chang [mailto:Alex.Chang at pmcs.com] Sent: Friday, June 27, 2014 12:10 PM To: Parag Sheth; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Potential bug in OFA driver 1.3 Hi Parag, I’ve confirmed that the setting for SrbTypeFlags is required in order to receive STORAGE_REQUEST_BLOCK. In addition, I did see that SrbGetCdb macro provided by srbhelper returns NULL pointer and fixed it already. If SrbTypeFlags is used and set to receive STORAGE_REQUEST_BLOCK only for Windows 8 and up, SrbGetScsiData and SrbSetScsiData will only be called to handle STORAGE_REQUEST_BLOCK in our implementation. Will that solve your problem? Thanks, Alex From: Parag Sheth [mailto:parag.sheth at avagotech.com] Sent: Thursday, June 26, 2014 11:51 AM To: Alex Chang; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Potential bug in OFA driver 1.3 Hi Alex, I use VS 2012 for the build. Thanks Parag Sheth From: Alex Chang [mailto:Alex.Chang at pmcs.com] Sent: Thursday, June 26, 2014 11:46 AM To: Parag Sheth; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Potential bug in OFA driver 1.3 Thanks, Parag. Let me confirm that first. By the way, could you please let me know how you build the driver for Windows 8? Alex From: Parag Sheth [mailto:parag.sheth at avagotech.com] Sent: Thursday, June 26, 2014 11:30 AM To: Alex Chang; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Potential bug in OFA driver 1.3 Hi Alex, What I have seen during my testing is that windows 8 sends down SCSI_REQUEST_BLOCK if we don’t set any value for SrbTypeFlags. And that is probably the reason nobody got into the blue screen that I mentioned in my previous email. Thanks Parag Sheth From: Alex Chang [mailto:Alex.Chang at pmcs.com] Sent: Thursday, June 26, 2014 9:20 AM To: Parag Sheth; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Potential bug in OFA driver 1.3 Hi Parag, When we added supporting SRB Extension for Windows 8 and up, there is no plan that supports Windows 8 + SCSI_REQUEST_BLOCK. To be more specific, we need to indicate that via SrbTypeFlags of HW_INITIALIZATION_DATA. However, Windows 8 always sends down STORAGE_REQUEST_BLOCK when SrbTypeFlags is set to zero. Is that what you’re seeing on your testing? Thanks, Alex From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Parag Sheth Sent: Wednesday, June 25, 2014 4:58 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Potential bug in OFA driver 1.3 Hi All, With the latest 1.3 driver, STORAGE_REQUEST_BLOCK support has been added for windows 8 and up. Is this the only configuration allowed with Windows 8 or SCSI_REQUEST_BLOCK + windows 8 combination is allowed as well? If allowed, than there are couple of bugs in the way srbhelper (from wdk) is being used. Specifically SrbSetScsiData() and SrbGetScsiData() from srbhelper do not handle SCSI_REQUEST_BLOCK properly and will cause command failure. Thanks Parag Sheth -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheng.peng at memblaze.com Mon Jun 30 02:04:40 2014 From: cheng.peng at memblaze.com (cheng.peng at memblaze.com) Date: Mon, 30 Jun 2014 17:04:40 +0800 Subject: [nvmewin] Bug Check 133 Message-ID: <2014063017043810636219@memblaze.com> 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: From cheng.peng at memblaze.com Mon Jun 30 02:06:32 2014 From: cheng.peng at memblaze.com (cheng.peng at memblaze.com) Date: Mon, 30 Jun 2014 17:06:32 +0800 Subject: [nvmewin] Bug Check 133 References: <2014063017043810636219@memblaze.com> Message-ID: <2014063017063155639420@memblaze.com> 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: From Alex.Chang at pmcs.com Mon Jun 30 09:09:19 2014 From: Alex.Chang at pmcs.com (Alex Chang) Date: Mon, 30 Jun 2014 16:09:19 +0000 Subject: [nvmewin] Bug Check 133 In-Reply-To: <2014063017063155639420@memblaze.com> References: <2014063017043810636219@memblaze.com> <2014063017063155639420@memblaze.com> Message-ID: 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: From Kwok.Kong at pmcs.com Mon Jun 30 15:11:43 2014 From: Kwok.Kong at pmcs.com (Kwok Kong) Date: Mon, 30 Jun 2014 22:11:43 +0000 Subject: [nvmewin] Release 1.4 Plan and schedule Message-ID: <03D88B383FA04244AA514AA931F7B1290D33DC3A@BBYEXM02.pmc-sierra.internal> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: PlanningMeetingSamsungInput.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 32142 bytes Desc: PlanningMeetingSamsungInput.docx URL: From Kwok.Kong at pmcs.com Mon Jun 30 15:55:18 2014 From: Kwok.Kong at pmcs.com (Kwok Kong) Date: Mon, 30 Jun 2014 22:55:18 +0000 Subject: [nvmewin] Release 1.4 Plan and schedule In-Reply-To: <10581_1404168746_53B1EA2A_10581_5418_1_49158E750348AA499168FD41D88983606318EBEB@fmsmsx117.amr.corp.intel.com> References: <03D88B383FA04244AA514AA931F7B1290D33DC3A@BBYEXM02.pmc-sierra.internal> <10581_1404168746_53B1EA2A_10581_5418_1_49158E750348AA499168FD41D88983606318EBEB@fmsmsx117.amr.corp.intel.com> Message-ID: <03D88B383FA04244AA514AA931F7B1290D33DDE2@BBYEXM02.pmc-sierra.internal> Ray, This is great that you release this example code. I'll work with Alex to check it into the nvmewin repo. Thanks -Kwok From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 30, 2014 3:52 PM To: Kwok Kong; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Release 1.4 Plan and schedule 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 Kwok, This is great to see! Thank you to all the companies now contributing. I'm very happy to see the driver grow and evolve with the needs of the environment. On a similar note, I recently wrote a small, sample user space application that sends pass through IOCTLs. I had been getting external requests on how to actually code pass through IOCTLs for NVMe devices. So, in the spirit of information sharing. I have attached the sample app here. This code is non-proprietary and should fall under the BSD license. Please feel free to use, or even possibly post to the nvmewin repo so that other contributors and/or companies can pull this sample source code for reference. Zip password: intel1234 Enjoy! Thanks, Ray 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: From raymond.c.robles at intel.com Mon Jun 30 15:57:06 2014 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Mon, 30 Jun 2014 22:57:06 +0000 Subject: [nvmewin] Release 1.4 Plan and schedule In-Reply-To: <03D88B383FA04244AA514AA931F7B1290D33DDE2@BBYEXM02.pmc-sierra.internal> References: <03D88B383FA04244AA514AA931F7B1290D33DC3A@BBYEXM02.pmc-sierra.internal> <10581_1404168746_53B1EA2A_10581_5418_1_49158E750348AA499168FD41D88983606318EBEB@fmsmsx117.amr.corp.intel.com> <03D88B383FA04244AA514AA931F7B1290D33DDE2@BBYEXM02.pmc-sierra.internal> Message-ID: <49158E750348AA499168FD41D88983606318EC25@fmsmsx117.amr.corp.intel.com> You're welcome! Did the attachment get blocked? It was 11MB and I got a mail delivery failure message? From: Kwok Kong [mailto:Kwok.Kong at pmcs.com] Sent: Monday, June 30, 2014 3:55 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Release 1.4 Plan and schedule Ray, This is great that you release this example code. I'll work with Alex to check it into the nvmewin repo. Thanks -Kwok From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 30, 2014 3:52 PM To: Kwok Kong; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Release 1.4 Plan and schedule 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 Kwok, This is great to see! Thank you to all the companies now contributing. I'm very happy to see the driver grow and evolve with the needs of the environment. On a similar note, I recently wrote a small, sample user space application that sends pass through IOCTLs. I had been getting external requests on how to actually code pass through IOCTLs for NVMe devices. So, in the spirit of information sharing. I have attached the sample app here. This code is non-proprietary and should fall under the BSD license. Please feel free to use, or even possibly post to the nvmewin repo so that other contributors and/or companies can pull this sample source code for reference. Zip password: intel1234 Enjoy! Thanks, Ray 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: From Kwok.Kong at pmcs.com Mon Jun 30 15:59:03 2014 From: Kwok.Kong at pmcs.com (Kwok Kong) Date: Mon, 30 Jun 2014 22:59:03 +0000 Subject: [nvmewin] Release 1.4 Plan and schedule In-Reply-To: <49158E750348AA499168FD41D88983606318EC25@fmsmsx117.amr.corp.intel.com> References: <03D88B383FA04244AA514AA931F7B1290D33DC3A@BBYEXM02.pmc-sierra.internal> <10581_1404168746_53B1EA2A_10581_5418_1_49158E750348AA499168FD41D88983606318EBEB@fmsmsx117.amr.corp.intel.com> <03D88B383FA04244AA514AA931F7B1290D33DDE2@BBYEXM02.pmc-sierra.internal> <49158E750348AA499168FD41D88983606318EC25@fmsmsx117.amr.corp.intel.com> Message-ID: <03D88B383FA04244AA514AA931F7B1290D33DE7A@BBYEXM02.pmc-sierra.internal> It has warning by still got thru. I received the attached file. Thanks -Kwok From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 30, 2014 3:57 PM To: Kwok Kong; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Release 1.4 Plan and schedule You're welcome! Did the attachment get blocked? It was 11MB and I got a mail delivery failure message? From: Kwok Kong [mailto:Kwok.Kong at pmcs.com] Sent: Monday, June 30, 2014 3:55 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Release 1.4 Plan and schedule Ray, This is great that you release this example code. I'll work with Alex to check it into the nvmewin repo. Thanks -Kwok From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 30, 2014 3:52 PM To: Kwok Kong; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Release 1.4 Plan and schedule 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 Kwok, This is great to see! Thank you to all the companies now contributing. I'm very happy to see the driver grow and evolve with the needs of the environment. On a similar note, I recently wrote a small, sample user space application that sends pass through IOCTLs. I had been getting external requests on how to actually code pass through IOCTLs for NVMe devices. So, in the spirit of information sharing. I have attached the sample app here. This code is non-proprietary and should fall under the BSD license. Please feel free to use, or even possibly post to the nvmewin repo so that other contributors and/or companies can pull this sample source code for reference. Zip password: intel1234 Enjoy! Thanks, Ray 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: From Alex.Chang at pmcs.com Mon Jun 30 16:00:46 2014 From: Alex.Chang at pmcs.com (Alex Chang) Date: Mon, 30 Jun 2014 23:00:46 +0000 Subject: [nvmewin] Release 1.4 Plan and schedule In-Reply-To: <49158E750348AA499168FD41D88983606318EC25@fmsmsx117.amr.corp.intel.com> References: <03D88B383FA04244AA514AA931F7B1290D33DC3A@BBYEXM02.pmc-sierra.internal> <10581_1404168746_53B1EA2A_10581_5418_1_49158E750348AA499168FD41D88983606318EBEB@fmsmsx117.amr.corp.intel.com> <03D88B383FA04244AA514AA931F7B1290D33DDE2@BBYEXM02.pmc-sierra.internal> <49158E750348AA499168FD41D88983606318EC25@fmsmsx117.amr.corp.intel.com> Message-ID: Yes, I can download it. Thank you very much, Ray. I will check it into the repository and let everyone know once it's there. Alex From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 30, 2014 3:57 PM To: Kwok Kong; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Release 1.4 Plan and schedule You're welcome! Did the attachment get blocked? It was 11MB and I got a mail delivery failure message? From: Kwok Kong [mailto:Kwok.Kong at pmcs.com] Sent: Monday, June 30, 2014 3:55 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Release 1.4 Plan and schedule Ray, This is great that you release this example code. I'll work with Alex to check it into the nvmewin repo. Thanks -Kwok From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 30, 2014 3:52 PM To: Kwok Kong; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Release 1.4 Plan and schedule 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 Kwok, This is great to see! Thank you to all the companies now contributing. I'm very happy to see the driver grow and evolve with the needs of the environment. On a similar note, I recently wrote a small, sample user space application that sends pass through IOCTLs. I had been getting external requests on how to actually code pass through IOCTLs for NVMe devices. So, in the spirit of information sharing. I have attached the sample app here. This code is non-proprietary and should fall under the BSD license. Please feel free to use, or even possibly post to the nvmewin repo so that other contributors and/or companies can pull this sample source code for reference. Zip password: intel1234 Enjoy! Thanks, Ray 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: From raymond.c.robles at intel.com Mon Jun 30 16:00:07 2014 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Mon, 30 Jun 2014 23:00:07 +0000 Subject: [nvmewin] Release 1.4 Plan and schedule In-Reply-To: <03D88B383FA04244AA514AA931F7B1290D33DE7A@BBYEXM02.pmc-sierra.internal> References: <03D88B383FA04244AA514AA931F7B1290D33DC3A@BBYEXM02.pmc-sierra.internal> <10581_1404168746_53B1EA2A_10581_5418_1_49158E750348AA499168FD41D88983606318EBEB@fmsmsx117.amr.corp.intel.com> <03D88B383FA04244AA514AA931F7B1290D33DDE2@BBYEXM02.pmc-sierra.internal> <49158E750348AA499168FD41D88983606318EC25@fmsmsx117.amr.corp.intel.com> <03D88B383FA04244AA514AA931F7B1290D33DE7A@BBYEXM02.pmc-sierra.internal> Message-ID: <49158E750348AA499168FD41D88983606318EC40@fmsmsx117.amr.corp.intel.com> Excellent! From: Kwok Kong [mailto:Kwok.Kong at pmcs.com] Sent: Monday, June 30, 2014 3:59 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Release 1.4 Plan and schedule It has warning by still got thru. I received the attached file. Thanks -Kwok From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 30, 2014 3:57 PM To: Kwok Kong; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Release 1.4 Plan and schedule You're welcome! Did the attachment get blocked? It was 11MB and I got a mail delivery failure message? From: Kwok Kong [mailto:Kwok.Kong at pmcs.com] Sent: Monday, June 30, 2014 3:55 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Release 1.4 Plan and schedule Ray, This is great that you release this example code. I'll work with Alex to check it into the nvmewin repo. Thanks -Kwok From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 30, 2014 3:52 PM To: Kwok Kong; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Release 1.4 Plan and schedule 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 Kwok, This is great to see! Thank you to all the companies now contributing. I'm very happy to see the driver grow and evolve with the needs of the environment. On a similar note, I recently wrote a small, sample user space application that sends pass through IOCTLs. I had been getting external requests on how to actually code pass through IOCTLs for NVMe devices. So, in the spirit of information sharing. I have attached the sample app here. This code is non-proprietary and should fall under the BSD license. Please feel free to use, or even possibly post to the nvmewin repo so that other contributors and/or companies can pull this sample source code for reference. Zip password: intel1234 Enjoy! Thanks, Ray 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: From cheng.peng at memblaze.com Mon Jun 30 19:04:48 2014 From: cheng.peng at memblaze.com (cheng.peng at memblaze.com) Date: Tue, 1 Jul 2014 10:04:48 +0800 Subject: [nvmewin] Bug Check 133 References: <2014063017043810636219@memblaze.com>, <2014063017063155639420@memblaze.com>, Message-ID: <2014070110044647748612@memblaze.com> 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: