Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 07 Jan 2007 23:00:49 -0400
From:      "Marc G. Fournier" <scrappy@freebsd.org>
To:        Kevin Oberman <oberman@es.net>, Robert Watson <rwatson@FreeBSD.org>
Cc:        freebsd-stable@freebsd.org, "Marc G. Fournier" <scrappy@freebsd.org>, jhb@FreeBSD.org
Subject:   Re: Fatal trap 12: page fault while in kernel mode 
Message-ID:  <5C33799266041ED9BD5BC288@ganymede.hub.org>
In-Reply-To: <20070108010240.1522845055@ptavv.es.net>
References:  <20070108010240.1522845055@ptavv.es.net>

next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I'm up and running on the patch now as well ...

- --On Sunday, January 07, 2007 17:02:40 -0800 Kevin Oberman <oberman@es.net> 
wrote:

>> Date: Sun, 7 Jan 2007 14:03:41 +0000 (GMT)
>> From: Robert Watson <rwatson@FreeBSD.org>
>> Sender: owner-freebsd-stable@freebsd.org
>>
>> On Sat, 6 Jan 2007, Marc G. Fournier wrote:
>>
>> > Just had the following happen on a FreeBSD 6.2-PRERELEASE #7: Sun Dec 17>
>> > 01:28:52 AST 2006 system ... amd64, HP Proliant, 6G of RAM ... have core >
>> > if  there is information that I can provide out of it ...
>> >
>> > Fatal trap 12: page fault while in kernel mode
>> > cpuid = 0; apic id = 00
>> > fault virtual address   = 0x18c
>> > fault code              = supervisor read, page not present
>> > instruction pointer     = 0x8:0xffffffff801f9053
>> > stack pointer           = 0x10:0xffffffffb5c78b30
>> > frame pointer           = 0x10:0xffffffffb5c78b60
>> > code segment            = base 0x0, limit 0xfffff, type 0x1b
>> >                        = DPL 0, pres 1, long 1, def32 0, gran 1
>> > processor eflags        = resume, IOPL = 0
>> > current process         = 5 (thread taskq)
>> > trap number             = 12
>> > panic: page fault
>> > cpuid = 0
>> > Uptime: 8d22h25m40s
>> >
>> > (kgdb) where
>> > # 0  doadump () at pcpu.h:172
>> > # 1  0xffffffff80203955 in boot (howto=260) at
>> > /usr/src/sys/kern/kern_shutdown.c:409
>> > # 2  0xffffffff80204065 in panic (fmt=0xffffff019b667720
>> > "X\223f\233\001???\020?c\233\001???") at
>> > /usr/src/sys/kern/kern_shutdown.c:565
>> > # 3  0xffffffff803287a6 in trap_fatal (frame=0xc, eva=1844674298110007>
>> > # 4784) at
>> > /usr/src/sys/amd64/amd64/trap.c:660
>> > # 4  0xffffffff80328cd8 in trap (frame=
>> >      {tf_rdi = 112, tf_rsi = -1092609476832, tf_rdx = 6, tf_rcx =>
>> >      3221225730, tf_r8 = -1245213424, tf_r9 = -1092609476832, tf_rax = 1,
>> > tf_rbx = - -1096874331952, tf_rbp = -1245213856, tf_r10 = -2142258536,
>> > tf_r11 > = 0, tf_r12 = 4, tf_r13 = -1092609476832, tf_r14 = 4, tf_r15 = 1,
>> > tf_trapno > = 12, tf_addr = 396, tf_flags = -2145197496, tf_err = 0,
>> > tf_rip = -2145415085, tf_c> s = 8, tf_rflags = 65538, tf_rsp =
>> > -1245213888, tf_ss = 16}) at
>> > /usr/src/sys/amd64/amd64/trap.c:238
>> > # 5  0xffffffff80313c6b in calltrap () at
>> > /usr/src/sys/amd64/amd64/exception.S:168
>> > # 6  0xffffffff801f9053 in _mtx_lock_sleep (m=0xffffff009d31f0d0,
>> > tid=18446742981100074784, opts=6, file=0xc0000102 <Address 0xc00001> 02
>> > out of bounds>, line=-1245213424) at /usr/src/sys/kern/kern_mutex.c:546
>> > # 7  0xffffffff8025b1ac in unp_gc (arg=0x70, pending=-1687783648) at
>> > /usr/src/sys/kern/uipc_usrreq.c:1714
>> > # 8  0xffffffff8022c314 in taskqueue_run (queue=0xffffff0000844800) at
>> > /usr/src/sys/kern/subr_taskqueue.c:257
>> > # 9  0xffffffff8022d0e7 in taskqueue_thread_loop (arg=0x70) at
>> > /usr/src/sys/kern/subr_taskqueue.c:376
>> > # 10 0xffffffff801e7b76 in fork_exit (callout=0xffffffff8022d060
>> > <taskqueue_thread_loop>, arg=0xffffffff805030d0, frame=0xffffffffb5c7>
>> > 8c50) at /usr/src/sys/kern/kern_fork.c:821
>> > # 11 0xffffffff80313fce in fork_trampoline () at
>> > /usr/src/sys/amd64/amd64/exception.S:394
>>
>> This is a NULL pointer dereference in the UNIX domain socket code.  John
>> Baldwin recently committed a fix for a bug with these symptoms to 7-CURRENT>
>> ,  with an MFC planned in the near future.  The fix won't make 6.2-RELEASE,
>> bu> t  assuming it tests out well over the next few weeks, we will cut an
>> errata>   patch/announcement for it.  I believe you can pull down his
>> 6-STABLE versio> n  at:
>>
>>    http://people.FreeBSD.org/~jhb/patches/unp_gc.patch
>>
>> This same patch is currently in texting on mx1.FreeBSD.org.
>>
>> (John CC'd)
>>
>> Robert N M Watson
>> Computer Laboratory
>> University of Cambridge
>
> I have installed this on my system, but the panics have always been very
> erratic, so it may be a while before I am sure whether this fixes it. At
> the moment the system has been up for 7 days, although I have had
> multiple crashes in a single day.
> --
> R. Kevin Oberman, Network Engineer
> Energy Sciences Network (ESnet)
> Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
> E-mail: oberman@es.net			Phone: +1 510 486-8634
> Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751



- ----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . scrappy@hub.org                              MSN . scrappy@hub.org
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)

iD8DBQFFobPh4QvfyHIvDvMRAuGBAJ4vwJoVIRmbdHK6wqBxneuUzjekfACgr4Ys
2DSldX3rTRAHkng3UqKO+8U=
=FtuJ
-----END PGP SIGNATURE-----




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5C33799266041ED9BD5BC288>