USB card overcurrent problems...

Barry Bouwsma freebsd-misuser at remove-NOSPAM-to-reply.NOSPAM.dyndns.dk
Tue Nov 4 21:02:40 PST 2003


[Drop my (IPv6-only) address when replying -- I'm offline too much, and I'm
 not even sure if all the ISPs I use let IPv4 mail through either]
[Sorry for being offline so long, and the delay in this reply...]


> > 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.

> Current protection and limiting is completely up to the card designer.
> The best that FreeBSD can do is getting informed if the card design
> allows it, but I almost never saw a card doing this.

The source has the following comment:

	/* Fiddle the No OverCurrent Protection bit to avoid chip bug. */
	desca = OREAD4(sc, OHCI_RH_DESCRIPTOR_A);
	OWRITE4(sc, OHCI_RH_DESCRIPTOR_A, desca | OHCI_NOCP);
	OWRITE4(sc, OHCI_RH_STATUS, OHCI_LPSC); /* Enable port power */
	usb_delay_ms(&sc->sc_bus, OHCI_ENABLE_POWER_DELAY);
	OWRITE4(sc, OHCI_RH_DESCRIPTOR_A, desca);

(Somehow that didn't make it into my hacked code; hmmm, I wonder if I
really hacked what I thought I was hacking -- I did try it alone once,
which wasn't enough to reliably power the external hub)


Since this doesn't seem to be in the RELENG_4 branch, or else I've
really botched my cvs tags, and the commit comment mentions that it
afflicts some OHCI controllers, I wonder if I have an even buggier
chip.


Nonetheless, I've apparently managed to make it work, somehow, after
boot, in spite of the overcurrent.  During boot (or when auto-loaded
at boot by usbd), though, it seems to hang with a timeout during the
port reset.  I need to make more sense of my hacks...  More hacking
has allowed me to also sometimes power it up at boot, although with
a painful delay, unlike my after-boot hack which powers it on cleanly.


> Either your hubs really use more power then it is allowed to or you

I wondered, but there were several things that made me suspicious that
this was not the case.  Then, some other things make me suspect that it
could be the case too:
= favoring the idea that the hub does not take too much power:
* the external hub works without any problems with a built-in UHCI USB,
* it also works fine with a different UHCI PCI card,
* I can connect an external power supply to the hub, also with current-
  drawing devices attached to the USB ports, then disconnect this power
  supply after everything is detected and the bus-power takes over with
  no overcurrent problems,
* my hacks of repeatedly applying power a few times are enough to power
  up the external hub, also with bus-powered devices attached...
= favoring the idea that the hub does take too much power:
* connecting a bus-powered USB mouse dongle to this same card does not
  trigger any overcurrent warnings.  (I have no other USB devices now)


Does `usbctl' or any similar utility give the aktuell current being
supplied on a particular port?  All I see is for the internal OHCI hub,

(some snippage)
iManufacturer=1(NEC) iProduct=2(OHCI root hub) iSerialNumber=0() bNumConfigurations=1
CONFIGURATION descriptor 0:
bLength=9 bDescriptorType=config(2) wTotalLength=25 bNumInterface=1
bConfigurationValue=1 iConfiguration=0() bmAttributes=40 bMaxPower=0 mA
HUB descriptor:
bDescLength=10 bDescriptorType=41 bNbrPorts=2 wHubCharacteristics=00
bPwrOn2PwrGood=255 bHubContrCurrent=0 DeviceRemovable=0


and for the external (Cypress) hub,

bDeviceProtocol=0 bMaxPacketSize=64 idVendor=0x04b4 idProduct=0x6560 bcdDevice=7
iManufacturer=0() iProduct=0() iSerialNumber=0() bNumConfigurations=1
CONFIGURATION descriptor 0:
bLength=9 bDescriptorType=config(2) wTotalLength=25 bNumInterface=1
bConfigurationValue=1 iConfiguration=0() bmAttributes=e0 bMaxPower=100 mA
HUB descriptor:
bDescLength=9 bDescriptorType=41 bNbrPorts=4 wHubCharacteristics=89
bPwrOn2PwrGood=50 bHubContrCurrent=100 DeviceRemovable=0

This is comparable to the mouse dongle bMaxPower=100 mA so I'm sure I'm
not seeing the actual current the device is sucking down.

Another Interesting Thing is that `usbdevs' reports this external
hub always as self-powered, even when it takes its power from the
bus...
 port 1 addr 2: self powered, config 1, product 0x6560(0x6560), Cypress Semicond
uctor(0x04b4), rev 0.07
If that makes any difference.



> have a broken controller card.

This is possible, for it was in a opened package marked a few Euro
less than normal, and I figured I'd take a chance, what with some 95%
of the junk I pick up at a discount or being discarded working fine
for me, and someone might have only been dissatisfied with it (or had
an IRQ problem, as I seemed to have earlier).


I'll either keep my present hacks, and continue to hack on the at-boot
case to see if I can arrive at a clean power-on, or keep the external
hub attached to its power supply cord, or try yet another card, or some
combination of the above, or something different.  Or maybe even cut
open a USB cable to measure the actual current inline...



Thanks,
Barry Bouwsma



More information about the freebsd-hackers mailing list