> Interesting. This log shows no errors at all. It's got a couple of reads
> followed by 12 writes, and they all completed successfully. Judging from
> this, I would say that the problem must lie somewhere else, not in the USB
> driver.
Interesting...
> I don't understand why the same test should behave differently depending
> on whether the device is attached directly to the host or not. If you
> also have a non-EHCI host in your system, it might be worth trying the
> same tests using that controller.
I tried various UHCI hosts, they all work fine under all kernel
versions I tried (2.4.{20,21}, 2.5.70), but at a much lower speed.
> Maybe another possibility is a flaw in the filesystem code (I'm guessing
> wildly here). Is it possible to use a different sort of filesystem and
> repeat the tests? And related to that, did your original command ever
> end up writing anything to the md5sums output file?
I'm afraid not -- the disk is in one partition, and I need the data
that's on there. Currently I have no way of moving it elsewhere for a
test.
But why should a filesystem or SCSI problem cause a timeout in the USB
subsystem? There must be something wrong with USB, even if other parts
of the kernel aren't spotless either.
Andras
===========================================================================
Major Andras
e-mail: [EMAIL PROTECTED]
www: http://andras.webhop.org/
===========================================================================
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
