On Fri, 23 Mar 2007, Oliver Neukum wrote: > Hi, > > I got a bug report about a device failing if EHCI is loaded shortly > after OHCI had been loaded. The device stalls. This seems to violate > the spec. Is there a reason not to clear the halt? > > Regards > Oliver > > usb 2-6.1.4: khubd timed out on ep0in len=0/255 > usb 2-6.1.4: string descriptor 0 read error: -32 > usb 2-6.1.4: new device found, idVendor=0430, idProduct=00a2 > usb 2-6.1.4: new device strings: Mfr=0, Product=1, SerialNumber=0 > usb 2-6.1.4: uevent > usb 2-6.1.4: device is bus-powered > usb 2-6.1.4: configuration #1 chosen from 1 choice > usb 2-6.1.4: can't set config #1, error -32
Looks like the device isn't working too well: a timeout and two STALLs. Maybe it doesn't like to be reset while it's in the middle of enumerating, which is what typically happens when ehci-hcd is loaded shortly after the other HCDs. (That's why we always recommend loading ehci-hcd first.) Stalling endpoint 0 isn't against the spec. It's the proper way for a device to respond to a request that it doesn't support. We don't clear the halt because the host is never supposed to clear halts on ep0. If the halt is a "protocol stall" (the normal case) then the device will clear it automatically when it receives the next SETUP packet. If the halt is a "functional stall" (discouraged by the USB spec) there is no way to clear it -- the Clear-Halt request won't get through because ep0 is halted! Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
