>Number: 176835
>Category: amd64
>Synopsis: 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 Mar 11 06:50:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Martin Bishop
>Release:9.1
>Organization:
>Environment:
FreeBSD host.domain 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4
09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
amd64
>Description:
Periodic panic, though it looks like it's happening in the same place. Stealing
some advice from another bug report, there's some gdb output at the bottom..
panic #1
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address = 0xd398481f
fault code = supervisor write data, page not present
instruction pointer = 0x20:0x808eb0b3
stack pointer = 0x28:0xff80913d4970
frame pointer = 0x28:0xff80913d4980
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 91049 (maildrop)
trap number = 12
panic: page fault
cpuid = 2
KDB: stack backtrace:
#0 0x809208a6 at kdb_backtrace+0x66
#1 0x808ea8be at panic+0x1ce
#2 0x80bd8240 at trap_fatal+0x290
#3 0x80bd857d at trap_pfault+0x1ed
#4 0x80bd8b9e at trap+0x3ce
#5 0x80bc315f at calltrap+0x8
#6 0x808efb14 at tdsendsignal+0x454
#7 0x808f0b6d at killpg1+0x3bd
#8 0x808f0de4 at sys_kill+0x1e4
#9 0x80bd7ae6 at amd64_syscall+0x546
panic #2
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address = 0xd398481f
fault code = supervisor write data, page not present
instruction pointer = 0x20:0x808eb0b3
stack pointer = 0x28:0xff8091109970
frame pointer = 0x28:0xff8091109980
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 57769 (maildrop)
trap number = 12
panic: page fault
cpuid = 2
KDB: stack backtrace:
#0 0x809208a6 at kdb_backtrace+0x66
#1 0x808ea8be at panic+0x1ce
#2 0x80bd8240 at trap_fatal+0x290
#3 0x80bd857d at trap_pfault+0x1ed
#4 0x80bd8b9e at trap+0x3ce
#5 0x80bc315f at calltrap+0x8
#6 0x808efb14 at tdsendsignal+0x454
#7 0x808f0b6d at killpg1+0x3bd
#8 0x808f0de4 at sys_kill+0x1e4
#9 0x80bd7ae6 at amd64_syscall+0x546
% gdb /boot/kernel/kernel
(gdb) l *tdsendsignal+0x454
0x808efb14 is in tdsendsignal (/usr/src/sys/kern/kern_sig.c:2046).
warning: Source file is more recent than executable.
2041 * IEEE Std 1003.1-2001: return success when killing a zombie.
2042 */
2043if (p->p_state == PRS_ZOMBIE) {
2044if (ksi && (ksi->ksi_flags & KSI_INS))
2045ksiginfo_tryfree(ksi);
2046return (ret);
2047}
2048
2049ps = p->p_sigacts;
2050KNOTE_LOCKED(&p->p_klist, NOTE_SIGNAL | sig);
(gdb)
I can grab a core if need be, but am hoping that given the consistency of the
backtrace the problem will be obvious to the maintainers of the relevant
portions of code :)
>How-To-Repeat:
I haven't been triggering it, but given the current process is consistently the
same:
- run 9.1 release
- use maildrop to filter mail
- wait for crash
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-amd64@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
