On Sat, 28 Jul 2007, David Brownell wrote: > On Friday 27 July 2007, Alan Stern wrote: > > > stressing a flash disk I rapidly get this error: > > > > > Jul 27 12:35:00 oenone kernel: ehci_hcd 0000:00:02.2: devpath 3.4 ep1in > > > 3strikes > > > Jul 27 12:35:00 oenone kernel: usb-storage: Status code -71; transferred > > > 8192/122880 > > > > > Is there a way I can enable more debugging about this cause of -EPROTO? > > dbg_qh() and friends ... but it probably won't say anything much. > > If it's that reproducible, I suggest you get some kind of USB analyser > and throw it at the problem. > > Notice how it happened rather promptly at the start of a new page; > and likely at the start of a new qTD.
Yep. That seems to be common among these errors, which is a little odd since you might expect them to occur at arbitrary 512-byte packet boundaries unless they were caused by a problem in the host controller hardware. But maybe device controllers also divide the data stream up into 4-KB chunks... > > In my experience this sort of thing tends to be caused by low-level > > hardware communications errors. Noise in the USB data lines or a > > missing handshake packet, stuff like that. Not much extra debugging > > can be done; the "3strikes" indication comes directly from the > > controller hardware. > > Well, that's one theory. In a few cases it has been positively proven. > Thing is, this kind of problem happens > more often than it should. True. In many other cases nobody was ever able to determine the cause of the problem. In fact, it wouldn't be surprising if there were many different causes. > No matter what causes it, it'd be better > to recover from it ... or prevent it from happening. > > My theory has been different: that some USB peripherals get deeply > confused if Linux talks to them "too fast" (i.e. probably anything > faster than MS-Windows). Notice how the "recovery" that followed > involved a device reset. The device reset is the normal recovery procedure used by usb-storage. It would occur regardless of what caused the -EPROTO error; it doesn't give any direct information about what has happened inside the device. However it is possible to test the "too fast" theory to some extent. All that's needed is an unusual_devs entry with the US_FL_GO_SLOW flag. > But -- never actually having had both a highspeed USB sniffer *AND* > hardware exhibiting this problem in the same place -- I've not been > able to test that theory. It sure would be good if somebody could do this. But high-speed USB analyzers aren't easy to come by, alas. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
