Re: Recent current panic
- Reply: Ahmad Khalifa : "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 20:29:39 UTC
On 7/7/26 22:18, Kyle Evans wrote: > On 7/7/26 15:11, Guido Falsi wrote: >> On 7/7/26 21:54, Kyle Evans wrote: >>> On 7/7/26 14:38, Guido Falsi wrote: >>>> On 7/7/26 20:38, Warner Losh wrote: >>>>> >>>>> >>>>> On Tue, Jul 7, 2026 at 12:17 PM Alan Somers <asomers@freebsd.org >>>>> <mailto:asomers@freebsd.org>> wrote: >>>>> >>>>> On Tue, Jul 7, 2026 at 11:24 AM Guido Falsi <mad@madpilot.net >>>>> <mailto:mad@madpilot.net>> 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: >>>>> > >>>>> > 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. >>>>> > >>>>> > >>>>> > Thanks in advance. >>>>> > >>>>> > -- >>>>> > Guido Falsi <mad@madpilot.net <mailto:mad@madpilot.net>> >>>>> >>>>> That "EFI RT page fault" message looks very concerning. How >>>>> confident >>>>> are you in your system's RAM? Have you tried something like >>>>> memtest86+ ? >>>>> >>>>> >>>>> It could also be from the runtime services from EFI that we're >>>>> calling back into >>>>> as well... Best to check into both. >>>>> >>>>> Warner >>>> >>>> I'll be running a memtest soon, just to be on the safe side, but >>>> I've not seen any other instability int he machine. >>>> >>>> How could I investigate the other option? >>>> >>>> This is coming up a few seconds after the login: prompt. >>>> >>> >>> My guess would be that this is from ntpd trying to set the RTC? What >>> kind of machine/firmware is this? >>> >> >> Sounds like a reasonable guess. >> >> This is a Ryzen 5 5600G on a Gigabyte mother board. Nothing fancy >> though. It's from 3 years ago if I remember correctly. The case itself >> is much older. >> > > Does `efivar -l` also cause a fault? Sometimes firmware does stupid > things like require regions we wouldn't normally have mapped to > operate. Ahmad (CC'd) had a change to map the first page because of > firmware shenanigans in 4add1a7a46b5cb, this might be exactly the case > here. I think they had found other type-based shenanigans as well. > `efivar -l` did not trigger any further EFI fault. -- Guido Falsi <mad@madpilot.net>