braman@dataio.UUCP (Rick Braman) (11/11/86)
We have been crashing fairly regularly the last month or so with the following
panic. Can anybody out there point me to a bug fix or provide some insight
as to what is causing this panic? I'm desperate and my users are getting
fidgety.
dev = 0xd, ino = 12327, fs = /usr/spool
panic: ifree: freeing free inode
syncing disks... 20 19 18 17 17 16 15 14 14 13 13 12 11 11 10 10 9 8 8 8 done
.
.
.
etc...
Thanks very much!
Rick Braman
FutureNet - Data I/O Corp.
Redmond WA
UUCP: uw-beaver!entropy!dataio!braman
--
Rick Braman
FutureNet - a division of Data I/O Corp.
Redmond, WA
UUCP: uw-beaver!entropy!dataio!bramanamos@instable.UUCP (Amos Shapir) (11/12/86)
When posting such a question, PLEASE state what machine you are on, what o.s. and release level, and preferably the mem, disk, tty etc. configuration. I have seen such a problem (panic: freeing free inode) on VAX 780 running 4.2BSD with certain disk controllers; it had to do with a bug in 'closef' that only happened when the close was interrupted. The solution was a fix from Mt. Xinu, and I think it was also fixed in 4.3. However, since you didn't give any details on your system, I cant be sure this is correct. -- Amos Shapir National Semiconductor (Israel) 6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel (01-972) 52-522261 amos%nsta@nsc 34.48'E 32.10'N
jsdy@hadron.UUCP (Joseph S. D. Yao) (12/12/86)
In article <1192@dataio.UUCP> braman@dataio.UUCP (Rick Braman) writes: >dev = 0xd, ino = 12327, fs = /usr/spool >panic: ifree: freeing free inode I saw this fairly regularly on a system with which I work, and was mystified. (Ultrix 1.1 on Vaxen.) It turned out that the operators, to do backup, just turned the modems off and did an fsck and dump. They rather blindly answered "yes" to each and every question. When they were instructed to bring the systems all the way down before doing any of this (and then forced to by some cleverer software), these disappeared. The problem was, of course, that BSD has at least a dozen back- ground processes working hard to corrupt the disk at all times. Usually, of course, they are helpful: but to fsck, they are just corruption. -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} jsdy@hadron.COM (not yet domainised)