From Thomas.Freeman at hgst.com  Sat Feb  1 14:01:39 2014
From: Thomas.Freeman at hgst.com (Thomas.Freeman at hgst.com)
Date: Sat, 1 Feb 2014 16:01:39 -0600
Subject: [nvmewin] Static Driver Verification
Message-ID: <OFD0B804F5.DB9A9A18-ON88257C72.00757CE5-86257C72.00790087@hgst.com>



I'm new to HCK testing, but I understand part of the testing requires a
Driver Verification Log (which contains the results from Code Analysis and
Static Driver Verifier). This is required for the Static Tools Logo test
(under the Device.Fundamentals category).
When I run those tools, I'm getting a large number of errors. The code
analysis shows over 50 warnings and the Static Driver Verifier fails
because the Callback roletypes (sp_DRIVER_INITIALIZE, HW_INITIALIZE, etc)
are not defined. Fixing the roletypes allows a new set of errors to appear.
I'm running with VS 2013 and WDK 8.1.
Am I missing something? Has anyone else run these tools against the code?


Tom Freeman
SSD Device Drivers/Firmware
HGST, a Western Digital company
Thomas.Freeman at HGST.com
507-322-2311/232311



From Thomas.Freeman at hgst.com  Mon Feb  3 16:12:26 2014
From: Thomas.Freeman at hgst.com (Thomas.Freeman at hgst.com)
Date: Mon, 3 Feb 2014 18:12:26 -0600
Subject: [nvmewin] Static Driver Verification
In-Reply-To: <BC85AFAC9186CE40AEDB53E064077E863CD5B745@sacexcmbx05-prd.hq.netapp.com>
Message-ID: <OF95CBC811.E280675D-ON88257C75.0000841F-86257C75.000123BA@hgst.com>

Kenny.... Not sure if you've tried to run this yet.... I ran into a problem
running the SDV in a Windows 8/x64 config.
I get a message saying that there aren't enough parms being passed into
StorPortReadRegisterUlong64.
To work around this, I went into sdv_storport.h
(WindowsKits/8.1/Tools/sdv/osmodel/storport). I made the
StorPortReadRegisterUlong64 prototype there match the prototype in
storport.h.
I've reported this to Microsoft and they are working on a permanent fix.

Tom Freeman
SSD Device Drivers/Firmware
HGST, a Western Digital company
Thomas.Freeman at HGST.com
507-322-2311/232311



                                                                           
             "Speer, Kenny"                                                
             <Kenny.Speer at neta                                             
             pp.com>                                                    To 
                                       "Thomas.Freeman at hgst.com"           
             02/01/2014 05:37          <Thomas.Freeman at hgst.com>,          
             PM                        "nvmewin at lists.openfabrics.org"     
                                       <nvmewin at lists.openfabrics.org>     
                                                                        cc 
                                                                           
                                                                   Subject 
                                       RE: [nvmewin] Static Driver         
                                       Verification                        
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Yes and IMHO, those need to be fixed and the tools should run error/warning
free.  The majority of the warnings are due to annotations which exist in
the definitions of the functions but not in their declarations.

It's good practice, again, IMO, to annotate and to do it in both. See
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383701
(v=vs.85).aspx for more info on SAL annotations.

Haven't run SDV yet, I'll do that now, not sure how long it takes on this
solution but on my other projects it takes 8 hours on a 4 core i7 with 32G
mem.

~kenny

-----Original Message-----
From: nvmewin-bounces at lists.openfabrics.org
[mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of
Thomas.Freeman at hgst.com
Sent: Saturday, February 1, 2014 2:02 PM
To: nvmewin at lists.openfabrics.org
Subject: [nvmewin] Static Driver Verification



I'm new to HCK testing, but I understand part of the testing requires a
Driver Verification Log (which contains the results from Code Analysis and
Static Driver Verifier). This is required for the Static Tools Logo test
(under the Device.Fundamentals category).
When I run those tools, I'm getting a large number of errors. The code
analysis shows over 50 warnings and the Static Driver Verifier fails
because the Callback roletypes (sp_DRIVER_INITIALIZE, HW_INITIALIZE, etc)
are not defined. Fixing the roletypes allows a new set of errors to appear.
I'm running with VS 2013 and WDK 8.1.
Am I missing something? Has anyone else run these tools against the code?


Tom Freeman
SSD Device Drivers/Firmware
HGST, a Western Digital company
Thomas.Freeman at HGST.com
507-322-2311/232311

_______________________________________________
nvmewin mailing list
nvmewin at lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin




From Thomas.Freeman at hgst.com  Tue Feb  4 06:54:19 2014
From: Thomas.Freeman at hgst.com (Thomas.Freeman at hgst.com)
Date: Tue, 4 Feb 2014 08:54:19 -0600
Subject: [nvmewin] Static Driver Verification
In-Reply-To: <BC85AFAC9186CE40AEDB53E064077E863CD7371A@SACEXCMBX01-PRD.hq.netapp.com>
Message-ID: <OF2009FEB7.DC3E7DD0-ON88257C75.0051CCF8-86257C75.0051E0AF@hgst.com>

I'm working with code from revision_1.2.
Tom Freeman
SSD Device Drivers/Firmware
HGST, a Western Digital company
Thomas.Freeman at HGST.com
507-322-2311/232311



                                                                           
             "Speer, Kenny"                                                
             <Kenny.Speer at neta                                             
             pp.com>                                                    To 
                                       "Thomas.Freeman at hgst.com"           
             02/03/2014 06:15          <Thomas.Freeman at hgst.com>           
             PM                                                         cc 
                                       "nvmewin at lists.openfabrics.org"     
                                       <nvmewin at lists.openfabrics.org>     
                                                                   Subject 
                                       RE: [nvmewin] Static Driver         
                                       Verification                        
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




I did briefly but ran into other issues.  Which branch are you building
from?

-----Original Message-----
From: Thomas.Freeman at hgst.com [mailto:Thomas.Freeman at hgst.com]
Sent: Monday, February 3, 2014 4:12 PM
To: Speer, Kenny
Cc: nvmewin at lists.openfabrics.org
Subject: RE: [nvmewin] Static Driver Verification

Kenny.... Not sure if you've tried to run this yet.... I ran into a problem
running the SDV in a Windows 8/x64 config.
I get a message saying that there aren't enough parms being passed into
StorPortReadRegisterUlong64.
To work around this, I went into sdv_storport.h
(WindowsKits/8.1/Tools/sdv/osmodel/storport). I made the
StorPortReadRegisterUlong64 prototype there match the prototype in
storport.h.
I've reported this to Microsoft and they are working on a permanent fix.

Tom Freeman
SSD Device Drivers/Firmware
HGST, a Western Digital company
Thomas.Freeman at HGST.com
507-322-2311/232311




             "Speer, Kenny"
             <Kenny.Speer at neta
             pp.com>                                                    To
                                       "Thomas.Freeman at hgst.com"
             02/01/2014 05:37          <Thomas.Freeman at hgst.com>,
             PM                        "nvmewin at lists.openfabrics.org"
                                       <nvmewin at lists.openfabrics.org>
                                                                        cc

                                                                   Subject
                                       RE: [nvmewin] Static Driver
                                       Verification










Yes and IMHO, those need to be fixed and the tools should run error/warning
free.  The majority of the warnings are due to annotations which exist in
the definitions of the functions but not in their declarations.

It's good practice, again, IMO, to annotate and to do it in both. See
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383701
(v=vs.85).aspx for more info on SAL annotations.

Haven't run SDV yet, I'll do that now, not sure how long it takes on this
solution but on my other projects it takes 8 hours on a 4 core i7 with 32G
mem.

~kenny

-----Original Message-----
From: nvmewin-bounces at lists.openfabrics.org
[mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of
Thomas.Freeman at hgst.com
Sent: Saturday, February 1, 2014 2:02 PM
To: nvmewin at lists.openfabrics.org
Subject: [nvmewin] Static Driver Verification



I'm new to HCK testing, but I understand part of the testing requires a
Driver Verification Log (which contains the results from Code Analysis and
Static Driver Verifier). This is required for the Static Tools Logo test
(under the Device.Fundamentals category).
When I run those tools, I'm getting a large number of errors. The code
analysis shows over 50 warnings and the Static Driver Verifier fails
because the Callback roletypes (sp_DRIVER_INITIALIZE, HW_INITIALIZE, etc)
are not defined. Fixing the roletypes allows a new set of errors to appear.
I'm running with VS 2013 and WDK 8.1.
Am I missing something? Has anyone else run these tools against the code?


Tom Freeman
SSD Device Drivers/Firmware
HGST, a Western Digital company
Thomas.Freeman at HGST.com
507-322-2311/232311

_______________________________________________
nvmewin mailing list
nvmewin at lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin






From Alex.Chang at pmcs.com  Tue Feb  4 10:11:45 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Tue, 4 Feb 2014 18:11:45 +0000
Subject: [nvmewin] Versioning proposal for trunk/
In-Reply-To: <2D98093777D3FD46A36253F35FE9D693891A4315@ORSMSX109.amr.corp.intel.com>
References: <2D98093777D3FD46A36253F35FE9D693891A0CD4@ORSMSX109.amr.corp.intel.com>
	<BC85AFAC9186CE40AEDB53E064077E863CD46A2D@sacexcmbx05-prd.hq.netapp.com>
	<2D98093777D3FD46A36253F35FE9D693891A0D67@ORSMSX109.amr.corp.intel.com>
	<BC85AFAC9186CE40AEDB53E064077E863CD46D1F@sacexcmbx05-prd.hq.netapp.com>
	<2D98093777D3FD46A36253F35FE9D693891A0DCF@ORSMSX109.amr.corp.intel.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C88403E@BBYEXM01.pmc-sierra.internal>
	<2D98093777D3FD46A36253F35FE9D693891A0E21@ORSMSX109.amr.corp.intel.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C88416B@BBYEXM01.pmc-sierra.internal>
	<BC85AFAC9186CE40AEDB53E064077E863CD498A9@sacexcmbx05-prd.hq.netapp.com>
	<2D98093777D3FD46A36253F35FE9D693891A4315@ORSMSX109.amr.corp.intel.com>
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C8844D9@BBYEXM01.pmc-sierra.internal>

Hi all,

Since no more feedbacks/objections had been received, I would say the proposal from Jay and Kenny works fine with me. I will start to incorporate it when adding next patch into the base. Basically, there is no change to COMMNvme.DeviceDesc and driver version format is defined as: Major.Minor.NVMeSpecRevision.PatchNumber
When I push next patch, the driver version logged in nvme.inf will be 1.2.1014.21.
Thank you, Jay and Kenny, for the proposal.

Regards,
Alex

From: Freyensee, James P [mailto:james.p.freyensee at intel.com]
Sent: Thursday, January 30, 2014 12:39 PM
To: Speer, Kenny; Alex Chang; nvmewin at lists.openfabrics.org
Subject: RE: Versioning proposal for trunk/

I like this versioning idea :).

I think this along with adding the NVMe spec version in COMMNvme.DeviceDesc makes it very clear what code version someone is pulling from trunk/ and when trunk/ will reflect the next NVMe spec target.


From: Speer, Kenny [mailto:Kenny.Speer at netapp.com]
Sent: Thursday, January 30, 2014 12:32 PM
To: Alex Chang; Freyensee, James P; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Versioning proposal for trunk/

It's clear that you not only want to track the NVMe spec that the current version implements, but also want to track driver specific changes (such as implementing new features).

A suggestion would be to continue using the Major.Minor to reflect driver versions and use the Release.Build fields to describe the spec and revision.  The Release field could contain a 4 digit number where the first two digits represent the Major Spec and the last 2 represent the revision.  For instance, in your example of 1.3.00 supporting up to 1.0e, the full version would be: 1.3.1014.36 where 10 = 1.0 and 14 = rev e and 36 = change number.  This way you could release a 1.4.1014.36 which contains only driver infrastructure changes (i.e. WPP tracing) without effecting the NVMe spec that it adheres to.

~kenny

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Thursday, January 30, 2014 12:22 PM
To: Freyensee, James P; Speer, Kenny; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Versioning proposal for trunk/

I wouldn't be against reflecting NVMe specification version in the COMMNvme.DeviceDesc. However,  the up-coming release will be versioned as 1.3.0.0 supporting up to 1.0e. Please provide your thoughts if you have any.

Thanks,
Alex

From: Freyensee, James P [mailto:james.p.freyensee at intel.com]
Sent: Wednesday, January 29, 2014 6:49 PM
To: Alex Chang; Speer, Kenny; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Versioning proposal for trunk/

So then why not have the NVMe standard target version in the COMMNvme.DeviceDesc and change this target version when trunk/ is focusing on the next NVMe standard?  Then when this happens the driver revision number goes from:

1.2.X.Y (NVMe 1.0.e version, reflected in COMMNvme.DeviceDesc) --> 1.3.0.0 (NVMe 1.1 version, reflected in COMMNvme.DeviceDesc)

??


From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Wednesday, January 29, 2014 6:43 PM
To: Freyensee, James P; Speer, Kenny; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Versioning proposal for trunk/

Hi James,

Yes, the driver displays its name in Device Manager via COMMNvme.DeviceDesc.
As for the driver revision number in .inf file, the last release is 1.2.0.0 and we mean to keep the first two numbers as release numbers for the future to comply with Windows versioning. I am open to any proposals using the last two numbers.

Thanks,
Alex

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P
Sent: Wednesday, January 29, 2014 6:25 PM
To: Speer, Kenny; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: Re: [nvmewin] Versioning proposal for trunk/

Oh ok, I thought COMMNvmeChat.DeviceDesc was the name/driver-title that shows up when you look at the driver under "Device Manager" in the device tree, but if CommNvme.DeviceDesc does it, then that's fine by me :).

I think that is a good idea, to have the numeric version match what is in COMMNvmeChat.DeviceDesc/ CommNvme.DeviceDesc.


From: Speer, Kenny [mailto:Kenny.Speer at netapp.com]
Sent: Wednesday, January 29, 2014 6:18 PM
To: Freyensee, James P; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Versioning proposal for trunk/

Yes, that makes more sense, in fact the last version I grabbed shows:

CommNvme.DeviceDesc = "Community NVME Storport Miniport"
;COMMNvmeChat.DeviceDesc = "Intel Chatham Prototype Hardware"

So it's already been updated to be more generic, just add the specific version you want.  I do also suggest having the numeric version match for clarity.

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P
Sent: Wednesday, January 29, 2014 6:02 PM
To: Speer, Kenny; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: Re: [nvmewin] Versioning proposal for trunk/

May be sufficient but associating 'e' as a hex value and making it '14' would not be as intuitive to the non-nvme open-source developer/maintainer, which is a goal I would like to meet.

Maybe using:

COMMNvmeChat.DeviceDesc = "NVMe 1.0.e open-source driver, version 36"

Would be good instead?

The current value is:

COMMNvmeChat.DeviceDesc = "Intel Chatham Prototype Hardware"

which I would think the goals of this project is beyond Intel Chatham Prototypes now?


From: Speer, Kenny [mailto:Kenny.Speer at netapp.com]
Sent: Wednesday, January 29, 2014 5:47 PM
To: Freyensee, James P; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Versioning proposal for trunk/

The only issue is that Windows driver versioning is of the format Major.Minor.Release.Build using numerics in decimal only.  I've never tried to just munge the .inf version directly and have it differ from the driver but I suspect VS2013 will flag it.

Perhaps just use 1.0.14.36 to represent 1.0.e.36 ...

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P
Sent: Wednesday, January 29, 2014 5:19 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Versioning proposal for trunk/

May I propose a versioning change with respect to nvme.inf file and trunk/?

When I pull code from trunk/, I always would like to know what code I am getting with respect to the NVMe spec standard, without having to ask people or ask the email list what the NVMe standard target is.  I would also like to be able to easily tell what version of a compiled Open-source NVMe driver is running on a Windows OS.

What I would like to propose is for the .inf file to maintain the versioning in the following manner:

If trunk/ is targeting the NVMe 1.0.e standard (which I assume it is), then 'DriverVer' in the .inf file is set in the following manner:

DriverVer=1/29/2014,1.0.e.36

where "1.0.e" is the NVMe standard being targeted, and '36' is the 36th time code in trunk/ has been changed for the NVMe standard target (1.0.e in this case).

Thus, when the open-source team is ready to target the NVMe 1.1 standard, the last version of the 1.0.e code in trunk/ will go to a 1.0.e branch, and in trunk/ the new value for "DriverVer" in nvme.inf would be:

DriverVer=1/29/2014,1.1.0

When a first revision of code is done in trunk/ with respect to the NVMe 1.1 standard, the DriverVer in the .inf file would be:

DriverVer=1/29/2014,1.1.1

And for a 2nd revision in trunk/ it would be:

DriverVer=1/29/2014,1.1.2

etc., etc.

I welcome alternative ideas if this is not doable or not simplistic enough where when someone pulls code down from trunk/ they do not recognize exactly what standard the code is targeting.  Regardless, I want the goal to be a simple solution such that a person not familiar with Windows NVMe open-source development and maintenance instantly recognize what NVMe spec standard their copy of the nvme source-code/compiled-driver is targeting.

Thanks!

Jay Freyensee



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140204/55ba205a/attachment.html>

From carolyn.d.foster at intel.com  Tue Feb  4 15:44:47 2014
From: carolyn.d.foster at intel.com (Foster, Carolyn D)
Date: Tue, 4 Feb 2014 23:44:47 +0000
Subject: [nvmewin] ***UNCHECKED*** RE: LBA Range Type Patch
In-Reply-To: <02EC085151D99A469E06988E94FEBCDB1CE72187@SJCEML701-CHM.china.huawei.com>
References: <6419_1391035517_52E9847D_6419_15986_1_B3A485AFDDB1DD4598621E85E8EB67A83AAF0B53@FMSMSX105.amr.corp.intel.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C883FA1@BBYEXM01.pmc-sierra.internal>
	<02EC085151D99A469E06988E94FEBCDB1CE71EAD@SJCEML701-CHM.china.huawei.com>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF0F73@FMSMSX105.amr.corp.intel.com>
	<02EC085151D99A469E06988E94FEBCDB1CE72187@SJCEML701-CHM.china.huawei.com>
Message-ID: <B3A485AFDDB1DD4598621E85E8EB67A83AAF3272@FMSMSX105.amr.corp.intel.com>

Hello,

I have made the recommended updates and have attached the new files for review.  The password is intel123

Thanks,
Carolyn

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com]
Sent: Thursday, January 30, 2014 12:08 PM
To: Foster, Carolyn D; Alex Chang; nvmewin at lists.openfabrics.org
Subject: RE: LBA Range Type Patch

Agreed. That is what I would do.

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Thursday, January 30, 2014 10:25 AM
To: Yong Chen; Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: LBA Range Type Patch

Hi Yong,
The 22 LOC are similar, but only half of that is actual code, and the rest are comments.  The effort to reuse such a small amount likely would outweigh the benefits.

I don't have a problem with removing the unnecessary code you outlined on line 1440.

Please let me know if this is acceptable.
Thanks,
Carolyn

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com]
Sent: Wednesday, January 29, 2014 11:50 PM
To: Alex Chang; Foster, Carolyn D; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: LBA Range Type Patch

22 LOC starting from #1424 is identical to LOC starting from #1537, including verbose comments...candidate to refactor/reuse.

If not a strong case, then minor Copy&Paste mistake :

On #1419                pAE->DriverState.ConfigLbaRangeNeeded = FALSE;
On #1440 block, we don't have a TRUE case anymore,  can simply set state to
NVMeWaitOnIdentifyNS;

Thanks,

Yong


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, January 29, 2014 2:49 PM
To: Foster, Carolyn D; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: Re: [nvmewin] LBA Range Type Patch

Thank you very much, Carolyn.

Hi all,

Please review/test the patch and provide your feedback(s) as soon as possible.

Thanks,
Alex

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Foster, Carolyn D
Sent: Wednesday, January 29, 2014 2:45 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] ***UNCHECKED*** LBA Range Type Patch


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Overview:
The LBA Range Type feature is defined as optional in the spec, but the driver currently fails to complete enumeration if the Get Features request for LBA Range Type fails.  Based on the serious nature of the failure, this could be a problem at the upcoming plugfest.  There will likely be devices at plugfest that do not support LBA Range Type, thus causing the OFA driver to not load on these devices.

Files Modified:
In nvmeInit.c, NVMeSetFeaturesCompletion(), the LBA Range Type Get Features request is treated as mandatory and will cause enumeration to fail if the Get Features command is not successful.  This change looks at the status codes and will allow enumeration to continue if the device returns Invalid.

Password: intel123
Feedback requested by Feb. 5th.

Unit Tests:
Cold boot
Reboot
Reset while running in the OS
SdStress
SCSI Compliance Test (I did see what I believe are known failures in Read Capacity, Mode Select, and Write (10))
Driver Update using INF

Carolyn Dase Foster
Intel Corp.
NVM Solutions Group
Internal SSD Engineering
Phone: 480-554-2421

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140204/a2c5dd32/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LBARangeType-v2.zip
Type: application/x-zip-compressed
Size: 174636 bytes
Desc: LBARangeType-v2.zip
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140204/a2c5dd32/attachment.bin>

From uma.parepalli at skhms.com  Tue Feb  4 15:45:49 2014
From: uma.parepalli at skhms.com (Uma Parepalli)
Date: Tue, 4 Feb 2014 15:45:49 -0800 (PST)
Subject: [nvmewin] ***UNCHECKED*** ***UNCHECKED*** RE: LBA Range Type
	Patch
In-Reply-To: <B3A485AFDDB1DD4598621E85E8EB67A83AAF3272@FMSMSX105.amr.corp.intel.com>
References: <6419_1391035517_52E9847D_6419_15986_1_B3A485AFDDB1DD4598621E85E8EB67A83AAF0B53@FMSMSX105.amr.corp.intel.com>	<E1729D5DBAB9E948BA87B76FDFA1298A0C883FA1@BBYEXM01.pmc-sierra.internal>	<02EC085151D99A469E06988E94FEBCDB1CE71EAD@SJCEML701-CHM.china.huawei.com>	<B3A485AFDDB1DD4598621E85E8EB67A83AAF0F73@FMSMSX105.amr.corp.intel.com>	<02EC085151D99A469E06988E94FEBCDB1CE72187@SJCEML701-CHM.china.huawei.com>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF3272@FMSMSX105.amr.corp.intel.com>
Message-ID: <ec777162.000059f8.00000002@n9228>

Is it OK not to initialize the MultipleCoresToSingleQueueFlag value?

Uma

 

From: nvmewin-bounces at lists.openfabrics.org
[mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Foster,
Carolyn D
Sent: Tuesday, February 04, 2014 3:45 PM
To: Yong Chen; Alex Chang; nvmewin at lists.openfabrics.org
Subject: ***UNCHECKED*** [nvmewin] ***UNCHECKED*** RE: LBA Range Type
Patch

 

Hello, 

 

I have made the recommended updates and have attached the new files for
review.  The password is intel123

 

Thanks,

Carolyn

 

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com] 
Sent: Thursday, January 30, 2014 12:08 PM
To: Foster, Carolyn D; Alex Chang; nvmewin at lists.openfabrics.org
Subject: RE: LBA Range Type Patch

 

Agreed. That is what I would do.

 

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com] 
Sent: Thursday, January 30, 2014 10:25 AM
To: Yong Chen; Alex Chang; nvmewin at lists.openfabrics.org
Subject: RE: LBA Range Type Patch

 

Hi Yong, 

The 22 LOC are similar, but only half of that is actual code, and the rest
are comments.  The effort to reuse such a small amount likely would
outweigh the benefits.  

 

I don't have a problem with removing the unnecessary code you outlined on
line 1440.

 

Please let me know if this is acceptable.

Thanks,

Carolyn

 

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com] 
Sent: Wednesday, January 29, 2014 11:50 PM
To: Alex Chang; Foster, Carolyn D; nvmewin at lists.openfabrics.org
Subject: RE: LBA Range Type Patch

 

22 LOC starting from #1424 is identical to LOC starting from #1537,
including verbose comments.candidate to refactor/reuse.

 

If not a strong case, then minor Copy&Paste mistake :

 

On #1419                pAE->DriverState.ConfigLbaRangeNeeded = FALSE;

On #1440 block, we don't have a TRUE case anymore,  can simply set state
to 

NVMeWaitOnIdentifyNS;

 

Thanks,

 

Yong

 

 

