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. I'm asking so we don't work on the same thing twice. Waiting for a reply, Alexandre Demers On Wed, Aug 14, 2013 at 8:50 PM, Alexandre Demers <alexandre.f.demers@xxxxxxxxx> wrote: > 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
