Same regression on Meteor Lake-P (ThinkPad P1 Gen 7, 8086:7d55), adding three
things this bug does not have yet: the hung-task trace for the hard-deadlock
variant, a negative result for the runtime PM workaround from comment #17, and
a 24.04 HWE data point now that 7.0.0-31 has reached noble-updates.
Hardware
--------
- Lenovo ThinkPad P1 Gen 7 (21KVCTO1WW), Core Ultra 9 185H, BIOS N48ET34W 1.21
(2026-05-11, latest available)
- iGPU: 00:02.0 Meteor Lake-P [8086:7d55], driver i915
- dGPU: 01:00.0 NVIDIA AD106M RTX 4070 Max-Q [10de:2820], PCI class 0302
(3D controller, no display connectors), nvidia 595.84 open modules,
prime-select on-demand. Every output on this machine is wired to the iGPU.
- Panel: eDP-1 3840x2400, port_clock 540000 (HBR2, lane_count 4, use_c10 yes)
- Firmware: DMC 2.21, GuC 70.36.0, HuC 8.5.4 (the 24.04 linux-firmware)
- Ubuntu 24.04 LTS with HWE kernels, GNOME on Xorg under GDM, s2idle only
Kernels
-------
6.17.0-35.35~24.04.1 20 days uptime, 07-09 to 07-29 GOOD, 0 i915
errors
7.0.0-28.28~24.04.1 10 boots, 07-29 to 08-03 BAD, see below
6.17.0-40.40~24.04.1 4 boots, 32 days, 26 s2idle cycles, GOOD, 0 i915
errors
08-03 to today
7.0.0-31.31~24.04.1 in noble-updates since 09-03, not booted: its changelog
has no trace of 062499cc4813, "PPS before PLL", or this
bug
On 7.0.0-28 every boot that reached a panel power-down failed, 8 of 8. The two
clean boots lasted 8 and 14 minutes and never powered the panel down. Boot
durations ranged from 4.7 h to 39 h. Four of the eight ended in the unkillable
deadlock described below; the other four were rebooted before anything touched
the dead pipe again.
BIOS 1.21 was flashed in the same reboot that first booted 7.0.0-28, so on this
machine alone firmware and kernel could not be separated. The 6.17.0-40 run is
on the same BIOS 1.21 and the same nvidia 595.84, so the kernel is the only
variable that moved back.
Signature
---------
Identical to the other reports, eDP on PHY A:
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* PHY A Write 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* Timed out waiting for DP idle patterns
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 540000, found 61440)
i915 0000:00:02.0: [drm] pipe state doesn't match!
WARNING: drivers/gpu/drm/i915/display/intel_modeset_verify.c:225 at
verify_crtc_state+0x51b/0x6c0 [i915]
i915 0000:00:02.0: [drm] DPLL 0: pll hw state mismatch
WARNING: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:4945 at
verify_single_dpll_state+0x6c7/0x7e0 [i915]
c10pll_rawhw_state reads back all zero (tx 0x0, cmn 0x0, pll[0..19] all 0x0)
with the PLL parked at 61440 instead of 540000. That is HBR2, next to the
HBR3 (810000) and HBR (270000) cases already here, so the link rate is not
a factor.
Entry points seen here: s2idle resume (2 of the first 6 failures) and the
DPMS-off commit at the 900 s idle timeout, issued by Xorg through
drm_connector_property_set_ioctl. Lid close reaches the same path.
The hard-deadlock variant, with the trace
-----------------------------------------
The title describes a slow wake with a retry storm, and comment #18 describes
hard freezes with the journal cut off mid-line. Here the journal survived, and
it shows why the same PHY failure sometimes ends as a 40 s stall and sometimes
as a permanently black panel that only a reboot clears.
Once the PLL is parked, pipe A produces no vblanks. Two code paths then wait
on that pipe, and only one of them is bounded:
drm_fb_helper_damage_work -> drm_client_modeset_wait_for_vblank
times out, WARNs at drm_vblank.c:1320, returns. Survivable.
intel_commit_modeset_disables -> drm_vblank_work_flush_all
no timeout. Blocks forever while holding the modeset lock.
The second path is entered by the next attempt to disable the pipe (DPMS off,
suspend, lid close). Verbatim hung-task output, 7.0.0-28, 2026-07-31:
INFO: task Xorg:9218 blocked for more than 245 seconds.
Tainted: G W OE 7.0.0-28-generic #28~24.04.1-Ubuntu
task:Xorg state:D stack:0 pid:9218 tgid:9218 ppid:9216
Call Trace:
__schedule+0x2d0/0x660
schedule+0x27/0x90
drm_vblank_work_flush_all+0x9c/0x120
intel_commit_modeset_disables+0x274/0x4c0 [i915]
intel_atomic_commit_tail+0x32a/0xc80 [i915]
intel_atomic_commit+0x2c0/0x310 [i915]
drm_atomic_commit+0xaf/0xf0
drm_atomic_connector_commit_dpms+0xfc/0x110
drm_mode_obj_set_property_ioctl+0x1c3/0x450
drm_connector_property_set_ioctl+0x3a/0x60
drm_ioctl_kernel+0xb7/0x110
drm_ioctl+0x2ec/0x5b0
__x64_sys_ioctl+0xa5/0x100
The reports repeat from 122 s to 1228 s and the task is never released. Every
later DRM ioctl queues behind the held lock and becomes another D-state
process (reading /sys/class/backlight/*/actual_brightness is enough to add
one). kill -9 has no effect, a VT switch needs the same lock, GDM cannot
restart Xorg, and i915_wedged resets the render engines rather than display.
Everything else keeps running and the machine stays reachable over the
network; one boot ran wedged for about 20 hours before I got to it. Only a
reboot recovers.
On the taint: it is the nvidia module. The blocked stack contains only drm
and i915 frames, the failing reads are on Intel's PHY message bus, and the
dGPU has no display engine at all (class 0302), so it is not on this path.
Comment #13 has the same model reproducing with the nvidia modules absent.
Workarounds, both negative here
-------------------------------
1. Runtime PM pin, which comment #17 reports as holding on Arrow Lake-P.
echo on > /sys/bus/pci/devices/0000:00:02.0/power/control, applied
2026-08-02 00:12, runtime_status verified "active". The PHY died anyway at
03:58:48, exactly 900 s after the last input, in the DPMS-off pipe-disable
path, with zero "PM: suspend entry" in that boot. That boot went on to the
full deadlock. So on Meteor Lake-P a plain pipe disable with the device
held in D0 reaches the failure too; the D3 to D0 transition is not the
only way in. Side note for anyone using a udev rule for this: a rule
setting power/control=on on ACTION=="add" for 0000:00:02.0 came up as
"auto" after the next reboot here, so verify it after every boot.
2. No screen blanking at all: gsettings idle-delay 0, verified with xset
(screensaver timeout 0, DPMS Standby/Suspend/Off all 0), lid switch set to
lock, automatic suspend off. The PHY died anyway on 2026-08-03 16:49:32
inside a DPMS commit issued by Xorg through drm_connector_property_set_ioctl,
with no lid, lock, or suspend event in the journal before it. The X DPMS
extension stays available to every client regardless of idle timers, so
there is no userspace configuration that closes this path. This one did
not complete into the deadlock, but the panel never came back either: a
re-enable at 17:20 failed with the DDI BUF timeout.
After those two, leaving the 7.0 series is the only thing that has
worked.
Why this matters for 24.04 specifically
---------------------------------------
For 24.04 LTS, 7.0 is the terminal HWE kernel: it is the 26.04 GA kernel and
the 24.04 HWE stack does not roll past it. Upstream 7.0.y went EOL at 7.0.14
before the fix reached any stable release, so as comment #18 lays out, the fix
cannot arrive through the upstream-stable SRUs. 7.0.0-31 reached noble-updates
on 2026-09-03 without it. Without a cherry-pick, every 24.04 user with a
Meteor Lake or Arrow Lake hybrid laptop is on a kernel that cannot power the
panel down safely for the remaining life of the LTS. The only escape today is
to pin linux-hwe-6.17, which still receives updates in noble (6.17.0-42 is in
noble-updates), and that is what I have done.
Request: please cherry-pick 062499cc4813 ("drm/i915/mtl+: Enable PPS before
PLL") into linux-hwe-7.0 for noble as well as into resolute's linux. The
failure reproduces here within hours on every 7.0 boot, through both the DPMS
and the s2idle path.
Attached: the 7.0.0-28 kernel traces (the bounded WARN path, the DPMS WARN
backtraces, and the full hung-task trace), hostname scrubbed.
** Attachment added: "7.0.0-28 kernel traces: bounded WARN path, DPMS WARN
backtraces, full hung-task trace (hostname scrubbed)"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2150605/+attachment/5997362/+files/i915-7.0.0-28-hung-task-and-warn-traces.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
