[nvmewin] binary for the pending release

[Chang, Alex]

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]<mailto:[mailto:paul.e.luse at intel.com]>
Sent: Thursday, April 26, 2012 7:52 PM
To: Chang, Alex; nvmewin at lists.openfabrics.org<mailto: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]<mailto:[mailto:Alex.Chang at idt.com]>
Sent: Thursday, April 26, 2012 7:48 PM
To: Luse, Paul E; nvmewin at lists.openfabrics.org<mailto: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<mailto: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]<mailto:[mailto:Alex.Chang at idt.com]>
Sent: Thursday, April 26, 2012 6:14 PM
To: Luse, Paul E; nvmewin at lists.openfabrics.org<mailto: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<mailto: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]<mailto:[mailto:Alex.Chang at idt.com]>
Sent: Thursday, April 26, 2012 4:46 PM
To: Luse, Paul E; nvmewin at lists.openfabrics.org<mailto: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> [mailto:nvmewin-bounces at lists.openfabrics.org]<mailto:[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<mailto: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: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20120427/a43ee1de/attachment.html>