trap 12

[Ian J Hart]

Quoting John Baldwin <jhb at freebsd.org>:

> On Tuesday 14 July 2009 9:51:01 am Ian J Hart wrote:
>> Quoting John Baldwin <jhb at freebsd.org>:
>>
>> > On Tuesday 07 July 2009 5:51:03 am Ian J Hart wrote:
>> >> Quoting Ian J Hart <ianjhart at ntlworld.com>:
>> >>
>> >>> Quoting Ian J Hart <ianjhart at 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
>

It's ECC and was extensively tested when new so I suspect it's  
something else, but I'll memtest it overnight anyway.

Sat at a panic when I went to put the floppy in.No debugger prompt and  
unresponsive so I power cycled it :(

-- 
ian j hart

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.