Storport Miniport: Device hot removal

Nirranjan_K · November 12, 2010, 6:12am

When a device is hot removed during IOs, can someone comment which is the correct sequence of steps Storport miniport driver should follow.

Change Internal state, so that new SRBs for the device will be returned with SRB_STATUS_NO_DEVICE in HwstartIO() itself
Call StorPortNotification(BusChangeDetected…) to rescan the bus where the device was connected before removal
Complete pending SRBs with appropriate SRB_STATUS. (Not sure what is correct SRB_STATUS that has to used. )

Thanks,
nirranjan

Nirranjan_K · November 12, 2010, 6:15am

In Step 1, I meant miniport driver’s internal state

-nirranjan

OSR_Community_User · November 12, 2010, 12:57pm

You would first indicate that there was a bus change detected before starting to fail requests. This will trigger the PnP Manager to see that there is a surprise removal and start the cleanup on its end.

–Mark Cariddi
OSR Open Systems Resources, Inc.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Friday, November 12, 2010 6:11 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Storport Miniport: Device hot removal

When a device is hot removed during IOs, can someone comment which is the correct sequence of steps Storport miniport driver should follow.

Change Internal state, so that new SRBs for the device will be returned with SRB_STATUS_NO_DEVICE in HwstartIO() itself
Call StorPortNotification(BusChangeDetected…) to rescan the bus where the device was connected before removal
Complete pending SRBs with appropriate SRB_STATUS. (Not sure what is correct SRB_STATUS that has to used. )

Thanks,
nirranjan

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Mark_Roddy · November 12, 2010, 2:56pm

Why? What are you supposed to do with the requests for devices that
don’t exist? Pile them onto the adapter? if you know the target is
gone, why not fail the request in buildio or startio?

Mark Roddy

On Fri, Nov 12, 2010 at 12:57 PM, Mark Cariddi wrote:
> You would first indicate that there was a bus change detected before starting to fail requests. ? This will trigger the PnP Manager to see that there is a surprise removal and start the cleanup on its end.
>
> --Mark Cariddi
> OSR Open Systems Resources, Inc.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
> Sent: Friday, November 12, 2010 6:11 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Storport Miniport: Device hot removal
>
> When a device is hot removed during IOs, can someone comment which is the correct sequence of steps Storport miniport driver should follow.
>
> 1. Change Internal state, so that new SRBs for the device will be returned with SRB_STATUS_NO_DEVICE in HwstartIO() itself
>
> 2. Call StorPortNotification(BusChangeDetected…) to rescan the bus where the device was connected before removal
>
> 3. Complete pending SRBs with appropriate SRB_STATUS. (Not sure what is correct SRB_STATUS that has to used. )
>
> Thanks,
> nirranjan
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

OSR_Community_User · November 12, 2010, 3:14pm

I believe that you want to get the PnP Manager into this early so that it is indicating to all devices involved that the device is going away so that they can stop sending requests to you. Once you get them out of the picture, then you can deal with the requests that were in the pipeline to you and your queues. Just seems cleaner to me…

–Mark Cariddi
OSR Open Systems Resources, Inc.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Friday, November 12, 2010 2:56 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Storport Miniport: Device hot removal

Why? What are you supposed to do with the requests for devices that don’t exist? Pile them onto the adapter? if you know the target is gone, why not fail the request in buildio or startio?

Mark Roddy

On Fri, Nov 12, 2010 at 12:57 PM, Mark Cariddi wrote:
> You would first indicate that there was a bus change detected before starting to fail requests. ? This will trigger the PnP Manager to see that there is a surprise removal and start the cleanup on its end.
>
> --Mark Cariddi
> OSR Open Systems Resources, Inc.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@yahoo.com
> Sent: Friday, November 12, 2010 6:11 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Storport Miniport: Device hot removal
>
> When a device is hot removed during IOs, can someone comment which is the correct sequence of steps Storport miniport driver should follow.
>
> 1. Change Internal state, so that new SRBs for the device will be
> returned with SRB_STATUS_NO_DEVICE in HwstartIO() itself
>
> 2. Call StorPortNotification(BusChangeDetected…) to rescan the bus
> where the device was connected before removal
>
> 3. Complete pending SRBs with appropriate SRB_STATUS. (Not sure what
> is correct SRB_STATUS that has to used. )
>
> Thanks,
> nirranjan
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Mark_Roddy · November 12, 2010, 4:34pm

Ok - my experience with this spans about 10 years of work, and for
both scsi and storport the earlier you start indicating errors to both
the port driver and the class drivers above you, the better. So, in my
opinion, you do both as soon as you know the target is gone.

