Same failure here on an Arrow Lake-P machine (ThinkPad T1g Gen 8), Kubuntu
26.04. I've been following the issue since June, but not this bug report.
There is an upstream fix for this already exists and shipped in stable.
Details below; requesting a cherry-pick into the resolute kernel.
**The fix:** mainline commit 062499cc4813 ("drm/i915/mtl+: Enable PPS before
PLL", Imre Deak) — in mainline since v7.2-rc1, Closes the matching upstream
reports (drm/i915 gitlab issues #16042, #16064, #16098).
It was tagged `Cc: stable # v7.0+` and was backported to 7.1.y as
af128ca139d6, released in v7.1.6 (2026-08-03):
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux7.1.y&id=af128ca139d65e64d3e859faac3351870d4a20ea
I've confirmed that both hunks of the patch apply cleanly to the 7.0 tree's
drivers/gpu/drm/i915/display/intel_ddi.c.
I have not independently tested this (work machine and the signed kernel is
a requirement).
**My hardware / confirmation:** ThinkPad P1 Gen 8 (21TD000MUS), Arrow Lake-P
iGPU [8086:7d51], hybrid NVIDIA, BIOS 1.09 (N4EET23W, latest), eDP 3840x2400
at HBR3 x4 on the C10 PHY (port A). Ubuntu 26.04, kernel 7.0.0-2x-generic.
Reproducible: any suspend longer than roughly 45 minutes wakes to a
permanently black internal panel — the PHY A bring-up fails once on resume
and is never retried. Kernel signature matches the other reports here and the
upstream issues:
i915 0000:00:02.0: [drm] *ERROR* Failed to bring PHY A to idle.
i915 0000:00:02.0: [drm] *ERROR* PHY A Read 0c70 failed after 3 retries.
i915 0000:00:02.0: [drm] *ERROR* Timeout waiting for DDI BUF A to get active
i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] flip_done timed out
i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] mismatch in port_clock
(expected 810000, found 61440)
i915 0000:00:02.0: [drm] DPLL 0: pll hw state mismatch
Attached is a curated kernel-journal excerpt from one incident showing the
full arc: the failure stack on resume, the error storm, and recovery via
external-monitor hotplug (see below) — including the backtrace showing the
compositor's atomic commit doing the pipe teardown the kernel never retried
on its own.
**Recovery workaround that works today (no reboot):** plug (or unplug and
replug) an external display into a port driven by the *Intel iGPU* — on my
machine, the USB-C/DP-alt port. The hotplug forces a full modeset, which
retries the failed PHY bring-up and restores the internal panel. Measured
three times: ~1–3 minutes from plug to usable, and it works even on a
locked session. The catch, and probably why nobody here has hit on it: the
port must route to the iGPU. On these hybrid laptops many ports are wired
to the NVIDIA dGPU (as with earlier commenters whose external monitors
stayed alive while eDP stayed black) — a dGPU-routed port never touches
i915, so plugging into it does nothing for the wedged PHY.
**Recovery workaround that works today (no reboot):** plug (or unplug and
replug) an external display into a port driven by the *Intel iGPU* — on my
machine, the USB-C/DP-alt port. The hotplug makes the compositor commit a
full modeset, which finally tears down the wedged pipe: the error storm
stops within ~45 s and the session comes up on the external display
(~1–3 minutes plug-to-usable, measured three times, works even on a locked
session). Note it's teardown rather than repair — the internal panel is
left off and needs re-enabling from display settings afterwards, which is
a fresh bring-up attempt and succeeds. The catch, and probably why nobody
here has hit on it: the port must route to the iGPU. On these hybrid
laptops many ports are wired to the NVIDIA dGPU (as with earlier
commenters whose external monitors stayed alive while eDP stayed black).
A dGPU-routed port never touches i915, so plugging into it does nothing for
the wedged PHY.
One more triage-relevant observation: the same failure can occur on a cold
panel re-enable with no suspend involved, so it is not strictly a resume
bug — consistent with the "one failed bring-up, never retried" mechanism
the upstream fix addresses.
Given the fix is a small, self-contained display patch already validated in
v7.1.6+, could it be considered for an SRU into the resolute kernel?
** Attachment added: "journal excerpt showing the bug and a monitor hotplug
recovery"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2150605/+attachment/5993690/+files/lp-2150605-journal-excerpt.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2150605
Title:
`i915 Arrow Lake-S: PHY A / C10 DPLL state mismatch on resume from
long s2idle dwell — slow wake (5-10s) with retry storm`
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2150605/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
