Hi Radovan, Yes, the stopper panic is definitely a secondary crash from the KVM oops.
Notice the faulting address 0xfffb77e9d05d8b4c in kvm_replace_memslot - bit 50 is flipped from the canonical 0xffff range. Once that vCPU thread oopsed and tainted the kernel with 'D', corrupted structures were left behind. Surviving 6 days after an oops on a 4-node NUMA host is actually impressive, but the scheduler eventually trips over it during migrate_swap. The hpilo IO_PAGE_FAULT at 0xbde0e000 is a side effect - pstore ERST tried to save the oops into ACPI reserved memory and AMD-Vi blocked it. On the journal- no need for gigabytes of userspace noise, but pls attach the snippet from those ~4 minutes before the freeze. Curious if any RCU stalls, soft lockups, or MCEs showed up right before the console went down. As for srv05 and srv07, I'd just let them keep running their soak test. But IMHO, 21 days on srv04 vs 3d and 8d without the params speaks for itself. I'd just keep processor.max_cstate=1 idle=nomwait on prod hosts. -- 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
