From: Mark Lord <lkml@rtr.ca>
To: Dan Zwell <dzwell@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Oliver Neukum <oliver@neukum.org>,
Tino Keitel <tino.keitel@gmx.de>,
David Brownell <david-b@pacbell.net>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Greg KH <gregkh@suse.de>
Subject: Re: 2.6.23-rc1: USB hard disk broken (REGRESSION)
Date: Wed, 12 Sep 2007 18:40:19 -0400 [thread overview]
Message-ID: <46E86AD3.7030204@rtr.ca> (raw)
In-Reply-To: <46E860CE.70704@rtr.ca>
Mark Lord wrote:
> 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.
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:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0781 SanDisk Corp.
idProduct 0x5151 Cruzer Micro 256/512MB Flash Drive
bcdDevice 0.10
iManufacturer 1 SanDisk Corporation
iProduct 2 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
bInterfaceNumber 0
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
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
prev parent reply other threads:[~2007-09-12 22:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-25 7:23 2.6.23-rc1: USB hard disk broken Tino Keitel
2007-07-25 8:24 ` Oliver Neukum
2007-07-25 18:13 ` Tino Keitel
2007-07-26 8:06 ` Oliver Neukum
2007-08-05 11:09 ` Tino Keitel
2007-08-05 11:41 ` Tino Keitel
2007-08-05 15:46 ` Oliver Neukum
2007-08-05 19:11 ` David Brownell
2007-08-09 16:58 ` Dan Zwell
2007-08-09 20:00 ` Alan Stern
2007-08-09 20:25 ` Tino Keitel
2007-08-09 22:20 ` Dan Zwell
2007-08-10 14:18 ` Alan Stern
2007-08-10 20:30 ` Dan Zwell
2007-08-10 20:43 ` Alan Stern
2007-09-12 21:57 ` 2.6.23-rc1: USB hard disk broken (REGRESSION) Mark Lord
2007-09-12 22:40 ` Mark Lord [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46E86AD3.7030204@rtr.ca \
--to=lkml@rtr.ca \
--cc=akpm@linux-foundation.org \
--cc=david-b@pacbell.net \
--cc=dzwell@gmail.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=oliver@neukum.org \
--cc=stern@rowland.harvard.edu \
--cc=tino.keitel@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.