Which, on reflection, is the same thing. You know a disk is gone, you
indicate to the port driver that it should rescan, and you flunk
requests with the appropriate status. What I wouldn’t do is wait for
the rescan to start flunking incoming requests. In stress testing
situations disk pulls are horrendous, and the only way to get the
class driver to STFU is to start screaming back at it that the damn
disk is gone as soon as possible. Also if it isn’t a class driver
above you but instead some multipath or software raid driver, telling
it about the error condition ASAP is again the best policy.

Mark Roddy

On Fri, Nov 12, 2010 at 3:14 PM, Mark Cariddi wrote:
> I believe that you want to get the PnP Manager into this early so that it is indicating to all devices involved that the device is going away so that they can stop sending requests to you. ? ?Once you get them out of the picture, then you can deal with the requests that were in the pipeline to you and your queues. ? ?Just seems cleaner to me…
>
> --Mark Cariddi
> OSR Open Systems Resources, Inc.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
> Sent: Friday, November 12, 2010 2:56 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Storport Miniport: Device hot removal
>
> Why? What are you supposed to do with the requests for devices that don’t exist? Pile them onto the adapter? if you know the target is gone, why not fail the request in buildio or startio?
>
> Mark Roddy
>
>
>
> On Fri, Nov 12, 2010 at 12:57 PM, Mark Cariddi wrote:
>> You would first indicate that there was a bus change detected before starting to fail requests. ? This will trigger the PnP Manager to see that there is a surprise removal and start the cleanup on its end.
>>
>> --Mark Cariddi
>> OSR Open Systems Resources, Inc.
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of
>> xxxxx@yahoo.com
>> Sent: Friday, November 12, 2010 6:11 AM
>> To: Windows System Software Devs Interest List
>> Subject: [ntdev] Storport Miniport: Device hot removal
>>
>> When a device is hot removed during IOs, can someone comment which is the correct sequence of steps Storport miniport driver should follow.
>>
>> 1. Change Internal state, so that new SRBs for the device will be
>> returned with SRB_STATUS_NO_DEVICE in HwstartIO() itself
>>
>> 2. Call StorPortNotification(BusChangeDetected…) to rescan the bus
>> where the device was connected before removal
>>
>> 3. Complete pending SRBs with appropriate SRB_STATUS. (Not sure what
>> is correct SRB_STATUS that has to used. )
>>
>> Thanks,
>> nirranjan
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

Nirranjan_K · November 12, 2010, 8:06pm

Thanks Mark Cariddi and Mark Roddy.

I will explain my problem more in detail. I have MPIO above Storport. When device is removed I do the following

Call StorportNotification(BusChangeDetected,…)
Complete the pending SRBs and new incoming SRBs for the removed device with SRB_STATUS_NO_DEVICE without waiting for entire bus rescan process to complete.

This causes the Storport to detect device is removed and MPIO to detect one of the path is gone. Which is correct and expected. Only problem is the IO Application complains that it did not receive completion for one of it read/write command.

One of SRB completed with SRB_STATUS_NO_DEVICE is some how lost before it reaches the IO App.( Storport miniport doesnt get SRB_FUNCTION_LUN_RESET, meaning no SRB is not pending with miniport. i.e all SRBs are completed for the device)

-nirranjan

Mark_Roddy · November 13, 2010, 10:00am

Hopefully you are not using StorPortCompleteRequest. Unless the
storage port driver team has repaired this interface, it has problems
and should be avoided. One of the symptoms of its malfunction is
missing or duplicate SRBs.

Mark Roddy

On Fri, Nov 12, 2010 at 8:05 PM, wrote:
> SRB_STATUS_NO_DEVICE

Jake_Oshins · November 13, 2010, 5:41pm

I agree with Mark Roddy. Surprise removal is fundamentally asynchronous,
and Mark Cariddi, you’re suggesting that it should be somehow synchronized.
That’s not really possible, and likely to introduce odd behavior, if not
deadlocks.

Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.

“Mark Roddy” wrote in message news:xxxxx@ntdev…

Ok - my experience with this spans about 10 years of work, and for
both scsi and storport the earlier you start indicating errors to both
the port driver and the class drivers above you, the better. So, in my
opinion, you do both as soon as you know the target is gone.

Which, on reflection, is the same thing. You know a disk is gone, you
indicate to the port driver that it should rescan, and you flunk
requests with the appropriate status. What I wouldn’t do is wait for
the rescan to start flunking incoming requests. In stress testing
situations disk pulls are horrendous, and the only way to get the
class driver to STFU is to start screaming back at it that the damn
disk is gone as soon as possible. Also if it isn’t a class driver
above you but instead some multipath or software raid driver, telling
it about the error condition ASAP is again the best policy.

Mark Roddy

