I hit this again yesterday on the same kernel (7.0.0-38-generic), and
this time it ended differently.
Timeline (boot 8a6b33bf, 2026-10-14):
- 22:08:12 Resume from hibernation (the machine had been hibernated since OctÂ
11).
- 23:07:29 About 1 hour after resume, the kernel starts reporting list
corruption from gnome-shell's GPU activity: 14 list_add/list_del corruption
warnings between 23:07:29 and 23:07:31.
- 23:07:37 I requested hibernate.
- 23:07:42 "PM: hibernation: hibernation entry" is the last line in the
journal. The machine never powered off. The fan ran at full speed, which
suggests a CPU spinning, and I had to hold the power button.
No soft lockup was logged this time, presumably because logging had
already stopped once the hibernation freeze began. But the corruption
signature matches the earlier occurrence in the original report exactly:
list_add corruption. prev->next should be next (ffff8e61c780eed8), but was
0000000000000079. (prev=ffff8e6442da96a0).
WARNING: lib/list_debug.c:32 at __list_add_valid_or_report+0x87/0xc0, CPU#6:
gnome-shell/5617
CPU: 6 UID: 1000 PID: 5617 Comm: gnome-shell Not tainted 7.0.0-38-generic
#38-Ubuntu
Hardware name: LENOVO 20XF009AUK/20XF009AUK, BIOS R1NET67W (1.37) 04/16/2026
Call Trace:
ttm_resource_move_to_lru_tail.cold+0x8/0x76 [ttm]
? ttm_tt_populate+0x124/0x150 [ttm]
ttm_bo_populate+0x85/0xb0 [ttm]
ttm_bo_vm_fault_reserved+0x20d/0x2d0 [ttm]
amdgpu_gem_fault+0x9a/0x100 [amdgpu]
...
The other warnings come through the command submission path:
amdgpu_cs_ioctl -> amdgpu_cs_parser_bos -> amdgpu_cs_bo_validate ->
ttm_bo_validate -> ttm_bo_handle_move_mem -> ttm_bo_populate ->
ttm_resource_move_to_lru_tail
with list_del corruption in amdgpu_bo_move / ttm_resource_free.
For comparison, the boot in the original report (Oct 3 to 10) followed
the same pattern:
- Oct 09 22:44 resume from hibernation
- 23:00 first list_add corruption, with the same "prev->next should be next
(...8eed8), but was ..." form and the same ttm_bo_populate ->
ttm_resource_move_to_lru_tail path
- Oct 10 00:00:28 "watchdog: BUG: soft lockup" on CPUs 9 and 10
So the failure is reproducible: after resuming from hibernation,
swapped-out buffer objects are populated back in and the TTM LRU lists
become corrupted. After that the system either soft-locks while running
or hangs on the next hibernate. This matches the bug fixed upstream by:
3db7d7d583419f7b1f2e141e36418802dbb25cf8
drm/ttm: fix swapped-out resources never leaving their bulk_move range
which fixes a regression from b2ed01e7ad3d ("drm/ttm: Fix
ttm_bo_swapout() infinite LRU walk on swapout failure"), picked up in
7.0.0-28.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2170429
Title:
Soft lockup after hibernate on AMD GPU
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2170429/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
