Hello, Tsutsui-san!
	First, thanks for all your work on getting Chris' changes folded
	in (and apologies for not doing so myself, but my hacking time
	has shrunk to ~ 0 lately).

In message <031005002609.M0217475@mirage.ceres.dti.ne.jp>, you write: 

-> At least, I've confirmed pmap.c actually requires some additional
-> cache flush for R5000 with L2cache. Currently pmap_zero_page() and
-> pmap_copy_page() have some additional cache flush ops for no L2 cache
-> machines, but it seems r5ksc also requires these ops otherwise
-> kernel falls into ddb around scsibus thread.
-> 
-> Changes currently I'm using is here (for reference, will not be committed): 
-> http://www.ceres.dti.ne.jp/~tsutsui/netbsd/mips_cache_r5k-20031004.diff

As I mentioned to Chris, parts of this are incorrect -- the R5k cache code
can't assume it can do the indexed operation the way the code does it since
the R5k L2 is physically indexed.  I'm working on getting my R5k changes
folded into -current again and getting my sgimips machines working again
and will try and take care of this in the next week or so (I need to do
some small cleanup and then test on both R5k and R4k/R4600 to make sure
I haven't loused anything up).  I'll commit the minimal changes needed
to make things work and then post the rest for comment/review here.

As for the R5k needing the extra flushes, this is indeed the case, since
the R5k does not do alias detection in hardware (which R4k with L2 do),
we have to treat it as if there were no L2 for purposes of eliminating
cache aliases.  What I ended up doing (per Nisimura-san's suggestion,
is to simply supply a new pmap_copy_page() and pmap_zero_page() for
the R5k), which do things slightly differently by writing through a
VA set aside for copy/zero and using write-through cache mode on that
mapping.

Thanks!
--rafal

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