From: nvmewin-bounces at lists.openfabrics.org
[mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, January 29, 2014 2:49 PM
To: Foster, Carolyn D; nvmewin at lists.openfabrics.org
Subject: Re: [nvmewin] LBA Range Type Patch

 

Thank you very much, Carolyn.

 

Hi all,

 

Please review/test the patch and provide your feedback(s) as soon as
possible.

 

Thanks,

Alex

 

From: nvmewin-bounces at lists.openfabrics.org
[mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Foster,
Carolyn D
Sent: Wednesday, January 29, 2014 2:45 PM
To: nvmewin at lists.openfabrics.org
Subject: [nvmewin] ***UNCHECKED*** LBA Range Type Patch

 

Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Date: %%SENT_DATE%%
Subject: Suspect Message Quarantined 
 
 
 
WARNING: The virus scanner was unable to scan an attachment in an email
message sent to you.  This attachment could possibly contain viruses or
other malicious programs.  The attachment could not be scanned for the
following reasons:
 
%%DESC%%
 
The full message and the attachment have been stored in the quarantine.
 
The identifier for this message is '%%QID%%'.
 
Access the quarantine at: 
https://puremessage.pmc-sierra.bc.ca:28443/
 
For more information on PMC's Anti-Spam system:
http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ
 
IT Services
PureMessage Admin 
 

Overview:

The LBA Range Type feature is defined as optional in the spec, but the
driver currently fails to complete enumeration if the Get Features request
for LBA Range Type fails.  Based on the serious nature of the failure,
this could be a problem at the upcoming plugfest.  There will likely be
devices at plugfest that do not support LBA Range Type, thus causing the
OFA driver to not load on these devices.

 

Files Modified:

In nvmeInit.c, NVMeSetFeaturesCompletion(), the LBA Range Type Get
Features request is treated as mandatory and will cause enumeration to
fail if the Get Features command is not successful.  This change looks at
the status codes and will allow enumeration to continue if the device
returns Invalid.  

 

Password: intel123

Feedback requested by Feb. 5th.

 

Unit Tests:

Cold boot

Reboot

Reset while running in the OS

SdStress

SCSI Compliance Test (I did see what I believe are known failures in Read
Capacity, Mode Select, and Write (10))

Driver Update using INF

 

Carolyn Dase Foster

Intel Corp.

NVM Solutions Group

Internal SSD Engineering

Phone: 480-554-2421

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140204/c886aa6b/attachment.html>

From Alex.Chang at pmcs.com  Tue Feb  4 17:12:42 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Wed, 5 Feb 2014 01:12:42 +0000
Subject: [nvmewin] ***UNCHECKED*** ***UNCHECKED*** RE: LBA Range Type
 Patch
In-Reply-To: <ec777162.000059f8.00000002@n9228>
References: <6419_1391035517_52E9847D_6419_15986_1_B3A485AFDDB1DD4598621E85E8EB67A83AAF0B53@FMSMSX105.amr.corp.intel.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C883FA1@BBYEXM01.pmc-sierra.internal>
	<02EC085151D99A469E06988E94FEBCDB1CE71EAD@SJCEML701-CHM.china.huawei.com>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF0F73@FMSMSX105.amr.corp.intel.com>
	<02EC085151D99A469E06988E94FEBCDB1CE72187@SJCEML701-CHM.china.huawei.com>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF3272@FMSMSX105.amr.corp.intel.com>
	<ec777162.000059f8.00000002@n9228>
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C8845BA@BBYEXM01.pmc-sierra.internal>

Hi Uma,

The Flag was added via last patch. I'd be interested why you don't want it to be initialized?

Thanks,
Alex

From: Uma Parepalli [mailto:uma.parepalli at skhms.com]
Sent: Tuesday, February 04, 2014 3:46 PM
To: Foster, Carolyn D; Yong Chen; Alex Chang; nvmewin at lists.openfabrics.org
Subject: RE: ***UNCHECKED*** [nvmewin] ***UNCHECKED*** RE: LBA Range Type Patch

Is it OK not to initialize the MultipleCoresToSingleQueueFlag value?
Uma

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Foster, Carolyn D
Sent: Tuesday, February 04, 2014 3:45 PM
To: Yong Chen; Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: ***UNCHECKED*** [nvmewin] ***UNCHECKED*** RE: LBA Range Type Patch

Hello,

I have made the recommended updates and have attached the new files for review.  The password is intel123

Thanks,
Carolyn

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com]
Sent: Thursday, January 30, 2014 12:08 PM
To: Foster, Carolyn D; Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: LBA Range Type Patch

Agreed. That is what I would do.

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Thursday, January 30, 2014 10:25 AM
To: Yong Chen; Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: LBA Range Type Patch

Hi Yong,
The 22 LOC are similar, but only half of that is actual code, and the rest are comments.  The effort to reuse such a small amount likely would outweigh the benefits.

I don't have a problem with removing the unnecessary code you outlined on line 1440.

Please let me know if this is acceptable.
Thanks,
Carolyn

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com]
Sent: Wednesday, January 29, 2014 11:50 PM
To: Alex Chang; Foster, Carolyn D; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: LBA Range Type Patch

22 LOC starting from #1424 is identical to LOC starting from #1537, including verbose comments...candidate to refactor/reuse.

If not a strong case, then minor Copy&Paste mistake :

On #1419                pAE->DriverState.ConfigLbaRangeNeeded = FALSE;
On #1440 block, we don't have a TRUE case anymore,  can simply set state to
NVMeWaitOnIdentifyNS;

Thanks,

Yong


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, January 29, 2014 2:49 PM
To: Foster, Carolyn D; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: Re: [nvmewin] LBA Range Type Patch

Thank you very much, Carolyn.

Hi all,

Please review/test the patch and provide your feedback(s) as soon as possible.

Thanks,
Alex

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Foster, Carolyn D
Sent: Wednesday, January 29, 2014 2:45 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] ***UNCHECKED*** LBA Range Type Patch


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Overview:
The LBA Range Type feature is defined as optional in the spec, but the driver currently fails to complete enumeration if the Get Features request for LBA Range Type fails.  Based on the serious nature of the failure, this could be a problem at the upcoming plugfest.  There will likely be devices at plugfest that do not support LBA Range Type, thus causing the OFA driver to not load on these devices.

Files Modified:
In nvmeInit.c, NVMeSetFeaturesCompletion(), the LBA Range Type Get Features request is treated as mandatory and will cause enumeration to fail if the Get Features command is not successful.  This change looks at the status codes and will allow enumeration to continue if the device returns Invalid.

Password: intel123
Feedback requested by Feb. 5th.

Unit Tests:
Cold boot
Reboot
Reset while running in the OS
SdStress
SCSI Compliance Test (I did see what I believe are known failures in Read Capacity, Mode Select, and Write (10))
Driver Update using INF

Carolyn Dase Foster
Intel Corp.
NVM Solutions Group
Internal SSD Engineering
Phone: 480-554-2421

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140205/16c019d8/attachment.html>

From Alex.Chang at pmcs.com  Tue Feb  4 17:15:00 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Wed, 5 Feb 2014 01:15:00 +0000
Subject: [nvmewin] ***UNCHECKED*** ***UNCHECKED*** RE: LBA Range Type
 Patch
In-Reply-To: <ec777162.000059f8.00000002@n9228>
References: <6419_1391035517_52E9847D_6419_15986_1_B3A485AFDDB1DD4598621E85E8EB67A83AAF0B53@FMSMSX105.amr.corp.intel.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C883FA1@BBYEXM01.pmc-sierra.internal>
	<02EC085151D99A469E06988E94FEBCDB1CE71EAD@SJCEML701-CHM.china.huawei.com>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF0F73@FMSMSX105.amr.corp.intel.com>
	<02EC085151D99A469E06988E94FEBCDB1CE72187@SJCEML701-CHM.china.huawei.com>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF3272@FMSMSX105.amr.corp.intel.com>
	<ec777162.000059f8.00000002@n9228>
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C8845CC@BBYEXM01.pmc-sierra.internal>

Hi Uma,

I believe the flag is part of NVME_DEVICE_EXTENSION and it would be initialized as FALSE (0).

Alex

From: Uma Parepalli [mailto:uma.parepalli at skhms.com]
Sent: Tuesday, February 04, 2014 3:46 PM
To: Foster, Carolyn D; Yong Chen; Alex Chang; nvmewin at lists.openfabrics.org
Subject: RE: ***UNCHECKED*** [nvmewin] ***UNCHECKED*** RE: LBA Range Type Patch

Is it OK not to initialize the MultipleCoresToSingleQueueFlag value?
Uma

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Foster, Carolyn D
Sent: Tuesday, February 04, 2014 3:45 PM
To: Yong Chen; Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: ***UNCHECKED*** [nvmewin] ***UNCHECKED*** RE: LBA Range Type Patch

Hello,

I have made the recommended updates and have attached the new files for review.  The password is intel123

Thanks,
Carolyn

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com]
Sent: Thursday, January 30, 2014 12:08 PM
To: Foster, Carolyn D; Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: LBA Range Type Patch

Agreed. That is what I would do.

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Thursday, January 30, 2014 10:25 AM
To: Yong Chen; Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: LBA Range Type Patch

Hi Yong,
The 22 LOC are similar, but only half of that is actual code, and the rest are comments.  The effort to reuse such a small amount likely would outweigh the benefits.

I don't have a problem with removing the unnecessary code you outlined on line 1440.

Please let me know if this is acceptable.
Thanks,
Carolyn

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com]
Sent: Wednesday, January 29, 2014 11:50 PM
To: Alex Chang; Foster, Carolyn D; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: LBA Range Type Patch

22 LOC starting from #1424 is identical to LOC starting from #1537, including verbose comments...candidate to refactor/reuse.

If not a strong case, then minor Copy&Paste mistake :

On #1419                pAE->DriverState.ConfigLbaRangeNeeded = FALSE;
On #1440 block, we don't have a TRUE case anymore,  can simply set state to
NVMeWaitOnIdentifyNS;

Thanks,

Yong


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, January 29, 2014 2:49 PM
To: Foster, Carolyn D; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: Re: [nvmewin] LBA Range Type Patch

Thank you very much, Carolyn.

Hi all,

Please review/test the patch and provide your feedback(s) as soon as possible.

Thanks,
Alex

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Foster, Carolyn D
Sent: Wednesday, January 29, 2014 2:45 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] ***UNCHECKED*** LBA Range Type Patch


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Overview:
The LBA Range Type feature is defined as optional in the spec, but the driver currently fails to complete enumeration if the Get Features request for LBA Range Type fails.  Based on the serious nature of the failure, this could be a problem at the upcoming plugfest.  There will likely be devices at plugfest that do not support LBA Range Type, thus causing the OFA driver to not load on these devices.

Files Modified:
In nvmeInit.c, NVMeSetFeaturesCompletion(), the LBA Range Type Get Features request is treated as mandatory and will cause enumeration to fail if the Get Features command is not successful.  This change looks at the status codes and will allow enumeration to continue if the device returns Invalid.

Password: intel123
Feedback requested by Feb. 5th.

Unit Tests:
Cold boot
Reboot
Reset while running in the OS
SdStress
SCSI Compliance Test (I did see what I believe are known failures in Read Capacity, Mode Select, and Write (10))
Driver Update using INF

Carolyn Dase Foster
Intel Corp.
NVM Solutions Group
Internal SSD Engineering
Phone: 480-554-2421

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140205/18c4b746/attachment.html>

From Alex.Chang at pmcs.com  Tue Feb  4 17:39:52 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Wed, 5 Feb 2014 01:39:52 +0000
Subject: [nvmewin] LBA Range Type Patch
In-Reply-To: <22453_1391557490_52F17B72_22453_6079_1_B3A485AFDDB1DD4598621E85E8EB67A83AAF3272@FMSMSX105.amr.corp.intel.com>
References: <6419_1391035517_52E9847D_6419_15986_1_B3A485AFDDB1DD4598621E85E8EB67A83AAF0B53@FMSMSX105.amr.corp.intel.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C883FA1@BBYEXM01.pmc-sierra.internal>
	<02EC085151D99A469E06988E94FEBCDB1CE71EAD@SJCEML701-CHM.china.huawei.com>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF0F73@FMSMSX105.amr.corp.intel.com>
	<02EC085151D99A469E06988E94FEBCDB1CE72187@SJCEML701-CHM.china.huawei.com>
	<22453_1391557490_52F17B72_22453_6079_1_B3A485AFDDB1DD4598621E85E8EB67A83AAF3272@FMSMSX105.amr.corp.intel.com>
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C8845E2@BBYEXM01.pmc-sierra.internal>

Hi all,

Please review/test the revised patch and provide your feedbacks as soon as possible. I will follow up for approvals on February 11 and push the patch if all approvals are collected.

Thanks,
Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Tuesday, February 04, 2014 3:45 PM
To: Yong Chen; Alex Chang; nvmewin at lists.openfabrics.org
Subject: RE: LBA Range Type Patch


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hello,

I have made the recommended updates and have attached the new files for review.  The password is intel123

Thanks,
Carolyn

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com]
Sent: Thursday, January 30, 2014 12:08 PM
To: Foster, Carolyn D; Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: LBA Range Type Patch

Agreed. That is what I would do.

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Thursday, January 30, 2014 10:25 AM
To: Yong Chen; Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: LBA Range Type Patch

Hi Yong,
The 22 LOC are similar, but only half of that is actual code, and the rest are comments.  The effort to reuse such a small amount likely would outweigh the benefits.

I don't have a problem with removing the unnecessary code you outlined on line 1440.

Please let me know if this is acceptable.
Thanks,
Carolyn

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com]
Sent: Wednesday, January 29, 2014 11:50 PM
To: Alex Chang; Foster, Carolyn D; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: LBA Range Type Patch

22 LOC starting from #1424 is identical to LOC starting from #1537, including verbose comments...candidate to refactor/reuse.

If not a strong case, then minor Copy&Paste mistake :

On #1419                pAE->DriverState.ConfigLbaRangeNeeded = FALSE;
On #1440 block, we don't have a TRUE case anymore,  can simply set state to
NVMeWaitOnIdentifyNS;

Thanks,

Yong


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, January 29, 2014 2:49 PM
To: Foster, Carolyn D; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: Re: [nvmewin] LBA Range Type Patch

Thank you very much, Carolyn.

Hi all,

Please review/test the patch and provide your feedback(s) as soon as possible.

Thanks,
Alex

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Foster, Carolyn D
Sent: Wednesday, January 29, 2014 2:45 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] ***UNCHECKED*** LBA Range Type Patch


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Overview:
The LBA Range Type feature is defined as optional in the spec, but the driver currently fails to complete enumeration if the Get Features request for LBA Range Type fails.  Based on the serious nature of the failure, this could be a problem at the upcoming plugfest.  There will likely be devices at plugfest that do not support LBA Range Type, thus causing the OFA driver to not load on these devices.

Files Modified:
In nvmeInit.c, NVMeSetFeaturesCompletion(), the LBA Range Type Get Features request is treated as mandatory and will cause enumeration to fail if the Get Features command is not successful.  This change looks at the status codes and will allow enumeration to continue if the device returns Invalid.

Password: intel123
Feedback requested by Feb. 5th.

Unit Tests:
Cold boot
Reboot
Reset while running in the OS
SdStress
SCSI Compliance Test (I did see what I believe are known failures in Read Capacity, Mode Select, and Write (10))
Driver Update using INF

Carolyn Dase Foster
Intel Corp.
NVM Solutions Group
Internal SSD Engineering
Phone: 480-554-2421

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140205/4cefa880/attachment.html>

From Alex.Chang at pmcs.com  Thu Feb  6 18:18:09 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Fri, 7 Feb 2014 02:18:09 +0000
Subject: [nvmewin] ***UNCHECKED*** RE: PMC New Patch
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C8848D5@BBYEXM01.pmc-sierra.internal>

Hi all,

Thanks to Carolyn for a quick feedback that CoreNum is no longer defined in Core Table, which causes a compiling error in debug build (Line# 1893 of nvmeinit.c). Sorry about the confusion and any inconveniences it may have caused. Please find the attached revised patch and password remains same.

Thanks,
Alex

From: Alex Chang
Sent: Friday, January 31, 2014 3:43 PM
To: nvmewin at lists.openfabrics.org; Truong Nguyen-SSI (tru.nguyen at ssi.samsung.com)
Subject: PMC New Patch

Hi all,

Please find the attached patch from PMC-Sierra. The password is pmc123. In order to speed up the entire process and meet our next release date, please review the changes and provide feedbacks as soon as possible. For each outstanding patch, we plan to collect feedbacks for about a week after it is being sent out. A revised patch shall be sent out to include the feedbacks. I will follow up for approval after a week or so to allow more testing and reviewing if necessary.
Summary of changes:

1.       SRB Extension support for Windows 8 and up.

Files changed: nvmeStd.c, nvmeSnti.c, nvmeStat.c, nvmePwrMgmt.c, nvmeInit.c and the related header files.

2.       PRP list building for IOCTL and internal requests.

Files changed: nvmeStd.c, nvmeInit.c and nvmestd.h.

3.       Performance issue in Windows 8/Server 2012.

File changed: nvmeStd.c (removed StorPortGetUncachedExtension calling in NVMeFindAdapter)

4.       NVMeInitAdminQueues return value.

File changed: nvmeStd.c (Instead of returning TRUE/FALSE, return Storport defined status)

5.       Paramlist length problem.

Files changed: nvmeSnti.c and nvmeSntiTypes.h (Program DW10 in submission entry in DWORDs for Write Buffer command translation)

6.       Removal of using mask bits as core index to allocate/identify core tables.

Files changed: nvmeStd.c, nvmeInit.c and the related header files.

7.       Implemented logical processor group defined by Windows.

Files changed: nvmeStd.c, nvmeInit.c and the related header files.

8.       NVMe reset handling issue.

File changed: nvmeStd.c (Need to wait until RDY bit is cleared to 0 after changing EN bit from 1 to 0)

9.       Core-MSI vector-Queue mapping, CMD_ENTRY synchronization and FreeQList access issues are related to using core mask bits as core index (#6) and no support for logical processor group (#7).
Platforms tested:

1.       Windows 7 64-bit

2.       Windows Server 2008 R2

3.       Windows 8 64-bit

4.       Windows Server 2012
Tests run;

1.       Installation(clean and update)/Un-Installation/Enable/Disable.

2.       IOMeter 4K Read/write combining in random/sequential manners.

3.       SCSC Compliance.

4.       SDStress

5.       Quick/full disk formats

Thanks,
Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140207/a7dd1421/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pmc_patch_v1.zip
Type: application/x-zip-compressed
Size: 174649 bytes
Desc: pmc_patch_v1.zip
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140207/a7dd1421/attachment.bin>

From Alex.Chang at pmcs.com  Tue Feb 11 14:02:34 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Tue, 11 Feb 2014 22:02:34 +0000
Subject: [nvmewin] NVMe Windows DB Is LOCKED - Pushing Patch From Intel For
 LBA Range Type Changes
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C884B36@BBYEXM01.pmc-sierra.internal>

Locking NVMe Windows DB.

Thanks,
Alex

nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140211/3d388436/attachment.html>

From Alex.Chang at pmcs.com  Tue Feb 11 14:25:47 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Tue, 11 Feb 2014 22:25:47 +0000
Subject: [nvmewin] NVMe Windows DB Is UNLOCKED - Pushing Patch From Intel
 For LBA Range Type As Optional Feature
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C884B4A@BBYEXM01.pmc-sierra.internal>

Hi all,

Thank you, Carolyn, for the effort.
The patch had been updated to the source base and a new tag called "Patch#21_LBA_Range_Type_As_Optional_Feature" had been created under tags directory.  As suggested, I updated the DriverVer entry in nvme.inf to reflect the release date, Major/Minor release numbers, NVMe Specification Compliant revision (1.0 e) and patch number as below:
DriverVer=02/11/2014, 1.2.1014.21

Should you have any questions, please reply to the email listed below.

Thanks,
Alex

nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140211/b292e30d/attachment.html>

From Alex.Chang at pmcs.com  Tue Feb 11 14:30:54 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Tue, 11 Feb 2014 22:30:54 +0000
Subject: [nvmewin] Hibernation Patch
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C884B5D@BBYEXM01.pmc-sierra.internal>

Hi Yong,

Please re-base your patch and re-send your patch again for review/test. Since we had reviewed and tested the patch a while back, I expect it won't take too long for approvals.

Thanks,
Alex


From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:26 PM
To: nvmewin at lists.openfabrics.org
Subject: [nvmewin] NVMe Windows DB Is UNLOCKED - Pushing Patch From Intel For LBA Range Type As Optional Feature

Hi all,

Thank you, Carolyn, for the effort.
The patch had been updated to the source base and a new tag called "Patch#21_LBA_Range_Type_As_Optional_Feature" had been created under tags directory.  As suggested, I updated the DriverVer entry in nvme.inf to reflect the release date, Major/Minor release numbers, NVMe Specification Compliant revision (1.0 e) and patch number as below:
DriverVer=02/11/2014, 1.2.1014.21

Should you have any questions, please reply to the email listed below.

Thanks,
Alex

nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140211/c522c2b1/attachment.html>

From Alex.Chang at pmcs.com  Tue Feb 11 15:16:03 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Tue, 11 Feb 2014 23:16:03 +0000
Subject: [nvmewin] NVMe Windows DB Is UNLOCKED - Pushing Patch From
 Intel For LBA Range Type As Optional Feature
In-Reply-To: <2D98093777D3FD46A36253F35FE9D693891B8905@ORSMSX109.amr.corp.intel.com>
References: <E1729D5DBAB9E948BA87B76FDFA1298A0C884B4A@BBYEXM01.pmc-sierra.internal>
	<2D98093777D3FD46A36253F35FE9D693891B8905@ORSMSX109.amr.corp.intel.com>
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C884B85@BBYEXM01.pmc-sierra.internal>

I don't see any reasons not making the change you proposed to make it clear. As long as no objections received, will add that in next patch.

Thanks,
Alex

From: Freyensee, James P [mailto:james.p.freyensee at intel.com]
Sent: Tuesday, February 11, 2014 3:10 PM
To: Alex Chang
Subject: RE: [nvmewin] NVMe Windows DB Is UNLOCKED - Pushing Patch From Intel For LBA Range Type As Optional Feature

Is it also possible to get the following:

CommNvme.DeviceDesc = "Community NVME Storport Miniport"

to

CommNvme.DeviceDesc = "Community NVME 1.0.e Storport Miniport"

on the next patch applied please?



From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:26 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] NVMe Windows DB Is UNLOCKED - Pushing Patch From Intel For LBA Range Type As Optional Feature

Hi all,

Thank you, Carolyn, for the effort.
The patch had been updated to the source base and a new tag called "Patch#21_LBA_Range_Type_As_Optional_Feature" had been created under tags directory.  As suggested, I updated the DriverVer entry in nvme.inf to reflect the release date, Major/Minor release numbers, NVMe Specification Compliant revision (1.0 e) and patch number as below:
DriverVer=02/11/2014, 1.2.1014.21

Should you have any questions, please reply to the email listed below.

Thanks,
Alex

nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140211/aa9e2b9f/attachment.html>

From Yong.sc.Chen at huawei.com  Tue Feb 11 23:06:32 2014
From: Yong.sc.Chen at huawei.com (Yong Chen)
Date: Wed, 12 Feb 2014 07:06:32 +0000
Subject: [nvmewin] Hibernation Patch
In-Reply-To: <E1729D5DBAB9E948BA87B76FDFA1298A0C884B5D@BBYEXM01.pmc-sierra.internal>
References: <E1729D5DBAB9E948BA87B76FDFA1298A0C884B5D@BBYEXM01.pmc-sierra.internal>
Message-ID: <02EC085151D99A469E06988E94FEBCDB1CE742E9@SJCEML701-CHM.china.huawei.com>

Hi, Alex,

I have sent the patch to you, due to internal policy I cannot email out code directly. Please forward to the alias for alias.

The only change affected is the LBA range and .INF.

Thanks,

Yong

From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:31 PM
To: nvmewin at lists.openfabrics.org
Subject: [nvmewin] Hibernation Patch

Hi Yong,

Please re-base your patch and re-send your patch again for review/test. Since we had reviewed and tested the patch a while back, I expect it won't take too long for approvals.

Thanks,
Alex


From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:26 PM
To: nvmewin at lists.openfabrics.org
Subject: [nvmewin] NVMe Windows DB Is UNLOCKED - Pushing Patch From Intel For LBA Range Type As Optional Feature

Hi all,

Thank you, Carolyn, for the effort.
The patch had been updated to the source base and a new tag called "Patch#21_LBA_Range_Type_As_Optional_Feature" had been created under tags directory.  As suggested, I updated the DriverVer entry in nvme.inf to reflect the release date, Major/Minor release numbers, NVMe Specification Compliant revision (1.0 e) and patch number as below:
DriverVer=02/11/2014, 1.2.1014.21

Should you have any questions, please reply to the email listed below.

Thanks,
Alex

nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140212/0fa6769b/attachment.html>

From Alex.Chang at pmcs.com  Wed Feb 12 12:53:03 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Wed, 12 Feb 2014 20:53:03 +0000
Subject: [nvmewin] ***UNCHECKED*** RE: Hibernation Patch
In-Reply-To: <02EC085151D99A469E06988E94FEBCDB1CE742E9@SJCEML701-CHM.china.huawei.com>
References: <E1729D5DBAB9E948BA87B76FDFA1298A0C884B5D@BBYEXM01.pmc-sierra.internal>
	<02EC085151D99A469E06988E94FEBCDB1CE742E9@SJCEML701-CHM.china.huawei.com>
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C884C54@BBYEXM01.pmc-sierra.internal>

Hi all,

On the behave of Yong, I am sending out the revised hibernation patch after re-basing the most current sources. Password is "huawei".
Should you have any feedbacks, please reply to this email. Again, we have been reviewing/testing the patch for quite some time and I don't expect taking too long to receive approvals from Intel and LSI.

Thanks,
Alex

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com]
Sent: Tuesday, February 11, 2014 11:07 PM
To: Alex Chang
Cc: nvmewin at lists.openfabrics.org
Subject: RE: Hibernation Patch

Hi, Alex,

I have sent the patch to you, due to internal policy I cannot email out code directly. Please forward to the alias for alias.

The only change affected is the LBA range and .INF.

