In message <20041214105923.2BD112356B@thoreau.thistledown.com.au>, you write: 

-> Christopher SEKIYA wrote:
-> 
-> > On Tue, Dec 14, 2004 at 10:33:22AM +0100, Florian Stoehr wrote:
-> > 
-> > > ...as encountered by someone elso on r5k and me on my Indigo2 ?
-> > 
-> > Not completely.  The commit to which you refer is the uncontroversial part
-> > of the fix.
-> > 
-> > Attached is the controversial part.  The pmap hack is not correct, but it
-> > fixed the panic on my r5ksc (revision 2.0).
-> 
-> So on the R5000, the L2 cache doesn't help with alias detection?  Is
-> this problem specific to the way the caches are wired up on this model
-> SGI, or a problem with the R5000 in general?

For "MIPS" CPUs, I think only the R4k/R4400 have alias detection hardware
and VCE{D,I} exceptions.  Certainly not the R5k (and Rm5200 too), and I
think not the R4600 either.  I certainly don't think it has anything to
do with the SGI platform per se (other than the fact that it uses those
CPUs ;-)).

-> If I read your suggested patch correctly, it will cause extra unneeded
-> cache flushes on other CPUs/machines with multi-way data caches that
-> have also have an L2 cache.  Do we know of any that exist, ignoring say
-> the Broadcom/Sibyte CPUs where the L2 is effectively invisible to us?

ENOCLUE.  My suggestion (and what I did when I first perpetrated this hack)
would be a new cache flag (in with the rest of the global cache-related foo
set in arch/mips/mips/cache.c) long the lines of "L2 detects aliases" or 
"L2 does not detect aliases" or as you suggested elsewhere, a new flag on
the CPU.  Certainly doing it for all machines with multi-way data caches is
going to Suck More(tm) in some cases (though as you say above, I am not sure
if those cases exist)

--rafal, who hopes soon he'll have more NetBSD time than just mailing-list
         skimming time.

----
Rafal Boni                                                     rafal@pobox.com
  We are all worms.  But I do believe I am a glowworm.  -- Winston Churchill