linux-mips
[Top] [All Lists]

Bus error question...

To: linux-mips@linux-mips.org
Subject: Bus error question...
From: peter fuerst <pf@net.alphadv.de>
Date: Mon, 2 May 2005 01:55:08 +0200 (CEST)
Original-recipient: rfc822;linux-mips@linux-mips.org
Reply-to: pf@net.alphadv.de
Sender: linux-mips-bounce@linux-mips.org

Hi,

this question is posted here in the hope, it will be picked up and answered
by some of the <*@*engr.sgi.com> gurus, i apologize to the other members of
this mailing-list for annoying them with it as well ;-)

Is it save to assume, that memory bus errors (mc cpu_error_stat & 0x400) on
IP28 - due to R10k's precise exception model - can be asynchronous only when
caused by an aborted (misspeculated) instruction ?
The R10k manual, experiences with spurious bus errors and experiments with
"real" and speculated loads/stores seem to suggest this.
Moreover, could it be enough to recognize the bus error as asynchrounous,
when the exception code in cp0_cause doesn't say "Instruction bus error
exception" (6) or "Data bus..." (7), but "Interrupt" (0) ?  (i.e. without
analyzing the instruction at epc and register contents)

Rationale for this question: if a memory bus error can reliably be identified
as originating from a misspeculated memory access, it would be possible to get
rid of the myriads of cache barriers before *loads* (stores will remain
protected by cache barriers anyway) again, and spending some thousand machine
cycles on analyzing a bus error every three days of uptime is clearly more
efficient than having a cache barrier in kernel code every seventeen
instructions...

with kind regards

pf



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