Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!nbires!isis!udenva!wedgingt From: wedgingt@udenva.UUCP (Will Edgington) Newsgroups: comp.unix.wizards Subject: Re: Problems with two UDA controllers in a MicroVAX Message-ID: <3744@udenva.UUCP> Date: Sun, 31-May-87 22:49:23 EDT Article-I.D.: udenva.3744 Posted: Sun May 31 22:49:23 1987 Date-Received: Tue, 2-Jun-87 05:25:37 EDT References: <7253@brl-adm.ARPA> <426@mtxinu.UUCP> Reply-To: wedgingt@udenva.UUCP (Will Edgington) Organization: U of Denver Lines: 68 In article <426@mtxinu.UUCP> ed@mtxinu.UUCP (Ed Gould) writes: >>I just purchased a Systems Industries QDA4EC/4382 combination. The >>controller emulates a UDA/KDA50. I'm installing it on a MicroVAX-II that >>already has an RQDX3/RD54 combination running BSD 4.3 Unix (Mt Xinu's >>43+nfs). >> >>I generated a system to support the current rqdx3/rd54 disk AND the new >>controller/disk. The new disk is not yet installed but I booted anyway >>to check the configuration. I was very surprized to watch it configure >>uda0 and uda1 at the same address (172150). I wasn't that surprized to see >>the system lock up after that point though. >> >>After rebooting my old vmunix I looked at the uda driver code. It has >>a section of conditional code delimited by VAX630 (i.e. MicroVAX) that >>checks for (cpu == VAX_630) and assumes that there is one controller at >>172150. Normally this code would init the controller at the gened in >>address and wait for it to initialize. *Which* driver code ? The uda.c in sys/vaxuba or in sys/stand ? I believe the one in sys/stand (or is it sys/mdec ?) *does* have this problem. I got around it by making two versions, one for each controller location ... >No such code exists in our distribution. Perhaps someone at your >site added it? Guessing, I might think that it was added because >the DEC controllers take an annoyingly long time to initialize. >Since the microvax was almost certainly bootstrapped with the same >controller, then maybe someone thought they could avoid initializing >it again. I have no idea if this will really work, or if it is why >the code was added, but it sounds plausible to me. I know it's *somewhere* in your distribution, though if I remember right the code is originally from DEC. I certainly didn't add it to my copies ... I know enough about drivers that I know that's (usually) going backwards in terms of capability. On the other hand, I know it's not in both the uda.c's, since I've built a kernel that *almost* works using both UDAs. I gave it the disk drive numbers (ra0, ra1, etc.) in a funny order (ra0 and ra1 on uda*1* and ra[234] on uda*0*), which may have confused it. If I remember right, it tried to swap on a non-existent partition and crashed instantly. I haven't had time to try a configuration in a more normal order (the machine is up and running without the RD53, which is too small to be useful at present). >>If it is not a limitation of the Q-BUS, but of one of the DEC >>controllers I belive I could modify the code to assume that a >>controller at 772150 is a dumb controller and controllers at other >>addresses respond the same as a UDA50. If it is a limitation of the >>RQDX1 or 2 I can take the code out or add conditional compilation if an >>RQDX1/2 is present. > >The second mscp controller on a microvax is usually addressed at >0160334. We have run systems with two controllers, but have >occasionally had difficulties configuring DEC RQDX[23]s as the >second controller. Other manufacturer's controllers configured >second seem to work correctly. I've heard that the controller for the RD5[234] hard disks *has* to be at 772150 and uda0; something in the hardware supposedly forces this. I've also gotten the impression working with the machine that if there's only one uda, it has to be at 772150. ----- Will Edgington, Computing and Information Resources, University of Denver System Administrator for udenva (== dueos), dutyche, duorion, dunike, ... {{hplabs,seismo}!hao,ucbvax!nbires,boulder,cires,ssds}!udenva!wedgingt, WEDGINGT@DUCAIR (BITNET), wedgingt@ccndu (CSN/CCN), ... COMING SOON: wedgingt@du.edu (all nets)|"No two addresses are the same ..."