On Tue, 15 Nov 2011, Sancho Dauskardt wrote: > On 14.11.2011 21:58, Alan Stern wrote: > > On Mon, 14 Nov 2011, Sancho Dauskardt wrote: > > ... > > > > >> Nov 14 19:19:39 (none) user.debug kernel: ehci_hcd 0000:00:12.2: irq > >> status e028 Async Periodic Recl IAA FLR > >> Nov 14 19:19:39 (none) user.debug kernel: ehci_hcd 0000:00:12.2: > >> ehci_urb_done 4.5 urb f31e4f00 ep2in status -115 len 54784/122880 > >> > > ... > > > > So either the reader stopped sending data or the controller stopped > > asking for it, after only 54784 bytes had been transferred. > > > > > How can I figure that out ? Use your bus analyzer. You should try monitoring both the connection leading to the hub and the connection leading to the card reader (not necessarily both at the same time). > When watch'ing /sys/kernel/debug/usb/ehci/../registers I can't see any > activity during the stall. Shouldn't there be at least some periodic > things happening ? Well, of course there _should_ be. Just as the transfer _should_ succeed without stalling. More specifically: The uframe value ought to be different each time you read the registers file. Was it not changing? If it's not changing then the controller isn't running. However, if the controller _is_ running and no data is being exchanged, then nothing in the registers file will change other than the uframe value. > usb-storage is doing the port reset due to timeout, right ? Right. > > It's possible one of the cables or connections is marginal. Or the > > power level -- are these powered hubs? > > > > > We've reproduces the with all the hubs are sitting on their reference > design pcbs - most of them being powered. > The cables are trustworthy. Also happens with an AU63xx reference design > SD-reader. > > > What happens with no hub? Have you tried any other storage devices > > besides the SD card reader? > > > > > SD-reader on the root hub works like a charm. Which certainly indicates that the hub is involved somehow. > A USB stick behind the hub shows the same problem, but a LOT harder to > reproduce. Like 20:1. > SD-card stalls after 5-50MB, USB stick takes ~1GB. > My gut feeling is that the faster the storage device - the harder it is > to reproduce the problem. Or maybe faster devices tend to use better hardware and therefore are less likely to hit the marginal situation that causes this problem. I'm assuming the card reader is a high-speed device, although you never said so explicitly. Is that correct? > 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? 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
