From Kwok.Kong at idt.com Mon Jun 3 10:18:51 2013 From: Kwok.Kong at idt.com (Kong, Kwok) Date: Mon, 3 Jun 2013 17:18:51 +0000 Subject: [nvmewin] Review Driver Development Status Message-ID: <05CD7821AE397547A01AC160FBC231474BCA9BB8@corpmail1.na.ads.idt.com> When: Wednesday, June 19, 2013 1:00 PM-2:00 PM (UTC-08:00) Pacific Time (US & Canada). Where: Conf call Note: The GMT offset above does not reflect daylight saving time adjustments. *~*~*~*~*~*~*~*~*~* You are invited to attend an AT&T Connect iMeeting . To connect to the Web Conference: ============================= Click here: https://connect9.uc.att.com/service32/meet/?ExEventID=8811938&CT=M TO CONNECT WITH YOUR *TELEPHONE ONLY* (no computer): =================================================== 1. Choose one of the following numbers to dial: If you are calling from an office location with on-site number(s) (listed below), try this number first. If you do not have on-site access, or you are not a member of the host's company/organization, use one of the other numbers shown. * Caller-Paid number: 602-333-0032 * Toll-Free Number (in USA): 888-270-9936. * Blackberry (Caller-Paid): 6023330032x811938# * A number in your country or in a country close to you (may be toll free): https://www.teleconference.att.com/servlet/glbAccess?process=1&accessNumber=8882709936&accessCode=811938 2. When prompted, enter the Meeting Access Code: 811938# To prepare in advance for the conference (for all devices): https://connect9.uc.att.com/service32/Prepare/. To view supported Operating Systems and devices: http://www.uc.att.com/support/SupportedDevices.html Powered by AT&T Connect. Agenda: - Review Release 1.2 Status o - Supports the following Windows versions in addition to Windows 7 - 64 bits (IDT) o - Windows 8 64-bit o - Windows Server 2008R2 64-bit o - Windows Server 2012 64-bit o o - TRIM command support (LSI) o - NVMe 1.00e enhancement (IDT) o - Hibernation as a boot drive (Huawei) - Review Known problems Status - Not Accessing NVMe registers in their native width. (Ray - Intel) - ModeSense Translation issue. (Dharani - SanDisk) - format nvm error. (Judy - Samsung) - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset. (Judy - Samsung) - SCSI Translation Update (Yong Chen - Huawei) - Release 1.3 Discussion - Support additional Windows versions - Windows 7 32-bit - Windows 8 32-bit - Windows 8 features: - Extended SRB format - SMART handling via new Extended SRB format Features that will not be supported in 2013 (will be reviewed mid-year): NVMe 1.1 support: - multi-path - SGL - Get/Set feature update - Autonomous power state transition - Host Identifier - Reservation Notification Mask - Reservation Persistence - identify structure update - write zeros command Other feature: - End-to-end protection (Server 2012 support this) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 4519 bytes Desc: not available URL: From Alex.Chang at idt.com Mon Jun 3 14:08:08 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Mon, 3 Jun 2013 21:08:08 +0000 Subject: [nvmewin] New Patch From Sandisk In-Reply-To: References: <49158E750348AA499168FD41D88983606256082A@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFE961C@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062560AA2@FMSMSX105.amr.corp.intel.com> <49158E750348AA499168FD41D889836062578A2D@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEC067@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062578B98@FMSMSX105.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFEE32C@corpmail1.na.ads.idt.com> Hi Sumant, I retested the patch with SCSICompliance and it results a new failure: MODE SENSE (6) Comparing MODE PAGE data before and after DBD bit is set. Could you test it to see if you can replicate it? You may find more details in the attachment. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 30, 2013 3:20 PM To: Robles, Raymond C; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Ray, Please find attached the patch that has fix for the last code review comment. This is the patch set that I had sent to Alex earlier. Password : sndk1234 Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 3:10 PM To: Chang, Alex; Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thanks Alex. Sumant, please continue with your updates from the last set of code review comments and resend the patch (after running all the required unit tests of course). Once we confirm the feedback changes are in place, I’ll push the patch. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 30, 2013 3:07 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Actually I did some preliminary debugging on it and found out the crash was not introduced by your patch. When the system gets normal shutdown, NVMeNormalShutdown calls NVMeFreeBuffers to free up all queue related structures. And later, when NVMeDetectPendingCmds is called to check on the pending commands, it refers to the queue structures and causes the crash. I will include the fix in my next patch that includes changes to be compliant with 1.0e NVMe Specification. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 30, 2013 2:11 PM To: Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hello Alex, I haven’t been able to repro the BSOD issue that you saw in your setup. Would it be possible for you to send me the crashdump please ? Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 1:24 PM To: Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Importance: High Dharani/Sumant, What is the status on this patch? I’ve not seen any follow up to my last email below. Hopefully we can close this out soon as there are other patches waiting to be submitted. Thanks for your quick attention. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, May 16, 2013 3:49 PM To: Chang, Alex; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Actually, I was going to type the same thing in my email below and then got derailed with the whole #define issue (thanks for capturing this Alex). There is no DataTransferLength field in the SRB Extension structure. That is defined in the SRB by Storport. As a general courtesy to other companies who are reviewing these patches, please insure that you are compiling and re-testing your patch prior to sending out for secondary or additional code reviews. This will help save valuable time in the code review process. If you are having issues compiling, or do not see the same errors, please contact me. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 16, 2013 3:44 PM To: Robles, Raymond C; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, The only change you've made in the new patch is replacing: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); with: memset(GET_DATA_BUFFER(pSrb), 0, min(pSrbExt->DataTransferLength, allocLength)); However, it generates compiling error because DataTransferLength is not a member of NVME_SRB_EXTENSION structure. Could you please fix it? Thanks a lot for you help, Alex ________________________________ From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 16, 2013 1:37 PM To: Sumant Patro; Knoblaugh, Rick; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant/Dharani, Thanks for the updated patch. A couple of comments/questions: - For all the mode sense page translations, the new temp buffer allocated in the SRB extension is used. But for the Modes Sense 0x3C (all mode pages), the SRB data buffer is still memset to 0 at the beginning of SntiReturnAllModePages(). I’m not sure we still need to do this considering how the temp buffer is used to build the mode sense data. - If you insist on keeping that memset in there, there is a #define in for all mode pages - MODE_SENSE_ALL_PAGES_LENGTH. It may be better to zero out the buffer based on the min between this define and allocLength. SRB data transfer length cannot be relied on for “data-in” commands (like mode sense). Thanks, Ray From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 16, 2013 12:43 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Sorry, sent the wrong zip in the previous mail. Please ignore the previous attachment. Attached is the updated zip file. Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 16, 2013 12:38 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Thanks Rick, Alex for your feedback. Please find attached updated files with following two changes : 1. Comment in header of SntiCreateModeDataHeader function changed to reflect passing of srb extension 2. memset(GET_DATA_BUFFER(pSrb), 0, allocLength); modified to use minimum of allocLength and DataTransferLength in SntiReturnAllModePages(..) Password : sndk1234 Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Thursday, May 16, 2013 11:59 AM To: Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, When you change that one, may as well fix the comment in header of SntiCreateModeDataHeader function to reflect that srb extension is now the parameter that’s passed in. Other stuff looks good. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, May 16, 2013 10:58 AM To: Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, I tested your new patch and experienced a D1 bugcheck while running SCSICompliance test. Some preliminary debugging leads to Line#3633 of nvmestni.c, where it looks like: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); The bugcheck happens when the value of "allocLength" is 0x1000. Apparently, the allocated length in CDB is somewhat a bogus value that is meant to test how driver handles it. Could you please fix it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Wednesday, May 01, 2013 8:56 AM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Ray, I have incorporated the changes according to your suggestions, I tried to keep up with the coding convention please feel free to let me know if anything has to be changed. I have incorporated one more fix in the nvmeInit.c which can lead to memory corruptions and used the SrbExt for the buffer allocation. PassWd: sndk1234 Thanks, Dharani. From: Dharani Kotte Sent: Tuesday, April 30, 2013 12:03 PM To: 'Robles, Raymond C'; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thank you for the feedback, I agree that the global buffer is not good I have made the changes to allocate this buffer from the srbext I will provide the code with the below modifications soon. Thanks, Dharani. From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, April 30, 2013 11:52 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, Thank you for putting this patch together. Please see my feedback below: - Line 52: Note that we have a file called nvmeSntiTypes.h. This file contains all #defines. As per our existing convention, all #defines should be placed in this file (versus at the top of a .c file). - Line 3339/3412/3502/3593/3756/5391/5433/5442/5453: Our coding convention states no line be longer than 80 characters. These lines all exceed 80 characters. - Line 5410: SntiTranslateAllModePagesResponse() contains new if-else blocks. Our coding convention dictates that open curly braces be placed on the same line as the if or else statement. You can refer to other instances of the code and if-else clauses as examples. - Line 4017: SntiCreateModeDataHeader() no longer needs the SRB pointer to be passed in as a parameter since you are using a global temp buffer to build up the mode sense data. That parameter can be removed. - General: The method of using a global buffer for a single mode sense command opens up a potential race condition for multiple mode sense commands submitted on top of each other. The idea behind putting the SCSI to NVMe translation phase in the HwStorBuildIo phase was to help performance. We initially knew that we would never be sharing any data structures or memory in calls to BuildIo. There is no spinlock or protection for calls to BuildIo and MSDN makes it clear that these BuildIo calls are not synchronized and that any synchronization of memory/data must be done within the function implementations or just use StartIo instead (since Storport will acquire the StartIoSpinLock). So there is hole here w/r/t the global buffer being populated for multiple mode sense commands at the same time. I believe you have the right idea, but the correct solution is to create a temp mode sense buffer inside the SRB extension. This way, each command has its own temp mode sense buffer for building the mode sense response, and then when ready to copy over to the SRB data buffer, it’s pulling from a buffer that can only be accessed by the current command (instead of a global buffer that may have been overwritten by another mode sense request call from another BuildIo call). Note that the driver collaboration group made the decision to never acquire any type of lock in BuildIo. Let me know if you have questions on this solution. The additional size to the SRB extension is not an issue. This fix is critical for this patch to be accepted. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 11:14 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Attaching the code with according to Alex suggestion. Passwd: sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, April 30, 2013 9:23 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, I'd suggest that it's safer to initialize gModeSenseBuf as all zeros each time before it is used, just in case there are some unexpected data in the buffer. Other than that, I am fine with the patch. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 8:37 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] New Patch From Sandisk Hi all, It's been almost two weeks after I sent out the patch. please let us know if you're okay with it. Thanks, Dharani. From: Dharani Kotte Sent: Friday, April 12, 2013 9:58 AM To: nvmewin at lists.openfabrics.org Subject: New Patch From Sandisk Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeSnti.c a. Allocate a global buffer of 256bytes size for modesense return data preparation b. For any mode sense this buffer is used for modesense data along with the requested pages in it. c. Copy the required data according to the alloc_length requested in the cdb to the Srb->DataBuffer and update the dataTransferLength accordingly d. In function SntiTranslateReturnAllModePagesResponse() the modesense data header offset is calculated wrong which ends up in BSOD in some cases modified code to fix this issue 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, 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). CAUTION: Please confirm that the password protected .zip attachment which contains the file(s) of type source_sndk_05_16_2013.zip is legitimate prior to opening. To make sure this message is not infected with a virus, it is important to verify that you are expecting the message or else confirm its legitimacy with the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: scsicompliance.wtl.txt URL: From raymond.c.robles at intel.com Mon Jun 3 16:44:03 2013 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Mon, 3 Jun 2013 23:44:03 +0000 Subject: [nvmewin] Sandisk patch delay Message-ID: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From Rick.Knoblaugh at lsi.com Mon Jun 3 16:57:11 2013 From: Rick.Knoblaugh at lsi.com (Knoblaugh, Rick) Date: Mon, 3 Jun 2013 17:57:11 -0600 Subject: [nvmewin] Sandisk patch delay In-Reply-To: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> Message-ID: <4565AEA676113A449269C2F3A549520FDBB1FBD5@cosmail03.lsi.com> Hi Ray, We also have the patch for Trim. It is ready to send. Please let me know when you would like me to send out. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:image001.png at 01CE607B.63C1EB20] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From Alex.Chang at idt.com Mon Jun 3 16:57:13 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Mon, 3 Jun 2013 23:57:13 +0000 Subject: [nvmewin] ***UNCHECKED*** RE: Sandisk patch delay In-Reply-To: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFEE41E@corpmail1.na.ads.idt.com> Hi all, I had modified nvme.h and nvmeReg.h to be compliant with NVMe specification 1.0e. Please find the patch in the attachment, review the changes and send out your feedbacks as soon as possible. Password is "idt1234". Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: source_IDT_06_03_2013.zip Type: application/x-zip-compressed Size: 165788 bytes Desc: source_IDT_06_03_2013.zip URL: From raymond.c.robles at intel.com Mon Jun 3 17:11:42 2013 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Tue, 4 Jun 2013 00:11:42 +0000 Subject: [nvmewin] Sandisk patch delay In-Reply-To: <4565AEA676113A449269C2F3A549520FDBB1FBD5@cosmail03.lsi.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBB1FBD5@cosmail03.lsi.com> Message-ID: <49158E750348AA499168FD41D88983606257AEE1@FMSMSX105.amr.corp.intel.com> Hi Rick, That's great news! LSI will be 3rd in line after IDT and Intel. Thanks for the contributions to TRIM. Thanks, Ray From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Ray, We also have the patch for Trim. It is ready to send. Please let me know when you would like me to send out. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From Gurpreet.Anand at sandisk.com Mon Jun 3 17:44:34 2013 From: Gurpreet.Anand at sandisk.com (Gurpreet Anand) Date: Tue, 4 Jun 2013 00:44:34 +0000 Subject: [nvmewin] Sandisk patch delay In-Reply-To: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> Message-ID: We apologize for the delay. Dharani is OOO and will be back next week and we should be able to submit the patch once he is back. From: , Raymond C > Date: Monday, June 3, 2013 4:44 PM To: "nvmewin at lists.openfabrics.org" > Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I’m going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he’d like to push and I also have a patch I’d like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 ________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From Rick.Knoblaugh at lsi.com Tue Jun 4 14:09:48 2013 From: Rick.Knoblaugh at lsi.com (Knoblaugh, Rick) Date: Tue, 4 Jun 2013 15:09:48 -0600 Subject: [nvmewin] Sandisk patch delay In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFEE41E@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEE41E@corpmail1.na.ads.idt.com> Message-ID: <4565AEA676113A449269C2F3A549520FDBBD2977@cosmail03.lsi.com> Hi Alex, These look to be compliant with spec, so should be good. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** RE: Sandisk patch delay Hi all, I had modified nvme.h and nvmeReg.h to be compliant with NVMe specification 1.0e. Please find the patch in the attachment, review the changes and send out your feedbacks as soon as possible. Password is "idt1234". Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:image001.png at 01CE612D.2C0C76C0] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From Alex.Chang at idt.com Tue Jun 4 14:12:43 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Tue, 4 Jun 2013 21:12:43 +0000 Subject: [nvmewin] Sandisk patch delay In-Reply-To: <4565AEA676113A449269C2F3A549520FDBBD2977@cosmail03.lsi.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEE41E@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520FDBBD2977@cosmail03.lsi.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFEE51E@corpmail1.na.ads.idt.com> Thanks a lot, Rick. Hi Ray, Are you fine with the changes? Thanks, Alex ________________________________ From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Tuesday, June 04, 2013 2:10 PM To: Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Alex, These look to be compliant with spec, so should be good. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** RE: Sandisk patch delay Hi all, I had modified nvme.h and nvmeReg.h to be compliant with NVMe specification 1.0e. Please find the patch in the attachment, review the changes and send out your feedbacks as soon as possible. Password is "idt1234". Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From raymond.c.robles at intel.com Wed Jun 5 20:52:58 2013 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Thu, 6 Jun 2013 03:52:58 +0000 Subject: [nvmewin] Sandisk patch delay In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFEE51E@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEE41E@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520FDBBD2977@cosmail03.lsi.com> <548C5470AAD9DA4A85D259B663190D361FFEE51E@corpmail1.na.ads.idt.com> Message-ID: <49158E750348AA499168FD41D88983606257C53C@FMSMSX105.amr.corp.intel.com> Hi Alex, Everything looks good. I'll push the patch and send mine out tomorrow. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 04, 2013 2:13 PM To: Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Thanks a lot, Rick. Hi Ray, Are you fine with the changes? Thanks, Alex ________________________________ From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Tuesday, June 04, 2013 2:10 PM To: Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Alex, These look to be compliant with spec, so should be good. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** RE: Sandisk patch delay Hi all, I had modified nvme.h and nvmeReg.h to be compliant with NVMe specification 1.0e. Please find the patch in the attachment, review the changes and send out your feedbacks as soon as possible. Password is "idt1234". Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From Alex.Chang at idt.com Thu Jun 6 12:28:04 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Thu, 6 Jun 2013 19:28:04 +0000 Subject: [nvmewin] Sandisk patch delay In-Reply-To: <49158E750348AA499168FD41D88983606257C53C@FMSMSX105.amr.corp.intel.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEE41E@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520FDBBD2977@cosmail03.lsi.com> <548C5470AAD9DA4A85D259B663190D361FFEE51E@corpmail1.na.ads.idt.com>, <49158E750348AA499168FD41D88983606257C53C@FMSMSX105.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFEE78A@corpmail1.na.ads.idt.com> Thanks, Ray. Alex ________________________________________ From: Robles, Raymond C [raymond.c.robles at intel.com] Sent: Wednesday, June 05, 2013 8:52 PM To: Chang, Alex; Knoblaugh, Rick; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Alex, Everything looks good. I’ll push the patch and send mine out tomorrow. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 04, 2013 2:13 PM To: Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Thanks a lot, Rick. Hi Ray, Are you fine with the changes? Thanks, Alex ________________________________ From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Tuesday, June 04, 2013 2:10 PM To: Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Alex, These look to be compliant with spec, so should be good. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** RE: Sandisk patch delay Hi all, I had modified nvme.h and nvmeReg.h to be compliant with NVMe specification 1.0e. Please find the patch in the attachment, review the changes and send out your feedbacks as soon as possible. Password is "idt1234". Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I’m going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he’d like to push and I also have a patch I’d like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From raymond.c.robles at intel.com Thu Jun 6 13:39:37 2013 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Thu, 6 Jun 2013 20:39:37 +0000 Subject: [nvmewin] NVMe Windows repo is LOCKED - Pushing IDT fix for NVMe 1.0e compliance Message-ID: <49158E750348AA499168FD41D88983606257CA03@FMSMSX105.amr.corp.intel.com> Locking the Windows NVMe repo. Pushing Alex's (IDT) fix for NVMe 1.0e compliance. Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From raymond.c.robles at intel.com Thu Jun 6 13:55:25 2013 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Thu, 6 Jun 2013 20:55:25 +0000 Subject: [nvmewin] NVMe Windows repo is UNLOCKED - Pushing IDT fix for NVMe 1.0e compliance Message-ID: <49158E750348AA499168FD41D88983606257CA4A@FMSMSX105.amr.corp.intel.com> All, Latest patch from IDT (NVMe 1.0e compliance) has been pushed to trunk. New tag created - IDT_NVMe_1_0_e_compliance. I will be sending out a patch today for review from Intel (accessing NVMe registers on aligned 32 bit boundaries). If anyone has any questions, please feel free to contact me. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, June 06, 2013 1:40 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] NVMe Windows repo is LOCKED - Pushing IDT fix for NVMe 1.0e compliance Locking the Windows NVMe repo. Pushing Alex's (IDT) fix for NVMe 1.0e compliance. Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From raymond.c.robles at intel.com Thu Jun 6 14:00:52 2013 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Thu, 6 Jun 2013 21:00:52 +0000 Subject: [nvmewin] OFA NVMe Windows Maintainer Coverage Message-ID: <49158E750348AA499168FD41D88983606257CA69@FMSMSX105.amr.corp.intel.com> Hello all, I just wanted to send out a quick email informing this distribution list that I will be going on sabbatical starting next week. I will be gone from June 10th to August 4th. During my absence, Alex Change from IDT (alex.chang at idt.com) will be the acting OFA Windows NVMe maintainer. Please direct any and all maintainer issues to him. For questions on the driver in general, please use this distribution list. And for general technical questions on NVM Express, please use the NVMe working group distribution list (technical at nvmeexpress.org). Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From Kwok.Kong at idt.com Fri Jun 7 10:01:06 2013 From: Kwok.Kong at idt.com (Kong, Kwok) Date: Fri, 7 Jun 2013 17:01:06 +0000 Subject: [nvmewin] Review Driver Development Status - Sorry, I have to reschedule Message-ID: <05CD7821AE397547A01AC160FBC231474BCAB8DB@corpmail1.na.ads.idt.com> When: Monday, June 17, 2013 1:00 PM-2:00 PM (UTC-08:00) Pacific Time (US & Canada). Where: Conf call Note: The GMT offset above does not reflect daylight saving time adjustments. *~*~*~*~*~*~*~*~*~* You are invited to attend an AT&T Connect iMeeting . To connect to the Web Conference: ============================= Click here: https://connect9.uc.att.com/service32/meet/?ExEventID=8811938&CT=M TO CONNECT WITH YOUR *TELEPHONE ONLY* (no computer): =================================================== 1. Choose one of the following numbers to dial: If you are calling from an office location with on-site number(s) (listed below), try this number first. If you do not have on-site access, or you are not a member of the host's company/organization, use one of the other numbers shown. * Caller-Paid number: 602-333-0032 * Toll-Free Number (in USA): 888-270-9936. * Blackberry (Caller-Paid): 6023330032x811938# * A number in your country or in a country close to you (may be toll free): https://www.teleconference.att.com/servlet/glbAccess?process=1&accessNumber=8882709936&accessCode=811938 2. When prompted, enter the Meeting Access Code: 811938# To prepare in advance for the conference (for all devices): https://connect9.uc.att.com/service32/Prepare/. To view supported Operating Systems and devices: http://www.uc.att.com/support/SupportedDevices.html Powered by AT&T Connect. Agenda: - Review Release 1.2 Status o - Supports the following Windows versions in addition to Windows 7 - 64 bits (IDT) o - Windows 8 64-bit o - Windows Server 2008R2 64-bit o - Windows Server 2012 64-bit o o - TRIM command support (LSI) o - NVMe 1.00e enhancement (IDT) o - Hibernation as a boot drive (Huawei) - Review Known problems Status - Not Accessing NVMe registers in their native width. (Ray - Intel) - ModeSense Translation issue. (Dharani - SanDisk) - format nvm error. (Judy - Samsung) - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset. (Judy - Samsung) - SCSI Translation Update (Yong Chen - Huawei) - Release 1.3 Discussion - Support additional Windows versions - Windows 7 32-bit - Windows 8 32-bit - Windows 8 features: - Extended SRB format - SMART handling via new Extended SRB format Features that will not be supported in 2013 (will be reviewed mid-year): NVMe 1.1 support: - multi-path - SGL - Get/Set feature update - Autonomous power state transition - Host Identifier - Reservation Notification Mask - Reservation Persistence - identify structure update - write zeros command Other feature: - End-to-end protection (Server 2012 support this) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 6399 bytes Desc: not available URL: From Rick.Knoblaugh at lsi.com Fri Jun 7 18:37:31 2013 From: Rick.Knoblaugh at lsi.com (Knoblaugh, Rick) Date: Fri, 7 Jun 2013 19:37:31 -0600 Subject: [nvmewin] ***UNCHECKED*** LSI Trim Patch In-Reply-To: <49158E750348AA499168FD41D88983606257AEE1@FMSMSX105.amr.corp.intel.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBB1FBD5@cosmail03.lsi.com> <49158E750348AA499168FD41D88983606257AEE1@FMSMSX105.amr.corp.intel.com> Message-ID: <4565AEA676113A449269C2F3A549520FDBBD3022@cosmail03.lsi.com> Hi Ray, Per your request, since we will switch order, moving Intel patch to the number 3 position, I'm sending LSI's Trim patch. Password for the attached file is: lsi1234. Also, I have attached a document here that describes what was changed/added. It would be great if everyone can review and please let me know any feedback. Thanks. -Rick From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 03, 2013 5:12 PM To: Knoblaugh, Rick; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Rick, That's great news! LSI will be 3rd in line after IDT and Intel. Thanks for the contributions to TRIM. Thanks, Ray From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Ray, We also have the patch for Trim. It is ready to send. Please let me know when you would like me to send out. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:image001.png at 01CE63AC.B10EB960] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LSI_trim_patch_ver1.zip Type: application/x-zip-compressed Size: 167204 bytes Desc: LSI_trim_patch_ver1.zip URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Windows NVMe Driver Trim Support ver .01.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 23194 bytes Desc: Windows NVMe Driver Trim Support ver .01.docx URL: From Sumant.Patro at sandisk.com Tue Jun 11 11:01:00 2013 From: Sumant.Patro at sandisk.com (Sumant Patro) Date: Tue, 11 Jun 2013 18:01:00 +0000 Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFEE32C@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D88983606256082A@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFE961C@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062560AA2@FMSMSX105.amr.corp.intel.com> <49158E750348AA499168FD41D889836062578A2D@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEC067@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062578B98@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEE32C@corpmail1.na.ads.idt.com> Message-ID: Hello Alex, Thanks for the feedback. Please find attached the patch that fixes the SCSI compliance test for MODE SENSE. Attached is also the log of a successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, June 03, 2013 2:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I retested the patch with SCSICompliance and it results a new failure: MODE SENSE (6) Comparing MODE PAGE data before and after DBD bit is set. Could you test it to see if you can replicate it? You may find more details in the attachment. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 30, 2013 3:20 PM To: Robles, Raymond C; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Ray, Please find attached the patch that has fix for the last code review comment. This is the patch set that I had sent to Alex earlier. Password : sndk1234 Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 3:10 PM To: Chang, Alex; Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thanks Alex. Sumant, please continue with your updates from the last set of code review comments and resend the patch (after running all the required unit tests of course). Once we confirm the feedback changes are in place, I’ll push the patch. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 30, 2013 3:07 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Actually I did some preliminary debugging on it and found out the crash was not introduced by your patch. When the system gets normal shutdown, NVMeNormalShutdown calls NVMeFreeBuffers to free up all queue related structures. And later, when NVMeDetectPendingCmds is called to check on the pending commands, it refers to the queue structures and causes the crash. I will include the fix in my next patch that includes changes to be compliant with 1.0e NVMe Specification. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 30, 2013 2:11 PM To: Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hello Alex, I haven’t been able to repro the BSOD issue that you saw in your setup. Would it be possible for you to send me the crashdump please ? Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 1:24 PM To: Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Importance: High Dharani/Sumant, What is the status on this patch? I’ve not seen any follow up to my last email below. Hopefully we can close this out soon as there are other patches waiting to be submitted. Thanks for your quick attention. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, May 16, 2013 3:49 PM To: Chang, Alex; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Actually, I was going to type the same thing in my email below and then got derailed with the whole #define issue (thanks for capturing this Alex). There is no DataTransferLength field in the SRB Extension structure. That is defined in the SRB by Storport. As a general courtesy to other companies who are reviewing these patches, please insure that you are compiling and re-testing your patch prior to sending out for secondary or additional code reviews. This will help save valuable time in the code review process. If you are having issues compiling, or do not see the same errors, please contact me. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 16, 2013 3:44 PM To: Robles, Raymond C; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, The only change you've made in the new patch is replacing: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); with: memset(GET_DATA_BUFFER(pSrb), 0, min(pSrbExt->DataTransferLength, allocLength)); However, it generates compiling error because DataTransferLength is not a member of NVME_SRB_EXTENSION structure. Could you please fix it? Thanks a lot for you help, Alex ________________________________ From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 16, 2013 1:37 PM To: Sumant Patro; Knoblaugh, Rick; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant/Dharani, Thanks for the updated patch. A couple of comments/questions: - For all the mode sense page translations, the new temp buffer allocated in the SRB extension is used. But for the Modes Sense 0x3C (all mode pages), the SRB data buffer is still memset to 0 at the beginning of SntiReturnAllModePages(). I’m not sure we still need to do this considering how the temp buffer is used to build the mode sense data. - If you insist on keeping that memset in there, there is a #define in for all mode pages - MODE_SENSE_ALL_PAGES_LENGTH. It may be better to zero out the buffer based on the min between this define and allocLength. SRB data transfer length cannot be relied on for “data-in” commands (like mode sense). Thanks, Ray From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 16, 2013 12:43 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Sorry, sent the wrong zip in the previous mail. Please ignore the previous attachment. Attached is the updated zip file. Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 16, 2013 12:38 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Thanks Rick, Alex for your feedback. Please find attached updated files with following two changes : 1. Comment in header of SntiCreateModeDataHeader function changed to reflect passing of srb extension 2. memset(GET_DATA_BUFFER(pSrb), 0, allocLength); modified to use minimum of allocLength and DataTransferLength in SntiReturnAllModePages(..) Password : sndk1234 Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Thursday, May 16, 2013 11:59 AM To: Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, When you change that one, may as well fix the comment in header of SntiCreateModeDataHeader function to reflect that srb extension is now the parameter that’s passed in. Other stuff looks good. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, May 16, 2013 10:58 AM To: Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, I tested your new patch and experienced a D1 bugcheck while running SCSICompliance test. Some preliminary debugging leads to Line#3633 of nvmestni.c, where it looks like: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); The bugcheck happens when the value of "allocLength" is 0x1000. Apparently, the allocated length in CDB is somewhat a bogus value that is meant to test how driver handles it. Could you please fix it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Wednesday, May 01, 2013 8:56 AM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Ray, I have incorporated the changes according to your suggestions, I tried to keep up with the coding convention please feel free to let me know if anything has to be changed. I have incorporated one more fix in the nvmeInit.c which can lead to memory corruptions and used the SrbExt for the buffer allocation. PassWd: sndk1234 Thanks, Dharani. From: Dharani Kotte Sent: Tuesday, April 30, 2013 12:03 PM To: 'Robles, Raymond C'; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thank you for the feedback, I agree that the global buffer is not good I have made the changes to allocate this buffer from the srbext I will provide the code with the below modifications soon. Thanks, Dharani. From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, April 30, 2013 11:52 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, Thank you for putting this patch together. Please see my feedback below: - Line 52: Note that we have a file called nvmeSntiTypes.h. This file contains all #defines. As per our existing convention, all #defines should be placed in this file (versus at the top of a .c file). - Line 3339/3412/3502/3593/3756/5391/5433/5442/5453: Our coding convention states no line be longer than 80 characters. These lines all exceed 80 characters. - Line 5410: SntiTranslateAllModePagesResponse() contains new if-else blocks. Our coding convention dictates that open curly braces be placed on the same line as the if or else statement. You can refer to other instances of the code and if-else clauses as examples. - Line 4017: SntiCreateModeDataHeader() no longer needs the SRB pointer to be passed in as a parameter since you are using a global temp buffer to build up the mode sense data. That parameter can be removed. - General: The method of using a global buffer for a single mode sense command opens up a potential race condition for multiple mode sense commands submitted on top of each other. The idea behind putting the SCSI to NVMe translation phase in the HwStorBuildIo phase was to help performance. We initially knew that we would never be sharing any data structures or memory in calls to BuildIo. There is no spinlock or protection for calls to BuildIo and MSDN makes it clear that these BuildIo calls are not synchronized and that any synchronization of memory/data must be done within the function implementations or just use StartIo instead (since Storport will acquire the StartIoSpinLock). So there is hole here w/r/t the global buffer being populated for multiple mode sense commands at the same time. I believe you have the right idea, but the correct solution is to create a temp mode sense buffer inside the SRB extension. This way, each command has its own temp mode sense buffer for building the mode sense response, and then when ready to copy over to the SRB data buffer, it’s pulling from a buffer that can only be accessed by the current command (instead of a global buffer that may have been overwritten by another mode sense request call from another BuildIo call). Note that the driver collaboration group made the decision to never acquire any type of lock in BuildIo. Let me know if you have questions on this solution. The additional size to the SRB extension is not an issue. This fix is critical for this patch to be accepted. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 11:14 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Attaching the code with according to Alex suggestion. Passwd: sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, April 30, 2013 9:23 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, I'd suggest that it's safer to initialize gModeSenseBuf as all zeros each time before it is used, just in case there are some unexpected data in the buffer. Other than that, I am fine with the patch. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 8:37 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] New Patch From Sandisk Hi all, It's been almost two weeks after I sent out the patch. please let us know if you're okay with it. Thanks, Dharani. From: Dharani Kotte Sent: Friday, April 12, 2013 9:58 AM To: nvmewin at lists.openfabrics.org Subject: New Patch From Sandisk Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeSnti.c a. Allocate a global buffer of 256bytes size for modesense return data preparation b. For any mode sense this buffer is used for modesense data along with the requested pages in it. c. Copy the required data according to the alloc_length requested in the cdb to the Srb->DataBuffer and update the dataTransferLength accordingly d. In function SntiTranslateReturnAllModePagesResponse() the modesense data header offset is calculated wrong which ends up in BSOD in some cases modified code to fix this issue 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, 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). CAUTION: Please confirm that the password protected .zip attachment which contains the file(s) of type source_sndk_05_16_2013.zip is legitimate prior to opening. To make sure this message is not infected with a virus, it is important to verify that you are expecting the message or else confirm its legitimacy with the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: source_sndk_06_11_2013.zip Type: application/x-zip-compressed Size: 199255 bytes Desc: source_sndk_06_11_2013.zip URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: scsicompliance.wtl.txt URL: From Alex.Chang at idt.com Tue Jun 11 14:14:24 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Tue, 11 Jun 2013 21:14:24 +0000 Subject: [nvmewin] New Patch From Sandisk In-Reply-To: References: <49158E750348AA499168FD41D88983606256082A@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFE961C@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062560AA2@FMSMSX105.amr.corp.intel.com> <49158E750348AA499168FD41D889836062578A2D@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEC067@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062578B98@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEE32C@corpmail1.na.ads.idt.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFEEB8A@corpmail1.na.ads.idt.com> Hi Sumant, Currently, we are reviewing the patch from LSI, which adds supporting for TRIM command. Once Intel and IDT approve it, the patch will be added first. Then we will review your patch. However, you need to re-base to include the recent patches from IDT and LSI first and re-send your patch out. Thanks you very much and please let me know if you have questions. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 11:01 AM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Alex, Thanks for the feedback. Please find attached the patch that fixes the SCSI compliance test for MODE SENSE. Attached is also the log of a successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, June 03, 2013 2:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I retested the patch with SCSICompliance and it results a new failure: MODE SENSE (6) Comparing MODE PAGE data before and after DBD bit is set. Could you test it to see if you can replicate it? You may find more details in the attachment. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 30, 2013 3:20 PM To: Robles, Raymond C; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Ray, Please find attached the patch that has fix for the last code review comment. This is the patch set that I had sent to Alex earlier. Password : sndk1234 Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 3:10 PM To: Chang, Alex; Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thanks Alex. Sumant, please continue with your updates from the last set of code review comments and resend the patch (after running all the required unit tests of course). Once we confirm the feedback changes are in place, I’ll push the patch. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 30, 2013 3:07 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Actually I did some preliminary debugging on it and found out the crash was not introduced by your patch. When the system gets normal shutdown, NVMeNormalShutdown calls NVMeFreeBuffers to free up all queue related structures. And later, when NVMeDetectPendingCmds is called to check on the pending commands, it refers to the queue structures and causes the crash. I will include the fix in my next patch that includes changes to be compliant with 1.0e NVMe Specification. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 30, 2013 2:11 PM To: Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hello Alex, I haven’t been able to repro the BSOD issue that you saw in your setup. Would it be possible for you to send me the crashdump please ? Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 1:24 PM To: Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Importance: High Dharani/Sumant, What is the status on this patch? I’ve not seen any follow up to my last email below. Hopefully we can close this out soon as there are other patches waiting to be submitted. Thanks for your quick attention. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, May 16, 2013 3:49 PM To: Chang, Alex; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Actually, I was going to type the same thing in my email below and then got derailed with the whole #define issue (thanks for capturing this Alex). There is no DataTransferLength field in the SRB Extension structure. That is defined in the SRB by Storport. As a general courtesy to other companies who are reviewing these patches, please insure that you are compiling and re-testing your patch prior to sending out for secondary or additional code reviews. This will help save valuable time in the code review process. If you are having issues compiling, or do not see the same errors, please contact me. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 16, 2013 3:44 PM To: Robles, Raymond C; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, The only change you've made in the new patch is replacing: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); with: memset(GET_DATA_BUFFER(pSrb), 0, min(pSrbExt->DataTransferLength, allocLength)); However, it generates compiling error because DataTransferLength is not a member of NVME_SRB_EXTENSION structure. Could you please fix it? Thanks a lot for you help, Alex ________________________________ From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 16, 2013 1:37 PM To: Sumant Patro; Knoblaugh, Rick; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant/Dharani, Thanks for the updated patch. A couple of comments/questions: - For all the mode sense page translations, the new temp buffer allocated in the SRB extension is used. But for the Modes Sense 0x3C (all mode pages), the SRB data buffer is still memset to 0 at the beginning of SntiReturnAllModePages(). I’m not sure we still need to do this considering how the temp buffer is used to build the mode sense data. - If you insist on keeping that memset in there, there is a #define in for all mode pages - MODE_SENSE_ALL_PAGES_LENGTH. It may be better to zero out the buffer based on the min between this define and allocLength. SRB data transfer length cannot be relied on for “data-in” commands (like mode sense). Thanks, Ray From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 16, 2013 12:43 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Sorry, sent the wrong zip in the previous mail. Please ignore the previous attachment. Attached is the updated zip file. Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 16, 2013 12:38 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Thanks Rick, Alex for your feedback. Please find attached updated files with following two changes : 1. Comment in header of SntiCreateModeDataHeader function changed to reflect passing of srb extension 2. memset(GET_DATA_BUFFER(pSrb), 0, allocLength); modified to use minimum of allocLength and DataTransferLength in SntiReturnAllModePages(..) Password : sndk1234 Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Thursday, May 16, 2013 11:59 AM To: Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, When you change that one, may as well fix the comment in header of SntiCreateModeDataHeader function to reflect that srb extension is now the parameter that’s passed in. Other stuff looks good. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, May 16, 2013 10:58 AM To: Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, I tested your new patch and experienced a D1 bugcheck while running SCSICompliance test. Some preliminary debugging leads to Line#3633 of nvmestni.c, where it looks like: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); The bugcheck happens when the value of "allocLength" is 0x1000. Apparently, the allocated length in CDB is somewhat a bogus value that is meant to test how driver handles it. Could you please fix it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Wednesday, May 01, 2013 8:56 AM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Ray, I have incorporated the changes according to your suggestions, I tried to keep up with the coding convention please feel free to let me know if anything has to be changed. I have incorporated one more fix in the nvmeInit.c which can lead to memory corruptions and used the SrbExt for the buffer allocation. PassWd: sndk1234 Thanks, Dharani. From: Dharani Kotte Sent: Tuesday, April 30, 2013 12:03 PM To: 'Robles, Raymond C'; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thank you for the feedback, I agree that the global buffer is not good I have made the changes to allocate this buffer from the srbext I will provide the code with the below modifications soon. Thanks, Dharani. From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, April 30, 2013 11:52 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, Thank you for putting this patch together. Please see my feedback below: - Line 52: Note that we have a file called nvmeSntiTypes.h. This file contains all #defines. As per our existing convention, all #defines should be placed in this file (versus at the top of a .c file). - Line 3339/3412/3502/3593/3756/5391/5433/5442/5453: Our coding convention states no line be longer than 80 characters. These lines all exceed 80 characters. - Line 5410: SntiTranslateAllModePagesResponse() contains new if-else blocks. Our coding convention dictates that open curly braces be placed on the same line as the if or else statement. You can refer to other instances of the code and if-else clauses as examples. - Line 4017: SntiCreateModeDataHeader() no longer needs the SRB pointer to be passed in as a parameter since you are using a global temp buffer to build up the mode sense data. That parameter can be removed. - General: The method of using a global buffer for a single mode sense command opens up a potential race condition for multiple mode sense commands submitted on top of each other. The idea behind putting the SCSI to NVMe translation phase in the HwStorBuildIo phase was to help performance. We initially knew that we would never be sharing any data structures or memory in calls to BuildIo. There is no spinlock or protection for calls to BuildIo and MSDN makes it clear that these BuildIo calls are not synchronized and that any synchronization of memory/data must be done within the function implementations or just use StartIo instead (since Storport will acquire the StartIoSpinLock). So there is hole here w/r/t the global buffer being populated for multiple mode sense commands at the same time. I believe you have the right idea, but the correct solution is to create a temp mode sense buffer inside the SRB extension. This way, each command has its own temp mode sense buffer for building the mode sense response, and then when ready to copy over to the SRB data buffer, it’s pulling from a buffer that can only be accessed by the current command (instead of a global buffer that may have been overwritten by another mode sense request call from another BuildIo call). Note that the driver collaboration group made the decision to never acquire any type of lock in BuildIo. Let me know if you have questions on this solution. The additional size to the SRB extension is not an issue. This fix is critical for this patch to be accepted. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 11:14 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Attaching the code with according to Alex suggestion. Passwd: sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, April 30, 2013 9:23 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, I'd suggest that it's safer to initialize gModeSenseBuf as all zeros each time before it is used, just in case there are some unexpected data in the buffer. Other than that, I am fine with the patch. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 8:37 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] New Patch From Sandisk Hi all, It's been almost two weeks after I sent out the patch. please let us know if you're okay with it. Thanks, Dharani. From: Dharani Kotte Sent: Friday, April 12, 2013 9:58 AM To: nvmewin at lists.openfabrics.org Subject: New Patch From Sandisk Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeSnti.c a. Allocate a global buffer of 256bytes size for modesense return data preparation b. For any mode sense this buffer is used for modesense data along with the requested pages in it. c. Copy the required data according to the alloc_length requested in the cdb to the Srb->DataBuffer and update the dataTransferLength accordingly d. In function SntiTranslateReturnAllModePagesResponse() the modesense data header offset is calculated wrong which ends up in BSOD in some cases modified code to fix this issue 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, 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). CAUTION: Please confirm that the password protected .zip attachment which contains the file(s) of type source_sndk_05_16_2013.zip is legitimate prior to opening. To make sure this message is not infected with a virus, it is important to verify that you are expecting the message or else confirm its legitimacy with the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Tue Jun 11 15:11:33 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Tue, 11 Jun 2013 22:11:33 +0000 Subject: [nvmewin] LSI Trim Patch In-Reply-To: <4565AEA676113A449269C2F3A549520FDBBD3022@cosmail03.lsi.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBB1FBD5@cosmail03.lsi.com> <49158E750348AA499168FD41D88983606257AEE1@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBBD3022@cosmail03.lsi.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFEEBA3@corpmail1.na.ads.idt.com> Hi Rick, After the driver being built with Windows 8 WDK, does it work on Windows 7 and the others? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Friday, June 07, 2013 6:38 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** LSI Trim Patch Hi Ray, Per your request, since we will switch order, moving Intel patch to the number 3 position, I'm sending LSI's Trim patch. Password for the attached file is: lsi1234. Also, I have attached a document here that describes what was changed/added. It would be great if everyone can review and please let me know any feedback. Thanks. -Rick From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 03, 2013 5:12 PM To: Knoblaugh, Rick; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Rick, That's great news! LSI will be 3rd in line after IDT and Intel. Thanks for the contributions to TRIM. Thanks, Ray From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Ray, We also have the patch for Trim. It is ready to send. Please let me know when you would like me to send out. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From Sumant.Patro at sandisk.com Tue Jun 11 15:23:50 2013 From: Sumant.Patro at sandisk.com (Sumant Patro) Date: Tue, 11 Jun 2013 22:23:50 +0000 Subject: [nvmewin] New Patch From Sandisk In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFEEB8A@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D88983606256082A@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFE961C@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062560AA2@FMSMSX105.amr.corp.intel.com> <49158E750348AA499168FD41D889836062578A2D@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEC067@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062578B98@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEE32C@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFEEB8A@corpmail1.na.ads.idt.com> Message-ID: Hello Alex, Sure, no problem. We will wait for the patches in the pipeline to be accepted and then rebase and resubmit the patch. Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 2:14 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Currently, we are reviewing the patch from LSI, which adds supporting for TRIM command. Once Intel and IDT approve it, the patch will be added first. Then we will review your patch. However, you need to re-base to include the recent patches from IDT and LSI first and re-send your patch out. Thanks you very much and please let me know if you have questions. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 11:01 AM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Alex, Thanks for the feedback. Please find attached the patch that fixes the SCSI compliance test for MODE SENSE. Attached is also the log of a successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, June 03, 2013 2:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I retested the patch with SCSICompliance and it results a new failure: MODE SENSE (6) Comparing MODE PAGE data before and after DBD bit is set. Could you test it to see if you can replicate it? You may find more details in the attachment. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 30, 2013 3:20 PM To: Robles, Raymond C; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Ray, Please find attached the patch that has fix for the last code review comment. This is the patch set that I had sent to Alex earlier. Password : sndk1234 Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 3:10 PM To: Chang, Alex; Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thanks Alex. Sumant, please continue with your updates from the last set of code review comments and resend the patch (after running all the required unit tests of course). Once we confirm the feedback changes are in place, I’ll push the patch. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 30, 2013 3:07 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Actually I did some preliminary debugging on it and found out the crash was not introduced by your patch. When the system gets normal shutdown, NVMeNormalShutdown calls NVMeFreeBuffers to free up all queue related structures. And later, when NVMeDetectPendingCmds is called to check on the pending commands, it refers to the queue structures and causes the crash. I will include the fix in my next patch that includes changes to be compliant with 1.0e NVMe Specification. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 30, 2013 2:11 PM To: Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hello Alex, I haven’t been able to repro the BSOD issue that you saw in your setup. Would it be possible for you to send me the crashdump please ? Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 1:24 PM To: Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Importance: High Dharani/Sumant, What is the status on this patch? I’ve not seen any follow up to my last email below. Hopefully we can close this out soon as there are other patches waiting to be submitted. Thanks for your quick attention. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, May 16, 2013 3:49 PM To: Chang, Alex; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Actually, I was going to type the same thing in my email below and then got derailed with the whole #define issue (thanks for capturing this Alex). There is no DataTransferLength field in the SRB Extension structure. That is defined in the SRB by Storport. As a general courtesy to other companies who are reviewing these patches, please insure that you are compiling and re-testing your patch prior to sending out for secondary or additional code reviews. This will help save valuable time in the code review process. If you are having issues compiling, or do not see the same errors, please contact me. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 16, 2013 3:44 PM To: Robles, Raymond C; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, The only change you've made in the new patch is replacing: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); with: memset(GET_DATA_BUFFER(pSrb), 0, min(pSrbExt->DataTransferLength, allocLength)); However, it generates compiling error because DataTransferLength is not a member of NVME_SRB_EXTENSION structure. Could you please fix it? Thanks a lot for you help, Alex ________________________________ From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 16, 2013 1:37 PM To: Sumant Patro; Knoblaugh, Rick; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant/Dharani, Thanks for the updated patch. A couple of comments/questions: - For all the mode sense page translations, the new temp buffer allocated in the SRB extension is used. But for the Modes Sense 0x3C (all mode pages), the SRB data buffer is still memset to 0 at the beginning of SntiReturnAllModePages(). I’m not sure we still need to do this considering how the temp buffer is used to build the mode sense data. - If you insist on keeping that memset in there, there is a #define in for all mode pages - MODE_SENSE_ALL_PAGES_LENGTH. It may be better to zero out the buffer based on the min between this define and allocLength. SRB data transfer length cannot be relied on for “data-in” commands (like mode sense). Thanks, Ray From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 16, 2013 12:43 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Sorry, sent the wrong zip in the previous mail. Please ignore the previous attachment. Attached is the updated zip file. Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 16, 2013 12:38 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Thanks Rick, Alex for your feedback. Please find attached updated files with following two changes : 1. Comment in header of SntiCreateModeDataHeader function changed to reflect passing of srb extension 2. memset(GET_DATA_BUFFER(pSrb), 0, allocLength); modified to use minimum of allocLength and DataTransferLength in SntiReturnAllModePages(..) Password : sndk1234 Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Thursday, May 16, 2013 11:59 AM To: Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, When you change that one, may as well fix the comment in header of SntiCreateModeDataHeader function to reflect that srb extension is now the parameter that’s passed in. Other stuff looks good. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, May 16, 2013 10:58 AM To: Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, I tested your new patch and experienced a D1 bugcheck while running SCSICompliance test. Some preliminary debugging leads to Line#3633 of nvmestni.c, where it looks like: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); The bugcheck happens when the value of "allocLength" is 0x1000. Apparently, the allocated length in CDB is somewhat a bogus value that is meant to test how driver handles it. Could you please fix it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Wednesday, May 01, 2013 8:56 AM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Ray, I have incorporated the changes according to your suggestions, I tried to keep up with the coding convention please feel free to let me know if anything has to be changed. I have incorporated one more fix in the nvmeInit.c which can lead to memory corruptions and used the SrbExt for the buffer allocation. PassWd: sndk1234 Thanks, Dharani. From: Dharani Kotte Sent: Tuesday, April 30, 2013 12:03 PM To: 'Robles, Raymond C'; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thank you for the feedback, I agree that the global buffer is not good I have made the changes to allocate this buffer from the srbext I will provide the code with the below modifications soon. Thanks, Dharani. From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, April 30, 2013 11:52 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, Thank you for putting this patch together. Please see my feedback below: - Line 52: Note that we have a file called nvmeSntiTypes.h. This file contains all #defines. As per our existing convention, all #defines should be placed in this file (versus at the top of a .c file). - Line 3339/3412/3502/3593/3756/5391/5433/5442/5453: Our coding convention states no line be longer than 80 characters. These lines all exceed 80 characters. - Line 5410: SntiTranslateAllModePagesResponse() contains new if-else blocks. Our coding convention dictates that open curly braces be placed on the same line as the if or else statement. You can refer to other instances of the code and if-else clauses as examples. - Line 4017: SntiCreateModeDataHeader() no longer needs the SRB pointer to be passed in as a parameter since you are using a global temp buffer to build up the mode sense data. That parameter can be removed. - General: The method of using a global buffer for a single mode sense command opens up a potential race condition for multiple mode sense commands submitted on top of each other. The idea behind putting the SCSI to NVMe translation phase in the HwStorBuildIo phase was to help performance. We initially knew that we would never be sharing any data structures or memory in calls to BuildIo. There is no spinlock or protection for calls to BuildIo and MSDN makes it clear that these BuildIo calls are not synchronized and that any synchronization of memory/data must be done within the function implementations or just use StartIo instead (since Storport will acquire the StartIoSpinLock). So there is hole here w/r/t the global buffer being populated for multiple mode sense commands at the same time. I believe you have the right idea, but the correct solution is to create a temp mode sense buffer inside the SRB extension. This way, each command has its own temp mode sense buffer for building the mode sense response, and then when ready to copy over to the SRB data buffer, it’s pulling from a buffer that can only be accessed by the current command (instead of a global buffer that may have been overwritten by another mode sense request call from another BuildIo call). Note that the driver collaboration group made the decision to never acquire any type of lock in BuildIo. Let me know if you have questions on this solution. The additional size to the SRB extension is not an issue. This fix is critical for this patch to be accepted. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 11:14 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Attaching the code with according to Alex suggestion. Passwd: sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, April 30, 2013 9:23 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, I'd suggest that it's safer to initialize gModeSenseBuf as all zeros each time before it is used, just in case there are some unexpected data in the buffer. Other than that, I am fine with the patch. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 8:37 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] New Patch From Sandisk Hi all, It's been almost two weeks after I sent out the patch. please let us know if you're okay with it. Thanks, Dharani. From: Dharani Kotte Sent: Friday, April 12, 2013 9:58 AM To: nvmewin at lists.openfabrics.org Subject: New Patch From Sandisk Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeSnti.c a. Allocate a global buffer of 256bytes size for modesense return data preparation b. For any mode sense this buffer is used for modesense data along with the requested pages in it. c. Copy the required data according to the alloc_length requested in the cdb to the Srb->DataBuffer and update the dataTransferLength accordingly d. In function SntiTranslateReturnAllModePagesResponse() the modesense data header offset is calculated wrong which ends up in BSOD in some cases modified code to fix this issue 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, 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). CAUTION: Please confirm that the password protected .zip attachment which contains the file(s) of type source_sndk_05_16_2013.zip is legitimate prior to opening. To make sure this message is not infected with a virus, it is important to verify that you are expecting the message or else confirm its legitimacy with the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Tue Jun 11 15:26:26 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Tue, 11 Jun 2013 22:26:26 +0000 Subject: [nvmewin] New Patch From Sandisk In-Reply-To: References: <49158E750348AA499168FD41D88983606256082A@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFE961C@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062560AA2@FMSMSX105.amr.corp.intel.com> <49158E750348AA499168FD41D889836062578A2D@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEC067@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062578B98@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEE32C@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFEEB8A@corpmail1.na.ads.idt.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFEEBBA@corpmail1.na.ads.idt.com> Thank you very much, Sumant. Regards, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 3:24 PM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hello Alex, Sure, no problem. We will wait for the patches in the pipeline to be accepted and then rebase and resubmit the patch. Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 2:14 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Currently, we are reviewing the patch from LSI, which adds supporting for TRIM command. Once Intel and IDT approve it, the patch will be added first. Then we will review your patch. However, you need to re-base to include the recent patches from IDT and LSI first and re-send your patch out. Thanks you very much and please let me know if you have questions. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 11:01 AM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Alex, Thanks for the feedback. Please find attached the patch that fixes the SCSI compliance test for MODE SENSE. Attached is also the log of a successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, June 03, 2013 2:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I retested the patch with SCSICompliance and it results a new failure: MODE SENSE (6) Comparing MODE PAGE data before and after DBD bit is set. Could you test it to see if you can replicate it? You may find more details in the attachment. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 30, 2013 3:20 PM To: Robles, Raymond C; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Ray, Please find attached the patch that has fix for the last code review comment. This is the patch set that I had sent to Alex earlier. Password : sndk1234 Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 3:10 PM To: Chang, Alex; Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thanks Alex. Sumant, please continue with your updates from the last set of code review comments and resend the patch (after running all the required unit tests of course). Once we confirm the feedback changes are in place, I’ll push the patch. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 30, 2013 3:07 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Actually I did some preliminary debugging on it and found out the crash was not introduced by your patch. When the system gets normal shutdown, NVMeNormalShutdown calls NVMeFreeBuffers to free up all queue related structures. And later, when NVMeDetectPendingCmds is called to check on the pending commands, it refers to the queue structures and causes the crash. I will include the fix in my next patch that includes changes to be compliant with 1.0e NVMe Specification. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 30, 2013 2:11 PM To: Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hello Alex, I haven’t been able to repro the BSOD issue that you saw in your setup. Would it be possible for you to send me the crashdump please ? Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 1:24 PM To: Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Importance: High Dharani/Sumant, What is the status on this patch? I’ve not seen any follow up to my last email below. Hopefully we can close this out soon as there are other patches waiting to be submitted. Thanks for your quick attention. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, May 16, 2013 3:49 PM To: Chang, Alex; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Actually, I was going to type the same thing in my email below and then got derailed with the whole #define issue (thanks for capturing this Alex). There is no DataTransferLength field in the SRB Extension structure. That is defined in the SRB by Storport. As a general courtesy to other companies who are reviewing these patches, please insure that you are compiling and re-testing your patch prior to sending out for secondary or additional code reviews. This will help save valuable time in the code review process. If you are having issues compiling, or do not see the same errors, please contact me. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 16, 2013 3:44 PM To: Robles, Raymond C; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, The only change you've made in the new patch is replacing: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); with: memset(GET_DATA_BUFFER(pSrb), 0, min(pSrbExt->DataTransferLength, allocLength)); However, it generates compiling error because DataTransferLength is not a member of NVME_SRB_EXTENSION structure. Could you please fix it? Thanks a lot for you help, Alex ________________________________ From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 16, 2013 1:37 PM To: Sumant Patro; Knoblaugh, Rick; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant/Dharani, Thanks for the updated patch. A couple of comments/questions: - For all the mode sense page translations, the new temp buffer allocated in the SRB extension is used. But for the Modes Sense 0x3C (all mode pages), the SRB data buffer is still memset to 0 at the beginning of SntiReturnAllModePages(). I’m not sure we still need to do this considering how the temp buffer is used to build the mode sense data. - If you insist on keeping that memset in there, there is a #define in for all mode pages - MODE_SENSE_ALL_PAGES_LENGTH. It may be better to zero out the buffer based on the min between this define and allocLength. SRB data transfer length cannot be relied on for “data-in” commands (like mode sense). Thanks, Ray From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 16, 2013 12:43 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Sorry, sent the wrong zip in the previous mail. Please ignore the previous attachment. Attached is the updated zip file. Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 16, 2013 12:38 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Thanks Rick, Alex for your feedback. Please find attached updated files with following two changes : 1. Comment in header of SntiCreateModeDataHeader function changed to reflect passing of srb extension 2. memset(GET_DATA_BUFFER(pSrb), 0, allocLength); modified to use minimum of allocLength and DataTransferLength in SntiReturnAllModePages(..) Password : sndk1234 Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Thursday, May 16, 2013 11:59 AM To: Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, When you change that one, may as well fix the comment in header of SntiCreateModeDataHeader function to reflect that srb extension is now the parameter that’s passed in. Other stuff looks good. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, May 16, 2013 10:58 AM To: Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, I tested your new patch and experienced a D1 bugcheck while running SCSICompliance test. Some preliminary debugging leads to Line#3633 of nvmestni.c, where it looks like: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); The bugcheck happens when the value of "allocLength" is 0x1000. Apparently, the allocated length in CDB is somewhat a bogus value that is meant to test how driver handles it. Could you please fix it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Wednesday, May 01, 2013 8:56 AM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Ray, I have incorporated the changes according to your suggestions, I tried to keep up with the coding convention please feel free to let me know if anything has to be changed. I have incorporated one more fix in the nvmeInit.c which can lead to memory corruptions and used the SrbExt for the buffer allocation. PassWd: sndk1234 Thanks, Dharani. From: Dharani Kotte Sent: Tuesday, April 30, 2013 12:03 PM To: 'Robles, Raymond C'; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thank you for the feedback, I agree that the global buffer is not good I have made the changes to allocate this buffer from the srbext I will provide the code with the below modifications soon. Thanks, Dharani. From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, April 30, 2013 11:52 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, Thank you for putting this patch together. Please see my feedback below: - Line 52: Note that we have a file called nvmeSntiTypes.h. This file contains all #defines. As per our existing convention, all #defines should be placed in this file (versus at the top of a .c file). - Line 3339/3412/3502/3593/3756/5391/5433/5442/5453: Our coding convention states no line be longer than 80 characters. These lines all exceed 80 characters. - Line 5410: SntiTranslateAllModePagesResponse() contains new if-else blocks. Our coding convention dictates that open curly braces be placed on the same line as the if or else statement. You can refer to other instances of the code and if-else clauses as examples. - Line 4017: SntiCreateModeDataHeader() no longer needs the SRB pointer to be passed in as a parameter since you are using a global temp buffer to build up the mode sense data. That parameter can be removed. - General: The method of using a global buffer for a single mode sense command opens up a potential race condition for multiple mode sense commands submitted on top of each other. The idea behind putting the SCSI to NVMe translation phase in the HwStorBuildIo phase was to help performance. We initially knew that we would never be sharing any data structures or memory in calls to BuildIo. There is no spinlock or protection for calls to BuildIo and MSDN makes it clear that these BuildIo calls are not synchronized and that any synchronization of memory/data must be done within the function implementations or just use StartIo instead (since Storport will acquire the StartIoSpinLock). So there is hole here w/r/t the global buffer being populated for multiple mode sense commands at the same time. I believe you have the right idea, but the correct solution is to create a temp mode sense buffer inside the SRB extension. This way, each command has its own temp mode sense buffer for building the mode sense response, and then when ready to copy over to the SRB data buffer, it’s pulling from a buffer that can only be accessed by the current command (instead of a global buffer that may have been overwritten by another mode sense request call from another BuildIo call). Note that the driver collaboration group made the decision to never acquire any type of lock in BuildIo. Let me know if you have questions on this solution. The additional size to the SRB extension is not an issue. This fix is critical for this patch to be accepted. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 11:14 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Attaching the code with according to Alex suggestion. Passwd: sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, April 30, 2013 9:23 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, I'd suggest that it's safer to initialize gModeSenseBuf as all zeros each time before it is used, just in case there are some unexpected data in the buffer. Other than that, I am fine with the patch. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 8:37 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] New Patch From Sandisk Hi all, It's been almost two weeks after I sent out the patch. please let us know if you're okay with it. Thanks, Dharani. From: Dharani Kotte Sent: Friday, April 12, 2013 9:58 AM To: nvmewin at lists.openfabrics.org Subject: New Patch From Sandisk Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeSnti.c a. Allocate a global buffer of 256bytes size for modesense return data preparation b. For any mode sense this buffer is used for modesense data along with the requested pages in it. c. Copy the required data according to the alloc_length requested in the cdb to the Srb->DataBuffer and update the dataTransferLength accordingly d. In function SntiTranslateReturnAllModePagesResponse() the modesense data header offset is calculated wrong which ends up in BSOD in some cases modified code to fix this issue 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, 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). CAUTION: Please confirm that the password protected .zip attachment which contains the file(s) of type source_sndk_05_16_2013.zip is legitimate prior to opening. To make sure this message is not infected with a virus, it is important to verify that you are expecting the message or else confirm its legitimacy with the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Tue Jun 11 15:48:37 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Tue, 11 Jun 2013 22:48:37 +0000 Subject: [nvmewin] LSI Trim Patch In-Reply-To: <4565AEA676113A449269C2F3A549520FDBBD3022@cosmail03.lsi.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBB1FBD5@cosmail03.lsi.com> <49158E750348AA499168FD41D88983606257AEE1@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBBD3022@cosmail03.lsi.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFEEBCB@corpmail1.na.ads.idt.com> Hi Rick, Just a quick note that you don't need to define WINDOWS_8 yourself. In a more WDK way, you may just wrap your changes with: #if (_WIN32_WINNT > _WIN32_WINNT_WIN7) #endif Then, it will be compiled without error on both Windows 8 WDK and 7600 WDK. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Friday, June 07, 2013 6:38 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** LSI Trim Patch Hi Ray, Per your request, since we will switch order, moving Intel patch to the number 3 position, I'm sending LSI's Trim patch. Password for the attached file is: lsi1234. Also, I have attached a document here that describes what was changed/added. It would be great if everyone can review and please let me know any feedback. Thanks. -Rick From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 03, 2013 5:12 PM To: Knoblaugh, Rick; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Rick, That's great news! LSI will be 3rd in line after IDT and Intel. Thanks for the contributions to TRIM. Thanks, Ray From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Ray, We also have the patch for Trim. It is ready to send. Please let me know when you would like me to send out. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From Rick.Knoblaugh at lsi.com Tue Jun 11 16:01:15 2013 From: Rick.Knoblaugh at lsi.com (Knoblaugh, Rick) Date: Tue, 11 Jun 2013 17:01:15 -0600 Subject: [nvmewin] LSI Trim Patch In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFEEBA3@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBB1FBD5@cosmail03.lsi.com> <49158E750348AA499168FD41D88983606257AEE1@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBBD3022@cosmail03.lsi.com> <548C5470AAD9DA4A85D259B663190D361FFEEBA3@corpmail1.na.ads.idt.com> Message-ID: <4565AEA676113A449269C2F3A549520FDBBD33DA@cosmail03.lsi.com> Hi Alex, Yes, if you build with Windows 8 WDK with Visual Studio, and you specify that the build is for Windows 7, the driver will work as it always has with Windows 7. I will check with the engineer who tested and see what else has been tried. Thanks, -Rick From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:12 PM To: Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: LSI Trim Patch Hi Rick, After the driver being built with Windows 8 WDK, does it work on Windows 7 and the others? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Friday, June 07, 2013 6:38 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** LSI Trim Patch Hi Ray, Per your request, since we will switch order, moving Intel patch to the number 3 position, I'm sending LSI's Trim patch. Password for the attached file is: lsi1234. Also, I have attached a document here that describes what was changed/added. It would be great if everyone can review and please let me know any feedback. Thanks. -Rick From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 03, 2013 5:12 PM To: Knoblaugh, Rick; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Rick, That's great news! LSI will be 3rd in line after IDT and Intel. Thanks for the contributions to TRIM. Thanks, Ray From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Ray, We also have the patch for Trim. It is ready to send. Please let me know when you would like me to send out. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:image001.png at 01CE66BC.91C3B4D0] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From kris.r.murray at intel.com Wed Jun 12 16:45:01 2013 From: kris.r.murray at intel.com (Murray, Kris R) Date: Wed, 12 Jun 2013 23:45:01 +0000 Subject: [nvmewin] ***UNCHECKED*** Intel Byte Enable Patch Message-ID: <6B4557D9CF036C4E8F9D6C561818DABB365CE5AD@FMSMSX112.amr.corp.intel.com> All, Attached is the patch to fix issues where accessing memory mapped controller register fields directly would generate single byte accesses across the PCIe bus by calling the StorPort functions to read those registers. The 4 places this is done are NVMeFindAdapter, NVMeInitCplQueue, NVMeSubQueue, and NVMeInitCallback. Password: intel1234 Testing done using IOMeter and SCSI Compliance with logs attached. Please review and provide feedback in the next couple weeks. Upon acceptance I'll rebase after the other patches make it through. Thanks, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IOMeter_results.csv Type: application/octet-stream Size: 160210 bytes Desc: IOMeter_results.csv URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: scsicompliance.log.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Intel_ByteEnable_Patch.zip Type: application/x-zip-compressed Size: 168238 bytes Desc: Intel_ByteEnable_Patch.zip URL: From Alex.Chang at idt.com Thu Jun 13 09:29:34 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Thu, 13 Jun 2013 16:29:34 +0000 Subject: [nvmewin] Intel Byte Enable Patch In-Reply-To: <6B4557D9CF036C4E8F9D6C561818DABB365CE5AD@FMSMSX112.amr.corp.intel.com> References: <6B4557D9CF036C4E8F9D6C561818DABB365CE5AD@FMSMSX112.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFEED8F@corpmail1.na.ads.idt.com> Thank you, Kris, for sending out the patch. Currently, we are reviewing the patch from LSI (TRIM command support). SanDisk's patch will be the next in the pipeline. Apparently, we need to speed up a bit on the patches. Since Ray is on his sabbatical, could you please help out on reviewing/testing LSI's patch and let us know your feedback as soon as possible? Regards, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Wednesday, June 12, 2013 4:45 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** Intel Byte Enable Patch All, Attached is the patch to fix issues where accessing memory mapped controller register fields directly would generate single byte accesses across the PCIe bus by calling the StorPort functions to read those registers. The 4 places this is done are NVMeFindAdapter, NVMeInitCplQueue, NVMeSubQueue, and NVMeInitCallback. Password: intel1234 Testing done using IOMeter and SCSI Compliance with logs attached. Please review and provide feedback in the next couple weeks. Upon acceptance I'll rebase after the other patches make it through. Thanks, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Thu Jun 13 09:40:28 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Thu, 13 Jun 2013 16:40:28 +0000 Subject: [nvmewin] LSI Trim Patch In-Reply-To: <4565AEA676113A449269C2F3A549520FDBBD3022@cosmail03.lsi.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBB1FBD5@cosmail03.lsi.com> <49158E750348AA499168FD41D88983606257AEE1@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBBD3022@cosmail03.lsi.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFEED9E@corpmail1.na.ads.idt.com> Hi Rick, I did some basic tests like disk formats, SCSICompliance, SDStress and IOMeter. They're all working fine except IOMeter, which I configured as 4Kbyte, sequential writes. IOMeter stops right after hitting "Start Tests" (green flag). Do you see the problem when you tested it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Friday, June 07, 2013 6:38 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** LSI Trim Patch Hi Ray, Per your request, since we will switch order, moving Intel patch to the number 3 position, I'm sending LSI's Trim patch. Password for the attached file is: lsi1234. Also, I have attached a document here that describes what was changed/added. It would be great if everyone can review and please let me know any feedback. Thanks. -Rick From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 03, 2013 5:12 PM To: Knoblaugh, Rick; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Rick, That's great news! LSI will be 3rd in line after IDT and Intel. Thanks for the contributions to TRIM. Thanks, Ray From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Ray, We also have the patch for Trim. It is ready to send. Please let me know when you would like me to send out. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From Rick.Knoblaugh at lsi.com Thu Jun 13 11:16:29 2013 From: Rick.Knoblaugh at lsi.com (Knoblaugh, Rick) Date: Thu, 13 Jun 2013 12:16:29 -0600 Subject: [nvmewin] LSI Trim Patch In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFEED9E@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBB1FBD5@cosmail03.lsi.com> <49158E750348AA499168FD41D88983606257AEE1@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBBD3022@cosmail03.lsi.com> <548C5470AAD9DA4A85D259B663190D361FFEED9E@corpmail1.na.ads.idt.com> Message-ID: <4565AEA676113A449269C2F3A549520FDBBD3758@cosmail03.lsi.com> Hi Alex, Thanks for checking it out. We did not see that issue. Will try that one again today. For those tests, I don't believe any UNMAP requests should be involved, so it should just be the normal code path. -Rick From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 13, 2013 9:40 AM To: Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: LSI Trim Patch Hi Rick, I did some basic tests like disk formats, SCSICompliance, SDStress and IOMeter. They're all working fine except IOMeter, which I configured as 4Kbyte, sequential writes. IOMeter stops right after hitting "Start Tests" (green flag). Do you see the problem when you tested it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Friday, June 07, 2013 6:38 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** LSI Trim Patch Hi Ray, Per your request, since we will switch order, moving Intel patch to the number 3 position, I'm sending LSI's Trim patch. Password for the attached file is: lsi1234. Also, I have attached a document here that describes what was changed/added. It would be great if everyone can review and please let me know any feedback. Thanks. -Rick From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 03, 2013 5:12 PM To: Knoblaugh, Rick; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Rick, That's great news! LSI will be 3rd in line after IDT and Intel. Thanks for the contributions to TRIM. Thanks, Ray From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Ray, We also have the patch for Trim. It is ready to send. Please let me know when you would like me to send out. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:image001.png at 01CE6827.2F991D60] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From Rick.Knoblaugh at lsi.com Sat Jun 15 20:48:05 2013 From: Rick.Knoblaugh at lsi.com (Knoblaugh, Rick) Date: Sat, 15 Jun 2013 21:48:05 -0600 Subject: [nvmewin] LSI Trim Patch In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFEEBCB@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBB1FBD5@cosmail03.lsi.com> <49158E750348AA499168FD41D88983606257AEE1@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBBD3022@cosmail03.lsi.com>, <548C5470AAD9DA4A85D259B663190D361FFEEBCB@corpmail1.na.ads.idt.com> Message-ID: <4565AEA676113A449269C2F3A549520F013819F022@cosmail03.lsi.com> Hi Alex, We can make that tweak to change how it checks for Windows 8. Also, I discovered one other item that hasn't affected TRIM, but is not actually correct. In the SntiTranslateBLockLimitsPage function that implements the Block Limits VPD page, two items weren't being returned correctly. pBLPage->MaximumCompareAndWriteLength and pBLPage->MaximumTransferLength were being assigned the value of pCntrlIdData->MDTS -- and what needs to be returned there is not this field, but a calculation based on this field and PAE->pCtrlRegister->CAP.MPSMIN. And actually, we have the ability to scale that maximum transfer value back based on a registry setting, so rather than doing that calculation, what should probably be returned there is pAE->InitInfo.MaxTxSize. Another issue with what was being done is that the value for these fields within the BLock Limits VPD Page needs to be in blocks, so for both of those, we should be returning pAE->InitInfo.MaxTxSize / block size. We can put in those fixes. (Again, these weren't affecting the UNMAP stuff, but should be corrected.) Thanks, -Rick ________________________________ From: Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:48 PM To: Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: LSI Trim Patch Hi Rick, Just a quick note that you don't need to define WINDOWS_8 yourself. In a more WDK way, you may just wrap your changes with: #if (_WIN32_WINNT > _WIN32_WINNT_WIN7) #endif Then, it will be compiled without error on both Windows 8 WDK and 7600 WDK. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Friday, June 07, 2013 6:38 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** LSI Trim Patch Hi Ray, Per your request, since we will switch order, moving Intel patch to the number 3 position, I’m sending LSI’s Trim patch. Password for the attached file is: lsi1234. Also, I have attached a document here that describes what was changed/added. It would be great if everyone can review and please let me know any feedback. Thanks. -Rick From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 03, 2013 5:12 PM To: Knoblaugh, Rick; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Rick, That’s great news! LSI will be 3rd in line after IDT and Intel. Thanks for the contributions to TRIM. Thanks, Ray From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Ray, We also have the patch for Trim. It is ready to send. Please let me know when you would like me to send out. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I’m going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he’d like to push and I also have a patch I’d like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:826034422 at 11062013-1A67] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From judy.brock at ssi.samsung.com Mon Jun 17 05:52:01 2013 From: judy.brock at ssi.samsung.com (Judy Brock-SSI) Date: Mon, 17 Jun 2013 12:52:01 +0000 Subject: [nvmewin] Review Driver Development Status Message-ID: <36E8D38D6B771A4BBDB1C0D800158A51308C9B16@SSIEXCH-MB2.ssi.samsung.com> Kwok , To submit patches for the Samsung items below, should I wait for the Sandisk patch (currently last in line behind LSI, IDT, and Intel I think) to be resubmitted and accepted and then submit our patches based on the then-current top of tree? I'm pasting code snippets meanwhile (see below) s o I can incorporate any early feedback that may be available. All changes are in yellow highlight. Also, one other miscellaneous bug: In nvmeSntiTypes.h: added #define NUM_BYTES_IN_DWORDS 4 In nvmeSnti.c, in function SntiTranslateWriteBuffer(): . . . case DOWNLOAD_SAVE_ACTIVATE: /* Issue NVME FIRMWARE IMAGE DOWNLOAD command */ dword10 |= paramListLength / NUM_BYTES_IN_DWORDS; case DOWNLOAD_SAVE_DEFER_ACTIVATE: /* Issue NVME FIRMWARE IMAGE DOWNLOAD command */ dword10 |= paramListLength / NUM_BYTES_IN_DWORDS; "Format NVM Error" patch: BOOLEAN FormatNVMFailure( PNVME_DEVICE_EXTENSION pDevExt, PNVME_SRB_EXTENSION pSrbExt ) { PFORMAT_NVM_INFO pFormatNvmInfo = &pDevExt->FormatNvmInfo; #if LEAVE_ORPHANED_REQUEST_OUTSTANDING // Q. is original code needed for something? Looks like it was intentional but results in lost req /* * Depends on AddNamespaceNeeded: * If TRUE, add back the namespace(s) via calling NVMeIoctlHotAddNamespace. * and return FALSE since the request will be completed later. * If FALSE, Clear the FORMAT_NVM_INFO structure and return TRUE * to let caller complete the request. */ if (pFormatNvmInfo->AddNamespaceNeeded == TRUE) { /* Need to add back namespace(s) first */ NVMeIoctlHotAddNamespace(pSrbExt); return FALSE; } else { /* * Reset FORMAT_NVM_INFO structure to zero * since the request is completed */ memset((PVOID)pFormatNvmInfo, 0, sizeof(FORMAT_NVM_INFO)); return TRUE; } #else /* * If AddNamespaceNeeded is TRUE, add back the namespace(s) via * NVMeIoctlHotAddNamespace. Then clear the FORMAT_NVM_INFO structure and * return TRUE in order to complete the request. Since we hit an error * we need to finish it. */ if (pFormatNvmInfo->AddNamespaceNeeded == TRUE) { /* Need to add back namespace(s) first */ NVMeIoctlHotAddNamespace(pSrbExt); } /* * Reset FORMAT_NVM_INFO structure to zero * since the request is completed */ memset((PVOID)pFormatNvmInfo, 0, sizeof(FORMAT_NVM_INFO)); return TRUE; #endif /* !LEAVE_ORPHANED_REQUEST_OUTSTANDING */ } "Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset" patch: * @return BOOLEAN * TRUE - If Adapter is enabled correctly * FALSE - If anything goes wrong ******************************************************************************/ BOOLEAN NVMeEnableAdapter( PNVME_DEVICE_EXTENSION pAE ) { PQUEUE_INFO pQI = &pAE->QueueInfo; NVMe_CONTROLLER_CONFIGURATION CC = {0}; NVMe_CONTROLLER_STATUS CSTS; ULONG PollMax = pAE->uSecCrtlTimeout / MAX_STATE_STALL_us; ULONG PollCount; . . . StorPortWriteRegisterUlong( pAE, (PULONG)(&pAE->pCtrlRegister->ACQ.HighPart), (ULONG)(pQI->pCplQueueInfo->CplQStart.HighPart)); StorPortDebugPrint(INFO, "NVMeEnableAdapter: Setting EN...\n"); /* * Set up Controller Configuration Register */ /* After reset, we must wait for CSTS.RDY == 0 before setting CC.EN to 1 */ for (PollCount = 0; PollCount < PollMax; PollCount++) { CSTS.AsUlong = StorPortReadRegisterUlong(pAE, (PULONG)(&pAE->pCtrlRegister->CSTS.AsUlong)); if (CSTS.RDY == 0) { /* Move on if RDY bit is cleared */ break; } NVMeStallExecution(pAE, MAX_STATE_STALL_us); } if (CSTS.RDY != 0) { /* If RDY bit won't clear we can't enable the adapter */ return FALSE; } CC.EN = 1; CC.CSS = NVME_CC_NVM_CMD; CC.MPS = (PAGE_SIZE >> NVME_MEM_PAGE_SIZE_SHIFT); CC.AMS = NVME_CC_ROUND_ROBIN; CC.SHN = NVME_CC_SHUTDOWN_NONE; CC.IOSQES = NVME_CC_IOSQES; CC.IOCQES = NVME_CC_IOCQES; StorPortWriteRegisterUlong(pAE, (PULONG)(&pAE->pCtrlRegister->CC), CC.AsUlong); return TRUE; } /* NVMeEnableAdapter */ In NVMeInitialize(): ... if ((NVMeEnableAdapter(pAE)) == FALSE) { return (FALSE); } In NVMeInitAdminQueues (): ... if ((NVMeEnableAdapter(pAE)) == FALSE) { return (FALSE); } In nvmeStd.h: BOOLEAN NVMeEnableAdapter( __in PNVME_DEVICE_EXTENSION pAE ); Thanks, Judy -----Original Appointment----- From: Kong, Kwok Sent: Friday, June 07, 2013 10:01 AM To: Kong, Kwok; 'nvmewin at lists.openfabrics.org' Cc: Chang, Alex; Bart Bartel; Knoblaugh, Rick; Murray, Kris R; Bob Griswold; Steven Shrader; Dave Landsman; Robert Randall (rrandall); Brandon.Schulz at hgst.com; Yong Chen; Neal Galbo (ngalbo); Judy Brock-SSI; Javier Castro-SSI; Bruce Langworthy; Nathan Obr; Thomas.Freeman at hgst.com Subject: [nvmewin] Review Driver Development Status - Sorry, I have to reschedule When: Monday, June 17, 2013 1:00 PM-2:00 PM (UTC-08:00) Pacific Time (US & Canada). Where: Conf call You are invited to attend an AT&T Connect iMeeting . To connect to the Web Conference: ============================= Click here: https://connect9.uc.att.com/service32/meet/?ExEventID=8811938&CT=M TO CONNECT WITH YOUR *TELEPHONE ONLY* (no computer): =================================================== 1. Choose one of the following numbers to dial: If you are calling from an office location with on-site number(s) (listed below), try this number first. If you do not have on-site access, or you are not a member of the host's company/organization, use one of the other numbers shown. * Caller-Paid number: 602-333-0032 * Toll-Free Number (in USA): 888-270-9936. * Blackberry (Caller-Paid): 6023330032x811938# * A number in your country or in a country close to you (may be toll free): https://www.teleconference.att.com/servlet/glbAccess?process=1&accessNumber=8882709936&accessCode=811938 2. When prompted, enter the Meeting Access Code: 811938# To prepare in advance for the conference (for all devices): https://connect9.uc.att.com/service32/Prepare/. To view supported Operating Systems and devices: http://www.uc.att.com/support/SupportedDevices.html Powered by AT&T Connect. Agenda: * Review Release 1.2 Status * - Supports the following Windows versions in addition to Windows 7 - 64 bits (IDT) * - Windows 8 64-bit * - Windows Server 2008R2 64-bit * - Windows Server 2012 64-bit * * - TRIM command support (LSI) * - NVMe 1.00e enhancement (IDT) * - Hibernation as a boot drive (Huawei) * Review Known problems Status - Not Accessing NVMe registers in their native width. (Ray - Intel) - ModeSense Translation issue. (Dharani - SanDisk) - format nvm error. (Judy - Samsung) - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset. (Judy - Samsung) * SCSI Translation Update (Yong Chen - Huawei) * Release 1.3 Discussion - Support additional Windows versions - Windows 7 32-bit - Windows 8 32-bit - Windows 8 features: - Extended SRB format - SMART handling via new Extended SRB format Features that will not be supported in 2013 (will be reviewed mid-year): NVMe 1.1 support: - multi-path - SGL - Get/Set feature update - Autonomous power state transition - Host Identifier - Reservation Notification Mask - Reservation Persistence - identify structure update - write zeros command Other feature: - End-to-end protection (Server 2012 support this) << File: ATT00001.txt >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kwok.Kong at idt.com Mon Jun 17 08:39:24 2013 From: Kwok.Kong at idt.com (Kong, Kwok) Date: Mon, 17 Jun 2013 15:39:24 +0000 Subject: [nvmewin] LSI Trim Patch In-Reply-To: <4565AEA676113A449269C2F3A549520F013819F022@cosmail03.lsi.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBB1FBD5@cosmail03.lsi.com> <49158E750348AA499168FD41D88983606257AEE1@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBBD3022@cosmail03.lsi.com>, <548C5470AAD9DA4A85D259B663190D361FFEEBCB@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F013819F022@cosmail03.lsi.com> Message-ID: <05CD7821AE397547A01AC160FBC231474BCADF06@corpmail1.na.ads.idt.com> Rick, Is it possible to run the Windows 8 binary driver with Windows 7, Windows server 2008R2 and Windows server 2012 ? If it works, then there is no need to have conditional compile . We can require Windows 8 WDK to compile the source code such that we only need to build a single binary file for Windows 7, 8, Server 2008R2 and Server 2012. Thanks -Kwok From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Saturday, June 15, 2013 8:48 PM To: Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: Re: [nvmewin] LSI Trim Patch Hi Alex, We can make that tweak to change how it checks for Windows 8. Also, I discovered one other item that hasn't affected TRIM, but is not actually correct. In the SntiTranslateBLockLimitsPage function that implements the Block Limits VPD page, two items weren't being returned correctly. pBLPage->MaximumCompareAndWriteLength and pBLPage->MaximumTransferLength were being assigned the value of pCntrlIdData->MDTS -- and what needs to be returned there is not this field, but a calculation based on this field and PAE->pCtrlRegister->CAP.MPSMIN. And actually, we have the ability to scale that maximum transfer value back based on a registry setting, so rather than doing that calculation, what should probably be returned there is pAE->InitInfo.MaxTxSize. Another issue with what was being done is that the value for these fields within the BLock Limits VPD Page needs to be in blocks, so for both of those, we should be returning pAE->InitInfo.MaxTxSize / block size. We can put in those fixes. (Again, these weren't affecting the UNMAP stuff, but should be corrected.) Thanks, -Rick ________________________________ From: Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:48 PM To: Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: LSI Trim Patch Hi Rick, Just a quick note that you don't need to define WINDOWS_8 yourself. In a more WDK way, you may just wrap your changes with: #if (_WIN32_WINNT > _WIN32_WINNT_WIN7) #endif Then, it will be compiled without error on both Windows 8 WDK and 7600 WDK. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Friday, June 07, 2013 6:38 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** LSI Trim Patch Hi Ray, Per your request, since we will switch order, moving Intel patch to the number 3 position, I'm sending LSI's Trim patch. Password for the attached file is: lsi1234. Also, I have attached a document here that describes what was changed/added. It would be great if everyone can review and please let me know any feedback. Thanks. -Rick From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 03, 2013 5:12 PM To: Knoblaugh, Rick; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Rick, That's great news! LSI will be 3rd in line after IDT and Intel. Thanks for the contributions to TRIM. Thanks, Ray From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Ray, We also have the patch for Trim. It is ready to send. Please let me know when you would like me to send out. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From Kwok.Kong at idt.com Mon Jun 17 08:52:52 2013 From: Kwok.Kong at idt.com (Kong, Kwok) Date: Mon, 17 Jun 2013 15:52:52 +0000 Subject: [nvmewin] Review Driver Development Status In-Reply-To: <36E8D38D6B771A4BBDB1C0D800158A51308C9B16@SSIEXCH-MB2.ssi.samsung.com> References: <36E8D38D6B771A4BBDB1C0D800158A51308C9B16@SSIEXCH-MB2.ssi.samsung.com> Message-ID: <05CD7821AE397547A01AC160FBC231474BCADF3A@corpmail1.na.ads.idt.com> Judy, Please wait for all the current active patches before sending Samsung patch out for review. Alex is going to apply the patch and he is the one who controls the order. Alex, What is the current order for patches ? Thanks -Kwok From: Judy Brock-SSI [mailto:judy.brock at ssi.samsung.com] Sent: Monday, June 17, 2013 5:52 AM To: Kong, Kwok; 'nvmewin at lists.openfabrics.org' Cc: Chang, Alex; Bart Bartel; Knoblaugh, Rick; Murray, Kris R; Bob Griswold; Steven Shrader; Dave Landsman; Robert Randall (rrandall); Brandon.Schulz at hgst.com; Yong Chen; Neal Galbo (ngalbo); Javier Castro-SSI; Bruce Langworthy; Nathan Obr; Thomas.Freeman at hgst.com Subject: RE: [nvmewin] Review Driver Development Status Kwok , To submit patches for the Samsung items below, should I wait for the Sandisk patch (currently last in line behind LSI, IDT, and Intel I think) to be resubmitted and accepted and then submit our patches based on the then-current top of tree? I'm pasting code snippets meanwhile (see below) s o I can incorporate any early feedback that may be available. All changes are in yellow highlight. Also, one other miscellaneous bug: In nvmeSntiTypes.h: added #define NUM_BYTES_IN_DWORDS 4 In nvmeSnti.c, in function SntiTranslateWriteBuffer(): . . . case DOWNLOAD_SAVE_ACTIVATE: /* Issue NVME FIRMWARE IMAGE DOWNLOAD command */ dword10 |= paramListLength / NUM_BYTES_IN_DWORDS; case DOWNLOAD_SAVE_DEFER_ACTIVATE: /* Issue NVME FIRMWARE IMAGE DOWNLOAD command */ dword10 |= paramListLength / NUM_BYTES_IN_DWORDS; "Format NVM Error" patch: BOOLEAN FormatNVMFailure( PNVME_DEVICE_EXTENSION pDevExt, PNVME_SRB_EXTENSION pSrbExt ) { PFORMAT_NVM_INFO pFormatNvmInfo = &pDevExt->FormatNvmInfo; #if LEAVE_ORPHANED_REQUEST_OUTSTANDING // Q. is original code needed for something? Looks like it was intentional but results in lost req /* * Depends on AddNamespaceNeeded: * If TRUE, add back the namespace(s) via calling NVMeIoctlHotAddNamespace. * and return FALSE since the request will be completed later. * If FALSE, Clear the FORMAT_NVM_INFO structure and return TRUE * to let caller complete the request. */ if (pFormatNvmInfo->AddNamespaceNeeded == TRUE) { /* Need to add back namespace(s) first */ NVMeIoctlHotAddNamespace(pSrbExt); return FALSE; } else { /* * Reset FORMAT_NVM_INFO structure to zero * since the request is completed */ memset((PVOID)pFormatNvmInfo, 0, sizeof(FORMAT_NVM_INFO)); return TRUE; } #else /* * If AddNamespaceNeeded is TRUE, add back the namespace(s) via * NVMeIoctlHotAddNamespace. Then clear the FORMAT_NVM_INFO structure and * return TRUE in order to complete the request. Since we hit an error * we need to finish it. */ if (pFormatNvmInfo->AddNamespaceNeeded == TRUE) { /* Need to add back namespace(s) first */ NVMeIoctlHotAddNamespace(pSrbExt); } /* * Reset FORMAT_NVM_INFO structure to zero * since the request is completed */ memset((PVOID)pFormatNvmInfo, 0, sizeof(FORMAT_NVM_INFO)); return TRUE; #endif /* !LEAVE_ORPHANED_REQUEST_OUTSTANDING */ } "Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset" patch: * @return BOOLEAN * TRUE - If Adapter is enabled correctly * FALSE - If anything goes wrong ******************************************************************************/ BOOLEAN NVMeEnableAdapter( PNVME_DEVICE_EXTENSION pAE ) { PQUEUE_INFO pQI = &pAE->QueueInfo; NVMe_CONTROLLER_CONFIGURATION CC = {0}; NVMe_CONTROLLER_STATUS CSTS; ULONG PollMax = pAE->uSecCrtlTimeout / MAX_STATE_STALL_us; ULONG PollCount; . . . StorPortWriteRegisterUlong( pAE, (PULONG)(&pAE->pCtrlRegister->ACQ.HighPart), (ULONG)(pQI->pCplQueueInfo->CplQStart.HighPart)); StorPortDebugPrint(INFO, "NVMeEnableAdapter: Setting EN...\n"); /* * Set up Controller Configuration Register */ /* After reset, we must wait for CSTS.RDY == 0 before setting CC.EN to 1 */ for (PollCount = 0; PollCount < PollMax; PollCount++) { CSTS.AsUlong = StorPortReadRegisterUlong(pAE, (PULONG)(&pAE->pCtrlRegister->CSTS.AsUlong)); if (CSTS.RDY == 0) { /* Move on if RDY bit is cleared */ break; } NVMeStallExecution(pAE, MAX_STATE_STALL_us); } if (CSTS.RDY != 0) { /* If RDY bit won't clear we can't enable the adapter */ return FALSE; } CC.EN = 1; CC.CSS = NVME_CC_NVM_CMD; CC.MPS = (PAGE_SIZE >> NVME_MEM_PAGE_SIZE_SHIFT); CC.AMS = NVME_CC_ROUND_ROBIN; CC.SHN = NVME_CC_SHUTDOWN_NONE; CC.IOSQES = NVME_CC_IOSQES; CC.IOCQES = NVME_CC_IOCQES; StorPortWriteRegisterUlong(pAE, (PULONG)(&pAE->pCtrlRegister->CC), CC.AsUlong); return TRUE; } /* NVMeEnableAdapter */ In NVMeInitialize(): ... if ((NVMeEnableAdapter(pAE)) == FALSE) { return (FALSE); } In NVMeInitAdminQueues (): ... if ((NVMeEnableAdapter(pAE)) == FALSE) { return (FALSE); } In nvmeStd.h: BOOLEAN NVMeEnableAdapter( __in PNVME_DEVICE_EXTENSION pAE ); Thanks, Judy -----Original Appointment----- From: Kong, Kwok Sent: Friday, June 07, 2013 10:01 AM To: Kong, Kwok; 'nvmewin at lists.openfabrics.org' Cc: Chang, Alex; Bart Bartel; Knoblaugh, Rick; Murray, Kris R; Bob Griswold; Steven Shrader; Dave Landsman; Robert Randall (rrandall); Brandon.Schulz at hgst.com; Yong Chen; Neal Galbo (ngalbo); Judy Brock-SSI; Javier Castro-SSI; Bruce Langworthy; Nathan Obr; Thomas.Freeman at hgst.com Subject: [nvmewin] Review Driver Development Status - Sorry, I have to reschedule When: Monday, June 17, 2013 1:00 PM-2:00 PM (UTC-08:00) Pacific Time (US & Canada). Where: Conf call You are invited to attend an AT&T Connect iMeeting . To connect to the Web Conference: ============================= Click here: https://connect9.uc.att.com/service32/meet/?ExEventID=8811938&CT=M TO CONNECT WITH YOUR *TELEPHONE ONLY* (no computer): =================================================== 1. Choose one of the following numbers to dial: If you are calling from an office location with on-site number(s) (listed below), try this number first. If you do not have on-site access, or you are not a member of the host's company/organization, use one of the other numbers shown. * Caller-Paid number: 602-333-0032 * Toll-Free Number (in USA): 888-270-9936. * Blackberry (Caller-Paid): 6023330032x811938# * A number in your country or in a country close to you (may be toll free): https://www.teleconference.att.com/servlet/glbAccess?process=1&accessNumber=8882709936&accessCode=811938 2. When prompted, enter the Meeting Access Code: 811938# To prepare in advance for the conference (for all devices): https://connect9.uc.att.com/service32/Prepare/. To view supported Operating Systems and devices: http://www.uc.att.com/support/SupportedDevices.html Powered by AT&T Connect. Agenda: * Review Release 1.2 Status * - Supports the following Windows versions in addition to Windows 7 - 64 bits (IDT) * - Windows 8 64-bit * - Windows Server 2008R2 64-bit * - Windows Server 2012 64-bit * * - TRIM command support (LSI) * - NVMe 1.00e enhancement (IDT) * - Hibernation as a boot drive (Huawei) * Review Known problems Status - Not Accessing NVMe registers in their native width. (Ray - Intel) - ModeSense Translation issue. (Dharani - SanDisk) - format nvm error. (Judy - Samsung) - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset. (Judy - Samsung) * SCSI Translation Update (Yong Chen - Huawei) * Release 1.3 Discussion - Support additional Windows versions - Windows 7 32-bit - Windows 8 32-bit - Windows 8 features: - Extended SRB format - SMART handling via new Extended SRB format Features that will not be supported in 2013 (will be reviewed mid-year): NVMe 1.1 support: - multi-path - SGL - Get/Set feature update - Autonomous power state transition - Host Identifier - Reservation Notification Mask - Reservation Persistence - identify structure update - write zeros command Other feature: - End-to-end protection (Server 2012 support this) << File: ATT00001.txt >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Mon Jun 17 08:56:00 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Mon, 17 Jun 2013 15:56:00 +0000 Subject: [nvmewin] Review Driver Development Status In-Reply-To: <05CD7821AE397547A01AC160FBC231474BCADF3A@corpmail1.na.ads.idt.com> References: <36E8D38D6B771A4BBDB1C0D800158A51308C9B16@SSIEXCH-MB2.ssi.samsung.com> <05CD7821AE397547A01AC160FBC231474BCADF3A@corpmail1.na.ads.idt.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFEF6CB@corpmail1.na.ads.idt.com> Hi Judy, Yes, you're right that, currently, we have LSI, SanDisk and Intel patches in the pipeline. Your patch will be after them. Thanks, Alex ________________________________ From: Kong, Kwok Sent: Monday, June 17, 2013 8:53 AM To: Judy Brock-SSI; 'nvmewin at lists.openfabrics.org' Cc: Chang, Alex; Bart Bartel; Knoblaugh, Rick; Murray, Kris R; Bob Griswold; Steven Shrader; Dave Landsman; Robert Randall (rrandall); Brandon.Schulz at hgst.com; Yong Chen; Neal Galbo (ngalbo); Javier Castro-SSI; Bruce Langworthy; Nathan Obr; Thomas.Freeman at hgst.com Subject: RE: [nvmewin] Review Driver Development Status Judy, Please wait for all the current active patches before sending Samsung patch out for review. Alex is going to apply the patch and he is the one who controls the order. Alex, What is the current order for patches ? Thanks -Kwok From: Judy Brock-SSI [mailto:judy.brock at ssi.samsung.com] Sent: Monday, June 17, 2013 5:52 AM To: Kong, Kwok; 'nvmewin at lists.openfabrics.org' Cc: Chang, Alex; Bart Bartel; Knoblaugh, Rick; Murray, Kris R; Bob Griswold; Steven Shrader; Dave Landsman; Robert Randall (rrandall); Brandon.Schulz at hgst.com; Yong Chen; Neal Galbo (ngalbo); Javier Castro-SSI; Bruce Langworthy; Nathan Obr; Thomas.Freeman at hgst.com Subject: RE: [nvmewin] Review Driver Development Status Kwok , To submit patches for the Samsung items below, should I wait for the Sandisk patch (currently last in line behind LSI, IDT, and Intel I think) to be resubmitted and accepted and then submit our patches based on the then-current top of tree? I'm pasting code snippets meanwhile (see below) s o I can incorporate any early feedback that may be available. All changes are in yellow highlight. Also, one other miscellaneous bug: In nvmeSntiTypes.h: added #define NUM_BYTES_IN_DWORDS 4 In nvmeSnti.c, in function SntiTranslateWriteBuffer(): . . . case DOWNLOAD_SAVE_ACTIVATE: /* Issue NVME FIRMWARE IMAGE DOWNLOAD command */ dword10 |= paramListLength / NUM_BYTES_IN_DWORDS; case DOWNLOAD_SAVE_DEFER_ACTIVATE: /* Issue NVME FIRMWARE IMAGE DOWNLOAD command */ dword10 |= paramListLength / NUM_BYTES_IN_DWORDS; "Format NVM Error" patch: BOOLEAN FormatNVMFailure( PNVME_DEVICE_EXTENSION pDevExt, PNVME_SRB_EXTENSION pSrbExt ) { PFORMAT_NVM_INFO pFormatNvmInfo = &pDevExt->FormatNvmInfo; #if LEAVE_ORPHANED_REQUEST_OUTSTANDING // Q. is original code needed for something? Looks like it was intentional but results in lost req /* * Depends on AddNamespaceNeeded: * If TRUE, add back the namespace(s) via calling NVMeIoctlHotAddNamespace. * and return FALSE since the request will be completed later. * If FALSE, Clear the FORMAT_NVM_INFO structure and return TRUE * to let caller complete the request. */ if (pFormatNvmInfo->AddNamespaceNeeded == TRUE) { /* Need to add back namespace(s) first */ NVMeIoctlHotAddNamespace(pSrbExt); return FALSE; } else { /* * Reset FORMAT_NVM_INFO structure to zero * since the request is completed */ memset((PVOID)pFormatNvmInfo, 0, sizeof(FORMAT_NVM_INFO)); return TRUE; } #else /* * If AddNamespaceNeeded is TRUE, add back the namespace(s) via * NVMeIoctlHotAddNamespace. Then clear the FORMAT_NVM_INFO structure and * return TRUE in order to complete the request. Since we hit an error * we need to finish it. */ if (pFormatNvmInfo->AddNamespaceNeeded == TRUE) { /* Need to add back namespace(s) first */ NVMeIoctlHotAddNamespace(pSrbExt); } /* * Reset FORMAT_NVM_INFO structure to zero * since the request is completed */ memset((PVOID)pFormatNvmInfo, 0, sizeof(FORMAT_NVM_INFO)); return TRUE; #endif /* !LEAVE_ORPHANED_REQUEST_OUTSTANDING */ } "Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset" patch: * @return BOOLEAN * TRUE - If Adapter is enabled correctly * FALSE - If anything goes wrong ******************************************************************************/ BOOLEAN NVMeEnableAdapter( PNVME_DEVICE_EXTENSION pAE ) { PQUEUE_INFO pQI = &pAE->QueueInfo; NVMe_CONTROLLER_CONFIGURATION CC = {0}; NVMe_CONTROLLER_STATUS CSTS; ULONG PollMax = pAE->uSecCrtlTimeout / MAX_STATE_STALL_us; ULONG PollCount; . . . StorPortWriteRegisterUlong( pAE, (PULONG)(&pAE->pCtrlRegister->ACQ.HighPart), (ULONG)(pQI->pCplQueueInfo->CplQStart.HighPart)); StorPortDebugPrint(INFO, "NVMeEnableAdapter: Setting EN...\n"); /* * Set up Controller Configuration Register */ /* After reset, we must wait for CSTS.RDY == 0 before setting CC.EN to 1 */ for (PollCount = 0; PollCount < PollMax; PollCount++) { CSTS.AsUlong = StorPortReadRegisterUlong(pAE, (PULONG)(&pAE->pCtrlRegister->CSTS.AsUlong)); if (CSTS.RDY == 0) { /* Move on if RDY bit is cleared */ break; } NVMeStallExecution(pAE, MAX_STATE_STALL_us); } if (CSTS.RDY != 0) { /* If RDY bit won't clear we can't enable the adapter */ return FALSE; } CC.EN = 1; CC.CSS = NVME_CC_NVM_CMD; CC.MPS = (PAGE_SIZE >> NVME_MEM_PAGE_SIZE_SHIFT); CC.AMS = NVME_CC_ROUND_ROBIN; CC.SHN = NVME_CC_SHUTDOWN_NONE; CC.IOSQES = NVME_CC_IOSQES; CC.IOCQES = NVME_CC_IOCQES; StorPortWriteRegisterUlong(pAE, (PULONG)(&pAE->pCtrlRegister->CC), CC.AsUlong); return TRUE; } /* NVMeEnableAdapter */ In NVMeInitialize(): ... if ((NVMeEnableAdapter(pAE)) == FALSE) { return (FALSE); } In NVMeInitAdminQueues (): ... if ((NVMeEnableAdapter(pAE)) == FALSE) { return (FALSE); } In nvmeStd.h: BOOLEAN NVMeEnableAdapter( __in PNVME_DEVICE_EXTENSION pAE ); Thanks, Judy -----Original Appointment----- From: Kong, Kwok Sent: Friday, June 07, 2013 10:01 AM To: Kong, Kwok; 'nvmewin at lists.openfabrics.org' Cc: Chang, Alex; Bart Bartel; Knoblaugh, Rick; Murray, Kris R; Bob Griswold; Steven Shrader; Dave Landsman; Robert Randall (rrandall); Brandon.Schulz at hgst.com; Yong Chen; Neal Galbo (ngalbo); Judy Brock-SSI; Javier Castro-SSI; Bruce Langworthy; Nathan Obr; Thomas.Freeman at hgst.com Subject: [nvmewin] Review Driver Development Status - Sorry, I have to reschedule When: Monday, June 17, 2013 1:00 PM-2:00 PM (UTC-08:00) Pacific Time (US & Canada). Where: Conf call You are invited to attend an AT&T Connect iMeeting . To connect to the Web Conference: ============================= Click here: https://connect9.uc.att.com/service32/meet/?ExEventID=8811938&CT=M TO CONNECT WITH YOUR *TELEPHONE ONLY* (no computer): =================================================== 1. Choose one of the following numbers to dial: If you are calling from an office location with on-site number(s) (listed below), try this number first. If you do not have on-site access, or you are not a member of the host's company/organization, use one of the other numbers shown. * Caller-Paid number: 602-333-0032 * Toll-Free Number (in USA): 888-270-9936. * Blackberry (Caller-Paid): 6023330032x811938# * A number in your country or in a country close to you (may be toll free): https://www.teleconference.att.com/servlet/glbAccess?process=1&accessNumber=8882709936&accessCode=811938 2. When prompted, enter the Meeting Access Code: 811938# To prepare in advance for the conference (for all devices): https://connect9.uc.att.com/service32/Prepare/. To view supported Operating Systems and devices: http://www.uc.att.com/support/SupportedDevices.html Powered by AT&T Connect. Agenda: * Review Release 1.2 Status * - Supports the following Windows versions in addition to Windows 7 - 64 bits (IDT) * - Windows 8 64-bit * - Windows Server 2008R2 64-bit * - Windows Server 2012 64-bit * * - TRIM command support (LSI) * - NVMe 1.00e enhancement (IDT) * - Hibernation as a boot drive (Huawei) * Review Known problems Status - Not Accessing NVMe registers in their native width. (Ray - Intel) - ModeSense Translation issue. (Dharani - SanDisk) - format nvm error. (Judy - Samsung) - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset. (Judy - Samsung) * SCSI Translation Update (Yong Chen - Huawei) * Release 1.3 Discussion - Support additional Windows versions - Windows 7 32-bit - Windows 8 32-bit - Windows 8 features: - Extended SRB format - SMART handling via new Extended SRB format Features that will not be supported in 2013 (will be reviewed mid-year): NVMe 1.1 support: - multi-path - SGL - Get/Set feature update - Autonomous power state transition - Host Identifier - Reservation Notification Mask - Reservation Persistence - identify structure update - write zeros command Other feature: - End-to-end protection (Server 2012 support this) << File: ATT00001.txt >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Mon Jun 17 09:15:44 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Mon, 17 Jun 2013 16:15:44 +0000 Subject: [nvmewin] LSI Trim Patch In-Reply-To: <05CD7821AE397547A01AC160FBC231474BCADF06@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBB1FBD5@cosmail03.lsi.com> <49158E750348AA499168FD41D88983606257AEE1@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBBD3022@cosmail03.lsi.com>, <548C5470AAD9DA4A85D259B663190D361FFEEBCB@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F013819F022@cosmail03.lsi.com> <05CD7821AE397547A01AC160FBC231474BCADF06@corpmail1.na.ads.idt.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFEF6E1@corpmail1.na.ads.idt.com> Hi Rick, Kwok has a good point, especially that we're going to release signed binary later. Please add the changes you mentioned below and re-send your patch after running the basic tests (drive formats, SDStress, SCSICompliance and IOMeter) and TRIM specific tests. Thank you, Alex ________________________________ From: Kong, Kwok Sent: Monday, June 17, 2013 8:39 AM To: Knoblaugh, Rick; Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Rick, Is it possible to run the Windows 8 binary driver with Windows 7, Windows server 2008R2 and Windows server 2012 ? If it works, then there is no need to have conditional compile . We can require Windows 8 WDK to compile the source code such that we only need to build a single binary file for Windows 7, 8, Server 2008R2 and Server 2012. Thanks -Kwok From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Saturday, June 15, 2013 8:48 PM To: Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: Re: [nvmewin] LSI Trim Patch Hi Alex, We can make that tweak to change how it checks for Windows 8. Also, I discovered one other item that hasn't affected TRIM, but is not actually correct. In the SntiTranslateBLockLimitsPage function that implements the Block Limits VPD page, two items weren't being returned correctly. pBLPage->MaximumCompareAndWriteLength and pBLPage->MaximumTransferLength were being assigned the value of pCntrlIdData->MDTS -- and what needs to be returned there is not this field, but a calculation based on this field and PAE->pCtrlRegister->CAP.MPSMIN. And actually, we have the ability to scale that maximum transfer value back based on a registry setting, so rather than doing that calculation, what should probably be returned there is pAE->InitInfo.MaxTxSize. Another issue with what was being done is that the value for these fields within the BLock Limits VPD Page needs to be in blocks, so for both of those, we should be returning pAE->InitInfo.MaxTxSize / block size. We can put in those fixes. (Again, these weren't affecting the UNMAP stuff, but should be corrected.) Thanks, -Rick ________________________________ From: Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:48 PM To: Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: LSI Trim Patch Hi Rick, Just a quick note that you don't need to define WINDOWS_8 yourself. In a more WDK way, you may just wrap your changes with: #if (_WIN32_WINNT > _WIN32_WINNT_WIN7) #endif Then, it will be compiled without error on both Windows 8 WDK and 7600 WDK. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Friday, June 07, 2013 6:38 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** LSI Trim Patch Hi Ray, Per your request, since we will switch order, moving Intel patch to the number 3 position, I'm sending LSI's Trim patch. Password for the attached file is: lsi1234. Also, I have attached a document here that describes what was changed/added. It would be great if everyone can review and please let me know any feedback. Thanks. -Rick From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 03, 2013 5:12 PM To: Knoblaugh, Rick; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Rick, That's great news! LSI will be 3rd in line after IDT and Intel. Thanks for the contributions to TRIM. Thanks, Ray From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Ray, We also have the patch for Trim. It is ready to send. Please let me know when you would like me to send out. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1756 bytes Desc: image001.png URL: From Rick.Knoblaugh at lsi.com Mon Jun 17 09:56:44 2013 From: Rick.Knoblaugh at lsi.com (Knoblaugh, Rick) Date: Mon, 17 Jun 2013 10:56:44 -0600 Subject: [nvmewin] LSI Trim Patch In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFEF6E1@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBB1FBD5@cosmail03.lsi.com> <49158E750348AA499168FD41D88983606257AEE1@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBBD3022@cosmail03.lsi.com>, <548C5470AAD9DA4A85D259B663190D361FFEEBCB@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F013819F022@cosmail03.lsi.com> <05CD7821AE397547A01AC160FBC231474BCADF06@corpmail1.na.ads.idt.com>, <548C5470AAD9DA4A85D259B663190D361FFEF6E1@corpmail1.na.ads.idt.com> Message-ID: <4565AEA676113A449269C2F3A549520F013819F023@cosmail03.lsi.com> Hi Alex, My original thought in conditionally compiling was to preserve compatibility with the existing Win 7 WDK. Driver builds as it always has in that environment. Seems like a convenience for anyone who still wants to build using Win 7 WDK (perhaps they already have some automated builds in place or whatever, so why break it?) And, it exposes the same VPD pages as before, whereas there will be 3 new ones with Win 8 Trim support -- not saying that breaks anything in Win 7 or Win 2008 R2, but we do have proven mileage behind us with things as they are. If the goal is to have a single binary that runs across all of those OS flavors, you may want to put that validation down as a project for someone. I think Parag had tried building the driver as it exists today in the repository for Windows 8 and saw some issues when trying to install that binary under Windows 7. Perhaps if other folks have tried that, they can weigh in on this as well. Thanks, -Rick ________________________________________ From: Chang, Alex [Alex.Chang at idt.com] Sent: Monday, June 17, 2013 9:15 AM To: Kong, Kwok; Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Hi Rick, Kwok has a good point, especially that we're going to release signed binary later. Please add the changes you mentioned below and re-send your patch after running the basic tests (drive formats, SDStress, SCSICompliance and IOMeter) and TRIM specific tests. Thank you, Alex ________________________________ From: Kong, Kwok Sent: Monday, June 17, 2013 8:39 AM To: Knoblaugh, Rick; Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Rick, Is it possible to run the Windows 8 binary driver with Windows 7, Windows server 2008R2 and Windows server 2012 ? If it works, then there is no need to have conditional compile . We can require Windows 8 WDK to compile the source code such that we only need to build a single binary file for Windows 7, 8, Server 2008R2 and Server 2012. Thanks -Kwok From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Saturday, June 15, 2013 8:48 PM To: Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: Re: [nvmewin] LSI Trim Patch Hi Alex, We can make that tweak to change how it checks for Windows 8. Also, I discovered one other item that hasn't affected TRIM, but is not actually correct. In the SntiTranslateBLockLimitsPage function that implements the Block Limits VPD page, two items weren't being returned correctly. pBLPage->MaximumCompareAndWriteLength and pBLPage->MaximumTransferLength were being assigned the value of pCntrlIdData->MDTS -- and what needs to be returned there is not this field, but a calculation based on this field and PAE->pCtrlRegister->CAP.MPSMIN. And actually, we have the ability to scale that maximum transfer value back based on a registry setting, so rather than doing that calculation, what should probably be returned there is pAE->InitInfo.MaxTxSize. Another issue with what was being done is that the value for these fields within the BLock Limits VPD Page needs to be in blocks, so for both of those, we should be returning pAE->InitInfo.MaxTxSize / block size. We can put in those fixes. (Again, these weren't affecting the UNMAP stuff, but should be corrected.) Thanks, -Rick ________________________________ From: Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:48 PM To: Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: LSI Trim Patch Hi Rick, Just a quick note that you don't need to define WINDOWS_8 yourself. In a more WDK way, you may just wrap your changes with: #if (_WIN32_WINNT > _WIN32_WINNT_WIN7) #endif Then, it will be compiled without error on both Windows 8 WDK and 7600 WDK. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Friday, June 07, 2013 6:38 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** LSI Trim Patch Hi Ray, Per your request, since we will switch order, moving Intel patch to the number 3 position, I’m sending LSI’s Trim patch. Password for the attached file is: lsi1234. Also, I have attached a document here that describes what was changed/added. It would be great if everyone can review and please let me know any feedback. Thanks. -Rick From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 03, 2013 5:12 PM To: Knoblaugh, Rick; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Rick, That’s great news! LSI will be 3rd in line after IDT and Intel. Thanks for the contributions to TRIM. Thanks, Ray From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Ray, We also have the patch for Trim. It is ready to send. Please let me know when you would like me to send out. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I’m going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he’d like to push and I also have a patch I’d like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:695370816 at 17062013-1A83] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 From Alex.Chang at idt.com Mon Jun 17 10:29:57 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Mon, 17 Jun 2013 17:29:57 +0000 Subject: [nvmewin] LSI Trim Patch In-Reply-To: <4565AEA676113A449269C2F3A549520F013819F023@cosmail03.lsi.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBB1FBD5@cosmail03.lsi.com> <49158E750348AA499168FD41D88983606257AEE1@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBBD3022@cosmail03.lsi.com>, <548C5470AAD9DA4A85D259B663190D361FFEEBCB@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F013819F022@cosmail03.lsi.com> <05CD7821AE397547A01AC160FBC231474BCADF06@corpmail1.na.ads.idt.com>, <548C5470AAD9DA4A85D259B663190D361FFEF6E1@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F013819F023@cosmail03.lsi.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFF0735@corpmail1.na.ads.idt.com> Hi Rick, I see your point. We can release one binary for all supported OS flavors only if it works for all of them. We can discuss more in the meeting today in this regard. Thanks, Alex -----Original Message----- From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 17, 2013 9:57 AM To: Chang, Alex; Kong, Kwok; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Hi Alex, My original thought in conditionally compiling was to preserve compatibility with the existing Win 7 WDK. Driver builds as it always has in that environment. Seems like a convenience for anyone who still wants to build using Win 7 WDK (perhaps they already have some automated builds in place or whatever, so why break it?) And, it exposes the same VPD pages as before, whereas there will be 3 new ones with Win 8 Trim support -- not saying that breaks anything in Win 7 or Win 2008 R2, but we do have proven mileage behind us with things as they are. If the goal is to have a single binary that runs across all of those OS flavors, you may want to put that validation down as a project for someone. I think Parag had tried building the driver as it exists today in the repository for Windows 8 and saw some issues when trying to install that binary under Windows 7. Perhaps if other folks have tried that, they can weigh in on this as well. Thanks, -Rick ________________________________________ From: Chang, Alex [Alex.Chang at idt.com] Sent: Monday, June 17, 2013 9:15 AM To: Kong, Kwok; Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Hi Rick, Kwok has a good point, especially that we're going to release signed binary later. Please add the changes you mentioned below and re-send your patch after running the basic tests (drive formats, SDStress, SCSICompliance and IOMeter) and TRIM specific tests. Thank you, Alex ________________________________ From: Kong, Kwok Sent: Monday, June 17, 2013 8:39 AM To: Knoblaugh, Rick; Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Rick, Is it possible to run the Windows 8 binary driver with Windows 7, Windows server 2008R2 and Windows server 2012 ? If it works, then there is no need to have conditional compile . We can require Windows 8 WDK to compile the source code such that we only need to build a single binary file for Windows 7, 8, Server 2008R2 and Server 2012. Thanks -Kwok From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Saturday, June 15, 2013 8:48 PM To: Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: Re: [nvmewin] LSI Trim Patch Hi Alex, We can make that tweak to change how it checks for Windows 8. Also, I discovered one other item that hasn't affected TRIM, but is not actually correct. In the SntiTranslateBLockLimitsPage function that implements the Block Limits VPD page, two items weren't being returned correctly. pBLPage->MaximumCompareAndWriteLength and pBLPage->MaximumTransferLength were being assigned the value of pCntrlIdData->MDTS -- and what needs to be returned there is not this field, but a calculation based on this field and PAE->pCtrlRegister->CAP.MPSMIN. And actually, we have the ability to scale that maximum transfer value back based on a registry setting, so rather than doing that calculation, what should probably be returned there is pAE->InitInfo.MaxTxSize. Another issue with what was being done is that the value for these fields within the BLock Limits VPD Page needs to be in blocks, so for both of those, we should be returning pAE->InitInfo.MaxTxSize / block size. We can put in those fixes. (Again, these weren't affecting the UNMAP stuff, but should be corrected.) Thanks, -Rick ________________________________ From: Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:48 PM To: Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: LSI Trim Patch Hi Rick, Just a quick note that you don't need to define WINDOWS_8 yourself. In a more WDK way, you may just wrap your changes with: #if (_WIN32_WINNT > _WIN32_WINNT_WIN7) #endif Then, it will be compiled without error on both Windows 8 WDK and 7600 WDK. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Friday, June 07, 2013 6:38 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** LSI Trim Patch Hi Ray, Per your request, since we will switch order, moving Intel patch to the number 3 position, I'm sending LSI's Trim patch. Password for the attached file is: lsi1234. Also, I have attached a document here that describes what was changed/added. It would be great if everyone can review and please let me know any feedback. Thanks. -Rick From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 03, 2013 5:12 PM To: Knoblaugh, Rick; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Rick, That's great news! LSI will be 3rd in line after IDT and Intel. Thanks for the contributions to TRIM. Thanks, Ray From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Ray, We also have the patch for Trim. It is ready to send. Please let me know when you would like me to send out. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:695370816 at 17062013-1A83] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 From kris.r.murray at intel.com Mon Jun 17 11:54:33 2013 From: kris.r.murray at intel.com (Murray, Kris R) Date: Mon, 17 Jun 2013 18:54:33 +0000 Subject: [nvmewin] LSI Trim Patch In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFF0735@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBB1FBD5@cosmail03.lsi.com> <49158E750348AA499168FD41D88983606257AEE1@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBBD3022@cosmail03.lsi.com>, <548C5470AAD9DA4A85D259B663190D361FFEEBCB@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F013819F022@cosmail03.lsi.com> <05CD7821AE397547A01AC160FBC231474BCADF06@corpmail1.na.ads.idt.com>, <548C5470AAD9DA4A85D259B663190D361FFEF6E1@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F013819F023@cosmail03.lsi.com> <548C5470AAD9DA4A85D259B663190D361FFF0735@corpmail1.na.ads.idt.com> Message-ID: <6B4557D9CF036C4E8F9D6C561818DABB365D4DBD@FMSMSX112.amr.corp.intel.com> Rick, I agree with Kwok on removing the compile-time switch for use a single binary on Win7 and Win8. Other than that I have no additional feedback. ~Kris -----Original Message----- From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, June 17, 2013 10:30 AM To: Knoblaugh, Rick; Kong, Kwok; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: Re: [nvmewin] LSI Trim Patch Hi Rick, I see your point. We can release one binary for all supported OS flavors only if it works for all of them. We can discuss more in the meeting today in this regard. Thanks, Alex -----Original Message----- From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 17, 2013 9:57 AM To: Chang, Alex; Kong, Kwok; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Hi Alex, My original thought in conditionally compiling was to preserve compatibility with the existing Win 7 WDK. Driver builds as it always has in that environment. Seems like a convenience for anyone who still wants to build using Win 7 WDK (perhaps they already have some automated builds in place or whatever, so why break it?) And, it exposes the same VPD pages as before, whereas there will be 3 new ones with Win 8 Trim support -- not saying that breaks anything in Win 7 or Win 2008 R2, but we do have proven mileage behind us with things as they are. If the goal is to have a single binary that runs across all of those OS flavors, you may want to put that validation down as a project for someone. I think Parag had tried building the driver as it exists today in the repository for Windows 8 and saw some issues when trying to install that binary under Windows 7. Perhaps if other folks have tried that, they can weigh in on this as well. Thanks, -Rick ________________________________________ From: Chang, Alex [Alex.Chang at idt.com] Sent: Monday, June 17, 2013 9:15 AM To: Kong, Kwok; Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Hi Rick, Kwok has a good point, especially that we're going to release signed binary later. Please add the changes you mentioned below and re-send your patch after running the basic tests (drive formats, SDStress, SCSICompliance and IOMeter) and TRIM specific tests. Thank you, Alex ________________________________ From: Kong, Kwok Sent: Monday, June 17, 2013 8:39 AM To: Knoblaugh, Rick; Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Rick, Is it possible to run the Windows 8 binary driver with Windows 7, Windows server 2008R2 and Windows server 2012 ? If it works, then there is no need to have conditional compile . We can require Windows 8 WDK to compile the source code such that we only need to build a single binary file for Windows 7, 8, Server 2008R2 and Server 2012. Thanks -Kwok From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Saturday, June 15, 2013 8:48 PM To: Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: Re: [nvmewin] LSI Trim Patch Hi Alex, We can make that tweak to change how it checks for Windows 8. Also, I discovered one other item that hasn't affected TRIM, but is not actually correct. In the SntiTranslateBLockLimitsPage function that implements the Block Limits VPD page, two items weren't being returned correctly. pBLPage->MaximumCompareAndWriteLength and pBLPage->MaximumTransferLength were being assigned the value of pCntrlIdData->MDTS -- and what needs to be returned there is not this field, but a calculation based on this field and PAE->pCtrlRegister->CAP.MPSMIN. And actually, we have the ability to scale that maximum transfer value back based on a registry setting, so rather than doing that calculation, what should probably be returned there is pAE->InitInfo.MaxTxSize. Another issue with what was being done is that the value for these fields within the BLock Limits VPD Page needs to be in blocks, so for both of those, we should be returning pAE->InitInfo.MaxTxSize / block size. We can put in those fixes. (Again, these weren't affecting the UNMAP stuff, but should be corrected.) Thanks, -Rick ________________________________ From: Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:48 PM To: Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: LSI Trim Patch Hi Rick, Just a quick note that you don't need to define WINDOWS_8 yourself. In a more WDK way, you may just wrap your changes with: #if (_WIN32_WINNT > _WIN32_WINNT_WIN7) #endif Then, it will be compiled without error on both Windows 8 WDK and 7600 WDK. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Friday, June 07, 2013 6:38 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** LSI Trim Patch Hi Ray, Per your request, since we will switch order, moving Intel patch to the number 3 position, I'm sending LSI's Trim patch. Password for the attached file is: lsi1234. Also, I have attached a document here that describes what was changed/added. It would be great if everyone can review and please let me know any feedback. Thanks. -Rick From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 03, 2013 5:12 PM To: Knoblaugh, Rick; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Rick, That's great news! LSI will be 3rd in line after IDT and Intel. Thanks for the contributions to TRIM. Thanks, Ray From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Ray, We also have the patch for Trim. It is ready to send. Please let me know when you would like me to send out. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:695370816 at 17062013-1A83] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin From barrett.n.mayes at intel.com Mon Jun 17 13:58:42 2013 From: barrett.n.mayes at intel.com (Mayes, Barrett N) Date: Mon, 17 Jun 2013 20:58:42 +0000 Subject: [nvmewin] LSI Trim Patch In-Reply-To: <4565AEA676113A449269C2F3A549520F013819F023@cosmail03.lsi.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBB1FBD5@cosmail03.lsi.com> <49158E750348AA499168FD41D88983606257AEE1@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBBD3022@cosmail03.lsi.com>, <548C5470AAD9DA4A85D259B663190D361FFEEBCB@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F013819F022@cosmail03.lsi.com> <05CD7821AE397547A01AC160FBC231474BCADF06@corpmail1.na.ads.idt.com>, <548C5470AAD9DA4A85D259B663190D361FFEF6E1@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F013819F023@cosmail03.lsi.com> Message-ID: Creating a single binary that will run across both win7 and win8 is possible but takes some tweaking of the VS projects to get everything right. As a "reference" driver, it will be simpler to just keep the two separate. For anyone wanting to attempt making a single binary that load on both win7 and win8 and enable win8 features at runtime on win8, I have had success building a driver with VS2012/win8 WDK along with a change to link against bufferoverflowk.lib rather than the default bufferoverflowfastfailk.lib. The latter is not available on win7 so the driver will fail to load because of the missing dependency if it's built with default Win8 settings. The library can be overridden a number of different ways and different vendors may chose a different method depending on their needs. There are some other gotchas as well if you make use of certain WDM APIs outside of the storport model. -----Original Message----- From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Monday, June 17, 2013 9:57 AM To: Chang, Alex; Kong, Kwok; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: Re: [nvmewin] LSI Trim Patch Hi Alex, My original thought in conditionally compiling was to preserve compatibility with the existing Win 7 WDK. Driver builds as it always has in that environment. Seems like a convenience for anyone who still wants to build using Win 7 WDK (perhaps they already have some automated builds in place or whatever, so why break it?) And, it exposes the same VPD pages as before, whereas there will be 3 new ones with Win 8 Trim support -- not saying that breaks anything in Win 7 or Win 2008 R2, but we do have proven mileage behind us with things as they are. If the goal is to have a single binary that runs across all of those OS flavors, you may want to put that validation down as a project for someone. I think Parag had tried building the driver as it exists today in the repository for Windows 8 and saw some issues when trying to install that binary under Windows 7. Perhaps if other folks have tried that, they can weigh in on this as well. Thanks, -Rick ________________________________________ From: Chang, Alex [Alex.Chang at idt.com] Sent: Monday, June 17, 2013 9:15 AM To: Kong, Kwok; Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Hi Rick, Kwok has a good point, especially that we're going to release signed binary later. Please add the changes you mentioned below and re-send your patch after running the basic tests (drive formats, SDStress, SCSICompliance and IOMeter) and TRIM specific tests. Thank you, Alex ________________________________ From: Kong, Kwok Sent: Monday, June 17, 2013 8:39 AM To: Knoblaugh, Rick; Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Rick, Is it possible to run the Windows 8 binary driver with Windows 7, Windows server 2008R2 and Windows server 2012 ? If it works, then there is no need to have conditional compile . We can require Windows 8 WDK to compile the source code such that we only need to build a single binary file for Windows 7, 8, Server 2008R2 and Server 2012. Thanks -Kwok From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Saturday, June 15, 2013 8:48 PM To: Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: Re: [nvmewin] LSI Trim Patch Hi Alex, We can make that tweak to change how it checks for Windows 8. Also, I discovered one other item that hasn't affected TRIM, but is not actually correct. In the SntiTranslateBLockLimitsPage function that implements the Block Limits VPD page, two items weren't being returned correctly. pBLPage->MaximumCompareAndWriteLength and pBLPage->MaximumTransferLength were being assigned the value of pCntrlIdData->MDTS -- and what needs to be returned there is not this field, but a calculation based on this field and PAE->pCtrlRegister->CAP.MPSMIN. And actually, we have the ability to scale that maximum transfer value back based on a registry setting, so rather than doing that calculation, what should probably be returned there is pAE->InitInfo.MaxTxSize. Another issue with what was being done is that the value for these fields within the BLock Limits VPD Page needs to be in blocks, so for both of those, we should be returning pAE->InitInfo.MaxTxSize / block size. We can put in those fixes. (Again, these weren't affecting the UNMAP stuff, but should be corrected.) Thanks, -Rick ________________________________ From: Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:48 PM To: Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: LSI Trim Patch Hi Rick, Just a quick note that you don't need to define WINDOWS_8 yourself. In a more WDK way, you may just wrap your changes with: #if (_WIN32_WINNT > _WIN32_WINNT_WIN7) #endif Then, it will be compiled without error on both Windows 8 WDK and 7600 WDK. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Friday, June 07, 2013 6:38 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** LSI Trim Patch Hi Ray, Per your request, since we will switch order, moving Intel patch to the number 3 position, I'm sending LSI's Trim patch. Password for the attached file is: lsi1234. Also, I have attached a document here that describes what was changed/added. It would be great if everyone can review and please let me know any feedback. Thanks. -Rick From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 03, 2013 5:12 PM To: Knoblaugh, Rick; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Rick, That's great news! LSI will be 3rd in line after IDT and Intel. Thanks for the contributions to TRIM. Thanks, Ray From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Ray, We also have the patch for Trim. It is ready to send. Please let me know when you would like me to send out. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:695370816 at 17062013-1A83] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin From Kwok.Kong at idt.com Mon Jun 17 14:46:44 2013 From: Kwok.Kong at idt.com (Kong, Kwok) Date: Mon, 17 Jun 2013 21:46:44 +0000 Subject: [nvmewin] Windows driver June 17, 2013 meeting note Message-ID: <05CD7821AE397547A01AC160FBC231474BCAE247@corpmail1.na.ads.idt.com> NVMe OFA Windows Driver Meeting Note (June 17, 2013) High level Summary ================== 1. Release 1.2 is expected to be released by end of July 2013. 2. Two binary files will be released - one version supports Windows 7, 8. server 2008R2 and 2012 64-bit but without the TRIM command. - Second version supports Windows 8 64-bit only with TRIM command support. 3. Release 1.3 will be release by Dec 2013 with the following features - windows 32-bit support - Windows 8 extended SRB support - end to end protection support with Windows server 2012 - NVM format state machine enhancement Release 1.2 Status ================== Features: - Alex (IDT) has completed his testing with Windows 8, Server 2008R2 and server 2012 64-bit. The current driver works with all Windows 64-bit OSes. - Alex (IDT) has checked in the code change to support NVMe 1.00e. - Rick (LSI) has submitted a patch to support the TRIM command. He is going to make a coupe of minor update and send the final patch for approval to check in. - Yong (Huawei) has finished the development of the hibernation as a boot drive. There is a problem in the power state transition. It is going to take another week before he can send out his patch for review. He is the 4th in line to send his patch out for review and approval. Known Problems: - Not Accessing NVMe registers in their native width. (Intel) - Code completed. 3rd inline to send patch for review. - ModeSense Translation issue. (Dharani - SanDisk) - Code and testing completed. 2nd inline to send patch for review. - format nvm error. (Judy - Samsung) - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset. (Judy - Samsung) - Code snippets sent out for review. 5th in line to send patch for review. Release 1.3 Plan (Dec 2013) =========================== The following features will be added in the 1.3 release: - Windows 32-bit support (Judy to check with Samsung) - Windows 8 extended SRB support and SMART handling (Kwok to check with Intel) - end to end protection support with Windows server 2012 (Yong - Huawei) - NVM format state machine enhancement (Alex - IDT) Features that will not be supported in 2013 =========================================== NVMe 1.1 support: - multi-path - SGL - Get/Set feature update - Autonomous power state transition - Host Identifier - Reservation Notification Mask - Reservation Persistence - identify structure update - write zeros command Others ====== - Yong (Huawei) is going to check with Microsoft on why binary built with Windows 8 WDK does not work with Windows 7. Next Meeting ============ - Will be scheduled when necessary. Likely to be around Sep time frame. From Rick.Knoblaugh at lsi.com Mon Jun 17 21:28:15 2013 From: Rick.Knoblaugh at lsi.com (Knoblaugh, Rick) Date: Mon, 17 Jun 2013 22:28:15 -0600 Subject: [nvmewin] Windows driver June 17, 2013 meeting note In-Reply-To: <05CD7821AE397547A01AC160FBC231474BCAE247@corpmail1.na.ads.idt.com> References: <05CD7821AE397547A01AC160FBC231474BCAE247@corpmail1.na.ads.idt.com> Message-ID: <4565AEA676113A449269C2F3A549520F013819F025@cosmail03.lsi.com> Hi Kwok, One note regarding versions: I am told that Windows Server 2012 has the same storage stack as Windows 8, so it should support Trim as well. (Actually, my first clue should have been when I saw this description of version checking: _WIN32_WINNT_WIN8 : Windows 8 and Windows Server 2012.) Thanks, -Rick ________________________________________ From: nvmewin-bounces at lists.openfabrics.org [nvmewin-bounces at lists.openfabrics.org] On Behalf Of Kong, Kwok [Kwok.Kong at idt.com] Sent: Monday, June 17, 2013 2:46 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Windows driver June 17, 2013 meeting note NVMe OFA Windows Driver Meeting Note (June 17, 2013) High level Summary ================== 1. Release 1.2 is expected to be released by end of July 2013. 2. Two binary files will be released - one version supports Windows 7, 8. server 2008R2 and 2012 64-bit but without the TRIM command. - Second version supports Windows 8 64-bit only with TRIM command support. 3. Release 1.3 will be release by Dec 2013 with the following features - windows 32-bit support - Windows 8 extended SRB support - end to end protection support with Windows server 2012 - NVM format state machine enhancement Release 1.2 Status ================== Features: - Alex (IDT) has completed his testing with Windows 8, Server 2008R2 and server 2012 64-bit. The current driver works with all Windows 64-bit OSes. - Alex (IDT) has checked in the code change to support NVMe 1.00e. - Rick (LSI) has submitted a patch to support the TRIM command. He is going to make a coupe of minor update and send the final patch for approval to check in. - Yong (Huawei) has finished the development of the hibernation as a boot drive. There is a problem in the power state transition. It is going to take another week before he can send out his patch for review. He is the 4th in line to send his patch out for review and approval. Known Problems: - Not Accessing NVMe registers in their native width. (Intel) - Code completed. 3rd inline to send patch for review. - ModeSense Translation issue. (Dharani - SanDisk) - Code and testing completed. 2nd inline to send patch for review. - format nvm error. (Judy - Samsung) - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset. (Judy - Samsung) - Code snippets sent out for review. 5th in line to send patch for review. Release 1.3 Plan (Dec 2013) =========================== The following features will be added in the 1.3 release: - Windows 32-bit support (Judy to check with Samsung) - Windows 8 extended SRB support and SMART handling (Kwok to check with Intel) - end to end protection support with Windows server 2012 (Yong - Huawei) - NVM format state machine enhancement (Alex - IDT) Features that will not be supported in 2013 =========================================== NVMe 1.1 support: - multi-path - SGL - Get/Set feature update - Autonomous power state transition - Host Identifier - Reservation Notification Mask - Reservation Persistence - identify structure update - write zeros command Others ====== - Yong (Huawei) is going to check with Microsoft on why binary built with Windows 8 WDK does not work with Windows 7. Next Meeting ============ - Will be scheduled when necessary. Likely to be around Sep time frame. _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin From Kwok.Kong at idt.com Tue Jun 18 08:33:22 2013 From: Kwok.Kong at idt.com (Kong, Kwok) Date: Tue, 18 Jun 2013 15:33:22 +0000 Subject: [nvmewin] Windows driver June 17, 2013 meeting note In-Reply-To: <4565AEA676113A449269C2F3A549520F013819F025@cosmail03.lsi.com> References: <05CD7821AE397547A01AC160FBC231474BCAE247@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F013819F025@cosmail03.lsi.com> Message-ID: <05CD7821AE397547A01AC160FBC231474BCAE3EA@corpmail1.na.ads.idt.com> Rick, Thanks for the clarification. -Kwok -----Original Message----- From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 17, 2013 9:28 PM To: Kong, Kwok; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Windows driver June 17, 2013 meeting note Hi Kwok, One note regarding versions: I am told that Windows Server 2012 has the same storage stack as Windows 8, so it should support Trim as well. (Actually, my first clue should have been when I saw this description of version checking: _WIN32_WINNT_WIN8 : Windows 8 and Windows Server 2012.) Thanks, -Rick ________________________________________ From: nvmewin-bounces at lists.openfabrics.org [nvmewin-bounces at lists.openfabrics.org] On Behalf Of Kong, Kwok [Kwok.Kong at idt.com] Sent: Monday, June 17, 2013 2:46 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Windows driver June 17, 2013 meeting note NVMe OFA Windows Driver Meeting Note (June 17, 2013) High level Summary ================== 1. Release 1.2 is expected to be released by end of July 2013. 2. Two binary files will be released - one version supports Windows 7, 8. server 2008R2 and 2012 64-bit but without the TRIM command. - Second version supports Windows 8 64-bit only with TRIM command support. 3. Release 1.3 will be release by Dec 2013 with the following features - windows 32-bit support - Windows 8 extended SRB support - end to end protection support with Windows server 2012 - NVM format state machine enhancement Release 1.2 Status ================== Features: - Alex (IDT) has completed his testing with Windows 8, Server 2008R2 and server 2012 64-bit. The current driver works with all Windows 64-bit OSes. - Alex (IDT) has checked in the code change to support NVMe 1.00e. - Rick (LSI) has submitted a patch to support the TRIM command. He is going to make a coupe of minor update and send the final patch for approval to check in. - Yong (Huawei) has finished the development of the hibernation as a boot drive. There is a problem in the power state transition. It is going to take another week before he can send out his patch for review. He is the 4th in line to send his patch out for review and approval. Known Problems: - Not Accessing NVMe registers in their native width. (Intel) - Code completed. 3rd inline to send patch for review. - ModeSense Translation issue. (Dharani - SanDisk) - Code and testing completed. 2nd inline to send patch for review. - format nvm error. (Judy - Samsung) - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset. (Judy - Samsung) - Code snippets sent out for review. 5th in line to send patch for review. Release 1.3 Plan (Dec 2013) =========================== The following features will be added in the 1.3 release: - Windows 32-bit support (Judy to check with Samsung) - Windows 8 extended SRB support and SMART handling (Kwok to check with Intel) - end to end protection support with Windows server 2012 (Yong - Huawei) - NVM format state machine enhancement (Alex - IDT) Features that will not be supported in 2013 =========================================== NVMe 1.1 support: - multi-path - SGL - Get/Set feature update - Autonomous power state transition - Host Identifier - Reservation Notification Mask - Reservation Persistence - identify structure update - write zeros command Others ====== - Yong (Huawei) is going to check with Microsoft on why binary built with Windows 8 WDK does not work with Windows 7. Next Meeting ============ - Will be scheduled when necessary. Likely to be around Sep time frame. _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin From judy.brock at ssi.samsung.com Tue Jun 18 16:14:40 2013 From: judy.brock at ssi.samsung.com (Judy Brock-SSI) Date: Tue, 18 Jun 2013 23:14:40 +0000 Subject: [nvmewin] Windows driver June 17, 2013 meeting note In-Reply-To: <05CD7821AE397547A01AC160FBC231474BCAE247@corpmail1.na.ads.idt.com> References: <05CD7821AE397547A01AC160FBC231474BCAE247@corpmail1.na.ads.idt.com> Message-ID: <36E8D38D6B771A4BBDB1C0D800158A51308CA1CB@SSIEXCH-MB2.ssi.samsung.com> Kwok, >> - Windows 32-bit support (Judy to check with Samsung) Unfortunately Samsung will not be able to take this work item on. Thanks, Judy -----Original Message----- From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Kong, Kwok Sent: Monday, June 17, 2013 2:47 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Windows driver June 17, 2013 meeting note NVMe OFA Windows Driver Meeting Note (June 17, 2013) High level Summary ================== 1. Release 1.2 is expected to be released by end of July 2013. 2. Two binary files will be released - one version supports Windows 7, 8. server 2008R2 and 2012 64-bit but without the TRIM command. - Second version supports Windows 8 64-bit only with TRIM command support. 3. Release 1.3 will be release by Dec 2013 with the following features - windows 32-bit support - Windows 8 extended SRB support - end to end protection support with Windows server 2012 - NVM format state machine enhancement Release 1.2 Status ================== Features: - Alex (IDT) has completed his testing with Windows 8, Server 2008R2 and server 2012 64-bit. The current driver works with all Windows 64-bit OSes. - Alex (IDT) has checked in the code change to support NVMe 1.00e. - Rick (LSI) has submitted a patch to support the TRIM command. He is going to make a coupe of minor update and send the final patch for approval to check in. - Yong (Huawei) has finished the development of the hibernation as a boot drive. There is a problem in the power state transition. It is going to take another week before he can send out his patch for review. He is the 4th in line to send his patch out for review and approval. Known Problems: - Not Accessing NVMe registers in their native width. (Intel) - Code completed. 3rd inline to send patch for review. - ModeSense Translation issue. (Dharani - SanDisk) - Code and testing completed. 2nd inline to send patch for review. - format nvm error. (Judy - Samsung) - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset. (Judy - Samsung) - Code snippets sent out for review. 5th in line to send patch for review. Release 1.3 Plan (Dec 2013) =========================== The following features will be added in the 1.3 release: - Windows 32-bit support (Judy to check with Samsung) - Windows 8 extended SRB support and SMART handling (Kwok to check with Intel) - end to end protection support with Windows server 2012 (Yong - Huawei) - NVM format state machine enhancement (Alex - IDT) Features that will not be supported in 2013 =========================================== NVMe 1.1 support: - multi-path - SGL - Get/Set feature update - Autonomous power state transition - Host Identifier - Reservation Notification Mask - Reservation Persistence - identify structure update - write zeros command Others ====== - Yong (Huawei) is going to check with Microsoft on why binary built with Windows 8 WDK does not work with Windows 7. Next Meeting ============ - Will be scheduled when necessary. Likely to be around Sep time frame. _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin From Kwok.Kong at idt.com Tue Jun 18 16:42:09 2013 From: Kwok.Kong at idt.com (Kong, Kwok) Date: Tue, 18 Jun 2013 23:42:09 +0000 Subject: [nvmewin] Windows driver June 17, 2013 meeting note In-Reply-To: <36E8D38D6B771A4BBDB1C0D800158A51308CA1CB@SSIEXCH-MB2.ssi.samsung.com> References: <05CD7821AE397547A01AC160FBC231474BCAE247@corpmail1.na.ads.idt.com> <36E8D38D6B771A4BBDB1C0D800158A51308CA1CB@SSIEXCH-MB2.ssi.samsung.com> Message-ID: <05CD7821AE397547A01AC160FBC231474BCAE7A5@corpmail1.na.ads.idt.com> Judy, Thanks for checking. -Kwok -----Original Message----- From: Judy Brock-SSI [mailto:judy.brock at ssi.samsung.com] Sent: Tuesday, June 18, 2013 4:15 PM To: Kong, Kwok; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] Windows driver June 17, 2013 meeting note Kwok, >> - Windows 32-bit support (Judy to check with Samsung) Unfortunately Samsung will not be able to take this work item on. Thanks, Judy -----Original Message----- From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Kong, Kwok Sent: Monday, June 17, 2013 2:47 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Windows driver June 17, 2013 meeting note NVMe OFA Windows Driver Meeting Note (June 17, 2013) High level Summary ================== 1. Release 1.2 is expected to be released by end of July 2013. 2. Two binary files will be released - one version supports Windows 7, 8. server 2008R2 and 2012 64-bit but without the TRIM command. - Second version supports Windows 8 64-bit only with TRIM command support. 3. Release 1.3 will be release by Dec 2013 with the following features - windows 32-bit support - Windows 8 extended SRB support - end to end protection support with Windows server 2012 - NVM format state machine enhancement Release 1.2 Status ================== Features: - Alex (IDT) has completed his testing with Windows 8, Server 2008R2 and server 2012 64-bit. The current driver works with all Windows 64-bit OSes. - Alex (IDT) has checked in the code change to support NVMe 1.00e. - Rick (LSI) has submitted a patch to support the TRIM command. He is going to make a coupe of minor update and send the final patch for approval to check in. - Yong (Huawei) has finished the development of the hibernation as a boot drive. There is a problem in the power state transition. It is going to take another week before he can send out his patch for review. He is the 4th in line to send his patch out for review and approval. Known Problems: - Not Accessing NVMe registers in their native width. (Intel) - Code completed. 3rd inline to send patch for review. - ModeSense Translation issue. (Dharani - SanDisk) - Code and testing completed. 2nd inline to send patch for review. - format nvm error. (Judy - Samsung) - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset. (Judy - Samsung) - Code snippets sent out for review. 5th in line to send patch for review. Release 1.3 Plan (Dec 2013) =========================== The following features will be added in the 1.3 release: - Windows 32-bit support (Judy to check with Samsung) - Windows 8 extended SRB support and SMART handling (Kwok to check with Intel) - end to end protection support with Windows server 2012 (Yong - Huawei) - NVM format state machine enhancement (Alex - IDT) Features that will not be supported in 2013 =========================================== NVMe 1.1 support: - multi-path - SGL - Get/Set feature update - Autonomous power state transition - Host Identifier - Reservation Notification Mask - Reservation Persistence - identify structure update - write zeros command Others ====== - Yong (Huawei) is going to check with Microsoft on why binary built with Windows 8 WDK does not work with Windows 7. Next Meeting ============ - Will be scheduled when necessary. Likely to be around Sep time frame. _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin From Rick.Knoblaugh at lsi.com Thu Jun 20 15:06:58 2013 From: Rick.Knoblaugh at lsi.com (Knoblaugh, Rick) Date: Thu, 20 Jun 2013 16:06:58 -0600 Subject: [nvmewin] ***UNCHECKED*** LSI Trim Patch In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFF0735@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBB1FBD5@cosmail03.lsi.com> <49158E750348AA499168FD41D88983606257AEE1@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBBD3022@cosmail03.lsi.com>, <548C5470AAD9DA4A85D259B663190D361FFEEBCB@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F013819F022@cosmail03.lsi.com> <05CD7821AE397547A01AC160FBC231474BCADF06@corpmail1.na.ads.idt.com>, <548C5470AAD9DA4A85D259B663190D361FFEF6E1@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F013819F023@cosmail03.lsi.com> <548C5470AAD9DA4A85D259B663190D361FFF0735@corpmail1.na.ads.idt.com> Message-ID: <4565AEA676113A449269C2F3A549520F0138186A1C@cosmail03.lsi.com> Hi Alex, I was hoping to send this earlier, but we had to deal with some logistical stuff getting into our new building. Here is the patch with the minor tweaks we discussed. Even though there is basically no change, we reran tests and such. There were only two changes: In nvmesnti.c, in the SntiTranslateBlockLimitsPage fuction, we are being consistent with what Microsoft's AHCI Storport miniport driver does and only explicitly providing values for Maximum UNMAP LBA Count and Maximum UNMAP Block Descriptor Count. Changed conditional compile for Win 8 to use #if _WIN32_WINNT > _WIN32_WINNT_WIN7. (And removed #define WINDOWS_8 from nvmestd.h.) Password is lsi1234 Thanks, -Rick -----Original Message----- From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, June 17, 2013 10:30 AM To: Knoblaugh, Rick; Kong, Kwok; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Hi Rick, I see your point. We can release one binary for all supported OS flavors only if it works for all of them. We can discuss more in the meeting today in this regard. Thanks, Alex -----Original Message----- From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 17, 2013 9:57 AM To: Chang, Alex; Kong, Kwok; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Hi Alex, My original thought in conditionally compiling was to preserve compatibility with the existing Win 7 WDK. Driver builds as it always has in that environment. Seems like a convenience for anyone who still wants to build using Win 7 WDK (perhaps they already have some automated builds in place or whatever, so why break it?) And, it exposes the same VPD pages as before, whereas there will be 3 new ones with Win 8 Trim support -- not saying that breaks anything in Win 7 or Win 2008 R2, but we do have proven mileage behind us with things as they are. If the goal is to have a single binary that runs across all of those OS flavors, you may want to put that validation down as a project for someone. I think Parag had tried building the driver as it exists today in the repository for Windows 8 and saw some issues when trying to install that binary under Windows 7. Perhaps if other folks have tried that, they can weigh in on this as well. Thanks, -Rick ________________________________________ From: Chang, Alex [Alex.Chang at idt.com] Sent: Monday, June 17, 2013 9:15 AM To: Kong, Kwok; Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Hi Rick, Kwok has a good point, especially that we're going to release signed binary later. Please add the changes you mentioned below and re-send your patch after running the basic tests (drive formats, SDStress, SCSICompliance and IOMeter) and TRIM specific tests. Thank you, Alex ________________________________ From: Kong, Kwok Sent: Monday, June 17, 2013 8:39 AM To: Knoblaugh, Rick; Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Rick, Is it possible to run the Windows 8 binary driver with Windows 7, Windows server 2008R2 and Windows server 2012 ? If it works, then there is no need to have conditional compile . We can require Windows 8 WDK to compile the source code such that we only need to build a single binary file for Windows 7, 8, Server 2008R2 and Server 2012. Thanks -Kwok From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Saturday, June 15, 2013 8:48 PM To: Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: Re: [nvmewin] LSI Trim Patch Hi Alex, We can make that tweak to change how it checks for Windows 8. Also, I discovered one other item that hasn't affected TRIM, but is not actually correct. In the SntiTranslateBLockLimitsPage function that implements the Block Limits VPD page, two items weren't being returned correctly. pBLPage->MaximumCompareAndWriteLength and pBLPage->MaximumTransferLength were being assigned the value of pCntrlIdData->MDTS -- and what needs to be returned there is not this field, but a calculation based on this field and PAE->pCtrlRegister->CAP.MPSMIN. And actually, we have the ability to scale that maximum transfer value back based on a registry setting, so rather than doing that calculation, what should probably be returned there is pAE->InitInfo.MaxTxSize. Another issue with what was being done is that the value for these fields within the BLock Limits VPD Page needs to be in blocks, so for both of those, we should be returning pAE->InitInfo.MaxTxSize / block size. We can put in those fixes. (Again, these weren't affecting the UNMAP stuff, but should be corrected.) Thanks, -Rick ________________________________ From: Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:48 PM To: Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: LSI Trim Patch Hi Rick, Just a quick note that you don't need to define WINDOWS_8 yourself. In a more WDK way, you may just wrap your changes with: #if (_WIN32_WINNT > _WIN32_WINNT_WIN7) #endif Then, it will be compiled without error on both Windows 8 WDK and 7600 WDK. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Friday, June 07, 2013 6:38 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** LSI Trim Patch Hi Ray, Per your request, since we will switch order, moving Intel patch to the number 3 position, I'm sending LSI's Trim patch. Password for the attached file is: lsi1234. Also, I have attached a document here that describes what was changed/added. It would be great if everyone can review and please let me know any feedback. Thanks. -Rick From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 03, 2013 5:12 PM To: Knoblaugh, Rick; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Rick, That's great news! LSI will be 3rd in line after IDT and Intel. Thanks for the contributions to TRIM. Thanks, Ray From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Ray, We also have the patch for Trim. It is ready to send. Please let me know when you would like me to send out. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:695370816 at 17062013-1A83] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 -------------- next part -------------- A non-text attachment was scrubbed... Name: LSI_Trim_Patch_Ver2.zip Type: application/x-zip-compressed Size: 167877 bytes Desc: LSI_Trim_Patch_Ver2.zip URL: From Alex.Chang at idt.com Thu Jun 20 16:50:21 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Thu, 20 Jun 2013 23:50:21 +0000 Subject: [nvmewin] LSI Trim Patch In-Reply-To: <4565AEA676113A449269C2F3A549520F0138186A1C@cosmail03.lsi.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBB1FBD5@cosmail03.lsi.com> <49158E750348AA499168FD41D88983606257AEE1@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBBD3022@cosmail03.lsi.com>, <548C5470AAD9DA4A85D259B663190D361FFEEBCB@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F013819F022@cosmail03.lsi.com> <05CD7821AE397547A01AC160FBC231474BCADF06@corpmail1.na.ads.idt.com>, <548C5470AAD9DA4A85D259B663190D361FFEF6E1@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F013819F023@cosmail03.lsi.com> <548C5470AAD9DA4A85D259B663190D361FFF0735@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F0138186A1C@cosmail03.lsi.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFF45C4@corpmail1.na.ads.idt.com> Thank you, Rick. I will re-run the tests and let you know later. Hi Kris, Could you please provide your feedbacks at your earliest convenience? Thanks, Alex -----Original Message----- From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Thursday, June 20, 2013 3:07 PM To: Chang, Alex; Kong, Kwok; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: LSI Trim Patch Hi Alex, I was hoping to send this earlier, but we had to deal with some logistical stuff getting into our new building. Here is the patch with the minor tweaks we discussed. Even though there is basically no change, we reran tests and such. There were only two changes: In nvmesnti.c, in the SntiTranslateBlockLimitsPage fuction, we are being consistent with what Microsoft's AHCI Storport miniport driver does and only explicitly providing values for Maximum UNMAP LBA Count and Maximum UNMAP Block Descriptor Count. Changed conditional compile for Win 8 to use #if _WIN32_WINNT > _WIN32_WINNT_WIN7. (And removed #define WINDOWS_8 from nvmestd.h.) Password is lsi1234 Thanks, -Rick -----Original Message----- From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, June 17, 2013 10:30 AM To: Knoblaugh, Rick; Kong, Kwok; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Hi Rick, I see your point. We can release one binary for all supported OS flavors only if it works for all of them. We can discuss more in the meeting today in this regard. Thanks, Alex -----Original Message----- From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 17, 2013 9:57 AM To: Chang, Alex; Kong, Kwok; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Hi Alex, My original thought in conditionally compiling was to preserve compatibility with the existing Win 7 WDK. Driver builds as it always has in that environment. Seems like a convenience for anyone who still wants to build using Win 7 WDK (perhaps they already have some automated builds in place or whatever, so why break it?) And, it exposes the same VPD pages as before, whereas there will be 3 new ones with Win 8 Trim support -- not saying that breaks anything in Win 7 or Win 2008 R2, but we do have proven mileage behind us with things as they are. If the goal is to have a single binary that runs across all of those OS flavors, you may want to put that validation down as a project for someone. I think Parag had tried building the driver as it exists today in the repository for Windows 8 and saw some issues when trying to install that binary under Windows 7. Perhaps if other folks have tried that, they can weigh in on this as well. Thanks, -Rick ________________________________________ From: Chang, Alex [Alex.Chang at idt.com] Sent: Monday, June 17, 2013 9:15 AM To: Kong, Kwok; Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Hi Rick, Kwok has a good point, especially that we're going to release signed binary later. Please add the changes you mentioned below and re-send your patch after running the basic tests (drive formats, SDStress, SCSICompliance and IOMeter) and TRIM specific tests. Thank you, Alex ________________________________ From: Kong, Kwok Sent: Monday, June 17, 2013 8:39 AM To: Knoblaugh, Rick; Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Rick, Is it possible to run the Windows 8 binary driver with Windows 7, Windows server 2008R2 and Windows server 2012 ? If it works, then there is no need to have conditional compile . We can require Windows 8 WDK to compile the source code such that we only need to build a single binary file for Windows 7, 8, Server 2008R2 and Server 2012. Thanks -Kwok From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Saturday, June 15, 2013 8:48 PM To: Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: Re: [nvmewin] LSI Trim Patch Hi Alex, We can make that tweak to change how it checks for Windows 8. Also, I discovered one other item that hasn't affected TRIM, but is not actually correct. In the SntiTranslateBLockLimitsPage function that implements the Block Limits VPD page, two items weren't being returned correctly. pBLPage->MaximumCompareAndWriteLength and pBLPage->MaximumTransferLength were being assigned the value of pCntrlIdData->MDTS -- and what needs to be returned there is not this field, but a calculation based on this field and PAE->pCtrlRegister->CAP.MPSMIN. And actually, we have the ability to scale that maximum transfer value back based on a registry setting, so rather than doing that calculation, what should probably be returned there is pAE->InitInfo.MaxTxSize. Another issue with what was being done is that the value for these fields within the BLock Limits VPD Page needs to be in blocks, so for both of those, we should be returning pAE->InitInfo.MaxTxSize / block size. We can put in those fixes. (Again, these weren't affecting the UNMAP stuff, but should be corrected.) Thanks, -Rick ________________________________ From: Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:48 PM To: Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: LSI Trim Patch Hi Rick, Just a quick note that you don't need to define WINDOWS_8 yourself. In a more WDK way, you may just wrap your changes with: #if (_WIN32_WINNT > _WIN32_WINNT_WIN7) #endif Then, it will be compiled without error on both Windows 8 WDK and 7600 WDK. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Friday, June 07, 2013 6:38 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** LSI Trim Patch Hi Ray, Per your request, since we will switch order, moving Intel patch to the number 3 position, I'm sending LSI's Trim patch. Password for the attached file is: lsi1234. Also, I have attached a document here that describes what was changed/added. It would be great if everyone can review and please let me know any feedback. Thanks. -Rick From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 03, 2013 5:12 PM To: Knoblaugh, Rick; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Rick, That's great news! LSI will be 3rd in line after IDT and Intel. Thanks for the contributions to TRIM. Thanks, Ray From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Ray, We also have the patch for Trim. It is ready to send. Please let me know when you would like me to send out. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:695370816 at 17062013-1A83] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 From kris.r.murray at intel.com Mon Jun 24 08:02:13 2013 From: kris.r.murray at intel.com (Murray, Kris R) Date: Mon, 24 Jun 2013 15:02:13 +0000 Subject: [nvmewin] LSI Trim Patch In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFF45C4@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBB1FBD5@cosmail03.lsi.com> <49158E750348AA499168FD41D88983606257AEE1@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBBD3022@cosmail03.lsi.com>, <548C5470AAD9DA4A85D259B663190D361FFEEBCB@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F013819F022@cosmail03.lsi.com> <05CD7821AE397547A01AC160FBC231474BCADF06@corpmail1.na.ads.idt.com>, <548C5470AAD9DA4A85D259B663190D361FFEF6E1@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F013819F023@cosmail03.lsi.com> <548C5470AAD9DA4A85D259B663190D361FFF0735@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F0138186A1C@cosmail03.lsi.com> <548C5470AAD9DA4A85D259B663190D361FFF45C4@corpmail1.na.ads.idt.com> Message-ID: <6B4557D9CF036C4E8F9D6C561818DABB365D6462@FMSMSX112.amr.corp.intel.com> Rick, Changes look good to me. ~Kris -----Original Message----- From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, June 20, 2013 4:50 PM To: Knoblaugh, Rick; Kong, Kwok; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: Re: [nvmewin] LSI Trim Patch Thank you, Rick. I will re-run the tests and let you know later. Hi Kris, Could you please provide your feedbacks at your earliest convenience? Thanks, Alex -----Original Message----- From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Thursday, June 20, 2013 3:07 PM To: Chang, Alex; Kong, Kwok; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: LSI Trim Patch Hi Alex, I was hoping to send this earlier, but we had to deal with some logistical stuff getting into our new building. Here is the patch with the minor tweaks we discussed. Even though there is basically no change, we reran tests and such. There were only two changes: In nvmesnti.c, in the SntiTranslateBlockLimitsPage fuction, we are being consistent with what Microsoft's AHCI Storport miniport driver does and only explicitly providing values for Maximum UNMAP LBA Count and Maximum UNMAP Block Descriptor Count. Changed conditional compile for Win 8 to use #if _WIN32_WINNT > _WIN32_WINNT_WIN7. (And removed #define WINDOWS_8 from nvmestd.h.) Password is lsi1234 Thanks, -Rick -----Original Message----- From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, June 17, 2013 10:30 AM To: Knoblaugh, Rick; Kong, Kwok; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Hi Rick, I see your point. We can release one binary for all supported OS flavors only if it works for all of them. We can discuss more in the meeting today in this regard. Thanks, Alex -----Original Message----- From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 17, 2013 9:57 AM To: Chang, Alex; Kong, Kwok; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Hi Alex, My original thought in conditionally compiling was to preserve compatibility with the existing Win 7 WDK. Driver builds as it always has in that environment. Seems like a convenience for anyone who still wants to build using Win 7 WDK (perhaps they already have some automated builds in place or whatever, so why break it?) And, it exposes the same VPD pages as before, whereas there will be 3 new ones with Win 8 Trim support -- not saying that breaks anything in Win 7 or Win 2008 R2, but we do have proven mileage behind us with things as they are. If the goal is to have a single binary that runs across all of those OS flavors, you may want to put that validation down as a project for someone. I think Parag had tried building the driver as it exists today in the repository for Windows 8 and saw some issues when trying to install that binary under Windows 7. Perhaps if other folks have tried that, they can weigh in on this as well. Thanks, -Rick ________________________________________ From: Chang, Alex [Alex.Chang at idt.com] Sent: Monday, June 17, 2013 9:15 AM To: Kong, Kwok; Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Hi Rick, Kwok has a good point, especially that we're going to release signed binary later. Please add the changes you mentioned below and re-send your patch after running the basic tests (drive formats, SDStress, SCSICompliance and IOMeter) and TRIM specific tests. Thank you, Alex ________________________________ From: Kong, Kwok Sent: Monday, June 17, 2013 8:39 AM To: Knoblaugh, Rick; Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Rick, Is it possible to run the Windows 8 binary driver with Windows 7, Windows server 2008R2 and Windows server 2012 ? If it works, then there is no need to have conditional compile . We can require Windows 8 WDK to compile the source code such that we only need to build a single binary file for Windows 7, 8, Server 2008R2 and Server 2012. Thanks -Kwok From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Saturday, June 15, 2013 8:48 PM To: Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: Re: [nvmewin] LSI Trim Patch Hi Alex, We can make that tweak to change how it checks for Windows 8. Also, I discovered one other item that hasn't affected TRIM, but is not actually correct. In the SntiTranslateBLockLimitsPage function that implements the Block Limits VPD page, two items weren't being returned correctly. pBLPage->MaximumCompareAndWriteLength and pBLPage->MaximumTransferLength were being assigned the value of pCntrlIdData->MDTS -- and what needs to be returned there is not this field, but a calculation based on this field and PAE->pCtrlRegister->CAP.MPSMIN. And actually, we have the ability to scale that maximum transfer value back based on a registry setting, so rather than doing that calculation, what should probably be returned there is pAE->InitInfo.MaxTxSize. Another issue with what was being done is that the value for these fields within the BLock Limits VPD Page needs to be in blocks, so for both of those, we should be returning pAE->InitInfo.MaxTxSize / block size. We can put in those fixes. (Again, these weren't affecting the UNMAP stuff, but should be corrected.) Thanks, -Rick ________________________________ From: Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:48 PM To: Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: LSI Trim Patch Hi Rick, Just a quick note that you don't need to define WINDOWS_8 yourself. In a more WDK way, you may just wrap your changes with: #if (_WIN32_WINNT > _WIN32_WINNT_WIN7) #endif Then, it will be compiled without error on both Windows 8 WDK and 7600 WDK. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Friday, June 07, 2013 6:38 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** LSI Trim Patch Hi Ray, Per your request, since we will switch order, moving Intel patch to the number 3 position, I'm sending LSI's Trim patch. Password for the attached file is: lsi1234. Also, I have attached a document here that describes what was changed/added. It would be great if everyone can review and please let me know any feedback. Thanks. -Rick From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 03, 2013 5:12 PM To: Knoblaugh, Rick; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Rick, That's great news! LSI will be 3rd in line after IDT and Intel. Thanks for the contributions to TRIM. Thanks, Ray From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Ray, We also have the patch for Trim. It is ready to send. Please let me know when you would like me to send out. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:695370816 at 17062013-1A83] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin From Alex.Chang at idt.com Mon Jun 24 08:11:33 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Mon, 24 Jun 2013 15:11:33 +0000 Subject: [nvmewin] LSI Trim Patch In-Reply-To: <6B4557D9CF036C4E8F9D6C561818DABB365D6462@FMSMSX112.amr.corp.intel.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBB1FBD5@cosmail03.lsi.com> <49158E750348AA499168FD41D88983606257AEE1@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBBD3022@cosmail03.lsi.com>, <548C5470AAD9DA4A85D259B663190D361FFEEBCB@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F013819F022@cosmail03.lsi.com> <05CD7821AE397547A01AC160FBC231474BCADF06@corpmail1.na.ads.idt.com>, <548C5470AAD9DA4A85D259B663190D361FFEF6E1@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F013819F023@cosmail03.lsi.com> <548C5470AAD9DA4A85D259B663190D361FFF0735@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F0138186A1C@cosmail03.lsi.com> <548C5470AAD9DA4A85D259B663190D361FFF45C4@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D6462@FMSMSX112.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFF4677@corpmail1.na.ads.idt.com> Thanks a lot, Kris. I will do more testing today and then push the patch today after the tests. Thanks, Alex -----Original Message----- From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Monday, June 24, 2013 8:02 AM To: Chang, Alex; Knoblaugh, Rick; Kong, Kwok; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Rick, Changes look good to me. ~Kris -----Original Message----- From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, June 20, 2013 4:50 PM To: Knoblaugh, Rick; Kong, Kwok; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: Re: [nvmewin] LSI Trim Patch Thank you, Rick. I will re-run the tests and let you know later. Hi Kris, Could you please provide your feedbacks at your earliest convenience? Thanks, Alex -----Original Message----- From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Thursday, June 20, 2013 3:07 PM To: Chang, Alex; Kong, Kwok; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: LSI Trim Patch Hi Alex, I was hoping to send this earlier, but we had to deal with some logistical stuff getting into our new building. Here is the patch with the minor tweaks we discussed. Even though there is basically no change, we reran tests and such. There were only two changes: In nvmesnti.c, in the SntiTranslateBlockLimitsPage fuction, we are being consistent with what Microsoft's AHCI Storport miniport driver does and only explicitly providing values for Maximum UNMAP LBA Count and Maximum UNMAP Block Descriptor Count. Changed conditional compile for Win 8 to use #if _WIN32_WINNT > _WIN32_WINNT_WIN7. (And removed #define WINDOWS_8 from nvmestd.h.) Password is lsi1234 Thanks, -Rick -----Original Message----- From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, June 17, 2013 10:30 AM To: Knoblaugh, Rick; Kong, Kwok; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Hi Rick, I see your point. We can release one binary for all supported OS flavors only if it works for all of them. We can discuss more in the meeting today in this regard. Thanks, Alex -----Original Message----- From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 17, 2013 9:57 AM To: Chang, Alex; Kong, Kwok; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Hi Alex, My original thought in conditionally compiling was to preserve compatibility with the existing Win 7 WDK. Driver builds as it always has in that environment. Seems like a convenience for anyone who still wants to build using Win 7 WDK (perhaps they already have some automated builds in place or whatever, so why break it?) And, it exposes the same VPD pages as before, whereas there will be 3 new ones with Win 8 Trim support -- not saying that breaks anything in Win 7 or Win 2008 R2, but we do have proven mileage behind us with things as they are. If the goal is to have a single binary that runs across all of those OS flavors, you may want to put that validation down as a project for someone. I think Parag had tried building the driver as it exists today in the repository for Windows 8 and saw some issues when trying to install that binary under Windows 7. Perhaps if other folks have tried that, they can weigh in on this as well. Thanks, -Rick ________________________________________ From: Chang, Alex [Alex.Chang at idt.com] Sent: Monday, June 17, 2013 9:15 AM To: Kong, Kwok; Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Hi Rick, Kwok has a good point, especially that we're going to release signed binary later. Please add the changes you mentioned below and re-send your patch after running the basic tests (drive formats, SDStress, SCSICompliance and IOMeter) and TRIM specific tests. Thank you, Alex ________________________________ From: Kong, Kwok Sent: Monday, June 17, 2013 8:39 AM To: Knoblaugh, Rick; Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: RE: LSI Trim Patch Rick, Is it possible to run the Windows 8 binary driver with Windows 7, Windows server 2008R2 and Windows server 2012 ? If it works, then there is no need to have conditional compile . We can require Windows 8 WDK to compile the source code such that we only need to build a single binary file for Windows 7, 8, Server 2008R2 and Server 2012. Thanks -Kwok From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Saturday, June 15, 2013 8:48 PM To: Chang, Alex; Robles, Raymond C; nvmewin at lists.openfabrics.org Cc: Sheth, Parag A Subject: Re: [nvmewin] LSI Trim Patch Hi Alex, We can make that tweak to change how it checks for Windows 8. Also, I discovered one other item that hasn't affected TRIM, but is not actually correct. In the SntiTranslateBLockLimitsPage function that implements the Block Limits VPD page, two items weren't being returned correctly. pBLPage->MaximumCompareAndWriteLength and pBLPage->MaximumTransferLength were being assigned the value of pCntrlIdData->MDTS -- and what needs to be returned there is not this field, but a calculation based on this field and PAE->pCtrlRegister->CAP.MPSMIN. And actually, we have the ability to scale that maximum transfer value back based on a registry setting, so rather than doing that calculation, what should probably be returned there is pAE->InitInfo.MaxTxSize. Another issue with what was being done is that the value for these fields within the BLock Limits VPD Page needs to be in blocks, so for both of those, we should be returning pAE->InitInfo.MaxTxSize / block size. We can put in those fixes. (Again, these weren't affecting the UNMAP stuff, but should be corrected.) Thanks, -Rick ________________________________ From: Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:48 PM To: Knoblaugh, Rick; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: LSI Trim Patch Hi Rick, Just a quick note that you don't need to define WINDOWS_8 yourself. In a more WDK way, you may just wrap your changes with: #if (_WIN32_WINNT > _WIN32_WINNT_WIN7) #endif Then, it will be compiled without error on both Windows 8 WDK and 7600 WDK. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Friday, June 07, 2013 6:38 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** LSI Trim Patch Hi Ray, Per your request, since we will switch order, moving Intel patch to the number 3 position, I'm sending LSI's Trim patch. Password for the attached file is: lsi1234. Also, I have attached a document here that describes what was changed/added. It would be great if everyone can review and please let me know any feedback. Thanks. -Rick From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Monday, June 03, 2013 5:12 PM To: Knoblaugh, Rick; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Rick, That's great news! LSI will be 3rd in line after IDT and Intel. Thanks for the contributions to TRIM. Thanks, Ray From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Monday, June 03, 2013 4:57 PM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: Sandisk patch delay Hi Ray, We also have the patch for Trim. It is ready to send. Please let me know when you would like me to send out. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Monday, June 03, 2013 4:44 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Sandisk patch delay Hello, It appears the Sandisk patch for Mode Sense is taking longer than expected. In order to keep things moving along with the OFA driver, I'm going to take the Sandisk patch offline for now until they can resolve their issues. Once they have worked out the kinks, they can re-submit. In the meantime, Alex from IDT has a patch he'd like to push and I also have a patch I'd like to push. Alex, please send your patch out for code review as soon as possible and then I will send out my patch immediately after. Thanks, Ray [cid:695370816 at 17062013-1A83] Raymond C. Robles NVM Solutions Group | Internal SSD Engineering Technology & Manufacturing Group Intel Corporation Desk: 480.554.2600 Mobile: 480.399.0645 _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin From Alex.Chang at idt.com Mon Jun 24 14:26:40 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Mon, 24 Jun 2013 21:26:40 +0000 Subject: [nvmewin] NVMe Windows DB Is LOCKED - Pushing Patch From LSI - TRIM Command Support In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFF4677@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D88983606257AE07@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBB1FBD5@cosmail03.lsi.com> <49158E750348AA499168FD41D88983606257AEE1@FMSMSX105.amr.corp.intel.com> <4565AEA676113A449269C2F3A549520FDBBD3022@cosmail03.lsi.com>, <548C5470AAD9DA4A85D259B663190D361FFEEBCB@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F013819F022@cosmail03.lsi.com> <05CD7821AE397547A01AC160FBC231474BCADF06@corpmail1.na.ads.idt.com>, <548C5470AAD9DA4A85D259B663190D361FFEF6E1@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F013819F023@cosmail03.lsi.com> <548C5470AAD9DA4A85D259B663190D361FFF0735@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F0138186A1C@cosmail03.lsi.com> <548C5470AAD9DA4A85D259B663190D361FFF45C4@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D6462@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4677@corpmail1.na.ads.idt.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFF4704@corpmail1.na.ads.idt.com> Locking NVMe Windows DB. Thanks, Alex From james.p.freyensee at intel.com Tue Jun 25 17:16:54 2013 From: james.p.freyensee at intel.com (Freyensee, James P) Date: Wed, 26 Jun 2013 00:16:54 +0000 Subject: [nvmewin] Pulling a version- where to go, tag/ or trunk/? Message-ID: <2D98093777D3FD46A36253F35FE9D6936FFD899C@ORSMSX109.amr.corp.intel.com> I would like to pull a 1.0e or 1.1 version of the NVMe windows driver. Where in the source repo (I'm looking at http://www.openfabrics.org/svnrepo/nvmewin/) should I pull from? Trunk/? Or should I be using the tag IDT_NVMe_1_0_e_compliance (if I wanted a 1.0e version of the driver)? I don't see a tag that clues me in on a 1.1 version so I assume I would target Trunk/ for this version? Thanks for the help! Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kwok.Kong at idt.com Tue Jun 25 17:35:10 2013 From: Kwok.Kong at idt.com (Kong, Kwok) Date: Wed, 26 Jun 2013 00:35:10 +0000 Subject: [nvmewin] Pulling a version- where to go, tag/ or trunk/? In-Reply-To: <2D98093777D3FD46A36253F35FE9D6936FFD899C@ORSMSX109.amr.corp.intel.com> References: <2D98093777D3FD46A36253F35FE9D6936FFD899C@ORSMSX109.amr.corp.intel.com> Message-ID: <05CD7821AE397547A01AC160FBC231474BCB0D15@corpmail1.na.ads.idt.com> Jay, The latest OFA driver supports NVMe 1.00e specification. NVMe 1.1 is not supported. You can use the tag IDT_NVMe_1_0_e_compliance to pull the source code that conforms to the 1.00e NVMe specification. -Kwok From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P Sent: Tuesday, June 25, 2013 5:17 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Pulling a version- where to go, tag/ or trunk/? I would like to pull a 1.0e or 1.1 version of the NVMe windows driver. Where in the source repo (I'm looking at http://www.openfabrics.org/svnrepo/nvmewin/) should I pull from? Trunk/? Or should I be using the tag IDT_NVMe_1_0_e_compliance (if I wanted a 1.0e version of the driver)? I don't see a tag that clues me in on a 1.1 version so I assume I would target Trunk/ for this version? Thanks for the help! Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Tue Jun 25 19:02:54 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Wed, 26 Jun 2013 02:02:54 +0000 Subject: [nvmewin] NVMe Windows Repo Is UNLOCKED - Pushing TRIM Command Support Message-ID: <548C5470AAD9DA4A85D259B663190D361FFF486B@corpmail1.na.ads.idt.com> Hi all, Latest patch from LSI (TRIM command support) has been pushed to trunk. A new tag has been created as "TRIM_command_support". If anyone has any questions, please feel free to contact me. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Tue Jun 25 19:07:57 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Wed, 26 Jun 2013 02:07:57 +0000 Subject: [nvmewin] New Patch From Sandisk In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFEEBBA@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D88983606256082A@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFE961C@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062560AA2@FMSMSX105.amr.corp.intel.com> <49158E750348AA499168FD41D889836062578A2D@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEC067@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062578B98@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEE32C@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFEEB8A@corpmail1.na.ads.idt.com> , <548C5470AAD9DA4A85D259B663190D361FFEEBBA@corpmail1.na.ads.idt.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFF487D@corpmail1.na.ads.idt.com> Hi Sumant, I just pushed the patch from LSI. Please re-base your changes and send your patch out for review. Since we had tested/reviewed your patch before, I hope to push it as soon as possible. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [nvmewin-bounces at lists.openfabrics.org] on behalf of Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:26 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Thank you very much, Sumant. Regards, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 3:24 PM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hello Alex, Sure, no problem. We will wait for the patches in the pipeline to be accepted and then rebase and resubmit the patch. Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 2:14 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Currently, we are reviewing the patch from LSI, which adds supporting for TRIM command. Once Intel and IDT approve it, the patch will be added first. Then we will review your patch. However, you need to re-base to include the recent patches from IDT and LSI first and re-send your patch out. Thanks you very much and please let me know if you have questions. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 11:01 AM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Alex, Thanks for the feedback. Please find attached the patch that fixes the SCSI compliance test for MODE SENSE. Attached is also the log of a successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, June 03, 2013 2:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I retested the patch with SCSICompliance and it results a new failure: MODE SENSE (6) Comparing MODE PAGE data before and after DBD bit is set. Could you test it to see if you can replicate it? You may find more details in the attachment. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 30, 2013 3:20 PM To: Robles, Raymond C; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Ray, Please find attached the patch that has fix for the last code review comment. This is the patch set that I had sent to Alex earlier. Password : sndk1234 Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 3:10 PM To: Chang, Alex; Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thanks Alex. Sumant, please continue with your updates from the last set of code review comments and resend the patch (after running all the required unit tests of course). Once we confirm the feedback changes are in place, I’ll push the patch. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 30, 2013 3:07 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Actually I did some preliminary debugging on it and found out the crash was not introduced by your patch. When the system gets normal shutdown, NVMeNormalShutdown calls NVMeFreeBuffers to free up all queue related structures. And later, when NVMeDetectPendingCmds is called to check on the pending commands, it refers to the queue structures and causes the crash. I will include the fix in my next patch that includes changes to be compliant with 1.0e NVMe Specification. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 30, 2013 2:11 PM To: Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hello Alex, I haven’t been able to repro the BSOD issue that you saw in your setup. Would it be possible for you to send me the crashdump please ? Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 1:24 PM To: Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Importance: High Dharani/Sumant, What is the status on this patch? I’ve not seen any follow up to my last email below. Hopefully we can close this out soon as there are other patches waiting to be submitted. Thanks for your quick attention. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, May 16, 2013 3:49 PM To: Chang, Alex; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Actually, I was going to type the same thing in my email below and then got derailed with the whole #define issue (thanks for capturing this Alex). There is no DataTransferLength field in the SRB Extension structure. That is defined in the SRB by Storport. As a general courtesy to other companies who are reviewing these patches, please insure that you are compiling and re-testing your patch prior to sending out for secondary or additional code reviews. This will help save valuable time in the code review process. If you are having issues compiling, or do not see the same errors, please contact me. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 16, 2013 3:44 PM To: Robles, Raymond C; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, The only change you've made in the new patch is replacing: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); with: memset(GET_DATA_BUFFER(pSrb), 0, min(pSrbExt->DataTransferLength, allocLength)); However, it generates compiling error because DataTransferLength is not a member of NVME_SRB_EXTENSION structure. Could you please fix it? Thanks a lot for you help, Alex ________________________________ From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 16, 2013 1:37 PM To: Sumant Patro; Knoblaugh, Rick; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant/Dharani, Thanks for the updated patch. A couple of comments/questions: - For all the mode sense page translations, the new temp buffer allocated in the SRB extension is used. But for the Modes Sense 0x3C (all mode pages), the SRB data buffer is still memset to 0 at the beginning of SntiReturnAllModePages(). I’m not sure we still need to do this considering how the temp buffer is used to build the mode sense data. - If you insist on keeping that memset in there, there is a #define in for all mode pages - MODE_SENSE_ALL_PAGES_LENGTH. It may be better to zero out the buffer based on the min between this define and allocLength. SRB data transfer length cannot be relied on for “data-in” commands (like mode sense). Thanks, Ray From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 16, 2013 12:43 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Sorry, sent the wrong zip in the previous mail. Please ignore the previous attachment. Attached is the updated zip file. Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 16, 2013 12:38 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Thanks Rick, Alex for your feedback. Please find attached updated files with following two changes : 1. Comment in header of SntiCreateModeDataHeader function changed to reflect passing of srb extension 2. memset(GET_DATA_BUFFER(pSrb), 0, allocLength); modified to use minimum of allocLength and DataTransferLength in SntiReturnAllModePages(..) Password : sndk1234 Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Thursday, May 16, 2013 11:59 AM To: Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, When you change that one, may as well fix the comment in header of SntiCreateModeDataHeader function to reflect that srb extension is now the parameter that’s passed in. Other stuff looks good. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, May 16, 2013 10:58 AM To: Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, I tested your new patch and experienced a D1 bugcheck while running SCSICompliance test. Some preliminary debugging leads to Line#3633 of nvmestni.c, where it looks like: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); The bugcheck happens when the value of "allocLength" is 0x1000. Apparently, the allocated length in CDB is somewhat a bogus value that is meant to test how driver handles it. Could you please fix it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Wednesday, May 01, 2013 8:56 AM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Ray, I have incorporated the changes according to your suggestions, I tried to keep up with the coding convention please feel free to let me know if anything has to be changed. I have incorporated one more fix in the nvmeInit.c which can lead to memory corruptions and used the SrbExt for the buffer allocation. PassWd: sndk1234 Thanks, Dharani. From: Dharani Kotte Sent: Tuesday, April 30, 2013 12:03 PM To: 'Robles, Raymond C'; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thank you for the feedback, I agree that the global buffer is not good I have made the changes to allocate this buffer from the srbext I will provide the code with the below modifications soon. Thanks, Dharani. From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, April 30, 2013 11:52 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, Thank you for putting this patch together. Please see my feedback below: - Line 52: Note that we have a file called nvmeSntiTypes.h. This file contains all #defines. As per our existing convention, all #defines should be placed in this file (versus at the top of a .c file). - Line 3339/3412/3502/3593/3756/5391/5433/5442/5453: Our coding convention states no line be longer than 80 characters. These lines all exceed 80 characters. - Line 5410: SntiTranslateAllModePagesResponse() contains new if-else blocks. Our coding convention dictates that open curly braces be placed on the same line as the if or else statement. You can refer to other instances of the code and if-else clauses as examples. - Line 4017: SntiCreateModeDataHeader() no longer needs the SRB pointer to be passed in as a parameter since you are using a global temp buffer to build up the mode sense data. That parameter can be removed. - General: The method of using a global buffer for a single mode sense command opens up a potential race condition for multiple mode sense commands submitted on top of each other. The idea behind putting the SCSI to NVMe translation phase in the HwStorBuildIo phase was to help performance. We initially knew that we would never be sharing any data structures or memory in calls to BuildIo. There is no spinlock or protection for calls to BuildIo and MSDN makes it clear that these BuildIo calls are not synchronized and that any synchronization of memory/data must be done within the function implementations or just use StartIo instead (since Storport will acquire the StartIoSpinLock). So there is hole here w/r/t the global buffer being populated for multiple mode sense commands at the same time. I believe you have the right idea, but the correct solution is to create a temp mode sense buffer inside the SRB extension. This way, each command has its own temp mode sense buffer for building the mode sense response, and then when ready to copy over to the SRB data buffer, it’s pulling from a buffer that can only be accessed by the current command (instead of a global buffer that may have been overwritten by another mode sense request call from another BuildIo call). Note that the driver collaboration group made the decision to never acquire any type of lock in BuildIo. Let me know if you have questions on this solution. The additional size to the SRB extension is not an issue. This fix is critical for this patch to be accepted. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 11:14 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Attaching the code with according to Alex suggestion. Passwd: sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, April 30, 2013 9:23 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, I'd suggest that it's safer to initialize gModeSenseBuf as all zeros each time before it is used, just in case there are some unexpected data in the buffer. Other than that, I am fine with the patch. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 8:37 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] New Patch From Sandisk Hi all, It's been almost two weeks after I sent out the patch. please let us know if you're okay with it. Thanks, Dharani. From: Dharani Kotte Sent: Friday, April 12, 2013 9:58 AM To: nvmewin at lists.openfabrics.org Subject: New Patch From Sandisk Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeSnti.c a. Allocate a global buffer of 256bytes size for modesense return data preparation b. For any mode sense this buffer is used for modesense data along with the requested pages in it. c. Copy the required data according to the alloc_length requested in the cdb to the Srb->DataBuffer and update the dataTransferLength accordingly d. In function SntiTranslateReturnAllModePagesResponse() the modesense data header offset is calculated wrong which ends up in BSOD in some cases modified code to fix this issue 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, 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). CAUTION: Please confirm that the password protected .zip attachment which contains the file(s) of type source_sndk_05_16_2013.zip is legitimate prior to opening. To make sure this message is not infected with a virus, it is important to verify that you are expecting the message or else confirm its legitimacy with the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dharani.Kotte at sandisk.com Wed Jun 26 09:03:20 2013 From: Dharani.Kotte at sandisk.com (Dharani Kotte) Date: Wed, 26 Jun 2013 16:03:20 +0000 Subject: [nvmewin] New Patch From Sandisk In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFF487D@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D88983606256082A@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFE961C@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062560AA2@FMSMSX105.amr.corp.intel.com> <49158E750348AA499168FD41D889836062578A2D@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEC067@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062578B98@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEE32C@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFEEB8A@corpmail1.na.ads.idt.com> , <548C5470AAD9DA4A85D259B663190D361FFEEBBA@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFF487D@corpmail1.na.ads.idt.com> Message-ID: <23EC73C80FB59046A6B7B8EB7B382659233059DD@MILMBXIP01.sdcorp.global.sandisk.com> Hi Alex, I have just merged the code to the latest OFA driver. I want to run the SCSI compliance test on the merged code. Probably EOD or tomorrow I will send the patch. Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 25, 2013 7:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I just pushed the patch from LSI. Please re-base your changes and send your patch out for review. Since we had tested/reviewed your patch before, I hope to push it as soon as possible. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [nvmewin-bounces at lists.openfabrics.org] on behalf of Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:26 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Thank you very much, Sumant. Regards, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 3:24 PM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hello Alex, Sure, no problem. We will wait for the patches in the pipeline to be accepted and then rebase and resubmit the patch. Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 2:14 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Currently, we are reviewing the patch from LSI, which adds supporting for TRIM command. Once Intel and IDT approve it, the patch will be added first. Then we will review your patch. However, you need to re-base to include the recent patches from IDT and LSI first and re-send your patch out. Thanks you very much and please let me know if you have questions. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 11:01 AM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Alex, Thanks for the feedback. Please find attached the patch that fixes the SCSI compliance test for MODE SENSE. Attached is also the log of a successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, June 03, 2013 2:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I retested the patch with SCSICompliance and it results a new failure: MODE SENSE (6) Comparing MODE PAGE data before and after DBD bit is set. Could you test it to see if you can replicate it? You may find more details in the attachment. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 30, 2013 3:20 PM To: Robles, Raymond C; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Ray, Please find attached the patch that has fix for the last code review comment. This is the patch set that I had sent to Alex earlier. Password : sndk1234 Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 3:10 PM To: Chang, Alex; Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thanks Alex. Sumant, please continue with your updates from the last set of code review comments and resend the patch (after running all the required unit tests of course). Once we confirm the feedback changes are in place, I’ll push the patch. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 30, 2013 3:07 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Actually I did some preliminary debugging on it and found out the crash was not introduced by your patch. When the system gets normal shutdown, NVMeNormalShutdown calls NVMeFreeBuffers to free up all queue related structures. And later, when NVMeDetectPendingCmds is called to check on the pending commands, it refers to the queue structures and causes the crash. I will include the fix in my next patch that includes changes to be compliant with 1.0e NVMe Specification. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 30, 2013 2:11 PM To: Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hello Alex, I haven’t been able to repro the BSOD issue that you saw in your setup. Would it be possible for you to send me the crashdump please ? Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 1:24 PM To: Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Importance: High Dharani/Sumant, What is the status on this patch? I’ve not seen any follow up to my last email below. Hopefully we can close this out soon as there are other patches waiting to be submitted. Thanks for your quick attention. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, May 16, 2013 3:49 PM To: Chang, Alex; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Actually, I was going to type the same thing in my email below and then got derailed with the whole #define issue (thanks for capturing this Alex). There is no DataTransferLength field in the SRB Extension structure. That is defined in the SRB by Storport. As a general courtesy to other companies who are reviewing these patches, please insure that you are compiling and re-testing your patch prior to sending out for secondary or additional code reviews. This will help save valuable time in the code review process. If you are having issues compiling, or do not see the same errors, please contact me. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 16, 2013 3:44 PM To: Robles, Raymond C; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, The only change you've made in the new patch is replacing: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); with: memset(GET_DATA_BUFFER(pSrb), 0, min(pSrbExt->DataTransferLength, allocLength)); However, it generates compiling error because DataTransferLength is not a member of NVME_SRB_EXTENSION structure. Could you please fix it? Thanks a lot for you help, Alex ________________________________ From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 16, 2013 1:37 PM To: Sumant Patro; Knoblaugh, Rick; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant/Dharani, Thanks for the updated patch. A couple of comments/questions: - For all the mode sense page translations, the new temp buffer allocated in the SRB extension is used. But for the Modes Sense 0x3C (all mode pages), the SRB data buffer is still memset to 0 at the beginning of SntiReturnAllModePages(). I’m not sure we still need to do this considering how the temp buffer is used to build the mode sense data. - If you insist on keeping that memset in there, there is a #define in for all mode pages - MODE_SENSE_ALL_PAGES_LENGTH. It may be better to zero out the buffer based on the min between this define and allocLength. SRB data transfer length cannot be relied on for “data-in” commands (like mode sense). Thanks, Ray From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 16, 2013 12:43 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Sorry, sent the wrong zip in the previous mail. Please ignore the previous attachment. Attached is the updated zip file. Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 16, 2013 12:38 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Thanks Rick, Alex for your feedback. Please find attached updated files with following two changes : 1. Comment in header of SntiCreateModeDataHeader function changed to reflect passing of srb extension 2. memset(GET_DATA_BUFFER(pSrb), 0, allocLength); modified to use minimum of allocLength and DataTransferLength in SntiReturnAllModePages(..) Password : sndk1234 Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Thursday, May 16, 2013 11:59 AM To: Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, When you change that one, may as well fix the comment in header of SntiCreateModeDataHeader function to reflect that srb extension is now the parameter that’s passed in. Other stuff looks good. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, May 16, 2013 10:58 AM To: Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, I tested your new patch and experienced a D1 bugcheck while running SCSICompliance test. Some preliminary debugging leads to Line#3633 of nvmestni.c, where it looks like: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); The bugcheck happens when the value of "allocLength" is 0x1000. Apparently, the allocated length in CDB is somewhat a bogus value that is meant to test how driver handles it. Could you please fix it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Wednesday, May 01, 2013 8:56 AM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Ray, I have incorporated the changes according to your suggestions, I tried to keep up with the coding convention please feel free to let me know if anything has to be changed. I have incorporated one more fix in the nvmeInit.c which can lead to memory corruptions and used the SrbExt for the buffer allocation. PassWd: sndk1234 Thanks, Dharani. From: Dharani Kotte Sent: Tuesday, April 30, 2013 12:03 PM To: 'Robles, Raymond C'; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thank you for the feedback, I agree that the global buffer is not good I have made the changes to allocate this buffer from the srbext I will provide the code with the below modifications soon. Thanks, Dharani. From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, April 30, 2013 11:52 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, Thank you for putting this patch together. Please see my feedback below: - Line 52: Note that we have a file called nvmeSntiTypes.h. This file contains all #defines. As per our existing convention, all #defines should be placed in this file (versus at the top of a .c file). - Line 3339/3412/3502/3593/3756/5391/5433/5442/5453: Our coding convention states no line be longer than 80 characters. These lines all exceed 80 characters. - Line 5410: SntiTranslateAllModePagesResponse() contains new if-else blocks. Our coding convention dictates that open curly braces be placed on the same line as the if or else statement. You can refer to other instances of the code and if-else clauses as examples. - Line 4017: SntiCreateModeDataHeader() no longer needs the SRB pointer to be passed in as a parameter since you are using a global temp buffer to build up the mode sense data. That parameter can be removed. - General: The method of using a global buffer for a single mode sense command opens up a potential race condition for multiple mode sense commands submitted on top of each other. The idea behind putting the SCSI to NVMe translation phase in the HwStorBuildIo phase was to help performance. We initially knew that we would never be sharing any data structures or memory in calls to BuildIo. There is no spinlock or protection for calls to BuildIo and MSDN makes it clear that these BuildIo calls are not synchronized and that any synchronization of memory/data must be done within the function implementations or just use StartIo instead (since Storport will acquire the StartIoSpinLock). So there is hole here w/r/t the global buffer being populated for multiple mode sense commands at the same time. I believe you have the right idea, but the correct solution is to create a temp mode sense buffer inside the SRB extension. This way, each command has its own temp mode sense buffer for building the mode sense response, and then when ready to copy over to the SRB data buffer, it’s pulling from a buffer that can only be accessed by the current command (instead of a global buffer that may have been overwritten by another mode sense request call from another BuildIo call). Note that the driver collaboration group made the decision to never acquire any type of lock in BuildIo. Let me know if you have questions on this solution. The additional size to the SRB extension is not an issue. This fix is critical for this patch to be accepted. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 11:14 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Attaching the code with according to Alex suggestion. Passwd: sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, April 30, 2013 9:23 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, I'd suggest that it's safer to initialize gModeSenseBuf as all zeros each time before it is used, just in case there are some unexpected data in the buffer. Other than that, I am fine with the patch. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 8:37 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] New Patch From Sandisk Hi all, It's been almost two weeks after I sent out the patch. please let us know if you're okay with it. Thanks, Dharani. From: Dharani Kotte Sent: Friday, April 12, 2013 9:58 AM To: nvmewin at lists.openfabrics.org Subject: New Patch From Sandisk Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeSnti.c a. Allocate a global buffer of 256bytes size for modesense return data preparation b. For any mode sense this buffer is used for modesense data along with the requested pages in it. c. Copy the required data according to the alloc_length requested in the cdb to the Srb->DataBuffer and update the dataTransferLength accordingly d. In function SntiTranslateReturnAllModePagesResponse() the modesense data header offset is calculated wrong which ends up in BSOD in some cases modified code to fix this issue 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, 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). CAUTION: Please confirm that the password protected .zip attachment which contains the file(s) of type source_sndk_05_16_2013.zip is legitimate prior to opening. To make sure this message is not infected with a virus, it is important to verify that you are expecting the message or else confirm its legitimacy with the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Wed Jun 26 09:08:46 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Wed, 26 Jun 2013 16:08:46 +0000 Subject: [nvmewin] New Patch From Sandisk In-Reply-To: <23EC73C80FB59046A6B7B8EB7B382659233059DD@MILMBXIP01.sdcorp.global.sandisk.com> References: <49158E750348AA499168FD41D88983606256082A@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFE961C@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062560AA2@FMSMSX105.amr.corp.intel.com> <49158E750348AA499168FD41D889836062578A2D@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEC067@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062578B98@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEE32C@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFEEB8A@corpmail1.na.ads.idt.com> , <548C5470AAD9DA4A85D259B663190D361FFEEBBA@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFF487D@corpmail1.na.ads.idt.com> <23EC73C80FB59046A6B7B8EB7B382659233059DD@MILMBXIP01.sdcorp.global.sandisk.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFF489C@corpmail1.na.ads.idt.com> That'd be great! Thanks, Alex ________________________________ From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com] Sent: Wednesday, June 26, 2013 9:03 AM To: Chang, Alex; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Alex, I have just merged the code to the latest OFA driver. I want to run the SCSI compliance test on the merged code. Probably EOD or tomorrow I will send the patch. Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 25, 2013 7:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I just pushed the patch from LSI. Please re-base your changes and send your patch out for review. Since we had tested/reviewed your patch before, I hope to push it as soon as possible. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [nvmewin-bounces at lists.openfabrics.org] on behalf of Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:26 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Thank you very much, Sumant. Regards, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 3:24 PM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hello Alex, Sure, no problem. We will wait for the patches in the pipeline to be accepted and then rebase and resubmit the patch. Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 2:14 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Currently, we are reviewing the patch from LSI, which adds supporting for TRIM command. Once Intel and IDT approve it, the patch will be added first. Then we will review your patch. However, you need to re-base to include the recent patches from IDT and LSI first and re-send your patch out. Thanks you very much and please let me know if you have questions. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 11:01 AM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Alex, Thanks for the feedback. Please find attached the patch that fixes the SCSI compliance test for MODE SENSE. Attached is also the log of a successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, June 03, 2013 2:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I retested the patch with SCSICompliance and it results a new failure: MODE SENSE (6) Comparing MODE PAGE data before and after DBD bit is set. Could you test it to see if you can replicate it? You may find more details in the attachment. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 30, 2013 3:20 PM To: Robles, Raymond C; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Ray, Please find attached the patch that has fix for the last code review comment. This is the patch set that I had sent to Alex earlier. Password : sndk1234 Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 3:10 PM To: Chang, Alex; Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thanks Alex. Sumant, please continue with your updates from the last set of code review comments and resend the patch (after running all the required unit tests of course). Once we confirm the feedback changes are in place, I’ll push the patch. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 30, 2013 3:07 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Actually I did some preliminary debugging on it and found out the crash was not introduced by your patch. When the system gets normal shutdown, NVMeNormalShutdown calls NVMeFreeBuffers to free up all queue related structures. And later, when NVMeDetectPendingCmds is called to check on the pending commands, it refers to the queue structures and causes the crash. I will include the fix in my next patch that includes changes to be compliant with 1.0e NVMe Specification. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 30, 2013 2:11 PM To: Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hello Alex, I haven’t been able to repro the BSOD issue that you saw in your setup. Would it be possible for you to send me the crashdump please ? Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 1:24 PM To: Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Importance: High Dharani/Sumant, What is the status on this patch? I’ve not seen any follow up to my last email below. Hopefully we can close this out soon as there are other patches waiting to be submitted. Thanks for your quick attention. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, May 16, 2013 3:49 PM To: Chang, Alex; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Actually, I was going to type the same thing in my email below and then got derailed with the whole #define issue (thanks for capturing this Alex). There is no DataTransferLength field in the SRB Extension structure. That is defined in the SRB by Storport. As a general courtesy to other companies who are reviewing these patches, please insure that you are compiling and re-testing your patch prior to sending out for secondary or additional code reviews. This will help save valuable time in the code review process. If you are having issues compiling, or do not see the same errors, please contact me. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 16, 2013 3:44 PM To: Robles, Raymond C; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, The only change you've made in the new patch is replacing: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); with: memset(GET_DATA_BUFFER(pSrb), 0, min(pSrbExt->DataTransferLength, allocLength)); However, it generates compiling error because DataTransferLength is not a member of NVME_SRB_EXTENSION structure. Could you please fix it? Thanks a lot for you help, Alex ________________________________ From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 16, 2013 1:37 PM To: Sumant Patro; Knoblaugh, Rick; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant/Dharani, Thanks for the updated patch. A couple of comments/questions: - For all the mode sense page translations, the new temp buffer allocated in the SRB extension is used. But for the Modes Sense 0x3C (all mode pages), the SRB data buffer is still memset to 0 at the beginning of SntiReturnAllModePages(). I’m not sure we still need to do this considering how the temp buffer is used to build the mode sense data. - If you insist on keeping that memset in there, there is a #define in for all mode pages - MODE_SENSE_ALL_PAGES_LENGTH. It may be better to zero out the buffer based on the min between this define and allocLength. SRB data transfer length cannot be relied on for “data-in” commands (like mode sense). Thanks, Ray From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 16, 2013 12:43 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Sorry, sent the wrong zip in the previous mail. Please ignore the previous attachment. Attached is the updated zip file. Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 16, 2013 12:38 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Thanks Rick, Alex for your feedback. Please find attached updated files with following two changes : 1. Comment in header of SntiCreateModeDataHeader function changed to reflect passing of srb extension 2. memset(GET_DATA_BUFFER(pSrb), 0, allocLength); modified to use minimum of allocLength and DataTransferLength in SntiReturnAllModePages(..) Password : sndk1234 Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Thursday, May 16, 2013 11:59 AM To: Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, When you change that one, may as well fix the comment in header of SntiCreateModeDataHeader function to reflect that srb extension is now the parameter that’s passed in. Other stuff looks good. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, May 16, 2013 10:58 AM To: Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, I tested your new patch and experienced a D1 bugcheck while running SCSICompliance test. Some preliminary debugging leads to Line#3633 of nvmestni.c, where it looks like: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); The bugcheck happens when the value of "allocLength" is 0x1000. Apparently, the allocated length in CDB is somewhat a bogus value that is meant to test how driver handles it. Could you please fix it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Wednesday, May 01, 2013 8:56 AM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Ray, I have incorporated the changes according to your suggestions, I tried to keep up with the coding convention please feel free to let me know if anything has to be changed. I have incorporated one more fix in the nvmeInit.c which can lead to memory corruptions and used the SrbExt for the buffer allocation. PassWd: sndk1234 Thanks, Dharani. From: Dharani Kotte Sent: Tuesday, April 30, 2013 12:03 PM To: 'Robles, Raymond C'; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thank you for the feedback, I agree that the global buffer is not good I have made the changes to allocate this buffer from the srbext I will provide the code with the below modifications soon. Thanks, Dharani. From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, April 30, 2013 11:52 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, Thank you for putting this patch together. Please see my feedback below: - Line 52: Note that we have a file called nvmeSntiTypes.h. This file contains all #defines. As per our existing convention, all #defines should be placed in this file (versus at the top of a .c file). - Line 3339/3412/3502/3593/3756/5391/5433/5442/5453: Our coding convention states no line be longer than 80 characters. These lines all exceed 80 characters. - Line 5410: SntiTranslateAllModePagesResponse() contains new if-else blocks. Our coding convention dictates that open curly braces be placed on the same line as the if or else statement. You can refer to other instances of the code and if-else clauses as examples. - Line 4017: SntiCreateModeDataHeader() no longer needs the SRB pointer to be passed in as a parameter since you are using a global temp buffer to build up the mode sense data. That parameter can be removed. - General: The method of using a global buffer for a single mode sense command opens up a potential race condition for multiple mode sense commands submitted on top of each other. The idea behind putting the SCSI to NVMe translation phase in the HwStorBuildIo phase was to help performance. We initially knew that we would never be sharing any data structures or memory in calls to BuildIo. There is no spinlock or protection for calls to BuildIo and MSDN makes it clear that these BuildIo calls are not synchronized and that any synchronization of memory/data must be done within the function implementations or just use StartIo instead (since Storport will acquire the StartIoSpinLock). So there is hole here w/r/t the global buffer being populated for multiple mode sense commands at the same time. I believe you have the right idea, but the correct solution is to create a temp mode sense buffer inside the SRB extension. This way, each command has its own temp mode sense buffer for building the mode sense response, and then when ready to copy over to the SRB data buffer, it’s pulling from a buffer that can only be accessed by the current command (instead of a global buffer that may have been overwritten by another mode sense request call from another BuildIo call). Note that the driver collaboration group made the decision to never acquire any type of lock in BuildIo. Let me know if you have questions on this solution. The additional size to the SRB extension is not an issue. This fix is critical for this patch to be accepted. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 11:14 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Attaching the code with according to Alex suggestion. Passwd: sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, April 30, 2013 9:23 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, I'd suggest that it's safer to initialize gModeSenseBuf as all zeros each time before it is used, just in case there are some unexpected data in the buffer. Other than that, I am fine with the patch. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 8:37 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] New Patch From Sandisk Hi all, It's been almost two weeks after I sent out the patch. please let us know if you're okay with it. Thanks, Dharani. From: Dharani Kotte Sent: Friday, April 12, 2013 9:58 AM To: nvmewin at lists.openfabrics.org Subject: New Patch From Sandisk Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeSnti.c a. Allocate a global buffer of 256bytes size for modesense return data preparation b. For any mode sense this buffer is used for modesense data along with the requested pages in it. c. Copy the required data according to the alloc_length requested in the cdb to the Srb->DataBuffer and update the dataTransferLength accordingly d. In function SntiTranslateReturnAllModePagesResponse() the modesense data header offset is calculated wrong which ends up in BSOD in some cases modified code to fix this issue 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, 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). CAUTION: Please confirm that the password protected .zip attachment which contains the file(s) of type source_sndk_05_16_2013.zip is legitimate prior to opening. To make sure this message is not infected with a virus, it is important to verify that you are expecting the message or else confirm its legitimacy with the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dharani.Kotte at sandisk.com Wed Jun 26 10:59:43 2013 From: Dharani.Kotte at sandisk.com (Dharani Kotte) Date: Wed, 26 Jun 2013 17:59:43 +0000 Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFF489C@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D88983606256082A@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFE961C@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062560AA2@FMSMSX105.amr.corp.intel.com> <49158E750348AA499168FD41D889836062578A2D@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEC067@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062578B98@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEE32C@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFEEB8A@corpmail1.na.ads.idt.com> , <548C5470AAD9DA4A85D259B663190D361FFEEBBA@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFF487D@corpmail1.na.ads.idt.com> <23EC73C80FB59046A6B7B8EB7B382659233059DD@MILMBXIP01.sdcorp.global.sandisk.com> <548C5470AAD9DA4A85D259B663190D361FFF489C@corpmail1.na.ads.idt.com> Message-ID: <23EC73C80FB59046A6B7B8EB7B38265923305A78@MILMBXIP01.sdcorp.global.sandisk.com> Hi Alex, Please find attached the patch that fixes the SCSI compliance test for MODE SENSE merged with the latest LSI TRIM command support . Attached is also the log of a scsicompliance successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Wednesday, June 26, 2013 9:09 AM To: Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk That'd be great! Thanks, Alex ________________________________ From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com] Sent: Wednesday, June 26, 2013 9:03 AM To: Chang, Alex; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Alex, I have just merged the code to the latest OFA driver. I want to run the SCSI compliance test on the merged code. Probably EOD or tomorrow I will send the patch. Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 25, 2013 7:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I just pushed the patch from LSI. Please re-base your changes and send your patch out for review. Since we had tested/reviewed your patch before, I hope to push it as soon as possible. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [nvmewin-bounces at lists.openfabrics.org] on behalf of Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:26 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Thank you very much, Sumant. Regards, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 3:24 PM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hello Alex, Sure, no problem. We will wait for the patches in the pipeline to be accepted and then rebase and resubmit the patch. Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 2:14 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Currently, we are reviewing the patch from LSI, which adds supporting for TRIM command. Once Intel and IDT approve it, the patch will be added first. Then we will review your patch. However, you need to re-base to include the recent patches from IDT and LSI first and re-send your patch out. Thanks you very much and please let me know if you have questions. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 11:01 AM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Alex, Thanks for the feedback. Please find attached the patch that fixes the SCSI compliance test for MODE SENSE. Attached is also the log of a successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, June 03, 2013 2:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I retested the patch with SCSICompliance and it results a new failure: MODE SENSE (6) Comparing MODE PAGE data before and after DBD bit is set. Could you test it to see if you can replicate it? You may find more details in the attachment. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 30, 2013 3:20 PM To: Robles, Raymond C; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Ray, Please find attached the patch that has fix for the last code review comment. This is the patch set that I had sent to Alex earlier. Password : sndk1234 Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 3:10 PM To: Chang, Alex; Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thanks Alex. Sumant, please continue with your updates from the last set of code review comments and resend the patch (after running all the required unit tests of course). Once we confirm the feedback changes are in place, I’ll push the patch. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 30, 2013 3:07 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Actually I did some preliminary debugging on it and found out the crash was not introduced by your patch. When the system gets normal shutdown, NVMeNormalShutdown calls NVMeFreeBuffers to free up all queue related structures. And later, when NVMeDetectPendingCmds is called to check on the pending commands, it refers to the queue structures and causes the crash. I will include the fix in my next patch that includes changes to be compliant with 1.0e NVMe Specification. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 30, 2013 2:11 PM To: Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hello Alex, I haven’t been able to repro the BSOD issue that you saw in your setup. Would it be possible for you to send me the crashdump please ? Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 1:24 PM To: Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Importance: High Dharani/Sumant, What is the status on this patch? I’ve not seen any follow up to my last email below. Hopefully we can close this out soon as there are other patches waiting to be submitted. Thanks for your quick attention. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, May 16, 2013 3:49 PM To: Chang, Alex; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Actually, I was going to type the same thing in my email below and then got derailed with the whole #define issue (thanks for capturing this Alex). There is no DataTransferLength field in the SRB Extension structure. That is defined in the SRB by Storport. As a general courtesy to other companies who are reviewing these patches, please insure that you are compiling and re-testing your patch prior to sending out for secondary or additional code reviews. This will help save valuable time in the code review process. If you are having issues compiling, or do not see the same errors, please contact me. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 16, 2013 3:44 PM To: Robles, Raymond C; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, The only change you've made in the new patch is replacing: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); with: memset(GET_DATA_BUFFER(pSrb), 0, min(pSrbExt->DataTransferLength, allocLength)); However, it generates compiling error because DataTransferLength is not a member of NVME_SRB_EXTENSION structure. Could you please fix it? Thanks a lot for you help, Alex ________________________________ From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 16, 2013 1:37 PM To: Sumant Patro; Knoblaugh, Rick; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant/Dharani, Thanks for the updated patch. A couple of comments/questions: - For all the mode sense page translations, the new temp buffer allocated in the SRB extension is used. But for the Modes Sense 0x3C (all mode pages), the SRB data buffer is still memset to 0 at the beginning of SntiReturnAllModePages(). I’m not sure we still need to do this considering how the temp buffer is used to build the mode sense data. - If you insist on keeping that memset in there, there is a #define in for all mode pages - MODE_SENSE_ALL_PAGES_LENGTH. It may be better to zero out the buffer based on the min between this define and allocLength. SRB data transfer length cannot be relied on for “data-in” commands (like mode sense). Thanks, Ray From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 16, 2013 12:43 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Sorry, sent the wrong zip in the previous mail. Please ignore the previous attachment. Attached is the updated zip file. Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 16, 2013 12:38 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Thanks Rick, Alex for your feedback. Please find attached updated files with following two changes : 1. Comment in header of SntiCreateModeDataHeader function changed to reflect passing of srb extension 2. memset(GET_DATA_BUFFER(pSrb), 0, allocLength); modified to use minimum of allocLength and DataTransferLength in SntiReturnAllModePages(..) Password : sndk1234 Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Thursday, May 16, 2013 11:59 AM To: Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, When you change that one, may as well fix the comment in header of SntiCreateModeDataHeader function to reflect that srb extension is now the parameter that’s passed in. Other stuff looks good. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, May 16, 2013 10:58 AM To: Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, I tested your new patch and experienced a D1 bugcheck while running SCSICompliance test. Some preliminary debugging leads to Line#3633 of nvmestni.c, where it looks like: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); The bugcheck happens when the value of "allocLength" is 0x1000. Apparently, the allocated length in CDB is somewhat a bogus value that is meant to test how driver handles it. Could you please fix it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Wednesday, May 01, 2013 8:56 AM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Ray, I have incorporated the changes according to your suggestions, I tried to keep up with the coding convention please feel free to let me know if anything has to be changed. I have incorporated one more fix in the nvmeInit.c which can lead to memory corruptions and used the SrbExt for the buffer allocation. PassWd: sndk1234 Thanks, Dharani. From: Dharani Kotte Sent: Tuesday, April 30, 2013 12:03 PM To: 'Robles, Raymond C'; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thank you for the feedback, I agree that the global buffer is not good I have made the changes to allocate this buffer from the srbext I will provide the code with the below modifications soon. Thanks, Dharani. From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, April 30, 2013 11:52 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, Thank you for putting this patch together. Please see my feedback below: - Line 52: Note that we have a file called nvmeSntiTypes.h. This file contains all #defines. As per our existing convention, all #defines should be placed in this file (versus at the top of a .c file). - Line 3339/3412/3502/3593/3756/5391/5433/5442/5453: Our coding convention states no line be longer than 80 characters. These lines all exceed 80 characters. - Line 5410: SntiTranslateAllModePagesResponse() contains new if-else blocks. Our coding convention dictates that open curly braces be placed on the same line as the if or else statement. You can refer to other instances of the code and if-else clauses as examples. - Line 4017: SntiCreateModeDataHeader() no longer needs the SRB pointer to be passed in as a parameter since you are using a global temp buffer to build up the mode sense data. That parameter can be removed. - General: The method of using a global buffer for a single mode sense command opens up a potential race condition for multiple mode sense commands submitted on top of each other. The idea behind putting the SCSI to NVMe translation phase in the HwStorBuildIo phase was to help performance. We initially knew that we would never be sharing any data structures or memory in calls to BuildIo. There is no spinlock or protection for calls to BuildIo and MSDN makes it clear that these BuildIo calls are not synchronized and that any synchronization of memory/data must be done within the function implementations or just use StartIo instead (since Storport will acquire the StartIoSpinLock). So there is hole here w/r/t the global buffer being populated for multiple mode sense commands at the same time. I believe you have the right idea, but the correct solution is to create a temp mode sense buffer inside the SRB extension. This way, each command has its own temp mode sense buffer for building the mode sense response, and then when ready to copy over to the SRB data buffer, it’s pulling from a buffer that can only be accessed by the current command (instead of a global buffer that may have been overwritten by another mode sense request call from another BuildIo call). Note that the driver collaboration group made the decision to never acquire any type of lock in BuildIo. Let me know if you have questions on this solution. The additional size to the SRB extension is not an issue. This fix is critical for this patch to be accepted. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 11:14 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Attaching the code with according to Alex suggestion. Passwd: sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, April 30, 2013 9:23 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, I'd suggest that it's safer to initialize gModeSenseBuf as all zeros each time before it is used, just in case there are some unexpected data in the buffer. Other than that, I am fine with the patch. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 8:37 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] New Patch From Sandisk Hi all, It's been almost two weeks after I sent out the patch. please let us know if you're okay with it. Thanks, Dharani. From: Dharani Kotte Sent: Friday, April 12, 2013 9:58 AM To: nvmewin at lists.openfabrics.org Subject: New Patch From Sandisk Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeSnti.c a. Allocate a global buffer of 256bytes size for modesense return data preparation b. For any mode sense this buffer is used for modesense data along with the requested pages in it. c. Copy the required data according to the alloc_length requested in the cdb to the Srb->DataBuffer and update the dataTransferLength accordingly d. In function SntiTranslateReturnAllModePagesResponse() the modesense data header offset is calculated wrong which ends up in BSOD in some cases modified code to fix this issue 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, 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). CAUTION: Please confirm that the password protected .zip attachment which contains the file(s) of type source_sndk_05_16_2013.zip is legitimate prior to opening. To make sure this message is not infected with a virus, it is important to verify that you are expecting the message or else confirm its legitimacy with the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: source_sndk_06_26_2013.zip Type: application/x-zip-compressed Size: 173254 bytes Desc: source_sndk_06_26_2013.zip URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: scsicompliancesndk_06_26_2013l.txt URL: From Alex.Chang at idt.com Wed Jun 26 13:24:21 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Wed, 26 Jun 2013 20:24:21 +0000 Subject: [nvmewin] New Patch From Sandisk In-Reply-To: <23EC73C80FB59046A6B7B8EB7B38265923305A78@MILMBXIP01.sdcorp.global.sandisk.com> References: <49158E750348AA499168FD41D88983606256082A@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFE961C@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062560AA2@FMSMSX105.amr.corp.intel.com> <49158E750348AA499168FD41D889836062578A2D@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEC067@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062578B98@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEE32C@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFEEB8A@corpmail1.na.ads.idt.com> , <548C5470AAD9DA4A85D259B663190D361FFEEBBA@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFF487D@corpmail1.na.ads.idt.com> <23EC73C80FB59046A6B7B8EB7B382659233059DD@MILMBXIP01.sdcorp.global.sandisk.com> <548C5470AAD9DA4A85D259B663190D361FFF489C@corpmail1.na.ads.idt.com> <23EC73C80FB59046A6B7B8EB7B38265923305A78@MILMBXIP01.sdcorp.global.sandisk.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFF48E4@corpmail1.na.ads.idt.com> Hi all, Please review the patch and provide your feedbacks if you have any. Meanwhile, I'd like to receive the approvals from Intel and LSI at your earliest convenience when you're fine with the patch. Thanks, Alex ________________________________ From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com] Sent: Wednesday, June 26, 2013 11:00 AM To: Chang, Alex; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Alex, Please find attached the patch that fixes the SCSI compliance test for MODE SENSE merged with the latest LSI TRIM command support . Attached is also the log of a scsicompliance successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Wednesday, June 26, 2013 9:09 AM To: Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk That'd be great! Thanks, Alex ________________________________ From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com] Sent: Wednesday, June 26, 2013 9:03 AM To: Chang, Alex; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Alex, I have just merged the code to the latest OFA driver. I want to run the SCSI compliance test on the merged code. Probably EOD or tomorrow I will send the patch. Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 25, 2013 7:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I just pushed the patch from LSI. Please re-base your changes and send your patch out for review. Since we had tested/reviewed your patch before, I hope to push it as soon as possible. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [nvmewin-bounces at lists.openfabrics.org] on behalf of Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:26 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Thank you very much, Sumant. Regards, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 3:24 PM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hello Alex, Sure, no problem. We will wait for the patches in the pipeline to be accepted and then rebase and resubmit the patch. Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 2:14 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Currently, we are reviewing the patch from LSI, which adds supporting for TRIM command. Once Intel and IDT approve it, the patch will be added first. Then we will review your patch. However, you need to re-base to include the recent patches from IDT and LSI first and re-send your patch out. Thanks you very much and please let me know if you have questions. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 11:01 AM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Alex, Thanks for the feedback. Please find attached the patch that fixes the SCSI compliance test for MODE SENSE. Attached is also the log of a successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, June 03, 2013 2:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I retested the patch with SCSICompliance and it results a new failure: MODE SENSE (6) Comparing MODE PAGE data before and after DBD bit is set. Could you test it to see if you can replicate it? You may find more details in the attachment. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 30, 2013 3:20 PM To: Robles, Raymond C; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Ray, Please find attached the patch that has fix for the last code review comment. This is the patch set that I had sent to Alex earlier. Password : sndk1234 Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 3:10 PM To: Chang, Alex; Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thanks Alex. Sumant, please continue with your updates from the last set of code review comments and resend the patch (after running all the required unit tests of course). Once we confirm the feedback changes are in place, I’ll push the patch. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 30, 2013 3:07 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Actually I did some preliminary debugging on it and found out the crash was not introduced by your patch. When the system gets normal shutdown, NVMeNormalShutdown calls NVMeFreeBuffers to free up all queue related structures. And later, when NVMeDetectPendingCmds is called to check on the pending commands, it refers to the queue structures and causes the crash. I will include the fix in my next patch that includes changes to be compliant with 1.0e NVMe Specification. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 30, 2013 2:11 PM To: Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hello Alex, I haven’t been able to repro the BSOD issue that you saw in your setup. Would it be possible for you to send me the crashdump please ? Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 1:24 PM To: Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Importance: High Dharani/Sumant, What is the status on this patch? I’ve not seen any follow up to my last email below. Hopefully we can close this out soon as there are other patches waiting to be submitted. Thanks for your quick attention. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, May 16, 2013 3:49 PM To: Chang, Alex; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Actually, I was going to type the same thing in my email below and then got derailed with the whole #define issue (thanks for capturing this Alex). There is no DataTransferLength field in the SRB Extension structure. That is defined in the SRB by Storport. As a general courtesy to other companies who are reviewing these patches, please insure that you are compiling and re-testing your patch prior to sending out for secondary or additional code reviews. This will help save valuable time in the code review process. If you are having issues compiling, or do not see the same errors, please contact me. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 16, 2013 3:44 PM To: Robles, Raymond C; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, The only change you've made in the new patch is replacing: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); with: memset(GET_DATA_BUFFER(pSrb), 0, min(pSrbExt->DataTransferLength, allocLength)); However, it generates compiling error because DataTransferLength is not a member of NVME_SRB_EXTENSION structure. Could you please fix it? Thanks a lot for you help, Alex ________________________________ From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 16, 2013 1:37 PM To: Sumant Patro; Knoblaugh, Rick; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant/Dharani, Thanks for the updated patch. A couple of comments/questions: - For all the mode sense page translations, the new temp buffer allocated in the SRB extension is used. But for the Modes Sense 0x3C (all mode pages), the SRB data buffer is still memset to 0 at the beginning of SntiReturnAllModePages(). I’m not sure we still need to do this considering how the temp buffer is used to build the mode sense data. - If you insist on keeping that memset in there, there is a #define in for all mode pages - MODE_SENSE_ALL_PAGES_LENGTH. It may be better to zero out the buffer based on the min between this define and allocLength. SRB data transfer length cannot be relied on for “data-in” commands (like mode sense). Thanks, Ray From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 16, 2013 12:43 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Sorry, sent the wrong zip in the previous mail. Please ignore the previous attachment. Attached is the updated zip file. Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 16, 2013 12:38 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Thanks Rick, Alex for your feedback. Please find attached updated files with following two changes : 1. Comment in header of SntiCreateModeDataHeader function changed to reflect passing of srb extension 2. memset(GET_DATA_BUFFER(pSrb), 0, allocLength); modified to use minimum of allocLength and DataTransferLength in SntiReturnAllModePages(..) Password : sndk1234 Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Thursday, May 16, 2013 11:59 AM To: Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, When you change that one, may as well fix the comment in header of SntiCreateModeDataHeader function to reflect that srb extension is now the parameter that’s passed in. Other stuff looks good. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, May 16, 2013 10:58 AM To: Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, I tested your new patch and experienced a D1 bugcheck while running SCSICompliance test. Some preliminary debugging leads to Line#3633 of nvmestni.c, where it looks like: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); The bugcheck happens when the value of "allocLength" is 0x1000. Apparently, the allocated length in CDB is somewhat a bogus value that is meant to test how driver handles it. Could you please fix it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Wednesday, May 01, 2013 8:56 AM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Ray, I have incorporated the changes according to your suggestions, I tried to keep up with the coding convention please feel free to let me know if anything has to be changed. I have incorporated one more fix in the nvmeInit.c which can lead to memory corruptions and used the SrbExt for the buffer allocation. PassWd: sndk1234 Thanks, Dharani. From: Dharani Kotte Sent: Tuesday, April 30, 2013 12:03 PM To: 'Robles, Raymond C'; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thank you for the feedback, I agree that the global buffer is not good I have made the changes to allocate this buffer from the srbext I will provide the code with the below modifications soon. Thanks, Dharani. From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, April 30, 2013 11:52 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, Thank you for putting this patch together. Please see my feedback below: - Line 52: Note that we have a file called nvmeSntiTypes.h. This file contains all #defines. As per our existing convention, all #defines should be placed in this file (versus at the top of a .c file). - Line 3339/3412/3502/3593/3756/5391/5433/5442/5453: Our coding convention states no line be longer than 80 characters. These lines all exceed 80 characters. - Line 5410: SntiTranslateAllModePagesResponse() contains new if-else blocks. Our coding convention dictates that open curly braces be placed on the same line as the if or else statement. You can refer to other instances of the code and if-else clauses as examples. - Line 4017: SntiCreateModeDataHeader() no longer needs the SRB pointer to be passed in as a parameter since you are using a global temp buffer to build up the mode sense data. That parameter can be removed. - General: The method of using a global buffer for a single mode sense command opens up a potential race condition for multiple mode sense commands submitted on top of each other. The idea behind putting the SCSI to NVMe translation phase in the HwStorBuildIo phase was to help performance. We initially knew that we would never be sharing any data structures or memory in calls to BuildIo. There is no spinlock or protection for calls to BuildIo and MSDN makes it clear that these BuildIo calls are not synchronized and that any synchronization of memory/data must be done within the function implementations or just use StartIo instead (since Storport will acquire the StartIoSpinLock). So there is hole here w/r/t the global buffer being populated for multiple mode sense commands at the same time. I believe you have the right idea, but the correct solution is to create a temp mode sense buffer inside the SRB extension. This way, each command has its own temp mode sense buffer for building the mode sense response, and then when ready to copy over to the SRB data buffer, it’s pulling from a buffer that can only be accessed by the current command (instead of a global buffer that may have been overwritten by another mode sense request call from another BuildIo call). Note that the driver collaboration group made the decision to never acquire any type of lock in BuildIo. Let me know if you have questions on this solution. The additional size to the SRB extension is not an issue. This fix is critical for this patch to be accepted. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 11:14 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Attaching the code with according to Alex suggestion. Passwd: sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, April 30, 2013 9:23 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, I'd suggest that it's safer to initialize gModeSenseBuf as all zeros each time before it is used, just in case there are some unexpected data in the buffer. Other than that, I am fine with the patch. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 8:37 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] New Patch From Sandisk Hi all, It's been almost two weeks after I sent out the patch. please let us know if you're okay with it. Thanks, Dharani. From: Dharani Kotte Sent: Friday, April 12, 2013 9:58 AM To: nvmewin at lists.openfabrics.org Subject: New Patch From Sandisk Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeSnti.c a. Allocate a global buffer of 256bytes size for modesense return data preparation b. For any mode sense this buffer is used for modesense data along with the requested pages in it. c. Copy the required data according to the alloc_length requested in the cdb to the Srb->DataBuffer and update the dataTransferLength accordingly d. In function SntiTranslateReturnAllModePagesResponse() the modesense data header offset is calculated wrong which ends up in BSOD in some cases modified code to fix this issue 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, 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). CAUTION: Please confirm that the password protected .zip attachment which contains the file(s) of type source_sndk_05_16_2013.zip is legitimate prior to opening. To make sure this message is not infected with a virus, it is important to verify that you are expecting the message or else confirm its legitimacy with the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rick.Knoblaugh at lsi.com Wed Jun 26 16:10:59 2013 From: Rick.Knoblaugh at lsi.com (Knoblaugh, Rick) Date: Wed, 26 Jun 2013 17:10:59 -0600 Subject: [nvmewin] New Patch From Sandisk In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFF48E4@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D88983606256082A@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFE961C@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062560AA2@FMSMSX105.amr.corp.intel.com> <49158E750348AA499168FD41D889836062578A2D@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEC067@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062578B98@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEE32C@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFEEB8A@corpmail1.na.ads.idt.com> , <548C5470AAD9DA4A85D259B663190D361FFEEBBA@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFF487D@corpmail1.na.ads.idt.com> <23EC73C80FB59046A6B7B8EB7B382659233059DD@MILMBXIP01.sdcorp.global.sandisk.com> <548C5470AAD9DA4A85D259B663190D361FFF489C@corpmail1.na.ads.idt.com> <23EC73C80FB59046A6B7B8EB7B38265923305A78@MILMBXIP01.sdcorp.global.sandisk.com> <548C5470AAD9DA4A85D259B663190D361FFF48E4@corpmail1.na.ads.idt.com> Message-ID: <4565AEA676113A449269C2F3A549520F01382E0998@cosmail03.lsi.com> Hi Alex, We are good with this patch from Sandisk. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Wednesday, June 26, 2013 1:24 PM To: Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi all, Please review the patch and provide your feedbacks if you have any. Meanwhile, I'd like to receive the approvals from Intel and LSI at your earliest convenience when you're fine with the patch. Thanks, Alex ________________________________ From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com] Sent: Wednesday, June 26, 2013 11:00 AM To: Chang, Alex; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Alex, Please find attached the patch that fixes the SCSI compliance test for MODE SENSE merged with the latest LSI TRIM command support . Attached is also the log of a scsicompliance successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Wednesday, June 26, 2013 9:09 AM To: Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk That'd be great! Thanks, Alex ________________________________ From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com] Sent: Wednesday, June 26, 2013 9:03 AM To: Chang, Alex; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Alex, I have just merged the code to the latest OFA driver. I want to run the SCSI compliance test on the merged code. Probably EOD or tomorrow I will send the patch. Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 25, 2013 7:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I just pushed the patch from LSI. Please re-base your changes and send your patch out for review. Since we had tested/reviewed your patch before, I hope to push it as soon as possible. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [nvmewin-bounces at lists.openfabrics.org] on behalf of Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:26 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Thank you very much, Sumant. Regards, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 3:24 PM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hello Alex, Sure, no problem. We will wait for the patches in the pipeline to be accepted and then rebase and resubmit the patch. Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 2:14 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Currently, we are reviewing the patch from LSI, which adds supporting for TRIM command. Once Intel and IDT approve it, the patch will be added first. Then we will review your patch. However, you need to re-base to include the recent patches from IDT and LSI first and re-send your patch out. Thanks you very much and please let me know if you have questions. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 11:01 AM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Alex, Thanks for the feedback. Please find attached the patch that fixes the SCSI compliance test for MODE SENSE. Attached is also the log of a successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, June 03, 2013 2:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I retested the patch with SCSICompliance and it results a new failure: MODE SENSE (6) Comparing MODE PAGE data before and after DBD bit is set. Could you test it to see if you can replicate it? You may find more details in the attachment. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 30, 2013 3:20 PM To: Robles, Raymond C; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Ray, Please find attached the patch that has fix for the last code review comment. This is the patch set that I had sent to Alex earlier. Password : sndk1234 Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 3:10 PM To: Chang, Alex; Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thanks Alex. Sumant, please continue with your updates from the last set of code review comments and resend the patch (after running all the required unit tests of course). Once we confirm the feedback changes are in place, I’ll push the patch. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 30, 2013 3:07 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Actually I did some preliminary debugging on it and found out the crash was not introduced by your patch. When the system gets normal shutdown, NVMeNormalShutdown calls NVMeFreeBuffers to free up all queue related structures. And later, when NVMeDetectPendingCmds is called to check on the pending commands, it refers to the queue structures and causes the crash. I will include the fix in my next patch that includes changes to be compliant with 1.0e NVMe Specification. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 30, 2013 2:11 PM To: Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hello Alex, I haven’t been able to repro the BSOD issue that you saw in your setup. Would it be possible for you to send me the crashdump please ? Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 1:24 PM To: Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Importance: High Dharani/Sumant, What is the status on this patch? I’ve not seen any follow up to my last email below. Hopefully we can close this out soon as there are other patches waiting to be submitted. Thanks for your quick attention. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, May 16, 2013 3:49 PM To: Chang, Alex; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Actually, I was going to type the same thing in my email below and then got derailed with the whole #define issue (thanks for capturing this Alex). There is no DataTransferLength field in the SRB Extension structure. That is defined in the SRB by Storport. As a general courtesy to other companies who are reviewing these patches, please insure that you are compiling and re-testing your patch prior to sending out for secondary or additional code reviews. This will help save valuable time in the code review process. If you are having issues compiling, or do not see the same errors, please contact me. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 16, 2013 3:44 PM To: Robles, Raymond C; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, The only change you've made in the new patch is replacing: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); with: memset(GET_DATA_BUFFER(pSrb), 0, min(pSrbExt->DataTransferLength, allocLength)); However, it generates compiling error because DataTransferLength is not a member of NVME_SRB_EXTENSION structure. Could you please fix it? Thanks a lot for you help, Alex ________________________________ From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 16, 2013 1:37 PM To: Sumant Patro; Knoblaugh, Rick; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant/Dharani, Thanks for the updated patch. A couple of comments/questions: - For all the mode sense page translations, the new temp buffer allocated in the SRB extension is used. But for the Modes Sense 0x3C (all mode pages), the SRB data buffer is still memset to 0 at the beginning of SntiReturnAllModePages(). I’m not sure we still need to do this considering how the temp buffer is used to build the mode sense data. - If you insist on keeping that memset in there, there is a #define in for all mode pages - MODE_SENSE_ALL_PAGES_LENGTH. It may be better to zero out the buffer based on the min between this define and allocLength. SRB data transfer length cannot be relied on for “data-in” commands (like mode sense). Thanks, Ray From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 16, 2013 12:43 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Sorry, sent the wrong zip in the previous mail. Please ignore the previous attachment. Attached is the updated zip file. Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 16, 2013 12:38 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Thanks Rick, Alex for your feedback. Please find attached updated files with following two changes : 1. Comment in header of SntiCreateModeDataHeader function changed to reflect passing of srb extension 2. memset(GET_DATA_BUFFER(pSrb), 0, allocLength); modified to use minimum of allocLength and DataTransferLength in SntiReturnAllModePages(..) Password : sndk1234 Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Thursday, May 16, 2013 11:59 AM To: Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, When you change that one, may as well fix the comment in header of SntiCreateModeDataHeader function to reflect that srb extension is now the parameter that’s passed in. Other stuff looks good. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, May 16, 2013 10:58 AM To: Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, I tested your new patch and experienced a D1 bugcheck while running SCSICompliance test. Some preliminary debugging leads to Line#3633 of nvmestni.c, where it looks like: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); The bugcheck happens when the value of "allocLength" is 0x1000. Apparently, the allocated length in CDB is somewhat a bogus value that is meant to test how driver handles it. Could you please fix it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Wednesday, May 01, 2013 8:56 AM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Ray, I have incorporated the changes according to your suggestions, I tried to keep up with the coding convention please feel free to let me know if anything has to be changed. I have incorporated one more fix in the nvmeInit.c which can lead to memory corruptions and used the SrbExt for the buffer allocation. PassWd: sndk1234 Thanks, Dharani. From: Dharani Kotte Sent: Tuesday, April 30, 2013 12:03 PM To: 'Robles, Raymond C'; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thank you for the feedback, I agree that the global buffer is not good I have made the changes to allocate this buffer from the srbext I will provide the code with the below modifications soon. Thanks, Dharani. From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, April 30, 2013 11:52 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, Thank you for putting this patch together. Please see my feedback below: - Line 52: Note that we have a file called nvmeSntiTypes.h. This file contains all #defines. As per our existing convention, all #defines should be placed in this file (versus at the top of a .c file). - Line 3339/3412/3502/3593/3756/5391/5433/5442/5453: Our coding convention states no line be longer than 80 characters. These lines all exceed 80 characters. - Line 5410: SntiTranslateAllModePagesResponse() contains new if-else blocks. Our coding convention dictates that open curly braces be placed on the same line as the if or else statement. You can refer to other instances of the code and if-else clauses as examples. - Line 4017: SntiCreateModeDataHeader() no longer needs the SRB pointer to be passed in as a parameter since you are using a global temp buffer to build up the mode sense data. That parameter can be removed. - General: The method of using a global buffer for a single mode sense command opens up a potential race condition for multiple mode sense commands submitted on top of each other. The idea behind putting the SCSI to NVMe translation phase in the HwStorBuildIo phase was to help performance. We initially knew that we would never be sharing any data structures or memory in calls to BuildIo. There is no spinlock or protection for calls to BuildIo and MSDN makes it clear that these BuildIo calls are not synchronized and that any synchronization of memory/data must be done within the function implementations or just use StartIo instead (since Storport will acquire the StartIoSpinLock). So there is hole here w/r/t the global buffer being populated for multiple mode sense commands at the same time. I believe you have the right idea, but the correct solution is to create a temp mode sense buffer inside the SRB extension. This way, each command has its own temp mode sense buffer for building the mode sense response, and then when ready to copy over to the SRB data buffer, it’s pulling from a buffer that can only be accessed by the current command (instead of a global buffer that may have been overwritten by another mode sense request call from another BuildIo call). Note that the driver collaboration group made the decision to never acquire any type of lock in BuildIo. Let me know if you have questions on this solution. The additional size to the SRB extension is not an issue. This fix is critical for this patch to be accepted. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 11:14 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Attaching the code with according to Alex suggestion. Passwd: sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, April 30, 2013 9:23 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, I'd suggest that it's safer to initialize gModeSenseBuf as all zeros each time before it is used, just in case there are some unexpected data in the buffer. Other than that, I am fine with the patch. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 8:37 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] New Patch From Sandisk Hi all, It's been almost two weeks after I sent out the patch. please let us know if you're okay with it. Thanks, Dharani. From: Dharani Kotte Sent: Friday, April 12, 2013 9:58 AM To: nvmewin at lists.openfabrics.org Subject: New Patch From Sandisk Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeSnti.c a. Allocate a global buffer of 256bytes size for modesense return data preparation b. For any mode sense this buffer is used for modesense data along with the requested pages in it. c. Copy the required data according to the alloc_length requested in the cdb to the Srb->DataBuffer and update the dataTransferLength accordingly d. In function SntiTranslateReturnAllModePagesResponse() the modesense data header offset is calculated wrong which ends up in BSOD in some cases modified code to fix this issue 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, 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). CAUTION: Please confirm that the password protected .zip attachment which contains the file(s) of type source_sndk_05_16_2013.zip is legitimate prior to opening. To make sure this message is not infected with a virus, it is important to verify that you are expecting the message or else confirm its legitimacy with the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Wed Jun 26 17:16:01 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Thu, 27 Jun 2013 00:16:01 +0000 Subject: [nvmewin] New Patch From Sandisk In-Reply-To: <4565AEA676113A449269C2F3A549520F01382E0998@cosmail03.lsi.com> References: <49158E750348AA499168FD41D88983606256082A@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFE961C@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062560AA2@FMSMSX105.amr.corp.intel.com> <49158E750348AA499168FD41D889836062578A2D@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEC067@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062578B98@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEE32C@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFEEB8A@corpmail1.na.ads.idt.com> , <548C5470AAD9DA4A85D259B663190D361FFEEBBA@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFF487D@corpmail1.na.ads.idt.com> <23EC73C80FB59046A6B7B8EB7B382659233059DD@MILMBXIP01.sdcorp.global.sandisk.com> <548C5470AAD9DA4A85D259B663190D361FFF489C@corpmail1.na.ads.idt.com> <23EC73C80FB59046A6B7B8EB7B38265923305A78@MILMBXIP01.sdcorp.global.sandisk.com> <548C5470AAD9DA4A85D259B663190D361FFF48E4@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F01382E0998@cosmail03.lsi.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFF49D9@corpmail1.na.ads.idt.com> Thanks a lot, Rick. I ran thru all the tests and the patch is working fine to me. Let's wait for Kris a bit. Alex ________________________________ From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Wednesday, June 26, 2013 4:11 PM To: Chang, Alex; Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Alex, We are good with this patch from Sandisk. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Wednesday, June 26, 2013 1:24 PM To: Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi all, Please review the patch and provide your feedbacks if you have any. Meanwhile, I'd like to receive the approvals from Intel and LSI at your earliest convenience when you're fine with the patch. Thanks, Alex ________________________________ From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com] Sent: Wednesday, June 26, 2013 11:00 AM To: Chang, Alex; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Alex, Please find attached the patch that fixes the SCSI compliance test for MODE SENSE merged with the latest LSI TRIM command support . Attached is also the log of a scsicompliance successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Wednesday, June 26, 2013 9:09 AM To: Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk That'd be great! Thanks, Alex ________________________________ From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com] Sent: Wednesday, June 26, 2013 9:03 AM To: Chang, Alex; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Alex, I have just merged the code to the latest OFA driver. I want to run the SCSI compliance test on the merged code. Probably EOD or tomorrow I will send the patch. Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 25, 2013 7:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I just pushed the patch from LSI. Please re-base your changes and send your patch out for review. Since we had tested/reviewed your patch before, I hope to push it as soon as possible. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [nvmewin-bounces at lists.openfabrics.org] on behalf of Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:26 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Thank you very much, Sumant. Regards, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 3:24 PM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hello Alex, Sure, no problem. We will wait for the patches in the pipeline to be accepted and then rebase and resubmit the patch. Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 2:14 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Currently, we are reviewing the patch from LSI, which adds supporting for TRIM command. Once Intel and IDT approve it, the patch will be added first. Then we will review your patch. However, you need to re-base to include the recent patches from IDT and LSI first and re-send your patch out. Thanks you very much and please let me know if you have questions. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 11:01 AM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Alex, Thanks for the feedback. Please find attached the patch that fixes the SCSI compliance test for MODE SENSE. Attached is also the log of a successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, June 03, 2013 2:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I retested the patch with SCSICompliance and it results a new failure: MODE SENSE (6) Comparing MODE PAGE data before and after DBD bit is set. Could you test it to see if you can replicate it? You may find more details in the attachment. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 30, 2013 3:20 PM To: Robles, Raymond C; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Ray, Please find attached the patch that has fix for the last code review comment. This is the patch set that I had sent to Alex earlier. Password : sndk1234 Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 3:10 PM To: Chang, Alex; Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thanks Alex. Sumant, please continue with your updates from the last set of code review comments and resend the patch (after running all the required unit tests of course). Once we confirm the feedback changes are in place, I’ll push the patch. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 30, 2013 3:07 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Actually I did some preliminary debugging on it and found out the crash was not introduced by your patch. When the system gets normal shutdown, NVMeNormalShutdown calls NVMeFreeBuffers to free up all queue related structures. And later, when NVMeDetectPendingCmds is called to check on the pending commands, it refers to the queue structures and causes the crash. I will include the fix in my next patch that includes changes to be compliant with 1.0e NVMe Specification. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 30, 2013 2:11 PM To: Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hello Alex, I haven’t been able to repro the BSOD issue that you saw in your setup. Would it be possible for you to send me the crashdump please ? Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 1:24 PM To: Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Importance: High Dharani/Sumant, What is the status on this patch? I’ve not seen any follow up to my last email below. Hopefully we can close this out soon as there are other patches waiting to be submitted. Thanks for your quick attention. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, May 16, 2013 3:49 PM To: Chang, Alex; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Actually, I was going to type the same thing in my email below and then got derailed with the whole #define issue (thanks for capturing this Alex). There is no DataTransferLength field in the SRB Extension structure. That is defined in the SRB by Storport. As a general courtesy to other companies who are reviewing these patches, please insure that you are compiling and re-testing your patch prior to sending out for secondary or additional code reviews. This will help save valuable time in the code review process. If you are having issues compiling, or do not see the same errors, please contact me. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 16, 2013 3:44 PM To: Robles, Raymond C; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, The only change you've made in the new patch is replacing: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); with: memset(GET_DATA_BUFFER(pSrb), 0, min(pSrbExt->DataTransferLength, allocLength)); However, it generates compiling error because DataTransferLength is not a member of NVME_SRB_EXTENSION structure. Could you please fix it? Thanks a lot for you help, Alex ________________________________ From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 16, 2013 1:37 PM To: Sumant Patro; Knoblaugh, Rick; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant/Dharani, Thanks for the updated patch. A couple of comments/questions: - For all the mode sense page translations, the new temp buffer allocated in the SRB extension is used. But for the Modes Sense 0x3C (all mode pages), the SRB data buffer is still memset to 0 at the beginning of SntiReturnAllModePages(). I’m not sure we still need to do this considering how the temp buffer is used to build the mode sense data. - If you insist on keeping that memset in there, there is a #define in for all mode pages - MODE_SENSE_ALL_PAGES_LENGTH. It may be better to zero out the buffer based on the min between this define and allocLength. SRB data transfer length cannot be relied on for “data-in” commands (like mode sense). Thanks, Ray From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 16, 2013 12:43 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Sorry, sent the wrong zip in the previous mail. Please ignore the previous attachment. Attached is the updated zip file. Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 16, 2013 12:38 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Thanks Rick, Alex for your feedback. Please find attached updated files with following two changes : 1. Comment in header of SntiCreateModeDataHeader function changed to reflect passing of srb extension 2. memset(GET_DATA_BUFFER(pSrb), 0, allocLength); modified to use minimum of allocLength and DataTransferLength in SntiReturnAllModePages(..) Password : sndk1234 Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Thursday, May 16, 2013 11:59 AM To: Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, When you change that one, may as well fix the comment in header of SntiCreateModeDataHeader function to reflect that srb extension is now the parameter that’s passed in. Other stuff looks good. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, May 16, 2013 10:58 AM To: Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, I tested your new patch and experienced a D1 bugcheck while running SCSICompliance test. Some preliminary debugging leads to Line#3633 of nvmestni.c, where it looks like: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); The bugcheck happens when the value of "allocLength" is 0x1000. Apparently, the allocated length in CDB is somewhat a bogus value that is meant to test how driver handles it. Could you please fix it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Wednesday, May 01, 2013 8:56 AM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Ray, I have incorporated the changes according to your suggestions, I tried to keep up with the coding convention please feel free to let me know if anything has to be changed. I have incorporated one more fix in the nvmeInit.c which can lead to memory corruptions and used the SrbExt for the buffer allocation. PassWd: sndk1234 Thanks, Dharani. From: Dharani Kotte Sent: Tuesday, April 30, 2013 12:03 PM To: 'Robles, Raymond C'; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thank you for the feedback, I agree that the global buffer is not good I have made the changes to allocate this buffer from the srbext I will provide the code with the below modifications soon. Thanks, Dharani. From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, April 30, 2013 11:52 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, Thank you for putting this patch together. Please see my feedback below: - Line 52: Note that we have a file called nvmeSntiTypes.h. This file contains all #defines. As per our existing convention, all #defines should be placed in this file (versus at the top of a .c file). - Line 3339/3412/3502/3593/3756/5391/5433/5442/5453: Our coding convention states no line be longer than 80 characters. These lines all exceed 80 characters. - Line 5410: SntiTranslateAllModePagesResponse() contains new if-else blocks. Our coding convention dictates that open curly braces be placed on the same line as the if or else statement. You can refer to other instances of the code and if-else clauses as examples. - Line 4017: SntiCreateModeDataHeader() no longer needs the SRB pointer to be passed in as a parameter since you are using a global temp buffer to build up the mode sense data. That parameter can be removed. - General: The method of using a global buffer for a single mode sense command opens up a potential race condition for multiple mode sense commands submitted on top of each other. The idea behind putting the SCSI to NVMe translation phase in the HwStorBuildIo phase was to help performance. We initially knew that we would never be sharing any data structures or memory in calls to BuildIo. There is no spinlock or protection for calls to BuildIo and MSDN makes it clear that these BuildIo calls are not synchronized and that any synchronization of memory/data must be done within the function implementations or just use StartIo instead (since Storport will acquire the StartIoSpinLock). So there is hole here w/r/t the global buffer being populated for multiple mode sense commands at the same time. I believe you have the right idea, but the correct solution is to create a temp mode sense buffer inside the SRB extension. This way, each command has its own temp mode sense buffer for building the mode sense response, and then when ready to copy over to the SRB data buffer, it’s pulling from a buffer that can only be accessed by the current command (instead of a global buffer that may have been overwritten by another mode sense request call from another BuildIo call). Note that the driver collaboration group made the decision to never acquire any type of lock in BuildIo. Let me know if you have questions on this solution. The additional size to the SRB extension is not an issue. This fix is critical for this patch to be accepted. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 11:14 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Attaching the code with according to Alex suggestion. Passwd: sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, April 30, 2013 9:23 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, I'd suggest that it's safer to initialize gModeSenseBuf as all zeros each time before it is used, just in case there are some unexpected data in the buffer. Other than that, I am fine with the patch. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 8:37 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] New Patch From Sandisk Hi all, It's been almost two weeks after I sent out the patch. please let us know if you're okay with it. Thanks, Dharani. From: Dharani Kotte Sent: Friday, April 12, 2013 9:58 AM To: nvmewin at lists.openfabrics.org Subject: New Patch From Sandisk Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeSnti.c a. Allocate a global buffer of 256bytes size for modesense return data preparation b. For any mode sense this buffer is used for modesense data along with the requested pages in it. c. Copy the required data according to the alloc_length requested in the cdb to the Srb->DataBuffer and update the dataTransferLength accordingly d. In function SntiTranslateReturnAllModePagesResponse() the modesense data header offset is calculated wrong which ends up in BSOD in some cases modified code to fix this issue 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, 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). CAUTION: Please confirm that the password protected .zip attachment which contains the file(s) of type source_sndk_05_16_2013.zip is legitimate prior to opening. To make sure this message is not infected with a virus, it is important to verify that you are expecting the message or else confirm its legitimacy with the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kris.r.murray at intel.com Thu Jun 27 08:07:20 2013 From: kris.r.murray at intel.com (Murray, Kris R) Date: Thu, 27 Jun 2013 15:07:20 +0000 Subject: [nvmewin] New Patch From Sandisk In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFF49D9@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D88983606256082A@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFE961C@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062560AA2@FMSMSX105.amr.corp.intel.com> <49158E750348AA499168FD41D889836062578A2D@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEC067@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062578B98@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEE32C@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFEEB8A@corpmail1.na.ads.idt.com> , <548C5470AAD9DA4A85D259B663190D361FFEEBBA@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFF487D@corpmail1.na.ads.idt.com> <23EC73C80FB59046A6B7B8EB7B382659233059DD@MILMBXIP01.sdcorp.global.sandisk.com> <548C5470AAD9DA4A85D259B663190D361FFF489C@corpmail1.na.ads.idt.com> <23EC73C80FB59046A6B7B8EB7B38265923305A78@MILMBXIP01.sdcorp.global.sandisk.com> <548C5470AAD9DA4A85D259B663190D361FFF48E4@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F01382E0998@cosmail03.lsi.com> <548C5470AAD9DA4A85D259B663190D361FFF49D9@corpmail1.na.ads.idt.com> Message-ID: <6B4557D9CF036C4E8F9D6C561818DABB365D7400@FMSMSX112.amr.corp.intel.com> Sorry for the delay, my corporate firewall settings don’t let me access the SVN repository so I need to update my repo from home. The only thing I could see is a minor nitpick, line 4074 is slightly longer than line length in code style guide. Just putting each argument on it’s own line would be sufficient change. From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Wednesday, June 26, 2013 5:16 PM To: Knoblaugh, Rick; Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Thanks a lot, Rick. I ran thru all the tests and the patch is working fine to me. Let's wait for Kris a bit. Alex ________________________________ From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Wednesday, June 26, 2013 4:11 PM To: Chang, Alex; Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Alex, We are good with this patch from Sandisk. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Wednesday, June 26, 2013 1:24 PM To: Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi all, Please review the patch and provide your feedbacks if you have any. Meanwhile, I'd like to receive the approvals from Intel and LSI at your earliest convenience when you're fine with the patch. Thanks, Alex ________________________________ From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com] Sent: Wednesday, June 26, 2013 11:00 AM To: Chang, Alex; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Alex, Please find attached the patch that fixes the SCSI compliance test for MODE SENSE merged with the latest LSI TRIM command support . Attached is also the log of a scsicompliance successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Wednesday, June 26, 2013 9:09 AM To: Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk That'd be great! Thanks, Alex ________________________________ From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com] Sent: Wednesday, June 26, 2013 9:03 AM To: Chang, Alex; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Alex, I have just merged the code to the latest OFA driver. I want to run the SCSI compliance test on the merged code. Probably EOD or tomorrow I will send the patch. Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 25, 2013 7:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I just pushed the patch from LSI. Please re-base your changes and send your patch out for review. Since we had tested/reviewed your patch before, I hope to push it as soon as possible. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [nvmewin-bounces at lists.openfabrics.org] on behalf of Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:26 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Thank you very much, Sumant. Regards, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 3:24 PM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hello Alex, Sure, no problem. We will wait for the patches in the pipeline to be accepted and then rebase and resubmit the patch. Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 2:14 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Currently, we are reviewing the patch from LSI, which adds supporting for TRIM command. Once Intel and IDT approve it, the patch will be added first. Then we will review your patch. However, you need to re-base to include the recent patches from IDT and LSI first and re-send your patch out. Thanks you very much and please let me know if you have questions. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 11:01 AM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Alex, Thanks for the feedback. Please find attached the patch that fixes the SCSI compliance test for MODE SENSE. Attached is also the log of a successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, June 03, 2013 2:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I retested the patch with SCSICompliance and it results a new failure: MODE SENSE (6) Comparing MODE PAGE data before and after DBD bit is set. Could you test it to see if you can replicate it? You may find more details in the attachment. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 30, 2013 3:20 PM To: Robles, Raymond C; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Ray, Please find attached the patch that has fix for the last code review comment. This is the patch set that I had sent to Alex earlier. Password : sndk1234 Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 3:10 PM To: Chang, Alex; Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thanks Alex. Sumant, please continue with your updates from the last set of code review comments and resend the patch (after running all the required unit tests of course). Once we confirm the feedback changes are in place, I’ll push the patch. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 30, 2013 3:07 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Actually I did some preliminary debugging on it and found out the crash was not introduced by your patch. When the system gets normal shutdown, NVMeNormalShutdown calls NVMeFreeBuffers to free up all queue related structures. And later, when NVMeDetectPendingCmds is called to check on the pending commands, it refers to the queue structures and causes the crash. I will include the fix in my next patch that includes changes to be compliant with 1.0e NVMe Specification. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 30, 2013 2:11 PM To: Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hello Alex, I haven’t been able to repro the BSOD issue that you saw in your setup. Would it be possible for you to send me the crashdump please ? Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 1:24 PM To: Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Importance: High Dharani/Sumant, What is the status on this patch? I’ve not seen any follow up to my last email below. Hopefully we can close this out soon as there are other patches waiting to be submitted. Thanks for your quick attention. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, May 16, 2013 3:49 PM To: Chang, Alex; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Actually, I was going to type the same thing in my email below and then got derailed with the whole #define issue (thanks for capturing this Alex). There is no DataTransferLength field in the SRB Extension structure. That is defined in the SRB by Storport. As a general courtesy to other companies who are reviewing these patches, please insure that you are compiling and re-testing your patch prior to sending out for secondary or additional code reviews. This will help save valuable time in the code review process. If you are having issues compiling, or do not see the same errors, please contact me. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 16, 2013 3:44 PM To: Robles, Raymond C; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, The only change you've made in the new patch is replacing: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); with: memset(GET_DATA_BUFFER(pSrb), 0, min(pSrbExt->DataTransferLength, allocLength)); However, it generates compiling error because DataTransferLength is not a member of NVME_SRB_EXTENSION structure. Could you please fix it? Thanks a lot for you help, Alex ________________________________ From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 16, 2013 1:37 PM To: Sumant Patro; Knoblaugh, Rick; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant/Dharani, Thanks for the updated patch. A couple of comments/questions: - For all the mode sense page translations, the new temp buffer allocated in the SRB extension is used. But for the Modes Sense 0x3C (all mode pages), the SRB data buffer is still memset to 0 at the beginning of SntiReturnAllModePages(). I’m not sure we still need to do this considering how the temp buffer is used to build the mode sense data. - If you insist on keeping that memset in there, there is a #define in for all mode pages - MODE_SENSE_ALL_PAGES_LENGTH. It may be better to zero out the buffer based on the min between this define and allocLength. SRB data transfer length cannot be relied on for “data-in” commands (like mode sense). Thanks, Ray From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 16, 2013 12:43 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Sorry, sent the wrong zip in the previous mail. Please ignore the previous attachment. Attached is the updated zip file. Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 16, 2013 12:38 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Thanks Rick, Alex for your feedback. Please find attached updated files with following two changes : 1. Comment in header of SntiCreateModeDataHeader function changed to reflect passing of srb extension 2. memset(GET_DATA_BUFFER(pSrb), 0, allocLength); modified to use minimum of allocLength and DataTransferLength in SntiReturnAllModePages(..) Password : sndk1234 Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Thursday, May 16, 2013 11:59 AM To: Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, When you change that one, may as well fix the comment in header of SntiCreateModeDataHeader function to reflect that srb extension is now the parameter that’s passed in. Other stuff looks good. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, May 16, 2013 10:58 AM To: Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, I tested your new patch and experienced a D1 bugcheck while running SCSICompliance test. Some preliminary debugging leads to Line#3633 of nvmestni.c, where it looks like: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); The bugcheck happens when the value of "allocLength" is 0x1000. Apparently, the allocated length in CDB is somewhat a bogus value that is meant to test how driver handles it. Could you please fix it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Wednesday, May 01, 2013 8:56 AM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Ray, I have incorporated the changes according to your suggestions, I tried to keep up with the coding convention please feel free to let me know if anything has to be changed. I have incorporated one more fix in the nvmeInit.c which can lead to memory corruptions and used the SrbExt for the buffer allocation. PassWd: sndk1234 Thanks, Dharani. From: Dharani Kotte Sent: Tuesday, April 30, 2013 12:03 PM To: 'Robles, Raymond C'; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thank you for the feedback, I agree that the global buffer is not good I have made the changes to allocate this buffer from the srbext I will provide the code with the below modifications soon. Thanks, Dharani. From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, April 30, 2013 11:52 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, Thank you for putting this patch together. Please see my feedback below: - Line 52: Note that we have a file called nvmeSntiTypes.h. This file contains all #defines. As per our existing convention, all #defines should be placed in this file (versus at the top of a .c file). - Line 3339/3412/3502/3593/3756/5391/5433/5442/5453: Our coding convention states no line be longer than 80 characters. These lines all exceed 80 characters. - Line 5410: SntiTranslateAllModePagesResponse() contains new if-else blocks. Our coding convention dictates that open curly braces be placed on the same line as the if or else statement. You can refer to other instances of the code and if-else clauses as examples. - Line 4017: SntiCreateModeDataHeader() no longer needs the SRB pointer to be passed in as a parameter since you are using a global temp buffer to build up the mode sense data. That parameter can be removed. - General: The method of using a global buffer for a single mode sense command opens up a potential race condition for multiple mode sense commands submitted on top of each other. The idea behind putting the SCSI to NVMe translation phase in the HwStorBuildIo phase was to help performance. We initially knew that we would never be sharing any data structures or memory in calls to BuildIo. There is no spinlock or protection for calls to BuildIo and MSDN makes it clear that these BuildIo calls are not synchronized and that any synchronization of memory/data must be done within the function implementations or just use StartIo instead (since Storport will acquire the StartIoSpinLock). So there is hole here w/r/t the global buffer being populated for multiple mode sense commands at the same time. I believe you have the right idea, but the correct solution is to create a temp mode sense buffer inside the SRB extension. This way, each command has its own temp mode sense buffer for building the mode sense response, and then when ready to copy over to the SRB data buffer, it’s pulling from a buffer that can only be accessed by the current command (instead of a global buffer that may have been overwritten by another mode sense request call from another BuildIo call). Note that the driver collaboration group made the decision to never acquire any type of lock in BuildIo. Let me know if you have questions on this solution. The additional size to the SRB extension is not an issue. This fix is critical for this patch to be accepted. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 11:14 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Attaching the code with according to Alex suggestion. Passwd: sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, April 30, 2013 9:23 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, I'd suggest that it's safer to initialize gModeSenseBuf as all zeros each time before it is used, just in case there are some unexpected data in the buffer. Other than that, I am fine with the patch. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 8:37 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] New Patch From Sandisk Hi all, It's been almost two weeks after I sent out the patch. please let us know if you're okay with it. Thanks, Dharani. From: Dharani Kotte Sent: Friday, April 12, 2013 9:58 AM To: nvmewin at lists.openfabrics.org Subject: New Patch From Sandisk Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeSnti.c a. Allocate a global buffer of 256bytes size for modesense return data preparation b. For any mode sense this buffer is used for modesense data along with the requested pages in it. c. Copy the required data according to the alloc_length requested in the cdb to the Srb->DataBuffer and update the dataTransferLength accordingly d. In function SntiTranslateReturnAllModePagesResponse() the modesense data header offset is calculated wrong which ends up in BSOD in some cases modified code to fix this issue 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, 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). CAUTION: Please confirm that the password protected .zip attachment which contains the file(s) of type source_sndk_05_16_2013.zip is legitimate prior to opening. To make sure this message is not infected with a virus, it is important to verify that you are expecting the message or else confirm its legitimacy with the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Thu Jun 27 09:14:45 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Thu, 27 Jun 2013 16:14:45 +0000 Subject: [nvmewin] New Patch From Sandisk In-Reply-To: <6B4557D9CF036C4E8F9D6C561818DABB365D7400@FMSMSX112.amr.corp.intel.com> References: <49158E750348AA499168FD41D88983606256082A@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFE961C@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062560AA2@FMSMSX105.amr.corp.intel.com> <49158E750348AA499168FD41D889836062578A2D@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEC067@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062578B98@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEE32C@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFEEB8A@corpmail1.na.ads.idt.com> , <548C5470AAD9DA4A85D259B663190D361FFEEBBA@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFF487D@corpmail1.na.ads.idt.com> <23EC73C80FB59046A6B7B8EB7B382659233059DD@MILMBXIP01.sdcorp.global.sandisk.com> <548C5470AAD9DA4A85D259B663190D361FFF489C@corpmail1.na.ads.idt.com> <23EC73C80FB59046A6B7B8EB7B38265923305A78@MILMBXIP01.sdcorp.global.sandisk.com> <548C5470AAD9DA4A85D259B663190D361FFF48E4@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F01382E0998@cosmail03.lsi.com> <548C5470AAD9DA4A85D259B663190D361FFF49D9@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D7400@FMSMSX112.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFF4A05@corpmail1.na.ads.idt.com> Hi Kris, I think that's pretty minor and there are other places going longer than that. Are there any significant ones or test results you'd like to address? Or you're good with it? Thanks Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 8:07 AM To: Chang, Alex; Knoblaugh, Rick; Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Sorry for the delay, my corporate firewall settings don’t let me access the SVN repository so I need to update my repo from home. The only thing I could see is a minor nitpick, line 4074 is slightly longer than line length in code style guide. Just putting each argument on it’s own line would be sufficient change. From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Wednesday, June 26, 2013 5:16 PM To: Knoblaugh, Rick; Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Thanks a lot, Rick. I ran thru all the tests and the patch is working fine to me. Let's wait for Kris a bit. Alex ________________________________ From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Wednesday, June 26, 2013 4:11 PM To: Chang, Alex; Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Alex, We are good with this patch from Sandisk. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Wednesday, June 26, 2013 1:24 PM To: Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi all, Please review the patch and provide your feedbacks if you have any. Meanwhile, I'd like to receive the approvals from Intel and LSI at your earliest convenience when you're fine with the patch. Thanks, Alex ________________________________ From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com] Sent: Wednesday, June 26, 2013 11:00 AM To: Chang, Alex; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Alex, Please find attached the patch that fixes the SCSI compliance test for MODE SENSE merged with the latest LSI TRIM command support . Attached is also the log of a scsicompliance successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Wednesday, June 26, 2013 9:09 AM To: Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk That'd be great! Thanks, Alex ________________________________ From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com] Sent: Wednesday, June 26, 2013 9:03 AM To: Chang, Alex; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Alex, I have just merged the code to the latest OFA driver. I want to run the SCSI compliance test on the merged code. Probably EOD or tomorrow I will send the patch. Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 25, 2013 7:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I just pushed the patch from LSI. Please re-base your changes and send your patch out for review. Since we had tested/reviewed your patch before, I hope to push it as soon as possible. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [nvmewin-bounces at lists.openfabrics.org] on behalf of Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:26 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Thank you very much, Sumant. Regards, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 3:24 PM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hello Alex, Sure, no problem. We will wait for the patches in the pipeline to be accepted and then rebase and resubmit the patch. Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 2:14 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Currently, we are reviewing the patch from LSI, which adds supporting for TRIM command. Once Intel and IDT approve it, the patch will be added first. Then we will review your patch. However, you need to re-base to include the recent patches from IDT and LSI first and re-send your patch out. Thanks you very much and please let me know if you have questions. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 11:01 AM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Alex, Thanks for the feedback. Please find attached the patch that fixes the SCSI compliance test for MODE SENSE. Attached is also the log of a successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, June 03, 2013 2:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I retested the patch with SCSICompliance and it results a new failure: MODE SENSE (6) Comparing MODE PAGE data before and after DBD bit is set. Could you test it to see if you can replicate it? You may find more details in the attachment. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 30, 2013 3:20 PM To: Robles, Raymond C; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Ray, Please find attached the patch that has fix for the last code review comment. This is the patch set that I had sent to Alex earlier. Password : sndk1234 Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 3:10 PM To: Chang, Alex; Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thanks Alex. Sumant, please continue with your updates from the last set of code review comments and resend the patch (after running all the required unit tests of course). Once we confirm the feedback changes are in place, I’ll push the patch. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 30, 2013 3:07 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Actually I did some preliminary debugging on it and found out the crash was not introduced by your patch. When the system gets normal shutdown, NVMeNormalShutdown calls NVMeFreeBuffers to free up all queue related structures. And later, when NVMeDetectPendingCmds is called to check on the pending commands, it refers to the queue structures and causes the crash. I will include the fix in my next patch that includes changes to be compliant with 1.0e NVMe Specification. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 30, 2013 2:11 PM To: Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hello Alex, I haven’t been able to repro the BSOD issue that you saw in your setup. Would it be possible for you to send me the crashdump please ? Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 1:24 PM To: Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Importance: High Dharani/Sumant, What is the status on this patch? I’ve not seen any follow up to my last email below. Hopefully we can close this out soon as there are other patches waiting to be submitted. Thanks for your quick attention. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, May 16, 2013 3:49 PM To: Chang, Alex; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Actually, I was going to type the same thing in my email below and then got derailed with the whole #define issue (thanks for capturing this Alex). There is no DataTransferLength field in the SRB Extension structure. That is defined in the SRB by Storport. As a general courtesy to other companies who are reviewing these patches, please insure that you are compiling and re-testing your patch prior to sending out for secondary or additional code reviews. This will help save valuable time in the code review process. If you are having issues compiling, or do not see the same errors, please contact me. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 16, 2013 3:44 PM To: Robles, Raymond C; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, The only change you've made in the new patch is replacing: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); with: memset(GET_DATA_BUFFER(pSrb), 0, min(pSrbExt->DataTransferLength, allocLength)); However, it generates compiling error because DataTransferLength is not a member of NVME_SRB_EXTENSION structure. Could you please fix it? Thanks a lot for you help, Alex ________________________________ From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 16, 2013 1:37 PM To: Sumant Patro; Knoblaugh, Rick; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant/Dharani, Thanks for the updated patch. A couple of comments/questions: - For all the mode sense page translations, the new temp buffer allocated in the SRB extension is used. But for the Modes Sense 0x3C (all mode pages), the SRB data buffer is still memset to 0 at the beginning of SntiReturnAllModePages(). I’m not sure we still need to do this considering how the temp buffer is used to build the mode sense data. - If you insist on keeping that memset in there, there is a #define in for all mode pages - MODE_SENSE_ALL_PAGES_LENGTH. It may be better to zero out the buffer based on the min between this define and allocLength. SRB data transfer length cannot be relied on for “data-in” commands (like mode sense). Thanks, Ray From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 16, 2013 12:43 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Sorry, sent the wrong zip in the previous mail. Please ignore the previous attachment. Attached is the updated zip file. Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 16, 2013 12:38 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Thanks Rick, Alex for your feedback. Please find attached updated files with following two changes : 1. Comment in header of SntiCreateModeDataHeader function changed to reflect passing of srb extension 2. memset(GET_DATA_BUFFER(pSrb), 0, allocLength); modified to use minimum of allocLength and DataTransferLength in SntiReturnAllModePages(..) Password : sndk1234 Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Thursday, May 16, 2013 11:59 AM To: Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, When you change that one, may as well fix the comment in header of SntiCreateModeDataHeader function to reflect that srb extension is now the parameter that’s passed in. Other stuff looks good. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, May 16, 2013 10:58 AM To: Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, I tested your new patch and experienced a D1 bugcheck while running SCSICompliance test. Some preliminary debugging leads to Line#3633 of nvmestni.c, where it looks like: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); The bugcheck happens when the value of "allocLength" is 0x1000. Apparently, the allocated length in CDB is somewhat a bogus value that is meant to test how driver handles it. Could you please fix it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Wednesday, May 01, 2013 8:56 AM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Ray, I have incorporated the changes according to your suggestions, I tried to keep up with the coding convention please feel free to let me know if anything has to be changed. I have incorporated one more fix in the nvmeInit.c which can lead to memory corruptions and used the SrbExt for the buffer allocation. PassWd: sndk1234 Thanks, Dharani. From: Dharani Kotte Sent: Tuesday, April 30, 2013 12:03 PM To: 'Robles, Raymond C'; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thank you for the feedback, I agree that the global buffer is not good I have made the changes to allocate this buffer from the srbext I will provide the code with the below modifications soon. Thanks, Dharani. From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, April 30, 2013 11:52 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, Thank you for putting this patch together. Please see my feedback below: - Line 52: Note that we have a file called nvmeSntiTypes.h. This file contains all #defines. As per our existing convention, all #defines should be placed in this file (versus at the top of a .c file). - Line 3339/3412/3502/3593/3756/5391/5433/5442/5453: Our coding convention states no line be longer than 80 characters. These lines all exceed 80 characters. - Line 5410: SntiTranslateAllModePagesResponse() contains new if-else blocks. Our coding convention dictates that open curly braces be placed on the same line as the if or else statement. You can refer to other instances of the code and if-else clauses as examples. - Line 4017: SntiCreateModeDataHeader() no longer needs the SRB pointer to be passed in as a parameter since you are using a global temp buffer to build up the mode sense data. That parameter can be removed. - General: The method of using a global buffer for a single mode sense command opens up a potential race condition for multiple mode sense commands submitted on top of each other. The idea behind putting the SCSI to NVMe translation phase in the HwStorBuildIo phase was to help performance. We initially knew that we would never be sharing any data structures or memory in calls to BuildIo. There is no spinlock or protection for calls to BuildIo and MSDN makes it clear that these BuildIo calls are not synchronized and that any synchronization of memory/data must be done within the function implementations or just use StartIo instead (since Storport will acquire the StartIoSpinLock). So there is hole here w/r/t the global buffer being populated for multiple mode sense commands at the same time. I believe you have the right idea, but the correct solution is to create a temp mode sense buffer inside the SRB extension. This way, each command has its own temp mode sense buffer for building the mode sense response, and then when ready to copy over to the SRB data buffer, it’s pulling from a buffer that can only be accessed by the current command (instead of a global buffer that may have been overwritten by another mode sense request call from another BuildIo call). Note that the driver collaboration group made the decision to never acquire any type of lock in BuildIo. Let me know if you have questions on this solution. The additional size to the SRB extension is not an issue. This fix is critical for this patch to be accepted. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 11:14 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Attaching the code with according to Alex suggestion. Passwd: sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, April 30, 2013 9:23 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, I'd suggest that it's safer to initialize gModeSenseBuf as all zeros each time before it is used, just in case there are some unexpected data in the buffer. Other than that, I am fine with the patch. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 8:37 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] New Patch From Sandisk Hi all, It's been almost two weeks after I sent out the patch. please let us know if you're okay with it. Thanks, Dharani. From: Dharani Kotte Sent: Friday, April 12, 2013 9:58 AM To: nvmewin at lists.openfabrics.org Subject: New Patch From Sandisk Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeSnti.c a. Allocate a global buffer of 256bytes size for modesense return data preparation b. For any mode sense this buffer is used for modesense data along with the requested pages in it. c. Copy the required data according to the alloc_length requested in the cdb to the Srb->DataBuffer and update the dataTransferLength accordingly d. In function SntiTranslateReturnAllModePagesResponse() the modesense data header offset is calculated wrong which ends up in BSOD in some cases modified code to fix this issue 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, 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). CAUTION: Please confirm that the password protected .zip attachment which contains the file(s) of type source_sndk_05_16_2013.zip is legitimate prior to opening. To make sure this message is not infected with a virus, it is important to verify that you are expecting the message or else confirm its legitimacy with the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kris.r.murray at intel.com Thu Jun 27 09:22:37 2013 From: kris.r.murray at intel.com (Murray, Kris R) Date: Thu, 27 Jun 2013 16:22:37 +0000 Subject: [nvmewin] New Patch From Sandisk In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFF4A05@corpmail1.na.ads.idt.com> References: <49158E750348AA499168FD41D88983606256082A@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFE961C@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062560AA2@FMSMSX105.amr.corp.intel.com> <49158E750348AA499168FD41D889836062578A2D@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEC067@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062578B98@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEE32C@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFEEB8A@corpmail1.na.ads.idt.com> , <548C5470AAD9DA4A85D259B663190D361FFEEBBA@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFF487D@corpmail1.na.ads.idt.com> <23EC73C80FB59046A6B7B8EB7B382659233059DD@MILMBXIP01.sdcorp.global.sandisk.com> <548C5470AAD9DA4A85D259B663190D361FFF489C@corpmail1.na.ads.idt.com> <23EC73C80FB59046A6B7B8EB7B38265923305A78@MILMBXIP01.sdcorp.global.sandisk.com> <548C5470AAD9DA4A85D259B663190D361FFF48E4@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F01382E0998@cosmail03.lsi.com> <548C5470AAD9DA4A85D259B663190D361FFF49D9@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D7400@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4A05@corpmail1.na.ads.idt.com> Message-ID: <6B4557D9CF036C4E8F9D6C561818DABB365D755A@FMSMSX112.amr.corp.intel.com> Nothing else. ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 9:15 AM To: Murray, Kris R; Knoblaugh, Rick; Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Kris, I think that's pretty minor and there are other places going longer than that. Are there any significant ones or test results you'd like to address? Or you're good with it? Thanks Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 8:07 AM To: Chang, Alex; Knoblaugh, Rick; Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Sorry for the delay, my corporate firewall settings don’t let me access the SVN repository so I need to update my repo from home. The only thing I could see is a minor nitpick, line 4074 is slightly longer than line length in code style guide. Just putting each argument on it’s own line would be sufficient change. From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Wednesday, June 26, 2013 5:16 PM To: Knoblaugh, Rick; Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Thanks a lot, Rick. I ran thru all the tests and the patch is working fine to me. Let's wait for Kris a bit. Alex ________________________________ From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Wednesday, June 26, 2013 4:11 PM To: Chang, Alex; Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Alex, We are good with this patch from Sandisk. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Wednesday, June 26, 2013 1:24 PM To: Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi all, Please review the patch and provide your feedbacks if you have any. Meanwhile, I'd like to receive the approvals from Intel and LSI at your earliest convenience when you're fine with the patch. Thanks, Alex ________________________________ From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com] Sent: Wednesday, June 26, 2013 11:00 AM To: Chang, Alex; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Alex, Please find attached the patch that fixes the SCSI compliance test for MODE SENSE merged with the latest LSI TRIM command support . Attached is also the log of a scsicompliance successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Wednesday, June 26, 2013 9:09 AM To: Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk That'd be great! Thanks, Alex ________________________________ From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com] Sent: Wednesday, June 26, 2013 9:03 AM To: Chang, Alex; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Alex, I have just merged the code to the latest OFA driver. I want to run the SCSI compliance test on the merged code. Probably EOD or tomorrow I will send the patch. Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 25, 2013 7:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I just pushed the patch from LSI. Please re-base your changes and send your patch out for review. Since we had tested/reviewed your patch before, I hope to push it as soon as possible. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [nvmewin-bounces at lists.openfabrics.org] on behalf of Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:26 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Thank you very much, Sumant. Regards, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 3:24 PM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hello Alex, Sure, no problem. We will wait for the patches in the pipeline to be accepted and then rebase and resubmit the patch. Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 2:14 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Currently, we are reviewing the patch from LSI, which adds supporting for TRIM command. Once Intel and IDT approve it, the patch will be added first. Then we will review your patch. However, you need to re-base to include the recent patches from IDT and LSI first and re-send your patch out. Thanks you very much and please let me know if you have questions. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 11:01 AM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Alex, Thanks for the feedback. Please find attached the patch that fixes the SCSI compliance test for MODE SENSE. Attached is also the log of a successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, June 03, 2013 2:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I retested the patch with SCSICompliance and it results a new failure: MODE SENSE (6) Comparing MODE PAGE data before and after DBD bit is set. Could you test it to see if you can replicate it? You may find more details in the attachment. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 30, 2013 3:20 PM To: Robles, Raymond C; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Ray, Please find attached the patch that has fix for the last code review comment. This is the patch set that I had sent to Alex earlier. Password : sndk1234 Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 3:10 PM To: Chang, Alex; Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thanks Alex. Sumant, please continue with your updates from the last set of code review comments and resend the patch (after running all the required unit tests of course). Once we confirm the feedback changes are in place, I’ll push the patch. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 30, 2013 3:07 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Actually I did some preliminary debugging on it and found out the crash was not introduced by your patch. When the system gets normal shutdown, NVMeNormalShutdown calls NVMeFreeBuffers to free up all queue related structures. And later, when NVMeDetectPendingCmds is called to check on the pending commands, it refers to the queue structures and causes the crash. I will include the fix in my next patch that includes changes to be compliant with 1.0e NVMe Specification. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 30, 2013 2:11 PM To: Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hello Alex, I haven’t been able to repro the BSOD issue that you saw in your setup. Would it be possible for you to send me the crashdump please ? Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 1:24 PM To: Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Importance: High Dharani/Sumant, What is the status on this patch? I’ve not seen any follow up to my last email below. Hopefully we can close this out soon as there are other patches waiting to be submitted. Thanks for your quick attention. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, May 16, 2013 3:49 PM To: Chang, Alex; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Actually, I was going to type the same thing in my email below and then got derailed with the whole #define issue (thanks for capturing this Alex). There is no DataTransferLength field in the SRB Extension structure. That is defined in the SRB by Storport. As a general courtesy to other companies who are reviewing these patches, please insure that you are compiling and re-testing your patch prior to sending out for secondary or additional code reviews. This will help save valuable time in the code review process. If you are having issues compiling, or do not see the same errors, please contact me. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 16, 2013 3:44 PM To: Robles, Raymond C; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, The only change you've made in the new patch is replacing: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); with: memset(GET_DATA_BUFFER(pSrb), 0, min(pSrbExt->DataTransferLength, allocLength)); However, it generates compiling error because DataTransferLength is not a member of NVME_SRB_EXTENSION structure. Could you please fix it? Thanks a lot for you help, Alex ________________________________ From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 16, 2013 1:37 PM To: Sumant Patro; Knoblaugh, Rick; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant/Dharani, Thanks for the updated patch. A couple of comments/questions: - For all the mode sense page translations, the new temp buffer allocated in the SRB extension is used. But for the Modes Sense 0x3C (all mode pages), the SRB data buffer is still memset to 0 at the beginning of SntiReturnAllModePages(). I’m not sure we still need to do this considering how the temp buffer is used to build the mode sense data. - If you insist on keeping that memset in there, there is a #define in for all mode pages - MODE_SENSE_ALL_PAGES_LENGTH. It may be better to zero out the buffer based on the min between this define and allocLength. SRB data transfer length cannot be relied on for “data-in” commands (like mode sense). Thanks, Ray From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 16, 2013 12:43 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Sorry, sent the wrong zip in the previous mail. Please ignore the previous attachment. Attached is the updated zip file. Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 16, 2013 12:38 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Thanks Rick, Alex for your feedback. Please find attached updated files with following two changes : 1. Comment in header of SntiCreateModeDataHeader function changed to reflect passing of srb extension 2. memset(GET_DATA_BUFFER(pSrb), 0, allocLength); modified to use minimum of allocLength and DataTransferLength in SntiReturnAllModePages(..) Password : sndk1234 Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Thursday, May 16, 2013 11:59 AM To: Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, When you change that one, may as well fix the comment in header of SntiCreateModeDataHeader function to reflect that srb extension is now the parameter that’s passed in. Other stuff looks good. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, May 16, 2013 10:58 AM To: Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, I tested your new patch and experienced a D1 bugcheck while running SCSICompliance test. Some preliminary debugging leads to Line#3633 of nvmestni.c, where it looks like: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); The bugcheck happens when the value of "allocLength" is 0x1000. Apparently, the allocated length in CDB is somewhat a bogus value that is meant to test how driver handles it. Could you please fix it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Wednesday, May 01, 2013 8:56 AM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Ray, I have incorporated the changes according to your suggestions, I tried to keep up with the coding convention please feel free to let me know if anything has to be changed. I have incorporated one more fix in the nvmeInit.c which can lead to memory corruptions and used the SrbExt for the buffer allocation. PassWd: sndk1234 Thanks, Dharani. From: Dharani Kotte Sent: Tuesday, April 30, 2013 12:03 PM To: 'Robles, Raymond C'; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thank you for the feedback, I agree that the global buffer is not good I have made the changes to allocate this buffer from the srbext I will provide the code with the below modifications soon. Thanks, Dharani. From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, April 30, 2013 11:52 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, Thank you for putting this patch together. Please see my feedback below: - Line 52: Note that we have a file called nvmeSntiTypes.h. This file contains all #defines. As per our existing convention, all #defines should be placed in this file (versus at the top of a .c file). - Line 3339/3412/3502/3593/3756/5391/5433/5442/5453: Our coding convention states no line be longer than 80 characters. These lines all exceed 80 characters. - Line 5410: SntiTranslateAllModePagesResponse() contains new if-else blocks. Our coding convention dictates that open curly braces be placed on the same line as the if or else statement. You can refer to other instances of the code and if-else clauses as examples. - Line 4017: SntiCreateModeDataHeader() no longer needs the SRB pointer to be passed in as a parameter since you are using a global temp buffer to build up the mode sense data. That parameter can be removed. - General: The method of using a global buffer for a single mode sense command opens up a potential race condition for multiple mode sense commands submitted on top of each other. The idea behind putting the SCSI to NVMe translation phase in the HwStorBuildIo phase was to help performance. We initially knew that we would never be sharing any data structures or memory in calls to BuildIo. There is no spinlock or protection for calls to BuildIo and MSDN makes it clear that these BuildIo calls are not synchronized and that any synchronization of memory/data must be done within the function implementations or just use StartIo instead (since Storport will acquire the StartIoSpinLock). So there is hole here w/r/t the global buffer being populated for multiple mode sense commands at the same time. I believe you have the right idea, but the correct solution is to create a temp mode sense buffer inside the SRB extension. This way, each command has its own temp mode sense buffer for building the mode sense response, and then when ready to copy over to the SRB data buffer, it’s pulling from a buffer that can only be accessed by the current command (instead of a global buffer that may have been overwritten by another mode sense request call from another BuildIo call). Note that the driver collaboration group made the decision to never acquire any type of lock in BuildIo. Let me know if you have questions on this solution. The additional size to the SRB extension is not an issue. This fix is critical for this patch to be accepted. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 11:14 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Attaching the code with according to Alex suggestion. Passwd: sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, April 30, 2013 9:23 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, I'd suggest that it's safer to initialize gModeSenseBuf as all zeros each time before it is used, just in case there are some unexpected data in the buffer. Other than that, I am fine with the patch. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 8:37 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] New Patch From Sandisk Hi all, It's been almost two weeks after I sent out the patch. please let us know if you're okay with it. Thanks, Dharani. From: Dharani Kotte Sent: Friday, April 12, 2013 9:58 AM To: nvmewin at lists.openfabrics.org Subject: New Patch From Sandisk Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeSnti.c a. Allocate a global buffer of 256bytes size for modesense return data preparation b. For any mode sense this buffer is used for modesense data along with the requested pages in it. c. Copy the required data according to the alloc_length requested in the cdb to the Srb->DataBuffer and update the dataTransferLength accordingly d. In function SntiTranslateReturnAllModePagesResponse() the modesense data header offset is calculated wrong which ends up in BSOD in some cases modified code to fix this issue 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, 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). CAUTION: Please confirm that the password protected .zip attachment which contains the file(s) of type source_sndk_05_16_2013.zip is legitimate prior to opening. To make sure this message is not infected with a virus, it is important to verify that you are expecting the message or else confirm its legitimacy with the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Thu Jun 27 09:59:58 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Thu, 27 Jun 2013 16:59:58 +0000 Subject: [nvmewin] New Patch From Sandisk In-Reply-To: <6B4557D9CF036C4E8F9D6C561818DABB365D755A@FMSMSX112.amr.corp.intel.com> References: <49158E750348AA499168FD41D88983606256082A@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFE961C@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062560AA2@FMSMSX105.amr.corp.intel.com> <49158E750348AA499168FD41D889836062578A2D@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEC067@corpmail1.na.ads.idt.com> <49158E750348AA499168FD41D889836062578B98@FMSMSX105.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFEE32C@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFEEB8A@corpmail1.na.ads.idt.com> , <548C5470AAD9DA4A85D259B663190D361FFEEBBA@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFF487D@corpmail1.na.ads.idt.com> <23EC73C80FB59046A6B7B8EB7B382659233059DD@MILMBXIP01.sdcorp.global.sandisk.com> <548C5470AAD9DA4A85D259B663190D361FFF489C@corpmail1.na.ads.idt.com> <23EC73C80FB59046A6B7B8EB7B38265923305A78@MILMBXIP01.sdcorp.global.sandisk.com> <548C5470AAD9DA4A85D259B663190D361FFF48E4@corpmail1.na.ads.idt.com> <4565AEA676113A449269C2F3A549520F01382E0998@cosmail03.lsi.com> <548C5470AAD9DA4A85D259B663190D361FFF49D9@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D7400@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4A05@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D755A@FMSMSX112.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFF4A25@corpmail1.na.ads.idt.com> Thank you, Kris. I will push the patch by the end of today. Regards, Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 9:23 AM To: Chang, Alex; Knoblaugh, Rick; Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Nothing else. ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 9:15 AM To: Murray, Kris R; Knoblaugh, Rick; Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Kris, I think that's pretty minor and there are other places going longer than that. Are there any significant ones or test results you'd like to address? Or you're good with it? Thanks Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 8:07 AM To: Chang, Alex; Knoblaugh, Rick; Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Sorry for the delay, my corporate firewall settings don’t let me access the SVN repository so I need to update my repo from home. The only thing I could see is a minor nitpick, line 4074 is slightly longer than line length in code style guide. Just putting each argument on it’s own line would be sufficient change. From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Wednesday, June 26, 2013 5:16 PM To: Knoblaugh, Rick; Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Thanks a lot, Rick. I ran thru all the tests and the patch is working fine to me. Let's wait for Kris a bit. Alex ________________________________ From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com] Sent: Wednesday, June 26, 2013 4:11 PM To: Chang, Alex; Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Alex, We are good with this patch from Sandisk. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Wednesday, June 26, 2013 1:24 PM To: Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi all, Please review the patch and provide your feedbacks if you have any. Meanwhile, I'd like to receive the approvals from Intel and LSI at your earliest convenience when you're fine with the patch. Thanks, Alex ________________________________ From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com] Sent: Wednesday, June 26, 2013 11:00 AM To: Chang, Alex; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Alex, Please find attached the patch that fixes the SCSI compliance test for MODE SENSE merged with the latest LSI TRIM command support . Attached is also the log of a scsicompliance successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Wednesday, June 26, 2013 9:09 AM To: Dharani Kotte; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk That'd be great! Thanks, Alex ________________________________ From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com] Sent: Wednesday, June 26, 2013 9:03 AM To: Chang, Alex; Sumant Patro; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Alex, I have just merged the code to the latest OFA driver. I want to run the SCSI compliance test on the merged code. Probably EOD or tomorrow I will send the patch. Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 25, 2013 7:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I just pushed the patch from LSI. Please re-base your changes and send your patch out for review. Since we had tested/reviewed your patch before, I hope to push it as soon as possible. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [nvmewin-bounces at lists.openfabrics.org] on behalf of Chang, Alex [Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 3:26 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Thank you very much, Sumant. Regards, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 3:24 PM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hello Alex, Sure, no problem. We will wait for the patches in the pipeline to be accepted and then rebase and resubmit the patch. Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, June 11, 2013 2:14 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Currently, we are reviewing the patch from LSI, which adds supporting for TRIM command. Once Intel and IDT approve it, the patch will be added first. Then we will review your patch. However, you need to re-base to include the recent patches from IDT and LSI first and re-send your patch out. Thanks you very much and please let me know if you have questions. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Tuesday, June 11, 2013 11:01 AM To: Chang, Alex; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Alex, Thanks for the feedback. Please find attached the patch that fixes the SCSI compliance test for MODE SENSE. Attached is also the log of a successful run for your reference. We see two failure READ CAP and WRITE (10) failure, however, it is not part of the submitted code changes. Please let us know if the patch is good for acceptance. Password : sndk1234 Regards, Sumant From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, June 03, 2013 2:08 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, I retested the patch with SCSICompliance and it results a new failure: MODE SENSE (6) Comparing MODE PAGE data before and after DBD bit is set. Could you test it to see if you can replicate it? You may find more details in the attachment. Thanks, Alex ________________________________ From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 30, 2013 3:20 PM To: Robles, Raymond C; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Hello Ray, Please find attached the patch that has fix for the last code review comment. This is the patch set that I had sent to Alex earlier. Password : sndk1234 Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 3:10 PM To: Chang, Alex; Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thanks Alex. Sumant, please continue with your updates from the last set of code review comments and resend the patch (after running all the required unit tests of course). Once we confirm the feedback changes are in place, I’ll push the patch. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 30, 2013 3:07 PM To: Sumant Patro; Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, Actually I did some preliminary debugging on it and found out the crash was not introduced by your patch. When the system gets normal shutdown, NVMeNormalShutdown calls NVMeFreeBuffers to free up all queue related structures. And later, when NVMeDetectPendingCmds is called to check on the pending commands, it refers to the queue structures and causes the crash. I will include the fix in my next patch that includes changes to be compliant with 1.0e NVMe Specification. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 30, 2013 2:11 PM To: Robles, Raymond C; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hello Alex, I haven’t been able to repro the BSOD issue that you saw in your setup. Would it be possible for you to send me the crashdump please ? Regards, Sumant From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 30, 2013 1:24 PM To: Sumant Patro; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Importance: High Dharani/Sumant, What is the status on this patch? I’ve not seen any follow up to my last email below. Hopefully we can close this out soon as there are other patches waiting to be submitted. Thanks for your quick attention. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Thursday, May 16, 2013 3:49 PM To: Chang, Alex; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Actually, I was going to type the same thing in my email below and then got derailed with the whole #define issue (thanks for capturing this Alex). There is no DataTransferLength field in the SRB Extension structure. That is defined in the SRB by Storport. As a general courtesy to other companies who are reviewing these patches, please insure that you are compiling and re-testing your patch prior to sending out for secondary or additional code reviews. This will help save valuable time in the code review process. If you are having issues compiling, or do not see the same errors, please contact me. Thanks, Ray From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, May 16, 2013 3:44 PM To: Robles, Raymond C; Sumant Patro; Knoblaugh, Rick; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant, The only change you've made in the new patch is replacing: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); with: memset(GET_DATA_BUFFER(pSrb), 0, min(pSrbExt->DataTransferLength, allocLength)); However, it generates compiling error because DataTransferLength is not a member of NVME_SRB_EXTENSION structure. Could you please fix it? Thanks a lot for you help, Alex ________________________________ From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Thursday, May 16, 2013 1:37 PM To: Sumant Patro; Knoblaugh, Rick; Chang, Alex; Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Sumant/Dharani, Thanks for the updated patch. A couple of comments/questions: - For all the mode sense page translations, the new temp buffer allocated in the SRB extension is used. But for the Modes Sense 0x3C (all mode pages), the SRB data buffer is still memset to 0 at the beginning of SntiReturnAllModePages(). I’m not sure we still need to do this considering how the temp buffer is used to build the mode sense data. - If you insist on keeping that memset in there, there is a #define in for all mode pages - MODE_SENSE_ALL_PAGES_LENGTH. It may be better to zero out the buffer based on the min between this define and allocLength. SRB data transfer length cannot be relied on for “data-in” commands (like mode sense). Thanks, Ray From: Sumant Patro [mailto:Sumant.Patro at sandisk.com] Sent: Thursday, May 16, 2013 12:43 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Sorry, sent the wrong zip in the previous mail. Please ignore the previous attachment. Attached is the updated zip file. Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Sumant Patro Sent: Thursday, May 16, 2013 12:38 PM To: Knoblaugh, Rick; Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: ニ[WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: New Patch From Sandisk Thanks Rick, Alex for your feedback. Please find attached updated files with following two changes : 1. Comment in header of SntiCreateModeDataHeader function changed to reflect passing of srb extension 2. memset(GET_DATA_BUFFER(pSrb), 0, allocLength); modified to use minimum of allocLength and DataTransferLength in SntiReturnAllModePages(..) Password : sndk1234 Regards, Sumant From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Knoblaugh, Rick Sent: Thursday, May 16, 2013 11:59 AM To: Chang, Alex; Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, When you change that one, may as well fix the comment in header of SntiCreateModeDataHeader function to reflect that srb extension is now the parameter that’s passed in. Other stuff looks good. Thanks, -Rick From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Thursday, May 16, 2013 10:58 AM To: Dharani Kotte; Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] New Patch From Sandisk Hi Dharani, I tested your new patch and experienced a D1 bugcheck while running SCSICompliance test. Some preliminary debugging leads to Line#3633 of nvmestni.c, where it looks like: memset(GET_DATA_BUFFER(pSrb), 0, allocLength); The bugcheck happens when the value of "allocLength" is 0x1000. Apparently, the allocated length in CDB is somewhat a bogus value that is meant to test how driver handles it. Could you please fix it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Wednesday, May 01, 2013 8:56 AM To: Robles, Raymond C; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Hi Ray, I have incorporated the changes according to your suggestions, I tried to keep up with the coding convention please feel free to let me know if anything has to be changed. I have incorporated one more fix in the nvmeInit.c which can lead to memory corruptions and used the SrbExt for the buffer allocation. PassWd: sndk1234 Thanks, Dharani. From: Dharani Kotte Sent: Tuesday, April 30, 2013 12:03 PM To: 'Robles, Raymond C'; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Thank you for the feedback, I agree that the global buffer is not good I have made the changes to allocate this buffer from the srbext I will provide the code with the below modifications soon. Thanks, Dharani. From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, April 30, 2013 11:52 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, Thank you for putting this patch together. Please see my feedback below: - Line 52: Note that we have a file called nvmeSntiTypes.h. This file contains all #defines. As per our existing convention, all #defines should be placed in this file (versus at the top of a .c file). - Line 3339/3412/3502/3593/3756/5391/5433/5442/5453: Our coding convention states no line be longer than 80 characters. These lines all exceed 80 characters. - Line 5410: SntiTranslateAllModePagesResponse() contains new if-else blocks. Our coding convention dictates that open curly braces be placed on the same line as the if or else statement. You can refer to other instances of the code and if-else clauses as examples. - Line 4017: SntiCreateModeDataHeader() no longer needs the SRB pointer to be passed in as a parameter since you are using a global temp buffer to build up the mode sense data. That parameter can be removed. - General: The method of using a global buffer for a single mode sense command opens up a potential race condition for multiple mode sense commands submitted on top of each other. The idea behind putting the SCSI to NVMe translation phase in the HwStorBuildIo phase was to help performance. We initially knew that we would never be sharing any data structures or memory in calls to BuildIo. There is no spinlock or protection for calls to BuildIo and MSDN makes it clear that these BuildIo calls are not synchronized and that any synchronization of memory/data must be done within the function implementations or just use StartIo instead (since Storport will acquire the StartIoSpinLock). So there is hole here w/r/t the global buffer being populated for multiple mode sense commands at the same time. I believe you have the right idea, but the correct solution is to create a temp mode sense buffer inside the SRB extension. This way, each command has its own temp mode sense buffer for building the mode sense response, and then when ready to copy over to the SRB data buffer, it’s pulling from a buffer that can only be accessed by the current command (instead of a global buffer that may have been overwritten by another mode sense request call from another BuildIo call). Note that the driver collaboration group made the decision to never acquire any type of lock in BuildIo. Let me know if you have questions on this solution. The additional size to the SRB extension is not an issue. This fix is critical for this patch to be accepted. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 11:14 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] New Patch From Sandisk Attaching the code with according to Alex suggestion. Passwd: sndk1234 Thanks, Dharani. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, April 30, 2013 9:23 AM To: Dharani Kotte; nvmewin at lists.openfabrics.org Subject: RE: New Patch From Sandisk Hi Dharani, I'd suggest that it's safer to initialize gModeSenseBuf as all zeros each time before it is used, just in case there are some unexpected data in the buffer. Other than that, I am fine with the patch. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani Kotte Sent: Tuesday, April 30, 2013 8:37 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] New Patch From Sandisk Hi all, It's been almost two weeks after I sent out the patch. please let us know if you're okay with it. Thanks, Dharani. From: Dharani Kotte Sent: Friday, April 12, 2013 9:58 AM To: nvmewin at lists.openfabrics.org Subject: New Patch From Sandisk Hi all, I am attaching a new patch that includes the following changes: 1. In nvmeSnti.c a. Allocate a global buffer of 256bytes size for modesense return data preparation b. For any mode sense this buffer is used for modesense data along with the requested pages in it. c. Copy the required data according to the alloc_length requested in the cdb to the Srb->DataBuffer and update the dataTransferLength accordingly d. In function SntiTranslateReturnAllModePagesResponse() the modesense data header offset is calculated wrong which ends up in BSOD in some cases modified code to fix this issue 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, 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). CAUTION: Please confirm that the password protected .zip attachment which contains the file(s) of type source_sndk_05_16_2013.zip is legitimate prior to opening. To make sure this message is not infected with a virus, it is important to verify that you are expecting the message or else confirm its legitimacy with the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Thu Jun 27 13:25:11 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Thu, 27 Jun 2013 20:25:11 +0000 Subject: [nvmewin] Intel Byte Enable Patch In-Reply-To: <6B4557D9CF036C4E8F9D6C561818DABB365CE5AD@FMSMSX112.amr.corp.intel.com> References: <6B4557D9CF036C4E8F9D6C561818DABB365CE5AD@FMSMSX112.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFF4A66@corpmail1.na.ads.idt.com> Hi Kris, After reviewing your patch, I notice that, variable "IODB" (Line# 900 and 1013 in nvmeinit.c) is declared/initialized, but never gets used. I think you meant to read back the initial value of doorbell pointer with it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Wednesday, June 12, 2013 4:45 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** Intel Byte Enable Patch All, Attached is the patch to fix issues where accessing memory mapped controller register fields directly would generate single byte accesses across the PCIe bus by calling the StorPort functions to read those registers. The 4 places this is done are NVMeFindAdapter, NVMeInitCplQueue, NVMeSubQueue, and NVMeInitCallback. Password: intel1234 Testing done using IOMeter and SCSI Compliance with logs attached. Please review and provide feedback in the next couple weeks. Upon acceptance I'll rebase after the other patches make it through. Thanks, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From kris.r.murray at intel.com Thu Jun 27 13:32:19 2013 From: kris.r.murray at intel.com (Murray, Kris R) Date: Thu, 27 Jun 2013 20:32:19 +0000 Subject: [nvmewin] Intel Byte Enable Patch In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFF4A66@corpmail1.na.ads.idt.com> References: <6B4557D9CF036C4E8F9D6C561818DABB365CE5AD@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4A66@corpmail1.na.ads.idt.com> Message-ID: <6B4557D9CF036C4E8F9D6C561818DABB365D764C@FMSMSX112.amr.corp.intel.com> Correct, Ray was going to use an array for the doorbell registers but it turns out that didn't need to happen. I saw that after I submitted, but decided to wait till the rebase to remove it from the patch. Another change I plan to make is adding a compile option for _WIN64 that will use the StorPortReadUlong64(...) function instead of 2x 32-bit reads. Thanks, ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 1:25 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Hi Kris, After reviewing your patch, I notice that, variable "IODB" (Line# 900 and 1013 in nvmeinit.c) is declared/initialized, but never gets used. I think you meant to read back the initial value of doorbell pointer with it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Wednesday, June 12, 2013 4:45 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** Intel Byte Enable Patch All, Attached is the patch to fix issues where accessing memory mapped controller register fields directly would generate single byte accesses across the PCIe bus by calling the StorPort functions to read those registers. The 4 places this is done are NVMeFindAdapter, NVMeInitCplQueue, NVMeSubQueue, and NVMeInitCallback. Password: intel1234 Testing done using IOMeter and SCSI Compliance with logs attached. Please review and provide feedback in the next couple weeks. Upon acceptance I'll rebase after the other patches make it through. Thanks, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Thu Jun 27 13:44:24 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Thu, 27 Jun 2013 20:44:24 +0000 Subject: [nvmewin] Intel Byte Enable Patch In-Reply-To: <6B4557D9CF036C4E8F9D6C561818DABB365D764C@FMSMSX112.amr.corp.intel.com> References: <6B4557D9CF036C4E8F9D6C561818DABB365CE5AD@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4A66@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D764C@FMSMSX112.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFF4A88@corpmail1.na.ads.idt.com> Sounds good to me. However, the API is only available on Windows 8. You might want add: #if _WIN32_WINNT > _WIN32_WINNT_WIN7 Thanks, Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 1:32 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Correct, Ray was going to use an array for the doorbell registers but it turns out that didn't need to happen. I saw that after I submitted, but decided to wait till the rebase to remove it from the patch. Another change I plan to make is adding a compile option for _WIN64 that will use the StorPortReadUlong64(...) function instead of 2x 32-bit reads. Thanks, ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 1:25 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Hi Kris, After reviewing your patch, I notice that, variable "IODB" (Line# 900 and 1013 in nvmeinit.c) is declared/initialized, but never gets used. I think you meant to read back the initial value of doorbell pointer with it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Wednesday, June 12, 2013 4:45 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** Intel Byte Enable Patch All, Attached is the patch to fix issues where accessing memory mapped controller register fields directly would generate single byte accesses across the PCIe bus by calling the StorPort functions to read those registers. The 4 places this is done are NVMeFindAdapter, NVMeInitCplQueue, NVMeSubQueue, and NVMeInitCallback. Password: intel1234 Testing done using IOMeter and SCSI Compliance with logs attached. Please review and provide feedback in the next couple weeks. Upon acceptance I'll rebase after the other patches make it through. Thanks, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From kris.r.murray at intel.com Thu Jun 27 16:35:35 2013 From: kris.r.murray at intel.com (Murray, Kris R) Date: Thu, 27 Jun 2013 23:35:35 +0000 Subject: [nvmewin] Intel Byte Enable Patch In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFF4A88@corpmail1.na.ads.idt.com> References: <6B4557D9CF036C4E8F9D6C561818DABB365CE5AD@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4A66@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D764C@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4A88@corpmail1.na.ads.idt.com> Message-ID: <6B4557D9CF036C4E8F9D6C561818DABB365D7721@FMSMSX112.amr.corp.intel.com> Are you sure? When we looked at the definition in storport.h (and wdm.h) it doesn't appear to be wrapped in any OS version compile switches. Also, I tested it on Windows 7 in QEMU and it ran without error. I verified in WinDbg that correct values were read using this function. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 1:44 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Sounds good to me. However, the API is only available on Windows 8. You might want add: #if _WIN32_WINNT > _WIN32_WINNT_WIN7 Thanks, Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 1:32 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Correct, Ray was going to use an array for the doorbell registers but it turns out that didn't need to happen. I saw that after I submitted, but decided to wait till the rebase to remove it from the patch. Another change I plan to make is adding a compile option for _WIN64 that will use the StorPortReadUlong64(...) function instead of 2x 32-bit reads. Thanks, ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 1:25 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Hi Kris, After reviewing your patch, I notice that, variable "IODB" (Line# 900 and 1013 in nvmeinit.c) is declared/initialized, but never gets used. I think you meant to read back the initial value of doorbell pointer with it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Wednesday, June 12, 2013 4:45 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** Intel Byte Enable Patch All, Attached is the patch to fix issues where accessing memory mapped controller register fields directly would generate single byte accesses across the PCIe bus by calling the StorPort functions to read those registers. The 4 places this is done are NVMeFindAdapter, NVMeInitCplQueue, NVMeSubQueue, and NVMeInitCallback. Password: intel1234 Testing done using IOMeter and SCSI Compliance with logs attached. Please review and provide feedback in the next couple weeks. Upon acceptance I'll rebase after the other patches make it through. Thanks, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Thu Jun 27 16:45:22 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Thu, 27 Jun 2013 23:45:22 +0000 Subject: [nvmewin] Intel Byte Enable Patch In-Reply-To: <6B4557D9CF036C4E8F9D6C561818DABB365D7721@FMSMSX112.amr.corp.intel.com> References: <6B4557D9CF036C4E8F9D6C561818DABB365CE5AD@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4A66@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D764C@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4A88@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D7721@FMSMSX112.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFF4B26@corpmail1.na.ads.idt.com> Per this link, it says so: http://msdn.microsoft.com/en-us/library/windows/hardware/hh967741(v=vs.85).aspx I checked the storport.h coming with WDK 7600, it does not define StorPortReadRegisterUlong64. Which WDK version you compile with? Thanks, Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 4:36 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Are you sure? When we looked at the definition in storport.h (and wdm.h) it doesn't appear to be wrapped in any OS version compile switches. Also, I tested it on Windows 7 in QEMU and it ran without error. I verified in WinDbg that correct values were read using this function. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 1:44 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Sounds good to me. However, the API is only available on Windows 8. You might want add: #if _WIN32_WINNT > _WIN32_WINNT_WIN7 Thanks, Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 1:32 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Correct, Ray was going to use an array for the doorbell registers but it turns out that didn't need to happen. I saw that after I submitted, but decided to wait till the rebase to remove it from the patch. Another change I plan to make is adding a compile option for _WIN64 that will use the StorPortReadUlong64(...) function instead of 2x 32-bit reads. Thanks, ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 1:25 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Hi Kris, After reviewing your patch, I notice that, variable "IODB" (Line# 900 and 1013 in nvmeinit.c) is declared/initialized, but never gets used. I think you meant to read back the initial value of doorbell pointer with it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Wednesday, June 12, 2013 4:45 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** Intel Byte Enable Patch All, Attached is the patch to fix issues where accessing memory mapped controller register fields directly would generate single byte accesses across the PCIe bus by calling the StorPort functions to read those registers. The 4 places this is done are NVMeFindAdapter, NVMeInitCplQueue, NVMeSubQueue, and NVMeInitCallback. Password: intel1234 Testing done using IOMeter and SCSI Compliance with logs attached. Please review and provide feedback in the next couple weeks. Upon acceptance I'll rebase after the other patches make it through. Thanks, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From kris.r.murray at intel.com Thu Jun 27 16:59:26 2013 From: kris.r.murray at intel.com (Murray, Kris R) Date: Thu, 27 Jun 2013 23:59:26 +0000 Subject: [nvmewin] Intel Byte Enable Patch In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFF4B26@corpmail1.na.ads.idt.com> References: <6B4557D9CF036C4E8F9D6C561818DABB365CE5AD@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4A66@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D764C@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4A88@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D7721@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4B26@corpmail1.na.ads.idt.com> Message-ID: <6B4557D9CF036C4E8F9D6C561818DABB365D774C@FMSMSX112.amr.corp.intel.com> We're using WDK 8.0 and compiling integrated with Visual Studio 2012. I did try my old WDK 7600 compiler and it gave the error for 'storPortReadRegisterUlong64' as undefined. How about wrapping it with (NTDDI_VERSION >= NTDDI_WIN8)? ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 4:45 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Per this link, it says so: http://msdn.microsoft.com/en-us/library/windows/hardware/hh967741(v=vs.85).aspx I checked the storport.h coming with WDK 7600, it does not define StorPortReadRegisterUlong64. Which WDK version you compile with? Thanks, Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 4:36 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Are you sure? When we looked at the definition in storport.h (and wdm.h) it doesn't appear to be wrapped in any OS version compile switches. Also, I tested it on Windows 7 in QEMU and it ran without error. I verified in WinDbg that correct values were read using this function. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 1:44 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Sounds good to me. However, the API is only available on Windows 8. You might want add: #if _WIN32_WINNT > _WIN32_WINNT_WIN7 Thanks, Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 1:32 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Correct, Ray was going to use an array for the doorbell registers but it turns out that didn't need to happen. I saw that after I submitted, but decided to wait till the rebase to remove it from the patch. Another change I plan to make is adding a compile option for _WIN64 that will use the StorPortReadUlong64(...) function instead of 2x 32-bit reads. Thanks, ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 1:25 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Hi Kris, After reviewing your patch, I notice that, variable "IODB" (Line# 900 and 1013 in nvmeinit.c) is declared/initialized, but never gets used. I think you meant to read back the initial value of doorbell pointer with it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Wednesday, June 12, 2013 4:45 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** Intel Byte Enable Patch All, Attached is the patch to fix issues where accessing memory mapped controller register fields directly would generate single byte accesses across the PCIe bus by calling the StorPort functions to read those registers. The 4 places this is done are NVMeFindAdapter, NVMeInitCplQueue, NVMeSubQueue, and NVMeInitCallback. Password: intel1234 Testing done using IOMeter and SCSI Compliance with logs attached. Please review and provide feedback in the next couple weeks. Upon acceptance I'll rebase after the other patches make it through. Thanks, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Thu Jun 27 17:11:05 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Fri, 28 Jun 2013 00:11:05 +0000 Subject: [nvmewin] Intel Byte Enable Patch In-Reply-To: <6B4557D9CF036C4E8F9D6C561818DABB365D774C@FMSMSX112.amr.corp.intel.com> References: <6B4557D9CF036C4E8F9D6C561818DABB365CE5AD@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4A66@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D764C@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4A88@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D7721@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4B26@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D774C@FMSMSX112.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFF4B3B@corpmail1.na.ads.idt.com> You may refer to the wrapping for TRIM command support codes. We will release two binary packages. One built with WDK 7600 for Windows 7, Windows Server 2008 R2 and Windows Server 2012. The other one built with WDK 8/VS2012 for Windows 8, where the API is compiled in. Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 4:59 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch We're using WDK 8.0 and compiling integrated with Visual Studio 2012. I did try my old WDK 7600 compiler and it gave the error for 'storPortReadRegisterUlong64' as undefined. How about wrapping it with (NTDDI_VERSION >= NTDDI_WIN8)? ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 4:45 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Per this link, it says so: http://msdn.microsoft.com/en-us/library/windows/hardware/hh967741(v=vs.85).aspx I checked the storport.h coming with WDK 7600, it does not define StorPortReadRegisterUlong64. Which WDK version you compile with? Thanks, Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 4:36 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Are you sure? When we looked at the definition in storport.h (and wdm.h) it doesn't appear to be wrapped in any OS version compile switches. Also, I tested it on Windows 7 in QEMU and it ran without error. I verified in WinDbg that correct values were read using this function. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 1:44 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Sounds good to me. However, the API is only available on Windows 8. You might want add: #if _WIN32_WINNT > _WIN32_WINNT_WIN7 Thanks, Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 1:32 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Correct, Ray was going to use an array for the doorbell registers but it turns out that didn't need to happen. I saw that after I submitted, but decided to wait till the rebase to remove it from the patch. Another change I plan to make is adding a compile option for _WIN64 that will use the StorPortReadUlong64(...) function instead of 2x 32-bit reads. Thanks, ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 1:25 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Hi Kris, After reviewing your patch, I notice that, variable "IODB" (Line# 900 and 1013 in nvmeinit.c) is declared/initialized, but never gets used. I think you meant to read back the initial value of doorbell pointer with it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Wednesday, June 12, 2013 4:45 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** Intel Byte Enable Patch All, Attached is the patch to fix issues where accessing memory mapped controller register fields directly would generate single byte accesses across the PCIe bus by calling the StorPort functions to read those registers. The 4 places this is done are NVMeFindAdapter, NVMeInitCplQueue, NVMeSubQueue, and NVMeInitCallback. Password: intel1234 Testing done using IOMeter and SCSI Compliance with logs attached. Please review and provide feedback in the next couple weeks. Upon acceptance I'll rebase after the other patches make it through. Thanks, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Thu Jun 27 19:05:35 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Fri, 28 Jun 2013 02:05:35 +0000 Subject: [nvmewin] NVMe Windows DB Is LOCKED - Pushing Patch From SanDisk - Mode Sense Buffer Fix Message-ID: <548C5470AAD9DA4A85D259B663190D361FFF4B6D@corpmail1.na.ads.idt.com> Locking NVMe Windows DB. Thanks, Alex _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin From Alex.Chang at idt.com Thu Jun 27 19:11:16 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Fri, 28 Jun 2013 02:11:16 +0000 Subject: [nvmewin] NVMe Windows Repo Is UNLOCKED - Mode Sense Buffer Fix Pushed Message-ID: <548C5470AAD9DA4A85D259B663190D361FFF4B7D@corpmail1.na.ads.idt.com> Hi all, Latest patch from SanDisk (Mode Sense Buffer Fix) has been pushed to trunk. A new tag has been created as "Mode_sense_buffer_fix". If anyone has any questions, please feel free to contact me. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Thu Jun 27 19:14:01 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Fri, 28 Jun 2013 02:14:01 +0000 Subject: [nvmewin] Intel Byte Enable Patch In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFF4B41@corpmail1.na.ads.idt.com> References: <6B4557D9CF036C4E8F9D6C561818DABB365CE5AD@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4A66@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D764C@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4A88@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D7721@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4B26@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D774C@FMSMSX112.amr.corp.intel.com>, <548C5470AAD9DA4A85D259B663190D361FFF4B41@corpmail1.na.ads.idt.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFF4B8E@corpmail1.na.ads.idt.com> Hi Kris, The patch from SanDisk had been pushed. You may go ahead re-base and re-send out your patch for review when you're ready. Thanks, Alex ________________________________ From: Chang, Alex Sent: Thursday, June 27, 2013 5:11 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch You may refer to the wrapping for TRIM command support codes. We will release two binary packages. One built with WDK 7600 for Windows 7, Windows Server 2008 R2 and Windows Server 2012. The other one built with WDK 8/VS2012 for Windows 8, where the API is compiled in. Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 4:59 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch We’re using WDK 8.0 and compiling integrated with Visual Studio 2012. I did try my old WDK 7600 compiler and it gave the error for ‘storPortReadRegisterUlong64’ as undefined. How about wrapping it with (NTDDI_VERSION >= NTDDI_WIN8)? ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 4:45 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Per this link, it says so: http://msdn.microsoft.com/en-us/library/windows/hardware/hh967741(v=vs.85).aspx I checked the storport.h coming with WDK 7600, it does not define StorPortReadRegisterUlong64. Which WDK version you compile with? Thanks, Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 4:36 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Are you sure? When we looked at the definition in storport.h (and wdm.h) it doesn’t appear to be wrapped in any OS version compile switches. Also, I tested it on Windows 7 in QEMU and it ran without error. I verified in WinDbg that correct values were read using this function. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 1:44 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Sounds good to me. However, the API is only available on Windows 8. You might want add: #if _WIN32_WINNT > _WIN32_WINNT_WIN7 Thanks, Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 1:32 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Correct, Ray was going to use an array for the doorbell registers but it turns out that didn’t need to happen. I saw that after I submitted, but decided to wait till the rebase to remove it from the patch. Another change I plan to make is adding a compile option for _WIN64 that will use the StorPortReadUlong64(…) function instead of 2x 32-bit reads. Thanks, ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 1:25 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Hi Kris, After reviewing your patch, I notice that, variable "IODB" (Line# 900 and 1013 in nvmeinit.c) is declared/initialized, but never gets used. I think you meant to read back the initial value of doorbell pointer with it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Wednesday, June 12, 2013 4:45 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** Intel Byte Enable Patch All, Attached is the patch to fix issues where accessing memory mapped controller register fields directly would generate single byte accesses across the PCIe bus by calling the StorPort functions to read those registers. The 4 places this is done are NVMeFindAdapter, NVMeInitCplQueue, NVMeSubQueue, and NVMeInitCallback. Password: intel1234 Testing done using IOMeter and SCSI Compliance with logs attached. Please review and provide feedback in the next couple weeks. Upon acceptance I’ll rebase after the other patches make it through. Thanks, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From kris.r.murray at intel.com Fri Jun 28 11:03:37 2013 From: kris.r.murray at intel.com (Murray, Kris R) Date: Fri, 28 Jun 2013 18:03:37 +0000 Subject: [nvmewin] ***UNCHECKED*** RE: Intel Byte Enable Patch In-Reply-To: <548C5470AAD9DA4A85D259B663190D361FFF4B8E@corpmail1.na.ads.idt.com> References: <6B4557D9CF036C4E8F9D6C561818DABB365CE5AD@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4A66@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D764C@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4A88@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D7721@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4B26@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D774C@FMSMSX112.amr.corp.intel.com>, <548C5470AAD9DA4A85D259B663190D361FFF4B41@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFF4B8E@corpmail1.na.ads.idt.com> Message-ID: <6B4557D9CF036C4E8F9D6C561818DABB365D7A6E@FMSMSX112.amr.corp.intel.com> See attached zip file with password: intel1234 In summary, the patch change is whenever the Capabilities register is referenced that is replaced with reading the entire 64-bit register. This is to avoid any Byte Enabled traffic that may be generated across the PCIe bus. The registers are read using 'StorPortReadRegisterUlong()' except on Windows 8 builds with a 64-bit platform. Thanks, ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 7:14 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Hi Kris, The patch from SanDisk had been pushed. You may go ahead re-base and re-send out your patch for review when you're ready. Thanks, Alex ________________________________ From: Chang, Alex Sent: Thursday, June 27, 2013 5:11 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch You may refer to the wrapping for TRIM command support codes. We will release two binary packages. One built with WDK 7600 for Windows 7, Windows Server 2008 R2 and Windows Server 2012. The other one built with WDK 8/VS2012 for Windows 8, where the API is compiled in. Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 4:59 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch We're using WDK 8.0 and compiling integrated with Visual Studio 2012. I did try my old WDK 7600 compiler and it gave the error for 'storPortReadRegisterUlong64' as undefined. How about wrapping it with (NTDDI_VERSION >= NTDDI_WIN8)? ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 4:45 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Per this link, it says so: http://msdn.microsoft.com/en-us/library/windows/hardware/hh967741(v=vs.85).aspx I checked the storport.h coming with WDK 7600, it does not define StorPortReadRegisterUlong64. Which WDK version you compile with? Thanks, Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 4:36 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Are you sure? When we looked at the definition in storport.h (and wdm.h) it doesn't appear to be wrapped in any OS version compile switches. Also, I tested it on Windows 7 in QEMU and it ran without error. I verified in WinDbg that correct values were read using this function. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 1:44 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Sounds good to me. However, the API is only available on Windows 8. You might want add: #if _WIN32_WINNT > _WIN32_WINNT_WIN7 Thanks, Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 1:32 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Correct, Ray was going to use an array for the doorbell registers but it turns out that didn't need to happen. I saw that after I submitted, but decided to wait till the rebase to remove it from the patch. Another change I plan to make is adding a compile option for _WIN64 that will use the StorPortReadUlong64(...) function instead of 2x 32-bit reads. Thanks, ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 1:25 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Hi Kris, After reviewing your patch, I notice that, variable "IODB" (Line# 900 and 1013 in nvmeinit.c) is declared/initialized, but never gets used. I think you meant to read back the initial value of doorbell pointer with it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Wednesday, June 12, 2013 4:45 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** Intel Byte Enable Patch All, Attached is the patch to fix issues where accessing memory mapped controller register fields directly would generate single byte accesses across the PCIe bus by calling the StorPort functions to read those registers. The 4 places this is done are NVMeFindAdapter, NVMeInitCplQueue, NVMeSubQueue, and NVMeInitCallback. Password: intel1234 Testing done using IOMeter and SCSI Compliance with logs attached. Please review and provide feedback in the next couple weeks. Upon acceptance I'll rebase after the other patches make it through. Thanks, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Intel_ByteEnable_Patch.zip Type: application/x-zip-compressed Size: 172906 bytes Desc: Intel_ByteEnable_Patch.zip URL: From Alex.Chang at idt.com Fri Jun 28 12:01:15 2013 From: Alex.Chang at idt.com (Chang, Alex) Date: Fri, 28 Jun 2013 19:01:15 +0000 Subject: [nvmewin] Intel Byte Enable Patch In-Reply-To: <6B4557D9CF036C4E8F9D6C561818DABB365D7A6E@FMSMSX112.amr.corp.intel.com> References: <6B4557D9CF036C4E8F9D6C561818DABB365CE5AD@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4A66@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D764C@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4A88@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D7721@FMSMSX112.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D361FFF4B26@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D774C@FMSMSX112.amr.corp.intel.com>, <548C5470AAD9DA4A85D259B663190D361FFF4B41@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D361FFF4B8E@corpmail1.na.ads.idt.com> <6B4557D9CF036C4E8F9D6C561818DABB365D7A6E@FMSMSX112.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D361FFF4BF9@corpmail1.na.ads.idt.com> Thank you, Kris. Hi all, I did some review on the changes and will do more tests with it. Please provide your feedbacks before July 4th holiday. If LSI and IDT can approve it, I plan to push it then. Thanks, Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Friday, June 28, 2013 11:04 AM To: nvmewin at lists.openfabrics.org Cc: Chang, Alex Subject: RE: Intel Byte Enable Patch See attached zip file with password: intel1234 In summary, the patch change is whenever the Capabilities register is referenced that is replaced with reading the entire 64-bit register. This is to avoid any Byte Enabled traffic that may be generated across the PCIe bus. The registers are read using 'StorPortReadRegisterUlong()' except on Windows 8 builds with a 64-bit platform. Thanks, ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 7:14 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Hi Kris, The patch from SanDisk had been pushed. You may go ahead re-base and re-send out your patch for review when you're ready. Thanks, Alex ________________________________ From: Chang, Alex Sent: Thursday, June 27, 2013 5:11 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch You may refer to the wrapping for TRIM command support codes. We will release two binary packages. One built with WDK 7600 for Windows 7, Windows Server 2008 R2 and Windows Server 2012. The other one built with WDK 8/VS2012 for Windows 8, where the API is compiled in. Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 4:59 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch We're using WDK 8.0 and compiling integrated with Visual Studio 2012. I did try my old WDK 7600 compiler and it gave the error for 'storPortReadRegisterUlong64' as undefined. How about wrapping it with (NTDDI_VERSION >= NTDDI_WIN8)? ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 4:45 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Per this link, it says so: http://msdn.microsoft.com/en-us/library/windows/hardware/hh967741(v=vs.85).aspx I checked the storport.h coming with WDK 7600, it does not define StorPortReadRegisterUlong64. Which WDK version you compile with? Thanks, Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 4:36 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Are you sure? When we looked at the definition in storport.h (and wdm.h) it doesn't appear to be wrapped in any OS version compile switches. Also, I tested it on Windows 7 in QEMU and it ran without error. I verified in WinDbg that correct values were read using this function. From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 1:44 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Sounds good to me. However, the API is only available on Windows 8. You might want add: #if _WIN32_WINNT > _WIN32_WINNT_WIN7 Thanks, Alex ________________________________ From: Murray, Kris R [mailto:kris.r.murray at intel.com] Sent: Thursday, June 27, 2013 1:32 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Correct, Ray was going to use an array for the doorbell registers but it turns out that didn't need to happen. I saw that after I submitted, but decided to wait till the rebase to remove it from the patch. Another change I plan to make is adding a compile option for _WIN64 that will use the StorPortReadUlong64(...) function instead of 2x 32-bit reads. Thanks, ~Kris From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, June 27, 2013 1:25 PM To: Murray, Kris R; nvmewin at lists.openfabrics.org Subject: RE: Intel Byte Enable Patch Hi Kris, After reviewing your patch, I notice that, variable "IODB" (Line# 900 and 1013 in nvmeinit.c) is declared/initialized, but never gets used. I think you meant to read back the initial value of doorbell pointer with it? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Murray, Kris R Sent: Wednesday, June 12, 2013 4:45 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** Intel Byte Enable Patch All, Attached is the patch to fix issues where accessing memory mapped controller register fields directly would generate single byte accesses across the PCIe bus by calling the StorPort functions to read those registers. The 4 places this is done are NVMeFindAdapter, NVMeInitCplQueue, NVMeSubQueue, and NVMeInitCallback. Password: intel1234 Testing done using IOMeter and SCSI Compliance with logs attached. Please review and provide feedback in the next couple weeks. Upon acceptance I'll rebase after the other patches make it through. Thanks, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kwok.Kong at idt.com Fri Jun 28 16:15:29 2013 From: Kwok.Kong at idt.com (Kong, Kwok) Date: Fri, 28 Jun 2013 23:15:29 +0000 Subject: [nvmewin] Windows driver June 17, 2013 meeting note In-Reply-To: <05CD7821AE397547A01AC160FBC231474BCAE247@corpmail1.na.ads.idt.com> References: <05CD7821AE397547A01AC160FBC231474BCAE247@corpmail1.na.ads.idt.com> Message-ID: <05CD7821AE397547A01AC160FBC231474BCB2128@corpmail1.na.ads.idt.com> All, Sandisk (Dharani Kotte) has agreed to take on the task to add the Windows 32-bit support for the 1.3 release. Thanks a lot to Sandisk and Dharani. -Kwok -----Original Message----- From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Kong, Kwok Sent: Monday, June 17, 2013 2:47 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] Windows driver June 17, 2013 meeting note NVMe OFA Windows Driver Meeting Note (June 17, 2013) High level Summary ================== 1. Release 1.2 is expected to be released by end of July 2013. 2. Two binary files will be released - one version supports Windows 7, 8. server 2008R2 and 2012 64-bit but without the TRIM command. - Second version supports Windows 8 64-bit only with TRIM command support. 3. Release 1.3 will be release by Dec 2013 with the following features - windows 32-bit support - Windows 8 extended SRB support - end to end protection support with Windows server 2012 - NVM format state machine enhancement Release 1.2 Status ================== Features: - Alex (IDT) has completed his testing with Windows 8, Server 2008R2 and server 2012 64-bit. The current driver works with all Windows 64-bit OSes. - Alex (IDT) has checked in the code change to support NVMe 1.00e. - Rick (LSI) has submitted a patch to support the TRIM command. He is going to make a coupe of minor update and send the final patch for approval to check in. - Yong (Huawei) has finished the development of the hibernation as a boot drive. There is a problem in the power state transition. It is going to take another week before he can send out his patch for review. He is the 4th in line to send his patch out for review and approval. Known Problems: - Not Accessing NVMe registers in their native width. (Intel) - Code completed. 3rd inline to send patch for review. - ModeSense Translation issue. (Dharani - SanDisk) - Code and testing completed. 2nd inline to send patch for review. - format nvm error. (Judy - Samsung) - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset. (Judy - Samsung) - Code snippets sent out for review. 5th in line to send patch for review. Release 1.3 Plan (Dec 2013) =========================== The following features will be added in the 1.3 release: - Windows 32-bit support (Judy to check with Samsung) - Windows 8 extended SRB support and SMART handling (Kwok to check with Intel) - end to end protection support with Windows server 2012 (Yong - Huawei) - NVM format state machine enhancement (Alex - IDT) Features that will not be supported in 2013 =========================================== NVMe 1.1 support: - multi-path - SGL - Get/Set feature update - Autonomous power state transition - Host Identifier - Reservation Notification Mask - Reservation Persistence - identify structure update - write zeros command Others ====== - Yong (Huawei) is going to check with Microsoft on why binary built with Windows 8 WDK does not work with Windows 7. Next Meeting ============ - Will be scheduled when necessary. Likely to be around Sep time frame. _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin