[Bug 218987] New: USB devices are not detected after Save/Restore error on Intel xHC

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=218987

            Bug ID: 218987
           Summary: USB devices are not detected after Save/Restore error
                    on Intel xHC
           Product: Drivers
           Version: 2.5
          Hardware: Intel
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: USB
          Assignee: drivers_usb@kernel-bugs.kernel.org
          Reporter: repk@triplefau.lt
        Regression: No

Created attachment 306492
  --> https://bugzilla.kernel.org/attachment.cgi?id=306492&action=edit
Annotated dmesg output showing unplug/replug xhci debug logs

Hello,

With some (Genesys Logic based Hub at least) USB devices, Intel xHC raises
Save/Restore error (SRE) if it gets suspended when those devices are unplugged.
It seems that in this case (Save/Restore error) the host controller does
sometimes miss Port Status Changed Event.

In xhci_resume() host controller port is actually resumed only if Port Status
Changed Event are generated (xhci_pending_portevent() returns true). Because
such event can be missing when an SRE happened, port can remain suspended when
a USB device has been plugged to it preventing the device enumeration.

This can be seen in the attached annotated dmesg excerpt with
drivers/usb/host/xhci* and drivers/usb/core/hub.c debug print enabled:

[13903.331265] pcieport 0000:00:1d.0: Intel SPT PCH root port ACS workaround
enabled
[13904.829108] xhci_hcd 0000:3c:00.0: // Setting command ring address to
0xffc55001
[13904.829300] xhci_hcd 0000:3c:00.0: xHC error in resume, USBSTS 0x411, Reinit
<==== SRE happened on resume
[13904.829308] usb usb3: root hub lost power or was reset
[13904.829315] usb usb4: root hub lost power or was reset

...

[13904.832695] xhci_hcd 0000:3c:00.0: xhci_resume: starting usb3 port polling.
[13904.832732] xhci_hcd 0000:3c:00.0: config port 4-1 wake bits, portsc: 0x2a0,
write: 0x202a0
[13904.832747] xhci_hcd 0000:3c:00.0: config port 4-2 wake bits, portsc: 0x2a0,
write: 0x202a0
[13904.832761] xhci_hcd 0000:3c:00.0: config port 3-1 wake bits, portsc: 0x2a0,
write: 0x202a0
[13904.832773] xhci_hcd 0000:3c:00.0: config port 3-2 wake bits, portsc: 0x2a0,
write: 0x202a0
[13904.832782] xhci_hcd 0000:3c:00.0: xhci_suspend: stopping usb3 port polling.
<==== Controller goes back to suspend

There are several ways to workaround that : 
    - Disabling autosuspend (echo on > /sys/bus/usb/devices/.../power) prevent
the issue to happen
    - Triggering a resume manually after the device has been replugged (lsusb
-v, cat /dev/bus/usb/<bus>/001, ...)

To summarize I can see 2 different issues here:
    1) Genesys Logic (and maybe other) devices cause SRE error if controller is
suspend due to it being unplugged
    2) Controller does not reflect Port Status correctly when SRE happened

Unfortunately I have no idea why 1) happen. Does anyone know what can cause a
SRE error to happen, besides issuing a CMD_RUN between a save and restore ? I
have attached a usbmon trace that registers the faulty device being unplugged
if it can ba ofe any help.

Also after a quick glance at xHCI specification I didn't managed to understand
why 2) happens either. Is it expected ? Is it a known behavior of some
controller ?

It can be noted that once a problematic device has been unplugged it does not
matter which device get plugged after (could be any I tried) it won't be
recognized, so 2) appears to me to not be specific to a single device but does
seems to be a host controller issue.

In the end in order to workaround this issue I have created the attached patch.
 This forces host controller to actually try to resume if a SRE happen, even if
no Port Status Change event has been received. This has the downsize to maybe
try resuming the controller while no devices has been actually connected (false
positive) but the controller will suspend utimately still. But maybe it is
something we can live with ?

If need be, this can also be made tunable through a XHCI quirks.

Thanks

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.