Date: Sat, 8 Feb 1997 16:47:53 -0500 (EST) From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: News on daily panic, panic: ffs_valloc: dup alloc (2.1.x and 2.2) Message-ID: <199702082147.QAA20465@lakes.water.net>
next in thread | raw e-mail | index | archive | help
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 -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702082147.QAA20465>