[Bug 222064] 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

[Bug 222064] 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

[bugzilla-daemon]

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: drivers_usb@kernel-bugs.kernel.org
          Reporter: zarej@svrljig.net
        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.