Re: Recent current panic

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,

Kyle Evans