[time-nuts] LH Z3801 and XP stalling

jimlux jimlux at earthlink.net
Fri Dec 16 11:08:12 EST 2016

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 at 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 at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

More information about the time-nuts mailing list