VAX 750 Upgrade (GET YOUR FACTS STRAIGHT!)
brown at kpno.UUCP
brown at kpno.UUCP
Mon May 14 08:52:42 AEST 1984
>We have had the same trouble, but managed to fend the DEC-people off.
Enough of this nonsense!
I would think that since you people know about DEC and ULTRIX and presumably
that decvax is reachable via electronic mail that you could send mail to the
folks there and ask them what is really going on rather than cluttering up
USENET with misinformation. If you don't know anyone there try
"decvax!postmaster".
The information I received from DEC concerning the 750 FCOs
is that you can run Un*x with no problems. And indeed you can because
Un*x does not use the stuff which is being fixed(4.3BSD might though
I don't know).
We are happily running 4.xBSD on our 750's with the FCO's installed.
4.xBSD functions happily both with and without the patch area loaded.
My understanding of the situation is that the Rev. 5 FCO installs a
"patch" area for microcode fixes. This patch area is "RAM" which is
loaded by the OS at boot time. The VAX will function without loading
this patch area.
Problems which Rev. 5 fixes: (taken from DIGITAL FCO)
- Premature Read Lock Timeout when a Read Lock Bus function is done on
the CMI.
- On unaligned data transfers using the buffered data path, when Unibus
address bits 0 and 1 are asserted the UBI microsequencer will branch
to DATOB execution flows on a DATI.
- The CPU writes to a Unibus Map Regsiter and clears the valid bit
while the UBI is asserting SSYN on the Unibus. SSYN can be deasserted
before MSYN deasserts.
- The contents of the Time of Year Offset Register are modified upon
assertion of UBUS DCLO L.
- The UBI can assert DBBZ in response to a CPU Unibus reference after
entering the purge microcode flows, causing the system to hang.
- The refresh logic does not always work correctly on power up with
six or more M8750 arrays.
- A patchable control store is needed on the 11/750 and 11/751 CPU's.
Rumor & Hearsay:
There is yet another Rev coming out soon as well. This will be Rev. 6.
Apparently there wasn't enough time to get all the problems straightened
out in time to release Rev. 5. Rev. 6 should finally fix the translation
buffer parity error problem.
regards,
Mike Brown National Solar Observatory
Tucson, Arizona (602) 325-9249
UUCP: {akgua,allegra,arizona,decvax,hao,ihnp4,lbl-csam,seismo}!kpno!brown
CSNET: brown at arizona
ARPA: kpno!brown at lbl-csam.arpa or brown%arizona at csnet-relay
More information about the Comp.unix.wizards
mailing list