Re: strange kernel crash

On Fri, Nov 06, 2015 at 01:20:13PM +0200, Andriy Gapon wrote:
> Unread portion of the kernel message buffer:
> 
> Fatal trap 1: privileged instruction fault while in kernel mode
> cpuid = 0; apic id = 00
> instruction pointer     = 0x20:0xffffffff80619a1e
> stack pointer           = 0x28:0xfffffe04f57856f0
> frame pointer           = 0x28:0xfffffe04f57857b0
> 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         = 2658 (firefox)
> trap number             = 1
> panic: privileged instruction fault
> cpuid = 0
> curthread: 0xfffff803270b6000
> stack: 0xfffffe04f5782000 - 0xfffffe04f5786000
> stack pointer: 0xfffffe04f5785320
> KDB: stack backtrace:
> db_trace_self_wrapper() at 0xffffffff8041e86b = db_trace_self_wrapper+0x2b/frame
> 0xfffffe04f5785250
> kdb_backtrace() at 0xffffffff80669f39 = kdb_backtrace+0x39/frame 0xfffffe04f5785300
> vpanic() at 0xffffffff8063531c = vpanic+0x14c/frame 0xfffffe04f5785340
> panic() at 0xffffffff80635063 = panic+0x43/frame 0xfffffe04f57853a0
> trap_fatal() at 0xffffffff8081fc0f = trap_fatal+0x33f/frame 0xfffffe04f5785400
> trap() at 0xffffffff8081f872 = trap+0x7d2/frame 0xfffffe04f5785610
> trap_check() at 0xffffffff8081ff2a = trap_check+0x2a/frame 0xfffffe04f5785630
> calltrap() at 0xffffffff80807ea0 = calltrap+0x8/frame 0xfffffe04f5785630
> --- trap 0x1, rip = 0xffffffff80619a1e, rsp = 0xfffffe04f5785700, rbp =
> 0xfffffe04f57857b0 ---
> __mtx_lock_flags() at 0xffffffff80619a1e = __mtx_lock_flags+0x2ee/frame
> 0xfffffe04f57857b0
> uma_dbg_getslab() at 0xffffffff807df15c = uma_dbg_getslab+0x3c/frame
> 0xfffffe04f57857d0
> uma_dbg_alloc() at 0xffffffff807df08d = uma_dbg_alloc+0x2d/frame 0xfffffe04f5785800
> uma_zalloc_arg() at 0xffffffff807dacf1 = uma_zalloc_arg+0x4b1/frame
> 0xfffffe04f5785890
> uma_zalloc() at 0xffffffff8068b040 = uma_zalloc+0x10/frame 0xfffffe04f57858a0
> selfdalloc() at 0xffffffff8068aa12 = selfdalloc+0x22/frame 0xfffffe04f57858c0
> pollscan() at 0xffffffff8068a615 = pollscan+0x95/frame 0xfffffe04f5785910
> kern_poll() at 0xffffffff8068a4b1 = kern_poll+0x1f1/frame 0xfffffe04f5785a70
> sys_poll() at 0xffffffff8068a2b9 = sys_poll+0x79/frame 0xfffffe04f5785a90
> syscallenter() at 0xffffffff80820560 = syscallenter+0x320/frame 0xfffffe04f5785b00
> amd64_syscall() at 0xffffffff8082012f = amd64_syscall+0x1f/frame 0xfffffe04f5785bf0
> Xfast_syscall() at 0xffffffff8080818b = Xfast_syscall+0xfb/frame 0xfffffe04f5785bf0
> --- syscall (209, FreeBSD ELF64, sys_poll), rip = 0x80146342a, rsp =
> 0x7fffffffd8e8, rbp = 0x7fffffffd920 ---
> Uptime: 1d12h57m32s
> 
> 
> Now the strange part:
> 
>    0xffffffff80619a18 <+744>:   jne    0xffffffff80619a61 <__mtx_lock_flags+817>
>    0xffffffff80619a1a <+746>:   mov    %rbx,(%rsp)
> => 0xffffffff80619a1e <+750>:   movq   $0x0,0x18(%rsp)
>    0xffffffff80619a27 <+759>:   movq   $0x0,0x10(%rsp)
>    0xffffffff80619a30 <+768>:   movq   $0x0,0x8(%rsp)
> 
> RSP value seems to be sane and consistent with the stack information above:
> (kgdb) i reg
> rax            0x4      4
> rbx            0xfffff80126ea54f0       -8791145163536
> rcx            0xffffffff8099a600       -2137414144
> rdx            0xfffff803270b6000       -8782553063424
> rsi            0x4      4
> rdi            0xfffff80027f41318       -8795422715112
> rbp            0xfffffe04f57857b0       0xfffffe04f57857b0
> rsp            0xfffffe04f5785700       0xfffffe04f5785700
> r8             0xffffffff809a7727       -2137360601
> r9             0xfffff80126ea54f0       -8791145163536
> r10            0x3e8    1000
> r11            0xfffffe04f5785cc0       -2177725080384
> r12            0x1      1
> r13            0xfffff803270b6000       -8782553063424
> r14            0xfffff80027f41318       -8795422715112
> r15            0x0      0
> rip            0xffffffff80619a1e       0xffffffff80619a1e <__mtx_lock_flags+750>
> eflags         0x10246  [ PF ZF IF RF ]
> cs             0x20     32
> ss             0x28     40
> ds             <unavailable>
> es             <unavailable>
> fs             <unavailable>
> gs             <unavailable>
> 
> (kgdb) x/a $rsp
> 0xfffffe04f5785700:     0xfffff80126ea54f0
> (kgdb) x/a $rsp + 0x18
> 0xfffffe04f5785718:     0x0
> 
> I have no idea what could have caused the #GP.  This is certainly not a stack
> overflow.

This is a second report, please take a look at
https://lists.freebsd.org/pipermail/freebsd-current/2015-October/057975.html
I have no idea as well.