linux-mips
[Top] [All Lists]

Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96

To: Jon Burgess <Jon_Burgess@eur.3com.com>
Subject: Re: mips32_flush_cache routine corrupts CP0_STATUS with gcc-2.96
From: Ralf Baechle <ralf@oss.sgi.com>
Date: Thu, 11 Jul 2002 14:13:32 +0200
Cc: "Gleb O. Raiko" <raiko@niisi.msk.ru>, linux-mips@oss.sgi.com, carstenl@mips.com
In-reply-to: <80256BF3.00366849.00@notesmta.eur.3com.com>; from Jon_Burgess@eur.3com.com on Thu, Jul 11, 2002 at 10:49:55AM +0100
References: <80256BF3.00366849.00@notesmta.eur.3com.com>
Sender: owner-linux-mips@oss.sgi.com
User-agent: Mutt/1.2.5.1i
On Thu, Jul 11, 2002 at 10:49:55AM +0100, Jon Burgess wrote:

> I'm fairly sure i've seen comments that say that cache manipulation code
> should be run uncached. My current thought is that it is probably safe to
> manipulate the d-cache with cached code, but I-cache manipulation which
> could invalidate the cacheline containing the currently executing code
> really should be run uncached. I think the CPU probably then skips
> instructions until it gets to the next cacheline, what effect this has
> depends on how the instructions are aligned relative to the cacheline.
> Given how hit-and-miss this is I am suspicous that this problem could
> simply be lurking undiscovered.
> 
> The patch below makes the I-Cache routines run via kseg1, it is a bit
> ugly but seems to work. I have not measured the performance impact of
> this patch.

Have you tried to insert a large number of nops instead?  Or preferably,
how about replacing the __restore_flags() in your example with the
following piece of inline assembler:

  __asm__ __volatile__("mtc0\t%0, $12" ::"r" (flags) : "memory");

  Ralf


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