USB card overcurrent problems...

[Barry Bouwsma]

[Drop hostname part of IPv6-only address above to obtain IPv4-capable e-mail,
 or just drop me from the recipients and I'll catch up from the archives]


Hello every last one of you,

First, before I spout off in the wrong forum, is there a better or preferred
location for USB-hardware-related questions like that which follows, akin to
the firewire list?


Okay, the question:  I have two cards with USB2.0 awareness, used for their
USB 1.x capability under FreeBSD 4.x.  One of them, a UHCI card, works just
fine, but the other one, an OHCI card, out-of-the-box exhibits problems.
Chipset is identified in dmesg as NEC uPD 9210 USB controller.

What happens, when I put it in a machine that it doesn't promptly wedge
at boot or soon afterwards, is that the uhub/ohci USB codes from 4.5-RC up
to 4.7 of last December (and now even recent 4.9-prerelease codes; haven't
tried the NetBSD codes they originate from) result in the internal hub going
dead (being disabled) when a bus-powered external USB2 hub device is
connected to it -- the other card (UHCI) has no problems with repeated
attach/detaches of this external hub.  There is no obvious problem when
connecting a self-powered device like that external hub with wall wart, or
an external hard drive.

Observation of the power indicator on the external hub shows that at time
of attachment, it lights very briefly and then immediately goes out, and
repeated unplug/re-plugging of the USB cable results in no further activity.

Adding copious debuggery to the kernel indicates that at time of connecting
the hub, the status of the internal port changes to unpowered and the
change variable has the overcurrent bit set.

Assuming that I don't have a truly wimpy piece of hardware (I haven't tried
it under any non-*BSD OSen), it should durn well be able to power this hub,
but perhaps the power-on surge of current into the filter capacitors is
triggering this (temporary?) overcurrent indication.

In fact, I was able to get the power indicator to come on and stay lit on
the external hub by checking for an overcurrent condition in uhub.c, and
then clearing the bit and re-applying power.  Not 100% reliably, but later
hacking (this evening) seems to have improved that, at the risk of ignoring a
Real Overcurrent indication.

What would be the proper changes to the code, after testing for such an
overcurrent condition, in order to safely reapply power until such condition
clears?  Adding a delay somewhere?  Limiting the number of times I try to
re-apply power before bailing?  (This last boot took some 5 or 6 tries
until it came up okay in a tight loop)

(There are comments in the source, imported from NetBSD, that some work-
arounds for an overcurrent problem have been applied, but those did not
seem to make any difference to me.  Also, as noted, I haven't yet tried
NetBSD from which these workarounds came, to see if there may be any not-
yet-imported fixes that make my device work.)

Also, I found that when applying the power within the test for overcurrent,
that clearing the overcurrent change did not necessarily re-enable the
interrupts, so I added that test to the routine that applies power, if
that's safe to do.

I'm probably not describing things well, but I'm positive my hacks aren't
at all proper, so I'd rather learn the right way to handle this case before
explaining where I run into problems.


And, I'll have more USB-related questions later, so pointers to the proper
place for those would be appreciated, if this list isn't it.


Thanks,
Barry Bouwsma