From paul.e.luse at intel.com Tue Apr 3 10:10:28 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Tue, 3 Apr 2012 17:10:28 +0000 Subject: [nvmewin] new live meeting link Message-ID: <82C9F782B054C94B9FC04A331649C77A0ADDB0@FMSMSX106.amr.corp.intel.com> Join online meeting https://meet.intel.com/paul.e.luse/7VYWK30P ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Tue Apr 3 11:51:52 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Tue, 3 Apr 2012 18:51:52 +0000 Subject: [nvmewin] ***UNCHECKED*** final bits for inspection Message-ID: <82C9F782B054C94B9FC04A331649C77A0ADE69@FMSMSX106.amr.corp.intel.com> Here's what we just looked at + 2 changes: - Removed spinlock in DPC/ISR for learning - Added check for INT_TYPE_MSI to determine whether we can learn or not Rebuilt for both qemu and chatham and did some quick smoke tests. Pw is ofanvme123 Let me know if additional changes are needed or if everyone is good to go. Anyone, of course, can ask additional questions/request other changes however once we heard the word from IDT+LSI we'll merge. Thx Paul ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: source.zip Type: application/x-zip-compressed Size: 157624 bytes Desc: source.zip URL: From paul.e.luse at intel.com Tue Apr 3 13:36:25 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Tue, 3 Apr 2012 20:36:25 +0000 Subject: [nvmewin] LBA range types Message-ID: <82C9F782B054C94B9FC04A331649C77A0AE011@FMSMSX106.amr.corp.intel.com> Alex, I think you and Kwok were the last ones paying attention to range type discussions in the NVMe WG, so I'll ask you. I have a change I'm planning on submitting in the next few weeks that has SNTI honor the hidden attribute however when I added it I quickly discovered that QEMU doesn't report any info for LBA range type and our existing code (on the left below) see the mismatch between range LBAs an namespace size as an indication that there are multiple ranges when in this case it really just means the device gave us all 0's for LBA range info. I notice 1.0c has the device reporting the number of range types in DW0 of the completion entry and since its zero based a device saying 0 now still works so I replaced the size check with that and added a size check to see if the device is reporting the LBA range as size 0 I assume it doesn't support range types at all and just expose it. Can you fill us all in on the latest thoughts wrt range types and how we're supposed to deal with the various scenarios (multiples, un-configured, etc). Also, let me know if you think the changes below are reasonable and I'll include them in my next patch. Thx Paul [cid:image001.png at 01CD119E.C291EA60] ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 344048 bytes Desc: image001.png URL: From paul.e.luse at intel.com Tue Apr 3 13:57:32 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Tue, 3 Apr 2012 20:57:32 +0000 Subject: [nvmewin] latest QEMU Message-ID: <82C9F782B054C94B9FC04A331649C77A0AE03F@FMSMSX106.amr.corp.intel.com> Is here: https://github.com/nvmeqemu/nvmeqemu Doesn't look like the change is up there yet, I'll ping the engr and see if he can push it soon. If anyone wants a one line quick fix, add the highlighted line below to nvme_adm.c in function do_features() and rebuild your qemu (you don't need to re-do your VM of course, just rebuild qemu and restart your VM) case NVME_FEATURE_NUMBER_OF_QUEUES: if (sqe->opcode == NVME_ADM_CMD_SET_FEATURES) { n->feature.number_of_queues = sqe->cdw11; cqe->cmd_specific = sqe->cdw11; } else { cqe->cmd_specific = n->feature.number_of_queues; } break; ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Tue Apr 3 14:13:47 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Tue, 3 Apr 2012 21:13:47 +0000 Subject: [nvmewin] LBA range types In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0AE011@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A0AE011@FMSMSX106.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D36F31E@corpmail1.na.ads.idt.com> Paul, Per NVMe specification, multiple LBA range types can be supported. However, the current driver supports only one for the time being. Apparently, only TYPE Filesystem is supported, which is agreed by all of us. If it's Reserved, Set Features command is issued to change it to Filesystem with Hidden as FALSE and Readonly as FALSE. My thinking for this is it can be pretty complex and it's really up to certain specific needs. Based on what the driver is implemented, it's still compliant with the 1b specification. I am fine with the change you are adding. However, I wonder if it will be defined in 1c or just a proprietary assumption? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Tuesday, April 03, 2012 1:36 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] LBA range types Alex, I think you and Kwok were the last ones paying attention to range type discussions in the NVMe WG, so I'll ask you. I have a change I'm planning on submitting in the next few weeks that has SNTI honor the hidden attribute however when I added it I quickly discovered that QEMU doesn't report any info for LBA range type and our existing code (on the left below) see the mismatch between range LBAs an namespace size as an indication that there are multiple ranges when in this case it really just means the device gave us all 0's for LBA range info. I notice 1.0c has the device reporting the number of range types in DW0 of the completion entry and since its zero based a device saying 0 now still works so I replaced the size check with that and added a size check to see if the device is reporting the LBA range as size 0 I assume it doesn't support range types at all and just expose it. Can you fill us all in on the latest thoughts wrt range types and how we're supposed to deal with the various scenarios (multiples, un-configured, etc). Also, let me know if you think the changes below are reasonable and I'll include them in my next patch. Thx Paul [cid:553325620 at 03042012-24DA] ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 344048 bytes Desc: image001.png URL: From paul.e.luse at intel.com Tue Apr 3 14:54:25 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Tue, 3 Apr 2012 21:54:25 +0000 Subject: [nvmewin] LBA range types In-Reply-To: <548C5470AAD9DA4A85D259B663190D36F31E@corpmail1.na.ads.idt.com> References: <82C9F782B054C94B9FC04A331649C77A0AE011@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D36F31E@corpmail1.na.ads.idt.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0AE187@FMSMSX106.amr.corp.intel.com> Yeah, maybe the better way to handle this is to instead get rid of the code that exists now that considers it a fatal error if get features for LBA range type fails as it is optional in both 1b and 1c and then update qemu to reject the command correctly. I'll look into a bit more before submitting a patch Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, April 03, 2012 2:14 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: LBA range types Paul, Per NVMe specification, multiple LBA range types can be supported. However, the current driver supports only one for the time being. Apparently, only TYPE Filesystem is supported, which is agreed by all of us. If it's Reserved, Set Features command is issued to change it to Filesystem with Hidden as FALSE and Readonly as FALSE. My thinking for this is it can be pretty complex and it's really up to certain specific needs. Based on what the driver is implemented, it's still compliant with the 1b specification. I am fine with the change you are adding. However, I wonder if it will be defined in 1c or just a proprietary assumption? Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Tuesday, April 03, 2012 1:36 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] LBA range types Alex, I think you and Kwok were the last ones paying attention to range type discussions in the NVMe WG, so I'll ask you. I have a change I'm planning on submitting in the next few weeks that has SNTI honor the hidden attribute however when I added it I quickly discovered that QEMU doesn't report any info for LBA range type and our existing code (on the left below) see the mismatch between range LBAs an namespace size as an indication that there are multiple ranges when in this case it really just means the device gave us all 0's for LBA range info. I notice 1.0c has the device reporting the number of range types in DW0 of the completion entry and since its zero based a device saying 0 now still works so I replaced the size check with that and added a size check to see if the device is reporting the LBA range as size 0 I assume it doesn't support range types at all and just expose it. Can you fill us all in on the latest thoughts wrt range types and how we're supposed to deal with the various scenarios (multiples, un-configured, etc). Also, let me know if you think the changes below are reasonable and I'll include them in my next patch. Thx Paul [cid:image002.jpg at 01CD11A9.A7DEBCB0] ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 408874 bytes Desc: image002.jpg URL: From paul.e.luse at intel.com Tue Apr 3 15:11:55 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Tue, 3 Apr 2012 22:11:55 +0000 Subject: [nvmewin] latest QEMU In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0AE03F@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A0AE03F@FMSMSX106.amr.corp.intel.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0AE209@FMSMSX106.amr.corp.intel.com> FYI the source repo below will be updated by early next week and include the fix I mentioned From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Tuesday, April 03, 2012 1:58 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] latest QEMU Is here: https://github.com/nvmeqemu/nvmeqemu Doesn't look like the change is up there yet, I'll ping the engr and see if he can push it soon. If anyone wants a one line quick fix, add the highlighted line below to nvme_adm.c in function do_features() and rebuild your qemu (you don't need to re-do your VM of course, just rebuild qemu and restart your VM) case NVME_FEATURE_NUMBER_OF_QUEUES: if (sqe->opcode == NVME_ADM_CMD_SET_FEATURES) { n->feature.number_of_queues = sqe->cdw11; cqe->cmd_specific = sqe->cdw11; } else { cqe->cmd_specific = n->feature.number_of_queues; } break; ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aruna.ramakrishna at intel.com Fri Apr 6 10:11:45 2012 From: aruna.ramakrishna at intel.com (Ramakrishna, Aruna) Date: Fri, 6 Apr 2012 17:11:45 +0000 Subject: [nvmewin] FW: New livemeeting link In-Reply-To: References: Message-ID: Resending link -----Original Appointment----- From: Ramakrishna, Aruna Sent: Friday, April 06, 2012 10:10 AM To: Robles, Raymond C Subject: FW: New livemeeting link When: Friday, April 06, 2012 10:00 AM-10:30 AM (UTC-07:00) Arizona. Where: Online Meeting -----Original Appointment----- From: Ramakrishna, Aruna Sent: Friday, April 06, 2012 10:08 AM To: nvmhci at lists.intel.com Subject: FW: New livemeeting link When: Friday, April 06, 2012 10:00 AM-10:30 AM (UTC-07:00) Arizona. Where: Online Meeting -----Original Appointment----- From: Ramakrishna, Aruna Sent: Friday, April 06, 2012 10:06 AM To: nvmewin-bounces at lists.openfabrics.org; albert.chen at wdc.com Subject: New livemeeting link When: Friday, April 06, 2012 10:00 AM-10:30 AM (UTC-07:00) Arizona. Where: Online Meeting ......................................................................................................................................... Join online meeting https://meet.intel.com/aruna.ramakrishna/4TFG62GR First online meeting? [!OC([1033])!] ......................................................................................................................................... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2955 bytes Desc: not available URL: From raymond.c.robles at intel.com Fri Apr 13 17:23:14 2012 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Sat, 14 Apr 2012 00:23:14 +0000 Subject: [nvmewin] nvmewin DB is locked - Merging learning mode modifications Message-ID: <49158E750348AA499168FD41D88983600C38BD56@FMSMSX105.amr.corp.intel.com> [Description: Description: Description: Description: cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles PSG Server Software Engineering Datacenter and Connected Systems Group Intel Corporation Office: 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 Fri Apr 13 17:26:03 2012 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Sat, 14 Apr 2012 00:26:03 +0000 Subject: [nvmewin] nvmewin DB is unlocked - Merging learning mode modifications Message-ID: <49158E750348AA499168FD41D88983600C38BD6A@FMSMSX105.amr.corp.intel.com> The latest patch for the learning mode changes have been applied to the trunk. There is also a new tag for this patch named "learning_mode" under the tags directory. The trunk contains all patches up to this point (please work from here). Please update your source to reflect the latest changes. Please let me know if you have any questions. Thanks, Ray [Description: Description: Description: Description: cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles PSG Server Software Engineering Datacenter and Connected Systems Group Intel Corporation Office: 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 paul.e.luse at intel.com Mon Apr 16 08:25:11 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Mon, 16 Apr 2012 15:25:11 +0000 Subject: [nvmewin] Win8 assertion message In-Reply-To: References: <82C9F782B054C94B9FC04A331649C77A08E9B6@FMSMSX106.amr.corp.intel.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0B7C1F@FMSMSX106.amr.corp.intel.com> FYI I finally got around to trying the suggestion below and it didn't get rid of the assertion. Not a high priority of course, but I'll ping Msft again -----Original Message----- From: Harris, James R Sent: Friday, March 16, 2012 11:22 AM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: Win8 assertion message You may need to call GetUncachedExtension, even if you're not going to use it. IIRC, on Win7 Storport would allocate the DMA adapter object during the GetUncachedExtension context. Your adapter likely doesn't have any DMA restrictions, so Storport probably doesn't really need the DMA adapter object, which is why everything works without the call. This is all guessing though - I did some quick searches on the online SVN repo and didn't see any calls to GetUncachedExtension, but I didn't look especially hard... -Jim >-----Original Message----- >From: Luse, Paul E >Sent: Friday, March 16, 2012 11:01 AM >To: Harris, James R; nvmewin at lists.openfabrics.org >Subject: RE: Win8 assertion message > >Sorry... this output starts right as we return true from passiveInit > >nvme!NVMePassiveInitialize+0x3cb: >fffff880`051a8cdb ebc9 jmp nvme!NVMePassiveInitialize+0x396 (fffff880`051a8ca6) >7: kd> p >Breakpoint 2 hit >nvme!NVMePassiveInitialize+0x396: >fffff880`051a8ca6 488b442448 mov rax,qword ptr [rsp+48h] >7: kd> p >nvme!NVMePassiveInitialize+0x3bc: >fffff880`051a8ccc ba88130000 mov edx,1388h >7: kd> p >nvme!NVMePassiveInitialize+0x3cb: >fffff880`051a8cdb ebc9 jmp nvme!NVMePassiveInitialize+0x396 (fffff880`051a8ca6) >7: kd> p >Breakpoint 2 hit >nvme!NVMePassiveInitialize+0x396: >fffff880`051a8ca6 488b442448 mov rax,qword ptr [rsp+48h] >7: kd> p >nvme!NVMePassiveInitialize+0x3bc: >fffff880`051a8ccc ba88130000 mov edx,1388h >7: kd> p >nvme!NVMePassiveInitialize+0x3cb: >fffff880`051a8cdb ebc9 jmp nvme!NVMePassiveInitialize+0x396 (fffff880`051a8ca6) >7: kd> p >Breakpoint 2 hit >nvme!NVMePassiveInitialize+0x396: >fffff880`051a8ca6 488b442448 mov rax,qword ptr [rsp+48h] >7: kd> g >Breakpoint 0 hit >nvme!NVMeRunningWaitOnIoSQ: >fffff880`051ad900 48894c2408 mov qword ptr [rsp+8],rcx >0: kd> g >Breakpoint 3 hit >nvme!NVMePassiveInitialize+0x3cd: >fffff880`051a8cdd 488b442448 mov rax,qword ptr [rsp+48h] >7: kd> p >nvme!NVMePassiveInitialize+0x3f6: >fffff880`051a8d06 4883c468 add rsp,68h >7: kd> p >storport!RaidAdapterStartMiniport+0x244: >fffff880`01700840 f6d8 neg al >7: kd> p >storport!RaidAdapterStartMiniport+0x246: >fffff880`01700842 1bff sbb edi,edi >7: kd> p >storport!RaidAdapterStartMiniport+0x248: >fffff880`01700844 f7d7 not edi >7: kd> p >storport!RaidAdapterStartMiniport+0x24a: >fffff880`01700846 81e7010000c0 and edi,0C0000001h >7: kd> p >storport!RaidAdapterStartMiniport+0x250: >fffff880`0170084c 85ff test edi,edi >7: kd> p >storport!RaidAdapterStartMiniport+0x252: >fffff880`0170084e 78c6 js storport!RaidAdapterStartMiniport+0x21a >(fffff880`01700816) >7: kd> p >storport!RaidAdapterStartMiniport+0x254: >fffff880`01700850 488bcb mov rcx,rbx >7: kd> p >storport!RaidAdapterStartMiniport+0x257: >fffff880`01700853 e8c0010000 call storport!RaidInitializePerfOptsPassive >(fffff880`01700a18) >7: kd> p >storport!RaidAdapterStartMiniport+0x25c: >fffff880`01700858 440fb69b68010000 movzx r11d,byte ptr [rbx+168h] >7: kd> p >storport!RaidAdapterStartMiniport+0x264: >fffff880`01700860 4181fbff000000 cmp r11d,0FFh >7: kd> p >storport!RaidAdapterStartMiniport+0x26b: >fffff880`01700867 7602 jbe storport!RaidAdapterStartMiniport+0x26f >(fffff880`0170086b) >7: kd> p >storport!RaidAdapterStartMiniport+0x26f: >fffff880`0170086b 418bfb mov edi,r11d >7: kd> p >storport!RaidAdapterStartMiniport+0x272: >fffff880`0170086e c1ef05 shr edi,5 >7: kd> p >storport!RaidAdapterStartMiniport+0x275: >fffff880`01700871 41f6c31f test r11b,1Fh >7: kd> p >storport!RaidAdapterStartMiniport+0x279: >fffff880`01700875 7403 je storport!RaidAdapterStartMiniport+0x27e >(fffff880`0170087a) >7: kd> p >storport!RaidAdapterStartMiniport+0x27b: >fffff880`01700877 4103fe add edi,r14d >7: kd> p >storport!RaidAdapterStartMiniport+0x27e: >fffff880`0170087a 8bf7 mov esi,edi >7: kd> p >storport!RaidAdapterStartMiniport+0x280: >fffff880`0170087c 41b85261564d mov r8d,4D566152h >7: kd> p >storport!RaidAdapterStartMiniport+0x286: >fffff880`01700882 b900020000 mov ecx,200h >7: kd> p >storport!RaidAdapterStartMiniport+0x28b: >fffff880`01700887 48c1e602 shl rsi,2 >7: kd> p >storport!RaidAdapterStartMiniport+0x28f: >fffff880`0170088b 488bd6 mov rdx,rsi >7: kd> p >storport!RaidAdapterStartMiniport+0x292: >fffff880`0170088e ff1584970200 call qword ptr [storport!_imp_ExAllocatePoolWithTag >(fffff880`0172a018)] >7: kd> p >storport!RaidAdapterStartMiniport+0x298: >fffff880`01700894 48898350120000 mov qword ptr [rbx+1250h],rax >7: kd> p >storport!RaidAdapterStartMiniport+0x29f: >fffff880`0170089b 4885c0 test rax,rax >7: kd> p >storport!RaidAdapterStartMiniport+0x2a2: >fffff880`0170089e 742b je storport!RaidAdapterStartMiniport+0x2cf >(fffff880`017008cb) >7: kd> p >storport!RaidAdapterStartMiniport+0x2a4: >fffff880`017008a0 4c8bc6 mov r8,rsi >7: kd> p >storport!RaidAdapterStartMiniport+0x2a7: >fffff880`017008a3 33d2 xor edx,edx >7: kd> p >storport!RaidAdapterStartMiniport+0x2a9: >fffff880`017008a5 488bc8 mov rcx,rax >7: kd> p >storport!RaidAdapterStartMiniport+0x2ac: >fffff880`017008a8 e8134b0200 call storport!memset (fffff880`017253c0) >7: kd> p >storport!RaidAdapterStartMiniport+0x2b1: >fffff880`017008ad 488b9350120000 mov rdx,qword ptr [rbx+1250h] >7: kd> p >storport!RaidAdapterStartMiniport+0x2b8: >fffff880`017008b4 c1e705 shl edi,5 >7: kd> p >storport!RaidAdapterStartMiniport+0x2bb: >fffff880`017008b7 488d8b40120000 lea rcx,[rbx+1240h] >7: kd> p >storport!RaidAdapterStartMiniport+0x2c2: >fffff880`017008be 448bc7 mov r8d,edi >7: kd> p >storport!RaidAdapterStartMiniport+0x2c5: >fffff880`017008c1 ff1529980200 call qword ptr [storport!_imp_RtlInitializeBitMap >(fffff880`0172a0f0)] >7: kd> p >storport!RaidAdapterStartMiniport+0x2cb: >fffff880`017008c7 33c0 xor eax,eax >7: kd> p >storport!RaidAdapterStartMiniport+0x2cd: >fffff880`017008c9 eb05 jmp storport!RaidAdapterStartMiniport+0x2d4 >(fffff880`017008d0) >7: kd> p >storport!RaidAdapterStartMiniport+0x2d4: >fffff880`017008d0 488b9c2488000000 mov rbx,qword ptr [rsp+88h] >7: kd> p >storport!RaidAdapterStartMiniport+0x2dc: >fffff880`017008d8 4883c450 add rsp,50h >7: kd> p >storport!RaidAdapterStartMiniport+0x2e0: >fffff880`017008dc 415e pop r14 >7: kd> p >storport!RaidAdapterStartMiniport+0x2e2: >fffff880`017008de 5f pop rdi >7: kd> p >storport!RaidAdapterStartMiniport+0x2e3: >fffff880`017008df 5e pop rsi >7: kd> p >storport!RaidAdapterStartMiniport+0x2e4: >fffff880`017008e0 c3 ret >7: kd> p >storport!RaidAdapterStartDeviceIrp+0x1db: >fffff880`0173182f 8bf8 mov edi,eax >7: kd> p >storport!RaidAdapterStartDeviceIrp+0x1dd: >fffff880`01731831 85c0 test eax,eax >7: kd> p >storport!RaidAdapterStartDeviceIrp+0x1df: >fffff880`01731833 7891 js storport!RaidAdapterStartDeviceIrp+0x172 >(fffff880`017317c6) >7: kd> p >storport!RaidAdapterStartDeviceIrp+0x1e1: >fffff880`01731835 488bcb mov rcx,rbx >7: kd> p >storport!RaidAdapterStartDeviceIrp+0x1e4: >fffff880`01731838 4584f6 test r14b,r14b >7: kd> p >storport!RaidAdapterStartDeviceIrp+0x1e7: >fffff880`0173183b 7524 jne storport!RaidAdapterStartDeviceIrp+0x20d >(fffff880`01731861) >7: kd> p >storport!RaidAdapterStartDeviceIrp+0x1e9: >fffff880`0173183d e8eefafcff call storport!RaidAdapterCompleteInitialization >(fffff880`01701330) >7: kd> p >Assertion: RaidIsRegionInitialized(&Adapter->UncachedExtension) >storport!StorAllocateContiguousIoResources+0x2d: >fffff880`017184a1 cd2c int 2Ch > > >-----Original Message----- >From: nvmewin-bounces at lists.openfabrics.org >[mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Harris, >James R >Sent: Friday, March 16, 2012 10:59 AM >To: nvmewin at lists.openfabrics.org >Subject: [nvmewin] Win8 assertion message > >Paul, > >I didn't see the assertion message come through. Can you paste into your message? > >Thanks, > >-Jim > >_______________________________________________ >nvmewin mailing list >nvmewin at lists.openfabrics.org >http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin From paul.e.luse at intel.com Mon Apr 16 10:04:29 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Mon, 16 Apr 2012 17:04:29 +0000 Subject: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work Message-ID: <82C9F782B054C94B9FC04A331649C77A0B7ED8@FMSMSX106.amr.corp.intel.com> There's only a few changes here that need to be reviewed, mostly this is Chatham specific and, again, the only reason we're allowing these HW specific changes in the driver is because its currently the only HW vehicle available to Msft and to UNH who is working on some test suites. We have an updated version of Chatham which required a few changes but also identified a few issues in the driver that I think are critical enough that I wanted to get them in before we build the release: - We weren't handling the CC register correctly in a few places. Details are below, but this one is critical for new HW. - We were exposing LBA ranges that are identified by the controller as hidden - We weren't correctly handing the report_luns command for multiple luns - We weren't correctly checking status on init state machine completion handlers As usual, pw is ofanvme123 and the faster folks can check this out the faster we can build our first release J Thx Paul Sources: - New switch for chatham2, removed inclusion of chatham switch by default Nvmestd.h - Chatham stuff - Moved some NVME register defines to nvmereg.h - For DBG mode, changed the timeout state machine to something more reasonable (first it was too short, then too long) Nvmestd.c - Chatham stuff - Added readback of CC before we write it again (to toggle EN for initial reset). Without this some HW will surely fail to init correctly Nvmestat.c - Chatham stuff Nvmesnti.ch - Chatham stuff Nvmesnti.c - Changes to honor the ExposeNamespace field we learn from LBA ranges. Previously we were not hiding namespaces that were supposed to be hidden - Fixes to SntiTranslateReportLuns() for multiple LUNs we were incorrectly failing the call when the allocated buffer was too small, the correct handling is to fill out what we can and return the size we needed in the response and we'll get second call with the correctly sized buffer. Tested, of course, and it works as expected - Chatham stuff Nvmereg.h - Moved reg defines to here from the other .h file mentioned above Nveinit.c - In NVMeResetAdapter() we were clobbering the CC register, changed so we correctly read it, clear EN, and write it - In NVMeEnableAdapter() we were not fully setting up CC, added additional fields and deifnes - in NVMeSetFeaturesCompletion(), I mentioned this before I think, I updated LBA range completion handler to assume that an all zero response means that we should expose it, also added a check for what we should be looking for to see if >1 ns is available, the NLB field. Qemu I think is wrong with its LBA range response right now, once its fixed I'll update this to remove the zero check - chatham stuff - in NVMeInitCallback() added checks for status code type as well as status code, just the status code is not sufficient in all cases to determine success or not ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: source.zip Type: application/x-zip-compressed Size: 158591 bytes Desc: source.zip URL: From Alex.Chang at idt.com Mon Apr 16 17:02:55 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Tue, 17 Apr 2012 00:02:55 +0000 Subject: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0B7ED8@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A0B7ED8@FMSMSX106.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D36FAF3@corpmail1.na.ads.idt.com> Hi Paul, I believe there is an error in SntiTranslateSglToPrp routine and it can be easily reproduced in non-quick drive format if the driver reports the size of LBA is 4096 bytes. The failing request I've seen is : 1. Reading LBA0 for one LBA. 2. Only one SG element included. 3. The starting physical address is not page-aligned, i.e., 0x1`12345600 In SntiTranslateSglToPrp, numImplicitEntries is assigned as 1 (Line 4238). After entering 2nd for loop (Line 4248), pSrbExt->numberofPrpEntries becomes 1 (Line 4253), which causes pPrp1 is programmed as localPrpEntry (Line 4256) and then jumps out of the for loop without programming pPrp2. However, pPrp2 should be programmed as 0x1`12346000 to transfer the rest of the page (0xa00 bytes). I am not sure why it works for us for such a long period. May be the different sizes of LBA, and 4096 is simply much easier to replicate the problem. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Monday, April 16, 2012 10:04 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work There's only a few changes here that need to be reviewed, mostly this is Chatham specific and, again, the only reason we're allowing these HW specific changes in the driver is because its currently the only HW vehicle available to Msft and to UNH who is working on some test suites. We have an updated version of Chatham which required a few changes but also identified a few issues in the driver that I think are critical enough that I wanted to get them in before we build the release: - We weren't handling the CC register correctly in a few places. Details are below, but this one is critical for new HW. - We were exposing LBA ranges that are identified by the controller as hidden - We weren't correctly handing the report_luns command for multiple luns - We weren't correctly checking status on init state machine completion handlers As usual, pw is ofanvme123 and the faster folks can check this out the faster we can build our first release J Thx Paul Sources: - New switch for chatham2, removed inclusion of chatham switch by default Nvmestd.h - Chatham stuff - Moved some NVME register defines to nvmereg.h - For DBG mode, changed the timeout state machine to something more reasonable (first it was too short, then too long) Nvmestd.c - Chatham stuff - Added readback of CC before we write it again (to toggle EN for initial reset). Without this some HW will surely fail to init correctly Nvmestat.c - Chatham stuff Nvmesnti.ch - Chatham stuff Nvmesnti.c - Changes to honor the ExposeNamespace field we learn from LBA ranges. Previously we were not hiding namespaces that were supposed to be hidden - Fixes to SntiTranslateReportLuns() for multiple LUNs we were incorrectly failing the call when the allocated buffer was too small, the correct handling is to fill out what we can and return the size we needed in the response and we'll get second call with the correctly sized buffer. Tested, of course, and it works as expected - Chatham stuff Nvmereg.h - Moved reg defines to here from the other .h file mentioned above Nveinit.c - In NVMeResetAdapter() we were clobbering the CC register, changed so we correctly read it, clear EN, and write it - In NVMeEnableAdapter() we were not fully setting up CC, added additional fields and deifnes - in NVMeSetFeaturesCompletion(), I mentioned this before I think, I updated LBA range completion handler to assume that an all zero response means that we should expose it, also added a check for what we should be looking for to see if >1 ns is available, the NLB field. Qemu I think is wrong with its LBA range response right now, once its fixed I'll update this to remove the zero check - chatham stuff - in NVMeInitCallback() added checks for status code type as well as status code, just the status code is not sufficient in all cases to determine success or not ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Mon Apr 16 17:09:27 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Tue, 17 Apr 2012 00:09:27 +0000 Subject: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work In-Reply-To: <548C5470AAD9DA4A85D259B663190D36FAF3@corpmail1.na.ads.idt.com> References: <82C9F782B054C94B9FC04A331649C77A0B7ED8@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D36FAF3@corpmail1.na.ads.idt.com> Message-ID: <548C5470AAD9DA4A85D259B663190D36FB03@corpmail1.na.ads.idt.com> My typo the size of rest of the page should be 0x600 instead of 0xa00. ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, April 16, 2012 5:03 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work Hi Paul, I believe there is an error in SntiTranslateSglToPrp routine and it can be easily reproduced in non-quick drive format if the driver reports the size of LBA is 4096 bytes. The failing request I've seen is : 1. Reading LBA0 for one LBA. 2. Only one SG element included. 3. The starting physical address is not page-aligned, i.e., 0x1`12345600 In SntiTranslateSglToPrp, numImplicitEntries is assigned as 1 (Line 4238). After entering 2nd for loop (Line 4248), pSrbExt->numberofPrpEntries becomes 1 (Line 4253), which causes pPrp1 is programmed as localPrpEntry (Line 4256) and then jumps out of the for loop without programming pPrp2. However, pPrp2 should be programmed as 0x1`12346000 to transfer the rest of the page (0xa00 bytes). I am not sure why it works for us for such a long period. May be the different sizes of LBA, and 4096 is simply much easier to replicate the problem. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Monday, April 16, 2012 10:04 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work There's only a few changes here that need to be reviewed, mostly this is Chatham specific and, again, the only reason we're allowing these HW specific changes in the driver is because its currently the only HW vehicle available to Msft and to UNH who is working on some test suites. We have an updated version of Chatham which required a few changes but also identified a few issues in the driver that I think are critical enough that I wanted to get them in before we build the release: - We weren't handling the CC register correctly in a few places. Details are below, but this one is critical for new HW. - We were exposing LBA ranges that are identified by the controller as hidden - We weren't correctly handing the report_luns command for multiple luns - We weren't correctly checking status on init state machine completion handlers As usual, pw is ofanvme123 and the faster folks can check this out the faster we can build our first release J Thx Paul Sources: - New switch for chatham2, removed inclusion of chatham switch by default Nvmestd.h - Chatham stuff - Moved some NVME register defines to nvmereg.h - For DBG mode, changed the timeout state machine to something more reasonable (first it was too short, then too long) Nvmestd.c - Chatham stuff - Added readback of CC before we write it again (to toggle EN for initial reset). Without this some HW will surely fail to init correctly Nvmestat.c - Chatham stuff Nvmesnti.ch - Chatham stuff Nvmesnti.c - Changes to honor the ExposeNamespace field we learn from LBA ranges. Previously we were not hiding namespaces that were supposed to be hidden - Fixes to SntiTranslateReportLuns() for multiple LUNs we were incorrectly failing the call when the allocated buffer was too small, the correct handling is to fill out what we can and return the size we needed in the response and we'll get second call with the correctly sized buffer. Tested, of course, and it works as expected - Chatham stuff Nvmereg.h - Moved reg defines to here from the other .h file mentioned above Nveinit.c - In NVMeResetAdapter() we were clobbering the CC register, changed so we correctly read it, clear EN, and write it - In NVMeEnableAdapter() we were not fully setting up CC, added additional fields and deifnes - in NVMeSetFeaturesCompletion(), I mentioned this before I think, I updated LBA range completion handler to assume that an all zero response means that we should expose it, also added a check for what we should be looking for to see if >1 ns is available, the NLB field. Qemu I think is wrong with its LBA range response right now, once its fixed I'll update this to remove the zero check - chatham stuff - in NVMeInitCallback() added checks for status code type as well as status code, just the status code is not sufficient in all cases to determine success or not ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Tue Apr 17 10:15:30 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Tue, 17 Apr 2012 17:15:30 +0000 Subject: [nvmewin] potential issue with SntiTranslateSglToPrp Message-ID: <82C9F782B054C94B9FC04A331649C77A0B91C0@FMSMSX106.amr.corp.intel.com> OK, thanks. I'll digest this a bit later, or maybe Ray will. For now though I changed the subject line as your observation has nothing to do with the patch I have out for review. Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, April 16, 2012 5:09 PM To: Chang, Alex; Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work My typo the size of rest of the page should be 0x600 instead of 0xa00. ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, April 16, 2012 5:03 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work Hi Paul, I believe there is an error in SntiTranslateSglToPrp routine and it can be easily reproduced in non-quick drive format if the driver reports the size of LBA is 4096 bytes. The failing request I've seen is : 1. Reading LBA0 for one LBA. 2. Only one SG element included. 3. The starting physical address is not page-aligned, i.e., 0x1`12345600 In SntiTranslateSglToPrp, numImplicitEntries is assigned as 1 (Line 4238). After entering 2nd for loop (Line 4248), pSrbExt->numberofPrpEntries becomes 1 (Line 4253), which causes pPrp1 is programmed as localPrpEntry (Line 4256) and then jumps out of the for loop without programming pPrp2. However, pPrp2 should be programmed as 0x1`12346000 to transfer the rest of the page (0xa00 bytes). I am not sure why it works for us for such a long period. May be the different sizes of LBA, and 4096 is simply much easier to replicate the problem. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Monday, April 16, 2012 10:04 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work There's only a few changes here that need to be reviewed, mostly this is Chatham specific and, again, the only reason we're allowing these HW specific changes in the driver is because its currently the only HW vehicle available to Msft and to UNH who is working on some test suites. We have an updated version of Chatham which required a few changes but also identified a few issues in the driver that I think are critical enough that I wanted to get them in before we build the release: - We weren't handling the CC register correctly in a few places. Details are below, but this one is critical for new HW. - We were exposing LBA ranges that are identified by the controller as hidden - We weren't correctly handing the report_luns command for multiple luns - We weren't correctly checking status on init state machine completion handlers As usual, pw is ofanvme123 and the faster folks can check this out the faster we can build our first release J Thx Paul Sources: - New switch for chatham2, removed inclusion of chatham switch by default Nvmestd.h - Chatham stuff - Moved some NVME register defines to nvmereg.h - For DBG mode, changed the timeout state machine to something more reasonable (first it was too short, then too long) Nvmestd.c - Chatham stuff - Added readback of CC before we write it again (to toggle EN for initial reset). Without this some HW will surely fail to init correctly Nvmestat.c - Chatham stuff Nvmesnti.ch - Chatham stuff Nvmesnti.c - Changes to honor the ExposeNamespace field we learn from LBA ranges. Previously we were not hiding namespaces that were supposed to be hidden - Fixes to SntiTranslateReportLuns() for multiple LUNs we were incorrectly failing the call when the allocated buffer was too small, the correct handling is to fill out what we can and return the size we needed in the response and we'll get second call with the correctly sized buffer. Tested, of course, and it works as expected - Chatham stuff Nvmereg.h - Moved reg defines to here from the other .h file mentioned above Nveinit.c - In NVMeResetAdapter() we were clobbering the CC register, changed so we correctly read it, clear EN, and write it - In NVMeEnableAdapter() we were not fully setting up CC, added additional fields and deifnes - in NVMeSetFeaturesCompletion(), I mentioned this before I think, I updated LBA range completion handler to assume that an all zero response means that we should expose it, also added a check for what we should be looking for to see if >1 ns is available, the NLB field. Qemu I think is wrong with its LBA range response right now, once its fixed I'll update this to remove the zero check - chatham stuff - in NVMeInitCallback() added checks for status code type as well as status code, just the status code is not sufficient in all cases to determine success or not ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.c.robles at intel.com Tue Apr 17 14:14:12 2012 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Tue, 17 Apr 2012 21:14:12 +0000 Subject: [nvmewin] potential issue with SntiTranslateSglToPrp In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0B91C0@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A0B91C0@FMSMSX106.amr.corp.intel.com> Message-ID: <49158E750348AA499168FD41D88983600C38CDC1@FMSMSX105.amr.corp.intel.com> I'm reviewing this case you've brought up Alex. I'll send out a note in the next day or two. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Tuesday, April 17, 2012 10:16 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: [nvmewin] potential issue with SntiTranslateSglToPrp OK, thanks. I'll digest this a bit later, or maybe Ray will. For now though I changed the subject line as your observation has nothing to do with the patch I have out for review. Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, April 16, 2012 5:09 PM To: Chang, Alex; Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work My typo the size of rest of the page should be 0x600 instead of 0xa00. ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, April 16, 2012 5:03 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work Hi Paul, I believe there is an error in SntiTranslateSglToPrp routine and it can be easily reproduced in non-quick drive format if the driver reports the size of LBA is 4096 bytes. The failing request I've seen is : 1. Reading LBA0 for one LBA. 2. Only one SG element included. 3. The starting physical address is not page-aligned, i.e., 0x1`12345600 In SntiTranslateSglToPrp, numImplicitEntries is assigned as 1 (Line 4238). After entering 2nd for loop (Line 4248), pSrbExt->numberofPrpEntries becomes 1 (Line 4253), which causes pPrp1 is programmed as localPrpEntry (Line 4256) and then jumps out of the for loop without programming pPrp2. However, pPrp2 should be programmed as 0x1`12346000 to transfer the rest of the page (0xa00 bytes). I am not sure why it works for us for such a long period. May be the different sizes of LBA, and 4096 is simply much easier to replicate the problem. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Monday, April 16, 2012 10:04 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work There's only a few changes here that need to be reviewed, mostly this is Chatham specific and, again, the only reason we're allowing these HW specific changes in the driver is because its currently the only HW vehicle available to Msft and to UNH who is working on some test suites. We have an updated version of Chatham which required a few changes but also identified a few issues in the driver that I think are critical enough that I wanted to get them in before we build the release: - We weren't handling the CC register correctly in a few places. Details are below, but this one is critical for new HW. - We were exposing LBA ranges that are identified by the controller as hidden - We weren't correctly handing the report_luns command for multiple luns - We weren't correctly checking status on init state machine completion handlers As usual, pw is ofanvme123 and the faster folks can check this out the faster we can build our first release :) Thx Paul Sources: - New switch for chatham2, removed inclusion of chatham switch by default Nvmestd.h - Chatham stuff - Moved some NVME register defines to nvmereg.h - For DBG mode, changed the timeout state machine to something more reasonable (first it was too short, then too long) Nvmestd.c - Chatham stuff - Added readback of CC before we write it again (to toggle EN for initial reset). Without this some HW will surely fail to init correctly Nvmestat.c - Chatham stuff Nvmesnti.ch - Chatham stuff Nvmesnti.c - Changes to honor the ExposeNamespace field we learn from LBA ranges. Previously we were not hiding namespaces that were supposed to be hidden - Fixes to SntiTranslateReportLuns() for multiple LUNs we were incorrectly failing the call when the allocated buffer was too small, the correct handling is to fill out what we can and return the size we needed in the response and we'll get second call with the correctly sized buffer. Tested, of course, and it works as expected - Chatham stuff Nvmereg.h - Moved reg defines to here from the other .h file mentioned above Nveinit.c - In NVMeResetAdapter() we were clobbering the CC register, changed so we correctly read it, clear EN, and write it - In NVMeEnableAdapter() we were not fully setting up CC, added additional fields and deifnes - in NVMeSetFeaturesCompletion(), I mentioned this before I think, I updated LBA range completion handler to assume that an all zero response means that we should expose it, also added a check for what we should be looking for to see if >1 ns is available, the NLB field. Qemu I think is wrong with its LBA range response right now, once its fixed I'll update this to remove the zero check - chatham stuff - in NVMeInitCallback() added checks for status code type as well as status code, just the status code is not sufficient in all cases to determine success or not ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Tue Apr 17 14:23:45 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Tue, 17 Apr 2012 21:23:45 +0000 Subject: [nvmewin] potential issue with SntiTranslateSglToPrp In-Reply-To: <49158E750348AA499168FD41D88983600C38CDC1@FMSMSX105.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A0B91C0@FMSMSX106.amr.corp.intel.com> <49158E750348AA499168FD41D88983600C38CDC1@FMSMSX105.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D36FB54@corpmail1.na.ads.idt.com> Thanks a lot, Ray. Please feel free to let me know if you need any helps from me. Alex ________________________________ From: Robles, Raymond C [mailto:raymond.c.robles at intel.com] Sent: Tuesday, April 17, 2012 2:14 PM To: Luse, Paul E; Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] potential issue with SntiTranslateSglToPrp I'm reviewing this case you've brought up Alex. I'll send out a note in the next day or two. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Tuesday, April 17, 2012 10:16 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: [nvmewin] potential issue with SntiTranslateSglToPrp OK, thanks. I'll digest this a bit later, or maybe Ray will. For now though I changed the subject line as your observation has nothing to do with the patch I have out for review. Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, April 16, 2012 5:09 PM To: Chang, Alex; Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work My typo the size of rest of the page should be 0x600 instead of 0xa00. ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, April 16, 2012 5:03 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work Hi Paul, I believe there is an error in SntiTranslateSglToPrp routine and it can be easily reproduced in non-quick drive format if the driver reports the size of LBA is 4096 bytes. The failing request I've seen is : 1. Reading LBA0 for one LBA. 2. Only one SG element included. 3. The starting physical address is not page-aligned, i.e., 0x1`12345600 In SntiTranslateSglToPrp, numImplicitEntries is assigned as 1 (Line 4238). After entering 2nd for loop (Line 4248), pSrbExt->numberofPrpEntries becomes 1 (Line 4253), which causes pPrp1 is programmed as localPrpEntry (Line 4256) and then jumps out of the for loop without programming pPrp2. However, pPrp2 should be programmed as 0x1`12346000 to transfer the rest of the page (0xa00 bytes). I am not sure why it works for us for such a long period. May be the different sizes of LBA, and 4096 is simply much easier to replicate the problem. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Monday, April 16, 2012 10:04 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work There's only a few changes here that need to be reviewed, mostly this is Chatham specific and, again, the only reason we're allowing these HW specific changes in the driver is because its currently the only HW vehicle available to Msft and to UNH who is working on some test suites. We have an updated version of Chatham which required a few changes but also identified a few issues in the driver that I think are critical enough that I wanted to get them in before we build the release: - We weren't handling the CC register correctly in a few places. Details are below, but this one is critical for new HW. - We were exposing LBA ranges that are identified by the controller as hidden - We weren't correctly handing the report_luns command for multiple luns - We weren't correctly checking status on init state machine completion handlers As usual, pw is ofanvme123 and the faster folks can check this out the faster we can build our first release :) Thx Paul Sources: - New switch for chatham2, removed inclusion of chatham switch by default Nvmestd.h - Chatham stuff - Moved some NVME register defines to nvmereg.h - For DBG mode, changed the timeout state machine to something more reasonable (first it was too short, then too long) Nvmestd.c - Chatham stuff - Added readback of CC before we write it again (to toggle EN for initial reset). Without this some HW will surely fail to init correctly Nvmestat.c - Chatham stuff Nvmesnti.ch - Chatham stuff Nvmesnti.c - Changes to honor the ExposeNamespace field we learn from LBA ranges. Previously we were not hiding namespaces that were supposed to be hidden - Fixes to SntiTranslateReportLuns() for multiple LUNs we were incorrectly failing the call when the allocated buffer was too small, the correct handling is to fill out what we can and return the size we needed in the response and we'll get second call with the correctly sized buffer. Tested, of course, and it works as expected - Chatham stuff Nvmereg.h - Moved reg defines to here from the other .h file mentioned above Nveinit.c - In NVMeResetAdapter() we were clobbering the CC register, changed so we correctly read it, clear EN, and write it - In NVMeEnableAdapter() we were not fully setting up CC, added additional fields and deifnes - in NVMeSetFeaturesCompletion(), I mentioned this before I think, I updated LBA range completion handler to assume that an all zero response means that we should expose it, also added a check for what we should be looking for to see if >1 ns is available, the NLB field. Qemu I think is wrong with its LBA range response right now, once its fixed I'll update this to remove the zero check - chatham stuff - in NVMeInitCallback() added checks for status code type as well as status code, just the status code is not sufficient in all cases to determine success or not ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Wed Apr 18 08:07:25 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Wed, 18 Apr 2012 15:07:25 +0000 Subject: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work In-Reply-To: <548C5470AAD9DA4A85D259B663190D36FB03@corpmail1.na.ads.idt.com> References: <82C9F782B054C94B9FC04A331649C77A0B7ED8@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D36FAF3@corpmail1.na.ads.idt.com> <548C5470AAD9DA4A85D259B663190D36FB03@corpmail1.na.ads.idt.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0B9D86@FMSMSX106.amr.corp.intel.com> Alex, Where you state: In SntiTranslateSglToPrp, numImplicitEntries is assigned as 1 (Line 4238). I don't understand why numImplicitEntries doesn't become 2 with this: numImplicitEntries += (((sgElementSize % PAGE_SIZE) != 0) ? 1 : 0); since 0x1`12345600 mod 0x1000 = 0x600 What am I missing here? Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, April 16, 2012 5:09 PM To: Chang, Alex; Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work My typo the size of rest of the page should be 0x600 instead of 0xa00. ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, April 16, 2012 5:03 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work Hi Paul, I believe there is an error in SntiTranslateSglToPrp routine and it can be easily reproduced in non-quick drive format if the driver reports the size of LBA is 4096 bytes. The failing request I've seen is : 1. Reading LBA0 for one LBA. 2. Only one SG element included. 3. The starting physical address is not page-aligned, i.e., 0x1`12345600 In SntiTranslateSglToPrp, numImplicitEntries is assigned as 1 (Line 4238). After entering 2nd for loop (Line 4248), pSrbExt->numberofPrpEntries becomes 1 (Line 4253), which causes pPrp1 is programmed as localPrpEntry (Line 4256) and then jumps out of the for loop without programming pPrp2. However, pPrp2 should be programmed as 0x1`12346000 to transfer the rest of the page (0xa00 bytes). I am not sure why it works for us for such a long period. May be the different sizes of LBA, and 4096 is simply much easier to replicate the problem. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Monday, April 16, 2012 10:04 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work There's only a few changes here that need to be reviewed, mostly this is Chatham specific and, again, the only reason we're allowing these HW specific changes in the driver is because its currently the only HW vehicle available to Msft and to UNH who is working on some test suites. We have an updated version of Chatham which required a few changes but also identified a few issues in the driver that I think are critical enough that I wanted to get them in before we build the release: - We weren't handling the CC register correctly in a few places. Details are below, but this one is critical for new HW. - We were exposing LBA ranges that are identified by the controller as hidden - We weren't correctly handing the report_luns command for multiple luns - We weren't correctly checking status on init state machine completion handlers As usual, pw is ofanvme123 and the faster folks can check this out the faster we can build our first release J Thx Paul Sources: - New switch for chatham2, removed inclusion of chatham switch by default Nvmestd.h - Chatham stuff - Moved some NVME register defines to nvmereg.h - For DBG mode, changed the timeout state machine to something more reasonable (first it was too short, then too long) Nvmestd.c - Chatham stuff - Added readback of CC before we write it again (to toggle EN for initial reset). Without this some HW will surely fail to init correctly Nvmestat.c - Chatham stuff Nvmesnti.ch - Chatham stuff Nvmesnti.c - Changes to honor the ExposeNamespace field we learn from LBA ranges. Previously we were not hiding namespaces that were supposed to be hidden - Fixes to SntiTranslateReportLuns() for multiple LUNs we were incorrectly failing the call when the allocated buffer was too small, the correct handling is to fill out what we can and return the size we needed in the response and we'll get second call with the correctly sized buffer. Tested, of course, and it works as expected - Chatham stuff Nvmereg.h - Moved reg defines to here from the other .h file mentioned above Nveinit.c - In NVMeResetAdapter() we were clobbering the CC register, changed so we correctly read it, clear EN, and write it - In NVMeEnableAdapter() we were not fully setting up CC, added additional fields and deifnes - in NVMeSetFeaturesCompletion(), I mentioned this before I think, I updated LBA range completion handler to assume that an all zero response means that we should expose it, also added a check for what we should be looking for to see if >1 ns is available, the NLB field. Qemu I think is wrong with its LBA range response right now, once its fixed I'll update this to remove the zero check - chatham stuff - in NVMeInitCallback() added checks for status code type as well as status code, just the status code is not sufficient in all cases to determine success or not ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Wed Apr 18 08:18:22 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Wed, 18 Apr 2012 15:18:22 +0000 Subject: [nvmewin] SGL issue Message-ID: <82C9F782B054C94B9FC04A331649C77A0B9DDF@FMSMSX106.amr.corp.intel.com> Ugh, replied to the wrong email subject name again. Anyway, I think I see the issue here. I believe we intended the mod operation below should be done w/the address not the size... as I did in my example below and then I realized the code would have done that mod on 0x100 and gotten a 0 back. From: Luse, Paul E Sent: Wednesday, April 18, 2012 8:07 AM To: 'Chang, Alex'; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work Alex, Where you state: In SntiTranslateSglToPrp, numImplicitEntries is assigned as 1 (Line 4238). I don't understand why numImplicitEntries doesn't become 2 with this: numImplicitEntries += (((sgElementSize % PAGE_SIZE) != 0) ? 1 : 0); since 0x1`12345600 mod 0x1000 = 0x600 What am I missing here? Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, April 16, 2012 5:09 PM To: Chang, Alex; Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work My typo the size of rest of the page should be 0x600 instead of 0xa00. ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, April 16, 2012 5:03 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work Hi Paul, I believe there is an error in SntiTranslateSglToPrp routine and it can be easily reproduced in non-quick drive format if the driver reports the size of LBA is 4096 bytes. The failing request I've seen is : 1. Reading LBA0 for one LBA. 2. Only one SG element included. 3. The starting physical address is not page-aligned, i.e., 0x1`12345600 In SntiTranslateSglToPrp, numImplicitEntries is assigned as 1 (Line 4238). After entering 2nd for loop (Line 4248), pSrbExt->numberofPrpEntries becomes 1 (Line 4253), which causes pPrp1 is programmed as localPrpEntry (Line 4256) and then jumps out of the for loop without programming pPrp2. However, pPrp2 should be programmed as 0x1`12346000 to transfer the rest of the page (0xa00 bytes). I am not sure why it works for us for such a long period. May be the different sizes of LBA, and 4096 is simply much easier to replicate the problem. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Monday, April 16, 2012 10:04 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work There's only a few changes here that need to be reviewed, mostly this is Chatham specific and, again, the only reason we're allowing these HW specific changes in the driver is because its currently the only HW vehicle available to Msft and to UNH who is working on some test suites. We have an updated version of Chatham which required a few changes but also identified a few issues in the driver that I think are critical enough that I wanted to get them in before we build the release: - We weren't handling the CC register correctly in a few places. Details are below, but this one is critical for new HW. - We were exposing LBA ranges that are identified by the controller as hidden - We weren't correctly handing the report_luns command for multiple luns - We weren't correctly checking status on init state machine completion handlers As usual, pw is ofanvme123 and the faster folks can check this out the faster we can build our first release J Thx Paul Sources: - New switch for chatham2, removed inclusion of chatham switch by default Nvmestd.h - Chatham stuff - Moved some NVME register defines to nvmereg.h - For DBG mode, changed the timeout state machine to something more reasonable (first it was too short, then too long) Nvmestd.c - Chatham stuff - Added readback of CC before we write it again (to toggle EN for initial reset). Without this some HW will surely fail to init correctly Nvmestat.c - Chatham stuff Nvmesnti.ch - Chatham stuff Nvmesnti.c - Changes to honor the ExposeNamespace field we learn from LBA ranges. Previously we were not hiding namespaces that were supposed to be hidden - Fixes to SntiTranslateReportLuns() for multiple LUNs we were incorrectly failing the call when the allocated buffer was too small, the correct handling is to fill out what we can and return the size we needed in the response and we'll get second call with the correctly sized buffer. Tested, of course, and it works as expected - Chatham stuff Nvmereg.h - Moved reg defines to here from the other .h file mentioned above Nveinit.c - In NVMeResetAdapter() we were clobbering the CC register, changed so we correctly read it, clear EN, and write it - In NVMeEnableAdapter() we were not fully setting up CC, added additional fields and deifnes - in NVMeSetFeaturesCompletion(), I mentioned this before I think, I updated LBA range completion handler to assume that an all zero response means that we should expose it, also added a check for what we should be looking for to see if >1 ns is available, the NLB field. Qemu I think is wrong with its LBA range response right now, once its fixed I'll update this to remove the zero check - chatham stuff - in NVMeInitCallback() added checks for status code type as well as status code, just the status code is not sufficient in all cases to determine success or not ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Wed Apr 18 08:46:27 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Wed, 18 Apr 2012 15:46:27 +0000 Subject: [nvmewin] SGL issue In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0B9DDF@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A0B9DDF@FMSMSX106.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D36FBAA@corpmail1.na.ads.idt.com> In addition, the logic seems assuming numImplicitEntries as 1 when the size is less than or equal to PAGE_SIZE. Thanks, Alex ________________________________ From: Luse, Paul E [mailto:paul.e.luse at intel.com] Sent: Wednesday, April 18, 2012 8:18 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: SGL issue Ugh, replied to the wrong email subject name again. Anyway, I think I see the issue here. I believe we intended the mod operation below should be done w/the address not the size... as I did in my example below and then I realized the code would have done that mod on 0x100 and gotten a 0 back. From: Luse, Paul E Sent: Wednesday, April 18, 2012 8:07 AM To: 'Chang, Alex'; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work Alex, Where you state: In SntiTranslateSglToPrp, numImplicitEntries is assigned as 1 (Line 4238). I don't understand why numImplicitEntries doesn't become 2 with this: numImplicitEntries += (((sgElementSize % PAGE_SIZE) != 0) ? 1 : 0); since 0x1`12345600 mod 0x1000 = 0x600 What am I missing here? Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, April 16, 2012 5:09 PM To: Chang, Alex; Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work My typo the size of rest of the page should be 0x600 instead of 0xa00. ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, April 16, 2012 5:03 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work Hi Paul, I believe there is an error in SntiTranslateSglToPrp routine and it can be easily reproduced in non-quick drive format if the driver reports the size of LBA is 4096 bytes. The failing request I've seen is : 1. Reading LBA0 for one LBA. 2. Only one SG element included. 3. The starting physical address is not page-aligned, i.e., 0x1`12345600 In SntiTranslateSglToPrp, numImplicitEntries is assigned as 1 (Line 4238). After entering 2nd for loop (Line 4248), pSrbExt->numberofPrpEntries becomes 1 (Line 4253), which causes pPrp1 is programmed as localPrpEntry (Line 4256) and then jumps out of the for loop without programming pPrp2. However, pPrp2 should be programmed as 0x1`12346000 to transfer the rest of the page (0xa00 bytes). I am not sure why it works for us for such a long period. May be the different sizes of LBA, and 4096 is simply much easier to replicate the problem. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Monday, April 16, 2012 10:04 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work There's only a few changes here that need to be reviewed, mostly this is Chatham specific and, again, the only reason we're allowing these HW specific changes in the driver is because its currently the only HW vehicle available to Msft and to UNH who is working on some test suites. We have an updated version of Chatham which required a few changes but also identified a few issues in the driver that I think are critical enough that I wanted to get them in before we build the release: - We weren't handling the CC register correctly in a few places. Details are below, but this one is critical for new HW. - We were exposing LBA ranges that are identified by the controller as hidden - We weren't correctly handing the report_luns command for multiple luns - We weren't correctly checking status on init state machine completion handlers As usual, pw is ofanvme123 and the faster folks can check this out the faster we can build our first release J Thx Paul Sources: - New switch for chatham2, removed inclusion of chatham switch by default Nvmestd.h - Chatham stuff - Moved some NVME register defines to nvmereg.h - For DBG mode, changed the timeout state machine to something more reasonable (first it was too short, then too long) Nvmestd.c - Chatham stuff - Added readback of CC before we write it again (to toggle EN for initial reset). Without this some HW will surely fail to init correctly Nvmestat.c - Chatham stuff Nvmesnti.ch - Chatham stuff Nvmesnti.c - Changes to honor the ExposeNamespace field we learn from LBA ranges. Previously we were not hiding namespaces that were supposed to be hidden - Fixes to SntiTranslateReportLuns() for multiple LUNs we were incorrectly failing the call when the allocated buffer was too small, the correct handling is to fill out what we can and return the size we needed in the response and we'll get second call with the correctly sized buffer. Tested, of course, and it works as expected - Chatham stuff Nvmereg.h - Moved reg defines to here from the other .h file mentioned above Nveinit.c - In NVMeResetAdapter() we were clobbering the CC register, changed so we correctly read it, clear EN, and write it - In NVMeEnableAdapter() we were not fully setting up CC, added additional fields and deifnes - in NVMeSetFeaturesCompletion(), I mentioned this before I think, I updated LBA range completion handler to assume that an all zero response means that we should expose it, also added a check for what we should be looking for to see if >1 ns is available, the NLB field. Qemu I think is wrong with its LBA range response right now, once its fixed I'll update this to remove the zero check - chatham stuff - in NVMeInitCallback() added checks for status code type as well as status code, just the status code is not sufficient in all cases to determine success or not ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Wed Apr 18 09:09:30 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Wed, 18 Apr 2012 16:09:30 +0000 Subject: [nvmewin] SGL issue In-Reply-To: <548C5470AAD9DA4A85D259B663190D36FBAA@corpmail1.na.ads.idt.com> References: <82C9F782B054C94B9FC04A331649C77A0B9DDF@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D36FBAA@corpmail1.na.ads.idt.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0B9EDA@FMSMSX106.amr.corp.intel.com> Yep, I was just noticing that too., Testing fix for both issues now... I think this might be behind and occasional failure in quick format I see on our test HW that I never had a chance to track down.... From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Wednesday, April 18, 2012 8:46 AM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: SGL issue In addition, the logic seems assuming numImplicitEntries as 1 when the size is less than or equal to PAGE_SIZE. Thanks, Alex ________________________________ From: Luse, Paul E [mailto:paul.e.luse at intel.com] Sent: Wednesday, April 18, 2012 8:18 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: SGL issue Ugh, replied to the wrong email subject name again. Anyway, I think I see the issue here. I believe we intended the mod operation below should be done w/the address not the size... as I did in my example below and then I realized the code would have done that mod on 0x100 and gotten a 0 back. From: Luse, Paul E Sent: Wednesday, April 18, 2012 8:07 AM To: 'Chang, Alex'; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work Alex, Where you state: In SntiTranslateSglToPrp, numImplicitEntries is assigned as 1 (Line 4238). I don't understand why numImplicitEntries doesn't become 2 with this: numImplicitEntries += (((sgElementSize % PAGE_SIZE) != 0) ? 1 : 0); since 0x1`12345600 mod 0x1000 = 0x600 What am I missing here? Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Monday, April 16, 2012 5:09 PM To: Chang, Alex; Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work My typo the size of rest of the page should be 0x600 instead of 0xa00. ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex Sent: Monday, April 16, 2012 5:03 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work Hi Paul, I believe there is an error in SntiTranslateSglToPrp routine and it can be easily reproduced in non-quick drive format if the driver reports the size of LBA is 4096 bytes. The failing request I've seen is : 1. Reading LBA0 for one LBA. 2. Only one SG element included. 3. The starting physical address is not page-aligned, i.e., 0x1`12345600 In SntiTranslateSglToPrp, numImplicitEntries is assigned as 1 (Line 4238). After entering 2nd for loop (Line 4248), pSrbExt->numberofPrpEntries becomes 1 (Line 4253), which causes pPrp1 is programmed as localPrpEntry (Line 4256) and then jumps out of the for loop without programming pPrp2. However, pPrp2 should be programmed as 0x1`12346000 to transfer the rest of the page (0xa00 bytes). I am not sure why it works for us for such a long period. May be the different sizes of LBA, and 4096 is simply much easier to replicate the problem. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Monday, April 16, 2012 10:04 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** NEW patch for review based on some recent HW bring up work There's only a few changes here that need to be reviewed, mostly this is Chatham specific and, again, the only reason we're allowing these HW specific changes in the driver is because its currently the only HW vehicle available to Msft and to UNH who is working on some test suites. We have an updated version of Chatham which required a few changes but also identified a few issues in the driver that I think are critical enough that I wanted to get them in before we build the release: - We weren't handling the CC register correctly in a few places. Details are below, but this one is critical for new HW. - We were exposing LBA ranges that are identified by the controller as hidden - We weren't correctly handing the report_luns command for multiple luns - We weren't correctly checking status on init state machine completion handlers As usual, pw is ofanvme123 and the faster folks can check this out the faster we can build our first release J Thx Paul Sources: - New switch for chatham2, removed inclusion of chatham switch by default Nvmestd.h - Chatham stuff - Moved some NVME register defines to nvmereg.h - For DBG mode, changed the timeout state machine to something more reasonable (first it was too short, then too long) Nvmestd.c - Chatham stuff - Added readback of CC before we write it again (to toggle EN for initial reset). Without this some HW will surely fail to init correctly Nvmestat.c - Chatham stuff Nvmesnti.ch - Chatham stuff Nvmesnti.c - Changes to honor the ExposeNamespace field we learn from LBA ranges. Previously we were not hiding namespaces that were supposed to be hidden - Fixes to SntiTranslateReportLuns() for multiple LUNs we were incorrectly failing the call when the allocated buffer was too small, the correct handling is to fill out what we can and return the size we needed in the response and we'll get second call with the correctly sized buffer. Tested, of course, and it works as expected - Chatham stuff Nvmereg.h - Moved reg defines to here from the other .h file mentioned above Nveinit.c - In NVMeResetAdapter() we were clobbering the CC register, changed so we correctly read it, clear EN, and write it - In NVMeEnableAdapter() we were not fully setting up CC, added additional fields and deifnes - in NVMeSetFeaturesCompletion(), I mentioned this before I think, I updated LBA range completion handler to assume that an all zero response means that we should expose it, also added a check for what we should be looking for to see if >1 ns is available, the NLB field. Qemu I think is wrong with its LBA range response right now, once its fixed I'll update this to remove the zero check - chatham stuff - in NVMeInitCallback() added checks for status code type as well as status code, just the status code is not sufficient in all cases to determine success or not ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrandall at micron.com Wed Apr 18 10:05:54 2012 From: rrandall at micron.com (Robert Randall (rrandall)) Date: Wed, 18 Apr 2012 17:05:54 +0000 Subject: [nvmewin] open source license model Message-ID: <70C73440F9F7C24F81A11355C292A9B5715BBE7C@NTXBOIMBX04.micron.com> ALL: I can't seem to find a clear description of the license model that applies to the nvme windows driver. Can someone point me at the correct document or web page? Perhaps there isn't a license and only the copyright notices apply? Best regards, Robert. Robert Randall Senior Software Architect Micron Technologies, Inc. 3001 Broadway St NE Minneapolis, MN 55413-2657 desk: 612.884.2592 mobile: 612.770.9612 rrandall at micron.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.p.freyensee at intel.com Wed Apr 18 10:16:45 2012 From: james.p.freyensee at intel.com (Freyensee, James P) Date: Wed, 18 Apr 2012 17:16:45 +0000 Subject: [nvmewin] open source license model In-Reply-To: <70C73440F9F7C24F81A11355C292A9B5715BBE7C@NTXBOIMBX04.micron.com> References: <70C73440F9F7C24F81A11355C292A9B5715BBE7C@NTXBOIMBX04.micron.com> Message-ID: <2D98093777D3FD46A36253F35FE9D693452AEF60@ORSMSX102.amr.corp.intel.com> >From reading the file header comments of the .c and .h files, it appears it is a BSD license. From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robert Randall (rrandall) Sent: Wednesday, April 18, 2012 10:06 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] open source license model ALL: I can't seem to find a clear description of the license model that applies to the nvme windows driver. Can someone point me at the correct document or web page? Perhaps there isn't a license and only the copyright notices apply? Best regards, Robert. Robert Randall Senior Software Architect Micron Technologies, Inc. 3001 Broadway St NE Minneapolis, MN 55413-2657 desk: 612.884.2592 mobile: 612.770.9612 rrandall at micron.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Wed Apr 18 10:56:22 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Wed, 18 Apr 2012 17:56:22 +0000 Subject: [nvmewin] open source license model In-Reply-To: <2D98093777D3FD46A36253F35FE9D693452AEF60@ORSMSX102.amr.corp.intel.com> References: <70C73440F9F7C24F81A11355C292A9B5715BBE7C@NTXBOIMBX04.micron.com> <2D98093777D3FD46A36253F35FE9D693452AEF60@ORSMSX102.amr.corp.intel.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0BA595@FMSMSX106.amr.corp.intel.com> That's correct From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P Sent: Wednesday, April 18, 2012 10:17 AM To: Robert Randall (rrandall); nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] open source license model >From reading the file header comments of the .c and .h files, it appears it is a BSD license. From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robert Randall (rrandall) Sent: Wednesday, April 18, 2012 10:06 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] open source license model ALL: I can't seem to find a clear description of the license model that applies to the nvme windows driver. Can someone point me at the correct document or web page? Perhaps there isn't a license and only the copyright notices apply? Best regards, Robert. Robert Randall Senior Software Architect Micron Technologies, Inc. 3001 Broadway St NE Minneapolis, MN 55413-2657 desk: 612.884.2592 mobile: 612.770.9612 rrandall at micron.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrandall at micron.com Wed Apr 18 12:36:46 2012 From: rrandall at micron.com (Robert Randall (rrandall)) Date: Wed, 18 Apr 2012 19:36:46 +0000 Subject: [nvmewin] open source license model In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0BA595@FMSMSX106.amr.corp.intel.com> References: <70C73440F9F7C24F81A11355C292A9B5715BBE7C@NTXBOIMBX04.micron.com> <2D98093777D3FD46A36253F35FE9D693452AEF60@ORSMSX102.amr.corp.intel.com> <82C9F782B054C94B9FC04A331649C77A0BA595@FMSMSX106.amr.corp.intel.com> Message-ID: <70C73440F9F7C24F81A11355C292A9B5715BCF29@NTXBOIMBX04.micron.com> Is this stated on the website someplace? We would like to participate but I have to get our legal department to approve of our participation before we can begin. They (legal) needs something more official than comments in the source code. I can't explain why . From: Luse, Paul E [mailto:paul.e.luse at intel.com] Sent: Wednesday, April 18, 2012 12:56 PM To: Freyensee, James P; Robert Randall (rrandall); nvmewin at lists.openfabrics.org Subject: RE: open source license model That's correct From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P Sent: Wednesday, April 18, 2012 10:17 AM To: Robert Randall (rrandall); nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] open source license model >From reading the file header comments of the .c and .h files, it appears it is a BSD license. From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robert Randall (rrandall) Sent: Wednesday, April 18, 2012 10:06 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] open source license model ALL: I can't seem to find a clear description of the license model that applies to the nvme windows driver. Can someone point me at the correct document or web page? Perhaps there isn't a license and only the copyright notices apply? Best regards, Robert. Robert Randall Senior Software Architect Micron Technologies, Inc. 3001 Broadway St NE Minneapolis, MN 55413-2657 desk: 612.884.2592 mobile: 612.770.9612 rrandall at micron.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Wed Apr 18 12:40:25 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Wed, 18 Apr 2012 19:40:25 +0000 Subject: [nvmewin] open source license model In-Reply-To: <70C73440F9F7C24F81A11355C292A9B5715BCF29@NTXBOIMBX04.micron.com> References: <70C73440F9F7C24F81A11355C292A9B5715BBE7C@NTXBOIMBX04.micron.com> <2D98093777D3FD46A36253F35FE9D693452AEF60@ORSMSX102.amr.corp.intel.com> <82C9F782B054C94B9FC04A331649C77A0BA595@FMSMSX106.amr.corp.intel.com> <70C73440F9F7C24F81A11355C292A9B5715BCF29@NTXBOIMBX04.micron.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0BA86F@FMSMSX106.amr.corp.intel.com> Hehe, I think it'd be the way around and they'd only care about what's in the code and not what's published on some webpage somewhere. Its not on the website but I cn ask to have it added, may take a few days though Thx Paul From: Robert Randall (rrandall) [mailto:rrandall at micron.com] Sent: Wednesday, April 18, 2012 12:37 PM To: Luse, Paul E; Freyensee, James P; nvmewin at lists.openfabrics.org Subject: RE: open source license model Is this stated on the website someplace? We would like to participate but I have to get our legal department to approve of our participation before we can begin. They (legal) needs something more official than comments in the source code. I can't explain why . From: Luse, Paul E [mailto:paul.e.luse at intel.com] Sent: Wednesday, April 18, 2012 12:56 PM To: Freyensee, James P; Robert Randall (rrandall); nvmewin at lists.openfabrics.org Subject: RE: open source license model That's correct From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P Sent: Wednesday, April 18, 2012 10:17 AM To: Robert Randall (rrandall); nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] open source license model >From reading the file header comments of the .c and .h files, it appears it is a BSD license. From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robert Randall (rrandall) Sent: Wednesday, April 18, 2012 10:06 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] open source license model ALL: I can't seem to find a clear description of the license model that applies to the nvme windows driver. Can someone point me at the correct document or web page? Perhaps there isn't a license and only the copyright notices apply? Best regards, Robert. Robert Randall Senior Software Architect Micron Technologies, Inc. 3001 Broadway St NE Minneapolis, MN 55413-2657 desk: 612.884.2592 mobile: 612.770.9612 rrandall at micron.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.p.freyensee at intel.com Wed Apr 18 12:42:12 2012 From: james.p.freyensee at intel.com (Freyensee, James P) Date: Wed, 18 Apr 2012 19:42:12 +0000 Subject: [nvmewin] open source license model In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0BA86F@FMSMSX106.amr.corp.intel.com> References: <70C73440F9F7C24F81A11355C292A9B5715BBE7C@NTXBOIMBX04.micron.com> <2D98093777D3FD46A36253F35FE9D693452AEF60@ORSMSX102.amr.corp.intel.com> <82C9F782B054C94B9FC04A331649C77A0BA595@FMSMSX106.amr.corp.intel.com> <70C73440F9F7C24F81A11355C292A9B5715BCF29@NTXBOIMBX04.micron.com> <82C9F782B054C94B9FC04A331649C77A0BA86F@FMSMSX106.amr.corp.intel.com> Message-ID: <2D98093777D3FD46A36253F35FE9D693452AF02B@ORSMSX102.amr.corp.intel.com> Dido...I would think license headers in the files explicitly saying what the person can-and-can-not-do would be way more official and legal than some website stating what that license is...seems to work for the Linux Kernel... From: Luse, Paul E Sent: Wednesday, April 18, 2012 12:40 PM To: Robert Randall (rrandall); Freyensee, James P; nvmewin at lists.openfabrics.org Subject: RE: open source license model Hehe, I think it'd be the way around and they'd only care about what's in the code and not what's published on some webpage somewhere. Its not on the website but I cn ask to have it added, may take a few days though Thx Paul From: Robert Randall (rrandall) [mailto:rrandall at micron.com] Sent: Wednesday, April 18, 2012 12:37 PM To: Luse, Paul E; Freyensee, James P; nvmewin at lists.openfabrics.org Subject: RE: open source license model Is this stated on the website someplace? We would like to participate but I have to get our legal department to approve of our participation before we can begin. They (legal) needs something more official than comments in the source code. I can't explain why . From: Luse, Paul E [mailto:paul.e.luse at intel.com] Sent: Wednesday, April 18, 2012 12:56 PM To: Freyensee, James P; Robert Randall (rrandall); nvmewin at lists.openfabrics.org Subject: RE: open source license model That's correct From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P Sent: Wednesday, April 18, 2012 10:17 AM To: Robert Randall (rrandall); nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] open source license model >From reading the file header comments of the .c and .h files, it appears it is a BSD license. From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robert Randall (rrandall) Sent: Wednesday, April 18, 2012 10:06 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] open source license model ALL: I can't seem to find a clear description of the license model that applies to the nvme windows driver. Can someone point me at the correct document or web page? Perhaps there isn't a license and only the copyright notices apply? Best regards, Robert. Robert Randall Senior Software Architect Micron Technologies, Inc. 3001 Broadway St NE Minneapolis, MN 55413-2657 desk: 612.884.2592 mobile: 612.770.9612 rrandall at micron.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Wed Apr 18 12:42:50 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Wed, 18 Apr 2012 19:42:50 +0000 Subject: [nvmewin] SGL bug update Message-ID: <82C9F782B054C94B9FC04A331649C77A0BA8A2@FMSMSX106.amr.corp.intel.com> So Alex- I'm with you - hard to believe this ever worked! I talked with Ray about it and both recall we caught this in inspection but somehow never got back to reworking it because at the time I think we ad bigger fish to fry. Anyway, I have a fix in place and my quick format always works now (before was intermittent) and I confirmed that the case we didn't handle indeed happens quite often. I think the data integrity tools we smoke test with don't do too many unaligned things. I'm doing some more exhaustive testing now and will share the updated code once I'm confident that it works. Thx Paul ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrandall at micron.com Wed Apr 18 12:43:36 2012 From: rrandall at micron.com (Robert Randall (rrandall)) Date: Wed, 18 Apr 2012 19:43:36 +0000 Subject: [nvmewin] open source license model In-Reply-To: <2D98093777D3FD46A36253F35FE9D693452AF02B@ORSMSX102.amr.corp.intel.com> References: <70C73440F9F7C24F81A11355C292A9B5715BBE7C@NTXBOIMBX04.micron.com> <2D98093777D3FD46A36253F35FE9D693452AEF60@ORSMSX102.amr.corp.intel.com> <82C9F782B054C94B9FC04A331649C77A0BA595@FMSMSX106.amr.corp.intel.com> <70C73440F9F7C24F81A11355C292A9B5715BCF29@NTXBOIMBX04.micron.com> <82C9F782B054C94B9FC04A331649C77A0BA86F@FMSMSX106.amr.corp.intel.com> <2D98093777D3FD46A36253F35FE9D693452AF02B@ORSMSX102.amr.corp.intel.com> Message-ID: <70C73440F9F7C24F81A11355C292A9B5715BCF47@NTXBOIMBX04.micron.com> I'll try again and see what happens. Our legal folks are a bit new to software . From: Freyensee, James P [mailto:james.p.freyensee at intel.com] Sent: Wednesday, April 18, 2012 2:42 PM To: Luse, Paul E; Robert Randall (rrandall); nvmewin at lists.openfabrics.org Subject: RE: open source license model Dido...I would think license headers in the files explicitly saying what the person can-and-can-not-do would be way more official and legal than some website stating what that license is...seems to work for the Linux Kernel... From: Luse, Paul E Sent: Wednesday, April 18, 2012 12:40 PM To: Robert Randall (rrandall); Freyensee, James P; nvmewin at lists.openfabrics.org Subject: RE: open source license model Hehe, I think it'd be the way around and they'd only care about what's in the code and not what's published on some webpage somewhere. Its not on the website but I cn ask to have it added, may take a few days though Thx Paul From: Robert Randall (rrandall) [mailto:rrandall at micron.com] Sent: Wednesday, April 18, 2012 12:37 PM To: Luse, Paul E; Freyensee, James P; nvmewin at lists.openfabrics.org Subject: RE: open source license model Is this stated on the website someplace? We would like to participate but I have to get our legal department to approve of our participation before we can begin. They (legal) needs something more official than comments in the source code. I can't explain why . From: Luse, Paul E [mailto:paul.e.luse at intel.com] Sent: Wednesday, April 18, 2012 12:56 PM To: Freyensee, James P; Robert Randall (rrandall); nvmewin at lists.openfabrics.org Subject: RE: open source license model That's correct From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P Sent: Wednesday, April 18, 2012 10:17 AM To: Robert Randall (rrandall); nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] open source license model >From reading the file header comments of the .c and .h files, it appears it is a BSD license. From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robert Randall (rrandall) Sent: Wednesday, April 18, 2012 10:06 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] open source license model ALL: I can't seem to find a clear description of the license model that applies to the nvme windows driver. Can someone point me at the correct document or web page? Perhaps there isn't a license and only the copyright notices apply? Best regards, Robert. Robert Randall Senior Software Architect Micron Technologies, Inc. 3001 Broadway St NE Minneapolis, MN 55413-2657 desk: 612.884.2592 mobile: 612.770.9612 rrandall at micron.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken at kenstrandberg.com Wed Apr 18 13:13:45 2012 From: ken at kenstrandberg.com (Ken Strandberg) Date: Wed, 18 Apr 2012 13:13:45 -0700 Subject: [nvmewin] open source license model In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0BA86F@FMSMSX106.amr.corp.intel.com> References: <70C73440F9F7C24F81A11355C292A9B5715BBE7C@NTXBOIMBX04.micron.com> <2D98093777D3FD46A36253F35FE9D693452AEF60@ORSMSX102.amr.corp.intel.com> <82C9F782B054C94B9FC04A331649C77A0BA595@FMSMSX106.amr.corp.intel.com> <70C73440F9F7C24F81A11355C292A9B5715BCF29@NTXBOIMBX04.micron.com> <82C9F782B054C94B9FC04A331649C77A0BA86F@FMSMSX106.amr.corp.intel.com> Message-ID: Not sure if this applies, but there are licenses for OFED on Linux on the web site under the Linux download page. Jim/Bill would probably have a much better idea. On Wed, Apr 18, 2012 at 12:40 PM, Luse, Paul E wrote: > Hehe, I think it’d be the way around and they’d only care about what’s > in the code and not what’s published on some webpage somewhere. Its not > on the website but I cn ask to have it added, may take a few days though** > ** > > ** ** > > Thx**** > > Paul**** > > ** ** > > *From:* Robert Randall (rrandall) [mailto:rrandall at micron.com] > *Sent:* Wednesday, April 18, 2012 12:37 PM > *To:* Luse, Paul E; Freyensee, James P; nvmewin at lists.openfabrics.org > *Subject:* RE: open source license model**** > > ** ** > > Is this stated on the website someplace? We would like to participate but > I have to get our legal department to approve of our participation before > we can begin. They (legal) needs something more official than comments in > the source code. I can’t explain why .**** > > ** ** > > *From:* Luse, Paul E [mailto:paul.e.luse at intel.com] > *Sent:* Wednesday, April 18, 2012 12:56 PM > *To:* Freyensee, James P; Robert Randall (rrandall); > nvmewin at lists.openfabrics.org > *Subject:* RE: open source license model**** > > ** ** > > That’s correct**** > > ** ** > > *From:* nvmewin-bounces at lists.openfabrics.org [ > mailto:nvmewin-bounces at lists.openfabrics.org] > *On Behalf Of *Freyensee, James P > *Sent:* Wednesday, April 18, 2012 10:17 AM > *To:* Robert Randall (rrandall); nvmewin at lists.openfabrics.org > *Subject:* Re: [nvmewin] open source license model**** > > ** ** > > From reading the file header comments of the .c and .h files, it appears > it is a BSD license.**** > > ** ** > > ** ** > > *From:* nvmewin-bounces at lists.openfabrics.org > [mailto:nvmewin-bounces at lists.openfabrics.org] *On Behalf Of *Robert > Randall (rrandall) > *Sent:* Wednesday, April 18, 2012 10:06 AM > *To:* nvmewin at lists.openfabrics.org > *Subject:* [nvmewin] open source license model**** > > ** ** > > ALL:**** > > ** ** > > I can’t seem to find a clear description of the license model that applies > to the nvme windows driver. Can someone point me at the correct document > or web page? Perhaps there isn’t a license and only the copyright notices > apply?**** > > ** ** > > Best regards,**** > > Robert.**** > > ** ** > > ** ** > > Robert Randall**** > > Senior Software Architect**** > > Micron Technologies, Inc.**** > > 3001 Broadway St NE**** > > Minneapolis, MN 55413-2657**** > > desk: 612.884.2592**** > > mobile: 612.770.9612**** > > rrandall at micron.com**** > > ** ** > > ** ** > > _______________________________________________ > nvmewin mailing list > nvmewin at lists.openfabrics.org > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin > > -- *Ken Strandberg* 775.690.6575 ken at kenstrandberg.com www.kenstrandberg.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Wed Apr 18 15:03:58 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Wed, 18 Apr 2012 22:03:58 +0000 Subject: [nvmewin] SGL bug update In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0BA8A2@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A0BA8A2@FMSMSX106.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D36FC85@corpmail1.na.ads.idt.com> Thanks a lot, Paul. I recall there were at least couple of changes for the translation after code review. And you and Ray did some changes on it. We just need to ensure it gets tested with all different cases. Regards, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Wednesday, April 18, 2012 12:43 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] SGL bug update So Alex- I'm with you - hard to believe this ever worked! I talked with Ray about it and both recall we caught this in inspection but somehow never got back to reworking it because at the time I think we ad bigger fish to fry. Anyway, I have a fix in place and my quick format always works now (before was intermittent) and I confirmed that the case we didn't handle indeed happens quite often. I think the data integrity tools we smoke test with don't do too many unaligned things. I'm doing some more exhaustive testing now and will share the updated code once I'm confident that it works. Thx Paul ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Wed Apr 18 15:09:50 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Wed, 18 Apr 2012 22:09:50 +0000 Subject: [nvmewin] SGL bug update In-Reply-To: <548C5470AAD9DA4A85D259B663190D36FC85@corpmail1.na.ads.idt.com> References: <82C9F782B054C94B9FC04A331649C77A0BA8A2@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D36FC85@corpmail1.na.ads.idt.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0BAC65@FMSMSX106.amr.corp.intel.com> Here's what I'm testing now. Changes are only to the element < page_size case, I was mistaken with where I thought I saw the issue before, that code was correct. I'm running various other data integrity tools and now all formats work, before some quick formats didn't work right and I've already confirmed that this was definitely due to the bug. What I do below, please anyone chime in if you know a better way, is determine the starting address of the next page and then add the address we're dealing and the element size and if its > the address of the next page then I bump up the number of required PRP entries by 1. Thx Paul physicalAddress.QuadPart = pSgl->List[index].PhysicalAddress.QuadPart; if (sgElementSize <= PAGE_SIZE) { ULONG nextPage = 0; /* Must transfer at least one full page */ numImplicitEntries = 1; /* * since we may be offset into the page, look to determine * address to determine if a 2nd PRP entry is needed */ nextPage = physicalAddress.LowPart + PAGE_SIZE; nextPage = nextPage & ~PAGE_MASK; numImplicitEntries += ((physicalAddress.LowPart + sgElementSize) > nextPage) ? 1 : 0; } else { numImplicitEntries = (sgElementSize / PAGE_SIZE); /* Check to see if there is residual data past a page boundary */ numImplicitEntries += ((sgElementSize % PAGE_SIZE) != 0) ? 1 : 0; } From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Wednesday, April 18, 2012 3:04 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: SGL bug update Thanks a lot, Paul. I recall there were at least couple of changes for the translation after code review. And you and Ray did some changes on it. We just need to ensure it gets tested with all different cases. Regards, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Wednesday, April 18, 2012 12:43 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] SGL bug update So Alex- I'm with you - hard to believe this ever worked! I talked with Ray about it and both recall we caught this in inspection but somehow never got back to reworking it because at the time I think we ad bigger fish to fry. Anyway, I have a fix in place and my quick format always works now (before was intermittent) and I confirmed that the case we didn't handle indeed happens quite often. I think the data integrity tools we smoke test with don't do too many unaligned things. I'm doing some more exhaustive testing now and will share the updated code once I'm confident that it works. Thx Paul ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.c.robles at intel.com Wed Apr 18 15:24:27 2012 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Wed, 18 Apr 2012 22:24:27 +0000 Subject: [nvmewin] SGL bug update In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0BAC65@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A0BA8A2@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D36FC85@corpmail1.na.ads.idt.com> <82C9F782B054C94B9FC04A331649C77A0BAC65@FMSMSX106.amr.corp.intel.com> Message-ID: <49158E750348AA499168FD41D88983600C38D5F4@FMSMSX105.amr.corp.intel.com> I've reviewed Paul's change and I believe that it addresses the issue that Alex brought up. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Wednesday, April 18, 2012 3:10 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] SGL bug update Here's what I'm testing now. Changes are only to the element < page_size case, I was mistaken with where I thought I saw the issue before, that code was correct. I'm running various other data integrity tools and now all formats work, before some quick formats didn't work right and I've already confirmed that this was definitely due to the bug. What I do below, please anyone chime in if you know a better way, is determine the starting address of the next page and then add the address we're dealing and the element size and if its > the address of the next page then I bump up the number of required PRP entries by 1. Thx Paul physicalAddress.QuadPart = pSgl->List[index].PhysicalAddress.QuadPart; if (sgElementSize <= PAGE_SIZE) { ULONG nextPage = 0; /* Must transfer at least one full page */ numImplicitEntries = 1; /* * since we may be offset into the page, look to determine * address to determine if a 2nd PRP entry is needed */ nextPage = physicalAddress.LowPart + PAGE_SIZE; nextPage = nextPage & ~PAGE_MASK; numImplicitEntries += ((physicalAddress.LowPart + sgElementSize) > nextPage) ? 1 : 0; } else { numImplicitEntries = (sgElementSize / PAGE_SIZE); /* Check to see if there is residual data past a page boundary */ numImplicitEntries += ((sgElementSize % PAGE_SIZE) != 0) ? 1 : 0; } From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Wednesday, April 18, 2012 3:04 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: SGL bug update Thanks a lot, Paul. I recall there were at least couple of changes for the translation after code review. And you and Ray did some changes on it. We just need to ensure it gets tested with all different cases. Regards, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Wednesday, April 18, 2012 12:43 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] SGL bug update So Alex- I'm with you - hard to believe this ever worked! I talked with Ray about it and both recall we caught this in inspection but somehow never got back to reworking it because at the time I think we ad bigger fish to fry. Anyway, I have a fix in place and my quick format always works now (before was intermittent) and I confirmed that the case we didn't handle indeed happens quite often. I think the data integrity tools we smoke test with don't do too many unaligned things. I'm doing some more exhaustive testing now and will share the updated code once I'm confident that it works. Thx Paul ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Wed Apr 18 15:50:01 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Wed, 18 Apr 2012 22:50:01 +0000 Subject: [nvmewin] SGL bug update In-Reply-To: <49158E750348AA499168FD41D88983600C38D5F4@FMSMSX105.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A0BA8A2@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D36FC85@corpmail1.na.ads.idt.com> <82C9F782B054C94B9FC04A331649C77A0BAC65@FMSMSX106.amr.corp.intel.com> <49158E750348AA499168FD41D88983600C38D5F4@FMSMSX105.amr.corp.intel.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0BADA5@FMSMSX106.amr.corp.intel.com> Actually Jim Harris pointed out another issue in the else case below, we don't handle a 'tail' there either. I'll send another update tomorrow with that included as well.... From: Robles, Raymond C Sent: Wednesday, April 18, 2012 3:24 PM To: Luse, Paul E; Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: SGL bug update I've reviewed Paul's change and I believe that it addresses the issue that Alex brought up. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Wednesday, April 18, 2012 3:10 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] SGL bug update Here's what I'm testing now. Changes are only to the element < page_size case, I was mistaken with where I thought I saw the issue before, that code was correct. I'm running various other data integrity tools and now all formats work, before some quick formats didn't work right and I've already confirmed that this was definitely due to the bug. What I do below, please anyone chime in if you know a better way, is determine the starting address of the next page and then add the address we're dealing and the element size and if its > the address of the next page then I bump up the number of required PRP entries by 1. Thx Paul physicalAddress.QuadPart = pSgl->List[index].PhysicalAddress.QuadPart; if (sgElementSize <= PAGE_SIZE) { ULONG nextPage = 0; /* Must transfer at least one full page */ numImplicitEntries = 1; /* * since we may be offset into the page, look to determine * address to determine if a 2nd PRP entry is needed */ nextPage = physicalAddress.LowPart + PAGE_SIZE; nextPage = nextPage & ~PAGE_MASK; numImplicitEntries += ((physicalAddress.LowPart + sgElementSize) > nextPage) ? 1 : 0; } else { numImplicitEntries = (sgElementSize / PAGE_SIZE); /* Check to see if there is residual data past a page boundary */ numImplicitEntries += ((sgElementSize % PAGE_SIZE) != 0) ? 1 : 0; } From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Wednesday, April 18, 2012 3:04 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: SGL bug update Thanks a lot, Paul. I recall there were at least couple of changes for the translation after code review. And you and Ray did some changes on it. We just need to ensure it gets tested with all different cases. Regards, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Wednesday, April 18, 2012 12:43 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] SGL bug update So Alex- I'm with you - hard to believe this ever worked! I talked with Ray about it and both recall we caught this in inspection but somehow never got back to reworking it because at the time I think we ad bigger fish to fry. Anyway, I have a fix in place and my quick format always works now (before was intermittent) and I confirmed that the case we didn't handle indeed happens quite often. I think the data integrity tools we smoke test with don't do too many unaligned things. I'm doing some more exhaustive testing now and will share the updated code once I'm confident that it works. Thx Paul ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Wed Apr 18 17:43:02 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Thu, 19 Apr 2012 00:43:02 +0000 Subject: [nvmewin] updated SGL conversion routine Message-ID: <82C9F782B054C94B9FC04A331649C77A0BAFC5@FMSMSX106.amr.corp.intel.com> OK, the else has now been updated (thanks Jim, needed some tweaks though but I saw what you were going for of course). There's so many way to handle this problem, I'm sure we can find something more efficient than this but its pretty good I think and easy to follow. Please review, I have this under test now and am heading out.... Thx Paul physicalAddress.QuadPart = pSgl->List[index].PhysicalAddress.QuadPart; if (sgElementSize <= PAGE_SIZE) { ULONG nextPage = 0; /* Must transfer at least one full page */ numImplicitEntries = 1; /* * since we may be offset into the page, look to determine * address to determine if a 2nd PRP entry is needed */ nextPage = physicalAddress.LowPart + PAGE_SIZE; nextPage = nextPage & ~PAGE_MASK; numImplicitEntries += ((physicalAddress.LowPart + sgElementSize) > nextPage) ? 1 : 0; } else { PHYSICAL_ADDRESS startAddr, endAddr; startAddr.QuadPart = physicalAddress.QuadPart; endAddr.QuadPart = startAddr.QuadPart + sgElementSize; numImplicitEntries = 0; /* account for an entry becaue of an offset start */ if (startAddr.QuadPart % PAGE_SIZE) { numImplicitEntries += 1; /* bump the start address to the next page boundary */ startAddr.QuadPart += PAGE_SIZE; startAddr.QuadPart &= ~PAGE_MASK; } /* account for an entry becaue of tail */ if (endAddr.QuadPart % PAGE_SIZE) { numImplicitEntries += 1; /* lop off the tail */ endAddr.QuadPart &= ~PAGE_MASK; } /* now account for the whole pages if any */ numImplicitEntries += (ULONG)((endAddr.QuadPart - startAddr.QuadPart) / PAGE_SIZE); } ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: nvmeSnti.c URL: From james.r.harris at intel.com Wed Apr 18 17:46:59 2012 From: james.r.harris at intel.com (Harris, James R) Date: Thu, 19 Apr 2012 00:46:59 +0000 Subject: [nvmewin] nvmewin Digest, Vol 4, Issue 27 In-Reply-To: References: Message-ID: You shouldn't need the "if" part here. The "else" part will handle the "less than PAGE_SIZE" case. -Jim >-----Original Message----- >From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On >Behalf Of nvmewin-request at lists.openfabrics.org >Sent: Wednesday, April 18, 2012 5:55 PM >To: nvmewin at lists.openfabrics.org >Subject: nvmewin Digest, Vol 4, Issue 27 > >Send nvmewin mailing list submissions to > nvmewin at lists.openfabrics.org > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin >or, via email, send a message with subject or body 'help' to > nvmewin-request at lists.openfabrics.org > >You can reach the person managing the list at > nvmewin-owner at lists.openfabrics.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of nvmewin digest..." > > >Today's Topics: > > 1. updated SGL conversion routine (Luse, Paul E) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 19 Apr 2012 00:43:02 +0000 >From: "Luse, Paul E" >To: "nvmewin at lists.openfabrics.org" >Subject: [nvmewin] updated SGL conversion routine >Message-ID: > <82C9F782B054C94B9FC04A331649C77A0BAFC5 at FMSMSX106.amr.corp.intel.com> >Content-Type: text/plain; charset="us-ascii" > >OK, the else has now been updated (thanks Jim, needed some tweaks though but I saw what you >were going for of course). There's so many way to handle this problem, I'm sure we can find >something more efficient than this but its pretty good I think and easy to follow. > >Please review, I have this under test now and am heading out.... > >Thx >Paul > > > physicalAddress.QuadPart = pSgl->List[index].PhysicalAddress.QuadPart; > > if (sgElementSize <= PAGE_SIZE) { > ULONG nextPage = 0; > > /* Must transfer at least one full page */ > numImplicitEntries = 1; > /* > * since we may be offset into the page, look to determine > * address to determine if a 2nd PRP entry is needed > */ > nextPage = physicalAddress.LowPart + PAGE_SIZE; > nextPage = nextPage & ~PAGE_MASK; > numImplicitEntries += > ((physicalAddress.LowPart + sgElementSize) > nextPage) ? 1 : 0; > } else { > PHYSICAL_ADDRESS startAddr, endAddr; > > startAddr.QuadPart = physicalAddress.QuadPart; > endAddr.QuadPart = startAddr.QuadPart + sgElementSize; > numImplicitEntries = 0; > > /* account for an entry becaue of an offset start */ > if (startAddr.QuadPart % PAGE_SIZE) { > numImplicitEntries += 1; > /* bump the start address to the next page boundary */ > startAddr.QuadPart += PAGE_SIZE; > startAddr.QuadPart &= ~PAGE_MASK; > } > > /* account for an entry becaue of tail */ > if (endAddr.QuadPart % PAGE_SIZE) { > numImplicitEntries += 1; > /* lop off the tail */ > endAddr.QuadPart &= ~PAGE_MASK; > } > /* now account for the whole pages if any */ > numImplicitEntries += (ULONG)((endAddr.QuadPart - startAddr.QuadPart) / PAGE_SIZE); > } > >____________________________________ >Paul Luse >Sr. Staff Engineer >PCG Server Software Engineering >Desk: 480.554.3688, Mobile: 480.334.4630 > >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: > >-------------- next part -------------- >An embedded and charset-unspecified text was scrubbed... >Name: nvmeSnti.c >URL: > > >------------------------------ > >_______________________________________________ >nvmewin mailing list >nvmewin at lists.openfabrics.org >http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin > > >End of nvmewin Digest, Vol 4, Issue 27 >************************************** From paul.e.luse at intel.com Wed Apr 18 18:26:09 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Thu, 19 Apr 2012 01:26:09 +0000 Subject: [nvmewin] nvmewin Digest, Vol 4, Issue 27 In-Reply-To: References: Message-ID: <82C9F782B054C94B9FC04A331649C77A0BB09B@FMSMSX106.amr.corp.intel.com> Actually it doesn't, I don't think. If you're less than a page size and have an offset and just go down the else side you'll end up with a bogus start/end address and the math to calculate the num of whole pages will be negative. I could have generically determined if the element crossed a page boundary and if not just set the num entries to 1 and if so drop to the else and that would work too. It wouldn't save any cycles though but would pull the part out about calc'ing the next starting page into common code. I didn't think it was worth it. Thoughts? -----Original Message----- From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Harris, James R Sent: Wednesday, April 18, 2012 5:47 PM To: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] nvmewin Digest, Vol 4, Issue 27 You shouldn't need the "if" part here. The "else" part will handle the "less than PAGE_SIZE" case. -Jim >-----Original Message----- >From: nvmewin-bounces at lists.openfabrics.org >[mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of >nvmewin-request at lists.openfabrics.org >Sent: Wednesday, April 18, 2012 5:55 PM >To: nvmewin at lists.openfabrics.org >Subject: nvmewin Digest, Vol 4, Issue 27 > >Send nvmewin mailing list submissions to > nvmewin at lists.openfabrics.org > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin >or, via email, send a message with subject or body 'help' to > nvmewin-request at lists.openfabrics.org > >You can reach the person managing the list at > nvmewin-owner at lists.openfabrics.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of nvmewin digest..." > > >Today's Topics: > > 1. updated SGL conversion routine (Luse, Paul E) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 19 Apr 2012 00:43:02 +0000 >From: "Luse, Paul E" >To: "nvmewin at lists.openfabrics.org" >Subject: [nvmewin] updated SGL conversion routine >Message-ID: > <82C9F782B054C94B9FC04A331649C77A0BAFC5 at FMSMSX106.amr.corp.intel.com> >Content-Type: text/plain; charset="us-ascii" > >OK, the else has now been updated (thanks Jim, needed some tweaks >though but I saw what you were going for of course). There's so many >way to handle this problem, I'm sure we can find something more efficient than this but its pretty good I think and easy to follow. > >Please review, I have this under test now and am heading out.... > >Thx >Paul > > > physicalAddress.QuadPart = > pSgl->List[index].PhysicalAddress.QuadPart; > > if (sgElementSize <= PAGE_SIZE) { > ULONG nextPage = 0; > > /* Must transfer at least one full page */ > numImplicitEntries = 1; > /* > * since we may be offset into the page, look to determine > * address to determine if a 2nd PRP entry is needed > */ > nextPage = physicalAddress.LowPart + PAGE_SIZE; > nextPage = nextPage & ~PAGE_MASK; > numImplicitEntries += > ((physicalAddress.LowPart + sgElementSize) > nextPage) ? 1 : 0; > } else { > PHYSICAL_ADDRESS startAddr, endAddr; > > startAddr.QuadPart = physicalAddress.QuadPart; > endAddr.QuadPart = startAddr.QuadPart + sgElementSize; > numImplicitEntries = 0; > > /* account for an entry becaue of an offset start */ > if (startAddr.QuadPart % PAGE_SIZE) { > numImplicitEntries += 1; > /* bump the start address to the next page boundary */ > startAddr.QuadPart += PAGE_SIZE; > startAddr.QuadPart &= ~PAGE_MASK; > } > > /* account for an entry becaue of tail */ > if (endAddr.QuadPart % PAGE_SIZE) { > numImplicitEntries += 1; > /* lop off the tail */ > endAddr.QuadPart &= ~PAGE_MASK; > } > /* now account for the whole pages if any */ > numImplicitEntries += (ULONG)((endAddr.QuadPart - startAddr.QuadPart) / PAGE_SIZE); > } > >____________________________________ >Paul Luse >Sr. Staff Engineer >PCG Server Software Engineering >Desk: 480.554.3688, Mobile: 480.334.4630 > >-------------- next part -------------- An HTML attachment was >scrubbed... >URL: >59ab31/attachment.html> >-------------- next part -------------- An embedded and >charset-unspecified text was scrubbed... >Name: nvmeSnti.c >URL: >59ab31/attachment.c> > >------------------------------ > >_______________________________________________ >nvmewin mailing list >nvmewin at lists.openfabrics.org >http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin > > >End of nvmewin Digest, Vol 4, Issue 27 >************************************** _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin From paul.e.luse at intel.com Thu Apr 19 05:16:36 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Thu, 19 Apr 2012 12:16:36 +0000 Subject: [nvmewin] nvmewin Digest, Vol 4, Issue 27 In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0BB09B@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A0BB09B@FMSMSX106.amr.corp.intel.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0C0FD2@FMSMSX106.amr.corp.intel.com> Actually I've got another more academic approach that I'm testing now and have written unit test code to cover all test cases that runs just against this little section that determines the number of PPR entries. Once I have it, and the test code, ready I'll send them out. We should actually have a contest for the simplest/tightest algorithm to solve this fairly simple problem... my current routine only has 2 conditions and 5 operations as compared to the 4 conditions and 11 operations that we currently use -----Original Message----- From: Luse, Paul E Sent: Wednesday, April 18, 2012 6:26 PM To: Harris, James R; nvmewin at lists.openfabrics.org Subject: RE: nvmewin Digest, Vol 4, Issue 27 Actually it doesn't, I don't think. If you're less than a page size and have an offset and just go down the else side you'll end up with a bogus start/end address and the math to calculate the num of whole pages will be negative. I could have generically determined if the element crossed a page boundary and if not just set the num entries to 1 and if so drop to the else and that would work too. It wouldn't save any cycles though but would pull the part out about calc'ing the next starting page into common code. I didn't think it was worth it. Thoughts? -----Original Message----- From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Harris, James R Sent: Wednesday, April 18, 2012 5:47 PM To: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] nvmewin Digest, Vol 4, Issue 27 You shouldn't need the "if" part here. The "else" part will handle the "less than PAGE_SIZE" case. -Jim >-----Original Message----- >From: nvmewin-bounces at lists.openfabrics.org >[mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of >nvmewin-request at lists.openfabrics.org >Sent: Wednesday, April 18, 2012 5:55 PM >To: nvmewin at lists.openfabrics.org >Subject: nvmewin Digest, Vol 4, Issue 27 > >Send nvmewin mailing list submissions to > nvmewin at lists.openfabrics.org > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin >or, via email, send a message with subject or body 'help' to > nvmewin-request at lists.openfabrics.org > >You can reach the person managing the list at > nvmewin-owner at lists.openfabrics.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of nvmewin digest..." > > >Today's Topics: > > 1. updated SGL conversion routine (Luse, Paul E) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 19 Apr 2012 00:43:02 +0000 >From: "Luse, Paul E" >To: "nvmewin at lists.openfabrics.org" >Subject: [nvmewin] updated SGL conversion routine >Message-ID: > <82C9F782B054C94B9FC04A331649C77A0BAFC5 at FMSMSX106.amr.corp.intel.com> >Content-Type: text/plain; charset="us-ascii" > >OK, the else has now been updated (thanks Jim, needed some tweaks >though but I saw what you were going for of course). There's so many >way to handle this problem, I'm sure we can find something more efficient than this but its pretty good I think and easy to follow. > >Please review, I have this under test now and am heading out.... > >Thx >Paul > > > physicalAddress.QuadPart = > pSgl->List[index].PhysicalAddress.QuadPart; > > if (sgElementSize <= PAGE_SIZE) { > ULONG nextPage = 0; > > /* Must transfer at least one full page */ > numImplicitEntries = 1; > /* > * since we may be offset into the page, look to determine > * address to determine if a 2nd PRP entry is needed > */ > nextPage = physicalAddress.LowPart + PAGE_SIZE; > nextPage = nextPage & ~PAGE_MASK; > numImplicitEntries += > ((physicalAddress.LowPart + sgElementSize) > nextPage) ? 1 : 0; > } else { > PHYSICAL_ADDRESS startAddr, endAddr; > > startAddr.QuadPart = physicalAddress.QuadPart; > endAddr.QuadPart = startAddr.QuadPart + sgElementSize; > numImplicitEntries = 0; > > /* account for an entry becaue of an offset start */ > if (startAddr.QuadPart % PAGE_SIZE) { > numImplicitEntries += 1; > /* bump the start address to the next page boundary */ > startAddr.QuadPart += PAGE_SIZE; > startAddr.QuadPart &= ~PAGE_MASK; > } > > /* account for an entry becaue of tail */ > if (endAddr.QuadPart % PAGE_SIZE) { > numImplicitEntries += 1; > /* lop off the tail */ > endAddr.QuadPart &= ~PAGE_MASK; > } > /* now account for the whole pages if any */ > numImplicitEntries += (ULONG)((endAddr.QuadPart - startAddr.QuadPart) / PAGE_SIZE); > } > >____________________________________ >Paul Luse >Sr. Staff Engineer >PCG Server Software Engineering >Desk: 480.554.3688, Mobile: 480.334.4630 > >-------------- next part -------------- An HTML attachment was >scrubbed... >URL: >59ab31/attachment.html> >-------------- next part -------------- An embedded and >charset-unspecified text was scrubbed... >Name: nvmeSnti.c >URL: >59ab31/attachment.c> > >------------------------------ > >_______________________________________________ >nvmewin mailing list >nvmewin at lists.openfabrics.org >http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin > > >End of nvmewin Digest, Vol 4, Issue 27 >************************************** _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin From paul.e.luse at intel.com Thu Apr 19 06:34:01 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Thu, 19 Apr 2012 13:34:01 +0000 Subject: [nvmewin] nvmewin Digest, Vol 4, Issue 27 References: <82C9F782B054C94B9FC04A331649C77A0BB09B@FMSMSX106.amr.corp.intel.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0C10D1@FMSMSX106.amr.corp.intel.com> OK, here's my user mode test code w/test cases and both current version of the section of translateSgl that determines the number of entries and the new one I just came up with. Both pass the unit test cases and I'm currently testing the driver with the new one implemented (prev version passed overnight testing). Please review both the test cases, unit test code and the new algorithm. I'm proposing using the new, of course, provided that it passes all tests and reviews go OK. There are several test cases that are n/a (I didn't include a full test matrix, only the ones that are applicable). Thx Paul PS: new code actually has 5 operations, had to add one since my last email :) -----Original Message----- From: Luse, Paul E Sent: Thursday, April 19, 2012 5:17 AM To: Harris, James R; 'nvmewin at lists.openfabrics.org' Subject: RE: nvmewin Digest, Vol 4, Issue 27 Actually I've got another more academic approach that I'm testing now and have written unit test code to cover all test cases that runs just against this little section that determines the number of PPR entries. Once I have it, and the test code, ready I'll send them out. We should actually have a contest for the simplest/tightest algorithm to solve this fairly simple problem... my current routine only has 2 conditions and 5 operations as compared to the 4 conditions and 11 operations that we currently use -----Original Message----- From: Luse, Paul E Sent: Wednesday, April 18, 2012 6:26 PM To: Harris, James R; nvmewin at lists.openfabrics.org Subject: RE: nvmewin Digest, Vol 4, Issue 27 Actually it doesn't, I don't think. If you're less than a page size and have an offset and just go down the else side you'll end up with a bogus start/end address and the math to calculate the num of whole pages will be negative. I could have generically determined if the element crossed a page boundary and if not just set the num entries to 1 and if so drop to the else and that would work too. It wouldn't save any cycles though but would pull the part out about calc'ing the next starting page into common code. I didn't think it was worth it. Thoughts? -----Original Message----- From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Harris, James R Sent: Wednesday, April 18, 2012 5:47 PM To: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] nvmewin Digest, Vol 4, Issue 27 You shouldn't need the "if" part here. The "else" part will handle the "less than PAGE_SIZE" case. -Jim >-----Original Message----- >From: nvmewin-bounces at lists.openfabrics.org >[mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of >nvmewin-request at lists.openfabrics.org >Sent: Wednesday, April 18, 2012 5:55 PM >To: nvmewin at lists.openfabrics.org >Subject: nvmewin Digest, Vol 4, Issue 27 > >Send nvmewin mailing list submissions to > nvmewin at lists.openfabrics.org > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin >or, via email, send a message with subject or body 'help' to > nvmewin-request at lists.openfabrics.org > >You can reach the person managing the list at > nvmewin-owner at lists.openfabrics.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of nvmewin digest..." > > >Today's Topics: > > 1. updated SGL conversion routine (Luse, Paul E) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 19 Apr 2012 00:43:02 +0000 >From: "Luse, Paul E" >To: "nvmewin at lists.openfabrics.org" >Subject: [nvmewin] updated SGL conversion routine >Message-ID: > <82C9F782B054C94B9FC04A331649C77A0BAFC5 at FMSMSX106.amr.corp.intel.com> >Content-Type: text/plain; charset="us-ascii" > >OK, the else has now been updated (thanks Jim, needed some tweaks >though but I saw what you were going for of course). There's so many >way to handle this problem, I'm sure we can find something more efficient than this but its pretty good I think and easy to follow. > >Please review, I have this under test now and am heading out.... > >Thx >Paul > > > physicalAddress.QuadPart = > pSgl->List[index].PhysicalAddress.QuadPart; > > if (sgElementSize <= PAGE_SIZE) { > ULONG nextPage = 0; > > /* Must transfer at least one full page */ > numImplicitEntries = 1; > /* > * since we may be offset into the page, look to determine > * address to determine if a 2nd PRP entry is needed > */ > nextPage = physicalAddress.LowPart + PAGE_SIZE; > nextPage = nextPage & ~PAGE_MASK; > numImplicitEntries += > ((physicalAddress.LowPart + sgElementSize) > nextPage) ? 1 : 0; > } else { > PHYSICAL_ADDRESS startAddr, endAddr; > > startAddr.QuadPart = physicalAddress.QuadPart; > endAddr.QuadPart = startAddr.QuadPart + sgElementSize; > numImplicitEntries = 0; > > /* account for an entry becaue of an offset start */ > if (startAddr.QuadPart % PAGE_SIZE) { > numImplicitEntries += 1; > /* bump the start address to the next page boundary */ > startAddr.QuadPart += PAGE_SIZE; > startAddr.QuadPart &= ~PAGE_MASK; > } > > /* account for an entry becaue of tail */ > if (endAddr.QuadPart % PAGE_SIZE) { > numImplicitEntries += 1; > /* lop off the tail */ > endAddr.QuadPart &= ~PAGE_MASK; > } > /* now account for the whole pages if any */ > numImplicitEntries += (ULONG)((endAddr.QuadPart - startAddr.QuadPart) / PAGE_SIZE); > } > >____________________________________ >Paul Luse >Sr. Staff Engineer >PCG Server Software Engineering >Desk: 480.554.3688, Mobile: 480.334.4630 > >-------------- next part -------------- An HTML attachment was >scrubbed... >URL: >59ab31/attachment.html> >-------------- next part -------------- An embedded and >charset-unspecified text was scrubbed... >Name: nvmeSnti.c >URL: >59ab31/attachment.c> > >------------------------------ > >_______________________________________________ >nvmewin mailing list >nvmewin at lists.openfabrics.org >http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin > > >End of nvmewin Digest, Vol 4, Issue 27 >************************************** _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: prp.cpp URL: From paul.e.luse at intel.com Thu Apr 19 06:51:00 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Thu, 19 Apr 2012 13:51:00 +0000 Subject: [nvmewin] nvmewin Digest, Vol 4, Issue 27 In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0C10D1@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A0BB09B@FMSMSX106.amr.corp.intel.com> <82C9F782B054C94B9FC04A331649C77A0C10D1@FMSMSX106.amr.corp.intel.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0C2149@FMSMSX106.amr.corp.intel.com> Forgot to mention... with this test code and the old algorithm, test cases 6,7,9,11 all fail. -----Original Message----- From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Thursday, April 19, 2012 6:34 AM To: Harris, James R; 'nvmewin at lists.openfabrics.org' Subject: Re: [nvmewin] nvmewin Digest, Vol 4, Issue 27 OK, here's my user mode test code w/test cases and both current version of the section of translateSgl that determines the number of entries and the new one I just came up with. Both pass the unit test cases and I'm currently testing the driver with the new one implemented (prev version passed overnight testing). Please review both the test cases, unit test code and the new algorithm. I'm proposing using the new, of course, provided that it passes all tests and reviews go OK. There are several test cases that are n/a (I didn't include a full test matrix, only the ones that are applicable). Thx Paul PS: new code actually has 5 operations, had to add one since my last email :) -----Original Message----- From: Luse, Paul E Sent: Thursday, April 19, 2012 5:17 AM To: Harris, James R; 'nvmewin at lists.openfabrics.org' Subject: RE: nvmewin Digest, Vol 4, Issue 27 Actually I've got another more academic approach that I'm testing now and have written unit test code to cover all test cases that runs just against this little section that determines the number of PPR entries. Once I have it, and the test code, ready I'll send them out. We should actually have a contest for the simplest/tightest algorithm to solve this fairly simple problem... my current routine only has 2 conditions and 5 operations as compared to the 4 conditions and 11 operations that we currently use -----Original Message----- From: Luse, Paul E Sent: Wednesday, April 18, 2012 6:26 PM To: Harris, James R; nvmewin at lists.openfabrics.org Subject: RE: nvmewin Digest, Vol 4, Issue 27 Actually it doesn't, I don't think. If you're less than a page size and have an offset and just go down the else side you'll end up with a bogus start/end address and the math to calculate the num of whole pages will be negative. I could have generically determined if the element crossed a page boundary and if not just set the num entries to 1 and if so drop to the else and that would work too. It wouldn't save any cycles though but would pull the part out about calc'ing the next starting page into common code. I didn't think it was worth it. Thoughts? -----Original Message----- From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Harris, James R Sent: Wednesday, April 18, 2012 5:47 PM To: nvmewin at lists.openfabrics.org Subject: Re: [nvmewin] nvmewin Digest, Vol 4, Issue 27 You shouldn't need the "if" part here. The "else" part will handle the "less than PAGE_SIZE" case. -Jim >-----Original Message----- >From: nvmewin-bounces at lists.openfabrics.org >[mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of >nvmewin-request at lists.openfabrics.org >Sent: Wednesday, April 18, 2012 5:55 PM >To: nvmewin at lists.openfabrics.org >Subject: nvmewin Digest, Vol 4, Issue 27 > >Send nvmewin mailing list submissions to > nvmewin at lists.openfabrics.org > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin >or, via email, send a message with subject or body 'help' to > nvmewin-request at lists.openfabrics.org > >You can reach the person managing the list at > nvmewin-owner at lists.openfabrics.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of nvmewin digest..." > > >Today's Topics: > > 1. updated SGL conversion routine (Luse, Paul E) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 19 Apr 2012 00:43:02 +0000 >From: "Luse, Paul E" >To: "nvmewin at lists.openfabrics.org" >Subject: [nvmewin] updated SGL conversion routine >Message-ID: > <82C9F782B054C94B9FC04A331649C77A0BAFC5 at FMSMSX106.amr.corp.intel.com> >Content-Type: text/plain; charset="us-ascii" > >OK, the else has now been updated (thanks Jim, needed some tweaks >though but I saw what you were going for of course). There's so many >way to handle this problem, I'm sure we can find something more efficient than this but its pretty good I think and easy to follow. > >Please review, I have this under test now and am heading out.... > >Thx >Paul > > > physicalAddress.QuadPart = > pSgl->List[index].PhysicalAddress.QuadPart; > > if (sgElementSize <= PAGE_SIZE) { > ULONG nextPage = 0; > > /* Must transfer at least one full page */ > numImplicitEntries = 1; > /* > * since we may be offset into the page, look to determine > * address to determine if a 2nd PRP entry is needed > */ > nextPage = physicalAddress.LowPart + PAGE_SIZE; > nextPage = nextPage & ~PAGE_MASK; > numImplicitEntries += > ((physicalAddress.LowPart + sgElementSize) > nextPage) ? 1 : 0; > } else { > PHYSICAL_ADDRESS startAddr, endAddr; > > startAddr.QuadPart = physicalAddress.QuadPart; > endAddr.QuadPart = startAddr.QuadPart + sgElementSize; > numImplicitEntries = 0; > > /* account for an entry becaue of an offset start */ > if (startAddr.QuadPart % PAGE_SIZE) { > numImplicitEntries += 1; > /* bump the start address to the next page boundary */ > startAddr.QuadPart += PAGE_SIZE; > startAddr.QuadPart &= ~PAGE_MASK; > } > > /* account for an entry becaue of tail */ > if (endAddr.QuadPart % PAGE_SIZE) { > numImplicitEntries += 1; > /* lop off the tail */ > endAddr.QuadPart &= ~PAGE_MASK; > } > /* now account for the whole pages if any */ > numImplicitEntries += (ULONG)((endAddr.QuadPart - startAddr.QuadPart) / PAGE_SIZE); > } > >____________________________________ >Paul Luse >Sr. Staff Engineer >PCG Server Software Engineering >Desk: 480.554.3688, Mobile: 480.334.4630 > >-------------- next part -------------- An HTML attachment was >scrubbed... >URL: >59ab31/attachment.html> >-------------- next part -------------- An embedded and >charset-unspecified text was scrubbed... >Name: nvmeSnti.c >URL: >59ab31/attachment.c> > >------------------------------ > >_______________________________________________ >nvmewin mailing list >nvmewin at lists.openfabrics.org >http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin > > >End of nvmewin Digest, Vol 4, Issue 27 >************************************** _______________________________________________ nvmewin mailing list nvmewin at lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin From james.r.harris at intel.com Thu Apr 19 08:19:16 2012 From: james.r.harris at intel.com (Harris, James R) Date: Thu, 19 Apr 2012 15:19:16 +0000 Subject: [nvmewin] nvmewin Digest, Vol 4, Issue 27 In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0BB09B@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A0BB09B@FMSMSX106.amr.corp.intel.com> Message-ID: In the case where you're less than a page size and have an offset on both the start and end, you'll go through both if() statements (incrementing by 1 each time), then you'll actually subtract 1 at the very end because you'll have start address after end address like you mentioned. So you'll still end up with the correct number at the end. But I see you have a bunch of other e-mails after this one. I'll look through those as well. Like you said, there are any number of ways to approach this... -Jim >-----Original Message----- >From: Luse, Paul E >Sent: Wednesday, April 18, 2012 6:26 PM >To: Harris, James R; nvmewin at lists.openfabrics.org >Subject: RE: nvmewin Digest, Vol 4, Issue 27 > >Actually it doesn't, I don't think. If you're less than a page size and have an offset and >just go down the else side you'll end up with a bogus start/end address and the math to >calculate the num of whole pages will be negative. I could have generically determined if the >element crossed a page boundary and if not just set the num entries to 1 and if so drop to the >else and that would work too. It wouldn't save any cycles though but would pull the part out >about calc'ing the next starting page into common code. I didn't think it was worth it. > >Thoughts? > >-----Original Message----- >From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On >Behalf Of Harris, James R >Sent: Wednesday, April 18, 2012 5:47 PM >To: nvmewin at lists.openfabrics.org >Subject: Re: [nvmewin] nvmewin Digest, Vol 4, Issue 27 > >You shouldn't need the "if" part here. The "else" part will handle the "less than PAGE_SIZE" >case. > >-Jim > > >>-----Original Message----- >>From: nvmewin-bounces at lists.openfabrics.org >>[mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of >>nvmewin-request at lists.openfabrics.org >>Sent: Wednesday, April 18, 2012 5:55 PM >>To: nvmewin at lists.openfabrics.org >>Subject: nvmewin Digest, Vol 4, Issue 27 >> >>Send nvmewin mailing list submissions to >> nvmewin at lists.openfabrics.org >> >>To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin >>or, via email, send a message with subject or body 'help' to >> nvmewin-request at lists.openfabrics.org >> >>You can reach the person managing the list at >> nvmewin-owner at lists.openfabrics.org >> >>When replying, please edit your Subject line so it is more specific >>than "Re: Contents of nvmewin digest..." >> >> >>Today's Topics: >> >> 1. updated SGL conversion routine (Luse, Paul E) >> >> >>---------------------------------------------------------------------- >> >>Message: 1 >>Date: Thu, 19 Apr 2012 00:43:02 +0000 >>From: "Luse, Paul E" >>To: "nvmewin at lists.openfabrics.org" >>Subject: [nvmewin] updated SGL conversion routine >>Message-ID: >> <82C9F782B054C94B9FC04A331649C77A0BAFC5 at FMSMSX106.amr.corp.intel.com> >>Content-Type: text/plain; charset="us-ascii" >> >>OK, the else has now been updated (thanks Jim, needed some tweaks >>though but I saw what you were going for of course). There's so many >>way to handle this problem, I'm sure we can find something more efficient than this but its >pretty good I think and easy to follow. >> >>Please review, I have this under test now and am heading out.... >> >>Thx >>Paul >> >> >> physicalAddress.QuadPart = >> pSgl->List[index].PhysicalAddress.QuadPart; >> >> if (sgElementSize <= PAGE_SIZE) { >> ULONG nextPage = 0; >> >> /* Must transfer at least one full page */ >> numImplicitEntries = 1; >> /* >> * since we may be offset into the page, look to determine >> * address to determine if a 2nd PRP entry is needed >> */ >> nextPage = physicalAddress.LowPart + PAGE_SIZE; >> nextPage = nextPage & ~PAGE_MASK; >> numImplicitEntries += >> ((physicalAddress.LowPart + sgElementSize) > nextPage) ? 1 : 0; >> } else { >> PHYSICAL_ADDRESS startAddr, endAddr; >> >> startAddr.QuadPart = physicalAddress.QuadPart; >> endAddr.QuadPart = startAddr.QuadPart + sgElementSize; >> numImplicitEntries = 0; >> >> /* account for an entry becaue of an offset start */ >> if (startAddr.QuadPart % PAGE_SIZE) { >> numImplicitEntries += 1; >> /* bump the start address to the next page boundary */ >> startAddr.QuadPart += PAGE_SIZE; >> startAddr.QuadPart &= ~PAGE_MASK; >> } >> >> /* account for an entry becaue of tail */ >> if (endAddr.QuadPart % PAGE_SIZE) { >> numImplicitEntries += 1; >> /* lop off the tail */ >> endAddr.QuadPart &= ~PAGE_MASK; >> } >> /* now account for the whole pages if any */ >> numImplicitEntries += (ULONG)((endAddr.QuadPart - startAddr.QuadPart) / >PAGE_SIZE); >> } >> >>____________________________________ >>Paul Luse >>Sr. Staff Engineer >>PCG Server Software Engineering >>Desk: 480.554.3688, Mobile: 480.334.4630 >> >>-------------- next part -------------- An HTML attachment was >>scrubbed... >>URL: >>>59ab31/attachment.html> >>-------------- next part -------------- An embedded and >>charset-unspecified text was scrubbed... >>Name: nvmeSnti.c >>URL: >>>59ab31/attachment.c> >> >>------------------------------ >> >>_______________________________________________ >>nvmewin mailing list >>nvmewin at lists.openfabrics.org >>http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin >> >> >>End of nvmewin Digest, Vol 4, Issue 27 >>************************************** >_______________________________________________ >nvmewin mailing list >nvmewin at lists.openfabrics.org >http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin From james.r.harris at intel.com Thu Apr 19 08:35:21 2012 From: james.r.harris at intel.com (Harris, James R) Date: Thu, 19 Apr 2012 15:35:21 +0000 Subject: [nvmewin] nvmewin Digest, Vol 4, Issue 27 In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0C10D1@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A0BB09B@FMSMSX106.amr.corp.intel.com> <82C9F782B054C94B9FC04A331649C77A0C10D1@FMSMSX106.amr.corp.intel.com> Message-ID: This code looks good. I think you can do one further simplification: Instead of: if (modulo || unaligned) { nextPage = physicalAddress.LowPart + PAGE_SIZE; nextPage = nextPage & ~PAGE_MASK; numImplicitEntries += ((physicalAddress.LowPart + modulo) > nextPage) ? 2 : 1; } How about: if (modulo || unaligned) { numImplicitEntries += 1 + (modulo + unaligned - 1) / PAGE_SIZE; } I'd work out all the examples myself, but since you have your nifty unit test program, maybe you can test it for me. :-) Thanks, -Jim >-----Original Message----- >From: Luse, Paul E >Sent: Thursday, April 19, 2012 6:34 AM >To: Harris, James R; 'nvmewin at lists.openfabrics.org' >Subject: RE: nvmewin Digest, Vol 4, Issue 27 > >OK, here's my user mode test code w/test cases and both current version of the section of >translateSgl that determines the number of entries and the new one I just came up with. Both >pass the unit test cases and I'm currently testing the driver with the new one implemented >(prev version passed overnight testing). > >Please review both the test cases, unit test code and the new algorithm. I'm proposing using >the new, of course, provided that it passes all tests and reviews go OK. There are several >test cases that are n/a (I didn't include a full test matrix, only the ones that are >applicable). > >Thx >Paul > >PS: new code actually has 5 operations, had to add one since my last email :) > >-----Original Message----- >From: Luse, Paul E >Sent: Thursday, April 19, 2012 5:17 AM >To: Harris, James R; 'nvmewin at lists.openfabrics.org' >Subject: RE: nvmewin Digest, Vol 4, Issue 27 > >Actually I've got another more academic approach that I'm testing now and have written unit >test code to cover all test cases that runs just against this little section that determines >the number of PPR entries. Once I have it, and the test code, ready I'll send them out. We >should actually have a contest for the simplest/tightest algorithm to solve this fairly simple >problem... my current routine only has 2 conditions and 5 operations as compared to the 4 >conditions and 11 operations that we currently use > >-----Original Message----- >From: Luse, Paul E >Sent: Wednesday, April 18, 2012 6:26 PM >To: Harris, James R; nvmewin at lists.openfabrics.org >Subject: RE: nvmewin Digest, Vol 4, Issue 27 > >Actually it doesn't, I don't think. If you're less than a page size and have an offset and >just go down the else side you'll end up with a bogus start/end address and the math to >calculate the num of whole pages will be negative. I could have generically determined if the >element crossed a page boundary and if not just set the num entries to 1 and if so drop to the >else and that would work too. It wouldn't save any cycles though but would pull the part out >about calc'ing the next starting page into common code. I didn't think it was worth it. > >Thoughts? > >-----Original Message----- >From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On >Behalf Of Harris, James R >Sent: Wednesday, April 18, 2012 5:47 PM >To: nvmewin at lists.openfabrics.org >Subject: Re: [nvmewin] nvmewin Digest, Vol 4, Issue 27 > >You shouldn't need the "if" part here. The "else" part will handle the "less than PAGE_SIZE" >case. > >-Jim > > >>-----Original Message----- >>From: nvmewin-bounces at lists.openfabrics.org >>[mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of >>nvmewin-request at lists.openfabrics.org >>Sent: Wednesday, April 18, 2012 5:55 PM >>To: nvmewin at lists.openfabrics.org >>Subject: nvmewin Digest, Vol 4, Issue 27 >> >>Send nvmewin mailing list submissions to >> nvmewin at lists.openfabrics.org >> >>To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin >>or, via email, send a message with subject or body 'help' to >> nvmewin-request at lists.openfabrics.org >> >>You can reach the person managing the list at >> nvmewin-owner at lists.openfabrics.org >> >>When replying, please edit your Subject line so it is more specific >>than "Re: Contents of nvmewin digest..." >> >> >>Today's Topics: >> >> 1. updated SGL conversion routine (Luse, Paul E) >> >> >>---------------------------------------------------------------------- >> >>Message: 1 >>Date: Thu, 19 Apr 2012 00:43:02 +0000 >>From: "Luse, Paul E" >>To: "nvmewin at lists.openfabrics.org" >>Subject: [nvmewin] updated SGL conversion routine >>Message-ID: >> <82C9F782B054C94B9FC04A331649C77A0BAFC5 at FMSMSX106.amr.corp.intel.com> >>Content-Type: text/plain; charset="us-ascii" >> >>OK, the else has now been updated (thanks Jim, needed some tweaks >>though but I saw what you were going for of course). There's so many >>way to handle this problem, I'm sure we can find something more efficient than this but its >pretty good I think and easy to follow. >> >>Please review, I have this under test now and am heading out.... >> >>Thx >>Paul >> >> >> physicalAddress.QuadPart = >> pSgl->List[index].PhysicalAddress.QuadPart; >> >> if (sgElementSize <= PAGE_SIZE) { >> ULONG nextPage = 0; >> >> /* Must transfer at least one full page */ >> numImplicitEntries = 1; >> /* >> * since we may be offset into the page, look to determine >> * address to determine if a 2nd PRP entry is needed >> */ >> nextPage = physicalAddress.LowPart + PAGE_SIZE; >> nextPage = nextPage & ~PAGE_MASK; >> numImplicitEntries += >> ((physicalAddress.LowPart + sgElementSize) > nextPage) ? 1 : 0; >> } else { >> PHYSICAL_ADDRESS startAddr, endAddr; >> >> startAddr.QuadPart = physicalAddress.QuadPart; >> endAddr.QuadPart = startAddr.QuadPart + sgElementSize; >> numImplicitEntries = 0; >> >> /* account for an entry becaue of an offset start */ >> if (startAddr.QuadPart % PAGE_SIZE) { >> numImplicitEntries += 1; >> /* bump the start address to the next page boundary */ >> startAddr.QuadPart += PAGE_SIZE; >> startAddr.QuadPart &= ~PAGE_MASK; >> } >> >> /* account for an entry becaue of tail */ >> if (endAddr.QuadPart % PAGE_SIZE) { >> numImplicitEntries += 1; >> /* lop off the tail */ >> endAddr.QuadPart &= ~PAGE_MASK; >> } >> /* now account for the whole pages if any */ >> numImplicitEntries += (ULONG)((endAddr.QuadPart - startAddr.QuadPart) / >PAGE_SIZE); >> } >> >>____________________________________ >>Paul Luse >>Sr. Staff Engineer >>PCG Server Software Engineering >>Desk: 480.554.3688, Mobile: 480.334.4630 >> >>-------------- next part -------------- An HTML attachment was >>scrubbed... >>URL: >>>59ab31/attachment.html> >>-------------- next part -------------- An embedded and >>charset-unspecified text was scrubbed... >>Name: nvmeSnti.c >>URL: >>>59ab31/attachment.c> >> >>------------------------------ >> >>_______________________________________________ >>nvmewin mailing list >>nvmewin at lists.openfabrics.org >>http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin >> >> >>End of nvmewin Digest, Vol 4, Issue 27 >>************************************** >_______________________________________________ >nvmewin mailing list >nvmewin at lists.openfabrics.org >http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin From paul.e.luse at intel.com Thu Apr 19 09:00:56 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Thu, 19 Apr 2012 16:00:56 +0000 Subject: [nvmewin] nvmewin Digest, Vol 4, Issue 27 In-Reply-To: References: <82C9F782B054C94B9FC04A331649C77A0BB09B@FMSMSX106.amr.corp.intel.com> <82C9F782B054C94B9FC04A331649C77A0C10D1@FMSMSX106.amr.corp.intel.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0C4323@FMSMSX106.amr.corp.intel.com> That passes all the tests as well and is a little trickier to understand at first, at least for me, but I like it! I'm going to make the change, get some test running. I'm revoking my last patch (the one where we handle CC incorrectly) and merge it with this one and send a new patch out after some more testing. I'll schedule call later this week to review and make sure any questions get answered before applying it. Thx Paul -----Original Message----- From: Harris, James R Sent: Thursday, April 19, 2012 8:35 AM To: Luse, Paul E; 'nvmewin at lists.openfabrics.org' Subject: RE: nvmewin Digest, Vol 4, Issue 27 This code looks good. I think you can do one further simplification: Instead of: if (modulo || unaligned) { nextPage = physicalAddress.LowPart + PAGE_SIZE; nextPage = nextPage & ~PAGE_MASK; numImplicitEntries += ((physicalAddress.LowPart + modulo) > nextPage) ? 2 : 1; } How about: if (modulo || unaligned) { numImplicitEntries += 1 + (modulo + unaligned - 1) / PAGE_SIZE; } I'd work out all the examples myself, but since you have your nifty unit test program, maybe you can test it for me. :-) Thanks, -Jim >-----Original Message----- >From: Luse, Paul E >Sent: Thursday, April 19, 2012 6:34 AM >To: Harris, James R; 'nvmewin at lists.openfabrics.org' >Subject: RE: nvmewin Digest, Vol 4, Issue 27 > >OK, here's my user mode test code w/test cases and both current version >of the section of translateSgl that determines the number of entries >and the new one I just came up with. Both pass the unit test cases and >I'm currently testing the driver with the new one implemented (prev version passed overnight testing). > >Please review both the test cases, unit test code and the new >algorithm. I'm proposing using the new, of course, provided that it >passes all tests and reviews go OK. There are several test cases that >are n/a (I didn't include a full test matrix, only the ones that are applicable). > >Thx >Paul > >PS: new code actually has 5 operations, had to add one since my last >email :) > >-----Original Message----- >From: Luse, Paul E >Sent: Thursday, April 19, 2012 5:17 AM >To: Harris, James R; 'nvmewin at lists.openfabrics.org' >Subject: RE: nvmewin Digest, Vol 4, Issue 27 > >Actually I've got another more academic approach that I'm testing now >and have written unit test code to cover all test cases that runs just >against this little section that determines the number of PPR entries. >Once I have it, and the test code, ready I'll send them out. We should >actually have a contest for the simplest/tightest algorithm to solve >this fairly simple problem... my current routine only has 2 conditions >and 5 operations as compared to the 4 conditions and 11 operations that >we currently use > >-----Original Message----- >From: Luse, Paul E >Sent: Wednesday, April 18, 2012 6:26 PM >To: Harris, James R; nvmewin at lists.openfabrics.org >Subject: RE: nvmewin Digest, Vol 4, Issue 27 > >Actually it doesn't, I don't think. If you're less than a page size >and have an offset and just go down the else side you'll end up with a >bogus start/end address and the math to calculate the num of whole >pages will be negative. I could have generically determined if the >element crossed a page boundary and if not just set the num entries to >1 and if so drop to the else and that would work too. It wouldn't save any cycles though but would pull the part out about calc'ing the next starting page into common code. I didn't think it was worth it. > >Thoughts? > >-----Original Message----- >From: nvmewin-bounces at lists.openfabrics.org >[mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Harris, >James R >Sent: Wednesday, April 18, 2012 5:47 PM >To: nvmewin at lists.openfabrics.org >Subject: Re: [nvmewin] nvmewin Digest, Vol 4, Issue 27 > >You shouldn't need the "if" part here. The "else" part will handle the "less than PAGE_SIZE" >case. > >-Jim > > >>-----Original Message----- >>From: nvmewin-bounces at lists.openfabrics.org >>[mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of >>nvmewin-request at lists.openfabrics.org >>Sent: Wednesday, April 18, 2012 5:55 PM >>To: nvmewin at lists.openfabrics.org >>Subject: nvmewin Digest, Vol 4, Issue 27 >> >>Send nvmewin mailing list submissions to >> nvmewin at lists.openfabrics.org >> >>To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin >>or, via email, send a message with subject or body 'help' to >> nvmewin-request at lists.openfabrics.org >> >>You can reach the person managing the list at >> nvmewin-owner at lists.openfabrics.org >> >>When replying, please edit your Subject line so it is more specific >>than "Re: Contents of nvmewin digest..." >> >> >>Today's Topics: >> >> 1. updated SGL conversion routine (Luse, Paul E) >> >> >>---------------------------------------------------------------------- >> >>Message: 1 >>Date: Thu, 19 Apr 2012 00:43:02 +0000 >>From: "Luse, Paul E" >>To: "nvmewin at lists.openfabrics.org" >>Subject: [nvmewin] updated SGL conversion routine >>Message-ID: >> <82C9F782B054C94B9FC04A331649C77A0BAFC5 at FMSMSX106.amr.corp.intel.com> >>Content-Type: text/plain; charset="us-ascii" >> >>OK, the else has now been updated (thanks Jim, needed some tweaks >>though but I saw what you were going for of course). There's so many >>way to handle this problem, I'm sure we can find something more >>efficient than this but its >pretty good I think and easy to follow. >> >>Please review, I have this under test now and am heading out.... >> >>Thx >>Paul >> >> >> physicalAddress.QuadPart = >> pSgl->List[index].PhysicalAddress.QuadPart; >> >> if (sgElementSize <= PAGE_SIZE) { >> ULONG nextPage = 0; >> >> /* Must transfer at least one full page */ >> numImplicitEntries = 1; >> /* >> * since we may be offset into the page, look to determine >> * address to determine if a 2nd PRP entry is needed >> */ >> nextPage = physicalAddress.LowPart + PAGE_SIZE; >> nextPage = nextPage & ~PAGE_MASK; >> numImplicitEntries += >> ((physicalAddress.LowPart + sgElementSize) > nextPage) ? 1 : 0; >> } else { >> PHYSICAL_ADDRESS startAddr, endAddr; >> >> startAddr.QuadPart = physicalAddress.QuadPart; >> endAddr.QuadPart = startAddr.QuadPart + sgElementSize; >> numImplicitEntries = 0; >> >> /* account for an entry becaue of an offset start */ >> if (startAddr.QuadPart % PAGE_SIZE) { >> numImplicitEntries += 1; >> /* bump the start address to the next page boundary */ >> startAddr.QuadPart += PAGE_SIZE; >> startAddr.QuadPart &= ~PAGE_MASK; >> } >> >> /* account for an entry becaue of tail */ >> if (endAddr.QuadPart % PAGE_SIZE) { >> numImplicitEntries += 1; >> /* lop off the tail */ >> endAddr.QuadPart &= ~PAGE_MASK; >> } >> /* now account for the whole pages if any */ >> numImplicitEntries += (ULONG)((endAddr.QuadPart - >> startAddr.QuadPart) / >PAGE_SIZE); >> } >> >>____________________________________ >>Paul Luse >>Sr. Staff Engineer >>PCG Server Software Engineering >>Desk: 480.554.3688, Mobile: 480.334.4630 >> >>-------------- next part -------------- An HTML attachment was >>scrubbed... >>URL: >>>9 >>59ab31/attachment.html> >>-------------- next part -------------- An embedded and >>charset-unspecified text was scrubbed... >>Name: nvmeSnti.c >>URL: >>>9 >>59ab31/attachment.c> >> >>------------------------------ >> >>_______________________________________________ >>nvmewin mailing list >>nvmewin at lists.openfabrics.org >>http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin >> >> >>End of nvmewin Digest, Vol 4, Issue 27 >>************************************** >_______________________________________________ >nvmewin mailing list >nvmewin at lists.openfabrics.org >http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin From paul.e.luse at intel.com Fri Apr 20 05:37:40 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Fri, 20 Apr 2012 12:37:40 +0000 Subject: [nvmewin] OFA NVMe miniport code review - SGL + CC handling patch Message-ID: <82C9F782B054C94B9FC04A331649C77A0C5115@FMSMSX106.amr.corp.intel.com> Tuesday, April 24, 2012, 01:00 PM US Pacific Time 916-356-2663, 8-356-2663, Bridge: 3, Passcode: 4672309 Live Meeting: https://webjoin.intel.com/?passcode=4672309 Speed dialer: inteldialer://3,4672309 | Learn more -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1720 bytes Desc: not available URL: From paul.e.luse at intel.com Fri Apr 20 07:19:44 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Fri, 20 Apr 2012 14:19:44 +0000 Subject: [nvmewin] ***UNCHECKED*** code for review next week Message-ID: <82C9F782B054C94B9FC04A331649C77A0C528D@FMSMSX106.amr.corp.intel.com> Pw is intel123 This is the last patch I sent out (see that emails for details) plus the latest # of PRP calc algorithm that's passed overnight testing on multiple systems running various data niteg test (plus it passes the unit tests of course) Thx Paul ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: source.zip Type: application/x-zip-compressed Size: 158748 bytes Desc: source.zip URL: From Alex.Chang at idt.com Tue Apr 24 09:55:36 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Tue, 24 Apr 2012 16:55:36 +0000 Subject: [nvmewin] Q Pointer Reset After Learning Mode In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0C528D@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A0C528D@FMSMSX106.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D36FF4F@corpmail1.na.ads.idt.com> Hi Paul, I am afraid that I have couple more issues to report: 1. When the driver finishes core-vector map learning, it deletes all IO queues and re-creates them. However, the driver doesn't reset Submission Tail Pointer and Completion Head Pointer to 0, which causes an extra completion entry for each IO queue and other side effects. 2. In NVMeCompleteCmd, the driver asserts to check Pending bit and Context pointer of CMD_ENTRY (for Checked-built driver only). Free-built driver ignores the checking and insert the CMD_ENTRY back to freeQList, which corrupts the linked-list when the completion queue entry is not a valid one and gets added back to the freeQList TWICE. For example, an extra completion entry produced by issue#1 above. I remember the original logic I put in was returning FALSE when it fails checking Pending bit and Context pointer and not touching the linked-list in the end of the routine. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Tue Apr 24 10:02:26 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Tue, 24 Apr 2012 17:02:26 +0000 Subject: [nvmewin] Q Pointer Reset After Learning Mode In-Reply-To: <548C5470AAD9DA4A85D259B663190D36FF4F@corpmail1.na.ads.idt.com> References: <82C9F782B054C94B9FC04A331649C77A0C528D@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D36FF4F@corpmail1.na.ads.idt.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0DADC8@FMSMSX106.amr.corp.intel.com> On item 1, it does. Look in NVMeInitSubQueue() which is indeed called after we've learned. On item 2 I believe we discussed only checking this in DBG case because, once validated, it should work all of the time. I'm not totally against a check in the free build as well but if it fails we'd need to set the error state for the driver because if our pending bit is set in this routine something really bad has happened. We can talk about it in the review and if we agree to look at it in the free case I can check it in as part of this patch. Thx Paul ULONG NVMeInitSubQueue( PNVME_DEVICE_EXTENSION pAE, USHORT QueueID ) { PQUEUE_INFO pQI = &pAE->QueueInfo; PSUB_QUEUE_INFO pSQI = pQI->pSubQueueInfo + QueueID; PRES_MAPPING_TBL pRMT = &pAE->ResMapTbl; ULONG_PTR PtrTemp = 0; USHORT Entries; /* Ensure the QueueID is valid via the number of active cores in system */ if (QueueID > pRMT->NumActiveCores) return ( STOR_STATUS_INVALID_PARAMETER ); /* Initialize static fields of SUB_QUEUE_INFO structure */ pSQI->SubQEntries = (QueueID != 0) ? pQI->NumIoQEntriesAllocated : pQI->NumAdQEntriesAllocated; pSQI->SubQueueID = QueueID; pSQI->FreeSubQEntries = pSQI->SubQEntries; pSQI->SubQTailPtr = 0; pSQI->SubQHeadPtr = 0; From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, April 24, 2012 9:56 AM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: Q Pointer Reset After Learning Mode Hi Paul, I am afraid that I have couple more issues to report: 1. When the driver finishes core-vector map learning, it deletes all IO queues and re-creates them. However, the driver doesn't reset Submission Tail Pointer and Completion Head Pointer to 0, which causes an extra completion entry for each IO queue and other side effects. 2. In NVMeCompleteCmd, the driver asserts to check Pending bit and Context pointer of CMD_ENTRY (for Checked-built driver only). Free-built driver ignores the checking and insert the CMD_ENTRY back to freeQList, which corrupts the linked-list when the completion queue entry is not a valid one and gets added back to the freeQList TWICE. For example, an extra completion entry produced by issue#1 above. I remember the original logic I put in was returning FALSE when it fails checking Pending bit and Context pointer and not touching the linked-list in the end of the routine. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Tue Apr 24 10:11:11 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Tue, 24 Apr 2012 17:11:11 +0000 Subject: [nvmewin] Q Pointer Reset After Learning Mode In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0DADC8@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A0C528D@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D36FF4F@corpmail1.na.ads.idt.com> <82C9F782B054C94B9FC04A331649C77A0DADC8@FMSMSX106.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D36FF68@corpmail1.na.ads.idt.com> Paul, NVMeInitSubQueue and NVMeInitCplQueue are called in NVMeWaitOnSetupQueues, which is before we first create IO queues. After we delete the queue and re-create them, the pointers are not reset. Thanks, Alex ________________________________ From: Luse, Paul E [mailto:paul.e.luse at intel.com] Sent: Tuesday, April 24, 2012 10:02 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: Q Pointer Reset After Learning Mode On item 1, it does. Look in NVMeInitSubQueue() which is indeed called after we've learned. On item 2 I believe we discussed only checking this in DBG case because, once validated, it should work all of the time. I'm not totally against a check in the free build as well but if it fails we'd need to set the error state for the driver because if our pending bit is set in this routine something really bad has happened. We can talk about it in the review and if we agree to look at it in the free case I can check it in as part of this patch. Thx Paul ULONG NVMeInitSubQueue( PNVME_DEVICE_EXTENSION pAE, USHORT QueueID ) { PQUEUE_INFO pQI = &pAE->QueueInfo; PSUB_QUEUE_INFO pSQI = pQI->pSubQueueInfo + QueueID; PRES_MAPPING_TBL pRMT = &pAE->ResMapTbl; ULONG_PTR PtrTemp = 0; USHORT Entries; /* Ensure the QueueID is valid via the number of active cores in system */ if (QueueID > pRMT->NumActiveCores) return ( STOR_STATUS_INVALID_PARAMETER ); /* Initialize static fields of SUB_QUEUE_INFO structure */ pSQI->SubQEntries = (QueueID != 0) ? pQI->NumIoQEntriesAllocated : pQI->NumAdQEntriesAllocated; pSQI->SubQueueID = QueueID; pSQI->FreeSubQEntries = pSQI->SubQEntries; pSQI->SubQTailPtr = 0; pSQI->SubQHeadPtr = 0; From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Tuesday, April 24, 2012 9:56 AM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: Q Pointer Reset After Learning Mode Hi Paul, I am afraid that I have couple more issues to report: 1. When the driver finishes core-vector map learning, it deletes all IO queues and re-creates them. However, the driver doesn't reset Submission Tail Pointer and Completion Head Pointer to 0, which causes an extra completion entry for each IO queue and other side effects. 2. In NVMeCompleteCmd, the driver asserts to check Pending bit and Context pointer of CMD_ENTRY (for Checked-built driver only). Free-built driver ignores the checking and insert the CMD_ENTRY back to freeQList, which corrupts the linked-list when the completion queue entry is not a valid one and gets added back to the freeQList TWICE. For example, an extra completion entry produced by issue#1 above. I remember the original logic I put in was returning FALSE when it fails checking Pending bit and Context pointer and not touching the linked-list in the end of the routine. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Tue Apr 24 10:52:13 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Tue, 24 Apr 2012 17:52:13 +0000 Subject: [nvmewin] SCSI compliance Message-ID: <82C9F782B054C94B9FC04A331649C77A0DB027@FMSMSX106.amr.corp.intel.com> FYI I fixed a few things reported by SCSI xlation test form Msft (read16/write16, one negative read_cap test) that we'll be looking at later today but we still fail write(1) but oit looks to me to be a tool issue. Just sent an email to Msft as someone else reported the same thing. Below is my busTRACE of this test clearly showing the odd sequence (different LBAs for the write and the read) [cid:image001.png at 01CD2208.4C8C7A90] ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 31068 bytes Desc: image001.png URL: -------------- next part -------------- An embedded message was scrubbed... From: "Luse, Paul E" Subject: Documentation feedback [wlk\wlk]: SCSI Compliance Test 2.0 (LOGO) RELEASE: (2/23/2012) Date: Tue, 24 Apr 2012 17:48:56 +0000 Size: 28666 URL: From paul.e.luse at intel.com Wed Apr 25 08:54:50 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Wed, 25 Apr 2012 15:54:50 +0000 Subject: [nvmewin] ***UNCHECKED*** binary for the pending release Message-ID: <82C9F782B054C94B9FC04A331649C77A0DC409@FMSMSX106.amr.corp.intel.com> pw is intel123. A few quick notes: - Both x86/64 fre and chk builds are included here - Source patch for these will be applied shortly - 3 addt'l changes since our review o Our ID ctrl stuct was missing 2 fields, IEEE and MAC o The struct for the COAL feature cmd had two fields in the wrong order o There was a typo in the INF for the x86 catalog file addition - I've run tests on the 64 bit versions so far, will look at 32 bit soon. - The attached are signed for the convenience of testing on the 64 bit. I actually don't have an issue posting these with my signature, again, for convenience only. Any issues with that from everyone? Also, we'll be covering the attached 2 slides at the NVME meeting this week, please review real quick and send any feedback by EOD Thx Paul ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nvme.zip Type: application/x-zip-compressed Size: 602181 bytes Desc: nvme.zip URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OFA NVMe Driver 2012.pptx Type: application/vnd.openxmlformats-officedocument.presentationml.presentation Size: 66422 bytes Desc: OFA NVMe Driver 2012.pptx URL: From raymond.c.robles at intel.com Wed Apr 25 14:01:11 2012 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Wed, 25 Apr 2012 21:01:11 +0000 Subject: [nvmewin] nvmewin DB is locked - merging latest learning mode and SGL changes Message-ID: <49158E750348AA499168FD41D88983600C39C863@FMSMSX105.amr.corp.intel.com> Thanks, Ray [Description: Description: Description: Description: cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles PSG Server Software Engineering Datacenter and Connected Systems Group Intel Corporation Office: 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 Apr 25 14:49:48 2012 From: raymond.c.robles at intel.com (Robles, Raymond C) Date: Wed, 25 Apr 2012 21:49:48 +0000 Subject: [nvmewin] nvmewin DB is unlocked - merging latest learning mode and SGL changes Message-ID: <49158E750348AA499168FD41D88983600C39C8AB@FMSMSX105.amr.corp.intel.com> The latest patch we reviewed yesterday has been applied. As usual, I created a tag for this revision and the trunk has the latest and greatest. Thanks, Ray From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Robles, Raymond C Sent: Wednesday, April 25, 2012 2:01 PM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] nvmewin DB is locked - merging latest learning mode and SGL changes Thanks, Ray [Description: Description: Description: Description: cid:image001.png at 01CB3870.4BB88E70] Raymond C. Robles PSG Server Software Engineering Datacenter and Connected Systems Group Intel Corporation Office: 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 paul.e.luse at intel.com Wed Apr 25 15:20:16 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Wed, 25 Apr 2012 22:20:16 +0000 Subject: [nvmewin] binary for the pending release Message-ID: <82C9F782B054C94B9FC04A331649C77A0DCCF1@FMSMSX106.amr.corp.intel.com> So my 32 bit testing didn't go so well. Works fine on Chatham but on qemu the initial ID ctrl command times out - I went back 2 patches and it still fails there as well so we went ahead with the check in since it's been broken for a while and seems to be a problem with a 32 bit VM on qemu (no issues with 64 bit). I don't have time to mess with it anymore so will put a comment in the release area when we post the binaries and won't post a 32 bit binary at all for now. If anyone want to debug, feel free but keep us all updated otherwise once of us at Intel will look at in the next month or so From: Luse, Paul E Sent: Wednesday, April 25, 2012 8:55 AM To: nvmewin at lists.openfabrics.org Subject: binary for the pending release pw is intel123. A few quick notes: - Both x86/64 fre and chk builds are included here - Source patch for these will be applied shortly - 3 addt'l changes since our review o Our ID ctrl stuct was missing 2 fields, IEEE and MAC o The struct for the COAL feature cmd had two fields in the wrong order o There was a typo in the INF for the x86 catalog file addition - I've run tests on the 64 bit versions so far, will look at 32 bit soon. - The attached are signed for the convenience of testing on the 64 bit. I actually don't have an issue posting these with my signature, again, for convenience only. Any issues with that from everyone? Also, we'll be covering the attached 2 slides at the NVME meeting this week, please review real quick and send any feedback by EOD Thx Paul ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Thu Apr 26 07:30:48 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Thu, 26 Apr 2012 14:30:48 +0000 Subject: [nvmewin] slides from this morn Message-ID: <82C9F782B054C94B9FC04A331649C77A0DE190@FMSMSX106.amr.corp.intel.com> >From the WG meeting this morning. Reminder: if you'd like to join the windows WG reflector visit the main NVMe website and click on the windows link, it will take you to the OFA windows WG page where you will find info on getting to the source/release as well as how to join the reflector ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OFA NVMe Driver 2012.pptx Type: application/vnd.openxmlformats-officedocument.presentationml.presentation Size: 66870 bytes Desc: OFA NVMe Driver 2012.pptx URL: From james.p.freyensee at intel.com Thu Apr 26 09:05:19 2012 From: james.p.freyensee at intel.com (Freyensee, James P) Date: Thu, 26 Apr 2012 16:05:19 +0000 Subject: [nvmewin] DBG question Message-ID: <2D98093777D3FD46A36253F35FE9D69346AD982F@ORSMSX101.amr.corp.intel.com> May I ask a fundamental question I see going on in the driver? What is the rationale behind debug blocks like: #if DBG DbgPrint("Complete CID 0x%x on 0x%x\n", pNVMeCmd->CDW0.CID, pSQI->SubQueueID); #endif I would have expected DbgPrint() to be already compiled out in 'release mode' , something like: #if "Microsoft Debug Build" #define DbgPrint(x...) do { \ fprintf(stderr, "Function: %s(), Line: %d-> ", __func__, __LINE__); \ fprintf(stderr, x); \ fprintf(stderr, "\n"); \ } while(0) #else #define DbgPrint(x...) #endif And not need the extra "DBG" #if around it in the actual code blocks. Though the MSDN page for DbgPrint does not really say what happens if code is compiled in "debug" build vs "release" build. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Thu Apr 26 09:17:29 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Thu, 26 Apr 2012 16:17:29 +0000 Subject: [nvmewin] DBG question In-Reply-To: <2D98093777D3FD46A36253F35FE9D69346AD982F@ORSMSX101.amr.corp.intel.com> References: <2D98093777D3FD46A36253F35FE9D69346AD982F@ORSMSX101.amr.corp.intel.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0DE354@FMSMSX106.amr.corp.intel.com> This is a storport miniport we use StorPortDebugPrint and use nt!Kd_STORMINIPORT_Mask to control the volume. The DbgPrint I think was there before we implemented the StorPort calls really doesn't really belong anywhere in the driver anymore. Next patch we can clean this up (whoever does the next patch). From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P Sent: Thursday, April 26, 2012 9:05 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] DBG question May I ask a fundamental question I see going on in the driver? What is the rationale behind debug blocks like: #if DBG DbgPrint("Complete CID 0x%x on 0x%x\n", pNVMeCmd->CDW0.CID, pSQI->SubQueueID); #endif I would have expected DbgPrint() to be already compiled out in 'release mode' , something like: #if "Microsoft Debug Build" #define DbgPrint(x...) do { \ fprintf(stderr, "Function: %s(), Line: %d-> ", __func__, __LINE__); \ fprintf(stderr, x); \ fprintf(stderr, "\n"); \ } while(0) #else #define DbgPrint(x...) #endif And not need the extra "DBG" #if around it in the actual code blocks. Though the MSDN page for DbgPrint does not really say what happens if code is compiled in "debug" build vs "release" build. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Thu Apr 26 16:45:52 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Thu, 26 Apr 2012 23:45:52 +0000 Subject: [nvmewin] binary for the pending release In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0DC409@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A0DC409@FMSMSX106.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D36010219@corpmail1.na.ads.idt.com> Hi Paul, I had fixed a race condition issue when using INTx interrupt and several errors found in nvme.h and nvmereg.h. I wonder if it's okay to add the changes to your patch. Please let me know. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Wednesday, April 25, 2012 8:55 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** binary for the pending release pw is intel123. A few quick notes: - Both x86/64 fre and chk builds are included here - Source patch for these will be applied shortly - 3 addt'l changes since our review o Our ID ctrl stuct was missing 2 fields, IEEE and MAC o The struct for the COAL feature cmd had two fields in the wrong order o There was a typo in the INF for the x86 catalog file addition - I've run tests on the 64 bit versions so far, will look at 32 bit soon. - The attached are signed for the convenience of testing on the 64 bit. I actually don't have an issue posting these with my signature, again, for convenience only. Any issues with that from everyone? Also, we'll be covering the attached 2 slides at the NVME meeting this week, please review real quick and send any feedback by EOD Thx Paul ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Thu Apr 26 16:55:07 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Thu, 26 Apr 2012 23:55:07 +0000 Subject: [nvmewin] binary for the pending release In-Reply-To: <548C5470AAD9DA4A85D259B663190D36010219@corpmail1.na.ads.idt.com> References: <82C9F782B054C94B9FC04A331649C77A0DC409@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D36010219@corpmail1.na.ads.idt.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0DFA1D@FMSMSX106.amr.corp.intel.com> The patch has already been applied so go ahead and start a new one based on the latest, make the changes, test and send to the list for review. Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, April 26, 2012 4:46 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release Hi Paul, I had fixed a race condition issue when using INTx interrupt and several errors found in nvme.h and nvmereg.h. I wonder if it's okay to add the changes to your patch. Please let me know. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Wednesday, April 25, 2012 8:55 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** binary for the pending release pw is intel123. A few quick notes: - Both x86/64 fre and chk builds are included here - Source patch for these will be applied shortly - 3 addt'l changes since our review o Our ID ctrl stuct was missing 2 fields, IEEE and MAC o The struct for the COAL feature cmd had two fields in the wrong order o There was a typo in the INF for the x86 catalog file addition - I've run tests on the 64 bit versions so far, will look at 32 bit soon. - The attached are signed for the convenience of testing on the 64 bit. I actually don't have an issue posting these with my signature, again, for convenience only. Any issues with that from everyone? Also, we'll be covering the attached 2 slides at the NVME meeting this week, please review real quick and send any feedback by EOD Thx Paul ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Thu Apr 26 18:14:03 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Fri, 27 Apr 2012 01:14:03 +0000 Subject: [nvmewin] binary for the pending release In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0DFA1D@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A0DC409@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D36010219@corpmail1.na.ads.idt.com>, <82C9F782B054C94B9FC04A331649C77A0DFA1D@FMSMSX106.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D3601025E@corpmail1.na.ads.idt.com> I see. I will prepare a new patch then. Thanks, Alex ________________________________ From: Luse, Paul E [paul.e.luse at intel.com] Sent: Thursday, April 26, 2012 4:55 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release The patch has already been applied so go ahead and start a new one based on the latest, make the changes, test and send to the list for review. Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, April 26, 2012 4:46 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release Hi Paul, I had fixed a race condition issue when using INTx interrupt and several errors found in nvme.h and nvmereg.h. I wonder if it's okay to add the changes to your patch. Please let me know. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Wednesday, April 25, 2012 8:55 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** binary for the pending release pw is intel123. A few quick notes: - Both x86/64 fre and chk builds are included here - Source patch for these will be applied shortly - 3 addt’l changes since our review o Our ID ctrl stuct was missing 2 fields, IEEE and MAC o The struct for the COAL feature cmd had two fields in the wrong order o There was a typo in the INF for the x86 catalog file addition - I’ve run tests on the 64 bit versions so far, will look at 32 bit soon. - The attached are signed for the convenience of testing on the 64 bit. I actually don’t have an issue posting these with my signature, again, for convenience only. Any issues with that from everyone? Also, we’ll be covering the attached 2 slides at the NVME meeting this week, please review real quick and send any feedback by EOD Thx Paul ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Thu Apr 26 19:00:45 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Fri, 27 Apr 2012 02:00:45 +0000 Subject: [nvmewin] binary for the pending release In-Reply-To: <548C5470AAD9DA4A85D259B663190D3601025E@corpmail1.na.ads.idt.com> References: <82C9F782B054C94B9FC04A331649C77A0DC409@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D36010219@corpmail1.na.ads.idt.com>, <82C9F782B054C94B9FC04A331649C77A0DFA1D@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D3601025E@corpmail1.na.ads.idt.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0E1DB0@FMSMSX106.amr.corp.intel.com> Cool, do you believe we need to hold the release for these - if so can you explain the impact of not doing so? Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, April 26, 2012 6:14 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release I see. I will prepare a new patch then. Thanks, Alex ________________________________ From: Luse, Paul E [paul.e.luse at intel.com] Sent: Thursday, April 26, 2012 4:55 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release The patch has already been applied so go ahead and start a new one based on the latest, make the changes, test and send to the list for review. Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, April 26, 2012 4:46 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release Hi Paul, I had fixed a race condition issue when using INTx interrupt and several errors found in nvme.h and nvmereg.h. I wonder if it's okay to add the changes to your patch. Please let me know. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Wednesday, April 25, 2012 8:55 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** binary for the pending release pw is intel123. A few quick notes: - Both x86/64 fre and chk builds are included here - Source patch for these will be applied shortly - 3 addt'l changes since our review o Our ID ctrl stuct was missing 2 fields, IEEE and MAC o The struct for the COAL feature cmd had two fields in the wrong order o There was a typo in the INF for the x86 catalog file addition - I've run tests on the 64 bit versions so far, will look at 32 bit soon. - The attached are signed for the convenience of testing on the 64 bit. I actually don't have an issue posting these with my signature, again, for convenience only. Any issues with that from everyone? Also, we'll be covering the attached 2 slides at the NVME meeting this week, please review real quick and send any feedback by EOD Thx Paul ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Thu Apr 26 19:47:34 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Fri, 27 Apr 2012 02:47:34 +0000 Subject: [nvmewin] binary for the pending release In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0E1DB0@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A0DC409@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D36010219@corpmail1.na.ads.idt.com>, <82C9F782B054C94B9FC04A331649C77A0DFA1D@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D3601025E@corpmail1.na.ads.idt.com>, <82C9F782B054C94B9FC04A331649C77A0E1DB0@FMSMSX106.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D36010274@corpmail1.na.ads.idt.com> The race condition issue of INTx can be easily re-produced and it has two problems: 1. Masking/Unmasking logic: When NVMeIsrIntx gets called, it should not assign pAE->IntxMasked as FALSE. Instead, we should do something related to masking/unmasking only when we confirm the ownership, i.e., there is pending completions. When DPC is called, after fetching valid completed entry, mask the interrupt and then mark pAE->IntMasked as TRUE. Before exiting DPC, check pAE->IntMasked, unmask it and set pAE->IntMasked as FALSE only when pAE->IntMasked is TRUE. 2. Interrupt ownership claiming: the driver always claims the interrupt, which may cause some device malfunction when sharing the interrupt. The errors I found in nvme.h and nvmereg.h are also quite mismatching with NVMe specification 1.0b. For example, when using Set Features command to configure interrupt coalescing, the both fields of DW11, aggregation time and threshold, are swapped. Thanks, Alex ________________________________ From: Luse, Paul E [paul.e.luse at intel.com] Sent: Thursday, April 26, 2012 7:00 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release Cool, do you believe we need to hold the release for these – if so can you explain the impact of not doing so? Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, April 26, 2012 6:14 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release I see. I will prepare a new patch then. Thanks, Alex ________________________________ From: Luse, Paul E [paul.e.luse at intel.com] Sent: Thursday, April 26, 2012 4:55 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release The patch has already been applied so go ahead and start a new one based on the latest, make the changes, test and send to the list for review. Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, April 26, 2012 4:46 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release Hi Paul, I had fixed a race condition issue when using INTx interrupt and several errors found in nvme.h and nvmereg.h. I wonder if it's okay to add the changes to your patch. Please let me know. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Wednesday, April 25, 2012 8:55 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** binary for the pending release pw is intel123. A few quick notes: - Both x86/64 fre and chk builds are included here - Source patch for these will be applied shortly - 3 addt’l changes since our review o Our ID ctrl stuct was missing 2 fields, IEEE and MAC o The struct for the COAL feature cmd had two fields in the wrong order o There was a typo in the INF for the x86 catalog file addition - I’ve run tests on the 64 bit versions so far, will look at 32 bit soon. - The attached are signed for the convenience of testing on the 64 bit. I actually don’t have an issue posting these with my signature, again, for convenience only. Any issues with that from everyone? Also, we’ll be covering the attached 2 slides at the NVME meeting this week, please review real quick and send any feedback by EOD Thx Paul ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Thu Apr 26 19:51:39 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Fri, 27 Apr 2012 02:51:39 +0000 Subject: [nvmewin] binary for the pending release In-Reply-To: <548C5470AAD9DA4A85D259B663190D36010274@corpmail1.na.ads.idt.com> References: <82C9F782B054C94B9FC04A331649C77A0DC409@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D36010219@corpmail1.na.ads.idt.com>, <82C9F782B054C94B9FC04A331649C77A0DFA1D@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D3601025E@corpmail1.na.ads.idt.com>, <82C9F782B054C94B9FC04A331649C77A0E1DB0@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D36010274@corpmail1.na.ads.idt.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0E1E77@FMSMSX106.amr.corp.intel.com> OK, personally I think 1 and 2 can be resolved later and on your last comment did you look at the code before the last patch? The example you have has already been fixed in addition to a few fields that were missing the ID ctrl section. What is your opinion of 1 and 2 holding up the release and you can confirm whether you looked at the latest patch or not? Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, April 26, 2012 7:48 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release The race condition issue of INTx can be easily re-produced and it has two problems: 1. Masking/Unmasking logic: When NVMeIsrIntx gets called, it should not assign pAE->IntxMasked as FALSE. Instead, we should do something related to masking/unmasking only when we confirm the ownership, i.e., there is pending completions. When DPC is called, after fetching valid completed entry, mask the interrupt and then mark pAE->IntMasked as TRUE. Before exiting DPC, check pAE->IntMasked, unmask it and set pAE->IntMasked as FALSE only when pAE->IntMasked is TRUE. 2. Interrupt ownership claiming: the driver always claims the interrupt, which may cause some device malfunction when sharing the interrupt. The errors I found in nvme.h and nvmereg.h are also quite mismatching with NVMe specification 1.0b. For example, when using Set Features command to configure interrupt coalescing, the both fields of DW11, aggregation time and threshold, are swapped. Thanks, Alex ________________________________ From: Luse, Paul E [paul.e.luse at intel.com] Sent: Thursday, April 26, 2012 7:00 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release Cool, do you believe we need to hold the release for these - if so can you explain the impact of not doing so? Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, April 26, 2012 6:14 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release I see. I will prepare a new patch then. Thanks, Alex ________________________________ From: Luse, Paul E [paul.e.luse at intel.com] Sent: Thursday, April 26, 2012 4:55 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release The patch has already been applied so go ahead and start a new one based on the latest, make the changes, test and send to the list for review. Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, April 26, 2012 4:46 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release Hi Paul, I had fixed a race condition issue when using INTx interrupt and several errors found in nvme.h and nvmereg.h. I wonder if it's okay to add the changes to your patch. Please let me know. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Wednesday, April 25, 2012 8:55 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** binary for the pending release pw is intel123. A few quick notes: - Both x86/64 fre and chk builds are included here - Source patch for these will be applied shortly - 3 addt'l changes since our review o Our ID ctrl stuct was missing 2 fields, IEEE and MAC o The struct for the COAL feature cmd had two fields in the wrong order o There was a typo in the INF for the x86 catalog file addition - I've run tests on the 64 bit versions so far, will look at 32 bit soon. - The attached are signed for the convenience of testing on the 64 bit. I actually don't have an issue posting these with my signature, again, for convenience only. Any issues with that from everyone? Also, we'll be covering the attached 2 slides at the NVME meeting this week, please review real quick and send any feedback by EOD Thx Paul ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Fri Apr 27 10:31:58 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Fri, 27 Apr 2012 17:31:58 +0000 Subject: [nvmewin] binary for the pending release In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0E1E77@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A0DC409@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D36010219@corpmail1.na.ads.idt.com>, <82C9F782B054C94B9FC04A331649C77A0DFA1D@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D3601025E@corpmail1.na.ads.idt.com>, <82C9F782B054C94B9FC04A331649C77A0E1DB0@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D36010274@corpmail1.na.ads.idt.com> <82C9F782B054C94B9FC04A331649C77A0E1E77@FMSMSX106.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D360102C9@corpmail1.na.ads.idt.com> Paul, Basically, we don't want to hold up the release. Kwok agrees that we can wait until next release then. By the way, I added AVSCC/NVSCC (defined in ECN_23) in the PT_IOCTL patch a while back. In the current sources, they are removed. I wonder why? In the "Learning Mode" tag, it still has them. Thanks, Alex ________________________________ From: Luse, Paul E [mailto:paul.e.luse at intel.com] Sent: Thursday, April 26, 2012 7:52 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release OK, personally I think 1 and 2 can be resolved later and on your last comment did you look at the code before the last patch? The example you have has already been fixed in addition to a few fields that were missing the ID ctrl section. What is your opinion of 1 and 2 holding up the release and you can confirm whether you looked at the latest patch or not? Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, April 26, 2012 7:48 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release The race condition issue of INTx can be easily re-produced and it has two problems: 1. Masking/Unmasking logic: When NVMeIsrIntx gets called, it should not assign pAE->IntxMasked as FALSE. Instead, we should do something related to masking/unmasking only when we confirm the ownership, i.e., there is pending completions. When DPC is called, after fetching valid completed entry, mask the interrupt and then mark pAE->IntMasked as TRUE. Before exiting DPC, check pAE->IntMasked, unmask it and set pAE->IntMasked as FALSE only when pAE->IntMasked is TRUE. 2. Interrupt ownership claiming: the driver always claims the interrupt, which may cause some device malfunction when sharing the interrupt. The errors I found in nvme.h and nvmereg.h are also quite mismatching with NVMe specification 1.0b. For example, when using Set Features command to configure interrupt coalescing, the both fields of DW11, aggregation time and threshold, are swapped. Thanks, Alex ________________________________ From: Luse, Paul E [paul.e.luse at intel.com] Sent: Thursday, April 26, 2012 7:00 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release Cool, do you believe we need to hold the release for these - if so can you explain the impact of not doing so? Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, April 26, 2012 6:14 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release I see. I will prepare a new patch then. Thanks, Alex ________________________________ From: Luse, Paul E [paul.e.luse at intel.com] Sent: Thursday, April 26, 2012 4:55 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release The patch has already been applied so go ahead and start a new one based on the latest, make the changes, test and send to the list for review. Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, April 26, 2012 4:46 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release Hi Paul, I had fixed a race condition issue when using INTx interrupt and several errors found in nvme.h and nvmereg.h. I wonder if it's okay to add the changes to your patch. Please let me know. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Wednesday, April 25, 2012 8:55 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** binary for the pending release pw is intel123. A few quick notes: - Both x86/64 fre and chk builds are included here - Source patch for these will be applied shortly - 3 addt'l changes since our review o Our ID ctrl stuct was missing 2 fields, IEEE and MAC o The struct for the COAL feature cmd had two fields in the wrong order o There was a typo in the INF for the x86 catalog file addition - I've run tests on the 64 bit versions so far, will look at 32 bit soon. - The attached are signed for the convenience of testing on the 64 bit. I actually don't have an issue posting these with my signature, again, for convenience only. Any issues with that from everyone? Also, we'll be covering the attached 2 slides at the NVME meeting this week, please review real quick and send any feedback by EOD Thx Paul ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kens at openfabrics.org Fri Apr 27 11:02:00 2012 From: kens at openfabrics.org (Ken Strandberg) Date: Fri, 27 Apr 2012 11:02:00 -0700 Subject: [nvmewin] Server migration Message-ID: In the next month, the OFA will be running from a new server. Nothing exciting in terms of processing and memory - those specs are the same - but much more disk space (/home is nearly full on sofa), and at quite a bit less cost. A new IMAP mail service will be available if you want it. The new server is called beany.openfabrics.org. And it's still being hosted by the same service provider, so bandwidth, availability, reliability, etc. will be the same from them. At this point, not data on sofa will change and you will still run from sofa. Everything will migrate over to beany, and it will become our list server, mail server, git, web, etc. This email is to inform those with user accounts that I will back up the sofa:/home directory and then rsync beany:/home with sofa:/home for user data this weekend. User accounts and the /home directory have already been set up, but the filesystems aren't sync'd yet. Once I do that, and I'll notify when it's done, I'd appreciate all users to check their home directories on beany and let me know if they see any abnormalities. Then I will make sure all other systems are in place and running on beany before doing one more sync, after which you will be responsible for your files. Again, at this time, I will NOT affect any data on sofa and you will still run from it. I realize that some users will not get this email before I rsync this weekend; but your data will not be affected on sofa. After that, I will keep sofa up and available for a couple more weeks, cp all /home directories to an archive space on beany that will be accessible in case there are some users who still need to access existing data as of the crossover date, tar /home offsite, and eventually remove the /home archive from beany over the months. Sofa will be decommissioned by the end of May. Anyone with any concerns, requests, issues, recommendations, etc. please reply to me only at kens at openfabrics.org. -- *Ken Strandberg* *Webmanager/SysAdmin* *OpenFabrics Alliance* kens at openfabrics.org www.openfabrics.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.e.luse at intel.com Fri Apr 27 11:57:53 2012 From: paul.e.luse at intel.com (Luse, Paul E) Date: Fri, 27 Apr 2012 18:57:53 +0000 Subject: [nvmewin] binary for the pending release In-Reply-To: <548C5470AAD9DA4A85D259B663190D360102C9@corpmail1.na.ads.idt.com> References: <82C9F782B054C94B9FC04A331649C77A0DC409@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D36010219@corpmail1.na.ads.idt.com>, <82C9F782B054C94B9FC04A331649C77A0DFA1D@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D3601025E@corpmail1.na.ads.idt.com>, <82C9F782B054C94B9FC04A331649C77A0E1DB0@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D36010274@corpmail1.na.ads.idt.com> <82C9F782B054C94B9FC04A331649C77A0E1E77@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D360102C9@corpmail1.na.ads.idt.com> Message-ID: <82C9F782B054C94B9FC04A331649C77A0E27F3@FMSMSX106.amr.corp.intel.com> Cool, sorry I pulled those not realizing they were from an ECN. Feel free to add them back with your upcoming patch - my bad J From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Friday, April 27, 2012 10:32 AM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release Paul, Basically, we don't want to hold up the release. Kwok agrees that we can wait until next release then. By the way, I added AVSCC/NVSCC (defined in ECN_23) in the PT_IOCTL patch a while back. In the current sources, they are removed. I wonder why? In the "Learning Mode" tag, it still has them. Thanks, Alex ________________________________ From: Luse, Paul E [mailto:paul.e.luse at intel.com] Sent: Thursday, April 26, 2012 7:52 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release OK, personally I think 1 and 2 can be resolved later and on your last comment did you look at the code before the last patch? The example you have has already been fixed in addition to a few fields that were missing the ID ctrl section. What is your opinion of 1 and 2 holding up the release and you can confirm whether you looked at the latest patch or not? Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, April 26, 2012 7:48 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release The race condition issue of INTx can be easily re-produced and it has two problems: 1. Masking/Unmasking logic: When NVMeIsrIntx gets called, it should not assign pAE->IntxMasked as FALSE. Instead, we should do something related to masking/unmasking only when we confirm the ownership, i.e., there is pending completions. When DPC is called, after fetching valid completed entry, mask the interrupt and then mark pAE->IntMasked as TRUE. Before exiting DPC, check pAE->IntMasked, unmask it and set pAE->IntMasked as FALSE only when pAE->IntMasked is TRUE. 2. Interrupt ownership claiming: the driver always claims the interrupt, which may cause some device malfunction when sharing the interrupt. The errors I found in nvme.h and nvmereg.h are also quite mismatching with NVMe specification 1.0b. For example, when using Set Features command to configure interrupt coalescing, the both fields of DW11, aggregation time and threshold, are swapped. Thanks, Alex ________________________________ From: Luse, Paul E [paul.e.luse at intel.com] Sent: Thursday, April 26, 2012 7:00 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release Cool, do you believe we need to hold the release for these - if so can you explain the impact of not doing so? Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, April 26, 2012 6:14 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release I see. I will prepare a new patch then. Thanks, Alex ________________________________ From: Luse, Paul E [paul.e.luse at intel.com] Sent: Thursday, April 26, 2012 4:55 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release The patch has already been applied so go ahead and start a new one based on the latest, make the changes, test and send to the list for review. Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, April 26, 2012 4:46 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release Hi Paul, I had fixed a race condition issue when using INTx interrupt and several errors found in nvme.h and nvmereg.h. I wonder if it's okay to add the changes to your patch. Please let me know. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Wednesday, April 25, 2012 8:55 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** binary for the pending release pw is intel123. A few quick notes: - Both x86/64 fre and chk builds are included here - Source patch for these will be applied shortly - 3 addt'l changes since our review o Our ID ctrl stuct was missing 2 fields, IEEE and MAC o The struct for the COAL feature cmd had two fields in the wrong order o There was a typo in the INF for the x86 catalog file addition - I've run tests on the 64 bit versions so far, will look at 32 bit soon. - The attached are signed for the convenience of testing on the 64 bit. I actually don't have an issue posting these with my signature, again, for convenience only. Any issues with that from everyone? Also, we'll be covering the attached 2 slides at the NVME meeting this week, please review real quick and send any feedback by EOD Thx Paul ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Chang at idt.com Fri Apr 27 13:05:41 2012 From: Alex.Chang at idt.com (Chang, Alex) Date: Fri, 27 Apr 2012 20:05:41 +0000 Subject: [nvmewin] binary for the pending release In-Reply-To: <82C9F782B054C94B9FC04A331649C77A0E27F3@FMSMSX106.amr.corp.intel.com> References: <82C9F782B054C94B9FC04A331649C77A0DC409@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D36010219@corpmail1.na.ads.idt.com>, <82C9F782B054C94B9FC04A331649C77A0DFA1D@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D3601025E@corpmail1.na.ads.idt.com>, <82C9F782B054C94B9FC04A331649C77A0E1DB0@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D36010274@corpmail1.na.ads.idt.com> <82C9F782B054C94B9FC04A331649C77A0E1E77@FMSMSX106.amr.corp.intel.com> <548C5470AAD9DA4A85D259B663190D360102C9@corpmail1.na.ads.idt.com> <82C9F782B054C94B9FC04A331649C77A0E27F3@FMSMSX106.amr.corp.intel.com> Message-ID: <548C5470AAD9DA4A85D259B663190D36010326@corpmail1.na.ads.idt.com> It's okay, Paul. I will them back then. Thanks, Alex ________________________________ From: Luse, Paul E [mailto:paul.e.luse at intel.com] Sent: Friday, April 27, 2012 11:58 AM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release Cool, sorry I pulled those not realizing they were from an ECN. Feel free to add them back with your upcoming patch - my bad J From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Friday, April 27, 2012 10:32 AM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release Paul, Basically, we don't want to hold up the release. Kwok agrees that we can wait until next release then. By the way, I added AVSCC/NVSCC (defined in ECN_23) in the PT_IOCTL patch a while back. In the current sources, they are removed. I wonder why? In the "Learning Mode" tag, it still has them. Thanks, Alex ________________________________ From: Luse, Paul E [mailto:paul.e.luse at intel.com] Sent: Thursday, April 26, 2012 7:52 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release OK, personally I think 1 and 2 can be resolved later and on your last comment did you look at the code before the last patch? The example you have has already been fixed in addition to a few fields that were missing the ID ctrl section. What is your opinion of 1 and 2 holding up the release and you can confirm whether you looked at the latest patch or not? Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, April 26, 2012 7:48 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release The race condition issue of INTx can be easily re-produced and it has two problems: 1. Masking/Unmasking logic: When NVMeIsrIntx gets called, it should not assign pAE->IntxMasked as FALSE. Instead, we should do something related to masking/unmasking only when we confirm the ownership, i.e., there is pending completions. When DPC is called, after fetching valid completed entry, mask the interrupt and then mark pAE->IntMasked as TRUE. Before exiting DPC, check pAE->IntMasked, unmask it and set pAE->IntMasked as FALSE only when pAE->IntMasked is TRUE. 2. Interrupt ownership claiming: the driver always claims the interrupt, which may cause some device malfunction when sharing the interrupt. The errors I found in nvme.h and nvmereg.h are also quite mismatching with NVMe specification 1.0b. For example, when using Set Features command to configure interrupt coalescing, the both fields of DW11, aggregation time and threshold, are swapped. Thanks, Alex ________________________________ From: Luse, Paul E [paul.e.luse at intel.com] Sent: Thursday, April 26, 2012 7:00 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release Cool, do you believe we need to hold the release for these - if so can you explain the impact of not doing so? Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, April 26, 2012 6:14 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release I see. I will prepare a new patch then. Thanks, Alex ________________________________ From: Luse, Paul E [paul.e.luse at intel.com] Sent: Thursday, April 26, 2012 4:55 PM To: Chang, Alex; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release The patch has already been applied so go ahead and start a new one based on the latest, make the changes, test and send to the list for review. Thx Paul From: Chang, Alex [mailto:Alex.Chang at idt.com] Sent: Thursday, April 26, 2012 4:46 PM To: Luse, Paul E; nvmewin at lists.openfabrics.org Subject: RE: binary for the pending release Hi Paul, I had fixed a race condition issue when using INTx interrupt and several errors found in nvme.h and nvmereg.h. I wonder if it's okay to add the changes to your patch. Please let me know. Thanks, Alex ________________________________ From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E Sent: Wednesday, April 25, 2012 8:55 AM To: nvmewin at lists.openfabrics.org Subject: [nvmewin] ***UNCHECKED*** binary for the pending release pw is intel123. A few quick notes: - Both x86/64 fre and chk builds are included here - Source patch for these will be applied shortly - 3 addt'l changes since our review o Our ID ctrl stuct was missing 2 fields, IEEE and MAC o The struct for the COAL feature cmd had two fields in the wrong order o There was a typo in the INF for the x86 catalog file addition - I've run tests on the 64 bit versions so far, will look at 32 bit soon. - The attached are signed for the convenience of testing on the 64 bit. I actually don't have an issue posting these with my signature, again, for convenience only. Any issues with that from everyone? Also, we'll be covering the attached 2 slides at the NVME meeting this week, please review real quick and send any feedback by EOD Thx Paul ____________________________________ Paul Luse Sr. Staff Engineer PCG Server Software Engineering Desk: 480.554.3688, Mobile: 480.334.4630 -------------- next part -------------- An HTML attachment was scrubbed... URL: From v25ravi at gmail.com Sun Apr 29 22:31:59 2012 From: v25ravi at gmail.com (Ravi Kumar) Date: Mon, 30 Apr 2012 11:01:59 +0530 Subject: [nvmewin] StartIo Function Return value for NVMePowerControl Message-ID: Hi, As per observation on Windows the function NVMeStarIo(NVMeStd.c) for Power management, in case NVMePowerControl() returns false it is still completed the request in NVMeStartIo and returns FALSE to StorPort driver. Whereas in case of StartIo returns FALSE StorPort driver treats IO has some issue and try to complete its own in AdapterControl call which create the BSOD to system (Multiple_IO_Request_Complete error). Don't we required to put the check in case failure of handle the power management system need not to be complete the Io as PortDriver makes it complete its own. Regards, Ravi Kumar -------------- next part -------------- An HTML attachment was scrubbed... URL: