markd@werple.apana.org.au (Mark Delany) writes:
>I've just upgraded from 0.9B of ancient vintage to 1.0A with a sup
>date of 8/10/94 and now I get repeated panics out of ffs_allo.c and
>I'd like to know if anyone else has seen these.

>The specific message comes out of ffs_alloc.c at line 1358:

>start = 0, len = 2, fs = /tmp
>panic: ffs_alloccg: map corrupted

>Normally /tmp is an mfs but I get the same error when it's part of the
>root file system.

An additional snippet. If I mount /tmp on a floppy file system I still
get the same error. FWIW, it's been suggested that a flakey disk may
be the cause of the problem, and indeed appeared to be the case for 1
of the 3 systems that exhibited the problem. I'm not quite sure how
that is relevant to my symptoms given the problem occurs across mfs,
scsi ufs and floppy ufs, but it may be relevant to others.

>From trial and error, and talking to others I can make some
conclusions about what is *not* relevant. I have been working hard to
try and find patterns but nothing obvious has appeared thus far.  Here
is what I know for sure:

	The same panic has occured on at least 3 totally separate
	systems.

	The same problem has been in Netbsd for at least a month.
	(I got it in Sept with an early 1.0X)

	The same problem is not manifest in Netbsd code prior to 1.0
	(eg 0.9B works fine on the same system).

	The 3 disparate systems have different disks, controllers,
	cpus and memory configs.

	The panic occurs in normal operation as well as single user.

	The start= and len= values seem to almost always be the same,
	that is start=0 and len=2.

	The panic is almost always pointing at /tmp regardless of the
	file system type of the mount order.

	In one of the three cases, the disk turned out to be flakey so
	*maybe* all flakey disks are prone to exhibiting this problem,
	but then why would mfs fail?


M..