On Tue, Oct 27, 2009 at 11:21 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 27 Oct 2009, John Faith wrote: > >> >> and this is the usbmon dump around the "80 06" descriptor request and >> >> the subsequent error -71 (EPROTO?): >> >> >> >> c671f8a0 1662538668 S Co:1:001:0 s 23 03 0004 0001 0000 0 >> >> c671f8a0 1662538760 C Co:1:001:0 0 0 >> >> c671f8a0 1662594851 S Ci:1:001:0 s a3 00 0000 0001 0004 4 < >> >> c71ca140 1662594942 C Ii:1:001:1 0:2048 1 D >> >> c71ca140 1662594973 S Ii:1:001:1 -115:2048 4 < >> >> c671f8a0 1662595064 C Ci:1:001:0 0 4 = 03051200 >> >> c671f8a0 1662657351 S Co:1:001:0 s 23 01 0014 0001 0000 0 >> >> c671f8a0 1662657412 C Co:1:001:0 0 0 >> >> c671f8a0 1662663393 S Ci:1:000:0 s 80 06 0100 0000 0040 64 < >> >> c671f8a0 1662663485 C Ci:1:000:0 -71 0 >> >> c671f8a0 1662663607 S Ci:1:000:0 s 80 06 0100 0000 0040 64 < >> >> c671f8a0 1662663821 C Ci:1:000:0 -71 0 >> >> >> >> The same hub on an EVM board using the same kernel returns the >> >> descriptor and works fine (can use USB mass storage), so I'm wondering >> >> what type of failure this might indicate or how best to proceed. I >> >> assume that the transceiver is mostly ok since some packets do make it >> >> in and out before the descriptor request. >> > >> > They do? What packets are those? Certainly nothing in the extract >> > above. >> >> I assumed that "S" and "C" before the descriptor request indicated >> 2-way communication between the host controller and the hub based on >> my minimal USB knowledge. > > Oh, okay. Your mixup is understandable. > > Look more closely at the device addresses in the usbmon output. The > descriptor request was sent to device 000, which is your hub (before it > has been assigned a real address). The earlier lines are addressed to > device 001, which is the root hub -- a virtual device created by the > controller driver and hardware. Messages sent to/from the root hub > never appear as packets on the USB bus; they are internal to the host > computer. Hm. I ran the output through these awk scripts: http://www.mail-archive.com/linux-usb-devel@xxxxxxxxxxxxxxxxxxxxx/msg36943.html and saw both "host_to_dev" and "dev_to_host" so I thought bits were going both ways. A scope showed activity on the D+ line out of the host, but of course a nice protocol analyzer would have made it more obvious which way packets were flying. >> Is the descriptor request the first set of >> bits that a hub might send? In other words, would a silent, >> (damaged/non-transmitting) hub give similar usbmon output? > > Yes, exactly. Or a silent, damaged device of any kind, not necessarily > a hub. > Since the device I'm using works fine on another host, we'll have to look elsewhere for the fault like the transceiver or a bad connection. Thanks! , John -- 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
