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.