Strange vkernel crash
Dave Hayes
dave at jetcafe.org
Mon Apr 9 15:10:31 PDT 2007
Matthew Dillon <dillon at apollo.backplane.com> writes:
> Maybe something in your /etc/ttys (the vkernel's /etc/ttys, that is)
> is causing init to blow up the vkernel. Try messing with that. Be
> sure to save the original in case that turns out to be the cause.
Well I've been bangin the ol head against the screen on this
crash. Since I really need to make progress here, it's like walking
through a forest with sunglasses on:
In /home/dave/gdbthis
set args -m 64m -r /var/vkernel/rootimg.1.8.1
break start_init
run
break vm_map_find
continue
# gdb -x /home/dave/gdbthis ./kernel.debug
GNU gdb 6.2.1
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-dragonfly"...
Breakpoint 1 at 0x809170a: file thread.h, line 83.
Using memory file: /var/vkernel/memimg.000000
Copyright (c) 2003, 2004, 2005, 2006, 2007 The DragonFly Project.
Copyright (c) 1992-2003 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.
DragonFly 1.8.1-RELEASE #0: Wed Apr 4 19:52:02 PDT 2007
dave at dfdev.jetcafe.org:/usr/altsrc/src.1.8.1/sys/compile/VKERNEL
real memory = 67108864 (65536K bytes)
avail memory = 62545920 (61080K bytes)
md0: Malloc disk
initclocks
IP packet filtering initialized, divert disabled, rule-based forwarding
enabled, default to accept, logging disabled
DUMMYNET initialized (011031)
IPsec: Initialized Security Association Processing.
Mounting root from ufs:vkd0a
Breakpoint 1, start_init (dummy=0x0) at thread.h:83
83 __asm ("movl %%fs:globaldata,%0" : "=r" (gd) :
"m"(__mycpu__dummy));
Breakpoint 2 at 0x81d98fc: file ../../vm/vm_map.c, line 996.
Breakpoint 2, vm_map_find (map=0x58772f00, object=0x7, offset=Unhandled dwarf
expression opcode 0x93
) at ../../vm/vm_map.c:996
996 start = *addr;
(gdb) break subyte
Breakpoint 3 at 0x81f840c: file ../../platform/vkernel/platform/copyio.c, line
209.
(gdb) c
Continuing.
Breakpoint 3, subyte (base=0x1, byte=1) at ../../platform/vkernel/platform/copy
io.c:209
209 unsigned char c = byte;
(gdb) bt
#0 subyte (base=0x1, byte=1) at ../../platform/vkernel/platform/copyio.c:209
#1 0x08091994 in start_init (dummy=0x0) at ../../kern/init_main.c:530
#2 0x081f6796 in fork_trampoline () at ../../platform/vkernel/i386/fork_tramp.
s:78
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x081fa76f in pmap_enter (pmap=0x58772f84, va=3217027072, m=0x548f7140, prot=7
'\a', wired=0)
at ../../platform/vkernel/platform/pmap.c:1734
1734 origpte = *pte;
(gdb) bt
#0 0x081fa76f in pmap_enter (pmap=0x58772f84, va=3217027072, m=0x548f7140,
prot=7 '\a', wired=0)
at ../../platform/vkernel/platform/pmap.c:1734
#1 0x081d5b76 in vm_fault_page (map=0x58772f00, vaddr=3217027072,
fault_type=3 '\003',
fault_flags=1227878396, errorp=0x5877ac94) at ../../vm/vm_fault.c:579
#2 0x081f8351 in copyout (kaddr=0x5877acbb, udaddr=0xbfbfffff, len=1)
at ../../platform/vkernel/platform/copyio.c:169
#3 0x081f842c in subyte (base=0x548f7140, byte=1418686784) at
. ./../platform/vkernel/platform/copyio.c:212
#4 0x08091994 in start_init (dummy=0x0) at ../../kern/init_main.c:530
#5 0x081f6796 in fork_trampoline () at ../../platform/vkernel/i386/fork_tramp.
s:78
(gdb) up 4
#4 0x08091994 in start_init (dummy=0x0) at ../../kern/init_main.c:530
530 (void)subyte(--ucp, 0); /* trailing zero */
It seems when it gets to the "subyte" call the first time, something
has trashed the stack.
What is the quickest way to find this problem and solve it?
------
Dave Hayes - Consultant - Altadena CA, USA - dave at jetcafe.org
>>> The opinions expressed above are entirely my own <<<
"What's so special about the Net? People -still- don't
listen..."
-The Unknown Drummer
More information about the Kernel
mailing list