linux-mips
[Top] [All Lists]

Re: Memory corruption

To: "William J. Earl" <wje@fir.engr.sgi.com>
Subject: Re: Memory corruption
From: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
Date: Thu, 01 Jul 1999 13:25:45 +0200 (MEST)
Cc: linux@cthulhu.engr.sgi.com, Ulf Carlsson <ulfc@thepuffingroup.com>, Ralf Baechle <ralf@uni-koblenz.de>, linux-mips@fnet.fr
In-reply-to: <199907010053.RAA00061@fir.engr.sgi.com>
Organization: none
Reply-to: "Harald Koerfgen" <Harald.Koerfgen@home.ivm.de>
Sender: owner-linux@cthulhu.engr.sgi.com
On 01-Jul-99 William J. Earl wrote:
> Ralf Baechle writes:
[...]
>  > Actually we're pretty generous with our cacheflushed, we flush more than we
>  > should.
> 
>      Yes, but it is not clear that all paths are covered.
> 
>  > > Also, the flush_page_to_ram() slows down processing on
>  > > machines which physical cache tags, for cases where the virtual
>  > > index used by the kernel and the virtual index used by the application
>  > > are the same.  It should have an extra argument of the intended user 
> virtual
>  > > address, so that it can decide whether to flush or not on architectures
>  > > such as MIPS.
>  > 
>  > For R3000 and R6000 flush_page_to_ram() is a no-op, see 
> arch/mips/mm/r2300.c
>  > and arch/mips/mm/r6000.c.
> 
>     Yes, since those have write-through caches.  The icache
> invalidation is still an issue, if there are any paths, such as
> try_to_swap_out(), which break a virtual-to-physical mapping without
> flushing the icache.

A good point. That seems to be exactly the problem R3k DECstations have. 
Processes
are dying with SIGABRT SIGBUS or SIGSEGV shortly after swapping occurs. Trying 
to
hunt that down I removed all optimisations from the cacheflushing routines and 
replaced them with flush_cache_all() but that didn't help.

---
Regards,
Harald

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