> > 
> > Ah!  I was wondering why the cats port didn't fall flat on its face
> > within a few milliseconds of enabling interrupts.
> 
> oh it did, till I hunted the bug down.  you can do funky things such as
> pressing keys waking things up (it was an odd one to track down)

I don't think I tried that -- I was running the kernel under RVD (ARM's 
debugger) and was just breaking in using Multi-ICE.  The great advantage 
of that was that I got to see exactly what the state was without having 
the processor go off and execute more code before handing over control 
(well, it's nearly like that).

I wonder if this explains why we are getting so many statclock overruns on 
cats at present...

> 
> > Yes, I think your patch would work, but it's much less efficient since
> > the pending interrupts will cause another trip up through the
> > interrupt entry code.
> 
> Yes, it does round trip, it was something I wanted to make more
> efficient but life has been busy for me.  I'm not that happy with it,
> but was concerned that the other method could cause interrupt starvation
> for a high priority interrupt as the interrupts are handled in ffs
> order, not in priority order, IE if bit 30 is statclock, but you've got
> bit 1 as clock, 2 as audio, 3 as bio etc,  and statclock and something
> else interrupt at the same time, you may actually manage to keep the
> system busy enough it never processes interrupt 31.  However the chances
> of this are probably very small.

Yep, I realized that as well (I was saving that for later, once I had 
committed the basic code).  However, I only enable interrupts that are not 
blocked by the current SPL and your code doesn't really do things any 
differently (it simply re-enables all blocked interrupts).  One thought I 
had on this was to test hwpend for being a single bit (trivial) and skip 
all the priority checks if that is the case (it will be the common case).  
Only if there are multiple pending interrupts do we need to scan for them 
in priority order.

R.