seymour@milton.acs.washington.edu (Richard Seymour) (04/10/90)
A few months ago, i had a diskless VAXstation 3200 connected
via an Able Qniverter booting vms v4.7 from an 11/750's Unibus
cage with a UDA50 controlled RA81.
Everything worked fine.
Last weekend, i tried it again, with vms v5.3-1 and a new model 3200
card (fixed CQBIC chip, new console ROM).
It would not fully boot. The initial "VMS v5.3" message appeared,
the screen cleared and everything got very quiet.
Anyone have any ideas? We also tried an MDB bus converter, same results.
I'm going to try to locate an old-style 3200 cpu card to see if that's
the problem, will report later and will summarize any answers.
thanks,
--dick seymour@npl.npl.wasington.edu (reply works too)
seymour@uwaphast.bitnet
23683::npl::seymour (HEPnet)mark@infopiz.uucp (04/10/90)
In article <2766@milton.acs.washington.edu>, seymour@milton.acs.washington.edu (Richard Seymour) writes: > A few months ago, i had a diskless VAXstation 3200 connected > via an Able Qniverter booting vms v4.7 from an 11/750's Unibus > cage with a UDA50 controlled RA81. > Everything worked fine. > > Last weekend, i tried it again, with vms v5.3-1 and a new model 3200 > card (fixed CQBIC chip, new console ROM). > > It would not fully boot. The initial "VMS v5.3" message appeared, > the screen cleared and everything got very quiet. I think what is going on here, is the following: As of VMS Version 5.0 Digital provided device driver writers the ability to use the extended Qbus mapping registers available on MicroVAX II & MicroVAX III qbus machines. At that point in time, none of the DEC supplied drivers used these routines themselves, but third party device driver writers could use them. As of VMS Version 5.2, Digital began using these extended Qbus mapping registers in their drivers. The driver that actually uses the extended mapping registers now for your disk I/O is PUDRIVER which is loaded from SYS$SYSROOT:[SYS$LDR] during the boot process, and only switched to part way through the boot process. The ROM based driver which are used in the earlier stages of the boot still only use mapping register which map the first 256K of Qbus space. In your configuration, the Qbus to Unibus converter only maps the first 256K bytes of the Qbus into the Unibus since the Unibus is only 18bits that's all you can hope for. Since the VMS driver being loaded during the boot process (PUDRIVER) doesn't know of this limitation in your hardware (as far as it knows since it is on a MicroVAX III machine it has a 22bit Qbus, at it's disposal), things get lost once it trys to start using bus addresses beyond the initial 256K. Other sites will also observe similar problems, with a VMS V5.2 or V5.3 upgrade, when using some third party disk controllers, which have not been properly configured when they were initially installed. Some of the controllers in question include: Emulex QD01, QD21, QD32, QD33, DM01, DM02, etc. Proper configuration in this case, is to enable the 22bit option on the controller and to install their 22bit addressing chip which was initially shipped with almost all of these controllers. -- Mark Pizzolato - INFO COMM Computer Consulting, Redwood City, Ca PHONE: (415)369-9366 UUCP: mark@infopiz.UUCP or decwrl!infopiz!mark or uunet!lupine!infopiz!mark