Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!fcom.cc.utah.edu!cc.utah.edu!cc.usu.edu!slsw2 From: slsw2@cc.usu.edu Newsgroups: comp.sys.dec Subject: Re: "passive release"? What is it? Message-ID: <1991Feb13.131922.46862@cc.usu.edu> Date: 13 Feb 91 19:19:22 GMT References: <1991Feb12.044547.1097@spcvxb.spc.edu> Organization: ÿÿÿÿ Lines: 32 In article <1991Feb12.044547.1097@spcvxb.spc.edu>, terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) writes: > In article , goehring@ai.mit.edu (Not Marc Spencer) writes: >> The _VAX Architecture Reference Manual_ specifies that SCB vector 00 >> is for a "passive release" interrupt. What is a "passive release", >> what causes one, what is the OS expected to do with one of these, and >> what parameters are pushed on the stack? > > In brief, when a device asks for the bus via interrupt request, but > then decides to ignore the interrupt ack from the Unibus adapter. Thus, > the ack progresses through the backplane. If no other device grabs it, > it hits the terminator. Close, but no cigar. You see, the UNIBUS bus requests are really DMA requests. Once a device has been granted the UNIBUS, it can do anything it wants including giving a vector to the CPU; note that the CPU is a slave for this operation, not the master. If the UNIBUS device decides not to give the CPU a vector, the bus is released and everything goes on its merry way; on a PDP-11, the bus request is ignored and the CPU is not interrupted. VAXes view the interrupt acknowledge sequence kind of like a special type of read; the CPU asks the interrupting device for a vector. The CPU is the master for this operation and the slave must respond. If the UNIBUS device elects not to give a vector to the processor, the UNIBUS adapter will return a 0 to complete the transaction. -- =============================================================================== Roger Ivie 35 S 300 W Logan, Ut. 84321 (801) 752-8633 ===============================================================================