Also reproducing this on a **ThinkPad P1 Gen 7** (Meteor Lake), which I don't
think is on the affected list yet — the existing reports cover P1 Gen 8, ZBook
Fury G1i and Dell Pro Max 16 Plus.
**One difference worth noting: for me this does not require a suspend/resume
cycle.** The bug title and most comments describe a freeze on resume. My most
recent occurrence happened on a plain DPMS blank -> unblank while the machine
was fully awake and had never suspended during that boot. I checked the whole
boot: the only "Suspending..." entry appears *after* the failure, when I closed
the lid trying to recover. So the trigger looks like any DDI/pipe re-enable, not
resume specifically — which may widen the reproducer.
Hardware / software:
* Lenovo ThinkPad P1 Gen 7, machine type 21KWSBP400, BIOS N48ET33W 1.20
(2026-03-02)
* Ubuntu 24.04.4, linux-image-generic-hwe-24.04, kernel 7.0.0-30-generic
* iGPU: Intel Meteor Lake-P / Arc Graphics (i915) — drives the internal panel
* dGPU: NVIDIA RTX 1000 Ada, open kernel module 595.84.
Not involved: `xrandr --listproviders` shows NVIDIA-G0 with cap 0x0, crtcs 0,
outputs 0; all CRTCs/outputs belong to the i915 provider.
* Panel: eDP-1, 2560x1600 @ 165 Hz, pixel clock 777.34 MHz
* Session: GNOME 46 / mutter 46.2 on **X11** (gdm auto-selects Xorg here because
of the NVIDIA driver, per 61-gdm.rules)
Log from the most recent occurrence:
```
10:52:28 kernel: i915 0000:00:02.0: [drm] *ERROR* Failed to bring PHY A to idle.
10:52:28 kernel: i915 0000:00:02.0: [drm] *ERROR* PHY A Read 0c70 failed after
3 retries.
10:52:28 kernel: i915 0000:00:02.0: [drm] *ERROR* PHY A Write 0c70 failed after
3 retries.
10:52:29 kernel: i915 0000:00:02.0: [drm] *ERROR* Timeout waiting for DDI BUF A
to get active
10:52:30 kernel: i915 0000:00:02.0: [drm] *ERROR* Timed out waiting for DP idle
patterns
10:52:40 kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] flip_done
timed out
10:52:40 kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] mismatch in
pixel_rate (expected 777340, found 58963)
10:52:40 kernel: i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] mismatch in
dpll_hw_state
10:52:41 kernel: i915 0000:00:02.0: [drm] DPLL 0: pll hw state mismatch
10:52:41 kernel: WARNING: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:4945 at
verify_single_dpll_state+0x6c7/0x7e0 [i915], CPU#8: Xorg/4349
```
The pixel_rate read-back is ~7.6% of target (58963 vs 777340), consistent with
the C10 PLL parking at its idle frequency instead of re-locking, as described
earlier in this bug.
Xorg blocks indefinitely in the DPMS ioctl:
```
drm_ioctl -> drm_mode_obj_set_property_ioctl -> drm_atomic_connector_commit_dpms
-> drm_atomic_commit -> intel_atomic_commit_tail
-> intel_modeset_verify_crtc -> intel_dpll_state_verify
```
About 30s later the input devices start logging SYN_DROPPED as events back up
behind the wedged X server, so the machine appears totally dead — no VT switch,
no keyboard. It is easy to mistake for a login/authentication failure, since the
greeter never draws.
Frequency, from the 26 boots currently in my journal (back to
2026-07-13):
| kernel | boots | boots with the signature |
|---|---|---|
| 7.0.0-28 | 21 | 6 |
| 7.0.0-29 | 5 | 1 |
| 7.0.0-30 | 3 | 1 |
| **7.0.0 total** | **25** | **8 (32%)** |
| 6.17.0-35 | 1 | 0 |
Four occurrences were terminal (panel never recovered, forced power-off within
1-2 minutes); four recovered on their own after several minutes, with the
session continuing for hours or days afterwards.
On the 6.17 data point — it is a single boot, so treat it accordingly, but it
was a long one: 13 days 15 hours of continuous uptime, 9 suspend/resume cycles
and 18 lid transitions, same X11 GNOME session on the same hardware, with zero
occurrences. Combined with the reports elsewhere that 6.x is unaffected and that
downgrading resolves it, the 7.0.0 regression window looks right.
Note also that `i915.enable_psr=0` is reported ineffective by others, which
matches the mechanism: at the point of failure the pipe has already been torn
down by DPMS-off, so there is no PSR exit to stall. The failure is in the cx0
PHY message bus during a full DDI/pipe re-enable (`PHY A Read/Write 0c70 failed
after 3 retries`), not in the PSR path.
**Question for the maintainers:** is there any plan to backport
commit 062499cc4813 ("drm/i915/mtl+: Enable PPS before PLL") to the 24.04 HWE
kernel? 7.0.0-30 is currently the latest candidate for
linux-image-generic-hwe-24.04 and does not contain it. Right now the only
option on this hardware is pinning to a 6.x kernel, which means giving up HWE
security updates. Happy to test a proposed kernel from -proposed or a PPA — I
can reproduce within a day or two of normal use.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2157079
Title:
ubuntu 26.04 freeze on ThinkPad P1 Gen 8
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2157079/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
