On Thu, 17 Nov 2011, Sancho Dauskardt wrote: > Ok, finally managed to get a usefull bus capture + match URB_TRACE. See > below for the urb trace. > > What happens: > - usb-storage requests 240x 512 Byte sectors. > - the 92th transfer doesn't get an ACK from the HC. > - after the missing ACK the HC keeps on sending IN's which are NAK'ed by > the storage device. That's a bug in the storage device -- it should resend the packet which wasn't ACK'ed. (Unless for some reason it thought the packet _did_ get an ACK.) > - after 30 seconds timeout the urb is aborted and a port reset follows. > - the aborted urb reports 46592 bytes transferred ==> 91 sectors. > > So it looks like the 92th packet is not seen by the HC. > The bus analyser is sitting between HC + hub, an can see the packet > without any errors. In this case, since the bug appear to lie in the storage device, you should monitor the segment between the hub and the device. > Normally an ACK would come 9100ns after the data packet (Data: 21.429 > 518 444 vs. ACK: 21.429 527 517). That seems awfully long. According to the USB-2 spec (section 7.1.18.2), high-speed inter-packet delays are supposed to be no more than 192 bit times. That's less than half a microsecond. > In the error case I see the next interrupt IN to the usblp 12200ns after > the data packet. (Data: 21.429 533 200, IN: 21.429 45 467). Why do you say "interrupt IN"? According to your debugging log, the URBs sent to the printer are all async, either bulk or control. > >> The usblp device also sitting on the root hub sometimes responds with > >> 100ms(!) worth of NAKs (Ellisys USB explorer trace). > >> Could this somehow be choking the ehci queues ? > >> > > It should not. It doesn't affect the NEC controller, right? > > > No, the NEC Controller is OK. > But i can't reproduce the transfer error without the usblp on the same ehci. It could be some sort of electrical crosstalk issue. > According the the bus trace, the NAK's on the usblp device come every 25 > uSec. Is there an easy way to loosen this polling rate ? No. It already is loose; if the controller weren't throttling its transmissions those NAKs would come every 2 to 4 us, or even faster. > Thanks, > - sda > > urb trace: > > - 1 is the hub > - 1.5 is the SD Reader > - 3 is usblp There's a few things you should know. First, don't use the system log for reporting kernel debugging info. Use dmesg instead; it doesn't drop data the way the syslog daemon does. Second, it's a good idea to turn on CONFIG_PRINTK_TIME to get high-precision timestamps in the log. Third, for debugging USB problems, it's generally better to use usbmon instead of the verbose debugging in the controller driver. 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
