Unable to get crash dump
Hi All, Running 8.3-STABLE 5/21/2012 on HP DL360. While testing crash dump functionality, the dump aborts with the following message: Aborting dump due to I/O error. status == 0xb, scsi status == 0x0 ** DUMP FAILED (ERROR 5) ** Automatic reboot in 5 seconds - press a key on the console to abort Googling and searching freebsd.org have produced what appeared to be some what relevant messages, but I found nothing pointing to a cause and fix. I'm hoping someone might be able to point me in a direction to figuring this out. -- Take care Rick Miller ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Help with crash dump
On 09/09/11 14:26, Bernt Hansson wrote: You have run out of swapspace, based on these 2 lines panic: ffs_write: dir write current process = 0 (swapper) Hmmm... Cacti woldn't think so: the graph about swap space is plain flat (round 0%, by the way); of course it could have risen so fast that it reached 100% between two consecutive polls, but I doubt it. Besides, why would the system crash for such a reason? I'd expect application failing, not the whole kernel. Am I wrong? Or you have a hardware error. SOB! I hope not. RAM is fine, HDs are SAS RAID with a good contoller which should have detected failures... What else can I check? > Does the "current process" change between panics or is it always the same? Right now I've only had this crash (and hope no other will follow). In the worst case, I'll take notice. I'm in no sense a kernel debugger, but it's a hint. I appreciate your interest anyway. bye & Thanks av. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Help with crash dump
2011-09-08 22:11, Andrea Venturoli skrev: Hello. Anyone can give any hint on this? Guessing! You have run out of swapspace, based on these 2 lines panic: ffs_write: dir write current process = 0 (swapper) Or you have a hardware error. Does the "current process" change between panics or is it always the same? I'm in no sense a kernel debugger, but it's a hint. I really have no clue. bye & Thanks av. # uname -a FreeBSD x..it 7.3-RELEASE-p4 FreeBSD 7.3-RELEASE-p4 #1: Wed Dec 15 11:53:13 CET 2010 r...@x..it:/usr/obj/usr/src/sys/x i386 # kgdb kernel.debug /var/crash/vmcore.17 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 "i386-marcel-freebsd"... Unread portion of the kernel message buffer: panic: ffs_write: dir write cpuid = 3 Uptime: 26d9h4m27s Physical memory: 2033 MB Dumping 300 MB: 285 269 253 237 221 205 189 173 157 141 125 109 93 77kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x20:0xc059accb stack pointer = 0x28:0xc0c20ccc frame pointer = 0x28:0xc0c20cec code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 0 (swapper) trap number = 12 panic: page fault cpuid = 3 61 45 29 13 Reading symbols from /boot/kernel/splash_bmp.ko...Reading symbols from /boot/kernel/splash_bmp.ko.symbols...done. done. Loaded symbols for /boot/kernel/splash_bmp.ko Reading symbols from /boot/kernel/geom_stripe.ko...Reading symbols from /boot/kernel/geom_stripe.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_stripe.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at pcpu.h:196 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc0563d48 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc0564025 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc06cd16d in ffs_write (ap=0xe6912a44) at /usr/src/sys/ufs/ffs/ffs_vnops.c:667 #4 0xc0740640 in VOP_WRITE_APV (vop=0xc07ba4e0, a=0xe6912a44) at vnode_if.c:691 #5 0xc06fd8d6 in vnode_pager_generic_putpages (vp=0xc672f678, m=0xe6912bb0, bytecount=Variable "bytecount" is not available. ) at vnode_if.h:373 #6 0xc05d4a5f in vop_stdputpages (ap=0xe6912ad4) at /usr/src/sys/kern/vfs_default.c:540 #7 0xc073faf3 in VOP_PUTPAGES_APV (vop=0xc07ba4e0, a=0xe6912ad4) at vnode_if.c:2189 #8 0xc06fda5f in vnode_pager_putpages (object=0xcb14ac80, m=0xe6912bb0, count=1, sync=0, rtvals=0xe6912b20) at vnode_if.h:1164 #9 0xc06f730b in vm_pageout_flush (mc=0xe6912bb0, count=1, flags=0) at vm_pager.h:148 #10 0xc06f7661 in vm_pageout_clean (m=Variable "m" is not available. ) at /usr/src/sys/vm/vm_pageout.c:403 #11 0xc06f92a2 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:1017 #12 0xc053e9a1 in fork_exit (callout=0xc06f82d6 , arg=0x0, frame=0xe6912d38) at /usr/src/sys/kern/kern_fork.c:811 #13 0xc0718b30 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:271 (kgdb) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Help with crash dump
Hello. Anyone can give any hint on this? I really have no clue. bye & Thanks av. # uname -a FreeBSD x..it 7.3-RELEASE-p4 FreeBSD 7.3-RELEASE-p4 #1: Wed Dec 15 11:53:13 CET 2010 r...@x..it:/usr/obj/usr/src/sys/x i386 # kgdb kernel.debug /var/crash/vmcore.17 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 "i386-marcel-freebsd"... Unread portion of the kernel message buffer: panic: ffs_write: dir write cpuid = 3 Uptime: 26d9h4m27s Physical memory: 2033 MB Dumping 300 MB: 285 269 253 237 221 205 189 173 157 141 125 109 93 77kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x20:0xc059accb stack pointer = 0x28:0xc0c20ccc frame pointer = 0x28:0xc0c20cec code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 0 (swapper) trap number = 12 panic: page fault cpuid = 3 61 45 29 13 Reading symbols from /boot/kernel/splash_bmp.ko...Reading symbols from /boot/kernel/splash_bmp.ko.symbols...done. done. Loaded symbols for /boot/kernel/splash_bmp.ko Reading symbols from /boot/kernel/geom_stripe.ko...Reading symbols from /boot/kernel/geom_stripe.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_stripe.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at pcpu.h:196 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc0563d48 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc0564025 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc06cd16d in ffs_write (ap=0xe6912a44) at /usr/src/sys/ufs/ffs/ffs_vnops.c:667 #4 0xc0740640 in VOP_WRITE_APV (vop=0xc07ba4e0, a=0xe6912a44) at vnode_if.c:691 #5 0xc06fd8d6 in vnode_pager_generic_putpages (vp=0xc672f678, m=0xe6912bb0, bytecount=Variable "bytecount" is not available. ) at vnode_if.h:373 #6 0xc05d4a5f in vop_stdputpages (ap=0xe6912ad4) at /usr/src/sys/kern/vfs_default.c:540 #7 0xc073faf3 in VOP_PUTPAGES_APV (vop=0xc07ba4e0, a=0xe6912ad4) at vnode_if.c:2189 #8 0xc06fda5f in vnode_pager_putpages (object=0xcb14ac80, m=0xe6912bb0, count=1, sync=0, rtvals=0xe6912b20) at vnode_if.h:1164 #9 0xc06f730b in vm_pageout_flush (mc=0xe6912bb0, count=1, flags=0) at vm_pager.h:148 #10 0xc06f7661 in vm_pageout_clean (m=Variable "m" is not available. ) at /usr/src/sys/vm/vm_pageout.c:403 #11 0xc06f92a2 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:1017 #12 0xc053e9a1 in fork_exit (callout=0xc06f82d6 , arg=0x0, frame=0xe6912d38) at /usr/src/sys/kern/kern_fork.c:811 #13 0xc0718b30 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:271 (kgdb) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Crash dump freebsd 7.2
I have several jails running on my freebesd machine and lately it started to crash when it gets a bit loaded. I followed the freebsd kernel debugging manual, and got some output, but I have no idea what to do with it. The only thing I think I understand of it that the bit that matters are just the two last lines. Is there anyone that can help? # kgdb kernel.debug /var/crash/vmcore.2 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 "i386-marcel-freebsd"... Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x10 fault code = supervisor read, page not present instruction pointer = 0x20:0xc07d4a21 stack pointer = 0x28:0xe9c879c4 frame pointer = 0x28:0xe9c879d8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 18223 (libssl.so) trap number = 12 panic: page fault cpuid = 1 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x6e727598 fault code = supervisor read, page not present instruction pointer = 0x20:0xc08bf945 stack pointer = 0x28:0xc72bfaa8 frame pointer = 0x28:0xc72bfacc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 30 (em1 taskq) trap number = 12 panic: page fault cpuid = 1 Uptime: 12h20m45s Physical memory: 3827 MB Dumping 295 MB: 280 264 248 232 216 200 184 168 152 136 120 104 88 72 56 40 24 8 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.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 #0 doadump () at pcpu.h:196 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Help with crash dump
Hello. Any one can make anything out of this crash dump? It's an SMP amd64 6.2 box with a RAID-5 SCSI controller and a couple GiB of RAM. We are also using GELI. bye & Thanks av. -- # kgdb kernel.debug /var/crash/vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] 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: 0s1e 0xff004ecf5510: tag ufs, type VREG usecount 1, writecount 0, refcount 9 mountedhere 0 flags () v_object 0xff002a70d000 ref 0 pages 515 lock type ufs: EXCL (count 1) by thread 0xff007a85d720 (pid 31) with 1 pending#0 0x802252b6 at lockmgr+0x5f6 #1 0x80302068 at ffs_lock+0x58 #2 0x80384fc1 at VOP_LOCK_APV+0x81 #3 0x802a78bb at vn_lock+0x6b #4 0x8029ba00 at vget+0x90 #5 0x80329cb9 at vm_pageout+0x1309 #6 0x8021a30b at fork_exit+0xbb #7 0x803358ee at fork_trampoline+0xe ino 118134, on dev amrd0s1e 0xff000ba75510: tag ufs, type VREG usecount 1, writecount 1, refcount 3 mountedhere 0 flags () v_object 0xff0043d80380 ref 0 pages 9 lock type ufs: EXCL (count 1) by thread 0xff0079b9b980 (pid 447)#0 0x802252b6 at lockmgr+0x5f6 #1 0x80302068 at ffs_lock+0x58 #2 0x80384fc1 at VOP_LOCK_APV+0x81 #3 0x802a78bb at vn_lock+0x6b #4 0x802a3cfb at fsync+0xab #5 0x8034a731 at syscall+0x4d1 #6 0x80335728 at Xfast_syscall+0xa8 ino 188422, on dev amrd0s1e 0xff0008358510: tag ufs, type VREG usecount 1, writecount 1, refcount 3 mountedhere 0 flags () v_object 0xff0064290e00 ref 0 pages 3 lock type ufs: EXCL (count 1) by thread 0xff001de6cbe0 (pid 3365)#0 0x802252b6 at lockmgr+0x5f6 #1 0x80302068 at ffs_lock+0x58 #2 0x80384fc1 at VOP_LOCK_APV+0x81 #3 0x802a78bb at vn_lock+0x6b #4 0x802a3cfb at fsync+0xab #5 0x8034a731 at syscall+0x4d1 #6 0x80335728 at Xfast_syscall+0xa8 ino 117876, on dev amrd0s1e 0xff0011565a20: tag ufs, type VREG usecount 1, writecount 1, refcount 3 mountedhere 0 flags () v_object 0xff002c970e00 ref 0 pages 3 lock type ufs: EXCL (count 1) by thread 0xff00496e3000 (pid 3367)#0 0x802252b6 at lockmgr+0x5f6 #1 0x80302068 at ffs_lock+0x58 #2 0x80384fc1 at VOP_LOCK_APV+0x81 #3 0x802a78bb at vn_lock+0x6b #4 0x802a3cfb at fsync+0xab #5 0x8034a731 at syscall+0x4d1 #6 0x80335728 at Xfast_syscall+0xa8 ino 118135, on dev amrd0s1e 0xff0036d66a20: tag ufs, type VREG usecount 1, writecount 1, refcount 3 mountedhere 0 flags () v_object 0xff001d4a21c0 ref 0 pages 3 lock type ufs: EXCL (count 1) by thread 0xff0046644980 (pid 3368)#0 0x802252b6 at lockmgr+0x5f6 #1 0x80302068 at ffs_lock+0x58 #2 0x80384fc1 at VOP_LOCK_APV+0x81 #3 0x802a78bb at vn_lock+0x6b #4 0x802a3cfb at fsync+0xab #5 0x8034a731 at syscall+0x4d1 #6 0x80335728 at Xfast_syscall+0xa8 ino 118141, on dev amrd0s1e 0xff000419c288: tag ufs, type VREG usecount 1, writecount 1, refcount 3 mountedhere 0 flags () v_object 0xff0049701000 ref 0 pages 3 lock type ufs: EXCL (count 1) by thread 0xff003264c000 (pid 3369)#0 0x802252b6 at lockmgr+0x5f6 #1 0x80302068 at ffs_lock+0x58 #2 0x80384fc1 at VOP_LOCK_APV+0x81 #3 0x802a78bb at vn_lock+0x6b #4 0x802a3cfb at fsync+0xab #5 0x8034a731 at syscall+0x4d1 #6 0x80335728 at Xfast_syscall+0xa8 ino 118305, on dev amrd0s1e 0xff0077dc1000: tag ufs, type VREG usecount 1, writecount 1, refcount 2 mountedhere 0 flags () v_object 0xff004478f8c0 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xff0079b9d980 (pid 593)#0 0x802252b6 at lockmgr+0x5f6 #1 0x80302068 at ffs_lock+0x58 #2 0x80384fc1 at VOP_LOCK_APV+0x81 #3 0x802a78bb at vn_lock+0x6b #4 0x802a8ab6 at vn_write+0x156 #5 0x8025f667 at dofilewrite+0x87 #6 0x8025f931 at kern_writev+0x51 #7 0x8025fa2a at write+0x4a #8 0x8034a731 at syscall+0x4d1 #9 0x80335728 at Xfast_syscall+0xa8 ino 212070, on dev amrd0s1e 0xff00082c5798: tag ufs, type VREG usecount 1, writecount 0, refcount 11258 mountedhe
Re: kernel crash dump could not be obtained
On Mon, Oct 31, 2005 at 02:58:50AM -0800, kamal kc wrote: > but rebooting does not show any crash dump file > on /var/crash. What is displayed when savecore is run at boot time? Alternatively, what happens when you run savecore yourself? You may not have enough space on /var to save the dump. Kris P.S. Don't cross-post questions@ and [EMAIL PROTECTED] pgpTjN9IVzhfR.pgp Description: PGP signature
kernel crash dump could not be obtained
dear all, i have to make modifictions to the kernel and i have been encountering kernel crashes all the time. the kernel panics with messages starting with vm_fault: and then crashes and reboots. i guess i have done incorrect memory operations and i want to know where i went wrong. so i thought of obtaining the crash dump. i went through the developers guide. and i added the following lines on the /etc/rc.conf --- dumpdev="/dev/ad0s1b" dumpdir="/var/crash" savecore_flags="" -- the /etc/fstab file is Device Mountpoint FStype Options DumpPass# /dev/ad0s1b noneswapsw 0 0 /dev/ad0s1a / ufs rw 1 1 /dev/ad0s1e /tmpufs rw 2 2 /dev/ad0s1f /usrufs rw 2 2 /dev/ad0s1d /varufs rw 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 swap partition is /dev/ad0s1b swapinfo gives the output:-- Device 1K-blocks UsedAvail Capacity /dev/ad0s1b4950480 495048 0% My memory size according to dmesg is -- real memory = 266600448 (254 MB) avail memory = 251232256 (239 MB) -- Now when the kernel crashes it prints the message writing dump 240MB but rebooting does not show any crash dump file on /var/crash. please help kamal __ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
crash dump
Hi, I compiled my FreeBSD 5.3-STABLE kernel with options KDB, DDB makeoptions DEBUG="-g" and wrote a kernel module that does nothing but call panic() upon its loading, to try experimenting on crash kernel debugger and crash dump. Upon kldload the module, KDB was invoked and I was dropped into a console debugger that let me see the backtrace by typing "where". However, when I typed "panic" as suggested by the FAQ, it doesn't dump anything to my swap device. Only by typing "call doadump" in the KDB that it does the job. I wonder why? Any help is appreciated. Thanks. Yours truly, Tan, Wei Chong. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
no crash dump generated
Hi. A couple of days ago I upgrades the system and a few ports on a 5.3 box and since then I'm often getting crashes. -bash-2.05b# uname -a FreeBSD jupiter.noonlights.net 5.3-RELEASE-p5 FreeBSD 5.3-RELEASE-p5 #0: Sun Feb 13 22:56:47 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/JUPITER i386 I'd like to get a crash dump and so I added the following lines to /etc/rc.conf dumpdev="/dev/ad0s1b" dumpdir="/usr/crash" -bash-2.05b# ls -ld /usr/crash/ drwx-- 2 root wheel 512 Feb 16 11:17 /usr/crash/ but I'm not getting any dump! /usr/crash is always empty. ..and the machine crashes quite often: -bash-2.05b# last|grep reboot reboot ~ Wed Feb 16 20:04 reboot ~ Wed Feb 16 19:17 reboot ~ Wed Feb 16 18:40 reboot ~ Wed Feb 16 17:26 reboot ~ Wed Feb 16 14:07 reboot ~ Wed Feb 16 12:39 reboot ~ Wed Feb 16 11:30 reboot ~ Wed Feb 16 10:27 reboot ~ Wed Feb 16 09:31 reboot ~ Wed Feb 16 09:16 What do I miss? Do I need some kernel option? Best regards. -- Roberto Nunnari -software engineer- mailto:[EMAIL PROTECTED] Scuola Universitaria Professionale della Svizzera Italiana Dipartimento Tecnologie Innovative http://www.dti.supsi.ch SUPSI-DTI Via Cantonaletel: +41-91-6108561 6928 Manno """ fax: +41-91-6108570 Switzerland (o o) ===oOO==(_)==OOo ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
4.11: crash dump while burning cdr
In case anybody is still interested in this one. I got it while burning a CDR with xcdroast. For lisp-related reasons the kernel was also build with options KVA_PAGES=768. I doubt it's easily repeatable. IdlePTD at physical address 0x003fd000 initial pcb at physical address 0x0034b440 panicstr: page fault panic messages: --- dmesg: kvm_read: --- #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 487 if (dumping++) { (kgdb) bt #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 #1 0x4017d147 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316 #2 0x4017d56c in poweroff_wait (junk=0x403166ac, howto=1076978095) at /usr/src/sys/kern/kern_shutdown.c:595 #3 0x402b9c6a in trap_fatal (frame=0x64978ea0, eva=3217030860) at /usr/src/sys/i386/i386/trap.c:974 #4 0x402b993d in trap_pfault (frame=0x64978ea0, usermode=0, eva=3217030860) at /usr/src/sys/i386/i386/trap.c:867 #5 0x402b9527 in trap (frame={tf_fs = 16, tf_es = 1105068048, tf_ds = 16, tf_edi = -1077936456, tf_esi = -1077936456, tf_ebp = 1687654116, tf_isp = 1687654092, tf_ebx = 1687654148, tf_edx = 1687642112, tf_ecx = -1077936456, tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 1127506396, tf_cs = 8, tf_eflags = 66118, tf_esp = 1684635488, tf_ss = 1687654184}) at /usr/src/sys/i386/i386/trap.c:466 #6 0x433461dc in ?? () #7 0x43346682 in ?? () #8 0x402b9f19 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 7, tf_esi = 0, tf_ebp = 1069465256, tf_isp = 1687654356, tf_ebx = 7, tf_edx = 1069465184, tf_ecx = 14, tf_eax = 221, tf_trapno = 12, tf_err = 2, tf_eip = 134645480, tf_cs = 31, tf_eflags = 582, tf_esp = 1069465148, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1175 #9 0x402adc45 in Xint0x80_syscall () #10 0x804b50e in ?? () #11 0x804a065 in ?? () #12 0x804a91a in ?? () #13 0x804864f in ?? () #14 0x804ce9f in ?? () Cheers, Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: finally a crash dump on 5.3
On Thu, Jan 06, 2005 at 08:56:45AM -0600, J.D. Bronson wrote: > I was up for 2wks and today saw this: > > Fatal trap 12 - page fault while in kernel mode > CPUID 0 APIC ID 0 > Fault write address = 0x418ad66c > Fault code = supervisor write, page not present > > Inst Pointer = 0x8:0xc05109d9 > Stack Pointer = 0x10:0xe5ea8978 > Frame Pointer = 0x10:0xe5ea8994 > Code Segment base 0x0 limit 0x type 0x1b > DPL 0, PRES 1 def 32 1, gran 1 > > current process= 7673 (telnetd) > > -JEFF > ..I had thought this was SCSI, but I dont have any scsi drives installed > and was running on IDE. > > What do I do with this information now that I finally have it ? That's not a crashdump, that's a panic. Check the handbook for the steps required to enable crashdumping. Kris pgpmU1hJFZvjP.pgp Description: PGP signature
Re: finally a crash dump on 5.3
On 2005-01-06 09:44, "J.D. Bronson" <[EMAIL PROTECTED]> wrote: > At 09:32 AM 1/6/2005, Giorgos Keramidas wrote: > >On 2005-01-06 08:56, "J.D. Bronson" <[EMAIL PROTECTED]> wrote: > >> I was up for 2wks and today saw this: > >> > >> Fatal trap 12 - page fault while in kernel mode > >> CPUID 0 APIC ID 0 > >> Fault write address = 0x418ad66c > >> Fault code = supervisor write, page not present > >> > >> What do I do with this information now that I finally have it ? > > > > During the next boot, savecore should save a crash dump in > > /var/crash (assuming one was successfully saved in swap when the > > crash happened). > > > > Look at the Developers Handbook for details about obtaining a stack > > trace of the kernel at the moment of the crash: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-gdb.html > > Well so much for that idea :( > > 9:43:24am /var/crash> ls -al > total 6 > drwxr-x--- 2 root wheel 512 Dec 29 18:25 . > drwxr-xr-x 23 root wheel 512 Jan 6 09:37 .. > -rw-r--r-- 1 root wheel5 Nov 4 19:27 minfree Then you are still seeing crashes without a dump :-( - Giorgos ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: finally a crash dump on 5.3
On Thu, 2005-01-06 at 09:44 -0600, J.D. Bronson wrote: > At 09:32 AM 1/6/2005, Giorgos Keramidas wrote: > >On 2005-01-06 08:56, "J.D. Bronson" <[EMAIL PROTECTED]> wrote: > > > I was up for 2wks and today saw this: > > > > > > Fatal trap 12 - page fault while in kernel mode > > > CPUID 0 APIC ID 0 > > > Fault write address = 0x418ad66c > > > Fault code = supervisor write, page not present > > > [...] > > > > > > What do I do with this information now that I finally have it ? > > > >During the next boot, savecore should save a crash dump in /var/crash > >(assuming one was successfully saved in swap when the crash happened). > > > >Look at the Developers Handbook for details about obtaining a stack > >trace of the kernel at the moment of the crash: > >http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-gdb.html > > > Well so much for that idea :( > > 9:43:24am /var/crash> ls -al > total 6 > drwxr-x--- 2 root wheel 512 Dec 29 18:25 . > drwxr-xr-x 23 root wheel 512 Jan 6 09:37 .. > -rw-r--r-- 1 root wheel5 Nov 4 19:27 minfree Call me old-fashioned, but I'd run memtest. Peter. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: finally a crash dump on 5.3
At 09:32 AM 1/6/2005, Giorgos Keramidas wrote: On 2005-01-06 08:56, "J.D. Bronson" <[EMAIL PROTECTED]> wrote: > I was up for 2wks and today saw this: > > Fatal trap 12 - page fault while in kernel mode > CPUID 0 APIC ID 0 > Fault write address = 0x418ad66c > Fault code = supervisor write, page not present > [...] > > What do I do with this information now that I finally have it ? During the next boot, savecore should save a crash dump in /var/crash (assuming one was successfully saved in swap when the crash happened). Look at the Developers Handbook for details about obtaining a stack trace of the kernel at the moment of the crash: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-gdb.html Well so much for that idea :( 9:43:24am /var/crash> ls -al total 6 drwxr-x--- 2 root wheel 512 Dec 29 18:25 . drwxr-xr-x 23 root wheel 512 Jan 6 09:37 .. -rw-r--r-- 1 root wheel5 Nov 4 19:27 minfree -- J.D. Bronson Aurora Health Care // Information Services // Milwaukee, WI USA Office: 414.978.8282 // Email: [EMAIL PROTECTED] // Pager: 414.314.8282 This message should contain confidential and/or privileged information, but it doesn't. If you are not the addressee or authorized to receive this for the addressee, go ahead, copy, disclose, or take any action based on this message or any information herein that you wish, what the heck! If you have received this message in error, please ask the sender what the heck they were thinking about. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: finally a crash dump on 5.3
On 2005-01-06 08:56, "J.D. Bronson" <[EMAIL PROTECTED]> wrote: > I was up for 2wks and today saw this: > > Fatal trap 12 - page fault while in kernel mode > CPUID 0 APIC ID 0 > Fault write address = 0x418ad66c > Fault code = supervisor write, page not present > [...] > > What do I do with this information now that I finally have it ? During the next boot, savecore should save a crash dump in /var/crash (assuming one was successfully saved in swap when the crash happened). Look at the Developers Handbook for details about obtaining a stack trace of the kernel at the moment of the crash: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-gdb.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
finally a crash dump on 5.3
I was up for 2wks and today saw this: Fatal trap 12 - page fault while in kernel mode CPUID 0 APIC ID 0 Fault write address = 0x418ad66c Fault code = supervisor write, page not present Inst Pointer = 0x8:0xc05109d9 Stack Pointer = 0x10:0xe5ea8978 Frame Pointer = 0x10:0xe5ea8994 Code Segment base 0x0 limit 0x type 0x1b DPL 0, PRES 1 def 32 1, gran 1 current process= 7673 (telnetd) -JEFF ..I had thought this was SCSI, but I dont have any scsi drives installed and was running on IDE. What do I do with this information now that I finally have it ? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 5.3BETA5: kernel panic and crash dump
Hello, I have a FreeBSD 5.3-BETA5 server that panics more or less every week. I have compiled the kernel with "makeoptions DEBUG=-g" and got a vmcore of the last crash. Next stop will be installing FreeBSD 5.3-RELEASE within the next days. Here is the kgdb output: # cd /usr/obj/usr/src/sys/GENERIC/ # kgdb /boot/kernel.debug/kernel.debug /var/crash/vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] 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 "i386-marcel-freebsd". doadump () at pcpu.h:159 (kgdb) bt #0 doadump () at pcpu.h:159 #1 0xc060b1fb in boot (howto=260) at ../../../kern/kern_shutdown.c:397 #2 0xc060b521 in panic (fmt=0xc07ec8c8 "%s") at ../../../kern/kern_shutdown.c:553 #3 0xc07a5aa4 in trap_fatal (frame=0xe9979c30, eva=4) at ../../../i386/i386/trap.c:809 #4 0xc07a57e7 in trap_pfault (frame=0xe9979c30, usermode=0, eva=4) at ../../../i386/i386/trap.c:727 #5 0xc07a5421 in trap (frame= {tf_fs = 24, tf_es = 16, tf_ds = -937099248, tf_edi = 1, tf_esi = -929937744, tf_ebp = -375939972, tf_isp = -375940004, tf_ebx = -932514684, tf_edx = 0, tf_ecx = -928768836, tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip = -1067512973, tf_cs = 8, tf_eflags = 66067, tf_esp = -929937744, tf_ss = -929937836}) at ../../../i386/i386/trap.c:417 #6 0xc079390a in calltrap () at ../../../i386/i386/exception.s:140 #7 0x0018 in ?? () #8 0x0010 in ?? () #9 0xc8250010 in ?? () #10 0x0001 in ?? () #11 0xc89246b0 in ?? () #12 0xe9979c7c in ?? () #13 0xe9979c5c in ?? () #14 0xc86af484 in ?? () #15 0x in ?? () #16 0xc8a41cbc in ?? () #17 0x0001 in ?? () #18 0x000c in ?? () #19 0x in ?? () #20 0xc05f0b73 in knlist_remove_kq (knl=0xc89246b0, kn=0xc86af484, knlislocked=1, kqislocked=0) at ../../../kern/kern_event.c:1510 #21 0xc05f0c53 in knlist_remove (knl=0xc89246b0, kn=0xc86af484, islocked=1) at ../../../kern/kern_event.c:1528 #22 0xc06434f0 in filt_sordetach (kn=0xc89246b0) at ../../../kern/uipc_socket.c:2164 #23 0xc05f0f79 in knote_fdclose (td=0xc7d7baf0, fd=13) at ../../../kern/kern_event.c:1677 #24 0xc05ea4d8 in close (td=0xc7d7baf0, uap=0x0) at ../../../kern/kern_descrip.c:994 #25 0xc07a5daf in syscall (frame= {tf_fs = -1065811921, tf_es = 47, tf_ds = 47, tf_edi = 135872512, tf_esi = -1077966576, tf_ebp = -1077966696, tf_isp = -375939724, tf_ebx = 672990700, tf_edx = 672983748, tf_ecx = 135872512, tf_eax = 6, tf_trapno = 22, tf_err = 2, tf_eip = 672503139, tf_cs = 31, tf_eflags = 646, tf_esp = -1077966724, tf_ss = 47}) at ../../../i386/i386/trap.c:1001 #26 0xc079395f in Xint0x80_syscall () at ../../../i386/i386/exception.s:201 #27 0xc079002f in bsd_disklabel_le_dec (ptr=0x8194000 , d=Cannot access memory at address 0xbfbf88a4 ) at endian.h:121 Previous frame inner to this frame (corrupt stack?) (kgdb) and also the dmesg output: # dmesg Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-BETA5 #0: Sat Nov 6 19:38:50 EET 2004 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.66GHz (2658.10-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf25 Stepping = 5 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 2147418112 (2047 MB) avail memory = 2095955968 (1998 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ACPI-0697: *** Warning: Type override - [DEB_] had invalid type (Integer) for Scope operator, changed to (Scope) ACPI-0697: *** Warning: Type override - [MLIB] had invalid type (Integer) for Scope operator, changed to (Scope) ACPI-0697: *** Warning: Type override - [DATA] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0697: *** Warning: Type override - [SIO_] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0697: *** Warning: Type override - [LEDP] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0697: *** Warning: Type override - [GPEN] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0697: *** Warning: Type override - [GPST] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0697: *** Warning: Type override - [GP1N] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0697: *** Warning: Type override - [WUES] had invalid type (String) for Scope op
Crash Dump
FreeBSD sage-american.com 4.8-RELEASE-p13 Hello again. Hope this the place for this question. One of my mail servers has been crashing for several months about once every 2 weeks at random times and after changing out all hardware, including shifting the OS to 3 different machines, I finally concluded it was the OS and setup to catch a crash dump. The dump is submitted below and perhaps someone knows how to tranlate it for a recommended fix. If this should be on another list, please let me know. Thanks for any help! CRASH DUMP: (kgdb) symbol-file kernel.debug Reading symbols from kernel.debug...(no debugging symbols found)...done. (kgdb) exec-file /usr/crash/kernel.0 (kgdb) core-file /usr/crash/vmcore.0 IdlePTD at phsyical address 0x003e7000 initial pcb at physical address 0x003494a0 panicstr: lockmgr: locking against myself panic messages: --- panic: lockmgr: locking against myself syncing disks... 24 3 done Uptime: 3h46m33s dumping to dev #ad/0x20001, offset 3145856 dump ata0: resetting devices .. done 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 0xc018d12a in dumpsys () (kgdb) END CRASH DUMP Best regards, Jack L. Stone, Administrator Sage American http://www.sage-american.com [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Trying to write a crash dump -> Trying to debug a kernel panic
I am trying to debug a boot time kernel panic. This is completely new territory for me and I need some help. I'm taking this one step at a time, the first step is to get a crash dump. This is a repeateable panic which occurs when I boot from my windows partition to my FreeBSD partition. Once the panic occurs, booting again clears the problem. Following the documentation in -http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html has gotten me so far, but I am stuck. I can trap and get dumped into the debugger (I think it's the debugger, the prompt is "db>"). However I am trying to get a core dump written and that's where I am having no success. 1) I've added the kernel debugging options -- options DDB #Debug Support makeoptions DEBUG=-g options KTRACE 2) made and installed the kernel, 3) added the following params to the rc.conf file -- dumpdir="/var/crash" dumpdev="/dev/ad0s2b" - where dumpdev corresponds to the swap device the fstab entry corresponds below. /dev/ad0s2b none swapsw0 0 4) executed the command "dumpon -v /dev/ad0s2b" 5) rebooted to wwindows 6) rebooted to freeBSD -> panic -> "db> prompt" 7) At this point I examined a few commands, (e.g. trace, show reg) and finished with the "panic" command which according to the documentation at http://www.freebsd.org/doc/en_US.ISO8859-1/ \ books/developers-handbook/x9854.html "This will cause your kernel to dump core and reboot, so you can later analyze the core on a higher level with gdb. " 8) At which the system rebooted and came up, but with no core file Joe Sotham Christianity got over the difficulty of furious opposites by keeping them both and keeping them furious. - G.K. Chesterton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message