On 12/16/16 6:33 AM, Chuck Harris wrote:
A customer's 'doze 7 computer got auto updated to 'doze 10,
and with that upgrade came a usb hub that timed out, turning
itself off.... the only problem was, the keyboard and
mouse were on that hub, leaving no way to signal the computer
to turn the hub back on.
That's a non-compliant hub. Part of the complexity in hub design is
that it's supposed to have the ability to "turn off (most) power to
downstream devices" and "turn off (most) power to hub", but still
trickle enough power through the tree that a leaf node can send the
"wakeup" message back up the tree.
Where the OS gets twisted around is that it has to infer the power
management state of that whole tree, and that is imperfect - partly it's
a problem in the USB spec - you can do perfectly legal things in terms
of connect/disconnect that cause changes in power management state of a
hub or node that seem not to propagate back up the tree, so the
controlling host has no idea what's going on, short of "turn the whole
thing on, enumerate, and then turn stuff off again".
My particular problems often come from USB devices that change their
personality (e.g. they're a Human Interface Device (HID - think mouse)
sometimes and a serial port sometimes, and mass storage sometimes).
It's not clear that the USB spec contemplates this, and it's really,
really clear that the folks writing software (particularly for Linux
drivers) handle it cleanly. This is a case where I've had much better
luck with Windows (7, in my case) than with *nix. I think it's a "mass
market" thing - there's many more Windows computers out there and USB
devices connected to Windows devices, so there's a bigger "test space".
It doesn't cost Microsoft very much to "get it right" - the USB power
management code is probably pretty small, and it really is distinct from
other functions, so they probably have a few people whose whole job is
fixing stuff like this.
All of the mobo mounted hubs I've run into (whether integrated into the
giant chip, or separate and distinct) do this correctly. Not all the
standalone hubs do it right. I suspect that there are some cheap and
cheerful parts out there that were designed a while back, and they keep
cropping up. I've got some older hubs (>10 years) that I got as
conference/trade show giveaways, and some do it right, and some do it
wrong. It's sort of like the whole "high power device" management
aspect - older devices sometimes get it wrong, and there's nothing in
the market place that stops someone from making a very cheap copy of an
older design and selling it.
There's no credible "USB device certification organization" that your $1
hub mfr is going to use - they'd probably just stamp it certified
whether it is or not.
Ultimately, the customer found that
if he unplugged the monitor, plug and pray would restore things.
For a while.
Probably not useful in that customer's case, but spending some time with
Device Manager and devcon would probably figure out what's going on.
devcon, in particular, can generate copious debug information about the
state of things. A day of systematic testing going through the various
sequences would probably nail it down.
-Chuck Harris
jimlux wrote:
On 12/15/16 7:08 PM, Chuck Harris wrote:
Sometimes, when one is doing a long run that goes past the
usual power save times, the USB port will shut itself off.
I believe that most motherboards have a setting in the BIOS
that controls the ability of the BIOS to power the USB port
down during quiet times.
More likely the OS configures the USB hardware. On Win 7 (but probably also
anything
from WinXP on, if not before) there's a whole bunch of command line tools (or
you can
use Device Manager) to deal with the incredible complex power state behavior of
USB
devices, and more particularly hubs.
devcon is the command line tool here
http://support.microsoft.com/kb/311272
More info at:
http://www.fixedbyvonnie.com/2013/11/fix-usb-root-hub-power-management-issue-windows-7/
and at:
http://support.microsoft.com/kb/817900
devcon is the command line tool here
http://support.microsoft.com/kb/311272
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
