On Tue, 25 Oct 2005, MAL wrote: > ok, I've been using 2.6.13 for a while now and while the error recovery > does now work (I can power cycle the device after it has a fit and it > reconnects as a new USB device), the problem with random SCSI errors to > USB2 hard disks continues, making them frustratingly unreliable. > > I have uploaded a kernel log here: > > http://dmesg:[EMAIL PROTECTED]/dmesg-20051025/dmesg.log
Unfortunately the log doesn't contain much useful information other than what you describe verbally. Most important to know would be _why_ the errors occur. > I fresh booted the PC, (x86) with the USB-IDE caddy connected (shows up > as sdb with 4 partitions), made ext3 filesystems on sdb1, 3 and 4, and > made a swap filesystem on sdb2, then mounted the partitions and unpacked > a tarball system image onto the partitions (~500MB of data). > > Part way through the unpacking, the device offlines and the tar fails > horribly. This happens regularily for me, but NOT every time. > > Here is the lsusb -v output for the HDD caddy and the lspci -vv output > for the host controller: > > http://dmesg:[EMAIL PROTECTED]/dmesg-20051025/lsusb.log > http://dmesg:[EMAIL PROTECTED]/dmesg-20051025/lspci.log > > I'd be happy to provide more info if needed. One way to get more information, although a somewhat painful way, is to enable USB Mass Storage verbose debugging in the kernel configuration (CONFIG_USB_STORAGE_DEBUG). That would help show exactly what goes wrong. The problem is that it generates voluminous debugging messages. For large transfers, like your tarball unpacking, the system log files would grow uncomfortably large. You know, it quite often turns out that instability in USB storage devices, especially the "insert ATA disk in a USB enclosure" sort, is caused not by problems in the host hardware or the system software. It's caused by defects and bad design of the USB (or USB-ATA) interface in the device's electronics. This line in particular from the log is telling: [4294922.249000] hub 2-0:1.0: connect-debounce failed, port 4 disabled It indicates very specifically that the device's USB hardware was trying to send a signal at a time when it should not have been. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
