[nvmewin] NVMe OFA Patch for Random bug fixes

Alex Chang Alex.Chang at pmcs.com
Fri Aug 15 17:50:24 PDT 2014 

Hi Judy,
I have my patch ready. Can I send it out first? And Suman can take his time to debug the issue?

Thanks,
Alex


From: Judy Brock-SSI [mailto:judy.brock at ssi.samsung.com]
Sent: Friday, August 15, 2014 5:13 PM
To: Uma Parepalli; Alex Chang; SUMAN PRAKASH B; nvmewin at lists.openfabrics.org
Subject: RE: [nvmewin] NVMe OFA Patch for Random bug fixes

Hi Uma,
I am not sure if there will be a patch by tomorrow. I relayed the exact message I got from Suman which was that he expects to have an update by EOD tomorrow. I believe it will depend on what he finds.
Thanks,
Judy

From: Uma Parepalli [mailto:Uma.Parepalli at skhms.com]
Sent: Friday, August 15, 2014 11:47 AM
To: Alex Chang; Judy Brock-SSI; SUMAN PRAKASH B; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: [nvmewin] NVMe OFA Patch for Random bug fixes

Thank you Alex and Judy.
Hi Judy,
             Does your email mean that there will be a patch by tomorrow 8/16 so that Alex can have it released on Monday 8/18?
             I would prefer to have the patch with the crash fix.
             Thank you,
Uma
Uma Parepalli
Cell: 408 805 9260
uma.parepalli at skhms.com<mailto:uma.parepalli at skhms.com>
SK Hynix Memory Solutions Inc.
3103 North 1st Street, San Jose, CA



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, August 15, 2014 11:02 AM
To: Judy Brock-SSI; SUMAN PRAKASH B; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: Re: [nvmewin] NVMe OFA Patch for Random bug fixes

Thanks, Judy, for letting me know.
Regards,
Alex

From: Judy Brock-SSI [mailto:judy.brock at ssi.samsung.com]
Sent: Thursday, August 14, 2014 11:51 PM
To: Alex Chang; SUMAN PRAKASH B; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: [nvmewin] NVMe OFA Patch for Random bug fixes

Hi Alex,
Please go ahead with your patch on Monday. Suman will be out of the office tomorrow (the 15th).  However, he is planning on looking into the crash on the 16th and should have an update by EOD 16th.
Thanks,
Judy

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, August 14, 2014 9:45 AM
To: SUMAN PRAKASH B; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: Re: [nvmewin] NVMe OFA Patch for Random bug fixes

Hi Suman,
Thank you so much for your effort.
I did a quick test on Windows 8.1 and it crashes the system right after installation. Have you seen that?
By the way, I thought PMC is the next to send patch out. Anyway, Could you please look into the crash? If it can be fixed by the end of tomorrow, we will start reviewing/testing your patch. Otherwise, I will send out PMC patch on Monday.
Regards,
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 SUMAN PRAKASH B
Sent: Thursday, August 14, 2014 1:41 AM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] NVMe OFA Patch for Random bug 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 Everyone,



We have a patch for the following random bug fixes -

a. Invalid return value for NVMeAdapterControl.
b. Handling StartIo deadlock when MultipleCoresToSingleQueueFlag is set.
c. Support for STORAGE_REQUEST_BLOCK in DriverEntry.
d. Handling return value for NVMeCompleteCmd.
e. Handling return value for NVMeWaitForCtrlRDY.
f. Fixing the NVMeResetAdapter issues to check if CC.EN is set to 1 before setting to 0.
g. Memory corruption constructing inquiry response data in SntiTranslateStandardInquiryPage.
h. Eliminate NVMeWaitOnReady and use only NVMeWaitForCtrlRDY.
i. Fix the RecoveryDpcRoutine to avoid redundant setting of CC.EN bit to 0.
j. Write Buffer implementation correction.
k. Enabling Eject option in the taskbar.



Please send feedback by August 21st.  The password is samsung123



Change details -

1) Invalid return value for NVMeAdapterControl
NVMeAdapterControl miniport routine -  sometimes returns illegal value. WDK specifies that the driver must always return ScsiAdapterControlSuccess. However, depending on execution, the driver may currently return ScsiAdapterControlUnsuccessful for ScsiStopAdapter and ScsiRestartAdapter control types.
As per msdn - http://msdn.microsoft.com/en-us/library/windows/hardware/ff557365(v=vs.85).aspx
Affected Files/Functions:
        nvmeStd.c / NVMeAdapterControl()



2) Handling StartIo deadlock when MultipleCoresToSingleQueueFlag is set
Affected Files/Functions:
        Set the AcquireLock parameter to FALSE in the processio () in the below functions.
        nvmeSnti.c / SntiTranslateTemperatureResponse ()
        nvmeSnti.c / SntiTranslateStartStopUnitResponse ()
        nvmeStd.c / NVMeHandleSmartThresholds ()



3) Support for STORAGE_REQUEST_BLOCK in DriverEntry
Set the SrbTypeFlags in DriverEntry() function to support STORAGE_REQUEST_BLOCK.

Affected Files/Functions:
        nvmeStd.c / DriverEntry ():



