On Sun, 1 Jun 2003, David Brownell wrote:

> The device timed out a control or bulk message ... which
> could be real, but I also don't trust that particular code
> (since it can/does give the "raced timeout" messages with
> quick EHCI turnaround, as well as just looking dubious).
> 
> Are you sure nothing interesting happened earlier?  I
> recognize that usb-storage doesn't normally tell you
> when things go strange ... and storage debug messages
> give so much data that they change i/o timings in
> significant ways, hiding bugs.
> 
> I translate this sequence as a fault recovery problem,
> because the last times I've investigated, usb-storage will
> not use that odd usbcore code otherwise.

Some significant changes to the error recovery code were just accepted 
into Greg K-H's kernel tree.  They will probably show up in the main 
distribution in 2.5.71, or you can get them right now by BitKeeper from 
bk://linuxusb.bkbits.net/usb-2.5.  With these changes, the errors you see 
shouldn't stop things in dead in their tracks (although they might cause a 
10-second delay).  Of course, that's just in theory -- who knows what will 
happen when you actually try it!

Of course, persisting in the face of errors is all very nice, but it would 
be better to eliminate the errors in the first place.

> > I see this with kernels 2.4.21-rc2 and rc6 just the same. 2.5.70 is
> > even worse, it just stalls the access (very early on, not after
> > several 100MB) without any log messages, and CPU load diverges without
> > any useful information showing up with "top". It happens only with the
> > EHCI driver, in full-speed mode I haven't yet been able to produce
> > this error (maybe due to the relaxed timing).
> 
> Well that 2.5.70 failure mode is curious...

It would be interesting to know if the 2.4.21 CPU load problem is related 
to the EHCI driver or the usb-storage driver.

> Checking the ehci "async" and "registers" files (in sysfs)
> could be useful.  The last time I saw a failure anything like
> that, the issue was a deadlock inside storage+scsi, since the
> EHCI driver had handed all requests back ("async" was empty)
> and Alt-SysRq-T showed usb-storageN and scsi-ehN wedged.

That particular failure existed only in 2.5, and it has since been fixed.

> > Turning on usb-storage logging isn't much use, I haven't seen any
> > timeout/oops with it enabled, probably because it changes the timings.

I'm still planning to add non-verbose error logging to usb-storage.  But 
the are other things ahead of it.  It'll get it there eventually.

Alan Stern



-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to