Follow-up to my 2026-07-21 update above — important correction to its
conclusion.
That update reported a hibernation failure on 7.0.0-28-generic (TTM
warning + failed resume + battery drain) and suggested reverting to
7.0.0-27-generic as a workaround. Since then I've been running
7.0.0-27-generic exclusively, with dozens of successful suspend and
hibernation cycles — but on 2026-08-19 the SAME failure family
reappeared on 7.0.0-27-generic, with a different and considerably worse
symptom.
## New incident: GPU hang + reset during hibernation entry, followed by
a crash storm requiring a forced power-off (kernel 7.0.0-27-generic)
Timeline (2026-08-19):
- 18:25:17 — systemd-hibernate.service starts, "PM: hibernation: hibernation
entry" logged.
- 18:26:26-29 — GPU ring timeout during the hibernation freeze phase:
amdgpu 0000:04:00.0: ring sdma0 timeout, signaled seq=1021178, emitted
seq=1021180
amdgpu 0000:04:00.0: GPU reset begin!. Source: 1
amdgpu 0000:04:00.0: Failed to disallow df cstate
amdgpu 0000:04:00.0: psp gfx command DESTROY_TMR(0x7) failed and response
status is (0x0)
amdgpu 0000:04:00.0: Failed to terminate tmr
amdgpu 0000:04:00.0: suspend of IP block <psp> failed -22
amdgpu 0000:04:00.0: GPU pre asic reset failed with err, -22 for drm dev,
0000:04:00.0
amdgpu 0000:04:00.0: MODE2 reset
amdgpu 0000:04:00.0: GPU reset succeeded, trying to resume
amdgpu 0000:04:00.0: VRAM is lost due to GPU reset!
Note "Failed to disallow df cstate" — same failure signature as the
7.0.0-28 incident above (DF C-state transition failure), now reproduced
on 7.0.0-27.
- Immediately after — hibernation aborts (systemd-hibernate.service
exits with FAILURE) and the Wayland compositor (kwin_wayland) is left
unable to allocate GPU buffers, repeatedly:
MESA: error: amdgpu: Failed to allocate a buffer:
size : 262144 bytes
domains : 4
- This degraded graphics state cascades into repeated application
crashes: a Qt QSGRenderThread segfaults, then the KDE crash handler
itself (drkonqi-coredump-launcher) segfaults repeatedly trying to
process it, in a crash-report-crashing-itself loop.
- Over the following ~2 hours (18:26 to 20:32), the machine stayed in
this state — fan running continuously, keyboard backlight stuck on,
consistent with the crash/relaunch loop consuming CPU.
- 20:32:49 — journal ends abruptly, no orderly shutdown sequence logged.
The machine had become fully unresponsive and required a hard power-off.
## Revised assessment
This is not a 7.0.0-28-specific regression as I first assumed — it's a
timing/load-sensitive amdgpu suspend-path bug that reproduces on
7.0.0-27 too, just less frequently (this is the first occurrence in
several weeks of otherwise-reliable use on that kernel). Severity is
also worse here: earlier incidents left the system failing to resume;
this one left it running but crash-looping and fully unresponsive,
requiring a hard power-off after ~2 hours.
Given this now spans multiple kernel builds, I'd suggest avoiding
hibernation on AMD Barcelo/Rembrandt iGPU laptops (amdgpu) until root-
caused — plain suspend (s2idle) has been reliable by comparison across
dozens of cycles on both kernels.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2161312
Title:
System hangs on suspend (s2idle) with kernel 7.0.0-28-generic, works
fine on 7.0.0-27
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161312/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
