Path: utzoo!utgpu!watmath!onfcanim!dave
From: dave@onfcanim.UUCP (Dave Martindale)
Newsgroups: comp.unix.wizards
Subject: Re: Ultrix tape job is unkillable!
Message-ID: <16971@onfcanim.UUCP>
Date: 21 Dec 88 15:45:05 GMT
References: <476@larry.UUCP> <43200057@uicsrd.csrd.uiuc.edu> <1988Dec18.023931.28730@utzoo.uucp> <17909@glacier.STANFORD.EDU> <1988Dec19.215505.3768@utzoo.uucp>
Reply-To: dave@onfcanim.UUCP (Dave Martindale)
Organization: National Film Board / Office national du film, Montreal
Lines: 26

In article <1988Dec19.215505.3768@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>>On Motorola iron, and on the
>>buses usually used with it, controllers raise an interrupt line when they
>>want attention, and the interrupt will recur until the controller is made
>>happy...
>
>Can you explain where you got the idea that the PDP11 (I can't speak for
>the VAX) does something different?  Believe me, having an interrupt recur
>until the controller is happy is a well-known nuisance on the 11, and as
>far as I know (I'm not intimate with the Unibus any more), the protocol
>is entirely level-triggered.

The behaviour depends on the interrupt controller in the device.
The Unibus itself just handles requests and grants, and a device is free
to request over and over again until it's happy.  However, the original
DEC interrupt controller card contained a flip-flop that was triggered
by the rising edge of an interrupt request signal (usually DONE anded with
interrupt enable) and cleared when the interrupt had been granted by
the Unibus.  Later DEC devices, with all the circuitry on a single card,
retained this behaviour.

Thus, it is common to have a Unibus device driver just handle the information
passed back from the device by an interrupt without ever doing anything
to change the state of the device.  The DONE or READY bit and IENABLE bits
remain set, and the software knows that the hardware will not request
another interrupt.