Date: Fri, 4 Dec 1998 18:14:12 +1030 From: Greg Lehey <grog@lemis.com> To: Eugeny Kuzakov <kev@lab321.ru>, FreeBSD Questions <questions@FreeBSD.ORG> Subject: Re: My 2.2.8 panics! Message-ID: <19981204181412.A495@freebie.lemis.com> In-Reply-To: <Pine.BSF.4.02.9812041159430.4091-100000@lab321.ru>; from Eugeny Kuzakov on Fri, Dec 04, 1998 at 12:46:46PM %2B0600 References: <Pine.BSF.4.02.9812041159430.4091-100000@lab321.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, 4 December 1998 at 12:46:46 +0600, Eugeny Kuzakov wrote:
>
> Hi !
>
> I have freebsd sources cvsuped at 30-Nov-1998.
>
> When I tryed to boot kernel, compiled with -g, I received the
> message: "bounce memory out of range" and then system rebooted.
> Why ?
How can we tell if you don't give the minimum information about the
problem? At the very least we need to know your hardware setup
(though we can assume an ISA SCSI controller and more than 16 MB of
RAM). Anyway, this isn't a -hackers question, it's a -questions
question, so I'm following up to -questions.
> I compiled kernel w/o debugging information with the same kernel config.
> Last night this kernel traped. I saved them core dump.
>
> The debug information is below:
> gdb -k
> GDB is free software and you are welcome to 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.
> GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation,
> Inc.
> (kgdb) symbol-file kernel
> Reading symbols from kernel...done.
> (kgdb) exec-file /var/crash/kernel.0
> (kgdb) core-file /var/crash/vmcore.0
> IdlePTD 2c5000
> current pcb at 24f8b8
> panic: blkfree: freeing free frag
> #0 boot (howto=256) at ../../kern/kern_shutdown.c:266
> 266 dumppcb.pcb_cr3 = rcr3();
> (kgdb) where
> #0 boot (howto=256) at ../../kern/kern_shutdown.c:266
> #1 0xf01199f3 in panic (fmt=0xf01cc821 "blkfree: freeing free frag")
> at ../../kern/kern_shutdown.c:400
> #2 0xf01ccc4c in ffs_blkfree (ip=0xf49fc900, bno=14782, size=1024)
> at ../../ufs/ffs/ffs_alloc.c:1255
> #3 0xf01ce9a3 in ffs_truncate (ap=0xefbffe74) at
> ../../ufs/ffs/ffs_inode.c:343
> #4 0xf01d23f5 in ufs_inactive (ap=0xefbffea0) at vnode_if.h:1003
> #5 0xf01392b7 in vrele (vp=0xf466de80) at vnode_if.h:699
> #6 0xf01391ab in vput (vp=0xf466de80) at ../../kern/vfs_subr.c:858
> #7 0xf01d5bd0 in ufs_remove (ap=0xefbffef4) at
> ../../ufs/ufs/ufs_vnops.c:697
> #8 0xf013b539 in unlink (p=0xf4efaa00, uap=0xefbfff94, retval=0xefbfff84)
> at vnode_if.h:459
> #9 0xf01f6e37 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 9707,
> tf_esi = -272639788, tf_ebp = -272639884, tf_isp = -272629788,
> tf_ebx = 1651904, tf_edx = 0, tf_ecx = 1642496, tf_eax = 10,
> tf_trapno = 151552, tf_err = 7, tf_eip = 537416161, tf_cs = 31,
> tf_eflags = 582, tf_esp = -272639996, tf_ss = 39})
> at ../../i386/i386/trap.c:920
> #10 0x200851e1 in ?? ()
> #11 0x2b17 in ?? ()
> #12 0x3b7c in ?? ()
> #13 0x1095 in ?? ()
This shows a process unlinking the final link to a file, and
discovering that the data being freed was already free. This can
happen, for example, if you crash a system and bring it up without
cleaning the file system. If this is repeatable, it would be helpful
to know which file you were removing (with some difficulty you can
find it in the dump).
> (kgdb) up 10
> #10 0x200851e1 in ?? ()
> (kgdb) frame frame->tf_ebp frame->tf_eip
> No symbol "frame" in current context.
> (kgdb) list
> 261 }
> 262 } else {
> 263 if (howto & RB_DUMP) {
> 264 if (!cold) {
> 265 savectx(&dumppcb);
> 266 dumppcb.pcb_cr3 = rcr3();
> 267 dumpsys();
> 268 }
> 269
> 270 if (PANIC_REBOOT_WAIT_TIME != 0) {
> (kgdb) print tp
> No symbol "tp" in current context.
> (kgdb) up
> #11 0x2b17 in ?? ()
> (kgdb) q
I don't know what you were looking for here, but I can't see anything
of any great advantage. What you need to know is which file you were
deleting; possibly this will give you a better lead.
> NOTE: I tryed to inspect core dump of kernel, compiled w/o debug, but use
> symbol table from this kernel compiled with debug.
> I know that it not so correctly.
Assuming that it's the same source, it shouldn't make any difference.
It looks to me as if your trace is close enough.
> I will try :
> 1. Compile kernel with -g
> 2. strip -d it kernel
> 3. boot this kernel
> 4. When it will trap, I will inspect it with kgdb again.
>
> Thanks for advices. This is production server and stable him work very
> critical.
The first thing I would do would be to do an fsck on the file system
on which the file was located. You can find that information in the
vnode if you don't know already. After that, you may never see the
problem again.
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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981204181412.A495>