Date: Sun, 30 Dec 2007 03:22:32 +0100 From: Kris Kennaway <kris@FreeBSD.org> To: Iain Dooley <iain@workingsoftware.com.au> Cc: freebsd-questions@freebsd.org Subject: Re: kernel panic 6.2-RELEASE SMP dual quad core Message-ID: <477700E8.3050100@FreeBSD.org> In-Reply-To: <20071230122718.D2071@socata.scoastnet.com.au> References: <20071230122718.D2071@socata.scoastnet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Iain Dooley wrote: > hi all, > > uname -a > FreeBSD HOSTNAME 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 11:05:30 > UTC 2007 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP i386 > > running on dual quad core intel xeons with 4gb ram. > > my server has been rebooting quite a bit and stopped responding today. i > found this on the console: > > Fatal trap: 12 page fault while in kernel mode > cpuid = 5; apic id = 05 > fault virtual address = 0x0 > fault code = supervisor write, page not present > instruction pointer = 0x20:0xc0880472 > stack pointer = 0x28:0xe6ea9c8c > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 12 (idle: cpu5) > trap number = 12 > panic: page fault > cpuid = 5 > uptime 24m41s > cannot dump. no dump device specified > > i've configured the dump device and will follow the kernel debugging > details in the handbook if it happens again but i thought i'd write in > now in case the cause of the problem jumped out at anyone. > > i've run mprime for 24 hours, and memtest for 3 passes, and a script i > wrote which just exhausts ram and CPU, then backs off and does it again > which have been running for 24 hours. > > i've also just started running this: > > http://www.holm.cc/stress/ > > i noticed that the same "fatal trap 12" appeared during stress tests as > listed here: > > http://people.freebsd.org/~pho/stress/log/cons224.html > > any help, guidance or information would be much appreciated. What you have so far is close to meaningless. The "fault virtual address = 0x0" means little more than "somewhere in the kernel there was a null pointer dereference". The fact that it was the idle process is suspicious though, it suggests that hardware failure is a high probability. Please follow up with the backtrace if you want to pursue this further. Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?477700E8.3050100>