Thanks,

Yong

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:31 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Hibernation Patch

Hi Yong,

Please re-base your patch and re-send your patch again for review/test. Since we had reviewed and tested the patch a while back, I expect it won't take too long for approvals.

Thanks,
Alex


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:26 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] NVMe Windows DB Is UNLOCKED - Pushing Patch From Intel For LBA Range Type As Optional Feature

Hi all,

Thank you, Carolyn, for the effort.
The patch had been updated to the source base and a new tag called "Patch#21_LBA_Range_Type_As_Optional_Feature" had been created under tags directory.  As suggested, I updated the DriverVer entry in nvme.inf to reflect the release date, Major/Minor release numbers, NVMe Specification Compliant revision (1.0 e) and patch number as below:
DriverVer=02/11/2014, 1.2.1014.21

Should you have any questions, please reply to the email listed below.

Thanks,
Alex

nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140212/bf6c463b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: huawei_patch_hiber_v3.zip
Type: application/x-zip-compressed
Size: 172966 bytes
Desc: huawei_patch_hiber_v3.zip
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140212/bf6c463b/attachment.bin>

From carolyn.d.foster at intel.com  Thu Feb 13 09:10:22 2014
From: carolyn.d.foster at intel.com (Foster, Carolyn D)
Date: Thu, 13 Feb 2014 17:10:22 +0000
Subject: [nvmewin] Hibernation Patch
In-Reply-To: <E1729D5DBAB9E948BA87B76FDFA1298A0C884C54@BBYEXM01.pmc-sierra.internal>
References: <E1729D5DBAB9E948BA87B76FDFA1298A0C884B5D@BBYEXM01.pmc-sierra.internal>
	<02EC085151D99A469E06988E94FEBCDB1CE742E9@SJCEML701-CHM.china.huawei.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C884C54@BBYEXM01.pmc-sierra.internal>
Message-ID: <B3A485AFDDB1DD4598621E85E8EB67A83AAF63A0@FMSMSX105.amr.corp.intel.com>

Hi Alex, The latest updates look good.  Thank you Yong, for allowing Intel to push an important patch and re-basing your changes.

Carolyn

From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, February 12, 2014 1:53 PM
To: Yong Chen; nvmewin at lists.openfabrics.org
Subject: [nvmewin] ***UNCHECKED*** RE: Hibernation Patch

Hi all,

On the behave of Yong, I am sending out the revised hibernation patch after re-basing the most current sources. Password is "huawei".
Should you have any feedbacks, please reply to this email. Again, we have been reviewing/testing the patch for quite some time and I don't expect taking too long to receive approvals from Intel and LSI.

Thanks,
Alex

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com]
Sent: Tuesday, February 11, 2014 11:07 PM
To: Alex Chang
Cc: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Hi, Alex,

I have sent the patch to you, due to internal policy I cannot email out code directly. Please forward to the alias for alias.

The only change affected is the LBA range and .INF.

Thanks,

Yong

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:31 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Hibernation Patch

Hi Yong,

Please re-base your patch and re-send your patch again for review/test. Since we had reviewed and tested the patch a while back, I expect it won't take too long for approvals.

Thanks,
Alex


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:26 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] NVMe Windows DB Is UNLOCKED - Pushing Patch From Intel For LBA Range Type As Optional Feature

Hi all,

Thank you, Carolyn, for the effort.
The patch had been updated to the source base and a new tag called "Patch#21_LBA_Range_Type_As_Optional_Feature" had been created under tags directory.  As suggested, I updated the DriverVer entry in nvme.inf to reflect the release date, Major/Minor release numbers, NVMe Specification Compliant revision (1.0 e) and patch number as below:
DriverVer=02/11/2014, 1.2.1014.21

Should you have any questions, please reply to the email listed below.

Thanks,
Alex

nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140213/8440b760/attachment.html>

From Alex.Chang at pmcs.com  Thu Feb 13 09:26:17 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Thu, 13 Feb 2014 17:26:17 +0000
Subject: [nvmewin] Hibernation Patch
In-Reply-To: <B3A485AFDDB1DD4598621E85E8EB67A83AAF63A0@FMSMSX105.amr.corp.intel.com>
References: <E1729D5DBAB9E948BA87B76FDFA1298A0C884B5D@BBYEXM01.pmc-sierra.internal>
	<02EC085151D99A469E06988E94FEBCDB1CE742E9@SJCEML701-CHM.china.huawei.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C884C54@BBYEXM01.pmc-sierra.internal>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF63A0@FMSMSX105.amr.corp.intel.com>
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C884D83@BBYEXM01.pmc-sierra.internal>

Thanks, Carolyn. Does that mean you've approved the patch?

Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Thursday, February 13, 2014 9:10 AM
To: Alex Chang; Yong Chen; nvmewin at lists.openfabrics.org
Subject: RE: Hibernation Patch

Hi Alex, The latest updates look good.  Thank you Yong, for allowing Intel to push an important patch and re-basing your changes.

Carolyn

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, February 12, 2014 1:53 PM
To: Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] ***UNCHECKED*** RE: Hibernation Patch

Hi all,

On the behave of Yong, I am sending out the revised hibernation patch after re-basing the most current sources. Password is "huawei".
Should you have any feedbacks, please reply to this email. Again, we have been reviewing/testing the patch for quite some time and I don't expect taking too long to receive approvals from Intel and LSI.

Thanks,
Alex

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com]
Sent: Tuesday, February 11, 2014 11:07 PM
To: Alex Chang
Cc: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Hi, Alex,

I have sent the patch to you, due to internal policy I cannot email out code directly. Please forward to the alias for alias.

The only change affected is the LBA range and .INF.

Thanks,

Yong

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:31 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Hibernation Patch

Hi Yong,

Please re-base your patch and re-send your patch again for review/test. Since we had reviewed and tested the patch a while back, I expect it won't take too long for approvals.

Thanks,
Alex


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:26 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] NVMe Windows DB Is UNLOCKED - Pushing Patch From Intel For LBA Range Type As Optional Feature

Hi all,

Thank you, Carolyn, for the effort.
The patch had been updated to the source base and a new tag called "Patch#21_LBA_Range_Type_As_Optional_Feature" had been created under tags directory.  As suggested, I updated the DriverVer entry in nvme.inf to reflect the release date, Major/Minor release numbers, NVMe Specification Compliant revision (1.0 e) and patch number as below:
DriverVer=02/11/2014, 1.2.1014.21

Should you have any questions, please reply to the email listed below.

Thanks,
Alex

nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140213/c56efc9a/attachment.html>

From carolyn.d.foster at intel.com  Thu Feb 13 09:27:00 2014
From: carolyn.d.foster at intel.com (Foster, Carolyn D)
Date: Thu, 13 Feb 2014 17:27:00 +0000
Subject: [nvmewin] Hibernation Patch
In-Reply-To: <E1729D5DBAB9E948BA87B76FDFA1298A0C884D83@BBYEXM01.pmc-sierra.internal>
References: <E1729D5DBAB9E948BA87B76FDFA1298A0C884B5D@BBYEXM01.pmc-sierra.internal>
	<02EC085151D99A469E06988E94FEBCDB1CE742E9@SJCEML701-CHM.china.huawei.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C884C54@BBYEXM01.pmc-sierra.internal>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF63A0@FMSMSX105.amr.corp.intel.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C884D83@BBYEXM01.pmc-sierra.internal>
Message-ID: <B3A485AFDDB1DD4598621E85E8EB67A83AAF644F@FMSMSX105.amr.corp.intel.com>

Yes I approve the patch.

Carolyn

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Thursday, February 13, 2014 10:26 AM
To: Foster, Carolyn D; Yong Chen; nvmewin at lists.openfabrics.org
Subject: RE: Hibernation Patch

Thanks, Carolyn. Does that mean you've approved the patch?

Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Thursday, February 13, 2014 9:10 AM
To: Alex Chang; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Hi Alex, The latest updates look good.  Thank you Yong, for allowing Intel to push an important patch and re-basing your changes.

Carolyn

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, February 12, 2014 1:53 PM
To: Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] ***UNCHECKED*** RE: Hibernation Patch

Hi all,

On the behave of Yong, I am sending out the revised hibernation patch after re-basing the most current sources. Password is "huawei".
Should you have any feedbacks, please reply to this email. Again, we have been reviewing/testing the patch for quite some time and I don't expect taking too long to receive approvals from Intel and LSI.

Thanks,
Alex

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com]
Sent: Tuesday, February 11, 2014 11:07 PM
To: Alex Chang
Cc: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Hi, Alex,

I have sent the patch to you, due to internal policy I cannot email out code directly. Please forward to the alias for alias.

The only change affected is the LBA range and .INF.

Thanks,

Yong

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:31 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Hibernation Patch

Hi Yong,

Please re-base your patch and re-send your patch again for review/test. Since we had reviewed and tested the patch a while back, I expect it won't take too long for approvals.

Thanks,
Alex


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:26 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] NVMe Windows DB Is UNLOCKED - Pushing Patch From Intel For LBA Range Type As Optional Feature

Hi all,

Thank you, Carolyn, for the effort.
The patch had been updated to the source base and a new tag called "Patch#21_LBA_Range_Type_As_Optional_Feature" had been created under tags directory.  As suggested, I updated the DriverVer entry in nvme.inf to reflect the release date, Major/Minor release numbers, NVMe Specification Compliant revision (1.0 e) and patch number as below:
DriverVer=02/11/2014, 1.2.1014.21

Should you have any questions, please reply to the email listed below.

Thanks,
Alex

nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140213/b4a37200/attachment.html>

From Alex.Chang at pmcs.com  Thu Feb 13 09:28:02 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Thu, 13 Feb 2014 17:28:02 +0000
Subject: [nvmewin] Hibernation Patch
In-Reply-To: <B3A485AFDDB1DD4598621E85E8EB67A83AAF644F@FMSMSX105.amr.corp.intel.com>
References: <E1729D5DBAB9E948BA87B76FDFA1298A0C884B5D@BBYEXM01.pmc-sierra.internal>
	<02EC085151D99A469E06988E94FEBCDB1CE742E9@SJCEML701-CHM.china.huawei.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C884C54@BBYEXM01.pmc-sierra.internal>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF63A0@FMSMSX105.amr.corp.intel.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C884D83@BBYEXM01.pmc-sierra.internal>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF644F@FMSMSX105.amr.corp.intel.com>
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C884D9A@BBYEXM01.pmc-sierra.internal>

Great!

Thanks,
Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Thursday, February 13, 2014 9:27 AM
To: Alex Chang; Yong Chen; nvmewin at lists.openfabrics.org
Subject: RE: Hibernation Patch

Yes I approve the patch.

Carolyn

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Thursday, February 13, 2014 10:26 AM
To: Foster, Carolyn D; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Thanks, Carolyn. Does that mean you've approved the patch?

Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Thursday, February 13, 2014 9:10 AM
To: Alex Chang; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Hi Alex, The latest updates look good.  Thank you Yong, for allowing Intel to push an important patch and re-basing your changes.

Carolyn

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, February 12, 2014 1:53 PM
To: Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] ***UNCHECKED*** RE: Hibernation Patch

Hi all,

On the behave of Yong, I am sending out the revised hibernation patch after re-basing the most current sources. Password is "huawei".
Should you have any feedbacks, please reply to this email. Again, we have been reviewing/testing the patch for quite some time and I don't expect taking too long to receive approvals from Intel and LSI.

Thanks,
Alex

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com]
Sent: Tuesday, February 11, 2014 11:07 PM
To: Alex Chang
Cc: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Hi, Alex,

I have sent the patch to you, due to internal policy I cannot email out code directly. Please forward to the alias for alias.

The only change affected is the LBA range and .INF.

Thanks,

Yong

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:31 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Hibernation Patch

Hi Yong,

Please re-base your patch and re-send your patch again for review/test. Since we had reviewed and tested the patch a while back, I expect it won't take too long for approvals.

Thanks,
Alex


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:26 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] NVMe Windows DB Is UNLOCKED - Pushing Patch From Intel For LBA Range Type As Optional Feature

Hi all,

Thank you, Carolyn, for the effort.
The patch had been updated to the source base and a new tag called "Patch#21_LBA_Range_Type_As_Optional_Feature" had been created under tags directory.  As suggested, I updated the DriverVer entry in nvme.inf to reflect the release date, Major/Minor release numbers, NVMe Specification Compliant revision (1.0 e) and patch number as below:
DriverVer=02/11/2014, 1.2.1014.21

Should you have any questions, please reply to the email listed below.

Thanks,
Alex

nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140213/37df9062/attachment.html>

From Yong.sc.Chen at huawei.com  Thu Feb 13 10:14:37 2014
From: Yong.sc.Chen at huawei.com (Yong Chen)
Date: Thu, 13 Feb 2014 18:14:37 +0000
Subject: [nvmewin] Hibernation Patch
In-Reply-To: <E1729D5DBAB9E948BA87B76FDFA1298A0C884D9A@BBYEXM01.pmc-sierra.internal>
References: <E1729D5DBAB9E948BA87B76FDFA1298A0C884B5D@BBYEXM01.pmc-sierra.internal>
	<02EC085151D99A469E06988E94FEBCDB1CE742E9@SJCEML701-CHM.china.huawei.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C884C54@BBYEXM01.pmc-sierra.internal>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF63A0@FMSMSX105.amr.corp.intel.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C884D83@BBYEXM01.pmc-sierra.internal>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF644F@FMSMSX105.amr.corp.intel.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C884D9A@BBYEXM01.pmc-sierra.internal>
Message-ID: <02EC085151D99A469E06988E94FEBCDB1CE74859@SJCEML701-CHM.china.huawei.com>

Thanks, Carolyn,
The merge was actually effortless and auto in VS/TFS.

Hi, Alex,
See if we can make it just in time for the PlugFest.

Thanks,

Yong

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Thursday, February 13, 2014 9:28 AM
To: Foster, Carolyn D; Yong Chen; nvmewin at lists.openfabrics.org
Subject: RE: Hibernation Patch

Great!

Thanks,
Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Thursday, February 13, 2014 9:27 AM
To: Alex Chang; Yong Chen; nvmewin at lists.openfabrics.org
Subject: RE: Hibernation Patch

Yes I approve the patch.

Carolyn

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Thursday, February 13, 2014 10:26 AM
To: Foster, Carolyn D; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Thanks, Carolyn. Does that mean you've approved the patch?

Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Thursday, February 13, 2014 9:10 AM
To: Alex Chang; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Hi Alex, The latest updates look good.  Thank you Yong, for allowing Intel to push an important patch and re-basing your changes.

Carolyn

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, February 12, 2014 1:53 PM
To: Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] ***UNCHECKED*** RE: Hibernation Patch

Hi all,

On the behave of Yong, I am sending out the revised hibernation patch after re-basing the most current sources. Password is "huawei".
Should you have any feedbacks, please reply to this email. Again, we have been reviewing/testing the patch for quite some time and I don't expect taking too long to receive approvals from Intel and LSI.

Thanks,
Alex

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com]
Sent: Tuesday, February 11, 2014 11:07 PM
To: Alex Chang
Cc: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Hi, Alex,

I have sent the patch to you, due to internal policy I cannot email out code directly. Please forward to the alias for alias.

The only change affected is the LBA range and .INF.

Thanks,

Yong

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:31 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Hibernation Patch

Hi Yong,

Please re-base your patch and re-send your patch again for review/test. Since we had reviewed and tested the patch a while back, I expect it won't take too long for approvals.

Thanks,
Alex


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:26 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] NVMe Windows DB Is UNLOCKED - Pushing Patch From Intel For LBA Range Type As Optional Feature

Hi all,

Thank you, Carolyn, for the effort.
The patch had been updated to the source base and a new tag called "Patch#21_LBA_Range_Type_As_Optional_Feature" had been created under tags directory.  As suggested, I updated the DriverVer entry in nvme.inf to reflect the release date, Major/Minor release numbers, NVMe Specification Compliant revision (1.0 e) and patch number as below:
DriverVer=02/11/2014, 1.2.1014.21

Should you have any questions, please reply to the email listed below.

Thanks,
Alex

nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140213/f75e8683/attachment.html>

From Rick.Knoblaugh at lsi.com  Thu Feb 13 13:48:33 2014
From: Rick.Knoblaugh at lsi.com (Knoblaugh, Rick)
Date: Thu, 13 Feb 2014 21:48:33 +0000
Subject: [nvmewin] Hibernation Patch
In-Reply-To: <E1729D5DBAB9E948BA87B76FDFA1298A0C884D9A@BBYEXM01.pmc-sierra.internal>
References: <E1729D5DBAB9E948BA87B76FDFA1298A0C884B5D@BBYEXM01.pmc-sierra.internal>
	<02EC085151D99A469E06988E94FEBCDB1CE742E9@SJCEML701-CHM.china.huawei.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C884C54@BBYEXM01.pmc-sierra.internal>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF63A0@FMSMSX105.amr.corp.intel.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C884D83@BBYEXM01.pmc-sierra.internal>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF644F@FMSMSX105.amr.corp.intel.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C884D9A@BBYEXM01.pmc-sierra.internal>
Message-ID: <45acb601a8e447439f8883ad7e268ab3@DM2PR07MB285.namprd07.prod.outlook.com>

Hi Alex,
                          We also approve patch.

Thanks,

-Rick

From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Thursday, February 13, 2014 9:28 AM
To: Foster, Carolyn D; Yong Chen; nvmewin at lists.openfabrics.org
Subject: Re: [nvmewin] Hibernation Patch

Great!

Thanks,
Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Thursday, February 13, 2014 9:27 AM
To: Alex Chang; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Yes I approve the patch.

Carolyn

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Thursday, February 13, 2014 10:26 AM
To: Foster, Carolyn D; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Thanks, Carolyn. Does that mean you've approved the patch?

Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Thursday, February 13, 2014 9:10 AM
To: Alex Chang; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Hi Alex, The latest updates look good.  Thank you Yong, for allowing Intel to push an important patch and re-basing your changes.

Carolyn

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, February 12, 2014 1:53 PM
To: Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] ***UNCHECKED*** RE: Hibernation Patch

Hi all,

On the behave of Yong, I am sending out the revised hibernation patch after re-basing the most current sources. Password is "huawei".
Should you have any feedbacks, please reply to this email. Again, we have been reviewing/testing the patch for quite some time and I don't expect taking too long to receive approvals from Intel and LSI.

Thanks,
Alex

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com]
Sent: Tuesday, February 11, 2014 11:07 PM
To: Alex Chang
Cc: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Hi, Alex,

I have sent the patch to you, due to internal policy I cannot email out code directly. Please forward to the alias for alias.

The only change affected is the LBA range and .INF.

Thanks,

Yong

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:31 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Hibernation Patch

Hi Yong,

Please re-base your patch and re-send your patch again for review/test. Since we had reviewed and tested the patch a while back, I expect it won't take too long for approvals.

Thanks,
Alex


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:26 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] NVMe Windows DB Is UNLOCKED - Pushing Patch From Intel For LBA Range Type As Optional Feature

Hi all,

Thank you, Carolyn, for the effort.
The patch had been updated to the source base and a new tag called "Patch#21_LBA_Range_Type_As_Optional_Feature" had been created under tags directory.  As suggested, I updated the DriverVer entry in nvme.inf to reflect the release date, Major/Minor release numbers, NVMe Specification Compliant revision (1.0 e) and patch number as below:
DriverVer=02/11/2014, 1.2.1014.21

Should you have any questions, please reply to the email listed below.

Thanks,
Alex

nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140213/d602187d/attachment.html>

From Alex.Chang at pmcs.com  Thu Feb 13 14:17:18 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Thu, 13 Feb 2014 22:17:18 +0000
Subject: [nvmewin] Hibernation Patch
In-Reply-To: <45acb601a8e447439f8883ad7e268ab3@DM2PR07MB285.namprd07.prod.outlook.com>
References: <E1729D5DBAB9E948BA87B76FDFA1298A0C884B5D@BBYEXM01.pmc-sierra.internal>
	<02EC085151D99A469E06988E94FEBCDB1CE742E9@SJCEML701-CHM.china.huawei.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C884C54@BBYEXM01.pmc-sierra.internal>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF63A0@FMSMSX105.amr.corp.intel.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C884D83@BBYEXM01.pmc-sierra.internal>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF644F@FMSMSX105.amr.corp.intel.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C884D9A@BBYEXM01.pmc-sierra.internal>
	<45acb601a8e447439f8883ad7e268ab3@DM2PR07MB285.namprd07.prod.outlook.com>
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C884DEC@BBYEXM01.pmc-sierra.internal>

Thanks a lot, Rick.
I will try my best to push the patch in tomorrow...

Alex

From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com]
Sent: Thursday, February 13, 2014 1:49 PM
To: Alex Chang; Foster, Carolyn D; Yong Chen; nvmewin at lists.openfabrics.org
Subject: RE: Hibernation Patch

Hi Alex,
                          We also approve patch.

Thanks,

-Rick

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Thursday, February 13, 2014 9:28 AM
To: Foster, Carolyn D; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: Re: [nvmewin] Hibernation Patch

Great!

Thanks,
Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Thursday, February 13, 2014 9:27 AM
To: Alex Chang; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Yes I approve the patch.

Carolyn

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Thursday, February 13, 2014 10:26 AM
To: Foster, Carolyn D; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Thanks, Carolyn. Does that mean you've approved the patch?

Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Thursday, February 13, 2014 9:10 AM
To: Alex Chang; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Hi Alex, The latest updates look good.  Thank you Yong, for allowing Intel to push an important patch and re-basing your changes.

Carolyn

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, February 12, 2014 1:53 PM
To: Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] ***UNCHECKED*** RE: Hibernation Patch

Hi all,

On the behave of Yong, I am sending out the revised hibernation patch after re-basing the most current sources. Password is "huawei".
Should you have any feedbacks, please reply to this email. Again, we have been reviewing/testing the patch for quite some time and I don't expect taking too long to receive approvals from Intel and LSI.

Thanks,
Alex

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com]
Sent: Tuesday, February 11, 2014 11:07 PM
To: Alex Chang
Cc: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Hi, Alex,

I have sent the patch to you, due to internal policy I cannot email out code directly. Please forward to the alias for alias.

The only change affected is the LBA range and .INF.

Thanks,

Yong

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:31 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Hibernation Patch

Hi Yong,

Please re-base your patch and re-send your patch again for review/test. Since we had reviewed and tested the patch a while back, I expect it won't take too long for approvals.

Thanks,
Alex


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:26 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] NVMe Windows DB Is UNLOCKED - Pushing Patch From Intel For LBA Range Type As Optional Feature

Hi all,

Thank you, Carolyn, for the effort.
The patch had been updated to the source base and a new tag called "Patch#21_LBA_Range_Type_As_Optional_Feature" had been created under tags directory.  As suggested, I updated the DriverVer entry in nvme.inf to reflect the release date, Major/Minor release numbers, NVMe Specification Compliant revision (1.0 e) and patch number as below:
DriverVer=02/11/2014, 1.2.1014.21

Should you have any questions, please reply to the email listed below.

Thanks,
Alex

nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140213/23f34802/attachment.html>

From ram_sunee at yahoo.com  Thu Feb 13 21:36:02 2014
From: ram_sunee at yahoo.com (Ramesh Mangamuri)
Date: Thu, 13 Feb 2014 21:36:02 -0800 (PST)
Subject: [nvmewin] nvmewin Digest, Vol 26, Issue 13
In-Reply-To: <mailman.4290.1392327550.1580.nvmewin@lists.openfabrics.org>
References: <mailman.4290.1392327550.1580.nvmewin@lists.openfabrics.org>
Message-ID: <1392356162.47941.YahooMailNeo@web163905.mail.gq1.yahoo.com>

Dear NVMe Win Driver Community,
Can some please educate me on when is the next version of the driver release is due ?
 
Best Regards,
Ramesh
 
********************************************************************************************************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender.If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
*********************************************************************************************************************************************

 



On Thursday, February 13, 2014 2:17 PM, "nvmewin-request at lists.openfabrics.org" <nvmewin-request at lists.openfabrics.org> wrote:
 
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. Re: Hibernation Patch (Knoblaugh, Rick)
   2. Re: Hibernation Patch (Alex Chang)


----------------------------------------------------------------------

Message: 1
Date: Thu, 13 Feb 2014 21:48:33 +0000
From: "Knoblaugh, Rick" <Rick.Knoblaugh at lsi.com>
To: Alex Chang <Alex.Chang at pmcs.com>, "Foster, Carolyn D"
    <carolyn.d.foster at intel.com>, Yong Chen <Yong.sc.Chen at huawei.com>,
    "nvmewin at lists.openfabrics.org" <nvmewin at lists.openfabrics.org>
Subject: Re: [nvmewin] Hibernation Patch
Message-ID:
    <45acb601a8e447439f8883ad7e268ab3 at DM2PR07MB285.namprd07.prod.outlook.com>
    
Content-Type: text/plain; charset="us-ascii"

Hi Alex,
                          We also approve patch.

Thanks,

-Rick

From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Thursday, February 13, 2014 9:28 AM
To: Foster, Carolyn D; Yong Chen; nvmewin at lists.openfabrics.org
Subject: Re: [nvmewin] Hibernation Patch

Great!

Thanks,
Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Thursday, February 13, 2014 9:27 AM
To: Alex Chang; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Yes I approve the patch.

Carolyn

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Thursday, February 13, 2014 10:26 AM
To: Foster, Carolyn D; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Thanks, Carolyn. Does that mean you've approved the patch?

Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Thursday, February 13, 2014 9:10 AM
To: Alex Chang; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Hi Alex, The latest updates look good.  Thank you Yong, for allowing Intel to push an important patch and re-basing your changes.

Carolyn

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, February 12, 2014 1:53 PM
To: Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] ***UNCHECKED*** RE: Hibernation Patch

Hi all,

On the behave of Yong, I am sending out the revised hibernation patch after re-basing the most current sources. Password is "huawei".
Should you have any feedbacks, please reply to this email. Again, we have been reviewing/testing the patch for quite some time and I don't expect taking too long to receive approvals from Intel and LSI.

Thanks,
Alex

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com]
Sent: Tuesday, February 11, 2014 11:07 PM
To: Alex Chang
Cc: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Hi, Alex,

I have sent the patch to you, due to internal policy I cannot email out code directly. Please forward to the alias for alias.

The only change affected is the LBA range and .INF.

Thanks,

Yong

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:31 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Hibernation Patch

Hi Yong,

Please re-base your patch and re-send your patch again for review/test. Since we had reviewed and tested the patch a while back, I expect it won't take too long for approvals.

Thanks,
Alex


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:26 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] NVMe Windows DB Is UNLOCKED - Pushing Patch From Intel For LBA Range Type As Optional Feature

Hi all,

Thank you, Carolyn, for the effort.
The patch had been updated to the source base and a new tag called "Patch#21_LBA_Range_Type_As_Optional_Feature" had been created under tags directory.  As suggested, I updated the DriverVer entry in nvme.inf to reflect the release date, Major/Minor release numbers, NVMe Specification Compliant revision (1.0 e) and patch number as below:
DriverVer=02/11/2014, 1.2.1014.21

Should you have any questions, please reply to the email listed below.

Thanks,
Alex

nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140213/d602187d/attachment-0001.html>

------------------------------

Message: 2
Date: Thu, 13 Feb 2014 22:17:18 +0000
From: Alex Chang <Alex.Chang at pmcs.com>
To: "Knoblaugh, Rick" <Rick.Knoblaugh at lsi.com>, "Foster, Carolyn D"
    <carolyn.d.foster at intel.com>, Yong Chen <Yong.sc.Chen at huawei.com>,
    "nvmewin at lists.openfabrics.org" <nvmewin at lists.openfabrics.org>
Subject: Re: [nvmewin] Hibernation Patch
Message-ID:
    <E1729D5DBAB9E948BA87B76FDFA1298A0C884DEC at BBYEXM01.pmc-sierra.internal>
    
Content-Type: text/plain; charset="us-ascii"

Thanks a lot, Rick.
I will try my best to push the patch in tomorrow...

Alex

From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com]
Sent: Thursday, February 13, 2014 1:49 PM
To: Alex Chang; Foster, Carolyn D; Yong Chen; nvmewin at lists.openfabrics.org
Subject: RE: Hibernation Patch

Hi Alex,
                          We also approve patch.

Thanks,

-Rick

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Thursday, February 13, 2014 9:28 AM
To: Foster, Carolyn D; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: Re: [nvmewin] Hibernation Patch

Great!

Thanks,
Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Thursday, February 13, 2014 9:27 AM
To: Alex Chang; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Yes I approve the patch.

Carolyn

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Thursday, February 13, 2014 10:26 AM
To: Foster, Carolyn D; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Thanks, Carolyn. Does that mean you've approved the patch?

Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Thursday, February 13, 2014 9:10 AM
To: Alex Chang; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Hi Alex, The latest updates look good.  Thank you Yong, for allowing Intel to push an important patch and re-basing your changes.

Carolyn

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, February 12, 2014 1:53 PM
To: Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] ***UNCHECKED*** RE: Hibernation Patch

Hi all,

On the behave of Yong, I am sending out the revised hibernation patch after re-basing the most current sources. Password is "huawei".
Should you have any feedbacks, please reply to this email. Again, we have been reviewing/testing the patch for quite some time and I don't expect taking too long to receive approvals from Intel and LSI.

Thanks,
Alex

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com]
Sent: Tuesday, February 11, 2014 11:07 PM
To: Alex Chang
Cc: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Hi, Alex,

I have sent the patch to you, due to internal policy I cannot email out code directly. Please forward to the alias for alias.

The only change affected is the LBA range and .INF.

Thanks,

Yong

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:31 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Hibernation Patch

Hi Yong,

Please re-base your patch and re-send your patch again for review/test. Since we had reviewed and tested the patch a while back, I expect it won't take too long for approvals.

Thanks,
Alex


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:26 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] NVMe Windows DB Is UNLOCKED - Pushing Patch From Intel For LBA Range Type As Optional Feature

Hi all,

Thank you, Carolyn, for the effort.
The patch had been updated to the source base and a new tag called "Patch#21_LBA_Range_Type_As_Optional_Feature" had been created under tags directory.  As suggested, I updated the DriverVer entry in nvme.inf to reflect the release date, Major/Minor release numbers, NVMe Specification Compliant revision (1.0 e) and patch number as below:
DriverVer=02/11/2014, 1.2.1014.21

Should you have any questions, please reply to the email listed below.

Thanks,
Alex

nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140213/23f34802/attachment.html>

------------------------------

_______________________________________________
nvmewin mailing list
nvmewin at lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin


End of nvmewin Digest, Vol 26, Issue 13
***************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140213/69b1e963/attachment.html>

From Alex.Chang at pmcs.com  Fri Feb 14 08:56:00 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Fri, 14 Feb 2014 16:56:00 +0000
Subject: [nvmewin] NVMe Windows DB Is LOCKED - Pushing Patch From Huawei For
 Hibernation Patch
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C884EA8@BBYEXM01.pmc-sierra.internal>

Locking NVMe Windows DB.

Thanks,
Alex

nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140214/fd0da673/attachment.html>

From james.p.freyensee at intel.com  Fri Feb 14 09:14:15 2014
From: james.p.freyensee at intel.com (Freyensee, James P)
Date: Fri, 14 Feb 2014 17:14:15 +0000
Subject: [nvmewin] nvmewin Digest, Vol 26, Issue 13
In-Reply-To: <1392356162.47941.YahooMailNeo@web163905.mail.gq1.yahoo.com>
References: <mailman.4290.1392327550.1580.nvmewin@lists.openfabrics.org>
	<1392356162.47941.YahooMailNeo@web163905.mail.gq1.yahoo.com>
Message-ID: <2D98093777D3FD46A36253F35FE9D693891C08B6@ORSMSX109.amr.corp.intel.com>

I believe the lead, Alex Chang, is working on that as we speak, as he announced the NVMe Windows source tree is currently locked.  A patch for hibernation just got accepted for merging.

Jay

From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Ramesh Mangamuri
Sent: Thursday, February 13, 2014 9:36 PM
To: nvmewin at lists.openfabrics.org
Subject: Re: [nvmewin] nvmewin Digest, Vol 26, Issue 13

Dear NVMe Win Driver Community,
Can some please educate me on when is the next version of the driver release is due ?

Best Regards,
Ramesh

********************************************************************************************************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender.If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
*********************************************************************************************************************************************



On Thursday, February 13, 2014 2:17 PM, "nvmewin-request at lists.openfabrics.org<mailto:nvmewin-request at lists.openfabrics.org>" <nvmewin-request at lists.openfabrics.org<mailto:nvmewin-request at lists.openfabrics.org>> wrote:
Send nvmewin mailing list submissions to
    nvmewin at lists.openfabrics.org<mailto: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<mailto:nvmewin-request at lists.openfabrics.org>

You can reach the person managing the list at
    nvmewin-owner at lists.openfabrics.org<mailto:nvmewin-owner at lists.openfabrics.org>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of nvmewin digest..."


Today's Topics:

  1. Re: Hibernation Patch (Knoblaugh, Rick)
  2. Re: Hibernation Patch (Alex Chang)


----------------------------------------------------------------------

Message: 1
Date: Thu, 13 Feb 2014 21:48:33 +0000
From: "Knoblaugh, Rick" <Rick.Knoblaugh at lsi.com<mailto:Rick.Knoblaugh at lsi.com>>
To: Alex Chang <Alex.Chang at pmcs.com<mailto:Alex.Chang at pmcs.com>>, "Foster, Carolyn D"
    <carolyn.d.foster at intel.com<mailto:carolyn.d.foster at intel.com>>, Yong Chen <Yong.sc.Chen at huawei.com<mailto:Yong.sc.Chen at huawei.com>>,
    "nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>" <nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>>
Subject: Re: [nvmewin] Hibernation Patch
Message-ID:
    <45acb601a8e447439f8883ad7e268ab3 at DM2PR07MB285.namprd07.prod.outlook.com<mailto:45acb601a8e447439f8883ad7e268ab3 at DM2PR07MB285.namprd07.prod.outlook.com>>

Content-Type: text/plain; charset="us-ascii"

Hi Alex,
                          We also approve patch.

Thanks,

-Rick

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org>] On Behalf Of Alex Chang
Sent: Thursday, February 13, 2014 9:28 AM
To: Foster, Carolyn D; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: Re: [nvmewin] Hibernation Patch

Great!

Thanks,
Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com<mailto:carolyn.d.foster at intel.com>]
Sent: Thursday, February 13, 2014 9:27 AM
To: Alex Chang; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org><mailto:nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>>
Subject: RE: Hibernation Patch

Yes I approve the patch.

Carolyn

From: Alex Chang [mailto:Alex.Chang at pmcs.com<mailto:Alex.Chang at pmcs.com>]
Sent: Thursday, February 13, 2014 10:26 AM
To: Foster, Carolyn D; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org><mailto:nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>>
Subject: RE: Hibernation Patch

Thanks, Carolyn. Does that mean you've approved the patch?

Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com<mailto:carolyn.d.foster at intel.com>]
Sent: Thursday, February 13, 2014 9:10 AM
To: Alex Chang; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org><mailto:nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>>
Subject: RE: Hibernation Patch

Hi Alex, The latest updates look good.  Thank you Yong, for allowing Intel to push an important patch and re-basing your changes.

Carolyn

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org><mailto:nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org>> [mailto:nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org>] On Behalf Of Alex Chang
Sent: Wednesday, February 12, 2014 1:53 PM
To: Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org><mailto:nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>>
Subject: [nvmewin] ***UNCHECKED*** RE: Hibernation Patch

Hi all,

On the behave of Yong, I am sending out the revised hibernation patch after re-basing the most current sources. Password is "huawei".
Should you have any feedbacks, please reply to this email. Again, we have been reviewing/testing the patch for quite some time and I don't expect taking too long to receive approvals from Intel and LSI.

Thanks,
Alex

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com<mailto:Yong.sc.Chen at huawei.com>]
Sent: Tuesday, February 11, 2014 11:07 PM
To: Alex Chang
Cc: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org><mailto:nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>>
Subject: RE: Hibernation Patch

Hi, Alex,

I have sent the patch to you, due to internal policy I cannot email out code directly. Please forward to the alias for alias.

The only change affected is the LBA range and .INF.

Thanks,

Yong

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org><mailto:nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org>> [mailto:nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org>] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:31 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org><mailto:nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>>
Subject: [nvmewin] Hibernation Patch

Hi Yong,

Please re-base your patch and re-send your patch again for review/test. Since we had reviewed and tested the patch a while back, I expect it won't take too long for approvals.

Thanks,
Alex


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org><mailto:nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org>> [mailto:nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org>] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:26 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org><mailto:nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>>
Subject: [nvmewin] NVMe Windows DB Is UNLOCKED - Pushing Patch From Intel For LBA Range Type As Optional Feature

Hi all,

Thank you, Carolyn, for the effort.
The patch had been updated to the source base and a new tag called "Patch#21_LBA_Range_Type_As_Optional_Feature" had been created under tags directory.  As suggested, I updated the DriverVer entry in nvme.inf to reflect the release date, Major/Minor release numbers, NVMe Specification Compliant revision (1.0 e) and patch number as below:
DriverVer=02/11/2014, 1.2.1014.21

Should you have any questions, please reply to the email listed below.

Thanks,
Alex

nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org><mailto:nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140213/d602187d/attachment-0001.html>

------------------------------

Message: 2
Date: Thu, 13 Feb 2014 22:17:18 +0000
From: Alex Chang <Alex.Chang at pmcs.com<mailto:Alex.Chang at pmcs.com>>
To: "Knoblaugh, Rick" <Rick.Knoblaugh at lsi.com<mailto:Rick.Knoblaugh at lsi.com>>, "Foster, Carolyn D"
    <carolyn.d.foster at intel.com<mailto:carolyn.d.foster at intel.com>>, Yong Chen <Yong.sc.Chen at huawei.com<mailto:Yong.sc.Chen at huawei.com>>,
    "nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>" <nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>>
Subject: Re: [nvmewin] Hibernation Patch
Message-ID:
    <E1729D5DBAB9E948BA87B76FDFA1298A0C884DEC at BBYEXM01.pmc-sierra.internal<mailto:E1729D5DBAB9E948BA87B76FDFA1298A0C884DEC at BBYEXM01.pmc-sierra.internal>>

Content-Type: text/plain; charset="us-ascii"

Thanks a lot, Rick.
I will try my best to push the patch in tomorrow...

Alex

From: Knoblaugh, Rick [mailto:Rick.Knoblaugh at lsi.com<mailto:Rick.Knoblaugh at lsi.com>]
Sent: Thursday, February 13, 2014 1:49 PM
To: Alex Chang; Foster, Carolyn D; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Hibernation Patch

Hi Alex,
                          We also approve patch.

Thanks,

-Rick

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org><mailto:nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org>> [mailto:nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org>] On Behalf Of Alex Chang
Sent: Thursday, February 13, 2014 9:28 AM
To: Foster, Carolyn D; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org><mailto:nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>>
Subject: Re: [nvmewin] Hibernation Patch

Great!

Thanks,
Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com<mailto:carolyn.d.foster at intel.com>]
Sent: Thursday, February 13, 2014 9:27 AM
To: Alex Chang; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org><mailto:nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>>
Subject: RE: Hibernation Patch

Yes I approve the patch.

Carolyn

From: Alex Chang [mailto:Alex.Chang at pmcs.com<mailto:Alex.Chang at pmcs.com>]
Sent: Thursday, February 13, 2014 10:26 AM
To: Foster, Carolyn D; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org><mailto:nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>>
Subject: RE: Hibernation Patch

Thanks, Carolyn. Does that mean you've approved the patch?

Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com<mailto:carolyn.d.foster at intel.com>]
Sent: Thursday, February 13, 2014 9:10 AM
To: Alex Chang; Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org><mailto:nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>>
Subject: RE: Hibernation Patch

Hi Alex, The latest updates look good.  Thank you Yong, for allowing Intel to push an important patch and re-basing your changes.

Carolyn

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org><mailto:nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org>> [mailto:nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org>] On Behalf Of Alex Chang
Sent: Wednesday, February 12, 2014 1:53 PM
To: Yong Chen; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org><mailto:nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>>
Subject: [nvmewin] ***UNCHECKED*** RE: Hibernation Patch

Hi all,

On the behave of Yong, I am sending out the revised hibernation patch after re-basing the most current sources. Password is "huawei".
Should you have any feedbacks, please reply to this email. Again, we have been reviewing/testing the patch for quite some time and I don't expect taking too long to receive approvals from Intel and LSI.

Thanks,
Alex

From: Yong Chen [mailto:Yong.sc.Chen at huawei.com<mailto:Yong.sc.Chen at huawei.com>]
Sent: Tuesday, February 11, 2014 11:07 PM
To: Alex Chang
Cc: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org><mailto:nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>>
Subject: RE: Hibernation Patch

Hi, Alex,

I have sent the patch to you, due to internal policy I cannot email out code directly. Please forward to the alias for alias.

The only change affected is the LBA range and .INF.

Thanks,

Yong

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org><mailto:nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org>> [mailto:nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org>] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:31 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org><mailto:nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>>
Subject: [nvmewin] Hibernation Patch

Hi Yong,

Please re-base your patch and re-send your patch again for review/test. Since we had reviewed and tested the patch a while back, I expect it won't take too long for approvals.

Thanks,
Alex


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org><mailto:nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org>> [mailto:nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org>] On Behalf Of Alex Chang
Sent: Tuesday, February 11, 2014 2:26 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org><mailto:nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>>
Subject: [nvmewin] NVMe Windows DB Is UNLOCKED - Pushing Patch From Intel For LBA Range Type As Optional Feature

Hi all,

Thank you, Carolyn, for the effort.
The patch had been updated to the source base and a new tag called "Patch#21_LBA_Range_Type_As_Optional_Feature" had been created under tags directory.  As suggested, I updated the DriverVer entry in nvme.inf to reflect the release date, Major/Minor release numbers, NVMe Specification Compliant revision (1.0 e) and patch number as below:
DriverVer=02/11/2014, 1.2.1014.21

Should you have any questions, please reply to the email listed below.

Thanks,
Alex

nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org><mailto:nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140213/23f34802/attachment.html>

------------------------------

_______________________________________________
nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin


End of nvmewin Digest, Vol 26, Issue 13
***************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140214/ac883bd6/attachment.html>

From Kwok.Kong at pmcs.com  Fri Feb 14 09:26:04 2014
From: Kwok.Kong at pmcs.com (Kwok Kong)
Date: Fri, 14 Feb 2014 17:26:04 +0000
Subject: [nvmewin] Next NVMe driver is going to be released in March
Message-ID: <03D88B383FA04244AA514AA931F7B1290D2933CF@BBYEXM01.pmc-sierra.internal>

Ramesh,

It is expected to have the next release 1.3 ready in early March.

Regards,

-Kwok


From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Ramesh Mangamuri
Sent: Thursday, February 13, 2014 9:36 PM
To: nvmewin at lists.openfabrics.org
Subject: Re: [nvmewin] nvmewin Digest, Vol 26, Issue 13

Dear NVMe Win Driver Community,
Can some please educate me on when is the next version of the driver release is due ?

Best Regards,
Ramesh


From Alex.Chang at pmcs.com  Fri Feb 14 09:50:45 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Fri, 14 Feb 2014 17:50:45 +0000
Subject: [nvmewin] NVMe Windows DB Is UNLOCKED - Pushing Patch From Huawei
 For Hibernation Support
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C884ECD@BBYEXM01.pmc-sierra.internal>

Hi all,

Thank you, Yong, for the effort.
The patch had been updated to the source base and a new tag called "Patch#22_Hibernation_Support" had been created under tags directory.  in addition to updating DriverVer as "DriverVer=02/14/2014, 1.2.1014.22", I modified the following entries in nvme.inf to better describe which NVMe Specification the driver is compliant with:
diskId1 = "NVMe Installation Disk"
CommNvme.DeviceDesc = "Community NVMe 1.0e Storport Miniport"

Should you have any questions, please reply to the email listed below.

Thanks,
Alex

nvmewin mailing list
nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140214/f77ce319/attachment.html>

From Alex.Chang at pmcs.com  Fri Feb 14 10:17:11 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Fri, 14 Feb 2014 18:17:11 +0000
Subject: [nvmewin] Re-send Sandisk Patch For Reset Fixes
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C884EEB@BBYEXM01.pmc-sierra.internal>

Good morning, Dharani,

As you may know, both Intel and Huawei patches had been added into OFA source base. Now, you may re-base your changes and send a patch out for review/test. Thank you very much for contributing the fixes.

Regards,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, January 15, 2014 2:08 PM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: Would you please help to resolve a few OFA NVMe driver problems ?


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the source for the preliminary review. I have tested the IO and scsi compliance test. I don't have a drive which supports abort/lun resets, not sure how to test the format command.

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:54 AM
To: Dharani Kotte; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Happy Holidays to you all.
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 11:52 AM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Thank you for the explanation. Sure I will take look.
Happy Holidays.
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:44 AM
To: Kwok Kong; Dharani Kotte; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Dharani,

The controller reset can be issued from either from the host or the driver itself. Currently, the driver seems handling them in the same manner via single entry "NVMeResetController". In the case of "from the host", the driver needs to separate the cases of SRB_FUNCTION_RESET_... requests from the ioctl request of NVME_RESET_DEVICE in the sense of handling pending IOs. In the case of "the driver itself", needs to re-exam the related error recovery codes as well.
Judy from Samsung suggested referring the storahci.sys driver sample codes for Windows 7/8 based on reset bus logic examples and detailed recommendations.

Thank you,
Alex


From: Kwok Kong
Sent: Friday, December 20, 2013 9:08 AM
To: Dharani Kotte; Akshay Mathur; Alex Chang
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Dharani,

Yes, these are the three areas that you are committed to.

Alex,

Please send more details on the "Controller reset does not handle all cases"  to Dharani.

Thanks

-Kwok

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 9:02 AM
To: Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Kwok,

I think the below are the items that we are committing for:
- Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
- Controller reset does not handle all cases
- orphaned requests

Can somebody provide little bit more details on the expectation for the item "Controller reset does not handle all cases".

Thanks,
Dharani.


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Thursday, December 19, 2013 6:53 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Excellent! Your help is much appreciated.

Dharani,

Please let me know if you have any question.

Happy holiday to all of you.

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Thursday, December 19, 2013 6:51 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kwok,
You are welcome. We are pleased to contribute to the community and appreciate you driving it!

We will try our best to complete the implementation by end of January but we may not be able to complete comprehensive testing by that time. This is because of overlaps with few internal business deliverables and a company-wide shut-down for next 1.5 weeks.

Anyway, Dharani will be in touch with you as he makes progress.
Thanks
Akshay

From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Tuesday, December 17, 2013 4:21 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Akshay,

Thanks for your willingness to contribute to the driver.   I am looking for a patch before end of Jan 2014, the earlier the better.
Please let me know if Sandisk can commit to that.

Your help is much appreciated.

Thanks

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Tuesday, December 17, 2013 4:11 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman; Akshay Mathur
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kowk,
I manage the Software and driver development team at SanDisk/ESS.
We are certainly willing to contribute to fixing the problems listed below but before we can commit, we would like to get clarification on the timeline i.e. by when these fixes are expected to be completed.
Thanks
Akshay Mathur
Sr Software Manager, Enterprise Storage Solutions
951 SanDisk Drive, Building #5  |  Milpitas, CA 95035 U.S.A.  |  Direct  +1 408.801.1336  |
Cell +1 856.607.7323  |  Corporate +1 408.801.1000  |  Akshay.Mathur at sandisk.com<mailto:Akshay.Mathur at sandisk.com>
[Description: cid:image001.jpg at 01CC358D.60974910]


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Wednesday, December 11, 2013 18:00
To: Dave Landsman
Cc: Dharani Kotte
Subject: Would you please help to resolve a few OFA NVMe driver problems ?

Dave and Dharani,

There are some issues with the current OFA driver that need to be fixed. PMC is working on resolving some of the problems. Intel has agreed to work on the following two problems:
- remove #define for CHATHAM2
- Learning of CPU core to Vector failure handling

I am also making request to other companies to work on some of the issues.

I wonder if your company can work on the following three problems:
                - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
                - Controller reset does not handle all cases
                - orphaned requests

Please let me know if your company can work on these two issues.

Thanks

-Kwok



________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140214/a2b3d0ed/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 9449 bytes
Desc: image001.jpg
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140214/a2b3d0ed/attachment.jpg>

From Dharani.Kotte at sandisk.com  Fri Feb 14 10:18:17 2014
From: Dharani.Kotte at sandisk.com (Dharani Kotte)
Date: Fri, 14 Feb 2014 18:18:17 +0000
Subject: [nvmewin] Re-send Sandisk Patch For Reset Fixes
In-Reply-To: <E1729D5DBAB9E948BA87B76FDFA1298A0C884EEB@BBYEXM01.pmc-sierra.internal>
References: <E1729D5DBAB9E948BA87B76FDFA1298A0C884EEB@BBYEXM01.pmc-sierra.internal>
Message-ID: <23EC73C80FB59046A6B7B8EB7B3826593BDF0B5C@SACMBXIP01.sdcorp.global.sandisk.com>

Sure Alex.
Dharani.

From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Friday, February 14, 2014 10:17 AM
To: nvmewin at lists.openfabrics.org
Subject: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Good morning, Dharani,

As you may know, both Intel and Huawei patches had been added into OFA source base. Now, you may re-base your changes and send a patch out for review/test. Thank you very much for contributing the fixes.

Regards,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, January 15, 2014 2:08 PM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: Would you please help to resolve a few OFA NVMe driver problems ?


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the source for the preliminary review. I have tested the IO and scsi compliance test. I don't have a drive which supports abort/lun resets, not sure how to test the format command.

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:54 AM
To: Dharani Kotte; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Happy Holidays to you all.
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 11:52 AM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Thank you for the explanation. Sure I will take look.
Happy Holidays.
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:44 AM
To: Kwok Kong; Dharani Kotte; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Dharani,

The controller reset can be issued from either from the host or the driver itself. Currently, the driver seems handling them in the same manner via single entry "NVMeResetController". In the case of "from the host", the driver needs to separate the cases of SRB_FUNCTION_RESET_... requests from the ioctl request of NVME_RESET_DEVICE in the sense of handling pending IOs. In the case of "the driver itself", needs to re-exam the related error recovery codes as well.
Judy from Samsung suggested referring the storahci.sys driver sample codes for Windows 7/8 based on reset bus logic examples and detailed recommendations.