On Fri, Nov 12, 2010 at 3:14 PM, Mark Cariddi wrote:
> I believe that you want to get the PnP Manager into this early so that it
> is indicating to all devices involved that the device is going away so
> that they can stop sending requests to you. Once you get them out of
> the picture, then you can deal with the requests that were in the pipeline
> to you and your queues. Just seems cleaner to me…
>
> --Mark Cariddi
> OSR Open Systems Resources, Inc.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
> Sent: Friday, November 12, 2010 2:56 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Storport Miniport: Device hot removal
>
> Why? What are you supposed to do with the requests for devices that don’t
> exist? Pile them onto the adapter? if you know the target is gone, why not
> fail the request in buildio or startio?
>
> Mark Roddy
>
>
>
> On Fri, Nov 12, 2010 at 12:57 PM, Mark Cariddi wrote:
>> You would first indicate that there was a bus change detected before
>> starting to fail requests. This will trigger the PnP Manager to see
>> that there is a surprise removal and start the cleanup on its end.
>>
>> --Mark Cariddi
>> OSR Open Systems Resources, Inc.
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of
>> xxxxx@yahoo.com
>> Sent: Friday, November 12, 2010 6:11 AM
>> To: Windows System Software Devs Interest List
>> Subject: [ntdev] Storport Miniport: Device hot removal
>>
>> When a device is hot removed during IOs, can someone comment which is the
>> correct sequence of steps Storport miniport driver should follow.
>>
>> 1. Change Internal state, so that new SRBs for the device will be
>> returned with SRB_STATUS_NO_DEVICE in HwstartIO() itself
>>
>> 2. Call StorPortNotification(BusChangeDetected…) to rescan the bus
>> where the device was connected before removal
>>
>> 3. Complete pending SRBs with appropriate SRB_STATUS. (Not sure what
>> is correct SRB_STATUS that has to used. )
>>
>> Thanks,
>> nirranjan
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Nirranjan_K · November 14, 2010, 10:03am

I am not using StorPortCompleteRequest(). Instead using StoPortNotification(RequestComplete,…) for every SRBs received.

Is there a need to call StoPortPauseDevice()/StorPortPause() during device removal to stop Storport from pumping in IOs to the removed device, when StorPortNotification(BusChangeDetected…) is called?

-nirranjan

OSR_Community_User · November 15, 2010, 9:53am

I did not suggest that it was synchronized. All I said was that you should notify the Bus Driver as soon as possible when you detect the device is gone.

–Mark Cariddi
OSR Open Systems Resources, Inc.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins
Sent: Saturday, November 13, 2010 5:41 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Storport Miniport: Device hot removal

I agree with Mark Roddy. Surprise removal is fundamentally asynchronous, and Mark Cariddi, you’re suggesting that it should be somehow synchronized.
That’s not really possible, and likely to introduce odd behavior, if not deadlocks.

Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.

“Mark Roddy” wrote in message news:xxxxx@ntdev…

Ok - my experience with this spans about 10 years of work, and for both scsi and storport the earlier you start indicating errors to both the port driver and the class drivers above you, the better. So, in my opinion, you do both as soon as you know the target is gone.

Which, on reflection, is the same thing. You know a disk is gone, you indicate to the port driver that it should rescan, and you flunk requests with the appropriate status. What I wouldn’t do is wait for the rescan to start flunking incoming requests. In stress testing situations disk pulls are horrendous, and the only way to get the class driver to STFU is to start screaming back at it that the damn disk is gone as soon as possible. Also if it isn’t a class driver above you but instead some multipath or software raid driver, telling it about the error condition ASAP is again the best policy.

Mark Roddy

On Fri, Nov 12, 2010 at 3:14 PM, Mark Cariddi wrote:
> I believe that you want to get the PnP Manager into this early so that
> it is indicating to all devices involved that the device is going away so
> that they can stop sending requests to you. Once you get them out of
> the picture, then you can deal with the requests that were in the pipeline
> to you and your queues. Just seems cleaner to me…
>
> --Mark Cariddi
> OSR Open Systems Resources, Inc.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
> Sent: Friday, November 12, 2010 2:56 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Storport Miniport: Device hot removal
>
> Why? What are you supposed to do with the requests for devices that
> don’t exist? Pile them onto the adapter? if you know the target is
> gone, why not fail the request in buildio or startio?
>
> Mark Roddy
>
>
>
> On Fri, Nov 12, 2010 at 12:57 PM, Mark Cariddi wrote:
>> You would first indicate that there was a bus change detected before
>> starting to fail requests. This will trigger the PnP Manager to see
>> that there is a surprise removal and start the cleanup on its end.
>>
>> --Mark Cariddi
>> OSR Open Systems Resources, Inc.
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of
>> xxxxx@yahoo.com
>> Sent: Friday, November 12, 2010 6:11 AM
>> To: Windows System Software Devs Interest List
>> Subject: [ntdev] Storport Miniport: Device hot removal
>>
>> When a device is hot removed during IOs, can someone comment which is
>> the correct sequence of steps Storport miniport driver should follow.
>>
>> 1. Change Internal state, so that new SRBs for the device will be
>> returned with SRB_STATUS_NO_DEVICE in HwstartIO() itself
>>
>> 2. Call StorPortNotification(BusChangeDetected…) to rescan the bus
>> where the device was connected before removal
>>
>> 3. Complete pending SRBs with appropriate SRB_STATUS. (Not sure what
>> is correct SRB_STATUS that has to used. )
>>
>> Thanks,
>> nirranjan
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Mark_Roddy · November 15, 2010, 10:07am

