jch@omnigate.clarkson.EDU (Jeffrey C Honig) (05/06/87)
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. Why is this code there? Is it because someone assumed that the uVAX will only ever have one controller, because of a Q-BUS limitation, or because the uda controllers used in development of the MicroVAX (RQDXn) support don't respond the same as a UDA50? 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. Thanks Jeff
ed@mtxinu.UUCP (Ed Gould) (05/07/87)
>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. 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. >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. -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."
wedgingt@udenva.UUCP (Will Edgington) (06/01/87)
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 ..."