Fatal trap 9: general protection fault while in kernel mode

[Peter Wemm]

Kris Kennaway wrote:
> hammer01 died overnight with:
> 
> ad0: WARNING - READ_DMA recovered from missing interrupt
> 
> 
> Fatal trap 9: general protection fault while in kernel mode
> instruction pointer     = 0x8:0xffffffff80466d30
> stack pointer           = 0x10:0xffffffff99ceaa00
> frame pointer           = 0x10:0xffffffff99ceaa90
> 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         = 85568 (cc1plus)
> kernel: type 9 trap, code=0
> Stopped at      vm_page_splay+0x20:     decl    %eax
> db> where
> vm_page_splay() at vm_page_splay+0x20
> vm_object_page_remove() at vm_object_page_remove+0xaa
> vm_map_delete() at vm_map_delete+0x27a
> vm_map_remove() at vm_map_remove+0x52
> munmap() at munmap+0x9c
> syscall() at syscall+0x320
> Xfast_syscall() at Xfast_syscall+0xa7
> --- syscall (73, FreeBSD ELF64, munmap), rip = 0x6a0dc4, rsp = 0x7fffffffebf8
    , rbp = 0 ---
> db>
> 
> Unfortunately I don't know the timing between the ad0 error and the panic.
> 
> Kris

For the record, I have not seent this before.   Can you please save the
kernel that blew up with that?  A GPF is kinda odd for a kernel trap.  Its
normally something that comes from a misaligned SSE2 register write to
stack.  Unfortunately, the disassembler has not been taught about the REX
prefixes yet.  "decl %eax" is a rex prefix for the next instruction.

vm_page_splay+0x20 looks something like this on my machines:
0xffffffff803469dc <vm_page_splay+0>:   push   %rbp
0xffffffff803469dd <vm_page_splay+1>:   mov    %rsp,%rbp
0xffffffff803469e0 <vm_page_splay+4>:   add    $0xffffffffffffff80,%rsp
0xffffffff803469e4 <vm_page_splay+8>:   mov    $0x0,%eax
0xffffffff803469e9 <vm_page_splay+13>:  test   %rsi,%rsi
0xffffffff803469ec <vm_page_splay+16>:  je     0xffffffff80346a90 <vm_page_splay+180>
0xffffffff803469f2 <vm_page_splay+22>:  lea    0xffffffffffffff80(%rbp),%r8
0xffffffff803469f6 <vm_page_splay+26>:  mov    %r8,%rcx
0xffffffff803469f9 <vm_page_splay+29>:  nop    
0xffffffff803469fa <vm_page_splay+30>:  nop    
0xffffffff803469fb <vm_page_splay+31>:  nop    
0xffffffff803469fc <vm_page_splay+32>:  cmp    0x38(%rsi),%rdi
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0xffffffff80346a00 <vm_page_splay+36>:  jae    0xffffffff80346a34 <vm_page_splay+88>
0xffffffff80346a02 <vm_page_splay+38>:  mov    0x20(%rsi),%rdx
0xffffffff80346a06 <vm_page_splay+42>:  test   %rdx,%rdx
0xffffffff80346a09 <vm_page_splay+45>:  je     0xffffffff80346a6d <vm_page_splay+145>

Hmm. If %rsi was in a non-canonical format, that would do a GPF too.

If you get these again, a 'show registers' type dump would be useful in the
future.

Cheers,
-Peter
--
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5