From owner-freebsd-hackers Wed Jan 22 20:50:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA27016 for hackers-outgoing; Wed, 22 Jan 1997 20:50:37 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id UAA27006 for ; Wed, 22 Jan 1997 20:50:33 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA15498; Wed, 22 Jan 1997 23:50:01 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Wed, 22 Jan 1997 23:50 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id XAA00205 for ; Wed, 22 Jan 1997 23:27:47 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id XAA07877 for freebsd-hackers@freefall.cdrom.com; Wed, 22 Jan 1997 23:04:09 -0500 (EST) Date: Wed, 22 Jan 1997 23:04:09 -0500 (EST) From: Thomas David Rivers Message-Id: <199701230404.XAA07877@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: 2.1.6.1 freeing free inode panic... (nightly panics) Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I've received a couple of interesting replies this go-'round on the panic. If you're interested in previous discussions; look through the mail archive for "nightly panics." Several people have suggested that fsck could be the culprit. In that, fsck is not catching some terrible file system inconsistency. such that when a file system gets into this state, it's stuck there. [A newfs and restore, of course, fixes.] I would submit that the bug is that the file system gets into that state to begin with.... granted; fsck (possibly) could do something with it - but there should be no reason (barring hardware faults, stray gamma rays, etc...) for the file system to be corrupted this way - much less for it to panic the machine. So, I'm willing to believe this is a situation unexamined by fsck because it's not supposed to happen. I'm also willing to believe that "it's not supposed to happen" is a contributing cause in the panic (sorta an obvious statement; that's what panic() means :-) ) Jaye Mathisen writes: > I have several servers that once I get this error one time, I can count on > getting it again, unless I newfs, and restore the FS. I would say that my experience echoes his. It seems that building a new file system eliminates the problem - for a short time; and once it's returned, it's there for good. Is it possible there's a boundary condition in "isclr" - such that bits around, say a word boundary; are not checked [this would presumably be a compiler bug, as isclr() is a pretty straightforward macro - see /usr/include/sys/param.h.] I'm not sure it's worth examining at 2.1.6.1; as I believe 2.2 is quite different in this area. But, if anyone has any suggestions, please don't hesitate to come forward with possibilities to examine [I've read through ffs_alloc.c; seems reasonable to me.] A quick/reliable reproduction of the problem would go a long way toward solving it.... - Dave Rivers -