> This part:
>
>> VOP_FSYNC() at VOP_FSYNC+0x2f
>> ffs_sync_vnode() at ffs_sync_vnode+0x77
>> vfs_mount_foreach_vnode() at vfs_mount_foreach_vnode+0x38
>> ffs_sync() at ffs_sync+0x83
>> sys_sync() at sys_sync+0xa1
>> vfs_syncwait() at vfs_syncwait+0x50
>> vfs_shutdown() at vfs_shutdown+0x32
>> boot() at boot+0x17f
>> panic() at panic+0xf6
>
> is from the "boot crash", not the original crash. Looking at the
> original crash:
>
>> --- trap (number 8) ---
>> ffs_update() at ffs_update+0x19f
>
> That points to the math in the ino_to_fsba() macro in this like of
> ffs_update()
> error = bread(ip->i_devvp, fsbtodb(fs, ino_to_fsba(fs,
> ip->i_number)),
> (int)fs->fs_bsize, &bp);
>
> It's trying to calculate the block address of the inode so that it can
> update the timestamps in it and divided by zero. That means the
> in-memory copy of the superblock had zeros in on other another member.
> If the on-disk superblock had zeros there, I would expected fsck to
> catch it, or for it to crash earlier, but maybe a forced fsck is in
> order. Otherwise, something's writing through a bogus pointer in the
> kernel...
Thank you so much, Philip.
I ran each filesystem through a 'fsck -n' just to see what it thought,
and it identified three filesystems that seemed to have issues. So,
I dropped it down to single user and ran fsck on each one. It didn't
say it fixed anything - kinda surprised me - but I ran fsck on every
filesystem, and then did a 'fsck -p' for good measure. Everything
came up clean?
I booted it back and and I guess we'll see how things go...
Thank you for your help!
Benny
--
"No matter how tempted I am with the prospect of unlimited power, I
will not consume any energy field bigger than my head."
-- #22 on Peter Anspach's Evil
Overlord list
