On Thu, Sep 28, 2006 at 02:56:29PM +0100, Maciej W. Rozycki wrote:
> > If we take a DBE exception in this code we're in trouble and I've seen
> > systems delivering DBEs highly asynchronously. Afar the Broadcom SOCs
> > fall into that class.
> > So the interesting part is if we take a data bus exception between
> > the stack pointer adjustment and and before EXL is cleared. We're taking
> > a nested exception so c0_epc and c0_cause.bd will not be updated. So
> > when the bus error handler will save the $sp value it saw on entry but
> > will return to the EPC of the first exception, that is only one stack
> > frame will be popped. Whops ...
> It looks like a design issue -- further asynchronous bus error exceptions
> should be blocked till one currenly being handled has been acked. In fact
> if they are asynchronous, then it really makes no sense to use the
> exception and a general interrupt should be used instead -- the whole
> point of using an exception here is the ability to stop a data corrupting
> transaction, as unlike an interropt, an exception can be precise.
I would suggest to disable interrupts around accesses that potencially
could result in DB exceptions and just to make sure he is not getting
trapped by a non-blocking load by making some use of any value read
from the device. Writes could be posted depending on bus type. So
having a read from the same device would force the write to complete.