In our kernel stack we have our driver sending out I/Os through the MS iSCSI initiator on Node A to another of our machine (node B) where we have our own iSCSI target driver. When one of those I/Os get stuck in Node B we see Node A’s MPIO layer throwing an error leading to the IRP_MN_REMOVE_DEVICE Irp to come down to our driver.
Currently we handle that Irp by first performing the IoReleaseRemoveLockAndWait (), then passing the Irp down to the next driver and finally releasing our resources.
The problem is that it takes about 4 minutes to get out of the IoReleaseRemoveLockAndWait() in this situation. Surely some of those stuck I/Os must still be waited upon by the iSCSI initiator and prevent us from getting out of the wait. When we do get out of it it coincides with the iSCSI initiator timing out, sending a SCSI RESET to Node B and , I guess, completing those IRPs back to us; which allows our remove to proceed further.
Reading the MSDN I can see that the IoReleaseRemoveLockAndWait() should be done *after* passing down the IRP_MN_REMOVE_DEVICE Irp down, so I can see I might have to change the order we have in place today but then my question is:
Would the MS iSCSI initiator then cancel those stuck I/Os and complete those IRPs back to us immediately when it receives the IRP_MN_REMOVE_DEVICE ?
If the answer is yes then the ordering is what is causing our 4 minutes wait problem. I’d like some confirmation as I do not have access to the MS iSCSI initiator code.
Thank you for your time.
Thierry
Try setting Immed bit to FALSE in your SCSI IO, and then poll the target for IO completion by TEST UNIT READY.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> In our kernel stack we have our driver sending out I/Os through the MS iSCSI initiator on Node A to another of our machine (node B) where we have our own iSCSI target driver. When one of those I/Os get stuck in Node B we see Node A’s MPIO layer throwing an error leading to the IRP_MN_REMOVE_DEVICE Irp to come down to our driver.
>
> Currently we handle that Irp by first performing the IoReleaseRemoveLockAndWait (), then passing the Irp down to the next driver and finally releasing our resources.
> The problem is that it takes about 4 minutes to get out of the IoReleaseRemoveLockAndWait() in this situation. Surely some of those stuck I/Os must still be waited upon by the iSCSI initiator and prevent us from getting out of the wait. When we do get out of it it coincides with the iSCSI initiator timing out, sending a SCSI RESET to Node B and , I guess, completing those IRPs back to us; which allows our remove to proceed further.
>
> Reading the MSDN I can see that the IoReleaseRemoveLockAndWait() should be done after passing down the IRP_MN_REMOVE_DEVICE Irp down, so I can see I might have to change the order we have in place today but then my question is:
>
> Would the MS iSCSI initiator then cancel those stuck I/Os and complete those IRPs back to us immediately when it receives the IRP_MN_REMOVE_DEVICE ?
>
> If the answer is yes then the ordering is what is causing our 4 minutes wait problem. I’d like some confirmation as I do not have access to the MS iSCSI initiator code.
>
> Thank you for your time.
> Thierry
>
It may be irrelevant, but 4 minutes sounds suspiciously like the TCP TIME_WAIT default period.
You might experiment by adjusting it in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Tcpip\Parameters\TcpTimedWaitDelay
and restarting.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-604734-
xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: 17 March 2016 23:57
To: Windows System Software Devs Interest List
Subject: [ntdev] handling of IRP_MN_REMOVE_DEVICE in iSCSI initiator
In our kernel stack we have our driver sending out I/Os through the MS
iSCSI initiator on Node A to another of our machine (node B) where we
have our own iSCSI target driver. When one of those I/Os get stuck in
Node B we see Node A’s MPIO layer throwing an error leading to the
IRP_MN_REMOVE_DEVICE Irp to come down to our driver.
Currently we handle that Irp by first performing the
IoReleaseRemoveLockAndWait (), then passing the Irp down to the next
driver and finally releasing our resources.
The problem is that it takes about 4 minutes to get out of the
IoReleaseRemoveLockAndWait() in this situation. Surely some of those
stuck I/Os must still be waited upon by the iSCSI initiator and prevent
us from getting out of the wait. When we do get out of it it coincides
with the iSCSI initiator timing out, sending a SCSI RESET to Node B and
, I guess, completing those IRPs back to us; which allows our remove to
proceed further.
Reading the MSDN I can see that the IoReleaseRemoveLockAndWait() should
be done *after* passing down the IRP_MN_REMOVE_DEVICE Irp down, so I
can see I might have to change the order we have in place today but
then my question is:
Would the MS iSCSI initiator then cancel those stuck I/Os and complete
those IRPs back to us immediately when it receives the
IRP_MN_REMOVE_DEVICE ?
If the answer is yes then the ordering is what is causing our 4 minutes
wait problem. I’d like some confirmation as I do not have access to
the MS iSCSI initiator code.
Thank you for your time.
Thierry
NTDEV is sponsored by OSR
Visit the list online at:
http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at
> http:</http:></http:></http:>
Thank you for your ideas. My original question was more specific though:
Would the MS iSCSI initiator then cancel those stuck I/Os and complete those
IRPs back to us immediately when it receives the IRP_MN_REMOVE_DEVICE ?
Let’s say the iSCSI initiator is waiting for responses to its sent I/Os and those will never come back. Instead of suffering the TCP timeout value (whatever the value may be), if it gets an IRP_MN_REMOVE_DEVICE does it take action right away to cleanup and return all those waited upon IRPs ?