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? Many thanks so far! :) Cheers, - 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
