New: USB enumeration lockup

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

            Bug ID: 216766
           Summary: USB enumeration lockup
           Product: Drivers
           Version: 2.5
    Kernel Version: 5.19.16 and 6.0.10
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: USB
          Assignee: [email protected]
          Reporter: [email protected]
        Regression: No

Hi,

Environment:

after resuming from suspend the gnome-shell/gdm hangs because of fprintd and I was able to track this down to usb device enumeration hanging on reading the "descriptors" sysfs file. Calls to lsusb also hang on the same file.

The error can be reproduced with all recend kernels, tested with various Fedora Kernels, from:

to:

Here is the backtrace from the hanging usb read:

USB4 seems to be the integrated card reader:

The repoduction is not that easy and I'm not able to reliably reproduce the issue mostly it works if I do the following:
1. Connect to docking station with Monitors, Headset and webcam attached
2. Suspend while connected to the docking station
3. Disconnect from the docking station
4. Resume while disconnected from the docking station

Please let me know if you need any further logs I can gather them if the next hang occures.

You may reply to this email to add a comment.

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

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

--- Comment #1 from Alan Stern ([email protected]) --- Please attach a copy of the dmesg log following one of these hangs.

You may reply to this email to add a comment.

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

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

--- Comment #2 from Jan Burgmeier ([email protected]) --- Created attachment 303343
--> https://bugzilla.kernel.org/attachment.cgi?id=303343&action=edit
dmesg output after hang

Attached dmesg output

You may reply to this email to add a comment.

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

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

--- Comment #3 from Alan Stern ([email protected]) --- Judging from the log, it looks like the problem is related to the xHCI controller at 0000:06:00.3 (although another possibility is PCI, since the log includes several PCI error messages). The problem seems to begin when all the USB devices connected to that controller disappear during the second system resume and never show up again.

I suggest you send an email describing the problem (include a pointer to this Bugzilla entry) to the [email protected] mailing list and CC: the xHCI
maintainer: Mathias Nyman <[email protected]>. He'll probably have some requests for more tests you can run.

You may reply to this email to add a comment.

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

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

--- Comment #4 from Jan Burgmeier ([email protected]) --- Thanks for the fast response and analyzing the dmesg output, I will contact the mailing list directly. I assume the xHCI controller is the one where the docking station is connected via USB-C.

The used Docking station is:

You may reply to this email to add a comment.

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

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

Mathias Nyman ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

                 CC|                            |[email protected]
                   |                            |om

--- Comment #5 from Mathias Nyman ([email protected]) --- This could also be related to USB Type-C port setting in resume.

I'm guessing this dock uses DP Alt-mode, with both Display port and USB 3 over Type-C.

In both resume cases there are some error related to the display:

[drm:dm_late_init [amdgpu]] *ERROR* DM_MST: Failed to start MST [drm:amdgpu_device_ip_late_init [amdgpu]] *ERROR* late_init of IP block <dm> failed -5

After this all usb devices on usb4 and usb5 buses disconnect (xHCI 0000:06:00.3:)
There are no xhci errors in the log, just disconnects, as if Type-C port was muxed away from xHCI.

A bit later we see DP Alt mode entry after first resume, and usb devices are enumerated again.

[  136.881649] [drm] DP Alt mode state on HPD: 1
[  137.153415] [drm] DM_MST: starting TM on aconnector: 00000000018c53ab [id:

89]

After second resume we don't se this DP Alt mode entry in the log, and usb devices remain disconnected.

Not that familiar with Type-C settings, could be AMD specific

You may reply to this email to add a comment.

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

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

--- Comment #6 from Mathias Nyman ([email protected]) --- But reading usbfs shouldn't block forever either, so there's something else wrong as well.
Maybe we fails to give back an URB, or retry reading all the disconnected devices forever.

Adding xhci and usb core dynamic debug could show more info about this. before suspeding could you as root add:

mount -t debugfs none /sys/kernel/debug
echo 'module xhci_hcd =p' >/sys/kernel/debug/dynamic_debug/control echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control

You may reply to this email to add a comment.

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

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

--- Comment #7 from Jan Burgmeier ([email protected]) --- Created attachment 303360
--> https://bugzilla.kernel.org/attachment.cgi?id=303360&action=edit
dmesg usb debug weird state

You may reply to this email to add a comment.

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

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

--- Comment #8 from Jan Burgmeier ([email protected]) --- Created attachment 303361
--> https://bugzilla.kernel.org/attachment.cgi?id=303361&action=edit
dmesg with debug multiple suspend resume

You may reply to this email to add a comment.

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

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

--- Comment #9 from Jan Burgmeier ([email protected]) --- Hi Matthias,

thanks for your feedback. You are right I have also 2 Monitors connected to the docking station.

I enabled the logging and tried to reproduce the error. The behavior seems to be a bit different, the error seems to happen a bit less but after resuming when reconnecting the docking station I need to connect it twice on the first connect the monitors are not recognized.

After some tries I was able to reproduce the error, multiple suspend and resumes where needed, it seems that a longer suspend time increases the chance to get the error:

I had also one try which was even weirder, where the system seemed not to go into suspend because the backlight stayed on but after ?resume? the error occurred:

You may reply to this email to add a comment.

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