Hello Paul.  Well, I've poked at this problem further, and have more 
ideas, but don't know how to test them.  The problem I'm seeing definitely
has to do with the creation of inodes under FFS, usually directory inodes,
but that's only because directories seem to employ the inode hashing
algorithm more intensely.  However, I don't think my problem is in the FFS
code.  I now have traces which show that it seems to happen in and out of
filesystems in CCD's, and, while the panics occur consistently in FFS, they
don't always occur at the same level.
	My suspicion is that I'm running into some sort of memory cache coherency
problem with the Sparc chip on the Sparc 5, but I don't know how to enable
or disable various portions of the cache.  Are there knobs I can turn which
disable the cache, if there is any, or otherwise stress test the cache
coherency code?  Have there been cache coherency fixes in -current which I
should pull back to 1.4.1-2?  I base this theory on the fact that I always
get caught in access_fault4m() in the stack trace.  It seems like we're
jumping to a page, or something like that, and its protection bits are
mis-set, or the page isn't the one we wanted, or something like that.
	Does this ring any bells for anyone?
-Brian