Subject: Re: Race condition in generic soft interrupts code?
To: Jason Thorpe <thorpej@wasabisystems.com>
From: Richard Earnshaw <rearnsha@buzzard.freeserve.co.uk>
List: port-arm
Date: 07/25/2003 19:13:19
> 
> On Monday, July 14, 2003, at 02:50  PM, Richard Earnshaw wrote:
> 
> > In trying to port the generic soft-ints code to the Integrator board 
> > I've
> > been running into a race condition that can lead to particular 
> > interrupts
> > becoming permanently blocked, even though the SPL level is 0 and the
> > processor is sitting in the idle loop.  The main symptom is that
> > XXX_ipending has a bit set, and the corresponding bit in intr_enabled 
> > is
> > zero, so the interrupt is permanently blocked.  Here is how I think 
> > this
> > can happen:
> 
> Yah, your analysis is right... However, if you take a look at the 
> XScale ports that use it, you'll see that they already take care of the 
> problem.  See line 515 of i80321_icu.c for an example of a platform 
> that tracks softintrs using software only, or line 504 of becc_icu.c 
> that uses hardware assist for softintrs.
> 

But that code only fixes up blocked soft intrs.  The problem being seen on 
the Integrator (and on Cats, before Chris patched things up) was for 
nested hard interrupts.  The port to the Integrator FPGA support chip was 
done by taking the 80321 code and doing mainly reg-exp replacements, so I 
know that code doesn't handle the case I came across.

R.