Follow-up to my Meteor Lake-P comments above, with a negative result that
should help scope
the SRU: backporting drm/i915/cx0: Clear response ready & error bit (Bspec
65101) onto the
current Ubuntu HWE kernel does not fix the resume stall. Mainline 7.1.x does.
Same machine and cmdline as my earlier comment (ThinkPad P1 Gen 7, 8086:7d55,
eDP-1
2560x1600 HBR3, port_clock 810000, use_c10: yes, s2idle only).
Build A — 7.0.0-30 + the Bspec 65101 backport
Built from linux-hwe-7.0 7.0.0-30.30~24.04.1 source with that one commit applied
(the two intel_clear_response_ready_flag() calls added ahead of the M2P msgbus
writes in
the read and write paths). The patch is genuinely in the shipped binary: the
built
intel_cx0_phy.o has 5 relocations against intel_clear_response_ready_flag
versus 3 in
the stock 7.0.0-30 build. So this is not a build miss.
Result after a 9 h 11 min s2idle dwell — failure is unchanged, same signature,
same
duration:
PM: suspend entry (s2idle) 02:48:07
Failed to bring PHY A to idle. 11:58:43
PHY A Read 0c70 failed after 3 retries.
PHY A Write 0c70 failed after 3 retries.
[CRTC:150:pipe A] flip_done timed out 11:58:55
[CRTC:150:pipe A] mismatch in port_clock (expected 810000, found 61440)
flip_done timed out 11:59:06
flip_done timed out 11:59:16
flip_done timed out 11:59:26
PHY A failed to change powerdown state 11:59:28
PM: suspend exit 11:59:29
46 s from first PHY error to suspend exit. Also one WARN at
drm_crtc_wait_one_vblank+0x18c reached via
intel_encoder_link_check_work_fn -> intel_ddi_link_check -> intel_dp_link_check
->
intel_modeset_commit_pipes -> intel_atomic_commit.
Build B — mainline v7.1.12
Stock kernel.ubuntu.com mainline build, no patches, same cmdline.
Result after a 47 min 56 s s2idle dwell:
PM: suspend entry (s2idle) 06:37:39
Restarting tasks: Starting 07:25:35
Restarting tasks: Done 07:25:35
PM: suspend exit 07:25:35
Zero occurrences of flip_done timed out, Failed to bring PHY, 0c70 failed,
port_clock mismatch or powerdown state across the whole boot. Resume is
subjectively
instant on keypress.
Second signal: the box also fails to *hold* the low-power state on 7.0
Comparing /sys/power/suspend_stats/last_hw_sleep against wall-clock
dwell:
- 7.0.0-30 + backport: 2929578342 us (48.8 min) of hardware sleep across a 9 h
11 min
suspend — under 9% residency.
- mainline 7.1.12: 2861759490 us (47.7 min) across a 47 min 56 s suspend —
99.6%.
So on 7.0 this is not purely a resume-path bug; the platform is not
staying down either.
Where the fix is *not*
Worth recording so nobody else burns a build on it: diffing
drivers/gpu/drm/i915/display/intel_cx0_phy.c between Ubuntu 7.0.0-30 and
mainline v7.1.12,
the C10 message-bus path differs only by a rename —
intel_clear_response_ready_flag() -> intel_cx0_clear_response_ready_flag() —
with the
same four call sites in the same positions. Build A above is therefore already
byte-equivalent to 7.1 in that function, and it still fails. Everything else
that changed in
that file is the PLL-table refactor that drops the .clock member in favour of
intel_c10pll_calc_port_clock() / intel_dpll_clock_matches(), which looks
unrelated (the
found 61440 in the mismatch is a readback off an unprogrammed PLL, i.e. a
symptom).
That points at the callers — DDI / display-power-well / DC-state sequencing —
rather
than at intel_cx0_phy.c itself. I have not bisected 7.0 -> 7.1 to name the
commits; if
someone on the kernel team can narrow it, I have the hardware and am happy to
test
candidate patches.
Caveats
- Build B ran without the nvidia DKMS module: mainline 7.1.12 is built with GCC
14 and
passes -fmin-function-alignment=16, which the gcc-13 on 24.04 rejects, so
nvidia
580.173.02 would not build against it. Build A had nvidia loaded. Per my
earlier comment
the stall is not nvidia-dependent, but noting the difference for completeness.
- Test dwell matters: this bug does not reproduce on short naps. Anything under
~45 min is
not a valid negative. last_hw_sleep is the way to prove the dwell actually
happened.
Ask
The 65101 commit is in the 7.1 tree but is not the whole fix, so an SRU that
picks only it
into 7.0 will not resolve this bug. Whatever else 7.1 carries in the CX0/DDI
resume path
needs to come with it.
--
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
