> Date: Sun, 7 Jan 2007 14:03:41 +0000 (GMT)
> From: Robert Watson <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
>
> 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 CambridgeI 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: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
pgpMYoyJA65XW.pgp
Description: PGP signature
