linux-mips
[Top] [All Lists]

Re: Promblem with PREF (prefetching) in memcpy

To: Dominic Sweetman <dom@algor.co.uk>
Subject: Re: Promblem with PREF (prefetching) in memcpy
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Fri, 4 Oct 2002 15:46:06 +0200 (MET DST)
Cc: Carsten Langgaard <carstenl@mips.com>, Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
In-reply-to: <200210041329.OAA12180@mudchute.algor.co.uk>
Organization: Technical University of Gdansk
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
On Fri, 4 Oct 2002, Dominic Sweetman wrote:

> > You can also configure you system, so you get a external interrupt
> > from you system controller in case of a bus error, there is no way
> > the CPU can relate this interrupt to the prefetching.
> 
> Yes, that's true; interrupts on bus errors are vaguely useful for
> post-mortem diagnosis, but useless for recovery.

 Why do you think so?  Bus errors on reads are synchronous, so if the
handler can judge the error is recoverable (e.g. it was a correctable ECC
error), you can just restart.

 Bus errors on writes are asynchronous, but you may record the necessary
details (the cycle type, the address and the data involved) in chipset
registers and if the handler judges the conditions are recoverable, it may
fix up the error -- e.g. mark the page of physical memory as bad and
substitute another one, copying all other valid data plus the bits that
caused the failure. 

 A system has to be designed to handle such cases, though.  And obviously
if you get one of these errors as a result of a severe hardware damage,
you may not be able to recover, anyway.

-- 
+  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>