USB enumeration timeout?
in [Device Drivers]
|
From: Hannes on 24 Nov 2009 11:11 Hi Tim, Thanks for your reply. My understandings of USB are not to-notch, why my questions may seem silly at times. My take from this discussion is that there is no clear requirement stated in Windows, why we'll have to assume the USB spec sets the startup time requirement. Dan Ellis say the maximum time is 1s, while you say 500ms. Either way, we will have to heavily re-architect our USB device and/or drivers in order to solve our current issues, which occur due to the driver unload after resume. Again, thanks a lot for your replies and efforts in explaining these things to me. Thanks! / Hannes.
From: Hannes on 27 Nov 2009 10:58 "Dan Ellis" wrote: > To be honest, I would have thought that Windows should _always_ be > unloading your driver if it's cut the power to it and reenumerated it > (which it will have done) when coming our of standby, although I must > admit I have seen the behaviour you are describing where it somehow > knows that your device is still similar enough when it's reenumerated > to have the same driver loaded - I would call this a dangerous > assumption! Dan, to be honest - wouldn't there on any given PC be A LOT of devices unloading/relaoding (with the accompanying bing-bong sounds) every time you sleep/resume a regular PC? Many devices inside a PC are USB based, and they should, just like our built-in USB device, get unloaded upon sleep...? There is some logic in Windows that today, and likely also in the future, decided to keep the drivers loaded in memory - and we would absolutely LOVE to figure out the requirement for this, so that also our device can enjoy the same treatment. / Hannes.
From: Doron Holan [MSFT] on 30 Nov 2009 13:34 nearly all embedded usb products in a laptop stay connected on return from low power and do not fall off of the bus. there is no logic in windows to keep drivers loaded in memory (or their associated device stacks which is the underlying issue) on return from resume if their devices are gone. you don't hear the device removal sounds b/c the devices are not being removed. d -- This posting is provided "AS IS" with no warranties, and confers no rights. "Hannes" <hannes.news(a)newsgroup.nospam> wrote in message news:094FAB85-8F91-445E-B296-F6D673697DDD(a)microsoft.com... > "Dan Ellis" wrote: >> To be honest, I would have thought that Windows should _always_ be >> unloading your driver if it's cut the power to it and reenumerated it >> (which it will have done) when coming our of standby, although I must >> admit I have seen the behaviour you are describing where it somehow >> knows that your device is still similar enough when it's reenumerated >> to have the same driver loaded - I would call this a dangerous >> assumption! > > Dan, to be honest - wouldn't there on any given PC be A LOT of devices > unloading/relaoding (with the accompanying bing-bong sounds) every time > you > sleep/resume a regular PC? Many devices inside a PC are USB based, and > they > should, just like our built-in USB device, get unloaded upon sleep...? > > There is some logic in Windows that today, and likely also in the future, > decided to keep the drivers loaded in memory - and we would absolutely > LOVE > to figure out the requirement for this, so that also our device can enjoy > the > same treatment. > > / Hannes.
From: Hannes on 1 Dec 2009 05:55 Excuse me gentlemen, for I must be having a blond moment here. 1. Let's assume that while the PC sleeps, the embedded USB devices are completely powered off. Dead. Supply voltage, USB bus voltage, everything. 2. Someone then presses the power button to resume the PC. 3. All embedded USB devices are powered on. 4. Windows resumes 5. At some point, Windows, or each device stack, checks if a device is still present. I see 2 possible outcomes: > 5a. The device is present (i.e. speaks USB), and the driver remains loaded. > 5b. The device is NOT present (i.e. does not respond to USB communication) and its driver gets unloaded. Bing-bong. On Windows 7, what is the minimum time step-3-to-step-5 ? (i.e. for how long can a USB device boot without getting unloaded?) Please let me know if: - I have gotten it all completely backwards - we should direct this question to a different newsgroup or forum - we should open a support case to get this time figure Thanks a lot for your efforts this far. / Hannes.
From: Tim Roberts on 2 Dec 2009 23:17
Hannes <hannes.news(a)newsgroup.nospam> wrote: > >1. Let's assume that while the PC sleeps, the embedded USB devices are >completely powered off. Dead. Supply voltage, USB bus voltage, everything. >2. Someone then presses the power button to resume the PC. >3. All embedded USB devices are powered on. >4. Windows resumes >5. At some point, Windows, or each device stack, checks if a device is still >present. >I see 2 possible outcomes: >> 5a. The device is present (i.e. speaks USB), and the driver remains loaded. >> 5b. The device is NOT present (i.e. does not respond to USB communication) and its driver gets unloaded. Bing-bong. > >On Windows 7, what is the minimum time step-3-to-step-5 ? >(i.e. for how long can a USB device boot without getting unloaded?) You need to stop thinking like this, because the answer to this question is not useful. Just because you happen to get a time that works in Windows 7 does NOT mean, for example, that it will work in Vista or XP or Windows 8, or even Windows 7 SP1, or even Windows 7 with a different motherboard. Microsoft is never going to give you a number. It's not part of their contract. The FACT is that your allowable time lag is dictated very clearly in the USB specification. If you violate the specification, you are not USB compliant, whether or not your device happens to work in some circumstances on some releases of some operating systems. >Please let me know if: >- I have gotten it all completely backwards >- we should direct this question to a different newsgroup or forum >- we should open a support case to get this time figure I would argue for the first answer. -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc. |