Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site watcgl.UUCP
Path: utzoo!linus!decvax!ittvax!qumix!amd!dual!zehntel!ihnp4!mhuxj!ulysses!burl!clyde!watmath!watcgl!dmmartindale
From: dmmartindale@watcgl.UUCP (Dave Martindale)
Newsgroups: net.unix-wizards
Subject: Re: Unibus zero vectors on vax/780
Message-ID: <132@watcgl.UUCP>
Date: Wed, 3-Oct-84 11:06:06 EDT
Article-I.D.: watcgl.132
Posted: Wed Oct  3 11:06:06 1984
Date-Received: Sat, 6-Oct-84 07:05:18 EDT
References: <479@oddjob.UChicago.UUCP>
Organization: U of Waterloo, Ontario
Lines: 22

All of the 780's that I've seen slowly accumulate zero vectors over time.
As far as I can tell, it is a feature of the interrupt controller used
in most DEC hardware.  When a device sees a bus grant going by at the
program interrupt level that it is on (BG4 or BG5 usually) and sees a
request for DMA cycle active (NPR), it will grab the grant, return
SACK to the arbitrator, and then release the bus to allow the NPR to
be serviced.  On PDP11's, this just caused a bit of wasted bus activity
but gave faster service to NPR's.  On the 780, at the point that the
BG is issued, the CPU is already in its interrupt service routine for
the UBA, and when a device doesn't complete an interrupt sequence,
the UBA returns 0 as the vector.

Thus zero vectors are a "feature" of the interrupt controllers
in some devices (DZ's included) which come into play when there is
DMA and programmed I/O activity occuring at the same time on the UNIBUS.
Having DZ's make it worse, since they do so much programmed I/O.
But I believe that this condition is quite normal and there is nothing
you can do about it, short of rearranging your UNIBUS.  Probably,
the kernel should be changed so that it does the UBA reset only if
the zero vector count has been very high over a very short period.
Accumulating the number since boot time without decrementing it
periodically is just silly.