From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 4 21:02:40 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 0CC6416A4CE for ; Tue, 4 Nov 2003 21:02:40 -0800 (PST) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (B7774.b.pppool.de [213.7.119.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73FFB43FB1 for ; Tue, 4 Nov 2003 21:02:06 -0800 (PST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk (NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk [2002:d507:7774:0:200:c0ff:fefc:19aa]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id hA551Ng89236 verified NO) for ; Wed, 5 Nov 2003 06:01:26 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost)hA551MK55087; Wed, 5 Nov 2003 06:01:22 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Wed, 5 Nov 2003 06:01:22 +0100 (CET) Message-Id: <200311050501.hA551MK55087@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk> X-Authentication-Warning: NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk: beer set sender to bounce@NOSPAM.dyndns.dk using -f From: Barry Bouwsma References: <200309241632.h8OGWgs02770@Mail.NOSPAM.DynDNS.dK> <20030924191217.GZ21665@cicely12.cicely.de> To: FreeBSD Hacking Group Subject: Re: 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, 05 Nov 2003 05:02:40 -0000 [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