I think we are in violent agreement. I just wanted to make clear that
there is no particular ordering and that the miniport needs to inform
everyone of the missing disk ASAP or risk having the system wedge
itself for extended periods of time under heavy load testing or
reallife conditions.

Mark Roddy

On Mon, Nov 15, 2010 at 9:52 AM, Mark Cariddi wrote:
> I did not suggest that it was synchronized. ? All I said was that you should notify the Bus Driver as soon as possible when you detect the device is gone.
>
> --Mark Cariddi
> OSR Open Systems Resources, Inc.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins
> Sent: Saturday, November 13, 2010 5:41 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Storport Miniport: Device hot removal
>
> I agree with Mark Roddy. ?Surprise removal is fundamentally asynchronous, and Mark Cariddi, you’re suggesting that it should be somehow synchronized.
> That’s not really possible, and likely to introduce odd behavior, if not deadlocks.
>
>
>
> Jake Oshins
> Hyper-V I/O Architect
> Windows Kernel Group
>
> This post implies no warranties and confers no rights.
>
> --------------------------------------------------------------
> “Mark Roddy” ?wrote in message news:xxxxx@ntdev…
>
> Ok - my experience with this spans about 10 years of work, and for both scsi and storport the earlier you start indicating errors to both the port driver and the class drivers above you, the better. So, in my opinion, you do both as soon as you know the target is gone.
>
> Which, on reflection, is the same thing. You know a disk is gone, you indicate to the port driver that it should rescan, and you flunk requests with the appropriate status. What I wouldn’t do is wait for the rescan to start flunking incoming requests. In stress testing situations disk pulls are horrendous, and the only way to get the class driver to STFU is to start screaming back at it that the damn disk is gone as soon as possible. Also if it isn’t a class driver above you but instead some multipath or software raid driver, telling it about the error condition ASAP is again the best policy.
>
> Mark Roddy
>
>
>
> On Fri, Nov 12, 2010 at 3:14 PM, Mark Cariddi wrote:
>> I believe that you want to get the PnP Manager into this early so that
>> it is indicating to all devices involved that the device is going away so
>> that they can stop sending requests to you. ? ?Once you get them out of
>> the picture, then you can deal with the requests that were in the pipeline
>> to you and your queues. ? ?Just seems cleaner to me…
>>
>> --Mark Cariddi
>> OSR Open Systems Resources, Inc.
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
>> Sent: Friday, November 12, 2010 2:56 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re: [ntdev] Storport Miniport: Device hot removal
>>
>> Why? What are you supposed to do with the requests for devices that
>> don’t exist? Pile them onto the adapter? if you know the target is
>> gone, why not fail the request in buildio or startio?
>>
>> Mark Roddy
>>
>>
>>
>> On Fri, Nov 12, 2010 at 12:57 PM, Mark Cariddi wrote:
>>> You would first indicate that there was a bus change detected before
>>> starting to fail requests. ? This will trigger the PnP Manager to see
>>> that there is a surprise removal and start the cleanup on its end.
>>>
>>> --Mark Cariddi
>>> OSR Open Systems Resources, Inc.
>>>
>>> -----Original Message-----
>>> From: xxxxx@lists.osr.com
>>> [mailto:xxxxx@lists.osr.com] On Behalf Of
>>> xxxxx@yahoo.com
>>> Sent: Friday, November 12, 2010 6:11 AM
>>> To: Windows System Software Devs Interest List
>>> Subject: [ntdev] Storport Miniport: Device hot removal
>>>
>>> When a device is hot removed during IOs, can someone comment which is
>>> the correct sequence of steps Storport miniport driver should follow.
>>>
>>> 1. Change Internal state, so that new SRBs for the device will be
>>> returned with SRB_STATUS_NO_DEVICE in HwstartIO() itself
>>>
>>> 2. Call StorPortNotification(BusChangeDetected…) to rescan the bus
>>> where the device was connected before removal
>>>
>>> 3. Complete pending SRBs with appropriate SRB_STATUS. (Not sure what
>>> is correct SRB_STATUS that has to used. )
>>>
>>> Thanks,
>>> nirranjan
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>