From owner-freebsd-bugs@FreeBSD.ORG Sun Jul 27 20:50:03 2008 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CDDE1065675 for ; Sun, 27 Jul 2008 20:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 520C28FC21 for ; Sun, 27 Jul 2008 20:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6RKo3hZ071446 for ; Sun, 27 Jul 2008 20:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6RKo22k071445; Sun, 27 Jul 2008 20:50:03 GMT (envelope-from gnats) Date: Sun, 27 Jul 2008 20:50:03 GMT Message-Id: <200807272050.m6RKo22k071445@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Kirk Strauser Cc: Subject: Re: kern/126002: Installing java/diablo-jdk15 crashes an amd64 machine X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kirk Strauser List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2008 20:50:03 -0000 The following reply was made to PR kern/126002; it has been noted by GNATS. From: Kirk Strauser To: Kris Kennaway Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/126002: Installing java/diablo-jdk15 crashes an amd64 machine Date: Sun, 27 Jul 2008 15:47:56 -0500 Here's what I came up with: $ sudo kgdb kernel.debug /var/tmp/vmcore.0 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 = 0; apic id = 00 fault virtual address = 0x8 fault code = supervisor write data, page not present instruction pointer = 0x8:0xffffffff8044ea20 stack pointer = 0x10:0xffffffffafe239d0 frame pointer = 0x10:0xffffff002350ea20 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 = 2558 (make) trap number = 12 panic: page fault cpuid = 0 Uptime: 28m24s Physical memory: 2034 MB Dumping 324 MB: 309 293 277 261 245 229 213 197 181 165 149 133 117 101 85 69 53 37 21 5 Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from / boot/kernel/tmpfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/tmpfs.ko Reading symbols from /boot/kernel/pflog.ko...Reading symbols from / boot/kernel/pflog.ko.symbols...done. done. Loaded symbols for /boot/kernel/pflog.ko Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/ kernel/pf.ko.symbols...done. done. Loaded symbols for /boot/kernel/pf.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from / boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from / boot/kernel/nullfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from / boot/kernel/fdescfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/fdescfs.ko Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from / boot/kernel/accf_http.ko.symbols...done. done. Loaded symbols for /boot/kernel/accf_http.ko #0 doadump () at pcpu.h:194 194 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) list *0xffffffff8044ea20 0xffffffff8044ea20 is in cpuset_rel (atomic.h:166). 161 */ 162 static __inline u_int 163 atomic_fetchadd_int(volatile u_int *p, u_int v) 164 { 165 166 __asm __volatile( 167 " " MPLOCKED " " 168 " xaddl %0, %1 ; " 169 "# atomic_fetchadd_int" 170 : "+r" (v), /* 0 (result) */ (kgdb) backtrace #0 doadump () at pcpu.h:194 #1 0x0000000000000004 in ?? () #2 0xffffffff8047e591 in boot (howto=260) at /usr/src/sys/kern/ kern_shutdown.c:418 #3 0xffffffff8047e9c2 in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:572 #4 0xffffffff8072ca4a in trap_fatal (frame=0xffffff0003fdf000, eva=18446742974791723232) at /usr/src/sys/amd64/amd64/trap.c:724 #5 0xffffffff8072cdf1 in trap_pfault (frame=0xffffffffafe23920, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:641 #6 0xffffffff8072d6af in trap (frame=0xffffffffafe23920) at /usr/src/ sys/amd64/amd64/trap.c:410 #7 0xffffffff807142ee in calltrap () at /usr/src/sys/amd64/amd64/ exception.S:169 #8 0xffffffff8044ea20 in cpuset_rel (set=0x0) at atomic.h:166 #9 0xffffffff8048aa6c in thread_free (td=0xffffff00237a4360) at /usr/ src/sys/kern/kern_thread.c:344 #10 0xffffffff8048ab51 in thread_reap () at /usr/src/sys/kern/ kern_thread.c:308 #11 0xffffffff8045da4b in kern_wait (td=0xffffffffafe23b3c, pid=Variable "pid" is not available. ) at /usr/src/sys/kern/kern_exit.c:787 #12 0xffffffff8045e039 in wait4 (td=Variable "td" is not available. ) at /usr/src/sys/kern/kern_exit.c:654 #13 0xffffffff8072d05c in syscall (frame=0xffffffffafe23c70) at /usr/ src/sys/amd64/amd64/trap.c:852 #14 0xffffffff807144fb in Xfast_syscall () at /usr/src/sys/amd64/amd64/ exception.S:290 #15 0x000000000041ee7c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) quit Is this enough information? I'm a kgdb newbie and not too sure what is needed. I'll happily provide anything else you need. Side note 1 ---- I was not able to save a crash dump to either of these drives: ad0: 715403MB at ata0-master SATA300 ad8: 286167MB at ata4-master UDMA100 It would start writing, but each 16MB chunk seemed to be exponentially slower than the last, so that after 5 or 6 chunks it was effectively hung. I ended up dumping to a USB keychain drive. Side note 2 ---- The dumpon(8) man page says: The dumpon utility will refuse to enable a dump device which is smaller than the total amount of physical memory as reported by the hw.physmem sysctl(8) variable. I made a crash dump of a 2GB RAM system to a 512MB flash drive which dumpon happily enabled.