USB card overcurrent problems...

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

  • Next message: Barry Bouwsma: "Kernel module problems/questions" 
    Date: Wed, 24 Sep 2003 18:32:42 +0200 (CEST)
To: FreeBSD Hacking Group <hackers@freebsd.org>

    [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

    _______________________________________________
    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: Barry Bouwsma: "Kernel module problems/questions"

    Relevant Pages