Control: tags -1 + moreinfo unreproducible
Control: severity -1 normal
Hi Alison,
On 25/08/2026 9:13 pm, Alison Chaiken wrote:
> The attached files are pretty redundant. I'm not why there are so many of
> them. I hope that the additional output is helpful.
Thanks for the detailed report and especially for setting up pstore
collection. The captured oopses are exactly what's needed to reason
about this.
Having gone through the three pstore dumps, I do not think this is a
kernel bug. The evidence points quite strongly at hardware memory
corruption (bad or marginal RAM, or an unstable DDR5 memory overclock
such as an EXPO/XMP profile). Here is why.
There are two completely different crash signatures on the same machine:
1) pstore-1787614683, uptime ~122473 s (~34 h), the jbd2 kjournald2 thread:
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor write access in kernel mode
CPU: 14 PID: 551 Comm: jbd2/nvme0n1p2- Not tainted 6.12.101+deb13-amd64
RIP: jbd2_journal_try_remove_checkpoint+0x17 [jbd2]
journal_shrink_one_cp_list+0x77 [jbd2]
__jbd2_journal_clean_checkpoint_list+0x79 [jbd2]
jbd2_journal_commit_transaction+0x340 [jbd2]
kjournald2+0xaa [jbd2]
RDI is 0x0, and the faulting instruction bytes (48 8b 3f =
"mov (%rdi),%rdi") are reading jh->b_transaction from a NULL
struct journal_head. In other words the checkpoint list that
journal_shrink_one_cp_list() was walking contained a NULL/garbage
entry.
2) pstore-1787638256/...257, uptime ~6941 s (~1.9 h), on the idle task:
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor write access in kernel mode
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.12.101+deb13-amd64
RIP: _raw_spin_lock_irqsave+0x27
hrtimer_try_to_cancel.part.0+0x24
hrtimer_cancel+0x21
tick_nohz_restart_sched_tick+0x36
tick_nohz_idle_exit+0x81
do_idle+0x161
Kernel panic - not syncing: Attempted to kill the idle task!
Here RDI (the spinlock pointer) is 0x0. In hrtimer_try_to_cancel that
lock is &timer->base->cpu_base->lock, so the hrtimer's base/cpu_base
pointer was corrupted to zero. Because this happened on the idle task,
the secondary "Attempted to kill the idle task!" panic followed.
Both are NULL-pointer dereferences in very old, extremely well-exercised
core code paths (ext4/jbd2 checkpointing and the hrtimer/tick machinery),
and in both cases a pointer that is never legitimately NULL there had been
zeroed. A software defect normally reproduces in one specific path; it is
very unusual for two unrelated, mature subsystems to independently trip
over zeroed pointers hours apart. The kernel is "Not tainted" in every
capture, so there is no out-of-tree module involved, and journald also
reported the system journal as "corrupted or uncleanly shut down",
consistent with the earlier unclean crashes.
For completeness: the one plausible software candidate here, the upstream
fix "jbd2: check 'jh->b_transaction' before removing it from checkpoint",
has been in the tree since long before 6.12, so it is already present in
6.12.101 and is not the cause.
Your machine is an AMD Granite Ridge / Raphael desktop with DDR5 (two
SPD5118 DIMMs visible in the log). Rare, multi-hour, random-location
corruption like this is a very common symptom of a marginal DDR5 EXPO/XMP
profile or a failing DIMM. Could you please try the following?
1. Run a memory test: boot MemTest86 / MemTest86+ and let it run several
full passes, ideally overnight. stressapptest or "stress-ng --vm"
under load is also useful. This kind of corruption can take a while
to surface.
2. Disable any memory overclock in the BIOS (Thelio Mira, AMI 3.11.SP01):
turn off EXPO/XMP and run the RAM at JEDEC default speed/timings. If
the crashes stop, the DIMMs or the EXPO profile were the cause.
Updating to the latest System76 BIOS is also worthwhile for the
AGESA/memory-training fixes.
3. If MemTest reports errors, re-test the DIMMs one at a time and in
different slots to isolate a bad module.
4. Keep an eye on temperatures/power if the box is under load when it
hangs.
If, and only if, MemTest is completely clean across many passes with
EXPO/XMP disabled and the crashes still recur, then it is worth treating
as a possible kernel issue. In that case:
- Please retest with a newer kernel (the trixie / trixie-security 6.12
series, or the newer upstream stable currently in unstable/experimental);
a later stable point release may help.
- Boot with "slub_debug=FZP page_poison=1" (and optionally "nohz=off" to
see whether the tick path stops crashing) to catch stray writes closer
to their source.
I'll tag this moreinfo/unreproducible for now. Please let us know how the
memory test and JEDEC-default run go, and we can take it from there.
> Thanks,
> Alison
>
> ---
> Alison Chaiken [email protected]
> https://she-devel.com
> "Trying to look good limits me." -- Stefan Sagmeister
Thanks again,
Yunseong
