linux-mips-fnet
[Top] [All Lists]

Re: Memory corruption

To: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
Subject: Re: Memory corruption
From: Ralf Baechle <ralf@uni-koblenz.de>
Date: Thu, 8 Jul 1999 12:39:14 +0200
Cc: linux-mips@vger.rutgers.edu, linux-mips@fnet.fr, linux@engr.sgi.com, Ulf Carlsson <ulfc@thepuffingroup.com>, "William J. Earl" <wje@fir.engr.sgi.com>
In-reply-to: <XFMail.990707230857.Harald.Koerfgen@home.ivm.de>; from Harald Koerfgen on Wed, Jul 07, 1999 at 11:08:57PM +0200
References: <19990706150549.A28849@uni-koblenz.de> <XFMail.990707230857.Harald.Koerfgen@home.ivm.de>
On Wed, Jul 07, 1999 at 11:08:57PM +0200, Harald Koerfgen wrote:

> On 06-Jul-99 Ralf Baechle wrote:
> > I've received a report from some person who is working on his own R3081
> > port.  He also observes data corruption and suspects reading of swapped
> > pages is causing that.
> 
> That's definitely true for R3k DECstations, and no, flushing the icache in
> flush_tlb_page() does not help. I have added cacheflushing to all tlb 
> routines,
> copy_page and even rw_swap_page_base() and swap_after_unlock_page() without
> success.

Note that on R3000 with it's physical indexed caches there is no way that
cache problems should be able to crash the whole system.  At least under the
provision that DMA drivers get their cacheflushing right.

I recently tried to put our memcpy / memmove from the kernel into libc
and as result ended up with a libc which was almost unusable.  Also, a
part of memove is disabled by #if 0, it was demonstrated to cause data
corruption.  Time to fix that bastard.  The whole file is a big mess, btw.
because the code tries to share as much code as possible between memcpy,
memmove and __copy_{to,from}_user.  So put on your peril sensitive
glasses ;-)

> P.S.: I'll be on vacation until July 18th so this has twait a little bit :-)

s/.*/P.S.: I have plenty of time for hacking during my vacation :-)/p ;-)

  Ralf

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