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

> 
> chris@dokein.co.uk said:
> >  Hmmm, which platform was this? 
> 
> As I said an Integrator (evbarm/INTEGRATOR)

That's what I get for answering emails after a play rehersal...

> > I fixed this on cats, note the tail
> > end of footbridge_intr_dispatch does an splx(pcpl), I did mail jason
> > about this, see attached, but he probably lost it in his mountains
> > of emails. 
> 
> 
> 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)

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

At one point I did experiment with an interrupt handler that processed
interrupts in priority order, rather than ffs order, but I binned it as
I was still having other issues which I've now fixed, I should probably
revisit that code...

Chris