As far as I know, you cannot *trick* MPIO into ignoring IRP_MN_REMOVE_DEVICE
which is what you want to do. When PnP attempts to remove the device, you
should not attempt to stop it.

When MPIO calls DsmRemovePending() you should do all the cleanup you require
and track the fact that the device (i.e. path) is about to be removed. Then
when DsmRemoveDevice() is called, you need to cleanup and remove the
structures within your DSM since it no longer exists, even if you think it
does.

Now, what do you mean by "disconnected" below? Are you referring to
physically disconnected or NT_STATUS DEVICE_NOT_CONNECTED (0xc000009d)?

What is the actual problem you want to resolve? (i.e. why do you want to
delay the removal of the device?)

~kenny

"Tomasz Kantecki" wrote in message
news:%23NUdSmmsHHA.3400@TK2MSFTNGP03.phx.gbl...
> Hi All,
>
> I am working on a DSM driver and I encountered problem to control MPIO
> path removal from driver in question. MPIO seems to ignore retry setting
> in DsmInterpretError() when it comes to path removal (i.e. disconnected).
> I also tried to return FAIL status in DsmRemoveDevice()/DsmRemovePath()
> functions but MPIO seems to ignore them and removes structures anyway.
> Ofcourse I understand that my code might be incorrect.
> Is it possible to delay path removal in MPIO from DSM driver level? If so
> then could you give me a hint on how to do it?
>
> Best regards,
> Tomasz Kantecki
>
>

Thanks for the answer.

I think the best way would be to describe desired functionality of my MPIO
driver:
- failover ASAP when some other paths are available
- wait some time before removing device when there is the only path left to
the device

I need this functionality as it happens with some FC cards that link may
reset itself in certain circumstances. When it happens and this is the only
path I might loose all devices. So all I want to do is to make MPIO more
tolerant and wait 20 seconds longer until link is up again. If it is not up
then it should proceed with adequate actions as it usually does.

I made some tests with MPIO and I found out one way to stop MPIO from
removing device for some time - it some kind of active wait in the driver.
Yet this solution is very awkward and may affect other threads&drivers in
the system. I need something better than this.

Regards
Tomasz


"Kenny Speer" wrote in message
news:545CCE5F-21EC-42CA-A64C-D952EB4AE2EA@microsoft.com...
> As far as I know, you cannot *trick* MPIO into ignoring
> IRP_MN_REMOVE_DEVICE which is what you want to do. When PnP attempts to
> remove the device, you should not attempt to stop it.
>
> When MPIO calls DsmRemovePending() you should do all the cleanup you
> require and track the fact that the device (i.e. path) is about to be
> removed. Then when DsmRemoveDevice() is called, you need to cleanup and
> remove the structures within your DSM since it no longer exists, even if
> you think it does.
>
> Now, what do you mean by "disconnected" below? Are you referring to
> physically disconnected or NT_STATUS DEVICE_NOT_CONNECTED (0xc000009d)?
>
> What is the actual problem you want to resolve? (i.e. why do you want to
> delay the removal of the device?)
>
> ~kenny
>
> "Tomasz Kantecki" wrote in message
> news:%23NUdSmmsHHA.3400@TK2MSFTNGP03.phx.gbl...
>> Hi All,
>>
>> I am working on a DSM driver and I encountered problem to control MPIO
>> path removal from driver in question. MPIO seems to ignore retry setting
>> in DsmInterpretError() when it comes to path removal (i.e. disconnected).
>> I also tried to return FAIL status in DsmRemoveDevice()/DsmRemovePath()
>> functions but MPIO seems to ignore them and removes structures anyway.
>> Ofcourse I understand that my code might be incorrect.
>> Is it possible to delay path removal in MPIO from DSM driver level? If so
>> then could you give me a hint on how to do it?
>>
>> Best regards,
>> Tomasz Kantecki
>>
>>
>

I see, but MPIO PDORemovePeriod is designed to handle this situation. You
are allowed to lose all paths to a device and the PseudoLUN will not be
destroyed until the expiration of PDORemovePeriod. You can simply increase
this to 60 seconds or so and you have that amount of time for a path to
arrive before your IO errors or the PDO is removed.

Also, you can change the LinkTimeout on the HBA to be the amount of time you
need. At the expiration of LinkTimeout the miniport will respond with
SELECTION_TIMEOUT and then PnP will attempt to remove the devices.

I don't recommend sleeping the thread or stalling the processor to your
20sec wait. I suppose you could also be sitting in an idle loop for 20 sec
before returning, but it seems that would cause you alot more pain than it's
worse.

Feel free to ping me offline if you like.

~kenny

