Solved Fatal trap 12: page fault while in kernel mode on new server running FreeBSD 10.1-RELEASE-p10

I was wondering if anyone has any thoughts on this and/or can help me figure out how to diagnose this problem. Basically the server runs fine by it's self but once I start running jails on it it will crash, usually around 24 to 48 hours but sometimes less.

The odd thing is I have an almost identical server running the same version of FreeBSD with the same kernel configuration and it does not crash, the only difference is the CPU and slightly different model hard drives. I also have a 3rd server that with the exception of FreeBSD 9.3 and the CPU has identical hardware and it is also stable as a rock.

Specs for good server (FreeBSD9):
  • SuperMicro SYS-5018D-MTF (X10SLM-F MB)
  • Intel Xeon E3-1230V3 Haswell 3.3GHz LGA 1150 80W Quad-Core BX80646E31230V3
  • 2x Kingston 8GB DDR3 SDRAM 1600 ECC Unbuffered w/TS KVR16E11/8I
  • 2x Seagate SATA ST1000NM0033-9ZM173
  • 2x WD SATA WD1003FBYZ-010FB0
Specs for good server (FreeBSD10):
  • SuperMicro SYS-5018D-MTF (X10SLM-F MB)
  • Intel Xeon E3-1230V3 Haswell 3.3GHz LGA 1150 80W Quad-Core BX80646E31230V3
  • 2x Kingston 8GB DDR3 SDRAM 1600 ECC Unbuffered w/TS KVR16E11/8I
  • 2x Seagate SATA ST1000NM0033-9ZM173
  • 2x Seagate SATA ST31000340NS
Specs for bad server:
  • SuperMicro SYS-5018D-MTF (X10SLM-F MB)
  • Intel Xeon E3-1231V3 Haswell 3.4GHz LGA 1150 80W Quad-Core BX80646E31231V3
  • 2x Kingston 8GB DDR3 SDRAM 1600 ECC Unbuffered w/TS KVR16E11/8I
  • 2x Seagate SATA ST1000NM0033-9ZM173
  • 2x WD SATA WD1003FBYZ-010FB0
Output of uname -a: FreeBSD example.com 10.1-RELEASE-p10 FreeBSD 10.1-RELEASE-p10 #2: Thu May 21 22:20:17 UTC 2015 user@example.com:/usr/obj/usr/src/sys/RACK7 amd64

Basic Drive Setup (All servers):
  • All drives partitioned like so:
    • => 63 1953525105 ada0 MBR (932G)
      63 1953525105 1 freebsd (932G)
      => 0 1953525105 ada0s1 BSD (932G)
      0 16 - free - (8.0K)
      16 20971520 1 freebsd-ufs (10G)
      20971536 20971520 2 freebsd-swap (10G)
      41943056 1911582049 4 freebsd-ufs (912G)
    • adaXs1a on all 4 drives are in a gmirror and run the OS
    • adaXs1d on all 4 drives are in a ZFS raidz2 pool and host all the jails

First crash this was all I got:
Code:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address    = 0x30058
fault code        = supervisor write data, page not present
instruction pointer    = 0x20:0xffffffff8062be9a
stack pointer        = 0x28:0xfffffe046a199640
frame pointer        = 0x28:0xfffffe046a199710
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        =

It then crashed again so I built a debug kernel but unfortunately with the debug kernel it locks up solid and the only thing I can do is power cycle the server but this was on the console:
Code:
Fatal trap 12: page fault while in kernel mode
cpuid = 5; apic id = 05
fault virtual address   = 0x30058
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff80637c27
stack pointer           = 0x28:0xfffffe046b576650
frame pointer           = 0x28:0xfffffe046b576710
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         = 13354 (httpd)
trap number             = 12
panic: page fault
cpuid = 5
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe046b576130
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe046b5761e0
vpanic() at vpanic+0x126/frame 0xfffffe046b576220
panic() at panic+0x43/frame 0xfffffe046b576280
trap_fatal() at trap_fatal+0x38f/frame 0xfffffe046b5762e0
trap_pfault() at trap_pfault+0x277/frame 0xfffffe046b576380
trap() at trap+0x4d5/frame 0xfffffe046b576590
calltrap() at calltrap+0x8/frame 0xfffffe046b576590
--- trap 0xc, rip = 0xffffffff80637c27, rsp = 0xfffffe046b576650, rbp = 0xfffffe046b576710 ---
lf_advlockasync() at lf_advlockasync+0xd67/frame 0xfffffe046b576710
lf_advlock() at lf_advlock+0x45/frame 0xfffffe046b576760
vop_stdadvlock() at vop_stdadvlock+0xa9/frame 0xfffffe046b576850
VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0x115/frame 0xfffffe046b576880
kern_fcntl() at kern_fcntl+0xb06/frame 0xfffffe046b576930
kern_fcntl_freebsd() at kern_fcntl_freebsd+0xac/frame 0xfffffe046b5769a0
amd64_syscall() at amd64_syscall+0x278/frame 0xfffffe046b576ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe046b576ab0
--- syscall (92, FreeBSD ELF64, sys_fcntl), rip = 0x801f6b1fc, rsp = 0x7ffffe1f0cb8, rbp = 0xd ---
Uptime: 53m16s

