New: Right-side USB-A port fails SuperSpeed link training on Lenovo ThinkPad X13 Gen 5 (Meteor Lake, xhci_hcd 8086:7e7d) — works on Fedora 6.19.300, fails on 6.18.39 and 7.1.4

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

            Bug ID: 221806
           Summary: Right-side USB-A port fails SuperSpeed link training
                    on Lenovo ThinkPad X13 Gen 5 (Meteor Lake, xhci_hcd
                    8086:7e7d) — works on Fedora 6.19.300, fails on
                    6.18.39 and 7.1.4
           Product: Drivers
           Version: 2.5
          Hardware: Intel
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: USB
          Assignee: [email protected]
          Reporter: [email protected]
        Regression: No

Hardware:
Lenovo ThinkPad X13 Gen 5 (21LVS3U900), Intel Core Ultra 7 165U (Meteor Lake) USB controller: Intel Corporation Meteor Lake-P USB 3.2 Gen 2x1 xHCI Host Controller [8086:7e7d] (rev 20), driver xhci_hcd

Problem:
The right-side USB-A port (physical_location panel=right; USB2 companion port bus3/port5, SuperSpeed port bus4/port1, both on the same 00:14.0 xHCI controller alongside the internal camera/fingerprint reader/Bluetooth, which work fine) fails to enumerate any device. Left-side USB-A and both USB-C ports work normally.

Confirmed NOT a hardware fault: the exact same USB drive works reliably, repeatedly, on a Fedora 44 LiveCD (kernel 6.19.300) in the same port.

Kernel versions tested on NixOS (vanilla/mainline builds via nixpkgs), both fail identically:
- 6.18.39 (nixpkgs linuxPackages, i.e. an older stable branch)
- 7.1.4 (nixpkgs linuxPackages_latest)

Symptom (with xhci_hcd/xhci_pci dynamic debug enabled):

xhci_hcd 0000:00:14.0: Port change event, 3-5, id 5, portsc: 0x20ae1 xhci_hcd 0000:00:14.0: handle_port_status: starting usb3 port polling. xhci_hcd 0000:00:14.0: Get port status 3-5 read: 0x20ae1, return 0x10301 xhci_hcd 0000:00:14.0: clear port5 connect change, portsc: 0xae1 xhci_hcd 0000:00:14.0: Get port status 3-5 read: 0xae1, return 0x301 xhci_hcd 0000:00:14.0: Port change event, 3-5, id 5, portsc: 0x202a0 xhci_hcd 0000:00:14.0: handle_port_status: starting usb3 port polling. xhci_hcd 0000:00:14.0: Get port status 3-5 read: 0x202a0, return 0x10100 xhci_hcd 0000:00:14.0: clear port5 connect change, portsc: 0x2a0 xhci_hcd 0000:00:14.0: Get port status 3-5 read: 0x2a0, return 0x100 [... repeated Get port status 0x2a0 ...]
xhci_hcd 0000:00:14.0: xhci_hub_status_data: stopping usb3 port polling

Interpretation: on connect, CCS (connect status) briefly goes to 1 with link state "Polling" (SuperSpeed link training in progress), then within ~2.3ms drops back to CCS=0 with link state "RxDetect". The kernel retries polling for ~130ms then gives up. This sequence is 100% deterministic and reproducible — identical portsc values and timing on every attempt, across both kernel versions above.

Things ruled out during troubleshooting:
- Not a loose/mechanical connection: laptop stationary, port physically fine, confirmed reliable on Fedora LiveCD with many repeated plug/unplug cycles.
- Not device-level USB autosuspend: usbcore.autosuspend=-1 kernel param set and confirmed active (/sys/module/usbcore/parameters/autosuspend = -1).
- Not USB roothub runtime PM: forced power/control=on on both usb3 and usb4 roothubs, no change.
- Not PCIe ASPM: forced pcie_aspm policy to "performance", no change, identical portsc trace.
- Not PCI device runtime PM: 0000:00:14.0 power/runtime_status was "active" throughout.
- thinkpad_acpi loads and initializes normally; no ACPI errors in dmesg around boot or around the 00:14.0 device.
- boltctl / bolt (Thunderbolt security) not relevant — this is a plain USB2/USB3 port on the classic xHCI controller (00:14.0), not the USB4/Thunderbolt controller (00:0d.x).

Requesting help identifying what Fedora's kernel build (6.19.300, likely with Red Hat/Fedora-specific patches or a different xhci_pci config/quirk) does differently that allows this port to work, versus a vanilla/mainline kernel build of both an older (6.18.39) and much newer (7.1.4) version, which fail identically.

Happy to test patches or provide additional logs (full dmesg, lspci -vvv, port_status via debugfs, etc.) on request.

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

The Linux kernel's regression tracker (Thorsten Leemhuis) ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #1 from The Linux kernel's regression tracker (Thorsten Leemhuis) ([email protected]) --- 6.18.39 is younger then 6.19.y, so it might be a regression that was introduced
in a recent backport. You might want to try if older 6.18.y released work – and
if they did, check if 7.2-rc5 is affected as well and bisect within the 6.18.y
series: https://docs.kernel.org/admin-guide/bug-bisect.html

You may reply to this email to add a comment.

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