Reproducible panic on 14.1 and 14.2
- Reply: Jan Bramkamp : "Re: Reproducible panic on 14.1 and 14.2"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 07 Jun 2025 04:37:25 UTC
I've been having cases of a reproducible panic on 14.1 and 14.2, but not on 14.0. The situation is that I have a 14.2 server running a number of jails, including some that have not been updated since 12.x days (yes, yikes, I know -- but it also shouldn't panic). One of those jails when shutting down after some length of time (but not immediately, so I cannot just on a whim do this) will reliably panic the system. Additionally, when it goes down it goes down pretty hard, including softupdate/journal errors that I need to manually fsck.. though this MIGHT be related to my use of geom mirror and unresolved dirty mirror status; since I know it is coming at this point I have taken steps to shield me from this, including going to single user immediately upon startup and killing all mirrors and force rebuilding them. This didn't happen on 13.x, and it didn't happen on 14.0, it only started when I upgraded to 14.1, and unfortunately continued to 14.2 (I reboot very rarely, only for security updates). Below is the most recent crash dump, I have 2 captured at this level now, they are both consistent in in both what process is running (ruby), and where the panic is): The ruby process in question is *most likely* (but I do not and cannot know) connected to an apache/mod_passenger process. This is also a custom kernel, and I had debugging symbols off. FInally, I am in the process of retiring that freebsd12 jail for multiple reasons, not the least of which being this panic, so I will not be able to reproduce; I just post this in the off chance that someone goes 'oh, I made this change to freebsd12 syscals around 14.1..I wonder if ....' Fatal trap 12: page fault while in kernel mode cpuid = 15; apic id = 0f fault virtual address = 0x40 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff805f1f56 stack pointer = 0x28:0xfffffe01ca7dab98 frame pointer = 0x28:0xfffffe01ca7dabe0 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 = 8564 (ruby26) rdi: 0000000000000000 rsi: fffffffffffff000 rdx: 0000000000000000 rcx: fffffffffffff000 r8: 000000000000003b r9: 0000000000000000 rax: fffff80001e87e00 rbx: fffffe01c91db718 rbp: fffffe01ca7dabe0 r10: 0000000000000218 r11: ffffffff80664390 r12: fffffe01c91db85c r13: fffffe01c91db7d8 r14: fffff80c538c1740 r15: fffffe01c91db5c0 trap number = 12 panic: page fault cpuid = 15 time = 1748715227 KDB: stack backtrace: #0 0xffffffff80640d43 at kdb_backtrace+0x63 #1 0xffffffff805f864f at vpanic+0x12f #2 0xffffffff805f8513 at panic+0x43 #3 0xffffffff809c93ab at trap_fatal+0x40b #4 0xffffffff809c93f6 at trap_pfault+0x46 #5 0xffffffff809a1d1e at calltrap+0x8 #6 0xffffffff806643e8 at pipe_close+0x58 #7 0xffffffff8059e3c7 at _fdrop+0x17 #8 0xffffffff805a1271 at closef+0x201 #9 0xffffffff805a0a0a at fdescfree+0x47a #10 0xffffffff805b2775 at exit1+0x435 #11 0xffffffff805b233d at sys_exit+0xd #12 0xffffffff809c9c4a at amd64_syscall+0x11a #13 0xffffffff809a263b at fast_syscall_common+0xf8 Uptime: 44d12h17m14s