Re: USB card overcurrent problems...

From: Barry Bouwsma (freebsd-misuser_at_remove-NOSPAM-to-reply.NOSPAM.dyndns.dk)
Date: 11/05/03

  • Next message: Mike Silbersack: "Re: Update: Debox sendfile modifications" 
    Date: Wed, 5 Nov 2003 06:01:22 +0100 (CET)
To: FreeBSD Hacking Group <hackers@freebsd.org>

    [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

    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

  • Next message: Mike Silbersack: "Re: Update: Debox sendfile modifications"