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=18446742981100074784) 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_cs = 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 0xc0000102 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=0xffffffffb5c78c50) 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, but 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 version 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
_______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"