4) Handlings return value for NVMeCompleteCmd.
NVMeCompleteCmd should have a return value that can be checked to see if it was successful or not. Right now, wherever it's called from the code forges ahead regardless of whether it succeeded or failed:
VOID NVMeCompleteCmd{
. . .
if ((pCmdEntry->Pending == FALSE) || (pCmdEntry->Context == NULL)) {
/* Something bad happened so reset the adapter and hope for the best */
                  NVMeResetController(pAE, NULL);
                                    return;
}
As shown above, one of the routines which NVMeCompleteCmd calls is NVMeResetController. Since NVMeCompleteCmd has no return value, this fatal error return is never detected in any of the places that the function is called from (quite a few) - the logic just proceeds on as if everything is fine. In some cases NVMeCompleteCmd can be called over and over (if it is called from DetectPendingCmds or IoCompletionDpcRoutine for example) which may in turn cause repeated calls to NVMeResetController.
Affected Files/Functions:
        nvmeIo.c / ProcessIo ()
        nvmeIo.c / NVMeCompleteCmd ()
        nvmeIo.h / NVMeCompleteCmd ()
        nvmeStd.c / IoCompletionDpcRoutine ()



5) Handling return value for NVMeWaitForCtrlRDY
NVMeWaitForCtrlRDY should have a return value of type BOOLEAN that can be checked to see if it was successful or not.

Affected Files/Functions:
        nvmeStd.c / NVMeInitialize ()



6) Fixing the NVMeResetAdapter issues to check if CC.EN is set to 1 before setting to 0.
The routine NVMeResetAdapter() sets CC.EN to 0 without ever checking to make sure that CSTS.RDY is set to '1' first. This check has to be included in this routine. Since it is not, there are many paths in the driver where there is no prior check for this condition:
a) NVMeInitAdminQueues -> NVMeEnableAdapter -> NVMeResetAdapter
b) NVMeNormalShutdown -> NVMeResetAdapter
c) NVMeAdapterControlPowerDown -> NVMeResetAdapter
d) NVMeSynchronizeReset -> NVMeResetAdapter

Affected Files/Functions:
        nvmeInit.c / NVMeResetAdapter ()



7) Memory corruption constructing inquiry response data in SntiTranslateStandardInquiryPage
Memory corruption constructing inquiry response data -  In SntiTranslateStandardInquiryPage(), the following line of code is touching a field way past the end of STANDARD_INQUIRY_LENGTH (36 bytes):
pStdInquiry->Reserved3[0]        = RESERVED_FIELD;

Affected Files/Functions:
        nvmeSnti.c / SntiTranslateStandardInquiryPage ()



8) Eliminate NVMeWaitOnReady and use only NVMeWaitForCtrlRDY.
There is redundancy in the new routine NVMeWaitForCtrlRDY() and the old routine NVMeWaitOnReady(). We don't need both - we can get rid of the old routine.

Affected Files/Functions:
        nvmeInit.c / NVMeResetAdapter ()



9) Fix the RecoveryDpcRoutine to avoid redundant setting of CC.EN bit to 0.
The code does not need to set CC.EN to '0' and then wait for CSTS.RDY to become 0 because right after it does so, it calls NVMeResetAdapter which does the exact same thing.

Affected Files/Functions:
        nvmeStd.c / RecoveryDpcRoutine ()



10) Write Buffer implementation correction.
a. Calculation of dword10 for DOWNLOAD_SAVE_ACTIVATE and DOWNLOAD_SAVE_DEFER_ACTIVATE is modified.
b. Set the SRB Status value for NVMe command failure condition in SntiCompletionCallbackRoutine.
c. Prepare the Firmware Activate Command and issue the command in case of DOWNLOAD_SAVE_ACTIVATE mode in SntiTranslateWriteBufferResponse.
d. Handled the scenario of SNTI_SEQUENCE_IN_PROGRESS for Write Data Buffer command.

Affected Files/Functions:
        nvmeSnti.c / SntiCompletionCallbackRoutine
        nvmeSnti.c / SntiTranslateWriteBufferResponse



11) Enabling Eject option in the taskbar:
Affected Files/Functions:
        nvmeStd.c / DriverEntry (): Set the FeatureSupport flag to STOR_FEATURE_FULL_PNP_DEVICE_CAPABILITIES.

        nvmeStd.c / NVMeBuildIo (): Use the PSTOR_DEVICE_CAPABILITIES_EX structure for PNPAction StorQueryCapabilities. Set the Removable flag to TRUE.



Unit tests:
Win7/8/8.1, Server 2008R2/2012/2012R2



Thanks,

Suman





[cid:image001.gif at 01CFB8B1.5A5250E0]

[Image removed by sender.]
The information contained in this e-mail is considered confidential of SK hynix memory solutions Inc. and intended only for the persons addressed or copied in this e-mail. Any unauthorized use, dissemination of the information, or copying of this message is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140816/7087867a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 13168 bytes
Desc: image001.gif
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140816/7087867a/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 823 bytes
Desc: image002.jpg
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140816/7087867a/attachment.jpg>

More information about the nvmewin mailing list