From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 24 09:33:59 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1955616A4BF for ; Wed, 24 Sep 2003 09:33:59 -0700 (PDT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (B76a1.pppool.de [213.7.118.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 991D844014 for ; Wed, 24 Sep 2003 09:33:20 -0700 (PDT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:d507:76a1:0:220:afff:fed4:dbcb]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id h8OGWg402771 verified NO) for ; Wed, 24 Sep 2003 18:32:58 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id h8OGWgs02770; Wed, 24 Sep 2003 18:32:42 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Wed, 24 Sep 2003 18:32:42 +0200 (CEST) Message-Id: <200309241632.h8OGWgs02770@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma To: FreeBSD Hacking Group Subject: USB card overcurrent problems... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2003 16:33:59 -0000 [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