4.2BSD MFIND panic (AGAIN/STILL?)

[terryl at tekcrl.CRL.TEK.COM]

In article <1368 at spp2.UUCP> urban at spp2 (Mike Urban) writes:
>About six weeks ago, I requested help from this newsgroup:
>our 4.2bsd system, to which we had just added two disk drives
>and several new file systems, was crashing daily with an
>MFIND panic.  Two kind souls directed me to change NMOUNT
>and MSWAPX in param.h, and the size of the c_mdev field
>in cmap.h (swiping the bit from the c_blkno field).  This
>I have done, and matters did improve somewhat.  The system
>in question now crashes with the MFIND panic on a weekly
>basis rather than daily (actually, it is more like once in
>ten days, but let that pass).  Is there another problem
>here that must be fixed, or should I begin to suspect
>hardware?  Thanks in proverbial advance.


     Sorry, I didn't see your original posting (our news has been somewhat
flakey due to disk space problems latley).

     There is a long, outstanding bug in the VAX C compiler when combining
signed/unsigned casts (at least in the 4.2 C compiler; I have no idea if
it has been fixed in 4.3). Anyways, there are two changes you have to make:

     In the file /sys/sys/vm_mem.c (your path name may vary), find a call to
mfind() in the routine memall(); it's a multi-line call whose last line
looks like thus:

	(daddr_t)(u_long)c->c_blkno))

     Take out the (daddr_t) cast. This is the bug I alluded to earlier. The
VAX C compiler folds both casts together somehow, but loses the fact that
c_blkno should be treated as an unsigned quantity, and sign extends it to
the call to mfind.

     In the file /sys/vax/vm_machdep.c (again, your path name may vary;
void where prohibited by law, etc.) in the routine chgprot(), there is
a call to munhash() (again, a multi-line call) that is identical to the
call to mfind in memall(). Again, look for the line:

	(daddr_t)(u_long)c->c_blkno))

     And, again, take out the (daddr_t) cast, for the reasons stated above.

     And a warning: in /sys/vax/locore.s, there are implicit assumptions
about the struct cmap (which is defined in cmap.h); specifically, the bit
offsets and lengths of various members of this structure are HARD CODED in
assembly language, so you shouldn't just go changing the structure definition
without makeing sure the bit offsets and lengths are updated in locore.s



				Terry Laskodi
				     of
				Tektronix