Another affected machine, and a request to cherry-pick the upstream fix into the
resolute 7.0 kernel.
## Hardware
- Dell Pro Max 14 Premium MA14250 (board 061K67, SKU 0D32), BIOS 1.9.0
03/31/2026
- iGPU: Arrow Lake-P [Arc Pro 130T/140T] `8086:7d51` rev 03, driver `i915`
- dGPU: NVIDIA GB206GLM RTX PRO 2000 Blackwell Laptop `10de:2d39`, 595.84 open
(unused for display)
- Internal panel: eDP-1, 1920x1200@60
- Dock: Dell Thunderbolt Dock WD22TB4, one 2560x1440 external on an iGPU-routed
DP connector
- Ubuntu 26.04, kernel 7.0.0-30-generic (7.0.0-30.30)
- KDE Plasma 6.6.6 / KWin 6.6.6 Wayland, SDDM
Note this is a *14"* Pro Max, distinct from the Dell Pro Max 16 already reported
here, and it is Arrow Lake-P rather than Meteor Lake. It is nonetheless the same
display engine: i915 loads Meteor Lake firmware for this device (`mtl_dmc.bin`,
`mtl_guc_70.bin`, `mtl_huc_gsc.bin`, `mtl_gsc_1.bin`), which is consistent with
the fix being scoped `drm/i915/mtl+`.
## Signature
Identical to the existing reports, on the eDP port:
```
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* 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 270000, found 61440)
i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] mismatch in
hw.pipe_mode.crtc_clock (expected 162240, found 36919)
i915 0000:00:02.0: [drm] *ERROR* [CRTC:150:pipe A] mismatch in
hw.adjusted_mode.crtc_clock (expected 162240, found 36919)
[drm] pipe state doesn't match!
WARNING: drivers/gpu/drm/i915/display/intel_modeset_verify.c:225
verify_crtc_state
[drm] DPLL 0: pll hw state mismatch
WARNING: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:4945
verify_single_dpll_state
```
The C10 PLL comes back parked: `clock: 270000, fracen: yes, multiplier: 140` is
expected, `clock: 61440, fracen: no, multiplier: 16` is what is found, with
`c10pll_rawhw_state` all zeroes. `use_c10: yes, tbt_mode: no, lane_count: 2`.
This is HBR (270000) rather than the HBR3 (810000) in the original report, so
the
failure is not specific to one link rate.
## Both trigger paths observed
DPMS wake with no system suspend, from `drm_mode_atomic_ioctl` on the
kwin_wayland
thread:
```
drm_mode_atomic_ioctl -> drm_atomic_commit -> intel_atomic_commit
-> intel_atomic_commit_tail -> intel_modeset_verify_crtc -> verify_crtc_state
```
s2idle resume, from the driver's own resume path:
```
i915_pm_resume -> i915_drm_resume -> intel_display_driver_resume
-> __intel_display_driver_resume -> drm_atomic_helper_commit_duplicated_state
-> drm_atomic_commit -> intel_atomic_commit -> ... -> verify_crtc_state
```
Dwell dependence on the s2idle path, same boot, same kernel, same
parameters:
| suspend entry | resume | dwell | result |
|---|---|---|---|
| 2026-08-20 17:37:39 | 2026-08-21 07:54:58 | 14 h 17 m | fails as above |
| 2026-08-21 07:57:35 | 2026-08-21 07:57:48 | 13 s | clean, no i915 errors |
## Both outputs go dark, not just the panel
Worth recording because it makes the symptom much more disruptive than "internal
panel is slow to light": the internal eDP-1 and the dock's external DP connector
are on the same DRM device (`card1` = `0000:00:02.0`). KWin issues one atomic
commit per device, so once pipe A holds a state the driver rejects, presentation
to the *external* monitor stops as well. On this machine both screens stay
black.
## Effect of the suggested parameters
With `i915.enable_panel_replay=0 i915.enable_psr=0`:
- `atomic commit failed: Device or resource busy` from KWin dropped from **1041
occurrences** in one incident to **1**. The hard wedge requiring a power cycle
is gone; the driver now degrades instead.
- The fault itself is unchanged. On the s2idle path the `Failed to bring PHY A
to
idle` and `PHY A Read 0c70` lines disappear, but `Timeout waiting for DDI BUF
A
to get active` and the identical PLL mismatch remain. Consistent with an
ordering race that the parameters move rather than remove.
This matches the existing assessment that `enable_psr=0` masks rather than
prevents. I did not test `enable_dc=0`/`enable_fbc=0` given the report that they
do not reach the race.
## Runtime PM pin does prevent it
`echo on > /sys/bus/pci/devices/0000:00:02.0/power/control` (persisted via a
udev
rule) is holding so far. Before pinning, `runtime_suspended_time` was
accumulating
(1142847), confirming the iGPU was entering runtime suspend on this machine.
## xe is not an alternative here
Both drivers claim `8086:7d51`, but `xe.ko` contains the same display code and
the
same strings — `Failed to bring PHY %c to idle.`, `Timeout waiting for DDI BUF
%c
to get active`, `Timed out waiting for DP idle patterns` — so switching drivers
cannot avoid this.
## Request
`062499cc4813` ("drm/i915/mtl+: Enable PPS before PLL") is in mainline v7.2-rc1,
backported to 7.1.y as `af128ca139d6`, released in v7.1.6, and tagged
`Cc: stable # v7.0+`. `7.0.0-30.30` does not contain it and is still affected,
and
26.04 currently offers nothing newer. Could this be picked up for the resolute
7.0 kernel?
Happy to test a proposed build on this hardware.
--
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
