>
> > It is really surprising to know this. It sounds like a CPU bug to me.
Can
> > some MIPS "gods" clarify if such a behaviour is a bug or allowed?
> >
> > BTW, the CPU in EV96100 is QED RM7000, I believe.
>
> If you want to be strictly correct you have to execute the code that
> disables caching of KSEG0 in uncached space like KSEG1, then flush the
> caches before you can resume execution in KSEG0. Otherwise you might
> end up with dirty d-caches which when flushed will overwrite more
> uptodate data in memory. The window is very small but yet exists if
> things are just right.
That's one possible failure mode. The other is that there
are dirty lines (those that were brought into the cache and
modified by stores, but never written back to memory) that
are rendered invisible by forcing KSEG0 to go uncached.
This will cause failure of any code that is expecting to see
the results of those stores if said code executes before
some other event causes the write-back - and if the
machine is running with cacheing completely disabled,
as it would be in the case under discussion, such an
event may never occur!
Regards,
Kevin K.