Saw it mentioned to run this (it comes out the same every crash):
Code:
7:/usr/obj/usr/src/sys/RACK7 # nm -n /boot/kernel/kernel | grep 0xffffffff80637c27
7:/usr/obj/usr/src/sys/RACK7 # nm -n /boot/kernel/kernel | grep 0xffffffff806
7:/usr/obj/usr/src/sys/RACK7 # nm -n /boot/kernel/kernel | grep 0xffffffff
7:/usr/obj/usr/src/sys/RACK7 # nm -n /boot/kernel/kernel | grep 0xfffff
7:/usr/obj/usr/src/sys/RACK7 # nm -n /boot/kernel/kernel | grep 0xff
7:/usr/obj/usr/src/sys/RACK7 # nm -n /boot/kernel/kernel | grep 0x
ffffffff80291a20 t cam_compat_handle_0x17
ffffffff8052b590 t xl_txeof_90xB
ffffffff8052b850 t xl_start_90xB_locked
ffffffff808d2d60 T Xint0x80_syscall
ffffffff808dd580 t topo_probe_0x4

Went back to normal kernel and enabled crash dumps and this is from the next crash:
Code:
Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address   = 0x30058
fault code              = supervisor write data, page not present
instruction pointer     = 0x20:0xffffffff8062934a
stack pointer           = 0x28:0xfffffe046a74e640
frame pointer           = 0x28:0xfffffe046a74e710
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         = 81190 (httpd)
trap number             = 12
panic: page fault
cpuid = 3
KDB: stack backtrace:
#0 0xffffffff8067dee0 at kdb_backtrace+0x60
#1 0xffffffff80643005 at panic+0x155
#2 0xffffffff808ececf at trap_fatal+0x38f
#3 0xffffffff808ed1e8 at trap_pfault+0x308
#4 0xffffffff808ec84a at trap+0x47a
#5 0xffffffff808d2812 at calltrap+0x8
#6 0xffffffff80629b15 at lf_advlock+0x45
#7 0xffffffff806d3d49 at vop_stdadvlock+0xa9
#8 0xffffffff809a78e7 at VOP_ADVLOCK_APV+0xa7
#9 0xffffffff805ff7f9 at kern_fcntl+0xb39
#10 0xffffffff805fec3c at kern_fcntl_freebsd+0xac
#11 0xffffffff808ed801 at amd64_syscall+0x351
#12 0xffffffff808d2afb at Xfast_syscall+0xfb
Uptime: 1d1h30m7s
Dumping 1950 out of 16327 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%Copyright (c) 1992-2014 The FreeBSD Project.


(kgdb) 7:/usr/obj/usr/src/sys/RACK7 # kgdb kernel.debug /var/crash/vmcore.0
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 81190 (httpd)
trap number             = 12
panic: page fault
cpuid = 3
KDB: stack backtrace:
#0 0xffffffff8067dee0 at kdb_backtrace+0x60
#1 0xffffffff80643005 at panic+0x155
#2 0xffffffff808ececf at trap_fatal+0x38f
#3 0xffffffff808ed1e8 at trap_pfault+0x308
#4 0xffffffff808ec84a at trap+0x47a
#5 0xffffffff808d2812 at calltrap+0x8
#6 0xffffffff80629b15 at lf_advlock+0x45
#7 0xffffffff806d3d49 at vop_stdadvlock+0xa9
#8 0xffffffff809a78e7 at VOP_ADVLOCK_APV+0xa7
#9 0xffffffff805ff7f9 at kern_fcntl+0xb39
#10 0xffffffff805fec3c at kern_fcntl_freebsd+0xac
#11 0xffffffff808ed801 at amd64_syscall+0x351
#12 0xffffffff808d2afb at Xfast_syscall+0xfb
Uptime: 1d1h30m7s
Dumping 1950 out of 16327 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done.
Loaded symbols for /boot/kernel/geom_mirror.ko.symbols
Reading symbols from /boot/kernel/accf_data.ko.symbols...done.
Loaded symbols for /boot/kernel/accf_data.ko.symbols
Reading symbols from /boot/kernel/accf_http.ko.symbols...done.
Loaded symbols for /boot/kernel/accf_http.ko.symbols
Reading symbols from /boot/kernel/zfs.ko.symbols...done.
Loaded symbols for /boot/kernel/zfs.ko.symbols
Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
Loaded symbols for /boot/kernel/opensolaris.ko.symbols
Reading symbols from /boot/kernel/ums.ko.symbols...done.
Loaded symbols for /boot/kernel/ums.ko.symbols
Reading symbols from /boot/kernel/pf.ko.symbols...done.
Loaded symbols for /boot/kernel/pf.ko.symbols
Reading symbols from /boot/kernel/nullfs.ko.symbols...done.
Loaded symbols for /boot/kernel/nullfs.ko.symbols
#0  doadump (textdump=<value optimized out>) at pcpu.h:219
219             __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) bt
#0  doadump (textdump=<value optimized out>) at pcpu.h:219
#1  0xffffffff80642c82 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:452
#2  0xffffffff80643044 in panic (fmt=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759
#3  0xffffffff808ececf in trap_fatal (frame=<value optimized out>, eva=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:865
#4  0xffffffff808ed1e8 in trap_pfault (frame=0xfffffe046a74e590, usermode=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:676
#5  0xffffffff808ec84a in trap (frame=0xfffffe046a74e590) at /usr/src/sys/amd64/amd64/trap.c:440
#6  0xffffffff808d2812 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232
#7  0xffffffff8062934a in lf_advlockasync (ap=0xfffffe046a74e720, statep=0xfffff801107b6358, size=<value optimized out>)
    at /usr/src/sys/kern/kern_lockf.c:745
#8  0xffffffff80629b15 in lf_advlock (ap=<value optimized out>, statep=0x0, size=0) at /usr/src/sys/kern/kern_lockf.c:771
#9  0xffffffff806d3d49 in vop_stdadvlock (ap=0xfffffe046a74e8d8) at /usr/src/sys/kern/vfs_default.c:414
#10 0xffffffff809a78e7 in VOP_ADVLOCK_APV (vop=<value optimized out>, a=<value optimized out>) at vnode_if.c:2531
#11 0xffffffff805ff7f9 in kern_fcntl (td=<value optimized out>, fd=<value optimized out>, cmd=<value optimized out>,
    arg=<value optimized out>) at vnode_if.h:1041
#12 0xffffffff805fec3c in kern_fcntl_freebsd (td=0xfffff801943f0000, fd=10, cmd=<value optimized out>, arg=34387200896)
    at /usr/src/sys/kern/kern_descrip.c:465
#13 0xffffffff808ed801 in amd64_syscall (td=0xfffff801943f0000, traced=0) at subr_syscall.c:134
#14 0xffffffff808d2afb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391
#15 0x0000000801f6b1fc in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language:  auto; currently minimal
(kgdb)

Like I said before, if I take all jails off the system it runs fine and never crashes though I guess that's somewhat to be expected. I tried replacing the old RAM even though it tested fine but obviously that didn't help, also, the hard drives "seem" fine.

Really, like I said earlier, the only difference between this server and the other two basically identical servers is the CPU but could that be causing these crashes? I did a burn-in test for a few hours and several buildworlds and had absolutely no issues it's only with these jails running.

I guess I could move jails off one-by-one till maybe it doesn't crash but these jails don't crash any other servers I put them on so that seems kind of pointless to me.

I'm not sure where to go from here and would supper appreciate any help anyone can offer. And please let me know if there's any other info I can provide that would be a help.

Thanks!
 
