Date: Fri, 30 Jul 1999 16:29:09 +0930 From: Greg Lehey <grog@lemis.com> To: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> Cc: current@FreeBSD.ORG Subject: Re: Panic plus advice needed Message-ID: <19990730162908.B56925@freebie.lemis.com> In-Reply-To: <19990730084532.B1396@daemon.ninth-circle.org>; from Jeroen Ruigrok/Asmodai on Fri, Jul 30, 1999 at 08:45:32AM %2B0200 References: <19990730084532.B1396@daemon.ninth-circle.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, 30 July 1999 at 8:45:32 +0200, Jeroen Ruigrok/Asmodai wrote:
> Hi,
>
> I started a make world on my box last night and then proceeded to go to bed.
>
> When I looked at my console this morning it had sprung into DDB because
> of a panic: ffs_alloccg: map corrupted.
>
> This panic occured on a box running pretty stable (at least panic less for
> the last past 4-8 weeks).
>
> I got show registers and trace information from DDB and also a crashdump.
> Now I am wanting to use GDB to get more relevant information from the
> crashdump. I have the GDB manual here, but could use some advice from
> people who've done this under FreeBSD before and could inform me of any
> things that are somewhat obligatory to look at under FreeBSD.
>
> If you want I can type in the DDB stuff later this day, but work awaits
> my presence first.
The first question is: do you have a kernel with debug symbols? If
not, gdb isn't going to help you much. bde can do it with ddb (though
it's a bit late if you have the dump), but mere mortals are in trouble
without symbols.
The first thing you should do with any dump is a backtrace (bt). The
appearance depends on how you got there. Since you appear to have
gone via ddb, your dump should look something like this:
IdlePTD 3264512
initial pcb at 29dbc0
panicstr: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x2fc
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc011d71f
stack pointer = 0x10:0xc74d3cc8
frame pointer = 0x10:0xc74d3ccc
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 = 69 (pccardd)
interrupt mask = net tty bio cam
panic: from debugger
panic: from debugger
dumping to dev (3,1), offset 327808
dump 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 boot (howto=260) at ../../kern/kern_shutdown.c:291
291 dumppcb.pcb_cr3 = rcr3();
This is where you are. You're in the dump routine.
(kgdb) bt
#0 boot (howto=260) at ../../kern/kern_shutdown.c:291
#1 0xc014174d in panic (fmt=0xc024e3d4 "from debugger")
at ../../kern/kern_shutdown.c:505
This is the panic call, from ddb.
#2 0xc011e23d in db_panic (addr=-1072572641, have_addr=0, count=1,
modif=0xc74d3b44 "") at ../../ddb/db_command.c:434
#3 0xc011e1dd in db_command (last_cmdp=0xc027bda8, cmd_table=0xc027bc08,
aux_cmd_tablep=0xc029a834) at ../../ddb/db_command.c:334
#4 0xc011e2a2 in db_command_loop () at ../../ddb/db_command.c:456
#5 0xc0120327 in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71
These frames relate to the debugger; they're not there if you panic
and dump without entering ddb.
#6 0xc021556c in kdb_trap (type=12, code=0, regs=0xc74d3c88)
at ../../i386/i386/db_interface.c:157
#7 0xc02249cc in trap_fatal (frame=0xc74d3c88, eva=764)
at ../../i386/i386/trap.c:902
#8 0xc02246a5 in trap_pfault (frame=0xc74d3c88, usermode=0, eva=764)
at ../../i386/i386/trap.c:800
#9 0xc02242e7 in trap (frame={tf_fs = 16, tf_es = -1071710192,
tf_ds = -65520, tf_edi = -1063317504, tf_esi = 0, tf_ebp = -951239476,
tf_isp = -951239500, tf_ebx = -1063301376, tf_edx = -1063301372,
tf_ecx = 744, tf_eax = 744, tf_trapno = 12, tf_err = 0,
tf_eip = -1072572641, tf_cs = 8, tf_eflags = 66182,
tf_esp = -1063301376, tf_ss = -951239332}) at ../../i386/i386/trap.c:426
The frames above are pretty much the same for all traps.
#10 0xc011d71f in BUS_READ_IVAR (dev=0x2e8, child=0xc09f4f04, index=8,
result=0xc74d3d3c) at bus_if.c:52
And this is where things really went crazy. From here on, your dump
will look very different. This is where I'd expect to see the
ffs_alloccg stack frame. The best thing to do there is to look at the
local variables, which might give you more information.
#11 0xc0246780 in sioprobe (dev=0xc09f4f04) at ../../isa/sio.c:599
#12 0xc024660d in sioinit (devi=0xc09f4f00) at ../../isa/sio.c:524
#13 0xc01cb8da in allocate_driver (slt=0xc0904600, desc=0xc09f1000)
at ../../pccard/pccard.c:660
#14 0xc01cc156 in crdioctl (dev=0xc097a7e0, cmd=2158514182,
data=0xc09f1000 "sio", fflag=3, p=0xc6d844c0) at ../../pccard/pccard.c:1061
#15 0xc0174428 in spec_ioctl (ap=0xc74d3e08)
at ../../miscfs/specfs/spec_vnops.c:437
#16 0xc0173da9 in spec_vnoperate (ap=0xc74d3e08)
at ../../miscfs/specfs/spec_vnops.c:128
#17 0xc01e45f5 in ufs_vnoperatespec (ap=0xc74d3e08)
at ../../ufs/ufs/ufs_vnops.c:2334
#18 0xc016e681 in vn_ioctl (fp=0xc099ca40, com=2158514182,
data=0xc09f1000 "sio", p=0xc6d844c0) at vnode_if.h:395
#19 0xc014ddc3 in ioctl (p=0xc6d844c0, uap=0xc74d3f80)
at ../../kern/sys_generic.c:564
#20 0xc0224c36 in syscall (frame={tf_fs = -1078001617, tf_es = -1078001617,
tf_ds = -1078001617, tf_edi = 0, tf_esi = 256, tf_ebp = -1077945096,
tf_isp = -951238700, tf_ebx = 134635776, tf_edx = 8, tf_ecx = 3,
tf_eax = 54, tf_trapno = 7, tf_err = 2, tf_eip = 134529928, tf_cs = 31,
tf_eflags = 514, tf_esp = -1077945340, tf_ss = 47})
at ../../i386/i386/trap.c:1056
This is where the currently executing process entered the kernel (with
an ioctl system call in this case).
#21 0xc0215e66 in Xint0x80_syscall ()
#22 0x8048806 in ?? ()
#23 0x804861a in ?? ()
#24 0x80483b7 in ?? ()
#25 0x80480e9 in ?? ()
And this is the user context. With some difficulty you can load the
symbol table for the binary and follow it back, but that doesn't help
often.
Greg
--
See complete headers for address, home page and phone numbers
finger grog@lemis.com for PGP public key
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990730162908.B56925>