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 ?
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 ?
usb-storage is doing the port reset due to timeout, right ?
This is on 2.6.39-4.
We've tried 3.2-next20111114. Tried to remove the amd_pll_quirk.
Also cross checked the AMD SB Eratta (made sure that the async park mode
is disabled).
Problem also occurs when ohci is unloaded.
Problem is gone with a NEC PCI ehci in the same system. A couple of
nforce ehci's didn't show the problem either.
SMSC 2504 (older) seem ok. SMSC 2507, 2514, 2517 are having problems.
A Cypress hub was also ok - an older philips hub also showed the same
problem.
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.
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.
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 ?
Hardware-level problems like this can be very difficult to track down.
Yeah. We love 'em.
- sda
--
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
