Re: RELENG_14 panic (kernel: freeing uidinfo: uid = xxx, sbsize = xxx
Date: Thu, 27 Mar 2025 13:58:46 UTC
On 3/26/2025 5:20 PM, mike tancsa wrote: > I have seen this sort of panic twice now on 2 separate machines when > restarting telegraf the odd time. Does this look familiar to anyone ? > Actually saw this as far back as November on RELENG_14 on a third machine, again when mucking about with telegraf. Anyone have any ideas what might be triggering this panic ? Going to try and randomly restart telegraf to see if I can trigger it. Maybe something about killing the process mid transmission ? ---Mike > On a 14.2R this popped up > > kernel: freeing uidinfo: uid = 884, sbsize = 115664 > > and then a few min later > > Mar 7 09:38:18 pf-cam2 kernel: freeing uidinfo: uid = 884, sbsize = > 115664 > > Mar 7 09:42:17 pf-cam2 kernel: Fatal trap 12: page fault while in > kernel mode > Mar 7 09:42:17 pf-cam2 kernel: cpuid = 0; apic id = 00 > Mar 7 09:42:17 pf-cam2 kernel: fault virtual address = 0x18 > Mar 7 09:42:17 pf-cam2 kernel: fault code = supervisor write > data, page not present > Mar 7 09:42:17 pf-cam2 kernel: instruction pointer = > 0x20:0xffffffff80b36899 > Mar 7 09:42:17 pf-cam2 kernel: stack pointer = > 0x28:0xfffffe0116613d18 > Mar 7 09:42:17 pf-cam2 kernel: frame pointer = > 0x28:0xfffffe0116613d30 > Mar 7 09:42:17 pf-cam2 kernel: code segment = base 0x0, > limit 0xfffff, type 0x1b > Mar 7 09:42:17 pf-cam2 kernel: = DPL 0, pres 1, > long 1, def32 0, gran 1 > Mar 7 09:42:17 pf-cam2 kernel: processor eflags = interrupt > enabled, resume, IOPL = 0 > Mar 7 09:42:17 pf-cam2 kernel: current process = 2 (clock > (0)) > Mar 7 09:42:17 pf-cam2 kernel: rdi: 0000000000000000 rsi: > fffff8003faf3aec rdx: 0000000000000000 > Mar 7 09:42:17 pf-cam2 kernel: rcx: 7fffffffffffffff r8: > ffffffffffff3cd4 r9: 00000000ffff3cd4 > Mar 7 09:42:17 pf-cam2 kernel: rax: 0000000000000000 rbx: > fffff8003faf3ad0 rbp: fffffe0116613d30 > Mar 7 09:42:17 pf-cam2 kernel: r10: ffffffffffff3cd4 r11: > 00000000671a0b2a r12: 000f000000000000 > Mar 7 09:42:17 pf-cam2 kernel: r13: fffff806da7b0aa0 r14: > fffff8003faf3800 r15: fffff80001c4a740 > Mar 7 09:42:17 pf-cam2 kernel: trap number = 12 > Mar 7 09:42:17 pf-cam2 kernel: panic: page fault > Mar 7 09:42:17 pf-cam2 kernel: cpuid = 0 > Mar 7 09:42:17 pf-cam2 kernel: time = 1741358358 > Mar 7 09:42:17 pf-cam2 kernel: KDB: stack backtrace: > Mar 7 09:42:17 pf-cam2 kernel: #0 0xffffffff80b8b89d at > kdb_backtrace+0x5d > Mar 7 09:42:17 pf-cam2 kernel: #1 0xffffffff80b3dc01 at vpanic+0x131 > Mar 7 09:42:17 pf-cam2 kernel: #2 0xffffffff80b3dac3 at panic+0x43 > Mar 7 09:42:17 pf-cam2 kernel: #3 0xffffffff81025a0b at trap_fatal+0x40b > Mar 7 09:42:17 pf-cam2 kernel: #4 0xffffffff81025a56 at trap_pfault+0x46 > Mar 7 09:42:17 pf-cam2 kernel: #5 0xffffffff80ffc398 at calltrap+0x8 > Mar 7 09:42:17 pf-cam2 kernel: #6 0xffffffff80be2b66 at > sorele_locked+0xa6 > Mar 7 09:42:17 pf-cam2 kernel: #7 0xffffffff80d21ae0 at tcp_close+0x170 > Mar 7 09:42:17 pf-cam2 kernel: #8 0xffffffff80d2b9b9 at > tcp_timer_2msl+0xf9 > Mar 7 09:42:17 pf-cam2 kernel: #9 0xffffffff80d2aa2e at > tcp_timer_enter+0xfe > Mar 7 09:42:17 pf-cam2 kernel: #10 0xffffffff80b5bc0c at > softclock_call_cc+0x12c > Mar 7 09:42:17 pf-cam2 kernel: #11 0xffffffff80b5d455 at > softclock_thread+0xe5 > Mar 7 09:42:17 pf-cam2 kernel: #12 0xffffffff80af760f at fork_exit+0x7f > Mar 7 09:42:17 pf-cam2 kernel: #13 0xffffffff80ffd3fe at > fork_trampoline+0xe > Mar 7 09:42:17 pf-cam2 kernel: Uptime: 94d14h13m41s > Mar 7 09:42:17 pf-cam2 kernel: Dumping 4577 out of 65260 > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%---<<BOOT>>--- > > > and just now in a VM a similar sort of pattern. uid 884 is telegraf > and I was mucking about with the configuration. > > And on a RELENG_14 box (kernel from Jan 31st) > > Mar 26 17:09:43 pf-firewall kernel: freeing uidinfo: uid = 884, sbsize > = 99600 > Mar 26 17:11:26 pf-firewall syslogd: kernel boot file is > /boot/kernel/kernel > Mar 26 17:11:26 pf-firewall kernel: panic: vm_fault_lookup: fault on > nofault entry, addr: 0xffffffff80aea000 > Mar 26 17:11:26 pf-firewall kernel: cpuid = 0 > Mar 26 17:11:26 pf-firewall kernel: time = 1743023443 > Mar 26 17:11:26 pf-firewall kernel: KDB: stack backtrace: > Mar 26 17:11:26 pf-firewall kernel: #0 0xffffffff80b8d13d at > kdb_backtrace+0x5d > Mar 26 17:11:26 pf-firewall kernel: #1 0xffffffff80b3ef01 at vpanic+0x161 > Mar 26 17:11:26 pf-firewall kernel: #2 0xffffffff80b3ed93 at panic+0x43 > Mar 26 17:11:26 pf-firewall kernel: #3 0xffffffff80ebcf67 at > vm_fault+0x15b7 > Mar 26 17:11:26 pf-firewall kernel: #4 0xffffffff80ebb8c1 at > vm_fault_trap+0x81 > Mar 26 17:11:26 pf-firewall kernel: #5 0xffffffff8102c97a at > trap_pfault+0x20a > Mar 26 17:11:26 pf-firewall kernel: #6 0xffffffff81003748 at calltrap+0x8 > Mar 26 17:11:26 pf-firewall kernel: #7 0xffffffff80b2d837 at > crfree_final+0x17 > Mar 26 17:11:26 pf-firewall kernel: #8 0xffffffff80cfc156 at > in_pcbfree+0x2a6 > Mar 26 17:11:26 pf-firewall kernel: #9 0xffffffff80be4229 at > sorele_locked+0x89 > Mar 26 17:11:26 pf-firewall kernel: #10 0xffffffff80d242b0 at > tcp_close+0x170 > Mar 26 17:11:26 pf-firewall kernel: #11 0xffffffff80d2e23b at > tcp_timer_2msl+0xfb > Mar 26 17:11:26 pf-firewall kernel: #12 0xffffffff80d2d2b4 at > tcp_timer_enter+0x104 > Mar 26 17:11:26 pf-firewall kernel: #13 0xffffffff80b5d139 at > softclock_call_cc+0x129 > Mar 26 17:11:26 pf-firewall kernel: #14 0xffffffff80b5e905 at > softclock_thread+0xe5 > Mar 26 17:11:26 pf-firewall kernel: #15 0xffffffff80af8471 at > fork_exit+0x81 > Mar 26 17:11:26 pf-firewall kernel: #16 0xffffffff810047ae at > fork_trampoline+0xe > Mar 26 17:11:26 pf-firewall kernel: Uptime: 54d4h48m5s > Mar 26 17:11:26 pf-firewall kernel: Automatic reboot in 15 seconds - > press a key on the console to abort > Mar 26 17:11:26 pf-firewall kernel: Rebooting... > > > >