Forgot to mention that the first time I reboot the server after a crash it will give the same "Fatal trap 12: page fault while in kernel mode" error and lock up hard and I have to power cycle. After that it will reboot fine ... till the next crash:

Code:
System shutdown time has arrived
May 23 03:37:20 7 shutdown: reboot by root:
Stopping bsnmpd.
Waiting for PIDS: 5484.
Stopping jail1.com...
Stopping jail2.com...


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x30058
fault code              = supervisor write data, page not present
instruction pointer     = 0x20:0xffffffff8062934a
stack pointer           = 0x28:0xfffffe046a6bd640
frame pointer           = 0x28:0xfffffe046a6bd710
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         = 15663 (httpd)
trap number             = 12
panic: page fault
cpuid = 7
KDB: stack backtrace:
#0 0xffffffff8067dee0 at kdb_backtrace+0x60
#1 0xffffffff80643005 at panic+0x155
#2 0xffffffff808ececf at trap_fatal+0x38f
#3 0xffffffff808ed1e8 at trap_pfault+0x308
#4 0xffffffff808ec84a at trap+0x47a
#5 0xffffffff808d2812 at calltrap+0x8
#6 0xffffffff80629b15 at lf_advlock+0x45
#7 0xffffffff806d3d49 at vop_stdadvlock+0xa9
#8 0xffffffff809a78e7 at VOP_ADVLOCK_APV+0xa7
#9 0xffffffff805ff7f9 at kern_fcntl+0xb39
#10 0xffffffff805fec3c at kern_fcntl_freebsd+0xac
#11 0xffffffff808ed801 at amd64_syscall+0x351
#12 0xffffffff808d2afb at Xfast_syscall+0xfb

...and I'm guessing "jail1.com" may be the jail running the offending apache process...
 
Oh, one more thing I just discovered:
- "Good" server with FreeBSD9 has hyperthreading enabled
- "Good" server with FreeBSD10 has hyperthreading disabled
- "Bad" server with FreeBSD10 has hyperthreading enabled

Are there any known issues with FreeBSD 10 and hyperthreading? I may try disabling hyperthreading on the bad server to see if that makes a difference or is that not a good idea?
 
Happened again just now after only being up for 20hrs:

Code:
Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 06
fault virtual address   = 0x30058
fault code              = supervisor write data, page not present
instruction pointer     = 0x20:0xffffffff8062934a
stack pointer           = 0x28:0xfffffe046a2bd640
frame pointer           = 0x28:0xfffffe046a2bd710
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         = 90603 (httpd)
trap number             = 12
panic: page fault
cpuid = 3
KDB: stack backtrace:
#0 0xffffffff8067dee0 at kdb_backtrace+0x60
#1 0xffffffff80643005 at panic+0x155
#2 0xffffffff808ececf at trap_fatal+0x38f
#3 0xffffffff808ed1e8 at trap_pfault+0x308
#4 0xffffffff808ec84a at trap+0x47a
#5 0xffffffff808d2812 at calltrap+0x8
#6 0xffffffff80629b15 at lf_advlock+0x45
#7 0xffffffff806d3d49 at vop_stdadvlock+0xa9
#8 0xffffffff809a78e7 at VOP_ADVLOCK_APV+0xa7
#9 0xffffffff805ff7f9 at kern_fcntl+0xb39
#10 0xffffffff805fec3c at kern_fcntl_freebsd+0xac
#11 0xffffffff808ed801 at amd64_syscall+0x351
#12 0xffffffff808d2afb at Xfast_syscall+0xfb
Uptime: 20h13m56s




