Bug 60738

Summary:	USB 3.0 connection delay seems to be too short for HP USB 3.0 hard drive
Product:	Drivers	Reporter:	Alexandre Demers (alexandre.f.demers)
Component:	USB	Assignee:	Greg Kroah-Hartman (greg)
Status:	RESOLVED INVALID
Severity:	normal	CC:	kumargauravgupta3, xhci
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	3.10.0	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	usbmon on all bus usbmon on bus 9 only dmesg for the two usbmon logs

Description Alexandre Demers 2013-08-12 23:43:29 UTC

Most of the time, my HP USB 3.0 hard drive will not be properly mounted when booting or when connecting it.

I usually end up with something similar to the following in dmesg:
[  204.081693] usb usb9: usb wakeup-resume
[  204.081700] usb usb9: usb auto-resume
[  204.081711] hub 9-0:1.0: hub_resume
[  204.081722] hub 9-0:1.0: port 1: status 02c1 change 0001
[  204.090114] usb usb8: usb wakeup-resume
[  204.090119] usb usb8: usb auto-resume
[  204.090131] hub 8-0:1.0: hub_resume
[  204.090140] hub 8-0:1.0: port 1: status 0101 change 0001
[  204.182172] hub 9-0:1.0: state 7 ports 2 chg 0002 evt 0000
[  204.182192] hub 9-0:1.0: port 1, status 02a0, change 0001, 5.0 Gb/s
[  204.286239] hub 9-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x2a0
[  204.286250] hub 8-0:1.0: state 7 ports 2 chg 0002 evt 0002
[  204.286262] hub 8-0:1.0: port 1, status 0101, change 0001, 12 Mb/s
[  204.286285] hub 9-0:1.0: hub_suspend
[  204.286291] usb usb9: bus auto-suspend, wakeup 1
[  204.390320] hub 8-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101
[  204.492391] usb 8-1: new high-speed USB device number 8 using xhci_hcd
[  204.697607] usb 8-1: Device not responding to set address.
[  204.898877] usb 8-1: Device not responding to set address.
[  205.099841] usb 8-1: device not accepting address 8, error -71
[  205.099868] kobject: '8-1' (ffff88020d7fe098): kobject_cleanup
[  205.099870] kobject: '8-1' (ffff88020d7fe098): calling ktype release
[  205.099883] kobject: '8-1': free name
[  205.150907] kobject: '8-1' (ffff88020a605898): kobject_cleanup
[  205.150918] kobject: '8-1' (ffff88020a605898): calling ktype release
[  205.150921] kobject: '8-1': free name
[  205.150929] hub 8-0:1.0: state 7 ports 2 chg 0000 evt 0002
[  205.150939] hub 8-0:1.0: port 1, status 0100, change 0001, 12 Mb/s
[  205.254964] hub 8-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100
[  205.254978] hub 8-0:1.0: hub_suspend
[  205.254983] usb usb8: bus auto-suspend, wakeup 1

To make it work, when the USB drive is already plugged, if I can disconnect it and reconnect it in the USB 3.0 port fast enough, it works.

This problem is not seen under Windows.
According to Windows Hardware Certification Requirements (part 1):
"Next, the time between the time that RxDetect succeeds and the time that the device enters U0 can be up to 300 ms. With an extra margin for hub control transfers and other delays, the total comes to 500 ms."

Also, when the drive is plugged in a USB 2.0 port, it works like a charm.

Are we too aggressive when we are "waking up" the device?

Comment 1 Greg Kroah-Hartman 2013-08-13 00:25:37 UTC

On Mon, Aug 12, 2013 at 11:43:29PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
>            Summary: USB 3.0 connection delay seems to be too short for HP
>                     USB 3.0 hard drive

Please send this to the linux-usb@vger.kernel.org mailing list.

Comment 2 Alexandre Demers 2013-08-15 00:43:02 UTC

Created attachment 107205 [details]
usbmon on all bus

usbmon on all bus, hard drive test being made on bus 9 until it hangs.

Comment 3 Alexandre Demers 2013-08-15 00:45:15 UTC

Created attachment 107206 [details]
usbmon on bus 9 only

Same thing as usbmon on all buses, but only listening to bus 9 when I plugged it in and it didn't mount.

Comment 4 Alexandre Demers 2013-08-15 00:47:14 UTC

Created attachment 107207 [details]
dmesg for the two usbmon logs

It contains the results of both manipulations with the usb hard drive (at some point being correctly mounted, other time as it hangs).

Comment 5 Alexandre Demers 2013-08-23 13:30:29 UTC

Anything to do with Sarah Sharp's (from Intel) comment (https://plus.google.com/u/0/116960357493251979546/posts/RZpndv4BCCD) and this patch (http://marc.info/?l=linux-usb&m=137714769606183&w=2) suggested to be tested? I'll test it in the next couple of days just in case.

Comment 6 Alexandre Demers 2020-12-27 17:10:30 UTC

Closing. Even though I still have the drive around, time has shown that the problem may be coming from the drive itself. It is now very sensible to being touched or connected in a specific position.