Hi Viktor,
thanks for the analysis. Unfortunately srv04 crashed again - this time WITH
processor.max_cstate=1 idle=nomwait, after ~3 days. So the params don't prevent
it;
the earlier 21-day run was most likely luck.
srv04 (6.8.12 mainline) summary:
- run 1, no params: crash after ~3d
- run 2, with params: 20d 22h, no crash
- run 3, no params: crash after ~8d 18h (KVM oops in kvm_replace_memslot 6 days
earlier)
- run 4, with params: crash after ~3d
The pattern is the same again: first an oops on a vCPU thread, then lockups.
Oct 12 19:12:31 UTC, kernel was "Not tainted" before:
BUG: kernel NULL pointer dereference, address: 000000000000000f
#PF: supervisor write access in kernel mode
CPU: 3 PID: 3174 Comm: CPU 6/KVM Not tainted 6.8.12-060812-generic
RIP: 0010:dequeue_entity+0xb9/0x530
Call Trace:
dequeue_entity / dequeue_task_fair / dequeue_task / __schedule
schedule / kvm_vcpu_block / kvm_vcpu_halt / vcpu_run
kvm_arch_vcpu_ioctl_run / kvm_vcpu_ioctl
This time the oops hit inside __schedule (rq lock held), so the host froze much
faster: soft lockups ("CPU#1 stuck for 40757s", taint G D L) in
smp_call_function_many_cond via flush_tlb_mm_range <- zap_page_range_single <-
madvise
(qemu worker, kvm_mmu_notifier_invalidate_range_end in the path).
Log attached.
Two oopses in two unrelated places (kvm_replace_memslot, CFS dequeue_entity),
both with garbage data, look to me like general memory corruption on 6.8
rather than one specific race. Regarding bit 50: even with that bit restored,
0xffff77e9d05d8b4c is still non-canonical (bit 47 = 0), and RSI contained x86
code bytes, so I'm not sure it's a single bit flip.
HW side looks clean: EDAC ce/ue counts 0 on all 4 MCs, no memory/MCE events in
iLO IML.
On the previous crash there were no RCU stalls, soft lockups or MCEs in the
kernel log before the freeze - the journal (userspace) was normal until ~4 min
before the panic.
Since all 5 AMD hosts crash on 6.8 while 5.15, mainline 6.13/6.15 and HWE 7.0
are stable (31+ days on 6.13/6.15, 20+ days on 7.0), I need to stabilize the
environment: I'm moving all AMD hosts to the noble HWE kernel (7.0.0-38),
without the extra boot params. srv04 is first, today.
If you have an idea which change between 6.8 and 6.13 could fix this kind
of corruption on Opteron 6300 / SVM, I'm happy to test a patched 6.8 kernel
on one host.
Best regards,
Radovan
** Attachment added: "srv04-panic-2026-10-13.log"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2163642/+attachment/6008666/+files/srv04-panic-2026-10-13.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2163642
Title:
Kernel panic "Attempted to kill the idle task" on AMD Opteron multi-
node NUMA under KVM (6.8.0-137)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2163642/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
