From owner-freebsd-questions Thu Dec 3 23:45:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA03381 for freebsd-questions-outgoing; Thu, 3 Dec 1998 23:45:49 -0800 (PST) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA03376; Thu, 3 Dec 1998 23:45:43 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id SAA10355; Fri, 4 Dec 1998 18:15:03 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.1/8.9.0) id SAA11683; Fri, 4 Dec 1998 18:14:26 +1030 (CST) Message-ID: <19981204181412.A495@freebie.lemis.com> Date: Fri, 4 Dec 1998 18:14:12 +1030 From: Greg Lehey To: Eugeny Kuzakov , FreeBSD Questions Subject: Re: My 2.2.8 panics! References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Eugeny Kuzakov on Fri, Dec 04, 1998 at 12:46:46PM +0600 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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-questions" in the body of the message