From suman.p at samsung.com Tue Dec 1 05:02:27 2015 From: suman.p at samsung.com (SUMAN PRAKASH B) Date: Tue, 01 Dec 2015 13:02:27 +0000 (GMT) Subject: [nvmewin] nvmewin Digest, Vol 47, Issue 6 Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 201512011834534_Y5W7Z1SF.png Type: image/png Size: 4274 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 201512011834539_QZUWXYH6.jpg Type: image/jpeg Size: 823 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 201512011834544_9220TQUP.gif Type: image/gif Size: 13168 bytes Desc: not available URL: From Uma.Parepalli at skhms.com Tue Dec 1 09:47:09 2015 From: Uma.Parepalli at skhms.com (Uma Parepalli) Date: Tue, 1 Dec 2015 17:47:09 +0000 Subject: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out In-Reply-To: References: <49158E750348AA499168FD41D88983607253C236@fmsmsx117.amr.corp.intel.com> <2a704af3b1f4439eab99dcfb5020baf9@N111XMB0240.skhms.com> Message-ID: Thank you Tom, Uma From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Monday, November 30, 2015 3:15 PM To: Uma Parepalli; Robles, Raymond C; 'nvmewin at lists.openfabrics.org' Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Hi Uma, This patch includes changes to support SNTL version 1.5, SCSI Persistent Reserve In/Out and a variety of small fixes. More details: 1. Numerous parts were changed to convert TABS to spaces 2. Make the driver compliant with SNTL 1.5 a. fail commands with Illegal Request when NACA bit in control field is set (SNTL 1.5, Section 3.3) nvmeSntiTypes.h, nvmeSnti.c:SntiTranslateCommand, SntiValidateNacaSetting b. Report LUNS support added for all values of Select Report field (SNTL 1.5, Section 4.5) nvmeSnti.c:SntiTranslateReportLuns c. Change serial number format in Unit Serial Number VPD page (SNTL 1.5, Section 6.1.3) The generated Product Serial Number is based on whether the device is V1.0 compliant, has an NGUID or EUI64 value. nvme.h, nvmeSntiTypes.h, nvmeSnti.h, nvmeSnti.c:SntiTranslateUnitSerialPage, SntiConvertULLongToA d. Update data returned in Device ID Data Page (SNTL 1.5, Section 6.1.4) Based on whether the device is V1.0 compliant, has an NGUID or EUI64 value, the driver will attempt to build a NAA IEEE Registered Extended designator, T10 Vendor ID Based descriptor, SCSI Name String Descriptor and EUI-64 based designator. nvme.h, nvmeSntiTypes.h, nvmeSnti.h, nvmeSnti.c:SntiTranslateDeviceIdentificationPage, SntiBuildIeeeRegExtDesc, SntiBuildT10VidBasedDesc, SntiBuildScsiNameStringDesc, SntiBuildEui64BasedDesc, SntiConvertULLongToA e. Set ATO bit in Control Mode Page to 1 (SNTL 1.5, Section 6.3.3.3) nvmeSnti.c:SntiCreateControlModePage, SntiReturnAllModePages f. Write_Protected command specific status (SNTL 1.5, Section 7.2) nvmeSnti.c g. Access denied Media Error (SNTL 1.5, Section 7.3) nvmeSnti.c 3. Add support for SCSI PERSISTENT RESERVE IN/OUT (SNTL 1.5, Sections 4.13 & 6.7) In support of this command, the driver must build and submit NVMe commands. The driver uses buffer space allocated by nvme_srb_extension.dsmBuffer for data areas required by these NVMe commands. nvme.h, nvmeStd.h, nvmeSnti.h, nvmeSntiTypes.h, nvmeSnti.c:SntiTranslateCommand, SntiTranslatePersistentReserveIn, SntiTranslatePersistentReserveOut, SntiBuildPersReserveRegisterCmd, SntiTranslatePersReserveInResponse, SntiTranslatePersReserveOutResponse 4. Add support for Identify Namespace List nvme.h, nvmeStd.c:NVMeIoctlIdentify 5. Change inquiry data to contain the last 4 characters of the firmware revision number (SNTL 1.5, Section 3.11) nvmeSnti.c:SntiTranslateStandardInquiryPage 6. Update read capacity 16 data to specify LogicalBlockProvisioningReadZeros = SPECIFIED (1) From SBC-4, Revision 8, section 5.18.2 "The logical block provisioning read zeros (LBPRZ) bit shall be set to one if the LBPRZ field in the Logical Block Provisioning VPD page (see 6.6.6) is set to xx1b. The LBPRZ bit shall be set to zero if the LBPRZ field in the Logical Block Provisioning VPD page is not set to xx1b." nvmeSnti.c:SntiTranslateReadCapacity16 7. Ensure returnStatus is initialized. There were code paths were it was returned without being set. nvmeSnti.c:SntiTranslateModeData 8. Correct the bit alignment for extended_inquiry_data and read_capacity_16_data nvmeSnti.h Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: Uma Parepalli [mailto:Uma.Parepalli at skhms.com] Sent: Monday, November 30, 2015 5:03 PM To: Robles, Raymond C >; Thomas Freeman >; 'nvmewin at lists.openfabrics.org' > Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Hi Ray and all, Is it possible to get a quick summary of the patch? Thank you, Uma From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Wednesday, November 25, 2015 2:52 PM To: 'Thomas Freeman'; 'nvmewin at lists.openfabrics.org' Subject: Re: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Hi Tom, Sorry for the delay in retesting your updated patch. We have finished our review/tests and Intel approves this patch. Now just need to wait approval from Samsung and PMC. Due to the holidays, we have a couple of options for this patch: - Wait for Samsung and PMC to come back with feedback/approval before pushing patch. - Push patch now (without approval from PMC and Samsung). Fix any remaining issues in future patches. The second option allows us to move forward with the next patch from Intel for namespace management. The first option is still ideal as we would like to get as much feedback as possible. Does anyone on this distribution have strong feelings for either option? Or an option I didn't describe? Thanks, Ray From: Robles, Raymond C Sent: Thursday, November 12, 2015 3:24 PM To: Thomas Freeman; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Thanks Tom! We'll rerun our tests. Thanks, Ray From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Thursday, November 12, 2015 3:23 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Hi Ray, There were issues with the IEKEY, RACQA, RRELA, RREGA and RTYPE. I'm attaching a new file with those fixes - SNTL15ResInOut111215.zip (password "nvmehgst"). The code passes Scsi compliance testing (reservation is not enabled) As before, I am doing a manual validation of PERSISTENT RESERVATION IN/OUT. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: Thomas Freeman Sent: Tuesday, November 10, 2015 4:52 PM To: 'Robles, Raymond C' >; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Hi Ray, I don't have hardware to support NVM Reservation Register. So, my testing was limited to issuing individual Scsi Persistent Reserve commands and manually verifying the Scsi to NVMe translation. As you observed, I missed the IEKEY field. My implementation was based on table 6-35 in the SNTL 1.5. That doesn't mention IEKEY. But, I overlooked the information about IEKEY from table 4-16. I'll make that change and submit a new patch. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, November 10, 2015 3:59 PM To: Thomas Freeman >; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Hi Tom, Intel has finished their internal testing of this patch. All tests passed with the exception of the MS SCSI Compliance Tests for Persistent Reserve In/Out (see attached file). We're not sure if the failures are due to IEKEY field not being handled in Persistent Reserve Out command. Was this something that was intentionally left out? Were you able to try the SCSI compliance test? Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, November 02, 2015 4:25 PM To: Thomas Freeman; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Hello all, I extended the review period for this patch to allow for more time. We're coming up on the end of the year and I'd like to wrap up all planned patches. Intel is wrapping up our review of this patch and will send out our feedback by the end of the week. Still awaiting feedback from Samsung and PMC. In order to keep to our original schedule, I'd like to wrap this patch up as soon as possible. Intel will be next with the namespace management patch. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Wednesday, October 07, 2015 12:54 PM To: Thomas Freeman; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Tom, Thanks for volunteering to submit this patch while Intel is wrapping up the namespace management patch. All Reviewers, Please provide feedback on HGST's patch by October 21st, 2015. Thanks! Thanks, Ray From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Wednesday, October 07, 2015 12:45 PM To: nvmewin at lists.openfabrics.org Cc: Robles, Raymond C Subject: Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out This patch includes changes to support SNTL version 1.5, SCSI Persistent Reserve In/Out and a variety of small fixes. The following tests were successfully run on Windows 2008 R2, Windows 2012 and Windows 2012 R2 1 hour sdstress, 1 hour IOMETER, Quick and Slow format - MBR and GPT, Microsoft Scsi Compliance. The above tests were run with an NVMe 1.1a compliant device that does not support NVMe Reservations. Testing variations of Unit SN VPD page/Device ID Data Page (requiring V1.0 or NGUID support) and SCSI Persistent Reserve In/Out, required setting breakpoints to manually alter the required Identify data. At that point individual SCSI commands were issued and the driver's response (NVMe commands issued and data returned) was manually verified. The attached file, SNTL15ResInOut.zip, contains a Patch file, a copy of the source code and a Log file detailing the changes made. The password for the file is "nvmehgst" Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com The information contained in this e-mail is considered confidential of SK hynix memory solutions Inc. and intended only for the persons addressed or copied in this e-mail. Any unauthorized use, dissemination of the information, or copying of this message is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email. HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. The information contained in this e-mail is considered confidential of SK hynix memory solutions Inc. and intended only for the persons addressed or copied in this e-mail. Any unauthorized use, dissemination of the information, or copying of this message is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 1117 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 4274 bytes Desc: image002.png URL: From thomas.freeman at hgst.com Tue Dec 1 14:07:25 2015 From: thomas.freeman at hgst.com (Thomas Freeman) Date: Tue, 1 Dec 2015 22:07:25 +0000 Subject: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out In-Reply-To: References: <49158E750348AA499168FD41D88983607253C236@fmsmsx117.amr.corp.intel.com> <2a704af3b1f4439eab99dcfb5020baf9@N111XMB0240.skhms.com> Message-ID: Attached is a zip file that includes changes for the fixes recommended by Suman. The password is "nvmehgst" Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: Uma Parepalli [mailto:Uma.Parepalli at skhms.com] Sent: Tuesday, December 1, 2015 11:47 AM To: Thomas Freeman ; Robles, Raymond C ; 'nvmewin at lists.openfabrics.org' Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Thank you Tom, Uma From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Monday, November 30, 2015 3:15 PM To: Uma Parepalli; Robles, Raymond C; 'nvmewin at lists.openfabrics.org' Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Hi Uma, This patch includes changes to support SNTL version 1.5, SCSI Persistent Reserve In/Out and a variety of small fixes. More details: 1. Numerous parts were changed to convert TABS to spaces 2. Make the driver compliant with SNTL 1.5 a. fail commands with Illegal Request when NACA bit in control field is set (SNTL 1.5, Section 3.3) nvmeSntiTypes.h, nvmeSnti.c:SntiTranslateCommand, SntiValidateNacaSetting b. Report LUNS support added for all values of Select Report field (SNTL 1.5, Section 4.5) nvmeSnti.c:SntiTranslateReportLuns c. Change serial number format in Unit Serial Number VPD page (SNTL 1.5, Section 6.1.3) The generated Product Serial Number is based on whether the device is V1.0 compliant, has an NGUID or EUI64 value. nvme.h, nvmeSntiTypes.h, nvmeSnti.h, nvmeSnti.c:SntiTranslateUnitSerialPage, SntiConvertULLongToA d. Update data returned in Device ID Data Page (SNTL 1.5, Section 6.1.4) Based on whether the device is V1.0 compliant, has an NGUID or EUI64 value, the driver will attempt to build a NAA IEEE Registered Extended designator, T10 Vendor ID Based descriptor, SCSI Name String Descriptor and EUI-64 based designator. nvme.h, nvmeSntiTypes.h, nvmeSnti.h, nvmeSnti.c:SntiTranslateDeviceIdentificationPage, SntiBuildIeeeRegExtDesc, SntiBuildT10VidBasedDesc, SntiBuildScsiNameStringDesc, SntiBuildEui64BasedDesc, SntiConvertULLongToA e. Set ATO bit in Control Mode Page to 1 (SNTL 1.5, Section 6.3.3.3) nvmeSnti.c:SntiCreateControlModePage, SntiReturnAllModePages f. Write_Protected command specific status (SNTL 1.5, Section 7.2) nvmeSnti.c g. Access denied Media Error (SNTL 1.5, Section 7.3) nvmeSnti.c 3. Add support for SCSI PERSISTENT RESERVE IN/OUT (SNTL 1.5, Sections 4.13 & 6.7) In support of this command, the driver must build and submit NVMe commands. The driver uses buffer space allocated by nvme_srb_extension.dsmBuffer for data areas required by these NVMe commands. nvme.h, nvmeStd.h, nvmeSnti.h, nvmeSntiTypes.h, nvmeSnti.c:SntiTranslateCommand, SntiTranslatePersistentReserveIn, SntiTranslatePersistentReserveOut, SntiBuildPersReserveRegisterCmd, SntiTranslatePersReserveInResponse, SntiTranslatePersReserveOutResponse 4. Add support for Identify Namespace List nvme.h, nvmeStd.c:NVMeIoctlIdentify 5. Change inquiry data to contain the last 4 characters of the firmware revision number (SNTL 1.5, Section 3.11) nvmeSnti.c:SntiTranslateStandardInquiryPage 6. Update read capacity 16 data to specify LogicalBlockProvisioningReadZeros = SPECIFIED (1) From SBC-4, Revision 8, section 5.18.2 "The logical block provisioning read zeros (LBPRZ) bit shall be set to one if the LBPRZ field in the Logical Block Provisioning VPD page (see 6.6.6) is set to xx1b. The LBPRZ bit shall be set to zero if the LBPRZ field in the Logical Block Provisioning VPD page is not set to xx1b." nvmeSnti.c:SntiTranslateReadCapacity16 7. Ensure returnStatus is initialized. There were code paths were it was returned without being set. nvmeSnti.c:SntiTranslateModeData 8. Correct the bit alignment for extended_inquiry_data and read_capacity_16_data nvmeSnti.h Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: Uma Parepalli [mailto:Uma.Parepalli at skhms.com] Sent: Monday, November 30, 2015 5:03 PM To: Robles, Raymond C >; Thomas Freeman >; 'nvmewin at lists.openfabrics.org' > Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Hi Ray and all, Is it possible to get a quick summary of the patch? Thank you, Uma From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Wednesday, November 25, 2015 2:52 PM To: 'Thomas Freeman'; 'nvmewin at lists.openfabrics.org' Subject: Re: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Hi Tom, Sorry for the delay in retesting your updated patch. We have finished our review/tests and Intel approves this patch. Now just need to wait approval from Samsung and PMC. Due to the holidays, we have a couple of options for this patch: - Wait for Samsung and PMC to come back with feedback/approval before pushing patch. - Push patch now (without approval from PMC and Samsung). Fix any remaining issues in future patches. The second option allows us to move forward with the next patch from Intel for namespace management. The first option is still ideal as we would like to get as much feedback as possible. Does anyone on this distribution have strong feelings for either option? Or an option I didn't describe? Thanks, Ray From: Robles, Raymond C Sent: Thursday, November 12, 2015 3:24 PM To: Thomas Freeman; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Thanks Tom! We'll rerun our tests. Thanks, Ray From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Thursday, November 12, 2015 3:23 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Hi Ray, There were issues with the IEKEY, RACQA, RRELA, RREGA and RTYPE. I'm attaching a new file with those fixes - SNTL15ResInOut111215.zip (password "nvmehgst"). The code passes Scsi compliance testing (reservation is not enabled) As before, I am doing a manual validation of PERSISTENT RESERVATION IN/OUT. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: Thomas Freeman Sent: Tuesday, November 10, 2015 4:52 PM To: 'Robles, Raymond C' >; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Hi Ray, I don't have hardware to support NVM Reservation Register. So, my testing was limited to issuing individual Scsi Persistent Reserve commands and manually verifying the Scsi to NVMe translation. As you observed, I missed the IEKEY field. My implementation was based on table 6-35 in the SNTL 1.5. That doesn't mention IEKEY. But, I overlooked the information about IEKEY from table 4-16. I'll make that change and submit a new patch. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, November 10, 2015 3:59 PM To: Thomas Freeman >; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Hi Tom, Intel has finished their internal testing of this patch. All tests passed with the exception of the MS SCSI Compliance Tests for Persistent Reserve In/Out (see attached file). We're not sure if the failures are due to IEKEY field not being handled in Persistent Reserve Out command. Was this something that was intentionally left out? Were you able to try the SCSI compliance test? Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, November 02, 2015 4:25 PM To: Thomas Freeman; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Hello all, I extended the review period for this patch to allow for more time. We're coming up on the end of the year and I'd like to wrap up all planned patches. Intel is wrapping up our review of this patch and will send out our feedback by the end of the week. Still awaiting feedback from Samsung and PMC. In order to keep to our original schedule, I'd like to wrap this patch up as soon as possible. Intel will be next with the namespace management patch. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Wednesday, October 07, 2015 12:54 PM To: Thomas Freeman; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Tom, Thanks for volunteering to submit this patch while Intel is wrapping up the namespace management patch. All Reviewers, Please provide feedback on HGST's patch by October 21st, 2015. Thanks! Thanks, Ray From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Wednesday, October 07, 2015 12:45 PM To: nvmewin at lists.openfabrics.org Cc: Robles, Raymond C Subject: Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out This patch includes changes to support SNTL version 1.5, SCSI Persistent Reserve In/Out and a variety of small fixes. The following tests were successfully run on Windows 2008 R2, Windows 2012 and Windows 2012 R2 1 hour sdstress, 1 hour IOMETER, Quick and Slow format - MBR and GPT, Microsoft Scsi Compliance. The above tests were run with an NVMe 1.1a compliant device that does not support NVMe Reservations. Testing variations of Unit SN VPD page/Device ID Data Page (requiring V1.0 or NGUID support) and SCSI Persistent Reserve In/Out, required setting breakpoints to manually alter the required Identify data. At that point individual SCSI commands were issued and the driver's response (NVMe commands issued and data returned) was manually verified. The attached file, SNTL15ResInOut.zip, contains a Patch file, a copy of the source code and a Log file detailing the changes made. The password for the file is "nvmehgst" Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com The information contained in this e-mail is considered confidential of SK hynix memory solutions Inc. and intended only for the persons addressed or copied in this e-mail. Any unauthorized use, dissemination of the information, or copying of this message is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email. HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. The information contained in this e-mail is considered confidential of SK hynix memory solutions Inc. and intended only for the persons addressed or copied in this e-mail. Any unauthorized use, dissemination of the information, or copying of this message is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.gif Type: image/gif Size: 1117 bytes Desc: image003.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 4274 bytes Desc: image004.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: HGSTSNTL15ResInOutVersion3.zip Type: application/x-zip-compressed Size: 236836 bytes Desc: HGSTSNTL15ResInOutVersion3.zip URL: -------------- next part -------------- HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. From iuliur at google.com Fri Dec 4 11:57:52 2015 From: iuliur at google.com (Iuliu Rus) Date: Fri, 4 Dec 2015 11:57:52 -0800 Subject: [nvmewin] FW: NVME fuzz test fixes In-Reply-To: <49158E750348AA499168FD41D88983606B773A5C@fmsmsx117.amr.corp.intel.com> References: <49158E750348AA499168FD41D88983606B76EEC6@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B76FCC8@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B773A5C@fmsmsx117.amr.corp.intel.com> Message-ID: Hi Raymond, We are continuously running the fuzz test in our lab and we have discovered a new issue. Some incorrect error handling results in nvme.sys setting the SRB_STATUS to: SRB_STATUS_AUTOSENSE_VALID | SRB_STATUS_ERROR | SRB_STATUS_SUCCESS (due to repeated or-ing in different functions) This actually means SRB_STATUS_BUSY (you are only allowed to or SRB_STATUS_AUTOSENSE_VALID). And it makes windows retry the command indefinitely (or at least a very long time). Do you still accept patches? We would like to push this fix into thunk at your earliest convenience. On Fri, Oct 2, 2015 at 11:47 AM, Robles, Raymond C < raymond.c.robles at intel.com> wrote: > Thank you Iuliu. I have applied your patch and created a new tag (#34). > > > > Thank you for using he SVN patch process. It worked very well. From this > point forward, I will enforce using the SVN patch process.The trunk is now > updated with Google’s latest patch. Please feel free to update as needed. > > > > Intel was next in line with the namespace patch, however we are still in > the process of unit testing. Is there any other company ready to submit a > patch? Samsung (Suman)? HGST (Tom)? > > > > Thanks, > > Ray > > > > *From:* Iuliu Rus [mailto:iuliur at google.com] > *Sent:* Thursday, October 01, 2015 11:13 AM > *To:* Robles, Raymond C > *Cc:* nvmewin at lists.openfabrics.org > > *Subject:* Re: FW: NVME fuzz test fixes > > > > Attached a patch file. > > > > On Tue, Sep 29, 2015 at 12:24 AM, Robles, Raymond C < > raymond.c.robles at intel.com> wrote: > > Hi Iuliu, > > As I was getting ready to merge your patch, I did a diff of your patch > with the current OFA trunk and noticed that you don’t have the latest > updates from the OFA trunk within your patch. > > I did not want to do a manual merge of your patch on top of the current > source in case there was any overlap. Could you please rebase your patch > with the latest OFA trunk? Thanks! > > This also brings up another point that you had previously raised to me… > patch submission. I spoke with Ken Strandberg (OFA admin) and he reminded > me that all SVN clients have a “create patch” and “apply patch” option. So, > if you don’t mind, once you are done with rebasing your code with the > latest trunk, could you please create a patch using the SVN tools? I use > TortoiseSVN and it’s pretty straightforward. You just need to copy your > files over your working copy of the trunk and select “create branch”. You > should then just be able to send me the patch. > > Thanks for being the guinea pig for this, but I think it makes sense to > use a patch tool as you recommended. Let me know if you have any questions. > > Thanks, > > Ray > > *From:* nvmewin-bounces at lists.openfabrics.org [mailto: > nvmewin-bounces at lists.openfabrics.org] *On Behalf Of *Robles, Raymond C > *Sent:* Monday, September 28, 2015 4:16 PM > *To:* suman.p at samsung.com; nvmewin-request at lists.openfabrics.org; > nvmewin at lists.openfabrics.org > > > *Subject:* Re: [nvmewin] FW: NVME fuzz test fixes > > > > Thanks Suman! I’ll push the patch today and it should be ready by tomorrow. > > Intel is up next with the Namespace Management patch. However, we are not > fully done with unit testing. Suman, is Samsung ready to push any of its > patches next? > > Thanks, > > Ray > > > > *From:* SUMAN PRAKASH B [mailto:suman.p at samsung.com ] > > *Sent:* Wednesday, September 23, 2015 4:49 AM > *To:* nvmewin-request at lists.openfabrics.org; nvmewin at lists.openfabrics.org; > Robles, Raymond C > *Subject:* Re: FW: NVME fuzz test fixes > > > > > > SAMSUNG approves the patch. > > > > Thanks, > > Suman > > ------- Original Message ------- > Sender : > nvmewin-request at lists.openfabrics.org > > Date : Sep 23, 2015 06:10 (GMT+05:30) > Title : nvmewin Digest, Vol 45, Issue 21 > > Send nvmewin mailing list submissions to > nvmewin at lists.openfabrics.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openfabrics.org/mailman/listinfo/nvmewin > or, via email, send a message with subject or body 'help' to > nvmewin-request at lists.openfabrics.org > > You can reach the person managing the list at > nvmewin-owner at lists.openfabrics.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of nvmewin digest..." > > > Today's Topics: > > 1. Re: FW: NVME fuzz test fixes (Robles, Raymond C) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 23 Sep 2015 00:40:46 +0000 > From: "Robles, Raymond C" > To: Alex Chang , Thomas Freeman > , Iuliu Rus > Cc: "nvmewin at lists.openfabrics.org" > Subject: Re: [nvmewin] FW: NVME fuzz test fixes > Message-ID: > <49158E750348AA499168FD41D88983606B769A4B at fmsmsx117.amr.corp.intel.com> > > Content-Type: text/plain; charset="utf-8" > > Thanks Alex! > > From: nvmewin-bounces at lists.openfabrics.org [ > mailto:nvmewin-bounces at lists.openfabrics.org > ] On Behalf Of Alex Chang > Sent: Tuesday, September 22, 2015 2:28 PM > To: Thomas Freeman; Iuliu Rus > Cc: nvmewin at lists.openfabrics.org; uliur at google.com > Subject: Re: [nvmewin] FW: NVME fuzz test fixes > > PMC approves the patch. > > Thank you! > Alex > > From: > nvmewin-bounces at lists.openfabrics.org > [mailto:nvmewin-bounces at lists.openfabrics.org > ] On Behalf Of Thomas Freeman > Sent: Tuesday, September 22, 2015 1:02 PM > To: Iuliu Rus > Cc: nvmewin at lists.openfabrics.org; > uliur at google.com > Subject: Re: [nvmewin] FW: NVME fuzz test fixes > > > HGST approves these changes. > > Tom Freeman > Software Engineer, Device Manager and Driver Development > HGST, a Western Digital company > thomas.freeman at hgst.com > 507-322-2311 > > [HGST_Logo_email] > 3605 Hwy 52 N > Rochester, MN 55901 > > www.hgst.com > > > > From: Iuliu Rus [mailto:iuliur at google.com ] > Sent: Tuesday, September 15, 2015 12:08 PM > To: Thomas Freeman >> > Cc: Robles, Raymond C < > raymond.c.robles at intel.com>; > nvmewin at lists.openfabrics.org; > uliur at google.com > Subject: Re: [nvmewin] FW: NVME fuzz test fixes > > Thanks for the great feedback. Fixed all and attached the new zip (same > password). I also reran the tests, but for 3) the Microsoft fuzz test seems > to have no coverage. It keeps asking for sense data with aloc length of 0 > (like 100 times). I artificially tested this by modifying the allocLength > variable in kernel debugger. > > > > On Mon, Sep 14, 2015 at 1:41 PM, Thomas Freeman < > thomas.freeman at hgst.com> wrote: > Iuliu, > The changes look good. > I have just a few comments. > > 1. nvmeSnti.C/Line 1157 ? memset(pResponseBuffer, 0, allocLength); > This was added to the comment, but it?s not clear why. I suspect it is an > accidental addition. If so, this should be removed. > > 2. nvmeSnti.c/Line 1519 ? Since the Lun value is actually written to > the second byte of the entry, the comparison should be: > > if (lunIdDataOffset + SINGLE_LVL_LUN_OFFSET >= allocLength) > > > > As an example, test with a buffer size of 0x11. Without this change, the > driver will actually write the byte after the allocated buffer. > > 3. nvmeSnti.c/Line 2652 & 2669. Your change handles the case where > there is no data buffer. But, it does not handle the case where the buffer > is smaller than sizeof(DESCRIPTOR_FORMAT_SENSE_DATA). With a small buffer > allocation, these writes would access beyond the allocated buffer > > > pSenseData->ErrorCode = FIXED_SENSE_DATA; > > pSenseData->SenseKey = SCSI_SENSE_NO_SENSE; > > pSenseData->AdditionalSenseLength = > FIXED_SENSE_DATA_ADD_LENGTH; > > pSenseData->AdditionalSenseCode = > SCSI_ADSENSE_NO_SENSE; > > pSenseData->AdditionalSenseCodeQualifier = 0; > > > Regards, > Tom Freeman > Software Engineer, Device Manager and Driver Development > HGST, a Western Digital company > thomas.freeman at hgst.com > 507-322-2311> > > [HGST_Logo_email] > 3605 Hwy 52 N > Rochester, MN 55901 > > www.hgst.com > > > > From: > nvmewin-bounces at lists.openfabrics.org > [ > mailto:nvmewin-bounces at lists.openfabrics.org > ] > On Behalf Of Robles, Raymond C > Sent: Friday, September 11, 2015 3:29 PM > To: nvmewin at lists.openfabrics.org > Subject: [nvmewin] FW: NVME fuzz test fixes > > All, > > Here is the original patch from Google (Iuliu) for the WHCK fuzz tests. > > Thanks, > Ray > > From: > nvmewin-bounces at lists.openfabrics.org > [mailto:nvmewin-bounces at lists.openfabrics.org > ] On Behalf Of Iuliu Rus > Sent: Monday, August 03, 2015 1:37 PM > To: nvmewin at lists.openfabrics.org > Subject: [nvmewin] NVME fuzz test fixes > > Hello, > I have attached the fixes we (Google) did for the several crashes / > corruptions exposed by the Windows HCK fuzztest.exe. > We have tested this on qemu/ Server 2012 R2. > The password on the zip is "nvme" :) > HGST E-mail Confidentiality Notice & Disclaimer: > This e-mail and any files transmitted with it may contain confidential or > legally privileged information of HGST and are intended solely for the use > of the individual or entity to which they are addressed. If you are not the > intended recipient, any disclosure, copying, distribution or any action > taken or omitted to be taken in reliance on it, is prohibited. If you have > received this e-mail in error, please notify the sender immediately and > delete the e-mail in its entirety from your system. > > _______________________________________________ > nvmewin mailing list > nvmewin at lists.openfabrics.org > http://lists.openfabrics.org/mailman/listinfo/nvmewin > > HGST E-mail Confidentiality Notice & Disclaimer: > This e-mail and any files transmitted with it may contain confidential or > legally privileged information of HGST and are intended solely for the use > of the individual or entity to which they are addressed. If you are not the > intended recipient, any disclosure, copying, distribution or any action > taken or omitted to be taken in reliance on it, is prohibited. If you have > received this e-mail in error, please notify the sender immediately and > delete the e-mail in its entirety from your system. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.openfabrics.org/pipermail/nvmewin/attachments/20150923/fede796b/attachment.html > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: image001.png > Type: image/png > Size: 4274 bytes > Desc: image001.png > URL: < > http://lists.openfabrics.org/pipermail/nvmewin/attachments/20150923/fede796b/attachment.png > > > > ------------------------------ > > _______________________________________________ > nvmewin mailing list > nvmewin at lists.openfabrics.org > http://lists.openfabrics.org/mailman/listinfo/nvmewin > > > End of nvmewin Digest, Vol 45, Issue 21 > *************************************** >

 

 

> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.c.robles at intel.com Fri Dec 4 12:41:01 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Fri, 4 Dec 2015 20:41:01 +0000 Subject: [nvmewin] FW: NVME fuzz test fixes In-Reply-To: References: <49158E750348AA499168FD41D88983606B76EEC6@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B76FCC8@fmsmsx117.amr.corp.intel.com> <49158E750348AA499168FD41D88983606B773A5C@fmsmsx117.amr.corp.intel.com> Message-ID: <49158E750348AA499168FD41D8898360725446BB@fmsmsx117.amr.corp.intel.com> Hi Iuliu, Yes we are still accepting patches. Please feel free to submit a patch request. Right now we are finishing up HGST’s multi-path patch, and then Intel will be pushing a patch for namespace management. After these two patches, you may submit your patch. Thanks, Ray From: Iuliu Rus [mailto:iuliur at google.com] Sent: Friday, December 04, 2015 12:58 PM To: Robles, Raymond C Cc: nvmewin at lists.openfabrics.org Subject: Re: FW: NVME fuzz test fixes Hi Raymond, We are continuously running the fuzz test in our lab and we have discovered a new issue. Some incorrect error handling results in nvme.sys setting the SRB_STATUS to: SRB_STATUS_AUTOSENSE_VALID | SRB_STATUS_ERROR | SRB_STATUS_SUCCESS (due to repeated or-ing in different functions) This actually means SRB_STATUS_BUSY (you are only allowed to or SRB_STATUS_AUTOSENSE_VALID). And it makes windows retry the command indefinitely (or at least a very long time). Do you still accept patches? We would like to push this fix into thunk at your earliest convenience. On Fri, Oct 2, 2015 at 11:47 AM, Robles, Raymond C > wrote: Thank you Iuliu. I have applied your patch and created a new tag (#34). Thank you for using he SVN patch process. It worked very well. From this point forward, I will enforce using the SVN patch process.The trunk is now updated with Google’s latest patch. Please feel free to update as needed. Intel was next in line with the namespace patch, however we are still in the process of unit testing. Is there any other company ready to submit a patch? Samsung (Suman)? HGST (Tom)? Thanks, Ray From: Iuliu Rus [mailto:iuliur at google.com] Sent: Thursday, October 01, 2015 11:13 AM To: Robles, Raymond C Cc: nvmewin at lists.openfabrics.org Subject: Re: FW: NVME fuzz test fixes Attached a patch file. On Tue, Sep 29, 2015 at 12:24 AM, Robles, Raymond C > wrote: Hi Iuliu, As I was getting ready to merge your patch, I did a diff of your patch with the current OFA trunk and noticed that you don’t have the latest updates from the OFA trunk within your patch. I did not want to do a manual merge of your patch on top of the current source in case there was any overlap. Could you please rebase your patch with the latest OFA trunk? Thanks! This also brings up another point that you had previously raised to me… patch submission. I spoke with Ken Strandberg (OFA admin) and he reminded me that all SVN clients have a “create patch” and “apply patch” option. So, if you don’t mind, once you are done with rebasing your code with the latest trunk, could you please create a patch using the SVN tools? I use TortoiseSVN and it’s pretty straightforward. You just need to copy your files over your working copy of the trunk and select “create branch”. You should then just be able to send me the patch. Thanks for being the guinea pig for this, but I think it makes sense to use a patch tool as you recommended. Let me know if you have any questions. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, September 28, 2015 4:16 PM To: suman.p at samsung.com; nvmewin-request at lists.openfabrics.org; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] FW: NVME fuzz test fixes Thanks Suman! I’ll push the patch today and it should be ready by tomorrow. Intel is up next with the Namespace Management patch. However, we are not fully done with unit testing. Suman, is Samsung ready to push any of its patches next? Thanks, Ray From: SUMAN PRAKASH B [mailto:suman.p at samsung.com] Sent: Wednesday, September 23, 2015 4:49 AM To: nvmewin-request at lists.openfabrics.org; nvmewin at lists.openfabrics.org; Robles, Raymond C Subject: Re: FW: NVME fuzz test fixes SAMSUNG approves the patch. Thanks, Suman ------- Original Message ------- Sender : nvmewin-request at lists.openfabrics.org> Date : Sep 23, 2015 06:10 (GMT+05:30) Title : nvmewin Digest, Vol 45, Issue 21 Send nvmewin mailing list submissions to nvmewin at lists.openfabrics.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openfabrics.org/mailman/listinfo/nvmewin or, via email, send a message with subject or body 'help' to nvmewin-request at lists.openfabrics.org You can reach the person managing the list at nvmewin-owner at lists.openfabrics.org When replying, please edit your Subject line so it is more specific than "Re: Contents of nvmewin digest..." Today's Topics: 1. Re: FW: NVME fuzz test fixes (Robles, Raymond C) ---------------------------------------------------------------------- Message: 1 Date: Wed, 23 Sep 2015 00:40:46 +0000 From: "Robles, Raymond C" > To: Alex Chang >, Thomas Freeman >, Iuliu Rus > Cc: "nvmewin at lists.openfabrics.org" > Subject: Re: [nvmewin] FW: NVME fuzz test fixes Message-ID: <49158E750348AA499168FD41D88983606B769A4B at fmsmsx117.amr.corp.intel.com> Content-Type: text/plain; charset="utf-8" Thanks Alex! From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang Sent: Tuesday, September 22, 2015 2:28 PM To: Thomas Freeman; Iuliu Rus Cc: nvmewin at lists.openfabrics.org; uliur at google.com Subject: Re: [nvmewin] FW: NVME fuzz test fixes PMC approves the patch. Thank you! Alex From: nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Thomas Freeman Sent: Tuesday, September 22, 2015 1:02 PM To: Iuliu Rus Cc: nvmewin at lists.openfabrics.org>; uliur at google.com> Subject: Re: [nvmewin] FW: NVME fuzz test fixes HGST approves these changes. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com> 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com> From: Iuliu Rus [mailto:iuliur at google.com] Sent: Tuesday, September 15, 2015 12:08 PM To: Thomas Freeman >> Cc: Robles, Raymond C >>; nvmewin at lists.openfabrics.org>; uliur at google.com> Subject: Re: [nvmewin] FW: NVME fuzz test fixes Thanks for the great feedback. Fixed all and attached the new zip (same password). I also reran the tests, but for 3) the Microsoft fuzz test seems to have no coverage. It keeps asking for sense data with aloc length of 0 (like 100 times). I artificially tested this by modifying the allocLength variable in kernel debugger. On Mon, Sep 14, 2015 at 1:41 PM, Thomas Freeman >> wrote: Iuliu, The changes look good. I have just a few comments. 1. nvmeSnti.C/Line 1157 ? memset(pResponseBuffer, 0, allocLength); This was added to the comment, but it?s not clear why. I suspect it is an accidental addition. If so, this should be removed. 2. nvmeSnti.c/Line 1519 ? Since the Lun value is actually written to the second byte of the entry, the comparison should be: if (lunIdDataOffset + SINGLE_LVL_LUN_OFFSET >= allocLength) As an example, test with a buffer size of 0x11. Without this change, the driver will actually write the byte after the allocated buffer. 3. nvmeSnti.c/Line 2652 & 2669. Your change handles the case where there is no data buffer. But, it does not handle the case where the buffer is smaller than sizeof(DESCRIPTOR_FORMAT_SENSE_DATA). With a small buffer allocation, these writes would access beyond the allocated buffer pSenseData->ErrorCode = FIXED_SENSE_DATA; pSenseData->SenseKey = SCSI_SENSE_NO_SENSE; pSenseData->AdditionalSenseLength = FIXED_SENSE_DATA_ADD_LENGTH; pSenseData->AdditionalSenseCode = SCSI_ADSENSE_NO_SENSE; pSenseData->AdditionalSenseCodeQualifier = 0; Regards, Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com> 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com> From: nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Friday, September 11, 2015 3:29 PM To: nvmewin at lists.openfabrics.org> Subject: [nvmewin] FW: NVME fuzz test fixes All, Here is the original patch from Google (Iuliu) for the WHCK fuzz tests. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Iuliu Rus Sent: Monday, August 03, 2015 1:37 PM To: nvmewin at lists.openfabrics.org> Subject: [nvmewin] NVME fuzz test fixes Hello, I have attached the fixes we (Google) did for the several crashes / corruptions exposed by the Windows HCK fuzztest.exe. We have tested this on qemu/ Server 2012 R2. The password on the zip is "nvme" :) HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org> http://lists.openfabrics.org/mailman/listinfo/nvmewin HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4274 bytes Desc: image001.png URL: ------------------------------ _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/nvmewin End of nvmewin Digest, Vol 45, Issue 21 ***************************************

 

 

[http://ext.samsung.net/mailcheck/SeenTimeChecker?do=36652d682e3669a8058afc1f1dafb9f39cd05f6ab872f9f6313cb48408a29da1bbef98290b9ea6844a835b19b8ec809fc7b41e955949e5c8a728c55b39cc59eacf878f9a26ce15a0] -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.c.robles at intel.com Wed Dec 9 10:36:50 2015 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Wed, 9 Dec 2015 18:36:50 +0000 Subject: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out In-Reply-To: References: <49158E750348AA499168FD41D88983607253C236@fmsmsx117.amr.corp.intel.com> <2a704af3b1f4439eab99dcfb5020baf9@N111XMB0240.skhms.com> Message-ID: <49158E750348AA499168FD41D889836072549169@fmsmsx117.amr.corp.intel.com> Hello, Samsung has approved the patch. I will push the patch in the next day. Please stay tuned for an email from me addressing the 2015 driver release. I will be requesting feedback on alternative options since we did not get all patches submitted and reviewed that were originally planned. Thanks, Ray From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Tuesday, December 01, 2015 3:07 PM To: Robles, Raymond C; 'nvmewin at lists.openfabrics.org' Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Attached is a zip file that includes changes for the fixes recommended by Suman. The password is "nvmehgst" Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: Uma Parepalli [mailto:Uma.Parepalli at skhms.com] Sent: Tuesday, December 1, 2015 11:47 AM To: Thomas Freeman >; Robles, Raymond C >; 'nvmewin at lists.openfabrics.org' > Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Thank you Tom, Uma From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Monday, November 30, 2015 3:15 PM To: Uma Parepalli; Robles, Raymond C; 'nvmewin at lists.openfabrics.org' Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Hi Uma, This patch includes changes to support SNTL version 1.5, SCSI Persistent Reserve In/Out and a variety of small fixes. More details: 1. Numerous parts were changed to convert TABS to spaces 2. Make the driver compliant with SNTL 1.5 a. fail commands with Illegal Request when NACA bit in control field is set (SNTL 1.5, Section 3.3) nvmeSntiTypes.h, nvmeSnti.c:SntiTranslateCommand, SntiValidateNacaSetting b. Report LUNS support added for all values of Select Report field (SNTL 1.5, Section 4.5) nvmeSnti.c:SntiTranslateReportLuns c. Change serial number format in Unit Serial Number VPD page (SNTL 1.5, Section 6.1.3) The generated Product Serial Number is based on whether the device is V1.0 compliant, has an NGUID or EUI64 value. nvme.h, nvmeSntiTypes.h, nvmeSnti.h, nvmeSnti.c:SntiTranslateUnitSerialPage, SntiConvertULLongToA d. Update data returned in Device ID Data Page (SNTL 1.5, Section 6.1.4) Based on whether the device is V1.0 compliant, has an NGUID or EUI64 value, the driver will attempt to build a NAA IEEE Registered Extended designator, T10 Vendor ID Based descriptor, SCSI Name String Descriptor and EUI-64 based designator. nvme.h, nvmeSntiTypes.h, nvmeSnti.h, nvmeSnti.c:SntiTranslateDeviceIdentificationPage, SntiBuildIeeeRegExtDesc, SntiBuildT10VidBasedDesc, SntiBuildScsiNameStringDesc, SntiBuildEui64BasedDesc, SntiConvertULLongToA e. Set ATO bit in Control Mode Page to 1 (SNTL 1.5, Section 6.3.3.3) nvmeSnti.c:SntiCreateControlModePage, SntiReturnAllModePages f. Write_Protected command specific status (SNTL 1.5, Section 7.2) nvmeSnti.c g. Access denied Media Error (SNTL 1.5, Section 7.3) nvmeSnti.c 3. Add support for SCSI PERSISTENT RESERVE IN/OUT (SNTL 1.5, Sections 4.13 & 6.7) In support of this command, the driver must build and submit NVMe commands. The driver uses buffer space allocated by nvme_srb_extension.dsmBuffer for data areas required by these NVMe commands. nvme.h, nvmeStd.h, nvmeSnti.h, nvmeSntiTypes.h, nvmeSnti.c:SntiTranslateCommand, SntiTranslatePersistentReserveIn, SntiTranslatePersistentReserveOut, SntiBuildPersReserveRegisterCmd, SntiTranslatePersReserveInResponse, SntiTranslatePersReserveOutResponse 4. Add support for Identify Namespace List nvme.h, nvmeStd.c:NVMeIoctlIdentify 5. Change inquiry data to contain the last 4 characters of the firmware revision number (SNTL 1.5, Section 3.11) nvmeSnti.c:SntiTranslateStandardInquiryPage 6. Update read capacity 16 data to specify LogicalBlockProvisioningReadZeros = SPECIFIED (1) From SBC-4, Revision 8, section 5.18.2 "The logical block provisioning read zeros (LBPRZ) bit shall be set to one if the LBPRZ field in the Logical Block Provisioning VPD page (see 6.6.6) is set to xx1b. The LBPRZ bit shall be set to zero if the LBPRZ field in the Logical Block Provisioning VPD page is not set to xx1b." nvmeSnti.c:SntiTranslateReadCapacity16 7. Ensure returnStatus is initialized. There were code paths were it was returned without being set. nvmeSnti.c:SntiTranslateModeData 8. Correct the bit alignment for extended_inquiry_data and read_capacity_16_data nvmeSnti.h Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: Uma Parepalli [mailto:Uma.Parepalli at skhms.com] Sent: Monday, November 30, 2015 5:03 PM To: Robles, Raymond C >; Thomas Freeman >; 'nvmewin at lists.openfabrics.org' > Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Hi Ray and all, Is it possible to get a quick summary of the patch? Thank you, Uma From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Wednesday, November 25, 2015 2:52 PM To: 'Thomas Freeman'; 'nvmewin at lists.openfabrics.org' Subject: Re: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Hi Tom, Sorry for the delay in retesting your updated patch. We have finished our review/tests and Intel approves this patch. Now just need to wait approval from Samsung and PMC. Due to the holidays, we have a couple of options for this patch: - Wait for Samsung and PMC to come back with feedback/approval before pushing patch. - Push patch now (without approval from PMC and Samsung). Fix any remaining issues in future patches. The second option allows us to move forward with the next patch from Intel for namespace management. The first option is still ideal as we would like to get as much feedback as possible. Does anyone on this distribution have strong feelings for either option? Or an option I didn't describe? Thanks, Ray From: Robles, Raymond C Sent: Thursday, November 12, 2015 3:24 PM To: Thomas Freeman; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Thanks Tom! We'll rerun our tests. Thanks, Ray From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Thursday, November 12, 2015 3:23 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Hi Ray, There were issues with the IEKEY, RACQA, RRELA, RREGA and RTYPE. I'm attaching a new file with those fixes - SNTL15ResInOut111215.zip (password "nvmehgst"). The code passes Scsi compliance testing (reservation is not enabled) As before, I am doing a manual validation of PERSISTENT RESERVATION IN/OUT. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: Thomas Freeman Sent: Tuesday, November 10, 2015 4:52 PM To: 'Robles, Raymond C' >; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Hi Ray, I don't have hardware to support NVM Reservation Register. So, my testing was limited to issuing individual Scsi Persistent Reserve commands and manually verifying the Scsi to NVMe translation. As you observed, I missed the IEKEY field. My implementation was based on table 6-35 in the SNTL 1.5. That doesn't mention IEKEY. But, I overlooked the information about IEKEY from table 4-16. I'll make that change and submit a new patch. Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, November 10, 2015 3:59 PM To: Thomas Freeman >; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Hi Tom, Intel has finished their internal testing of this patch. All tests passed with the exception of the MS SCSI Compliance Tests for Persistent Reserve In/Out (see attached file). We're not sure if the failures are due to IEKEY field not being handled in Persistent Reserve Out command. Was this something that was intentionally left out? Were you able to try the SCSI compliance test? Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, November 02, 2015 4:25 PM To: Thomas Freeman; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Hello all, I extended the review period for this patch to allow for more time. We're coming up on the end of the year and I'd like to wrap up all planned patches. Intel is wrapping up our review of this patch and will send out our feedback by the end of the week. Still awaiting feedback from Samsung and PMC. In order to keep to our original schedule, I'd like to wrap this patch up as soon as possible. Intel will be next with the namespace management patch. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Wednesday, October 07, 2015 12:54 PM To: Thomas Freeman; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out Tom, Thanks for volunteering to submit this patch while Intel is wrapping up the namespace management patch. All Reviewers, Please provide feedback on HGST's patch by October 21st, 2015. Thanks! Thanks, Ray From: Thomas Freeman [mailto:thomas.freeman at hgst.com] Sent: Wednesday, October 07, 2015 12:45 PM To: nvmewin at lists.openfabrics.org Cc: Robles, Raymond C Subject: Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out This patch includes changes to support SNTL version 1.5, SCSI Persistent Reserve In/Out and a variety of small fixes. The following tests were successfully run on Windows 2008 R2, Windows 2012 and Windows 2012 R2 1 hour sdstress, 1 hour IOMETER, Quick and Slow format - MBR and GPT, Microsoft Scsi Compliance. The above tests were run with an NVMe 1.1a compliant device that does not support NVMe Reservations. Testing variations of Unit SN VPD page/Device ID Data Page (requiring V1.0 or NGUID support) and SCSI Persistent Reserve In/Out, required setting breakpoints to manually alter the required Identify data. At that point individual SCSI commands were issued and the driver's response (NVMe commands issued and data returned) was manually verified. The attached file, SNTL15ResInOut.zip, contains a Patch file, a copy of the source code and a Log file detailing the changes made. The password for the file is "nvmehgst" Tom Freeman Software Engineer, Device Manager and Driver Development HGST, a Western Digital company thomas.freeman at hgst.com 507-322-2311 [HGST_Logo_email] 3605 Hwy 52 N Rochester, MN 55901 www.hgst.com The information contained in this e-mail is considered confidential of SK hynix memory solutions Inc. and intended only for the persons addressed or copied in this e-mail. Any unauthorized use, dissemination of the information, or copying of this message is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email. HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system. The information contained in this e-mail is considered confidential of SK hynix memory solutions Inc. and intended only for the persons addressed or copied in this e-mail. Any unauthorized use, dissemination of the information, or copying of this message is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 1117 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 4274 bytes Desc: image002.png URL: From asb at cin.ufpe.br Fri Dec 18 11:10:27 2015 From: asb at cin.ufpe.br (Angelo Brito) Date: Fri, 18 Dec 2015 17:10:27 -0200 Subject: [nvmewin] Is NVMe Generic Devices supported? Message-ID: Hello All, I have a generic NVMe device that works perfectly on Linux but does not work on Windows. The device is recognized as a Default NVMe Controller with Microsoft as vendor but issue an error code 10: This device cannot start. I am aware that this is a generic error code and could mean any thing. I have started to debug from the device perspective and the Host CPU just writes the MSI configuration registers during startup. I use Altera´s PCIe Hard IP to implement the PCIe and my controller is hosted on FPGA. The device was never started. Someone can share any more leads to debug? Why windows doesn´t start my device? Regards, Angelo Silva Brito. B.S. in Computer Engineering - UFPE Brazil http://about.me/angelobrito _________________________________________________ From iuliur at google.com Fri Dec 18 11:29:43 2015 From: iuliur at google.com (Iuliu Rus) Date: Fri, 18 Dec 2015 11:29:43 -0800 Subject: [nvmewin] Is NVMe Generic Devices supported? In-Reply-To: References: Message-ID: Last time this happened to us it was because the device was responding with an IdentifyController structure which had no firmware_revision field and the fields were padded with zeroes instead of spaces. Does your device get any commands on the admin queue from windows? On Fri, Dec 18, 2015 at 11:10 AM, Angelo Brito wrote: > Hello All, > > I have a generic NVMe device that works perfectly on Linux but does > not work on Windows. The device is recognized as a Default NVMe > Controller with Microsoft as vendor but issue an error code 10: This > device cannot start. I am aware that this is a generic error code and > could mean any thing. > > I have started to debug from the device perspective and the Host CPU > just writes the MSI configuration registers during startup. I use > Altera´s PCIe Hard IP to implement the PCIe and my controller is > hosted on FPGA. The device was never started. > > Someone can share any more leads to debug? Why windows doesn´t start my > device? > > Regards, > Angelo Silva Brito. > B.S. in Computer Engineering - UFPE Brazil > http://about.me/angelobrito > _________________________________________________ > _______________________________________________ > nvmewin mailing list > nvmewin at lists.openfabrics.org > http://lists.openfabrics.org/mailman/listinfo/nvmewin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asb at cin.ufpe.br Fri Dec 18 12:36:50 2015 From: asb at cin.ufpe.br (Angelo Brito) Date: Fri, 18 Dec 2015 15:36:50 -0500 Subject: [nvmewin] Is NVMe Generic Devices supported? In-Reply-To: References: Message-ID: Hi Iuliu, I haven't seen any commands. No write were sent to my controller other than the MSIX configuration. Not even the Admin Queue's registers. I suspect that for some reason windows NVMe Driver is dropping off my controller after the PCIe configuration and windows events wasn't of much help. The events reported: - System - Provider [ Name] stornvme - EventID 11 [ Qualifiers] 49156 Level 2 Task 0 Keywords 0x80000000000000 - TimeCreated [ SystemTime] 2015-12-18T18:28:31.145251600Z EventRecordID 2443 Channel System Computer schenberg-PC Security - EventData \Device\RaidPort3 0F00240001000000000000000B0004C002000000000000000000000000000000000000000000000001000000200004000B0004C0020000000000000000000000000000000000000004000000 ________________________________ Dados binários: Em Palavras 0000: 0024000F 00000001 00000000 C004000B 0008: 00000002 00000000 00000000 00000000 0010: 00000000 00000000 00000001 00040020 0018: C004000B 00000002 00000000 00000000 0020: 00000000 00000000 00000004 Em Bytes 0000: 0F 00 24 00 01 00 00 00 ..$..... 0008: 00 00 00 00 0B 00 04 C0 .......À 0010: 02 00 00 00 00 00 00 00 ........ 0018: 00 00 00 00 00 00 00 00 ........ 0020: 00 00 00 00 00 00 00 00 ........ 0028: 01 00 00 00 20 00 04 00 .... ... 0030: 0B 00 04 C0 02 00 00 00 ...À.... 0038: 00 00 00 00 00 00 00 00 ........ 0040: 00 00 00 00 00 00 00 00 ........ 0048: 04 00 00 00 .... This pages suggest it is a hardware problem tough it works fine on Linux: https://support.microsoft.com/en-us/kb/154690 Regards, Angelo Silva Brito. B.S. in Computer Engineering - UFPE Brazil http://about.me/angelobrito _________________________________________________ 2015-12-18 14:29 GMT-05:00 Iuliu Rus : > Last time this happened to us it was because the device was responding with > an IdentifyController structure which had no firmware_revision field and the > fields were padded with zeroes instead of spaces. Does your device get any > commands on the admin queue from windows? > > > On Fri, Dec 18, 2015 at 11:10 AM, Angelo Brito wrote: >> >> Hello All, >> >> I have a generic NVMe device that works perfectly on Linux but does >> not work on Windows. The device is recognized as a Default NVMe >> Controller with Microsoft as vendor but issue an error code 10: This >> device cannot start. I am aware that this is a generic error code and >> could mean any thing. >> >> I have started to debug from the device perspective and the Host CPU >> just writes the MSI configuration registers during startup. I use >> Altera´s PCIe Hard IP to implement the PCIe and my controller is >> hosted on FPGA. The device was never started. >> >> Someone can share any more leads to debug? Why windows doesn´t start my >> device? >> >> Regards, >> Angelo Silva Brito. >> B.S. in Computer Engineering - UFPE Brazil >> http://about.me/angelobrito >> _________________________________________________ >> _______________________________________________ >> nvmewin mailing list >> nvmewin at lists.openfabrics.org >> http://lists.openfabrics.org/mailman/listinfo/nvmewin > > Regards, Angelo Silva Brito. B.S. in Computer Engineering - UFPE Brazil http://about.me/angelobrito _________________________________________________ 2015-12-18 17:29 GMT-02:00 Iuliu Rus : > Last time this happened to us it was because the device was responding with > an IdentifyController structure which had no firmware_revision field and the > fields were padded with zeroes instead of spaces. Does your device get any > commands on the admin queue from windows? > > > On Fri, Dec 18, 2015 at 11:10 AM, Angelo Brito wrote: >> >> Hello All, >> >> I have a generic NVMe device that works perfectly on Linux but does >> not work on Windows. The device is recognized as a Default NVMe >> Controller with Microsoft as vendor but issue an error code 10: This >> device cannot start. I am aware that this is a generic error code and >> could mean any thing. >> >> I have started to debug from the device perspective and the Host CPU >> just writes the MSI configuration registers during startup. I use >> Altera´s PCIe Hard IP to implement the PCIe and my controller is >> hosted on FPGA. The device was never started. >> >> Someone can share any more leads to debug? Why windows doesn´t start my >> device? >> >> Regards, >> Angelo Silva Brito. >> B.S. in Computer Engineering - UFPE Brazil >> http://about.me/angelobrito >> _________________________________________________ >> _______________________________________________ >> nvmewin mailing list >> nvmewin at lists.openfabrics.org >> http://lists.openfabrics.org/mailman/listinfo/nvmewin > > Regards, Angelo Silva Brito. B.S. in Computer Engineering - UFPE Brazil http://about.me/angelobrito _________________________________________________ 2015-12-18 14:29 GMT-05:00 Iuliu Rus : > Last time this happened to us it was because the device was responding with > an IdentifyController structure which had no firmware_revision field and the > fields were padded with zeroes instead of spaces. Does your device get any > commands on the admin queue from windows? > > > On Fri, Dec 18, 2015 at 11:10 AM, Angelo Brito wrote: >> >> Hello All, >> >> I have a generic NVMe device that works perfectly on Linux but does >> not work on Windows. The device is recognized as a Default NVMe >> Controller with Microsoft as vendor but issue an error code 10: This >> device cannot start. I am aware that this is a generic error code and >> could mean any thing. >> >> I have started to debug from the device perspective and the Host CPU >> just writes the MSI configuration registers during startup. I use >> Altera´s PCIe Hard IP to implement the PCIe and my controller is >> hosted on FPGA. The device was never started. >> >> Someone can share any more leads to debug? Why windows doesn´t start my >> device? >> >> Regards, >> Angelo Silva Brito. >> B.S. in Computer Engineering - UFPE Brazil >> http://about.me/angelobrito >> _________________________________________________ >> _______________________________________________ >> nvmewin mailing list >> nvmewin at lists.openfabrics.org >> http://lists.openfabrics.org/mailman/listinfo/nvmewin > > From mikeb at bustrace.com Fri Dec 18 14:55:28 2015 From: mikeb at bustrace.com (Mike Berhan) Date: Fri, 18 Dec 2015 15:55:28 -0700 Subject: [nvmewin] Is NVMe Generic Devices supported? In-Reply-To: References: Message-ID: <009f01d139e7$31511100$93f33300$@bustrace.com> Since the NVMe driver source code is available, can you just build it and single step through the initialization sequence to see where it's failing? If not, perhaps the WPP tracing capability built into the OFA driver can be engaged. Mike -----Original Message----- From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Angelo Brito Sent: Friday, December 18, 2015 1:37 PM To: Iuliu Rus Cc: nvmewin Subject: Re: [nvmewin] Is NVMe Generic Devices supported? Hi Iuliu, I haven't seen any commands. No write were sent to my controller other than the MSIX configuration. Not even the Admin Queue's registers. I suspect that for some reason windows NVMe Driver is dropping off my controller after the PCIe configuration and windows events wasn't of much help. The events reported: - System - Provider [ Name] stornvme - EventID 11 [ Qualifiers] 49156 Level 2 Task 0 Keywords 0x80000000000000 - TimeCreated [ SystemTime] 2015-12-18T18:28:31.145251600Z EventRecordID 2443 Channel System Computer schenberg-PC Security - EventData \Device\RaidPort3 0F00240001000000000000000B0004C002000000000000000000000000000000000000000000000001000000200004000B0004C0020000000000000000000000000000000000000004000000 ________________________________ Dados binários: Em Palavras 0000: 0024000F 00000001 00000000 C004000B 0008: 00000002 00000000 00000000 00000000 0010: 00000000 00000000 00000001 00040020 0018: C004000B 00000002 00000000 00000000 0020: 00000000 00000000 00000004 Em Bytes 0000: 0F 00 24 00 01 00 00 00 ..$..... 0008: 00 00 00 00 0B 00 04 C0 .......À 0010: 02 00 00 00 00 00 00 00 ........ 0018: 00 00 00 00 00 00 00 00 ........ 0020: 00 00 00 00 00 00 00 00 ........ 0028: 01 00 00 00 20 00 04 00 .... ... 0030: 0B 00 04 C0 02 00 00 00 ...À.... 0038: 00 00 00 00 00 00 00 00 ........ 0040: 00 00 00 00 00 00 00 00 ........ 0048: 04 00 00 00 .... This pages suggest it is a hardware problem tough it works fine on Linux: https://support.microsoft.com/en-us/kb/154690 Regards, Angelo Silva Brito. B.S. in Computer Engineering - UFPE Brazil http://about.me/angelobrito _________________________________________________ 2015-12-18 14:29 GMT-05:00 Iuliu Rus : > Last time this happened to us it was because the device was responding > with an IdentifyController structure which had no firmware_revision > field and the fields were padded with zeroes instead of spaces. Does > your device get any commands on the admin queue from windows? > > > On Fri, Dec 18, 2015 at 11:10 AM, Angelo Brito wrote: >> >> Hello All, >> >> I have a generic NVMe device that works perfectly on Linux but does >> not work on Windows. The device is recognized as a Default NVMe >> Controller with Microsoft as vendor but issue an error code 10: This >> device cannot start. I am aware that this is a generic error code and >> could mean any thing. >> >> I have started to debug from the device perspective and the Host CPU >> just writes the MSI configuration registers during startup. I use >> Altera´s PCIe Hard IP to implement the PCIe and my controller is >> hosted on FPGA. The device was never started. >> >> Someone can share any more leads to debug? Why windows doesn´t start >> my device? >> >> Regards, >> Angelo Silva Brito. >> B.S. in Computer Engineering - UFPE Brazil >> http://about.me/angelobrito >> _________________________________________________ >> _______________________________________________ >> nvmewin mailing list >> nvmewin at lists.openfabrics.org >> http://lists.openfabrics.org/mailman/listinfo/nvmewin > > Regards, Angelo Silva Brito. B.S. in Computer Engineering - UFPE Brazil http://about.me/angelobrito _________________________________________________ 2015-12-18 17:29 GMT-02:00 Iuliu Rus : > Last time this happened to us it was because the device was responding > with an IdentifyController structure which had no firmware_revision > field and the fields were padded with zeroes instead of spaces. Does > your device get any commands on the admin queue from windows? > > > On Fri, Dec 18, 2015 at 11:10 AM, Angelo Brito wrote: >> >> Hello All, >> >> I have a generic NVMe device that works perfectly on Linux but does >> not work on Windows. The device is recognized as a Default NVMe >> Controller with Microsoft as vendor but issue an error code 10: This >> device cannot start. I am aware that this is a generic error code and >> could mean any thing. >> >> I have started to debug from the device perspective and the Host CPU >> just writes the MSI configuration registers during startup. I use >> Altera´s PCIe Hard IP to implement the PCIe and my controller is >> hosted on FPGA. The device was never started. >> >> Someone can share any more leads to debug? Why windows doesn´t start >> my device? >> >> Regards, >> Angelo Silva Brito. >> B.S. in Computer Engineering - UFPE Brazil >> http://about.me/angelobrito >> _________________________________________________ >> _______________________________________________ >> nvmewin mailing list >> nvmewin at lists.openfabrics.org >> http://lists.openfabrics.org/mailman/listinfo/nvmewin > > Regards, Angelo Silva Brito. B.S. in Computer Engineering - UFPE Brazil http://about.me/angelobrito _________________________________________________ 2015-12-18 14:29 GMT-05:00 Iuliu Rus : > Last time this happened to us it was because the device was responding > with an IdentifyController structure which had no firmware_revision > field and the fields were padded with zeroes instead of spaces. Does > your device get any commands on the admin queue from windows? > > > On Fri, Dec 18, 2015 at 11:10 AM, Angelo Brito wrote: >> >> Hello All, >> >> I have a generic NVMe device that works perfectly on Linux but does >> not work on Windows. The device is recognized as a Default NVMe >> Controller with Microsoft as vendor but issue an error code 10: This >> device cannot start. I am aware that this is a generic error code and >> could mean any thing. >> >> I have started to debug from the device perspective and the Host CPU >> just writes the MSI configuration registers during startup. I use >> Altera´s PCIe Hard IP to implement the PCIe and my controller is >> hosted on FPGA. The device was never started. >> >> Someone can share any more leads to debug? Why windows doesn´t start >> my device? >> >> Regards, >> Angelo Silva Brito. >> B.S. in Computer Engineering - UFPE Brazil >> http://about.me/angelobrito >> _________________________________________________ >> _______________________________________________ >> 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 asb at cin.ufpe.br Fri Dec 18 19:22:56 2015 From: asb at cin.ufpe.br (Angelo Brito) Date: Sat, 19 Dec 2015 00:22:56 -0300 Subject: [nvmewin] Is NVMe Generic Devices supported? In-Reply-To: <009f01d139e7$31511100$93f33300$@bustrace.com> References: <009f01d139e7$31511100$93f33300$@bustrace.com> Message-ID: Hi guys thanks for the feedbacks. I am using windows 7 so the available hot fix on Microsoft's site to add nvme driver natively is outdated. The driver version date is from 2006 (didn't knew NVMe Spec was that old). After the hot fix I downloaded and installed Release 1.4 from SVN and had to manually force the device driver to be Release 1.4 otherwise it was just using the stornvme from the hot fix. It works as a charm now! So is windows 7 updates going to receive new driver releases? Also 32bit SVN Release 1.4 reports driver version 1.3, is it ok? Thanks! Regards, Angelo Silva Brito. B.S. in Computer Engineering - UFPE Brazil http://about.me/angelobrito _________________________________________________ 2015-12-18 19:55 GMT-03:00 Mike Berhan : > Since the NVMe driver source code is available, can you just build it and single step through the initialization sequence to see where it's failing? If not, perhaps the WPP tracing capability built into the OFA driver can be engaged. > > Mike > > -----Original Message----- > From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Angelo Brito > Sent: Friday, December 18, 2015 1:37 PM > To: Iuliu Rus > Cc: nvmewin > Subject: Re: [nvmewin] Is NVMe Generic Devices supported? > > Hi Iuliu, > > I haven't seen any commands. No write were sent to my controller other than the MSIX configuration. Not even the Admin Queue's registers. I suspect that for some reason windows NVMe Driver is dropping off my controller after the PCIe configuration and windows events wasn't of much help. > The events reported: > - System > - Provider > [ Name] stornvme > - EventID 11 > [ Qualifiers] 49156 > Level 2 > Task 0 > Keywords 0x80000000000000 > - TimeCreated > [ SystemTime] 2015-12-18T18:28:31.145251600Z EventRecordID 2443 Channel System Computer schenberg-PC Security > - EventData > \Device\RaidPort3 > 0F00240001000000000000000B0004C002000000000000000000000000000000000000000000000001000000200004000B0004C0020000000000000000000000000000000000000004000000 > ________________________________ > > Dados binários: > > Em Palavras > > 0000: 0024000F 00000001 00000000 C004000B > 0008: 00000002 00000000 00000000 00000000 > 0010: 00000000 00000000 00000001 00040020 > 0018: C004000B 00000002 00000000 00000000 > 0020: 00000000 00000000 00000004 > > Em Bytes > > 0000: 0F 00 24 00 01 00 00 00 ..$..... > 0008: 00 00 00 00 0B 00 04 C0 .......À > 0010: 02 00 00 00 00 00 00 00 ........ > 0018: 00 00 00 00 00 00 00 00 ........ > 0020: 00 00 00 00 00 00 00 00 ........ > 0028: 01 00 00 00 20 00 04 00 .... ... > 0030: 0B 00 04 C0 02 00 00 00 ...À.... > 0038: 00 00 00 00 00 00 00 00 ........ > 0040: 00 00 00 00 00 00 00 00 ........ > 0048: 04 00 00 00 .... > > This pages suggest it is a hardware problem tough it works fine on Linux: > https://support.microsoft.com/en-us/kb/154690 > > Regards, > Angelo Silva Brito. > B.S. in Computer Engineering - UFPE Brazil http://about.me/angelobrito _________________________________________________ > > > 2015-12-18 14:29 GMT-05:00 Iuliu Rus : >> Last time this happened to us it was because the device was responding >> with an IdentifyController structure which had no firmware_revision >> field and the fields were padded with zeroes instead of spaces. Does >> your device get any commands on the admin queue from windows? >> >> >> On Fri, Dec 18, 2015 at 11:10 AM, Angelo Brito wrote: >>> >>> Hello All, >>> >>> I have a generic NVMe device that works perfectly on Linux but does >>> not work on Windows. The device is recognized as a Default NVMe >>> Controller with Microsoft as vendor but issue an error code 10: This >>> device cannot start. I am aware that this is a generic error code and >>> could mean any thing. >>> >>> I have started to debug from the device perspective and the Host CPU >>> just writes the MSI configuration registers during startup. I use >>> Altera´s PCIe Hard IP to implement the PCIe and my controller is >>> hosted on FPGA. The device was never started. >>> >>> Someone can share any more leads to debug? Why windows doesn´t start >>> my device? >>> >>> Regards, >>> Angelo Silva Brito. >>> B.S. in Computer Engineering - UFPE Brazil >>> http://about.me/angelobrito >>> _________________________________________________ >>> _______________________________________________ >>> nvmewin mailing list >>> nvmewin at lists.openfabrics.org >>> http://lists.openfabrics.org/mailman/listinfo/nvmewin >> >> > > > Regards, > Angelo Silva Brito. > B.S. in Computer Engineering - UFPE Brazil http://about.me/angelobrito _________________________________________________ > > > 2015-12-18 17:29 GMT-02:00 Iuliu Rus : >> Last time this happened to us it was because the device was responding >> with an IdentifyController structure which had no firmware_revision >> field and the fields were padded with zeroes instead of spaces. Does >> your device get any commands on the admin queue from windows? >> >> >> On Fri, Dec 18, 2015 at 11:10 AM, Angelo Brito wrote: >>> >>> Hello All, >>> >>> I have a generic NVMe device that works perfectly on Linux but does >>> not work on Windows. The device is recognized as a Default NVMe >>> Controller with Microsoft as vendor but issue an error code 10: This >>> device cannot start. I am aware that this is a generic error code and >>> could mean any thing. >>> >>> I have started to debug from the device perspective and the Host CPU >>> just writes the MSI configuration registers during startup. I use >>> Altera´s PCIe Hard IP to implement the PCIe and my controller is >>> hosted on FPGA. The device was never started. >>> >>> Someone can share any more leads to debug? Why windows doesn´t start >>> my device? >>> >>> Regards, >>> Angelo Silva Brito. >>> B.S. in Computer Engineering - UFPE Brazil >>> http://about.me/angelobrito >>> _________________________________________________ >>> _______________________________________________ >>> nvmewin mailing list >>> nvmewin at lists.openfabrics.org >>> http://lists.openfabrics.org/mailman/listinfo/nvmewin >> >> > > > Regards, > Angelo Silva Brito. > B.S. in Computer Engineering - UFPE Brazil http://about.me/angelobrito _________________________________________________ > > > 2015-12-18 14:29 GMT-05:00 Iuliu Rus : >> Last time this happened to us it was because the device was responding >> with an IdentifyController structure which had no firmware_revision >> field and the fields were padded with zeroes instead of spaces. Does >> your device get any commands on the admin queue from windows? >> >> >> On Fri, Dec 18, 2015 at 11:10 AM, Angelo Brito wrote: >>> >>> Hello All, >>> >>> I have a generic NVMe device that works perfectly on Linux but does >>> not work on Windows. The device is recognized as a Default NVMe >>> Controller with Microsoft as vendor but issue an error code 10: This >>> device cannot start. I am aware that this is a generic error code and >>> could mean any thing. >>> >>> I have started to debug from the device perspective and the Host CPU >>> just writes the MSI configuration registers during startup. I use >>> Altera´s PCIe Hard IP to implement the PCIe and my controller is >>> hosted on FPGA. The device was never started. >>> >>> Someone can share any more leads to debug? Why windows doesn´t start >>> my device? >>> >>> Regards, >>> Angelo Silva Brito. >>> B.S. in Computer Engineering - UFPE Brazil >>> http://about.me/angelobrito >>> _________________________________________________ >>> _______________________________________________ >>> 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 >