On 2016-03-14 10:06, Mathias Nyman wrote: > On 13.03.2016 11:16, Mike Murdoch wrote: >> >> >> On 2016-03-01 16:32, Mathias Nyman wrote: >>> On 18.02.2016 18:34, Mike Murdoch wrote: >>>> >>>> >>>> On 2016-02-18 16:12, Mathias Nyman wrote: >>>>> On 16.02.2016 23:58, main.haarp@xxxxxxxxxxxxxx wrote: >>>>>> >>>>>> >>>>>> On 2016-02-08 15:31, Mathias Nyman wrote: >>>>>>> Hi >>>>>>> >>>>>>> On 06.02.2016 19:08, Mike Murdoch wrote: >>>>>>>> Bug ID: 111251 >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I have a NEC uPD720200 USB3.0 controller in a Thinkpad W520 >>>>>>>> laptop on >>>>>>>> kernel 4.4.1-gentoo. >>>>>>>> >>>>>>>> 0e:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host >>>>>>>> Controller (rev 04) (prog-if 30 [XHCI]) >>>>>>>> Subsystem: Lenovo uPD720200 USB 3.0 Host Controller >>>>>>>> >>>>>>>> When runtime power control for this controller is disabled >>>>>>>> (/sys/bus/pci/devices/0000:0e:00.0/power/control = on), the >>>>>>>> controller >>>>>>>> works fine and reaches over 120MB/s transfer rates. >>>>>>>> >>>>>>>> When runtime power control for this controller is enabled >>>>>>>> (/sys/bus/pci/devices/0000:0e:00.0/power/control = auto), two >>>>>>>> effects >>>>>>>> can be observed: >>>>>>>> >>>>>>>> - Transfer rates are much lower at around 30MB/s >>>>>>>> - During transfers, the controller dies after a couple of seconds: >>>>>>>> >>>>>>>> At this point, a reboot is required to reactivate the controller, >>>>>>>> unloading and reloading the xhci_* modules does not work. >>>>>>>> >>>>>>> >>> >>> ... >>> >>> I did some more digging, there are a few things that need to be >>> addressed: >>> 1. We should resume USB3 bus before USB2 bus to let devices enumerate >>> as USB3 better, >>> this gives them more time to finish the link training. >>> >>> 2. After resuming xhci we don't see any port changes immediately, hub >>> thinks nothing >>> happended and stops polling the ports, hub will suspend again -> >>> xhci will try to >>> suspend. >>> 3. Roothubs will autosuspend immediately after autoresume, >>> (autosuspend timeout = 0) >>> This could be a reason why we see the "xhci_suspend" entry in the >>> log. We either >>> need to increase the autosuspend timeout, or prevent suspend if we >>> can see the pending >>> event in a xhci status register. >>> >>> inserting usb3 storage device >>> Feb 16 20:03:33 xhci_hcd 0000:0e:00.0: // Setting command ring address >>> to 0xffffe001 >>> Feb 16 20:03:33 xhci_hcd 0000:0e:00.0: xhci_resume: starting port >>> polling. >>> Feb 16 20:03:33 xhci_hcd 0000:0e:00.0: xhci_hub_status_data: stopping >>> port polling. >>> Feb 16 20:03:33 xhci_hcd 0000:0e:00.0: xhci_suspend: stopping port >>> polling. >>> >>> I got a few patches, attached. They both partially try to fix the >>> issue, and add more logging. >>> Same changes can be found in a topic branch from in: >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git >>> bug_usb3_enum_rtresume >>> >>> Any chance to try them out? >>> >>> -Mathias >> >> Hello, >> >> I've come around to testing these patches. I applied them all at once >> (did you want me to test them individually?) and they appear to fix this >> issue completely! Full speed and no dead controllers.Do you need any >> further logs? >> > > That's good news. > > Can I add your "Tested-by:" tag to two of the patches? > I'll send them as fixes after rc1 is out. > > No more logs needed as it works, I'll send the third additional debug > info > patch to usb-next later. It will be useful for future debugging > > Thanks > Mathias > > > > for further debugging this case > The third patch is just additional debug info and useful for future > debugging (or if those > > Hello, yes, feel free to add the tag. Thanks for everything! - Mike -- 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
