amd64/175091: Crash: Fatal trap 12: page fault while in kernel mode

[John Baldwin]

The following reply was made to PR amd64/175091; it has been noted by GNATS.

From: John Baldwin <jhb at freebsd.org>
To: freebsd-amd64 at freebsd.org
Cc: Rasmus Skaarup <freebsd at gal.dk>,
 freebsd-gnats-submit at freebsd.org
Subject: Re: amd64/175091: Crash: Fatal trap 12: page fault while in kernel mode
Date: Mon, 7 Jan 2013 09:32:36 -0500

 On Monday, January 07, 2013 03:05:18 AM Rasmus Skaarup wrote:
 > >Number:         175091
 > >Category:       amd64
 > >Synopsis:       Crash: Fatal trap 12: page fault while in kernel mode
 > >Confidential:   no
 > >Severity:       non-critical
 > >Priority:       low
 > >Responsible:    freebsd-amd64
 > >State:          open
 > >Quarter:
 > >Keywords:
 > >Date-Required:
 > >Class:          sw-bug
 > >Submitter-Id:   current-users
 > >Arrival-Date:   Mon Jan 07 08:10:01 UTC 2013
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     Rasmus Skaarup
 > >Release:        9.1-RELEASE
 > >Organization:
 > 
 > >Environment:
 > FreeBSD thirdhost 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec  4
 > 09:23:10 UTC 2012    
 > root at farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
 > 
 > >Description:
 > On of my virtualized FreeBSD machines has been panic'ing two times within
 > the last two weeks. After the first panic I ran freebsd-update and
 > upgraded to 9.1-RELEASE succesfully. Today the machine panic'ed again.
 > 
 > I have another virtualized FreeBSD machine running on the same host, and it
 > does not exhibit this behaviour.
 > 
 > Here is the output from dmesg, after reboot:
 > 
 > ****
 > Fatal trap 12: page fault while in kernel mode
 > cpuid = 2; apic id = 02
 > fault virtual address   = 0x48
 > fault code              = supervisor read data, page not present
 > instruction pointer     = 0x20:0xffffffff80bd5139
 > stack pointer           = 0x28:0xffffff81625536c0
 > frame pointer           = 0x28:0xffffff8162553750
 > 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         = 62083 (httpd)
 > trap number             = 12
 > panic: page fault
 > cpuid = 2
 > KDB: stack backtrace:
 > #0 0xffffffff809208a6 at kdb_backtrace+0x66
 > #1 0xffffffff808ea8be at panic+0x1ce
 > #2 0xffffffff80bd8240 at trap_fatal+0x290
 > #3 0xffffffff80bd857d at trap_pfault+0x1ed
 > #4 0xffffffff80bd8b9e at trap+0x3ce
 > #5 0xffffffff80bc315f at calltrap+0x8
 > #6 0xffffffff80b41133 at vm_fault_hold+0x1b13
 > #7 0xffffffff80b41cc3 at vm_fault+0x73
 > #8 0xffffffff80bd84b4 at trap_pfault+0x124
 > #9 0xffffffff80bd8c6c at trap+0x49c
 > #10 0xffffffff80bc315f at calltrap+0x8
 > Uptime: 13h6m22s
 > *********
 
 Can you enable crashdumps by setting 'dumpdev="AUTO"' in /etc/rc.conf?
 
 Also, can you run 'gdb /boot/kernel/kernel' and then at the prompt run
 'l *vm_fault_hold+0x1b13' and reply with the output?
 
 -- 
 John Baldwin