linux-mips
[Top] [All Lists]

Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96

To: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Tue, 16 Jul 2002 11:00:04 +0200 (MET DST)
Cc: linux-mips@oss.sgi.com
In-reply-to: <3D3292E0.40FE937B@niisi.msk.ru>
Organization: Technical University of Gdansk
Sender: owner-linux-mips@oss.sgi.com
On Mon, 15 Jul 2002, Gleb O. Raiko wrote:

> A cache is filled in cachline units. There is a possibility to fill only
> part of cacheline in one cache and to store the rest of data in another
> cache on the switch. Both caches will set the valid bit on this
> cacheline, but only part of cacheline is valid. In the worst cache, this
> operation may load instructions that will be reused later, for example,
> part of the main loop of the cache invalidation (sic!) routine.

 Well, it looks possible for a CPU with cache lines wider than 32-bits
(are there any such R3k-class CPUs?), indeed.

> Unfortunately, the behaviour depends on whether miss occurs, what
> instructions are loaded, how they are aligned, and so on. It means, if
> you get crash on this kernel version, you won't get a crash on another.
> If you add debug routines, everything is OK. Other black magic tricks
> are also here. (As you may guess, I explain my real experience here.
> :-). Analyzer doesn't help, bus transactions look good.)

 How true -- I've seen such nastinesses, too. :-/  Except that I don't
have an analyzer.

> In order to avoid this, CPU shall either perform the check again or
> freeze everything on the cache swap operation. The latter doesn't look
> real. Anyway, it's a lot of additional unnatural logic. So, the
> requirement to run swapping operation uncached looks reasonable.

 Well, the simplest effective approach would be a third alternative, i.e. 
to make swapping happen only when no fill is in progress.  Trivial logic
with a single D latch on the swap signal should suffice -- I don't think
the save on omitting it is worth breaking architecture specs and
performance.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


<Prev in Thread] Current Thread [Next in Thread>