[Bug 221806] 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

[Bug 221806] 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

[bugzilla-daemon]

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: drivers_usb@kernel-bugs.kernel.org
          Reporter: perttu@thinkerit.pro
        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.