"Tomasz Kantecki" wrote in message
news:udF$1p$tHHA.4916@TK2MSFTNGP04.phx.gbl...
> Thanks for the answer.
>
> I think the best way would be to describe desired functionality of my MPIO
> driver:
> - failover ASAP when some other paths are available
> - wait some time before removing device when there is the only path left
> to the device
>
> I need this functionality as it happens with some FC cards that link may
> reset itself in certain circumstances. When it happens and this is the
> only path I might loose all devices. So all I want to do is to make MPIO
> more tolerant and wait 20 seconds longer until link is up again. If it is
> not up then it should proceed with adequate actions as it usually does.
>
> I made some tests with MPIO and I found out one way to stop MPIO from
> removing device for some time - it some kind of active wait in the driver.
> Yet this solution is very awkward and may affect other threads&drivers in
> the system. I need something better than this.
>
> Regards
> Tomasz
>
>
> "Kenny Speer" wrote in message
> news:545CCE5F-21EC-42CA-A64C-D952EB4AE2EA@microsoft.com...
>> As far as I know, you cannot *trick* MPIO into ignoring
>> IRP_MN_REMOVE_DEVICE which is what you want to do. When PnP attempts to
>> remove the device, you should not attempt to stop it.
>>
>> When MPIO calls DsmRemovePending() you should do all the cleanup you
>> require and track the fact that the device (i.e. path) is about to be
>> removed. Then when DsmRemoveDevice() is called, you need to cleanup and
>> remove the structures within your DSM since it no longer exists, even if
>> you think it does.
>>
>> Now, what do you mean by "disconnected" below? Are you referring to
>> physically disconnected or NT_STATUS DEVICE_NOT_CONNECTED (0xc000009d)?
>>
>> What is the actual problem you want to resolve? (i.e. why do you want to
>> delay the removal of the device?)
>>
>> ~kenny
>>
>> "Tomasz Kantecki" wrote in message
>> news:%23NUdSmmsHHA.3400@TK2MSFTNGP03.phx.gbl...
>>> Hi All,
>>>
>>> I am working on a DSM driver and I encountered problem to control MPIO
>>> path removal from driver in question. MPIO seems to ignore retry setting
>>> in DsmInterpretError() when it comes to path removal (i.e.
>>> disconnected). I also tried to return FAIL status in
>>> DsmRemoveDevice()/DsmRemovePath() functions but MPIO seems to ignore
>>> them and removes structures anyway. Ofcourse I understand that my code
>>> might be incorrect.
>>> Is it possible to delay path removal in MPIO from DSM driver level? If
>>> so then could you give me a hint on how to do it?
>>>
>>> Best regards,
>>> Tomasz Kantecki
>>>
>>>
>>
>
>

Tried to reply to you, but your mail server bounced my gmail account.

"Tomasz Kantecki" wrote in message
news:udF$1p$tHHA.4916@TK2MSFTNGP04.phx.gbl...
> Thanks for the answer.
>
> I think the best way would be to describe desired functionality of my MPIO
> driver:
> - failover ASAP when some other paths are available
> - wait some time before removing device when there is the only path left
> to the device
>
> I need this functionality as it happens with some FC cards that link may
> reset itself in certain circumstances. When it happens and this is the
> only path I might loose all devices. So all I want to do is to make MPIO
> more tolerant and wait 20 seconds longer until link is up again. If it is
> not up then it should proceed with adequate actions as it usually does.
>
> I made some tests with MPIO and I found out one way to stop MPIO from
> removing device for some time - it some kind of active wait in the driver.
> Yet this solution is very awkward and may affect other threads&drivers in
> the system. I need something better than this.
>
> Regards
> Tomasz
>
>
> "Kenny Speer" wrote in message
> news:545CCE5F-21EC-42CA-A64C-D952EB4AE2EA@microsoft.com...
>> As far as I know, you cannot *trick* MPIO into ignoring
>> IRP_MN_REMOVE_DEVICE which is what you want to do. When PnP attempts to
>> remove the device, you should not attempt to stop it.
>>
>> When MPIO calls DsmRemovePending() you should do all the cleanup you
>> require and track the fact that the device (i.e. path) is about to be
>> removed. Then when DsmRemoveDevice() is called, you need to cleanup and
>> remove the structures within your DSM since it no longer exists, even if
>> you think it does.
>>
>> Now, what do you mean by "disconnected" below? Are you referring to
>> physically disconnected or NT_STATUS DEVICE_NOT_CONNECTED (0xc000009d)?
>>
>> What is the actual problem you want to resolve? (i.e. why do you want to
>> delay the removal of the device?)
>>
>> ~kenny
>>
>> "Tomasz Kantecki" wrote in message
>> news:%23NUdSmmsHHA.3400@TK2MSFTNGP03.phx.gbl...
>>> Hi All,
>>>
>>> I am working on a DSM driver and I encountered problem to control MPIO
>>> path removal from driver in question. MPIO seems to ignore retry setting
>>> in DsmInterpretError() when it comes to path removal (i.e.
>>> disconnected). I also tried to return FAIL status in
>>> DsmRemoveDevice()/DsmRemovePath() functions but MPIO seems to ignore
>>> them and removes structures anyway. Ofcourse I understand that my code
>>> might be incorrect.
>>> Is it possible to delay path removal in MPIO from DSM driver level? If
>>> so then could you give me a hint on how to do it?
>>>
>>> Best regards,
>>> Tomasz Kantecki
>>>
>>>
>>
>
>