Re: Recent current panic
- In reply to: Kyle Evans : "Re: Recent current panic"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 08 Jul 2026 06:50:23 UTC
On 7/8/26 05:18, Kyle Evans wrote: > On 7/7/26 14:36, Guido Falsi wrote: >> 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. >> > Thanks for confirming- pushed in https://cgit.freebsd.org/src/commit/? > id=f5329a0d14712ae, slightly > tweaked but not in a way that will affect the outcome. > > Thanks, Thanks a lot for your support! -- Guido Falsi <mad@madpilot.net>