After my driver hibernates, the userspace program that was talking to it
is no longer talking to it on restore. My guess is that this is expected
behaviour, and my userspace code just needs to re-open the interface. Is
this correct?
Thanks
James
If the driver doesn’t handle hybernation request correctly, it may get force-unloaded/reloaded, thus the app handle will be invalidated.
If it’s a stor miniport, you need to have ScsiRestartAdapter handler in your HwStorAdapterControl function, even though it will be doing nothing.
Which driver (model) force unloads a driver if it does not support hiber?
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Friday, March 13, 2009 10:09 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] userspace code talking to driver after hibernate
If the driver doesn’t handle hybernation request correctly, it may get force-unloaded/reloaded, thus the app handle will be invalidated.
If it’s a stor miniport, you need to have ScsiRestartAdapter handler in your HwStorAdapterControl function, even though it will be doing nothing.
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
>Which driver (model) force unloads a driver if it does not support hiber?
For example, I’ve seen that for WDM drivers for USB devices under XP. Unless you follow very strict sequence of forwarding/completing Sx IRPs and sending Dx IRPs (found very much empirically), your driver would get SURPRISE_REMOVAL/REMOVE_DEVICE on wakeup, or just won’t work while still there.
Storport miniport, if it doesn’t return ScsiRestartAdapter code in the array of supported codes, will get a strange (legacy-style?) HwStorFindAdapter callback during wakeup, on DISPATCH_LEVEL (as opposed to PASSIVE_LEVEL it’s normally called). Because the OP seems to write a storminiport, this may be the cause of his problem.
You are linking 2 distinctly different behaviors and cause and effect. Yes, you need to implement power policy correctly so that it will continue working after resume. Not implementing power correctly does not necessarily mean you will get unloaded, that really depends on what you are trying to do to the underlying device (that you should not be doing if you had implemented power correctly) when you are in low power and the bus driver that supports the device. In the usb case, it could be that it doesn’t like what you are doing so it is popping you off the bus. It could be your device itself is misbehaving and the same thing (surprise removal) occurs. There is no generic policy that says “ooh, this driver didn’t implement power properly, let’s unload it now (or later)”
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Friday, March 13, 2009 10:38 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] userspace code talking to driver after hibernate
Which driver (model) force unloads a driver if it does not support hiber?
For example, I’ve seen that for WDM drivers for USB devices under XP. Unless you follow very strict sequence of forwarding/completing Sx IRPs and sending Dx IRPs (found very much empirically), your driver would get SURPRISE_REMOVAL/REMOVE_DEVICE on wakeup, or just won’t work while still there.
Storport miniport, if it doesn’t return ScsiRestartAdapter code in the array of supported codes, will get a strange (legacy-style?) HwStorFindAdapter callback during wakeup, on DISPATCH_LEVEL (as opposed to PASSIVE_LEVEL it’s normally called). Because the OP seems to write a storminiport, this may be the cause of his problem.
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
>
If the driver doesn’t handle hybernation request correctly, it may get
force-unloaded/reloaded, thus the app handle will be invalidated.If it’s a stor miniport, you need to have ScsiRestartAdapter handler
in
your HwStorAdapterControl function, even though it will be doing
nothing.
The device with the interface is not a miniport driver, but it is in the
hibernation/dump/pagefile path as it is the bus driver for a scsiport
device.
All I’m really asking is is it the expected behaviour that the interface
that my userspace program has open gets closed on hibernate, and the
userspace program is expected to reopen it on resume, or is there
something I need to do to keep it open.
Is there a document somewhere that describes the correct way to handle
this?
Thanks
James
Again, did you make sure your PDO for storage stack doesn’t have DO_POWER_PAGABLE flag? Check !devstack in the debugger.
And I’m not really sure scsiport model supports retaining the miniport during hibernation; it was designed for NT, after all. Use storport model.
>
Again, did you make sure your PDO for storage stack doesn’t have
DO_POWER_PAGABLE flag? Check !devstack in the debugger.
Yes. I did make that mistake earlier but of course hibernate completely
doesn’t work when that flag is set (as do a bunch of other things not
work).
And I’m not really sure scsiport model supports retaining the miniport
during hibernation; it was designed for NT, after all. Use storport
model.
Storport doesn’t exist under XP, so of course scsiport hibernate works.
I will be writing a storport driver to replace the scsiport driver once
things have settled down a bit, but scsiport was the fastest way to make
sure the single driver works right across the MS family.
Maintaining both versions will suck a bit but once it’s stable it
shouldn’t require a lot of work - the scsiport driver is pretty small.
As a testing exercise (eg lets see how difficult this will be…) I
converted my scsiport driver to storport a while back and it only took a
few hours to get something running, so doing it properly should only be
a days work or so.
James
Wow there James. STORPORT does not exist under XP? Since when? One of the
last things I did for Seagate before their layoff, was to test LSI’s
STORPORT drivers on XP and Server 2003.
–
The personal opinion of
Gary G. Little
“James Harper” wrote in message
news:xxxxx@ntdev…
>
> Again, did you make sure your PDO for storage stack doesn’t have
> DO_POWER_PAGABLE flag? Check !devstack in the debugger.
Yes. I did make that mistake earlier but of course hibernate completely
doesn’t work when that flag is set (as do a bunch of other things not
work).
> And I’m not really sure scsiport model supports retaining the miniport
> during hibernation; it was designed for NT, after all. Use storport
model.
>
Storport doesn’t exist under XP, so of course scsiport hibernate works.
I will be writing a storport driver to replace the scsiport driver once
things have settled down a bit, but scsiport was the fastest way to make
sure the single driver works right across the MS family.
Maintaining both versions will suck a bit but once it’s stable it
shouldn’t require a lot of work - the scsiport driver is pretty small.
As a testing exercise (eg lets see how difficult this will be…) I
converted my scsiport driver to storport a while back and it only took a
few hours to get something running, so doing it properly should only be
a days work or so.
James
As far as I know, StorPort is not available for XP 32 bit but it is for
64.
“Gary G. Little”
Sent by: xxxxx@lists.osr.com
03/16/2009 01:03 PM
Please respond to
“Windows System Software Devs Interest List”
To
“Windows System Software Devs Interest List”
cc
Subject
Re:[ntdev] userspace code talking to driver after hibernate
Wow there James. STORPORT does not exist under XP? Since when? One of the
last things I did for Seagate before their layoff, was to test LSI’s
STORPORT drivers on XP and Server 2003.
–
The personal opinion of
Gary G. Little
“James Harper” wrote in message
news:xxxxx@ntdev…
>
> Again, did you make sure your PDO for storage stack doesn’t have
> DO_POWER_PAGABLE flag? Check !devstack in the debugger.
Yes. I did make that mistake earlier but of course hibernate completely
doesn’t work when that flag is set (as do a bunch of other things not
work).
> And I’m not really sure scsiport model supports retaining the miniport
> during hibernation; it was designed for NT, after all. Use storport
model.
>
Storport doesn’t exist under XP, so of course scsiport hibernate works.
I will be writing a storport driver to replace the scsiport driver once
things have settled down a bit, but scsiport was the fastest way to make
sure the single driver works right across the MS family.
Maintaining both versions will suck a bit but once it’s stable it
shouldn’t require a lot of work - the scsiport driver is pretty small.
As a testing exercise (eg lets see how difficult this will be…) I
converted my scsiport driver to storport a while back and it only took a
few hours to get something running, so doing it properly should only be
a days work or so.
James
—
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
>As far as I know, StorPort is not available for XP 32 bit but it is for
64.
And that’s because XP 64 bit is not XP at all, but just Win2003 in client disguise.
> Wow there James. STORPORT does not exist under XP? Since when?
It never existed there.
This is, BTW, the reason why Hyper-V’s virtual SCSI (storvsc.sys) does not work on XP. It is based on storport.
last things I did for Seagate before their layoff, was to test LSI’s
STORPORT drivers on XP
Maybe the idea was to copy the stortport.sys file from 2003 to XP?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com