Re: Recent current panic
- Reply: Guido Falsi : "Re: Recent current panic"
- In reply to: Guido Falsi : "Re: Recent current panic"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 07 Jul 2026 20:57:13 UTC
On Tue Jul 7, 2026 at 11:29 PM +0300, Guido Falsi wrote: > 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. Hmm, it's odd that it's faulting on address 0. IIRC that should always be mapped after 4add1a7a46b5cb (as Kyle mentioned). Could you send the output of sysctl machdep.efi_map please? I'm starting to build somewhat of a collection of those. :) If you need the functionality the fault is preventing, you could also have a look at https://cgit.freebsd.org/src/commit/?id=85dcdb7aad854 (beware that this would actually eat into the available memory of the system.) Otherwise the fault should be harmless. Thanks.