On Tue, 14 Dec 2004, Izumi Tsutsui wrote:

> In article <20041214114534.197EA2356B@thoreau.thistledown.com.au>
> simonb@wasabisystems.com wrote:
>
>> At this stage, I'd suggest a new flag to add to cpu_arch in
>> <mips/cpu.h>.  Maybe something like CPU_MIPS_NO_L2_ALIAS_DETECT or
>> something similar?  Then replace the "mips_pdcache_ways > 1" with
>> "cpu_arch & CPU_MIPS_NO_L2_ALIAS_DETECT", or possibly something like the
>> other MIPS_HAS_ checks since this would only apply to MIPS4 CPUs.
>
> Well, I'd like to get your comment for my recent post ;-)
> http://mail-index.netbsd.org/port-mips/2004/09/30/0001.html
>
>> For now, I think we would just set this for this model SGI, and if/when
>> we get another system that has an L2 with an R5000 and we get problems
>> reported we could then set this for all R5000 in the cputab array in
>> mips/mips_machdep.c.  If we get such a system and it works ok, we'd
>> obviously leave setting the flag for just this model SGI.
>
> Nishimura-san said "only L2-equipped R4000 is capable of emitting VCE."
> http://mail-index.netbsd.org/port-mips/2003/12/13/0005.html
> On R10000, VCE is handled by hardware.
> http://mail-index.netbsd.org/port-mips/2002/12/18/0001.html
>
> Anyway, depending on VCE is not so good with current VCE
> implementation, IMHO.
> At least, cache flush code in mips/vm_machdep.c:cpu_lwp_fork()
> is ugly as noted in the comment.
> ---
> Izumi Tsutsui
> tsutsui@ceres.dti.ne.jp
>

Hm, remember, I get also cache panics (see my post from some days ago) and 
this is _NOT_ an r5k -> Indigo2 (R4400 ??).

But maybe this is a different problem - I'll try the new -current with the 
additional fix, then let's see.

-Florian