Thank you,
Alex


From: Kwok Kong
Sent: Friday, December 20, 2013 9:08 AM
To: Dharani Kotte; Akshay Mathur; Alex Chang
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Dharani,

Yes, these are the three areas that you are committed to.

Alex,

Please send more details on the "Controller reset does not handle all cases"  to Dharani.

Thanks

-Kwok

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 9:02 AM
To: Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Kwok,

I think the below are the items that we are committing for:
- Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
- Controller reset does not handle all cases
- orphaned requests

Can somebody provide little bit more details on the expectation for the item "Controller reset does not handle all cases".

Thanks,
Dharani.


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Thursday, December 19, 2013 6:53 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Excellent! Your help is much appreciated.

Dharani,

Please let me know if you have any question.

Happy holiday to all of you.

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Thursday, December 19, 2013 6:51 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kwok,
You are welcome. We are pleased to contribute to the community and appreciate you driving it!

We will try our best to complete the implementation by end of January but we may not be able to complete comprehensive testing by that time. This is because of overlaps with few internal business deliverables and a company-wide shut-down for next 1.5 weeks.

Anyway, Dharani will be in touch with you as he makes progress.
Thanks
Akshay

From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Tuesday, December 17, 2013 4:21 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Akshay,

Thanks for your willingness to contribute to the driver.   I am looking for a patch before end of Jan 2014, the earlier the better.
Please let me know if Sandisk can commit to that.

Your help is much appreciated.

Thanks

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Tuesday, December 17, 2013 4:11 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman; Akshay Mathur
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kowk,
I manage the Software and driver development team at SanDisk/ESS.
We are certainly willing to contribute to fixing the problems listed below but before we can commit, we would like to get clarification on the timeline i.e. by when these fixes are expected to be completed.
Thanks
Akshay Mathur
Sr Software Manager, Enterprise Storage Solutions
951 SanDisk Drive, Building #5  |  Milpitas, CA 95035 U.S.A.  |  Direct  +1 408.801.1336  |
Cell +1 856.607.7323  |  Corporate +1 408.801.1000  |  Akshay.Mathur at sandisk.com<mailto:Akshay.Mathur at sandisk.com>
[Description: cid:image001.jpg at 01CC358D.60974910]


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Wednesday, December 11, 2013 18:00
To: Dave Landsman
Cc: Dharani Kotte
Subject: Would you please help to resolve a few OFA NVMe driver problems ?

Dave and Dharani,

There are some issues with the current OFA driver that need to be fixed. PMC is working on resolving some of the problems. Intel has agreed to work on the following two problems:
- remove #define for CHATHAM2
- Learning of CPU core to Vector failure handling

I am also making request to other companies to work on some of the issues.

I wonder if your company can work on the following three problems:
                - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
                - Controller reset does not handle all cases
                - orphaned requests

Please let me know if your company can work on these two issues.

Thanks

-Kwok



________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140214/f0357ecf/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 9449 bytes
Desc: image001.jpg
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140214/f0357ecf/attachment.jpg>

From Alex.Chang at pmcs.com  Wed Feb 19 09:05:40 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Wed, 19 Feb 2014 17:05:40 +0000
Subject: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes
In-Reply-To: <26455_1392829222_5304E326_26455_6404_1_23EC73C80FB59046A6B7B8EB7B3826593BDF1488@SACMBXIP01.sdcorp.global.sandisk.com>
References: <E1729D5DBAB9E948BA87B76FDFA1298A0C884EEB@BBYEXM01.pmc-sierra.internal>
	<23EC73C80FB59046A6B7B8EB7B3826593BDF0B5C@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889023@BBYEXM01.pmc-sierra.internal>
	<23EC73C80FB59046A6B7B8EB7B3826593BDF134C@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889036@BBYEXM01.pmc-sierra.internal>
	<26455_1392829222_5304E326_26455_6404_1_23EC73C80FB59046A6B7B8EB7B3826593BDF1488@SACMBXIP01.sdcorp.global.sandisk.com>
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C88952B@BBYEXM01.pmc-sierra.internal>

Thank you, Dharani.

Hi all,

Please review/test the attached reset fix patch from Sandisk and provide your feedbacks.

Thank you very much,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, February 19, 2014 9:00 AM
To: Alex Chang
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the patch source for review. I have tested the I/O running over night.

Areas need to be focused for test this patch:
1. Test abort/LUN resets.
2. Test chip reset.
3. Test the format command.
4.Test Firmware download command.

Password is "sndk1234"

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 18, 2014 12:15 PM
To: Dharani Kotte
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Great!

Thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Tuesday, February 18, 2014 12:14 PM
To: Alex Chang
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Just testing after merging the code it I should be able to  send it tomorrow morning.
Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 18, 2014 12:13 PM
To: Dharani Kotte
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Hi Dharani,

Just a friendly reminder, could you please send out your patch as soon as it's ready?

Many thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, February 14, 2014 10:18 AM
To: Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Sure Alex.
Dharani.

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Friday, February 14, 2014 10:17 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Good morning, Dharani,

As you may know, both Intel and Huawei patches had been added into OFA source base. Now, you may re-base your changes and send a patch out for review/test. Thank you very much for contributing the fixes.

Regards,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, January 15, 2014 2:08 PM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: Would you please help to resolve a few OFA NVMe driver problems ?


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the source for the preliminary review. I have tested the IO and scsi compliance test. I don't have a drive which supports abort/lun resets, not sure how to test the format command.

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:54 AM
To: Dharani Kotte; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Happy Holidays to you all.
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 11:52 AM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Thank you for the explanation. Sure I will take look.
Happy Holidays.
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:44 AM
To: Kwok Kong; Dharani Kotte; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Dharani,

The controller reset can be issued from either from the host or the driver itself. Currently, the driver seems handling them in the same manner via single entry "NVMeResetController". In the case of "from the host", the driver needs to separate the cases of SRB_FUNCTION_RESET_... requests from the ioctl request of NVME_RESET_DEVICE in the sense of handling pending IOs. In the case of "the driver itself", needs to re-exam the related error recovery codes as well.
Judy from Samsung suggested referring the storahci.sys driver sample codes for Windows 7/8 based on reset bus logic examples and detailed recommendations.

Thank you,
Alex


From: Kwok Kong
Sent: Friday, December 20, 2013 9:08 AM
To: Dharani Kotte; Akshay Mathur; Alex Chang
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Dharani,

Yes, these are the three areas that you are committed to.

Alex,

Please send more details on the "Controller reset does not handle all cases"  to Dharani.

Thanks

-Kwok

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 9:02 AM
To: Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Kwok,

I think the below are the items that we are committing for:
- Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
- Controller reset does not handle all cases
- orphaned requests

Can somebody provide little bit more details on the expectation for the item "Controller reset does not handle all cases".

Thanks,
Dharani.


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Thursday, December 19, 2013 6:53 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Excellent! Your help is much appreciated.

Dharani,

Please let me know if you have any question.

Happy holiday to all of you.

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Thursday, December 19, 2013 6:51 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kwok,
You are welcome. We are pleased to contribute to the community and appreciate you driving it!

We will try our best to complete the implementation by end of January but we may not be able to complete comprehensive testing by that time. This is because of overlaps with few internal business deliverables and a company-wide shut-down for next 1.5 weeks.

Anyway, Dharani will be in touch with you as he makes progress.
Thanks
Akshay

From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Tuesday, December 17, 2013 4:21 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Akshay,

Thanks for your willingness to contribute to the driver.   I am looking for a patch before end of Jan 2014, the earlier the better.
Please let me know if Sandisk can commit to that.

Your help is much appreciated.

Thanks

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Tuesday, December 17, 2013 4:11 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman; Akshay Mathur
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kowk,
I manage the Software and driver development team at SanDisk/ESS.
We are certainly willing to contribute to fixing the problems listed below but before we can commit, we would like to get clarification on the timeline i.e. by when these fixes are expected to be completed.
Thanks
Akshay Mathur
Sr Software Manager, Enterprise Storage Solutions
951 SanDisk Drive, Building #5  |  Milpitas, CA 95035 U.S.A.  |  Direct  +1 408.801.1336  |
Cell +1 856.607.7323  |  Corporate +1 408.801.1000  |  Akshay.Mathur at sandisk.com<mailto:Akshay.Mathur at sandisk.com>
[Description: cid:image001.jpg at 01CC358D.60974910]


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Wednesday, December 11, 2013 18:00
To: Dave Landsman
Cc: Dharani Kotte
Subject: Would you please help to resolve a few OFA NVMe driver problems ?

Dave and Dharani,

There are some issues with the current OFA driver that need to be fixed. PMC is working on resolving some of the problems. Intel has agreed to work on the following two problems:
- remove #define for CHATHAM2
- Learning of CPU core to Vector failure handling

I am also making request to other companies to work on some of the issues.

I wonder if your company can work on the following three problems:
                - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
                - Controller reset does not handle all cases
                - orphaned requests

Please let me know if your company can work on these two issues.

Thanks

-Kwok



________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).









-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140219/eca8f4e4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 9449 bytes
Desc: image001.jpg
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140219/eca8f4e4/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: source_sndk_02_19_2014.zip
Type: application/x-zip-compressed
Size: 177005 bytes
Desc: source_sndk_02_19_2014.zip
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140219/eca8f4e4/attachment.bin>

From carolyn.d.foster at intel.com  Mon Feb 24 15:50:39 2014
From: carolyn.d.foster at intel.com (Foster, Carolyn D)
Date: Mon, 24 Feb 2014 23:50:39 +0000
Subject: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset
 Fixes
In-Reply-To: <E1729D5DBAB9E948BA87B76FDFA1298A0C88952B@BBYEXM01.pmc-sierra.internal>
References: <E1729D5DBAB9E948BA87B76FDFA1298A0C884EEB@BBYEXM01.pmc-sierra.internal>
	<23EC73C80FB59046A6B7B8EB7B3826593BDF0B5C@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889023@BBYEXM01.pmc-sierra.internal>
	<23EC73C80FB59046A6B7B8EB7B3826593BDF134C@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889036@BBYEXM01.pmc-sierra.internal>
	<26455_1392829222_5304E326_26455_6404_1_23EC73C80FB59046A6B7B8EB7B3826593BDF1488@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C88952B@BBYEXM01.pmc-sierra.internal>
Message-ID: <B3A485AFDDB1DD4598621E85E8EB67A83AAF9C48@FMSMSX105.amr.corp.intel.com>

Hi Alex and Dharni,

I have been reviewing the code and performing some tests and I have some concerns about this patch.

In nvmeStd.c:
Line 1384: NVMeProcessAbortLunReset - This change will now send abort commands for all pending requests when a RESET_LOGICAL_UNIT request comes in, instead of issuing the RecoveryDpc routine.  This change concerns me the most.  During a reset there is no need to send individual abort requests for outstanding commands.  When the LUN reset comes in, we will set CC.EN to 0 and the spec clearly states that "the controller shall not process commands nor post completion queue entries to the completion queue."  This reset behavior has been accounted for in the driver, by design.  In the LUN reset case, we should continue to issue the recovery DPC routine, which will complete all outstanding commands.

What should happen here is that the new processAbortLun function should be moved under the SRB_FUNCTION_ABORT_COMMAND only.  Then the procesAbortLunReset function should only send one abort and not abort all outstanding commands.

Also, during testing, I hit a D1 BSOD when I tried to step through the code.  I ran IO and forced a timeout by using the debugger to skip over the line of code that rings the submission queue doorbell.  The IO should be timed out by storport, which will then send a reset lun.

Line 2219: StorPortSynchronizeAccess - I don't understand why this is needed.  The SynchronizeReset function looks very much like the recovery DPC routine, which should already be synchronized with Start IO and the interrupt DPC.

Thanks,
Carolyn


From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, February 19, 2014 10:06 AM
To: nvmewin at lists.openfabrics.org
Subject: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Thank you, Dharani.

Hi all,

Please review/test the attached reset fix patch from Sandisk and provide your feedbacks.

Thank you very much,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, February 19, 2014 9:00 AM
To: Alex Chang
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the patch source for review. I have tested the I/O running over night.

Areas need to be focused for test this patch:
1. Test abort/LUN resets.
2. Test chip reset.
3. Test the format command.
4.Test Firmware download command.

Password is "sndk1234"

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 18, 2014 12:15 PM
To: Dharani Kotte
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Great!

Thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Tuesday, February 18, 2014 12:14 PM
To: Alex Chang
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Just testing after merging the code it I should be able to  send it tomorrow morning.
Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 18, 2014 12:13 PM
To: Dharani Kotte
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Hi Dharani,

Just a friendly reminder, could you please send out your patch as soon as it's ready?

Many thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, February 14, 2014 10:18 AM
To: Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Sure Alex.
Dharani.

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Friday, February 14, 2014 10:17 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Good morning, Dharani,

As you may know, both Intel and Huawei patches had been added into OFA source base. Now, you may re-base your changes and send a patch out for review/test. Thank you very much for contributing the fixes.

Regards,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, January 15, 2014 2:08 PM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: Would you please help to resolve a few OFA NVMe driver problems ?


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the source for the preliminary review. I have tested the IO and scsi compliance test. I don't have a drive which supports abort/lun resets, not sure how to test the format command.

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:54 AM
To: Dharani Kotte; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Happy Holidays to you all.
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 11:52 AM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Thank you for the explanation. Sure I will take look.
Happy Holidays.
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:44 AM
To: Kwok Kong; Dharani Kotte; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Dharani,

The controller reset can be issued from either from the host or the driver itself. Currently, the driver seems handling them in the same manner via single entry "NVMeResetController". In the case of "from the host", the driver needs to separate the cases of SRB_FUNCTION_RESET_... requests from the ioctl request of NVME_RESET_DEVICE in the sense of handling pending IOs. In the case of "the driver itself", needs to re-exam the related error recovery codes as well.
Judy from Samsung suggested referring the storahci.sys driver sample codes for Windows 7/8 based on reset bus logic examples and detailed recommendations.

Thank you,
Alex


From: Kwok Kong
Sent: Friday, December 20, 2013 9:08 AM
To: Dharani Kotte; Akshay Mathur; Alex Chang
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Dharani,

Yes, these are the three areas that you are committed to.

Alex,

Please send more details on the "Controller reset does not handle all cases"  to Dharani.

Thanks

-Kwok

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 9:02 AM
To: Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Kwok,

I think the below are the items that we are committing for:
- Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
- Controller reset does not handle all cases
- orphaned requests

Can somebody provide little bit more details on the expectation for the item "Controller reset does not handle all cases".

Thanks,
Dharani.


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Thursday, December 19, 2013 6:53 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Excellent! Your help is much appreciated.

Dharani,

Please let me know if you have any question.

Happy holiday to all of you.

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Thursday, December 19, 2013 6:51 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kwok,
You are welcome. We are pleased to contribute to the community and appreciate you driving it!

We will try our best to complete the implementation by end of January but we may not be able to complete comprehensive testing by that time. This is because of overlaps with few internal business deliverables and a company-wide shut-down for next 1.5 weeks.

Anyway, Dharani will be in touch with you as he makes progress.
Thanks
Akshay

From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Tuesday, December 17, 2013 4:21 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Akshay,

Thanks for your willingness to contribute to the driver.   I am looking for a patch before end of Jan 2014, the earlier the better.
Please let me know if Sandisk can commit to that.

Your help is much appreciated.

Thanks

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Tuesday, December 17, 2013 4:11 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman; Akshay Mathur
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kowk,
I manage the Software and driver development team at SanDisk/ESS.
We are certainly willing to contribute to fixing the problems listed below but before we can commit, we would like to get clarification on the timeline i.e. by when these fixes are expected to be completed.
Thanks
Akshay Mathur
Sr Software Manager, Enterprise Storage Solutions
951 SanDisk Drive, Building #5  |  Milpitas, CA 95035 U.S.A.  |  Direct  +1 408.801.1336  |
Cell +1 856.607.7323  |  Corporate +1 408.801.1000  |  Akshay.Mathur at sandisk.com<mailto:Akshay.Mathur at sandisk.com>
[Description: cid:image001.jpg at 01CC358D.60974910]


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Wednesday, December 11, 2013 18:00
To: Dave Landsman
Cc: Dharani Kotte
Subject: Would you please help to resolve a few OFA NVMe driver problems ?

Dave and Dharani,

There are some issues with the current OFA driver that need to be fixed. PMC is working on resolving some of the problems. Intel has agreed to work on the following two problems:
- remove #define for CHATHAM2
- Learning of CPU core to Vector failure handling

I am also making request to other companies to work on some of the issues.

I wonder if your company can work on the following three problems:
                - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
                - Controller reset does not handle all cases
                - orphaned requests

Please let me know if your company can work on these two issues.

Thanks

-Kwok



________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).









-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140224/2c6e3d58/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 9449 bytes
Desc: image001.jpg
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140224/2c6e3d58/attachment.jpg>

From Alex.Chang at pmcs.com  Mon Feb 24 15:58:51 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Mon, 24 Feb 2014 23:58:51 +0000
Subject: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset
 Fixes
In-Reply-To: <B3A485AFDDB1DD4598621E85E8EB67A83AAF9C48@FMSMSX105.amr.corp.intel.com>
References: <E1729D5DBAB9E948BA87B76FDFA1298A0C884EEB@BBYEXM01.pmc-sierra.internal>
	<23EC73C80FB59046A6B7B8EB7B3826593BDF0B5C@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889023@BBYEXM01.pmc-sierra.internal>
	<23EC73C80FB59046A6B7B8EB7B3826593BDF134C@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889036@BBYEXM01.pmc-sierra.internal>
	<26455_1392829222_5304E326_26455_6404_1_23EC73C80FB59046A6B7B8EB7B3826593BDF1488@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C88952B@BBYEXM01.pmc-sierra.internal>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF9C48@FMSMSX105.amr.corp.intel.com>
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C889D51@BBYEXM01.pmc-sierra.internal>

Hi Carolyn,

Did you root cause why D1 BSOD hit when you forced a time out?

Thanks,
Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Monday, February 24, 2014 3:51 PM
To: Alex Chang; nvmewin at lists.openfabrics.org
Subject: RE: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Hi Alex and Dharni,

I have been reviewing the code and performing some tests and I have some concerns about this patch.

In nvmeStd.c:
Line 1384: NVMeProcessAbortLunReset - This change will now send abort commands for all pending requests when a RESET_LOGICAL_UNIT request comes in, instead of issuing the RecoveryDpc routine.  This change concerns me the most.  During a reset there is no need to send individual abort requests for outstanding commands.  When the LUN reset comes in, we will set CC.EN to 0 and the spec clearly states that "the controller shall not process commands nor post completion queue entries to the completion queue."  This reset behavior has been accounted for in the driver, by design.  In the LUN reset case, we should continue to issue the recovery DPC routine, which will complete all outstanding commands.

What should happen here is that the new processAbortLun function should be moved under the SRB_FUNCTION_ABORT_COMMAND only.  Then the procesAbortLunReset function should only send one abort and not abort all outstanding commands.

Also, during testing, I hit a D1 BSOD when I tried to step through the code.  I ran IO and forced a timeout by using the debugger to skip over the line of code that rings the submission queue doorbell.  The IO should be timed out by storport, which will then send a reset lun.

Line 2219: StorPortSynchronizeAccess - I don't understand why this is needed.  The SynchronizeReset function looks very much like the recovery DPC routine, which should already be synchronized with Start IO and the interrupt DPC.

Thanks,
Carolyn


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, February 19, 2014 10:06 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Thank you, Dharani.

Hi all,

Please review/test the attached reset fix patch from Sandisk and provide your feedbacks.

Thank you very much,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, February 19, 2014 9:00 AM
To: Alex Chang
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the patch source for review. I have tested the I/O running over night.

Areas need to be focused for test this patch:
1. Test abort/LUN resets.
2. Test chip reset.
3. Test the format command.
4.Test Firmware download command.

Password is "sndk1234"

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 18, 2014 12:15 PM
To: Dharani Kotte
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Great!

Thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Tuesday, February 18, 2014 12:14 PM
To: Alex Chang
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Just testing after merging the code it I should be able to  send it tomorrow morning.
Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 18, 2014 12:13 PM
To: Dharani Kotte
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Hi Dharani,

Just a friendly reminder, could you please send out your patch as soon as it's ready?

Many thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, February 14, 2014 10:18 AM
To: Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Sure Alex.
Dharani.

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Friday, February 14, 2014 10:17 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Good morning, Dharani,

As you may know, both Intel and Huawei patches had been added into OFA source base. Now, you may re-base your changes and send a patch out for review/test. Thank you very much for contributing the fixes.

Regards,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, January 15, 2014 2:08 PM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: Would you please help to resolve a few OFA NVMe driver problems ?


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the source for the preliminary review. I have tested the IO and scsi compliance test. I don't have a drive which supports abort/lun resets, not sure how to test the format command.

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:54 AM
To: Dharani Kotte; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Happy Holidays to you all.
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 11:52 AM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Thank you for the explanation. Sure I will take look.
Happy Holidays.
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:44 AM
To: Kwok Kong; Dharani Kotte; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Dharani,

The controller reset can be issued from either from the host or the driver itself. Currently, the driver seems handling them in the same manner via single entry "NVMeResetController". In the case of "from the host", the driver needs to separate the cases of SRB_FUNCTION_RESET_... requests from the ioctl request of NVME_RESET_DEVICE in the sense of handling pending IOs. In the case of "the driver itself", needs to re-exam the related error recovery codes as well.
Judy from Samsung suggested referring the storahci.sys driver sample codes for Windows 7/8 based on reset bus logic examples and detailed recommendations.

Thank you,
Alex


From: Kwok Kong
Sent: Friday, December 20, 2013 9:08 AM
To: Dharani Kotte; Akshay Mathur; Alex Chang
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Dharani,

Yes, these are the three areas that you are committed to.

Alex,

Please send more details on the "Controller reset does not handle all cases"  to Dharani.

Thanks

-Kwok

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 9:02 AM
To: Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Kwok,

I think the below are the items that we are committing for:
- Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
- Controller reset does not handle all cases
- orphaned requests

Can somebody provide little bit more details on the expectation for the item "Controller reset does not handle all cases".

Thanks,
Dharani.


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Thursday, December 19, 2013 6:53 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Excellent! Your help is much appreciated.

Dharani,

Please let me know if you have any question.

Happy holiday to all of you.

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Thursday, December 19, 2013 6:51 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kwok,
You are welcome. We are pleased to contribute to the community and appreciate you driving it!

We will try our best to complete the implementation by end of January but we may not be able to complete comprehensive testing by that time. This is because of overlaps with few internal business deliverables and a company-wide shut-down for next 1.5 weeks.

Anyway, Dharani will be in touch with you as he makes progress.
Thanks
Akshay

From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Tuesday, December 17, 2013 4:21 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Akshay,

Thanks for your willingness to contribute to the driver.   I am looking for a patch before end of Jan 2014, the earlier the better.
Please let me know if Sandisk can commit to that.

Your help is much appreciated.

Thanks

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Tuesday, December 17, 2013 4:11 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman; Akshay Mathur
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kowk,
I manage the Software and driver development team at SanDisk/ESS.
We are certainly willing to contribute to fixing the problems listed below but before we can commit, we would like to get clarification on the timeline i.e. by when these fixes are expected to be completed.
Thanks
Akshay Mathur
Sr Software Manager, Enterprise Storage Solutions
951 SanDisk Drive, Building #5  |  Milpitas, CA 95035 U.S.A.  |  Direct  +1 408.801.1336  |
Cell +1 856.607.7323  |  Corporate +1 408.801.1000  |  Akshay.Mathur at sandisk.com<mailto:Akshay.Mathur at sandisk.com>
[Description: cid:image001.jpg at 01CC358D.60974910]


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Wednesday, December 11, 2013 18:00
To: Dave Landsman
Cc: Dharani Kotte
Subject: Would you please help to resolve a few OFA NVMe driver problems ?

Dave and Dharani,

There are some issues with the current OFA driver that need to be fixed. PMC is working on resolving some of the problems. Intel has agreed to work on the following two problems:
- remove #define for CHATHAM2
- Learning of CPU core to Vector failure handling

I am also making request to other companies to work on some of the issues.

I wonder if your company can work on the following three problems:
                - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
                - Controller reset does not handle all cases
                - orphaned requests

Please let me know if your company can work on these two issues.

Thanks

-Kwok



________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).









-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140224/faf9ab4e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 9449 bytes
Desc: image001.jpg
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140224/faf9ab4e/attachment.jpg>

From carolyn.d.foster at intel.com  Mon Feb 24 16:05:38 2014
From: carolyn.d.foster at intel.com (Foster, Carolyn D)
Date: Tue, 25 Feb 2014 00:05:38 +0000
Subject: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset
 Fixes
In-Reply-To: <E1729D5DBAB9E948BA87B76FDFA1298A0C889D51@BBYEXM01.pmc-sierra.internal>
References: <E1729D5DBAB9E948BA87B76FDFA1298A0C884EEB@BBYEXM01.pmc-sierra.internal>
	<23EC73C80FB59046A6B7B8EB7B3826593BDF0B5C@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889023@BBYEXM01.pmc-sierra.internal>
	<23EC73C80FB59046A6B7B8EB7B3826593BDF134C@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889036@BBYEXM01.pmc-sierra.internal>
	<26455_1392829222_5304E326_26455_6404_1_23EC73C80FB59046A6B7B8EB7B3826593BDF1488@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C88952B@BBYEXM01.pmc-sierra.internal>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF9C48@FMSMSX105.amr.corp.intel.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889D51@BBYEXM01.pmc-sierra.internal>
