[BUG] Type-C Subsystem xHCI (8086:e331, Panther Lake) — repeated err -71 / port reset failures under sustained DP+HID load

[BUG] Type-C Subsystem xHCI (8086:e331, Panther Lake) — repeated err -71 / port reset failures under sustained DP+HID load

[Rodolfo Semprevivo]

Hardware

* Laptop: ASUS ROG Zephyrus G16 (2026), model GU606AX
* CPU: Intel Core Ultra 9 386H (Panther Lake)
* Affected controller: 0000:00:0d.0 "Core Ultra Processors (Series 3)
    Type-C Subsystem xHCI" [8086:e331] (separate from the Thunderbolt
    DMA0 controller at 0000:00:0d.2 [8086:e333], which is unaffected)
* Distro: CachyOS (Arch-based)
* Kernel: 7.2.6-1-cachyos (also reproduced on 6.18.52-1-cachyos-lts)
* linux-firmware: 1:20260916-1 (current at time of report)


Connected device

ASUS ProArt PA169CDV pen display (4K, USB-C with DP Alt Mode, integrated 
USB hub for pen digitizer + touch + a VLI USB2.0 Billboard device), 
connected via a certified USB4 20Gbps cable to the laptop's left-side 
USB-C/Thunderbolt-capable port. The same cable and monitor work 
correctly (4K@60Hz) on another laptop (older Alder Lake-based ASUS ROG 
Zephyrus, Intel + NVIDIA hybrid).


Problem description

When the external monitor is connected at 3840x2160@60Hz, the downstream 
USB hub inside the monitor enumerates correctly (pen digitizer, 
touchscreen, and a VLI USB2.0 Billboard control device all appear 
normally), but within ~10-30 seconds the ports begin failing resets and 
the entire hub disconnects:

|usb 3-1-port1: cannot reset (err = -71) usb 3-1-port1: cannot reset 
(err = -71) [... repeated ...] usb 3-1-port1: Cannot enable. Maybe the 
USB cable is bad? usb 3-1-port1: cannot disable (err = -71) usb 
3-1-port2: cannot reset (err = -71) [... same pattern on port2 ...] usb 
3-1.1: USB disconnect, device number N usb 3-1.2: USB disconnect, device 
number N usb 3-1.4: USB disconnect, device number N usb 3-1.5: USB 
disconnect, device number N usb 3-1: reset high-speed USB device number 
N using xhci_hcd usb 3-1: device descriptor read/64, error -71 usb 3-1: 
USB disconnect, device number N|

The external monitor shows "No Signal" / "USB Type-C No Signal" once 
this occurs.

Reproduction is 100% consistent at 3840x2160@60Hz. The same physical 
port, cable, and monitor work reliably at:

* 3840x2160@30Hz
* 1920x1080@60Hz

This was verified to be independent of which GPU drives the DP output: 
the laptop has a MUX switch (Intel Xe iGPU / NVIDIA RTX 5090 dGPU). 
Forcing the dGPU-only mode (NVIDIA driving the port instead of Xe) 
reproduces the identical err -71 pattern, ruling out a GPU-driver-side 
cause.


Things already ruled out

* Cable: same cable confirmed working at 4K@60Hz on a different
    (older, Alder Lake) laptop with the same monitor.
* GPU/driver routing: identical failure under both Xe (|xe| driver,
    card0-DP-2) and NVIDIA (|nvidia| driver, card1-DP-1) via MUX switch.
* Firmware: |fwupdmgr get-updates| reports all firmware (EC/BIOS/etc.)
    up to date, no updates available.
* Kernel: reproduced on both current CachyOS kernel (7.2.6-1) and LTS
    (6.18.52-1).
* linux-firmware: current as of report date.
* xhci_hcd.quirks=0x2 (reset-on-resume) kernel parameter: no effect,
    identical failure pattern.
* Driver binding: |lspci -nnk| confirms all Panther Lake controllers
    (xe, thunderbolt, xhci_hcd, iwlwifi, etc.) have their expected
    kernel driver bound; no unbound devices found.


lspci output for the affected controller

0000:00:0d.0 USB controller [0c03]: Intel Corporation Core Ultra 
Processors (Series 3) Type-C Subsystem xHCI [8086:e331] Kernel driver in 
use: xhci_hcd


Request

Given that the error is consistently tied to the higher-bandwidth mode 
(4K@60Hz, which pushes more sustained DP AUX/HPD and USB traffic through 
this specific Type-C xHCI controller) and reproduces identically 
regardless of GPU/driver backing the DP output, this looks like it could 
be a Panther Lake-specific xHCI/Type-C subsystem timing or 
power-negotiation issue rather than a cable or userspace configuration 
problem. Happy to provide additional logs (full dmesg, usbmon capture, 
lsusb -v) on request.

Reporter: (Rodolfo Semprevivo/rodolfo@semprevivo.ch)

Panther Lake UCSI: PPM forces DP alt mode pin assignment D (2 lanes) for C/E-only partner, no 4K60 (was: [BUG] Type-C Subsystem xHCI (8086:e331, Panther Lake) — repeated err -71 / port reset failures under sustained DP+HID load)

[Rodolfo Semprevivo]

Hi,

