From owner-freebsd-hackers  Sat Feb  8 13:51:42 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id NAA02161
          for hackers-outgoing; Sat, 8 Feb 1997 13:51:42 -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 NAA02152
          for <freebsd-hackers@freefall.FreeBSD.org>; Sat, 8 Feb 1997 13:51:15 -0800 (PST)
Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02)
	id AA18800; Sat, 8 Feb 1997 16:50:06 -0500
Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Sat,  8 Feb 1997 16: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 QAA01503 for <freebsd-hackers@freefall.cdrom.com>; Sat, 8 Feb 1997 16:43:31 -0500 (EST)
Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id QAA20465 for freebsd-hackers@freefall.cdrom.com; Sat, 8 Feb 1997 16:47:53 -0500 (EST)
Date: Sat, 8 Feb 1997 16:47:53 -0500 (EST)
From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
Message-Id: <199702082147.QAA20465@lakes.water.net>
To: ponds!freefall.cdrom.com!freebsd-hackers
Subject: News on daily panic, panic: ffs_valloc: dup alloc  (2.1.x and 2.2)
Content-Type: text
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


Ok - 

 I've hacked together a shell script to build boot floppies and
have been trying to determine the cause of the "dup alloc" problem.

 Some high-level items:

	1) It occurs on a new file system; with the second mkdir().

	2) The inode we're allocating is #7680 - it has not been
	    previously allocated.

	3) The number of inodes per group also happens to be 7680, the
	    newfs output is:
 
    /dev/rsd0a:    204800 sectors in 50 cylinders of 1 tracks, 4096 sectors
            100.0MB in 4 cyl groups (16 c/g, 32.00MG/g, 7680 i/g)
                                                        ^^^^^^^^

 Currently, I'm adding printf's to the kernel and rebooting; while
wading through the macros in /sys/ufs/ffs/fs.h to determine if one of 
them has a boundary problem.  [I'm using 2.1.6.1; but this also occurs 
with 2.2-GAMMA.]

 Some things I've discovered:

	1) in ffs_vget; the ip structure is allocated for inode #7680,
		after the bzero, of course ip->i_mode is 0.

	2) After the bread() to get the block from the disk, we assign
		the 'i_din' structure.  At that point; ip->i_mode (a member
		of the i_din structure) is non-zero (in fact, it is 0xc674).

	3) The subsequent test of a non-zero i_mode causes the "dup alloc"
		panic.

Now - I'm investigating the macros to determine if we've either
read the wrong physical block; or if we're not accessing the data in
the block correctly.

 It does seem to be, though; that allocating a inode which happens
to be the same (possibly a multiple) of the inodes/group is the cause
of my panics.

 When I've gathered all the information on how the inoXXX macros evaluate,
I'll post again.  If anyone has any ideas; feel free to chime in.

	- Dave Rivers -