Message-ID: <B3A485AFDDB1DD4598621E85E8EB67A83AAF9C97@FMSMSX105.amr.corp.intel.com>

Unfortunately I did not have time to debug the failure.  I saw that we did get the reset from Storport, and that it called into the new function.  But I'm not sure where exactly after that it crashed.

Carolyn

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Monday, February 24, 2014 4:59 PM
To: Foster, Carolyn D; nvmewin at lists.openfabrics.org
Subject: RE: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Hi Carolyn,

Did you root cause why D1 BSOD hit when you forced a time out?

Thanks,
Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Monday, February 24, 2014 3:51 PM
To: Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Hi Alex and Dharani,

I have been reviewing the code and performing some tests and I have some concerns about this patch.

In nvmeStd.c:
Line 1384: NVMeProcessAbortLunReset - This change will now send abort commands for all pending requests when a RESET_LOGICAL_UNIT request comes in, instead of issuing the RecoveryDpc routine.  This change concerns me the most.  During a reset there is no need to send individual abort requests for outstanding commands.  When the LUN reset comes in, we will set CC.EN to 0 and the spec clearly states that "the controller shall not process commands nor post completion queue entries to the completion queue."  This reset behavior has been accounted for in the driver, by design.  In the LUN reset case, we should continue to issue the recovery DPC routine, which will complete all outstanding commands.

What should happen here is that the new processAbortLun function should be moved under the SRB_FUNCTION_ABORT_COMMAND only.  Then the procesAbortLunReset function should only send one abort and not abort all outstanding commands.

Also, during testing, I hit a D1 BSOD when I tried to step through the code.  I ran IO and forced a timeout by using the debugger to skip over the line of code that rings the submission queue doorbell.  The IO should be timed out by storport, which will then send a reset lun.

Line 2219: StorPortSynchronizeAccess - I don't understand why this is needed.  The SynchronizeReset function looks very much like the recovery DPC routine, which should already be synchronized with Start IO and the interrupt DPC.

Thanks,
Carolyn


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, February 19, 2014 10:06 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Thank you, Dharani.

Hi all,

Please review/test the attached reset fix patch from Sandisk and provide your feedbacks.

Thank you very much,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, February 19, 2014 9:00 AM
To: Alex Chang
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the patch source for review. I have tested the I/O running over night.

Areas need to be focused for test this patch:
1. Test abort/LUN resets.
2. Test chip reset.
3. Test the format command.
4.Test Firmware download command.

Password is "sndk1234"

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 18, 2014 12:15 PM
To: Dharani Kotte
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Great!

Thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Tuesday, February 18, 2014 12:14 PM
To: Alex Chang
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Just testing after merging the code it I should be able to  send it tomorrow morning.
Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 18, 2014 12:13 PM
To: Dharani Kotte
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Hi Dharani,

Just a friendly reminder, could you please send out your patch as soon as it's ready?

Many thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, February 14, 2014 10:18 AM
To: Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Sure Alex.
Dharani.

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Friday, February 14, 2014 10:17 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Good morning, Dharani,

As you may know, both Intel and Huawei patches had been added into OFA source base. Now, you may re-base your changes and send a patch out for review/test. Thank you very much for contributing the fixes.

Regards,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, January 15, 2014 2:08 PM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: Would you please help to resolve a few OFA NVMe driver problems ?


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the source for the preliminary review. I have tested the IO and scsi compliance test. I don't have a drive which supports abort/lun resets, not sure how to test the format command.

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:54 AM
To: Dharani Kotte; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Happy Holidays to you all.
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 11:52 AM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Thank you for the explanation. Sure I will take look.
Happy Holidays.
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:44 AM
To: Kwok Kong; Dharani Kotte; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Dharani,

The controller reset can be issued from either from the host or the driver itself. Currently, the driver seems handling them in the same manner via single entry "NVMeResetController". In the case of "from the host", the driver needs to separate the cases of SRB_FUNCTION_RESET_... requests from the ioctl request of NVME_RESET_DEVICE in the sense of handling pending IOs. In the case of "the driver itself", needs to re-exam the related error recovery codes as well.
Judy from Samsung suggested referring the storahci.sys driver sample codes for Windows 7/8 based on reset bus logic examples and detailed recommendations.

Thank you,
Alex


From: Kwok Kong
Sent: Friday, December 20, 2013 9:08 AM
To: Dharani Kotte; Akshay Mathur; Alex Chang
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Dharani,

Yes, these are the three areas that you are committed to.

Alex,

Please send more details on the "Controller reset does not handle all cases"  to Dharani.

Thanks

-Kwok

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 9:02 AM
To: Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Kwok,

I think the below are the items that we are committing for:
- Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
- Controller reset does not handle all cases
- orphaned requests

Can somebody provide little bit more details on the expectation for the item "Controller reset does not handle all cases".

Thanks,
Dharani.


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Thursday, December 19, 2013 6:53 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Excellent! Your help is much appreciated.

Dharani,

Please let me know if you have any question.

Happy holiday to all of you.

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Thursday, December 19, 2013 6:51 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kwok,
You are welcome. We are pleased to contribute to the community and appreciate you driving it!

We will try our best to complete the implementation by end of January but we may not be able to complete comprehensive testing by that time. This is because of overlaps with few internal business deliverables and a company-wide shut-down for next 1.5 weeks.

Anyway, Dharani will be in touch with you as he makes progress.
Thanks
Akshay

From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Tuesday, December 17, 2013 4:21 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Akshay,

Thanks for your willingness to contribute to the driver.   I am looking for a patch before end of Jan 2014, the earlier the better.
Please let me know if Sandisk can commit to that.

Your help is much appreciated.

Thanks

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Tuesday, December 17, 2013 4:11 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman; Akshay Mathur
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kowk,
I manage the Software and driver development team at SanDisk/ESS.
We are certainly willing to contribute to fixing the problems listed below but before we can commit, we would like to get clarification on the timeline i.e. by when these fixes are expected to be completed.
Thanks
Akshay Mathur
Sr Software Manager, Enterprise Storage Solutions
951 SanDisk Drive, Building #5  |  Milpitas, CA 95035 U.S.A.  |  Direct  +1 408.801.1336  |
Cell +1 856.607.7323  |  Corporate +1 408.801.1000  |  Akshay.Mathur at sandisk.com<mailto:Akshay.Mathur at sandisk.com>
[Description: cid:image001.jpg at 01CC358D.60974910]


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Wednesday, December 11, 2013 18:00
To: Dave Landsman
Cc: Dharani Kotte
Subject: Would you please help to resolve a few OFA NVMe driver problems ?

Dave and Dharani,

There are some issues with the current OFA driver that need to be fixed. PMC is working on resolving some of the problems. Intel has agreed to work on the following two problems:
- remove #define for CHATHAM2
- Learning of CPU core to Vector failure handling

I am also making request to other companies to work on some of the issues.

I wonder if your company can work on the following three problems:
                - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
                - Controller reset does not handle all cases
                - orphaned requests

Please let me know if your company can work on these two issues.

Thanks

-Kwok



________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).









-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140225/c8dea833/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 9449 bytes
Desc: image001.jpg
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140225/c8dea833/attachment.jpg>

From Alex.Chang at pmcs.com  Mon Feb 24 18:13:34 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Tue, 25 Feb 2014 02:13:34 +0000
Subject: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset
 Fixes
In-Reply-To: <B3A485AFDDB1DD4598621E85E8EB67A83AAF9C97@FMSMSX105.amr.corp.intel.com>
References: <E1729D5DBAB9E948BA87B76FDFA1298A0C884EEB@BBYEXM01.pmc-sierra.internal>
	<23EC73C80FB59046A6B7B8EB7B3826593BDF0B5C@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889023@BBYEXM01.pmc-sierra.internal>
	<23EC73C80FB59046A6B7B8EB7B3826593BDF134C@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889036@BBYEXM01.pmc-sierra.internal>
	<26455_1392829222_5304E326_26455_6404_1_23EC73C80FB59046A6B7B8EB7B3826593BDF1488@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C88952B@BBYEXM01.pmc-sierra.internal>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF9C48@FMSMSX105.amr.corp.intel.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889D51@BBYEXM01.pmc-sierra.internal>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF9C97@FMSMSX105.amr.corp.intel.com>
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C889DA0@BBYEXM01.pmc-sierra.internal>

Hi Dharani,

Your patch is meant for the reset issues. Now, the bug check seems happening due to a forced timeout that would later trigger reset requests from Storport. Could you please mimic the way Carolyn had done to replicate it? I will also do some similar testing as well.

Thanks,
Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Monday, February 24, 2014 4:06 PM
To: Alex Chang; nvmewin at lists.openfabrics.org
Subject: RE: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Unfortunately I did not have time to debug the failure.  I saw that we did get the reset from Storport, and that it called into the new function.  But I'm not sure where exactly after that it crashed.

Carolyn

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Monday, February 24, 2014 4:59 PM
To: Foster, Carolyn D; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Hi Carolyn,

Did you root cause why D1 BSOD hit when you forced a time out?

Thanks,
Alex

From: Foster, Carolyn D [mailto:carolyn.d.foster at intel.com]
Sent: Monday, February 24, 2014 3:51 PM
To: Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Hi Alex and Dharani,

I have been reviewing the code and performing some tests and I have some concerns about this patch.

In nvmeStd.c:
Line 1384: NVMeProcessAbortLunReset - This change will now send abort commands for all pending requests when a RESET_LOGICAL_UNIT request comes in, instead of issuing the RecoveryDpc routine.  This change concerns me the most.  During a reset there is no need to send individual abort requests for outstanding commands.  When the LUN reset comes in, we will set CC.EN to 0 and the spec clearly states that "the controller shall not process commands nor post completion queue entries to the completion queue."  This reset behavior has been accounted for in the driver, by design.  In the LUN reset case, we should continue to issue the recovery DPC routine, which will complete all outstanding commands.

What should happen here is that the new processAbortLun function should be moved under the SRB_FUNCTION_ABORT_COMMAND only.  Then the procesAbortLunReset function should only send one abort and not abort all outstanding commands.

Also, during testing, I hit a D1 BSOD when I tried to step through the code.  I ran IO and forced a timeout by using the debugger to skip over the line of code that rings the submission queue doorbell.  The IO should be timed out by storport, which will then send a reset lun.

Line 2219: StorPortSynchronizeAccess - I don't understand why this is needed.  The SynchronizeReset function looks very much like the recovery DPC routine, which should already be synchronized with Start IO and the interrupt DPC.

Thanks,
Carolyn


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, February 19, 2014 10:06 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Thank you, Dharani.

Hi all,

Please review/test the attached reset fix patch from Sandisk and provide your feedbacks.

Thank you very much,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, February 19, 2014 9:00 AM
To: Alex Chang
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the patch source for review. I have tested the I/O running over night.

Areas need to be focused for test this patch:
1. Test abort/LUN resets.
2. Test chip reset.
3. Test the format command.
4.Test Firmware download command.

Password is "sndk1234"

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 18, 2014 12:15 PM
To: Dharani Kotte
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Great!

Thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Tuesday, February 18, 2014 12:14 PM
To: Alex Chang
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Just testing after merging the code it I should be able to  send it tomorrow morning.
Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 18, 2014 12:13 PM
To: Dharani Kotte
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Hi Dharani,

Just a friendly reminder, could you please send out your patch as soon as it's ready?

Many thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, February 14, 2014 10:18 AM
To: Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Sure Alex.
Dharani.

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Friday, February 14, 2014 10:17 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Good morning, Dharani,

As you may know, both Intel and Huawei patches had been added into OFA source base. Now, you may re-base your changes and send a patch out for review/test. Thank you very much for contributing the fixes.

Regards,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, January 15, 2014 2:08 PM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: Would you please help to resolve a few OFA NVMe driver problems ?


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the source for the preliminary review. I have tested the IO and scsi compliance test. I don't have a drive which supports abort/lun resets, not sure how to test the format command.

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:54 AM
To: Dharani Kotte; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Happy Holidays to you all.
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 11:52 AM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Thank you for the explanation. Sure I will take look.
Happy Holidays.
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:44 AM
To: Kwok Kong; Dharani Kotte; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Dharani,

The controller reset can be issued from either from the host or the driver itself. Currently, the driver seems handling them in the same manner via single entry "NVMeResetController". In the case of "from the host", the driver needs to separate the cases of SRB_FUNCTION_RESET_... requests from the ioctl request of NVME_RESET_DEVICE in the sense of handling pending IOs. In the case of "the driver itself", needs to re-exam the related error recovery codes as well.
Judy from Samsung suggested referring the storahci.sys driver sample codes for Windows 7/8 based on reset bus logic examples and detailed recommendations.

Thank you,
Alex


From: Kwok Kong
Sent: Friday, December 20, 2013 9:08 AM
To: Dharani Kotte; Akshay Mathur; Alex Chang
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Dharani,

Yes, these are the three areas that you are committed to.

Alex,

Please send more details on the "Controller reset does not handle all cases"  to Dharani.

Thanks

-Kwok

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 9:02 AM
To: Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Kwok,

I think the below are the items that we are committing for:
- Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
- Controller reset does not handle all cases
- orphaned requests

Can somebody provide little bit more details on the expectation for the item "Controller reset does not handle all cases".

Thanks,
Dharani.


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Thursday, December 19, 2013 6:53 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Excellent! Your help is much appreciated.

Dharani,

Please let me know if you have any question.

Happy holiday to all of you.

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Thursday, December 19, 2013 6:51 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kwok,
You are welcome. We are pleased to contribute to the community and appreciate you driving it!

We will try our best to complete the implementation by end of January but we may not be able to complete comprehensive testing by that time. This is because of overlaps with few internal business deliverables and a company-wide shut-down for next 1.5 weeks.

Anyway, Dharani will be in touch with you as he makes progress.
Thanks
Akshay

From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Tuesday, December 17, 2013 4:21 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Akshay,

Thanks for your willingness to contribute to the driver.   I am looking for a patch before end of Jan 2014, the earlier the better.
Please let me know if Sandisk can commit to that.

Your help is much appreciated.

Thanks

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Tuesday, December 17, 2013 4:11 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman; Akshay Mathur
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kowk,
I manage the Software and driver development team at SanDisk/ESS.
We are certainly willing to contribute to fixing the problems listed below but before we can commit, we would like to get clarification on the timeline i.e. by when these fixes are expected to be completed.
Thanks
Akshay Mathur
Sr Software Manager, Enterprise Storage Solutions
951 SanDisk Drive, Building #5  |  Milpitas, CA 95035 U.S.A.  |  Direct  +1 408.801.1336  |
Cell +1 856.607.7323  |  Corporate +1 408.801.1000  |  Akshay.Mathur at sandisk.com<mailto:Akshay.Mathur at sandisk.com>
[Description: cid:image001.jpg at 01CC358D.60974910]


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Wednesday, December 11, 2013 18:00
To: Dave Landsman
Cc: Dharani Kotte
Subject: Would you please help to resolve a few OFA NVMe driver problems ?

Dave and Dharani,

There are some issues with the current OFA driver that need to be fixed. PMC is working on resolving some of the problems. Intel has agreed to work on the following two problems:
- remove #define for CHATHAM2
- Learning of CPU core to Vector failure handling

I am also making request to other companies to work on some of the issues.

I wonder if your company can work on the following three problems:
                - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
                - Controller reset does not handle all cases
                - orphaned requests

Please let me know if your company can work on these two issues.

Thanks

-Kwok



________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).









-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140225/ec0b14be/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 9449 bytes
Desc: image001.jpg
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140225/ec0b14be/attachment.jpg>

From Dharani.Kotte at sandisk.com  Tue Feb 25 04:28:10 2014
From: Dharani.Kotte at sandisk.com (Dharani Kotte)
Date: Tue, 25 Feb 2014 12:28:10 +0000
Subject: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset
 Fixes
In-Reply-To: <B3A485AFDDB1DD4598621E85E8EB67A83AAF9C48@FMSMSX105.amr.corp.intel.com>
References: <E1729D5DBAB9E948BA87B76FDFA1298A0C884EEB@BBYEXM01.pmc-sierra.internal>
	<23EC73C80FB59046A6B7B8EB7B3826593BDF0B5C@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889023@BBYEXM01.pmc-sierra.internal>
	<23EC73C80FB59046A6B7B8EB7B3826593BDF134C@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889036@BBYEXM01.pmc-sierra.internal>
	<26455_1392829222_5304E326_26455_6404_1_23EC73C80FB59046A6B7B8EB7B3826593BDF1488@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C88952B@BBYEXM01.pmc-sierra.internal>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF9C48@FMSMSX105.amr.corp.intel.com>
Message-ID: <23EC73C80FB59046A6B7B8EB7B3826593DA6D6E0@SACMBXIP02.sdcorp.global.sandisk.com>

Hi Carolyn,

Line 1384: I can take care of this item.

Line 2219: StorPortSynchronizeAccess, This is the request from Samsung suggested by Judy. Below is the reference mail.

In our testing, we create a situation where we put the NVMe driver under heavy I/O load with Iometer and then cause the device to stop responding.  This results in I/O request timeouts which eventually causes the driver to be called at it's HwStorResetBus entry point (NVMeResetBus).  I have some feedback on the current architecture of that routine:


1.       Among other things, NMeResetBus schedules a DPC to complete any pending commands. This creates a situation where upon return from this entry point, there are still cmds outstanding which don't get completed till the DPC runs.  According to the WDK, this doesn't appear to be legal - all outstanding cmds have to be completed by the HwStorResetBus routine before it returns:

HwResetBus

Pointer to the miniport driver's HwStorResetBus<ms-help://MS.WDK.v10.7600.091201/Storage_r/hh/Storage_r/stormini_b3051379-4caa-4502-9492-a21672cfbf0d.xml.htm> routine, which is a required entry point for all miniport drivers. This member has the same meaning for the Storport version of the HW_INITIALIZATION_DATA structure as it does for the SCSI Port version of the structure. For more information, see the HwResetBus member of HW_INITIALIZATION_DATA (SCSI)
and
HwScsiResetBus must complete any outstanding requests by calling ScsiPortCompleteRequest with the SrbStatus value SRB_STATUS_BUS_RESET or, for individual SRBs, ScsiPortNotification with this status value.
and
The port driver pauses all device IO queues for the adapter and then calls the HwStorResetBus routine at IRQL DISPATCH_LEVEL after acquiring the StartIo spin lock. A miniport driver is responsible for completing SRBs received by HwStorStartIo<http://msdn.microsoft.com/en-us/library/windows/hardware/ff557423(v=vs.85).aspx> for PathId during this routine and setting their status to SRB_STATUS_BUS_RESET if necessary

Since HwStorResetBus must finish its work before returning; it can't schedule a DPC to do so later on. The logic which schedules a DPC should be removed.


2.       Code should be added to call StorPortPause() to hold off any new requests till StorPortResume() is called.


3.       Code should be added to call  StorPortSynchronizeAccess() in order to synchronize with HwStorInterrupt. A callback routine in the NVMe driver should also be added for NVMeResetBus to do the synchronized work in. HwStorResetBus is already synchronized with HwStorStartIo since the port driver calls it only after acquiring the StartIo spinlock.



4.       We should implement a driver-internal global (per "adapter") flag signifying we are busy with reset processing and thus can't allow new I/O requests to go through to the hardware.



5.       Code should be added to call StorPortResume() when all work is complete.



6.       We should refer to the WDK-supplied LSI parallel SCSI StorPort miniport sample driver for an example of all of the above.



Thanks,
Judy


Thanks,
Dharani.


From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Foster, Carolyn D
Sent: Monday, February 24, 2014 3:51 PM
To: Alex Chang; nvmewin at lists.openfabrics.org
Subject: Re: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Hi Alex and Dharni,

I have been reviewing the code and performing some tests and I have some concerns about this patch.

In nvmeStd.c:
Line 1384: NVMeProcessAbortLunReset - This change will now send abort commands for all pending requests when a RESET_LOGICAL_UNIT request comes in, instead of issuing the RecoveryDpc routine.  This change concerns me the most.  During a reset there is no need to send individual abort requests for outstanding commands.  When the LUN reset comes in, we will set CC.EN to 0 and the spec clearly states that "the controller shall not process commands nor post completion queue entries to the completion queue."  This reset behavior has been accounted for in the driver, by design.  In the LUN reset case, we should continue to issue the recovery DPC routine, which will complete all outstanding commands.

What should happen here is that the new processAbortLun function should be moved under the SRB_FUNCTION_ABORT_COMMAND only.  Then the procesAbortLunReset function should only send one abort and not abort all outstanding commands.

Also, during testing, I hit a D1 BSOD when I tried to step through the code.  I ran IO and forced a timeout by using the debugger to skip over the line of code that rings the submission queue doorbell.  The IO should be timed out by storport, which will then send a reset lun.

Line 2219: StorPortSynchronizeAccess - I don't understand why this is needed.  The SynchronizeReset function looks very much like the recovery DPC routine, which should already be synchronized with Start IO and the interrupt DPC.

Thanks,
Carolyn


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, February 19, 2014 10:06 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Thank you, Dharani.

Hi all,

Please review/test the attached reset fix patch from Sandisk and provide your feedbacks.

Thank you very much,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, February 19, 2014 9:00 AM
To: Alex Chang
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the patch source for review. I have tested the I/O running over night.

Areas need to be focused for test this patch:
1. Test abort/LUN resets.
2. Test chip reset.
3. Test the format command.
4.Test Firmware download command.

Password is "sndk1234"

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 18, 2014 12:15 PM
To: Dharani Kotte
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Great!

Thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Tuesday, February 18, 2014 12:14 PM
To: Alex Chang
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Just testing after merging the code it I should be able to  send it tomorrow morning.
Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 18, 2014 12:13 PM
To: Dharani Kotte
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Hi Dharani,

Just a friendly reminder, could you please send out your patch as soon as it's ready?

Many thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, February 14, 2014 10:18 AM
To: Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Sure Alex.
Dharani.

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Friday, February 14, 2014 10:17 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Good morning, Dharani,

As you may know, both Intel and Huawei patches had been added into OFA source base. Now, you may re-base your changes and send a patch out for review/test. Thank you very much for contributing the fixes.

Regards,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, January 15, 2014 2:08 PM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: Would you please help to resolve a few OFA NVMe driver problems ?


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the source for the preliminary review. I have tested the IO and scsi compliance test. I don't have a drive which supports abort/lun resets, not sure how to test the format command.

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:54 AM
To: Dharani Kotte; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Happy Holidays to you all.
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 11:52 AM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Thank you for the explanation. Sure I will take look.
Happy Holidays.
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:44 AM
To: Kwok Kong; Dharani Kotte; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Dharani,

The controller reset can be issued from either from the host or the driver itself. Currently, the driver seems handling them in the same manner via single entry "NVMeResetController". In the case of "from the host", the driver needs to separate the cases of SRB_FUNCTION_RESET_... requests from the ioctl request of NVME_RESET_DEVICE in the sense of handling pending IOs. In the case of "the driver itself", needs to re-exam the related error recovery codes as well.
Judy from Samsung suggested referring the storahci.sys driver sample codes for Windows 7/8 based on reset bus logic examples and detailed recommendations.

Thank you,
Alex


From: Kwok Kong
Sent: Friday, December 20, 2013 9:08 AM
To: Dharani Kotte; Akshay Mathur; Alex Chang
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Dharani,

Yes, these are the three areas that you are committed to.

Alex,

Please send more details on the "Controller reset does not handle all cases"  to Dharani.

Thanks

-Kwok

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 9:02 AM
To: Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Kwok,

I think the below are the items that we are committing for:
- Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
- Controller reset does not handle all cases
- orphaned requests

Can somebody provide little bit more details on the expectation for the item "Controller reset does not handle all cases".

Thanks,
Dharani.


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Thursday, December 19, 2013 6:53 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Excellent! Your help is much appreciated.

Dharani,

Please let me know if you have any question.

Happy holiday to all of you.

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Thursday, December 19, 2013 6:51 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kwok,
You are welcome. We are pleased to contribute to the community and appreciate you driving it!

We will try our best to complete the implementation by end of January but we may not be able to complete comprehensive testing by that time. This is because of overlaps with few internal business deliverables and a company-wide shut-down for next 1.5 weeks.

Anyway, Dharani will be in touch with you as he makes progress.
Thanks
Akshay

From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Tuesday, December 17, 2013 4:21 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Akshay,

Thanks for your willingness to contribute to the driver.   I am looking for a patch before end of Jan 2014, the earlier the better.
Please let me know if Sandisk can commit to that.

Your help is much appreciated.

Thanks

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Tuesday, December 17, 2013 4:11 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman; Akshay Mathur
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kowk,
I manage the Software and driver development team at SanDisk/ESS.
We are certainly willing to contribute to fixing the problems listed below but before we can commit, we would like to get clarification on the timeline i.e. by when these fixes are expected to be completed.
Thanks
Akshay Mathur
Sr Software Manager, Enterprise Storage Solutions
951 SanDisk Drive, Building #5  |  Milpitas, CA 95035 U.S.A.  |  Direct  +1 408.801.1336  |
Cell +1 856.607.7323  |  Corporate +1 408.801.1000  |  Akshay.Mathur at sandisk.com<mailto:Akshay.Mathur at sandisk.com>
[Description: cid:image001.jpg at 01CC358D.60974910]


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Wednesday, December 11, 2013 18:00
To: Dave Landsman
Cc: Dharani Kotte
Subject: Would you please help to resolve a few OFA NVMe driver problems ?

