From Alex.Chang at idt.com Mon Mar 4 17:03:26 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Tue, 5 Mar 2013 01:03:26 +0000 Subject: [nvmewin] SCSI Translation Issues In-Reply-To: <49158E750348AA499168FD41D8898360611CA580@FMSMSX105.amr.corp.intel.com> References: <49158E750348AA499168FD41D8898360611CA580@FMSMSX105.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFDAE6D@corpmail1.na.ads.idt.com> Hi all, After reviewing the translation codes from SCSI to NVMe more carefully, it seems there are some potential issues we might want to address sooner than later: 1. We don't handle buffer over/under run cases for read/write commands. For example, when the number of LBAs coded in CDB requires larger buffer size than indicated in DataTransferLength of SRB, the driver needs to return Check Condition and proper status. In under-run case, driver needs to mark down the actual transfer size in DataTransferLength before completing the request back to Storport. 2. How do we handle the case when the number of LBAs coded in CDB is zero? I think the number of LBAs for read/write commands is 0's based defined in NVMe specification. Is it a valid case? 3. For Read6/Write6, there is only one byte (byte 4) in CDB to indicate the transfer length. When the value of byte 4 is zero, it indicates the number of LBAs to transfer is 256. In that case, what driver does is subtracting 1 from 0 and assigning 0xFFFF to DW12. Apparently, it's a known bug. I can fix the potential issues mentioned above. However, I need you inputs regarding how we are going to handle #2. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kwok.Kong at idt.com Tue Mar 5 17:59:47 2013 From: Kwok.Kong at idt.com (Kong, Kwok) Date: Wed, 6 Mar 2013 01:59:47 +0000 Subject: [nvmewin] SCSI Translation Issues In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFDAE6D@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D8898360611CA580@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFDAE6D@corpmail1.na.ads.idt.com> Message-ID: <05CD7821AE397547A01AC160FBC231474BC832F1@corpmail1.na.ads.idt.com> Alex, I think #1 and #3 are bugs in the driver and should be fixed according to your suggestion. I am ok for you to fix them. #2. CDB request 0 LBA. NVMe requires the number of LBA requested to be 0's. The minimum number of LBA requested is 1. A request of 0 LBA cannot be sent to a NVMe device. In my view, the driver should return "OK" status to the port driver immediately without any further processing when the number of LBA requested is 0. Since the request size is 0, the driver has completed the request with exactly 0 byte of data being transferred. (means no action is required). Any other opinion on what the driver should do when the number of LBA requested is 0 ? Would a SCSI expert please explain what the driver (or a SCSI device) is supposed to do when the number of request LBA is 0 ? Thanks -Kwok From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, March 04, 2013 5:03 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] SCSI Translation Issues Hi all, After reviewing the translation codes from SCSI to NVMe more carefully, it seems there are some potential issues we might want to address sooner than later: 1. We don't handle buffer over/under run cases for read/write commands. For example, when the number of LBAs coded in CDB requires larger buffer size than indicated in DataTransferLength of SRB, the driver needs to return Check Condition and proper status. In under-run case, driver needs to mark down the actual transfer size in DataTransferLength before completing the request back to Storport. 2. How do we handle the case when the number of LBAs coded in CDB is zero? I think the number of LBAs for read/write commands is 0's based defined in NVMe specification. Is it a valid case? 3. For Read6/Write6, there is only one byte (byte 4) in CDB to indicate the transfer length. When the value of byte 4 is zero, it indicates the number of LBAs to transfer is 256. In that case, what driver does is subtracting 1 from 0 and assigning 0xFFFF to DW12. Apparently, it's a known bug. I can fix the potential issues mentioned above. However, I need you inputs regarding how we are going to handle #2. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Tue Mar 5 19:02:04 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Wed, 6 Mar 2013 03:02:04 +0000 Subject: [nvmewin] SCSI Translation Issues In-Reply-To: <05CD7821AE397547A01AC160FBC231474BC832F1@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D8898360611CA580@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFDAE6D@corpmail1.na.ads.idt.com>, <05CD7821AE397547A01AC160FBC231474BC832F1@corpmail1.na.ads.idt.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFDBFBA@corpmail1.na.ads.idt.com> Sure. I will go ahead fix them and let's see if anyone have different ideas about #2... Thanks, Alex ________________________________ From: Kong, Kwok Sent: Tuesday, March 05, 2013 5:59 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: SCSI Translation Issues Alex, I think #1 and #3 are bugs in the driver and should be fixed according to your suggestion. I am ok for you to fix them. #2. CDB request 0 LBA. NVMe requires the number of LBA requested to be 0’s. The minimum number of LBA requested is 1. A request of 0 LBA cannot be sent to a NVMe device. In my view, the driver should return “OK” status to the port driver immediately without any further processing when the number of LBA requested is 0. Since the request size is 0, the driver has completed the request with exactly 0 byte of data being transferred. (means no action is required). Any other opinion on what the driver should do when the number of LBA requested is 0 ? Would a SCSI expert please explain what the driver (or a SCSI device) is supposed to do when the number of request LBA is 0 ? Thanks -Kwok From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, March 04, 2013 5:03 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] SCSI Translation Issues Hi all, After reviewing the translation codes from SCSI to NVMe more carefully, it seems there are some potential issues we might want to address sooner than later: 1. We don't handle buffer over/under run cases for read/write commands. For example, when the number of LBAs coded in CDB requires larger buffer size than indicated in DataTransferLength of SRB, the driver needs to return Check Condition and proper status. In under-run case, driver needs to mark down the actual transfer size in DataTransferLength before completing the request back to Storport. 2. How do we handle the case when the number of LBAs coded in CDB is zero? I think the number of LBAs for read/write commands is 0's based defined in NVMe specification. Is it a valid case? 3. For Read6/Write6, there is only one byte (byte 4) in CDB to indicate the transfer length. When the value of byte 4 is zero, it indicates the number of LBAs to transfer is 256. In that case, what driver does is subtracting 1 from 0 and assigning 0xFFFF to DW12. Apparently, it's a known bug. I can fix the potential issues mentioned above. However, I need you inputs regarding how we are going to handle #2. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.c.robles at intel.com Tue Mar 5 19:37:37 2013 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Wed, 6 Mar 2013 03:37:37 +0000 Subject: [nvmewin] SCSI Translation Issues In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFDBFBA@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D8898360611CA580@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFDAE6D@corpmail1.na.ads.idt.com>, <05CD7821AE397547A01AC160FBC231474BC832F1@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFDBFBA@corpmail1.na.ads.idt.com> Message-ID: <49158E750348AA499168FD41D8898360611D92FA@FMSMSX105.amr.corp.intel.com> Alex/Kwok, For READ 6, a zero transfer length indicates 256 LBAs must be read. For READ 10/12/16/32, the SBC-3 spec states that a zero transfer length field "specifies that no logical blocks shall be read. This condition shall not be considered an error...". The correct behavior is to return a no data for the READ and return SRB_STATUS_SUCCESS for the SCSI READ request. For WRITEs, the behavior is the same (only no data is transferred to the device). In either case, the SRB is completed successfully. [cid:image003.jpg at 01CE19E1.41893490] To answer Alex's question, in this case of a zero transfer length for READ/WRITE (other than READ 6 and WRITE 6), this is a valid case, there should be no NVMe command sent to the device (SCSI target), and the SRB should complete successfully. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Tuesday, March 05, 2013 8:02 PM To: Kong, Kwok; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] SCSI Translation Issues Sure. I will go ahead fix them and let's see if anyone have different ideas about #2... Thanks, Alex ________________________________ From: Kong, Kwok Sent: Tuesday, March 05, 2013 5:59 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: SCSI Translation Issues Alex, I think #1 and #3 are bugs in the driver and should be fixed according to your suggestion. I am ok for you to fix them. #2. CDB request 0 LBA. NVMe requires the number of LBA requested to be 0's. The minimum number of LBA requested is 1. A request of 0 LBA cannot be sent to a NVMe device. In my view, the driver should return "OK" status to the port driver immediately without any further processing when the number of LBA requested is 0. Since the request size is 0, the driver has completed the request with exactly 0 byte of data being transferred. (means no action is required). Any other opinion on what the driver should do when the number of LBA requested is 0 ? Would a SCSI expert please explain what the driver (or a SCSI device) is supposed to do when the number of request LBA is 0 ? Thanks -Kwok From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, March 04, 2013 5:03 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] SCSI Translation Issues Hi all, After reviewing the translation codes from SCSI to NVMe more carefully, it seems there are some potential issues we might want to address sooner than later: 1. We don't handle buffer over/under run cases for read/write commands. For example, when the number of LBAs coded in CDB requires larger buffer size than indicated in DataTransferLength of SRB, the driver needs to return Check Condition and proper status. In under-run case, driver needs to mark down the actual transfer size in DataTransferLength before completing the request back to Storport. 2. How do we handle the case when the number of LBAs coded in CDB is zero? I think the number of LBAs for read/write commands is 0's based defined in NVMe specification. Is it a valid case? 3. For Read6/Write6, there is only one byte (byte 4) in CDB to indicate the transfer length. When the value of byte 4 is zero, it indicates the number of LBAs to transfer is 256. In that case, what driver does is subtracting 1 from 0 and assigning 0xFFFF to DW12. Apparently, it's a known bug. I can fix the potential issues mentioned above. However, I need you inputs regarding how we are going to handle #2. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 29048 bytes Desc: image003.jpg URL: From judy.brock at ssi.samsung.com Tue Mar 5 20:08:53 2013 From: judy.brock at ssi.samsung.com (Judy Brock-SSI) Date: Wed, 6 Mar 2013 04:08:53 +0000 Subject: [nvmewin] SCSI Translation Issues In-Reply-To: <05CD7821AE397547A01AC160FBC231474BC832F1@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D8898360611CA580@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFDAE6D@corpmail1.na.ads.idt.com> <05CD7821AE397547A01AC160FBC231474BC832F1@corpmail1.na.ads.idt.com> Message-ID: <36E8D38D6B771A4BBDB1C0D800158A512FBA22E3@SSIEXCH-MB2.ssi.samsung.com> I agree with Kwok regarding how to translate #2 below. For SCSI, requesting a transfer of zero LBAs is not considered an error - it just means no LBAs will be transferred. Mapping this to simply returning 'OK' status for NVMe is the functional equivalent. Judy From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Kong, Kwok Sent: Tuesday, March 05, 2013 6:00 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] SCSI Translation Issues Alex, I think #1 and #3 are bugs in the driver and should be fixed according to your suggestion. I am ok for you to fix them. #2. CDB request 0 LBA. NVMe requires the number of LBA requested to be 0's. The minimum number of LBA requested is 1. A request of 0 LBA cannot be sent to a NVMe device. In my view, the driver should return "OK" status to the port driver immediately without any further processing when the number of LBA requested is 0. Since the request size is 0, the driver has completed the request with exactly 0 byte of data being transferred. (means no action is required). Any other opinion on what the driver should do when the number of LBA requested is 0 ? Would a SCSI expert please explain what the driver (or a SCSI device) is supposed to do when the number of request LBA is 0 ? Thanks -Kwok From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, March 04, 2013 5:03 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] SCSI Translation Issues Hi all, After reviewing the translation codes from SCSI to NVMe more carefully, it seems there are some potential issues we might want to address sooner than later: 1. We don't handle buffer over/under run cases for read/write commands. For example, when the number of LBAs coded in CDB requires larger buffer size than indicated in DataTransferLength of SRB, the driver needs to return Check Condition and proper status. In under-run case, driver needs to mark down the actual transfer size in DataTransferLength before completing the request back to Storport. 2. How do we handle the case when the number of LBAs coded in CDB is zero? I think the number of LBAs for read/write commands is 0's based defined in NVMe specification. Is it a valid case? 3. For Read6/Write6, there is only one byte (byte 4) in CDB to indicate the transfer length. When the value of byte 4 is zero, it indicates the number of LBAs to transfer is 256. In that case, what driver does is subtracting 1 from 0 and assigning 0xFFFF to DW12. Apparently, it's a known bug. I can fix the potential issues mentioned above. However, I need you inputs regarding how we are going to handle #2. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From judy.brock at ssi.samsung.com Tue Mar 5 20:23:45 2013 From: judy.brock at ssi.samsung.com (Judy Brock-SSI) Date: Wed, 6 Mar 2013 04:23:45 +0000 Subject: [nvmewin] SCSI Translation Issues In-Reply-To: <36E8D38D6B771A4BBDB1C0D800158A512FBA22E3@SSIEXCH-MB2.ssi.samsung.com> References: <49158E750348AA499168FD41D8898360611CA580@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFDAE6D@corpmail1.na.ads.idt.com> <05CD7821AE397547A01AC160FBC231474BC832F1@corpmail1.na.ads.idt.com> <36E8D38D6B771A4BBDB1C0D800158A512FBA22E3@SSIEXCH-MB2.ssi.samsung.com> Message-ID: <36E8D38D6B771A4BBDB1C0D800158A512FBA230F@SSIEXCH-MB2.ssi.samsung.com> Sorry, sent this before reading Ray's much more complete response :) From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Judy Brock-SSI Sent: Tuesday, March 05, 2013 8:09 PM To: Kong, Kwok; Chang, Alex; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] SCSI Translation Issues I agree with Kwok regarding how to translate #2 below. For SCSI, requesting a transfer of zero LBAs is not considered an error - it just means no LBAs will be transferred. Mapping this to simply returning 'OK' status for NVMe is the functional equivalent. Judy From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Kong, Kwok Sent: Tuesday, March 05, 2013 6:00 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] SCSI Translation Issues Alex, I think #1 and #3 are bugs in the driver and should be fixed according to your suggestion. I am ok for you to fix them. #2. CDB request 0 LBA. NVMe requires the number of LBA requested to be 0's. The minimum number of LBA requested is 1. A request of 0 LBA cannot be sent to a NVMe device. In my view, the driver should return "OK" status to the port driver immediately without any further processing when the number of LBA requested is 0. Since the request size is 0, the driver has completed the request with exactly 0 byte of data being transferred. (means no action is required). Any other opinion on what the driver should do when the number of LBA requested is 0 ? Would a SCSI expert please explain what the driver (or a SCSI device) is supposed to do when the number of request LBA is 0 ? Thanks -Kwok From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, March 04, 2013 5:03 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] SCSI Translation Issues Hi all, After reviewing the translation codes from SCSI to NVMe more carefully, it seems there are some potential issues we might want to address sooner than later: 1. We don't handle buffer over/under run cases for read/write commands. For example, when the number of LBAs coded in CDB requires larger buffer size than indicated in DataTransferLength of SRB, the driver needs to return Check Condition and proper status. In under-run case, driver needs to mark down the actual transfer size in DataTransferLength before completing the request back to Storport. 2. How do we handle the case when the number of LBAs coded in CDB is zero? I think the number of LBAs for read/write commands is 0's based defined in NVMe specification. Is it a valid case? 3. For Read6/Write6, there is only one byte (byte 4) in CDB to indicate the transfer length. When the value of byte 4 is zero, it indicates the number of LBAs to transfer is 256. In that case, what driver does is subtracting 1 from 0 and assigning 0xFFFF to DW12. Apparently, it's a known bug. I can fix the potential issues mentioned above. However, I need you inputs regarding how we are going to handle #2. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From vishal.l.verma at intel.com Wed Mar 6 10:21:08 2013 From: vishal.l.verma at intel.com (Verma, Vishal L) Date: Wed, 6 Mar 2013 18:21:08 +0000 Subject: [nvmewin] SCSI Translation Issues In-Reply-To: <49158E750348AA499168FD41D8898360611D92FA@FMSMSX105.amr.corp.intel.com> Message-ID: For what its worth, the translation in the Linux driver follows whad Kwok and Ray said. #1: Overruns and Underruns are both errored out. If we receive a condition like this, it says that the host application has got the LBA size wrong, and needs to be notified. #2/#3: If it is a CDB-6 command, then transfer 256 blocks. Else return success at the driver level. No NVMe commands are sent. Thanks, -Vishal From: , Raymond C Robles > Date: Tuesday, March 5, 2013 8:37 PM To: "Chang, Alex" >, "Kong, Kwok" >, "nvmewin at lists.openfabrics.org" > Subject: Re: [nvmewin] SCSI Translation Issues Alex/Kwok, For READ 6, a zero transfer length indicates 256 LBAs must be read. For READ 10/12/16/32, the SBC-3 spec states that a zero transfer length field “specifies that no logical blocks shall be read. This condition shall not be considered an error…”. The correct behavior is to return a no data for the READ and return SRB_STATUS_SUCCESS for the SCSI READ request. For WRITEs, the behavior is the same (only no data is transferred to the device). In either case, the SRB is completed successfully. [cid:image003.jpg at 01CE19E1.41893490] To answer Alex’s question, in this case of a zero transfer length for READ/WRITE (other than READ 6 and WRITE 6), this is a valid case, there should be no NVMe command sent to the device (SCSI target), and the SRB should complete successfully. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Tuesday, March 05, 2013 8:02 PM To: Kong, Kwok; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] SCSI Translation Issues Sure. I will go ahead fix them and let's see if anyone have different ideas about #2... Thanks, Alex ________________________________ From: Kong, Kwok Sent: Tuesday, March 05, 2013 5:59 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: SCSI Translation Issues Alex, I think #1 and #3 are bugs in the driver and should be fixed according to your suggestion. I am ok for you to fix them. #2. CDB request 0 LBA. NVMe requires the number of LBA requested to be 0’s. The minimum number of LBA requested is 1. A request of 0 LBA cannot be sent to a NVMe device. In my view, the driver should return “OK” status to the port driver immediately without any further processing when the number of LBA requested is 0. Since the request size is 0, the driver has completed the request with exactly 0 byte of data being transferred. (means no action is required). Any other opinion on what the driver should do when the number of LBA requested is 0 ? Would a SCSI expert please explain what the driver (or a SCSI device) is supposed to do when the number of request LBA is 0 ? Thanks -Kwok From:nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, March 04, 2013 5:03 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] SCSI Translation Issues Hi all, After reviewing the translation codes from SCSI to NVMe more carefully, it seems there are some potential issues we might want to address sooner than later: 1. We don't handle buffer over/under run cases for read/write commands. For example, when the number of LBAs coded in CDB requires larger buffer size than indicated in DataTransferLength of SRB, the driver needs to return Check Condition and proper status. In under-run case, driver needs to mark down the actual transfer size in DataTransferLength before completing the request back to Storport. 2. How do we handle the case when the number of LBAs coded in CDB is zero? I think the number of LBAs for read/write commands is 0's based defined in NVMe specification. Is it a valid case? 3. For Read6/Write6, there is only one byte (byte 4) in CDB to indicate the transfer length. When the value of byte 4 is zero, it indicates the number of LBAs to transfer is 256. In that case, what driver does is subtracting 1 from 0 and assigning 0xFFFF to DW12. Apparently, it's a known bug. I can fix the potential issues mentioned above. However, I need you inputs regarding how we are going to handle #2. Thanks, Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 29048 bytes Desc: image003.jpg URL: From Kwok.Kong at idt.com Wed Mar 6 10:27:20 2013 From: Kwok.Kong at idt.com (Kong, Kwok) Date: Wed, 6 Mar 2013 18:27:20 +0000 Subject: [nvmewin] SCSI Translation Issues In-Reply-To: References: <49158E750348AA499168FD41D8898360611D92FA@FMSMSX105.amr.corp.intel.com> Message-ID: <05CD7821AE397547A01AC160FBC231474BC83850@corpmail1.na.ads.idt.com> Vishal, This is useful. It is good to know that we are consistent on this. Thanks -Kwok -----Original Message----- From: Verma, Vishal L [mailto:vishal.l.verma at intel.com] Sent: Wednesday, March 06, 2013 10:21 AM To: Robles, Raymond C; Chang, Alex; Kong, Kwok; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] SCSI Translation Issues For what its worth, the translation in the Linux driver follows whad Kwok and Ray said. #1: Overruns and Underruns are both errored out. If we receive a condition like this, it says that the host application has got the LBA size wrong, and needs to be notified. #2/#3: If it is a CDB-6 command, then transfer 256 blocks. Else return success at the driver level. No NVMe commands are sent. Thanks, -Vishal From: , Raymond C Robles > Date: Tuesday, March 5, 2013 8:37 PM To: "Chang, Alex" >, "Kong, Kwok" >, "nvmewin at lists.openfabrics.org" > Subject: Re: [nvmewin] SCSI Translation Issues Alex/Kwok, For READ 6, a zero transfer length indicates 256 LBAs must be read. For READ 10/12/16/32, the SBC-3 spec states that a zero transfer length field "specifies that no logical blocks shall be read. This condition shall not be considered an error...". The correct behavior is to return a no data for the READ and return SRB_STATUS_SUCCESS for the SCSI READ request. For WRITEs, the behavior is the same (only no data is transferred to the device). In either case, the SRB is completed successfully. [cid:image003.jpg at 01CE19E1.41893490] To answer Alex's question, in this case of a zero transfer length for READ/WRITE (other than READ 6 and WRITE 6), this is a valid case, there should be no NVMe command sent to the device (SCSI target), and the SRB should complete successfully. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Tuesday, March 05, 2013 8:02 PM To: Kong, Kwok; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] SCSI Translation Issues Sure. I will go ahead fix them and let's see if anyone have different ideas about #2... Thanks, Alex ________________________________ From: Kong, Kwok Sent: Tuesday, March 05, 2013 5:59 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: SCSI Translation Issues Alex, I think #1 and #3 are bugs in the driver and should be fixed according to your suggestion. I am ok for you to fix them. #2. CDB request 0 LBA. NVMe requires the number of LBA requested to be 0's. The minimum number of LBA requested is 1. A request of 0 LBA cannot be sent to a NVMe device. In my view, the driver should return "OK" status to the port driver immediately without any further processing when the number of LBA requested is 0. Since the request size is 0, the driver has completed the request with exactly 0 byte of data being transferred. (means no action is required). Any other opinion on what the driver should do when the number of LBA requested is 0 ? Would a SCSI expert please explain what the driver (or a SCSI device) is supposed to do when the number of request LBA is 0 ? Thanks -Kwok From:nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, March 04, 2013 5:03 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] SCSI Translation Issues Hi all, After reviewing the translation codes from SCSI to NVMe more carefully, it seems there are some potential issues we might want to address sooner than later: 1. We don't handle buffer over/under run cases for read/write commands. For example, when the number of LBAs coded in CDB requires larger buffer size than indicated in DataTransferLength of SRB, the driver needs to return Check Condition and proper status. In under-run case, driver needs to mark down the actual transfer size in DataTransferLength before completing the request back to Storport. 2. How do we handle the case when the number of LBAs coded in CDB is zero? I think the number of LBAs for read/write commands is 0's based defined in NVMe specification. Is it a valid case? 3. For Read6/Write6, there is only one byte (byte 4) in CDB to indicate the transfer length. When the value of byte 4 is zero, it indicates the number of LBAs to transfer is 256. In that case, what driver does is subtracting 1 from 0 and assigning 0xFFFF to DW12. Apparently, it's a known bug. I can fix the potential issues mentioned above. However, I need you inputs regarding how we are going to handle #2. Thanks, Alex From Kwok.Kong at idt.com Thu Mar 7 16:12:40 2013 From: Kwok.Kong at idt.com (Kong, Kwok) Date: Fri, 8 Mar 2013 00:12:40 +0000 Subject: [nvmewin] Meta Data check in the driver initialization Message-ID: <05CD7821AE397547A01AC160FBC231474BC83E47@corpmail1.na.ads.idt.com> All, The current driver does not check for Metadata size in the Identify Namespace LBA Format. It assumes that the metadata size is always 0. This is a bug in the driver and should be fixed. The fix should be similar to the following: - During initialization, the driver sends identify namespace to a NVMe device to discover the namespace configuration (Namespace size, capacity, LBA data size ...etc). - If the Metadata size (MS) in the Identify - LBA Format Data structure is not 0, Ignore this namespace and don't advertise it to Windows. - Otherwise Do the normal initialization as we are doing currently When a namespace is formatted with non-zero metadata size, the Metadata Pointer (MPTR) is assumed to point to a valid metadata buffer. Since the current driver does not support meta-data, the metadata pointer is not set up to point to a valid buffer. The driver cannot use this namespace and must skip it. Please let me know if you disagree. Otherwise, I'll ask Alex to put in the fix. Thanks -Kwok -------------- next part -------------- An HTML attachment was scrubbed... URL: From ngalbo at micron.com Mon Mar 11 10:54:35 2013 From: ngalbo at micron.com (Neal Galbo (ngalbo)) Date: Mon, 11 Mar 2013 17:54:35 +0000 Subject: [nvmewin] SCSI Translation Issues In-Reply-To: <36E8D38D6B771A4BBDB1C0D800158A512FBA22E3@SSIEXCH-MB2.ssi.samsung.com> References: <49158E750348AA499168FD41D8898360611CA580@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFDAE6D@corpmail1.na.ads.idt.com> <05CD7821AE397547A01AC160FBC231474BC832F1@corpmail1.na.ads.idt.com> <36E8D38D6B771A4BBDB1C0D800158A512FBA22E3@SSIEXCH-MB2.ssi.samsung.com> Message-ID: <5E6652408D93274292C8F06C9A4A26007195AF84@NTXBOIMBX05.micron.com> Better late, then never. è Would a SCSI expert please explain what the driver (or a SCSI device) is supposed to do when the number of request LBA is 0 ? Depends upon the command. With SCSI READ/WRITE 6 command, a zero value means transfer 256 LBA's. For READ/WRITE (10, 12,16,32) the specs say the following: A TRANSFER LENGTH field set to zero specifies that no logical blocks shall be read. This condition shall not be considered an error. ... meaning the command completes successfully; just no data is transferred, as Judy mentioned. A zero transfer length is common in loops of read/write commands where the remaining LBA transfer length is calculated and where the test for loop termination is done AFTER the command has been sent. SCSI programmers expect this behavior for zero length transfers. -Neal From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Judy Brock-SSI Sent: Tuesday, March 05, 2013 11:09 PM To: Kong, Kwok; Chang, Alex; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] SCSI Translation Issues I agree with Kwok regarding how to translate #2 below. For SCSI, requesting a transfer of zero LBAs is not considered an error - it just means no LBAs will be transferred. Mapping this to simply returning 'OK' status for NVMe is the functional equivalent. Judy From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Kong, Kwok Sent: Tuesday, March 05, 2013 6:00 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] SCSI Translation Issues Alex, I think #1 and #3 are bugs in the driver and should be fixed according to your suggestion. I am ok for you to fix them. #2. CDB request 0 LBA. NVMe requires the number of LBA requested to be 0's. The minimum number of LBA requested is 1. A request of 0 LBA cannot be sent to a NVMe device. In my view, the driver should return "OK" status to the port driver immediately without any further processing when the number of LBA requested is 0. Since the request size is 0, the driver has completed the request with exactly 0 byte of data being transferred. (means no action is required). Any other opinion on what the driver should do when the number of LBA requested is 0 ? Would a SCSI expert please explain what the driver (or a SCSI device) is supposed to do when the number of request LBA is 0 ? Thanks -Kwok From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, March 04, 2013 5:03 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] SCSI Translation Issues Hi all, After reviewing the translation codes from SCSI to NVMe more carefully, it seems there are some potential issues we might want to address sooner than later: 1. We don't handle buffer over/under run cases for read/write commands. For example, when the number of LBAs coded in CDB requires larger buffer size than indicated in DataTransferLength of SRB, the driver needs to return Check Condition and proper status. In under-run case, driver needs to mark down the actual transfer size in DataTransferLength before completing the request back to Storport. 2. How do we handle the case when the number of LBAs coded in CDB is zero? I think the number of LBAs for read/write commands is 0's based defined in NVMe specification. Is it a valid case? 3. For Read6/Write6, there is only one byte (byte 4) in CDB to indicate the transfer length. When the value of byte 4 is zero, it indicates the number of LBAs to transfer is 256. In that case, what driver does is subtracting 1 from 0 and assigning 0xFFFF to DW12. Apparently, it's a known bug. I can fix the potential issues mentioned above. However, I need you inputs regarding how we are going to handle #2. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Mon Mar 11 11:21:06 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Mon, 11 Mar 2013 18:21:06 +0000 Subject: [nvmewin] SCSI Translation Issues In-Reply-To: <5E6652408D93274292C8F06C9A4A26007195AF84@NTXBOIMBX05.micron.com> References: <49158E750348AA499168FD41D8898360611CA580@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFDAE6D@corpmail1.na.ads.idt.com> <05CD7821AE397547A01AC160FBC231474BC832F1@corpmail1.na.ads.idt.com> <36E8D38D6B771A4BBDB1C0D800158A512FBA22E3@SSIEXCH-MB2.ssi.samsung.com> <5E6652408D93274292C8F06C9A4A26007195AF84@NTXBOIMBX05.micron.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFDD300@corpmail1.na.ads.idt.com> Thanks a lot, Neal, for your feedback. Regards, Alex ________________________________ From: Neal Galbo (ngalbo) [mailto:ngalbo at micron.com] Sent: Monday, March 11, 2013 10:55 AM To: Judy Brock-SSI; Kong, Kwok; Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: SCSI Translation Issues Better late, then never. è Would a SCSI expert please explain what the driver (or a SCSI device) is supposed to do when the number of request LBA is 0 ? Depends upon the command. With SCSI READ/WRITE 6 command, a zero value means transfer 256 LBA's. For READ/WRITE (10, 12,16,32) the specs say the following: A TRANSFER LENGTH field set to zero specifies that no logical blocks shall be read. This condition shall not be considered an error. ... meaning the command completes successfully; just no data is transferred, as Judy mentioned. A zero transfer length is common in loops of read/write commands where the remaining LBA transfer length is calculated and where the test for loop termination is done AFTER the command has been sent. SCSI programmers expect this behavior for zero length transfers. -Neal From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Judy Brock-SSI Sent: Tuesday, March 05, 2013 11:09 PM To: Kong, Kwok; Chang, Alex; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] SCSI Translation Issues I agree with Kwok regarding how to translate #2 below. For SCSI, requesting a transfer of zero LBAs is not considered an error - it just means no LBAs will be transferred. Mapping this to simply returning 'OK' status for NVMe is the functional equivalent. Judy From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Kong, Kwok Sent: Tuesday, March 05, 2013 6:00 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] SCSI Translation Issues Alex, I think #1 and #3 are bugs in the driver and should be fixed according to your suggestion. I am ok for you to fix them. #2. CDB request 0 LBA. NVMe requires the number of LBA requested to be 0's. The minimum number of LBA requested is 1. A request of 0 LBA cannot be sent to a NVMe device. In my view, the driver should return "OK" status to the port driver immediately without any further processing when the number of LBA requested is 0. Since the request size is 0, the driver has completed the request with exactly 0 byte of data being transferred. (means no action is required). Any other opinion on what the driver should do when the number of LBA requested is 0 ? Would a SCSI expert please explain what the driver (or a SCSI device) is supposed to do when the number of request LBA is 0 ? Thanks -Kwok From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, March 04, 2013 5:03 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] SCSI Translation Issues Hi all, After reviewing the translation codes from SCSI to NVMe more carefully, it seems there are some potential issues we might want to address sooner than later: 1. We don't handle buffer over/under run cases for read/write commands. For example, when the number of LBAs coded in CDB requires larger buffer size than indicated in DataTransferLength of SRB, the driver needs to return Check Condition and proper status. In under-run case, driver needs to mark down the actual transfer size in DataTransferLength before completing the request back to Storport. 2. How do we handle the case when the number of LBAs coded in CDB is zero? I think the number of LBAs for read/write commands is 0's based defined in NVMe specification. Is it a valid case? 3. For Read6/Write6, there is only one byte (byte 4) in CDB to indicate the transfer length. When the value of byte 4 is zero, it indicates the number of LBAs to transfer is 256. In that case, what driver does is subtracting 1 from 0 and assigning 0xFFFF to DW12. Apparently, it's a known bug. I can fix the potential issues mentioned above. However, I need you inputs regarding how we are going to handle #2. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Fri Mar 15 12:08:52 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Fri, 15 Mar 2013 19:08:52 +0000 Subject: [nvmewin] New Patch From IDT In-Reply-To: <5E6652408D93274292C8F06C9A4A26007195AF84@NTXBOIMBX05.micron.com> References: <49158E750348AA499168FD41D8898360611CA580@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFDAE6D@corpmail1.na.ads.idt.com> <05CD7821AE397547A01AC160FBC231474BC832F1@corpmail1.na.ads.idt.com> <36E8D38D6B771A4BBDB1C0D800158A512FBA22E3@SSIEXCH-MB2.ssi.samsung.com> <5E6652408D93274292C8F06C9A4A26007195AF84@NTXBOIMBX05.micron.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFDD847@corpmail1.na.ads.idt.com> Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeinit.c and nvmestat.c - When Metadata is enabled, the associated drive is not visible to the host to avoid system crash when processing Read/Write commands. 2. In nvmesnti.c, nvmesnti.h and nvmesntitypes.h - Added handling zero length in Read/Write commands except Read6/Write6. - Added handling buffer over-run/under-run for Read/Write commands. - Fixed Read6/Write6 zero length bug in CDB. 3. In nvmestd.c - Fixed system crash issue when LunExtensionTable is not allocated and requests hit NVMeBuildIo. It happens when driver is not initialized successfully. Please review the changes and provide feedbacks if you have any. If nobody disagrees with the changes, I will remind Ray to merge them in two weeks. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: source_idt_031513.zip Type: application/x-zip-compressed Size: 165117 bytes Desc: source_idt_031513.zip URL: From raymond.c.robles at intel.com Thu Mar 21 13:17:44 2013 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Thu, 21 Mar 2013 20:17:44 +0000 Subject: [nvmewin] NVMe 1.1 : Clarification on PRP2 Entry list In-Reply-To: <05CD7821AE397547A01AC160FBC231474BC89737@corpmail1.na.ads.idt.com> References: <05CD7821AE397547A01AC160FBC231474BC89737@corpmail1.na.ads.idt.com> Message-ID: <49158E750348AA499168FD41D889836061B8BC7C@FMSMSX105.amr.corp.intel.com> Hi Santosh, I am one of the original authors of the OFA Windows NVMe driver (sorry, I'm late to this thread). What do you believe is the problem? The Windows OFA driver constructs PRP lists per the NVMe spec. We've run for several days with numerous data integrity testing tools (without error). Do you believe that the PRP list is incorrectly constructed? Based on the screen shot you sent out, the second PRP entry in the submission queue entry points to a PRP list... it should not contain the 2nd PRP entry. This is per the NVMe spec. Thanks, Ray From: Kong, Kwok [mailto:Kwok.Kong at idt.com] Sent: Thursday, March 21, 2013 11:14 AM To: santosh.s2 at samsung.com Cc: technical at nvmexpress.org; Onufryk, Peter; Wilcox, Matthew R Subject: RE: RE: RE: NVMe 1.1 : Clarification on PRP2 Entry list Santosh, The specification is very clear on how the PRP list should be constructed. If you see a problem with any driver, then it is a driver problem and not a specification problem. Please send your question to nvmewin at lists.openfabrics.org if you believe there is a driver bug. What is the LBA size for your testing ? 512B or 4KB ? Thanks -Kwok From: SANTOSH SINGH [mailto:santosh.s2 at samsung.com] Sent: Thursday, March 21, 2013 3:55 AM To: Kong, Kwok Cc: technical at nvmexpress.org; Onufryk, Peter; 'Wilcox, Matthew R' Subject: Re: RE: RE: NVMe 1.1 : Clarification on PRP2 Entry list Sorry some how the attachement is missing. Resending. [cid:image001.png at 01CE2635.EFEEF460] Regards Santosh ------- Original Message ------- Sender : SANTOSH SINGH> Senior Chief Engineer/SRI-Bangalore-SSD Solutions/Samsung Electronics Date : Mar 21, 2013 19:45 (GMT+09:00) Title : RE: RE: NVMe 1.1 : Clarification on PRP2 Entry list Hi Kwok, I got the scenario reproduced again, while issuing the FS format command. Following are the debug details. Page size 4k Data Transfer size was 16 LBA PRP1 Entry 0x3e8fd060 PRP2 Entry list 0xbe166ff0 Total no. of PRP entries 17 The 16 PRP entries should fit in single page. But the PRP2 offset 0xbe166ff0(PRP2) is not correct and it has run off the page(from 0xbe166ff0 to 0xbe167000) which is the next page in continuity. Attached is the snapshot of the debug window for the detailed analysis. Regards Santosh -----Original Message----- From: Kong, Kwok [mailto:Kwok.Kong at idt.com] Sent: Thursday, March 21, 2013 1:22 AM To: Wilcox, Matthew R; santosh.s2 at samsung.com Cc: Onufryk, Peter; technical at nvmexpress.org Subject: RE: RE: NVMe 1.1 : Clarification on PRP2 Entry list Santosh, Your verification on the OFA driver that it uses PRP list format as in figure 2 is incorrect. The OFA driver does neither figure 1, nor figure 2. By default, the max request size that the mini-port supports is 128KB. If the request size is bigger than 128KB, the port driver sends multiple 128KB requests to the OFA mini-port driver. The OFA mini-port driver pre-allocates the PRP list buffers during initialization. The PRP entries (a max of 32 entries for 128KB request size) never run off the end of a page as shown in figure 1 or figure 2. All PRP entries are guaranteed to fit within a single Memory Page. Thanks -Kwok -----Original Message----- From: Wilcox, Matthew R [mailto:matthew.r.wilcox at intel.com] Sent: Wednesday, March 20, 2013 8:26 AM To: santosh.s2 at samsung.com; Kong, Kwok Cc: Onufryk, Peter; technical at nvmexpress.org Subject: RE: RE: NVMe 1.1 : Clarification on PRP2 Entry list The Linux driver does neither figure 1, nor figure 2. If the number of PRP entries requires more than one page, it starts at the beginning of a page. If it requires less than a page, it may start in the middle of a page, but will never run off the end of a page as shown in figure 2. I have not reviewed the OFA driver to see what it does. ________________________________ From: SANTOSH SINGH [santosh.s2 at samsung.com] Sent: March 19, 2013 8:01 PM To: Kong, Kwok; Wilcox, Matthew R Cc: Onufryk, Peter; technical at nvmexpress.org Subject: Re: RE: NVMe 1.1 : Clarification on PRP2 Entry list Hi Kwok, Matthew, I verified the OFA driver too and that prepares the PRP List entry as in fig-2. Any reason why both the drivers(Linux and OFA) prepares the PRP2 list like fig-2. Will it change in the later version of drivers as fig-1. Regards Santosh ------- Original Message ------- Sender : Kong, Kwok Date : Mar 20, 2013 01:01 (GMT+09:00) Title : RE: NVMe 1.1 : Clarification on PRP2 Entry list I believe the specification is very clear to indicate that figure 1 is correct. "The last entry within a memory page, as indicated by the memory page size in the CC.MPS field, shall be a PRP List pointer if there is more than a single memory page of data to be transferred.". Thanks -Kwok From: Onufryk, Peter [mailto:Peter.Onufryk at idt.com] Sent: Tuesday, March 19, 2013 7:22 AM To: Santosh Singh; technical at nvmexpress.org Subject: RE: NVMe 1.1 : Clarification on PRP2 Entry list Santosh, John and I discussed this and we believe that Figure 1 is correct and that the best way to clarify this is by adding a figure showing it to the spec. This will be the first item on the agenda in this week's calls. Regards, Peter From: Santosh Singh [mailto:santosh.s2 at samsung.com] Sent: Tuesday, March 19, 2013 5:49 AM To: technical at nvmexpress.org Subject: NVMe 1.1 : Clarification on PRP2 Entry list Hi All, I got the query on PRP2 , when it is entry list and not memory page aligned from a design engineer . The below paragraph is from section 4.3 'Physical Region Page Entry and List' of Spec 1.1. [cid:Z5JE7EUABGFC at namo.co.kr] PRP entry 2, when pointing to a list may also have a non-zero offset within a memory page, means that is not memory page aligned. The last entry within a memory page shall be a list pointer. There are following two understandings for this: 1000 h 1 FFFh PRP entry 2 pointing to a list Entry 1 Entry 2 Entry 3 Entry 4 Address of PRP list 5000 h 5 FFFh Entry 5 Entry 6 Entry 7 Entry 8 1000 h 1 FFFh PRP entry 2 pointing to a list Entry 1 Entry 2 Entry 3 Entry 4 2 FFFh Entry 5 Entry 6 Entry 7 Entry 8 Entry 511 Entry 510 Address of PRP list 5000 h 5 FFFh Entry 512 Entry 513 Entry 514 Fig:1 Fig:2 Page boundary So just want to verify with others that as per the line in section 4.3 'A physical region page list (PRP List) is a set of PRP entries in a single page of contiguous memory' fig:2 is the correct understanding. Thanks & Regards Santosh [cid:LK7CT9SZN3WZ at namo.co.kr] [cid:image002.gif at 01CE2635.EFEEF460] [http://ext.samsung.net/mailcheck/SeenTimeChecker?do=ba69d47c78c3acc08d47d8c18e24da0151171515984b9d550ad7d0699a0799098adfa564d3c39ac365b186a42a35dd3e259756a7cc35ba77326bbdfb2ea96a2fcf878f9a26ce15a0] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 126969 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 14036 bytes Desc: image002.gif URL: From raymond.c.robles at intel.com Fri Mar 22 13:54:57 2013 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Fri, 22 Mar 2013 20:54:57 +0000 Subject: [nvmewin] ModeSense Translation Issue In-Reply-To: <23EC73C80FB59046A6B7B8EB7B38265912B82F14@SACMBXIP01.sdcorp.global.sandisk.com> References: <23EC73C80FB59046A6B7B8EB7B38265912B82F14@SACMBXIP01.sdcorp.global.sandisk.com> Message-ID: <49158E750348AA499168FD41D889836061B8C62B@FMSMSX105.amr.corp.intel.com> Hi Dharani, Since this issue is directly related to the OFA Windows NVMe driver, you can redirect your question to the OFA NVMe distribution mailing list at nvmewin at lists.openfabrics.org. The technical at nvmepress.org distribution list is for the NVMe working group. This is the open source community that originally developed the driver (similar to kernel.org for the Linux NVMe driver). We welcome any suggestions for improvements, defect identification, or anything relating to the OFA Windows NVMe driver. We also encourage companies to submit patches for existing issues in the driver. Here are links with information on how to join the distribution list and about our patch submission process. http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin --> subscribing to mailing list https://www.openfabrics.org/resources/developer-tools/nvme-windows-development.html --> process on submitting patches and other misc. info Thanks, Ray From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com] Sent: Friday, March 22, 2013 1:41 PM To: technical at nvmexpress.org Subject: ModeSense Translation Issue The ModeSense Translation is directly using pSrb->DataBuf to prepare the modesense data which is wrong. Because we are supposed to prepare the modesensedata in the local buffer and copy it based on the "allocLength" from the cdb which we actually the size of the pSrb->DataBuf. This is basically corrupting the Application buffer. This needs a major change all over the ModeSense Translation code. Example: VOID SntiCreateModeDataHeader( PSCSI_REQUEST_BLOCK pSrb, PMODE_PARAMETER_BLOCK *ppModeParamBlock, PUINT16 pModeDataLength, UINT16 blockDescLength, BOOLEAN modeSense10 ) { PMODE_PARAMETER_HEADER pModeHeader6 = NULL; PMODE_PARAMETER_HEADER10 pModeHeader10 = NULL; if (modeSense10 == FALSE) { /* MODE SENSE 6 */ pModeHeader6 = (PMODE_PARAMETER_HEADER)(GET_DATA_BUFFER(pSrb)); // This needs to be something like "gModesenseLocalBuf[]" /* Set necessary fields */ memset(pModeHeader6, 0, sizeof(MODE_PARAMETER_HEADER)); pModeHeader6->MediumType = DIRECT_ACCESS_DEVICE; pModeHeader6->DeviceSpecificParameter = 0; pModeHeader6->BlockDescriptorLength = (UCHAR)blockDescLength; } VOID SntiTranslateCachingModePageResponse( PNVME_SRB_EXTENSION pSrbExt, PNVME_LUN_EXTENSION pLunExt, PNVMe_COMPLETION_QUEUE_ENTRY pCQEntry, UINT16 allocLength, UINT8 longLbaAccepted, UINT8 disableBlockDesc, BOOLEAN modeSense10 ) { PMODE_PARAMETER_HEADER pModeHeader6 = NULL; PMODE_PARAMETER_HEADER10 pModeHeader10 = NULL; PMODE_PARAMETER_BLOCK pModeParamBlock = NULL; PCACHING_MODE_PAGE pCachingModePage = NULL; PSCSI_REQUEST_BLOCK pSrb = pSrbExt->pSrb; UINT32 volatileWriteCache = 0; UINT16 modeDataLength = 0; UINT16 blockDescLength = 0; /* The Volatile Write Cache info will be stored in DWORD 0 of the CQE */ volatileWriteCache = pCQEntry->DW0; memset(pSrb->DataBuffer, 0, allocLength); /* Determine which Mode Parameter Descriptor Block to use (8 or 16) */ if (longLbaAccepted == 0) blockDescLength = SHORT_DESC_BLOCK; else blockDescLength = LONG_DESC_BLOCK; /* Mode Page Header */ SntiCreateModeDataHeader(pSrb, &pModeParamBlock, &modeDataLength, (disableBlockDesc ? 0 : blockDescLength), modeSense10); /* Check if block descriptors enabled, if not, then mode pages comes next */ if (disableBlockDesc == BLOCK_DESCRIPTORS_ENABLED) { /* Mode Parameter Descriptor Block */ SntiCreateModeParameterDescBlock(pLunExt, pModeParamBlock, &modeDataLength); /* Increment pointer to after block descriptor */ pModeParamBlock++; } /* Caching Mode Page */ pCachingModePage = (PCACHING_MODE_PAGE)pModeParamBlock; modeDataLength += sizeof(CACHING_MODE_PAGE); memset(pCachingModePage, 0, sizeof(CACHING_MODE_PAGE)); pCachingModePage->PageCode = MODE_PAGE_CACHING; pCachingModePage->PageSavable = MODE_PAGE_PARAM_SAVEABLE_DISABLED; pCachingModePage->PageLength = CACHING_MODE_PAGE_LENGTH; pCachingModePage->WriteCacheEnable = volatileWriteCache & VOLATILE_WRITE_CACHE_MASK; /* Now go back and set the Mode Data Length in the header */ if (modeSense10 == FALSE) { /* Get the correct header that starts at the buffer beginning */ pModeHeader6 = (PMODE_PARAMETER_HEADER)(/* GET_DATA_BUFFER(pSrb)*/ gModesenseLocalBuf); // Changes pModeHeader6->ModeDataLength = (UCHAR)(modeDataLength - 1); } else { /* Get the correct header that starts at the buffer beginning */ pModeHeader10 = (PMODE_PARAMETER_HEADER10)( /* GET_DATA_BUFFER(pSrb)*/ gModesenseLocalBuf); // Changes pModeHeader10->ModeDataLength[0] = ((modeDataLength - 2) & WORD_HIGH_BYTE_MASK) >> BYTE_SHIFT_1; pModeHeader10->ModeDataLength[1] = ((modeDataLength - 2) & WORD_LOW_BYTE_MASK); } pSrb->DataTransferLength = min(modeDataLength, allocLength); StorPortCopyMemory((PVOID)pSrb->DataBuffer, (PVOID) gModesenseLocalBuf, pSrb->DataTransferLength); // Changes pSrbExt->pSrb->ScsiStatus = SCSISTAT_GOOD; pSrbExt->pSrb->SrbStatus = SRB_STATUS_SUCCESS; } /* SntiTranslateCachingModePageResponse */ Thanks, Dharani. ________________________________ PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies). -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dharani.Kotte at sandisk.com Fri Mar 22 13:56:18 2013 From: Dharani.Kotte at sandisk.com (Dharani Kotte) Date: Fri, 22 Mar 2013 20:56:18 +0000 Subject: [nvmewin] ModeSense Translation Issue In-Reply-To: <49158E750348AA499168FD41D889836061B8C62B@FMSMSX105.amr.corp.intel.com> References: <23EC73C80FB59046A6B7B8EB7B38265912B82F14@SACMBXIP01.sdcorp.global.sandisk.com> <49158E750348AA499168FD41D889836061B8C62B@FMSMSX105.amr.corp.intel.com> Message-ID: <23EC73C80FB59046A6B7B8EB7B38265912B82F40@SACMBXIP01.sdcorp.global.sandisk.com> Sorry I sent it to wrong email id. Thanks, Dharani. From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Friday, March 22, 2013 1:55 PM To: Dharani Kotte; technical at nvmexpress.org Cc: nvmewin at lists.openfabrics.org Subject: RE: ModeSense Translation Issue Hi Dharani, Since this issue is directly related to the OFA Windows NVMe driver, you can redirect your question to the OFA NVMe distribution mailing list at nvmewin at lists.openfabrics.org. The technical at nvmepress.org distribution list is for the NVMe working group. This is the open source community that originally developed the driver (similar to kernel.org for the Linux NVMe driver). We welcome any suggestions for improvements, defect identification, or anything relating to the OFA Windows NVMe driver. We also encourage companies to submit patches for existing issues in the driver. Here are links with information on how to join the distribution list and about our patch submission process. http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin --> subscribing to mailing list https://www.openfabrics.org/resources/developer-tools/nvme-windows-development.html --> process on submitting patches and other misc. info Thanks, Ray From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com] Sent: Friday, March 22, 2013 1:41 PM To: technical at nvmexpress.org Subject: ModeSense Translation Issue The ModeSense Translation is directly using pSrb->DataBuf to prepare the modesense data which is wrong. Because we are supposed to prepare the modesensedata in the local buffer and copy it based on the "allocLength" from the cdb which we actually the size of the pSrb->DataBuf. This is basically corrupting the Application buffer. This needs a major change all over the ModeSense Translation code. Example: VOID SntiCreateModeDataHeader( PSCSI_REQUEST_BLOCK pSrb, PMODE_PARAMETER_BLOCK *ppModeParamBlock, PUINT16 pModeDataLength, UINT16 blockDescLength, BOOLEAN modeSense10 ) { PMODE_PARAMETER_HEADER pModeHeader6 = NULL; PMODE_PARAMETER_HEADER10 pModeHeader10 = NULL; if (modeSense10 == FALSE) { /* MODE SENSE 6 */ pModeHeader6 = (PMODE_PARAMETER_HEADER)(GET_DATA_BUFFER(pSrb)); // This needs to be something like "gModesenseLocalBuf[]" /* Set necessary fields */ memset(pModeHeader6, 0, sizeof(MODE_PARAMETER_HEADER)); pModeHeader6->MediumType = DIRECT_ACCESS_DEVICE; pModeHeader6->DeviceSpecificParameter = 0; pModeHeader6->BlockDescriptorLength = (UCHAR)blockDescLength; } VOID SntiTranslateCachingModePageResponse( PNVME_SRB_EXTENSION pSrbExt, PNVME_LUN_EXTENSION pLunExt, PNVMe_COMPLETION_QUEUE_ENTRY pCQEntry, UINT16 allocLength, UINT8 longLbaAccepted, UINT8 disableBlockDesc, BOOLEAN modeSense10 ) { PMODE_PARAMETER_HEADER pModeHeader6 = NULL; PMODE_PARAMETER_HEADER10 pModeHeader10 = NULL; PMODE_PARAMETER_BLOCK pModeParamBlock = NULL; PCACHING_MODE_PAGE pCachingModePage = NULL; PSCSI_REQUEST_BLOCK pSrb = pSrbExt->pSrb; UINT32 volatileWriteCache = 0; UINT16 modeDataLength = 0; UINT16 blockDescLength = 0; /* The Volatile Write Cache info will be stored in DWORD 0 of the CQE */ volatileWriteCache = pCQEntry->DW0; memset(pSrb->DataBuffer, 0, allocLength); /* Determine which Mode Parameter Descriptor Block to use (8 or 16) */ if (longLbaAccepted == 0) blockDescLength = SHORT_DESC_BLOCK; else blockDescLength = LONG_DESC_BLOCK; /* Mode Page Header */ SntiCreateModeDataHeader(pSrb, &pModeParamBlock, &modeDataLength, (disableBlockDesc ? 0 : blockDescLength), modeSense10); /* Check if block descriptors enabled, if not, then mode pages comes next */ if (disableBlockDesc == BLOCK_DESCRIPTORS_ENABLED) { /* Mode Parameter Descriptor Block */ SntiCreateModeParameterDescBlock(pLunExt, pModeParamBlock, &modeDataLength); /* Increment pointer to after block descriptor */ pModeParamBlock++; } /* Caching Mode Page */ pCachingModePage = (PCACHING_MODE_PAGE)pModeParamBlock; modeDataLength += sizeof(CACHING_MODE_PAGE); memset(pCachingModePage, 0, sizeof(CACHING_MODE_PAGE)); pCachingModePage->PageCode = MODE_PAGE_CACHING; pCachingModePage->PageSavable = MODE_PAGE_PARAM_SAVEABLE_DISABLED; pCachingModePage->PageLength = CACHING_MODE_PAGE_LENGTH; pCachingModePage->WriteCacheEnable = volatileWriteCache & VOLATILE_WRITE_CACHE_MASK; /* Now go back and set the Mode Data Length in the header */ if (modeSense10 == FALSE) { /* Get the correct header that starts at the buffer beginning */ pModeHeader6 = (PMODE_PARAMETER_HEADER)(/* GET_DATA_BUFFER(pSrb)*/ gModesenseLocalBuf); // Changes pModeHeader6->ModeDataLength = (UCHAR)(modeDataLength - 1); } else { /* Get the correct header that starts at the buffer beginning */ pModeHeader10 = (PMODE_PARAMETER_HEADER10)( /* GET_DATA_BUFFER(pSrb)*/ gModesenseLocalBuf); // Changes pModeHeader10->ModeDataLength[0] = ((modeDataLength - 2) & WORD_HIGH_BYTE_MASK) >> BYTE_SHIFT_1; pModeHeader10->ModeDataLength[1] = ((modeDataLength - 2) & WORD_LOW_BYTE_MASK); } pSrb->DataTransferLength = min(modeDataLength, allocLength); StorPortCopyMemory((PVOID)pSrb->DataBuffer, (PVOID) gModesenseLocalBuf, pSrb->DataTransferLength); // Changes pSrbExt->pSrb->ScsiStatus = SCSISTAT_GOOD; pSrbExt->pSrb->SrbStatus = SRB_STATUS_SUCCESS; } /* SntiTranslateCachingModePageResponse */ Thanks, Dharani. ________________________________ PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies). -------------- next part -------------- An HTML attachment was scrubbed... URL: From santosh.s2 at samsung.com Tue Mar 26 03:32:13 2013 From: santosh.s2 at samsung.com (SANTOSH SINGH) Date: Tue, 26 Mar 2013 10:32:13 +0000 (GMT) Subject: [nvmewin] NVMe 1.1 : Clarification on PRP2 Entry list Message-ID: <46.C4.05358.E2971515@epcpsbgx3.samsung.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 201303261604609_N3WZA6X7.png Type: image/png Size: 81077 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 201303261604624_LP7KBSL8.png Type: image/png Size: 126969 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 201303261605569_04A24XEV.gif Type: image/gif Size: 14036 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PRP.pptx Type: application/octet-stream Size: 66659 bytes Desc: not available URL: From Kwok.Kong at idt.com Tue Mar 26 15:56:01 2013 From: Kwok.Kong at idt.com (Kong, Kwok) Date: Tue, 26 Mar 2013 22:56:01 +0000 Subject: [nvmewin] NVMe 1.1 : Clarification on PRP2 Entry list In-Reply-To: References: Message-ID: <05CD7821AE397547A01AC160FBC231474BC8C867@corpmail1.na.ads.idt.com> Santosh, Something is not right here. The driver pre-allocates the PRP list to store up to 32 entries per list during initialization time. PRP2 must point to a list with the following offset: - 0x000 - 0x100 - 0x200 - … - … - 0xE00 - 0xF00 PRP2 cannot point to an offset 0xFF0 as in your example. You can confirm this in your driver by adding the following debugging message in the file nvmeinit.c and function NVMeInitFreeQ. It's around Line# 720 to add the printout... /* Save the address of current list for calculating next list */ CurPRPList = (ULONG_PTR)pCmdInfo->pPRPList; pCmdInfo->prpListPhyAddr = StorPortGetPhysicalAddress(pAE, NULL, pCmdInfo->pPRPList, &prpListSz); StorPortDebugPrint(INFO, "NVMeInitFreeQ : Entry#%d List starts 0x%llX\n", Entry, pCmdInfo->pPRPList); Here is a sample output: STORMINI: NVMeInitFreeQ : Entry#0 List starts 0xFFFFFA800D69E100 STORMINI: NVMeInitFreeQ : Entry#1 List starts 0xFFFFFA800D69E200 STORMINI: NVMeInitFreeQ : Entry#2 List starts 0xFFFFFA800D69E300 STORMINI: NVMeInitFreeQ : Entry#3 List starts 0xFFFFFA800D69E400 STORMINI: NVMeInitFreeQ : Entry#4 List starts 0xFFFFFA800D69E500 STORMINI: NVMeInitFreeQ : Entry#5 List starts 0xFFFFFA800D69E600 STORMINI: NVMeInitFreeQ : Entry#6 List starts 0xFFFFFA800D69E700 STORMINI: NVMeInitFreeQ : Entry#7 List starts 0xFFFFFA800D69E800 STORMINI: NVMeInitFreeQ : Entry#8 List starts 0xFFFFFA800D69E900 STORMINI: NVMeInitFreeQ : Entry#9 List starts 0xFFFFFA800D69EA00 STORMINI: NVMeInitFreeQ : Entry#10 List starts 0xFFFFFA800D69EB00 STORMINI: NVMeInitFreeQ : Entry#11 List starts 0xFFFFFA800D69EC00 STORMINI: NVMeInitFreeQ : Entry#12 List starts 0xFFFFFA800D69ED00 STORMINI: NVMeInitFreeQ : Entry#13 List starts 0xFFFFFA800D69EE00 STORMINI: NVMeInitFreeQ : Entry#14 List starts 0xFFFFFA800D69EF00 STORMINI: NVMeInitFreeQ : Entry#15 List starts 0xFFFFFA800D69F000 STORMINI: NVMeInitFreeQ : Entry#16 List starts 0xFFFFFA800D69F100 STORMINI: NVMeInitFreeQ : Entry#17 List starts 0xFFFFFA800D6A0100 STORMINI: NVMeInitFreeQ : Entry#18 List starts 0xFFFFFA800D6A0200 STORMINI: NVMeInitFreeQ : Entry#19 List starts 0xFFFFFA800D6A0300 … … Did you modify the driver and create a bug in your driver ? We have not seen this problem in our testing environment. Thanks -Kwok From: SANTOSH SINGH [mailto:santosh.s2 at samsung.com] Sent: Tuesday, March 26, 2013 3:32 AM To: Robles, Raymond C Cc: Kong, Kwok; technical at nvmexpress.org; Onufryk, Peter; Wilcox, Matthew R; nvmewin at lists.openfabrics.org Subject: Re: RE: RE: RE: NVMe 1.1 : Clarification on PRP2 Entry list Hi Ray, Attached is the summary of the screen shot. [cid:image001.png at 01CE2A3A.69BD3380] We can discuss in the next WG call. Regards Santosh ------- Original Message ------- Sender : Robles, Raymond C> Date : Mar 22, 2013 05:17 (GMT+09:00) Title : RE: RE: RE: NVMe 1.1 : Clarification on PRP2 Entry list Hi Santosh, I am one of the original authors of the OFA Windows NVMe driver (sorry, I’m late to this thread). What do you believe is the problem? The Windows OFA driver constructs PRP lists per the NVMe spec. We’ve run for several days with numerous data integrity testing tools (without error). Do you believe that the PRP list is incorrectly constructed? Based on the screen shot you sent out, the second PRP entry in the submission queue entry points to a PRP list… it should not contain the 2nd PRP entry. This is per the NVMe spec. Thanks, Ray From: Kong, Kwok [mailto:Kwok.Kong at idt.com] Sent: Thursday, March 21, 2013 11:14 AM To: santosh.s2 at samsung.com Cc: technical at nvmexpress.org; Onufryk, Peter; Wilcox, Matthew R Subject: RE: RE: RE: NVMe 1.1 : Clarification on PRP2 Entry list Santosh, The specification is very clear on how the PRP list should be constructed. If you see a problem with any driver, then it is a driver problem and not a specification problem. Please send your question to nvmewin at lists.openfabrics.org if you believe there is a driver bug. What is the LBA size for your testing ? 512B or 4KB ? Thanks -Kwok From: SANTOSH SINGH [mailto:santosh.s2 at samsung.com] Sent: Thursday, March 21, 2013 3:55 AM To: Kong, Kwok Cc: technical at nvmexpress.org; Onufryk, Peter; 'Wilcox, Matthew R' Subject: Re: RE: RE: NVMe 1.1 : Clarification on PRP2 Entry list Sorry some how the attachement is missing. Resending. [cid:image002.png at 01CE2A3A.69BD3380] Regards Santosh ------- Original Message ------- Sender : SANTOSH SINGH> Senior Chief Engineer/SRI-Bangalore-SSD Solutions/Samsung Electronics Date : Mar 21, 2013 19:45 (GMT+09:00) Title : RE: RE: NVMe 1.1 : Clarification on PRP2 Entry list Hi Kwok, I got the scenario reproduced again, while issuing the FS format command. Following are the debug details. Page size 4k Data Transfer size was 16 LBA PRP1 Entry 0x3e8fd060 PRP2 Entry list 0xbe166ff0 Total no. of PRP entries 17 The 16 PRP entries should fit in single page. But the PRP2 offset 0xbe166ff0(PRP2) is not correct and it has run off the page(from 0xbe166ff0 to 0xbe167000) which is the next page in continuity. Attached is the snapshot of the debug window for the detailed analysis. Regards Santosh -----Original Message----- From: Kong, Kwok [mailto:Kwok.Kong at idt.com] Sent: Thursday, March 21, 2013 1:22 AM To: Wilcox, Matthew R; santosh.s2 at samsung.com Cc: Onufryk, Peter; technical at nvmexpress.org Subject: RE: RE: NVMe 1.1 : Clarification on PRP2 Entry list Santosh, Your verification on the OFA driver that it uses PRP list format as in figure 2 is incorrect. The OFA driver does neither figure 1, nor figure 2. By default, the max request size that the mini-port supports is 128KB. If the request size is bigger than 128KB, the port driver sends multiple 128KB requests to the OFA mini-port driver. The OFA mini-port driver pre-allocates the PRP list buffers during initialization. The PRP entries (a max of 32 entries for 128KB request size) never run off the end of a page as shown in figure 1 or figure 2. All PRP entries are guaranteed to fit within a single Memory Page. Thanks -Kwok -----Original Message----- From: Wilcox, Matthew R [mailto:matthew.r.wilcox at intel.com] Sent: Wednesday, March 20, 2013 8:26 AM To: santosh.s2 at samsung.com; Kong, Kwok Cc: Onufryk, Peter; technical at nvmexpress.org Subject: RE: RE: NVMe 1.1 : Clarification on PRP2 Entry list The Linux driver does neither figure 1, nor figure 2. If the number of PRP entries requires more than one page, it starts at the beginning of a page. If it requires less than a page, it may start in the middle of a page, but will never run off the end of a page as shown in figure 2. I have not reviewed the OFA driver to see what it does. ________________________________ From: SANTOSH SINGH [santosh.s2 at samsung.com] Sent: March 19, 2013 8:01 PM To: Kong, Kwok; Wilcox, Matthew R Cc: Onufryk, Peter; technical at nvmexpress.org Subject: Re: RE: NVMe 1.1 : Clarification on PRP2 Entry list Hi Kwok, Matthew, I verified the OFA driver too and that prepares the PRP List entry as in fig-2. Any reason why both the drivers(Linux and OFA) prepares the PRP2 list like fig-2. Will it change in the later version of drivers as fig-1. Regards Santosh ------- Original Message ------- Sender : Kong, Kwok Date : Mar 20, 2013 01:01 (GMT+09:00) Title : RE: NVMe 1.1 : Clarification on PRP2 Entry list I believe the specification is very clear to indicate that figure 1 is correct. "The last entry within a memory page, as indicated by the memory page size in the CC.MPS field, shall be a PRP List pointer if there is more than a single memory page of data to be transferred.". Thanks -Kwok From: Onufryk, Peter [mailto:Peter.Onufryk at idt.com] Sent: Tuesday, March 19, 2013 7:22 AM To: Santosh Singh; technical at nvmexpress.org Subject: RE: NVMe 1.1 : Clarification on PRP2 Entry list Santosh, John and I discussed this and we believe that Figure 1 is correct and that the best way to clarify this is by adding a figure showing it to the spec. This will be the first item on the agenda in this week's calls. Regards, Peter From: Santosh Singh [mailto:santosh.s2 at samsung.com] Sent: Tuesday, March 19, 2013 5:49 AM To: technical at nvmexpress.org Subject: NVMe 1.1 : Clarification on PRP2 Entry list Hi All, I got the query on PRP2 , when it is entry list and not memory page aligned from a design engineer . The below paragraph is from section 4.3 'Physical Region Page Entry and List' of Spec 1.1. [cid:Z5JE7EUABGFC at namo.co.kr] PRP entry 2, when pointing to a list may also have a non-zero offset within a memory page, means that is not memory page aligned. The last entry within a memory page shall be a list pointer. There are following two understandings for this: 1000 h 1 FFFh PRP entry 2 pointing to a list Entry 1 Entry 2 Entry 3 Entry 4 Address of PRP list 5000 h 5 FFFh Entry 5 Entry 6 Entry 7 Entry 8 1000 h 1 FFFh PRP entry 2 pointing to a list Entry 1 Entry 2 Entry 3 Entry 4 2 FFFh Entry 5 Entry 6 Entry 7 Entry 8 Entry 511 Entry 510 Address of PRP list 5000 h 5 FFFh Entry 512 Entry 513 Entry 514 Fig:1 Fig:2 Page boundary So just want to verify with others that as per the line in section 4.3 'A physical region page list (PRP List) is a set of PRP entries in a single page of contiguous memory' fig:2 is the correct understanding. Thanks & Regards Santosh [cid:LK7CT9SZN3WZ at namo.co.kr] [cid:image003.gif at 01CE2A3A.69BD3380] [http://ext.samsung.net/mailcheck/SeenTimeChecker?do=ba69d47c78c3acc08d47d8c18e24da0151171515984b9d550ad7d0699a0799098adfa564d3c39ac365b186a42a35dd3e259756a7cc35ba77326bbdfb2ea96a2fcf878f9a26ce15a0] [http://ext.samsung.net/mailcheck/SeenTimeChecker?do=ba69d47c78c3acc0b6872ba05ecac647cb20e510c9bc8be10ad7d0699a0799098adfa564d3c39ac365b186a42a35dd3e259756a7cc35ba77326bbdfb2ea96a2fcf878f9a26ce15a0] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 81077 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 126969 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.gif Type: image/gif Size: 14036 bytes Desc: image003.gif URL: From Alex.Chang at idt.com Thu Mar 28 16:14:39 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Thu, 28 Mar 2013 23:14:39 +0000 Subject: [nvmewin] New Patch From IDT References: <49158E750348AA499168FD41D8898360611CA580@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFDAE6D@corpmail1.na.ads.idt.com> <05CD7821AE397547A01AC160FBC231474BC832F1@corpmail1.na.ads.idt.com> <36E8D38D6B771A4BBDB1C0D800158A512FBA22E3@SSIEXCH-MB2.ssi.samsung.com> <5E6652408D93274292C8F06C9A4A26007195AF84@NTXBOIMBX05.micron.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFDE264@corpmail1.na.ads.idt.com> Hi all, It's been almost two weeks after I sent out the patch. Ray/Arpit, please let us know if you're okay with it. Thanks, Alex ________________________________ From: Chang, Alex Sent: Friday, March 15, 2013 12:09 PM To: nvmewin at lists.openfabrics.org Subject: New Patch From IDT Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeinit.c and nvmestat.c - When Metadata is enabled, the associated drive is not visible to the host to avoid system crash when processing Read/Write commands. 2. In nvmesnti.c, nvmesnti.h and nvmesntitypes.h - Added handling zero length in Read/Write commands except Read6/Write6. - Added handling buffer over-run/under-run for Read/Write commands. - Fixed Read6/Write6 zero length bug in CDB. 3. In nvmestd.c - Fixed system crash issue when LunExtensionTable is not allocated and requests hit NVMeBuildIo. It happens when driver is not initialized successfully. Please review the changes and provide feedbacks if you have any. If nobody disagrees with the changes, I will remind Ray to merge them in two weeks. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.c.robles at intel.com Thu Mar 28 16:37:16 2013 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Thu, 28 Mar 2013 23:37:16 +0000 Subject: [nvmewin] New Patch From IDT In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFDE264@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D8898360611CA580@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFDAE6D@corpmail1.na.ads.idt.com> <05CD7821AE397547A01AC160FBC231474BC832F1@corpmail1.na.ads.idt.com> <36E8D38D6B771A4BBDB1C0D800158A512FBA22E3@SSIEXCH-MB2.ssi.samsung.com> <5E6652408D93274292C8F06C9A4A26007195AF84@NTXBOIMBX05.micron.com> <548C5470AAD9DA4A85D259B663190D361FFDE264@corpmail1.na.ads.idt.com> Message-ID: <49158E750348AA499168FD41D889836061B8FD50@FMSMSX105.amr.corp.intel.com> Hi Alex, I never received this patch (or the email below)? I apologize, but I don't see it in my inbox. Can you please resend the email along with the patch? I know there have been issues with the email distribution list before. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, March 28, 2013 4:15 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From IDT Hi all, It's been almost two weeks after I sent out the patch. Ray/Arpit, please let us know if you're okay with it. Thanks, Alex ________________________________ From: Chang, Alex Sent: Friday, March 15, 2013 12:09 PM To: nvmewin at lists.openfabrics.org Subject: New Patch From IDT Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeinit.c and nvmestat.c - When Metadata is enabled, the associated drive is not visible to the host to avoid system crash when processing Read/Write commands. 2. In nvmesnti.c, nvmesnti.h and nvmesntitypes.h - Added handling zero length in Read/Write commands except Read6/Write6. - Added handling buffer over-run/under-run for Read/Write commands. - Fixed Read6/Write6 zero length bug in CDB. 3. In nvmestd.c - Fixed system crash issue when LunExtensionTable is not allocated and requests hit NVMeBuildIo. It happens when driver is not initialized successfully. Please review the changes and provide feedbacks if you have any. If nobody disagrees with the changes, I will remind Ray to merge them in two weeks. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Thu Mar 28 16:41:01 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Thu, 28 Mar 2013 23:41:01 +0000 Subject: [nvmewin] New Patch From IDT In-Reply-To: <49158E750348AA499168FD41D889836061B8FD50@FMSMSX105.amr.corp.intel.com> References: <49158E750348AA499168FD41D8898360611CA580@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFDAE6D@corpmail1.na.ads.idt.com> <05CD7821AE397547A01AC160FBC231474BC832F1@corpmail1.na.ads.idt.com> <36E8D38D6B771A4BBDB1C0D800158A512FBA22E3@SSIEXCH-MB2.ssi.samsung.com> <5E6652408D93274292C8F06C9A4A26007195AF84@NTXBOIMBX05.micron.com> <548C5470AAD9DA4A85D259B663190D361FFDE264@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836061B8FD50@FMSMSX105.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFDE283@corpmail1.na.ads.idt.com> Hi Ray, Here you go... Alex ________________________________ From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, March 28, 2013 4:37 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: New Patch From IDT Hi Alex, I never received this patch (or the email below)? I apologize, but I don't see it in my inbox. Can you please resend the email along with the patch? I know there have been issues with the email distribution list before. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, March 28, 2013 4:15 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From IDT Hi all, It's been almost two weeks after I sent out the patch. Ray/Arpit, please let us know if you're okay with it. Thanks, Alex ________________________________ From: Chang, Alex Sent: Friday, March 15, 2013 12:09 PM To: nvmewin at lists.openfabrics.org Subject: New Patch From IDT Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeinit.c and nvmestat.c - When Metadata is enabled, the associated drive is not visible to the host to avoid system crash when processing Read/Write commands. 2. In nvmesnti.c, nvmesnti.h and nvmesntitypes.h - Added handling zero length in Read/Write commands except Read6/Write6. - Added handling buffer over-run/under-run for Read/Write commands. - Fixed Read6/Write6 zero length bug in CDB. 3. In nvmestd.c - Fixed system crash issue when LunExtensionTable is not allocated and requests hit NVMeBuildIo. It happens when driver is not initialized successfully. Please review the changes and provide feedbacks if you have any. If nobody disagrees with the changes, I will remind Ray to merge them in two weeks. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: source_idt_031513.zip Type: application/x-zip-compressed Size: 165117 bytes Desc: source_idt_031513.zip URL: From Rick.Knoblaugh at lsi.com Thu Mar 28 17:10:11 2013 From: Rick.Knoblaugh at lsi.com (Knoblaugh, Rick) Date: Thu, 28 Mar 2013 18:10:11 -0600 Subject: [nvmewin] New Patch From IDT In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFDE264@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D8898360611CA580@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFDAE6D@corpmail1.na.ads.idt.com> <05CD7821AE397547A01AC160FBC231474BC832F1@corpmail1.na.ads.idt.com> <36E8D38D6B771A4BBDB1C0D800158A512FBA22E3@SSIEXCH-MB2.ssi.samsung.com> <5E6652408D93274292C8F06C9A4A26007195AF84@NTXBOIMBX05.micron.com> <548C5470AAD9DA4A85D259B663190D361FFDE264@corpmail1.na.ads.idt.com> Message-ID: <4565AEA676113A449269C2F3A549520FD3A3B174@cosmail03.lsi.com> Hi Alex, I did receive your patch back on the 15th. Have reviewed changes and we are good with all of these. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, March 28, 2013 4:15 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From IDT Hi all, It's been almost two weeks after I sent out the patch. Ray/Arpit, please let us know if you're okay with it. Thanks, Alex ________________________________ From: Chang, Alex Sent: Friday, March 15, 2013 12:09 PM To: nvmewin at lists.openfabrics.org Subject: New Patch From IDT Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeinit.c and nvmestat.c - When Metadata is enabled, the associated drive is not visible to the host to avoid system crash when processing Read/Write commands. 2. In nvmesnti.c, nvmesnti.h and nvmesntitypes.h - Added handling zero length in Read/Write commands except Read6/Write6. - Added handling buffer over-run/under-run for Read/Write commands. - Fixed Read6/Write6 zero length bug in CDB. 3. In nvmestd.c - Fixed system crash issue when LunExtensionTable is not allocated and requests hit NVMeBuildIo. It happens when driver is not initialized successfully. Please review the changes and provide feedbacks if you have any. If nobody disagrees with the changes, I will remind Ray to merge them in two weeks. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Thu Mar 28 17:19:22 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Fri, 29 Mar 2013 00:19:22 +0000 Subject: [nvmewin] New Patch From IDT In-Reply-To: <4565AEA676113A449269C2F3A549520FD3A3B174@cosmail03.lsi.com> References: <49158E750348AA499168FD41D8898360611CA580@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFDAE6D@corpmail1.na.ads.idt.com> <05CD7821AE397547A01AC160FBC231474BC832F1@corpmail1.na.ads.idt.com> <36E8D38D6B771A4BBDB1C0D800158A512FBA22E3@SSIEXCH-MB2.ssi.samsung.com> <5E6652408D93274292C8F06C9A4A26007195AF84@NTXBOIMBX05.micron.com> <548C5470AAD9DA4A85D259B663190D361FFDE264@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520FD3A3B174@cosmail03.lsi.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFDE2AB@corpmail1.na.ads.idt.com> Thanks a lot, Rick. Alex ________________________________ From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Thursday, March 28, 2013 5:10 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: New Patch From IDT Hi Alex, I did receive your patch back on the 15th. Have reviewed changes and we are good with all of these. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, March 28, 2013 4:15 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From IDT Hi all, It's been almost two weeks after I sent out the patch. Ray/Arpit, please let us know if you're okay with it. Thanks, Alex ________________________________ From: Chang, Alex Sent: Friday, March 15, 2013 12:09 PM To: nvmewin at lists.openfabrics.org Subject: New Patch From IDT Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeinit.c and nvmestat.c - When Metadata is enabled, the associated drive is not visible to the host to avoid system crash when processing Read/Write commands. 2. In nvmesnti.c, nvmesnti.h and nvmesntitypes.h - Added handling zero length in Read/Write commands except Read6/Write6. - Added handling buffer over-run/under-run for Read/Write commands. - Fixed Read6/Write6 zero length bug in CDB. 3. In nvmestd.c - Fixed system crash issue when LunExtensionTable is not allocated and requests hit NVMeBuildIo. It happens when driver is not initialized successfully. Please review the changes and provide feedbacks if you have any. If nobody disagrees with the changes, I will remind Ray to merge them in two weeks. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: