2012/10/11 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > On Thu, 11 Oct 2012, Elric Fu wrote: > >> Hi all, >> >> I recently found a strange issue on a embedded platform and don't know >> how to fix it. Please give me some suggestions. >> >> The platform is ar9331. The issue is if we attach a usb audio device to >> the host on ar9331 directly or via a usb 1.1 hub the usb audio works fine, >> but if we attach it via usb 2.0 hub the undermentioned message will be >> reported. Moreover, when the usb audio was attached to the host on X86 >> via usb 2.0 hub it worked fine too. >> >> ~ # usb 1-1.3: new full speed USB device using ar7240-ehci and address 3 >> usb 1-1.3: unable to read config index 0 descriptor/start: -145 >> usb 1-1.3: chopping to 0 config(s) >> usb 1-1.3: string descriptor 0 read error: -145 >> usb 1-1.3: New USB device found, idVendor=040d, idProduct=3400 >> usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 >> usb 1-1.3: no configuration chosen from 0 choices >> >> I tracked the issue and found the usb audio had a strange issue. It is a >> usb 1.1 device and works at full speed. But the interesting thing is the >> bcdUSB field of device descriptor is 0x0200. > > That means it is a USB-2.0 device, not USB-1.1. Well. I see. > >> So the >> hub_port_connect_change() will involke the check_highspeed() which >> would get device qualifier descriptor. >> >> The correct case is the device doesn't have the device qualifier descriptor > > That's okay. It means the device doesn't support high-speed operation, > only full speed. > >> and usb_get_descriptor() will retry 3 times and return -32. But now >> usb_get_descriptor() will return -145 at the second time. Then when the > > What is error -145 on your platform? Is it -ETIMEDOUT? Yes. -145 means -ETIMEOUT. > >> usb core send a get configuration descriptor request, but the control transfer >> will be timeout again. >> >> I used the usb analyzer to capture the trace and found host just sent one >> get-device-qualifier-descriptor control transfer and the device return a >> STALL. But at the second time, actually, the host even didn't send the setup >> packet. I don't know why. > > Since the transfer uses aplit transactions, the host doesn't send any > SETUP packets at all. The intervening hub sends them. Maybe there's > something wrong with the hub. > > Can you use your analyzer to capture the traffic between the computer > and the hub, rather than between the hub and the device? Yes. I have already capture the traffic between the host and the hub.Same situation would happened. I can't found any packets belong to the second get-device-qualifier-descriptor control transfer. > >> My opinion is the split transactions to the device which has a 0x0200 bcdUSB >> but is actually a full speed device have some issues. I would >> appreciate any ideas. > > What happens if you use both the device and the same hub with a regular > PC? If I use the same device and the same hub with a regular pc, everything is normal. The issue just occurred on Atheros ar9331 platform. > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
