[lkml]   [2005]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: [BUG] 2.6.11: Random SCSI/USB errors when reading from USB memory stick
On Thu, 31 Mar 2005, kus Kusche Klaus wrote:

> > Latency is the subject of a separate email. Does this
> > increase in latency
> > occur only when you see the errors, or whenever you do a large data
> > transfer? In fact, I would suspect the errors to _decrease_
> > the latency
> > with respect to a normal transfer.
> I observe from <1 to 2 ms on successful transfers, and around 15 ms
> latency when things go wrong.

I hate to ask this question; it sounds an awful lot like "Monty Python and
the Holy Grail", but... Is that IRQ latency or application latency?

I can't think of any reason why IRQ latency should change during the error
handling. Application latency might change because the SCSI error handler
could start using up a lot of CPU time. I don't know what priority it
runs at; you can check with ps.

> I do not know what the kernel does internally, but I tried block
> sizes from 512b to 8192kb with dd, and it did not make any
> difference, neither w.r.t. timing nor w.r.t. errors.

dd's block size makes almost no difference to anything within the kernel.

> > This indicates that the problem lies in the computer, or its USB
> > connectors and their electromagnetic environment.
> Hmmm, hard to believe. It happens on all USB ports, on two
> different controllers. The box is an industrial-grade
> embedded control system, in a robust steel case. There is
> no external USB cable involved, the stick is plugged directly
> into the box.
> The USB ports of these boxes work fine in vxWorks
> (don't know about Windows).

It's hard to know what to say. The error code shown in your log comes
directly from reading a data value that is set by the USB host controller.
The only way to interpret it is that something is wrong at the hardware

Maybe vxWorks and Windows don't stress the USB controller or device as
heavily as Linux does.

> > Timing or interrupt trouble wouldn't cause the problems you see. Bus
> > utilization can cause problems, but they would be reported
> > differently.
> > I think your problem is due either to faulty hardware or to bad signal
> > propagation.
> If it's not caused by bus utilization or shared or lost irqs,
> I think it is some kind of software problem, maybe in the driver,
> maybe elsewhere:
> The dd command *always* runs fine for some time, up to now
> the transfer never had any problems for the first 30 MB or so,
> sometimes even for 500 MB on my 1 GB stick.

That doesn't mean anything necessarily.

> Is there any possibility for integer overflow?


> Is there any data which may accumulate over time?


> > > Mar 30 10:47:16 OF455 kern.debug kernel: usb-storage:
> > > usb_stor_bulk_transfer_sglist: xfer 122880 bytes, 30 entries
> > > Mar 30 10:47:17 OF455 kern.debug kernel: usb-storage:
> > Status code -75;
> > > transferred 19840/122880
> > > Mar 30 10:47:17 OF455 kern.debug kernel: usb-storage: -- babble
> >
> > This is not a "short read"; as the log says, it's a "babble".
> > That means
> > the computer's USB controller believed the device continued
> > transmitting
> > past the time when it was supposed to stop. Assuming the device is
> > functioning correctly, either the USB controller is bad or
> > the signal was
> > degraded.
> But doesn't it say 19840 of 122880 transferred?
> In all cases of trouble, the first number is smaller than the second.

Yes. That's how far the transfer had gotten before the "babble" error
occurred. A genuine short read would have a status code of -121 and
would be reported as a "short read transfer".

Alan Stern

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-04-06 13:31    [W:0.039 / U:4.660 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site