--On 7. august 2003 10:33 +0930 Greg 'groggy' Lehey <grog_at_FreeBSD.org> wrote: >> Q: If you have a crash, please supply a backtrace from the dump analysis >> as discussed below under Kernel Panics. Please don't delete the crash >> dump; it may be needed for further analysis. >> A: Sorry, I don't have a crash dump. I tried creating one when the >> computer had crashed by giving the commands "panic" and then "continue" >> but that didn't help. >> Was this of any help? > Not much, unfortunately. I think that these problems occur as the > result of some hardware failure, but there's nothing in what you've > supplied to indicate that. If you can't repeat it, I fear that it's > yet another of the ones that got away. I have now managed to produce a crash dump but I'm not sure if it's any good or not. For some reason I tried to give ddb the "panic" command twice in a row and then it at least produced a crash dump but I'm not sure if it contains any information. Here is a backtrace at least. Keep in mind that I'm not a C programmer and have no experience with gdb so I must be told what to do to produce more information. eivind_at_vimes:~/tmp/debug > gdb -k kernel.debug vmcore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 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-undermydesk-freebsd"... panic: from debugger panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x14 fault code = supervisor write, page not present instruction pointer = 0x8:0xc02e8139 stack pointer = 0x10:0xcac43a00 frame pointer = 0x10:0xcac43a34 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 5 (pagedaemon) panic: from debugger Fatal trap 3: breakpoint instruction fault while in kernel mode instruction pointer = 0x8:0xc048cd34 stack pointer = 0x10:0xcac43780 frame pointer = 0x10:0xcac4378c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = IOPL = 0 current process = 5 (pagedaemon) panic: from debugger Uptime: 1d13h38m55s Dumping 191 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 --- Reading symbols from /usr/obj/usr/src/sys/VIMES/modules/usr/src/sys/modules/vinum/vinum.ko.debug ...done. Loaded symbols for /usr/obj/usr/src/sys/VIMES/modules/usr/src/sys/modules/vinum/vinum.ko.debug Reading symbols from /usr/obj/usr/src/sys/VIMES/modules/usr/src/sys/modules/ipfw/ipfw.ko.debug.. .done. Loaded symbols for /usr/obj/usr/src/sys/VIMES/modules/usr/src/sys/modules/ipfw/ipfw.ko.debug Reading symbols from /boot/kernel/dragon_saver.ko...done. Loaded symbols for /boot/kernel/dragon_saver.ko #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:238 238 dumping++; (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:238 #1 0xc031a8f9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:370 #2 0xc031abeb in panic () at /usr/src/sys/kern/kern_shutdown.c:543 #3 0xc0173e92 in db_panic () at /usr/src/sys/ddb/db_command.c:448 #4 0xc0173e12 in db_command (last_cmdp=0xc0527740, cmd_table=0x0, aux_cmd_tablep=0xc051da0c, aux_cmd_tablep_end=0xc051da24) at /usr/src/sys/ddb/db_command.c:346 #5 0xc0173f26 in db_command_loop () at /usr/src/sys/ddb/db_command.c:470 #6 0xc0176caa in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:72 #7 0xc048ca95 in kdb_trap (type=12, code=0, regs=0xcac439c0) at /usr/src/sys/i386/i386/db_interface.c:170 #8 0xc049e772 in trap_fatal (frame=0xcac439c0, eva=0) at /usr/src/sys/i386/i386/trap.c:829 #9 0xc049e482 in trap_pfault (frame=0xcac439c0, usermode=0, eva=20) at /usr/src/sys/i386/i386/trap.c:748 #10 0xc049e05d in trap (frame= {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1039907200, tf_esi = -978486016, tf_ebp = -893109708, tf_isp = -893109780, tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax = 23179264, tf_trapno = 12, tf_err = 2, tf_eip = -1070694087, tf_cs = 8, tf_eflags = 66054, tf_esp = -978486016, tf_ss = -893109736}) at /usr/src/sys/i386/i386/trap.c:433 #11 0xc048e3e8 in calltrap () at {standard input}:96 #12 0xc02e5bc6 in spec_xstrategy (vp=0xc2044680, bp=0xc5ad7d00) at /usr/src/sys/fs/specfs/spec_vnops.c:513 #13 0xc02e5c4b in spec_specstrategy (ap=0x0) at /usr/src/sys/fs/specfs/spec_vnops.c:550 #14 0xc02e4f18 in spec_vnoperate (ap=0x0) at /usr/src/sys/fs/specfs/spec_vnops.c:123 #15 0xc0465c4d in swapdev_strategy (ap=0x0) at vnode_if.h:1114 #16 0xc0452809 in swap_pager_putpages (object=0x0, m=0xcac43bd0, count=1, sync=0, rtvals=0xcac43b40) at vnode_if.h:1089 #17 0xc04635e0 in vm_pageout_flush (mc=0xcac43bd0, count=1, flags=0, is_object_locked=0) at vm_pager.h:142 #18 0xc046349d in vm_pageout_clean (m=0x0) at /usr/src/sys/vm/vm_pageout.c:351 #19 0xc0464310 in vm_pageout_scan (pass=0) at /usr/src/sys/vm/vm_pageout.c:997 #20 0xc0464ebe in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:1491 #21 0xc0307c1e in fork_exit (callout=0xc0464bf0 <vm_pageout>, arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:768 (kgdb) I don't know if this backtrace is any good or if it just refers to the panic-command I typed into ddb. At least this one doesn't refer to g_dev_strategy or any functions called vinum-something. But the instruction pointer, fault virtual address and fault code are the same as before. If this is something to look deeper into, please tell me which commands to enter into gdb etc. Also, I can make the kernel + modules + crashdump available on for example FTP or web if need be. > There have also been some problems with GEOM lately. Maybe, despite > all indications, it's a GEOM problem. You should probably upgrade. I was going to try CURRENT (still using RELENG_5_1 here now) but I haven't gotten to it yet. I'm actually a bit scared of going to CURRENT, especially since there seems to be mentions of GEOM/Vinum issues which are apparently not resolved. -- Regards / Hilsen Eivind Olsen <eivind_at_aminor.no>Received on Sat Aug 09 2003 - 11:50:24 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:18 UTC