7:/usr/obj/usr/src/sys/RACK7 # kgdb kernel /var/crash/vmcore.1 
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
panic: page fault
cpuid = 3
KDB: stack backtrace:
#0 0xffffffff8067dee0 at kdb_backtrace+0x60
#1 0xffffffff80643005 at panic+0x155
#2 0xffffffff808ececf at trap_fatal+0x38f
#3 0xffffffff808ed1e8 at trap_pfault+0x308
#4 0xffffffff808ec84a at trap+0x47a
#5 0xffffffff808d2812 at calltrap+0x8
#6 0xffffffff80629b15 at lf_advlock+0x45
#7 0xffffffff806d3d49 at vop_stdadvlock+0xa9
#8 0xffffffff809a78e7 at VOP_ADVLOCK_APV+0xa7
#9 0xffffffff805ff7f9 at kern_fcntl+0xb39
#10 0xffffffff805fec3c at kern_fcntl_freebsd+0xac
#11 0xffffffff808ed801 at amd64_syscall+0x351
#12 0xffffffff808d2afb at Xfast_syscall+0xfb
Uptime: 20h13m56s
Dumping 1702 out of 16327 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done.
Loaded symbols for /boot/kernel/geom_mirror.ko.symbols
Reading symbols from /boot/kernel/accf_data.ko.symbols...done.
Loaded symbols for /boot/kernel/accf_data.ko.symbols
Reading symbols from /boot/kernel/accf_http.ko.symbols...done.
Loaded symbols for /boot/kernel/accf_http.ko.symbols
Reading symbols from /boot/kernel/zfs.ko.symbols...done.
Loaded symbols for /boot/kernel/zfs.ko.symbols
Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
Loaded symbols for /boot/kernel/opensolaris.ko.symbols
Reading symbols from /boot/kernel/ums.ko.symbols...done.
Loaded symbols for /boot/kernel/ums.ko.symbols
Reading symbols from /boot/kernel/pf.ko.symbols...done.
Loaded symbols for /boot/kernel/pf.ko.symbols
Reading symbols from /boot/kernel/nullfs.ko.symbols...done.
Loaded symbols for /boot/kernel/nullfs.ko.symbols
#0  doadump (textdump=<value optimized out>) at pcpu.h:219
219             __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) bt
#0  doadump (textdump=<value optimized out>) at pcpu.h:219
#1  0xffffffff80642c82 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:452
#2  0xffffffff80643044 in panic (fmt=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759
#3  0xffffffff808ececf in trap_fatal (frame=<value optimized out>, eva=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:865
#4  0xffffffff808ed1e8 in trap_pfault (frame=0xfffffe046a2bd590, usermode=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:676
#5  0xffffffff808ec84a in trap (frame=0xfffffe046a2bd590) at /usr/src/sys/amd64/amd64/trap.c:440
#6  0xffffffff808d2812 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232
#7  0xffffffff8062934a in lf_advlockasync (ap=0xfffffe046a2bd720, statep=0xfffff8020bd3d8e0, size=<value optimized out>)
    at /usr/src/sys/kern/kern_lockf.c:745
#8  0xffffffff80629b15 in lf_advlock (ap=<value optimized out>, statep=0x0, size=0) at /usr/src/sys/kern/kern_lockf.c:771
#9  0xffffffff806d3d49 in vop_stdadvlock (ap=0xfffffe046a2bd8d8) at /usr/src/sys/kern/vfs_default.c:414
#10 0xffffffff809a78e7 in VOP_ADVLOCK_APV (vop=<value optimized out>, a=<value optimized out>) at vnode_if.c:2531
#11 0xffffffff805ff7f9 in kern_fcntl (td=<value optimized out>, fd=<value optimized out>, cmd=<value optimized out>, 
    arg=<value optimized out>) at vnode_if.h:1041
#12 0xffffffff805fec3c in kern_fcntl_freebsd (td=0xfffff802a54ed490, fd=10, cmd=<value optimized out>, arg=34384318656)
    at /usr/src/sys/kern/kern_descrip.c:465
#13 0xffffffff808ed801 in amd64_syscall (td=0xfffff802a54ed490, traced=0) at subr_syscall.c:134
#14 0xffffffff808d2afb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391
#15 0x0000000801cac1fc in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language:  auto; currently minimal
(kgdb)

Would really appreciate any help or advice...
 
That does sound like it ... odd that I didn't come across that in my searches. I'll try patching and see if that works. Thanks for the tip.
 
I'm marking this as resolved as the server has now been up for 3 days which is twice as long as it's ever stayed up. Thank you very much for the help Terry_Kennedy.
 
This looks like it might be Bug 194525. It is fixed in r276904, which was applied to 10-STABLE in r277625. It probably isn't in any of the 10.1-RELEASE-pX releases, as those are generally security fixes only.

Errata notices are usually the means to fix widespread issues like this. For example, this errata notice, https://www.FreeBSD.org/security/advisories/FreeBSD-EN-14:02.mmap.asc, resolved a similar issue where Java applications would sporadically cause a kernel panic. It appears a request was already made on the Bugzilla PR for a -p11 release with the patch.
 
Back
Top