Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!ocpt!tsdiag!hico2!sonyd1.Broadcast.Sony.COM!blilly.UUCP!bruce
From: bruce@balilly (Bruce Lilly)
Newsgroups: comp.sys.3b1
Subject: Re: more on the HFC saga
Message-ID: <1991Jun1.113531.5096@blilly.UUCP>
Date: 1 Jun 91 11:35:31 GMT
References: <1991May28.035153.544@highspl> <1991May29.225254.27852@blilly.UUCP> <1991May31.185952.4619@eci386.uucp>
Sender: usenet@blilly.UUCP (News Administrator)
Distribution: na
Organization: Bruce Lilly, Flushing, NY
Lines: 56
Nntp-Posting-Host: balilly

In article <1991May31.185952.4619@eci386.uucp> jmm@eci386.UUCP (John Macdonald) writes:
>
>    (2) When to quit?
>	This can have such possibilities as: quit after the first
>	driver has processed an interrupt, quit after all drivers
>	have been polled once, quit after all drivers have denied
>	having an outstanding interrupt.
>
>(DISCLAIMER: I don't know how these issues were resolved for the
>3b1 - I've looked into them for other Unix kernels on similar
>hardware.)

Quitting after the first driver has processed an interrupt does not
gracefully handle the case where two or more devices have pending
interrupts at the same interrupt level.

The 68000 series interrupt hardware/software uses 3 interrupt lines to
encode an interrupt priority level (7 possible, as well as a no-interrupt
condition). When a device, such as a serial interface controller chip,
wishes to generate an interrupt, it typically drives one of its pins low.
This signal then usually goes to an interrupt controller, which coverts
that one signal into the three which the CPU uses. In the 3B1, according
to the Device Driver Guide, only two interrupt levels are used, so the
interrupt level encoder might not be required. When the interrupting
device had had its interrupt serviced, as in reading the data register on
a serial controller, that device's interrupt output pin is no longer
driven. If there is another device at the same interrupt level, the CPU
will still see an interrupt condition. If all devices at the same level
with pending interrupts have been serviced, the interrupt priority visible
to the CPU will have changed (if there are no pending interrupts at any
priority, the CPU will see a no-interrupt condition -- if a higher-pririty
group of interrupts has been serviced, and there exists one or more
devices with pending interrupts at a lower priority, the CPU will see the
lower priority).

Assuming the interrupt servicing code in the kernel does things in a
logical manner, service routines in the interrupt handling chain need only
be polled until there are no more pending interrupts at the priority level
of the chain. If the 3B1's kernel continues throught the chain, that could
be a source of poor interrupt response time when many device drivers are
loaded (it could also be fixed).

An earlier poster had raised a question about the kernel modification
which was intended to improve response time. My recollection is that that
involved a change to the clock interrupt, which would cause *output*
characters to be sent more frequently. The extra overhead in so doing
could very well delay handling of *incoming* characters at a lower (serial
card) priority.

Perhaps the fellow who posted a day or so ago that he worked on the 3.51
kernel could confirm how it handles these interrupts, and whether the
interrupt services routines are ordered in a last-loaded, first-serviced
manner as described in the Device Driver Guide (which was written for an
earlier version of the OS).
-- 
	Bruce Lilly		blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM