From owner-freebsd-hackers Mon Jan 20 08:21:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA09541 for hackers-outgoing; Mon, 20 Jan 1997 08:21:13 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id IAA09534 for ; Mon, 20 Jan 1997 08:21:09 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA03591; Mon, 20 Jan 1997 11:20:05 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 20 Jan 1997 11:20 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id JAA16411; Mon, 20 Jan 1997 09:06:37 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id JAA01866; Mon, 20 Jan 1997 09:10:17 -0500 (EST) Date: Mon, 20 Jan 1997 09:10:17 -0500 (EST) From: Thomas David Rivers Message-Id: <199701201410.JAA01866@lakes.water.net> To: nick@eunet.ie, ponds!ponds!rivers Subject: Re: kern/2516: Filesystem trouble in 2.2-BETA_A Cc: ponds!freefall.cdrom.com!freebsd-hackers Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Well - I'd have to say that this is exactly the type of > > panic I have experienced with 2.1.0, 2.1.5 and 2.1.5-STABLE. > > Really? I've never seen in before in either 2.1.0 or 2.1.5 Oh yes - I've been trying to determine what the problem is for over a year now... > > > Interestingly enough, my recently installed 2.1.6.1 hasn't (yet) > > experienced it. > > > > I've been trying to determine a consistent reproduction; if you > > can accomplish this - I'm sure it would go a long way toward > > fixing this problem. > > As I say, it just happened once. I don't know whether this is going to > happen again in a hurry -- 2.2-BETA hasn't been on the machine for terribly > long. To add more to this; I _still_ haven't experienced the panic's on my 2.1.6.1 machine (which was panic'ing daily under 2.1.5-STABLE.) I think the problem has to do with a bad FFS inode table - perhaps if the disk goes bad, or there's some other problem, this corrupt table can work it's way in there and not be corrected by fsck(1). It's just another thought I had. - Dave R. -