Fatal trap 9: general protection fault while in kernel mode

T

trev

FreeBSD shadow 12.2-STABLE FreeBSD 12.2-STABLE #4 r369361: Thu Feb 25 08:39:14 AEDT 2021 trev@shadow:/usr/obj/usr/src/amd64.amd64/sys/MACMINI amd64

Argh, at ~03:00 this morning I was woken by my mid-2011 Mac mini (the infamous Apple "boing") rebooting during the 03:00 periodic run:

Code: 
May 15 03:05:18 shadow syslogd: kernel boot file is /boot/kernel/kernel
May 15 03:05:18 shadow kernel: kernel trap 9 with interrupts disabled
May 15 03:05:18 shadow kernel: 
May 15 03:05:18 shadow syslogd: last message repeated 1 times
May 15 03:05:18 shadow kernel: Fatal trap 9: general protection fault while in kernel mode
May 15 03:05:18 shadow kernel: cpuid = 2; apic id = 02
May 15 03:05:18 shadow kernel: instruction pointer      = 0x20:0xffffffff805d0a95
May 15 03:05:18 shadow kernel: stack pointer            = 0x28:0xfffffe008ff2ab60
May 15 03:05:18 shadow kernel: frame pointer            = 0x28:0xfffffe008ff2ab60
May 15 03:05:18 shadow kernel: code segment             = base 0x0, limit 0xfffff, type 0x1b
May 15 03:05:18 shadow kernel:                  = DPL 0, pres 1, long 1, def32 0, gran 1
May 15 03:05:18 shadow kernel: processor eflags = resume, IOPL = 0
May 15 03:05:18 shadow kernel: current process          = 72405 (top)
May 15 03:05:18 shadow kernel: trap number              = 9
May 15 03:05:18 shadow kernel: panic: general protection fault
May 15 03:05:18 shadow kernel: cpuid = 2
May 15 03:05:18 shadow kernel: time = 1621011765
May 15 03:05:18 shadow kernel: KDB: stack backtrace:
May 15 03:05:18 shadow kernel: #0 0xffffffff80542455 at kdb_backtrace+0x65
May 15 03:05:18 shadow kernel: #1 0xffffffff804fd19b at vpanic+0x17b
May 15 03:05:18 shadow kernel: #2 0xffffffff804fd013 at panic+0x43
May 15 03:05:18 shadow kernel: #3 0xffffffff80796bc1 at trap_fatal+0x391
May 15 03:05:18 shadow kernel: #4 0xffffffff807960a7 at trap+0x67
May 15 03:05:18 shadow kernel: #5 0xffffffff8077122e at calltrap+0x8
May 15 03:05:18 shadow kernel: #6 0xffffffff804e6d30 at fill_kinfo_thread+0x70
May 15 03:05:18 shadow kernel: #7 0xffffffff804e6c11 at fill_kinfo_proc+0x701
May 15 03:05:18 shadow kernel: #8 0xffffffff804e71e4 at kern_proc_out+0x34
May 15 03:05:18 shadow kernel: #9 0xffffffff804e9814 at sysctl_out_proc+0x64
May 15 03:05:18 shadow kernel: #10 0xffffffff804e96b4 at sysctl_kern_proc+0x364
May 15 03:05:18 shadow kernel: #11 0xffffffff8050a75d at sysctl_root_handler_locked+0x7d
May 15 03:05:18 shadow kernel: #12 0xffffffff80509c04 at sysctl_root+0x1c4
May 15 03:05:18 shadow kernel: #13 0xffffffff8050a241 at userland_sysctl+0x141
May 15 03:05:18 shadow kernel: #14 0xffffffff8050a0bf at sys___sysctl+0x5f
May 15 03:05:18 shadow kernel: #15 0xffffffff8079761e at amd64_syscall+0x27e
May 15 03:05:18 shadow kernel: #16 0xffffffff80771b5e at fast_syscall_common+0xf8
May 15 03:05:18 shadow kernel: Uptime: 63d12h9m47s
May 15 03:05:18 shadow kernel: Dumping 3816 out of 16344 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%---<<BOOT>>---

Memory issues? Nope, three passes of memtest86 were OK.

Any ideas from the above output where I should look to resolve?
 
Did you read a sysctl?
I see sysctl_out_proc in the backtrace, which might refer to a sysctl handler function.
 
Not interactively, but maybe the 03:00 periodic scripts did. The last time I interactively read a sysctl (which I often do to extract temperatures from the asmc(4) KLM or to change the fan speed) would have been at least six hours earlier.
 
were any compat/linux involved?

May 15 03:05:18 shadow kernel: #11 0xffffffff8050a75d at sysctl_root_handler_locked+0x7d

it appears (some app: which?) used sysctl to set a parameter (perhaps a hardware driver parameter - free bsd drivers sometimes use sysctl, so check that) and either your kernel (did you compile it yourself?) or perhaps hardware caused a fault.

I now see "MAC MINI 2011". It's all Intel CPU+Mohterboard ... but not a generic PC. It has special parts (including security features) FreeBSD doesn't know about.

_________________________
So this is just just one run of periodic, the scheduler? Then what is in your periodic list?

This seems like a no-starter. If it's happened only once then just ignore it, I would say.

63d uptime ... not bad considering your using a mac mini never designed for what your using it for ?

Check your "periodic" config in /etc/ and /usr/local/ec and see what's in the lists (ie, installed apps may have altered it from default, what was running when the sysctl was invoked)
 
debguy said:
were any compat/linux involved?
Click to expand...
It's pretty clear from the stack trace that it has nothing to do with that. Why do you always assume Linux is somehow involved with anything on FreeBSD?
 
The system is running my own slimmed-down kernel, but that's never been an issue. There's no Linux components.

I've been running FreeBSD successfully and without any issues on Mac minis since the 2007 Intel core duo model. My late-2009 Mac mini was only retired late last year. Apart from needing to submit patches for asmc(4) to add access to the SMC for temperature checking and fan control, it has always just worked out of the box.

For the moment, I'm putting the issue down to an unfortunate shift in the earth's magnetic field.
 
You must log in or register to reply here.
Back
Top