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. Ralf
