Created attachment 251453 [details] Kernel Panic On a recent current @fbff6d54da146e98ec2ce4ebfbb86339d4f9fa21 I see the attached kernel panic very early at boot. I can't provide a crash dump only a screenshot of the panic. It's a virtualized system on Hyper-V with two cores and 2048 MB RAM. UFS is the main filesystem and ZFS is only used for /usr/lib/debug space, if the matters. Latest working kernel is from the 7th of June.
Does this patch fix the problem for you? https://reviews.freebsd.org/D45596
(In reply to Mark Johnston from comment #1) I've since gone ahead and committed this. Please let me know if the panic persists on the latest main.
No, they call contigmalloc() from smp_rendezvous() action. This was discussed in private with wen@.
(In reply to Mark Johnston from comment #1) Hi Mark, I applied D45596 on a fresh build, but the crash is still the same.
This is due to calling contigmalloc() from smp_rendezvous(). Even passing the M_NOWAIT flag, on smaller memory sized VM it still reach vmem_xalloc in the path and tries to grab sleep lock by calling VMEM_LOCK(vm). I will try to move the contigmalloc call out of smp_rendezvous.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=d0cb4674df97aa638d5d17861c364b1625f79401 commit d0cb4674df97aa638d5d17861c364b1625f79401 Author: Wei Hu <whu@FreeBSD.org> AuthorDate: 2024-06-15 14:07:58 +0000 Commit: Wei Hu <whu@FreeBSD.org> CommitDate: 2024-06-15 14:07:58 +0000 Hyper-V: move memory alloc call for tlb hypercall out of smp_rendezvous The allocation call could result in sleep lock violation if it is in smp_rendezvous. Move it out. Also move the pcpu memory pointer to vmbus_pcpu_data since it is only used on Hyper-V. PR: 279738 Reported by: gbe Fixes: 2b887687edc25bb4553f0d8a1183f454a85d413d MFC after: 2 weeks Sponsored by: Microsoft sys/dev/hyperv/vmbus/hyperv_mmu.c | 6 +-- sys/dev/hyperv/vmbus/vmbus.c | 88 +++++++++++++++++++++++++++++---------- sys/dev/hyperv/vmbus/vmbus_var.h | 5 ++- 3 files changed, 71 insertions(+), 28 deletions(-)
d0cb4674df97aa638d5d17861c364b1625f79401 fixes the problem and the VM boots just fine again on Hyper-V.