From owner-freebsd-hackers  Fri Nov 15 19:21:01 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id TAA06385
          for hackers-outgoing; Fri, 15 Nov 1996 19:21:01 -0800 (PST)
Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA06344
          for <freebsd-hackers@freefall.FreeBSD.org>; Fri, 15 Nov 1996 19:20:54 -0800 (PST)
Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02)
	id AA21350; Fri, 15 Nov 1996 22:20:21 -0500
Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Fri, 15 Nov 1996 22:20 EST
Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.7.5/8.7.3) with ESMTP id VAA29778; Fri, 15 Nov 1996 21:42:00 -0500 (EST)
Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id VAA24034; Fri, 15 Nov 1996 21:43:35 -0500 (EST)
Date: Fri, 15 Nov 1996 21:43:35 -0500 (EST)
From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
Message-Id: <199611160243.VAA24034@lakes.water.net>
To: ponds!root.com!dg, ponds!freefall.cdrom.com!freebsd-hackers,
        ponds!lakes.water.net!rivers, ponds!lambert.org!terry
Subject: Another possible explanation about my daily panics...
Content-Type: text
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


I've been staring at/reading through ffs_valloc.c and think I might
have a potential explanation about the daily panics...

In ffs_nodealloccg(), we look for an free inode.  When one is
found; the cg_inosused() bit is set "allocating" it.

However; if you look at the for() loop (just before the "gotit"
label) you'll see it marches "ipref" up as it looks for a free
inode.

But - and here's the crux of this - that calculated "ipref"
value does not take into account fs_ipg (inodes per group).
All the other calculations that set the allocated bit do
take into account fs->fs_ipg.  

For the sake of this scenario, let's assume that this 
calulated ipref is larger than fs->fs_ipg  
(i.e. ipref != ipref & fs->fs_ipg).  We set the wrong
bit in the bitstring; and more importantly, we don't set the
right bit...

Now, in ffs_vfree(), we redetermine the index to check the
allocated bit again - *but* when doing that we do account
for fs->fs_ipg...  so, the bit we check isn't the one we
set.

This would seem to be quite consistent with the panic's I'm 
seeing...

What do you think?

I'm going to put a new panic message in ffs_nodealloccg()
just after the "gotit:" label:

   if(ipref != (ipref % fs->fs_ipg)) {
      panic("ffs_nodealloccg: ipref != ipref & fs->fs_ipg\n");
   }

If I trip over that one - I think I may have this figured out...


	- Dave Rivers -