Date: Sun, 30 Dec 2007 13:27:11 +1100 (EST) From: Iain Dooley <iain@workingsoftware.com.au> To: Kris Kennaway <kris@freebsd.org> Cc: freebsd-questions@freebsd.org Subject: Re: kernel panic 6.2-RELEASE SMP dual quad core Message-ID: <20071230132455.T2071@socata.scoastnet.com.au> In-Reply-To: <477700E8.3050100@FreeBSD.org> References: <20071230122718.D2071@socata.scoastnet.com.au> <477700E8.3050100@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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. I thought that dodgy ram was the culprit. I've run memtest86 on three passes with no errrors reported although I've also read numerous reports on the net of memtest86 not being very effective. can you suggest a good method of stress testing ram? this is a new machine and still under warranty so if it's a ram issue I can easily just get it replaced. Cheers, Iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071230132455.T2071>