On Sat, Mar 10, 2007 at 04:49:21PM +0100, Attilio Rao wrote: > 2007/3/10, Tillman Hodgson <tillman_at_seekingfire.com>: > >I'm trying to follow the instructions at > >http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/advanced.html#KERNEL-PANIC-TROUBLESHOOTING > >and in > >http://www.onlamp.com/pub/a/bsd/2002/04/04/Big_Scary_Daemons.html?page=1 > >but I'm running into an issue even getting gdb to start: > > > >[root_at_athena /var/crash]# which gdb > >/usr/bin/gdb > >[root_at_athena /var/crash]# gdb -k > >gdb: unrecognized option `-k' > >Use `gdb --help' for a complete list of options. > > > >The man page doesn't list a -k option either. /usr/src/UPDATING doesn't > >seem to mention any gdb changes. > > man kgdb [root_at_athena /var/crash]# kgdb -n 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". Unread portion of the kernel message buffer: KDB: enter: Line break on console panic: from debugger cpuid = 0 Uptime: 12h59m41s Physical memory: 1011 MB Dumping 201 MB: 186 170 154 138 122 106 90 74 58 42 26 10 #0 doadump () at pcpu.h:147 147 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:147 #1 0xc06c234c in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:411 #2 0xc06c2656 in panic (fmt=0xc09095f3 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:567 #3 0xc0477542 in db_panic (addr=-1066528405, have_addr=0, count=-1, modif=0xe2986a40 "") at /usr/src/sys/ddb/db_command.c:433 #4 0xc04774db in db_command (last_cmdp=0xc0a23264, cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:401 #5 0xc0477596 in db_command_loop () at /usr/src/sys/ddb/db_command.c:453 #6 0xc04791e1 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:222 #7 0xc06e1444 in kdb_trap (type=3, code=0, tf=0xe2986bd8) at /usr/src/sys/kern/subr_kdb.c:502 #8 0xc08c0cfd in trap (frame=0xe2986bd8) at /usr/src/sys/i386/i386/trap.c:621 #9 0xc08aaefb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #10 0xc06e116b in kdb_enter (msg=0x22 <Address 0x22 out of bounds>) at cpufunc.h:60 #11 0xc089f232 in siointr1 (com=0xc40b4000) at /usr/src/sys/dev/sio/sio.c:1522 #12 0xc089f029 in siointr (arg=0xc40b4000) at /usr/src/sys/dev/sio/sio.c:1391 #13 0xc08afb15 in intr_execute_handlers (isrc=0xc3ef4cc8, frame=0xe2986c94) at /usr/src/sys/i386/i386/intr_machdep.c:270 #14 0xc08b208b in lapic_handle_intr (vector=34, frame=0xe2986c94) at /usr/src/sys/i386/i386/local_apic.c:622 #15 0xc08ab2c4 in Xapic_isr1 () at apic_vector.s:90 #16 0xc0c000b5 in ?? () #17 0xe2986cfc in ?? () #18 0xc08b3d90 in cpu_idle () at /usr/src/sys/i386/i386/machdep.c:1150 Previous frame inner to this frame (corrupt stack?) If I'm understanding what I'm reading, this isn't all that helpful because it's just saying that I broke into the kernel debugger and then issued a manual panic (which is true, that's how I got the core). Is there a way to obtain information on what was happening before I broke into the debugger? -T -- Keeping UUCP running is starting to seem a lot like keeping a 130-year- old man who smokes 4 packs a day on life support because he's the last person on Earth who knows how to do the cha-cha, but he won't tell anyone. - A.S.R. quote (Ryan Tucker)Received on Sat Mar 10 2007 - 15:14:24 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:06 UTC