gamiddleton@lakehead.UUCP (Guy Middleton) (05/08/84)
We have a 750 running 4.2bsd, and our DEC field service people tell us that we have to have an upgrade to the machine, to read microcode patches. The problem is, that this is a software update as well as hardware, so you have to be running VMS to put the patches in. Does anybody know any details? We can't find out for sure, and don't want to go ahead until we know it's safe. Guy Middleton, Lakehead University
hans@log-hb.UUCP (05/09/84)
[]
We have had the same trouble, but managed to fend the DEC-people off.
In the end we'll all need to take this particular plunge, but in that
very same end, DEC vill have ULTRIX around, and will have some sort of
solution.
One idea is to boot VMS, letting VMS load the patches, and then let VMS
boot UNIX for you. With VMS & UNIX on different disks, this would work.
Further, this particular solution requires that under UNIX the VMS-area
is hidden out of sight, by ( for instance ) shortening a file system
somewhere. Since VMS should never run in it's own right, no similar
artifact is really needed unde VMS, but covering the UNIX area with an
unaccessible file is a tested technique.
Later this year I'll definitely do just this, since I want to be able to
move UNIX around more.
--
{decvax,philabs}!mcvax!enea!log-hb!hans
Hans Albertsson,
TeleLOGIC AB
Box 1001,
S-14901 Nynashamn,
SWEDENbrown@kpno.UUCP (05/14/84)
>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@arizona
ARPA: kpno!brown@lbl-csam.arpa or brown%arizona@csnet-relay