Re: Bug 60738 - USB 3.0 connection delay seems to be too short for HP USB 3.0 hard drive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



OK, so I had to plug the hard drive a couple of time to have the behavior. I uploaded the files (2 usbmon log files and 1 corresponding dmesg) as attachments to kernel bug 60738 ( https://bugzilla.kernel.org/show_bug.cgi?id=60738)

Here are the links to the files:
usbmon on all buses (https://bugzilla.kernel.org/attachment.cgi?id=107205)
usbmon on bus 9 (https://bugzilla.kernel.org/attachment.cgi?id=107206)
dmesg containing both manipulations (https://bugzilla.kernel.org/attachment.cgi?id=107207)

I hope it is what you were expecting.

Alexandre Demers

On 08/13/2013 01:21 PM, Kumar Gaurav wrote:
On Tuesday 13 August 2013 12:01 PM, Alexandre Demers wrote:
lsusb gives me the following:

sudo lsusb --verbose -t
/: Bus 13.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/: Bus 12.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/: Bus 11.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/: Bus 10.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/: Bus 09.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
|__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/4p, 12M
|__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid,
12M
|__ Port 1: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid,
12M
|__ Port 1: Dev 2, If 2, Class=Human Interface Device, Driver=usbhid,
12M
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/2p, 12M
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/5p, 12M
|__ Port 4: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid,
1.5M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/5p, 12M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/4p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/5p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/5p, 480M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8712u,
480M

So I assume it is a combinaision of usb-storage over xhci_hcd (the hp hard
drive is working right now and is on Bus 09).
Alex

On Tue 13 Aug 2013 02:23:50 AM EDT, Kumar Gaurav wrote:

Hi Alexandre,

I'm new to kernel development. I want to explore this bug. From you
dmesg output I'm unable to get the driver your device is using. can
you tell me which driver are you using?

regards

Kumar Gaurav

On Tuesday 13 August 2013 11:15 AM, Alexandre Demers wrote:

Sorry, here are more details.
I'm refering to https://bugzilla.kernel.org/show_bug.cgi?id=60738

To sum up:

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 in, if I can
disconnect it and reconnect it in the USB 3.0 port fast enough, it
works most of the time.

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 hard 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?

Alexandre Demers

On 08/13/2013 12:26 AM, Alexandre Demers wrote:
> Hi,
>
> As requested by Greg Kroah, please see bug 60738 - Summary: USB 3.0
connection delay seems to be too short for HP USB 3.0 hard drive.
>
> I'll be pleased to help you as much as possible.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html


--
Alexandre Demers
I'm still unable to find exact reason. So far my guess is

1. After resume driver in use in not xhci but may be EHCI
2. We aren't waiting enough. as far as i explored it is 100ms and i think it should be more.

can you provide dmesg with usbmon enabled?
and lsusb after waking up?

Regards
Kumar Gaurav

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux