Yet another crash in FreeBSD 5.1
Eivind Olsen
eivind at aminor.no
Sat Aug 9 13:50:24 PDT 2003
--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>
More information about the freebsd-current
mailing list