Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 23 Oct 1996 19:24:55 -0400 (EDT)
From:      Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
To:        ponds!freefall.cdrom.com!freebsd-hackers, ponds!lakes.water.net!rivers
Subject:   Daily panic's with 2.1.5R.
Message-ID:  <199610232324.TAA09502@lakes.water.net>

next in thread | raw e-mail | index | archive | help

I've been getting daily panic's with 2.1.5R on my news server.

The machine is a 386dx w/8meg of memory, a 387 and a 1.2G IDE drive.

After (finally) stumbling across dumpdev/savecore (I was wondering
why I didn't get a core image saved in my swap space...)  I've
now determined what the panic is.

One question before I get to that.  I recall that the kernel
boot messages used to say something about the previous panic when
it discovered the savecore image.  Did this go away, or am I
simply mis-remembering?

Anyway - on to the panic.

A quick gdb -k kernel.0 vmcore.0 reveals:

ponds# gdb -k kernel.0 vmcore.0
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.13 (i386-unknown-freebsd), 
Copyright 1994 Free Software Foundation, Inc...(no debugging symbols found)...
IdlePTD 1e1000
current pcb at 1d3f0c
panic: ifree: freeing free inode
#0  0xf0193abb in boot ()
(kgdb) where
#0  0xf0193abb in boot ()
#1  0xf0112b73 in panic ()
#2  0xf0176db7 in ffs_vfree ()
#3  0xf017c042 in ufs_inactive ()
#4  0xf0128ca5 in vrele ()
#5  0xf0128c07 in vput ()
#6  0xf017f574 in ufs_remove ()
#7  0xf012acae in unlink ()
#8  0xf019be36 in syscall ()
#9  0xf01912fb in Xsyscall ()
#10 0x2d9a in ?? ()
#11 0x2b2a in ?? ()
#12 0x2507 in ?? ()
#13 0x19b9 in ?? ()
#14 0x10d3 in ?? ()


The traceback is pretty straightforward - an unlink() has
caused an inode to be duplicately free'd.

Has anyone seen this before?

I've seen similar problems when installing - from version 2.1.0
on.  I've been able to work around them in the past by adjusting
the inode values on newfs parms on the file system.  I'm guessing
that adjustment simply covers up the problem.

 I see in ffs_vfree() that I should have seen a message detailing
some information - but that's not in the /var/log/messages (not likely
it could be, eh?) and the screen has long since scrolled on...

 I have the kernel & vmcore files, I can put them on freefall
if anyone wants to take a gander...

	- Dave R. -



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610232324.TAA09502>