[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 _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
