Re: 2.6.23-rc1: USB hard disk broken (REGRESSION)
Mark Lord wrote:
Dan Zwell wrote:
Alan Stern wrote:
[ 126.512815] usb 1-1: usb auto-resume
[ 126.543447] uhci_hcd :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, );
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.
Nope. Patch is already in -rc6 I see, so still NFG.
We can continue blacklisting the multitudes of b0rked devices one by one,
or we can revert this change or default it to "off" for usb-storage (at least).
This really kills a lot of everyday devices. Here's my Sandisk Cruzer(s),
after forcing autosuspend=0:
Bus 005 Device 014: ID 0781:5151 SanDisk Corp. Cruzer Micro 256/512MB Flash
Drive
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
idVendor 0x0781 SanDisk Corp.
idProduct 0x5151 Cruzer Micro 256/512MB Flash Drive
bcdDevice0.10
iManufacturer 1 SanDisk Corporation
iProduct2 Cruzer Micro
iSerial 3 20060775000CF73334D3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 200mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
bNumConfigurations 1
Device Status: 0x
(Bus Powered)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: 2.6.23-rc1: USB hard disk broken (REGRESSION)
Dan Zwell wrote:
Alan Stern wrote:
[ 126.512815] usb 1-1: usb auto-resume
[ 126.543447] uhci_hcd :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, );
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc1: USB hard disk broken (REGRESSION)
Dan Zwell wrote:
Alan Stern wrote:
[ 126.512815] usb 1-1: usb auto-resume
[ 126.543447] uhci_hcd :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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc1: USB hard disk broken (REGRESSION)
Mark Lord wrote:
Dan Zwell wrote:
Alan Stern wrote:
[ 126.512815] usb 1-1: usb auto-resume
[ 126.543447] uhci_hcd :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.
Nope. Patch is already in -rc6 I see, so still NFG.
We can continue blacklisting the multitudes of b0rked devices one by one,
or we can revert this change or default it to off for usb-storage (at least).
This really kills a lot of everyday devices. Here's my Sandisk Cruzer(s),
after forcing autosuspend=0:
Bus 005 Device 014: ID 0781:5151 SanDisk Corp. Cruzer Micro 256/512MB Flash
Drive
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
idVendor 0x0781 SanDisk Corp.
idProduct 0x5151 Cruzer Micro 256/512MB Flash Drive
bcdDevice0.10
iManufacturer 1 SanDisk Corporation
iProduct2 Cruzer Micro
iSerial 3 20060775000CF73334D3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 200mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
bNumConfigurations 1
Device Status: 0x
(Bus Powered)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
