Hi,
My device takes on 2 roles. The first role stems from not having the
firmware downloaded and running. The second role is it’s fully operational
mode with the firmware. Each of these roles has a different set of
descriptors (this is due to how the hardware works and for the most part
cannot be changed).
My problem is hibernation. When the system powers off it leaves with the
device playing the fully operational role. When it comes back from
hibernation it is playing the no-firmware role. Upon passing the power-up
IRP down to the USB stack, the USB stack queries the device for the device
descriptors as well as the configuration descriptors. It then thinks that
the device has been swapped during the low power state and marks the device
for removal. This causes all subsequent submissions of URB’s to return with
STATUS_DEVICE_NOT_CONNECTED, and also causes my driver to be unloaded,
eventually. If there is an open handle to the device before going into
hibernate things don’t go well when coming back (the driver will unload as
soon as the handle is closed).
Firstly, can anyone tell me exactly what the USB stack uses to determine if
the device is the same or not? Depending on what it is I may be able to
massage the firmware enough to make it work (I can change certain attributes
of the descriptors).
Secondly, is there another way I could stop the USB stack from giving me the
boot?
Thanks, Chris
Chris,
When the system comes back after hibernation, should it not load the
“no-firmware” driver? When hibernation is taking place, can’t your driver
set the context for the “no-firmware” driver to be used when the system
comes back up? For want of a better analogy, can you treat hibernation just
as you would treat a reboot?
Regards,
Sirish
-----Original Message-----
From: Chris Dore [mailto:xxxxx@connecttech.com]
Sent: Thursday, September 05, 2002 7:02 AM
To: NT Developers Interest List
Subject: [ntdev] Looking for some USB specifics
Hi,
My device takes on 2 roles. The first role stems from not having the
firmware downloaded and running. The second role is it’s fully operational
mode with the firmware. Each of these roles has a different set of
descriptors (this is due to how the hardware works and for the most part
cannot be changed).
My problem is hibernation. When the system powers off it leaves with the
device playing the fully operational role. When it comes back from
hibernation it is playing the no-firmware role. Upon passing the power-up
IRP down to the USB stack, the USB stack queries the device for the device
descriptors as well as the configuration descriptors. It then thinks that
the device has been swapped during the low power state and marks the device
for removal. This causes all subsequent submissions of URB’s to return with
STATUS_DEVICE_NOT_CONNECTED, and also causes my driver to be unloaded,
eventually. If there is an open handle to the device before going into
hibernate things don’t go well when coming back (the driver will unload as
soon as the handle is closed).
Firstly, can anyone tell me exactly what the USB stack uses to determine if
the device is the same or not? Depending on what it is I may be able to
massage the firmware enough to make it work (I can change certain attributes
of the descriptors).
Secondly, is there another way I could stop the USB stack from giving me the
boot?
Thanks, Chris
You are currently subscribed to ntdev as: xxxxx@vmware.com
To unsubscribe send a blank email to %%email.unsub%%
The problem is that the original “firmware” driver has not been unloaded
yet. When coming back from hibernation, the USB drivers try to unload the
“firmware” driver before loading the “no-firmware” driver. If there is an
open handle this unload will not occur. If there is no open handles then
yes it all works, the “firmware” driver unloads and the “non-firmware”
driver loads and starts just as a normal reboot would.
Chris
“Sirish Raghuram” wrote in message
news:xxxxx@ntdev…
>
> Chris,
>
> When the system comes back after hibernation, should it not load the
> “no-firmware” driver? When hibernation is taking place, can’t your driver
> set the context for the “no-firmware” driver to be used when the system
> comes back up? For want of a better analogy, can you treat hibernation
just
> as you would treat a reboot?
>
> Regards,
> Sirish
>
> -----Original Message-----
> From: Chris Dore [mailto:xxxxx@connecttech.com]
> Sent: Thursday, September 05, 2002 7:02 AM
> To: NT Developers Interest List
> Subject: [ntdev] Looking for some USB specifics
>
>
> Hi,
>
> My device takes on 2 roles. The first role stems from not having the
> firmware downloaded and running. The second role is it’s fully operational
> mode with the firmware. Each of these roles has a different set of
> descriptors (this is due to how the hardware works and for the most part
> cannot be changed).
> My problem is hibernation. When the system powers off it leaves with the
> device playing the fully operational role. When it comes back from
> hibernation it is playing the no-firmware role. Upon passing the power-up
> IRP down to the USB stack, the USB stack queries the device for the device
> descriptors as well as the configuration descriptors. It then thinks that
> the device has been swapped during the low power state and marks the
device
> for removal. This causes all subsequent submissions of URB’s to return
with
> STATUS_DEVICE_NOT_CONNECTED, and also causes my driver to be unloaded,
> eventually. If there is an open handle to the device before going into
> hibernate things don’t go well when coming back (the driver will unload as
> soon as the handle is closed).
>
> Firstly, can anyone tell me exactly what the USB stack uses to determine
if
> the device is the same or not? Depending on what it is I may be able to
> massage the firmware enough to make it work (I can change certain
attributes
> of the descriptors).
>
> Secondly, is there another way I could stop the USB stack from giving me
the
> boot?
>
> Thanks, Chris
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@vmware.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>