Two things not yet in this bug: the no-suspend path is also clean on 7.1.x,
and there is a recorded reason why some journals here die and others survive.
Everything else I had prepared is already covered by #16, #19 and #20.
Why the journal dies -- the console lock, not just the modeset lock
-------------------------------------------------------------------
#20 remarks that its journal survived, in contrast to the cut-off-mid-line
reports in #18 and in my #9. On this machine the reason is on record. On
7.0.0-22, in a boot carrying 56 lines of the PHY A / DPLL signature, the
hung-task detector caught two tasks, one of them journald itself:
INFO: task systemd-journal:617 blocked for more than 122 seconds.
task:systemd-journal state:D
__mutex_lock_slowpath -> mutex_lock -> tty_open -> chrdev_open
-> do_dentry_open -> vfs_open
INFO: task 9:84842 blocked for more than 122 seconds.
__down -> down -> console_device -> tty_lookup_driver -> tty_open
So alongside the modeset lock in #20's trace, the console semaphore is held as
well, and journald blocks on it as soon as it touches a tty. Nothing reaches
the journal after that, which is exactly the "cut off mid-line" pattern. It is
loss of evidence rather than proof of a dead machine: in that instance a clean
shutdown still completed afterwards (systemd-shutdown, filesystems unmounted),
so the system was alive behind a dead display.
Reading my own four July freezes with that in mind: three end mid-cascade with
60-130 s to the next boot, one goes silent for seven hours after the cascade
and then stops. Only a long press on the power button recovered them, and I
never tested network reachability, so I cannot say whether those were #20's
unbounded wait or something worse. If it recurs I will check from another host
before power-cycling; anyone else hitting this, please do the same, because the
local console is the one thing that is provably unreliable here.
The no-suspend path on a fixed kernel
-------------------------------------
Comment #2 describes the failure with no suspend at all -- panel powered down
through inactivity, system still running -- and #20 documents that path with a
trace, reaching the pipe disable through DPMS. Every clean result posted so
far, #19 included, measures s2idle dwell, and #20's good kernel is 6.17, from
before the regression. So the no-suspend path has not yet been shown clean on
a kernel that carries the fix.
ThinkPad P1 Gen 8, Arrow Lake-P [8086:7d51], BIOS N4EET24W 1.10, Ubuntu 26.04,
internal eDP-1 (pipe A / DDI A / PHY A), undocked, on AC. Stock mainline
7.1.9-070109-generic, no local patches. Same machine as comment #9.
24./25.08. 11 h 31 m no nvidia (taint 0)
25.08. 1 h 52 m nvidia 595.84 loaded
Both: machine left running, panel powered down through inactivity, zero
"PM: suspend entry" in the journal for the whole window. Zero hits across each
boot for PHY A, DDI BUF, DP idle patterns, pll hw state mismatch, flip_done,
commit wait, and zero i915 *ERROR*.
One detail that may extend the userspace conclusion in #20: my sessions are KDE
on Wayland, so the X DPMS extension is not in the picture, and the pipe disable
was still reached on 7.0.0-27. The path does not look closable from userspace
there either.
--
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
