1. boot the machine with the drive plugged into the usb 2.0 controller (it is properly recognized and works fine at first...) 2. mount the drive 3. copy a large file to the drive (which reproducably fails after about ~450M) 4. curse
can anybody make sense of this? i have seen other people report similar problems with usb2->ide bridges, is there a fix available or in the works?
... 13:12:06 sim k: hub.c: port 6, portstatus 503, change 10, 480 Mb/s 13:12:06 sim k: hub.c: new USB device 00:0e.3-6, assigned address 2 13:12:06 sim k: usb.c: kmalloc IF dfdabd40, numif 1 13:12:06 sim k: usb.c: descriptor data left
Hmm, can you forward "lsusb -v" output for this device? I'm curious what's up with those descriptors.
And the rest of the debug log ... with initialization dump for the EHCI controller, at "00:0e.3" ? Looks like that was immediately before what you sent.
13:12:06 sim k: usb.c: new device strings: Mfr=0, Product=1, SerialNumber=0 13:12:06 sim k: usb.c: USB device number 2 default language ID 0x409 13:12:06 sim k: Product: USB TO IDE 13:12:06 sim k: scsi1 : SCSI emulation for USB Mass Storage devices ...
The first thing that comes to mind is that this looks like one of those GeneSys devices that have been causing problems. The diagnostic with "descriptor data left" seems to be a new clue.
You might be able to turn up some more information with this EHCI diagnostic patch (for 2.4), which just dumps the hardware data structures at the moment usb-storage times out the transfer. What it's shown in similar cases is that the GeneSys adapter got part way through a transfer and then stopped responding.
One person had better luck after applying a patch that slowed down EHCI on an NForce2 southbridge ... the fact that it even mattered is in indication of problems in the GeneSys device.
But I have no idea if your ALI hardware even implements the feature being turned off (you snipped the "00:0e.3" init info).
Also, as Alan Stern commented, it's worth trying this on 2.6 kernels. If nothing else, the usb-storage/scsi fault recovery code is more robust there, and you're using it to recover from this problem.
- Dave
--- 1.16/drivers/usb/host/ehci-q.c Thu Jun 19 06:51:52 2003
+++ edited/ehci-q.c Sun Aug 10 12:06:53 2003
@@ -267,6 +267,7 @@
unsigned count = 0;
int do_status = 0;
u8 state;
+ u8 dumped = 0;
if (unlikely (list_empty (&qh->qtd_list)))
return count;
@@ -347,6 +348,19 @@
do_status = 0;
continue;
}
+#if 1
+ switch (urb->status) {
+ default:
+ break;
+ case -ECONNRESET: /* canceled */
+ case -ENOENT:
+ if (!dumped) {
+ dumped = 1;
+ dbg_qh ("cancel", ehci, qh);
+ }
+ dbg_qtd ("cancel", ehci, qtd);
+ }
+#endif
/* token in overlay may be most current */
if (state == QH_STATE_IDLE
