Date: Tue, 9 Sep 2025 09:50:18 +0400 From: Oleg Cherkasov <o1e9.cherkasov@yandex.com> To: questions@freebsd.org Subject: Re: Fatal trap 12: page fault while in kernel mode swapper Message-ID: <78f6ce09-5870-4f96-ae9e-d6120f8407dc@yandex.com> In-Reply-To: <a7f76c69-2f4c-c570-923e-204188750aee@nerdbynature.de> References: <15f82cb8-32be-e1ce-e0ca-db66b59542f9@xs4all.nl> <a7f76c69-2f4c-c570-923e-204188750aee@nerdbynature.de>
index | next in thread | previous in thread | raw e-mail
On 07.01.2025 19:09, Christian Kujau wrote: > On Sun, 5 Jan 2025, Marco Beishuizen wrote: > > A similar splat was reported on freebsd-current, quite recently actually: > > | Re: EFI RT page fault in init pid = 1 > | https://marc.info/?l=freebsd-current&m=173599133021897&w=2 > > A bit puzzling that this also happens for your 14.2-STABLE system. Maybe > check back with freebsd-current, "a developer might be interested" someone > wrote :-) The same happened on one of my hosts less than 24 hours ago, a day after the planned upgrade to 14.3 (running 14.3-RELEASE-p2). The system has two ZFS pools, and both were successfully scrubbed after the upgrade a few days ago. Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 06 fault virtual address = 0xc84bb018 fault code = supervisor read data, page not present instruction pointer = 0x20:0xc8799cdf stack pointer = 0x28:0xfffffe00f9e58a80 frame pointer = 0x28:0xfffffe00f9e58cb0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (thread taskq) rdi: fffffe00f9e58d18 rsi: fffff80001b31c60 rdx: 00000000c84bb018 rcx: 00000000c8790004 r8: 0000000000000008 r9: fffffe00f9e58df7 rax: 00000000c84bb018 rbx: 0000000000000000 rbp: fffffe00f9e58cb0 r10: 0000000000000000 r11: 000000000000001c r12: fffff800012e5d58 r13: 0000000000000000 r14: fffffe00f9e58e20 r15: fffffe00f9e58dc0 trap number = 12 EFI RT page fault Not sure what caused that, especially since there are no timestamps and the system is hosting Bareos SD pools, so it most likely happened during some backup jobs running, as a best guess. Would force the scrubbing on both pools then. Oleghelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?78f6ce09-5870-4f96-ae9e-d6120f8407dc>