On Thu, 5 Jun 2003, Major A wrote: > OK, here we go. The drive is now connected directly to the EHCI host, > and it does the exact same thing (hang) after I type "md5sum *.png > > md5sums", _except_ that the system load stays down (much less than 1), > which means the computer doesn't spend most its time waiting for I/O, > and that there is no timeout or oops in the logs. What you see below > is all, I've waited for quite a while now (10 minutes) and it just > doesn't give more output.
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. 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. 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? Alan Stern ------------------------------------------------------- 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
