[nvmewin] ***UNCHECKED*** ***UNCHECKED*** RE: LBA Range Type Patch

[Alex Chang]

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>