Dave and Dharani,

There are some issues with the current OFA driver that need to be fixed. PMC is working on resolving some of the problems. Intel has agreed to work on the following two problems:
- remove #define for CHATHAM2
- Learning of CPU core to Vector failure handling

I am also making request to other companies to work on some of the issues.

I wonder if your company can work on the following three problems:
                - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
                - Controller reset does not handle all cases
                - orphaned requests

Please let me know if your company can work on these two issues.

Thanks

-Kwok



________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140225/3a9e601e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 9449 bytes
Desc: image001.jpg
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140225/3a9e601e/attachment.jpg>

From Alex.Chang at pmcs.com  Tue Feb 25 14:03:11 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Tue, 25 Feb 2014 22:03:11 +0000
Subject: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset
 Fixes
In-Reply-To: <23EC73C80FB59046A6B7B8EB7B3826593DA6D6E0@SACMBXIP02.sdcorp.global.sandisk.com>
References: <E1729D5DBAB9E948BA87B76FDFA1298A0C884EEB@BBYEXM01.pmc-sierra.internal>
	<23EC73C80FB59046A6B7B8EB7B3826593BDF0B5C@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889023@BBYEXM01.pmc-sierra.internal>
	<23EC73C80FB59046A6B7B8EB7B3826593BDF134C@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889036@BBYEXM01.pmc-sierra.internal>
	<26455_1392829222_5304E326_26455_6404_1_23EC73C80FB59046A6B7B8EB7B3826593BDF1488@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C88952B@BBYEXM01.pmc-sierra.internal>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF9C48@FMSMSX105.amr.corp.intel.com>
	<23EC73C80FB59046A6B7B8EB7B3826593DA6D6E0@SACMBXIP02.sdcorp.global.sandisk.com>
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C889E55@BBYEXM01.pmc-sierra.internal>

Hi Carolyn and Dharani,

I basically agree the suggested changes in HwStorResetBus. However, I have some feedback:

1.       In Line#2161, NVMeResetAdapter is called and it returns after making sure RDY bit is cleared as 0, why we need 10 ms delay ? The exact same delay added in RecoveryDpcRoutine was because original NVMeResetAdater did not wait until RDY bit is cleared as 0. Due to the changes in NVMeResetAdapter, we need to remove the 10 ms delay in RecoveryDpcRoutine as well.

2.       In Line#2216, StorPortPause is called with 60 seconds to force Storport hold up requests. I am not sure 60 seconds is proper assumption. Instead, calling "StorPortBusy(pAdapterExtension, STOR_ALL_REQUESTS);" seems better idea to me.

3.       In the definition of HwStorResetBus, the routine returns TRUE in successful case. We need to take care of failed cases as well, i.e., any failures within NVMeSynchronizeReset. And StorPortResume should be called only in successful case.

Thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Tuesday, February 25, 2014 4:28 AM
To: Foster, Carolyn D; Alex Chang; nvmewin at lists.openfabrics.org
Subject: RE: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Hi Carolyn,

Line 1384: I can take care of this item.

Line 2219: StorPortSynchronizeAccess, This is the request from Samsung suggested by Judy. Below is the reference mail.

In our testing, we create a situation where we put the NVMe driver under heavy I/O load with Iometer and then cause the device to stop responding.  This results in I/O request timeouts which eventually causes the driver to be called at it's HwStorResetBus entry point (NVMeResetBus).  I have some feedback on the current architecture of that routine:


1.       Among other things, NMeResetBus schedules a DPC to complete any pending commands. This creates a situation where upon return from this entry point, there are still cmds outstanding which don't get completed till the DPC runs.  According to the WDK, this doesn't appear to be legal - all outstanding cmds have to be completed by the HwStorResetBus routine before it returns:

HwResetBus

Pointer to the miniport driver's HwStorResetBus<ms-help://MS.WDK.v10.7600.091201/Storage_r/hh/Storage_r/stormini_b3051379-4caa-4502-9492-a21672cfbf0d.xml.htm> routine, which is a required entry point for all miniport drivers. This member has the same meaning for the Storport version of the HW_INITIALIZATION_DATA structure as it does for the SCSI Port version of the structure. For more information, see the HwResetBus member of HW_INITIALIZATION_DATA (SCSI)
and
HwScsiResetBus must complete any outstanding requests by calling ScsiPortCompleteRequest with the SrbStatus value SRB_STATUS_BUS_RESET or, for individual SRBs, ScsiPortNotification with this status value.
and
The port driver pauses all device IO queues for the adapter and then calls the HwStorResetBus routine at IRQL DISPATCH_LEVEL after acquiring the StartIo spin lock. A miniport driver is responsible for completing SRBs received by HwStorStartIo<http://msdn.microsoft.com/en-us/library/windows/hardware/ff557423(v=vs.85).aspx> for PathId during this routine and setting their status to SRB_STATUS_BUS_RESET if necessary

Since HwStorResetBus must finish its work before returning; it can't schedule a DPC to do so later on. The logic which schedules a DPC should be removed.


2.       Code should be added to call StorPortPause() to hold off any new requests till StorPortResume() is called.


3.       Code should be added to call  StorPortSynchronizeAccess() in order to synchronize with HwStorInterrupt. A callback routine in the NVMe driver should also be added for NVMeResetBus to do the synchronized work in. HwStorResetBus is already synchronized with HwStorStartIo since the port driver calls it only after acquiring the StartIo spinlock.



4.       We should implement a driver-internal global (per "adapter") flag signifying we are busy with reset processing and thus can't allow new I/O requests to go through to the hardware.



5.       Code should be added to call StorPortResume() when all work is complete.



6.       We should refer to the WDK-supplied LSI parallel SCSI StorPort miniport sample driver for an example of all of the above.



Thanks,
Judy


Thanks,
Dharani.


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Foster, Carolyn D
Sent: Monday, February 24, 2014 3:51 PM
To: Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: Re: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Hi Alex and Dharni,

I have been reviewing the code and performing some tests and I have some concerns about this patch.

In nvmeStd.c:
Line 1384: NVMeProcessAbortLunReset - This change will now send abort commands for all pending requests when a RESET_LOGICAL_UNIT request comes in, instead of issuing the RecoveryDpc routine.  This change concerns me the most.  During a reset there is no need to send individual abort requests for outstanding commands.  When the LUN reset comes in, we will set CC.EN to 0 and the spec clearly states that "the controller shall not process commands nor post completion queue entries to the completion queue."  This reset behavior has been accounted for in the driver, by design.  In the LUN reset case, we should continue to issue the recovery DPC routine, which will complete all outstanding commands.

What should happen here is that the new processAbortLun function should be moved under the SRB_FUNCTION_ABORT_COMMAND only.  Then the procesAbortLunReset function should only send one abort and not abort all outstanding commands.

Also, during testing, I hit a D1 BSOD when I tried to step through the code.  I ran IO and forced a timeout by using the debugger to skip over the line of code that rings the submission queue doorbell.  The IO should be timed out by storport, which will then send a reset lun.

Line 2219: StorPortSynchronizeAccess - I don't understand why this is needed.  The SynchronizeReset function looks very much like the recovery DPC routine, which should already be synchronized with Start IO and the interrupt DPC.

Thanks,
Carolyn


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, February 19, 2014 10:06 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Thank you, Dharani.

Hi all,

Please review/test the attached reset fix patch from Sandisk and provide your feedbacks.

Thank you very much,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, February 19, 2014 9:00 AM
To: Alex Chang
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the patch source for review. I have tested the I/O running over night.

Areas need to be focused for test this patch:
1. Test abort/LUN resets.
2. Test chip reset.
3. Test the format command.
4.Test Firmware download command.

Password is "sndk1234"

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 18, 2014 12:15 PM
To: Dharani Kotte
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Great!

Thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Tuesday, February 18, 2014 12:14 PM
To: Alex Chang
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Just testing after merging the code it I should be able to  send it tomorrow morning.
Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 18, 2014 12:13 PM
To: Dharani Kotte
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Hi Dharani,

Just a friendly reminder, could you please send out your patch as soon as it's ready?

Many thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, February 14, 2014 10:18 AM
To: Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Sure Alex.
Dharani.

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Friday, February 14, 2014 10:17 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Good morning, Dharani,

As you may know, both Intel and Huawei patches had been added into OFA source base. Now, you may re-base your changes and send a patch out for review/test. Thank you very much for contributing the fixes.

Regards,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, January 15, 2014 2:08 PM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: Would you please help to resolve a few OFA NVMe driver problems ?


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the source for the preliminary review. I have tested the IO and scsi compliance test. I don't have a drive which supports abort/lun resets, not sure how to test the format command.

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:54 AM
To: Dharani Kotte; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Happy Holidays to you all.
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 11:52 AM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Thank you for the explanation. Sure I will take look.
Happy Holidays.
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:44 AM
To: Kwok Kong; Dharani Kotte; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Dharani,

The controller reset can be issued from either from the host or the driver itself. Currently, the driver seems handling them in the same manner via single entry "NVMeResetController". In the case of "from the host", the driver needs to separate the cases of SRB_FUNCTION_RESET_... requests from the ioctl request of NVME_RESET_DEVICE in the sense of handling pending IOs. In the case of "the driver itself", needs to re-exam the related error recovery codes as well.
Judy from Samsung suggested referring the storahci.sys driver sample codes for Windows 7/8 based on reset bus logic examples and detailed recommendations.

Thank you,
Alex


From: Kwok Kong
Sent: Friday, December 20, 2013 9:08 AM
To: Dharani Kotte; Akshay Mathur; Alex Chang
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Dharani,

Yes, these are the three areas that you are committed to.

Alex,

Please send more details on the "Controller reset does not handle all cases"  to Dharani.

Thanks

-Kwok

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 9:02 AM
To: Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Kwok,

I think the below are the items that we are committing for:
- Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
- Controller reset does not handle all cases
- orphaned requests

Can somebody provide little bit more details on the expectation for the item "Controller reset does not handle all cases".

Thanks,
Dharani.


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Thursday, December 19, 2013 6:53 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Excellent! Your help is much appreciated.

Dharani,

Please let me know if you have any question.

Happy holiday to all of you.

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Thursday, December 19, 2013 6:51 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kwok,
You are welcome. We are pleased to contribute to the community and appreciate you driving it!

We will try our best to complete the implementation by end of January but we may not be able to complete comprehensive testing by that time. This is because of overlaps with few internal business deliverables and a company-wide shut-down for next 1.5 weeks.

Anyway, Dharani will be in touch with you as he makes progress.
Thanks
Akshay

From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Tuesday, December 17, 2013 4:21 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Akshay,

Thanks for your willingness to contribute to the driver.   I am looking for a patch before end of Jan 2014, the earlier the better.
Please let me know if Sandisk can commit to that.

Your help is much appreciated.

Thanks

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Tuesday, December 17, 2013 4:11 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman; Akshay Mathur
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kowk,
I manage the Software and driver development team at SanDisk/ESS.
We are certainly willing to contribute to fixing the problems listed below but before we can commit, we would like to get clarification on the timeline i.e. by when these fixes are expected to be completed.
Thanks
Akshay Mathur
Sr Software Manager, Enterprise Storage Solutions
951 SanDisk Drive, Building #5  |  Milpitas, CA 95035 U.S.A.  |  Direct  +1 408.801.1336  |
Cell +1 856.607.7323  |  Corporate +1 408.801.1000  |  Akshay.Mathur at sandisk.com<mailto:Akshay.Mathur at sandisk.com>
[Description: cid:image001.jpg at 01CC358D.60974910]


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Wednesday, December 11, 2013 18:00
To: Dave Landsman
Cc: Dharani Kotte
Subject: Would you please help to resolve a few OFA NVMe driver problems ?

Dave and Dharani,

There are some issues with the current OFA driver that need to be fixed. PMC is working on resolving some of the problems. Intel has agreed to work on the following two problems:
- remove #define for CHATHAM2
- Learning of CPU core to Vector failure handling

I am also making request to other companies to work on some of the issues.

I wonder if your company can work on the following three problems:
                - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
                - Controller reset does not handle all cases
                - orphaned requests

Please let me know if your company can work on these two issues.

Thanks

-Kwok



________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).










-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140225/1355baed/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 9449 bytes
Desc: image001.jpg
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140225/1355baed/attachment.jpg>

From Alex.Chang at pmcs.com  Tue Feb 25 14:09:17 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Tue, 25 Feb 2014 22:09:17 +0000
Subject: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset
 Fixes
In-Reply-To: <E1729D5DBAB9E948BA87B76FDFA1298A0C889E55@BBYEXM01.pmc-sierra.internal>
References: <E1729D5DBAB9E948BA87B76FDFA1298A0C884EEB@BBYEXM01.pmc-sierra.internal>
	<23EC73C80FB59046A6B7B8EB7B3826593BDF0B5C@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889023@BBYEXM01.pmc-sierra.internal>
	<23EC73C80FB59046A6B7B8EB7B3826593BDF134C@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889036@BBYEXM01.pmc-sierra.internal>
	<26455_1392829222_5304E326_26455_6404_1_23EC73C80FB59046A6B7B8EB7B3826593BDF1488@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C88952B@BBYEXM01.pmc-sierra.internal>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF9C48@FMSMSX105.amr.corp.intel.com>
	<23EC73C80FB59046A6B7B8EB7B3826593DA6D6E0@SACMBXIP02.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889E55@BBYEXM01.pmc-sierra.internal>
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C889E6C@BBYEXM01.pmc-sierra.internal>

Just left out one more :
In Line#1228 of nvmeInit.c, NVMeWaitOnRdy is called to replace assigning NextDriverState as NVMeWaitOnRdy. I think the assignment is still required before the initialization state machine starts.

Alex

From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 25, 2014 2:03 PM
To: Dharani Kotte; Foster, Carolyn D; nvmewin at lists.openfabrics.org
Subject: Re: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Hi Carolyn and Dharani,

I basically agree the suggested changes in HwStorResetBus. However, I have some feedback:

1.       In Line#2161, NVMeResetAdapter is called and it returns after making sure RDY bit is cleared as 0, why we need 10 ms delay ? The exact same delay added in RecoveryDpcRoutine was because original NVMeResetAdater did not wait until RDY bit is cleared as 0. Due to the changes in NVMeResetAdapter, we need to remove the 10 ms delay in RecoveryDpcRoutine as well.

2.       In Line#2216, StorPortPause is called with 60 seconds to force Storport hold up requests. I am not sure 60 seconds is proper assumption. Instead, calling "StorPortBusy(pAdapterExtension, STOR_ALL_REQUESTS);" seems better idea to me.

3.       In the definition of HwStorResetBus, the routine returns TRUE in successful case. We need to take care of failed cases as well, i.e., any failures within NVMeSynchronizeReset. And StorPortResume should be called only in successful case.

Thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Tuesday, February 25, 2014 4:28 AM
To: Foster, Carolyn D; Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Hi Carolyn,

Line 1384: I can take care of this item.

Line 2219: StorPortSynchronizeAccess, This is the request from Samsung suggested by Judy. Below is the reference mail.

In our testing, we create a situation where we put the NVMe driver under heavy I/O load with Iometer and then cause the device to stop responding.  This results in I/O request timeouts which eventually causes the driver to be called at it's HwStorResetBus entry point (NVMeResetBus).  I have some feedback on the current architecture of that routine:


1.       Among other things, NMeResetBus schedules a DPC to complete any pending commands. This creates a situation where upon return from this entry point, there are still cmds outstanding which don't get completed till the DPC runs.  According to the WDK, this doesn't appear to be legal - all outstanding cmds have to be completed by the HwStorResetBus routine before it returns:

HwResetBus

Pointer to the miniport driver's HwStorResetBus<ms-help://MS.WDK.v10.7600.091201/Storage_r/hh/Storage_r/stormini_b3051379-4caa-4502-9492-a21672cfbf0d.xml.htm> routine, which is a required entry point for all miniport drivers. This member has the same meaning for the Storport version of the HW_INITIALIZATION_DATA structure as it does for the SCSI Port version of the structure. For more information, see the HwResetBus member of HW_INITIALIZATION_DATA (SCSI)
and
HwScsiResetBus must complete any outstanding requests by calling ScsiPortCompleteRequest with the SrbStatus value SRB_STATUS_BUS_RESET or, for individual SRBs, ScsiPortNotification with this status value.
and
The port driver pauses all device IO queues for the adapter and then calls the HwStorResetBus routine at IRQL DISPATCH_LEVEL after acquiring the StartIo spin lock. A miniport driver is responsible for completing SRBs received by HwStorStartIo<http://msdn.microsoft.com/en-us/library/windows/hardware/ff557423(v=vs.85).aspx> for PathId during this routine and setting their status to SRB_STATUS_BUS_RESET if necessary

Since HwStorResetBus must finish its work before returning; it can't schedule a DPC to do so later on. The logic which schedules a DPC should be removed.


2.       Code should be added to call StorPortPause() to hold off any new requests till StorPortResume() is called.


3.       Code should be added to call  StorPortSynchronizeAccess() in order to synchronize with HwStorInterrupt. A callback routine in the NVMe driver should also be added for NVMeResetBus to do the synchronized work in. HwStorResetBus is already synchronized with HwStorStartIo since the port driver calls it only after acquiring the StartIo spinlock.



4.       We should implement a driver-internal global (per "adapter") flag signifying we are busy with reset processing and thus can't allow new I/O requests to go through to the hardware.



5.       Code should be added to call StorPortResume() when all work is complete.



6.       We should refer to the WDK-supplied LSI parallel SCSI StorPort miniport sample driver for an example of all of the above.



Thanks,
Judy


Thanks,
Dharani.


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Foster, Carolyn D
Sent: Monday, February 24, 2014 3:51 PM
To: Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: Re: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Hi Alex and Dharni,

I have been reviewing the code and performing some tests and I have some concerns about this patch.

In nvmeStd.c:
Line 1384: NVMeProcessAbortLunReset - This change will now send abort commands for all pending requests when a RESET_LOGICAL_UNIT request comes in, instead of issuing the RecoveryDpc routine.  This change concerns me the most.  During a reset there is no need to send individual abort requests for outstanding commands.  When the LUN reset comes in, we will set CC.EN to 0 and the spec clearly states that "the controller shall not process commands nor post completion queue entries to the completion queue."  This reset behavior has been accounted for in the driver, by design.  In the LUN reset case, we should continue to issue the recovery DPC routine, which will complete all outstanding commands.

What should happen here is that the new processAbortLun function should be moved under the SRB_FUNCTION_ABORT_COMMAND only.  Then the procesAbortLunReset function should only send one abort and not abort all outstanding commands.

Also, during testing, I hit a D1 BSOD when I tried to step through the code.  I ran IO and forced a timeout by using the debugger to skip over the line of code that rings the submission queue doorbell.  The IO should be timed out by storport, which will then send a reset lun.

Line 2219: StorPortSynchronizeAccess - I don't understand why this is needed.  The SynchronizeReset function looks very much like the recovery DPC routine, which should already be synchronized with Start IO and the interrupt DPC.

Thanks,
Carolyn


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, February 19, 2014 10:06 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Thank you, Dharani.

Hi all,

Please review/test the attached reset fix patch from Sandisk and provide your feedbacks.

Thank you very much,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, February 19, 2014 9:00 AM
To: Alex Chang
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the patch source for review. I have tested the I/O running over night.

Areas need to be focused for test this patch:
1. Test abort/LUN resets.
2. Test chip reset.
3. Test the format command.
4.Test Firmware download command.

Password is "sndk1234"

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 18, 2014 12:15 PM
To: Dharani Kotte
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Great!

Thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Tuesday, February 18, 2014 12:14 PM
To: Alex Chang
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Just testing after merging the code it I should be able to  send it tomorrow morning.
Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 18, 2014 12:13 PM
To: Dharani Kotte
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Hi Dharani,

Just a friendly reminder, could you please send out your patch as soon as it's ready?

Many thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, February 14, 2014 10:18 AM
To: Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Sure Alex.
Dharani.

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Friday, February 14, 2014 10:17 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Good morning, Dharani,

As you may know, both Intel and Huawei patches had been added into OFA source base. Now, you may re-base your changes and send a patch out for review/test. Thank you very much for contributing the fixes.

Regards,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, January 15, 2014 2:08 PM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: Would you please help to resolve a few OFA NVMe driver problems ?


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the source for the preliminary review. I have tested the IO and scsi compliance test. I don't have a drive which supports abort/lun resets, not sure how to test the format command.

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:54 AM
To: Dharani Kotte; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Happy Holidays to you all.
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 11:52 AM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Thank you for the explanation. Sure I will take look.
Happy Holidays.
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:44 AM
To: Kwok Kong; Dharani Kotte; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Dharani,

The controller reset can be issued from either from the host or the driver itself. Currently, the driver seems handling them in the same manner via single entry "NVMeResetController". In the case of "from the host", the driver needs to separate the cases of SRB_FUNCTION_RESET_... requests from the ioctl request of NVME_RESET_DEVICE in the sense of handling pending IOs. In the case of "the driver itself", needs to re-exam the related error recovery codes as well.
Judy from Samsung suggested referring the storahci.sys driver sample codes for Windows 7/8 based on reset bus logic examples and detailed recommendations.

Thank you,
Alex


From: Kwok Kong
Sent: Friday, December 20, 2013 9:08 AM
To: Dharani Kotte; Akshay Mathur; Alex Chang
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Dharani,

Yes, these are the three areas that you are committed to.

Alex,

Please send more details on the "Controller reset does not handle all cases"  to Dharani.

Thanks

-Kwok

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 9:02 AM
To: Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Kwok,

I think the below are the items that we are committing for:
- Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
- Controller reset does not handle all cases
- orphaned requests

Can somebody provide little bit more details on the expectation for the item "Controller reset does not handle all cases".

Thanks,
Dharani.


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Thursday, December 19, 2013 6:53 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Excellent! Your help is much appreciated.

Dharani,

Please let me know if you have any question.

Happy holiday to all of you.

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Thursday, December 19, 2013 6:51 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kwok,
You are welcome. We are pleased to contribute to the community and appreciate you driving it!

We will try our best to complete the implementation by end of January but we may not be able to complete comprehensive testing by that time. This is because of overlaps with few internal business deliverables and a company-wide shut-down for next 1.5 weeks.

Anyway, Dharani will be in touch with you as he makes progress.
Thanks
Akshay

From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Tuesday, December 17, 2013 4:21 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Akshay,

Thanks for your willingness to contribute to the driver.   I am looking for a patch before end of Jan 2014, the earlier the better.
Please let me know if Sandisk can commit to that.

Your help is much appreciated.

Thanks

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Tuesday, December 17, 2013 4:11 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman; Akshay Mathur
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kowk,
I manage the Software and driver development team at SanDisk/ESS.
We are certainly willing to contribute to fixing the problems listed below but before we can commit, we would like to get clarification on the timeline i.e. by when these fixes are expected to be completed.
Thanks
Akshay Mathur
Sr Software Manager, Enterprise Storage Solutions
951 SanDisk Drive, Building #5  |  Milpitas, CA 95035 U.S.A.  |  Direct  +1 408.801.1336  |
Cell +1 856.607.7323  |  Corporate +1 408.801.1000  |  Akshay.Mathur at sandisk.com<mailto:Akshay.Mathur at sandisk.com>
[Description: cid:image001.jpg at 01CC358D.60974910]


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Wednesday, December 11, 2013 18:00
To: Dave Landsman
Cc: Dharani Kotte
Subject: Would you please help to resolve a few OFA NVMe driver problems ?

Dave and Dharani,

There are some issues with the current OFA driver that need to be fixed. PMC is working on resolving some of the problems. Intel has agreed to work on the following two problems:
- remove #define for CHATHAM2
- Learning of CPU core to Vector failure handling

I am also making request to other companies to work on some of the issues.

I wonder if your company can work on the following three problems:
                - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
                - Controller reset does not handle all cases
                - orphaned requests

Please let me know if your company can work on these two issues.

Thanks

-Kwok



________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).










-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140225/23a76fec/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 9449 bytes
Desc: image001.jpg
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140225/23a76fec/attachment.jpg>

From Dharani.Kotte at sandisk.com  Tue Feb 25 15:25:20 2014
From: Dharani.Kotte at sandisk.com (Dharani Kotte)
Date: Tue, 25 Feb 2014 23:25:20 +0000
Subject: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset
 Fixes
In-Reply-To: <E1729D5DBAB9E948BA87B76FDFA1298A0C889E6C@BBYEXM01.pmc-sierra.internal>
References: <E1729D5DBAB9E948BA87B76FDFA1298A0C884EEB@BBYEXM01.pmc-sierra.internal>
	<23EC73C80FB59046A6B7B8EB7B3826593BDF0B5C@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889023@BBYEXM01.pmc-sierra.internal>
	<23EC73C80FB59046A6B7B8EB7B3826593BDF134C@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889036@BBYEXM01.pmc-sierra.internal>
	<26455_1392829222_5304E326_26455_6404_1_23EC73C80FB59046A6B7B8EB7B3826593BDF1488@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C88952B@BBYEXM01.pmc-sierra.internal>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF9C48@FMSMSX105.amr.corp.intel.com>
	<23EC73C80FB59046A6B7B8EB7B3826593DA6D6E0@SACMBXIP02.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889E55@BBYEXM01.pmc-sierra.internal>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889E6C@BBYEXM01.pmc-sierra.internal>
