CC.ALAN@COLUMBIA-20.ARPA (08/21/84)
From: Alan Crosswell <CC.ALAN@COLUMBIA-20.ARPA> Can anybody give me some pointers as to why autoconf can't find my dmf32 and 2 dz11's on uba1? Uba1 comes up at nexus tr9 but none of the devices come up. I've looked thru the code in vax/autoconf.c and added printfs and the problem is that badaddr() returns true (i.e. the address does not respond). I can't figure out what to try next; everything on uba0 works fine: uda50, 2 dmf32's. I know that at least one of the dz's works because the machine was running VMS just last week (no jokes that VMS broke the hardware, please). I am using the VMS Autosizer (EVSBA) diagnostic SELECT ALL/SHOW DEVICE listing to get the CSR addresses and assume that it is correct since the dmf's on uba0 work fine. There are some other devices on uba1 that I am ignoring for now (dup's and dmc's), but I don't see how that could matter. When running GENERIC, the two dmc's (which have csr's in the block of dz's in the GENERIC config file) did respond properly to the dz driver's probe routine (i.e. autoconf said dzx at uba1 yyy although the device was actually a dmc). Help? Alan Crosswell Columbia U. -------
chris@umcp-cs.UUCP (Chris Torek) (08/22/84)
Does the 4.2 distribution have a preallocated UBA1 interrupt vector
area? If not, that's the problem. If you look at ubavar.c (and I
think locore.s) you'll find a ``UNIvec'' table. This is used for UBA 0
interrupt vectors. Unfortunately for Comet users, the scheme used to
allocate interrupt vectors for UBAs 1 on up doesn't work on 750s. So
autoconf and locore.s and so forth need to use one allocated in ``low
core'' like UNIvec.
(I don't have any more specific information; this is what I remember
from a fix posted long ago for 4.1.)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@maryland