After another bug report from a FreeBSD user about processes core dumping
during kernel builds, I decided to spend all of Saturday with the new user
troubleshooting the problem (it helped that the user was a student at a local
university). The time was well spent. In this case, the person was using an
UltraStore 34F (SCSI, VESA LB) controller with a Seagate Barracuda drive on a
486DX2/66, 16MB of memory.
   The problem turned out to be the slot the controller was plugged into:
apparantly, bus master controllers _must_ be plugged into the 'master' VLB
slot in order for the cache update to work! Now this might sound reasonable,
and the casual observer might say "well, it seems stupid that you wouldn't have
realized this in the first place!"...ahh, but after you RTFM, you quickly find
that not only do the manuals not tell you this, but the motherboard manual
doesn't even indicate _which_ slot is the master and which is the slave! All
it says is "VLB: one master, and one slave slot; or two slave slots". I spent
at least half an hour carefully looking through TFM for a clue on how to
figure out which is which, or even how to configure the master/slave and
slave/slave modes. Not a single clue.
   Anyway, I've confirmed this behavior on two totally different motherboards.
If you plug the 34F into the 'inside' slot, you have a cache coherency
problem, if you plug it into the 'outside' slot, it works great.

-DG

------------------------------------------------------------------------------