Bug 15421

Summary: Not mount USB-Storage - dmesg: usb 1-1: reset high speed USB device using ehci_hcd and address 4
Product: Drivers Reporter: Cristian Aravena Romero (caravena)
Component: USBAssignee: Greg Kroah-Hartman (greg)
Status: CLOSED OBSOLETE    
Severity: normal CC: alan, klaus.doblmann, stern, the.ridikulus.rat
Priority: P1    
Hardware: All   
OS: Linux   
URL: https://bugs.edge.launchpad.net/ubuntu/+source/gvfs/+bug/545588
Kernel Version: 2.6.34-rc3 Subsystem:
Regression: No Bisected commit-id:
Attachments: /2.6.31-14-generic_dmesg.txt
dmesg_2.6.34-rc2.26032010.txt
config-2.6.34-rc2.26032010
boot_dmesg-2.6.34-rc3
current_dmesg-2.6.34-rc3
config-2.6.34-rc3-31032010
Patch for imx51 from Ubuntu
original usbmon trace

Description Cristian Aravena Romero 2010-03-01 19:02:41 UTC
Open bug in Launchpad.net:
https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/530227

Messaje:


Mount in console and message:

[ 1542.774463] sd 6:0:0:0: [sdc] Unhandled sense code
[ 1542.774472] sd 6:0:0:0: [sdc] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 1542.774479] sd 6:0:0:0: [sdc] Sense Key : Medium Error [current]
[ 1542.774488] sd 6:0:0:0: [sdc] Add. Sense: Unrecovered read error
[ 1542.774496] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 60 53 57 00 00 88 00
[ 1542.774512] end_request: I/O error, dev sdc, sector 6312791
[ 1542.774521] Buffer I/O error on device sdc1, logical block 789091
[ 1542.774532] Buffer I/O error on device sdc1, logical block 789092
[ 1542.774539] Buffer I/O error on device sdc1, logical block 789093
[ 1542.774545] Buffer I/O error on device sdc1, logical block 789094
[ 1542.774551] Buffer I/O error on device sdc1, logical block 789095
[ 1542.774557] Buffer I/O error on device sdc1, logical block 789096
[ 1542.774563] Buffer I/O error on device sdc1, logical block 789097
[ 1542.774569] Buffer I/O error on device sdc1, logical block 789098
[ 1542.774575] Buffer I/O error on device sdc1, logical block 789099
Comment 1 Cristian Aravena Romero 2010-03-01 20:25:28 UTC
Message in kernel 2.6.31-14-generic

[  278.769885] sd 6:0:0:0: [sdc] Unhandled sense code
[  278.769890] sd 6:0:0:0: [sdc] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[  278.769894] sd 6:0:0:0: [sdc] Sense Key : Medium Error [current] 
[  278.769898] sd 6:0:0:0: [sdc] Add. Sense: Unrecovered read error
[  278.769902] end_request: I/O error, dev sdc, sector 6312799
[  278.769907] __ratelimit: 8 callbacks suppressed
[  278.769910] Buffer I/O error on device sdc1, logical block 789092
[  278.769914] Buffer I/O error on device sdc1, logical block 789093
[  278.769935] Buffer I/O error on device sdc1, logical block 789094
[  278.769938] Buffer I/O error on device sdc1, logical block 789095
[  278.769941] Buffer I/O error on device sdc1, logical block 789096
[  278.769943] Buffer I/O error on device sdc1, logical block 789097
[  278.769946] Buffer I/O error on device sdc1, logical block 789098
[  278.769949] Buffer I/O error on device sdc1, logical block 789099
[  278.769952] Buffer I/O error on device sdc1, logical block 789100
[  278.769954] Buffer I/O error on device sdc1, logical block 789101
Comment 2 Cristian Aravena Romero 2010-03-01 20:26:03 UTC
Created attachment 25295 [details]
/2.6.31-14-generic_dmesg.txt
Comment 3 Greg Kroah-Hartman 2010-03-24 02:52:17 UTC
Please do not file Ubuntu kernel issues here, file them in the ubuntu bug database.

If you can duplicate this on a kernel.org kernel, like 2.6.34-rc2 right now,
then we can work on it.

Can you?
Comment 4 Cristian Aravena Romero 2010-03-24 23:47:24 UTC
Not work for my kernel 2.6.34-rc2, testing with 2.6.33.1?
Comment 5 Cristian Aravena Romero 2010-03-25 00:04:40 UTC
Not work for my kernel 2.6.34-rc2, testing with 2.6.33.1?
Comment 6 Klaus Doblmann 2010-03-28 16:31:52 UTC
See also my bugreport here containing links to the problem being discussed on linux-usb a while ago: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/515023