Message-ID: <23EC73C80FB59046A6B7B8EB7B3826593DA6F8B5@SACMBXIP02.sdcorp.global.sandisk.com>

Hi Alex,

Sure, I will go over the list below and make changes accordingly next week.

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 25, 2014 2:09 PM
To: Alex Chang; Dharani Kotte; Foster, Carolyn D; nvmewin at lists.openfabrics.org
Subject: RE: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Just left out one more :
In Line#1228 of nvmeInit.c, NVMeWaitOnRdy is called to replace assigning NextDriverState as NVMeWaitOnRdy. I think the assignment is still required before the initialization state machine starts.

Alex

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 25, 2014 2:03 PM
To: Dharani Kotte; Foster, Carolyn D; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: Re: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Hi Carolyn and Dharani,

I basically agree the suggested changes in HwStorResetBus. However, I have some feedback:

1.       In Line#2161, NVMeResetAdapter is called and it returns after making sure RDY bit is cleared as 0, why we need 10 ms delay ? The exact same delay added in RecoveryDpcRoutine was because original NVMeResetAdater did not wait until RDY bit is cleared as 0. Due to the changes in NVMeResetAdapter, we need to remove the 10 ms delay in RecoveryDpcRoutine as well.

2.       In Line#2216, StorPortPause is called with 60 seconds to force Storport hold up requests. I am not sure 60 seconds is proper assumption. Instead, calling "StorPortBusy(pAdapterExtension, STOR_ALL_REQUESTS);" seems better idea to me.

3.       In the definition of HwStorResetBus, the routine returns TRUE in successful case. We need to take care of failed cases as well, i.e., any failures within NVMeSynchronizeReset. And StorPortResume should be called only in successful case.

Thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Tuesday, February 25, 2014 4:28 AM
To: Foster, Carolyn D; Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Hi Carolyn,

Line 1384: I can take care of this item.

Line 2219: StorPortSynchronizeAccess, This is the request from Samsung suggested by Judy. Below is the reference mail.

In our testing, we create a situation where we put the NVMe driver under heavy I/O load with Iometer and then cause the device to stop responding.  This results in I/O request timeouts which eventually causes the driver to be called at it's HwStorResetBus entry point (NVMeResetBus).  I have some feedback on the current architecture of that routine:


1.       Among other things, NMeResetBus schedules a DPC to complete any pending commands. This creates a situation where upon return from this entry point, there are still cmds outstanding which don't get completed till the DPC runs.  According to the WDK, this doesn't appear to be legal - all outstanding cmds have to be completed by the HwStorResetBus routine before it returns:

HwResetBus

Pointer to the miniport driver's HwStorResetBus<ms-help://MS.WDK.v10.7600.091201/Storage_r/hh/Storage_r/stormini_b3051379-4caa-4502-9492-a21672cfbf0d.xml.htm> routine, which is a required entry point for all miniport drivers. This member has the same meaning for the Storport version of the HW_INITIALIZATION_DATA structure as it does for the SCSI Port version of the structure. For more information, see the HwResetBus member of HW_INITIALIZATION_DATA (SCSI)
and
HwScsiResetBus must complete any outstanding requests by calling ScsiPortCompleteRequest with the SrbStatus value SRB_STATUS_BUS_RESET or, for individual SRBs, ScsiPortNotification with this status value.
and
The port driver pauses all device IO queues for the adapter and then calls the HwStorResetBus routine at IRQL DISPATCH_LEVEL after acquiring the StartIo spin lock. A miniport driver is responsible for completing SRBs received by HwStorStartIo<http://msdn.microsoft.com/en-us/library/windows/hardware/ff557423(v=vs.85).aspx> for PathId during this routine and setting their status to SRB_STATUS_BUS_RESET if necessary

Since HwStorResetBus must finish its work before returning; it can't schedule a DPC to do so later on. The logic which schedules a DPC should be removed.


2.       Code should be added to call StorPortPause() to hold off any new requests till StorPortResume() is called.


3.       Code should be added to call  StorPortSynchronizeAccess() in order to synchronize with HwStorInterrupt. A callback routine in the NVMe driver should also be added for NVMeResetBus to do the synchronized work in. HwStorResetBus is already synchronized with HwStorStartIo since the port driver calls it only after acquiring the StartIo spinlock.



4.       We should implement a driver-internal global (per "adapter") flag signifying we are busy with reset processing and thus can't allow new I/O requests to go through to the hardware.



5.       Code should be added to call StorPortResume() when all work is complete.



6.       We should refer to the WDK-supplied LSI parallel SCSI StorPort miniport sample driver for an example of all of the above.



Thanks,
Judy


Thanks,
Dharani.


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Foster, Carolyn D
Sent: Monday, February 24, 2014 3:51 PM
To: Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: Re: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Hi Alex and Dharni,

I have been reviewing the code and performing some tests and I have some concerns about this patch.

In nvmeStd.c:
Line 1384: NVMeProcessAbortLunReset - This change will now send abort commands for all pending requests when a RESET_LOGICAL_UNIT request comes in, instead of issuing the RecoveryDpc routine.  This change concerns me the most.  During a reset there is no need to send individual abort requests for outstanding commands.  When the LUN reset comes in, we will set CC.EN to 0 and the spec clearly states that "the controller shall not process commands nor post completion queue entries to the completion queue."  This reset behavior has been accounted for in the driver, by design.  In the LUN reset case, we should continue to issue the recovery DPC routine, which will complete all outstanding commands.

What should happen here is that the new processAbortLun function should be moved under the SRB_FUNCTION_ABORT_COMMAND only.  Then the procesAbortLunReset function should only send one abort and not abort all outstanding commands.

Also, during testing, I hit a D1 BSOD when I tried to step through the code.  I ran IO and forced a timeout by using the debugger to skip over the line of code that rings the submission queue doorbell.  The IO should be timed out by storport, which will then send a reset lun.

Line 2219: StorPortSynchronizeAccess - I don't understand why this is needed.  The SynchronizeReset function looks very much like the recovery DPC routine, which should already be synchronized with Start IO and the interrupt DPC.

Thanks,
Carolyn


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, February 19, 2014 10:06 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Thank you, Dharani.

Hi all,

Please review/test the attached reset fix patch from Sandisk and provide your feedbacks.

Thank you very much,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, February 19, 2014 9:00 AM
To: Alex Chang
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the patch source for review. I have tested the I/O running over night.

Areas need to be focused for test this patch:
1. Test abort/LUN resets.
2. Test chip reset.
3. Test the format command.
4.Test Firmware download command.

Password is "sndk1234"

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 18, 2014 12:15 PM
To: Dharani Kotte
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Great!

Thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Tuesday, February 18, 2014 12:14 PM
To: Alex Chang
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Just testing after merging the code it I should be able to  send it tomorrow morning.
Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 18, 2014 12:13 PM
To: Dharani Kotte
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Hi Dharani,

Just a friendly reminder, could you please send out your patch as soon as it's ready?

Many thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, February 14, 2014 10:18 AM
To: Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Sure Alex.
Dharani.

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Friday, February 14, 2014 10:17 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Good morning, Dharani,

As you may know, both Intel and Huawei patches had been added into OFA source base. Now, you may re-base your changes and send a patch out for review/test. Thank you very much for contributing the fixes.

Regards,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, January 15, 2014 2:08 PM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: Would you please help to resolve a few OFA NVMe driver problems ?


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the source for the preliminary review. I have tested the IO and scsi compliance test. I don't have a drive which supports abort/lun resets, not sure how to test the format command.

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:54 AM
To: Dharani Kotte; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Happy Holidays to you all.
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 11:52 AM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Thank you for the explanation. Sure I will take look.
Happy Holidays.
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:44 AM
To: Kwok Kong; Dharani Kotte; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Dharani,

The controller reset can be issued from either from the host or the driver itself. Currently, the driver seems handling them in the same manner via single entry "NVMeResetController". In the case of "from the host", the driver needs to separate the cases of SRB_FUNCTION_RESET_... requests from the ioctl request of NVME_RESET_DEVICE in the sense of handling pending IOs. In the case of "the driver itself", needs to re-exam the related error recovery codes as well.
Judy from Samsung suggested referring the storahci.sys driver sample codes for Windows 7/8 based on reset bus logic examples and detailed recommendations.

Thank you,
Alex


From: Kwok Kong
Sent: Friday, December 20, 2013 9:08 AM
To: Dharani Kotte; Akshay Mathur; Alex Chang
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Dharani,

Yes, these are the three areas that you are committed to.

Alex,

Please send more details on the "Controller reset does not handle all cases"  to Dharani.

Thanks

-Kwok

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 9:02 AM
To: Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Kwok,

I think the below are the items that we are committing for:
- Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
- Controller reset does not handle all cases
- orphaned requests

Can somebody provide little bit more details on the expectation for the item "Controller reset does not handle all cases".

Thanks,
Dharani.


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Thursday, December 19, 2013 6:53 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Excellent! Your help is much appreciated.

Dharani,

Please let me know if you have any question.

Happy holiday to all of you.

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Thursday, December 19, 2013 6:51 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kwok,
You are welcome. We are pleased to contribute to the community and appreciate you driving it!

We will try our best to complete the implementation by end of January but we may not be able to complete comprehensive testing by that time. This is because of overlaps with few internal business deliverables and a company-wide shut-down for next 1.5 weeks.

Anyway, Dharani will be in touch with you as he makes progress.
Thanks
Akshay

From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Tuesday, December 17, 2013 4:21 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Akshay,

Thanks for your willingness to contribute to the driver.   I am looking for a patch before end of Jan 2014, the earlier the better.
Please let me know if Sandisk can commit to that.

Your help is much appreciated.

Thanks

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Tuesday, December 17, 2013 4:11 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman; Akshay Mathur
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kowk,
I manage the Software and driver development team at SanDisk/ESS.
We are certainly willing to contribute to fixing the problems listed below but before we can commit, we would like to get clarification on the timeline i.e. by when these fixes are expected to be completed.
Thanks
Akshay Mathur
Sr Software Manager, Enterprise Storage Solutions
951 SanDisk Drive, Building #5  |  Milpitas, CA 95035 U.S.A.  |  Direct  +1 408.801.1336  |
Cell +1 856.607.7323  |  Corporate +1 408.801.1000  |  Akshay.Mathur at sandisk.com<mailto:Akshay.Mathur at sandisk.com>
[Description: cid:image001.jpg at 01CC358D.60974910]


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Wednesday, December 11, 2013 18:00
To: Dave Landsman
Cc: Dharani Kotte
Subject: Would you please help to resolve a few OFA NVMe driver problems ?

Dave and Dharani,

There are some issues with the current OFA driver that need to be fixed. PMC is working on resolving some of the problems. Intel has agreed to work on the following two problems:
- remove #define for CHATHAM2
- Learning of CPU core to Vector failure handling

I am also making request to other companies to work on some of the issues.

I wonder if your company can work on the following three problems:
                - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
                - Controller reset does not handle all cases
                - orphaned requests

Please let me know if your company can work on these two issues.

Thanks

-Kwok



________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140225/fef7756b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 9449 bytes
Desc: image001.jpg
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140225/fef7756b/attachment.jpg>

From Alex.Chang at pmcs.com  Tue Feb 25 15:26:27 2014
From: Alex.Chang at pmcs.com (Alex Chang)
Date: Tue, 25 Feb 2014 23:26:27 +0000
Subject: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset
 Fixes
In-Reply-To: <23EC73C80FB59046A6B7B8EB7B3826593DA6F8B5@SACMBXIP02.sdcorp.global.sandisk.com>
References: <E1729D5DBAB9E948BA87B76FDFA1298A0C884EEB@BBYEXM01.pmc-sierra.internal>
	<23EC73C80FB59046A6B7B8EB7B3826593BDF0B5C@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889023@BBYEXM01.pmc-sierra.internal>
	<23EC73C80FB59046A6B7B8EB7B3826593BDF134C@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889036@BBYEXM01.pmc-sierra.internal>
	<26455_1392829222_5304E326_26455_6404_1_23EC73C80FB59046A6B7B8EB7B3826593BDF1488@SACMBXIP01.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C88952B@BBYEXM01.pmc-sierra.internal>
	<B3A485AFDDB1DD4598621E85E8EB67A83AAF9C48@FMSMSX105.amr.corp.intel.com>
	<23EC73C80FB59046A6B7B8EB7B3826593DA6D6E0@SACMBXIP02.sdcorp.global.sandisk.com>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889E55@BBYEXM01.pmc-sierra.internal>
	<E1729D5DBAB9E948BA87B76FDFA1298A0C889E6C@BBYEXM01.pmc-sierra.internal>
	<23EC73C80FB59046A6B7B8EB7B3826593DA6F8B5@SACMBXIP02.sdcorp.global.sandisk.com>
Message-ID: <E1729D5DBAB9E948BA87B76FDFA1298A0C889EAA@BBYEXM01.pmc-sierra.internal>

Thank you! Dharani.

Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Tuesday, February 25, 2014 3:25 PM
To: Alex Chang; Foster, Carolyn D; nvmewin at lists.openfabrics.org
Subject: RE: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Hi Alex,

Sure, I will go over the list below and make changes accordingly next week.

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 25, 2014 2:09 PM
To: Alex Chang; Dharani Kotte; Foster, Carolyn D; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Just left out one more :
In Line#1228 of nvmeInit.c, NVMeWaitOnRdy is called to replace assigning NextDriverState as NVMeWaitOnRdy. I think the assignment is still required before the initialization state machine starts.

Alex

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Tuesday, February 25, 2014 2:03 PM
To: Dharani Kotte; Foster, Carolyn D; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: Re: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Hi Carolyn and Dharani,

I basically agree the suggested changes in HwStorResetBus. However, I have some feedback:

1.       In Line#2161, NVMeResetAdapter is called and it returns after making sure RDY bit is cleared as 0, why we need 10 ms delay ? The exact same delay added in RecoveryDpcRoutine was because original NVMeResetAdater did not wait until RDY bit is cleared as 0. Due to the changes in NVMeResetAdapter, we need to remove the 10 ms delay in RecoveryDpcRoutine as well.

2.       In Line#2216, StorPortPause is called with 60 seconds to force Storport hold up requests. I am not sure 60 seconds is proper assumption. Instead, calling "StorPortBusy(pAdapterExtension, STOR_ALL_REQUESTS);" seems better idea to me.

3.       In the definition of HwStorResetBus, the routine returns TRUE in successful case. We need to take care of failed cases as well, i.e., any failures within NVMeSynchronizeReset. And StorPortResume should be called only in successful case.

Thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Tuesday, February 25, 2014 4:28 AM
To: Foster, Carolyn D; Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Hi Carolyn,

Line 1384: I can take care of this item.

Line 2219: StorPortSynchronizeAccess, This is the request from Samsung suggested by Judy. Below is the reference mail.

In our testing, we create a situation where we put the NVMe driver under heavy I/O load with Iometer and then cause the device to stop responding.  This results in I/O request timeouts which eventually causes the driver to be called at it's HwStorResetBus entry point (NVMeResetBus).  I have some feedback on the current architecture of that routine:


1.       Among other things, NMeResetBus schedules a DPC to complete any pending commands. This creates a situation where upon return from this entry point, there are still cmds outstanding which don't get completed till the DPC runs.  According to the WDK, this doesn't appear to be legal - all outstanding cmds have to be completed by the HwStorResetBus routine before it returns:

HwResetBus

Pointer to the miniport driver's HwStorResetBus<ms-help://MS.WDK.v10.7600.091201/Storage_r/hh/Storage_r/stormini_b3051379-4caa-4502-9492-a21672cfbf0d.xml.htm> routine, which is a required entry point for all miniport drivers. This member has the same meaning for the Storport version of the HW_INITIALIZATION_DATA structure as it does for the SCSI Port version of the structure. For more information, see the HwResetBus member of HW_INITIALIZATION_DATA (SCSI)
and
HwScsiResetBus must complete any outstanding requests by calling ScsiPortCompleteRequest with the SrbStatus value SRB_STATUS_BUS_RESET or, for individual SRBs, ScsiPortNotification with this status value.
and
The port driver pauses all device IO queues for the adapter and then calls the HwStorResetBus routine at IRQL DISPATCH_LEVEL after acquiring the StartIo spin lock. A miniport driver is responsible for completing SRBs received by HwStorStartIo<http://msdn.microsoft.com/en-us/library/windows/hardware/ff557423(v=vs.85).aspx> for PathId during this routine and setting their status to SRB_STATUS_BUS_RESET if necessary

Since HwStorResetBus must finish its work before returning; it can't schedule a DPC to do so later on. The logic which schedules a DPC should be removed.


2.       Code should be added to call StorPortPause() to hold off any new requests till StorPortResume() is called.


3.       Code should be added to call  StorPortSynchronizeAccess() in order to synchronize with HwStorInterrupt. A callback routine in the NVMe driver should also be added for NVMeResetBus to do the synchronized work in. HwStorResetBus is already synchronized with HwStorStartIo since the port driver calls it only after acquiring the StartIo spinlock.



4.       We should implement a driver-internal global (per "adapter") flag signifying we are busy with reset processing and thus can't allow new I/O requests to go through to the hardware.



5.       Code should be added to call StorPortResume() when all work is complete.



6.       We should refer to the WDK-supplied LSI parallel SCSI StorPort miniport sample driver for an example of all of the above.



Thanks,
Judy


Thanks,
Dharani.


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Foster, Carolyn D
Sent: Monday, February 24, 2014 3:51 PM
To: Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: Re: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Hi Alex and Dharni,

I have been reviewing the code and performing some tests and I have some concerns about this patch.

In nvmeStd.c:
Line 1384: NVMeProcessAbortLunReset - This change will now send abort commands for all pending requests when a RESET_LOGICAL_UNIT request comes in, instead of issuing the RecoveryDpc routine.  This change concerns me the most.  During a reset there is no need to send individual abort requests for outstanding commands.  When the LUN reset comes in, we will set CC.EN to 0 and the spec clearly states that "the controller shall not process commands nor post completion queue entries to the completion queue."  This reset behavior has been accounted for in the driver, by design.  In the LUN reset case, we should continue to issue the recovery DPC routine, which will complete all outstanding commands.

What should happen here is that the new processAbortLun function should be moved under the SRB_FUNCTION_ABORT_COMMAND only.  Then the procesAbortLunReset function should only send one abort and not abort all outstanding commands.

Also, during testing, I hit a D1 BSOD when I tried to step through the code.  I ran IO and forced a timeout by using the debugger to skip over the line of code that rings the submission queue doorbell.  The IO should be timed out by storport, which will then send a reset lun.

Line 2219: StorPortSynchronizeAccess - I don't understand why this is needed.  The SynchronizeReset function looks very much like the recovery DPC routine, which should already be synchronized with Start IO and the interrupt DPC.

Thanks,
Carolyn


From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Wednesday, February 19, 2014 10:06 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes

Thank you, Dharani.

Hi all,

Please review/test the attached reset fix patch from Sandisk and provide your feedbacks.

Thank you very much,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, February 19, 2014 9:00 AM
To: Alex Chang
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the patch source for review. I have tested the I/O running over night.

Areas need to be focused for test this patch:
1. Test abort/LUN resets.
2. Test chip reset.
3. Test the format command.
4.Test Firmware download command.

Password is "sndk1234"

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 18, 2014 12:15 PM
To: Dharani Kotte
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Great!

Thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Tuesday, February 18, 2014 12:14 PM
To: Alex Chang
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Just testing after merging the code it I should be able to  send it tomorrow morning.
Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Tuesday, February 18, 2014 12:13 PM
To: Dharani Kotte
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Hi Dharani,

Just a friendly reminder, could you please send out your patch as soon as it's ready?

Many thanks,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, February 14, 2014 10:18 AM
To: Alex Chang; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Sure Alex.
Dharani.

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Alex Chang
Sent: Friday, February 14, 2014 10:17 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Re-send Sandisk Patch For Reset Fixes

Good morning, Dharani,

As you may know, both Intel and Huawei patches had been added into OFA source base. Now, you may re-base your changes and send a patch out for review/test. Thank you very much for contributing the fixes.

Regards,
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Wednesday, January 15, 2014 2:08 PM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] RE: Would you please help to resolve a few OFA NVMe driver problems ?


Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

Date: %%SENT_DATE%%

Subject: Suspect Message Quarantined







WARNING: The virus scanner was unable to scan an attachment in an email message sent to you.  This attachment could possibly contain viruses or other malicious programs.  The attachment could not be scanned for the following reasons:



%%DESC%%



The full message and the attachment have been stored in the quarantine.



The identifier for this message is '%%QID%%'.



Access the quarantine at:

https://puremessage.pmc-sierra.bc.ca:28443/



For more information on PMC's Anti-Spam system:

http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ



IT Services

PureMessage Admin


Hi Alex,

The attached is the source for the preliminary review. I have tested the IO and scsi compliance test. I don't have a drive which supports abort/lun resets, not sure how to test the format command.

Thanks,
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:54 AM
To: Dharani Kotte; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Happy Holidays to you all.
Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 11:52 AM
To: Alex Chang; Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Thank you for the explanation. Sure I will take look.
Happy Holidays.
Dharani.

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Friday, December 20, 2013 11:44 AM
To: Kwok Kong; Dharani Kotte; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Dharani,

The controller reset can be issued from either from the host or the driver itself. Currently, the driver seems handling them in the same manner via single entry "NVMeResetController". In the case of "from the host", the driver needs to separate the cases of SRB_FUNCTION_RESET_... requests from the ioctl request of NVME_RESET_DEVICE in the sense of handling pending IOs. In the case of "the driver itself", needs to re-exam the related error recovery codes as well.
Judy from Samsung suggested referring the storahci.sys driver sample codes for Windows 7/8 based on reset bus logic examples and detailed recommendations.

Thank you,
Alex


From: Kwok Kong
Sent: Friday, December 20, 2013 9:08 AM
To: Dharani Kotte; Akshay Mathur; Alex Chang
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Dharani,

Yes, these are the three areas that you are committed to.

Alex,

Please send more details on the "Controller reset does not handle all cases"  to Dharani.

Thanks

-Kwok

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com]
Sent: Friday, December 20, 2013 9:02 AM
To: Kwok Kong; Akshay Mathur
Cc: Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Hi Kwok,

I think the below are the items that we are committing for:
- Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
- Controller reset does not handle all cases
- orphaned requests

Can somebody provide little bit more details on the expectation for the item "Controller reset does not handle all cases".

Thanks,
Dharani.


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Thursday, December 19, 2013 6:53 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Excellent! Your help is much appreciated.

Dharani,

Please let me know if you have any question.

Happy holiday to all of you.

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Thursday, December 19, 2013 6:51 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kwok,
You are welcome. We are pleased to contribute to the community and appreciate you driving it!

We will try our best to complete the implementation by end of January but we may not be able to complete comprehensive testing by that time. This is because of overlaps with few internal business deliverables and a company-wide shut-down for next 1.5 weeks.

Anyway, Dharani will be in touch with you as he makes progress.
Thanks
Akshay

From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Tuesday, December 17, 2013 4:21 PM
To: Akshay Mathur
Cc: Dharani Kotte; Dave Landsman
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Akshay,

Thanks for your willingness to contribute to the driver.   I am looking for a patch before end of Jan 2014, the earlier the better.
Please let me know if Sandisk can commit to that.

Your help is much appreciated.

Thanks

-Kwok

From: Akshay Mathur [mailto:Akshay.Mathur at sandisk.com]
Sent: Tuesday, December 17, 2013 4:11 PM
To: Kwok Kong
Cc: Dharani Kotte; Dave Landsman; Akshay Mathur
Subject: RE: Would you please help to resolve a few OFA NVMe driver problems ?

Kowk,
I manage the Software and driver development team at SanDisk/ESS.
We are certainly willing to contribute to fixing the problems listed below but before we can commit, we would like to get clarification on the timeline i.e. by when these fixes are expected to be completed.
Thanks
Akshay Mathur
Sr Software Manager, Enterprise Storage Solutions
951 SanDisk Drive, Building #5  |  Milpitas, CA 95035 U.S.A.  |  Direct  +1 408.801.1336  |
Cell +1 856.607.7323  |  Corporate +1 408.801.1000  |  Akshay.Mathur at sandisk.com<mailto:Akshay.Mathur at sandisk.com>
[Description: cid:image001.jpg at 01CC358D.60974910]


From: Kwok Kong [mailto:Kwok.Kong at pmcs.com]
Sent: Wednesday, December 11, 2013 18:00
To: Dave Landsman
Cc: Dharani Kotte
Subject: Would you please help to resolve a few OFA NVMe driver problems ?

Dave and Dharani,

There are some issues with the current OFA driver that need to be fixed. PMC is working on resolving some of the problems. Intel has agreed to work on the following two problems:
- remove #define for CHATHAM2
- Learning of CPU core to Vector failure handling

I am also making request to other companies to work on some of the issues.

I wonder if your company can work on the following three problems:
                - Not handling CSTS.RDY status (from 1->0 and 0->1) properly on NVMe reset
                - Controller reset does not handle all cases
                - orphaned requests

Please let me know if your company can work on these two issues.

Thanks

-Kwok



________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).











-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140225/073414f9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 9449 bytes
Desc: image001.jpg
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140225/073414f9/attachment.jpg>