Date: Wed, 5 Nov 2003 06:01:22 +0100 (CET) From: Barry Bouwsma <freebsd-misuser@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk> To: FreeBSD Hacking Group <hackers@freebsd.org> Subject: Re: USB card overcurrent problems... Message-ID: <200311050501.hA551MK55087@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk> References: <200309241632.h8OGWgs02770@Mail.NOSPAM.DynDNS.dK> <20030924191217.GZ21665@cicely12.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
[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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311050501.hA551MK55087>