Second occurrence, 2026-08-31. Two things in the original description need
correcting: this is not a one-off, and it is not specific to the Ubuntu
kernel.
Please add the kernel-bug-exists-upstream tag.
REPRODUCED ON MAINLINE
linux-image-unsigned-7.2.0-070200-generic 7.2.0-070200.202608162350
Linux version 7.2.0-070200-generic (kernel@balboa) ... #202608162350
SMP PREEMPT_DYNAMIC Wed Aug 19 18:42:46 UTC 2026
That is a mainline-builds PPA kernel with no Ubuntu patches applied. Same
board, same iGPU, same boot cmdline as the original report. The defect is in
mainline drm/amdgpu + ttm, not in the Ubuntu delta.
FREQUENCY
Twice in four days, so "Occurred once ... rare and timing-dependent" in the
original description no longer holds:
2026-08-28 09:16:29 kernel 7.0.0-30-generic (original report)
2026-08-31 12:55:21 kernel 7.2.0-070200-generic (this one)
Both were captured by pstore.
THE WHOLE SEQUENCE COLLAPSED INTO 48 ms IN ONE PROCESS
This is the useful part. In the original report the corruption and the fatal
dereference were ten minutes and two processes apart, which made the causal
link circumstantial. This time all three events are the same task,
file-roller PID 316904, inside a single command-submission sequence:
12:55:21.088996 slab kmalloc-part-05-96 start ffff8997c7109840
pointer offset 64 size 96
12:55:21.093258 list_add corruption. prev->next should be next
(ffff8997e240ee30), but was 0000000000000000.
(prev=ffff8997c7109880).
WARNING: lib/list_debug.c:32 at
__list_add_valid_or_report+0x87/0xc0, CPU#5:
file-roller/316904
ttm_resource_move_to_lru_tail.cold+0x8/0x76 [ttm]
ttm_bo_populate+0x85/0xb0 [ttm]
ttm_bo_handle_move_mem+0x1a5/0x1e0 [ttm]
ttm_bo_bounce_temp_buffer+0xa4/0xd0 [ttm]
ttm_bo_validate+0xc0/0x190 [ttm]
amdgpu_cs_bo_validate+0xa1/0x1a0 [amdgpu]
amdgpu_cs_parser_bos.isra.0+0x4ff/0x700 [amdgpu]
amdgpu_cs_ioctl+0x14c/0x360 [amdgpu]
12:55:21.114567 list_del corruption. prev->next should be
ffff8997d152d340, but was ffff8997cda6bdc0.
(prev=ffff8997d1532820)
WARNING: lib/list_debug.c:62 at
__list_del_entry_valid_or_report+0xe4/0x10b, CPU#8:
file-roller/316904
ttm_resource_fini.cold+0xc/0x15 [ttm]
ttm_sys_man_free+0x12/0x30 [ttm]
ttm_resource_free+0xae/0x140 [ttm]
ttm_bo_handle_move_mem+0xe7/0x1e0 [ttm]
ttm_bo_validate+0xc0/0x190 [ttm]
12:55:21.136759 BUG: kernel NULL pointer dereference, address:
0000000000000008
#PF: supervisor write access in kernel mode
Oops: Oops: 0002 [#1] SMP NOPTI
RIP: 0010:ttm_lru_bulk_move_tail+0x1a5/0x360 [ttm]
amdgpu_vm_move_to_lru_tail+0x2b/0x40 [amdgpu]
amdgpu_cs_submit+0x3b8/0x6b0 [amdgpu]
amdgpu_cs_ioctl+0x21b/0x360 [amdgpu]
note: file-roller[316904] exited with irqs disabled
note: file-roller[316904] exited with preempt_count 1
THE OOPS DEREFERENCES EXACTLY THE ADDRESSES NAMED IN THE WARNING
The register state at the oops matches the pointers reported 43 ms earlier,
so this is demonstrably the same list node rather than an inference:
RAX: ffff8997e240ee30 == the "should be next" value from the list_add
report
R09: ffff8997c7109880 == the "prev=" value from the list_add report
RDX: ffff8997c7109840 == the slab object start from the slab line
RSI: 0000000000000000 == the bad prev->next that was reported as NULL
CR2: 0000000000000008
The faulting instruction is 48 89 7e 08, a write to RSI+8, with RSI zero.
Note ffff8997c7109880 = ffff8997c7109840 + 64, i.e. the damaged list_head sits
at offset 64 of a 96-byte kmalloc object, matching "pointer offset 64 size 96"
in the slab line. So the corrupted node and the node the oops walks into are
one and the same allocation. I have not tried to identify which struct that is
and would rather not guess.
For comparison, the 7.0.0-30 oops was at the same RIP offset +0x1a5 with the
same opcode, but RSI was 0x4000 rather than 0. Near-NULL there, plain NULL
here.
DAMAGED FROM THE INSERTION SIDE THIS TIME
The original stage 1 was ttm_lru_bulk_move_del via amdgpu_vm_pt_free, i.e.
page-table teardown. Here it is ttm_resource_move_to_lru_tail from
ttm_bo_populate inside a bounce-buffer move during CS buffer validation, i.e.
the insertion side. The same sublist is damaged from either direction, which
suggests the problem is the sublist's own consistency rather than one
particular caller's teardown ordering.
WHY THE WARNING IS NOT SURVIVABLE
The original description says the kernel "warns but continues". The mechanism
is worth stating explicitly, because it is why stage 1 leads deterministically
to stage 2. This kernel has:
CONFIG_LIST_HARDENED=y
# CONFIG_DEBUG_LIST is not set
so these reports come from list hardening, not from DEBUG_LIST. Under
LIST_HARDENED, __list_add_valid_or_report() returning false causes
__list_add() to bail out without performing the insertion. The warning is
therefore not advisory: the list operation is silently dropped, leaving the
bulk-move sublist half-updated with a NULL link, which the next
ttm_lru_bulk_move_tail() walk then writes through. Because that write happens
under spin_lock, a would-be per-process oops becomes a machine-wide deadlock.
(kmalloc-part-05-96 and kmalloc-rnd-01-192 in the slab lines are
CONFIG_SLAB_BUCKETS=y bucket names, not different structures.)
CASCADE AND RECOVERY
As before, the leaked LRU spinlock took down every subsequent GPU consumer.
Soft lockups began 27 s after the oops and climbed from 26 s to 551 s across
chrome:cs0, gnome-shell, KMS thread, nvtop, claude-desktop and the ttm
delayed-delete workqueue (kworker/u49:12, in ttm_bo_delayed_delete ->
ttm_resource_free). Last log entry 13:05:12, hard reset required.
Third distinct triggering application now: chrome, lact, file-roller. As the
original description argued, the application is incidental.
STILL NOT HARDWARE
Re-verified for this occurrence: no machine-check exceptions, no EDAC errors,
no NVMe errors, no OOM anywhere in the boot. The recurring
"amdgpu ... REG_WAIT timeout ... optc314_disable_crtc" message appears on
every
boot including clean ones and is unrelated.
OFFER
Since this now reproduces every couple of days, I am willing to run a debug
kernel to catch the corrupting write where it happens rather than at the point
of death. Ubuntu ships no KASAN kernel, but CONFIG_SLUB_DEBUG=y is set, so I
can boot with slub_debug=FZP for redzoning and poisoning on the TTM resource
objects. If a KASAN build would be more useful, tell me which config you want
and I will build and run it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2165729
Title:
faulting task died holding the TTM LRU spinlock (exited with irqs
disabled / preempt_count 1),
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2165729/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
