Date: Tue, 14 Jul 2009 13:00:16 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-stable@freebsd.org Subject: Re: trap 12 Message-ID: <200907141300.16634.jhb@freebsd.org> In-Reply-To: <20090714145101.60515vh49s7o7c4k@10.248.192.16> References: <20090714145101.60515vh49s7o7c4k@10.248.192.16>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 14 July 2009 9:51:01 am Ian J Hart wrote: > Quoting John Baldwin <jhb@freebsd.org>: > > > On Tuesday 07 July 2009 5:51:03 am Ian J Hart wrote: > >> Quoting Ian J Hart <ianjhart@ntlworld.com>: > >> > >>> Quoting Ian J Hart <ianjhart@ntlworld.com>: > >>> > >>>> Is this likely to be hardware? Details will follow if not. > >>>> > >>>> [copied from a screen dump] > >>>> > >>>> Fatal trap 12: page fault while in kernel mode > >>>> cpuid = 1; apic id = 01 > >>>> fault virtual address = 0x0 > >>>> fault code = supervisor write data, page not present > >>>> instruction pointer = 0x8:0xffffffff807c6c12 > >>>> stack pointer = 0x10:0xffffffff510e7890 > >>>> frame pointer = 0x10:0xffffff00054a6c90 > >>>> 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 = 75372 (printf) > >>>> trap number = 12 > >>>> panic: page fault > >>>> cpuid = 1 > >>>> uptime: 8m2s > >>>> Cannot dump. No dump device defined. > >>>> > >>>> > >>> Ran crashinfo, now have much more info than I need ;) > >>> > >>> Starting another portupgrade run now to see how reproducable this is. > >>> > >>> Later BIOS waiting in USB floppy. > >>> > >> [snip dmesg] > >> > >> It took 2 runs of portupgrade -af.Some corruption in the dbs may have > >> to pkg_delete -a. > >> > >> FreeBSD * 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #0: Tue Jun 16 > >> 18:03:10 BST 2009 *@*:/usr/obj/usr/src/sys/GENERIC amd64 > >> > >> panic: page fault > >> > >> GNU gdb 6.1.1 [FreeBSD] > >> Copyright 2004 Free Software Foundation, Inc. > >> GDB is free software, covered by the GNU General Public License, and you are > >> welcome to change it and/or distribute copies of it under certain > > conditions. > >> Type "show copying" to see the conditions. > >> There is absolutely no warranty for GDB. Type "show warranty" for details. > >> This GDB was configured as "amd64-marcel-freebsd"... > >> > >> Unread portion of the kernel message buffer: > >> > >> > >> Fatal trap 12: page fault while in kernel mode > >> cpuid = 1; apic id = 01 > >> fault virtual address = 0xfffffffff5555570 > >> fault code = supervisor write data, page not present > >> instruction pointer = 0x8:0xffffffff807c429b > >> stack pointer = 0x10:0xffffffff511e4710 > >> frame pointer = 0x10:0x20 > >> 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 = 69996 (mkdir) > >> trap number = 12 > >> panic: page fault > > > > This one does look like a hardware issue from the stack trace. It's hard to > > know if the first panic you saw was a hardware issue as well without the > > stack trace information. > > > >> #7 0xffffffff807b706e in calltrap () > >> at /usr/src/sys/amd64/amd64/exception.S:209 > >> #8 0xffffffff807c429b in free_pv_entry (pmap=0xffffffff80b66c80, > >> pv=Variable "pv" is not available. > >> ) > >> at /usr/src/sys/amd64/amd64/pmap.c:1905 > >> #9 0xffffffff807c4403 in pmap_remove_entry (pmap=Variable "pmap" is > >> not available. > >> ) > >> at /usr/src/sys/amd64/amd64/pmap.c:2131 > >> #10 0xffffffff807c6447 in pmap_remove_pte (pmap=0xffffffff80b66c80, > >> ptq=0xaaaaaaa8, va=18446744070506639360, ptepde=23601251, > >> free=0xffffffff511e4790) at /usr/src/sys/amd64/amd64/pmap.c:2366 > >> #11 0xffffffff807cab87 in pmap_remove (pmap=0xffffffff80b66c80, > >> sva=18446744070506639360, eva=18446744070506909696) > >> at /usr/src/sys/amd64/amd64/pmap.c:2510 > > > > -- > > John Baldwin > > > > The remote backup continues to run so there was definitely some issue > there. No more reboots, but it wasn't doing that regularly without > some additional load. > > Hopefully I can swap parts around until I find the offending item. > > Thanks for your input. I would try running memtest86 to check your RAM. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200907141300.16634.jhb>