Subject: Re: pmax interrupt problem solved
To: Terry R. Friedrichsen <email@example.com>
From: Michael L. Hitch <firstname.lastname@example.org>
Date: 03/08/2000 08:33:36
On Wed, 8 Mar 2000, Terry R. Friedrichsen wrote:
> Thanks! Now that I know what's broken, I fixed it as in the attached context
> diff. The MI SCSI kernel boots now, and my keyboard and mouse are no longer
> broken, either!
I had already commited a similar fix yesterday, but I'm going to change
it a bit now that I understand what the code was attempting to do.
> While the original code looks confused, what with the ifound variable and
> the do loop, it really isn't (though it *is* broken, as Michael points out).
> The original author is clearly looking for speed, trying to bum a few in-
> structions out of the interrupt dispatch code by using a couple of switch
> statements rather than the chain of if statements in my version.
> In fact, though, the switch() hack is wrongheaded, in that it becomes more
> and more expensive if two or more interrupts are pending.
I think the code was trying to do the same thing Ultrix does, but missed
an important case - i.e. when 2 or 3 interrupts were simultaneously
pending in the same group of bits used in the switch() value. I
disassembled the kn02iointr() routine from Ultrix, and although I haven't
fully analyzed it yet, I think Ultrix includes all possible combinations
of the interrupt bits used in the switch() value. It appears to only
process one interrupt, and would appear to rely on makeing a second (and
possibly third) pass through kn02iointr() to pick up the rest of the
> Since this *is* interrupt code (translation: it gets executed *a lot*), it
> is worth some time to inspect the generated code to make sure we aren't hur-
> ting ourselves too much by doing things the new way.
The Ultrix code would appear to be a very quick way to dispatch
interrupts, at least the case where only one interrupt per switch() is
pending. The NetBSD interrupt processing is different, and uses a lot
more code, at least at this particular part of the interrupt handling.
Michael L. Hitch email@example.com
Information Technology Center
Montana State University Bozeman, MT USA