New: External monitor over USB-C→DP adapter never recovers (stuck at 0x0 EDID) after suspend/replug — only a full reboot fixes it — Alpine Ridge (JHL6540) Thunderbolt 3 controller

https://bugzilla.kernel.org/show_bug.cgi?id=222064

            Bug ID: 222064
           Summary: External monitor over USB-C→DP adapter never recovers
                    (stuck at 0x0 EDID) after suspend/replug — only a full
                    reboot fixes it — Alpine Ridge (JHL6540) Thunderbolt 3
                    controller
           Product: Drivers
           Version: 2.5
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: USB
          Assignee: [email protected]
          Reporter: [email protected]
        Regression: No

## Summary

On a ThinkPad X1 Carbon Gen 8 (Intel Comet Lake-U, Alpine Ridge JHL6540 TB3 controller), an external monitor connected via a USB-C→DisplayPort adapter routinely fails to (re-)establish its DisplayPort alt-mode link after a suspend/resume cycle or a physical replug. The GPU (i915) reports EDID checksum/header corruption and an "Unexpected DP dual mode adaptor ID", and Hyprland/DRM shows the connector as connected but with a 0x0 mode (no valid video mode) indefinitely. Only a full system power cycle (reboot) recovers it — no in-session software action was found that clears the condition.

## System

- Model: Lenovo ThinkPad X1 Carbon Gen 8 (Type 20U9006HMX)
- BIOS: N2WET48W (2024-11-08)
- CPU/GPU: Intel Comet Lake-U, i915 0000:00:02.0 (CometLake-U GT2 [UHD Graphics])
- Thunderbolt controller: Intel Corporation JHL6540 Thunderbolt 3 [Alpine Ridge 4C 2016] (rev 02)
- 0000:05:00.0 PCI bridge (root)
- 0000:06:00.0 / 06:01.0 / 06:02.0 / 06:04.0 PCI bridges
- 0000:07:00.0 Thunderbolt 3 NHI
- 0000:2d:00.0 xHCI USB controller (this BDF shifts after a reset, e.g. to
2e:00.0)
- Kernel: 7.2.5-3-omarchy (Arch-based, x86_64)
- External monitor: Xiaomi "Mi monitor", connected via a USB-C→DisplayPort adapter (dongle), DP dual-mode (DP++)

## Symptom

After the laptop suspends and resumes (or, less reliably, after unplugging and replugging the adapter), the external monitor connector (DP-2 in Hyprland/DRM) stays reported as connected but with mode 0x0@60 — i.e. no usable video mode. The screen stays black. This can also happen without any suspend at all, just from a cold plug sometime after boot.

## Kernel log evidence

```
xhci_hcd 0000:2d:00.0: xHC error in resume, USBSTS 0x401, Reinit
typec port1-partner: PM: parent port1 should not be sleeping
EDID block 0 (tag 0x00) checksum is invalid, remainder is 141
i915 0000:00:02.0: [drm] *ERROR* Unexpected DP dual mode adaptor ID 50
EDID has corrupt header
i915 0000:00:02.0: [drm] *ERROR* Unexpected DP dual mode adaptor ID 50
EDID block 0 (tag 0x00) checksum is invalid, remainder is 18
i915 0000:00:02.0: [drm] *ERROR* Unexpected DP dual mode adaptor ID 54
EDID has corrupt header
i915 0000:00:02.0: [drm] *ERROR* Unexpected DP dual mode adaptor ID 54
```

This repeats with different adaptor-ID/checksum-remainder values across independent replug/resume attempts throughout the day, always the same
shape: xHCI hits a "broken_suspend"-style resume error on the Alpine Ridge controller, and the DP dual-mode adaptor's EDID/AUX read comes back invalid immediately after.

## What was tried (in order), and results

1. hyprctl reload — no effect (mode stays 0x0).
2. Forcing a DRM connector reprobe via
echo detect > /sys/class/drm/card1-DP-2/status (as root) — status stays connected, mode stays 0x0.
3. Forcing the connector off then re-detect
(echo off > .../status; sleep 1; echo detect > .../status) — same result.
4. Physical unplug/replug of the adapter at both the monitor end and the laptop USB-C end — no change, same EDID/adaptor-ID errors reappear in dmesg.
5. Full suspend (S3) and resume — no change; xHCI logs the same xHC error in resume, USBSTS 0x401, Reinit on every resume, and the DP link does not come back afterward.
6. PCI-level reset of just the TB3 xHCI USB function
(echo 1 > /sys/bus/pci/devices/0000:2d:00.0/remove then echo 1 > /sys/bus/pci/rescan) — the USB function cleanly re-enumerates (new BDF, e.g. 2e:00.0), but the DP-2 connector is unaffected, still 0x0. This confirms the DP tunnel is not owned by the xHCI PCI function.
7. Full PCI-level reset of the entire TB3 hierarchy from the root bridge (echo 1 > /sys/bus/pci/devices/0000:05:00.0/remove then echo 1 > /sys/bus/pci/rescan) — the entire Alpine Ridge hierarchy (bridges, NHI, xHCI, typec ports) re-enumerates from scratch, functionally as close to a live "power cycle" of the controller as the kernel's PCI core allows. DP-2 is still stuck at 0x0 afterward.
8. Only a full system reboot (real ACPI S5 power-off/on) reliably clears the condition and the external monitor comes up normally.

## Analysis

Step 6 and especially step 7 are the interesting data points: even a full software-level teardown/re-probe of the entire Thunderbolt PCI hierarchy did not recover the DisplayPort tunnel. This suggests the DP alt-mode/tunnel negotiation state for this connector is not represented in anything the Linux PCI core can reset — it likely lives in EC/PMC firmware or in a redriver/mux chip on the board that is only reset by an actual platform power cycle, not a live device removal+rescan. Given USBSTS 0x401 is a recognized "broken_suspend"-class quirk already handled defensively by xhci_hcd (see 30f3808d10f8, "xhci: Don't show warning for reinit on known broken suspend"), this looks like a case where the existing reinit path successfully recovers plain USB but does not (and structurally cannot) recover the co-tunneled DisplayPort link.

## Expected behavior

Either the DP alt-mode link should survive/recover across suspend-resume and hot-replug on this controller, or there should be some way (from software, without a full power cycle) to force the platform to redo the Type-C/DP mux negotiation for a specific port.

## Reproduction rate

Observed multiple times over one day of normal use (several suspend/resume cycles plus manual replugs), each time requiring a full reboot to recover.

## Notes for triage

- Willing to gather additional logs (acpidump, sudo dmesg full buffer, boltctl output, EC firmware version) on request.
- Not currently able to test with a direct DP/HDMI cable (no non-adapter port available on this hardware) to isolate adapter vs. platform, but the full TB3-hierarchy reset in step 7 argues against a simple "flaky dongle" explanation, since a fresh, cleanly re-enumerated controller still fails to bring the link up.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.