On Thu, 28 Mar 2013, David Linares wrote: > Ok so here is what I did: > - compiled all USB stuff as modules > - boot up the device with nothing plugged in > - Checked that "lsmod | grep usb" didn't return anything > - modprobe usbmon (this will also load usbcore) > - start the capture : cat /sys/kernel/debug/usb/usbmon/0u > mon.out & > - modprobe ehci-hcd > - kill the cat ;p > > I managed to get the capture for the failing case (NOK) and the OK > case. Here are the results: > OK case, dmesg output: http://pastebin.com/8DRP9L4E > OK case, lsusb -v output: http://pastebin.com/HcFKhVeW > OK case, usbmon output: http://pastebin.com/LrFuJ2cd > > NOK case, dmesg output: http://pastebin.com/7kXDCDmr > NOK case, lsusb -v output: http://pastebin.com/zachs6FX > NOK case, usbmon output: http://pastebin.com/RtyLjKt9 > > I still haven't analysed the results, but there are definitely some > differences between the two usbmon results. > Just wanted to post them as soon as possible, just in case I did > something wrong. You did everything right. There are two important differences between the usbmon traces. In the okay case, we have this: c1b2e240 75754579 S Ci:1:002:0 s 80 06 0100 0000 0012 18 < c1b2e240 75755779 C Ci:1:002:0 0 18 = 00000000 00000000 00000000 00000000 0000 c1b2e240 75755915 S Ci:1:002:0 s 80 06 0100 0000 0012 18 < c1b2e240 75756777 C Ci:1:002:0 0 18 = 12010002 09000040 24041225 00000000 0001 This shows the host asking for the 2-port hub's device descriptor twice and getting two different answers. The first response is obviously wrong, because it is all zeros. The second is right. I can't imagine why it went wrong the first time, nor why there was a second attempt -- the driver only tries once. The corresponding part of the not-okay usbmon trace shows only one attempt: c146a420 72878459 S Ci:1:002:0 s 80 06 0100 0000 0012 18 < c146a420 72879654 C Ci:1:002:0 0 18 = 12010002 09000040 24041225 00000000 0001 The second difference occurs in the response to the Get-Device-Status request. The okay case shows: c1af6820 75799421 S Ci:1:002:0 s 80 00 0000 0000 0002 2 < c1af6820 75800790 C Ci:1:002:0 0 2 = 0100 which looks right. There's only one bit set in the response, to indicate the 2-port hub is self-powered. The not-okay case shows: c14365c0 72920304 S Ci:1:002:0 s 80 00 0000 0000 0002 2 < c14365c0 72920676 C Ci:1:002:0 0 2 = 6063 This response is complete garbage. I have no idea where it came from, but it clearly indicates a bug somewhere. Everything else was identical. However, there was one more problem, which showed up in both traces: The 2-port hub connected as a full-speed device instead of high-speed. You can see it in the dmesg logs: usb 1-1: new full-speed USB device number 2 using mxc-ehci usb 1-1: not running at top speed; connect to a high speed hub This is another bug. There's no way to tell if the flaw lies in the 2-port hub or in the iMX25's EHCI controller. It's even possible that the problem lies in the connection between them; it may be picking up electromagnetic noise from the other components on the board. 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