I can also confirm this bug with a very recent (git-checkout from today) kernel from Linus' tree (post .34-rc2)
Comment 7 Cristian Aravena Romero 2010-03-31 01:00:23 UTC
New release - new test:
mainline:  	2.6.34-rc3  	2010-03-30
Comment 8 Cristian Aravena Romero 2010-03-31 18:55:36 UTC
Created attachment 25777 [details]
dmesg_2.6.34-rc2.26032010.txt
Comment 9 Cristian Aravena Romero 2010-03-31 19:06:30 UTC
Created attachment 25778 [details]
config-2.6.34-rc2.26032010
Comment 10 Cristian Aravena Romero 2010-03-31 21:40:11 UTC
*** Bug 15081 has been marked as a duplicate of this bug. ***
Comment 11 Cristian Aravena Romero 2010-03-31 21:59:57 UTC
Created attachment 25785 [details]
boot_dmesg-2.6.34-rc3
Comment 12 Cristian Aravena Romero 2010-03-31 22:02:32 UTC
Created attachment 25786 [details]
current_dmesg-2.6.34-rc3
Comment 13 Cristian Aravena Romero 2010-03-31 22:12:14 UTC
Created attachment 25787 [details]
config-2.6.34-rc3-31032010
Comment 14 Cristian Aravena Romero 2010-03-31 23:32:53 UTC
*** Bug 15236 has been marked as a duplicate of this bug. ***
Comment 15 Alan Stern 2010-04-01 15:43:44 UTC
Neither of the two dmesg logs in comments #8 and #12 contains anything about an I/O error.  Each one does contain a failed read of sector 63, but in both cases the read was retried successfully.  Is this because the dmesg logs don't cover the time when you tried to mount the drive?

Please collect a usbmon trace showing what happens when the I/O error occurs.  Instructions are in Documentation/usb/usbmon.txt.  The output from usbmon is a lot more compact and more informative than the usb-storage debugging messages.

Also, note that this most likely is not a bug in the kernel.  Instead it is probably caused by a bug in the Jmicron converter (those things are notoriously buggy) combined with a user program issuing commands the converter can't handle.
Comment 16 Klaus Doblmann 2010-04-02 12:50:22 UTC
Alan, we already discussed this some time back on linux-usb (topic was "strange problem regarding non-mounting usb hard drive). The date was the last days of January. You found out that something was sending two Ata passhrough commands with the second one being problematic. You also mentioned then it was unlikely to be a kernel bug.
I then took the issue tu Ubuntu's launchpad where it bounced back to the kernel. They released a fix for a specific imx51-kernel (don't have the patch at hand but I'll look it up) so maybe you could take a look at this bugreport here and decide whether this could be apply to mainline as well: https://bugs.launchpad.net/ubuntu/+source/linux-fsl-imx51/+bug/499881
Comment 17 Klaus Doblmann 2010-04-02 12:59:23 UTC
Created attachment 25818 [details]
Patch for imx51 from Ubuntu

I extracted the patch from this original diff where the copyright information can also be found: https://launchpad.net/ubuntu/+archive/primary/+files/linux-fsl-imx51_2.6.31-607.12.diff.gz
Comment 18 Klaus Doblmann 2010-04-02 13:01:51 UTC
Created attachment 25819 [details]
original usbmon trace
Comment 19 Alan Stern 2010-04-02 15:27:46 UTC
You might want to read through this thread:

    http://marc.info/?t=126927150300011&r=1&w=2

It's essentially the same problem as you are having.  It turns out the offending command is sent by the hdparm program, as invoked automatically by udev through

    /lib/udev/rules.d/85-hdparm.rules

If you have this file, and you rename it or move it somewhere else so that udev doesn't see it, you may find the problem has gone away.

In the end, something like the Ubuntu patch may be needed.  I don't like the way they wrote it, however.  Still, if there's no other choice then we'll add something similar.
Comment 20 Klaus Doblmann 2010-04-02 16:34:00 UTC
Thanks, Alan, renaming that file is a workaround - at least with the mainline kernel I compiled for myself. I remember trying this some time ago when I was on another kernel (it was either Ubuntu's -32 version or one the Ubuntu -33 mainline build) and back then it didn't have any effect.
Ho-hum, I'll go file a bug against udev in Ubuntu now, thanks Alan!
Comment 21 Klaus Doblmann 2010-04-02 16:40:54 UTC
Sorry, I mistook that file for a different one from udev someone suggested renaming and which of course didn't change anything - the issue is kernel-independent...