On Thu, Sep 30, 1999 at 06:36:26PM -0700, Chris Johnson wrote:
> A close examination of the QED docs shows that the 52xx
> series uses 2 low order bits of the virtual address to
> index the on-chip cache. QED thought this information was
> important enought that they mentioned it exactly once, in
> the table showing the Cache Error Register - register 27.
> In the rev 3.0 doc that we have lying around, this is in
> table 5.9.
All MIPS R4000 and better caches are virtual indexed and therefore
affected by this problem. The sole exception is the RM7000 which has
(cache-size / 4kb)-way, that is 8-way associative caches which completly
elleminate all pathological sympthoms of virtual indexed caches.
I don't have the R5230 manual at hand but the other MIPS manuals do
explain things in the cache chapter. They don't cover the effects
on software, though ...
> The bug is that if a region is mapped at addresses that are
> not 16 kbyte aligned, then the obvious bad things happen.
> This doesn't effect pthreads because they tend to load the
> same shared libraries in the same order, but other shared
> region programs have problems.
Can you give an example where this happens? While I know that we have
this problem since '94 I've never seen a real world case of this
problem.
> Entertainingly, Linux has no provision for virtually tagged
> caches. This seems to be true in out 2.0.34 base and, based
> on inspection, 2.2.12.
Virtually indexed, physically tagged you mean. 2.3 also doesn't get it
right either except on the R10000 - which fixes virtual coherency
problems in hardware.
> I included our test & 2.0.34 fix below. Ideally, there would
> be a concept of "platform specific" in Linux, that would be
> distinct from "processor specific". In the current layout,
> I suppose the mips specific code could probe the processor,
> and dynamically set up the virtual cache mode. Our solution
> uses 'CONFIG_QED_RM52XX'.
This obviously is the simplest solution but I'm not really sure how this
looks from the perspective from standards and real world application
software. Let me verify this.
With minor modifications your proposed patch will however at least have
one big advantage - it'll probably satisfy Linus' constraints. Linus
_hates_ virtual indexed caches of the sucky kind like this ones and is
not willing to accept patches which by his view clutter the kernel ...
Bill, comments?
Ralf
