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

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

[Mathias Nyman]

On 11/3/26 20:18, 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.
> 

Could you take both xhci traces, and log with xhci and usb core dynamic debug enabled?

Looks like the endpoint or its contexts may be in some odd state
(vendor event for specific endpoint, and failure to stop endpoint)

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
echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable
echo 1 > /sys/kernel/debug/tracing/tracing_on
< Reproduce issue >
Send output of dmesg
Send content of /sys/kernel/debug/tracing/trace

xHC may also refuse to add an endpoints if it doesn't have the bandwidth to handle it.

What do files under /sys/kernel/debug/usb/xhci/0000:00:0d.0/port_bandwidth'
show right after starting network traffic?

Thanks
Mathias

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

[Mathias Nyman]

On 11/11/26 01:58, Phani Kumar wrote:
> Hi Mathias, Mika,
> 
> Thanks both. Here are the captures you asked for. All runs are on
> kernel 7.3.3 with Secure Boot (lockdown) disabled.
> 
> == xHCI traces and dynamic debug (Mathias) ==
> 
> xhci_hcd and usbcore dyndbg and the xhci-hcd trace were enabled from
> boot (xhci_hcd.dyndbg=+p usbcore.dyndbg=+p trace_event=xhci-hcd:*
> trace_buf_size=80M log_buf_len=16M). Nothing overflowed. Files: Attached.
> 
> 1) xhci-debug-20261110-capture3-event199.tar.xz: the event 199 case.
>     - 52.10 s: "Unknown event condition 199 for slot 5 ep 3"
>       (slot 5 is the RTL8153 in the dock, 2-3.4.5)
>     - 52.28 s: "Unknown event condition 199 for slot 2 ep 0"
>     - 67.94 s: "xHCI host not responding to stop endpoint command",
>       "HC died; cleaning up"
>     - The trace covers 34.5 s to 73.5 s.
> 
> 2) xhci-debug-20261110-capture2.tar.xz: a run without event 199 or
>     HC died.
>     - 114.4 s: "usb 2-3-port2: link state change", "do warm reset,
>       port only", and the warm reset does not complete
>     - 115.2 s: repeated "Transfer error for slot 5 ep 3" and "ep 2",
>       with soft and hard endpoint resets
>     - later, usb2-port3 stays stuck in warm reset (portsc 0x2f4)
> 
> port_bandwidth: the same before network traffic, during traffic, and
> after the failure in run 2. After the event 199 failure it can't be
> read ("Cannot send after transport endpoint shutdown").
>    FS_BW: port[1] 90%, port[2-5] 0%
>    HS_BW: port[1] 80%, port[2-5] 0%
>    SS_BW: port[1] 0%, port[2] 90%, port[3] 90%, port[4] 89%, port[5] 90%
> 

Thanks

case 1

Tunneled USB3 link goes bad somewhere between the hub 2-3 and RTL8153
2-3.4.5 at 52.09.
All URBs behind 2-3 hub fail with transaction errors after this.
r8153 driver immediately re-queues URBs, even the ones returned with -PROTO,
so we end up in a massive endpoint reset and restart churn with
225 endpoint resets, Setting deq, and restart during  1.6 seconds.
xHC then just stops submitting any events.

case 2

In this case the link between xHC and Hub 2-3 goes bad. xhci detects
the bad link early and prevents URBs from being queueud.
Only 28 transfer errors in 100ms, xHC seems to handles this.

Several unsuccessful attempts to recover the link to 2-3 hub are done.
xHC stays functional.

I don't know why the links suddenly fails.

hub 2-3 port2 is unsuccessfully being reset all the time in both cases.

Any Idea what's connected to hub 2-3 port2? can it be unplugged? (if yes, does it help?)

Thanks
Mathias