Subject: Re: pmax interrupt problem solved
To: Terry R. Friedrichsen <terry@venus.sunquest.com>
From: Michael L. Hitch <mhitch@lightning.msu.montana.edu>
List: port-pmax
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
pending interrupts.

> 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			mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA