On Tue, 15 Jul 2003 00:45:07 +0100
Richard Earnshaw <rearnsha@buzzard.freeserve.co.uk> wrote:

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

Initially you get one when interrupts are enabled, I suspect I need to
rework when statclock is first primed as it takes to long from priming
to interrupts being enabled, hence the overrun.  The other problem is
the granulatity, currently statclocks speed is probably to high, and
something blocks it for long enough somewhere to cause overruns.
 
> > 
> > > 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.

Sounds a fairly sane way to handle priorities for interrupts.  At some
point I've got to add the isa bus into the cats interrupt handling, so
it does closer to the right thing with devices of a high interrupt
level.

Hmm, the new interrupt code jason did only blocks an interrupt at the
hardware level until it has interrupted, this avoids writing to hardware
when not necessary.  This means that splx doesn't actually write to
hardware, and should make it faster.  It does potentially mean we may
get interrupts that we just add to the pending list.

Chris