Re: 2.6.23-rc1: USB hard disk broken (REGRESSION)

From: Mark Lord
Date: Wed Sep 12 2007 - 18:22:01 EST


Dan Zwell wrote:
Alan Stern wrote:
[ 126.512815] usb 1-1: usb auto-resume
[ 126.543447] uhci_hcd 0000:00:1f.2: port 1 portsc 00a5,01
[ 126.559426] usb 1-1: finish resume
[ 126.561435] usb 1-1: gone after usb resume? status -19
[ 126.561445] usb 1-1: can't resume, status -19
[ 126.561451] hub 1-0:1.0: logical disconnect on port 1
[ 126.562486] sd 5:0:0:0: [sdb] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK,SUGGEST_OK

This suggests a bug in the device's firmware, probably it sends a 1-byte Device-Status reply instead of a 2-byte reply as required by the USB spec. You could find out for certain by using usbmon.

But if that is indeed the problem, the patch below should help. I've seen it before; perhaps we should adopt this workaround permanently.

Relevant info:
-obviously, I'm using uhci
-the drive is SATA, connected to USB with a SATA/IDE to USB adapter
-this problem does not occur with a USB flash drive
-reverting the commit that introduced auto-suspend prevents this error.

If necessary you could disable autosuspend for your drive. But first test this patch.

Alan Stern



Index: 2.6.23-rc1/drivers/usb/core/hub.c
===================================================================
--- 2.6.23-rc1.orig/drivers/usb/core/hub.c
+++ 2.6.23-rc1/drivers/usb/core/hub.c
@@ -1644,9 +1644,10 @@ static int finish_port_resume(struct usb
* and device drivers will know about any resume quirks.
*/
if (status == 0) {
+ devstatus = 0;
status = usb_get_status(udev, USB_RECIP_DEVICE, 0, &devstatus);
if (status >= 0)
- status = (status == 2 ? 0 : -ENODEV);
+ status = (status > 0 ? 0 : -ENODEV);
}
if (status) {



Alan,

Yes, that patch worked, and dmesg now shows the device auto-suspending and resuming every few seconds. Thanks a lot. I hope you do merge this patch or a workaround like it.

Dan

The same bug kills my Sandisk Cruzer Micro USB pen drives.
I plug them in, they work briefly, then the light goes out (abnormal),
and 30-second timeout/reset is needed for each subsequent access. Ugh.

They work fine in 2.6.22. I'll try the above patch here now and see if it fixes
this regression.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/