[nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes
Alex Chang
Alex.Chang at pmcs.com
Tue Apr 22 09:26:22 PDT 2014
Hi Judy,
Thank you for your suggestions/comments. When reviewing/testing Dharani's patch, we believe the reset related changes had covered most cases and paths. We're going to release revision 1.3 soon and, unless there are some immediate urgent fixes required, I'd suggest we can discuss more before adding changes that are agreed by the community and included in revision 1.4 later. Please let us know what you think.
Regards,
Alex
From: Judy Brock-SSI [mailto:judy.brock at ssi.samsung.com]
Sent: Monday, April 21, 2014 12:04 PM
To: nvmewin at openfabrics.org
Cc: Foster, Carolyn D; Dharani Kotte (Dharani.Kotte at sandisk.com); Alex Chang
Subject: RE: [nvmewin] ***UNCHECKED*** FW: Re-send Sandisk Patch For Reset Fixes
Hi Carolyn and Dharani et al,
[Carolyn wrote] 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.
[Dharani wrote] Line 2219: StorPortSynchronizeAccess, This is the request from Samsung suggested by Judy. Below is the reference mail.
The reason it was needed is because when the reference email was sent (7/18/2013), the OFA driver had a flag called COMPLETE_IN_DPC which controlled whether completions were handled in ISR context directly vs handled later in DPC context. So there was a true ISR context to contend with which the HwResetBus routine had to be synchronized with.
One way to do that is to use StorPortSynchronizeAccess as the legacy LSI miniport does, another way is to acquire/release the StorPortInterruptLock ourselves in our HwResetBus routine as the storport AHCI miniport does, for example. One way or another, we needed to synchronize with our HwInterrupt routine at that time. We have since eliminated the COMPLETE_IN_DPC flag along with the path which did completions in the ISR directly (see http://lists.openfabrics.org/pipermail/nvmewin/2013-July/000608.html ) so Carolyn is correct - NVMeResetBus is currently synchronized with StartIo and the Interrupt DPC already.
However, that does not mean the original recovery DPC routine could be scheduled as it originally wasfrom NVMeResetBus since there is still a need to not schedule a DPC from within that routine - by definition, all work must be completed before returning. Below please find some additional feedback on the restructured reset logic. I apologize for not having provided it in the originally requested timeframe. I hope it can discussed and dealt with as the team decides is most convenient.
1. NVMeResetBus routine does not need to use StorPortSynchronizeAccess to synchronize with the ISR because we no longer do completions directly in ISR context as we did at the time I wrote my original recommendations for revising the HwBusReset routine.
See http://lists.openfabrics.org/pipermail/nvmewin/2013-July/000608.html in which we decided to remove the COMPLETE_IN_DPC flag which allowed the driver to switch between completions in ISR context vs completions in DPC context. However, there is still a need to not schedule a DPC from NVMeResetBus as was the case prior to the reset patch effort. All work must be completed before returning from the call to NVMeResetBus.
2. Even if called directly, the current logic in the NVMeSynchronizeReset() routine has the same problem as the original code had in that it will not wait for all necessary work to be done before returning. After resetting the controller and completing all outstanding requests, it starts the re-initialize state machine with a call to NVMeRunningStartAttempt(). However,upon return from that call, there is no logic in place to wait for the initialization state machine to run to completion. We just fall straight through, allow IOs to resume, and return.
There needs to be logic, similar to that in NVMePassiveInitialize, which waits for pAE->DriverState.NextDriverState to become either NVMeStartComplete or NVMeStartFailed in a while loop which calls NVMeStallExecution between checks, up to some maximum amount of time.
3. The Recovery DPC routine has the same problem NVMeSynchronizeReset - there is no logic in place to wait for the initialization state machine to run to completion after the call to NVMeRunningStartAttempt() which starts it off.
4. NVMeWaitForCtrlRDY should have a return value that can be checked to see if it was successful or not. Right now, everywhere it is called the code forges ahead regardless of whether the RDY bit is in the desired state or not. Specifically, the following changes should be made (highlighted,line nums based on most-recently circulated Intel patch):
In NvmeStd.h:
BOOLEAN NVMeWaitForCtrlRDY(
__in PNVME_DEVICE_EXTENSION pAE,
__in ULONG expectedValue
);
In NvmeStd.c:
Line 1978:
BOOLEAN NVMeWaitForCtrlRDY(
__in PNVME_DEVICE_EXTENSION pAE,
__in ULONG expectedValue
)
{
NVMe_CONTROLLER_STATUS CSTS = {0};
ULONG time = 0;
CSTS.AsUlong =
StorPortReadRegisterUlong(pAE,
&pAE->pCtrlRegister->CSTS.AsUlong);
while (CSTS.RDY != expectedValue) {
NVMeCrashDelay(STORPORT_TIMER_CB_us, pAE->ntldrDump);
time += STORPORT_TIMER_CB_us;
if (time > pAE->uSecCrtlTimeout) {
return FALSE;
}
CSTS.AsUlong =
StorPortReadRegisterUlong(pAE,
&pAE->pCtrlRegister->CSTS.AsUlong);
};
return TRUE;
}
Line 651:
if(NVMeWaitForCtrlRDY(pAE, 1) == FALSE) {
StorPortDebugPrint(INFO,
"NVMeInitialize: EN bit set to 1 but RDY bit set to 0\n");
return FALSE;
}
Line 661:
if(NVMeWaitForCtrlRDY(pAE, 0) == FALSE) {
StorPortDebugPrint(INFO,
"NVMeInitialize: EN bit set to 0 but RDY bit won't clear- still 1\n");
return FALSE;
}
etc.
5. NVMeCompleteCmd should have a return value that can be checked to see if it was successful or not. Right now, everywhere it is called the code forges ahead regardless of whether the RDY bit is in the desired state or not. NVMeResetController is called from several places in the driver. One of the routines which it is called from is NVMeCompleteCmd:
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;
}
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.
6. There is redundancy in the new routine NVMeWaitForCtrlRDY() and the routine NVMeWaitOnReady(). Although the new routine is missing a return value (see item #1), we don't need both - we can get rid of the old routine.
7. In NvmeStd.c, line 646:
Except for the first sentence, this comment is not accurate,should be removed:
/*
* Before we transition to 0, make sure the ctrl is actually RDY
* NOTE: Some HW implementations may not require this wait and if not then it could be removed as waiting at this IRQL is not recommended. The spec is not clear on whether we
* need to wait for RDY to transition EN back to 0 or not.
*/
NVM Express 1.0e and beyond includes the following statement in the definition of the EN bit(emphasis added): "Setting this field from a '0' to a '1' when CSTS.RDY is a '1,' or setting this field from a '1' to a '0' when CSTS.RDY is a '0,' has undefined results."
8. 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
9. In the RecoveryDpcRoutine():
a) 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.
b) is there an actual requirement for the following code?:
/* 10 msec "settle" delay post reset */
NVMeStallExecution(pAE, 10000);
c) is it really safe and/or required to always acquire/release the StartIo lock?
10. This is not feedback related Reset logic per-se but do we really need the NVMeCallArbiter() function at this point? I think we could replace all occurences of
NVMeCallArbiter(pAE);
with
if (pAE->ntldrDump == FALSE) {
StorPortNotification(RequestTimerCall,
pAE,
NVMeRunning,
pAE->DriverState.CheckbackInterval);
}
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 Dharani Kotte
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/20140422/17583c97/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/20140422/17583c97/attachment.jpg>
More information about the nvmewin
mailing list