Public bug reported:
# xHCI: USB device tree behind a USB-C/Thunderbolt-tunneled hub
repeatedly disconnects/re-enumerates (error -71) on ThinkPad P14s Gen 6;
stable on native PCH xHCI (USB-A) and under Windows
## Summary
On a Lenovo ThinkPad P14s Gen 6, a multi-tier USB hub device (a TESmart USB-C
KVM
containing cascaded Realtek hubs) fails to stay enumerated when connected to the
laptop's USB-C port. The full device tree enumerates once, stays up for ~2.5 s,
then
the whole tree disconnects and the kernel enters an endless
disconnect/re-enumerate
loop. Re-enumeration of the second-tier (cascaded) hubs fails with `-EPROTO
(-71)` and
`-EIO (-5)`, plus `xHCI ... invalid context state for evaluate context command`.
The same KVM on the same cable works perfectly on Windows (different machine),
and works
perfectly on this laptop when connected via a **USB-A** port (USB-A <-> USB-C
cable),
which routes USB through the native PCH xHCI instead of the Thunderbolt USB
controller
and off the DisplayPort-altmode-shared USB-C connector.
This looks like an xHCI re-enumeration bug for full-speed devices behind
cascaded hubs
on the USB-C/Thunderbolt data path.
## Hardware
- Machine: LENOVO ThinkPad P14s Gen 6, type 21QUS1CT00
- BIOS: R2WET41W (1.23) [latest available; LVFS stable is 1.22]
- SoC/platform: Intel (Arrow Lake-P iGPU 8086:7d51; Meteor Lake-P Thunderbolt 4)
- USB / TB controllers:
- 00:14.0 USB controller [8086:777d] (native PCH xHCI; buses 3/4)
- 00:0d.0 Meteor Lake-P Thunderbolt 4 USB Controller [8086:7ec0] (buses 1/2)
- 00:0d.2 / 00:0d.3 Thunderbolt 4 NHI [8086:7ec2 / 7ec3]
- iGPU: 00:02.0 [8086:7d51] (i915) — DisplayPort-altmode shares the USB-C
connector
## Software
- Distro: Ubuntu 24.04.4 LTS
- Kernel: 6.17.0-1028-oem (also reproduced on 6.17.0-1025-oem)
- Note: kernel is a locked/managed OEM kernel; cannot boot alternate kernels
(Secure Boot + lockdown=integrity + GRUB password), so an upstream/mainline
bisect was not possible on this unit.
Worked earlier on some other kernel. I don't recall the exact version.
## Device under test (the KVM)
TESmart HCK0402A1U USB-C KVM. Internal USB topology as seen by the host:
- 0bda:5411 Realtek USB2.1 hub (top-level, high-speed)
- 0bda:5411 Realtek USB2.1 hub (cascaded 2nd tier)
- 0bda:8152 Realtek USB 10/100 LAN (cdc_ether)
- 4348:7048 TESmart "CH545" hub (full-speed)
- 046d:c542 Logitech Wireless Receiver
- 3434:0d53 Keychron K5 keyboard
- 1a86:e010 TESmart HCK0402A1U HID
- 001f:0b21 Generic USB Audio (full-speed)
- (046d:08e5 Logitech C920 webcam on the 2nd-tier hub in some tests)
- 0bda:0411 Realtek USB3.2 hub (top-level, SuperSpeed)
- 0bda:0411 Realtek USB3.2 hub (cascaded 2nd tier)
On the USB-C path, USB2 lands on the PCH xHCI (00:14.0, bus 3) while
USB3/SuperSpeed
lands on the Thunderbolt USB controller (00:0d.0, bus 2).
## Steps to reproduce
1. Connect the TESmart USB-C KVM to the laptop's USB-C (Thunderbolt) port with a
USB-C cable (reproduced with the bundled cable and with a short certified
TB4 cable).
2. Observe dmesg.
## Expected
The device tree enumerates and stays connected (as it does under Windows and as
it does
via USB-A on this same laptop).
## Actual
The tree enumerates fully, holds ~2.5 s, then the entire tree disconnects and
the kernel
loops forever trying to re-enumerate. Re-enumeration of the cascaded hubs fails:
```
usb 3-1: USB disconnect, device number 7 # whole tree drops ~2.5s
after enum
...
hub 2-3.1:1.0: hub_ext_port_status failed (err = -71)
usb 3-1.1: Device not responding to setup address.
usb 3-1.1: device not accepting address 17, error -71
usb 3-1-port1: attempt power cycle
...
hub 3-1.1:1.0: Using single TT (err -71)
hub 3-1.1:1.0: config failed, can't get hub status (err -5)
```
Earlier captures on the USB-C path also show, on the full-speed control device
(TESmart CH545 / port .3):
```
usb 3-5.3: Device not responding to setup address.
usb 3-5.3: device not accepting address 67, error -71
usb 3-5.3: WARN: invalid context state for evaluate context command.
usb 3-5-port3: attempt power cycle
```
DisplayPort-altmode errors from i915 appear interleaved (same USB-C
connector):
```
i915 0000:00:02.0: [drm] *ERROR* Sending link address failed with -5
i915 0000:00:02.0: [drm] *ERROR* Failed to read DPCD register 0x60
i915 0000:00:02.0: [drm] *ERROR* Failed to read FEC DPCD register
```
## Working configuration (confirmed stable)
Connecting the KVM to a laptop **USB-A** port via a USB-A <-> USB-C cable
routes all USB
through the native PCH xHCI (00:14.0) as USB 2.0, off the Thunderbolt
controller and off
the DP-altmode-shared connector. The full tree enumerates and stays up
indefinitely with
no disconnect, no error -71, no i915 errors:
```
usb 3-6: USB2.1 Hub (0bda:5411)
usb 3-6.1: USB2.1 Hub (0bda:5411)
usb 3-6.2: USB 10/100 LAN (0bda:8152)
usb 3-6.3: CH545 (4348:7048)
usb 3-6.4: USB Audio (001f:0b21)
usb 3-6.3.1: Logitech Wireless Receiver (046d:c542)
usb 3-6.3.2: Keychron K5 (3434:0d53)
usb 3-6.3.3: TESmart HCK0402A1U (1a86:e010)
# ...no disconnects, stable
```
## Cross-check
- Same KVM + same cable on a different PC running Windows: fully stable.
- So the KVM/cable are not at fault; the issue is specific to this laptop's
USB-C/Thunderbolt USB data path under Linux.
## Things tried that did NOT fix it (USB-C path)
- usbcore.autosuspend=-1
- usbcore.quirks=0bda:5411:k,0bda:0411:k (USB_QUIRK_NO_LPM)
- usbcore.quirks=0bda:5411:ok,0bda:0411:ok (+ USB_QUIRK_HUB_SLOW_RESET)
- usbcore.old_scheme_first=1
- pcie_aspm=off (with this, the *first* enumeration completes reliably, but
the
~2.5 s drop + re-enumeration loop still occurs)
- i915.enable_dc=0
- Both laptop USB-C ports; short certified TB4 cable; USB-2-only USB-C cable
- KVM powered from its own DC supply; laptop at 100% charge
- Removing downstream peripherals
## What fixes it
- Native PCH xHCI via USB-A (USB-A <-> USB-C cable). Fully stable.
## Notes / hypothesis
The failure is on re-enumeration of the cascaded (2nd-tier) hubs after the
device tree
drops once (which appears to be a normal KVM-side re-init ~2.5 s after
connect). The
`invalid context state for evaluate context command`, `Using single TT (err
-71)` and
`hub_ext_port_status failed (err -71)` point at the xHCI slot/hub (TT) context
handling
on the Thunderbolt-tunneled USB path. Happy to capture additional traces
(dynamic debug for xhci_hcd / hub, full unfiltered dmesg, lsusb -v) on request.
ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: linux-image-6.17.0-1028-oem 6.17.0-1028.28
ProcVersionSignature: Ubuntu 6.17.0-1028.28-oem 6.17.13
Uname: Linux 6.17.0-1028-oem x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.28.1-0ubuntu3.8
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC0: gbieszczad 4126 F.... pipewire
gbieszczad 4130 F.... wireplumber
/dev/snd/seq: gbieszczad 4126 F.... pipewire
CRDA: N/A
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
Date: Mon Jul 6 17:17:03 2026
MachineType: LENOVO 21QUS1CT00
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-6.17.0-1028-oem
root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash usbcore.autosuspend=-1
i915.enable_dc=0 usbcore.quirks=0bda:5411:ok,0bda:0411:ok pcie_aspm=off
vt.handoff=7
RelatedPackageVersions:
linux-restricted-modules-6.17.0-1028-oem N/A
linux-backports-modules-6.17.0-1028-oem N/A
linux-firmware 20240318.git3b128b60-0ubuntu2.27
SourcePackage: linux-oem-6.17
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 02/24/2026
dmi.bios.release: 1.23
dmi.bios.vendor: LENOVO
dmi.bios.version: R2WET41W (1.23 )
dmi.board.asset.tag: Not Available
dmi.board.name: 21QUS1CT00
dmi.board.vendor: LENOVO
dmi.board.version: SDK0T76530 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.ec.firmware.release: 1.14
dmi.modalias:
dmi:bvnLENOVO:bvrR2WET41W(1.23):bd02/24/2026:br1.23:efr1.14:svnLENOVO:pn21QUS1CT00:pvrThinkPadP14sGen6:rvnLENOVO:rn21QUS1CT00:rvrSDK0T76530WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_21QU_BU_Think_FM_ThinkPadP14sGen6:
dmi.product.family: ThinkPad P14s Gen 6
dmi.product.name: 21QUS1CT00
dmi.product.sku: LENOVO_MT_21QU_BU_Think_FM_ThinkPad P14s Gen 6
dmi.product.version: ThinkPad P14s Gen 6
dmi.sys.vendor: LENOVO
** Affects: linux-oem-6.17 (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug noble
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2159662
Title:
xHCI: USB device tree behind a USB-C/Thunderbolt-tunneled hub
repeatedly disconnects/re-enumerates (error -71) on ThinkPad P14s Gen
6; stable on native PCH xHCI (USB-A) and under Windows
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-oem-6.17/+bug/2159662/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
