Re: xhci_hcd 0000:00:0d.0 (Panther Lake, 8086:e431): “Unknown event condition 199”, then HC died, with a TB4 dock and two displays

Re: xhci_hcd 0000:00:0d.0 (Panther Lake, 8086:e431): “Unknown event condition 199”, then HC died, with a TB4 dock and two displays

[Mika Westerberg]

Hi,

On Tue, Nov 03, 2026 at 10:18:28AM -0800, Phani Kumar wrote:
> Hi,
> 
> On a Framework Laptop 13 Pro (Panther Lake), the Type-C Subsystem xHCI
> controller (0000:00:0d.0, 8086:e431) reports a vendor-defined completion code
> 199 and then stops responding, taking down every USB 3 device behind a
> Thunderbolt 4 dock. It is triggered by Ethernet traffic through the dock. With
> two displays connected to the dock at boot it happens reliably within 1 to 4
> minutes; without displays it happens intermittently.
> 
> Hardware:
>   Laptop:   Framework Laptop 13 Pro (Intel Core Ultra Series 3)
>   CPU:      Intel Core Ultra X7 358H, microcode 0x11a
>   BIOS:     03.02 (2026-05-26), ME firmware 21.0.6.1503
>   xHCI:     00:0d.0 Intel Core Ultra (Series 3) Type-C Subsystem xHCI
> [8086:e431] (rev 01)
>   TB host:  Intel Gen16 USB4 host router (8087:a000)
>   Dock:     Razer Thunderbolt 4 Dock Chroma (TB vendor 0x127, device 0x8), NVM
> 30.0
>   Ethernet: RTL8153 (0bda:8153) inside the dock, in-tree r8152 driver
>   Displays: two 2560x1440@60 on the dock's downstream TB4 ports
>             (one USB-C to DisplayPort, one USB-C to HDMI adapter)
> 
> Kernel: 7.3.1 (Ubuntu mainline build 7.3.1-070301-generic)
> 
> Reproduction:
>   1. Boot with the dock and both displays connected.
>   2. Generate network traffic over the dock's Ethernet (e.g. open a browser).
>   3. Within about 1 minute the xHCI controller dies, and every USB 3 device
> behind the dock disconnects.
> 
> Log:
>   xhci_hcd 0000:00:0d.0: ERROR Unknown event condition 199 for slot 5 ep 3 , HC
> probably busted
>   r8152 2-3.4.5:1.0 eth0: NETDEV WATCHDOG: CPU: 11: transmit queue 0 timed out
> 5665 ms
>   r8152 2-3.4.5:1.0 eth0: Tx timeout
>   r8152 2-3.4.5:1.0 eth0: Tx status -2
>   r8152-cfgselector 2-3.4.5: reset SuperSpeed USB device number 6 using
> xhci_hcd
>   xhci_hcd 0000:00:0d.0: ERROR Unknown event condition 199 for slot 5 ep 3 , HC
> probably busted
>   r8152 2-3.4.5:1.0 eth0: Stop submitting intr, status -71
>   xhci_hcd 0000:00:0d.0: xHCI host not responding to stop endpoint command
>   xhci_hcd 0000:00:0d.0: xHCI host controller not responding, assume dead
>   xhci_hcd 0000:00:0d.0: HC died; cleaning up
>   usb 2-3: USB disconnect, device number 3
> 
> Full kernel log attached.
> 
> Observations:
>   - With only one display connected (either one), it does not happen.
>   - Booting with one display and hot-plugging the second after login did not
> trigger it in one test.
>   - With thunderbolt.dyndbg=+p, the Thunderbolt driver logs nothing in the
> window before the failure, so tunnel and bandwidth changes don't appear to be
> involved.

I agree, I checked the log you shared (although it missed some details)
tunnels look fine. One thing you can try is to run "sudo tbunnels -v" after
this happens so we can see if the USB3 tunnel is up.

You can get tbtunnels from [1].

[1] https://github.com/intel/tbtools