Re: Recent current panic
- Reply: Kyle Evans : "Re: Recent current panic"
- In reply to: Kyle Evans : "Re: Recent current panic"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 07 Jul 2026 19:36:53 UTC
On 7/7/26 20:40, Kyle Evans wrote: > On 7/7/26 12:23, Guido Falsi wrote: >> Hi! >> >> I'm experiencing a fully reproducible panic on recent current. I'm not >> sure what is triggering it, looks ZFS related but I could be wrong. It >> started when I updated shortly after the latest ZFS import. >> >> I'm running 2de20c5c77cf8d5b2059054cff0e0c1fc124739d committed on Fri >> Jul 3 10:55:37 2026 -0800 (from the commit message timestamp). >> >> first just after booting I get this report on the console: >> >> EFI RT fault page fault >> >> EFI runtime trap 12: page fault while in kernel mode >> cpuid = 5; apic id = 05 >> fault virtual address = 0x0 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xb8bc1c5f >> stack pointer = 0x28:0xfffffe0121ae6c20 >> frame pointer = 0x28:0x1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current thread = 0/100045 (kernel/thread taskq) >> rdi: fffffe0121ae6ce0 rsi: fffff80002523cd0 rdx: 0000000000000000 >> rcx: 00000000b8bc31b8 r8: 00000000b8bc3448 r9: 0000000000000006 >> rax: 00000000b9254e70 rbx: fffffe0121ae6d98 rbp: 0000000000000001 >> r10: 0000000000000000 r11: 0000000000000006 r12: fffff800014df658 >> r13: 0000000000000000 r14: fffffe0121ae6e08 r15: fffffe0121ae6da8 >> >> >> The system works fine after this, except if I start building a nanobsd >> image with scripts that have worked fine till now. Then when it tries >> to install packages in the image jail system panics hard: >> > > This is fine- we trap EFIRT page faults and defang them because firmware > does stupid things at times. It could still be worth investigating to > make sure we're not doing anything out-of-spec, but I somewhat suspect > this is just harmless. The machine in question is mostly headless, I just noticed this by chance, so, while I know for sure it was not doing this a year ago, it could have come a littel while ago. Anyway I now am sure the two errors are unrelated. > >> Fatal trap 12: page fault while in kernel mode >> cpuid = 1; apic id = 01 >> fault virtual address = 0x180 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff807a74e5 >> stack pointer = 0x28:0xfffffe016f8ef9e0 >> frame pointer = 0x28:0xfffffe016f8efd70 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current thread = 15751/101480 (sh/sh) >> rdi: fffffe016369e984 rsi: fffff80035ad3000 rdx: 0000000000000000 >> rcx: 0000000000000000 r8: 0000000000006873 r9: 00000000ffffff01 >> rax: 0000000000000000 rbx: fffffe016369e984 rbp: fffffe016f8efd70 >> r10: 0000000000000001 r11: 0000000000000001 r12: fffffe016369e5a0 >> r13: 0000000000000000 r14: 0000000000000000 r15: 0000000000000000 >> panic: page fault >> cpuid = 1 >> time = 1783444123 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x36/frame >> 0xfffffe016f8ef720 >> vpanic() at vpanic+0x149/frame 0xfffffe016f8ef850 >> panic() at panic+0x43/frame 0xfffffe016f8ef8b0 >> trap_pfault() at trap_pfault+0x3a8/frame 0xfffffe016f8ef910 >> calltrap() at calltrap+0x8/frame 0xfffffe016f8ef910 >> --- trap 0xc, rip = 0xffffffff807a74e5, rsp = 0xfffffe016f8ef9e0, rbp >> = 0xfffffe016f8efd70 --- >> kern_execve() at kern_execve+0x17f5/frame 0xfffffe016f8efd70 >> sys_execve() at sys_execve+0xc2/frame 0xfffffe016f8efe00 >> amd64_syscall() at amd64_syscall+0x133/frame 0xfffffe016f8eff30 >> fast_syscall_common() at fast_syscall_common+0xf8/frame >> 0xfffffe016f8eff30 >> --- syscall (59, FreeBSD ELF64, execve), rip = 0x605cefca, rsp = >> 0x881310ee8, rbp = 0x881311360 --- >> KDB: enter: panic >> >> >> Anyone can help I can trigger this easily. If someone could give me >> some steps to perform in the debugger to extract more information I >> can do that. >> > > This looks remarkably what I have a fix for here: https:// > reviews.freebsd.org/D58063 > > If nanobsd is trying to use qemu-user-static / imgact_binmisc, this > could easily explain it. I expect to have a minute to land this here > within the next 6 hours or so. > Yes, I forgot to mention in the report the NanoBSD images are for raspberry, so yes, I'm using qemu-user-static. A quick recompile with your patch fixed this issue and now I can compile images successfully. Thanks a lot, I can followup with a report to your review if needed. -- Guido Falsi <mad@madpilot.net>