follow-up to my report below, with a corrected analysis. The xHCI was
the wrong suspect: the -71 errors come from the monitor's internal USB
2.0 hub, which sits on the standalone xHCI (8086:e37d, 00:14.0), not on
8086:e331. They only appear because the monitor resets when the DP link
fails.

Root cause: on the left TB4 port the PPM/EC configures DP alt mode with
pin assignment D (2 lanes), although the monitor only advertises C and E:

   port0-partner.0: svid ff01, active yes, vdo 0x00140045
   displayport/pin_assignment: C E   (nothing selected)
   displayport/configuration: [USB] sink
   xe: Port D/TC#1: TC port mode reset (disconnected -> dp-alt) pin 
assignment: D max lanes: 2
   xe: [LTTPR 1] Link Training passed at link rate = 540000, lane count = 2

2x HBR2 is not enough for 3840x2160@60 (594 MHz), so the picture drops
regardless of bpc/HDR. Lower resolutions at 60 Hz work. This also
explains why the dGPU route via the MUX failed identically: the lane
split is decided by the firmware, not by the GPU driver.

For comparison, an Alder Lake ASUS GU603ZW on the same kernel, with the
same monitor and cable:

   i915: Port D/TC#1: ... pin assignment: C max lanes: 4
   i915: Link Training passed at link rate = 540000, lane count = 4

and 4K60 is stable.

Linux cannot correct this. Writes to pin_assignment/configuration fail
with EOPNOTSUPP:

   typec_displayport port0-partner.0: firmware doesn't support alternate 
mode overriding
   ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-95)

So this looks like a firmware issue (reported to ASUS as well).
Questions:
1. Is the PPM choosing pin assignment D for a partner that does not
    advertise D a known issue on Panther Lake?
2. Should Linux warn about it (partner VDO lacks D but FIA reports D),
    or avoid the resulting 2-lane DSC mode?

System: ASUS ROG Zephyrus G16 GU606AX (Panther Lake, Core Ultra 9 386H),
BIOS GU606AX.304, kernel 7.3.0-4 (CachyOS), monitor ASUS ProArt
PA169CDV. Bug report: https://paste.cachyos.org/p/83e1bcf.log
Full drm.debug log available on request.

Thanks,
Rodolfo

Re: Panther Lake UCSI: PPM forces DP alt mode pin assignment D (2 lanes) for C/E-only partner, no 4K60 (was: [BUG] Type-C Subsystem xHCI (8086:e331, Panther Lake) — repeated err -71 / port reset failures under sustained DP+HID load)

[Heikki Krogerus]

On Fri, Oct 23, 2026 at 10:27:32PM +0200, Rodolfo Semprevivo wrote:
> Hi,
> 
> follow-up to my report below, with a corrected analysis. The xHCI was
> the wrong suspect: the -71 errors come from the monitor's internal USB
> 2.0 hub, which sits on the standalone xHCI (8086:e37d, 00:14.0), not on
> 8086:e331. They only appear because the monitor resets when the DP link
> fails.
> 
> Root cause: on the left TB4 port the PPM/EC configures DP alt mode with
> pin assignment D (2 lanes), although the monitor only advertises C and E:
> 
>   port0-partner.0: svid ff01, active yes, vdo 0x00140045
>   displayport/pin_assignment: C E   (nothing selected)
>   displayport/configuration: [USB] sink
>   xe: Port D/TC#1: TC port mode reset (disconnected -> dp-alt) pin
> assignment: D max lanes: 2
>   xe: [LTTPR 1] Link Training passed at link rate = 540000, lane count = 2
> 
> 2x HBR2 is not enough for 3840x2160@60 (594 MHz), so the picture drops
> regardless of bpc/HDR. Lower resolutions at 60 Hz work. This also
> explains why the dGPU route via the MUX failed identically: the lane
> split is decided by the firmware, not by the GPU driver.
> 
> For comparison, an Alder Lake ASUS GU603ZW on the same kernel, with the
> same monitor and cable:
> 
>   i915: Port D/TC#1: ... pin assignment: C max lanes: 4
>   i915: Link Training passed at link rate = 540000, lane count = 4
> 
> and 4K60 is stable.
> 
> Linux cannot correct this. Writes to pin_assignment/configuration fail
> with EOPNOTSUPP:
> 
>   typec_displayport port0-partner.0: firmware doesn't support alternate mode
> overriding
>   ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-95)
> 
> So this looks like a firmware issue (reported to ASUS as well).
> Questions:
> 1. Is the PPM choosing pin assignment D for a partner that does not
>    advertise D a known issue on Panther Lake?

I have not heard of this particular problem before.

> 2. Should Linux warn about it (partner VDO lacks D but FIA reports D),
>    or avoid the resulting 2-lane DSC mode?

You tell me. If you think that this would be useful, prepare the patch
for it.

> System: ASUS ROG Zephyrus G16 GU606AX (Panther Lake, Core Ultra 9 386H),
> BIOS GU606AX.304, kernel 7.3.0-4 (CachyOS), monitor ASUS ProArt
> PA169CDV. Bug report: https://paste.cachyos.org/p/83e1bcf.log
> Full drm.debug log available on request.

Thanks,

-- 
heikki