Re: NEC uPD720200 xHCI Controller dies when Runtime PM enabled

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

 



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

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