[Top] [All Lists]

Re: CVS linux

To: "Maciej W. Rozycki" <>
Subject: Re: CVS linux
From: Ralf Baechle <>
Date: Tue, 3 Feb 2004 16:49:35 +0100
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <>
User-agent: Mutt/1.4.1i
On Tue, Feb 03, 2004 at 04:30:33PM +0100, Maciej W. Rozycki wrote:

> > >  How do we assure tails of interrupt handlers don't trigger the errata?
> > 
> > The problem can only be triggered if instructions surrounding the
> > cacheop use the dcache; exceptions such as interrupts are not relevant.
>  Why?  How is an "eret" with its preceding instructions different to other 
> instructions?  There may be a data cache miss soon before an "eret" and 
> the response buffer may contain data.  And you may get an exeption right 
> before a CACHE instruction.
> > Which I'm really happy about.  Disabling interrupts is a problem in cases
> > were we can't avoid page faults.
>  I worry this is unsafe and given the unlikeliness of getting an interrupt
> just between the dummy load and the CACHE instruction, this change creates
> a completely obscure bug that'll bite unpredictably and possibly
> invisibly, just corrupting data, every once and then.  But the situation
> may be not that bad -- what does exactly happen when the erratum gets 
> triggered?  Missing a Create_Dirty_Excl_D operation should itself be a 
> performance hit only, but given the problems reported I suppose data gets 
> corrupted, either in the cache or in the main memory.  Am I right?

I don't know details but since the person who answered my question was
directly working on the CPU design I have to take that as authoritative
information and after all, the systems seems stable.

Daring a guess, the CPU restarts the pipeline following an eret therefore
instructions preceeding the eret can't cause the problem.


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