| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 78.1 | Faster and faster..... | COMICS::TREVENNOR | A child of init | Fri Nov 10 1989 10:25 | 12 |
|
There is an interesting discussion going on in the MIPS notes file
(note 133) about the VAX 9000 series as compared to the MIPS RISC
machines (as to be found in our DECstation 3xxx and 5xxx series
machines). The recently announced R6000 chip set from MIPS is
discussed. *DO NOT* tell anyone that this will be shipped in a future
DEC platform....
Hit KP7 to add the MIPS notes file to your notebook.
Alan T.
|
| 78.2 | | KERNEL::MOUNTFORD | | Mon Jan 15 1990 09:58 | 20 |
| <<< KERNEL::DISK$APD1:[NOTES$LIBRARY]CSGUK_SYSTEMS.NOTE;1 >>>
-< CSGUK_SYSTEMS >-
================================================================================
Note 78.2 VAX 9000 topic. 2 of 2
KERNEL::MOUNTFORD 12 lines 12-JAN-1990 09:10
-< 9000 Documentation. >-
--------------------------------------------------------------------------------
Moved by moderator:
-------------------
The Documentation to support the VAX 9000 is to be made available
in Book-Reader format (i.e., it can be read on-line if you have a
smart new `telly' on your desk!). I am copying over a preliminary
version of the MBox Technical Description Manual to the PAPERS::
Cluster and will demonstrate it's abilities on demand (given that I
can drive a mouse!!)
Chris Loane.
|
| 78.3 | 9000 info | KERNEL::BLAND | toward 2000 ... | Sun Jun 10 1990 06:14 | 216 |
| From: KERNEL::MRGATE::"A1_KERNEL::PENAT" 25-MAY-1990 17:46:21.88
To:
CC: COMICS::LOANE,KERNEL::ALLEN,KERNEL::DICKSON
Subj: VAX9000 Service Status (25-May-90)
From: NAME: Toze Pena
FUNC: P & T
TEL: (0256) 56101 x3942 <PENAT AT A1_KERNEL @THESUN @UVO>
To: See Below
CC: See Below
**************************
COMPANY CONFIDENTIAL
**************************
Here is the latest status on the VAX9000. The information contained
herewith is subject to change as more information becames available.
The next update will be on the 8th of June.
SYSTEMS ORDERED: Customer Delivery date Location
---------------- ----------------------------- ------------------
SQM (internal DEC) July Dec Park
Mercury July Warrington
Lloyds July Worthing
Liffe September London
FUTURE ORDERS: Customer Comments
-------------- -------------------------------------------------------------
SMS Order Placed. Customer does not require
System until Feb 1991.
Short Bros. * Order not yet placed by the customer.
(Currently the earliest ship date from
Manufacturing is Oct 90)
British Gas * As above.
British Aerospace * As above.
Reuters * As above.
Nat. West. The exact situation is unknown.
Ins. Services
TRAINING:
---------
Course contents are being reviewd, any modifications will be communicated
in the next update. The following is the latest list of courses and
Engineers who have already attended or who are booked.
Installation and Maintenance (EY-B734E-DM):
Dyfrig Davies ESO 9-Apr
Andrew Kakoullis ESO 9-Apr
Marek Stubbs SBP 9-Apr
Steve Begley HHL 7-May Andy King HHL 18-Jun
Bob Cramphorn NOT 7-May Mike Rhodes BIO 18-Jun
Graham Langford HHL 7-May Chris Steiert HHL 18-Jun
Daljit Tamana HHL 7-May Chas Donnelly HAN 18-Jun
Ronnie Millar BVO 28-May Chris Chandler EOO 15-Aug
Bill Dawson OLO 28-May Malcolm Raper EOO 10-Sep
Martin Rowe OLO 28-May David Pang EDA 26-Sep
Fault Analysis (EY-B733E-DM):
Peter Luck ESO 9-Apr Peter Bird RKG 17-Sep
Allen Maskell UBO 9-Apr Peter Greatbach BSO-9 17-Sep
Steve Wibrew UVO 21-May Chris Chandler EOO 17-Sep
Ralph Clingan NOT 9-Jul Neil Hutchinson RKG 17-Sep
Rory O'Donnell UVO 9-Jul John Travell UVO 17-Sep
Theory of Operations:
Dave Wrighton UVO 26-Mar
VAX9000 UPC (EY-B729E-DM):
Dyfrig Davies ESO 2-Apr
Marek Stubbs SBP 2-Apr
John Morgan HAN 2-Apr
Peter Luck ESO 2-Apr David Pang EDA 11-Jun
Allen Maskell UBO 2-Apr Chris Steiert HHL 11-Jun
Andrew Kakoullis ESO 2-Apr Andy King HHL 11-Jun
Steve Begley HHL 30-Apr Chas Donnelly HAN 11-Jun
Bob Cramphorn NOT 30-Apr Bill Dawson OLO 11-Jun
Graham Langford HHL 30-Apr Ralph Clingan NOT 2-Jul
Daljit Tamana HHL 30-Apr Rory O'Donnell UVO 2-Jul
Steve Begley HHL 30-Apr Chris Chandler EOO 2-Jul
Mike Rhodes BIO 14-May Malcolm Raper EOO 27-Aug
Steve Wibrew UVO 14-May Peter Bird RKG 10-Sep
Martin Rowe OLO 21-May Neil Hutchinson RKG 10-Sep
Ronnie Millar BVO 21-May John Travell UVO 10-Sep
Site preparation Seminar was conducted and here is a list of attendees:
Nigel White UVO DS
John Strong LZO ENV
Ronnie Millar BST ENV
Ron Fletcher DS_Skills Centre DS
John Brooks HHL DS
Tom Cox UBO DS
John Elwin REO IS
Martin Patten HHL ENV
Ken Matthews OLO ENV
John Cashman DBO DS
Graham Langford HHL PF 9000 ENGINEER
Phil Stone BIO DS
Liz Woodward BIO DS
Fiaz Khan NEW DS
Bill Whitmore ESO Installations Planner
Below is a list of courses available and dates.
- Fault Analysis: 9-Jul 17-Sep
- Installation and Maintenance: 28-May 18-Jun 15-Aug 10-Sep 26-Sep
- UPC: 11-Jun 2-Jul 27-Aug 3-Sep 10-Sep 8-Oct
There are a few slots available on courses scheduled up to June,
courses thereafter have plenty of vacancies. There are no UK enrolments
on the 3-Sep and 8-Oct courses.
SUPPORT PLAN:
-------------
Cover will be provided seven days a week, twenty four hours a day
for both Software and Hardware. This is an area which is still
under discussion.
The Services escalation flow is as follows:
SDD generated call
logged by System.
|
|
V
Accepted by CSC
(RSDS Call Handling System) (CSC will provide RDC cover 24x7)
|
|
V
RDC Eng places call w/ Branch
detailing spares required.
|
|
V
Fault fixed ?
| No
Yes |------------> a) PTG Prod Focus Eng is involved.
V
Call Completed b) Problem information is entered
on TIMA (Chatter Box) and ESASE.
This will alert ALL Corporate
and European areas of the problem.
c) CSSE support available.
d) All Senior European Eng's will
be used as a European Support
Group.
It is crucial that each Service Operation with responsibility for a
VAX9000 site must ensure that a trained Engineer is available 24x7.
LOGISTICS:
----------
One full spares kit and miscellaneous parts will be available at FCS
for Mercury. This material will be located in the Warrington branch.
Logistics support has been negotiated for another spares kit for SQM
in the unlikely event of the MCU's revision differ from the first
System shipped.
Some of the modules ie MCUs, Vectors (part numbers starting P,T or H)
will be available with a blank TK50 tape, to differentiate these modules
the part number will start with an F6- or F7- making the part number
something like F6-Pxxxx-00. If the module is being returned for repair
the TK50 tape with data must be accompanied with the module using the
same part number ie F6-Pxxxx-00.
When a spare is used from the kit it will trigger an automatic
replenishment mechanism. A special high speed route is in place to
replenish the module directly to the Branch.
UK and Europe will be tracking the MCU revision levels, serial numbers
and stock locations.
POD PROCESS
-----------
1) It is the Account Team responsibility to a) get the CCD from Galway,
(Contact is Padraic O'Loughin) and b) at the completion of CCD it
ensures a slot in Manufacturing.
2) The Configuration is an EIS responsibility. Special VAX9000 courses
have been run for EIS pre-sales people and on-going training is still
available.
3) Service Engineer will travel to Galway to participate in the final
assembly of the System. When this is completed the System will be
loaded on a special Air Conditioning truck and transhipped directly
to customer site. The Installation Eng and Galway Manufacturing Eng
will travel with the System and install it. The goal is 100% trouble
free installation within 48 hours.
Best Regards,
Toze
**************************
COMPANY CONFIDENTIAL
**************************
|
| 78.4 | and you thought the 8800 had I/O related problems ! | KERNEL::WRIGHTON | No , it's meant to work like that ! | Mon Jun 18 1990 16:27 | 98 |
|
INTEROFFICE MEMORANDUM
To: VAX 9000 developers Date: June 8, 1990
cc: From: Sarah Tappan
Dept: VMS Engineering
Phone: 381-1637
Loc: ZK3-4/W23
E-Mail:STAR::TAPPAN
Subject: VAX 9000 BI device drivers must conform to I/O space access
rules.
Developers of code for VAX BI options intended to run on the VAX
9000 need to be aware that field-type instructions are not
legal in I/O space. Other VAX implementations were forgiving
of this type of illegal reference. These instructions will fail
on the VAX 9000 due to the way the hardware pre-fetches addresses.
All current BI drivers should be checked for references to
instructions that use bit field operands to CSR's or other I/O
space regions. Examples of such instructions are:
� BBS, BBC, BBSS, BBSC, BBCS, BBCC
� FFS, FFC
� EXTV, EXTZV
� CMPV, CMPZV
� INSV
DEC Standard 32 section 7 contains a complete description of
legal instructions for use in I/O space.
This memo is being distributed to make support people aware of the
issues that exist with the enforcement of DEC std 32 combined with the BBS and
BBC type instructions on a VAX-9000. The issues are being resolved with Digital
written software as testing continues and problems are uncovered. However we
have no control over third party software which may also have the same
problems. So, be aware of this adherence to DEC std 32 related to VAX-9000 and
the possibility of related problems.
< Many forwards removed>
+---------------------------+ TM
| | | | | | | | INTERNETWORK MEMORANDUM
| d | i | g | i | t | a | l |
| | | | | | | |
+---------------------------+
TO: VAX 9000 TECHNICAL PERSONAL DATE: June 15, 1990
CC: FROM: TOM MORAN
DEPT: VMS Engineering
EXT: 381-2876
MAIL: ZKO1-1/F16
ENET: VMSSPT::MORAN
SUBJECT: Fix in drivers YIdriver and LIdriver for VAX 9000
The VAX 9000 has enforced a DEC standard 32, that
states BBS and BBC type instructions are not allow
on I/O space. Other BI VAXes to date have allowed
these instructions.
When the VAX 9000 hardware was upgraded several
weeks ago the DMB32 and DHB32 stopped operating
correctly. It was determine the reason was because
the drivers used for these devices used these type
of instructions.
The YIdriver for the ASYNC ports for the DMB32 and
the DHB32, along with the LIdriver for the DMB32 line
printer port have been modified and tested today in
MRO, on a VAX 9000. Both drivers functioned correctly.
I have submitted the drivers to be put into the
official V5.4 version, which freezes on Monday and will
be available soon for internal testing.
If any new problems arise please contact me as soon
as possible.
|
| 78.5 | MCU bolt problem | KERNEL::WRIGHTON | No , it's meant to work like that ! | Mon Jul 30 1990 10:43 | 35 |
|
Subj: Planar assembly build -Castings/screws
THIS IS AN IMPORTANT MESSAGE THAT EVERYONE NEEDS TO READ, UNDERSTAND AND
ADHERE TO -
o ANY CASTING USED IN PLANAR ASSEMBLY BUILD HAS TO (AT THIS POINT IN TIME)
MEET THE FOLLOWING CRITERIA:
o IT NEEDS TO HAVE KEENSERTS AND NOT HELICOILS. I DON'T HAVE TIME
TO EXPLAIN THE DIFFERENCE. ANYONE WHO KNOWS THE DIFFERENCE
CAN EXPLAIN. SEEK THEM OUT IF YOU DON'T KNOW.
o IT NEEDS TO HAVE HAD ALL OF THESE KEENSERTS TAPPED. SEE GORDY
MCCUIN TO VERIFY. JIM & JON ALSO KNOW HOW TO DO THIS PROCESS.
o ANY SCREW TO BE USED IN THIS PROCESS NEEDS TO HAVE BEEN THREAD GAGED BY
GORDY AND OR HIS DESIGNEES.
THE ABOVE CONDITIONS ARE IMPERATIVE.
THE ABOVE CONDITIONS ARE IMPERATIVE.
THE ABOVE CONDITIONS ARE IMPERATIVE.
IF YOU HAVE ANY QUESTIONS OR HAVE ANY PROBLEMS WITH THE BUILD THIS WEEKEND
FROM PARTS THAT HAVE MET THESE CONDITIONS, THEN PLEASE CALL ME. 865-2292.
THANKS, AND HAVE A GOOD WEEKEND,
Gary
|
| 78.6 | The function of SJALOG.SYS | KERNEL::WRIGHTON | No , it's meant to work like that ! | Mon Jul 30 1990 10:51 | 43 |
|
Sjalog.sys is the file created by the portion of
sjadriver that handles SPU to VMS error log transport.
If VMS is not available, sjadriver logs error log
entries bound for VMS into SJALOG.SYS until VMS
becomes available. At that time sjadriver (the sub
proc that handles this) will unload SJALOG.SYS and
send all the contents to VMS and delete sjalog.sys.
consequently:
1) sjalog.sys can be treated just like errlog.sys on
the SPU (as far as ERF is concerned, that is);
2) you can force errors to re-occur (be resent) to
VMS by copying your errlog.sys file to a file called
sjalog.sys (neat trick);
-IF- you are seeing this and VMS is running, it
typically means you're running an older version of
SPU code (like 10.1 or 2). There's a hack in 10.3
that fixes a VMS bug that didn't want to accept these
packets when it was supposed to. The hack delays
requesting memory to load in the packets until after
VMS has booted completely (before we were asking too
early - this is still a VMS bug, but now you won't
see it when you got to 10.3).
There will be another hack that may make 10.4 which
will actually restart the sjadriver hunk that handles
this by doing repeated retries to VMS in case we
still miss the window (which still happens if ERH
runs while SJAdriver tries to log a message to VMS -
VMS isn't running so it never sees the request - so
the process hangs due to a timeout! then sjalog.sys
grows and grows and grows and...)
hope that helps.
butch
|
| 78.7 | Problems with BL10.3 SPU S/W release | KERNEL::WRIGHTON | No , it's meant to work like that ! | Mon Jul 30 1990 10:52 | 33 |
|
There are two serious bugs in the BL10.3 SPU software release that we must
insure the systems in the field and those about to be shipped do not incur.
They are SPU to VMS DMA bug and automatic snapshot bug.
SPU to VMS DMA bug:
This problem causes the last quadword of blocks transferred from VMS to the
SPU to be incorrect if the block is 508 bytes or greater. The workaround is
to edit SJAINIT.CMD and add the command SET SJA/NODMA.
Automatic snapshot bug:
This problem causes infinite snapshot files on keep alive failures and uses
the SCU CDB filename with no extension as the filename. The workaround is to
edit SITESPECIFIC.CMD and set SYS$KEEPALIVE to "MANUAL". The file KAF.CMD
should be created in [SYSEXE] if it does not already exist and should contain:
SET SNAPSHOT TRIGGER
@[SYSEXE]REBOOT
Please let me know if there is a problem in making these changes. Both problems
are corrected in BL10.4 and will be available shortly for updates. The 10.4
release is currently on hold pending the VCS hang debug effort. This should
be resolved by the end of the week.
The edit to SJAINIT.CMD must have the SET SJA/NODMA at the end of the file as
there is a command to enable DMA. Alternately, the existing command may be
edited to set /NODMA.
Butch Leitz
|
| 78.8 | XJA problems | KERNEL::WRIGHTON | No , it's meant to work like that ! | Mon Jul 30 1990 10:53 | 68 |
|
XJA STATUS UPDATE
July 16, 1990
This XJA status update has been jointly prepared by Brad Palmer and
Malcolm White and is designed to clarify some of the conditions which
currently exist in the XJA module.
There are three known defects in the Rev C03 XJA design.
- The XJA and the XCD have an interaction during self test when they
are both located on the same backplane. This is caused by the XJA
incorrectly responding to a signal generated by the XCD as a part
of its self test. This condition will be corrected with the
DC7092C PGA (Rev D modules). There are three proposals for
correcting the Rev C03 modules. The current plan is to fix it by
modifying the XJA AOST code in the EEPROMS. The other two
proposals had more far reaching effects be modifying the XCD. The
modified AOST XJA's (probably identified as Rev C04) will be
available one week after the code has been fully evaluated and
provided to Augusta. The system receives a self test failure
message, but the system is still fully functional.
- The XJA intermittently fails self test upon initialization. While
the problem is known to exist in varying degrees in Rev C02 and
C03 it is not known to be present in C01's. It occurs only on
initialization with a SPU reset; once it has passed
initialization, it can be looped indefinitely on the same set of
tests or operated as part of the system. Extensive analysis has
gone into diagnosis of the problem, but a fix is not yet known.
The problem is most severe when the module is hot. Cooling down
one of the two DC444 gate arrays with localized cooling allows
the XJA to successfully complete initialization. While it is
desired to incorporate a fix into Rev C04 or Rev D, it is not
currently planned to delay either of these two upgrades. Solution
to this problem will remain a very high priority.
- The XJA Retry is a known parity error anomoly that occurs very
intermittently in all Rev C XJA's, but is not a serious problem
for the system. The data is retransmitted with no loss. It will
be fixed with the DC7092C.
Other XJA's have been rejected at Burlington for failing High Clock
Margining at ~535 MHz. This is above the design criteria of 500 MHz.
If it is determined that the XJA is required to operate at this
frequency, additional effort will be required to modify the design or
the purchase specs to enable the module to reliably meet this higher
criteria.
It is very important that any perceived failure of an XJA in a system
be clearly identified and described to Brad Palmer, preferably in near
real time. This will allow proper analysis of the problem, and if
appropriate, retry of the suspect XJA. It does no good to replace an
XJA for one of the above problems as any existing XJA has the same
problems inherent in it.
The DC7092C layout is currently being evaluated with Second Sign-Off
occurring as soon as Wednesday, July 18th. Proto PGA's will be
available two weeks after that date. The first of the pre-production
PGA's would then be available in late August.
|
| 78.9 | SDD Installation | KERNEL::WRIGHTON | No , it's meant to work like that ! | Mon Jul 30 1990 10:54 | 88 |
|
**************************************************************************
DIGITAL EQUIPMENT CORPORATION CONFIDENTIAL
------------------------------------------
F O R I N T E R N A L U S E O N L Y
***************************************************************************
TITLE: 9000 System Console install of SDD
DATE: 12 July 1990
AUTHOR: Tom Collentine TD #: 000339
DTN: 297-4749
ENET: MRCSSE::TCOLLENTINE CROSS REFERENCE #'s:
DEPARTMENT: HIGH-END SYSTEMS CSSE (PRISM/TIME/CLD#'s)
INTENDED AUDIENCE: PRIORITY LEVEL: 1
(U.S./EUROPE/GIA) (1=TIME CRITICAL,
2=NON-TIME CRITICAL)
=====================================================================
Procedure to install EWKCA the SDD Diagnostic.
OVERVIEW:
EWKCA is a symptom directed diagnostic that run on the 9000
service processor. It performs single event fault analysis
using the error signature information contained within the
error log entry. EWKCA generates a SDD syndrome entry that
contains the theory number that indicts the failing FRU. This
entry is placed in the error log.
PROBLEM:
EWKCA is bonded to the SID serial number. It will have to be
RE-installed whenever the 9000 console software is upgraded.
If EWKCA has not been installed with the Install utility you
will get the following message on the console when the SPU is
rebooted.
%SPU-F-NOTINSTALLED, this image has not been installed
Workaround:
To Install EWKCA.EXE
1. Copy Install.exe and Install.cld to the console dir
[sysexe]
2. SET DEF [SYSEXE]
3. SET COMMAND INSTALL
4. INSTALL [SYSMAINT]EWKCA.EXE
5. REBOOT/NOCONF
After installing EWKCA and rebooting the SPU check that the
EWKCA process is present as follows.
>>> Show Sys
00140000 EWKCA Wait 20 0 00:00:02.07 492 112
If EWKCA is not started check the following command files
located in [SYSEXE] on the console.
STARTUP.CMD !Executed by the SPU on reboot.
SPUINIT.CMD !Called by Startup.cmd.
EWKCA.CMD !Command file to start SDD if installed correctly.
Long Term fix:
This is valid with console FT 10.3 and may change in future
releases.
*** DIGITAL INTERNAL USE ONLY***
|
| 78.10 | SPDF MATRIX | KERNEL::WRIGHTON | No , it's meant to work like that ! | Mon Jul 30 1990 10:56 | 179 |
|
CONFIG B4
---------
| Total now 23 of 23. 0 still running, 0 have failed.
These files shall be used along with all Config B3 files to test a complete B4 system.
Only Vbox test files and CPU1 test files are included in this set.
| X = MCU involved in testing |
|--------------------------------------------|
|C C D D D F I M O U V V V V V X C D D D D T|
|T T S T T A N U P C A A I M R B C A A B B A|
Filename |L U T A B D T L U S D P C L G R U 0 1 0 1 G|
------------------------|--------------------------------------------|
XB4_AVA_CTL2_9005281849 |X X X X X . X X . X X X . . . . . . . . . .|
XB4_1AA_CTU1_9006171413 |. X . X X . . . . . . X . . . X X . . . . X|
XB4_1AA_DST1_9006302339 |X X X X X X X X X . . X . . . X . X . . . .|
XB4_1AA_DTA1_9006200516 |. X . X X X . X . . . X . . . X . X . X . .|
XB4_1AA_DTB1_9006200116 |. X . X X X . X . . . X . . . X . X . X . .|
XB4_AVA_INT1_9006181510 |X X X . . X X X X X X X . . . X . . . . . .|
XB4_AVA_MUL1_9006181510 |X . X . . X X X . X X X . . . . . . . . . .|
XB4_AVA_OPU1_9006181510 |X X . . X X X X X X X X X . . X . . . . . .|
XB4_AVA_OPU2_9006090047 |X X . X . X X X X . X X X . . X . . . . . .|
XB4_AVA_OPU3_9006080733 |X . X X X X X X X . X . X . . X . . . . . .|
XB4_AVA_OPU4_9006081039 |. X . . . . . . X . . X X . . X . . . . . .|
XB4_AVA_UCS1_9005220317 |X . X . . . X X . X X . . X X . . . . . . .|
XB4_AVA_UCS2_9005240550 |X X X . . X X X . X . X . . . . . . . . . .|
XB4_AVA_VAD1_9005221928 |X X X . . . X X . X X X . X X . . . . . . .|
XB4_0VA_VAP1_9005271642 |X X . X X X X X X . X X . . . X . X . . . .|
XB4_1NA_VAP1_9006222115 |X X X X X X X X X . . X . . . X . X . . . .|
XB4_1VA_VAP1_9006202232 |X X . X X X X X X . X X . . . X . X . . . .|
XB4_AVA_VAP2_9005260520 |X X X X X X X X X . . X X . . X . . . . . .|
XB4_AVA_VML1_9005141448 |. . X . . . X X . X X . . X X . . . . . . .|
XB4_AVA_VRG1_9005120224 |. . X . . . X X . X X . . X X . . . . . . .|
XB4_1AD_SCU1_9006201727 |. X . . . . . . . . . . . . . . X X X X X X|
XB4_1AN_SCU1_9006241834 |. X . . . . . . . . . X . . . . X X . X . X|
XB4_1AD_SCU2_9006160245 |. X . . . . . . . . . X . . . . X X X . X .|
CONFIG B3
---------
Total now 22 of 22.
| X = MCU involved in testing |
|--------------------------------------------|
|C C D D D F I M O U V V V V V X C D D D D T|
|T T S T T A N U P C A A I M R B C A A B B A|
Filename |L U T A B D T L U S D P C L G R U 0 1 0 1 G|
------------------------|--------------------------------------------|
XB3_AAA_CTL1_9005221012 |X . X . . X X X X . . . X . . X . . . . . .|
XB3_ANA_CTL2_9004251443 |X X X X X . X . . X . X . . . . . . . . . .|
XB3_AAA_CTL3_9005031059 |X X X . . . X . X . . X X . . X . . . . . .|
XB3_0AA_CTU1_9006150947 |. X . X X . . . . . . X . . . X X . . . . X|
XB3_0AA_DST1_9005130042 |X X X X X X X X X . . X . . . X . X . . . .|
XB3_AAA_DST2_9005040231 |X X X X X X X X X X . . . . . . . . . . . .|
XB3_AAA_DST3_9006150949 |X X X . . . . . . . . X . . . X . . . . . .|
XB3_0AA_DTA1_9004280444 |. X . X X X . X . . . X . . . X . X . X . .|
XB3_0AA_DTB1_9006141109 |. X . X X X . X . . . X . . . X . X . X . .|
XB3_AAA_FAD1_9006141209 |X . X . . X X X . X . . . . . . . . . . . .|
XB3_ANA_INT1_9004291524 |X X X . . X X X X X . X . . . X . . . . . .|
XB3_ANA_MUL1_9006141610 |X . X . . X X X . X . X . . . . . . . . . .|
XB3_ANA_OPU1_9006161219 |X X . X X X X X X . . X X . . X . . . . . .|
XB3_ANA_OPU2_9006150949 |X . X . . . X . X . . . X . . X . . . . . .|
XB3_0NA_VAP1_9006161220 |X X X X X X X X X . . X . . . X . X . . . .|
XB3_ANA_VAP2_9006180917 |X X . X X X X X X . . X X . . X . . . . . .|
XB3_AAA_VAP3_9006141209 |. . X . . . . . . . . X X . . X . . . . . .|
XB3_AAA_VIC1_9006161219 |. X . . . X X X X . . X X . . X . . . . . .|
XB3_AAA_XBR1_9006150949 |X . . X X X X X X . . X X . . X . . . . . .|
XB3_0AN_SCU1_9006141109 |. X . . . . . . . . . X . . . . X X . X . X|
XB3_0AD_SCU1_9005091017 |. X . . . . . . . . . . . . . . X X X X X X|
XB3_0AD_SCU2_9006141208 |. X . . . . . . . . . X . . . . X X X . X .|
B2 CONFIG
---------
Total now 23 of 28.
| X = MCU involved in testing |
|--------------------------------------------|
|C C D D D F I M O U V V V V V X C D D D D T|
|T T S T T A N U P C A A I M R B C A A B B A|
Filename |L U T A B D T L U S D P C L G R U 0 1 0 1 G|
------------------------|--------------------------------------------|
XB2_AAA_CTL2_9004041359 |X X X X X . X X . X . X . . . . . . . . . .|
XB2_AAA_CTU1_9003271939 |. X . X X . . . . . . X . . . X . . . . . .|
XB2_AAA_DST1_9004120949 |X X X X X X X X X . . X . . . X . . . . . .|
XB2_AAA_DST2_9005081530 |X X X X X X X X X X . . . . . . . . . . . .|
XB2_AAA_DST3_9003301038 |X X X . . . . . . . . X . . . X . . . . . .|
XB2_AAA_DTA1_9003271941 |. X . X X X . X . . . X . . . X . . . . . .|
XB2_AAA_DTB1_9003271941 |. X . X X X . X . . . X . . . X . . . . . .|
XB2_AAA_FAD1_9004041359 |X . X . . X X X . X . . . . . . . . . . . .|
XB2_AAA_INT1_9004121633 |X X X . . X X X X X . X . . . X . . . . . .|
XB2_AAA_MUL1_9004041400 |X . X . . X X X . X . X . . . . . . . . . .|
XB2_ANA_OPU2_9004041530 |X . X . . . X . X X . . X . . X . . . . . .|
XB2_ANA_UCS1_9003301027 |X X X . . X X X . X . X . . . . . . . . . .|
XB2_AAA_VAP2_9004120959 |X X . X X X X X X . . X X . . X . . . . . .|
XB2_AAA_VAP3_9003272100 |. . X . . . . . . . . X X . . X . . . . . .|
XB2_AAA_VIC1_9004041402 |. X . . . X X X X . . X X . . X . . . . . .|
XB2_AAA_XBR1_9004041544 |X . . X X X X X X . . X X . . X . . . . . .|
XB2_AAD_SCU1_9004091439 |. . . . . . . . . . . . . . . . X X X X X X|
XB2_0AD_SCU1_9005081530 |. X . . . . . . . . . . . . . . X X X X X X|
XB2_0AD_SCU2_9004041720 |. X . . . . . . . . . X . . . . X X X . X .|
XB2_0AA_CTU1_9003281218 |. X . X X . . . . . . X . . . X X . . . . X|
XB2_0AA_DST1_9004071435 |X X X X X X X X X . . X . . . X . X . . . .|
XB2_0AA_DTA1_9004071437 |. X . X X X . X . . . X . . . X . X . X . .|
XB2_0AA_DTB1_9003290929 |. X . X X X . X . . . X . . . X . X . X . .|
Key to filename
---------------
XB1_2VD_CTU1_9002141059
| | | |
| | | ------> Date stamp to identify file revision. Two digits
| | | each for year, month, date, hour, minute.
| | ------> Target of test file and file number. First three characters
| | identify an MCU or board. The fourth character is a file
| | count for the target, starting with 1.
| -----> Each character describes applicability of test file to a system
| option.
| #1: Specifies which CPU port this test can be used on.
| Values are 0, 1, 2, 3, or A for all.
| #2: Specifies presence of VBOX option on CPU. Values are
| V - VBOX must be installed
| N - VBOX not installed
| A - All systems, presence of VBOX does not matter
| #3: Specifies presence of DA1 and DB1 MCUs on SCU. Values are
| D - Optional MCUs must be installed
| N - Optional MCUs not installed
| A - All systems, presence of optional MCUs does
| not matter
-----> System configuration. Will eventually match RM document.
XB1 represents initial pilot configuration.
XB1_2VD_CTU1_CTMV_9002141059
|
------> Additional target information when the target is an
individual MCA.
Files with this longer filename are no longer being generated and
will be phased out as they are replaced with newer files.
|
| 78.11 | 9000 memory problems | KERNEL::WRIGHTON | No , it's meant to work like that ! | Mon Jul 30 1990 10:59 | 56 |
|
**************************************************************************
DIGITAL EQUIPMENT CORPORATION CONFIDENTIAL
------------------------------------------
F O R I N T E R N A L U S E O N L Y
***************************************************************************
TITLE:VAX 9000 no usable memory in System.
DATE: 13 July 1990
AUTHOR: Tom Collentine TD #: 000342
DTN: 297-4749
ENET: MRCSSE::TCOLLENTINE CROSS REFERENCE #'s:
DEPARTMENT: HIGH-END SYSTEMS CSSE (PRISM/TIME/CLD#'s)
INTENDED AUDIENCE: PRIORITY LEVEL: 1
(U.S./EUROPE/GIA) (1=TIME CRITICAL,
2=NON-TIME CRITICAL)
=====================================================================
PROBLEM:
During error recovery, or memory (BIST) built in self test,
or any other event that causes clocks to be turned off and
on, a small probability exists that the memory refresh cycle
will be briefly stopped. This causes memory to become
corrupted.
The resulting SBE and DBE errors cause a large portion of
memory to get mapped out as bad and the system will not
reboot.
During a subsequent initialization of the Kernal the
console will display the following message.
[Initializing memory subsystem]
CLI-E-NOMEMORY, there is no usable memory in this system
check the MMU handshake lines. Specify a bank mask to override the
default
[saving state of CPUs and SCU for error recovery]
[Initializing IO subsystem]
Workaround:
Use the SHOW MEMORY /DEFECT_LIST /BAD_PAGES console commands
to examine the memory defect list.
Delete the memory defect list located in the top level
directory on the console disk [000000]DEFECT_LIST.SYS and
reinitialize the system to create a new defect list.
Long Term fix:
In progress.
*** DIGITAL INTERNAL USE ONLY***
|
| 78.12 | scan problems | KERNEL::WRIGHTON | No , it's meant to work like that ! | Mon Jul 30 1990 11:01 | 79 |
|
**************************************************************************
DIGITAL EQUIPMENT CORPORATION CONFIDENTIAL
------------------------------------------
F O R I N T E R N A L U S E O N L Y
***************************************************************************
TITLE: Scan Verification failures during Kernal Initialization
DATE: 13 July 1990
AUTHOR: Tom Collentine TD #: 000340
DTN: 297-4749
ENET: MRCSSE::TCOLLENTINE CROSS REFERENCE #'s:
DEPARTMENT: HIGH-END SYSTEMS CSSE (PRISM/TIME/CLD#'s)
INTENDED AUDIENCE: PRIORITY LEVEL: 1
(U.S./EUROPE/GIA) (1=TIME CRITICAL,
2=NON-TIME CRITICAL)
=====================================================================
9000 System Scan verification failures and ring data corruption.
OVERVIEW:
During Kernal Initialization the Siteinit.cmd file uses
logicals defined in Sitespecific.cmd to configure the VAX
9000 system. This file must be edited to reflect the correct
9000 hardware configuration to allow a complete error free
initialization.
PROBLEM:
During the Kernal initialization by the Service processor the
Scan controller may display errors as follows.
%SCM-E-SCMVERIFY, scan verification failure - ring data corrupted
Solution:
This may be due to improper setup of the sitespecific.cmd
file.
Edit the Sitespecific.cmd file contained in the [sysexe] area
of the console disk to reflect the 9000 system hardware
configuration installed.
DEFINE/SYSTEM SYS$CPU_MASK 1
This is a mask of CPUs present, for a uniprocessor this mask
is set to 1
DEFINE/SYSTEM SYS$VBOX_MASK 1
This logical is a mask of CPUs with a VBOX, for a
uniprocessor with a VBOX this mask is set to a 1.
DEFINE/SYSTEM SYS$ICU_MASK 3
This logical is a mask of ICUs present with a fully
configured SCU this logical is set to 3.
DEFINE/SYSTEM SYS$XJA_MASK 1
This is a logical mask of XJA's present, for a uniprocessor
with 1 XMI backplane this logical is set to 1.
DEFINE/SYSTEM SYS$MMU_MASK 1
This logical is a mask of MMUs present with a fully
configured SCU this logical is set to 3.
After making any necessary changes to the Sitespecific.cmd
file execute the command file so that the new logicals are
defined before initializing the system again.
*** DIGITAL INTERNAL USE ONLY***
|
| 78.13 | alpha particles | KERNEL::WRIGHTON | No , it's meant to work like that ! | Mon Jul 30 1990 11:02 | 63 |
| From: 17519::SHORTT "John Shortt / Ed Services / DTN: 266-4594 25-Jul-1990 1052" 25-JUL-1990 15:58:27.28
To: @9K,@THEORY
CC: JOE
Subj: alpha particles
Folks, it is very important that we drive this to conclusion very quickly. If
we cannot solve the Alpha particle problem quickly then we are into a huge ECO
trying to redo the MCUs with new designs. Perhaps Murali ought spearhead the
introduction criteria for the new encapsulant and drive it thru Motorola.
Perhaps Bob Steele can join forces with Murali. In any event this has to be
program managed. Timing is so very crucial...
Any ideas...
******
There are 3 encapsulants which at the present time Motorola has no serious
reservations about in terms of their physical properties. They are in order
of preference:
1. Hokuriku Toryo 8107
2. Hokuriku Toryo 8101
3. Amicon 1047
All of these are presently available as mechanical and live samples for UCF to
evaluate. The emissivity of the Hokuriku 8107 has been determined by our
standard measurement process, done by Spectrum Sciences, to be 10e4 better than
the present encapsulant, Ablestyk 69-5. 8101 is expected to be similar. The
1047 has not been measured but is silicone based and generally these materials
are very low.
By the end of this week we should have a pretty good idea which could meet the
UCF requirements. If none do, there are 3 additional encapsulants being
evaluated at Motorola.
In yesterday's phone conference to Motorola the question was asked if we all
agreed that a suitable encapsulant was available amongst the present candidates
(primarily the amongst the first 3) how long would it take to get it into
production for all product. There carefully considered reply:
1. They must be insured an adequate level of material for production purposes.
The Hokuriku products, being from Japan, could present problems. Since these
are promising, Motorola will look into this immediately.
2. They must finish completely the OLB solderability studies as different
cure profiles are used than the present encapsulant. In particular the
Hokuriku products have a longer cure cycle. No time was given for this
activity. This will be asked for on Tues.
3. Given the answers to 1 and 2 were favorable they would need a pilot run of
a month before cutting it in across the board. During this month they could
do our most sensitive devices, MULX and DIVX. When queried about doing some
representative devices to be sure experince was gained with all sizes of
chips, they said they would investigate.
The reasons given for the need to do the one mont pilot was to insure that all
the wrinkles had been worked out of the process before large scale commitment.
They said that the encapsulant process was still being stabilized and the
wholesale introduction of an entirely new encapsulant before the bugs were
worked out could bring the entire line down.
|
| 78.14 | rev C1 | KERNEL::WRIGHTON | No , it's meant to work like that ! | Mon Jul 30 1990 11:05 | 167 |
| From: 17519::SHORTT "John Shortt / Ed Services / DTN: 266-4594 25-Jul-1990 1051" 25-JUL-1990 15:58:48.89
To: @9K,@THEORY
CC: JOE
Subj: 9000 status
MCA STATUS FOR KERNEL CONFIGURATION C1
MCASTATUSC1.MEM
7/18/90
JURGEN
MCU MCA PROCESS TO MOT FROM MOT
=== === ======= ====== ========
VAP
VAPO.F1 Done Done Avail.
CCSQ.H1 Done Done 8/22
CTU
CTMA.D1 Done Done Avail.
CTMV.L1 Done Done 8/6
CCU
CTLA.D1 Done Done 8/29
CTLB.D1 L.B. 7/25 9/8
CTLD.D1 L.B. 7/25 9/8
TAG
ADRX.D1 L.B. 7/25 9/8
DAX
DSXX.C1 Done Done 8/29
JDCX.C1 Done Done 8/29
DBX
DSXX.C1 Done Done 8/29
MMCX.D1 Done Done Avail.
or E1* D.S. 7/18 May not be needed
Process:
D.F.. Designing a fix for problem
L.B. Loopback Process, i.e. SID Synthesis, Auto Placement, Auto Routing
T.F. Timing Fix resulting from Timing violation with new layout
D.S. Design Services, manually fixing unroutes, Rules Checking
F.C. Final Checking and Sign-off
TO MOT = Back from D.S. plus 2 days
Notes:
* Depends on decision which way to solve the REQ_STEP problem
Bug Descriptions:
=================
MBOX VAP VAPO.F1 MAX INSTRUCTION SEQUENCE MISMATCH (MEDIUM
LIKELYHOOD TO OCCUR IN REAL APPLICATIONS)
VAP CCSQ.F1 FOR HIGH I/O LOADS, SINGLE CYCLE VULNERABILITY
TO RETIRE REQUESTS OUT OF ORDER
VAP CCSQ.H1 CACHE SWEEP BUG, CACHE SBE RECOVERY BUG
CTU CTMA.D1 CACHE SWEEP BUG
CTU CTMV.L1 CACHE SWEEP BUG
JBOX DBX MMCX.D1 REPORTING SBEs (THAT OCCUR AT HIGH RATE) TO SPU
SLOWS DOWN MEMORY ACCESS
TAG ADRX.D1 CPU AND SCU CLOCKS MUST BOTH BE TURNED OFF
DURING ERROR RECOVERY, VMS CAN'T DEAL WITH
ALL POSSIBLE TYPES OF RESULTING I/O TIMEOUTS.
DAX,DBX DSXX.C1 - SAME AS ABOVE -
CCU CTLA.D1 - SAME AS ABOVE -
CCU CTLB.D1 - SAME AS ABOVE -
CCU CTLD.D1 1. SPU POWER OK SCAN LATCHES CAUSE SCAN TO
UPSET THE XJA IF THE SCU MCUS ARE
BROADCAST SCANNED, WHICH IS REQUIRED FOR
MEMORY SINGLE STEP.
2. SPU INTERFACE HANGS IF SPU READS MEM AND
GETS DBE.
DISABLING A PARITY CHECK AVOIDS THIS.
3. SOME CHANCE OF SPU INTERFACE HANGING IF
SPU IS POWERED OFF AND MEM HAS ECC EVENT.
4. LOGIC WHICH HANDLES SPU ERRORS REDEFINED.
DBX JDCX.C1 2 LATCHES MISSING CREATES POTENTIAL WORST CASE
TIMING PROBLEM. NEW PROGRAMM. DELAY PROMS IN
MCM CORRECTED PROBLEM IN LAB SYSTEMS
PHASE IN CHIPS (CONFIG.C2)
===================================
BEST CASE
CHIP MCU STATUS AVAIL. STATUS
---- ----- ------ ------- -------
VMLB-C1 VML @MOTO ENG. DEMAND FILLED
VFPK-C1 VAD @MOTO ENG. DEMAND FILLED
USQB-C1 INT @MOTO ENG. DEMAND FILLED
USQA-D1 INT @MOTO ENG. DEMAND FILLED
ISSC-E1 CTL @MOTO ENG. DEMAND FILLED
OSQA-F1 OPU @MOTO 6 DUE TO SHIP 7/31
Distribution:
nm%wldwst::jmcelroy
nm%wldwst::harika
nm%hyend::hakala
nm%hyend::boldeia
nm%hyend::j_sharma
nm%milkwy::lkelly
nm%hpstek::paderson
nm%hpstek::desantis
nm%hpstek::pasco
nm%hpstek::haller
nm%hyend::bhildick
nm%hyend::pcastellanos
nm%AQUA::DELAHUNT
nm%aqua::MCKEEN
nm%aqua::HETHERINGTON
nm%aqua::MURRAY
nm%aqua::BEAVEN
nm%aqua::pratt
nm%aqua::evans
nm%aqua::salett
nm%AQUA::fossum
nm%aqua::paternoster
nm%aqua::sozio
nm%aqua::schullman
nm%btovt::glover
nm%hyend::beck
nm%mrcsse::genova
nm%hyend::tata
nm%gwyned::zia
|
| 78.15 | kaf blitz | KERNEL::WRIGHTON | No , it's meant to work like that ! | Mon Jul 30 1990 11:13 | 82 |
|
Name of this document:VAX 9000 KEEP ALIVE FAILURES DURING ERROR RECOVERY
Author:Tom Collentine
Location:MR02-3/5E
DTN:297-4749
Author's Node:MRCSSE
Author's organization:HIGH-END SYSTEMS CSSE
Intended audience for this document:All Customer Service Engineers supporting
the VAX 9000 Systems.
Brief description of this document:
Date document submitted:25-July-1990
Date readers must receive document:26-July-1990
-----------------------------------------------------------------------------
+---------------------------+
| | | | | | | |
| d | i | g | i | t | a | l | TIME DEPENDENT CASE
| | | | | | | |
+---------------------------+
TITLE:VAX 9000 KEEPALIVE FAILURES DURING ERROR RECOVERY
DATE: 25 July 1990
AUTHOR: Tom Collentine TD #: 000350
DTN: 297-4749
ENET: MRCSSE::TCOLLENTINE CROSS REFERENCE #'s:
DEPARTMENT: HIGH-END SYSTEMS CSSE (PRISM/TIME/CLD#'s)
INTENDED AUDIENCE: PRIORITY LEVEL: 1
(U.S./EUROPE/GIA) (1=TIME CRITICAL,
2=NON-TIME CRITICAL)
=====================================================================
OVERVIEW:
MBOX hardware cache sweeps should be disabled for Revision B
VAX 9000 CPUs.
PROBLEM:
Keepalive failures may occur during error recovery due to a
problem with MBOX hardware Cache Sweeps.
Erroneous MBOX Parity errors will be set in the Error log
entry along with the real error.
Workaround:
To disable MBOX hardware cache sweeps edit the console file
[SYSEXE]SITEINIT.CMD and insert the following command.
"DEPOSIT VAP.CCSQ.JCON.NO_ERROR_SWEEP_H 1"
This will disable the hardware sweeps. Microcode version 315
and later will simulate Cache Sweeps in Microcode.
Console command "SHOW STRUCTURE ECS" will display the EBOX
Microcode revision.
Long Term fix:
Console revision BL10.3 did not contain this required change.
Future revisions of the console software supporting revision
B CPUs should reflect this change.
*** DIGITAL INTERNAL USE ONLY***
|
| 78.16 | boot blitz | KERNEL::WRIGHTON | No , it's meant to work like that ! | Mon Jul 30 1990 11:20 | 89 |
|
Name of this document:VAX 9000 may fail to boot after VMS 5.4-4HW install.
Author:Tom Collentine
Location:MR02-3/5E
DTN:297-4749
Author's Node:MRCSSE
Author's organization:HIGH-END SYSTEMS CSSE
Intended audience for this document:All Customer Service Engineers supporting
the VAX 9000 Systems.
Brief description of this document: VAX 9000 may fail to boot after VAX/VMS
T5.4-4HW installation.
Date document submitted:24-July-1990
Date readers must receive document:24-July-1990
-----------------------------------------------------------------------------
+---------------------------+
| | | | | | | |
| d | i | g | i | t | a | l | TIME DEPENDENT CASE
| | | | | | | |
+---------------------------+
TITLE:VAX 9000 BOOT PROBLEM AFTER VMS T5.4-4HW INSTALLATION.
DATE: 24 July 1990
AUTHOR: Tom Collentine TD #: 000349
DTN: 297-4749
ENET: MRCSSE::TCOLLENTINE CROSS REFERENCE #'s:
DEPARTMENT: HIGH-END SYSTEMS CSSE (PRISM/TIME/CLD#'s)
INTENDED AUDIENCE: PRIORITY LEVEL: 1
(U.S./EUROPE/GIA) (1=TIME CRITICAL,
2=NON-TIME CRITICAL)
=====================================================================
Problem:
After upgrading to VMS T5.4-4HW the VAX 9000 System will not
reboot if the system is booted over the CI.
The problem is with the primary bootstrap program VMB9AQ.EXE
that is copied to the console disk during the VMS build
procedure.
This is VAX 9000 Primary Bootstrap, Version V1.0-11U12
Workaround:
Remove or rename VMB9AQ.EXE on DISK$HARD:[USERFILES] so that
the previous older version of VMB, released with VMS T5.4-4GE
of VMS is used.
This is VAX 9000 Primary Bootstrap, Version V1.0-11U12.1
In addition to the version numbers, the new VMB can be
identified as it is one block larger than the older version.
VMB9AQ.EXE;4 115 31-MAY-1990 15:19:57.00 !Old
VMB9AQ.EXE;5 116 11-JUL-1990 12:58:14.00 !New
Long Term fix:
This problem with VMB does not affect VAX 9000 systems that
are booted from a KDM70 disk controller and the above action
is not required.
*** DIGITAL INTERNAL USE ONLY***
|
| 78.17 | XJA Diagnostic Failures | KERNEL::WRIGHTON | No , it's meant to work like that ! | Mon Jul 30 1990 18:48 | 201 |
|
TITLE:VAX 9000 XJA DIAGNOSTIC FAILURES
DATE: 30 July 1990
AUTHOR: Tom Collentine TD #:
DTN: 297-4749
ENET: MRCSSE::TCOLLENTINE CROSS REFERENCE #'s:
DEPARTMENT: HIGH-END SYSTEMS CSSE (PRISM/TIME/CLD#'s)
INTENDED AUDIENCE: PRIORITY LEVEL: 1
(U.S./EUROPE/GIA) (1=TIME CRITICAL,
2=NON-TIME CRITICAL)
=====================================================================
OVERVIEW:
The XJA is a interface adapter between 9000 System Control
Unit (SCU) and the XMI bus. The XJA is preliminary tested by
three diagnostics.
EWCLD - XJA Add-On Selftest Level 4 Diagnostic
EWCLD is written in Intel 8096 Assembly language. EWCLD is
contained in EEPROM on the XJA module and is executed
automatically during the power up phase of the XJA, and
during any XJA Node Resets. EWCLD can be executed manually
through commands issued by a terminal connected to the
terminal port on the XJA module.
EWCLA - XJA Level 4 Diagnostic
EWCLA is written in Macro assembly language. The program is
loaded form the [UCODE] area on the console disk into system
memory when invoked by the TEST/XJA command. This implies
that the Vax Hardcore exerciser should be run successfully
prior to running EWCLA. A brief description of the tests
EWCLA performs is appended to the end of this document.
EVCLB - XJA Level 3 Repair level Diagnostic
EVCLB is a macro diagnostic and runs under the diagnostic
supervisor. EVCLB performs similar tests as described in
EWCLA at the end of this document. In addition EVCLB provides
error call out and expected and received data.
PROBLEM:
EWCLD the powerup self test diagnostic may fail. The failure
may occur in any revision XJA C1, C2, C3. The failures
appears to happen regularly when a CIXCD is in slots 4 or C
of the XMI backplane.
Booting through the XCD from these slots is not usually
possible as VMB/VMS invokes node reset many times during the
boot process. There is also a problem with some XJAs failing
self-test intermittently regardless of an XCD.
Workaround:
Do not configure CIXCDs is slot 4 or C of the XMI bus.
Long Term fix:
Revision D of the XJA.
PROBLEM:
Version 1.x of EWCLA may fail. Test and subtests may vary. An
example follows;
>>>TEST/XJA:0
%CLI-E-XJAFAIL , XJA selftest version 1.1 on XJA 00 has failed
Subtest number 2
Module number: 20
Failing PC: 000007BC
>>>Exam R0
G 00 07bc0214
^ ^ ^_ (Module Number)Subtest number in Decimal
| |_(Subtest #) TEST Number
|_PC
Workaround:
EVKAA The VAX Hardcore diagnostic should be run successfully
before running EWCLA (TEST/XJA). Verify a suspected XJA
failure by running EVCLB before replacing any hardware.
Long Term fix:
Fixed in a future release of EWCLA possibly version 1.3.
PROBLEM:
EVCLB may fail test 1. EVCLB checks the AOST register and
will display a failure if the AOST has failed. Be aware this
failure may be related to the problem listed above under
EWCLD.
Also
EVCLB may fail test 2 intermittently. An example follows;
******** XJA Functional Diagnostic - ZZ-EVCLB - 1.5 ********
Pass 384, test 2, subtest 10, error 2 27-JUL-1990 07:58:45.15
Hard error while testing XJA0: Octaword read lock/Write
unlock failure(s)
1)Unexpected XJA Error Interrupt when attempting to lock
Location 6640 - 667F, just above locked locations 6600 -663F
Workaround:
DO NOT use the above test failures to indict as faulty, and
replace any defective hardware in the VAX 9000.
Long Term fix:
In a future release of EVCLB, possibly V1.8, the test 1
failure will display a AOST failure as a soft failure.
The test 2 failure will be fixed in a future release of EVCLB
possibly V1.8.
Here is a brief description of the tests EWCLA performs.
MODULE 0 (A.K.A test)
This is the initialization section. It is started at
0(X) by the Service Processing Unit or Console operator after
R0 is loaded with the information concerning which XJA(s)
exist on the system, and R1 for the passcount and Test(s) to
execute. This section will then initialize all the XJA
register address locations depending on which bit in R0 is
set. If bit 0 is set, XJA0 is tested. If bit 1 is set, XJA1
is tested, etc. up to bit 3. Once all the XJA's have been
tested, this section then executes a CPU halt. The SPU can
then examine the contents of R0 through R3 for the test
results of XJA0 through XJA3 respectively, and use the
results accordingly (clear if that XJA passed, failure
information if it failed).
MODULE 1:
This module contains the code to check the initial state of
the XJA after Powerup Reset, pattern tests for all XJA
registers that are write and readable, and checks the Powerup
Interrupt and data returned.
MODULE 2:
This module provides code to fully check the operation of the
XJA Force Command Register (FCMD), both defined and undefined
commands.
MODULE 3:
This module contains the test code to check the start- ing
and memory size fields.
MODULE 4:
This module provides test code to check the four XJA IDENT
registers - IDENT4, IDENT5, IDENT6 and IDENT7.
MODULE 5:
This module provides test code to check the XJA Error Summary
Register.
MODULE 6:
Parity Error Insertion Test
XCI_P[0] - XCI_P[2] C/A cycle Parity Error tests
XCI_P[0] - XCI_P[2], data cycle Parity Error Tests
JXDI_P[0] - JXDI_P[1], cycle 0,1,2 Parity Error Tests
MODULE 7:
DMA Pattern, Exercise and Error Test
DMA Pattern test
Multiple DMA exerciser
*** DIGITAL INTERNAL USE ONLY***
|
| 78.18 | VMS 5.4 Field Test letter | KERNEL::WRIGHTON | No , it's meant to work like that ! | Tue Jul 31 1990 09:27 | 145 |
|
DIGITAL
VMS Version 5.4 Early Hardware Support
Customer Letter
AV-PCJPC-XE
Digital is pleased to provide Field Test Version 5.4 of the VMS
operating system. Because this is a field test kit, you will
receive at least one media update and the complete Version 5.4
documentation set at no charge, when they become available.
Please apply any media updates shortly after you receive them.
NOTE
Use of this VMS media and documentation kit is subject
to the terms and conditions of your field test agreement
letter. You must sign that letter and return it to Digital
before using this media and documentation kit.
Contents of This Kit
Enclosed are two TK50 tape cartridges or three magnetic tapes
that contain VMS Field Test Version 5.4 software. Also included
is the following field test documentation:
o VMS RTL Mathematics (MTH$) Manual
o VMS Volume Shadowing Manual
o VMS Debugger Manual Supplement
o VAX MACRO and Instruction Set Reference Manual Supplement
o VMS Version 5.4 Upgrade and Installation Manual
o VMS Version 5.4 Release Notes
o VMS Version 5.4 New Features Manual
o VMS Device Support Manual
o VMS Upgrade and Installation Supplement: VAX 6000 Series
o VMS Upgrade and Installation Supplement: VAX 9000 Series
You might also receive VMS Version 5.3 documentation in your
kit.
Restrictions
Digital recommends that you observe the following restrictions
with VMS Field Test Version 5.4 software. Some of these restric-
tions may be removed as you receive software updates.
VAXft 3000 Systems
The VAXft 3000 series is not supported in a VAXcluster environ-
ment.
VAX 6000 Model 400 Vector Systems
o One vector unit is allowed per system.
o The CIXCD adapter is not supported.
o VAXclusters are supported if the following conditions are
met:
- The computers with vectors are running VMS Field Test
Version 5.4 software.
- The other nodes in the VAXcluster environment are running
VMS Version 5.3 or a subsequent dash release (5.3-n). For
information on operating in mixed-version clusters, refer
to VMS Version 5.4 Upgrade and Installation Manual.
o Standalone BACKUP might fail to boot, displaying the follow-
ing error message:
VAX/VMS Version X4GE-A3A Major version id = 1 Minor version id = 0
%EXECINIT-F-Insufficient nonpaged pool
2
To avoid this problem, perform a conversational boot and
increase nonpaged dynamic memory as follows:
>>> B/R5:1 CSA1:
SYSBOOT> SET NPAGEDYN 950000
SYSBOOT> CONTINUE
.
.
.
VAX 9000 Systems
Digital's VAX 9000 Program Office and your local account team
(Sales and Customer Services) will provide a detailed plan and
VMS Field Test Agreement that will include:
o Supported configurations
o Configuration or utilization restrictions
o Estimated schedule for lifting these restrictions
Reporting Problems
For VMS Field Test Version 5.4 support, consult your local Dig-
ital Customer Support Center or your local Digital representa-
tive.
�Digital Equipment Corporation. 1990. All rights reserved.
3
|
| 78.19 | RMS error when doing ANAL/ERR | KERNEL::WRIGHTON | No , it's meant to work like that ! | Tue Jul 31 1990 09:28 | 34 |
|
Abstract:
ANALYZE /ERROR reports an RMS RTB Error when reading a VAX9000 ERRLOG.SYS file
Problem:
When running the ANALYZE /ERROR (ERF) Utility under VMS Version 5.4-4GE on the
VAX 9000, the utility aborts with the following error.
%ERF-E-READERR, Error reading SYS$SYSDEVICE:[SYS0.SYSERR]ERRLOG.SYS
-RMS-F-RTB, 526 byte record is too large for users buffer
Analysis:
The ERF utility has run into a record in which it is not yet ready to
handle. It is passing to RMS that it has a maximum buffer of one size
and the records in the ERRLOG.SYS file is larger than that maximum size.
Workaround:
The use of the /OUTPUT qualifier appears to have an effect on this behavior
and may cercumvent the problem. Also using the /SINCE and /BEFORE qualifiers
may also be used to get around the affected record in the file. Depending
on the error records in the ERRLOG.SYS, the size of the file may have
an effect on this problem also and keeping the ERRLOG.SYS file to
less than 150 blocks may help.
Problem Status:
The problem is known to CSSE and VMS Engineering. It is not clear
at this time that the problem has been addressed by later releases
of VMS Field Test Software.
|
| 78.20 | VAX9000 Registration Procedure | KERNEL::WRIGHTON | No , it's meant to work like that ! | Tue Jul 31 1990 09:30 | 490 |
|
OVERVIEW:
Registration procedures for the VAX 9000 have been streamlined by
combining the hardware, software and SSP registration forms into one
form. All redundant information has been deleted.
The following will describe in detail the registration procedures for
VAX 9000 customers in the areas of:
- Access Number Assignment
- Registration Process
- SSP Registration
- Q-Numbers
- Hardware and Software Registration
PROCEDURE SUMMARY:
The VAX 9000 customers will be registered electronically. The
Software, Hardware and SSP Registration Forms have been combined into
one form for ease of use. The Install Team will supply the necessary
information to the CA. The CA will send the registration information
to the CSRA (Customer Service Revenue Administrator). The CSRA will
then send the registration to the Colorado Springs CSC electronically
for registration. When the customer has been registered an access
number will be mailed to the primary contact identified in the
customer's record.
The installation tech will complete an Install Verify upon installation
so information can be entered into the Smart database.
REGISTRATION TEXT:
In the third line of the customer registration text we will add the
following [25 VAX 9000 Customer]. This will allow reports to be ran
for VAX 9000 customers.
This text can also be used to identify of a VAX 9000 customer.
SOFTWARE Q-NUMBER:
The Q-numbers will be entered into the Parts File prior to registration
of the VAX 9000 layered products in the 2-5-2 format.
HARDWARE PART NUMBER:
The part number for hardware to be entered into the RSDS database in
the five-digit format for entry.
SSP:
The Site Service Processor registration will be incorporated in the
combined registration form.
EXCEPTIONS:
If a VAX 9000 customer calls the Atlanta CSC or the Massachusetts CSC
and requests registration, the customer name and number will be taken
and Colorado will call them back for registration.
If a VAX 9000 customer calls into a CSC for support on the VAX 9000 or
a layered product on the VAX 9000 and is not registered, the customer
should be given a temporary access number and given immediate support,
with a note that the customer is a VAX 9000 customer and should follow
the VAX 9000 call flow. The local office will then be notified.
PROCEDURES:
Customer Telephone Support is provided out of a Customer Support Center
located in Atlanta, Georgia (AT); Westboro, Massachusetts (MA); or Colorado
Springs, Colorado (CS); depending on the product type.
All customers entitled to Telephone Support Services must be registered
with the Customer Support Center (CSC) in Colorado Springs (CS) to receive
the entitled remedial/advisory services. The CSC/CS will update the CSC/AT
and CSC/MA for their supported products.
The benefits of combined VAX 9000 Electronic Registration are as follows:
o 24X7 availability
o Reduces telephone time for CSRAs and CSC Registration personnel
o Improves data accuracy (written vs. oral communications)
o Provides CSRAs with a single point for registration submissions
(eliminates registration at multiple CSCs)
o Provides an audit trail for CSRA and CSC Registration Personnel
o Provides CSRAs with an opportunity to centralize and streamline the
registration process.
o Eliminates redundancy in multiple registration forms
CSRA ROLE
CSRAs must register customers that are
entitled to Telephone Support Services
with the CSC/CS, ensuring that complete
and accurate registration information is
provided.
OTHER RESPONSIBLE PARTIES
Facility/District/Area Contact A CSRA identified to the CSC/CS as the
recipient for registration confirmations,
which are sent from the CSC/CS via
automated nightly dispatch.
Responsible for distributing the
confirmations to the CSRA who submitted
the registration. Registration
confirmations will be generated for every
new, modified or cancelled registration
that is submitted to the CSC/CS.
Customer Support Center
Colorado Springs (CSC/CS) Upon registration by the CSRA, the CSC/CS
mails a letter and information packet to
the customer, instructing them where to
call for support and providing them with
an access number(s) and DSIN access
information, including the DSIN password.
This packet includes the TYMNET and DSIN
brochures.
The CSC/CS updates the CSC/AT and the
CSC/MA on products which are supported out
of their centers.
The CSC/CS also provides the CSRA with a
registration confirmation via an automated
nightly dispatch process. Customer Support
Center/Atlanta (CSC/AT). The Customer
Support Center/Atlanta receives data on
registrations, de-registrations, and
changes for PL001 HPS ONLY products via
the SCORE feed and provides call screening
for those service products. CS Area
Administrative Representative
Area contact for CSA hotline inquiries.
CSRA 1. Complete the registration(s) via
electronic mail, utilizing the following
sequence:
o Obtain all required data
o Complete the combined Electronic
Registration Form illustrated in
Exhibit 1
o Send the electronic mail registration to
one of the following account addresses:
VAXmail: BSS::SPSREG
OR ALL-IN-1: SPSREG @ CXO
Please copy all registrations to:
CC: JUDY GHEA@ALF OR CSCOAC::GHEA_J
CSC/CS 2. Process and confirm the registration:
a. Update the CSC/CS database with
registration information provided by the
CSRA. Also, update the CSC/AT and CSC/MA
on products which are supported out of
their centers.
b. Issue access number(s) and DSIN password
for electronic mail registrations. Mail
the customer's access number and
temporary DSIN password directly to the
primary contact designated in the
customer record. Advise the customer to
change the password upon first DSIN
access. Include DSIN and TYMNET
brochures in the package, and send within
3 business days of the original receipt
of the registration from CSRA.
c. The electronic registration
confirmation(s) are generated via nightly
dispatch, and are received by CSRA the
next business day.
d. If there is no software to be registered,
the registration form will be routed
directly to hardware by the SPSREG.
CSC/CS 3. If information is complete and accurate,
CSC registration is finished.
Note: If information is missing, the CSC/CS
will electronically return the
incomplete/erroneous registration to the
originating CSRA for correction. The
information that requires
correction/completion will be identified.
EXHIBIT 1
REQUIRED DATA FOR SPS SPECIFIC INFORMATION
The following information must be completed prior to submitting an
electronic SPS contract/warranty registration to the CSC/CS:
1. System Serial Number - The hardware CPU serial number.
2. System (CPU) Type - CPU type (for example, 650T5, 8500, VS31V, etc.).
3. Servicing Cost Center - The cost center of the Unit delivering service.
4,5. Company Name and Address - The complete mailing information for the
customer location where the primary contact is located.
6,7. Primary Contact and Telephone Number - The person at the system site
responsible for CSC service and problem information control. Telephone
number must include area code.
8. Identify Operating System Software and Version (include service model
number).
9. Identify RD Console Type
10. Provide System Dial-in Phone Number
11. Provide Dial-in Baud Rate
12. Provide information on whether VAX Console System was installed.
13. Provide VAX Console System ID
14. Provide VAX Console System CPU Type
15. Provide information of VCS installation
16. Provide Account Name and password
17-21. If registering a cluster, please provide all information requested.
22. Provide System information and node name.
23. Provide information on tools installation for Spear and VAXsimPLUS.
24. SPS Specific Information
A. Software DEC Number - DEC number for contracts and hardware order
number for warranty.
B. Unit ID - Provide the Unit ID. NOTE: The Unit ID will continue to
be requested until a solution is implemented.
C. Provide supported products and model numbers.
D. Secondary Contact and Telephone Number - System site person who is
authorized to use the CSC service.
E. Tertiary Contact and Telephone Number
F. List additional contact names and full telephone numbers if
additional CSC contacts were purchased.
G,H. Warranty or Contract Effective Dates - Effective start and stop
dates of contract or warranty coverage.
I. Level of Service - Source of information is the warranty code and
service code. Identify BSS, SUIS, SSMS, DSS, DECsupport, or Basic
support. Please Note: Node Service does not include telephone
support, however, the CSC must be informed that a customer has
purchased this service when sold in a multiple CPU environment. In
this situation, provide the CSC/CS with the level of service (BNS or
DNS).
J. COMMENTS:
25. List Site Site Service Processor information.
VAX 9000 ELECTRONIC REGISTRATION DATA FIELDS
Is this Hardware only registration? Yes_____ No_____
1. System Serial Number:
2. CPU Type:
3. Servicing Cost Center:
4. Company Name:
5. Complete Site Address (City, State and Zip Code):
6. Site Contact Name (Primary Contact):
7. Site Contact Telephone Number (including Area Code):
8. Operating System Software and Version (include Service Model
Number):
9. RD Console Type:
10. System Dial-in Phone Number:
11. Dial-in Baud Rate:
12. VAX Console System Installed? (Yes/No):
13. VAX Console System ID:
14. VAX Console System CPU Type:
15. VCS Installed as the system single point of entry? (Yes/No):
16. If Yes, provide Account Name: Password:
17. Cluster Registration? (Yes/No):
18. Cluster ID (from SMART):
19. Cluster Name (DECnet alias):
20. Primary CPU:
Serial Number: CPU
Type: Node Name: Contract:(K/F)
21. List all Nodes on Cluster by:
Serial Number: CPU
Type: Node
Name: Contract: (K/F)
22. Is System Part of a Network? (Yes/No) System Node Name:
23: Tools Installed:
SPEAR (Yes/No) Version:
VAXsimPLUS (Yes/No) Version:
24: SPS Specific Information:
(A) Software DEC Number:
(B) Unit ID:
(C) List all SPS Supported Products (include SPS model numbers):
(D) Secondary SPS Customer Contact Name: Telephone Number:
__________________________________ ________________
(E) Tertiary SPS Customer Contact Name: Telephone Number:
_________________________________ ________________
(F) Additional Contacts Purchased Telephone Numbers:
_________________________________ _________________
_________________________________ _________________
_________________________________ ________________
(G) Warranty (Yes/No) Effective Date: End Date:
(H) Contract (Yes/No) Effective Date: End Date:
(I) Level of Service (i.e. BSS, SUIS, SSMS etc)
- Comments:
25. Site Service Processor (SSP) Specific Information:
- System Disk or Boot Device ID
REGISTRATION FLOW
INSTALL TEAM
|
|
|
|
CA
|
|
CSRA
|
|
|
CSC/CS------------------>SW--->HW---->SSP
|
_________________________
| | |
| | |
| | |
ELECTRONIC MAILS UPDATES
CONFIRMATION CUSTOMER CSC/AT
TO CSRA |
|
|
SCORE FEED
TO ATLANTA
INSTALL TEAM: Provides all registration information on the
combined registration form for the CA.
CSC/CS: Accepts registration and registers SW/HW and SSP.
Sends an electronic confirmation through a nightly
dispatch to CSRA with Access Number only. Mails
out within 3 days of receipt of registration form
the ACCESS #, DSIN Password, DSIN & TYMNET
Brochures.
|
| 78.21 | System Test procedure | KERNEL::WRIGHTON | No , it's meant to work like that ! | Tue Jul 31 1990 09:38 | 2142 |
|
Rom Based Diagnostics (RBD):
----------------------------
o Rom-based diagnostics will be run on the following SPU modules; the
Service Processor Module (SPM), the Scan Control Module (SCM), the
KFBTA Disk Contoller (AIO), and the DEBNT Network/TK50 Controller
(AIE). Enter the following underlined commands on the console terminal.
- SPM (T2051-00) RBDs:
SPM-ROM> D0/Tr/He ! SPM selftest
--------
SPM-ROM> D1/Tr/He ! SPM Memory test
--------
SPM-ROM> D4/Tr/He ! SPM EEprom test
--------
- SCM (T2050-00) RBDs:
SPM-ROM> Z 6 ! Select SCM RBD
---
T/R ! invoke parser
---
RBD6> D0/Tr/He ! SCM selftest
--------
RBD6> (^P) ! Do a CTRL^P to return to the SPM-ROM
prompt
- AIO (T1031-00) RBDs:
SPM-ROM> Z A ! Select AIO RBD
---
T/R ! invoke parser
---
RBDA> D0/Tr/He ! AIO selftest
--------
RBDA> (^P) ! Do a CTRL^P to return to the SPM-ROM
prompt
- AIE (T1034-00) RBDs:
SPM-ROM> Z 7 ! Select AIE RBD
---
T/R ! invoke parser
---
RBD7> D0/Tr/He ! AIE selftest
--------
RBD7> D1/Tr/He ! NI/TK diag
--------
RBD7> D2/C/Tr/He ! TK50 Functional exercisor
---------- Destructive test
o This completes the running of the required SPU RBDs on the SCM, SPM, AIE,
and AIO modules.
BOOT UP of VAXELN:
------------------
o Return to the SPM-ROM and reboot Vaxeln by entering the following commands.
RBD7> ^P (Control P)
--
SPM-ROM> UNJAM (perfrom UNJAM)
-----
SPM-ROM> B (Boot Vaxeln)
-
o VaxELN will now bootstrap, displaying the following header information:
Attempting system bootstrap
SPU/ELN Base Level 10, dd-mmm-yyyy hh:mm
FOR INTERNAL USE ONLY
EWBAB V10.x(x), loading SPU system software
EWBAA X10.x(xxx), node BTARID
[Initializing Power System]
%PEM-I-EXCEPTION, availabilty of BBU has transitioned
[Power system has initialized and reported ARIDUS configuration]
%PEM-I-EXCEPTION, Bias status has transitioned
%CLI-I-SCMINITR, initializing SCM firmware
%CLI-I-CDBLOAD, loading DUA50:[UCODE]Bx_CPU.CDB for unit(s) CP0
%CLI-I-CDBLOAD, loading DUA50:[UCODE]Bx_SCU.CDB for unit(s) SCU
Scope = %CPU0, Model = CPU, Revision = x
>>>
o A successful boot of VAXELN will display a Console prompt ">>>".
POWER UP OF SYSTEM:
-------------------
o Procede to Power up the CPU and SCU by performing the following steps:
- Make sure everyone is clear of the system and announce "Power ON".
- then type:
>>> SET POWER ON
------------
POWER UP OF SYSTEM: - Cont -
-------------------
o Verify that the complete power system is operating properly by observing
the status of buses and regulators for the SCU and CPU cabinets:
>>> SHOW POWER
----------
SCU/CPA ! Sample SHOW POWER display
BUS A BUS B BUS C BUS D
MARGIN NOM NOM NOM NOM
VOLTS +4.997V +4.997V -3.395V -5.202V
AMPS
REG 0 018.0A 017.0A 144.0A 148.0A
REG 1 ----- 018.0A 131.0A 154.0A
REG 2 ----- ----- 128.0A 146.0A
TOTAL 018.0A 035.0A 403.0A 448.0A
STATUS
GROUP OK OK OK OK
CROWBAR ----- ----- ----- OK
BUS OK OK OK OK
REG 0 OK OK OK OK
REG 1 ----- OK OK OK
REG 2 ----- ----- OK OK
BIAS 0 OK OK OK OK
CR BIAS 0 ----- ----- ----- OK
o The tolerance of the busses for the above should be within the following
limits:
MAIN BUS NOMINAL VOLTAGE TOLERANCE +/-
-------- --------------- -------------
A + 5.0 95mv
B + 5.0 95mv
C - 3.4 65mv
D - 5.2 98mv
o Verify that the system temperature and airflow conditions are acceptable.
>>> SHOW ENVIRONMENT ! Verify Airflow/Temperature Sensors
----------------
IOA CPA SCU ! Sample SHOW ENVIR display
AMBIENT
TEMP ------ ------ 26.00C
STATUS ------ ------ NOM
POWER (FAN 1)
TEMP ------ 37.03C 35.23C
STATUS ------ NOM NOM
SPEED CONTROL OK OK OK
FLOW CONTROL OK OK OK
LOGIC (FAN 2) CPU0 SCU
TEMP ------ 38.22C 38.26C
STATUS ------ NOM NOM
SPEED CONTROL OK OK OK
FLOW CONTROL OK OK OK
LOGIC (FAN 3) CPU1 MEMORY
TEMP ------ ------ 34.66C
STATUS ------ ------ NOM
SPEED CONTROL ------ ------ OK
FLOW CONTROL ------ ------ OK
>>>
VERIFICATION OF MCU CONSOLE CONFINGURATION DATA
-----------------------------------------------
o The following steps must be performed to provide a validation check of what
serial number(last 5 digits), Rev (letter), and MCU Part Number has been
loaded in the SPU. The resulting data should be compared against the actual
MCU and INFINET data. Discrepencies in data between the SPU, MCU barcode
label, or INFINET should be addressed as required.
>>> SENSE SYSTEM
------------
>>> SHOW CONFIG/KERNEL/CPU:0 ! View CPU MCU data in recorded in SPU
------------------------ ! Sample display follows:
CPU MCU TYPE NAME VERSION IDENTIFIER S/N
00 00 0004 FAD 000F ( 15) P1004-AA.E 0000000059
00 01 0003 MUL 0007 ( 7) P1003-AA.D 0000000058
00 02 000D CTU 000E ( 14) P1013-AA.J 0000000081
00 03 000B DTA 0003 ( 3) P1011-AA.C 0000000036
00 04 0009 VAP 000E ( 14) P1009-AA.J 0000000078
00 05 0007 XBR 000E ( 14) P1007-AA.J 0000000062
00 06 0008 OPU 0008 ( 8) P1008-AA.F 0000000032
00 07 0006 VIC 000C ( 12) P1006-AA.H 0000000023
00 08 0002 INT 000F ( 15) P1002-AA.E 0000000075
00 09 0001 DST 0008 ( 8) P1001-AA.F 0000000064
00 0A 000C DTB 0007 ( 7) P1012-AA.D 0000000040
00 0B 0005 CTL 0008 ( 8) P1005-AA.F 0000000067
00 0C 000A UCS 0004 ( 4) P1010-AA.K 0000000041
NOTE: These 2 commands will display all the MCUs, part numbers,
variation, revision and serial number. The revision listed
is just the alpha part (ie: E02 is displayed as E), and
the serial number will be the last 5 digits (ie: UC01400058
is displayed as 000000058). The alpha revision is the letter
following the part and variation (ie: P1004-AA.H where H is
the letter rev).
>>> SHOW CONFIG/KERNEL/SCU ! View SCU MCU data recorded in the SPU
---------------------- ! Sample display follows
MCU TYPE NAME VERSION IDENTIFIER S/N
00 000F CCU 0007 ( 7) P1015-AA.D 0000000075
01 0013 DA0 000F ( 15) P1019-AA.E 0000000041
02 0010 TAG 0007 ( 7) P1016-AA.D 0000000021
03 0014 DB0 000F ( 15) P1020-AA.E 0000000075
04 0013 DA1 000F ( 15) P1019-AA.E 0000000048
05 0014 DB1 000F ( 15) P1020-AA.E 0000000043
VERIFY THE SYSTEM ID (SID) MODULE SETUP:
----------------------------------------
o The SYSTEM ID (SID) module should be correctly configured for the System
under test. It can be verified by examining the SID register:
>>> E/I 3E
0E801xxx
o Make sure that the correct Plant Code, CPU Type, and Kernel Serial # have
been set. Refer to APPENDIX 5 for definition of the SID Register. If it is
incorrect check the SID module and reset when system is next powered down.
INSTALLATION OF SDD (Symptom Directed Diagnosis) TOOL:
------------------------------------------------------
o The SDD Tool is used to isolate intermittent faults in the VAX 9000 systems.
When a hardware error is reported to the SPU, the SPU in turn will generate
a error message which is sent to the SDD diagnostic. The SDD tool will then
perform single event analysis on the error information using a fault matrix
(created by other soft tools) to derive a syndrome entry. The syndrome entry
is then sent back to the SPU error handling software, logged, and used by
personnel to determine/isolate to the failing FRU.
SDD must first be installed and activated on the System's Console disk
upon initial powering up of the system.
o Perform the following steps to install SDD (Symptom Directed Diagnosis)
on the Systems' Console:
>>> SET COMMAND [SYSEXE]INSTALL
---------------------------
>>> INSTALL/EXPIRATION="dd-mmm-yyyy hh:mm" [SYSMAINT]EWKCA
------------------------------------------------------
^
|_______ The expiration date should be set for
(1) year from the current date/time
o Activate SDD on the system by typing the following:
>>> @[SYSMAINT]EWKCA
----------------
o Now verify that SDD (EWKCA) was properly installed and is running by typing:
>>> SHOW SYSTEM
-----------
- TBD
Ensure that the xxxxx process is displayed
BATTERY BACKUP (BBU) TEST
-------------------------
o Each VAX 9000 system contains within in its FXC or IOA cabinets (2) Battery
Backup Units (BBU's), H7231-Bs, which provide power to hold up the memory
in the SCU cabinet during a power fail. A BBU Test switch (2-position,
Momentary) is located in the FXC/IOA cabinets to allow for a manual check
to be performed in a simulated power fail condition. This is to ensure
that the BBUs and the assosciated power/logic function properly to hold
up memory as required.
o To perform this simulated power fail BBU test perform the following
sequence of steps:
- Observe on the SIP module (viewing it from the front of the cab) that the
(2) RED LEDs are on (constant).
- switch the BBU Test switch to the ON (right) position and hold. The small
RED LED to the RIGHT of the switch should be lit.
- Turn the POWER switch on the OCP panel to the OFF (0) position and now
observe that the following happens:
1) the two (2) RED LEDs on the SIP blink at a fast rate (10Hz) indicating
each BBU is in a discharge state.
2) a "310" is display on the OCP display LEDs,
3) The Bus B RIC 42 (H7389) in the SCU cabinet is on,
4) Both BUS B H7380 Converters B0 and B1 in the SCU cab are ON -
GREEN "MOD OK" LEDs lit
5) Ensure these conditions exist for approximately one minute then
release the BBU test switch
6) Restore power to the system by turning the OCP POWER switch to ON (1)
position.
o Allow the console to boot, SET POWER ON, verify system power is OK, and
then continue to HARDCORE TESTS section.
PERFORM HARDCORE TESTS (TEST/xxx):
----------------------------------
o Execution of the following Hardcore tests will now be performed by using
the "TEST/" command as shown below:
* NOTE: Some of these tests and/or their subtests currently do not work.
These are denoted by the "!" in front of the respective command line.
!>>> TEST/POWER/ON_ERROR=STOP/TRACE ! This doesn't work yet
------------------------------
>>> TEST/SCM/TRACE ! Verify SCM's BI interface
-------------- ! to the SPM
>>> TEST/SCAN/CPU=0/ON_ERROR=STOP/TRACE ! Hardcore scan - CPU chain
-----------------------------------
>>> TEST/SCAN/SCU/ON_ERROR=STOP/TRACE ! Hardcore scan - SCU chain
---------------------------------
>>> INIT/CLOCK ! Initialize the clocks
----------
>>> TEST/CLOCK/ON_ERROR=STOP/TRACE ! Execute clock system test
------------------------------
>>> TEST/MEM/ON_ERROR=STOP/TRACE ! Execute Memory tests
----------------------------
>>> TEST/STRUCTURE/CPU:All/ALL/ON_ERROR=STOP/TRACE ! Takes approx 1 Hr
----------------------------------------------
>>> TEST/STRUCTURE/SCU:All/ALL/ON_ERROR=STOP/TRACE ! takes +/- 35 mins
----------------------------------------------
RUN SCAN PATTERN DIAGNOSTIC (SCEPTER):
--------------------------------------
o The CPU and SCU MCUs/PMA will now be verified by running SCAN patterns and
verifying the expected results.The SCAN pattern files reside in the Console's
[SYSMAINT] directory and will be represented by a .SPDF file extension. To
invoke the SCEPTER SCAN Pattern Diagnostic type the following at the SPU
prompt (CONSOLE>):
>>> SET DEF [SYSEXE] ! set def to [SYSEXE] directory
----------------
>>> @SPDINIT CPU0 ! need to INIT both the CPU and the
-------------
>>> @SPDINIT SCU ! SCU when running SCU patterns
------------ ! System goes out to lunch if you don't
! so it's best to init both if you
! plan to run stuff on SCU and CPU
>>> SPD/SYSTEM/OUT=XB3_AAA_CTL2/LOG/DTP XB3_AAA_CTL2_9004041359
------------------------------------------------------------
! see appendix for .SPDFs... run all the files that are associated with the
! configuration you are testing
!
! .SPDF files are in the [sysmaint] directory
!
!
!
!NOTE: There is a problem with SPD right now , such that something goes out to
! lunch in the console/system , so that you get hundreds to thousands
! of errors on the first couple of tests.... if this happens to you,
! reboot the console and start all over with SPDINIT.
!
!
!
!
!
Following is what you will see on a successful run of a SPDF file:
SCAN PATTERN DIAGNOSTIC
REV 10.2.15(03)
Processing DUA50:[SYSMAINT]XB2_AAA_CTL2_9004041359.SPDF;1 has started.
File DUA50:[SYSMAINT]XB2_AAA_CTL2_9004041359.SPDF;1 has been opened.
Creation date: 4-Apr-90
Creation time: 14:47:54
Generated by: SPOTRAN: V1.27-28
%SPD-I-NOCNFGCH, Not checking HW revs or types.
Pattern set 0 contains 95 tests.
%SPD-I-NOPROBLM, No processing problems
. Processing DUA50:[SYSMAINT]XB2_AAA_CTL2_9004041359.SPDF;1 has finished.
If Failures are encountered during SPD testing:
>>> SPD/SYSTEM/OUT=XB3_AAA_CTL2/LOG/DTP XB2_AAA_CTL2_9004041359
-------------------------------------------------------------
Following is what you will see on when SPD detects a Pattern compare error
(PCE):
SCAN PATTERN DIAGNOSTIC
REV 15.02
Processing DUA50:[SYSMAINT]XB2_AAA_CTL2_9004041359.SPDF;2 has started.
File DUA50:[SYSMAINT]XB2_AAA_CTL2_9004041359.SPDF;2 has been opened.
Creation date: 4-Apr-90
Creation time: 14:47:54
Generated by: SPOTRAN: V1.27-28
%SPD-I-NOCNFGCH, Not checking HW revs or types.
Pattern set 0 contains 95 tests.
TEST 4 detected %d1 failures.
%d1 of these failures were new and
%d0 failures were detected prior to this test.
TEST 5 detected %d1 failures.
%d0 of these failures were new and
%d1 failures were detected prior to this test.
TEST 16 detected %d1 failures.
%d0 of these failures were new and
%d1 failures were detected prior to this test.
TEST 17 detected %d1 failures.
%d0 of these failures were new and
%d1 failures were detected prior to this test.
TEST 18 detected %d1 failures.
%d0 of these failures were new and
%d1 failures were detected prior to this test.
Failure total for DUA50:[SYSMAINT]*.spdf; is %d5
Drum rolls PLEASE!! ..... and the verdict IS....
ISO unit # 0 alias %BOARD_CPU was indicted by 1 failures.
ISO unit # 67 alias %BOARD_CPU.MCU_DST.MCA_DST0 was indicted by 1 failures.
ISO unit # 86 alias %BOARD_CPU.MCU_UCS was indicted by 1 failures.
ISO unit # 90 alias %BOARD_CPU.MCU_UCS.MCA_VCTC was indicted by 1 failures.
%SPD-I-NOPROBLM, No processing problems
. Processing DUA50:[SYSMAINT]XB2_AAA_CTL2_9004041359.SPDF;2 has finished.
Running SPD with failure isolation:
If you had a Pattern compare error see the following section, otherwise
continue with the next spdf file .
Failure Isolation with SPD
Run SPD as per test process.
/dtp/out=<spdf file name>.log
These qualifiers will create two outputs.
1- .log file containing the isolation information that
SPD was able to generate .
2- .dtp file contains scan mismatch information in the format
that MCU_FAILURE programs needs to convert the scan mismatch
info to actual MCU pins that feed that scan latch.
MCU_FAILURE will generate a <spdf file name>.fls file with
the pin info .
How to run MCU_FAILURE;
On your SUV do the following :
>>> define skivt 17.335
>>> copy <spdf file name>.dtp skivt::
This will copy your .DTP file to SKIVT , and automatically
submit it to the MCU_FAILURE program.... When MCU_FAILURE has finished
running your job , you will be notified with a broadcast message on
your SUV... (this takes 3-10 minutes to complete , so relax and read
a spec or something)
See frost::ud$1:[AQUA_DOCS] for a copy of the user guide for
MCU_FAILURE.
What to do with the .FLS file.
When you look at the .FLS file you will see :
!
! List of potentially faulty MCU's and MCU pins
! created by MCU_FAILURE V01.17-001 linked 18-APR-1990 04:08:10.99
! with command MCU_FAILURE/ISO MB1DIR:B4_UNI0 QUAD_PI XB3_AAA_XBR1_9004242226
Followed by many lines beginning with an ! , this shows what data files it used
to create your output....Noise .....
You want to go to the end of the file where is says :
"Detection points obtained from"
This is where the important info is .... The first section describes the actual
scan latches that detected the bit mismatches. The next section describes the
MCU's and MCU pins potentially responsible for the failures.
!
!
!
!
Detection points obtained from
SYBIL$DISK:[SYBIL.MCU]XB3_0AN_SCU1_9005041854.DTP;1 of 15-JUN-1990 10:17
1. 41_0945 417_037 DA014 "JDA0.E2638"
2. 41_0959 417_051 DA014 "JDA0.E4134"
3. 41_1007 417_099 DA014 "JDA0.E0218"
4. 41_1024 417_116 DA014 "JDA0.E0204"
5. 43_1063 434_102 DB013 "MMC0.E0518"
6. 43_1064 434_103 DB013 "MMC0.E0718"
7. 43_1080 434_119 DB013 "MMC0.E0916"
8. 43_1119 434_158 DB013 "MMC0.O178"
0 detection points encountered in more than one cycle.
8 cycles out of a total of 8 had failures.
17 potential fault sources were identified, and are listed below.
There appears to be more than one fault,
since there are no MCU's with a failure count of 8.
Total number of failure cycles, and most recent failure cycle,
sthat each MCU and MCU pin is potentially responsible for,
with equal failure counts sorted by MCU ring address or pin position,
and "upstream" fault tracing stopping at RAM's:
4 8 MCU 40_CCU05
4 8 2-250 O "CTLX_MMC0_M0CMD_H<4>"
2 6 4-154 O "CTLX_MMC0_M0CMD_H<9>"
2 6 4-158 O "CTLX_MMC0_M0CMD_H<10>"
4 4 MCU 41_DA014
1 2 2-200 I "XJA1_JDAX_DATA_L<1>"
1 2 2-202 I "XJA1_JDAX_DATA_H<1>"
1 1 2-246 I "XJA1_JDAX_DATA_L<0>"
1 1 2-247 I "XJA1_JDAX_DATA_H<0>"
1 4 2-264 I "XJA0_JDAX_DATA_L<1>"
1 4 2-266 I "XJA0_JDAX_DATA_H<1>"
1 3 3-035 I "XJA0_JDAX_DATA_L<0>"
1 3 3-036 I "XJA0_JDAX_DATA_H<0>"
4 8 MCU 43_DB013
4 8 2-052 I "CTLX_MMCX_M0CMD_H<4>"
2 6 2-068 I "CTLX_MMCX_M0CMD_H<10>"
2 6 2-106 I "CTLX_MMCX_M0CMD_H<9>"
!
! end of potential fault list -- 92 lines written
!
If MCU_FAILURE detects that there is a fault that is self contained
on one MCU it will have an * next to the MCU name.
It will also notify you if it thinks you have multiple faults
The next step would be to remove one of the MCUs and use a curve trace, multi-
meter or TDR to check the bumps on the MCU and then the pads on the planars to
see if you had any opens ...
Some general guide lines to help determine what to pull first:
1) if an MCU has an * . Pull that one first.
2) if there is an MCU with an * and other MCUs are also called out
there are multiple faults . try fixing one fault at a time.
3) If there are two MCUs called out without any * the fault
must be between a scan latch on one MCU and scan latches on
another MCU. If you suspect a bump to pad problem look at the
pin callout. Pins near the ends of the flex are more likely to have
problems than pins in the middle. Pull the MCU that has pin callouts
in these areas. If you suspect a problem in logic, pull the
MCU that has the most combinational logic between the MCU pins
and the scan latch.
4) If none of these techniques seem to be sea worthy just pull the
MCU that is called out first by SPD and MCU_FAILURE
VERIFICATION OF THE XJA, JXDI, and XBI+ :
-----------------------------------------
o The XJA will now be tested to verify its operation:
>>> SCU ! set scope to SCU
---
>>> SET CLOCK/SCU OFF ! Set SCU Clock OFF
-----------------
>>> TEST/JXDI=0 ! This may fail,
-----------
>>> TEST/JXDI=0 ! may have to run twice
----------- ! before working correctly
%CLI-I-TXJA, starting XMI adapter test
%TEST-I-XJATEST, Executing XMI adapter test 1
:
:
%TEST-I-XJATEST, Exectuing XMI adapter test 37
%CLI-I-TXJAEND, XMI adapter test complete
>>> TEST/JXDI=1 ! Doesn't work (if present)
-----------
>>> TEST/XJA=0 ! Runs EWCLA (XJA L4 diag)
----------
>>> TEST/XJA=1 ! (if 2nd XJA is present)
----------
o The following test will be invoked if a DWMBB (XBI+;XMI to BI) adapter is
installed in the System being tested. The DWMBB consists of a T2018-00 XMI
module connected by interbay cabling to a T1043 BI module in a BI Expansion
Cabinet.
o Type the following commands:
>>> TEST/XBI=0 ! (if present) Runs EWCMA,
---------- ! XBI+ Level 4 diagnostic
>>> TEST/XBI=1 ! (if present)
----------
RUNNING VAX MACROHARDCORE (EVKAA):
----------------------------------
o Run EVKAA, the VAX Macrohardcore Level 4 diagnostic, individually on each
cpu in the system. This will verify that the system can execute the in-
structions which are required in order to boot the VAX Diagnostic Super-
visor. Enter the following sequence of commands to get the system back to
a known state and then to invoke EVKAA:
>>> I/K/B ! Do an Initialization/Brief
-----
>>> LOAD [SYSMAINT]EVKAA ! load EVKAA from [SYSMAINT]
--------------------
>>> SET CPU x ! x = 0, 1, 2, 3
---------
>>> START/CPU=x 200 ! start & run EVKAA from address 200
--------------- ! on CPU x (x = 0, 1, 2, 3)
EVKAA...............end of Pass 1
After the first pass completes hit any key to continue the test.
EVKAA will now execute on CPU #0. Repeat the last command, /cpu=2,
if a second cpu is present.
o Allow EVKAA to run for (5) passes, then stop with a <CTRL P> command.
Then Halt it and rerun EVKAA on other CPUs which are present in the
system configuration by performing the above commands.
>>> HALT/CPU:x ! x = 0, 1, 2, 3
----------
BOOT VAX DIAGNOSTIC SUPERVISOR (EWSAA):
----------------------------------------------
o The VAX Diagnostic Supervisor (EWSAA), or VAX DS, will now be booted so
that standalone diagnostic testing can be performed. This will consist of
running the following level 3 VAX CPU Diagnostics :
EWSAA - VAX DIAGNOSTIC SUPERVISOR (VAX 9000)
EVKAQ - VAX Basic Instructions Exercisor I
EVKAR - VAX Basic Instructions Exercisor II
EVKAS - VAX Floating Point Instruction Exercisor I
EVKAT - VAX Floating Point Instruction Exercisor II
EVKAU - VAX Privileged Architecture Exercisor I
EVKAV - VAX Privileged Architecture Exercisor II
EWKAX - Kernel Architecture Diagnostic
EWKMP - Multi-port SCU Exercisor
EVCLB - XJA Diagnostic
EVKAG - VAX Vector Instructions Diagnostic I
EVKAH - VAX Vector Instructions Diagnostic II
o Boot the VAX Diagnostic Supervisor (EWSAA) by entering the following
commands:
>>> I/K/B ! Init/brief to get back to known state
-----
>>> B VDS ! invokes VDSBOO.CMD to boot VAX DS
-----
o The VAX DIAGNOSTIC SUPERVISOR will now boot up, displaying the following
header:
VAX DIAGNOSTIC SOFTWARE
PROPERTY OF
DIGITAL EQUIPMENT CORPORATION
***CONFIDENTIAL AND PROPRIETARY***
Use Authorized Only Pursuant to a Valid Right-to-Use License
Copyright, Digital Equipment Corporation, 1989. All Rights Reserved.
DIAGNOSTIC SUPERVISOR. ZZ-EWSAA- x.x-xxx xx-xxx-xxxx 11:11:46
DS>
CONFIGURE THE SYSTEM UNDER VDS:
-------------------------------
o Determine the configuration of the system and enter the appropriate
ATTACH commands for the CPUs and XJAs, or run the VAX Autosizer (EVSBA)
to automatically configure them. Use the following examples as a guide.
Individual ATTACH commands:
CPU:
DS> ATTACH KAWWW HUB KA0 0 N (CPU 0 without vector)
------------------------
^ ^ ^ ^
CPU | | |______Vector (Y/N)
| |________Physical CPU #
|___________Logicial name/cpu#
XJA:
DS> ATTACH XJA HUB XJA0 0 (XJA0)
---------------------
^ ^
| |________Physical XJA#
|___________Logicial name/Xja#
o Type the following command to select the Attached devices for testing.
DS> SEL All
-------
OR
o Use the VAX Autosizer Diagnostic (EVSBA) to automatically define the
System configuration by typing the following commands:
DS> RUN EVSBA ! Load and run the Autosizer
---------
DS> SHOW DEV ! Examine what the Autosizer has
-------- ! configured to select accordingly.
:
DS> SEL KAx,XJAx ! Select the appropriate CPUs/XJAs,
------------ ! don't select options at this point
CPU LEVEL 3 VAX DIAGNOSTIC TESTING:
-----------------------------------
o Load and run the CPU Kernel diagnostics as specified in the sequence below:
DS> LOAD EVKAQ !Vax Basic Instructions I
----------
DS> SET T,H !Set Trace and Halt-on-error flags
-------
DS> START/P:3 !Start EVKAQ and run for (3) passes
---------
DS> LOAD EVKAR !Vax Basic Instructions II
----------
DS> SET T,H
-------
DS> ST/P:3
------
DS> LOAD EVKAS !Vax Floating Point Instructions I
----------
DS> SET T,H
-------
DS> ST/P:3
------
DS> LOAD EVKAT !Vax Floating Point Instructions II
----------
DS> SET T,H
-------
DS> ST/P:3
------
DS> LOAD EVKAU !Vax Privileged Arch. Instructions
----------
DS> SET T,H
-------
DS> ST/P:3
------
DS> LOAD EVKAV !Vax Privileged Arch. Instructions
----------
DS> SET T,H
-------
DS> ST/P:3
------
! DS> LOAD EVCLB !XJA Adapter diagiagnostic
----------
! DS> SET T,H
-------
! DS> ST/P:3
------
CPU LEVEL 3 DIAGNOSTIC TESTING - CONT -
------------------------------
DS> LOAD EWKAX !Aqua. Kernal Exerciser
----------
DS> SET QUICK ! 1 pass - normal mode
---------
DS> SET T,H
-------
DS> ST/P:=3
-------
DS> CLR QUICK ! for Test 11 (power fail)
---------
DS> SET OPERATOR ! Valid flag ?????
------------
DS> ST/P=3
------
DS> LOAD EWKMP !SCU multiport diag.
----------
DS> SET T,H
-------
DS> ST/P:3
------
..Program: EWKMP.......
:
Number of minutes exercisor should run,...[(0),0-65536(D)] 5 <CR>
_
Number of seconds between reports,....[(0),0-65536(D)] 30 <CR>
--
o Now run Vector Level 3 Diagnostics if the System under test has a V-Box
installed (ie. VRG, VML, VAD):
DS> LOAD EVKAG !Vax Vector Instructions I
----------
DS> SET T,H
-------
DS> ST/P:3
------
DS> LOAD EVKAH !Vax Vector Instructions II
----------
DS> SET T,H
-------
DS> ST/P:3
------
o After completion of the Kernel diagnostics, the next step will be to
run Level 3 diagnostics on the XMI options.
XMI OPTION DIAGNOSTIC TESTING (LEVEL 3):
----------------------------------------
o The following sections describe the test requirements for each XMI option.
Refer to the appropriate sections based on the system I/O configuration.
********************************* IMPORTANT ********************************
When testing XMI Options using Loopbacks it is important to test each option
invidually (ie. No other loopbacks installed except for one on option under
test) to ensure proper installation/configuration of the option/module under
test to its corresponding I/O panel bulkhead. Refer to XCON for the designa-
ted module to I/O panel configuration.
******************************************************************************
KDM70 OPTION (T2022-00 and T2023-00 modules):
The KDM70 will always be present in the XMI backplane, either as part
of the system order or a KGM. In the case of multiple adapters, only
one adapter can be tested at a time. A RA60 and RA82 disk drive will be
used to verify each of the (8) ports on each KDM70.
** NOTE: Whenever using Disk Drives in the Systems Test Area please ensure
that heads are locked on RA82/RA81 drives and Disk Packs removed
on RA60 drives prior to moving these drives any distance. Also DO
NOT place anything (ie. tools, parts, etc) on top of these drives
as the RA60s are extremely susceptable to dust,foreign material,etc
getting inside the disk compartment.
o Attach the drive cable, from the RA60 drive, to one of the ports on
the KDM70 under test. Examine the Front of the RA60 Drive, making sure
it is spun up and ready. If not load a "Scratch" RA60 Pack and spin up.
o Attach the drive cable, from the RA82 drive, to one of the ports on
the KDM70 under test. Examine the Front of the RA82 Drive, making sure
it is spun up and ready.
o At the DS> prompt, attach/select the KDM70 under test and the RA60/82
drives. Refer to the examples below.
DS> ATTACH KDM70 XJA0 DUA A 5 (KDM70 in XMI #0, Slot 10, BR 5)
-------------------------
^ ^ ^ ^_______Bus Request = 5
| | |_________XMI slot #
| |____________Logicial name (second KDM = DUB,etc)
|_________________XJA#
DS> ATTACH RA82 DUA DUA0 (RA82 Unit #0)
--------------------
^ ^
| |____________Disk Logical name
|_________________KDM adapter
DS> ATTACH RA60 DUA DJA1 (RA60 Unit #1)
--------------------
^ ^
| |____________Disk Logical name
|_________________KDM adapter
XMI OPTION DIAGNOSTIC TESTING (LEVEL 3): - Continued -
----------------------------------------
KDM70 OPTION: - cont -
DS> SELECT ALL
----------
o Enter the following commands to run EVRLJ on the KDM70.
DS> LOAD EVRLJ
----------
DS> SET T,H
-------
DS> ST/T:1:2/P:3 ! Run Tests 1 and 2 only
------------
o If the KDM70 Option being tested was a KGM set then no additional port
testing is required. If there are additional KDM70s installed, then
procede to test them as above and verify all ports. If no other KDM70s
are installed, then procede to the "BI Option" or "Diagnostic Level 2"
test sections as applicable.
o Now move the RA60, RA82 drives to other (untested) ports on KDM70 and
restart the diagnostic by typing START <cr> at the DS> prompt. Repeat this
process (3) more timeBs until each port has been tested (8 ports/KDM70).
o Attach/Select any additional KDM70s for testing and repeat the
testing.
Note: If testing multiple KDM70 adapters, make sure to only
attach/select one at a time. (deselect all other KDM70s)
o If there are no other XMI options to test, refer to "BI options" for
BI option testing (if present) or exit the Diagnostic Supervisor and
refer to "Diagnostic Testing, level 2".
XMI OPTION DIAGNOSTIC TESTING (LEVEL 3): - Continued -
----------------------------------------
DEMNA OPTION (T2020-00):
The DEMNA will always be present in the XMI backplane, either as part
of the system order or a KGM module.
o Attach the AVS/Enet transceiver cable, located in the test area, to the
DEMNA bulkhead corresponding to DEMNA # 0. If multiple DEMNAs are installed
connect the DEMNA Transceiver loopback/test connector(12-22196-02), or a
H4080 loopback transceiver, to each DEMNA bulkhead one at a time during
testing.
NOTE: A DEMNA transceiver/loopback 12-22196-02 should be present for each
DEMNA option embedded. It is left in the loose-piece box of the
corresponding system cabinet (FXC, IOA, IOB), which it is installed
in, when not be used for testing purposes.
o At the DS> prompt, attach/select the DEMNA(s) to be tested. Refer to the
example below:
DS> ATTACH DEMNA XJA0 EXA0 5 (DEMNA in XMI #0, Slot 5)
------------------------
^ ^ ^
| | |________XMI slot #
| |____________Logicial name (second DEMNA = EXB0,etc)
|_________________XJA#
DS> SEL EXA0 ! select the DEMNA
--------
o Enter the following commands to run EVDYF on the DEMNA(s).
DS> LOAD EVDYF
----------
DS> SET T,H
-------
DS> ST/P:3
------
o The diagnostic will test each adapter and report a status when completed.
Make sure 0 errors were reported.
o If there are no other XMI options to test, refer to "BI options" for
BI option testing (if present) or Exit the Diagnostic Supervisor and
refer to "Diagnostic Testing, level 2".
XMI OPTION DIAGNOSTIC TESTING (LEVEL 3): - Continued -
----------------------------------------
CIXCD OPTION (T2080-00 Module):
o Place (2) CI loopback/attenuators on the CIXCD bulkhead(s), connecting
Path A Transmit -> Path A Receive and Path B Transmit -> Path B Receive.
o At the DS> prompt, attach/select the CIXCD(s)to be tested. Refer to the
example below.
DS> ATTACH CIXCD XJA0 PAA0 5 0 (CIXCD in XMI #0, Slot 5, CI Node #0)
--------------------------
^ ^ ^ ^
| | | |______CI Node # (ex. = CI Node 0)
| | |________XMI slot # (ex. = slot 5)
| |____________Logicial name (second CIXCD = PAB0,etc)
|_________________XJA#
DS> SEL PAA0 (Select CIXCD logical name to test)
--------
o Enter the following commands to run EVGAA, CI Functional Diagnostic Part 1,
on the CIXCD(s).
DS> LOAD EVGAA
----------
DS> SET T,H
-------
DS> SET EVENT FLAG 1
----------------
DS> ST/P:3
------
o The diagnostic will test each adapter and report a status when completed.
Make sure 0 errors were reported.
o Run EVGAB, CI Functional Diagnostic Part 2, using the following commands.
DS> LOAD EVGAB
----------
DS> SET T,H
-------
DS> ST/P:3
------
o The diagnostic will test each adapter, which has been selected, and reports
a status when completed. Make sure 0 errors were reported.
o If there are no other XMI options to test, refer to "BI options" for
BI option testing (if present) or Exit the Diagnostic Supervisor and
refer to "Diagnostic Testing, level 2".
XMI OPTION DIAGNOSTIC TESTING (LEVEL 3): - Continued -
----------------------------------------
DWMBB XMI-BI ADAPTER OPTION (T2018-00):
Test Setup:
o For each VAX 9000 system which has an embedded DWMBB XBIA module (T2018)
installed in the FEC's XMI bus the following steps most be performed:
o Attach a BI Expander cab with embedded KDB50, DEBNA, and DWMBB BI interface
if NO customer ordered BI Expander cabinet/configuration is present with
the order.
- Get BI Expander and place at rear of FXC/IOA/IOB cab of system under test
which contains DWMBB option to be tested.
- Power VAX 9000 system down and turn Main breaker to OFF.
- Ensure BI cab power is OFF and plug in its main power cord into the
appropriate bus bar "pigtail outlet".
- connect the XMI-BI set of (3) ribbon cables into XMI backplane slot that
the DWMBB option is configured in.
- now power up, boot the Console, and continue with the following
diagnostic testing.
>>> I/K ! Re-initialize system
---
>>> B VDS ! boot VAX Diagnostic Supervisor(EWSAA)
-----
VAX DIAGNOSTIC SOFTWARE
PROPERTY OF
DIGITAL EQUIPMENT CORPORATION
***CONFIDENTIAL AND PROPRIETARY***
Use Authorized Only Pursuant to a Valid Right-to-Use License
Copyright, Digital Equipment Corporation, 1989. All Rights Reserved.
DIAGNOSTIC SUPERVISOR. ZZ-EWSAA- x.x-xxx xx-xxx-xxxx 11:11:46
DS>
DS> ATTACH KAWWW HUB KA0 0 N (CPU 0 without vector)
------------------------
^ ^ ^ ^
CPU | | |______Vector (Y/N)
| |________Physical CPU #
|___________Logicial name/cpu#
DS> ATTACH XJA HUB XJA0 0 (XJA0)
---------------------
^ ^
| |________Physical XJA#
|___________Logicial name/Xja#
XMI OPTION DIAGNOSTIC TESTING (LEVEL 3): - Continued -
----------------------------------------
DWMBB XMI-BI OPTION ADAPTER OPTION: - cont -
o At the DS> prompt, attach/select the DWMBB options for test. Refer to
the example below.
DS> ATTACH DWMBB XJA0 DWMBB0 1 6 (DWMBB in XMI 0 - slot 1, BI slot 6)
----------------------------
^ ^ ^ ^ ^
DWMBB | | | |______BI node #
| | |________XMI slot #
| |_____________Logicial name/# (DWMBB)
|___________________XMI adapter
DS> SEL DWMBB0
----------
o Enter the following commands to run EVCME on the DWMBB(XBI+) options.
DS> LOAD EVCME
----------
DS> SET T,H
-------
DS> ST/P:3
------
o The diagnostic will test each adapter and report a status when completed.
Make sure 0 errors were reported.
o If there are no other XMI options to test, refer to "BI options" for
BI option testing (if present) or Exit the Diagnostic Supervisor and
refer to "Diagnostic Testing, level 2".
BI OPTION TESTING (LEVEL 3):
----------------------------
o Refer to the appropriate sections based on the system I/O configuration.
o If this a KGM BI cabinet with KDB50 Option and DEBNA Options then run KDB50
and DEBNA tests (minimal) only.
o If this is a Customer configured BI Expander cabinet run the appropriate
BI option diagnostics as required for the configuration under test.
********************************* IMPORTANT ********************************
When testing BI Options using Loopbacks it is important to test each option
invidually (ie. No other loopbacks installed except for one on option under
test) to ensure proper installation/configuration of the option/module under
test to its corresponding I/O panel bulkhead. Refer to XCON for the designa-
ted module to I/O panel configuration.
******************************************************************************
DMB32 Option:
o Refering to the DMB32 distribution panel, Place a H3196 loopback
connector on the Sync port, and a H3197 on each of the Async ports.
o At the DS> prompt, attach/select the DMB32 options for test. Refer to
the example below.
DS> ATTACH DMB32 XBI0 TXA 6 (DMB32 in XBI0 - BI node 6)
-----------------------
^ ^ ^
| | |___________BI node #
| |______________Logicial name (second DMB - TXB)
|___________________XBI adapter
DS> SEL TXA
-------
o Enter the following commands to run EVDAK on the DMB32.
DS> LOAD EVDAK
----------
DS> SET T,H
-------
DS> SET EVENT FLAG 3,4 !External loopback
------------------
DS> ST/P:3 ! run 3 passes of EVDAK
------
o The diagnostic will test each adapter and report a status when completed.
Make sure 0 errors were reported.
o If there are no other BI options to test, Exit the diagnostic supervisor
and refer to "Diagnostic Testing, level 2".
KDB50 Option (T1022 & T1023):
o Attach the drive cable, from the RA82 drive, to one of the ports on
the KDB50 under test. Examine the Front of the RA82 Drive, making sure
it is spun up and ready.
o Attach the drive cable, from the RA60 drive, to one of the ports on
the KDB50 under test. Examine the Front of the RA60 Drive, making sure
it is spun up and ready.
o At the DS> prompt, attach/select the KDB50 under test and the RA82/60
drives. Refer to the examples below.
DS> ATTACH KDB50 XBI0 DUA 5 (KDB50 in XBI0 - BI node 5)
-----------------------
^ ^ ^
| | |___________BI node #
| |______________Logicial name (second KDB50 - DUB)
|___________________XBI adapter
DS> ATTACH RA82 DUA DUA0 (RA82 #0)
--------------------
^ ^
| |____________Logicial name
|_________________KDM adapter
DS> ATTACH RA60 DUA DJA1 (RA60 #1)
--------------------
^ ^
| |____________Logicial name
|_________________KDM adapter
DS> SEL DUA,DUA0,DJA1
-----------------
o Enter the following commands to run EVRLF on the KDB50.
DS> LOAD EVRLF
----------
DS> SET T,H
-------
DS> ST/P:3
------
o Now move the RA60, RA82 drives to the next (2) ports on KDB50 and restart
the diagnostic by:
DS> ST/P:3
------
o Attach/Select any additional KDB50s for testing and repeat the
testing.
Note: If testing multiple KDB50 adapters, make sure to only
attach/select one at a time. (deselect all other KDB50s)
o If there are no other BI options to test, Exit the diagnostic supervisor
and refer to "Diagnostic Testing, level 2".
CIBCA-B Option (T1045 & T1046):
o Place CI loopback connectors on the CIBCA bulkhead(s), connecting
Path A Trans. -> Path A Rec. and Path B Trans -> Path B Rec.
o At the DS> prompt, attach/select the CIBCA(s)to be tested. Refer to the
example below:
DS> ATTACH CIBCA XBI0 PAA0 5 4 0 (CIBCA @BI node 5, BR=4,CI node 0)
----------------------------
^ ^ ^ ^ ^
| | | | |____CI Node #
| | | |______BR level
| | |________BI Node #
| |____________Logicial name (second CIBCA = PAB0,etc)
|_________________XJA#
DS> SEL PAA0 ! Select CIBCA under test
--------
o Enter the following commands to run EVGAA on the CIBCA(s).
DS> LOAD EVGAA
----------
DS> SET T,H
-------
DS> SET EVENT FLAG 1
----------------
DS> ST/P:3
------
o The diagnostic will test each adapter and report a status when completed.
Make sure 0 errors were reported.
o Run EVGAB, using the following commands.
DS> LOAD EVGAB
----------
DS> SET T,H
-------
DS> ST/P:3
------
o The diagnostic will test each adapter and report a status when completed.
Make sure 0 errors were reported.
o If there are no other BI options to test, Exit the diagnostic supervisor
and refer to "Diagnostic Testing, level 2".
DEBNA Option (T1031?):
o Attach the DEBNA loopback (12-22196-02), or a transceiver cable/H4080, to
the DEBNA bulkhead.
o At the DS> prompt, attach/select the DEBNA to be tested. Refer to the
example below.
DS> ATTACH DEBNA XBI0 ETA 5 (DEBNA - Bi node 5)
------------------------
^ ^ ^
| | |________BI Node #
| |____________Logicial name (second DEBNA = ETA,etc)
|_________________XBI #0
DS> SEL ETA
-------
o Enter the following commands to run EVDYF on the DEBNA(s).
DS> LOAD EVDYC
----------
DS> SET T,H
-------
DS> ST/P:3
------
o The diagnostic will test each adapter and report a status when completed.
Make sure 0 errors were reported.
o If there are no other BI options to test, Exit the Diagnostic Supervisor
and procede to "DIAGNOSTIC TESTING (LEVEL 2)".
DS> EXIT
----
>>>
INITIAL BOOT UP OF VAX/VMS:
---------------------------
o For the initial boot up of VAX/VMS it will be necessary to edit the
[USERFILES]DEFBOO.CMD command file for your particular system.
>>> EDIT [USERFILES]DEFBOO.CMD
The contents of registers R1 and R3 will have to be set as follows:
R1 - Device Node address (slot # KDM70 is configured in)
R3 - Unit Select number "0" of the RA82 system disk.
o Also the [SYSEXE]SITESPECIFIC.CMD file will need to be edited as follows:
>>> EDIT [SYSEXE]SITESPECIFIC.CMD
- Change the file so that AUTORESTART is enabled:
SET SYS$AUTORESTART 1
- Add Power on:
SET SJA/POWER:CPA
- then exit the file
o Set the OCP Startup switch to the RESTART/HALT position.
o Ensure that the RA82 System Disk is connected to a KDM70 Option, that
it is Spun Up, and its READY light is lit. Drive select # should be 0.
o Ensure that the RA60 Drive has a SCRATCH pack installed, it is connected
to another KDM70 option (if present in the config), or the same one as the
RA82 drive. It should be Spun Up with its READY indicator lit. The Drive
select number should be 1.
o At the Console prompt, type the following boot command to boot up VMS.
>>> B/R5:0 ( DEFBOO.CMD = Boot File, 0 = RA82 drive #)
NOTE: Using a "B/R5:1" command will stop the boot up in SYSBOOT to allow
for modification of system parameters/minimal startup if necessary.
[interleave memory 1WAY for testing]
:
[building memory bitmap]
[VAX 900 Primary Bootstrap, Version Vx.x-xxxx.x
%BOOT-I-MEMINIT, Initializing memory to known state
-I-PROGRESS,..........................................................K
INITIAL BOOTUP OF VAX/VMS - Continued -
-------------------------
o The following header information will be displayed as VMS is booted.
VAX/VMS Version V5.4 Major version id = x Minor version id = x
PLEASE ENTER DATE AND TIME (DD-MMM-YYYY HH:MM:SS):
:
:
SYSTEM job terminated at dd-mmm-yyyy hh:mm:ss.xx
o Enter the "SYSTEST" account by entering the following information.
<CR> ! Type a carraige return to get USERNAME prompt
Welcome to VAX/VMS T5.4-xxx
Username: SYSTEST ! Username = SYSTEST
Password: VAX9000_UETP ! Password = VAX9000_UETP
Welcome to VAX/VMS Version V5.4-4GE
Last interactive login on DDDDDDDDDD, dd-mmm-yyyy hh:mm
$
o Verify that there are no potential problems by entering the following
command:
$ SHOW DEV ! Ensure that no errors are being observed
-------- ! and that Disks/devices are seen correctly
: ! by the VMS operating system.
$ SHOW ERR ! Determine if any other errors
--------
o Set up and verify the RA60 Disk Drive for use during UETP testing as follows:
$ INIT DJA1: TEST1 <CR> ! initialize RA60 and assign it
---------------- ! a label = TEST1
$ MOU/SYS DJA1: TEST1 <CR> ! Mount the RA60 disk
-------------------
$ CRE/DIR DJA1:[SYSTEST] <CR> ! Create SYSTEST directory on disk
----------------------
$ SHOW DEV <CR> ! SHOW DEV with example display
--------
DEVICE DEVICE ERROR VOLUME FREE TRANS MNT
NAME STATUS COUNT LABEL BLOCKS COUNT CNT
DUA0: MOUNTED 0 VAXVMSRL5_4 200000 50 1
DJA1: MOUNTED 0 TEST1 50000 20 1
:
:
etc
DIAGNOSTIC TESTING (LEVEL 2):
-----------------------------
o Set default to the [SYSMAINT] directory where the Diagnostics are contained:
$ SET DEF SYS$MAINTENANCE <CR>
-----------------------
o Invoke the VAX Diagnostic Superviser (VAX DS) by entering the following
command:
$ RUN EWSAA
---------
o VAX DS will now boot up, displaying the following header:
VAX DIAGNOSTIC SOFTWARE
PROPERTY OF
DIGITAL EQUIPMENT CORPORATION
***CONFIDENTIAL AND PROPRIETARY***
Use Authorized Only Pursuant to a Valid Right-to-Use License
Copyright, Digital Equipment Corporation, 1989. All Rights Reserved.
DIAGNOSTIC SUPERVISOR. ZZ-EWSAA- x.x-xxx xx-xxx-xxxx 11:11:46
DS>
o Determine the configuration of the system and enter the appropriate
ATTACH commands for the CPUs, and XJAs. Use the following examples as
a guide.
To attach CPU:
DS> ATTACH KAWWW HUB KA0 0 N (CPU 0 without vector)
------------------------
^ ^ ^ ^
CPU | | |______Vector (Y/N)
| |________Physical CPU #
|___________Logicial name/cpu#
To attach XJA:
DS> ATTACH XJA HUB XJA0 0 (XJA0)
---------------------
^ ^
| |________Physical XJA#
|___________Logicial name/Xja#
o Type the following command to select the CPUs, XJAs.
DS> SEL All
-------
o The following sections describe the Level 2 diagnostic testing for each
option. Refer to the appropriate sections based on the system configura-
tion.
DEMNA Option (T2020):
o Attach the AVS/Enet transceiver cable, located in the test area, to the
DEMNA bulkhead. If multiple DEMNAs are installed, connect the Loopback
transceivers 12-22196-02, to each DEMNA I/O bulkhead.
o At the DS> prompt, attach/select the DEMNA(s)to be tested. Refer to the
example below.
DS> ATTACH DEMNA XJA0 EXA0 5 (DEMNA in XMI #0, Slot 5)
------------------------
^ ^ ^
| | |________XMI slot #
| |____________Logicial name (second DEMNA = EXA1,etc)
|_________________XJA#
DS> SEL EXA0
--------
o Enter the following commands to run EVDYE on the DEMNA(s).
DS> LOAD EVDYE
----------
DS> SET T,H
-------
DS> ST/P:3
------
o The diagnostic will test each adapter and report a status when completed.
Make sure 0 errors were reported.
o If there are no other options, requiring level 2 testing, Exit the
Diag. Supervisor and refer to "UETP Testing".
DEBNA Option:
o Attach the tranciever loopback (12-22196-02) or H4080 loopback, to the
DEBNA I/O bulkhead.
o At the DS> prompt, attach/select the DEBNA to be tested. Refer to the
example below.
DS> ATTACH DEBNA XBI0 ETA 5 (DEBNA - Bi node 5)
-----------------------
^ ^ ^
| | |_________BI Node #
| |____________Logicial name (second DEBNA = ETA,etc)
|_________________XBI #0
DS> SEL ETA
-------
o Enter the following commands to run EVDYD on the DEBNA(s).
DS> LOAD EVDYD
----------
DS> SET T,H
-------
DS> SET EVENT FLAG 3
----------------
DS> ST/P:3
------
o The diagnostic will test each adapter and report a status when completed.
Make sure 0 errors were reported.
o If there are no other options, requiring level 2 testing, Exit the
Diagnostic Supervisor and refer to "VAX/VMS UETP Testing".
VAX/VMS UETP TESTING ( Initial 5 Pass Run):
-------------------------------------------
o Return to the default login directory ([SYSTEST]) by:
$ SET DEF SYS$LOGIN<CR> or $ SET DEF SYS$SYSROOT:[SYSTEST]<CR>
o Type @UETP to setup and run the Quick Pass UETP test for 5 passes.
$ @UETP DEVICE & LOAD phases, 5 passes, 290 loads, short
Welcome to VAX/VMS UETP Version T5.4-4GE
:
:
:
Run "ALL" UETP phases or a "SUBSET" [ALL]? SUB <CR>
---
:
Phase(s): LOAD,DEV <CR>
--------
How many passes of UETP do you wish to run [1]? 5 <CR>
-
How many simulated user loads do you want [284]? <CR>
Do you want Long or short report fromat [Long]? SHORT <CR>
-----
UETP Starting at dd-mmm-yyyy hh:mm:ss.xx with parameters:
LOAD, DEVICE phases, 5 passes, 284 loads, short report.
:
:
*********************************************************
* *
END OF UETP PASS 1 AT dd-mmm-yyyy hh:mm:ss.xx
* *
*********************************************************
:
SHOW ERRORS
% SHOW-S-NOERRORS, No device errors found
:
o Perform Power-Fail Restart Test :
- This test is performed after an exceptable (0 errors from SHO ERR)
first pass run of UETP to simulate that the system can make a "Warm
Start" recovery after a power failure has occurred.
- Verfiy state of BBUs by checking status LEDs (two upper RED LEDs) on SIP
to ensure they are charged sufficiently.(should be on constant)
- Set the OCP STARTUP Switch to the RESTART/HALT position.
- Allow UETINIT01 test to complete and the 2nd pass LOAD Tests to start
executing.
CAUTION note: Extreme care is to be used when turning off main breaker
to OFF and ON positions.
Do Not let BBU remain on for any time beyond that specified.
This will drain Batteries and in case of failure require a
longer time to recharge BBU before being able to retest.
VAX/VMS UETP TESTING ( Initial 5 Pass Run): - Continued -
-------------------------------------------
o Power Fail Test - Cont -
- On Main Power Distribution Bus - stand clear and turn the Main Breaker to
OFF (RED pull cord).
- Carefully observe the following:
- Status LEDs lit: SIP RED LEDs indicate BBU's in discharge state by fast
flash (10Hz), in SCU Cab the BUS B RIC #42 is on, and both BUS B H7380
Converters B0 and B1 are ON - "MOD OK" LEDs are lit.
- After 1-2 minutes restore main AC power by turning Distribution Bus Main
Breaker to ON.
- The SPU will reinitialize itself and the system and will print out
"ATTEMPTING SYSTEM RESTART"
:
- This will then be followed by the continuation of the UETP LOAD Tests.
:
:
*********************************************************
* *
END OF UETP PASS 5 AT dd-mmm-yyyy hh:mm:ss.xx
* *
*********************************************************
:
SHOW ERRORS
% SHOW-S-NOERRORS, No device errors found
o After successful completion of the (5) pass UETP Test the Error Logs need
to be verified:
$ ANALYZE/ERROR (/EXCLUDE=(x,x,x) - may add this qualifier for mask-
ing known bugs or device errors)
- Verify that the SID is being interpreted correctly by VMS (ie. plant
code = 1, serial # = unit under test) when displayed in ANALYZE/ERR
header.
- use NO SCROLL key of terminal to suspend printout to view
- after examination of the Error Log File (this is [SYSERR]ERRLOG.SYS) has
verified that the UETP run was successful the system may be shutdown.
VAX/VMS UETP TESTING ( Initial 5 Pass Run):
-------------------------------------------
**** Skip to VMS Shutdown section *****
o Verify that the SPU can have its power turned off and then restored without
causing problems, while the system is booted up in VAX/VMS operating System.
This is a maintainability feature that has been designed into the VAX 9000.
- TBD
- start up and run (1) additonal pass of UETP. While UETP is running:
1) Turn SPU power switch (located above BBU Test switch) to teh OFF (0)
position.
2) Observe that SPU power is OFF - No LEDs lit on SPU modules (T2050,
T2051,T1060,T1031,T1034).
3)
o Shutdown the system under test as follows:
$ @[SYSEXE]SHUTDOWN <CR>
-----------------
- reply with Carraige Returns <CR> to each prompt which follows
OR
$ SHUT <CR> ( the system will execute an automatic shutdown)
----
:
SYSTEM SHUTDOWN COMPLETE - USE CONSOLE TO HALT SYSTEM
:
Ctrl P (Type a "Ctrl P" command to Halt and drop to console)
:
>>>H ! HALT
POWER DOWN SYSTEM AND CONNECT TO TEST CLUSTER:
----------------------------------------------
o Power Down the system under test. Remove the CI loopbacks from the
CIXCD (or CIBCA) Adapter Ports.
o Connect the appropriate Cluster cables to the CI Adapter (CIXCD or
CIBCA ports) as follows:
- Connect the RECEIVE A BNCIA cable to the CIxxx RECEIVE A (->O) port
- Connect the TRANSMIT A BNCIA cable to the CIxxx TRANSMIT A (O->) port
- Connect the RECEIVE B BNCIA cable to the CIxxx RECEIVE B (->O) port
- Connect the TRANSMIT B BNCIA cable to the CIxxx TRANSMIT B (O->) port
o Power Up the System and verify proper initialization sequence,BIST,etc.
CLUSTER UETP TESTING:
---------------------
#A - 5#
01000000
.. 2...67..A.....
Attempting system bootstrap
%VAXELN system initializing
VAXELN Vx.x SPM
EWBAB Xx.x(0), initializing
Scope = %CPU0, Model = CPU, Revision = x
>>>
o A successful boot of VAXELN will display a Console prompt ">>>". At the
prompt, type the following boot command to boot up VMS.
>>> @NODExx (xx = CI NODE NODE corresponding to that
Test slot)
o The following header information will be displayed as VMS is booted.
VAX/VMS Version V5.x Major version id = x Minor version id = x
:
:
%CNXMAN, Now a VAXcluster member -- system NODExx
:
Cluster Common systartup procedure executing on NODExx
:
SYSTEM job terminated at dd-mmm-yyyy hh:mm:ss.xx
o Enter the "SYSTEST" account by entering the following information.
<CR>
Username: Systest
Passord: xxxxxxxx
Welcome to VAX/VMS Version V5.x
:
:
$
o Type @UETP3 to run the Quick Pass CLUSTER UETP test for 3 passes.
$ @UETP3<cr> (script name for 3 pass run)
:
:
The serial number of this CPU under test is xxxxxxxx ??
The serial number of this SCU under test is xxxxxxxx ??
The serial number of this FXC under test is xxxxxxxx ??
etc
:
UETP Starting at dd-mmm-yyyy hh:mm:ss.xx with parameters:
LOAD, phases, 3 passes, xx loads, short report.
:
:
*********************************************************
* *
END OF UETP PASS 1 AT dd-mmm-yyyy hh:mm:ss.xx
* *
*********************************************************
:
SHOW ERRORS
% SHOW-S-NOERRORS, No device errors found
:
*********************************************************
* *
END OF UETP PASS 2 AT dd-mmm-yyyy hh:mm:ss.xx
* *
*********************************************************
:
SHOW ERRORS
% SHOW-S-NOERRORS, No device errors found
:
:
*********************************************************
* *
END OF UETP PASS 3 AT dd-mmm-yyyy hh:mm:ss.xx
* *
*********************************************************
:
SHOW ERRORS
% SHOW-S-NOERRORS, No device errors found
o After successful completion of the (3) pass UETP Test the Error Logs need
to be verified:
$ ANALYZE/ERROR (/EXCLUDE=(x,x,x) - may add this qualifier for mask-
ing known bugs or device errors)
- use NO SCROLL key of terminal to suspend printout to view
** How can AVS monitor output of the logs for errors???? Is this possible?
- after examination of the Error Log File (this is [SYSERR]ERRLOG.SYS) has
verified that the UETP run was successful the system may be shutdown.
o Shutdown the system under test as follows:
$ CLUS_SHUT<CR> ( the system will execute an automatic shutdown
: with REMOVE_NODE qualifier)
:
SYSTEM SHUTDOWN COMPLETE - USE CONSOLE TO HALT SYSTEM
:
Ctrl P (Type a "Ctrl P" command to Halt and drop to console)
:
CONSOLE>
o Disconnect the Cluster's (4) BNCIA cables from the CIxxx Adapter Ports.
ULTRIX TESTING:
---------------
o Determine if System order is an ULTRIX SBB (System Building Blocks).
Refer to XCON (should be line item for system: 92xxx-xx)
o If it is then proceed to set up for Ultrix Testing. Place RA60 Pack
with ULTRIX operating system on it into the RA60 Disk drive.
o Boot and run ULTRIX Excercisors per steps that follow:
TBD
o When ULTRIX testing is complete; shutdown ULTRIX, spin down disk,
remove ULTRIX RA60 pack, and procede to next step.
COMPLETION OF QUICK PASS:
-------------------------
o Remove VECTOR and Memory KGM sets if installed on Scalar CPU. Extreme care
and detailed process must be adhered to when removing MCUs in Non-clean
Room environment.
- Return KGMs as per detailed flow:
TBD QUICK PASS --> TRANSPORT CONTAINER --> CLEAN RM QUEUE
o Remove Loopbacks and any related test connectors.
o Ensure that all required INFINET FDC Quality transactions have been entered
for the system under test.
- If complete, the SYSTEM (KA9x0-xx) can be "PASSED" in INFINET. (refer to
the INFINET FDC procedure in APPENDIX 2 for detail)
o Quick Pass testing has now been completed.
RUN-IN TESTING (96 Hour):
-------------------------
o Overview:
This portion of the System Level test will highlight any gross infancy,
timing problems, and functional problems remaining in the system as well
as any intermittent problems. During this period of time data will be
collected on each of the systems and any failures/problems will be worked
to resolution (ie. solution identified and implemented).
The test scripts run here will be similar to those run in the Quick Pass
version of system test however multiple passes will be run for an extended
period of time.
o All options will be installed as configured to the customer order, however
extensive option testing will not be performed during Runin.
o RUNIN will begin at 96 hours, with 96 hours error free for "all" MCU
failures. A matrix of retest times will be used for all possible FRUs
that may fail during Run-in. (identifying those that will not require a
complete 96 hour retest)
o RUNIN capital
o Same as required for Quick Pass Testing
o Outline of tests:
o Diagnostics - use long version of each diagnostic
o First 40 % of test: SCAN, diagnostics, UETP(minimum)...with margins
Next 50% of test: Extended run of UETP
Last 10% of test: iteration of Quick Pass sequence
(refer to test process flow)
o CI testing using loopbacks only. No Cluster setup/UETP run unless
required for retest.
o No ULTRIX testing during Runin. - unless required for retest.
o Run-in Test Process Flow - see following page
|
| 78.22 | Missing A-latch problem | KERNEL::ODONNELLR | | Thu Aug 02 1990 10:04 | 38 |
|
Note - the "Missing A-latch problem" causes I/O (and the system)
to hang. It is sensitive to clock speeds and variations in JXDI cable
length, and does not occur in all systems.
The permanent fix will be a new chip/new MCU rev in the SCU. A
temporary fix - a modification to one of the JXDI cables - is being tested
and will be available shortly.
Ray Lin describes below an exact pattern that will be seen
in SCU scan-latches if the hang you are observing is due to this problem.
From: AQUA::LIN 31-JUL-1990 17:48:53.64
To: DELAHUNT,BEAVEN
CC: LIN
Subj: To identify the missing A-latch problem
To identify the Missing an A-LATCH problem, check these scanlatches
at the time of failure.
1. %SCU.CCU.CTLA.PRTERR_H<2> = 1
2. %SCU.CCU.CTLA.2PRTRDY_H<1:0> = 0 or 1 and
%SCU.DA0.JDC0.RCV_CCU.TO_XJA_BUFA_FULL_TB_H = 0 and
%SCU.DA0.JDC0.RCV_CCU.TO_XJA_BUFB_FULL_TB_H = 0 and
%SCU.DA0.JDC0.RCV_CCU.IO_BUFA_BUSY_TB_H = 0 and
%SCU.DA0.JDC0.RCV_CCU.IO_BUFB_BUSY_TB_H = 0
========================================================================
or if XJA2 or XJA3 exists,
1. %SCU.CCU.CTLA.PRTERR_H<5> = 1
2. %SCU.CCU.CTLA.5PRTRDY_H<1:0> = 0 or 1 and
%SCU.DA1.JDC0.RCV_CCU.TO_XJA_BUFA_FULL_TB_H = 0 and
%SCU.DA1.JDC0.RCV_CCU.TO_XJA_BUFB_FULL_TB_H = 0 and
%SCU.DA1.JDC0.RCV_CCU.IO_BUFA_BUSY_TB_H = 0 and
%SCU.DA1.JDC0.RCV_CCU.IO_BUFB_BUSY_TB_H = 0
|
| 78.23 | CIXCD revisions | KERNEL::WRIGHTON | No , it's meant to work like that ! | Mon Aug 06 1990 08:27 | 37 |
|
CIXCD REVISION MATRIX AVAILABLE
PROBLEM
There is a potential problem concerning the current
acceptable CIXCD Hardware, Software, Microcode, Cluster, and
VMS revisions. Mixing different releases of the diagnostics
and CIXCD Microcode can cause some diagnostics to fail. The
types of failures depend on the versions that are combined at
the time.
ACTION
PLEASE AT THIS TIME, VERIFY THE CIXCD MODULE YOU HAVE WITH
THE INFORMATION PROVIDED IN THIS MEMO.
CURRENT REVISIONS
At this time, August 3, 1990, the current CIXCD HW revision
is E02. This module has some component rework on the back side
of the module. The current Microcode version is 22.
You will find the current revision matrix for all the above
mentioned in the AUGGIE::XCD_FORUM notes file. This notes file
is updated as new information is made available. There is a
pointer in the notes file as to where the most current software
releases may be pulled from.
|
| 78.24 | more about KAF and CACHE SWEEPS | KERNEL::WRIGHTON | No , it's meant to work like that ! | Mon Aug 06 1990 08:29 | 55 |
|
Regarding the recent blitz on:
TITLE:VAX 9000 KEEPALIVE FAILURES DURING ERROR RECOVERY
DATE: 25 July 1990
AUTHOR: Tom Collentine TD #: 000350
DTN: 297-4749
ENET: MRCSSE::TCOLLENTINE CROSS REFERENCE #'s:
DEPARTMENT: HIGH-END SYSTEMS CSSE (PRISM/TIME/CLD#'s)
INTENDED AUDIENCE: PRIORITY LEVEL: 1
(U.S./EUROPE/GIA) (1=TIME CRITICAL,
2=NON-TIME CRITICAL)
=====================================================================
OVERVIEW:
MBOX hardware cache sweeps should be disabled for Revision B
VAX 9000 CPUs.
-----------------------------------------------------------------------------
The suggested workaround was to edit siteinit.cmd in [sysexe] and
include the following deposit command:
"DEPOSIT VAP.CCSQ.JCON.NO_ERROR_SWEEP_H 1"
We have identified that this will cause VDS to be unable to boot as
the result of issues between the amount of memory respective sets of
software are expecting to have available and the way Cache TAGs are
handled.
The symptom is that VMS -will- be able to boot, but VDS will come up
with either ECC errors when BOOT is trying to test memory; and/or
you will see the SJA TX buffer not empty message (preceded by the
message about memory handshake errors).
This is being worked by engineering who is aware of the problem.
In the interim, while it is still suggested that you leave
"NO_ERROR_SWEEP" set to 1 (as stated in the blitz), until we get
this issue resolved you can either manually deposit a 0 to
VAP.CCSQ.JCON.NO_ERROR_SWEEP_H prior to BOOTing VDS, or edit
[USERFILES]VDSBOO.CMD to deposit a 0 before loading and starting
VDS.
Follow on mail or another blitz will be sent when this issue is
resolved.
Butch
|
| 78.25 | Console problem summary | KERNEL::WRIGHTON | odd numbered release = bug insert | Tue Aug 07 1990 07:59 | 63 |
|
Subject: Notes regarding 10.3 and 10.4 releases
1) SPD
SPD (The Scepter Pattern Diagnostic) SHOULD NOT BE RUN UNDER
ANY CIRCUMSTANCES UNTIL FURTHER NOTICE. SPDINIT.CMD was not
released under 10.3 for a reason: SPD callouts are not
considered reliable enough at this time for use in the field.
The fault cones extend too far into the hardware (provide a 2
cycle test when tests are designed for a single clock cycle
only). The end result will be unpredicatable callouts. Do not
propagate SPDINIT.CMD if you should get a copy of it outside
of the SPU release kit.
2) CONFIG.DAT
During I/K commands, an issue with the CONFIG.DAT file has
been identified which may make it impossible for the SENSE
command to return to completion resulting in the SPU hanging.
If you have 10.3 systems and you do not see a problem, ignore
this update. If you are currently installing a VAX 9000 with
10.3 SPU software, delete [SYSEXE]CONFIG.DAT after booting the
SPU before proceeding with other system verifications. This
should be fixed under the 10.4 release.
3) TEST commands
The following test commands fail or are not implemented yet:
TEST/XJA nyi
TEST/XBI nyi
TEST/JXDI (fails first pass, fixed in 10.4)
TEST/CLOCK leaves the clock uninitialized under 10.3 (fixed in
10.4) so a TEST/SCAN immediately following a
TEST/CLOCK will currently fail. Under 10.3, you
must INIT/CLOCK before running TEST/SCAN since
TEST/SCAN requires clocks be initialized and off.
Under 10.4, you can go right to TEST/SCAN after
TEST/CLOCK.
TEST/SCM/SPE was a debug facility only. The /SPE switch is
unsupported in the field and should be crossed out of any
documented test procedures you have (including the 10.3
release notes, Install manual, or SFI manual).
The release notes or additional memos will detail when these
tests have been fixed for field use.
4) Structures
The following structures have been removed (so TEST/STR will
fail on them): PCACHE0, PCACHE1, P_IGPR.
IBANK2 requires a VBOX to be installed otherwise this will
fail under 10.3, and will be skipped under 10.4 (when
TEST/STR/ALL is given as the command).
|
| 78.26 | SDD Decoder functions | KERNEL::LOANE | Once upon a time in a TU45! | Wed Aug 08 1990 20:59 | 85 |
| There is a facility available for automatic generation of VAX 9000
Repair Plans. In other words, a Customer/Engineer(/Site Service
Processor) logs a call with a VAX 9000 SDD Theory Code. Now, you
could fire up a TIMA Stars process and interrogate the SDD_THEORIES
database to find out what FRU is indicted, or you could use the SDD
DECODER. This facility will generate an ASCII file with the full
repair plan AND Theory Description. The command syntax is as
follows:-
$ DECODE/TH=3090A.011.144
This will generate the file and update you as to it's name.
The following text is from the preliminary Release Notes:-
DECODER V0.1 Release Notes
Temporary file until the release notes are completed
1. The decoder is installed in the SDD$EXE directory. If the directory
cannot be found, the installation will create [SYMAINT.SDD]. The
image name is local_decode.exe.
2. Define a foreign command for the SDD decoder as follows.
$decode == "$sdd$exe:local_decode.exe"
3. Define a logical (SDD$STARS) to point to the STARS database containing the
SDD articles. The following is an example pointing to the STARS sample files.
This example will not point to the SDD articles, WORK1:[STARS.DATABASES.
SAMPLE] will be replaced by the location of the SDD database.
$define SDD$STARS WORK1:[STARS.DATABASES.SAMPLE]/system
4. The SDD Decoder can be called from another program or can be activated
from a user interface.
The user interface, in a VMS/DCL environment, has a foreign command, "decode".
This is a shorthand method of running the decoder program. There are two
switches that can be used with the command, /CDP and /THY. The /CDP switch
indicates to the program that a filespec of a Configuration Data Packet will
follow. The /THY switch indicates that a theory number will follow. The
decoder also recognizes a shortened version of decoding the theory number.
With no switch, the data following the decode command is assumed to be the
theory number. Examples of the various commands are:
Decoding the theory number
decode 3091a.81.11
decode/thy 3091a.81.11
decode/thy=3091a.81.11
Decoding the CDP
decode/cdp femtest.dat
decode/cdp=femtest.dat
(femtest.dat is the filespec of a test CDP file)
The decoder will prompt for the missing data. Typing just "decode" will
initiate the prompt asking for a CDP or THY. Typing "decode/thy" will prompt
for the theory number and "decode/cdp" will prompt for the CDP filespec. If
the wrong theory number is typed in the decoder will display an warning message
and request that you resubmit the theory number. If there is a problem reading
or finding the CDP file, the decoder will prompt you to check the existence of
the file and to check that file contains a CDP. It will then allow you to
enter a corrected filespec.
Without a qualifier:
$ decode
Please type in the data using one of the following examples./n
Enter '/thy' followed by the theory number
(ex: /thy 3091a.81.11)
OR enter '/cdp' followed by the CDP file name
(ex: /cdp cdp.file)
OR type 'exit' to leave the decoder.
With a qualifier:
$ decode/thy
Enter the theory number or type exit:
$ decode/cdp
Enter the CDP file name or type exit:
|
| 78.27 | some more bugs ( from manufacturing ) | KERNEL::WRIGHTON | odd numbered release = bug insert | Thu Aug 09 1990 08:13 | 108 |
|
TO: BTO VAX 9000 Debug FROM: Donald Zukswert
DATE: 7 August 1990
DEPT: Mfg. Engineering
EXT : 266-4099
CC: see attached LOC : BTO
ENET: BTOVT::ZUKSWERT
FILE:
SUBJ: Known Hardware/Software Bugs for Aridus and Aquarius Systems
I have started to put together a list of known hardware and software bugs
which have been observed during BTO's Aridus and Aquarius system test/debug.
We need to have this info available to the system test/debug people and I
have not yet decided on the best way to do this considering that there
already exists a VAXnotesfile as well as the QAR database (MRO) for error
reporting. There should be a fast and easy way to match a systems failure
message/symptom with a list of known bugs. This would:
1) eliminate repetitive BTO debug of already known problems
2) identify any new bugs
3) ensure all bugs get reported/resolved
I would ask that all of you who have worked on the systems in one capacity
or another take the time to list all the bugs you can remember ever seeing.
I have included some templates for this purpose, however just a one-liner
description would also be fine. I can contact people individually for more
details. I would prefer sorting through hundreds of responses rather than none
at all. The more complete this list is, the better tool it will be for
use on the manufacturing floor during system test/debug.
In addition to known bugs, also include anything strange you may have noticed
or questioned such as:
"why does test/jxdi always fail the first time"
"why does /trace work on some commands and not others"
"why does the CIXCD hardware rev always show up as 0000 when running EVGAA"
"why do you have to manually disable CPU 1 interrupts (in cpucnf) when
testing XMI options under VDS on Aquarius ASx systems?"
Listed below is the format I have been using so far. Any comments/criticism
will be considered. Ten blank forms are included at the end of this memo for
your use. Just fill in whatever sections you have information on and I'll
work on how we can all access them.
Thanks,
don
=============================================================================
Bug format:
----------
Bug number : number assigned as they are entered on list
Bug name : short name used for bug identification/conversation
Date entered : date bug entered on list
Responsible party: who is responsible for fixing the bug
Test/command : command or test used which results in the bug
Failure displayed: what failure the operator would observe on the terminal
Hardware revision: any related hardware such as system rev, mcu rev, XMI option
module rev, cable rev, Aridus or Aquarius, etc
Software revision: any related software rev such as console software rev,
VMS rev, XMI option microcode rev, diagnostic rev, etc
Solution : open/closed; actual solution, or date, or new version #, etc
Details : general details of failure displayed, error latches set,
solution, etc
===============================================================================
Below are several examples of some known bugs:
Bug number :
Bug name :
Date entered : 7/30/90
Responsible party:
Test/command : i/k (I/O initialization section)
Failure displayed: SCU failed to respond to last packet sent
Hardware revision: Aridus; cpu b4/scu b3 mcus
Software revision: console v10.3
Solution : open
Details : Appeared to be an XJA problem, but found the work around:
>>> DEFINE INIT$SCU_DEBUG 1 ! Don't turn SCU clocks on
>>> INIT /KERNEL (/BRIEF)
>>> @CLEAR_MEMORY ! Clear memory, Initialize IO
>>> DEASSIGN INIT$SCU_DEBUG ! Don't need this anymore
Once the memory was cleared, we no longer had initialization
problems. Suspected init problem, MRO notified.
*****************************************************************************
Bug number :
Bug name :
Date entered : 7/30/90
Responsible party:
Test/command : EVCLB (XJA diag) running multiple passes
Failure displayed: Test 2, subtest 10, error 2 (octaword read lock/write
unlock failures)
Hardware revision: Observed on RQT2; also on AS5 during first pass of EVCLB.
Software revision: EVCLB version 1.5
Solution : Closed. Use EVCLB version 1.8
Details : Reference V9K_engineering_tips notes file
|
| 78.28 | FCO for the SPD | KERNEL::WRIGHTON | odd numbered release = bug insert | Fri Aug 10 1990 08:17 | 49 |
| PRELIMINARY NOTIFICATION
OF
PENDING ECO
****************************************************************************
* *
* The purpose of the information contained herein is to provide Field *
* Service and Manufacturing with preliminary/advanced notification of *
* a pending ECO. Expectations are that those operations, to be affected *
* by the forthcoming ECO, will take a responsible position, for the *
* Corporation, to reduce the implementation cost of the respective ECO. *
* *
****************************************************************************
Power spikes generated during H7390 DEC 103/122 testing were damaging an RS-232
receiver on T2051, Service Processor Module. The most logical choice for
damage prevention, ease of implementation, and lowest cost is to add transorb
zener diodes on the SPD electrically between logic signals and chassis
ground.
! These spikes might cause the SPU to drop to the SPM-ROM> prompt
! and can be induced by simple things like turning the MDS01 off/on
! The break control jumper on the SPD ( the transition bracket
! on the back of the system ) appears to have no affect over this
! problem .
! Dave Wrighton
==============================================================================
ESTIMATE OF REWORK INSTRUCTIONS:
Addition of two 20-pin DIP ICs (19-25894-01, 19-25894-02) and 14 wire changes.
The extent of the rework and the desire not to mount ICs inverted (pins-up)
preclude the rework of existing revision modules. New etch will be required.
==============================================================================
IMPLEMENTATION STRATEGY:
This notice is NOT an engineering hold on manufacturing builds of the current
revision. Although this is desired, the shipment of VAX 9000 systems with
the current SPD revision is considered paramount for Digital. B02 revision
SPD builds should be continued ONLY to prevent the delay in system shipments.
At some point, all VAX 9000 systems must be retrofitted with the ECO.
Retrofit strategy has not yet been determined.
==============================================================================
|
| 78.30 | Torque wrench problem ( maybe US only ) | KERNEL::WRIGHTON | odd numbered release = bug insert | Fri Aug 17 1990 09:57 | 102 |
|
+----------------------------+ TM +-------+
| | | | | | | | | | | | |
| d | i | g | i | t | a | l | |c|s|s|e|
| | | | | | | | | | | | |
+----------------------------+ +-------+
To: See distribution From: Tom Daley
Dept: HPS CSSE
Date: 16-AUG-1990
MS : MRO02-3/5E
DTN : 297-7340
Pole: 2B
Node: HPSMEG::DALEY
Subject: Uncalibrated Torque Tool (P/N: 29-28143-01.A01)
PROBLEM:
We have just found indications that there is an uncalibrated torque
device in the VAX 9000 CONNECTOR TORQUE TOOLS KIT (P/N:
29-28143-01.A01).
KIT AFFECTED:
Three of three kits shipped to MRO were received with the Z-FLEX &
MEM/FLEX Torque Tool (P/N: 29-28143-01.A01) uncalibrated. This tool
is essential to the installation of the VAX 9000 Z-FLEX Cables.
POSSIBLE IMPACT:
We are presently unsure as to the possible symptoms/problems that
could result, but the 20 in-lb value that the uncalibrated tools are
coming in at should establish adequate connector contact. The
addition 7 in-lbs provides long term vibration resistance for the
connection.
PREVENTIVE MAINTENANCE:
Once a correctly calibrated tool is available, all existing VAX 9000
Installations should be re-visited and all Z-FLEX connections be
re-torqued. We DO NOT recommend separating the connection, merely
tighten the existing connection with the calibrated tool. This
should ensure a robust connection.
QUICK CHECK PROCEDURE:
The best way to determine if the tool you received is properly
calibrated is to look at the butt of the red handle. The number 27
should be stamped next to the "calibration at" label. If no value is
stamped, your tool is likely not calibrated (we have found them at
20 in-lbs).
RECOVERY PROCEDURES:
FASTEST METHOD: The quickest way to get this tool calibrated
involves directly contacting a local machine shop that calibrates
torque devices. It should only take a few minutes to actually
calibrate and stamp/mark the tool. The expense will vary between
calibration shops, but should not cost more than $10-20 dollars
(US).
TORQUE SETTING: 27 in-lbs or 31 cm-Kg
ALTERNATE METHOD: Fast ship (Ex. Federal Express etc) your Z-Flex
Torque tool to:
KAUFMAN COMPANY, INC.
110 Second Street
Cambridge, MA 02141
Attn: Mr. Norman Kaufman
Enclose with the tool a memo listing the address to return
calibrated tool to. Kaufman Co. will fast ship the corrected
tool to you.
Note: The current Z-Flex Torque Tool being shipped has a red
anodized aluminum handle. Some (not all) of the replacement
tools may have blue handles. Refer to the calibration stamp for
setting varification
COMMENT:
Luckily the non calibrated tool is not stored at values above the 27
in-lbs, so no damage will occur to the connector.
A quality hold has been placed on all kits in inventory and the
vendor will correct this over the next week. Customer Service
Purchasing and Logistics are aware of this and are taking the
necessary steps to ensure correction and future prevention of this
problem.
|
| 78.31 | latest manufacturing bug list | KERNEL::WRIGHTON | odd numbered release = bug insert | Fri Aug 17 1990 10:00 | 112 |
|
+---------------------------+ TM
| | | | | | | |
| d | i | g | i | t | a | l | INTEROFFICE MEMORANDUM
| | | | | | | |
+---------------------------+
TO: BTO VAX 9000 Debug FROM: Donald Zukswert
DATE: 15 August 1990
DEPT: Mfg. Engineering
EXT : 266-4099
CC: see attached LOC : BTO
ENET: BTOVT::ZUKSWERT
FILE:
SUBJ: VAX 9000 Known Hardware/Software Bugs
Over the past week, I have received two responses to my request for known
bugs. Either no one has seen any bugs, no one has time to respond, or no
one cares. Anyways, attached is a summary of the bugs I have seen or read
about as well as some questionable ones. Any input of additional info on
these bugs, or any other bugs not yet listed would be greatly appreciated.
I will continue to update the list, so feel free to send info anytime.
Not all of the bugs listed have been confirmed, so use the list as a guide,
not gospel.
The summary, as well as details for each bug listed, is contained in a
text file called bugs.doc located for your reference in
skivt::disk$zukswert:[zukswert.aqua]bugs.doc
I find that using edit/read and then searching for either a test command,
diagnostic name, or a particular error is the easiest way to use the file.
For quick and easy access, you may want to add this to your login.com:
$ bugs :== edit/read skivt::disk$zukswert:[zukswert.aqua]bugs.doc
then all you have to type is "bugs".
Although the bug entries appear to be somewhat sorted now, all future entries
will be added sequentially by bug number.
Additional sources of bug information can be found in:
1. AQUARIUS Quality Assurance Reporting (QAR) system
2. Notes file AQUA::DV$DISK:[BEAVEN.CONF9K]V9K_ENGTIPS
3. "VAX 9000 Release Notes for Manufacturing" by Chris McClare
BUG List
* * * * *
Questionable BUGS
BUG # Description Date Status
------------------------------------------------------------------------------
Q12 Test/xja:0 8/14/90 open
Q11 Boot VMS on Aquarius dual with SMP = -1 (all CPUs) 8/14/90 open
Q10 Boot VMS on CPU 1 (VAX9420). Disable memory test? 8/14/90 open
Q9 EWKAX diag on dual cpus (VAX9420) 8/14/90 open
Q8 EWKAX diag test 5 failure 8/14/90 open
Q7 SCU TAG errorscalled out in all_error_latches.cmd 8/14/90 open
Q6 Test/structure vreg error when no VRG mcu installed 8/14/90 open
Q5 Test/structure xja%_buf fails with no DA1, DB1 mcus 8/14/90 open
Q4 Test/structure adr_buf "no testable bits" 8/14/90 open
Q3 EVKAA diag. Cannot CTRL-P out of it. 8/14/90 open
Q2 EWKAX diag test 5 failure 8/14/90 open
Q1 @hws_all.cmd run on VAX9410. Ignore small letters? 8/14/90 open
****************************************************************************
Known Bugs
BUG # Description Date Status
------------------------------------------------------------------------------
032 TOY; enter date and time after every console reboot 8/15/90 open
031 EVGAA CIXCD diag Test 1, subtest 0, err 9; unexp intr 8/15/90 open
EVGAB CIXCD diag Test 1, subtest 0, err 19; unexp intr
030 Test/jxdi:0 always fails first time 8/14/90 open
029 VDS XMI diag failures due to multi-cpu interrupts 8/14/90 open
028 EVKAG vector diag running multiple passes 8/14/90 closed
027 EVKAG, EVKAH vector diags - attach KAWWW, not KA900 8/14/90 open
026 EVCLB XJA diag running multiple passes 8/14/90 closed
025 EVCLB XJA diag margin testing with clock freq=532 MHz 8/14/90 open
024 EVKAR test 42(MOVC3), 43, 50, 51 failures 8/14/90 closed
023 IO init; EVCLB XJA diag. CIXCD XMI slot config prob. 8/14/90 closed
022 Init/kernel (IO section); SCU fails to respond 8/14/90 open
021 IO tests with clock margining 8/14/90 open
020 SPU to VMS DMA bug 8/14/90 open
019 VCS hang bug 8/14/90 open
018 Automatic SNAPSHOT bug 8/14/90 open
017 Incorrect TAG1.LOD file. HALT does not work. 8/14/90 closed
016 Missing A-Latch problem causes IO and system hangs. 8/14/90 open
015 Simultaneous network and tape transfers using DEBNT 8/14/90 closed
014 SPU handshake parity error 8/14/90 open
013 UETP bug check - ECC single and double bit errors 8/14/90 open
012 UETP bug check - ACP failure to read mailbox 8/14/90 open
011 Powerfail SPU fails, software state not saved 8/14/90 open
010 Powerfail BBU test, open cable 8/14/90 open
009 Test/structure vreg; transient cell failure first pass 8/14/90 open
008 Test/structure/ibank2; scan failure, ring data corrupt 8/14/90 open
007 Test/structure tbrams; data mismatch, bit 37 stuck @ 1 8/14/90 open
006 Test/structure LRU; structures temporarily not tested 8/14/90 open
005 Test/structure wrtq; used to fail, still tested? 8/14/90 open
004 Scan Pattern Diagnostic (SPD); observe many errors 8/14/90 open
003 Scan Pattern Diagnostic (SPD); Vbox error if no Vbox 8/14/90 open
002 Show sja; MMU present mask=00 if bank_mask=0F 8/14/90 open
001 Booting console, RD54 disk problem; two reversed wires 8/14/90 open
*****************************************************************************
|
| 78.32 | RFT problems and fixes | KERNEL::WRIGHTON | odd numbered release = bug insert | Sat Aug 25 1990 00:34 | 35 |
|
Chaps,
There are a few problems with RFTS on 9000 systems that may
cause the console and or system to hang. The problems are ...
1) You can't run the image [CONSOLE]RFTS.EXE from the SPU,
it causes the console to hang.
2) You can only downline load the RFT process (ie plant the
seed) if the console is running at 1200 baud,the seed will
no plant properly if the baud rate is 9600.
3) RFT> RECEIVE works fine ...
4) RFT> SEND hangs the console and the system.
Fixes ...........
a) Don't run [CONSOLE]RFTS.EXE
b) Don't plant the seed unless the console is at 1200 baud
Do >>> SHO CONSOLE to check
c) To fix the SEND problem do
RFT>SET NOON
--------
RFT>SET/BUFSIZ=128 (it was 300)
--------------
In this way the transfer time is a bit slower but it works.
Dave W
|
| 78.33 | JXDI Timing Problem | KERNEL::WRIGHTON | odd numbered release = bug insert | Sat Aug 25 1990 00:35 | 161 |
|
+---------------------------+ TM
| | | | | | | | I N T E R O F F I C E M E M O
| d | i | g | i | t | a | l |
| | | | | | | | ****************************************
+---------------------------+ *HPS TECHNOLOGY, RESEARCH & ENGINEERING*
****************************************
TO: DISTRIBUTION DATE: 23-AUGUST-1990
FROM: JOHN BURROUGHS
TEL.: 297-4435
LOC.: MR01-3/T4
ENET: HPSTEK::BURROUGHS
SUBJECT: SCHEDULE FOR JXDI CABLE PROBLEM RESOLUTION
SUMMARY
--------
Because of a single unexpectedly long data path signal
between the XJA in the XMI card cage and the SCU, current 9000s may
have a legitimate operating frequency where improper operation will
occur. There are 3 solutions to this problem, very short term, short
term, and long term. These need to be applied to systems in BTO and
systems in the field as appropriate. The procedure described is valid
for systems with one XMI card cage. Solutions for multiple XMI card
cages will be published in a short time.
The question of mechanical seating of the connectors under all operating
conditions is being separately investigated and will be complete by Sept.
21, 1990.
SOLUTION MATRIX
-----------------
The fundamental cause of the problem is a logic bug. As this can
not be corrected for sometime (at System Rev C1) alternative solutions are
required. These fall into two categories: very short term, which means as
quickly as possible, and short term, which is dependent upon new cables
from the vendor. It is estimated that these will begin to arrive Sept 10.
The long term solution is the correction of the logic bug.
It is ABSOLUTELY IMPERATIVE to perform the "XJA Clock Cable Phase
Test" herein described before making any changes to the system. Failure to
do so may make a working system into a nonworking system. This procedure is
valid for systems with one XMI card cage. A procedure for multiple XMIs
will be published in sufficient time to allow BTO to configure these
systems properly.
With the "Very Short Term" fix in place Clock Margins should be set
between 488 mhz to 512 mhz. This insures adequate margin for 500 mhz
operation. Failures may occur beyond these limits. For both the "Short Term"
and "Long Term" fixes normal Clock Margins may be employed.
The matrix on the next page describes the assemblies involved and the steps
to be taken correct the problem.
Systems that exhibit the JXDI timing problem are expected to fail at
a single master clock frequency near 500 MHz (ie 488-512 MHz). A system
failing for this cause can be corrected by the "XJA Clock Cable Phase Test"
described below.
==============================================================================
| |
Assembly| Cause | Corrective Action (dates are subject to part
| | availablity)
| |-----------------------------------------------------
| | |Short Term | Long Term
| |Very Short Term|Est. Start 9/10| (System Rev C1)
==============================================================================
| | | |
MCU | Logic Bug | No change | No change | Phase in new MCU
(DAX) | | | |
| | | |
------------------------------------------------------------------------------
| | | Retrofit ALL existing and new builds
JXDI | Long | Continue use | as follows:
Cable | Electrically | of 17-01786-01|
| | | Replace All 17-01786-01 cables with
17-01786| | Rev B01 | 17-01786-02
| | | Replace All 17-02454-01 cables with
----------------------------------------| Rev C01
XJA | Long |1.Do XJA Clock | *****************************
Clock | Electrically |Cable Phase | * BOTH CABLE TYPES MUST BE *
Cable | & |Test attached | * *
| JC Conn |2.Configure XJA| * REPLACED AT THE SAME TIME *
17-02454| Phased Wrong |connectors per | *****************************
-01 | |XJA Clock Cable|
| |Phase Test |
------------------------------------------------------------------------------
------------------------------------------------------------------------------
FREQUENCY |488 to 512mhz | Normal Margins
MARGIN | |
-------------------------------------------------------------------------------
XJA Clock Cable Phase Test:
1. Power off system
2. Disconnect the 17-02454-01 Cable from the MCM and XJA0 ends
3. With a DVM (ohmmeter) Locate the JB and JC connector
(see cable schematic below)
4. Tape over the JB connector
5. Reinstall JA to the MCM and JC to the XJA0
6. Power on system
7. Reboot, etc.
Cable schematic:
JA 1-----------------------------1 JB
JA 3-----------------------------3 JB
JA 5 open
JA 7-----------------------------1 JC
JA 9-----------------------------3 JC
All remaining pins are ground and bussed together
|-----|
| 1 2 |
| 3 4 | As viewed from the cable connector,
key || 5 6 | mating end view
| 7 8 |
| 9 10|
|-----|
17-02454-01 Cable configuration
JB
____
| | Normally
| |====> connects to XJA0
/--| |
JA / | |
____ / ----
To | | 17-02454-01 Assy /
MCM <== | |-----------------------------/
| |-----------------------------\
| | \ JC
---- \ ____
\ | |
| | \__| |====> Connect to XJA0
| | | |
| | | |
| | ----
| |
| |
SCU ------->|<----CPU Cabinet------>|<----- I/O Cabinet
| |
|
| 78.34 | SPU Backup Utility | KERNEL::WRIGHTON | odd numbered release = bug insert | Sat Aug 25 1990 00:41 | 52 |
|
+---------------------------+ TM
! ! ! ! ! ! ! ! i n t e r o f f i c e
! d ! i ! g ! i ! t ! a ! l !
! ! ! ! ! ! ! ! m e m o r a n d u m
+---------------------------+
Date: 8/23/90
To: 9k Technical Dist. From: Butch Leitz
Dept: HPS/C CSSE MEG
DTN: 297-4257
LOC/MAIL STOP: MRO2-3/5E, Pole 2C
Email: HPSMEG::LEITZ
cc:
Subject: 10.4 Status and BACKUP Utility on the SPU
Many people have been asking about how the SPU software is going to
updated in future releases, or how to restore or backup their RD54.
As you should already know, the official release kit for the SPU
software will contain four TK50 tapes. Two of these contain the SPU
system software, boot path diagnostics, and support files (command
files, etc). The third tape contains diagnostics available under
license. I believe this is where the scepter pattern diag files
will be found when they are stable and effective enough to be
released. The fourth tape will be Digital proprietary and will
contain the SDD rules files, EWKCA, and the INSTALL utility for use
with EWKCA. Some of you have already seen a preliminary version of
this tape.
The 10.4 release kit is being processed via an "interim" field test
release mechanism. It does not follow what will be the official
release process, so the packaging will be such that there may only
be two or three tapes shipped to you. I will send out specifics
about 10.4 when available. The master tape set is being created now
prior to final review by CSSE and engineering. Then upon approval,
tapes will be duplicated and shipped to you. The master kit will be
under verification by CSSE and engineering starting friday 8/24/90
and should start to ship to the field by the end of next week
pending approval and tape duplication.
The SPU BACKUP utility makes it's debut on the 10.4 kit. Read
MRCSSE::[PUBLIC]BACKUP_HELP.TXT for more information on how to use
SPU BACKUP. The building of a boot tape isn't described, nor do we
have a written "backup procedure" per se, but how to do this will
be made available shortly (I'll send out mail when I've updated
BACKUP_HELP.TXT with verbiage describing boot tape creation.)
|
| 78.35 | Demna problems | KERNEL::WRIGHTON | odd numbered release = bug insert | Sat Aug 25 1990 00:45 | 37 |
| From: COMICS::LOANE "Chris Loane, U.K. Customer Services Support 24-Aug-1990 2040" 24-AUG-1990 20:38:49.86
To: WINN,BUTT,AQUARDC,MEGARITY
CC:
Subj: I: DEMNA and slow response; FYI
********************************************************************************
Digital Internal Use Only
********************************************************************************
If this looks like something you're seeing contact Jack Davisson at
CSC32::DAVISSON to get more info.
DECNET transfers to a 9000/DEMNA work very slowly. This was observed
by SQM (QAR #1307), in CLD CXO_05970 and by myself in MSEE yesterday.
I talked with Rob Frick (DTN 471-5655) who looked in detail at the CLD
problem.
Rob Frick noted that the problem occurred only on receive and other
protocols (SCA, LAT ...) were not affected.
Looking at it in MSEE showed a few other things. That it is DEMNA
specific (a DEBNI worked fine). That it is not 9000 specific (a Rigel
showed up the problem). That it is 5.4 specific (the same test program
did not fail with 5.3, this from the months of DEMNA testing done by
MSEE with 5.3 using this DECNET test program). Also, the problem
wasn't noticed until 5.4-4HW and later. MSEE has 4G1 but didn't
do any testing on earlier 5.4 releases.
What it looks like is that DECNET transfers into the system lose packets
internal to DECNET. The DEMNA doesn't lose them, the driver doesn't
either. DECNET may actually not lose them - it may mishandle them in
such a way that the observable effect is the same.
The only (driver observable) difference I know of between DEMNA and DEBNI
operation is the speed which means queueing in transmit and receive
processing will be different.
|
| 78.36 | CIXCD Update procedure (+hints/kinks) | KERNEL::LOANE | Once upon a time in a TU45! | Thu Aug 30 1990 12:15 | 140 |
| ___ ___ ___ ___ ___ ___ ___
| | | | | | | |
| d | i | g | i | t | a | l | I N T E R O F F I C E M E M O
|___|___|___|___|___|___|___|
To: Distribution Date : August 20, 1990
From : Joe Mellone
Dept : ISB
Ext : 297-4682
Loc/MS : MR01-2 S10/KL18.6
Enet : IOENG::MELLONE
SUBJECT: CIXCD Software Release Area Update Notification
A software release area is available which contains all of
the required CIXCD software components, needed for diagnostic
and functional operations. The below listed files can be
retrieved by using the following procedure call:
$ @IOENG::XMVDSK:[CIXCD.DIAG]RETRIEVE
The 'retrieve' procedure will prompt you for the destination
directory and whether you want diagnostic or operational
files. If the destination directory is not specified, the
procedure will use your default directory. If diagnostic
or operational is not specified, all files will be retrieved.
A new feature was added to the retrieve procedure, which allows
the copy of just a single file. Use the 's' option when prompted
for diagnostic, operational or single files.
COMPONENT CREATION DATE VERSION NUMBER
--------- ------------- -----------------------------
>CIXCD.BIN 16-AUG-1990 V1.00
ELSAA.EXE 16-JUL-1990 X13.2-2008
ERSAA.EXE 06-JUL-1990 13.1-893
EWSAA.EXE 17-AUG-1990 13.2-1221
>DIAGBOOT.EXE 17-AUG-1990 n/a
EVGEA.BIN 04-APR-1990 V0.01
>EVGEA.EXE 14-AUG-1990 V2.1
>EVGEA.HLP 14-AUG-1990 n/a
EVGEB.EXE 16-JUL-1990 V2.0
EVGEB.HLP 16-JUL-1989 n/a
EVGAA.EXE 18-JUL-1990 V6.1
EVGAB.EXE 18-JUL-1990 V6.1
EVGAC.EXE 18-JUL-1990 V1.1
VMS T5.4-4HW 11-JUL-1990 Available from VMS
HYPERION.EEROM 10-MAY-1990 V4.E
CALYPSO.EEROM 10-MAY-1990 V3.D
RIGEL.EEROM 07-MAY-1990 V1.FE
---------------------------------------------------------
>=New version
COMPONENT DESCRIPTIONS :
CIXCD.BIN = Microcode file
ELSAA.EXE = Calypso/Hyperion Diagnostic Supervisor
ERSAA.EXE = Rigel Diagnostic Supervisor
EWSAA.EXE = Aridus Diagnostic Supervisor
DIAGBOOT.EXE = Diagnostic bootstrap file
EVGEA.BIN = CIXCD Repair Level Diagnostic Test Microcode
EVGEA.EXE = CIXCD Repair Level Diagnostic / Loader Program
EVGEA.HLP = CIXCD Repair Level Diagnostic VDS Help File
EVGEB.EXE = CIXCD Microcode Load Utility
EVGEB.HLP = CIXCD Microcode Load Utility VDS Help File
EVGAA.EXE = CI Functional Diagnostic (part 1)
EVGAB.EXE = CI Functional Diagnostic (part 2)
EVGAC.EXE = CI Multi-Node Diagnostic
HYPERION.EEROM = Hyperion CPU eeprom microcode patch file
CALYPSO.EEROM = Calypso CPU eeprom microcode patch file
RIGEL.EEROM = Rigel CPU eeprom microcode patch file
COMPONENT CHANGES SINCE LAST RELEASE :
CIXCD.BIN :
On 9000 series machines, the CIXCD could not be used as the boot
device in XMI slots 4 and C. This problem was fixed with a new
version of the CIXCD self-test microcode. A couple of bug fixes
were also made to the functional microcode.
EVGEA.EXE :
A correction to the BAR_DCB init section to support extended module
revisions was done. A correction to properly decode default file
name after executing START/SECT=MFG was done. Changing the definition
of EVENT FLAG 1 from INHIBIT external loopback tests to ENABLE
external loopback tests was chnaged as requested.
EWSAA.EXE :
The previous version would not boot VDS via the CIXCD. The problem
was found a fixed in this version. A new DIAGBOOT.EXE image is
also needed in conjuction with this new supervisor.
COMPATABLE HSC MICROCODE REVISIONS :
HSC70 Version (Y50D)
HSC50 Version (YB02)
CURRENT KNOWN PROBLEMS :
VDS will not boot correctly through the CIXCD when the
NODE specification in the boot string contains a failover
CI address. It will boot, only when the correct HSC node is
in bits 15:8, not when the correct HSC node is in bits 7:0.
INSTALLATION/USAGE NOTES:
All CIXCDs currently in use must be updated with the latest
microcode version. QARs posted against previous versions
will be answered "microcode out-of-rev" and closed.
On 6000 series machines, the CIXCD will only operate in slots
1-4 and B-E.
When installing the header assembly, needed for Rev E modules,
make sure that all pins are plugged into the connector. The
connectors are not keyed, and it is possible to plug the header
card in one position to high or one position to low.
Take note of the hardware revision held in XDEV<24:16>. The
format of this field has changed and must be reprogrammed with
section init_dcb of EVGEA. The old format displayed an E02 module
as "A2", the new format will display an E02 module as "52".
HYPERION/CALYPSO/RIGEL.EEROM CPU MICROCODE FILES :
Three files have been added to the directory. These files can be
used to patch the cpu microcode on the respective processor. This
updated cpu microcode will enable the cpu to recognize the CIXCD
as a valid I/O device, thus allowing the CIXCD to function as the
primary boot device.
A command procedure "CREATE_EEROM_TAPE.COM" can be used to create
a patch tape for the respective processor. This procedure is located
in the release area for general use.
|
| 78.37 | 5.4 and the 9000 | KERNEL::ODONNELLR | | Tue Sep 04 1990 19:29 | 1136 |
| From: CLADA::MEDLEY "PADDY MEDLEY, DTN: 784-3331, GAE, GALWAY 04-Sep-1990 1807" 4-SEP-1990 18:20:10.37
To: @SYS_SUPPORT,@CSC_ENG
CC:
Subj: VMS 5.4 cover letter.
From: MACNAS::JWAFER "JOHN WAFER, ISBS QUALITY, 822-2243" 4-SEP-1990 15:02:23.65
To: NOCONNOR,CLADA::ERROL,JHESNAN,CLADA::MEDLEY
CC:
Subj: VMS Letter and restrictions
From: HYEND::ZAGAME "ISB Marketing DTN 297-5026 04-Sep-1990 0825" 4-SEP-1990 13:29:38.01
To: @[.EUROPE.FIELD_TEST]UPDATE.DIS
CC:
Subj: Draft of VMS V5.4 cover letter - describes features and restrictions
Attached is a draft of the letter that will go out with VMS V5.4. It
describes what new features are in the release, plus it also covers
the restrictions which may apply to your VAX9000 system. I'm in
Cannes, but will try to read my mail as often as possible in case
you have any questions.
best regards,
- Steve
----------------------
Cover Letter for VMS Version 5.4
AV-LX-TE
Digital is pleased to provide VMS operating system Version 5.4.
This new version of VMS extends and enhances the VMS operating
system by offering support for distributed transaction process-
ing, enhanced data availability and integrity, and fault tol-
erant computing. This version also provides support for vector
processing and new VAX systems.
For more information about these enhancements, see the VMS
Version V5.4 New Features Manual.
Upgrade and Installation
The VMS Version V5.4 Upgrade and Installation Manual contains
step-by-step instructions for upgrading and installing VMS
Version 5.4 and VMS DECwindows.
To support full VMS, a system disk of greater than 100 MB is
recommended. When a smaller disk is used, tailoring is required
prior to installing some VMS options. Refer to the VMS Ver-
sion 5.4 Upgrade and Installation Manaul for information on
tailoring.
Please note that the VMS Version 5.4 upgrade procedure will
restore your site specific files (e.g. SYSTARTUP_V5.COM) during
the last phase of the upgrade. However, there are two files,
SYSHUTDOWN.COM and SYSECURITY.COM, which are not restored. Your
site specific version will be the next lower version of these
files. Please take steps to preserve these files before starting
the upgrade.
Kit Contents: Media
Enclosed is the VMS Version 5.4 media. For new customers, Ver-
sion 5.4 is distributed on the following pieces of media:
o Nine-track, 1600 bpi magnetic tapes
o TK50 tape cartridges
o Compact Disc
Kit Contents: Documentation
The complete VMS Version 5.4 Documentation Set contains over
100 manuals describing every aspect of using the VMS operating
system for daily operations, system management, and programming.
The documentation set is organized into several kits to provide
a wide range of choices about the level of information desired.
The Base Documentation Set provides users who do not require the
complete documentation set with essential and frequently used
reference information.
For users who need complete information, the Extended Documen-
tation Set provides introductory and reference information on
every VMS resource. It contains three subkits-a subkit for each
major type of user (general, system manager, programmer)-and an
Obsolete Features Kit.
The Release Notes Kit includes the cover letters, Software
Product Descriptions, and release notes for VMS Version 5.0
through VMS Version 5.4, the Overview of VMS Documentation, and
the VMS Version 5.4 New Features Manual.
The upgrade and installation supplements provide information
on the features of VAX computers and step-by-step instructions
for installing VMS software and for frequently performed system
operations. The VMS Version 5.4 Upgrade and Installation Manual
provides step-by-step installation and upgrade procedures for
VMS Version 5.4 for all VAX computers. This manual must be used
with the upgrade and installation supplement for individual VAX
computers.
2
The VMS DECwindows Programming Kit is an optional kit which
provides the information necessary to develop DECwindows appli-
cations.
The following manuals are new for VMS Version 5.4:
VMS Device Support Reference Manual
VMS Upgrade and Installation Supplement: VAX 9000 Series
VMS Volume Shadowing Manual
Display PostScript System Perspective for Software Developers
Display PostScript System Client Library Reference Manual
PostScript Language Extensions for the Display PostScript
System
PostScript Language Color Extensions
Display PostScript System pswrap Reference Manual
PostScript Document Structuring Conventions Specification
Version 2.1
VMS DECwindows Display PostScript System Programming Supple-
ment
Introduction to the CDA Toolkit
Guide to Creating Compound Documents with CDA
Complete documentation for VMS is also available on the VMS
Online Documentation Library compact disc for use with the VMS
DECwindows Bookreader.
Documentation on the VMS Compact Disc The VMS Version 5.4 com-
pact disc includes the following two manuals along with the
VMS Version 5.4 software: the VMS Version 5.4 Release Notes
and the VMS Version 5.4 Upgrade and Installation Manual. Both
manuals are in ASCII text format, readable on your terminal,
and also in DECwindows Bookreader format, readable with the
VMS DECwindows Bookreader. To read the VMS Version 5.4 Release
Notes and the VMS Version 5.4 Upgrade and Installation Man-
ual using the Bookreader, first copy the following files from
the [DOCUMENTATION.V054] directory on the compact disc to the
SYS$COMMON:[DECW$BOOK] directory on your system:
o VMS_V54_RELNOTES.DECW$BOOK
3
o VMS_V54_INSTALL_UPGRADE.DECW$BOOK
o LIBRARY.DECW$BOOKSHELF
Then, follow the directions for using the Bookreader in the VMS
DECwindows Desktop Applications Guide.
VMS Volume Shadowing Phase I and Phase II
Digital provides a volume shadowing product with two methods
for performing shadowing operations. VMS Volume Shadowing Phase
I provides for centralized shadowing on VMS systems using Hi-
erarchical Storage Controllers (HSCs) with compatible Digital
Standard Architecture (DSA) disks.
VMS Volume Shadowing Phase II allows shadowing on the same
configurations as Phase I plus extends the benefits of volume
shadowing to all DSA disks. Refer to the VMS Volume Shadowing
Software Product Description 27.29.07.
VMS Volume Shadowing Phase II is initially restricted in VMS
Version 5.4 to VAXft 3000 standalone configurations, pending
further qualification of the product. Digital Equipment Corpo-
ration expects to significantly expand the range of supported
configurations after successful qualification.
CI Architecture Extensions
Extensions to the computer interconnect (CI) architecture allow
the application of multiple CI interfaces per CPU and multi-
ple star couplers per VAXcluster system. These extensions make
possible VAXcluster systems with many times the data through-
out capacity of current VAXcluster systems with a single star
coupler. VMS Version 5.4 will initially support up to four CI
interfaces per CPU and two star couplers per VAXcluster system.
DSF32 Support for the VAXft 3000 Computer
Support for the DSF32 synchronous DDCMP communications option
specifically for the VAXft 3000 has been added with DECnet-VAX
and VMS Version 5.4.
4
DECnet-VAX Device Support Information
In the next 6 to 12 months, VMS, DECnet-VAX, and VAXcluster
software support for the DEQNA Ethernet adapter will be with-
drawn. For 24 months after that, the DEQNA adapter will be ac-
cessible only by user applications using the $QIO interface to
the Q-bus Ethernet device driver (XQDRIVER). During that time,
when the XQDRIVER recognizes the device as a DEQNA adapter, a
console message will be printed specifying that the DEQNA is
an unsupported device. However, these user applications will
continue to work. At the end of the 24-month period, the DEQNA
Ethernet adapter will no longer be accessible.
Digital recommends that customer implementations that use the
DEQNA upgrade as soon as possible to either the DELQA or the
DESQA, whichever is appropriate for the system. Customer upgrade
options currently are available from DECdirect. Contact your
local Digital sales office for more information.
Also, at the next major functional ("dot") release of VMS and
DECnet-VAX, functional support for the DMV11 synch comm de-
vice, and the KMV/KMS/K* custom synch comm devices also will be
dropped.
As of the next release, customers may continue to use customer
developed drivers to access the above devices, however, DECnet-
VAX and VMS will no longer use these devices for any native
communication operations. Service contracts will be honored on
the hardware for 12-24 months after the next release, however,
at some point during the 12-24 month period, all support for the
devices will be dropped. See the VAX Wide Area Device Drivers
SPD (xx.xx) at the next release for more detailed information.
Digital recommends that customer implementations that use these
synch comm devices upgrade as soon as possible. Customer upgrade
options currently are available from DECdirect. Contact your
local Digital sales office for more information.
DECnet-VAX V5.4 does not support the CIXCD adapter. Support for
this adapter is planned for a followon release of DECnet-VAX.
5
Also, as of V5.4, CNDRIVER support for all other CI adapters is
currently limited to single adapter operation. Multiport support
is planned for a follow-on release of DECnet-VAX. This affects
any operations which use CNDRIVER.
PHONE Utility Update
The VMS PHONE utility will be removed from the base VMS oper-
ating system in a future major release, currently planned for
12 to 15 months from the present time. Digital intends to pro-
vide executable source code to the DECUS library at that time.
Customers will be able to get support for the PHONE utility
for the VMS version previous to this major release for up to 12
months after FCS of that major release. Digital recommends that
customers plan accordingly.
SYSGEN Parameter Values and the VAX 9000 Series
In order to maximize the performance of the VMS file system
caches on the VAX 9000 series, Digital recommends the following
minimum SYSGEN parameter values:
ACP_HDRCACHE: 1500
ACP_DIRCACHE: 1500
ACP_DINDXCACHE: 300
ACP_MAPCACHE: 300
These caches are allocated from the system-wide paged pool.
Therefore, in order to maintain the appropriate relationship
among the various SYSGEN parameters, you should add the follow-
ing records to SYS$SYSTEM:MODPARAMS.DAT:
MIN_ACP_HDRCACHE = 1500
MIN_ACP_DIRCACHE = 1500
MIN_ACP_DINDXCACHE = 300
MIN_ACP_MAPCACHE = 300
Then, invoke AUTOGEN with feedback. For information on AUTOGEN,
see Chapter 6 of the Guide to Setting Up a VMS System.
6
Layered Product Caution for Remote System Manager 2.2 Server
VMS Version 5.4 corrects some previously inconsistent error re-
turns to the AUTHORIZE facility. As a result, MANAGE> INSTALL
OPERATING_SYSTEM commands fail when AUTHORIZE attempts to add
a proxy account for the client a second time. The failure in-
formation is returned when you use /NOTIFY. It will occur the
second time an INSTALL OPERATING_SYSTEM command is issued for a
new client.
If you have the RSM Server installed and use this facility, you
can work around the problem with the following command:
MCR AUTHORIZE REMOVE /PROXY client-name::RSM$CMANAGER
Use this command on the RSM server before performing INSTALL
OPERATING_SYSTEM commands. For a patch to this problem, contact
Digital Support channels.
Correction to VMS V5.4 Release Note: ALL-IN-1 Shareable Images
Requirement for CDA Support
VMS Version 5.4 provides two new shareable images that are ac-
tivated by the Compound Document Architecture (CDA) support for
ALL-IN-1 Version 2.4. ALL-IN-1 is a privileged image; therefore,
any images activated by ALL-IN-1 must also be installed as known
images.
The new shareable images for VMS Version 5.4 are not installed
as known images. If you require CDA support for ALL-IN-1 Version
2.4, you must install the two new shareable images as known im-
ages. If you do not require CDA support, no action is required.
To install the two shareable images for CDA support, add the
following command lines to your ALL-IN-1 site startup file,
OA$SITE_BUILD_SHARE:A1V24_SITE_START.COM:
$ CREATE SYS$SHARE:XDPS$DPSLIBSHR.EXE
$ INSTALL CREATE SYS$SHARE:XDPS$DPSLIBSHR.EXE
$ INSTALL CREATE SYS$SHARE:XDPS$DPSCLIENTSHR.EXE
7
Release Notes for the VAX 6000-500 Computer
When booting (STABACKUP and VMS) a VAX 6000-500 system with 512
MB of memory, you must perform a conversational boot and change
the SYSGEN parameter PHYSICALPAGES to 1047552. For example:
>>> B/R5:1 du0
SYSBOOT> SET PHYSICALPAGES 1047552
SYSBOOT> CONTINUE
This problem will be fixed in the next maintance release of VMS.
After your system is up and running you may wish to change the
SYSGEN parameter PHYSICALPAGES to 1047552 to avoid stopping in
SYSBOOT during each reboot. For example:
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN> SET PHYSICALPAGES 1047552
SYSGEN> WRITE CURRENT
SYSGEN> EXIT
Due to a problem in Version 5.4, primary switching on the 6000
family of VAX computers will not work. When a STOP CPU command
is issued on the primary CPU, the command will fail due to a
lack of qualified CPUs to become the new primary one. This will
be fixed in the next maintance release of VMS.
Powerfail warm start functionality will not operate correctly
under Version 5.4 for the VAX 6000-500 computer. This will be
fixed in the next maintance release of VMS.
�Digital Equipment Corporation. 1990. All rights reserved.
___________________
[TM] The following are trademarks of Digital Equipment Corporation:
DDCMP, DECnet-VAX, DELQA, DEQNA, MicroVAX, Q-bus, VAX, VAX-
cluster, VAXft, VAXstation, VMS, VMS/ULTRIX Connection, XMI,
and the DIGITAL Logo.
8
APPENDIX A
INFOSERVER 100 INFORMATION
An InfoServer 100 is a disk storage server that efficently
transfers data between compact disc drives connected to the
server and remote network client systems. A server consists
of memory, an Ethernet interface, some number of compact disc
drives and software to control the server.
The VMS InfoServer Client software support, available in this
release, allows a remote VMS network client to communicate with
an InfoServer 100 storage server. The VMS InfoServer Client
(VIC) enables shared access to any compact disc drive connected
to an InfoServer 100.
The VMS InfoServer Client software provides support for:
o Initial System Loading (ISL) via the Ethernet: This lets you
install the VMS operating system from a compact disc via the
Ethernet. You place a VMS compact disc distribution kit in
an InfoServer 100 and then boot the CPU on which you want to
install VMS.
o Compact Disc access via the Ethernet: This function allows an
installed VMS system to access compact disc volumes available
on an InfoServer 100.
o VMS Layered Product Installation: By placing a VMS Software
Consolidation Compact Disc in an InfoServer 100, an installed
VMS system can install VMS Layered Products via the Ethernet.
InfoServer 100 Information 9
o Online Documentation Access: By placing a VMS Online Doc-
umentation Library Compact Disc in an InfoServer 100, an
installed VMS workstation can display the VMS and VMS DECwin-
dows documentation set.
Each compact disc that you insert in an InfoServer drive is
available to a remote client system as a service. Each InfoS-
erver service has a service name. A VMS compact disc is identi-
fied by its volume label. For example, the VMS V5.4 compact disc
distribution kit has a volume label of VMS054. When you wish to
access this compact disc, specify VMS054 as the service name.
Service names are used by the InfoServer 100 to identify all
disk volumes. For more information about changing service names,
see the InfoServer 100 Installation and Owner's Guide and the
VMS LAD Control Program (LADCP) Manual.
A.1 Initial System Loading (ISL)
Initial System Loading is a means of loading the operating
system software onto your target system disk. The VMS InfoServer
Client software supports the Initial System Loading of the
following VAX computers:
o VAX 6200 with console rom version 5.0
o VAX 6300 with console rom version 6.0
o VAX 6000-400 with console rom version 2.0
o VAX 6000-500
If you do not have the correct console rom version, see your
Digital sales representative for an upgrade.
10 InfoServer 100 Information
A.2 VMS InfoServer Client Installation: Startup and Use
After installing an InfoServer 100 you will need to activate
the VMS InfoServer Client software to allow a remote VMS client
system to access the InfoServer 100 hardware.
Once your system is up and running and you have logged into
the SYSTEM account you can immediately start the InfoServer
Client software or you may wish to modify the system startup
command file to always start the InfoServer Client software. The
InfoServer Client software shares access to the Ethernet port on
your system.
NOTE
If DECnet is typically started on your system be sure the
InfoServer startup procedure is executed after your DECnet
startup procedure has completed.
The InfoServer Client software requires a node name be defined
for the system it runs on. The InfoServer Client software will
attempt to obtain the system node name from two locations. The
first is the logical name SYS$NODE which is defined by having
DECnet started. The second is the SYSGEN parameter SCSNODE. If
DECnet is not used on your system, define the SYSGEN parameter
SCSNODE before executing the InfoServer Client startup command
procedure. For more on SYSGEN, see the VMS System Generation
Utility Manual.
NOTE
If the node name of you system cannot be found, the InfoS-
erver Client software will not start.
If you wish to have the InfoServer Client software started on
your system after each reboot, be sure your system has a node
name defined and that you have removed the comment character(!)
from the command lines in SYS$MANAGER:SYSTARTUP_V5.COM which are
used to call the ESS$STARTUP command procedure.
InfoServer 100 Information 11
To manually start the InfoServer Client software, execute the
InfoServer startup command procedure located in the SYS$STARTUP
directory. This procedure can be executed only from a privileged
account. Start the procedure by typing:
$ @SYS$STARTUP:ESS$STARTUP CLIENT
The InfoServer Client startup command procedure accepts one
optional parameter, "CLIENT". This parameter enables the loading
of the InfoServer client driver, ESS$DADDRIVER.EXE, and the
InfoServer transport driver. If this parameter is ommited, the
InfoServer transport driver, ESS$LASTDRIVER.EXE, is the only
InfoServer driver loaded.
Other VMS layered products can make use of the InfoServer trans-
port driver and do not require the InfoServer client driver
to be loaded. The startup command procedures for these layered
products will call the InfoServer startup command procedure with
the proper parameters specified for their product.
As the startup procedure executes informational messages are
displayed. The following sequence of messages result from a
successful startup of the software. For more information about
solving problems which may occur during ESS startup, see Sec-
tion A.2.3
%LASTCP-I-VERSION, LASTDRIVER X1.5 is stopped
%LASTCP-I-ADAINIT, Initializing adapter xxx for LASTDRIVER
%LASTCP-I-STARTED, LASTDRIVER X1.5 started on node yyyyyy
%NIC$STARTUP-I-LOADED, DADDRIVER loaded
12 InfoServer 100 Information
A.2.1 How to BIND to a Remote Disk
After the startup procedure has successfully completed you may
BIND to an InfoServer service. An InfoServer service is defined
to be a drive and its volume connected to an InfoServer 100
system. A InfoServer service name is used in a BIND command
to specify a desired InfoServer volume. For ODS-2 volumes the
InfoServer service name is defined to be the volume label of
the volume. For example, the service name for a VMS Version 5.4
compact disc distribution kit is VMS054. In order to BIND to the
VMS Version 5.4 compact disc distribution kit the compact disc
must be inserted into a compact disc drive which is connected to
an InfoServer 100. To execute the BIND command for this volume
you would type the following commands:
$ RUN SYS$SYSTEM:ESS$LADCP
LADCP> BIND VMS054
%LADCP-I-BIND, service bound to logical unit DAD$VMS054 (_DADn:)
LADCP> EXIT
For more information about the BIND command, see the VMS LAD
Control Program (LADCP) Manual.
A.2.2 Mounting a Remote InfoServer Disk
As a result of BINDing to a remote disk, a logical name and
a local physical device name are displayed. The rule for the
creation of the logical name is that the string "DAD$" is used
as a prefix to the service name specified in a BIND command.
The local physical device name is "DADn". Where n is the device
unit number which is incremented with each successive BIND
command.
To mount the DAD device displayed by the BIND command, specify
the logical name created by the BIND command. For example:
$ MOUNT DAD$VMS054 VMS054
InfoServer 100 Information 13
A.2.3 Problems During Startup
If only the first informational message appears during the
execution of the ESS$STARTUP command procedure, check to be
sure that a node name is defined for your system.
A log file is created or appended to each time the ESS$STARTUP
command procedure is executed. This log file is located in the
SYS$MANAGER directory with a filename of ESS$LAST_STARTUP.LOG.
The information at the end of this file may help to determine
why the ESS$STARTUP procedure is not successful starting the
InfoServer.
A.3 Release Notes for InfoServer 100 Software
The following release notes pertain to the InfoServer 100 and
VMS Version 5.4.
A.3.1 Installing VMS from an InfoServer 100
The VMS installation procedure asks you to enter the name of
the device that holds the VMS distribution kit. If you are
installing the VMS operating system from an InfoServer 100
device, enter DAD1 in reponse to this prompt. For example:
* Enter the name of the drive holding the VMS distribution media: DAD1
A.3.2 Device Names
The device code for the DEMNA Ethernet controller on the VAX
6000-200, 6000-300, and 6000-400 series is ET. The device code
for the DEMNA Ethernet controller on the VAX 6000-500 is EX.
14 InfoServer 100 Information
A.3.3 Command Procedure to Test for DECnet Status Before
Starting the InfoServer 100 Software
DECnet is not required for InfoServer 100 software usage. If
you do not have DECnet, you can simply start the InfoServer 100
software with the startup procedure ESS$STARTUP.COM.
However, if DECnet is part of your system, you must make certain
that DECnet is running before you start the InfoServer 100
startup command procedure.
The following is a sample command procedure that you can run to
test whether DECnet is running. This type of command procedure
is located in SYS$MANAGER. First, start DECnet. Then, run the
command procedure from the site-specific startup file SYSTARTUP_
V5.COM.
$! ESS$CHECK.COM
$! Sample Command Procedure to Check Status of DECnet
$!
$! Check to see if the user has DECnet. DECnet is not necessary
$! for the InfoServer 100; however, if the user has DECnet, the
$! InfoServer must be started AFTER DECnet.
$!
$! If the user does not have DECnet running, but still wants to use
$! this command procedure, the user can indicate that DECnet is not
$! on the system by defining the logical name ESS$IGNORE_DECNET with
$! the following DCL command:
$!
$! $ DEFINE ESS$IGNORE_DECNET TRUE
$!
$! This logical name can be defined in the SYSTARTUP_V5.COM procedure
$! before the command line that invokes the InfoServer 100 startup file,
$! ESS$STARTUP.COM.
$!
$ IF F$TRNLNM("ESS$IGNORE_DECNET") THEN GOTO ESS_CONTINUE
$!
$! Check to see if DECnet is running. If DECnet is not running,
$! and the system is not running as a subprocess, loop for 10 minutes to
InfoServer 100 Information 15
$! give DECnet time to start up.
$!
$ decnet_cnt = 0
$net_loop:
$ IF .not. F$GETDVI("NET0","EXISTS") THEN GOTO wait_decnet
$ IF F$GETDVI("NET0","MNT") THEN GOTO decnet_running
$wait_decnet:
$ IF DECNET_CNT .EQ. 0 THEN -
WRITE sys$output "%ESS-I-WAITNET, InfoServer waiting for DECnet to start"
$ WAIT 00:00:10
$ decnet_cnt = decnet_cnt + 1
$ IF DECNET_CNT .GE. 6*10 THEN GOTO give_up_on_decnet
$ GOTO net_loop
$give_up_on_decnet:
$ WRITE sys$output "%ESS-F-NODECNET, InfoServer cannot start without DECnet"
$ EXIT
$!
$decnet_running:
$ WRITE sys$output "%ESS-I-INFO DECnet detected as started"
$!
$ESS_CONTINUE:
$! The user can now start the InfoServer 100 software with the command:
$ @SYS$MANAGER:ESS$STARTUP.COM
$ EXIT
A.3.4 VMS Client Support for the InfoServer 100 Supports Only
Disk Access to Compact Disc Drives
The Client InfoServer 100 software on the VMS operating system
supports only disk access to compact disc drives. Using the VMS
client InfoServer software to access any device other than a
compact disc drive is unsupported.
16 InfoServer 100 Information
A.3.5 Troubleshooting the LAN with MOP Down-line Load Systems
When trouble shooting a LAN for failure of a down-line load
from the InfoServer 100 box, it is not necessary to check for a
MOP partition on the InfoServer box. A MOP partition is not
necessary for a successful down-line loading of an Initial
System Load image.
A.3.6 Multiple Standalone BACKUP Operations from ISL is
Unsupported
When you use the Initial System Load function to install the
operating system, you can successfully issue only one backup
command at the standalone backup prompt. A second backup command
will be ignored and is unsupported for this release. For details
on the Initial System Load Function, see the VMS Upgrade and
Installation Supplement: VAX 6000 Series.
A.3.7 PCSA and InfoServer 100 Interaction
If you use both PCSA and the InfoServer 100 Client software on
your system, you must obtain a new PCSA kit. Older PCSA releases
and the InfoServer 100 Client software for VMS Version 5.4 are
incompatible.
A.3.8 RSM 2.2 and Infoserver 100 Interaction
If you are installing RSM 2.2 on a system with a running Infos-
erver 100 client or if you already have RSM 2.2 installed and
you decide to run the Infoserver 100 Client software, you must
perform the following steps to avoid a system crash during your
installation:
1. Always place the RSM$SERVER_STARTUP.COM file after the
ESS$STARTUP.COM file in your system startup files.
InfoServer 100 Information 17
2. Always replace your RSM$SERVER_STARTUP command file with
the one provided for you in SYS$EXAMPLES. Use the following
command:
$ COPY SYS$EXAMPLES:ESS$RSM$SERVER_STARTUP.COM -
_$ SYS$COMMON:[SYS$STARTUP]RSM$SERVER_STARTUP.COM
Do this after an installation of RSM 2.2 before any RSM
configuring or startup.
3. If RSM 2.2 was already installed on your system, reboot your
system before executing ESS$STARTUP.COM the first time.
These precautions are designed to prevent the possibility of a
system crash during your installation. After these three steps
are done in the order specified, you can proceed normally.
NOTE
ESS$STARTUP.COM checks for the presence of old driver
files used by RSM 2.2 and refuses to start up until those
files are deleted. You will need to delete the following
files:
SYS$LOADABLE_IMAGES:LASTDRIVER.EXE
SYS$LOADABLE_IMAGES:LADDRIVER.EXE
SYS$LOADABLE_IMAGES:LASTCP.EXE
A.3.9 Configuring Hardware for InfoServer 100 Usage
All Ethernet Controllers within a VAX computer must be connected
to the Ethernet and working. If two Ethernet Controller boards
are in a machine but one is not connected to the wire, the
ESS software may or may not work, depending on the hardware
configuration.
18 InfoServer 100 Information
A.3.10 ESS$LASTCP Quota Exceeded Message
The SYSGEN parameter MAXBUF must be set to 2300 bytes for the
SHOW SERVERS command to properly operate from the ESS$LASTCP
utility. When the parameter is incorrectly set an error indicat-
ing Quota Exceeded is displayed.
InfoServer 100 Information 19
APPENDIX B
VAX 4000 MODEL 300 GENERAL INFORMATION GUIDE
This appendix describes Digital's new computer, the VAX 4000
Model 300 (VAX 4000-300) system. It also explains how the VAX
4000-300 differs from the MicroVAX, VAXstation, and VAXserver
3400, 3600, and 3900 Series of systems. Finally, this appendix
describes some of the information needed to install the VMS
operating system on the VAX 4000-300, if it was not factory-
installed.
B.1 General Information
The VAX 4000 Model 300 system is the latest VAX computer in the
MicroVAX, VAXstation, and VAXserver 3400, 3600, 3900 series of
systems. Refer to the VMS Installation and Operations: MicroVAX,
VAXstation, and VAXserver 3400, 3600, 3900 Series manual for
basic system information. Keep this information with that manual
for future reference.
B.2 Features of the VAX 4000-300 System
The differences between other members in the 3400, 3600, 3900
series and the VAX 4000-300 are described in the following
sections.
VAX 4000 Model 300 General Information Guide 21
B.2.1 The Compact Disc Drive
You can add an RRD40 compact disc drive to the VAX 4000-300
system. This read-only drive reads data stored on removable
compact discs.
To determine the device name of an installed compact disc drive
on your VAX 4000-300, enter the SHOW DEVICE command at the
console-mode prompt (>>>). The device name appears on the line
with RRD40.
Refer to Chapters 2 and 4 of the VMS Installation and Opera-
tions: MicroVAX, VAXstation, and VAXserver 3400, 3600, 3900
Series manual for additional information.
B.2.2 VAX 4000-300 Device Names
The VAX 4000-300 system can have the device names listed in
Chapter 4 of the VMS Installation and Operations: MicroVAX,
VAXstation, and VAXserver 3400, 3600, 3900 Series manual. It can
also have the following device names:
________________________________________________________________
Device Name
Device_______________________Device_Name________for_Booting_____
Integral Ethernet con- EZA0 EZA0
troller
RRD40_on_a_KZQSA_____________DKAu_______________DKAu____________
B.2.3 RF Drives
Some VAX 4000-300 systems include RF30 or RF71 drives. Each
drive uses an integrated controller to communicate through the
Digital Storage Systems Interconnect (DSSI) bus. The device
names for RF drives are determined by the configuration of the
two integral DSSI adapters on the CPU module.
22 VAX 4000 Model 300 General Information Guide
The following table shows the device name formats for the RF
drives on the VAX 4000-300 system.
________________________________________________________________
Device Name Formats VMS
for_Booting__________________Device_Name_Formats________________
DIcu or x$DIcu $n$DIAu or x$DIAu
________________________________________________________________
where:
c = controller designation
A is the controller designation for the first DSSI bus
B is the controller designation for the second DSSI bus
u = unit number
x = DSSI node name
__n_=_allocation_class_value_(1_to_255)_________________________
Example device names for booting:
DIA0
DIB1
Example VMS device names:
$1$DIA1
BETTY$DIA0
To determine the boot device name of an RF drive on your VAX
4000-300, enter the SHOW DEVICE command at the console-mode
prompt (>>>).
VAX 4000 Model 300 General Information Guide 23
B.3 Installing the VMS Operating System on the VAX 4000-300
If you have received a VAX 4000 Model 300 system with the VMS
operating system already loaded (factory-installed) on the hard
disk, you should not install this VMS operating system kit. Keep
this media and documentation available, however, in case you
encounter problems with the preinstalled software.
If you encounter problems with the preinstalled software and
need to reinstall the VMS operating system, follow the in-
structions beginning in Chapter 1 of the VMS Installation and
Operations: MicroVAX, VAXstation, and VAXserver 3400, 3600, 3900
Series manual.
Then refer to the VMS Version 5.4 Upgrade and Installation
Manual for additional installation information.
24 VAX 4000 Model 300 General Information Guide
|
| 78.39 | Console problems (pre-release 10.4 only) | KERNEL::WRIGHTON | odd numbered release = bug insert | Thu Sep 06 1990 11:42 | 551 |
|
+---------------------------+ TM
! ! ! ! ! ! ! ! i n t e r o f f i c e
! d ! i ! g ! i ! t ! a ! l !
! ! ! ! ! ! ! ! m e m o r a n d u m
+---------------------------+
Date: 8/31/90
To: 10.4 prereleased sites From: Butch Leitz
Dept: HPS/C CSSE MEG
DTN: 297-4257
LOC/MAIL STOP: MRO2-3/5E, Pole 2C
Email: HPSMEG::LEITZ
cc:
Subject: Base Level 10.4 Notes
The following list represents some of the immediate points of note we
have with the 10.4 kits now in the field that were released to
approximately six systems before it was totally checked out. This kit
is getting repackaged with later and greater versions of diagnostics,
and possibly with a new SYSBOOT.EXE for the SPU the week of September
4th and will be shipped via tapes for updating your RD54 after
verification of the repackaged software. Note that this places a hold
on the TK50 release that was to happen by today for repackaging.
This list may not be all inclusive. I'll update this file in:
MRCSSE::PUBLIC:BL104.NOTES
as issues change and BLITZ'S will be sent if need be.
There is also a new update in MRCSSE::PUBLIC:SPU.QARS of all SPU QARS
that have been entered, whether they are closed, answered, or open. You
can use this as a refresher to previous problems we had under 10.3 that
may have carried over into 10.4.
10.4 NOTES:
Known SPU SYSTEM issues:
------------------------
1) Possible SPU hangs when ^O is used. No detail available as to
what excites this condition. Don't use ^O on the SPU in the current
| 10.4 kit. The new 10.4-A package (to be shipped) will contain a
| new SYSBOOT.EXE which corrects this problem.
2) SET SJA/NODMA no longer needs to be added to the end of SJAINIT.CMD
in [SYSEXE]. This was necessary for 10.3 only.
3) DEFECT LIST handling; code has been added to help stem floods of CRDs
resulting from a KNOWN memory design issue that has caused spurious
CRDs to occur and occasional DBEs. However in some instances you may
still have to periodically delete [000000]DEFECT_LIST.SYS. You'll know
when - you'll see unavailable memory messages when trying to BOOT.
We'll have to keep doing this until further notice (when the memory FCOs
get released).
Known SPU CLI issues:
---------------------
1) SHOW CONFIG/DATE= fails. This gives current configuration always,
so it doesn't work right yet.
2) There is a known failure with symbol translations sometimes causing
buffer overflow messages. There's no work around except to evaluate the
the size of the resulting symbol substitution and try and break it down
into smaller pieces. You should rarely see this unless developing
complex command files for the SPU.
Known SPU Utility issues:
-------------------------
1) RFTS on the SPU does not work. Don't even try and use it.
2) BACKUP:
BACKUP/LIST to a tape (MUA7:[]) will hang the SPU.
BACKUP/LIST to a non-saveset file will hang the SPU process.
BACKUP requires very specific device and file specs otherwise
errors will occur.
BACKUP does not allow single file restoration from a save set,
you must dump all files in a save set to the disk first.
3) SDU:
SDU> LOAD/SNAP will hang the current SPU process. Note this
only occurs with the SPU version of SDU, not the VMS version
that reads SPU snapshot files. That works ok.
Known DIAG and TEST issues:
---------------------------
1) TEST/XJA fails first time, fails sub:31 mod:65 second time, tx
buffer not empty is tried a third time in a row with no inits
in between. Do an i/k to run it again if needed.
Use EVCLB under VDS instead (see below).
2) TEST/STRUCT reports of:
TBRAMS structure test fails intermittently;
VREG structure test fails;
WBUF failing under test/struc/all but ok if run
standalone (test/str=wbuf)
NOTE: These structure tests are not failures verified by CSSE.
3) EWSAA (VDS):
latest rev under test is 1235.
version 13.2(1221) causes failures running EVKAU.
version 13.0(1144) is on the 10.4 release today and should
run ok.
4) CIXCD:
| Note: without correct CICXD ucode loaded, you risk getting
| XJA self test timeouts.
v1/.38 is correct for release. v.22/.38 is on release kit today.
Either way, it should run.
EVGEA 1.4 has to be loaded prior to loading EVGAA or else EVGAA will
fail at T:1,error:9.
Told that new copies of EVGAA and EVGAB are under test now and will
be made available for the updated release of 10.4.
EVGAA and EVGAB are both currently QAR'd.
5) EVSBA:
v7.1 is on the release kit. The latest is v7.2.
6) TEST/JXDI
REV A is in the release kit. This runs through test 37.
REV B is the latest available, running through test 6?.
Test 61 fails unless jxdi.cmp test 60 (zero based=61)
has clock tick bumped to 2.
7a) EVCLB:
10.4 kit contains 1.7, but 1.8 is available.
NOTE: See XJA blitz appended to the end of this memo for more XJA diag notes.
7b) EWCLA:
v1.1 is in the kit, but latest is 1.6.
note that this is NOT "RELEASED" and may provide bogus info.
has been known to pass on bad XJAs, fail on good ones.
NOTE: See XJA blitz appended to the end of this memo for more XJA diag notes.
7c) EWCLD: the powerup self test diagnostic may fail. The failure
may occur in any revision XJA C1, C2, C3. The failures
appears to happen regularly when a CIXCD is in slots 4 or C
of the XMI backplane.
NOTE: See XJA blitz appended to the end of this memo for more XJA diag notes.
9) SPD doesn't provide correct outputs yet, so don't even bother
running it.
Known Miscellaneous issues:
---------------------------
1) from CTY in PIO mode, dir csa1:, ^P to SPU, do work, continue,
VMS proc will look hung...<cr> doesn't work, ^T or ^R don't work.
^Y clears back to DCL.
2) two jobs under VMS doing accesses to CSA1 crash VMS:
job 1: dir csa1:[sysexe]*.*/date/size
job 2: dir csa1:[sysmaint]*.*/date/siz
VMS crashes...
3) Use the SET KEEPALIVE on the SPU to get snap data if an Ebox hang should
occur:
>>> set keep manual
>>> edit [sysexe]sitespecific.cmd
.
def sys$keepalive "manual" <-<< change from OFF to MANUAL
.
>>> edit [sysexe]KAF.CMD !and make sure the following 3 lines exist:
set clock/cpu=all/scu off
set snap trigger
@[sysexe]reboot.cmd
>>>
| Next time a hang occurs, contact support for analysis.
4) ADMIN.CMD is at version 1.6 under 10.4. Version 1.0 was released under
10.3 and failed miserably. Consider 1.6 a minor enhancement, although
| there are many more bug fixes in the release for BL 11, version 3.0
1.6 should be adequate to start generating FRU Return Data, but version 3.0
will be the best version (I'm now debugging one remaining issue with it
before its next release). If it's ready early, we'll send mail and release
it over the net.
From: MRCSSE::TIMA_MGR "CSSE ISBS TIMA Manager" 1-AUG-1990 03:31:52.87
To: MRCSSE::LEITZ
CC:
Subj: GRAM: VAX 9000 XJA Diagnostic Failures (VAX9000 blitz)
Author : BARBARA GILBERT
User type : AIM
Location : TIMA
Vaxmail address : TIMA::GILBERT
The attached information is from the HES CSSE Group.
It contains important information regarding, VAX 9000 XJA DIAGNOSTIC FAILURES.
This information can be found through TIMA STARS
Database: CSSE_TIME_CRITICAL
============================[ Start Message ]==============================
+---------------------------+
| | | | | | | |
| d | i | g | i | t | a | l | TIME DEPENDENT CASE
| | | | | | | |
+---------------------------+
TITLE: VAX 9000 XJA DIAGNOSTIC FAILURES
DATE: 30 July 1990
AUTHOR: Tom Collentine TD #: 000356
DTN: 297-4749
ENET: MRCSSE::TCOLLENTINE CROSS REFERENCE #'s:
DEPARTMENT: HIGH-END SYSTEMS CSSE (PRISM/TIME/CLD#'s)
INTENDED AUDIENCE: PRIORITY LEVEL: 1
(U.S./EUROPE/GIA) (1=TIME CRITICAL,
2=NON-TIME CRITICAL)
=====================================================================
OVERVIEW:
The XJA is a interface adapter between 9000 System Control
Unit (SCU) and the XMI bus. The XJA is preliminary tested by
three diagnostics.
EWCLD - XJA Add-On Selftest Level 4 Diagnostic
EWCLD is written in Intel 8096 Assembly language. EWCLD is
contained in EEPROM on the XJA module and is executed
automatically during the power up phase of the XJA, and
during any XJA Node Resets. EWCLD can be executed manually
through commands issued by a terminal connected to the
terminal port on the XJA module.
EWCLA - XJA Level 4 Diagnostic
EWCLA is written in Macro assembly language. The program is
loaded form the [UCODE] area on the console disk into system
memory when invoked by the TEST/XJA command. This implies
that the Vax Hardcore exerciser should be run successfully
prior to running EWCLA. A brief description of the tests
EWCLA performs is appended to the end of this document.
EVCLB - XJA Level 3 Repair level Diagnostic
EVCLB is a macro diagnostic and runs under the diagnostic
supervisor. EVCLB performs similar tests as described in
EWCLA at the end of this document. In addition EVCLB provides
error call out and expected and received data.
PROBLEM:
EWCLD the powerup self test diagnostic may fail. The failure
may occur in any revision XJA C1, C2, C3. The failures
appears to happen regularly when a CIXCD is in slots 4 or C
of the XMI backplane.
Booting through the XCD from these slots is not usually
possible as VMB/VMS invokes node reset many times during the
boot process. There is also a problem with some XJAs failing
self-test intermittently regardless of an XCD.
Workaround:
Do not configure CIXCDs is slot 4 or C of the XMI bus.
Long Term fix:
Revision D of the XJA.
PROBLEM:
Version 1.x of EWCLA may fail. Test and subtests may vary. An
example follows;
>>>TEST/XJA:0
%CLI-E-XJAFAIL , XJA selftest version 1.1 on XJA 00 has failed
Subtest number 2
Module number: 20
Failing PC: 000007BC
>>>Exam R0
G 00 07bc0214
^ ^ ^_ (Module Number)Subtest number in Decimal
| |_(Subtest #) TEST Number
|_PC
Workaround:
EVKAA The VAX Hardcore diagnostic should be run successfully
before running EWCLA (TEST/XJA). Verify a suspected XJA
failure by running EVCLB before replacing any hardware.
Long Term fix:
Fixed in a future release of EWCLA possibly version 1.3.
PROBLEM:
EVCLB may fail test 1. EVCLB checks the AOST register and
will display a failure if the AOST has failed. Be aware this
failure may be related to the problem listed above under
EWCLD.
Also
EVCLB may fail test 2 intermittently. An example follows;
******** XJA Functional Diagnostic - ZZ-EVCLB - 1.5 ********
Pass 384, test 2, subtest 10, error 2 27-JUL-1990 07:58:45.15
Hard error while testing XJA0: Octaword read lock/Write
unlock failure(s)
1)Unexpected XJA Error Interrupt when attempting to lock
Location 6640 - 667F, just above locked locations 6600 -663F
Workaround:
DO NOT use the above test failures to indict as faulty, and
replace any defective hardware in the VAX 9000.
Long Term fix:
In a future release of EVCLB, possibly V1.8, the test 1
failure will display a AOST failure as a soft failure.
The test 2 failure will be fixed in a future release of EVCLB
possibly V1.8.
Here is a brief description of the tests EWCLA performs.
MODULE 0 (A.K.A test)
This is the initialization section. It is started at
0(X) by the Service Processing Unit or Console operator after
R0 is loaded with the information concerning which XJA(s)
exist on the system, and R1 for the passcount and Test(s) to
execute. This section will then initialize all the XJA
register address locations depending on which bit in R0 is
set. If bit 0 is set, XJA0 is tested. If bit 1 is set, XJA1
is tested, etc. up to bit 3. Once all the XJA's have been
tested, this section then executes a CPU halt. The SPU can
then examine the contents of R0 through R3 for the test
results of XJA0 through XJA3 respectively, and use the
results accordingly (clear if that XJA passed, failure
information if it failed).
MODULE 1:
This module contains the code to check the initial state of
the XJA after Powerup Reset, pattern tests for all XJA
registers that are write and readable, and checks the Powerup
Interrupt and data returned.
MODULE 2:
This module provides code to fully check the operation of the
XJA Force Command Register (FCMD), both defined and undefined
commands.
MODULE 3:
This module contains the test code to check the start- ing
and memory size fields.
MODULE 4:
This module provides test code to check the four XJA IDENT
registers - IDENT4, IDENT5, IDENT6 and IDENT7.
MODULE 5:
This module provides test code to check the XJA Error Summary
Register.
MODULE 6:
Parity Error Insertion Test
XCI_P[0] - XCI_P[2] C/A cycle Parity Error tests
XCI_P[0] - XCI_P[2], data cycle Parity Error Tests
JXDI_P[0] - JXDI_P[1], cycle 0,1,2 Parity Error Tests
MODULE 7:
DMA Pattern, Exercise and Error Test
DMA Pattern test
Multiple DMA exerciser
*** DIGITAL INTERNAL USE ONLY***
=============================[ End Message ]===============================
From: MRCSSE::KRETZ "Charlie Kretz - HES CSSE - MRO2-3/5E - 297-4948 09-Aug-1990 1517" 9-AUG-1990 15:25:11.61
To: @PUBLIC:9K_TECH
CC: ASTON,CARSLN::RIEHL,KRETZ
Subj: VAX 9000 XJA & CIXCD Selftest Interaction Problem
+---------------------------+ TM
| | | | | | | |
| d | i | g | i | t | a | l | INTEROFFICE MEMORANDUM
| | | | | | | |
+---------------------------+
DATE: August 9, 1990
TO: 9K_TECH FROM: Charlie Kretz
CC: VAX 9000 CSSE Group DEPT: HPS CSSE
Bob Aston EXT: 297-4948
Dave Riehl LOC: MRO2-3/5E
ENET: MRCSSE::KRETZ
SUBJECT: VAX 9000 XJA and CIXCD Selftest Interaction Problems
There have been some interaction problems between the XJA and the CIXCD
selftest. These problems caused the XJA to fail self test and depending
on what slot the CIXCD was in would prohibit VMS from booting. All these
problems have been resolved, the CIXCD requires a microcode update to
correct these problems. The latest version of the CIXCD functional
microcode is version V0.22 with selftest microcode version V0.38 corrects
these problems.
The latest version of the CIXCD microcode is accessible on our cluster,
the file name is MRCSSE::NONAME:[PUBLIC]CIXCD.BIN. Some people have
gotten an early release copy of the CIXCD functional microcode version
0.22 that still had the older selftest version V0.37 microcode. While
this provided the latest functional features it did not have the selftest
interaction problems corrected. Unfortunately the diagnostic firmware
revision is not displayed in the XMI XDEV register, only the functional
revision is displayed. You can identify the new microcode file by dumping
or typing the file and looking for the version information. The version
is stored in a human readable format in the first block of the file, see
the example on page 2 (two) of this memo.
In case you do not have the CIXCD Users Guide, I have put a softcopy of
this manual in our cluster. This manual contains information about the
CIXCD on the VAX 6000, which is an unannounced product. Therefore, it can
not to be given or viewed by any Non-Digital personnel. The file name is
MRCSSE::NONAME:[PUBLIC]CIXCD_UG.PS.
The proper procedures for loading the CIXCD Microcode ON A VAX 9000 are:
Copy the latest version of the CIXCD microcode file in the [SYSMAINT]
directory on the console disk.
>>> I/K
>>> SET XMI_UPDATE/XMI:0 ON
>>> B VDS
DS> ATTACH XJA HUB XJA0 0
DS> ATTACH CIXCD XJA0 PAA0 'xmi_node_number 'ci_node_number
DS> SEL PAA0
DS> R EVGEA/SECTION=UPDATE
The diagnostic will ask for the filename of the CIXCD microcode file, the
default file name is CIXCD.BIN.
Page 2 of 2
The have been a couple of systems that had trouble updating the microcode
due to problem with a cable. This cable (17-02324-01) brings the signal
XMI EEPROM UPDATE ENABLE from the IORIC to the XMI card cage. Check this
cable for the correct revision (C01) and that it is plugged in securely.
The following is pin out for this cable:
1o o2 IORIC(J6) Name (IORIC) XMI A (J1)
o o --------------------------------------------
o o pin 1 PRM A RESET L pin 17
o o pin 2 GND pin 1
o o pin 3 XMI A DC LO L pin 19
notch o o pin 4 GND pin 11
o o pin 5 XMI LAT AC LO L pin 20
o o pin 6 GND pin 15
o o pin 7 XUE A H pin 5
19o o20 pin 8 XMI A PRESENT L pin 18
pin 9 NC
cable connector for pin 10 NC
IORIC and XMIA viewed
from the wire side
$ DUMP MRCSSE::NONAME:[PUBLIC]CIXCD.BIN
Dump of file NONAME:[PUBLIC]CIXCD.BIN;1 on 9-AUG-1990 10:20:11.00
File ID (6610,5,0) End of file block 353 / Allocated 354
Virtual block number 1 (00000001), 512 (0200) bytes
28207468 67697279 706F4320 0A0A0D99 .... Copyright ( 000000
70697571 45206C61 74696769 44202963 c) Digital Equip 000010
6E6F6974 61726F70 726F4320 746E656D ment Corporation 000020
74686769 72206C6C 41202E30 39393120 1990. All right 000030
0A0A0D20 202E6465 76726573 65722073 s reserved. ... 000040
6D726946 20636974 736F6E67 61694420 Diagnostic Firm 000050 <-- Diag.
2E30206E 6F697369 76655220 65726177 ware Revision 0. 000060 V0.38
206C616E 6F697463 6E754620 2C203833 38 , Functional 000070 <-- Func.
6F697369 76655220 65726177 6D726946 Firmware Revisio 000080 V0.22
20202020 20200A0A 0D203232 2E30206E n 0.22 ... 000090
20202020 20362E38 56205043 55444358 XCDUCP V8.6 0000A0
20202020 20202020 20202020 20202020 0000B0
$ TYPE MRCSSE::NONAME:[PUBLIC]CIXCD.BIN
Copyright (c) Digital Equipment Corporation 1990. All rights reserved.
Diagnostic Firmware Revision 0.38 , Functional Firmware Revision 0.22
XCDUCP V8.6
The rest of the file is unreadable by a human.
End of BL104.NOTES appendices.
|
| 78.40 | C1 MCU's , Bugs Fixed and Bugs Inserted ! | KERNEL::WRIGHTON | odd numbered release = bug insert | Wed Sep 12 1990 08:05 | 120 |
|
+---------------------------+ TM
| | | | | | | |
| d | i | g | i | t | a | l | I N T E R O F F I C E M E M O
| | | | | | | |
+---------------------------+
To: Distribution From: J. Brommelhoff
Loc: MRO1-3/T2
Phone: 297-4778
Enet: AEGEAN::BROMMELHOFF
Date: 12-Jun-1990
Subject: Strategy for VAX 9000 Revision C1
The definition/contents of Revision C1 has changed. The following will
show the "old" C1 configuration and provide the reasons for the change.
We have also categorized the MCA changes into 4 categories (CAT):
(1) Performance (MFLOPS) improvement only
(2) VAX Functionality
(3) Error Handling
(4) Contingency Planning for future product changes
"Old C1" Configuration:
-----------------------
BOX MCU MCA CAT PROBLEM
--- --- --- --- -----------------------------------------------
VBOX VAD VFPK 1 Performance Enhancements
VML VMLB 1 Performance Enhancements
EBOX INT USQA 4 Specific I/R Scenario (DEC 32 viol.). Would never
occur under VMS or ULTRIX
INT USQB 3 For a small number of VAX instr.s, a subset of
the recoverable Ebox errors become unrecoverable
CTL ISSC 4 This bug would only occur if we decided, for
whatever reason sometimes in the future, to
emulate H-Floating Point Format Instructions
JBOX DBX MMCX 3 REPORTING SBEs (THAT OCCUR AT HIGH RATE) TO SPU
SLOWS DOWN MEMORY ACCESS
IBOX OPU OSQA 2 MAX INSTRUCTION SEQUENCE MISMATCH (LOW
LIKELYHOOD TO OCCUR IN REAL APPLICATIONS)
MBOX VAP VAPO 2 MAX INSTRUCTION SEQUENCE MISMATCH (MEDIUM
LIKELYHOOD TO OCCUR IN REAL APPLICATIONS)
VAP CCSQ.F1 2 FOR HIGH I/O LOADS, SINGLE CYCLE VULNERABILITY
TO RETIRE REQUESTS OUT OF ORDER
CTU CTMA 2,3 CACHE SWEEP BUG
10 MCA Types on 8 MCU Types
---------------------------------------------------------------------------------
New Problems:
-------------
MBOX CTU CTMV 2,3 CACHE SWEEP BUG
VAP CCSQ.H1 2,3 CACHE SWEEP BUG, CACHE SBE RECOVERY BUG
JBOX TAG ADRX 3 CPU AND SCU CLOCKS MUST BOTH BE TURNED OFF
DURING ERROR RECOVERY, VMS CAN'T DEAL WITH
ALL POSSIBLE TYPES OF RESULTING I/O TIMEOUTS.
DAX,DBX DSXX 3 - SAME AS ABOVE -
CCU CTLA 3 - SAME AS ABOVE -
CCU CTLB 3 - SAME AS ABOVE -
PROPOSED NEW REVISION CONFIGURATIONS:
C1: VAP VAPO.F1
CCSQ.H1
CTU CTMA.D1
CTMV.M1
TAG ADRX.D1
CCU CTLA.D1
CTLB.D1
DAX DSXX.C1
DBX DSXX.C1
MMCX.D1
9 MCA Types on 6 MCU Types
----------------------------------------
C2: INT USQA.D1
USQB.C1
OPU OSQA.F1
CTL ISSC.E1
VAD VFPK.C1
VML VMLB.C1
6 MCA Types on 5 MCU Types
----------------------------------------
Revision C2 will be left open.
*** END ***
|
| 78.41 | VAX9000 , An Introduction | KERNEL::WRIGHTON | odd numbered release = bug insert | Wed Sep 12 1990 08:10 | 15 |
|
Chaps ,
I have rewritten that short book "VAX9000 , An Introduction"
with the latest and greatest toy (PSart) and copied it to COMICS.
You can print it with the following command ......
PRINT/NOTI/QUE=LPS20$UVO20/PARAM=DATA=POST COMICS::SYS$PUBLIC: ---
--- 9000_AN_INTRODUCTION.PS
This will come out on the LPS20 in Devices .
Any problems , give me a call.
Dave W
|
| 78.42 | Console 10.5 supplemental notes | KERNEL::WRIGHTON | odd numbered release = bug insert | Fri Sep 14 1990 08:10 | 526 |
|
+---------------------------+ TM
! ! ! ! ! ! ! ! i n t e r o f f i c e
! d ! i ! g ! i ! t ! a ! l !
! ! ! ! ! ! ! ! m e m o r a n d u m
+---------------------------+
Date: 9/7/90
To: VAX 9000 Tech. Dist. From: Butch Leitz
Dept: HPS/C CSSE MEG
DTN: 297-4257
LOC/MAIL STOP: MRO2-3/5E, Pole 2C
Email: HPSMEG::LEITZ
cc:
Subject: VAX 9000 SPU Base Level 10.5 Supplemental Notes
A new software kit, 10.5, is being distributed for the VAX 9000 SPU.
This supercedes the previous 10.4 release that was scheduled for a few
weeks ago by updating diagnostics in the [SYSMAINT] area to latest
supported revisions. Some of these were not available in the original
10.4 kit, which is why that kit was held from most sites.
The following notes are meant to supplement the 10.4 release notes
which can be found in:
MRCSSE::PUBLIC:RELEASE_NOTES_10-4.PS.
The new kit can be identified by [SYSEXE]MEDIA_REV.DAT, the contents
of which will say: AQ-DISK-FT10.5
When booting the SPU, SYSBOOT will display FT10.4 in it's banner.
This file has been placed in:
MRCSSE::PUBLIC:BL105.NOTES
and will be updated with change bars if additional notes need to be
made. As usual, blitzes will be sent out if needed.
There is also a new update in MRCSSE::PUBLIC:SPU.QARS of all SPU QARS
that have been entered, whether they are closed, answered, or open. You
can use this as a refresher to previous problems we had under 10.3 and
10.4 that may have carried over into 10.5
10.5 NOTES:
Known SPU SYSTEM issues:
------------------------
1) The ^O hang issue is fixed in this release.
2) SET SJA/NODMA no longer needs to be added to the end of SJAINIT.CMD
in [SYSEXE]. This was necessary for 10.3 only.
3) DEFECT LIST handling; code has been added to help control overruns of
CRDs from a KNOWN memory design issue that has caused spurious CRDs to
occur and occasional DBEs due to a noise problem. However in some
instances you may still have to periodically delete
[000000]DEFECT_LIST.SYS. You'll know when - you'll see unavailable
memory messages when trying to BOOT. We'll have to keep doing this
until further notice (when the memory FCOs get released).
Known SPU CLI issues/features:
------------------------------
1) SHOW CONFIG/DATE= fails. This gives current configuration always,
so it doesn't work right yet.
2) There is known behavior in the SPU with symbol translations within
command files sometimes causing buffer overflow messages; this
subsequently returning the user to CLI level (out of the command
file). Setting error handling on in the command file does not trap the
error.
There's no work around except to evaluate the the size of the
resulting symbol substitution and try and break it down into smaller
pieces with a sum length of no more than 80 characters (the maximum
length of characters the SPU will recognize as a command.
You should rarely see this unless developing complex command files for
the SPU. This is not considered a bug but a known behavior given that
scenerio.
3) TEST/SCAN/ON_ERROR:ISOLATE has been changed. ISOLATE is now it's own
parameter:
TEST/SCAN/ISO/LOG/TRA/SCU will now provide isolation on error instead
of using the /ON_ERROR switch.
Known SPU Utility Issues/features:
----------------------------------
1) RFTS on the SPU does not work. Don't even try and use it. Fixes will
be made available in a future release.
2) BACKUP:
BACKUP/LIST to a tape (MUA7:[]) will hang the SPU.
BACKUP/LIST to a non-saveset file will hang the SPU process.
BACKUP requires very specific device and file specs otherwise
errors will occur.
BACKUP does not allow single file restoration from a save set,
you must dump all files in a save set to the disk first.
3) SDU:
SDU> LOAD/SNAP works correctly.
Some of the new features available:
a) SDU> SET SCOPE %SCU ;(or whatever scope level you pick)
b) SDU> EXAMINE/SYMBOL:symbol_name signal_list ;now works!
Note that you won't see the output. It gets assigned to
the symbol you specified. You can then do IF-THEN-ELSE
testing on this symbol:
SDU> IF FOO .EQS. 0 THEN WRITE SYS$OUTPUT "test"
Known DIAG and TEST issues/features:
-----------------------------------
1) No known issues with TEST/STR/ALL.
2) EWSAA (VDS): Revision on this kit is 13.2(1235) with no
known problems.
3) CIXCD:
EVGEA is at rev 2.1, EVGEB is at rev 2.0. both work fine.
EVGAA,AB,and AC have been removed from this kit pending work.
4) EVSBA:
v7.2 is included in this kit. No issues.
5) TEST/JXDI is at rev B and runs through test 65 with no known errors.
6a) EVCLB: This kit contains rev 1.8.
6b) EWCLA (TEST/XJA) now appears to work with no known issues, although
it has not been officially qualified. Use of EVCLB is recommended
until further notice.
6c) EWCLD: the powerup self test diagnostic may fail. The failure
may occur in any revision XJA C1, C2, C3. The failures
appears to happen regularly when a CIXCD is in slots 4 or C
of the XMI backplane.
NOTE: See XJA blitz appended to the end of this memo for more XJA diag notes.
7) SPD doesn't provide correct outputs yet, so don't even bother
running it. The new SPD is being tested now in house and should be
released on the SPU BL 11.1 kit.
Known Miscellaneous issues:
---------------------------
1) from CTY in PIO mode, dir csa1:, ^P to SPU, do work, continue,
VMS proc will look hung...<cr> doesn't work, ^T or ^R don't work.
^Y clears back to DCL.
2) two jobs under VMS doing accesses to CSA1 crash VMS:
job 1: dir csa1:[sysexe]*.*/date/size
job 2: dir csa1:[sysmaint]*.*/date/siz
VMS crashes...
3) If SYS$KEEPALIVE in [SYSEXE]SITESPECIFIC.CMD is set to "ON", a
snapshot will be taken. If the OCP keyswitch is set to reboot, then a
reboot should be performed. There are no known issues with EBOX
keepalive functions or snapshot control.
4) ADMIN.CMD is at version 1.6. There may be issues with it that won't
be resolved until revision 3.0. Try and use it, mail me feedback.
From: MRCSSE::TIMA_MGR "CSSE ISBS TIMA Manager" 1-AUG-1990 03:31:52.87
To: MRCSSE::LEITZ
CC:
Subj: GRAM: VAX 9000 XJA Diagnostic Failures (VAX9000 blitz)
Author : BARBARA GILBERT
User type : AIM
Location : TIMA
Vaxmail address : TIMA::GILBERT
The attached information is from the HES CSSE Group.
It contains important information regarding, VAX 9000 XJA DIAGNOSTIC FAILURES.
This information can be found through TIMA STARS
Database: CSSE_TIME_CRITICAL
============================[ Start Message ]==============================
+---------------------------+
| | | | | | | |
| d | i | g | i | t | a | l | TIME DEPENDENT CASE
| | | | | | | |
+---------------------------+
TITLE: VAX 9000 XJA DIAGNOSTIC FAILURES
DATE: 30 July 1990
AUTHOR: Tom Collentine TD #: 000356
DTN: 297-4749
ENET: MRCSSE::TCOLLENTINE CROSS REFERENCE #'s:
DEPARTMENT: HIGH-END SYSTEMS CSSE (PRISM/TIME/CLD#'s)
INTENDED AUDIENCE: PRIORITY LEVEL: 1
(U.S./EUROPE/GIA) (1=TIME CRITICAL,
2=NON-TIME CRITICAL)
=====================================================================
OVERVIEW:
The XJA is a interface adapter between 9000 System Control
Unit (SCU) and the XMI bus. The XJA is preliminary tested by
three diagnostics.
EWCLD - XJA Add-On Selftest Level 4 Diagnostic
EWCLD is written in Intel 8096 Assembly language. EWCLD is
contained in EEPROM on the XJA module and is executed
automatically during the power up phase of the XJA, and
during any XJA Node Resets. EWCLD can be executed manually
through commands issued by a terminal connected to the
terminal port on the XJA module.
EWCLA - XJA Level 4 Diagnostic
EWCLA is written in Macro assembly language. The program is
loaded form the [UCODE] area on the console disk into system
memory when invoked by the TEST/XJA command. This implies
that the Vax Hardcore exerciser should be run successfully
prior to running EWCLA. A brief description of the tests
EWCLA performs is appended to the end of this document.
EVCLB - XJA Level 3 Repair level Diagnostic
EVCLB is a macro diagnostic and runs under the diagnostic
supervisor. EVCLB performs similar tests as described in
EWCLA at the end of this document. In addition EVCLB provides
error call out and expected and received data.
PROBLEM:
EWCLD the powerup self test diagnostic may fail. The failure
may occur in any revision XJA C1, C2, C3. The failures
appears to happen regularly when a CIXCD is in slots 4 or C
of the XMI backplane.
Booting through the XCD from these slots is not usually
possible as VMB/VMS invokes node reset many times during the
boot process. There is also a problem with some XJAs failing
self-test intermittently regardless of an XCD.
Workaround:
Do not configure CIXCDs is slot 4 or C of the XMI bus.
Long Term fix:
Revision D of the XJA.
PROBLEM:
Version 1.x of EWCLA may fail. Test and subtests may vary. An
example follows;
>>>TEST/XJA:0
%CLI-E-XJAFAIL , XJA selftest version 1.1 on XJA 00 has failed
Subtest number 2
Module number: 20
Failing PC: 000007BC
>>>Exam R0
G 00 07bc0214
^ ^ ^_ (Module Number)Subtest number in Decimal
| |_(Subtest #) TEST Number
|_PC
Workaround:
EVKAA The VAX Hardcore diagnostic should be run successfully
before running EWCLA (TEST/XJA). Verify a suspected XJA
failure by running EVCLB before replacing any hardware.
Long Term fix:
Fixed in a future release of EWCLA possibly version 1.3.
PROBLEM:
EVCLB may fail test 1. EVCLB checks the AOST register and
will display a failure if the AOST has failed. Be aware this
failure may be related to the problem listed above under
EWCLD.
Also
EVCLB may fail test 2 intermittently. An example follows;
******** XJA Functional Diagnostic - ZZ-EVCLB - 1.5 ********
Pass 384, test 2, subtest 10, error 2 27-JUL-1990 07:58:45.15
Hard error while testing XJA0: Octaword read lock/Write
unlock failure(s)
1)Unexpected XJA Error Interrupt when attempting to lock
Location 6640 - 667F, just above locked locations 6600 -663F
Workaround:
DO NOT use the above test failures to indict as faulty, and
replace any defective hardware in the VAX 9000.
Long Term fix:
In a future release of EVCLB, possibly V1.8, the test 1
failure will display a AOST failure as a soft failure.
The test 2 failure will be fixed in a future release of EVCLB
possibly V1.8.
Here is a brief description of the tests EWCLA performs.
MODULE 0 (A.K.A test)
This is the initialization section. It is started at
0(X) by the Service Processing Unit or Console operator after
R0 is loaded with the information concerning which XJA(s)
exist on the system, and R1 for the passcount and Test(s) to
execute. This section will then initialize all the XJA
register address locations depending on which bit in R0 is
set. If bit 0 is set, XJA0 is tested. If bit 1 is set, XJA1
is tested, etc. up to bit 3. Once all the XJA's have been
tested, this section then executes a CPU halt. The SPU can
then examine the contents of R0 through R3 for the test
results of XJA0 through XJA3 respectively, and use the
results accordingly (clear if that XJA passed, failure
information if it failed).
MODULE 1:
This module contains the code to check the initial state of
the XJA after Powerup Reset, pattern tests for all XJA
registers that are write and readable, and checks the Powerup
Interrupt and data returned.
MODULE 2:
This module provides code to fully check the operation of the
XJA Force Command Register (FCMD), both defined and undefined
commands.
MODULE 3:
This module contains the test code to check the start- ing
and memory size fields.
MODULE 4:
This module provides test code to check the four XJA IDENT
registers - IDENT4, IDENT5, IDENT6 and IDENT7.
MODULE 5:
This module provides test code to check the XJA Error Summary
Register.
MODULE 6:
Parity Error Insertion Test
XCI_P[0] - XCI_P[2] C/A cycle Parity Error tests
XCI_P[0] - XCI_P[2], data cycle Parity Error Tests
JXDI_P[0] - JXDI_P[1], cycle 0,1,2 Parity Error Tests
MODULE 7:
DMA Pattern, Exercise and Error Test
DMA Pattern test
Multiple DMA exerciser
*** DIGITAL INTERNAL USE ONLY***
=============================[ End Message ]===============================
From: MRCSSE::KRETZ "Charlie Kretz - HES CSSE - MRO2-3/5E - 297-4948 09-Aug-1990 1517" 9-AUG-1990 15:25:11.61
To: @PUBLIC:9K_TECH
CC: ASTON,CARSLN::RIEHL,KRETZ
Subj: VAX 9000 XJA & CIXCD Selftest Interaction Problem
+---------------------------+ TM
| | | | | | | |
| d | i | g | i | t | a | l | INTEROFFICE MEMORANDUM
| | | | | | | |
+---------------------------+
DATE: August 9, 1990
TO: 9K_TECH FROM: Charlie Kretz
CC: VAX 9000 CSSE Group DEPT: HPS CSSE
Bob Aston EXT: 297-4948
Dave Riehl LOC: MRO2-3/5E
ENET: MRCSSE::KRETZ
SUBJECT: VAX 9000 XJA and CIXCD Selftest Interaction Problems
There have been some interaction problems between the XJA and the CIXCD
selftest. These problems caused the XJA to fail self test and depending
on what slot the CIXCD was in would prohibit VMS from booting. All these
problems have been resolved, the CIXCD requires a microcode update to
correct these problems. The latest version of the CIXCD functional
microcode is version V0.22 with selftest microcode version V0.38 corrects
these problems.
The latest version of the CIXCD microcode is accessible on our cluster,
the file name is MRCSSE::NONAME:[PUBLIC]CIXCD.BIN. Some people have
gotten an early release copy of the CIXCD functional microcode version
0.22 that still had the older selftest version V0.37 microcode. While
this provided the latest functional features it did not have the selftest
interaction problems corrected. Unfortunately the diagnostic firmware
revision is not displayed in the XMI XDEV register, only the functional
revision is displayed. You can identify the new microcode file by dumping
or typing the file and looking for the version information. The version
is stored in a human readable format in the first block of the file, see
the example on page 2 (two) of this memo.
In case you do not have the CIXCD Users Guide, I have put a softcopy of
this manual in our cluster. This manual contains information about the
CIXCD on the VAX 6000, which is an unannounced product. Therefore, it can
not to be given or viewed by any Non-Digital personnel. The file name is
MRCSSE::NONAME:[PUBLIC]CIXCD_UG.PS.
The proper procedures for loading the CIXCD Microcode ON A VAX 9000 are:
Copy the latest version of the CIXCD microcode file in the [SYSMAINT]
directory on the console disk.
>>> I/K
>>> SET XMI_UPDATE/XMI:0 ON
>>> B VDS
DS> ATTACH XJA HUB XJA0 0
DS> ATTACH CIXCD XJA0 PAA0 'xmi_node_number 'ci_node_number
DS> SEL PAA0
DS> R EVGEA/SECTION=UPDATE
The diagnostic will ask for the filename of the CIXCD microcode file, the
default file name is CIXCD.BIN.
Page 2 of 2
The have been a couple of systems that had trouble updating the microcode
due to problem with a cable. This cable (17-02324-01) brings the signal
XMI EEPROM UPDATE ENABLE from the IORIC to the XMI card cage. Check this
cable for the correct revision (C01) and that it is plugged in securely.
The following is pin out for this cable:
1o o2 IORIC(J6) Name (IORIC) XMI A (J1)
o o --------------------------------------------
o o pin 1 PRM A RESET L pin 17
o o pin 2 GND pin 1
o o pin 3 XMI A DC LO L pin 19
notch o o pin 4 GND pin 11
o o pin 5 XMI LAT AC LO L pin 20
o o pin 6 GND pin 15
o o pin 7 XUE A H pin 5
19o o20 pin 8 XMI A PRESENT L pin 18
pin 9 NC
cable connector for pin 10 NC
IORIC and XMIA viewed
from the wire side
$ DUMP MRCSSE::NONAME:[PUBLIC]CIXCD.BIN
Dump of file NONAME:[PUBLIC]CIXCD.BIN;1 on 9-AUG-1990 10:20:11.00
File ID (6610,5,0) End of file block 353 / Allocated 354
Virtual block number 1 (00000001), 512 (0200) bytes
28207468 67697279 706F4320 0A0A0D99 .... Copyright ( 000000
70697571 45206C61 74696769 44202963 c) Digital Equip 000010
6E6F6974 61726F70 726F4320 746E656D ment Corporation 000020
74686769 72206C6C 41202E30 39393120 1990. All right 000030
0A0A0D20 202E6465 76726573 65722073 s reserved. ... 000040
6D726946 20636974 736F6E67 61694420 Diagnostic Firm 000050 <-- Diag.
2E30206E 6F697369 76655220 65726177 ware Revision 0. 000060 V0.38
206C616E 6F697463 6E754620 2C203833 38 , Functional 000070 <-- Func.
6F697369 76655220 65726177 6D726946 Firmware Revisio 000080 V0.22
20202020 20200A0A 0D203232 2E30206E n 0.22 ... 000090
20202020 20362E38 56205043 55444358 XCDUCP V8.6 0000A0
20202020 20202020 20202020 20202020 0000B0
$ TYPE MRCSSE::NONAME:[PUBLIC]CIXCD.BIN
Copyright (c) Digital Equipment Corporation 1990. All rights reserved.
Diagnostic Firmware Revision 0.38 , Functional Firmware Revision 0.22
XCDUCP V8.6
The rest of the file is unreadable by a human.
End of BL104.NOTES appendices.
|
| 78.43 | | KERNEL::WRIGHTON | odd numbered release = bug insert | Tue Sep 18 1990 11:46 | 2565 |
|
For those who are interested in the 9000 hardware,features and
benchmarks , I have included the following postscript file which
is used by EDU SERVICES as part of the introduction. It is the
instructors original and includes "instructors notes" pages that
you will probably want to bin.
***************************** cut here **********************************
%!PS-Adobe-2.0
%%Creator: VAX DOCUMENT V1.1
%%+Copyright (c) 1986,1987,1988 DIGITAL EQUIPMENT CORPORATION.
%%+All Rights Reserved.
%%DocumentFonts: (atend)
%%Pages: (atend)
%%EndComments
/$DVCDict where { %FIND DICTIONARY
pop
}{ %else
/$DVCDict 300 dict def
} ifelse
/BeginDVC$PSDoc { %BEGIN DOCUMENT
vmstatus pop pop 0 eq {
$DVCDict begin InitializeState
}{ %else
/DVC$PSJob save def $DVCDict begin InitializeState
/DVC$PSFonts save def
} ifelse
} def
/EndDVC$PSDoc { %END DOCUMENT
vmstatus pop pop 0 eq {
end
}{ %else
DVC$PSFonts restore end DVC$PSJob restore
} ifelse
} def
%
$DVCDict begin
%
mark % CREATE ISOLatin1 ENCODING
/ISOLatin1
8#000 1 8#054 {StandardEncoding exch get} for
/minus
8#056 1 8#217 {StandardEncoding exch get} for
/dotlessi
8#301 1 8#317 {StandardEncoding exch get} for
/space /exclamdown /cent /sterling /currency /yen /brokenbar /section
/dieresis /copyright /ordfeminine /guillemotleft /logicalnot /hyphen
/registered /macron /degree /plusminus /twosuperior /threesuperior /acute
/mu /paragraph /periodcentered /cedilla /onesuperior /ordmasculine
/guillemotright /onequarter /onehalf /threequarters /questiondown /Agrave
/Aacute /Acircumflex /Atilde /Adieresis /Aring /AE /Ccedilla /Egrave /Eacute
/Ecircumflex /Edieresis /Igrave /Iacute /Icircumflex /Idieresis /Eth /Ntilde
/Ograve /Oacute /Ocircumflex /Otilde /Odieresis /multiply /Oslash /Ugrave
/Uacute /Ucircumflex /Udieresis /Yacute /Thorn /germandbls /agrave /aacute
/acircumflex /atilde /adieresis /aring /ae /ccedilla /egrave /eacute
/ecircumflex /edieresis /igrave /iacute /icircumflex /idieresis /eth /ntilde
/ograve /oacute /ocircumflex /otilde /odieresis /divide /oslash /ugrave
/uacute /ucircumflex /udieresis /yacute /thorn /ydieresis
/ISOLatin1 where not {256 array astore def} if
cleartomark
%
/DECMCS ISOLatin1 256 array copy def
mark % CREATE DECMCS ENCODING
8#240 8#244 8#246 8#254 8#255 8#256 8#257 8#264
8#270 8#276 8#320 8#336 8#360 8#376 8#377
counttomark
{DECMCS exch /.notdef put} repeat % STACK NOW CONTAINS MARK
8#250 /currency 8#327 /OE 8#335 /Ydieresis 8#367 /oe 8#375 /ydieresis
counttomark -1 bitshift % DIVIDE BY 2
{DECMCS 3 1 roll put} repeat % STACK NOW CONTAINS MARK
cleartomark
%
/DOCPSE DECMCS 256 array copy def
mark % CREATE DOCPSE ENCODING
8#055 /hyphen
8#201 /bullet 8#202 /emdash 8#203 /endash 8#204 /dagger
8#205 /daggerdbl 8#206 /registered 8#207 /trademark %8#210 /Delta
8#211 /fi 8#212 /fl
counttomark -1 bitshift % DIVIDE BY 2
{DOCPSE 3 1 roll put} repeat % STACK NOW CONTAINS MARK
cleartomark
%
/reencodedict 10 dict def %Local storage for "ReENCODE"
/ReENCODE { % /basefont /newfont encoding ReENCODE
/newencoding exch def %ARG: NAME OF ENCODING VECTOR
/newfontname exch def %ARG: NEW NAME FOR FONT AFTER RE-ENCODING
findfont
/basefontdict exch def %ARG: NAME OF FONT TO BE RE-ENCODED
basefontdict maxlength dict begin %CREATE AND OPEN NEW DICT
basefontdict { %COPY ENTRIES FROM BASE FONT DICT TO NEW ONE
1 index /FID ne {
def %IF NOT THE ONE WE'RE ENCODING, JUST COPY PTRS
} { %else
pop pop %IGNORE FID AND ENCODING FOR ONE WE'RE ENCODING
} ifelse
} forall
/FontName newfontname def %DEFINE NEW NAME
/Encoding newencoding def %DEFINE NEW ENCODING VECTOR
newfontname currentdict definefont %TURN IT INTO A PS FONT
pop %IGNORE MODIFIED DICT RETURNED BY DEFINEFONT
end
} bind def
%
/cvsstr 64 string def
/tempmatrix matrix def
%
/BP { % BEGIN PAGE
/Magnification exch def /DVC$PSPage save def
} def
%
/EP {DVC$PSPage restore} def % END PAGE
%
/XP { % EXIT PAGE (TEMPORARILY) TO ADD FONTS/CHARS
% SAVE CURRENT POINT INFORMATION SO IT CAN BE RESET LATER
/Xpos where {pop Xpos} {0} ifelse
/Ypos where {pop Ypos} {0} ifelse
/currentpoint cvx stopped {0 0 moveto currentpoint} if
/DVC$PSPage where {pop DVC$PSPage restore} if
moveto
/Ypos exch def /Xpos exch def
} def
%
/RP {/DVC$PSPage save def} def % RESUME PAGE
%
/PF {GlobalMode LocalMode} def % PURGE FONTS TO RECLAIM MEMORY
%
/GlobalMode { % SWITCH TO BASE SAVE/RESTORE LEVEL, SAVING STATE
PortraitMode PaperWidth PaperHeight PxlResolution Resolution
Magnification Ymax Xorigin Yorigin RasterScaleFactor
% SAVE CURRENTPOINT INFORMATION TO RESET LATER
/currentpoint cvx stopped {0 0 moveto currentpoint} if
/DVC$PSPage where {pop DVC$PSPage restore} if
DVC$PSFonts restore RecoverState
} def
%
/RecoverState { % PRESERVE STATE AT BASE LEVEL
12 copy
/Ypos exch def /Xpos exch def /RasterScaleFactor exch def
/Yorigin exch def /Xorigin exch def /Ymax exch def
/Magnification exch def /Resolution exch def /PxlResolution exch def
/PaperHeight exch def /PaperWidth exch def /PortraitMode exch def
DoInitialScaling
PortraitMode not {PaperWidth 0 SetupLandscape} if
Xpos Ypos moveto
} def
%
/InitializeState { % INITIALIZE STATE VARIABLES TO DEFAULT VALUES
/Resolution 3600 def /PxlResolution 300 def
/RasterScaleFactor PxlResolution Resolution div def
/PortraitMode true def /PaperHeight 11 Resolution mul def
/PaperWidth 8.5 Resolution mul def /Ymax PaperHeight def
/Magnification 1000 def /Xorigin 0 def /Yorigin 0 def
/Xpos 0 def /Ypos 0 def /InitialMatrix matrix currentmatrix def
} def
%
/LocalMode { % SWITCH FROM BASE SAVE/RESTORE LEVEL, RESTORING STATE
/Ypos exch def /Xpos exch def /RasterScaleFactor exch def
/Yorigin exch def /Xorigin exch def /Ymax exch def
/Magnification exch def /Resolution exch def /PxlResolution exch def
/PaperHeight exch def /PaperWidth exch def /PortraitMode exch def
DoInitialScaling
PortraitMode not {PaperWidth 0 SetupLandscape} if
Xpos Ypos moveto
/DVC$PSFonts save def /DVC$PSPage save def
} def
% % ABBREVIATIONS
/S /show load def
/SV /save load def
/RST /restore load def
/Yadjust {Ymax exch sub} def
%
/SXY { % (x,y) POSITION ABSOLUTE, JUST SET Xpos & Ypos, DON'T MOVE
Yadjust /Ypos exch def /Xpos exch def
} def
%
/XY { % (x,y) POSITION ABSOLUTE
Yadjust 2 copy /Ypos exch def /Xpos exch def moveto
} def
%
/X { % (x,0) POSITION ABSOLUTE
currentpoint exch pop 2 copy /Ypos exch def /Xpos exch def moveto
} def
%
/Y { % (0,y) POSITION ABSOLUTE
currentpoint pop exch Yadjust 2 copy
/Ypos exch def /Xpos exch def moveto
} def
%
/xy { % (x,y) POSITION RELATIVE
neg rmoveto currentpoint /Ypos exch def /Xpos exch def
} def
%
/x { % (x,0) POSITION RELATIVE
0 rmoveto currentpoint /Ypos exch def /Xpos exch def
} def
%
/y { % (0,y) POSITION RELATIVE
0 exch neg rmoveto currentpoint /Ypos exch def /Xpos exch def
} def
%
/R { % DRAW A RULE
/ht exch def /wd exch def gsave 0 setgray
currentpoint newpath moveto
0 ht rlineto wd 0 rlineto
0 ht neg rlineto wd neg 0 rlineto
closepath fill grestore wd 0 rmoveto
currentpoint /Ypos exch def /Xpos exch def
} def
%
/RES { % <PXL-file resolution(pix/inch)> <resolution(pix/inch)> RES
/Resolution exch def /PxlResolution exch def
/RasterScaleFactor PxlResolution Resolution div def
DoInitialScaling
} def
%
/DoInitialScaling { % DO INITIAL SCALING
InitialMatrix setmatrix 72 Resolution div dup scale
} def
%
/PM { % <paper-height(pix)> <paper-width(pix)> PM
XP
/PaperWidth exch def /PaperHeight exch def
/Ymax PaperHeight def /PortraitMode true def
DoInitialScaling
RP
} def
%
/SetupLandscape {translate 90 rotate} def
/LM { % <paper-height(pix)> <paper-width(pix)> LM
XP
/PaperWidth exch def /PaperHeight exch def
/Ymax PaperWidth def /PortraitMode false def
DoInitialScaling PaperWidth 0 SetupLandscape
RP
} def
%
/MAG { % CHANGE MAGNIFICATION SETTING
XP /Magnification exch def RP
} def
%
/SPB { % <xoffset><yoffset>SPB - BEGIN "\SPECIAL" MODE
Yadjust /Yorigin exch def /Xorigin exch def
GlobalMode Xorigin Yorigin translate
Resolution 72 div dup scale % RESTORE DEFAULT SCALING
Magnification 1000 div dup scale % ADJUST FOR ANY MAGNIFICATION
/Xpos Xpos 72 Resolution div mul 1000 Magnification div mul def
/Ypos Ypos 72 Resolution div mul 1000 Magnification div mul def
/spsavobj save def %SAVE STATE & STACK DEPTH FOR CLEANUP AFTER FIGURE
/showpage {} def %DISABLE DURING FIGURE; `RESTORE' WILL BLOW DEF AWAY
mark
} def
%
/SPE { % SPE - END "\SPECIAL" MODE
spsavobj restore
cleartomark
1000 Magnification div dup scale % UN-ADJUST FOR ANY MAGNIFICATION
72 Resolution div dup scale % RESTORE DEFAULT INTERNAL SCALING
LocalMode
} def
%
/PP {showpage} def
/CLRP {erasepage} def
%
/DMF { % /font-name <point-size(pix)> DMF
/psz exch def /nam exch def nam findfont psz scalefont setfont
} def
%
/concatnam { % /abcd (xxx) concatnam ==> /abcdxxx
/xxx exch def /nam exch def
/namstr nam cvsstr cvs def
/newnam namstr length xxx length add string def
newnam 0 namstr putinterval
newnam namstr length xxx putinterval
newnam cvn
} def
%
/strip { % /abcdef 2 strip ==> /cdef
/num exch def /nam exch def
/namstr nam cvsstr cvs def
/newlen namstr length num sub def
namstr num newlen getinterval cvn
} def
% ROUTINES TO HANDLE PACKING/UNPACKING NUMBERS
/PackHW { % <target> <pos> <num> PackHW --> <new target>
/num exch def /pos exch def /target exch def
num 16#0000FFFF and 1 pos sub 16 mul bitshift target or
} def
/PackByte { % <target> <pos> <num> PackByte --> <new target>
/num exch def /pos exch def /target exch def
num 16#000000FF and 3 pos sub 8 mul bitshift target or
} def
/UnpkHW { % <pos> <num> UnpkHW --> <unpacked value>
/num exch def /pos exch def
num 1 pos sub -16 mul bitshift 16#0000FFFF and
dup 16#00007FFF gt {16#00010000 sub} if
} def
/UnpkByte { % <pos> <num> UnpkByte --> <unpacked value>
/num exch def /pos exch def
num 3 pos sub -8 mul bitshift 16#000000FF and
dup 16#0000007F gt {16#00000100 sub} if
} def
%
/DPSF { % /procname size /fontname DPSF
findfont exch scalefont
[ exch /setfont cvx ] cvx def
} bind def
%
/PXLBuildCharDict 17 dict def
/CMEncodingArray 128 array def
0 1 127 {CMEncodingArray exch dup cvsstr cvs cvn put} for
/RasterConvert {RasterScaleFactor div} def
/TransformBBox {
aload pop
/BB-ury exch def /BB-urx exch def /BB-lly exch def /BB-llx exch def
[ BB-llx RasterConvert BB-lly RasterConvert
BB-urx RasterConvert BB-ury RasterConvert ]
} def
/RunLengthToRasters {
% none yet
} def
/GenerateRasters { % GENERATE RASTERS FOR "IMAGEMASK"
rasters runlength 1 eq {RunLengthToRasters} if
} def
%
/int-dict-name {int (-dict) concatnam} def
/int-dict {int (-dict) concatnam cvx load} def
%
/DefinePXLFont {
% <int-font-name><ext-font-name><pt-sz(pix)><PXL mag><num-chars>...
% ...[llx lly urx ury]<newfont-fg>DefinePXLFont
/newfont exch def /bb exch def /num exch def /psz exch def
/dsz exch def /pxlmag exch def /ext exch def /int exch def
/fnam ext (-) concatnam pxlmag cvsstr cvs concatnam def
newfont not {
int-dict-name 13 dict def
int-dict begin
/FontType 3 def /FontMatrix [ 1 dsz div 0 0 1 dsz div 0 0 ] def
/FontBBox bb TransformBBox def /Encoding CMEncodingArray def
/CharDict 1 dict def CharDict begin /Char-Info num array def end
/BuildChar {
PXLBuildCharDict begin
/char exch def /fontdict exch def
fontdict /CharDict get /Char-Info get char get aload pop
/rasters exch def /PackedWord1 exch def
0 PackedWord1 UnpkHW 16#7FFF ne {
/PackedWord2 exch def /wx 0 PackedWord1 UnpkHW def
/rows 2 PackedWord1 UnpkByte def /cols 3 PackedWord1 UnpkByte def
/llx 0 PackedWord2 UnpkByte def /lly 1 PackedWord2 UnpkByte def
/urx 2 PackedWord2 UnpkByte def /ury 3 PackedWord2 UnpkByte def
}{ %else
/PackedWord2 exch def /PackedWord3 exch def /PackedWord4 exch def
/wx 1 PackedWord1 UnpkHW def /rows 0 PackedWord2 UnpkHW def
/cols 1 PackedWord2 UnpkHW def /llx 0 PackedWord3 UnpkHW def
/lly 1 PackedWord3 UnpkHW def /urx 0 PackedWord4 UnpkHW def
/ury 1 PackedWord4 UnpkHW def
} ifelse
rows 0 lt {
/rows rows neg def /runlength 1 def
}{ %else
/runlength 0 def
} ifelse
wx 0
llx RasterConvert lly RasterConvert
urx RasterConvert ury RasterConvert setcachedevice
rows 0 ne {
gsave
cols rows true RasterScaleFactor
0 0 RasterScaleFactor neg llx .5 add neg ury .5 add
tempmatrix astore GenerateRasters imagemask
grestore
} if
end
} def
end
fnam int-dict definefont pop
} if
int-dict-name fnam findfont psz scalefont def
currentdict int [ int-dict /setfont cvx ] cvx put
} def
/PXLF { true DefinePXLFont} def % SIGNAL THAT FONT IS ALREADY LOADED
/PXLNF {false DefinePXLFont} def % SIGNAL THAT FONT IS NOT ALREADY LOADED
%
/PXLC { % <int-font-name><code><wx><llx><lly><urx><ury>...
% ...<rows><cols><runlength><rasters>PXLC
/rasters exch def /runlength exch def /cols exch def /rows exch def
/ury exch def /urx exch def /lly exch def /llx exch def
/wx exch def /code exch def /int exch def
% SEE IF LONG OR SHORT FORMAT IS REQUIRED
true cols CKSZ rows CKSZ ury CKSZ urx CKSZ lly CKSZ llx CKSZ
TackRunLengthToRows {
int-dict /CharDict get /Char-Info get code
[ 0 0 llx PackByte 1 lly PackByte 2 urx PackByte 3 ury PackByte
0 0 wx PackHW 2 rows PackByte 3 cols PackByte rasters ] put
}{ %else
int-dict /CharDict get /Char-Info get code
[ 0 0 urx PackHW 1 ury PackHW 0 0 llx PackHW 1 lly PackHW
0 0 rows PackHW 1 cols PackHW 0 0 16#7FFF PackHW 1 wx PackHW rasters ] put
} ifelse
} def
%
/CKSZ {abs 127 le and} def
/TackRunLengthToRows {runlength 0 ne {/rows rows neg def} if} def
%
/PLOTC {
% <wx><dsz><psz><llx><lly><urx><ury><rows><cols><runlength><rasters>PLOTC
/rasters exch def /runlength exch def /cols exch def /rows exch def
/ury exch def /urx exch def /lly exch def /llx exch def
/psz exch def /dsz exch def /wx exch def
% "PLOT" A CHARACTER'S RASTER PATTERN
rows 0 ne {
gsave
currentpoint translate psz dsz div dup scale
cols rows true RasterScaleFactor 0 0 RasterScaleFactor
neg llx .5 add neg ury .5 add tempmatrix astore
GenerateRasters imagemask
grestore
} if
wx x
} def
%
end %$DVCDict
%%EndProlog
%%BeginSetup
BeginDVC$PSDoc
CLRP 300 3600 RES
%%EndSetup
%%DOC$Page: 2-1 1
1000 BP 39600 30600 PM 0 0 XY
XP
% DefineFont:F16 Category:10 PointSize:24
/Helvetica-Bold /Helvetica-Bold@DOCPSE DOCPSE ReENCODE
/F16 1200.0 /Helvetica-Bold@DOCPSE DPSF
RP
9817 13977 XY F16(V)S -88 x(AX)S 500 x(9000)S 499 x(Hardware)S
PP
EP
%%DOC$Page: 2-3 2
1000 BP 39600 30600 PM 0 0 XY
XP
% DefineFont:F36 Category:10 PointSize:10
/F36 500.0 /Helvetica-Bold@DOCPSE DPSF
RP
3899 2106 XY F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S
XP
% DefineFont:F20 Category:10 PointSize:18
/F20 900.0 /Helvetica-Bold@DOCPSE DPSF
RP
3899 4247 XY F20(Instruc)S -2 x(tor)S 298 x(Notes)S 5443 Y 3899 X
23316 96 R 35879 Y 3899 X 23316 96 R 37373 Y 3899 X F36(2\2033.a)S
498 x(V)S -36 x(AX)S 166 x(9000)S 166 x(Hardware)S
PP
EP
%%DOC$Page: 2-3 3
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4275 Y 3899 X F20(INTRODUCTI)S 2 x(ON)S
XP
% DefineFont:F30 Category:10 PointSize:11
/Helvetica /Helvetica@DOCPSE DOCPSE ReENCODE
/F30 550.0 /Helvetica@DOCPSE DPSF
RP
3899 5471 XY F30(The)S 196 x(V)S -40 x(AX)S 198 x(9000)S 196 x
(systems)S 198 x(represent)S 196 x(Digital')S -12 x(s)S 198 x(entry)S
197 x(into)S 196 x(advanced)S 196 x(mainframe)S 197 x(computing)S
-2 x(.)S 288 x(Several)S 647 y 3899 X(characteristics)S 182 x
(disting)S -2 x(uish)S 182 x(them)S 183 x(from)S 183 x(prevous)S
182 x(V)S -40 x(AX)S 184 x(systems:)S 7314 Y 3899 X(\201)S 854 x
(Advanced)S 181 x(technolog)S -2 x(y)S 8509 Y 3899 X(\201)S 854 x
(System)S 183 x(architecture)S 183 x(based)S 181 x(on)S 182 x(a)S
182 x(crossbar)S 183 x(switch)S 181 x(\(rather)S 184 x(than)S 182 x
(a)S 182 x(bus\))S 9705 Y 3899 X(\201)S 854 x(High-pe)S -2 x(rform)S
2 x(ance)S 181 x(memory)S 184 x(and)S 181 x(I/O)S 184 x(subsystems)S
182 x(that)S 183 x(bala)S -2 x(nce)S 182 x(the)S 182 x(performance)S
183 x(of)S 182 x(the)S 183 x(CPU)S 10900 Y 3899 X(\201)S 854 x(An)S
183 x(intell)S -2 x(igent)S 182 x(service)S 182 x(processor)S 182 x
(that)S 183 x(enha)S -2 x(nces)S 182 x(system)S 183 x(reliabil)S
-2 x(ity)S 12644 Y 3899 X F20(OBJECTIVES)S 14387 Y 3899 X F30(\201)S
854 x(Describe)S 181 x(the)S 183 x(features)S 182 x(of)S 183 x(the)S
182 x(V)S -40 x(AX)S 183 x(9000)S 182 x(hardwa)S -2 x(re.)S 15583 Y
3899 X(\201)S 854 x(List)S 182 x(the)S 182 x(features)S 183 x(that)S
182 x(contribute)S 182 x(to)S 183 x(system)S 183 x(reliabi)S -2 x
(lity)S -41 x(.)S 16778 Y 3899 X(\201)S 854 x(List)S 182 x(the)S
182 x(I/O)S 184 x(devices)S 181 x(supported)S 182 x(on)S 182 x(V)S
-40 x(AX)S 183 x(9000)S 181 x(systems.)S 18522 Y 3899 X F20
(RESOURCES)S 20265 Y 3899 X F30(\201)S 37373 Y 21185 X F36(V)S -36 x
(AX)S 166 x(9000)S 165 x(Hardware)S 498 x(2\2033)S
PP
EP
%%DOC$Page: 2-4 4
1000 BP 39600 30600 PM 0 0 XY
2106 Y 3899 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4247 Y 3899 X F20(Instruc)S -2 x(tor)S 298 x
(Notes)S 5443 Y 3899 X 23316 96 R 6638 Y 3899 X F30(W)S -10 x(e)S
183 x(cover)S 182 x(the)S 182 x(HW)S 183 x(compone)S -2 x(nts)S 183 x
(in)S 182 x(order)S 183 x(from)S 183 x(smallest)S 182 x(to)S 183 x
(largest.)S 35879 Y 3899 X 23316 96 R 37373 Y 3899 X F36(2\2034.a)S
498 x(V)S -36 x(AX)S 166 x(9000)S 166 x(Hardware)S
PP
EP
%%DOC$Page: 2-4 5
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S
XP
% DefineFont:F24 Category:10 PointSize:14
/F24 700.0 /Helvetica-Bold@DOCPSE DPSF
RP
3899 4125 XY F24(NEW)S 232 x(TECHNOLO)S -2 x(GY)S 5869 Y 3899 X F30
(\201)S 854 x(Macro)S 183 x(cell)S 181 x(array)S 183 x(III)S 184 x
(\(MCA)S 184 x(III\))S 7064 Y 3899 X(\201)S 854 x(High)S 181 x
(density)S 182 x(signa)S -2 x(l)S 183 x(carrier)S 183 x(\(HDSC)S
182 x(interconne)S -2 x(ct\))S 8260 Y 3899 X(\201)S 854 x(Multichip)S
181 x(unit)S 182 x(\(MCU)S 183 x(unit\))S 9455 Y 3899 X(\201)S 854 x
(Planar)S 182 x(module)S 10999 Y 3899 X F24(Macro)S 232 x(Cell)S
232 x(Array)S 232 x(III)S 232 x(\(MCA)S 231 x(III\))S 12743 Y 3899 X
F30(\201)S 854 x(Third)S 180 x(generatio)S -2 x(n)S 181 x(ECL)S 180 x
(technolo)S -2 x(gy)S 181 x(10K)S 180 x(gate)S 180 x(arrays)S 181 x
(\(eight)S 181 x(times)S 180 x(denser)S 180 x(and)S 180 x(two)S 180 x
(times)S 181 x(faster)S 647 y 4945 X(than)S 182 x(the)S 182 x(MCA)S
183 x(I)S 183 x(devices)S 182 x(in)S 181 x(the)S 183 x(V)S -40 x(AX)S
183 x(8000)S 182 x(systems.\))S 14586 Y 3899 X(\201)S 854 x(10K)S
182 x(gates,)S 183 x(0.4)S 182 x(inches)S 181 x(square)S 15781 Y
3899 X(\201)S 854 x(Input)S 182 x(and)S 182 x(output)S 182 x(pins)S
181 x(\(256\))S 16977 Y 3899 X(\201)S 854 x(On-chip)S 182 x(gate)S
182 x(speed)S 181 x(of)S 183 x(0.2)S 182 x(ns)S 37373 Y 21185 X F36
(V)S -36 x(AX)S 166 x(9000)S 165 x(Hardware)S 498 x(2\2034)S
PP
EP
%%DOC$Page: 2-5 6
1000 BP 39600 30600 PM 0 0 XY
2106 Y 3899 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4247 Y 3899 X F20(Instruc)S -2 x(tor)S 298 x
(Notes)S 5443 Y 3899 X 23316 96 R 35879 Y 3899 X 23316 96 R 37373 Y
3899 X F36(2\2035.a)S 498 x(V)S -36 x(AX)S 166 x(9000)S 166 x
(Hardware)S
PP
EP
%%DOC$Page: 2-5 7
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4125 Y 3899 X F24(High)S 232 x(Density)S 231 x
(Signal)S 233 x(Carrier)S 232 x(\(HDSC)S 231 x(interconnect\))S
5869 Y 3899 X F30(\201)S 854 x(Repla)S -2 x(ces)S 182 x(printed)S
182 x(circuit)S 182 x(board)S 182 x(\(PCB\))S 184 x(-)S 183 x
(\(thirty)S 184 x(times)S 183 x(as)S 182 x(dense\))S 7064 Y 3899 X
(\201)S 854 x(IC)S 183 x(interconn)S -2 x(ect)S 183 x(\(4)S 183 x
(in)S 182 x(X)S 183 x(4)S 182 x(in\))S 648 y 4945 X(\(Eight)S 183 x
(gate)S 182 x(arrays,)S 183 x(48)S 182 x(STRAMS,)S 184 x(or)S 183 x
(a)S 182 x(mixture\))S 8907 Y 3899 X(\201)S 854 x(Short)S 183 x(and)S
182 x(fast)S 183 x(interconn)S -2 x(ects)S 10103 Y 3899 X(\201)S
854 x(W)S -20 x(afer)S 183 x(scale)S 181 x(technolo)S -2 x(gy)S
11298 Y 3899 X(\201)S 854 x(Routing)S 181 x(chann)S -2 x(els)S 182 x
(\(666/in)S
XP
% DefineFont:F42 Category:10 PointSize:8
/F42 400.0 /Helvetica@DOCPSE DPSF
RP
11066 11117 XY F42(2)S 181 y 25 x F30(\))S 12494 Y 3899 X(\201)S
854 x(Minimizes)S 182 x(propag)S -2 x(ation)S 182 x(delays)S 14038 Y
3899 X F24(Multichip)S 232 x(Unit)S 232 x(\(MCU)S 232 x(Unit\))S
15781 Y 3899 X F30(\201)S 854 x(Compact)S 182 x(solutio)S -2 x(n)S
183 x(for)S 183 x(housi)S -2 x(ng,)S 183 x(interconn)S -2 x(ecting,)S
182 x(and)S 182 x(coolin)S -2 x(g)S 183 x(ICs)S 16977 Y 3899 X(\201)S
854 x(6in)S -181 y F42(2)S 181 y 206 x F30(\202)S 183 x(Hold)S -2 x
(s)S 183 x(gate)S 182 x(arrays,)S 183 x(clock)S 182 x(driver)S -30 x
(,)S 183 x(and)S 181 x(heat)S 182 x(sink)S 18172 Y 3899 X(\201)S
854 x(One)S 182 x(MCU)S 183 x(uni)S -2 x(t)S 183 x(equals)S 181 x
(four)S 183 x(V)S -40 x(AX)S 184 x(8650)S -2 x(/8700)S 182 x
(modules)S 19368 Y 3899 X(\201)S 854 x(80K)S 182 x(gates)S 182 x
(per)S 183 x(MCU)S 182 x(unit)S 20563 Y 3899 X(\201)S 854 x
(Eight-hundred)S 181 x(signal)S 181 x(I/O)S 184 x(line)S -2 x(s)S
183 x(per)S 182 x(MCU)S 183 x(unit)S 21759 Y 3899 X(\201)S 854 x
(Air-cooled)S 23303 Y 3899 X F24(Planar)S 232 x(Module)S 25047 Y
3899 X F30(\201)S 854 x(Repla)S -2 x(ces)S 182 x(the)S 183 x(conven)S
-2 x(tional)S 182 x(backp)S -2 x(lane)S 26242 Y 3899 X(\201)S 854 x
(Contain)S -2 x(s)S 183 x(the)S 182 x(CPU)S 182 x(and)S 182 x
(cache,)S 182 x(and)S 182 x(the)S 182 x(option)S -2 x(al)S 182 x
(vector)S 183 x(processor)S 27438 Y 3899 X(\201)S 854 x(Each)S 182 x
(module)S 182 x(hold)S -2 x(s)S 183 x(up)S 182 x(to)S 183 x(16)S
182 x(MCU)S 182 x(units)S 28633 Y 3899 X(\201)S 854 x(V)S -30 x
(ertically-mounted)S 209 x(printed)S 209 x(wire)S 209 x(board)S 209 x
(\(PW)S 2 x(B\))S 211 x(with)S 209 x(24)S 209 x(layers)S 210 x(for)S
210 x(signal)S -2 x(,)S 217 x(ground,)S 216 x(and)S 209 x(power)S
648 y 4945 X(plane)S 181 x(\(It)S 184 x(contain)S -2 x(s)S 183 x
(the)S 182 x(equiva)S -2 x(lent)S 182 x(of)S 183 x(3500)S 181 x(ft)S
184 x(of)S 182 x(wire\).)S 37373 Y 21185 X F36(V)S -36 x(AX)S 166 x
(9000)S 165 x(Hardware)S 498 x(2\2035)S
PP
EP
%%DOC$Page: 2-6 8
1000 BP 39600 30600 PM 0 0 XY
2106 Y 3899 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4247 Y 3899 X F20(Instruc)S -2 x(tor)S 298 x
(Notes)S 5443 Y 3899 X 23316 96 R 35879 Y 3899 X 23316 96 R 37373 Y
3899 X F36(2\2036.a)S 498 x(V)S -36 x(AX)S 166 x(9000)S 166 x
(Hardware)S
PP
EP
%%DOC$Page: 2-6 9
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4275 Y 3899 X F20(UNIQUE)S 300 x(DESIGN)S 299 x
(FEA)S -66 x(TURES)S 6019 Y 3899 X F30(\201)S 854 x(Balanced)S 181 x
(systems)S 7214 Y 3899 X(\201)S 854 x(Relia)S -2 x(ble)S 182 x(and)S
181 x(availab)S -2 x(le)S 8410 Y 3899 X(\201)S 854 x(Air-cooled)S
9954 Y 3899 X F24(Balance)S -2 x(d)S 233 x(Systems)S 11697 Y 3899 X
F30(\201)S 854 x(CPU)S 182 x(performance)S 12893 Y 3899 X(\201)S
854 x(I/O)S 184 x(band)S -2 x(width)S 14088 Y 3899 X(\201)S 854 x
(Memory)S 183 x(bandw)S -2 x(idth)S 37373 Y 21185 X F36(V)S -36 x
(AX)S 166 x(9000)S 165 x(Hardware)S 498 x(2\2036)S
PP
EP
%%DOC$Page: 2-7 10
1000 BP 39600 30600 PM 0 0 XY
2106 Y 3899 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4247 Y 3899 X F20(Instruc)S -2 x(tor)S 298 x
(Notes)S 5443 Y 3899 X 23316 96 R 35879 Y 3899 X 23316 96 R 37373 Y
3899 X F36(2\2037.a)S 498 x(V)S -36 x(AX)S 166 x(9000)S 166 x
(Hardware)S
PP
EP
%%DOC$Page: 2-7 11
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S
XP
% DefineFont:F28 Category:10 PointSize:12
/F28 600.0 /Helvetica-Bold@DOCPSE DPSF
RP
3899 4050 XY F28(V)S -45 x(AX)S 199 x(9000)S 201 x(System)S 200 x
(Block)S 200 x(Diagram)S
4082 5196 XY
4082 18347 SPB
% Begin Plot (bal_sys.eps)
%!PS-Adobe-2.0 EPSF 1.2
%%File: WORK2:[HUBBARD.SALES]BAL_SYS.EPS
%%Creator: PSART, PostScript ART V1.1
%%Copyright 1987,1988,1989 DIGITAL EQUIPMENT CORPORATION. All Rights Reserved.
%%CreationDate: Fri Nov 17 13:49:32 1989
%%This file to be included in a DOCUMENT-produced file
%%
%%DOCUMENT <FIGURE_FILE> reservation = 22 picas.
%%
%%BoundingBox: 30 0 438 256
%%DocumentFonts: PSART-Helvetica
%%This file processed with the following qualifiers:
%%
%% /All_directions
%% /Centered = 6.5
%% /Comment_delimiter = !
%% /NoControl
%% /Encapsulated
%% /NoIges
%% /ISO (ISOLatin1 Character Encoding)
%% /Output = WORK2:[HUBBARD.SALES]BAL_SYS.EPS
%% /NoPicmode
%% /Rotate = 0.00 degrees
%% /Size = 8
%% /Text_adjust = 4
%% /Thick = 1.44 points
%% /Thin = 0.86 points
%% /Type = HELV
%% /Xoffset = 0.00 inches
%% /Xscale = 1.00
%% /Yoffset = 0.00 inches
%% /Yscale = 1.00
%%
%% Analyzed character strings have maximum average width
%% of 5.07 points and a maximum average height of 6.04
%% points, with 3.02 points of leading between lines.
%%
%%EndComments
/reencode { findfont begin currentdict dup length dict begin { 1 index
/FID ne {def} {pop pop} ifelse } forall /FontName exch def dup length
0 ne { /Encoding Encoding 256 array copy def 0 exch { dup type
/nametype eq { Encoding 2 index 2 index put pop 1 add }{ exch pop }
ifelse } forall } if pop currentdict dup end end /FontName get exch
definefont pop } bind def mark /ISOLatin1 8#000 1 8#054
{StandardEncoding exch get} for /minus 8#056 1 8#217 {StandardEncoding
exch get} for /dotlessi 8#301 1 8#317 {StandardEncoding exch get} for
/space /exclamdown /cent /sterling /currency /yen /brokenbar /section
/dieresis /copyright /ordfeminine /guillemotleft /logicalnot /hyphen
/registered /macron /degree /plusminus /twosuperior /threesuperior
/acute /mu /paragraph /periodcentered /cedilla /onesuperior
/ordmasculine /guillemotright /onequarter /onehalf /threequarters
/questiondown /Agrave /Aacute /Acircumflex /Atilde /Adieresis /Aring
/AE /Ccedilla /Egrave /Eacute /Ecircumflex /Edieresis /Igrave /Iacute
/Icircumflex /Idieresis /Eth /Ntilde /Ograve /Oacute /Ocircumflex
/Otilde /Odieresis /multiply /Oslash /Ugrave /Uacute /Ucircumflex
/Udieresis /Yacute /Thorn /germandbls /agrave /aacute /acircumflex
/atilde /adieresis /aring /ae /ccedilla /egrave /eacute /ecircumflex
/edieresis /igrave /iacute /icircumflex /idieresis /eth /ntilde
/ograve /oacute /ocircumflex /otilde /odieresis /divide /oslash
/ugrave /uacute /ucircumflex /udieresis /yacute /thorn /ydieresis
/ISOLatin1 where not {256 array astore def} if cleartomark /DECMCS
ISOLatin1 256 array copy def mark 8#240 8#244 8#246 8#254 8#255 8#256
8#257 8#264 8#270 8#276 8#320 8#336 8#360 8#376 8#377 counttomark
{DECMCS exch /.notdef put} repeat 8#250 /currency 8#327 /OE 8#335
/Ydieresis 8#367 /oe 8#375 /ydieresis counttomark -1 bitshift {DECMCS
3 1 roll put} repeat cleartomark
%
%%Page
[1.00 0.00 0.00 1.00 31.44 0.72] concat
/psarrow
{
newpath -8.00 0.0 moveto 0.0 0.30 rlineto
-0.10 0.60 rlineto
-0.20 0.60 rlineto
-0.30 0.40 rlineto
-0.40 0.30 rlineto
9.00 -2.20 rlineto
-9.00 -2.20 rlineto
0.40 0.30 rlineto
0.30 0.40 rlineto
0.20 0.60 rlineto
0.10 0.60 rlineto
0.0 0.30 rlineto
closepath fill
} bind def
1 setlinecap 1 setlinejoin
ISOLatin1 /PSART-Helvetica /Helvetica reencode
/PSART-Helvetica findfont 8.00 scalefont setfont
5.82 241.60 moveto 0.40 0.00 (SCALAR) ashow
239.56 241.60 moveto 0.40 0.00 (1 GByte s) ashow
51.15 232.54 moveto 0.40 0.00 (CACHE) ashow
178.44 232.54 moveto 0.40 0.00 (System) ashow
178.44 223.48 moveto 0.40 0.00 (Control) ashow
178.44 214.42 moveto 0.40 0.00 (Unit) ashow
178.44 196.30 moveto 0.40 0.00 (\(SCU\)) ashow
306.69 232.54 moveto 0.40 0.00 (Memory) ashow
105.12 223.48 moveto 0.40 0.00 (1 GByte s) ashow
358.25 114.76 moveto 0.40 0.00 (XMI) ashow
349.94 24.16 moveto 0.40 0.00 (CI NI BI SI) ashow
5.16 223.48 moveto 0.40 0.00 (VECTOR) ashow
239.56 105.70 moveto 0.40 0.00 (1 GByte s) ashow
51.15 178.18 moveto 0.40 0.00 (CACHE) ashow
173.17 42.28 moveto 0.40 0.00 (Service) ashow
173.17 33.22 moveto 0.40 0.00 (Processor) ashow
311.33 96.64 moveto 0.40 0.00 (I/O) ashow
105.12 169.12 moveto 0.40 0.00 (1 GByte s) ashow
5.82 187.24 moveto 0.40 0.00 (SCALAR) ashow
51.15 123.82 moveto 0.40 0.00 (CACHE) ashow
173.64 15.10 moveto 0.40 0.00 (Scan) ashow
173.64 6.04 moveto 0.40 0.00 (Controller) ashow
105.12 114.76 moveto 0.40 0.00 (1 GByte s) ashow
5.16 169.12 moveto 0.40 0.00 (VECTOR) ashow
51.15 69.46 moveto 0.40 0.00 (CACHE) ashow
105.12 60.40 moveto 0.40 0.00 (1 GByte s) ashow
5.82 132.88 moveto 0.40 0.00 (SCALAR) ashow
5.16 114.76 moveto 0.40 0.00 (VECTOR) ashow
5.82 78.52 moveto 0.40 0.00 (SCALAR) ashow
5.16 60.40 moveto 0.40 0.00 (VECTOR) ashow
gsave
223.21 253.68 translate 180.00 rotate psarrow
grestore
newpath 288.23 253.68 moveto 229.21 253.68 lineto 0.864 setlinewidth stroke
gsave
294.23 253.68 translate 0.00 rotate psarrow
grestore
gsave
86.24 235.56 translate 180.00 rotate psarrow
grestore
newpath 156.33 235.56 moveto 92.24 235.56 lineto 0.864 setlinewidth stroke
gsave
162.34 235.56 translate 0.00 rotate psarrow
grestore
gsave
223.21 235.56 translate 180.00 rotate psarrow
grestore
newpath 288.23 235.56 moveto 229.21 235.56 lineto 0.864 setlinewidth stroke
gsave
294.23 235.56 translate 0.00 rotate psarrow
grestore
gsave
86.24 181.20 translate 180.00 rotate psarrow
grestore
newpath 156.33 181.20 moveto 92.24 181.20 lineto 0.864 setlinewidth stroke
gsave
162.34 181.20 translate 0.00 rotate psarrow
grestore
gsave
86.24 126.84 translate 180.00 rotate psarrow
grestore
newpath 156.33 126.84 moveto 92.24 126.84 lineto 0.864 setlinewidth stroke
gsave
162.34 126.84 translate 0.00 rotate psarrow
grestore
gsave
223.21 117.78 translate 180.00 rotate psarrow
grestore
newpath 288.23 117.78 moveto 229.21 117.78 lineto 0.864 setlinewidth stroke
gsave
294.23 117.78 translate 0.00 rotate psarrow
grestore
gsave
405.84 108.72 translate 0.00 rotate psarrow
grestore
newpath 344.96 108.72 moveto 399.84 108.72 lineto 0.864 setlinewidth stroke
gsave
223.21 99.66 translate 180.00 rotate psarrow
grestore
newpath 288.23 99.66 moveto 229.21 99.66 lineto 0.864 setlinewidth stroke
gsave
294.23 99.66 translate 0.00 rotate psarrow
grestore
gsave
400.77 99.66 translate 0.00 rotate psarrow
grestore
newpath 344.96 99.66 moveto 394.76 99.66 lineto 0.864 setlinewidth stroke
gsave
395.69 90.60 translate 0.00 rotate psarrow
grestore
newpath 344.96 90.60 moveto 389.69 90.60 lineto 0.864 setlinewidth stroke
gsave
86.24 72.48 translate 180.00 rotate psarrow
grestore
newpath 156.33 72.48 moveto 92.24 72.48 lineto 0.864 setlinewidth stroke
gsave
162.34 72.48 translate 0.00 rotate psarrow
grestore
gsave
350.04 27.18 translate 270.00 rotate psarrow
grestore
newpath 350.04 81.54 moveto 350.04 33.18 lineto 0.864 setlinewidth stroke
gsave
360.18 27.18 translate 270.00 rotate psarrow
grestore
newpath 360.18 81.54 moveto 360.18 33.18 lineto 0.864 setlinewidth stroke
gsave
370.33 27.18 translate 270.00 rotate psarrow
grestore
newpath 370.33 81.54 moveto 370.33 33.18 lineto 0.864 setlinewidth stroke
gsave
380.48 27.18 translate 270.00 rotate psarrow
grestore
newpath 380.48 81.54 moveto 380.47 33.18 lineto 0.864 setlinewidth stroke
newpath 0.00 253.68 moveto 86.24 0.00 rlineto 1.440 setlinewidth stroke
newpath 0.00 253.68 moveto 0.00 -36.24 rlineto 1.440 setlinewidth stroke
newpath 45.66 253.68 moveto 0.00 -36.24 rlineto 1.440 setlinewidth stroke
newpath 86.24 253.68 moveto 0.00 -36.24 rlineto 1.440 setlinewidth stroke
newpath 162.34 253.68 moveto 60.88 0.00 rlineto 1.440 setlinewidth stroke
newpath 162.34 253.68 moveto 0.00 -253.68 rlineto 1.440 setlinewidth stroke
newpath 223.21 253.68 moveto 0.00 -253.68 rlineto 1.440 setlinewidth stroke
newpath 294.23 253.68 moveto 55.80 0.00 rlineto 1.440 setlinewidth stroke
newpath 294.23 253.68 moveto 0.00 -36.24 rlineto 1.440 setlinewidth stroke
newpath 350.04 253.68 moveto 0.00 -36.24 rlineto 1.440 setlinewidth stroke
newpath 0.00 235.56 moveto 45.66 0.00 rlineto 1.440 setlinewidth stroke
newpath 0.00 217.44 moveto 86.24 0.00 rlineto 1.440 setlinewidth stroke
newpath 294.23 217.44 moveto 55.80 0.00 rlineto 1.440 setlinewidth stroke
newpath 0.00 199.32 moveto 86.24 0.00 rlineto 1.440 setlinewidth stroke
newpath 0.00 199.32 moveto 0.00 -36.24 rlineto 1.440 setlinewidth stroke
newpath 45.66 199.32 moveto 0.00 -36.24 rlineto 1.440 setlinewidth stroke
newpath 86.24 199.32 moveto 0.00 -36.24 rlineto 1.440 setlinewidth stroke
newpath 0.00 181.20 moveto 45.66 0.00 rlineto 1.440 setlinewidth stroke
newpath 0.00 163.08 moveto 86.24 0.00 rlineto 1.440 setlinewidth stroke
newpath 0.00 144.96 moveto 86.24 0.00 rlineto 1.440 setlinewidth stroke
newpath 0.00 144.96 moveto 0.00 -36.24 rlineto 1.440 setlinewidth stroke
newpath 45.66 144.96 moveto 0.00 -36.24 rlineto 1.440 setlinewidth stroke
newpath 86.24 144.96 moveto 0.00 -36.24 rlineto 1.440 setlinewidth stroke
newpath 0.00 126.84 moveto 45.66 0.00 rlineto 1.440 setlinewidth stroke
newpath 294.23 117.78 moveto 45.66 0.00 rlineto 1.440 setlinewidth stroke
newpath 294.23 117.78 moveto 0.00 -45.30 rlineto 1.440 setlinewidth stroke
newpath 339.89 117.78 moveto 0.00 -45.30 rlineto 1.440 setlinewidth stroke
newpath 0.00 108.72 moveto 86.24 0.00 rlineto 1.440 setlinewidth stroke
newpath 0.00 90.60 moveto 86.24 0.00 rlineto 1.440 setlinewidth stroke
newpath 0.00 90.60 moveto 0.00 -36.24 rlineto 1.440 setlinewidth stroke
newpath 45.66 90.60 moveto 0.00 -36.24 rlineto 1.440 setlinewidth stroke
newpath 86.24 90.60 moveto 0.00 -36.24 rlineto 1.440 setlinewidth stroke
newpath 350.04 81.54 moveto 30.44 0.00 rlineto 0.864 setlinewidth stroke
newpath 350.04 81.54 moveto -5.07 0.00 rlineto 0.864 setlinewidth stroke
newpath 0.00 72.48 moveto 45.66 0.00 rlineto 1.440 setlinewidth stroke
newpath 294.23 72.48 moveto 45.66 0.00 rlineto 1.440 setlinewidth stroke
newpath 0.00 54.36 moveto 86.24 0.00 rlineto 1.440 setlinewidth stroke
newpath 162.34 54.36 moveto 60.88 0.00 rlineto 1.440 setlinewidth stroke
newpath 162.34 27.18 moveto 60.88 0.00 rlineto 1.440 setlinewidth stroke
newpath 162.34 0.00 moveto 60.88 0.00 rlineto 1.440 setlinewidth stroke
showpage
%%Trailer
% End Plot
SPE
XP
% DefineFont:F28 Category:10 PointSize:12
/Helvetica-Bold /Helvetica-Bold@DOCPSE DOCPSE ReENCODE
/F28 600.0 /Helvetica-Bold@DOCPSE DPSF
RP
3899 20439 XY F28(System)S 200 x(Control)S 200 x(Unit)S 199 x
(\(SCU\))S
XP
% DefineFont:F30 Category:10 PointSize:11
/Helvetica /Helvetica@DOCPSE DOCPSE ReENCODE
/F30 550.0 /Helvetica@DOCPSE DPSF
RP
3899 22182 XY F30(\201)S 854 x(Key)S 183 x(to)S 182 x(a)S 183 x
(bala)S -2 x(nced)S 182 x(system)S 23378 Y 3899 X(\201)S 854 x
(Manages)S 181 x(the)S 183 x(\212ow)S 181 x(of)S 183 x(data)S 182 x
(between)S 181 x(processors,)S 182 x(memory)S -40 x(,)S 183 x(and)S
182 x(I/O)S 184 x(buses)S 24573 Y 3899 X(\201)S 854 x(Crossbar)S
182 x(switch)S 182 x(\(not)S 183 x(a)S 182 x(bus\))S 182 x(with)S
182 x(four)S 183 x(paths)S 25769 Y 3899 X(\201)S 854 x(Allows)S 182 x
(up)S 182 x(to)S 182 x(four)S 183 x(simultaneo)S -2 x(us)S 183 x
(data)S 182 x(transfers)S 183 x(\(500)S 182 x(Mbytes/s)S 183 x
(transfers\))S 183 x(at)S 183 x(any)S 182 x(moment)S 26964 Y 4945 X
(\(Resulting)S 181 x(2)S 182 x(Gbytes/s)S 183 x(bandw)S -2 x(idth)S
182 x(is)S 182 x(20)S 182 x(times)S 183 x(faster)S 183 x(than)S 182 x
(previous)S 181 x(designs.\))S 28160 Y 3899 X(\201)S 854 x(Uses)S
182 x(redunda)S -2 x(nt)S 183 x(circuits)S 182 x(to)S 183 x(reduce)S
182 x(the)S 182 x(number)S 182 x(of)S 183 x(singl)S -2 x(e)S 183 x
(poi)S -2 x(nts)S 183 x(of)S 183 x(failure)S
XP
% DefineFont:F36 Category:10 PointSize:10
/F36 500.0 /Helvetica-Bold@DOCPSE DPSF
RP
21185 37373 XY F36(V)S -36 x(AX)S 166 x(9000)S 165 x(Hardware)S 498 x
(2)S
(\2037)S
PP
EP
%%DOC$Page: 2-8 12
1000 BP 39600 30600 PM 0 0 XY
2106 Y 3899 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S
XP
% DefineFont:F20 Category:10 PointSize:18
/F20 900.0 /Helvetica-Bold@DOCPSE DPSF
RP
3899 4247 XY F20(Instruc)S -2 x(tor)S 298 x(Notes)S 5443 Y 3899 X
23316 96 R 6638 Y 3899 X F30(30)S 152 x(VUPS)S 154 x(is)S 152 x(the)S
152 x(publici)S -2 x(zed)S 152 x(estimate.)S 234 x(Actual)S 152 x
(benchmarks)S 152 x(average)S 152 x(more)S 153 x(like)S 151 x(40.)S
234 x(See)S 152 x(section)S 152 x(later)S 648 y 3899 X(on)S 182 x
(bench)S -2 x(marks.)S 35879 Y 3899 X 23316 96 R 37373 Y 3899 X F36
(2)S
(\2038.a)S 498 x(V)S -36 x(AX)S 166 x(9000)S 166 x(Hardware)S
PP
EP
%%DOC$Page: 2-8 13
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4050 Y 3899 X F28(V)S -45 x(AX)S 199 x(9000)S
201 x(CPU)S 198 x(Performance)S 5794 Y 3899 X F30(\201)S 854 x(CPU)S
182 x(is)S 183 x(roughl)S -2 x(y)S 183 x(30)S 182 x(times)S 183 x
(faster)S 183 x(than)S 182 x(V)S -40 x(AX)S 183 x(1)S -41 x(1/780)S
182 x(system.)S 6989 Y 3899 X(\201)S 854 x(Cycle)S 181 x(time)S 183 x
(is)S 182 x(16)S 182 x(ns)S 183 x(\(vs.)S 244 x(a)S 182 x(cycle)S
182 x(time)S 183 x(of)S 182 x(28)S 182 x(ns)S 183 x(on)S 182 x(the)S
182 x(V)S -40 x(AX)S 184 x(600)S -2 x(0)S 183 x(model)S 181 x(410)S
182 x(system\).)S 648 y 4945 X(\(Increased)S 182 x(speed)S 181 x
(due)S 182 x(to)S 183 x(the)S 182 x(MCU)S 182 x(unit)S 182 x
(technolo)S -2 x(gy)S 183 x(and)S 181 x(the)S 183 x(ECL)S 182 x
(gate)S 182 x(arrays.\))S 8832 Y 3899 X(\201)S 854 x(Dual)S 238 x
(cache)S 239 x(\(128)S 239 x(Kbytes)S 239 x(of)S 240 x(data)S 239 x
(cache)S 238 x(and)S 238 x(8)S 240 x(Kbytes)S 239 x(of)S 240 x
(virtual)S 239 x(instruction)S 238 x(cache\))S 239 x(boosts)S 648 y
4945 X(performance)S 182 x(by)S 182 x(more)S 183 x(ef)S -10 x
(\211cient)S 182 x(handli)S -2 x(ng)S 182 x(of)S 183 x(programs)S
183 x(and)S 181 x(data.)S 10675 Y 3899 X(\201)S 854 x(Internal)S
233 x(data)S 234 x(paths)S 233 x(\(64-bit\))S 234 x(make)S 234 x
(doub)S -2 x(le)S 234 x(precisio)S -2 x(n)S 234 x(arithmetic)S 234 x
(perform)S 234 x(at)S 234 x(nearly)S 233 x(the)S 234 x(same)S 648 y
4945 X(speed)S 181 x(as)S 182 x(single)S 181 x(precision.)S 12518 Y
3899 X(\201)S 854 x(Cycles)S 181 x(per)S 183 x(instruction\2023)S
-2 x(8%)S 183 x(more)S 183 x(ef)S -10 x(\211ciency)S 181 x(than)S
182 x(V)S -40 x(AX)S 184 x(8xxx)S 182 x(systems.)S 14013 Y 3899 X
F28(V)S -45 x(AX)S 199 x(9000)S 201 x(I/O)S 199 x(Bandwidth)S 15756 Y
3899 X F30(\201)S 854 x(XMI)S 184 x(bus)S 182 x(is)S 182 x(strictly)S
183 x(an)S 182 x(I/O)S 184 x(bus.)S 16952 Y 3899 X(\201)S 854 x(T)S
-30 x(welve)S 181 x(slots)S 182 x(per)S 182 x(XMI)S 184 x(allow)S
181 x(multiple)S 182 x(adap)S -2 x(ters.)S 18147 Y 3899 X(\201)S
854 x(Bandwid)S -2 x(th)S 183 x(up)S 182 x(to)S 183 x(320)S 181 x
(Mbytes/s)S 183 x(in)S 182 x(the)S 182 x(V)S -40 x(AX)S 184 x(9000)S
181 x(model)S 182 x(4xx)S 182 x(systems.)S 19343 Y 3899 X(\201)S
854 x(I/O)S 184 x(subsystems)S 182 x(capab)S -2 x(ility)S 182 x(is)S
183 x(twenty)S 182 x(times)S 182 x(previous)S 182 x(V)S -40 x(AX)S
183 x(systems.)S 20837 Y 3899 X F28(V)S -45 x(AX)S 199 x(9000)S 201 x
(Memory)S 200 x(Bandwidth)S 22581 Y 3899 X F30(\201)S 854 x(Necessa)S
-2 x(ry)S 184 x(to)S 182 x(balan)S -2 x(ce)S 183 x(high)S 181 x(CPU)S
182 x(performance)S 23776 Y 3899 X(\201)S 854 x(T)S -61 x(en)S 182 x
(times)S 183 x(previou)S -2 x(s)S 183 x(V)S -40 x(AX)S 183 x
(systems)S 24972 Y 3899 X(\201)S 854 x(Standard)S 182 x(-)S 183 x
(256)S 182 x(Mbytes)S 647 y 4945 X(V)S -40 x(AX)S 183 x(9000)S 182 x
(models)S 181 x(430)S 182 x(and)S 182 x(440)S 181 x(systems)S 183 x
(-)S 183 x(512)S 182 x(Mbytes)S 648 y 4945 X(\(Reduces)S 181 x
(paging)S 181 x(and)S 181 x(swappin)S -2 x(g\))S 27462 Y 3899 X
(\201)S 854 x(Simultaneou)S -2 x(s)S 183 x(reads)S 182 x(and)S 182 x
(writes)S 182 x(at)S 183 x(500)S 181 x(Mbytes/s)S 28658 Y 3899 X
(\201)S 854 x(Peak)S 182 x(memory)S 184 x(to)S 182 x(processor)S
182 x(bandwi)S -2 x(dth)S 183 x(up)S 182 x(to)S 182 x(2)S 182 x
(Gbytes/s)S 37373 Y 21185 X F36(V)S -36 x(AX)S 166 x(9000)S 165 x
(Hardware)S 498 x(2\2038)S
PP
EP
%%DOC$Page: 2-9 14
1000 BP 39600 30600 PM 0 0 XY
2106 Y 3899 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4247 Y 3899 X F20(Instruc)S -2 x(tor)S 298 x
(Notes)S 5443 Y 3899 X 23316 96 R 35879 Y 3899 X 23316 96 R 37373 Y
3899 X F36(2\2039.a)S 498 x(V)S -36 x(AX)S 166 x(9000)S 166 x
(Hardware)S
PP
EP
%%DOC$Page: 2-9 15
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4247 Y 3899 X F20(RELIABILI)S 2 x(TY)S 298 x
(AND)S 300 x(A)S -66 x(V)S -66 x(AILABI)S 2 x(LITY)S 5991 Y 3899 X
F30(\201)S 854 x(Thirty)S 167 x(percent)S 166 x(of)S 166 x(V)S -40 x
(AX)S 168 x(9000)S 165 x(circuitry)S 167 x(is)S 167 x(devoted)S 165 x
(to)S 167 x(error)S 167 x(detection,)S 169 x(correction,)S 170 x
(diag)S -2 x(nosis,)S 169 x(and)S 647 y 4945 X(redunda)S -2 x(ncy)S
-41 x(.)S 7834 Y 3899 X(\201)S 854 x(High)S 181 x(reliabil)S -2 x
(ity)S 183 x(and)S 181 x(availab)S -2 x(ility)S 182 x(achieve)S -2 x
(d)S 183 x(by)S 182 x(the)S 182 x(followi)S -2 x(ng:)S 9029 Y 4945 X
(\202)S 498 x(Fault)S 182 x(avoid)S -2 x(ance)S 10225 Y 4945 X(\202)S
498 x(Error)S 184 x(detection/an)S -2 x(alysis)S 11420 Y 4945 X
(\202)S 498 x(Serviceabil)S -2 x(ity)S
XP
% DefineFont:F32 Category:10 PointSize:11
/F32 550.0 /Helvetica-Bold@DOCPSE DPSF
RP
3899 13313 XY F32(Figure)S 182 x(2\2031)S 680 x(Fault)S 182 x(A)S
-20 x(voidance)S -2 x(\202Hardware)S 182 x(Redun)S -2 x(dancy)S
4082 14031 XY
4082 26584 SPB
% Begin Plot (fault_avoidance.eps)
%!PS-Adobe-2.0 EPSF 1.2
%%File: USER3:[COMP.RB0057]FAULT_AVOIDANCE.EPS
%%Creator: PSART, PostScript ART V1.1
%%Copyright 1987,1988,1989 DIGITAL EQUIPMENT CORPORATION. All Rights Reserved.
%%CreationDate: Wed Dec 13 14:31:03 1989
%%This file to be included in a DOCUMENT-produced file
%%
%%DOCUMENT <FIGURE_FILE> reservation = 20 picas.
%%
%%BoundingBox: 62 0 406 240
%%DocumentFonts: PSART-Helvetica
%%This file processed with the following qualifiers:
%%
%% /All_directions
%% /Centered = 6.5
%% /Comment_delimiter = !
%% /NoControl
%% /Encapsulated
%% /NoIges
%% /ISO (ISOLatin1 Character Encoding)
%% /Output = USER3:[COMP.RB0057]FAULT_AVOIDANCE.EPS
%% /NoPicmode
%% /Rotate = 0.00 degrees
%% /Size = 10
%% /Text_adjust = 4
%% /Thick = 1.44 points
%% /Thin = 0.86 points
%% /Type = HELV
%% /Xoffset = 0.00 inches
%% /Xscale = 1.00
%% /Yoffset = 0.00 inches
%% /Yscale = 1.00
%%
%% Analyzed character strings have maximum average width
%% of 5.04 points and a maximum average height of 7.55
%% points, with 3.78 points of leading between lines.
%%
%%EndComments
/reencode { findfont begin currentdict dup length dict begin { 1 index
/FID ne {def} {pop pop} ifelse } forall /FontName exch def dup length
0 ne { /Encoding Encoding 256 array copy def 0 exch { dup type
/nametype eq { Encoding 2 index 2 index put pop 1 add }{ exch pop }
ifelse } forall } if pop currentdict dup end end /FontName get exch
definefont pop } bind def mark /ISOLatin1 8#000 1 8#054
{StandardEncoding exch get} for /minus 8#056 1 8#217 {StandardEncoding
exch get} for /dotlessi 8#301 1 8#317 {StandardEncoding exch get} for
/space /exclamdown /cent /sterling /currency /yen /brokenbar /section
/dieresis /copyright /ordfeminine /guillemotleft /logicalnot /hyphen
/registered /macron /degree /plusminus /twosuperior /threesuperior
/acute /mu /paragraph /periodcentered /cedilla /onesuperior
/ordmasculine /guillemotright /onequarter /onehalf /threequarters
/questiondown /Agrave /Aacute /Acircumflex /Atilde /Adieresis /Aring
/AE /Ccedilla /Egrave /Eacute /Ecircumflex /Edieresis /Igrave /Iacute
/Icircumflex /Idieresis /Eth /Ntilde /Ograve /Oacute /Ocircumflex
/Otilde /Odieresis /multiply /Oslash /Ugrave /Uacute /Ucircumflex
/Udieresis /Yacute /Thorn /germandbls /agrave /aacute /acircumflex
/atilde /adieresis /aring /ae /ccedilla /egrave /eacute /ecircumflex
/edieresis /igrave /iacute /icircumflex /idieresis /eth /ntilde
/ograve /oacute /ocircumflex /otilde /odieresis /divide /oslash
/ugrave /uacute /ucircumflex /udieresis /yacute /thorn /ydieresis
/ISOLatin1 where not {256 array astore def} if cleartomark /DECMCS
ISOLatin1 256 array copy def mark 8#240 8#244 8#246 8#254 8#255 8#256
8#257 8#264 8#270 8#276 8#320 8#336 8#360 8#376 8#377 counttomark
{DECMCS exch /.notdef put} repeat 8#250 /currency 8#327 /OE 8#335
/Ydieresis 8#367 /oe 8#375 /ydieresis counttomark -1 bitshift {DECMCS
3 1 roll put} repeat cleartomark
%
%%Page
[1.00 0.00 0.00 1.00 62.80 0.72] concat
1 setlinecap 1 setlinejoin
ISOLatin1 /PSART-Helvetica /Helvetica reencode
/PSART-Helvetica findfont 10.00 scalefont setfont
187.04 222.73 moveto 0.40 0.00 (VAX 9000) ashow
187.04 211.40 moveto 0.40 0.00 (Model 210) ashow
283.28 222.73 moveto 0.40 0.00 (VAX 9000) ashow
283.28 211.40 moveto 0.40 0.00 (Model 4xx) ashow
8.06 188.75 moveto 0.40 0.00 (Redundancy in system control unit) ashow
8.06 166.10 moveto 0.40 0.00 (Redundant power supplies on each) ashow
8.06 132.13 moveto 0.40 0.00 (Duplicate internal data structures) ashow
8.06 109.48 moveto 0.40 0.00 (Memory system has multiple segments) ashow
8.06 64.18 moveto 0.40 0.00 (Memory battery back-up) ashow
8.06 41.53 moveto 0.40 0.00 (Configure multiple CPUs) ashow
8.06 7.55 moveto 0.40 0.00 (Redundant AC power source \(UPC\)) ashow
199.52 188.75 moveto 0.40 0.00 (Yes) ashow
199.52 154.78 moveto 0.40 0.00 (No) ashow
199.52 132.13 moveto 0.40 0.00 (Yes) ashow
199.52 86.83 moveto 0.40 0.00 (Yes) ashow
199.52 64.18 moveto 0.40 0.00 (Yes) ashow
199.52 30.20 moveto 0.40 0.00 (No) ashow
199.52 7.55 moveto 0.40 0.00 (Optional) ashow
293.53 188.75 moveto 0.40 0.00 (Yes) ashow
293.53 154.78 moveto 0.40 0.00 (Yes) ashow
293.53 132.13 moveto 0.40 0.00 (Yes) ashow
293.53 86.83 moveto 0.40 0.00 (Yes) ashow
293.53 64.18 moveto 0.40 0.00 (Yes) ashow
293.53 30.20 moveto 0.40 0.00 (Yes) ashow
293.53 7.55 moveto 0.40 0.00 (Standard) ashow
16.12 154.78 moveto 0.40 0.00 (power bus) ashow
22.36 30.20 moveto 0.40 0.00 (and I/O buses) ashow
17.92 98.15 moveto 0.40 0.00 (and multiple banks which can) ashow
17.92 86.83 moveto 0.40 0.00 (be mapped out) ashow
newpath 0.00 237.83 moveto 342.41 0.00 rlineto 1.440 setlinewidth stroke
newpath 0.00 237.83 moveto 0.00 -237.83 rlineto 1.440 setlinewidth stroke
newpath 342.41 237.83 moveto 0.00 -237.83 rlineto 1.440 setlinewidth stroke
newpath 0.00 203.85 moveto 342.41 0.00 rlineto 1.440 setlinewidth stroke
newpath 0.00 0.00 moveto 342.41 0.00 rlineto 1.440 setlinewidth stroke
showpage
%%Trailer
% End Plot
SPE
XP
% DefineFont:F36 Category:10 PointSize:10
/Helvetica-Bold /Helvetica-Bold@DOCPSE DOCPSE ReENCODE
/F36 500.0 /Helvetica-Bold@DOCPSE DPSF
RP
21185 37373 XY F36(V)S -36 x(AX)S 166 x(9000)S 165 x(Hardware)S 498 x
(2)S
(\2039)S
PP
EP
%%DOC$Page: 2-10 16
1000 BP 39600 30600 PM 0 0 XY
2106 Y 3899 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S
XP
% DefineFont:F20 Category:10 PointSize:18
/F20 900.0 /Helvetica-Bold@DOCPSE DPSF
RP
3899 4247 XY F20(Instruc)S -2 x(tor)S 298 x(Notes)S 5443 Y 3899 X
23316 96 R
XP
% DefineFont:F30 Category:10 PointSize:11
/Helvetica /Helvetica@DOCPSE DOCPSE ReENCODE
/F30 550.0 /Helvetica@DOCPSE DPSF
RP
3899 6638 XY F30(Do)S 215 x(not)S 216 x(confuse)S 214 x(UPC)S 216 x
(with)S 215 x(UPS)S 216 x(\(uninterruptible)S 214 x(power)S 215 x
(supply\);)S 232 x(this)S 216 x(is)S 215 x(not)S 216 x(a)S 215 x
(UPS.)S 217 x(\(V)S -40 x(AXf)S 2 x(t)S 216 x(3000)S 648 y 3899 X
(system)S 183 x(has)S 182 x(a)S 182 x(UPS.\))S 35879 Y 3899 X
23316 96 R 37373 Y 3899 X F36(2\20310.a)S 498 x(V)S -36 x(AX)S 166 x
(9000)S 166 x(Hardware)S
PP
EP
%%DOC$Page: 2-10 17
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S
XP
% DefineFont:F24 Category:10 PointSize:14
/F24 700.0 /Helvetica-Bold@DOCPSE DPSF
RP
3899 4125 XY F24(Fault)S 232 x(A)S -26 x(voidance\202V)S -52 x(AX)S
232 x(9000)S 232 x(Systems)S 5869 Y 3899 X F30(\201)S 854 x(Dynamic)S
182 x(error)S 183 x(checkin)S -2 x(g)S 7064 Y 3899 X(\201)S 854 x
(Micro/Macro)S 183 x(recovery)S 183 x(techniq)S -2 x(ues)S 8260 Y
3899 X(\201)S 854 x(Agressive)S 182 x(availa)S -2 x(bility)S 182 x
(goal)S -2 x(s)S 183 x(for)S 183 x(SMP)S 184 x(con\211guration)S
-2 x(s)S 9455 Y 3899 X(\201)S 854 x(Redun)S -2 x(dant)S 182 x
(components)S 181 x(in)S 182 x(model)S 182 x(4xx)S 10651 Y 3899 X
(\201)S 854 x(Solid)S 182 x(state)S 182 x(power)S 182 x(front)S 183 x
(end)S
XP
% DefineFont:F28 Category:10 PointSize:12
/F28 600.0 /Helvetica-Bold@DOCPSE DPSF
RP
3899 12145 XY F28(Fault)S 200 x(A)S -22 x(voidanc)S 2 x
(e\202Utility)S 200 x(Port)S 198 x(Conditione)S 2 x(r)S 199 x(\(UPC)S
-2 x(\))S 13889 Y 3899 X F30(\201)S 854 x(Clean)S -2 x(s)S 183 x(up)S
182 x("dirty")S 182 x(AC)S 182 x(power)S 15084 Y 3899 X(\201)S 854 x
(Extended)S 182 x(ride-through)S 181 x(\(100)S 182 x(ms\))S 16280 Y
3899 X(\201)S 854 x(Harmonic)S 182 x(\211ltering)S 17475 Y 3899 X
(\201)S 854 x(Power)S 182 x(factor)S 184 x(correction)S 18671 Y
3899 X(\201)S 854 x(Built-in)S 182 x(redundan)S -2 x(cy)S 37373 Y
20908 X F36(V)S -36 x(AX)S 166 x(9000)S 165 x(Hardware)S 498 x
(2\20310)S
PP
EP
%%DOC$Page: 2-11 18
1000 BP 39600 30600 PM 0 0 XY
2106 Y 3899 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4247 Y 3899 X F20(Instruc)S -2 x(tor)S 298 x
(Notes)S 5443 Y 3899 X 23316 96 R 35879 Y 3899 X 23316 96 R 37373 Y
3899 X F36(2\2031)S -28 x(1.a)S 499 x(V)S -37 x(AX)S 166 x(9000)S
166 x(Hardware)S
PP
EP
%%DOC$Page: 2-11 19
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4032 Y 3899 X F28(Error)S 198 x(Detection)S
200 x(and)S 200 x(Analysi)S 2 x(s)S 5775 Y 3899 X F30(\201)S 854 x
(Achieved)S 181 x(through)S 182 x(service)S 182 x(processor)S -31 x
(.)S 6971 Y 4945 X(\202)S 498 x(Dedica)S -2 x(ted)S 183 x(MicroV)S
-40 x(AX)S 183 x(based)S 181 x(system)S 8166 Y 4945 X(\202)S 498 x
(Embedded)S 182 x(in)S 181 x(the)S 183 x(V)S -40 x(AX)S 183 x(9000)S
182 x(system)S 9362 Y 4945 X(\202)S 498 x(V)S -9 x(isibi)S -2 x
(lity)S 154 x(to)S 155 x(18,000)S 153 x(points)S 154 x(in)S 154 x
(each)S 153 x(CPU)S 154 x(and)S 154 x(6000)S 153 x(points)S 154 x
(in)S 154 x(the)S 154 x(system)S 155 x(control)S 154 x(unit)S 154 x
(\(SCU\))S 10557 Y 4945 X(\202)S 498 x(Recogn)S -2 x(izes)S 182 x
(90%)S 182 x(of)S 183 x(potentia)S -2 x(l)S 183 x(errors)S 11753 Y
4945 X(\202)S 498 x(Recovers)S 182 x(from)S 183 x(80%)S 182 x(of)S
183 x(intermittent)S 183 x(and)S 181 x(soft)S 183 x(errors)S 12948 Y
3899 X(\201)S 854 x(Service)S 182 x(processor)S 183 x(also)S 181 x
(monitors:)S 14144 Y 4945 X(\202)S 498 x(Power)S 183 x(leve)S -2 x
(ls)S 15339 Y 4945 X(\202)S 498 x(T)S -61 x(emperature)S 16535 Y
4945 X(\202)S 498 x(Air\212ow)S 17730 Y 4945 X(\202)S 498 x(Condi)S
-2 x(tion)S 182 x(of)S 183 x(the)S 182 x(I/O)S 184 x(buses)S 181 x
(\(includin)S -2 x(g)S 183 x(V)S -40 x(AXBI)S 184 x(bus\))S 18926 Y
4945 X(\202)S 498 x(Condi)S -2 x(tion)S 182 x(of)S 183 x(the)S 182 x
(UPC)S 20121 Y 3899 X(\201)S 854 x(Error)S 184 x(correction)S 182 x
(code)S 182 x(\(ECC\))S 183 x(performed)S 183 x(on)S 182 x(cache)S
181 x(and)S 182 x(memory)S -40 x(.)S 648 y 4945 X(\(All)S 183 x
(data)S 182 x(paths)S 182 x(are)S 182 x(parity)S 183 x(protected.\))S
37373 Y 20936 X F36(V)S -37 x(AX)S 166 x(9000)S 166 x(Hardware)S
497 x(2\2031)S -28 x(1)S
PP
EP
%%DOC$Page: 2-12 20
1000 BP 39600 30600 PM 0 0 XY
2106 Y 3899 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4247 Y 3899 X F20(Instruc)S -2 x(tor)S 298 x
(Notes)S 5443 Y 3899 X 23316 96 R 35879 Y 3899 X 23316 96 R 37373 Y
3899 X F36(2\20312.a)S 498 x(V)S -36 x(AX)S 166 x(9000)S 166 x
(Hardware)S
PP
EP
%%DOC$Page: 2-12 21
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4032 Y 3899 X F28(T)S -44 x(wo)S 199 x
(Methods)S 201 x(of)S 200 x(Err)S -2 x(or)S 199 x(Detectio)S 2 x(n)S
199 x(And)S 199 x(Analysi)S 2 x(s)S
XP
% DefineFont:F32 Category:10 PointSize:11
/F32 550.0 /Helvetica-Bold@DOCPSE DPSF
RP
3899 6423 XY F32(System)S 183 x(Directed)S 182 x(Diagnos)S -2 x
(tics)S 183 x(\(SDD\))S 7618 Y 3899 X F30(\201)S 854 x(Software)S
183 x(running)S 181 x(in)S 182 x(the)S 182 x(service)S 182 x
(processor)S 8814 Y 3899 X(\201)S 854 x(Analyzes)S 182 x(soft)S 183 x
(and)S 181 x(hard)S 182 x(error)S 184 x(information)S 181 x(to)S
183 x(predict)S 182 x(failing)S 181 x(componen)S -2 x(ts)S 10009 Y
3899 X(\201)S 854 x(Identi\211es)S 149 x(up)S 150 x(to)S 151 x(95%)S
149 x(of)S 151 x(all)S 149 x(processor)S 150 x(errors)S 151 x(and)S
150 x(automatical)S -2 x(ly)S 151 x(maps)S 150 x(them)S 150 x(to)S
151 x(\211eld)S 149 x(replacea)S -2 x(ble)S 648 y 4945 X(units)S
182 x(\(FRUs\))S 12052 Y 3899 X F32(T)S -41 x(est)S 183 x(Directed)S
182 x(Diagnos)S -2 x(tics)S 183 x(\(TDD\))S 13247 Y 3899 X F30(\201)S
854 x(T)S -30 x(ypical)S 181 x(standal)S -2 x(one)S 182 x(diagn)S
-2 x(ostics)S 14443 Y 3899 X(\201)S 854 x(Identi\211es)S 181 x(99%)S
183 x(of)S 182 x(processor)S 182 x(errors)S 15937 Y 3899 X F28
(Error)S 198 x(Detection)S 200 x(and)S 200 x(Analysi)S 2 x(s)S 199 x
(Support)S 17680 Y 3899 X F30(\201)S 854 x(System)S 260 x(can)S 258 x
(be)S 258 x(programmed)S 259 x(through)S 258 x(V)S -40 x(AXsimPLUS)S
260 x(software)S 258 x(to)S 259 x(automatically)S 257 x(dial)S 258 x
(out)S 258 x(to)S 648 y 4945 X(Digital)S 181 x(service)S 182 x
(centers)S 182 x(to)S 183 x(report)S 183 x(intermittent)S 182 x(or)S
183 x(hard)S 182 x(errors.)S 19523 Y 3899 X(\201)S 854 x(V)S -40 x
(AX)S 276 x(9000)S 275 x(system)S 276 x(also)S 274 x(supports)S 275 x
(full)S 275 x(remote)S 276 x(diag)S -2 x(nostic)S 275 x(capabi)S
-2 x(lities)S 275 x(from)S 276 x(remote)S 276 x(service)S 648 y
4945 X(centers.)S 37373 Y 20908 X F36(V)S -36 x(AX)S 166 x(9000)S
165 x(Hardware)S 498 x(2\20312)S
PP
EP
%%DOC$Page: 2-13 22
1000 BP 39600 30600 PM 0 0 XY
2106 Y 3899 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4247 Y 3899 X F20(Instruc)S -2 x(tor)S 298 x
(Notes)S 5443 Y 3899 X 23316 96 R 35879 Y 3899 X 23316 96 R 37373 Y
3899 X F36(2\20313.a)S 498 x(V)S -36 x(AX)S 166 x(9000)S 166 x
(Hardware)S
PP
EP
%%DOC$Page: 2-13 23
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4125 Y 3899 X F24(Serviceability)S 5869 Y
3899 X F30(\201)S 854 x(V)S -40 x(AX)S 183 x(9000)S 182 x(system)S
183 x(is)S 182 x(design)S -2 x(ed)S 182 x(for)S 183 x(quick)S 182 x
(repair)S 182 x(and)S 182 x(minimum)S 182 x(disruption.)S 7064 Y
4945 X(\202)S 498 x(Consol)S -2 x(e)S 183 x(compone)S -2 x(nts)S
183 x(can)S 182 x(be)S 182 x(swapp)S -2 x(ed)S 182 x(during)S 182 x
(operatio)S -2 x(n.)S 8260 Y 4945 X(\202)S 498 x(MCU)S 182 x(unit)S
182 x(is)S 183 x(a)S 182 x(\211eld)S 181 x(replaceab)S -2 x(le)S
182 x(unit)S 182 x(\(FRU\).)S 9455 Y 4945 X(\202)S 498 x(Three)S
203 x(and)S 203 x(four)S 204 x(CPU)S 204 x(con\211gu)S -2 x(rations)S
204 x(of)S 204 x(the)S 203 x(Models)S 203 x(430)S 203 x(and)S 203 x
(440)S 203 x(are)S 204 x(segmented)S 203 x(in)S 203 x(two)S 648 y
5991 X(separate)S 182 x(powe)S -2 x(r)S 183 x(systems)S 183 x(to)S
183 x(allow)S 181 x(concurrent)S 182 x(repair)S 182 x(and)S 182 x
(operation)S -2 x(.)S 11647 Y 3899 X F24(Air)S 232 x(Cooled)S 13390 Y
3899 X F30(\201)S 854 x(MCU)S 182 x(unit)S 182 x(coolin)S -2 x(g)S
183 x(pins)S 181 x(dissipate)S 181 x(heat.)S 14586 Y 3899 X(\201)S
854 x(Removes)S 182 x(possi)S -2 x(bility)S 182 x(of)S 183 x(water)S
182 x(damage)S 181 x(to)S 183 x(componen)S -2 x(ts)S 183 x(and)S
182 x(data)S 182 x(center)S -30 x(.)S 15781 Y 3899 X(\201)S 854 x
(Uses)S 182 x(less)S 182 x(energy)S 181 x(and)S 182 x(costs)S 183 x
(less)S 182 x(than)S 181 x(water)S 183 x(cooli)S -2 x(ng.)S 16977 Y
3899 X(\201)S 854 x(Uses)S 182 x(half)S 182 x(the)S 182 x(\212oor)S
182 x(space)S 182 x(of)S 183 x(the)S 182 x(water-cooled)S 181 x
(IBM\206)S 184 x(3090)S 181 x(system.)S 35356 Y 3899 X 6996 24 R
XP
% DefineFont:F42 Category:10 PointSize:8
/F42 400.0 /Helvetica@DOCPSE DPSF
RP
4004 35879 XY F42(\206)S 199 x(IBM)S 132 x(is)S 134 x(a)S 132 x
(registere)S -2 x(d)S 133 x(trad)S -2 x(emark)S 132 x(of)S 132 x
(Intern)S -2 x(ational)S 132 x(Business)S 133 x(Machines)S 132 x
(Corp)S -2 x(oration)S -2 x(.)S 37558 Y 20908 X F36(V)S -36 x(AX)S
166 x(9000)S 165 x(Hardware)S 498 x(2\20313)S
PP
EP
%%DOC$Page: 2-14 24
1000 BP 39600 30600 PM 0 0 XY
2106 Y 3899 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4247 Y 3899 X F20(Instruc)S -2 x(tor)S 298 x
(Notes)S 5443 Y 3899 X 23316 96 R 35879 Y 3899 X 23316 96 R 37373 Y
3899 X F36(2\20314.a)S 498 x(V)S -36 x(AX)S 166 x(9000)S 166 x
(Hardware)S
PP
EP
%%DOC$Page: 2-14 25
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4275 Y 3899 X F20(I/O)S 299 x(SUBSYSTEMS)S
4082 5421 XY
4082 28733 SPB
% Begin Plot (io_subsystems.eps)
%!PS-Adobe-2.0 EPSF 1.2
%%File: WORK2:[HUBBARD.SALES]IO_SUBSYSTEMS.EPS
%%Creator: PSART, PostScript ART V1.1
%%Copyright 1987,1988,1989 DIGITAL EQUIPMENT CORPORATION. All Rights Reserved.
%%CreationDate: Fri Nov 17 15:14:57 1989
%%This file to be included in a DOCUMENT-produced file
%%
%%DOCUMENT <FIGURE_FILE> reservation = 40 picas.
%%
%%BoundingBox: 76 0 392 472
%%DocumentFonts: PSART-Helvetica
%%This file processed with the following qualifiers:
%%
%% /All_directions
%% /Centered = 6.5
%% /Comment_delimiter = !
%% /NoControl
%% /Encapsulated
%% /NoIges
%% /ISO (ISOLatin1 Character Encoding)
%% /Output = WORK2:[HUBBARD.SALES]IO_SUBSYSTEMS.EPS
%% /NoPicmode
%% /Rotate = 0.00 degrees
%% /Size = 8
%% /Text_adjust = 4
%% /Thick = 1.44 points
%% /Thin = 0.86 points
%% /Type = HELV
%% /Xoffset = 0.00 inches
%% /Xscale = 1.00
%% /Yoffset = 0.00 inches
%% /Yscale = 1.00
%%
%% Analyzed character strings have maximum average width
%% of 4.41 points and a maximum average height of 6.04
%% points, with 3.02 points of leading between lines.
%%
%%EndComments
/reencode { findfont begin currentdict dup length dict begin { 1 index
/FID ne {def} {pop pop} ifelse } forall /FontName exch def dup length
0 ne { /Encoding Encoding 256 array copy def 0 exch { dup type
/nametype eq { Encoding 2 index 2 index put pop 1 add }{ exch pop }
ifelse } forall } if pop currentdict dup end end /FontName get exch
definefont pop } bind def mark /ISOLatin1 8#000 1 8#054
{StandardEncoding exch get} for /minus 8#056 1 8#217 {StandardEncoding
exch get} for /dotlessi 8#301 1 8#317 {StandardEncoding exch get} for
/space /exclamdown /cent /sterling /currency /yen /brokenbar /section
/dieresis /copyright /ordfeminine /guillemotleft /logicalnot /hyphen
/registered /macron /degree /plusminus /twosuperior /threesuperior
/acute /mu /paragraph /periodcentered /cedilla /onesuperior
/ordmasculine /guillemotright /onequarter /onehalf /threequarters
/questiondown /Agrave /Aacute /Acircumflex /Atilde /Adieresis /Aring
/AE /Ccedilla /Egrave /Eacute /Ecircumflex /Edieresis /Igrave /Iacute
/Icircumflex /Idieresis /Eth /Ntilde /Ograve /Oacute /Ocircumflex
/Otilde /Odieresis /multiply /Oslash /Ugrave /Uacute /Ucircumflex
/Udieresis /Yacute /Thorn /germandbls /agrave /aacute /acircumflex
/atilde /adieresis /aring /ae /ccedilla /egrave /eacute /ecircumflex
/edieresis /igrave /iacute /icircumflex /idieresis /eth /ntilde
/ograve /oacute /ocircumflex /otilde /odieresis /divide /oslash
/ugrave /uacute /ucircumflex /udieresis /yacute /thorn /ydieresis
/ISOLatin1 where not {256 array astore def} if cleartomark /DECMCS
ISOLatin1 256 array copy def mark 8#240 8#244 8#246 8#254 8#255 8#256
8#257 8#264 8#270 8#276 8#320 8#336 8#360 8#376 8#377 counttomark
{DECMCS exch /.notdef put} repeat 8#250 /currency 8#327 /OE 8#335
/Ydieresis 8#367 /oe 8#375 /ydieresis counttomark -1 bitshift {DECMCS
3 1 roll put} repeat cleartomark
%
%%Page
[1.00 0.00 0.00 1.00 77.40 0.00] concat
/psarrow
{
newpath -8.00 0.0 moveto 0.0 0.30 rlineto
-0.10 0.60 rlineto
-0.20 0.60 rlineto
-0.30 0.40 rlineto
-0.40 0.30 rlineto
9.00 -2.20 rlineto
-9.00 -2.20 rlineto
0.40 0.30 rlineto
0.30 0.40 rlineto
0.20 0.60 rlineto
0.10 0.60 rlineto
0.0 0.30 rlineto
closepath fill
} bind def
1 setlinecap 1 setlinejoin
ISOLatin1 /PSART-Helvetica /Helvetica reencode
/PSART-Helvetica findfont 8.00 scalefont setfont
112.48 459.04 moveto 0.40 0.00 (Memory) ashow
112.48 449.98 moveto 0.40 0.00 (256 MB) ashow
112.48 440.92 moveto 0.40 0.00 (to 1 GB) ashow
174.24 459.04 moveto 0.40 0.00 (Memory) ashow
174.24 449.98 moveto 0.40 0.00 (256 MB) ashow
174.24 440.92 moveto 0.40 0.00 (to 1 GB) ashow
129.68 422.80 moveto 0.40 0.00 (1 GB) ashow
129.68 413.74 moveto 0.40 0.00 (sec) ashow
191.43 422.80 moveto 0.40 0.00 (1 GB) ashow
191.43 413.74 moveto 0.40 0.00 (sec) ashow
8.46 377.50 moveto 0.40 0.00 (Service Processor) ashow
125.98 377.50 moveto 0.40 0.00 (System Control) ashow
125.98 232.54 moveto 0.40 0.00 (paths at 500MB) ashow
125.98 223.48 moveto 0.40 0.00 (per sec. each) ashow
148.89 368.44 moveto 0.40 0.00 (Unit) ashow
139.86 350.32 moveto 0.40 0.00 (crossbar) ashow
76.99 341.26 moveto 0.40 0.00 (1 GB sec) ashow
138.75 341.26 moveto 0.40 0.00 (switch) ashow
138.75 323.14 moveto 0.40 0.00 (2 GB sec) ashow
200.50 341.26 moveto 0.40 0.00 (1 GB sec) ashow
282.97 341.26 moveto 0.40 0.00 (CPU 3) ashow
40.57 332.20 moveto 0.40 0.00 (Cache) ashow
247.90 332.20 moveto 0.40 0.00 (Cache) ashow
187.02 196.30 moveto 0.40 0.00 (1 GB) ashow
187.02 187.24 moveto 0.40 0.00 (sec) ashow
102.17 160.06 moveto 0.40 0.00 (I/O Control) ashow
68.59 123.82 moveto 0.40 0.00 (XMI 1) ashow
227.40 123.82 moveto 0.40 0.00 (XMI 4) ashow
54.94 114.76 moveto 0.40 0.00 (80 MB sec) ashow
222.56 114.76 moveto 0.40 0.00 (80 MB sec) ashow
27.26 60.40 moveto 0.40 0.00 (up to 12 I/O interfaces) ashow
221.36 60.40 moveto 0.40 0.00 (up to 12 I/O interfaces) ashow
51.41 51.34 moveto 0.40 0.00 (per XMI) ashow
245.50 51.34 moveto 0.40 0.00 (per XMI) ashow
108.30 33.22 moveto 0.40 0.00 (XMI 2) ashow
94.64 24.16 moveto 0.40 0.00 (80 MB sec) ashow
182.86 24.16 moveto 0.40 0.00 (80 MB sec) ashow
177.16 160.06 moveto 0.40 0.00 (I/O Control) ashow
133.50 241.60 moveto 0.40 0.00 (4 read/write) ashow
5.06 341.26 moveto 0.40 0.00 (CPU 1) ashow
146.88 196.30 moveto 0.40 0.00 (1 GB) ashow
146.88 187.24 moveto 0.40 0.00 (sec) ashow
76.99 277.84 moveto 0.40 0.00 (1 GB sec) ashow
200.50 277.84 moveto 0.40 0.00 (1 GB sec) ashow
283.66 323.14 moveto 0.40 0.00 (vector) ashow
283.66 314.08 moveto 0.40 0.00 (proc.) ashow
40.57 268.78 moveto 0.40 0.00 (Cache) ashow
247.90 268.78 moveto 0.40 0.00 (Cache) ashow
187.70 33.22 moveto 0.40 0.00 (XMI 3) ashow
5.75 323.14 moveto 0.40 0.00 (vector) ashow
5.75 314.08 moveto 0.40 0.00 (proc.) ashow
282.97 277.84 moveto 0.40 0.00 (CPU 4) ashow
5.06 277.84 moveto 0.40 0.00 (CPU 2) ashow
283.66 259.72 moveto 0.40 0.00 (vector) ashow
283.66 250.66 moveto 0.40 0.00 (proc.) ashow
5.75 259.72 moveto 0.40 0.00 (vector) ashow
5.75 250.66 moveto 0.40 0.00 (proc.) ashow
gsave
123.51 434.88 translate 90.00 rotate psarrow
grestore
newpath 123.51 395.58 moveto 123.51 428.88 lineto 0.864 setlinewidth stroke
gsave
185.27 434.88 translate 90.00 rotate psarrow
grestore
newpath 185.27 395.58 moveto 185.27 428.88 lineto 0.864 setlinewidth stroke
gsave
123.51 389.58 translate 270.00 rotate psarrow
grestore
gsave
185.27 389.58 translate 270.00 rotate psarrow
grestore
gsave
88.22 380.52 translate 180.00 rotate psarrow
grestore
newpath 113.10 380.52 moveto 94.23 380.52 lineto 0.864 setlinewidth stroke
gsave
119.10 380.52 translate 0.00 rotate psarrow
grestore
gsave
70.58 335.22 translate 180.00 rotate psarrow
grestore
newpath 113.10 335.22 moveto 76.58 335.22 lineto 0.864 setlinewidth stroke
gsave
119.10 335.22 translate 0.00 rotate psarrow
grestore
gsave
194.09 335.22 translate 180.00 rotate psarrow
grestore
newpath 236.61 335.22 moveto 200.10 335.22 lineto 0.864 setlinewidth stroke
gsave
242.62 335.22 translate 0.00 rotate psarrow
grestore
gsave
70.58 271.80 translate 180.00 rotate psarrow
grestore
newpath 113.10 271.80 moveto 76.58 271.80 lineto 0.864 setlinewidth stroke
gsave
119.10 271.80 translate 0.00 rotate psarrow
grestore
gsave
194.09 271.80 translate 180.00 rotate psarrow
grestore
newpath 236.61 271.80 moveto 200.10 271.80 lineto 0.864 setlinewidth stroke
gsave
242.62 271.80 translate 0.00 rotate psarrow
grestore
gsave
132.34 217.44 translate 90.00 rotate psarrow
grestore
newpath 132.34 178.14 moveto 132.34 211.44 lineto 0.864 setlinewidth stroke
gsave
180.86 217.44 translate 90.00 rotate psarrow
grestore
newpath 180.86 178.14 moveto 180.86 211.44 lineto 0.864 setlinewidth stroke
gsave
132.34 172.14 translate 270.00 rotate psarrow
grestore
gsave
180.86 172.14 translate 270.00 rotate psarrow
grestore
gsave
17.64 99.66 translate 180.00 rotate psarrow
grestore
newpath 30.88 99.66 moveto 23.65 99.66 lineto 1.440 setlinewidth stroke
gsave
299.96 99.66 translate 0.00 rotate psarrow
grestore
newpath 286.73 99.66 moveto 293.96 99.66 lineto 1.440 setlinewidth stroke
gsave
30.88 72.48 translate 270.00 rotate psarrow
grestore
newpath 30.88 99.66 moveto 30.88 78.48 lineto 1.440 setlinewidth stroke
gsave
39.70 72.48 translate 270.00 rotate psarrow
grestore
newpath 39.70 99.66 moveto 39.70 78.48 lineto 1.440 setlinewidth stroke
gsave
48.52 72.48 translate 270.00 rotate psarrow
grestore
newpath 48.52 99.66 moveto 48.52 78.48 lineto 1.440 setlinewidth stroke
gsave
57.35 72.48 translate 270.00 rotate psarrow
grestore
newpath 57.35 99.66 moveto 57.35 78.48 lineto 1.440 setlinewidth stroke
gsave
66.17 72.48 translate 270.00 rotate psarrow
grestore
newpath 66.17 99.66 moveto 66.17 78.48 lineto 1.440 setlinewidth stroke
gsave
74.99 72.48 translate 270.00 rotate psarrow
grestore
newpath 74.99 99.66 moveto 74.99 78.48 lineto 1.440 setlinewidth stroke
gsave
83.81 72.48 translate 270.00 rotate psarrow
grestore
newpath 83.81 99.66 moveto 83.81 78.48 lineto 1.440 setlinewidth stroke
gsave
92.64 72.48 translate 270.00 rotate psarrow
grestore
newpath 92.64 99.66 moveto 92.64 78.48 lineto 1.440 setlinewidth stroke
gsave
224.97 72.48 translate 270.00 rotate psarrow
grestore
newpath 224.97 99.66 moveto 224.97 78.48 lineto 1.440 setlinewidth stroke
gsave
233.79 72.48 translate 270.00 rotate psarrow
grestore
newpath 233.79 99.66 moveto 233.79 78.48 lineto 1.440 setlinewidth stroke
gsave
242.62 72.48 translate 270.00 rotate psarrow
grestore
newpath 242.62 99.66 moveto 242.62 78.48 lineto 1.440 setlinewidth stroke
gsave
251.44 72.48 translate 270.00 rotate psarrow
grestore
newpath 251.44 99.66 moveto 251.44 78.48 lineto 1.440 setlinewidth stroke
gsave
260.26 72.48 translate 270.00 rotate psarrow
grestore
newpath 260.26 99.66 moveto 260.26 78.48 lineto 1.440 setlinewidth stroke
gsave
269.08 72.48 translate 270.00 rotate psarrow
grestore
newpath 269.08 99.66 moveto 269.08 78.48 lineto 1.440 setlinewidth stroke
gsave
277.91 72.48 translate 270.00 rotate psarrow
grestore
newpath 277.91 99.66 moveto 277.91 78.48 lineto 1.440 setlinewidth stroke
gsave
286.73 72.48 translate 270.00 rotate psarrow
grestore
newpath 286.73 99.66 moveto 286.73 78.48 lineto 1.440 setlinewidth stroke
gsave
141.16 0.00 translate 270.00 rotate psarrow
grestore
newpath 141.16 144.96 moveto 141.16 6.00 lineto 1.440 setlinewidth stroke
gsave
176.45 0.00 translate 270.00 rotate psarrow
grestore
newpath 176.45 144.96 moveto 176.45 6.00 lineto 1.440 setlinewidth stroke
newpath 105.87 471.12 moveto 44.11 0.00 rlineto 1.440 setlinewidth stroke
newpath 105.87 471.12 moveto 0.00 -36.24 rlineto 1.440 setlinewidth stroke
newpath 149.98 471.12 moveto 0.00 -36.24 rlineto 1.440 setlinewidth stroke
newpath 167.63 471.12 moveto 44.11 0.00 rlineto 1.440 setlinewidth stroke
newpath 167.63 471.12 moveto 0.00 -36.24 rlineto 1.440 setlinewidth stroke
newpath 211.74 471.12 moveto 0.00 -36.24 rlineto 1.440 setlinewidth stroke
newpath 105.87 434.88 moveto 44.11 0.00 rlineto 1.440 setlinewidth stroke
newpath 167.63 434.88 moveto 44.11 0.00 rlineto 1.440 setlinewidth stroke
newpath 0.00 389.58 moveto 88.22 0.00 rlineto 1.440 setlinewidth stroke
newpath 0.00 389.58 moveto 0.00 -18.12 rlineto 1.440 setlinewidth stroke
newpath 88.22 389.58 moveto 0.00 -18.12 rlineto 1.440 setlinewidth stroke
newpath 119.10 389.58 moveto 74.99 0.00 rlineto 1.440 setlinewidth stroke
newpath 119.10 389.58 moveto 0.00 -172.14 rlineto 1.440 setlinewidth stroke
newpath 194.09 389.58 moveto 0.00 -172.14 rlineto 1.440 setlinewidth stroke
newpath 0.00 371.46 moveto 88.22 0.00 rlineto 1.440 setlinewidth stroke
newpath 0.00 353.34 moveto 70.58 0.00 rlineto 1.440 setlinewidth stroke
newpath 0.00 353.34 moveto 0.00 -45.30 rlineto 1.440 setlinewidth stroke
newpath 35.29 353.34 moveto 0.00 -45.30 rlineto 1.440 setlinewidth stroke
newpath 70.58 353.34 moveto 0.00 -45.30 rlineto 1.440 setlinewidth stroke
newpath 242.62 353.34 moveto 70.58 0.00 rlineto 1.440 setlinewidth stroke
newpath 242.62 353.34 moveto 0.00 -45.30 rlineto 1.440 setlinewidth stroke
newpath 277.91 353.34 moveto 0.00 -45.30 rlineto 1.440 setlinewidth stroke
newpath 313.20 353.34 moveto 0.00 -45.30 rlineto 1.440 setlinewidth stroke
newpath 0.00 335.22 moveto 35.29 0.00 rlineto 1.440 setlinewidth stroke
newpath 277.91 335.22 moveto 35.29 0.00 rlineto 1.440 setlinewidth stroke
newpath 0.00 308.04 moveto 70.58 0.00 rlineto 1.440 setlinewidth stroke
newpath 242.62 308.04 moveto 70.58 0.00 rlineto 1.440 setlinewidth stroke
newpath 0.00 289.92 moveto 70.58 0.00 rlineto 1.440 setlinewidth stroke
newpath 0.00 289.92 moveto 0.00 -45.30 rlineto 1.440 setlinewidth stroke
newpath 35.29 289.92 moveto 0.00 -45.30 rlineto 1.440 setlinewidth stroke
newpath 70.58 289.92 moveto 0.00 -45.30 rlineto 1.440 setlinewidth stroke
newpath 242.62 289.92 moveto 70.58 0.00 rlineto 1.440 setlinewidth stroke
newpath 242.62 289.92 moveto 0.00 -45.30 rlineto 1.440 setlinewidth stroke
newpath 277.91 289.92 moveto 0.00 -45.30 rlineto 1.440 setlinewidth stroke
newpath 313.20 289.92 moveto 0.00 -45.30 rlineto 1.440 setlinewidth stroke
newpath 0.00 271.80 moveto 35.29 0.00 rlineto 1.440 setlinewidth stroke
newpath 277.91 271.80 moveto 35.29 0.00 rlineto 1.440 setlinewidth stroke
newpath 0.00 244.62 moveto 70.58 0.00 rlineto 1.440 setlinewidth stroke
newpath 242.62 244.62 moveto 70.58 0.00 rlineto 1.440 setlinewidth stroke
newpath 119.10 217.44 moveto 74.99 0.00 rlineto 1.440 setlinewidth stroke
newpath 92.64 172.14 moveto 61.76 0.00 rlineto 1.440 setlinewidth stroke
newpath 92.64 172.14 moveto 0.00 -27.18 rlineto 1.440 setlinewidth stroke
newpath 154.39 172.14 moveto 0.00 -27.18 rlineto 1.440 setlinewidth stroke
newpath 167.63 172.14 moveto 61.76 0.00 rlineto 1.440 setlinewidth stroke
newpath 167.63 172.14 moveto 0.00 -27.18 rlineto 1.440 setlinewidth stroke
newpath 229.38 172.14 moveto 0.00 -27.18 rlineto 1.440 setlinewidth stroke
newpath 92.64 144.96 moveto 61.76 0.00 rlineto 1.440 setlinewidth stroke
newpath 101.46 144.96 moveto 0.00 -45.30 rlineto 1.440 setlinewidth stroke
newpath 167.63 144.96 moveto 61.76 0.00 rlineto 1.440 setlinewidth stroke
newpath 216.15 144.96 moveto 0.00 -45.30 rlineto 1.440 setlinewidth stroke
newpath 30.88 99.66 moveto 70.58 0.00 rlineto 1.440 setlinewidth stroke
newpath 216.15 99.66 moveto 70.58 0.00 rlineto 1.440 setlinewidth stroke
showpage
%%Trailer
% End Plot
SPE
XP
% DefineFont:F36 Category:10 PointSize:10
/Helvetica-Bold /Helvetica-Bold@DOCPSE DOCPSE ReENCODE
/F36 500.0 /Helvetica-Bold@DOCPSE DPSF
RP
20908 37373 XY F36(V)S -36 x(AX)S 166 x(9000)S 165 x(Hardware)S 498 x
(2)S
(\20314)S
PP
EP
%%DOC$Page: 2-15 26
1000 BP 39600 30600 PM 0 0 XY
2106 Y 3899 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S
XP
% DefineFont:F20 Category:10 PointSize:18
/F20 900.0 /Helvetica-Bold@DOCPSE DPSF
RP
3899 4247 XY F20(Instruc)S -2 x(tor)S 298 x(Notes)S 5443 Y 3899 X
23316 96 R 35879 Y 3899 X 23316 96 R 37373 Y 3899 X F36(2\20315.a)S
498 x(V)S -36 x(AX)S 166 x(9000)S 166 x(Hardware)S
PP
EP
%%DOC$Page: 2-15 27
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S
XP
% DefineFont:F24 Category:10 PointSize:14
/F24 700.0 /Helvetica-Bold@DOCPSE DPSF
RP
3899 4104 XY F24(Four)S 233 x(New)S 231 x(Adapters)S
XP
% DefineFont:F30 Category:10 PointSize:11
/Helvetica /Helvetica@DOCPSE DOCPSE ReENCODE
/F30 550.0 /Helvetica@DOCPSE DPSF
RP
3899 5847 XY F30(\201)S 854 x(KDM70)S 182 x(local)S 182 x(disk)S
182 x(and)S 181 x(tape)S 182 x(controller)S 7042 Y 3899 X(\201)S
854 x(CIXCD)S 182 x(CI)S 183 x(adap)S -2 x(ter)S 8238 Y 3899 X(\201)S
854 x(DEC)S 182 x(LANcontroller)S 182 x(400)S 181 x(\(DEMNA)S 2 x
(\))S 183 x(Ethernet)S 183 x(adap)S -2 x(ter)S 9434 Y 3899 X(\201)S
854 x(V)S -40 x(AXBI)S 184 x(adapter)S 182 x(for)S 183 x(BI)S 184 x
(expan)S -2 x(sion)S
XP
% DefineFont:F28 Category:10 PointSize:12
/F28 600.0 /Helvetica-Bold@DOCPSE DPSF
RP
3899 10928 XY F28(KDM70)S 199 x(Local)S 201 x(Disk)S 199 x(and)S
200 x(T)S -44 x(ape)S 201 x(Controller)S 12671 Y 3899 X F30(\201)S
854 x(New)S 181 x(XMI)S 184 x(controller)S 182 x(for)S 183 x(the)S
183 x(follow)S -2 x(ing:)S 13867 Y 4945 X(\202)S 498 x(RA)S 183 x
(disks)S 182 x(\(Low-cost)S 182 x(disk)S 182 x(connectio)S -2 x(n)S
182 x(with)S 182 x(up)S 182 x(to)S 183 x(9.7)S 182 x(Gbytes)S 183 x
(of)S 182 x(on-line)S 181 x(storage)S 183 x(capa)S -2 x(city\))S
15062 Y 4945 X(\202)S 498 x(T)S -41 x(A)S 189 x(tape)S 188 x(drives)S
188 x(\(One)S 188 x(T)S -40 x(A90)S 188 x(formatter)S 190 x(with)S
187 x(slaves)S 188 x(has)S 187 x(2.4)S 189 x(Gbytes)S 188 x
(unattende)S -2 x(d)S 188 x(backup)S 187 x(or)S 648 y 5991 X(data)S
182 x(collectio)S -2 x(n.\))S 16906 Y 4945 X(\202)S 498 x(ESE20)S
183 x(Solid)S 182 x(state)S 183 x(disks)S 182 x(\(120)S 182 x
(Mbytes)S 182 x(with)S 182 x(up)S 182 x(to)S 183 x(300)S 181 x(I/O)S
184 x(s/s\))S 18101 Y 3899 X(\201)S 854 x(High)S 329 x(performance)S
330 x(I/O)S 331 x(for)S 330 x(scienti\211c,)S 366 x(commercial,)S
367 x(\211nancial)S -2 x(,)S 368 x(and)S 329 x(transaction)S 329 x
(processing)S 648 y 4945 X(appli)S -2 x(cations)S 19944 Y 3899 X
(\201)S 854 x(Eight)S 182 x(device)S 182 x(ports)S 182 x(\(T)S -30 x
(wo)S 182 x(ports)S 183 x(may)S 183 x(be)S 182 x(used)S 181 x(for)S
183 x(tape)S 182 x(drives.\))S 21140 Y 3899 X(\201)S 854 x(T)S -30 x
(wo)S 182 x(I/O)S 183 x(data)S 182 x(channe)S -2 x(ls)S 22335 Y
3899 X(\201)S 854 x(Features)S 182 x(high)S 181 x(performance)S 182 x
(with:)S 23531 Y 4945 X(\202)S 498 x(Seven)S 182 x(hundred)S 181 x
(I/O)S 184 x(requests)S 182 x(per)S 182 x(second)S 24726 Y 4945 X
(\202)S 498 x(Sustained)S 181 x(data)S 182 x(rate)S 183 x(of)S 183 x
(3.4)S 182 x(Mbytes/s)S 183 x(to)S 183 x(RA90)S 182 x(disks)S 25922 Y
4945 X(\202)S 498 x(VMS)S 184 x(backup)S 181 x(of)S 183 x(3.6)S 182 x
(Mbytes/s)S 183 x(\(two)S 183 x(T)S -41 x(A90)S 183 x(and)S 181 x
(RA90\))S 37373 Y 20908 X F36(V)S -36 x(AX)S 166 x(9000)S 165 x
(Hardware)S 498 x(2\20315)S
PP
EP
%%DOC$Page: 2-16 28
1000 BP 39600 30600 PM 0 0 XY
2106 Y 3899 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4247 Y 3899 X F20(Instruc)S -2 x(tor)S 298 x
(Notes)S 5443 Y 3899 X 23316 96 R
XP
% DefineFont:F32 Category:10 PointSize:11
/F32 550.0 /Helvetica-Bold@DOCPSE DPSF
RP
3899 6638 XY F32(Reliability)S 7834 Y 3899 X F30(\201)S 854 x(MTBF)S
183 x(rated)S 183 x(>)S 182 x(180,000)S 181 x(hrs)S 183 x(\(20)S
182 x(yrs!\))S 9029 Y 3899 X(\201)S 854 x(Access)S 183 x(RBD)S 182 x
(from)S 184 x(CPU)S 182 x(consol)S -2 x(e)S 183 x(via)S 182 x(Z)S
182 x(command)S 35879 Y 3899 X 23316 96 R 37373 Y 3899 X F36
(2\20316.a)S 498 x(V)S -36 x(AX)S 166 x(9000)S 166 x(Hardware)S
PP
EP
%%DOC$Page: 2-16 29
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4050 Y 3899 X F28(CIXCD)S 198 x(CI)S 199 x
(Adapter)S 5794 Y 3899 X F30(\201)S 854 x(I/O)S 184 x(interface)S
182 x(conne)S -2 x(cting)S 182 x(to)S 183 x(computer)S 182 x
(interconnect)S 182 x(systems)S 6989 Y 3899 X(\201)S 854 x(Uses)S
362 x(a)S 362 x(new)S 362 x(method)S 362 x(of)S 363 x(computer)S
362 x(interconnect)S 362 x(communicatio)S -2 x(n)S 363 x(allo)S -2 x
(wing)S 362 x(simultane)S -2 x(ous)S 648 y 4945 X(communication)S
181 x(\(in)S 182 x(any)S 182 x(order\))S 183 x(over)S 183 x(both)S
182 x(paths)S 8832 Y 4945 X(\202)S 498 x(T)S -20 x(ransmit)S 182 x
(&)S 183 x(Receive)S 181 x(on)S 182 x(both)S 182 x(paths)S 182 x(at)S
183 x(same)S 182 x(time)S 10028 Y 4945 X(\202)S 498 x(Can)S 182 x
(reseque)S -2 x(nce)S 182 x(out)S 183 x(of)S 182 x(order)S 183 x
(packets)S 11223 Y 4945 X(\202)S 498 x(Dual)S 181 x(70)S 182 x
(Mb/sec)S 183 x(CI)S 182 x(interface:)S 12419 Y 7037 X(70Mb/sec)S
182 x(x)S 183 x(2)S 182 x(=)S 183 x(17.5MB/sec)S 13614 Y 3899 X
(\201)S 854 x(Provides)S 216 x(up)S 215 x(to)S 216 x(a)S 216 x
(fourfold)S 216 x(increase)S 214 x(in)S 216 x(I/O)S 217 x
(performance)S 216 x(over)S 215 x(current)S 217 x(computer)S 216 x
(interconn)S -2 x(ect)S 648 y 4945 X(interfaces)S 15457 Y 4945 X
(\202)S 498 x(32)S 182 x(bit)S 182 x(wide)S 181 x
(architecture/implementation)S 16653 Y 4945 X(\202)S 498 x(Dual)S
181 x(data)S 182 x(movers,)S 183 x(each)S 182 x(rated)S 182 x(at)S
183 x(20MB/sec)S 17848 Y 4945 X(\202)S 498 x(62.5MB/sec)S 183 x
(packet)S 182 x(buf)S -10 x(fer)S 19044 Y 3899 X(\201)S 854 x
(Compatibl)S -2 x(e)S 214 x(with)S 214 x(existing)S 213 x(V)S -40 x
(AXcluster)S 215 x(port)S 215 x(interfaces)S 214 x(and)S 213 x
(enhance)S -2 x(s)S 215 x(the)S 214 x(I/O)S 215 x(performance)S 214 x
(of)S 647 y 4945 X(existing)S 181 x(V)S -40 x(AXcluster)S 183 x
(systems)S 20887 Y 3899 X(\201)S 854 x(Design)S -2 x(ed)S 182 x(for)S
183 x(high)S 181 x(reliabili)S -2 x(ty)S 22082 Y 4945 X(\202)S 498 x
(All)S 182 x(data)S 182 x(paths)S 182 x(parity)S 183 x(protected)S
23278 Y 4945 X(\202)S 498 x(Microcode)S 182 x(stored)S 182 x
(on-board)S 182 x(in)S 182 x(EEPROM,)S 184 x(moved)S 182 x(to)S 183 x
(RAM)S 183 x(at)S 183 x(power)S 182 x(up)S 24474 Y 4945 X(\202)S
498 x(Power-up)S 182 x(self)S 183 x(test)S 25669 Y 4945 X(\202)S
498 x(ROM)S 302 x(Based)S 300 x(Diagno)S -2 x(stics)S 302 x
(\(RBD\),)S 302 x(accessibl)S -2 x(e)S 301 x(from)S 303 x(CPU)S 301 x
(conso)S -2 x(le,)S 331 x(will)S 300 x(check)S 301 x(module)S 648 y
5991 X(functions)S 27512 Y 3899 X(\201)S 854 x(Supports)S 182 x(CI)S
183 x(subnod)S -2 x(e)S 183 x(addressi)S -2 x(ng)S 28708 Y 3899 X
(\201)S 854 x(Is)S 183 x(compatible)S 181 x(with)S 182 x(current)S
183 x(V)S -40 x(AX)S 183 x(CI)S 183 x(ports)S 29903 Y 3899 X(\201)S
854 x(A)S -9 x(vail)S -2 x(able)S 182 x(on)S 182 x(all)S 181 x(9xxx)S
183 x(and)S 181 x(6xxx)S 182 x(systems)S 31099 Y 3899 X(\201)S 854 x
(Multiple)S 181 x(CIXCD)S 183 x(adap)S -2 x(ters)S 183 x(supported)S
182 x(on)S 182 x(V)S -40 x(AX)S 183 x(9000)S 181 x(systems)S 37373 Y
20908 X F36(V)S -36 x(AX)S 166 x(9000)S 165 x(Hardware)S 498 x
(2\20316)S
PP
EP
%%DOC$Page: 2-17 30
1000 BP 39600 30600 PM 0 0 XY
2106 Y 3899 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4247 Y 3899 X F20(Instruc)S -2 x(tor)S 298 x
(Notes)S 5443 Y 3899 X 23316 96 R 35879 Y 3899 X 23316 96 R 37373 Y
3899 X F36(2\20317.a)S 498 x(V)S -36 x(AX)S 166 x(9000)S 166 x
(Hardware)S
PP
EP
%%DOC$Page: 2-17 31
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4050 Y 3899 X F28(DEC)S 198 x(LANcontroller)S
200 x(400)S 200 x(\(DEMNA)S -2 x(\))S 5794 Y 3899 X F30(\201)S 854 x
(Network)S 182 x(interconne)S -2 x(ct)S 183 x(\(NI\))S 184 x(for)S
183 x(V)S -40 x(AX)S 183 x(9000)S 182 x(systems)S 6989 Y 3899 X
(\201)S 854 x(High-pe)S -2 x(rform)S 2 x(ance)S 181 x(XMI)S 184 x
(to)S 183 x(Ethernet)S 183 x(adap)S -2 x(ter)S 8185 Y 3899 X(\201)S
854 x(Includes)S 181 x(512)S 182 x(Kbytes)S 182 x(of)S 183 x(buf)S
-10 x(fering)S 182 x(for)S 183 x(commands)S 182 x(and)S 182 x(data)S
182 x(packets)S 9380 Y 3899 X(\201)S 854 x(Allows)S 301 x(systems)S
303 x(to)S 303 x(conne)S -2 x(ct)S 303 x(multiple)S 301 x(Ethernets)S
303 x(using)S 301 x(multiple)S 301 x(DEMNAs,)S 333 x(and)S 302 x(to)S
302 x(directly)S 648 y 4945 X(connect)S 305 x(XMI)S 306 x(systems)S
306 x(to)S 306 x(Local)S 304 x(Area)S 306 x(V)S -40 x(AXcluster)S
-30 x(,)S 337 x(Ethernet)S 306 x(V)S -30 x(ersion)S 305 x(2.0,)S
336 x(or)S 306 x(IEEE)S 307 x(802.3)S 647 y 4945 X(networks)S 182 x
(and)S 182 x(associ)S -2 x(ated)S 182 x(Digital)S 181 x(network)S
182 x(hardware)S 12170 Y 3899 X F28(V)S -45 x(AXBI)S 199 x(Bus)S
199 x(Interconne)S 2 x(ct)S 199 x(\(DWMBB\))S 13913 Y 3899 X F30
(\201)S 854 x(Provides)S 182 x(compatibil)S -2 x(ity)S 183 x(with)S
182 x(existing)S 181 x(systems)S 15109 Y 3899 X(\201)S 854 x(Allows)S
182 x(up)S 182 x(to)S 182 x(14)S 182 x(additio)S -2 x(nal)S 182 x
(BI)S 183 x(adapters)S 182 x(per)S 183 x(system)S 16304 Y 3899 X
(\201)S 854 x(The)S 182 x(BI)S 183 x(devices)S 181 x(and)S 182 x
(adapters)S 182 x(suppo)S -2 x(rted:)S 17500 Y 4945 X(\202)S 498 x
(DHB32)S 182 x(-)S 183 x(16)S 182 x(line)S 181 x(asynchrono)S -2 x
(us)S 18695 Y 4945 X(\202)S 498 x(DSB32)S 183 x(-)S 183 x(2)S 182 x
(line)S 181 x(synchronous)S 19891 Y 4945 X(\202)S 498 x(DRB32)S 182 x
(-)S 183 x(medium)S 182 x(speed)S 181 x(32-bit)S 182 x(parallel)S
181 x(adapter)S 21086 Y 4945 X(\202)S 498 x(DMB32)S 183 x(-)S 183 x
(8)S 182 x(line)S 181 x(asynchronou)S -2 x(s)S 183 x(multiple)S -2 x
(xer)S 22282 Y 4945 X(\202)S 498 x(KLESI)S 184 x(for)S 183 x(R)S
-10 x(V20)S 182 x(and)S 182 x(R)S -10 x(V65)S 182 x(products)S 37373 Y
20908 X F36(V)S -36 x(AX)S 166 x(9000)S 165 x(Hardware)S 498 x
(2\20317)S
PP
EP
%%DOC$Page: 2-18 32
1000 BP 39600 30600 PM 0 0 XY
2106 Y 3899 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4247 Y 3899 X F20(Instruc)S -2 x(tor)S 298 x
(Notes)S 5443 Y 3899 X 23316 96 R 35879 Y 3899 X 23316 96 R 37373 Y
3899 X F36(2\20318.a)S 498 x(V)S -36 x(AX)S 166 x(9000)S 166 x
(Hardware)S
PP
EP
%%DOC$Page: 2-18 33
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4125 Y 3899 X F24(V)S -52 x(AX)S 233 x(9000)S
231 x(System)S 232 x(Models)S 6265 Y 6539 X F30(210,)S 9179 X(210VP)S
XP /F121 /amsy8 1500 399 400.0 128 [0 -33 31 25] PXLNF RP
XP /F121 3 212 3 2 13 15 14 16 0
<0600 0600 0400 C460 C460 E4E0 3F80 0E00 3F80 E4E0 C460 0400 0600
0600>
PXLC RP
10824 6084 XY F121(\003)S 7162 Y 6539 X F30(410,)S 9179 X(410VP)S
-181 y F121(\003)S 8058 Y 6539 X F30(420,)S 9179 X(420VP)S -180 y
F121(\003)S 8955 Y 6539 X F30(430,)S 9179 X(430VP)S -181 y F121
(\003)S 9852 Y 6539 X F30(440,)S 9179 X(440VP)S -181 y F121(\003)S
828 y 3899 X 23316 24 R 435 y 3899 X(\003)S
XP
% DefineFont:F34 Category:10 PointSize:10
/F34 500.0 /Helvetica@DOCPSE DPSF
RP
4135 11114 XY F34(VP)S 184 x(designates)S 182 x(a)S 183 x(model)S
182 x(with)S 182 x(a)S 183 x(vector)S 183 x(processor)S -28 x(.)S
37373 Y 20908 X F36(V)S -36 x(AX)S 166 x(9000)S 165 x(Hardware)S
498 x(2\20318)S
PP
EP
%%DOC$Page: 2-19 34
1000 BP 39600 30600 PM 0 0 XY
2106 Y 3899 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4247 Y 3899 X F20(Instruc)S -2 x(tor)S 298 x
(Notes)S 5443 Y 3899 X 23316 96 R 35879 Y 3899 X 23316 96 R 37373 Y
3899 X F36(2\20319.a)S 498 x(V)S -36 x(AX)S 166 x(9000)S 166 x
(Hardware)S
PP
EP
%%DOC$Page: 2-19 35
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4262 Y 3899 X F32(Figure)S 182 x(2\2032)S 680 x
(V)S -40 x(AX)S 182 x(9000)S 182 x(Models)S 182 x(210)S 182 x(and)S
182 x(410)S 181 x(System)S 183 x(Performance)S
4082 4980 XY
4082 16337 SPB
% Begin Plot (perf_210_410.eps)
%!PS-Adobe-2.0 EPSF 1.2
%%File: USER3:[COMP.RB0057]PERF_210_410.EPS
%%Creator: PSART, PostScript ART V1.1
%%Copyright 1987,1988,1989 DIGITAL EQUIPMENT CORPORATION. All Rights Reserved.
%%CreationDate: Wed Dec 27 10:40:52 1989
%%This file to be included in a DOCUMENT-produced file
%%
%%DOCUMENT <FIGURE_FILE> reservation = 12 picas.
%%
%%BoundingBox: 79 0 389 141
%%DocumentFonts: PSART-Helvetica
%%This file processed with the following qualifiers:
%%
%% /All_directions
%% /Centered = 6.5
%% /Comment_delimiter = !
%% /NoControl
%% /Encapsulated
%% /NoIges
%% /ISO (ISOLatin1 Character Encoding)
%% /Output = USER3:[COMP.RB0057]PERF_210_410.EPS
%% /NoPicmode
%% /Rotate = 0.00 degrees
%% /Size = 10
%% /Text_adjust = 4
%% /Thick = 1.44 points
%% /Thin = 0.86 points
%% /Type = HELV
%% /Xoffset = 0.00 inches
%% /Xscale = 1.00
%% /Yoffset = 0.00 inches
%% /Yscale = 1.00
%%
%% Analyzed character strings have maximum average width
%% of 5.67 points and a maximum average height of 7.55
%% points, with 3.78 points of leading between lines.
%%
%%EndComments
/reencode { findfont begin currentdict dup length dict begin { 1 index
/FID ne {def} {pop pop} ifelse } forall /FontName exch def dup length
0 ne { /Encoding Encoding 256 array copy def 0 exch { dup type
/nametype eq { Encoding 2 index 2 index put pop 1 add }{ exch pop }
ifelse } forall } if pop currentdict dup end end /FontName get exch
definefont pop } bind def mark /ISOLatin1 8#000 1 8#054
{StandardEncoding exch get} for /minus 8#056 1 8#217 {StandardEncoding
exch get} for /dotlessi 8#301 1 8#317 {StandardEncoding exch get} for
/space /exclamdown /cent /sterling /currency /yen /brokenbar /section
/dieresis /copyright /ordfeminine /guillemotleft /logicalnot /hyphen
/registered /macron /degree /plusminus /twosuperior /threesuperior
/acute /mu /paragraph /periodcentered /cedilla /onesuperior
/ordmasculine /guillemotright /onequarter /onehalf /threequarters
/questiondown /Agrave /Aacute /Acircumflex /Atilde /Adieresis /Aring
/AE /Ccedilla /Egrave /Eacute /Ecircumflex /Edieresis /Igrave /Iacute
/Icircumflex /Idieresis /Eth /Ntilde /Ograve /Oacute /Ocircumflex
/Otilde /Odieresis /multiply /Oslash /Ugrave /Uacute /Ucircumflex
/Udieresis /Yacute /Thorn /germandbls /agrave /aacute /acircumflex
/atilde /adieresis /aring /ae /ccedilla /egrave /eacute /ecircumflex
/edieresis /igrave /iacute /icircumflex /idieresis /eth /ntilde
/ograve /oacute /ocircumflex /otilde /odieresis /divide /oslash
/ugrave /uacute /ucircumflex /udieresis /yacute /thorn /ydieresis
/ISOLatin1 where not {256 array astore def} if cleartomark /DECMCS
ISOLatin1 256 array copy def mark 8#240 8#244 8#246 8#254 8#255 8#256
8#257 8#264 8#270 8#276 8#320 8#336 8#360 8#376 8#377 counttomark
{DECMCS exch /.notdef put} repeat 8#250 /currency 8#327 /OE 8#335
/Ydieresis 8#367 /oe 8#375 /ydieresis counttomark -1 bitshift {DECMCS
3 1 roll put} repeat cleartomark
%
%%Page
[1.00 0.00 0.00 1.00 81.89 3.78] concat
1 setlinecap 1 setlinejoin
ISOLatin1 /PSART-Helvetica /Helvetica reencode
/PSART-Helvetica findfont 10.00 scalefont setfont
14.49 120.80 moveto 0.40 0.00 (Model) ashow
104.81 120.80 moveto 0.40 0.00 (VUPS) ashow
162.74 120.80 moveto 0.40 0.00 (TPS) ashow
158.53 109.48 moveto 0.40 0.00 (Debit) ashow
158.53 98.15 moveto 0.40 0.00 (Credit) ashow
228.51 109.48 moveto 0.40 0.00 (MFLOPS*) ashow
201.77 98.15 moveto 0.40 0.00 (100x100) ashow
251.11 98.15 moveto 0.40 0.00 (1000x1000) ashow
-2.27 75.50 moveto 0.40 0.00 (VAX 9000) ashow
-2.27 64.18 moveto 0.40 0.00 (VAX 9000) ashow
-2.27 41.53 moveto 0.40 0.00 (VAX 9000) ashow
-2.27 30.20 moveto 0.40 0.00 (VAX 9000) ashow
47.10 75.50 moveto 0.40 0.00 (210) ashow
47.10 64.18 moveto 0.40 0.00 (210VP) ashow
47.10 41.53 moveto 0.40 0.00 (410) ashow
47.10 30.20 moveto 0.40 0.00 (410VP) ashow
113.26 75.50 moveto 0.40 0.00 (30) ashow
113.26 64.18 moveto 0.40 0.00 (30) ashow
221.10 75.50 moveto 0.40 0.00 (8) ashow
218.12 64.18 moveto 0.40 0.00 (18) ashow
271.96 64.18 moveto 0.40 0.00 (80) ashow
158.03 75.50 moveto 0.40 0.00 (44-70) ashow
158.03 64.18 moveto 0.40 0.00 (44-70) ashow
4.81 -3.78 moveto 0.40 0.00 (*Linpack double precision, FORTRAN.) ashow
113.26 41.53 moveto 0.40 0.00 (30) ashow
113.26 30.20 moveto 0.40 0.00 (30) ashow
221.10 41.53 moveto 0.40 0.00 (8) ashow
218.12 30.20 moveto 0.40 0.00 (18) ashow
271.96 30.20 moveto 0.40 0.00 (80) ashow
158.03 41.53 moveto 0.40 0.00 (44-70) ashow
158.03 30.20 moveto 0.40 0.00 (44-70) ashow
newpath 90.68 135.90 moveto 215.38 0.00 rlineto 0.864 setlinewidth stroke
newpath 90.68 135.90 moveto 0.00 -113.25 rlineto 0.864 setlinewidth stroke
newpath 147.36 135.90 moveto 0.00 -113.25 rlineto 0.864 setlinewidth stroke
newpath 198.37 135.90 moveto 0.00 -113.25 rlineto 0.864 setlinewidth stroke
newpath 306.06 135.90 moveto 0.00 -113.25 rlineto 0.864 setlinewidth stroke
newpath 90.68 90.60 moveto 215.38 0.00 rlineto 0.864 setlinewidth stroke
newpath 249.38 90.60 moveto 0.00 -67.95 rlineto 0.864 setlinewidth stroke
newpath 90.68 56.63 moveto 215.38 0.00 rlineto 0.864 setlinewidth stroke
newpath 90.68 22.65 moveto 215.38 0.00 rlineto 0.864 setlinewidth stroke
showpage
%%Trailer
% End Plot
SPE
XP
% DefineFont:F32 Category:10 PointSize:11
/Helvetica-Bold /Helvetica-Bold@DOCPSE DOCPSE ReENCODE
/F32 550.0 /Helvetica-Bold@DOCPSE DPSF
RP
3899 18098 XY F32(Figure)S 182 x(2\2033)S 680 x(Differences)S 182 x
(Between)S 181 x(the)S 183 x(V)S -40 x(AX)S 183 x(9000)S 181 x
(Models)S 182 x(210)S 182 x(and)S 182 x(410)S 181 x(Systems)S
4082 18816 XY
4082 27782 SPB
% Begin Plot (diff_210_410.eps)
%!PS-Adobe-2.0 EPSF 1.2
%%File: WORK2:[HUBBARD.SALES]DIFF_210_410.EPS
%%Creator: PSART, PostScript ART V1.1
%%Copyright 1987,1988,1989 DIGITAL EQUIPMENT CORPORATION. All Rights Reserved.
%%CreationDate: Thu Nov 9 14:07:59 1989
%%This file to be included in a DOCUMENT-produced file
%%
%%DOCUMENT <FIGURE_FILE> reservation = 15 picas.
%%
%%BoundingBox: 80 0 388 172
%%DocumentFonts: PSART-Helvetica
%%This file processed with the following qualifiers:
%%
%% /All_directions
%% /Centered = 6.5
%% /Comment_delimiter = !
%% /NoControl
%% /Encapsulated
%% /NoIges
%% /ISO (ISOLatin1 Character Encoding)
%% /Output = WORK2:[HUBBARD.SALES]DIFF_210_410.EPS
%% /NoPicmode
%% /Rotate = 0.00 degrees
%% /Size = 10
%% /Text_adjust = 4
%% /Thick = 1.44 points
%% /Thin = 0.86 points
%% /Type = HELV
%% /Xoffset = 0.00 inches
%% /Xscale = 1.00
%% /Yoffset = 0.00 inches
%% /Yscale = 1.00
%%
%% Analyzed character strings have maximum average width
%% of 5.44 points and a maximum average height of 7.55
%% points, with 3.78 points of leading between lines.
%%
%%EndComments
/reencode { findfont begin currentdict dup length dict begin { 1 index
/FID ne {def} {pop pop} ifelse } forall /FontName exch def dup length
0 ne { /Encoding Encoding 256 array copy def 0 exch { dup type
/nametype eq { Encoding 2 index 2 index put pop 1 add }{ exch pop }
ifelse } forall } if pop currentdict dup end end /FontName get exch
definefont pop } bind def mark /ISOLatin1 8#000 1 8#054
{StandardEncoding exch get} for /minus 8#056 1 8#217 {StandardEncoding
exch get} for /dotlessi 8#301 1 8#317 {StandardEncoding exch get} for
/space /exclamdown /cent /sterling /currency /yen /brokenbar /section
/dieresis /copyright /ordfeminine /guillemotleft /logicalnot /hyphen
/registered /macron /degree /plusminus /twosuperior /threesuperior
/acute /mu /paragraph /periodcentered /cedilla /onesuperior
/ordmasculine /guillemotright /onequarter /onehalf /threequarters
/questiondown /Agrave /Aacute /Acircumflex /Atilde /Adieresis /Aring
/AE /Ccedilla /Egrave /Eacute /Ecircumflex /Edieresis /Igrave /Iacute
/Icircumflex /Idieresis /Eth /Ntilde /Ograve /Oacute /Ocircumflex
/Otilde /Odieresis /multiply /Oslash /Ugrave /Uacute /Ucircumflex
/Udieresis /Yacute /Thorn /germandbls /agrave /aacute /acircumflex
/atilde /adieresis /aring /ae /ccedilla /egrave /eacute /ecircumflex
/edieresis /igrave /iacute /icircumflex /idieresis /eth /ntilde
/ograve /oacute /ocircumflex /otilde /odieresis /divide /oslash
/ugrave /uacute /ucircumflex /udieresis /yacute /thorn /ydieresis
/ISOLatin1 where not {256 array astore def} if cleartomark /DECMCS
ISOLatin1 256 array copy def mark 8#240 8#244 8#246 8#254 8#255 8#256
8#257 8#264 8#270 8#276 8#320 8#336 8#360 8#376 8#377 counttomark
{DECMCS exch /.notdef put} repeat 8#250 /currency 8#327 /OE 8#335
/Ydieresis 8#367 /oe 8#375 /ydieresis counttomark -1 bitshift {DECMCS
3 1 roll put} repeat cleartomark
%
%%Page
[1.00 0.00 0.00 1.00 82.44 0.43] concat
1 setlinecap 1 setlinejoin
ISOLatin1 /PSART-Helvetica /Helvetica reencode
/PSART-Helvetica findfont 10.00 scalefont setfont
130.07 154.78 moveto 0.40 0.00 (Model 210) ashow
230.69 154.78 moveto 0.40 0.00 (Model 410) ashow
-2.18 132.13 moveto 0.40 0.00 (System Performance) ashow
-2.18 98.15 moveto 0.40 0.00 (Growth) ashow
-2.18 75.50 moveto 0.40 0.00 (Availability/) ashow
-2.18 64.18 moveto 0.40 0.00 (Reliability) ashow
-2.18 30.20 moveto 0.40 0.00 (Price) ashow
133.13 132.13 moveto 0.40 0.00 (Excellent) ashow
226.55 132.13 moveto 0.40 0.00 (Potential for) ashow
226.55 120.80 moveto 0.40 0.00 (higher I/O) ashow
133.80 98.15 moveto 0.40 0.00 (Bounded) ashow
124.83 75.50 moveto 0.40 0.00 (Very reliable) ashow
129.67 30.20 moveto 0.40 0.00 (Entry level) ashow
227.43 98.15 moveto 0.40 0.00 (Expandable) ashow
216.23 75.50 moveto 0.40 0.00 (Available and) ashow
216.23 64.18 moveto 0.40 0.00 (Reliable through) ashow
216.23 52.85 moveto 0.40 0.00 (redundancy) ashow
221.98 30.20 moveto 0.40 0.00 (A bit higher to) ashow
221.98 18.88 moveto 0.40 0.00 (reflect growth) ashow
221.98 7.55 moveto 0.40 0.00 (potential) ashow
newpath 103.34 169.88 moveto 201.24 0.00 rlineto 1.440 setlinewidth stroke
newpath 103.34 169.88 moveto 0.00 -22.65 rlineto 1.440 setlinewidth stroke
newpath 206.68 169.88 moveto 0.00 -169.88 rlineto 0.864 setlinewidth stroke
newpath 304.58 169.88 moveto 0.00 -22.65 rlineto 1.440 setlinewidth stroke
newpath 103.34 147.23 moveto 201.24 0.00 rlineto 1.440 setlinewidth stroke
newpath 103.34 147.23 moveto 0.00 -147.23 rlineto 0.864 setlinewidth stroke
newpath 304.58 147.23 moveto 0.00 -147.23 rlineto 0.864 setlinewidth stroke
newpath 103.34 113.25 moveto 201.24 0.00 rlineto 0.864 setlinewidth stroke
newpath 103.34 90.60 moveto 201.24 0.00 rlineto 0.864 setlinewidth stroke
newpath 103.34 45.30 moveto 201.24 0.00 rlineto 0.864 setlinewidth stroke
newpath 103.34 0.00 moveto 201.24 0.00 rlineto 0.864 setlinewidth stroke
showpage
%%Trailer
% End Plot
SPE
XP
% DefineFont:F36 Category:10 PointSize:10
/Helvetica-Bold /Helvetica-Bold@DOCPSE DOCPSE ReENCODE
/F36 500.0 /Helvetica-Bold@DOCPSE DPSF
RP
20908 37373 XY F36(V)S -36 x(AX)S 166 x(9000)S 165 x(Hardware)S 498 x
(2)S
(\20319)S
PP
EP
%%DOC$Page: 2-20 36
1000 BP 39600 30600 PM 0 0 XY
2106 Y 3899 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S
XP
% DefineFont:F20 Category:10 PointSize:18
/F20 900.0 /Helvetica-Bold@DOCPSE DPSF
RP
3899 4247 XY F20(Instruc)S -2 x(tor)S 298 x(Notes)S 5443 Y 3899 X
23316 96 R 35879 Y 3899 X 23316 96 R 37373 Y 3899 X F36(2\20320.a)S
498 x(V)S -36 x(AX)S 166 x(9000)S 166 x(Hardware)S
PP
EP
%%DOC$Page: 2-20 37
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S
4082 4198 XY
4082 13164 SPB
% Begin Plot (perf_420_430_440.eps)
%!PS-Adobe-2.0 EPSF 1.2
%%File: USER3:[COMP.RB0057]PERF_420_430_440.EPS
%%Creator: PSART, PostScript ART V1.1
%%Copyright 1987,1988,1989 DIGITAL EQUIPMENT CORPORATION. All Rights Reserved.
%%CreationDate: Wed Dec 27 10:42:00 1989
%%This file to be included in a DOCUMENT-produced file
%%
%%DOCUMENT <FIGURE_FILE> reservation = 17 picas.
%%
%%BoundingBox: 79 0 389 197
%%DocumentFonts: PSART-Helvetica
%%This file processed with the following qualifiers:
%%
%% /All_directions
%% /Centered = 6.5
%% /Comment_delimiter = !
%% /NoControl
%% /Encapsulated
%% /NoIges
%% /ISO (ISOLatin1 Character Encoding)
%% /Output = USER3:[COMP.RB0057]PERF_420_430_440.EPS
%% /NoPicmode
%% /Rotate = 0.00 degrees
%% /Size = 10
%% /Text_adjust = 4
%% /Thick = 1.44 points
%% /Thin = 0.86 points
%% /Type = HELV
%% /Xoffset = 0.00 inches
%% /Xscale = 1.00
%% /Yoffset = 0.00 inches
%% /Yscale = 1.00
%%
%% Analyzed character strings have maximum average width
%% of 5.67 points and a maximum average height of 7.55
%% points, with 3.78 points of leading between lines.
%%
%%EndComments
/reencode { findfont begin currentdict dup length dict begin { 1 index
/FID ne {def} {pop pop} ifelse } forall /FontName exch def dup length
0 ne { /Encoding Encoding 256 array copy def 0 exch { dup type
/nametype eq { Encoding 2 index 2 index put pop 1 add }{ exch pop }
ifelse } forall } if pop currentdict dup end end /FontName get exch
definefont pop } bind def mark /ISOLatin1 8#000 1 8#054
{StandardEncoding exch get} for /minus 8#056 1 8#217 {StandardEncoding
exch get} for /dotlessi 8#301 1 8#317 {StandardEncoding exch get} for
/space /exclamdown /cent /sterling /currency /yen /brokenbar /section
/dieresis /copyright /ordfeminine /guillemotleft /logicalnot /hyphen
/registered /macron /degree /plusminus /twosuperior /threesuperior
/acute /mu /paragraph /periodcentered /cedilla /onesuperior
/ordmasculine /guillemotright /onequarter /onehalf /threequarters
/questiondown /Agrave /Aacute /Acircumflex /Atilde /Adieresis /Aring
/AE /Ccedilla /Egrave /Eacute /Ecircumflex /Edieresis /Igrave /Iacute
/Icircumflex /Idieresis /Eth /Ntilde /Ograve /Oacute /Ocircumflex
/Otilde /Odieresis /multiply /Oslash /Ugrave /Uacute /Ucircumflex
/Udieresis /Yacute /Thorn /germandbls /agrave /aacute /acircumflex
/atilde /adieresis /aring /ae /ccedilla /egrave /eacute /ecircumflex
/edieresis /igrave /iacute /icircumflex /idieresis /eth /ntilde
/ograve /oacute /ocircumflex /otilde /odieresis /divide /oslash
/ugrave /uacute /ucircumflex /udieresis /yacute /thorn /ydieresis
/ISOLatin1 where not {256 array astore def} if cleartomark /DECMCS
ISOLatin1 256 array copy def mark 8#240 8#244 8#246 8#254 8#255 8#256
8#257 8#264 8#270 8#276 8#320 8#336 8#360 8#376 8#377 counttomark
{DECMCS exch /.notdef put} repeat 8#250 /currency 8#327 /OE 8#335
/Ydieresis 8#367 /oe 8#375 /ydieresis counttomark -1 bitshift {DECMCS
3 1 roll put} repeat cleartomark
%
%%Page
[1.00 0.00 0.00 1.00 81.89 3.78] concat
1 setlinecap 1 setlinejoin
ISOLatin1 /PSART-Helvetica /Helvetica reencode
/PSART-Helvetica findfont 10.00 scalefont setfont
14.49 177.43 moveto 0.40 0.00 (Model) ashow
104.81 177.43 moveto 0.40 0.00 (VUPS) ashow
162.74 177.43 moveto 0.40 0.00 (TPS) ashow
228.51 177.43 moveto 0.40 0.00 (MFLOPS*) ashow
201.77 166.10 moveto 0.40 0.00 (100x100) ashow
251.11 166.10 moveto 0.40 0.00 (1000x1000) ashow
-2.27 132.13 moveto 0.40 0.00 (VAX 9000) ashow
-2.27 120.80 moveto 0.40 0.00 (VAX 9000) ashow
-2.27 86.83 moveto 0.40 0.00 (VAX 9000) ashow
-2.27 75.50 moveto 0.40 0.00 (VAX 9000) ashow
-2.27 41.53 moveto 0.40 0.00 (VAX 9000) ashow
-2.27 30.20 moveto 0.40 0.00 (VAX 9000) ashow
47.10 132.13 moveto 0.40 0.00 (420) ashow
47.10 120.80 moveto 0.40 0.00 (420VP) ashow
47.10 86.83 moveto 0.40 0.00 (430) ashow
47.10 75.50 moveto 0.40 0.00 (430VP) ashow
47.10 41.53 moveto 0.40 0.00 (440) ashow
47.10 30.20 moveto 0.40 0.00 (440VP) ashow
113.26 132.13 moveto 0.40 0.00 (59) ashow
113.26 120.80 moveto 0.40 0.00 (59) ashow
216.53 132.13 moveto 0.40 0.00 (n/a) ashow
216.53 120.80 moveto 0.40 0.00 (n/a) ashow
268.98 120.80 moveto 0.40 0.00 (158) ashow
110.28 41.53 moveto 0.40 0.00 (117) ashow
110.28 30.20 moveto 0.40 0.00 (117) ashow
162.47 132.13 moveto 0.40 0.00 (TBD) ashow
162.47 120.80 moveto 0.40 0.00 (TBD) ashow
4.81 -3.78 moveto 0.40 0.00 (*Linpack double precision, FORTRAN.) ashow
113.26 86.83 moveto 0.40 0.00 (88) ashow
113.26 75.50 moveto 0.40 0.00 (88) ashow
216.53 86.83 moveto 0.40 0.00 (n/a) ashow
216.53 75.50 moveto 0.40 0.00 (n/a) ashow
268.98 75.50 moveto 0.40 0.00 (235) ashow
162.47 86.83 moveto 0.40 0.00 (TBD) ashow
162.47 75.50 moveto 0.40 0.00 (TBD) ashow
216.53 41.53 moveto 0.40 0.00 (n/a) ashow
216.53 30.20 moveto 0.40 0.00 (n/a) ashow
268.98 30.20 moveto 0.40 0.00 (312) ashow
162.47 41.53 moveto 0.40 0.00 (TBD) ashow
162.47 30.20 moveto 0.40 0.00 (TBD) ashow
newpath 90.68 192.53 moveto 215.38 0.00 rlineto 0.864 setlinewidth stroke
newpath 90.68 192.53 moveto 0.00 -169.88 rlineto 0.864 setlinewidth stroke
newpath 147.36 192.53 moveto 0.00 -169.88 rlineto 0.864 setlinewidth stroke
newpath 198.37 192.53 moveto 0.00 -169.88 rlineto 0.864 setlinewidth stroke
newpath 306.06 192.53 moveto 0.00 -169.88 rlineto 0.864 setlinewidth stroke
newpath 90.68 158.55 moveto 215.38 0.00 rlineto 0.864 setlinewidth stroke
newpath 249.38 158.55 moveto 0.00 -135.90 rlineto 0.864 setlinewidth stroke
newpath 90.68 113.25 moveto 215.38 0.00 rlineto 0.864 setlinewidth stroke
newpath 90.68 67.95 moveto 215.38 0.00 rlineto 0.864 setlinewidth stroke
newpath 90.68 22.65 moveto 215.38 0.00 rlineto 0.864 setlinewidth stroke
showpage
%%Trailer
% End Plot
SPE
XP
% DefineFont:F36 Category:10 PointSize:10
/Helvetica-Bold /Helvetica-Bold@DOCPSE DOCPSE ReENCODE
/F36 500.0 /Helvetica-Bold@DOCPSE DPSF
RP
20908 37373 XY F36(V)S -36 x(AX)S 166 x(9000)S 165 x(Hardware)S 498 x
(2)S
(\20320)S
PP
EP
%%DOC$Page: 2-21 38
1000 BP 39600 30600 PM 0 0 XY
2106 Y 3899 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S
XP
% DefineFont:F20 Category:10 PointSize:18
/F20 900.0 /Helvetica-Bold@DOCPSE DPSF
RP
3899 4247 XY F20(Instruc)S -2 x(tor)S 298 x(Notes)S 5443 Y 3899 X
23316 96 R 35879 Y 3899 X 23316 96 R 37373 Y 3899 X F36(2\20321.a)S
498 x(V)S -36 x(AX)S 166 x(9000)S 166 x(Hardware)S
PP
EP
%%DOC$Page: 2-21 39
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4275 Y 3899 X F20(BENCHMA)S 2 x(RK)S 299 x
(RESUL)S -65 x(TS)S
XP
% DefineFont:F24 Category:10 PointSize:14
/F24 700.0 /Helvetica-Bold@DOCPSE DPSF
RP
3899 6318 XY F24(Scalar)S 232 x(Results)S
XP
% DefineFont:F30 Category:10 PointSize:11
/Helvetica /Helvetica@DOCPSE DOCPSE ReENCODE
/F30 550.0 /Helvetica@DOCPSE DPSF
RP
3899 8061 XY F30(\201)S 854 x(50)S 182 x(customer)S 183 x(bench)S
-2 x(marks)S 183 x(completed,)S 182 x(over)S 183 x(250)S 181 x
(programs\202average)S 181 x(42)S 182 x(VUPs)S 9256 Y 3899 X(\201)S
854 x(Single)S 181 x(User)S 183 x(Benchmark)S 182 x(Suite)S 183 x
(\(SUBS\))S 184 x(completed\20233)S 181 x(VUPs)S 183 x(overall)S
10452 Y 4945 X(\202)S 498 x(32)S 182 x(VUPs)S 183 x(integer)S 11648 Y
4945 X(\202)S 498 x(31)S 182 x(VUPs)S 183 x(single)S 181 x
(precision)S 12843 Y 4945 X(\202)S 498 x(40)S 182 x(VUPs)S 183 x
(doubl)S -2 x(e)S 183 x(precisio)S -2 x(n)S 14039 Y 3899 X(\201)S
854 x(Digital)S 181 x(Revie)S -2 x(w)S 183 x(DR)S 181 x(Labs)S 182 x
(CPU-2)S 183 x(scala)S -2 x(r)S 184 x(suite\2025)S -2 x(3)S 183 x
(MVUPs)S 183 x(\(40)S 183 x(VUPs\)\202better)S 184 x(than:)S 15234 Y
4945 X(\202)S 498 x(Convex)S 181 x(C240)S 181 x(=)S 183 x(45)S 182 x
(MVUPs)S 16430 Y 4945 X(\202)S 498 x(Multi\212ow)S 182 x(28/300)S
181 x(=)S 183 x(47)S 182 x(MVUPs)S 17625 Y 4945 X(\202)S 498 x(FPS)S
183 x(500EA)S 183 x(=)S 183 x(47)S 182 x(MVUPs)S 18821 Y 3899 X
(\201)S 854 x(CERN)S 182 x(\(Geneva\))S 182 x(suite)S 182 x
(completed)S 20016 Y 4945 X(\202)S 498 x(V)S -40 x(AX)S 184 x(9000)S
-2 x(-210)S 182 x(=)S 183 x(9.1)S 182 x(times)S 183 x(V)S -40 x(AX)S
183 x(8600)S 21212 Y 4945 X(\202)S 498 x(Cray)S 182 x(X-M)S 2 x
(P/48)S 183 x(=)S 182 x(7.7)S 22407 Y 4945 X(\202)S 498 x(IBM)S 184 x
(3090-40)S -2 x(0E)S 183 x(=)S 183 x(6.6)S 23603 Y 3899 X(\201)S
854 x(Perfect)S 183 x(Club)S 182 x(prelimina)S -2 x(ry)S 183 x
(results)S 24798 Y 4945 X(\202)S 498 x(Seismic)S 182 x(=)S 183 x(3)S
182 x(times)S 183 x(Convex)S 181 x(C220)S 25994 Y 4945 X(\202)S 498 x
(Structural)S 183 x(Analysis)S 182 x(=)S 183 x(5)S 27189 Y 4945 X
(\202)S 498 x(Signal)S 181 x(Processing)S 182 x(=)S 183 x(3)S 37373 Y
20908 X F36(V)S -36 x(AX)S 166 x(9000)S 165 x(Hardware)S 498 x
(2\20321)S
PP
EP
%%DOC$Page: 2-22 40
1000 BP 39600 30600 PM 0 0 XY
2106 Y 3899 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4247 Y 3899 X F20(Instruc)S -2 x(tor)S 298 x
(Notes)S 5443 Y 3899 X 23316 96 R 35879 Y 3899 X 23316 96 R 37373 Y
3899 X F36(2\20322.a)S 498 x(V)S -36 x(AX)S 166 x(9000)S 166 x
(Hardware)S
PP
EP
%%DOC$Page: 2-22 41
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 3996 Y 3899 X F30(\201)S 854 x(Livermore)S
182 x(Loops)S 5192 Y 4945 X(\202)S 498 x(Single)S 181 x(precision)S
181 x(=)S 183 x(37)S 182 x(VUPs)S 6387 Y 4945 X(\202)S 498 x(Doubl)S
-2 x(e)S 183 x(precisio)S -2 x(n)S 183 x(=)S 182 x(50)S 182 x(VUPs)S
7583 Y 3899 X(\201)S 854 x(NASTRAN)S 8779 Y 4945 X(\202)S 498 x(40)S
182 x(VUPs)S 183 x(without)S 182 x(optimizatio)S -2 x(n)S 9974 Y
4945 X(\202)S 498 x(M)S 183 x(number)S 182 x(=)S 183 x(.3)S 11170 Y
3899 X(\201)S 854 x(ANSYS)S 184 x(up)S 182 x(to)S 183 x(60)S 182 x
(VUPs)S 12714 Y 3899 X F24(V)S -38 x(ector)S 232 x(Results)S 14457 Y
3899 X F30(\201)S 854 x(Customer)S 182 x(version)S 182 x(of)S 183 x
(Discove)S -2 x(r)S 183 x(\(chemistry\))S 15653 Y 4945 X(\202)S 498 x
(Scalar:)S 244 x(10)S 182 x(times)S 182 x(V)S -40 x(AX)S 184 x(8810)S
16848 Y 4945 X(\202)S 498 x(V)S -30 x(ector:)S 244 x(20)S 182 x
(times)S 183 x(V)S -40 x(AX)S 184 x(881)S -2 x(0)S 18044 Y 4945 X
(\202)S 498 x(1.3)S 182 x(times)S 183 x(optimized)S 181 x(Convex)S
182 x(C21)S -2 x(0)S 183 x(\(optimization)S 181 x(took)S 182 x(one)S
182 x(person-year\))S 19239 Y 3899 X(\201)S 854 x(Indiana)S 181 x
(Unive)S -2 x(rsity\202test)S 184 x(was)S 182 x(990)S 181 x(million)S
181 x(\212oating)S 181 x(point)S 182 x(operation)S -2 x(s)S 20435 Y
4945 X(\202)S 498 x(Single)S 181 x(precision)S 181 x(81)S 182 x
(MFLOPS)S 21630 Y 4945 X(\202)S 498 x(Doubl)S -2 x(e)S 183 x
(precisio)S -2 x(n)S 183 x(67)S 182 x(MFLOPS)S 22826 Y 3899 X(\201)S
854 x(SDRC/IDEAS)S 184 x(\(Structural)S 183 x(analysis)S 181 x(for)S
183 x(automotive,)S 182 x(aerospace,)S 182 x(etc.\))S 24021 Y 4945 X
(\202)S 498 x(50)S 182 x(VUPs)S 183 x(scalar)S -31 x(,)S 183 x
(\211ve)S 183 x(times)S 182 x(as)S 183 x(fast)S 183 x(with)S 181 x
(vectors)S 37373 Y 20908 X F36(V)S -36 x(AX)S 166 x(9000)S 165 x
(Hardware)S 498 x(2\20322)S
PP
EP
%%DOC$Page: 2-23 42
1000 BP 39600 30600 PM 0 0 XY
2106 Y 3899 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4247 Y 3899 X F20(Instruc)S -2 x(tor)S 298 x
(Notes)S 5443 Y 3899 X 23316 96 R 35879 Y 3899 X 23316 96 R 37373 Y
3899 X F36(2\20323.a)S 498 x(V)S -36 x(AX)S 166 x(9000)S 166 x
(Hardware)S
PP
EP
%%DOC$Page: 2-23 43
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4104 Y 3899 X F24(Benchmark)S 231 x(Plans)S
5847 Y 3899 X F30(\201)S 854 x(Complete)S 181 x(vector)S 183 x(runs)S
182 x(in)S 182 x(early)S 182 x(April)S 183 x(\(LINP)S -40 x(ACK,)S
183 x(Perfect)S 184 x(Club,)S 182 x(SPEC,)S 184 x(others\))S 7042 Y
3899 X(\201)S 854 x(Batch)S 183 x(runs)S 182 x(of)S 183 x(workloa)S
-2 x(ds)S 183 x(in)S 182 x(March)S 8238 Y 4945 X(\202)S 498 x(D&B)S
183 x(\(McCormack)S 184 x(and)S 181 x(Dodge)S -2 x(\))S 9434 Y 4945 X
(\202)S 498 x(Ross)S 182 x(Systems)S 10629 Y 4945 X(\202)S 498 x
(Cyborg)S 11825 Y 4945 X(\202)S 498 x(MAC)S 183 x(P)S -40 x(AC/D)S
13020 Y 4945 X(\202)S 498 x(COMETS)S 14216 Y 3899 X(\201)S 854 x
(Full)S 181 x(characterization)S 181 x(starting)S 183 x(in)S 182 x
(May)S 182 x(\(ALL-IN-)S 2 x(1,)S 182 x(PDE,)S 184 x(others\))S
15411 Y 3899 X(\201)S 854 x(TPC-A)S 183 x(testing)S 182 x(starting)S
183 x(in)S 182 x(April)S 16607 Y 3899 X(\201)S 854 x(Publisha)S -2 x
(ble)S 182 x(results)S 182 x(at)S 183 x(DECUS)S 182 x(and)S 182 x
(DECworld)S 17802 Y 3899 X(\201)S 854 x(Customers)S 182 x(can)S 182 x
(be)S 182 x(present;)S 183 x(limited)S 181 x(dial-in)S 181 x
(possible)S 19346 Y 3899 X F24(Benchmark)S 231 x(Process)S 21090 Y
3899 X F30(\201)S 854 x(All)S 182 x(requests)S 182 x(\212ow)S 182 x
(through)S 182 x(benchmark)S 182 x(centers.)S 22285 Y 5991 X(Los)S
182 x(Angeles)S 648 y 5991 X(W)S -20 x(ashing)S -2 x(ton,)S 183 x
(DC)S 647 y 5991 X(V)S -40 x(albon)S -2 x(ne)S 648 y 5991 X(T)S -61 x
(oronto)S 25424 Y 3899 X(\201)S 854 x(All)S 252 x(bench)S -2 x
(marks)S 253 x(are)S 251 x(staged)S 251 x(before)S 251 x(running)S
251 x(on)S 251 x(V)S -40 x(AX)S 252 x(9000)S 251 x(system)S 252 x
(to)S 252 x(minimize)S 251 x(errors)S 252 x(and)S 647 y 4945 X
(estimate)S 182 x(time)S 183 x(requirements.)S 27267 Y 3899 X(\201)S
854 x(Batch)S 183 x(runs)S 182 x(\(R)S -10 x(TE)S 183 x(later\))S
28462 Y 3899 X(\201)S 854 x(VMS)S 184 x(and)S 182 x(UL)S -42 x(TRIX)S
183 x(software)S 183 x(avai)S -2 x(lable)S 29658 Y 3899 X(\201)S
854 x(Asking)S 182 x(for)S 183 x(competitive)S 182 x(data)S 37373 Y
20908 X F36(V)S -36 x(AX)S 166 x(9000)S 165 x(Hardware)S 498 x
(2\20323)S
PP
EP
%%DOC$Page: 2-24 44
1000 BP 39600 30600 PM 0 0 XY
2106 Y 3899 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4247 Y 3899 X F20(Instruc)S -2 x(tor)S 298 x
(Notes)S 5443 Y 3899 X 23316 96 R 35879 Y 3899 X 23316 96 R 37373 Y
3899 X F36(2\20324.a)S 498 x(V)S -36 x(AX)S 166 x(9000)S 166 x
(Hardware)S
PP
EP
%%DOC$Page: 2-24 45
1000 BP 39600 30600 PM 0 0 XY
2106 Y 19877 X F36(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S
166 x(ONL)S -46 x(Y)S 4125 Y 3899 X F24(SUMMAR)S -27 x(Y)S 5869 Y
3899 X F30(\201)S 854 x(V)S -40 x(AX)S 183 x(9000)S 182 x(systems)S
183 x(are)S 182 x(built)S 182 x(using)S 181 x(these)S 182 x(new)S
181 x(technolog)S -2 x(ies:)S 7064 Y 4945 X(\202)S 498 x(MCA)S 183 x
(III)S 184 x(integrated)S 181 x(circuit)S 183 x(usin)S -2 x(g)S 183 x
(ECL)S 182 x(technolo)S -2 x(gy)S 8260 Y 4945 X(\202)S 498 x(High)S
181 x(density)S 182 x(signa)S -2 x(l)S 183 x(carrier)S 183 x
(\(HDSC\))S 183 x(for)S 183 x(interconn)S -2 x(ecting)S 182 x(the)S
182 x(ICs)S 9455 Y 4945 X(\202)S 498 x(Multichip)S 181 x(unit)S 182 x
(\(MCU\))S 184 x(for)S 183 x(housi)S -2 x(ng,)S 182 x
(interconnectin)S -2 x(g,)S 183 x(and)S 182 x(cooli)S -2 x(ng)S 182 x
(the)S 183 x(ICs)S 182 x(and)S 182 x(HDSC)S 10651 Y 4945 X(\202)S
498 x(Planar)S 182 x(module)S 182 x(for)S 183 x(interconn)S -2 x
(ecting)S 182 x(the)S 182 x(MCUs)S 11846 Y 3899 X(\201)S 854 x
(Performance)S 183 x(of)S 183 x(the)S 182 x(three)S 182 x(main)S
182 x(subsystems)S 183 x(\(CPU,)S 183 x(memory)S -40 x(,)S 183 x
(and)S 182 x(I/O\))S 184 x(is)S 182 x(bala)S -2 x(nced.)S 13042 Y
4945 X(\202)S 498 x(System)S 266 x(control)S 265 x(unit)S 265 x
(\(SCU\))S 265 x(connects)S 265 x(subsystems)S 265 x(and)S 264 x
(manages)S 264 x(\212ow)S 264 x(of)S 266 x(data)S 264 x(among)S 647 y
5991 X(them.)S 14885 Y 3899 X(\201)S 854 x(V)S -40 x(AX)S 170 x
(9000)S 168 x(systems)S 170 x(are)S 169 x(desig)S -2 x(ned)S 168 x
(for)S 170 x(high)S 168 x(availa)S -2 x(bility)S 169 x(and)S 168 x
(reliab)S -2 x(ility)S 169 x(using)S 168 x(these)S 168 x(technique)S
-2 x(s:)S 16080 Y 4945 X(\202)S 498 x(Fault)S 182 x(avoid)S -2 x
(ance:)S 243 x(redundan)S -2 x(t)S 183 x(con\211guration)S -2 x(,)S
183 x(power)S 182 x(condi)S -2 x(tioning)S 17276 Y 4945 X(\202)S
498 x(Error)S 172 x(detection)S 170 x(and)S 169 x(analysi)S -2 x(s:)S
238 x(performed)S 171 x(by)S 170 x(service)S 170 x(processor)S 171 x
(unit)S 170 x(\(SPU\))S 172 x(hardware)S 169 x(and)S 647 y 5991 X(V)S
-40 x(AXsimPLUS)S 184 x(software)S 19119 Y 4945 X(\202)S 498 x
(Serviceabil)S -2 x(ity:)S 244 x(quick)S 182 x(repair)S 182 x(with)S
182 x(minimum)S 182 x(disruption)S 20314 Y 3899 X(\201)S 854 x(New)S
181 x(I/O)S 184 x(devices:)S 21510 Y 4945 X(\202)S 498 x(KDM70)S
183 x(loca)S -2 x(l)S 183 x(disk)S 182 x(and)S 181 x(tape)S 182 x
(controller)S 22705 Y 4945 X(\202)S 498 x(CIXCD)S 182 x(CI)S 183 x
(adapter)S 23901 Y 4945 X(\202)S 498 x(DEC)S 182 x(LANcontroller)S
182 x(400)S 182 x(\(DEMNA\))S 184 x(Ethernet)S 183 x(adap)S -2 x
(ter)S 25096 Y 4945 X(\202)S 498 x(V)S -40 x(AXBI)S 184 x(adapter)S
182 x(for)S 183 x(BI)S 184 x(expan)S -2 x(sion)S 26292 Y 3899 X
(\201)S 854 x(Benchmark)S 183 x(results)S 182 x(have)S 182 x(excee)S
-2 x(ded)S 182 x(estimated)S 182 x(performance)S 182 x(in)S 182 x
(most)S 183 x(cases.)S 37373 Y 20908 X F36(V)S -36 x(AX)S 166 x
(9000)S 165 x(Hardware)S 498 x(2\20324)S
PP
EP
%%DOC$Page: 2-25 46
1000 BP 39600 30600 PM 0 0 XY
PP
EP
%%Trailer
EndDVC$PSDoc
%%DocumentFonts: Helvetica-Bold@DOCPSE Helvetica@DOCPSE amsy8
%%Pages 46
|
| 78.44 | More on the JXDI timing problem | KERNEL::WRIGHTON | odd numbered release = bug insert | Wed Sep 19 1990 13:53 | 103 |
|
This entry is almost identical to note #33 , I have included it
for completeness.
Dave
+---------------------------+ TM
| | | | | | | |
| d | i | g | i | t | a | l | INTEROFFICE MEMORANDUM
| | | | | | | |
+---------------------------+
DATE: September 18, 1990
TO: 9K_TECH FROM: Charlie Kretz
DEPT: HPS CSSE
EXT: 297-4948
LOC: MRO2-3/5E
ENET: MRCSSE::KRETZ
SUBJECT: XJA/JXDI TIMING PROBLEM
There seems to be a lot of confusion around the XJA timing bug. This memo
is an attempt to clarify what what to do and when to do it. There is a
marginal timing bug in the system between the XJA and the SCU. The real
fix is the new shorter JXDI (17-01786-02) cable AND the XJA Clock
(17-02454-01) cable revision "C01". Most systems will never see this bug,
as an interim solution the XJA Clock cable phase check should reduce
the number of systems that see this bug even further.
1. First, every system currently in the field MUST have the XJA clock
phase check, the procedure is attached. This check applies to the
17-02454-01 cable revision "Axx" and "Bxx". The problem with these
cables is the output labeled "JB" on some cables is incorrectly
wired. The procedure merely gives the pin out of the cable so you can
find the "JC" leg if the cable is not labeled or labeled incorrectly.
Using this "JC" connector will eliminate the possibility of wiring
problem since it was correctly wired on all revisions of the cable.
2. A new revision of this cable (17-02454-01) "C01" corrects the problem
with the XJA Clock cable and either end "JB" or "JC" is usable.
However, this cable is only usable with the new shorter JXDI cables
(17-01786-02). The new shorter JXDI cables are not available
quantities yet, so, if you really believe you have a XJA/JXDI timing
escalate the call to CSSE, and CSSE will will help resolve any
problems.
XJA Clock Cable Phase Test:
1. Power off system
2. Disconnect the 17-02454-01 Cable from the MCM and XJA0 ends
3. With a DVM (ohmmeter) Locate the JB and JC connector
(see cable schematic below)
4. Tape over the JB connector
5. Reinstall JA to the MCM and JC to the XJA0
6. Power on system
7. Reboot, etc.
Cable schematic:
JA 1-----------------------------1 JB
JA 2-----------------------------2 JB
JA 3-----------------------------3 JB
JA 4-----------------------------4 JB
JA 5 open
JA 6 open
JA 7-----------------------------1 JC
JA 8-----------------------------2 JC
JA 9-----------------------------3 JC
JA 10-----------------------------4 JC
|-----|
| 9 10|
| 7 8 | As viewed from the cable connector,
key || 5 6 | mating end view
| 3 4 |
| 1 2 |
|-----|
17-02454-01 Cable configuration
JB
____
| | Normally
| |====> connects to XJA0
/--| |
JA / | |
____ / ----
To | | 17-02454-01 Assy /
MCM <== | |-----------------------------/
| |-----------------------------\
| | \ JC
---- \ ____
\ | |
| | \__| |====> Connect to XJA0
| | | | for correct
| | | | operation.
| | ----
| |
| |
SCU ------->|<----CPU Cabinet------>|<----- I/O Cabinet
| |
|
| 78.45 | Info on cache sweeps and associated bugs | KERNEL::WRIGHTON | odd numbered release = bug insert | Fri Sep 21 1990 08:32 | 205 |
|
(mrcsse::public:cache_sweeps.txt)
+---------------------------+ TM
| | | | | | | |
| d | i | g | i | t | a | l | I N T E R O F F I C E M E M O
| | | | | | | |
+---------------------------+
From: Maurice Steinman
Dept: VAX 9000 CPU Eng.
Loc: MRO1-3/T2
DTN: 297-5370
Phone: (508)467-5370
Enet: AQUA::STEINMAN
Date: 20-Sep-90
To: VAX 9000 Field/Support Engineers
Subj: VAX 9000 MBox cache sweep problems
I. Abstract
There are a number of cache sweep bugs in MBox logic present
in pre-C1 CPU logic configurations. In an attempt to work around these
bugs, Engineering has devised several initialization and microcode changes.
Admittedly, some of these work-arounds have some 'interesting' side-effects,
and in some cases, bring things to a grinding halt. The purpose of this memo
is threefold; (1) to explain the shortcomings of cache-sweep functionality,
(2) to describe the workarounds put in place, and (3) to describe the side-
effects that can result from the work-arounds.
II. What doesn't work - There are several hardware design bugs in the MBox
relating to cache sweeps.
A. Erroneous detection of single-bit and double-bit cache errors
This is due to the CTMV MCA addressing the data cache incorrectly
while trying to sweep the first block of set 0. The data does
not match the check bits in the ECC store, so an error is
reported. This can occur in any VAX 9000 configuration.
B. Abbreviated cache sweep
This is due to the CTMA MCA prematurely detecting the end of the
sweep. I have not seen this on any hardware system, but it
was found in a DECSIM simulation. This can occur in any VAX 9000
configuration.
C. Incorrect physical address
This is due to the CCSQ MCA selecting the wrong address sent to
the SCU by the CTMA MCA. It occurs when the cache sweep is
interrupted by the SCU to resolve a cache consistency fixup.
Because of this, it should chiefly occur on multiprocessor VAX
9000 configurations, although it is theoretically possible for
a uniprocessor to encounter this problem.
III. Work-arounds for above problems
A. Problem listed in II-A
It was determined that the MBox can sweep the cache reliably if
there were no modified data in the cache. Invalid and read-status
blocks can be processed correctly with currently existing hardware.
To that end, we requested that the EBox microcode read physical
memory blocks into the entire cache just prior to triggering the
sweep hardware. The microcode reads EREG location D0 (hex) to
obtain the initial physical address to read into the cache, and
issues multiple reads to subsequent addresses, thus filling both
cache sets with read-status data. The SPU loads EREG[D0] during
the initialization sequence once memory has been tested and the
addresses of good pages are known.
Note: if the EBox is unable to utilize the microcode (due to a
hardware error-fault), this workaround is bypassed.
B. Sweep problems in general
One approach (in conjunction with the above work-around) was to
disable sweeps on hardware error conditions and kernel-mode
HALT executions completely. After the microcode fills the cache
with read-status data (by using the above work-around), the sweep
action is triggered. It is however, disabled in the MBox, and
the CDXX attention is raised on the VAP MCU, bypassing the sweep
completely (so it doesn't have a chance to encounter the bugs
listed in I-B and I-C).
IV. Effects of bugs and workarounds - All this sounds good, but there
are some potential problems. In addition, SPU base-levels 10.2,
10.3, 10.4 and 11.0 each implement the work-arounds somewhat
differently. This can be very confusing!
When is the cache swept? First, let's enumerate all the scenarios
where the MBox cache is swept.
A. Software
A cache sweep can be initiated via software using the
the following instruction:
MTPR #1,#PR$_CSWP (PR$_CSWP = 42 Hex)
This type of sweep cannot be disabled in the MBox.
B. Hardware errors/faults
Part of the error-handling strategy of the VAX 9000 CPU is
to remove all memory data from the CPU via cache sweep.
C. Kernel-Mode HALT
When the CPU executes a HALT in kernel mode, the cache is
swept. The 'sweep-complete' attention signals the end of the
HALT to the SPU.
D. What can go wrong?
The problems arise chiefly from workaround III-B. This is
the work-around that is implemented differently in the various
releases of SPU software. The cache sweep scenarios described
in IV-B and IV-C can be disabled in the MBox by a single
scan deposit in CSA1:[SYSEXE]SITEINIT.CMD, namely:
! Disable HALT, ERROR cache sweeps
D/CPU=('CPU') %CPU.VAP.CCSQ.JCON.NO_ERROR_SWEEP_H 1
The following chart identifies which SPU software revisions
have enabled the IV-B and IV-C cache sweeps:
Base Level Revision Sweeps ENABLED in default SITEINIT?
---------------------------------------------------------------
BL10.2 Yes (not explicitly disabled)
BL10.3 Yes (not explicitly disabled)
BL10.4 No
BL10.5 No
BL11.0 Yes
Of course, if SITEINIT.CMD has been modified on site, this table
is invalid. In any case, SITEINIT.CMD should be checked for
the deposit 'VAP.CCSQ.JCON.NO_ERROR_SWEEP_H = 0' to ENABLE halt and
error sweeps (or = 1 to DISABLE).
i. Error/Halt sweeps disabled - SPU Memory access problems
If the sweep is disabled, a common failure mode is
SPU-SJA error messages: "Transmit Buffer not emptied" or
"No response from SCU on last packet sent." This happens when
the SPU attempts to access memory that is resident in the CPU
cache while the CPU clocks are stopped.
An example of this failure occurs while booting VDS with SPU
BL10.3 and sweeps disabled. During the VDS boot procedure, the
SPU attempts to perform a DMA write to an address that was
still resident in the CPU's cache due to work-around III-A.
The CPU's clocks were not running at the time, so the memory
writes did not complete, and the message "Transmit buffer not
emptied" was displayed. This has been successfully avoided by
disabling the memory test via
>>>DEFINE/SYS SYS$DISABLE_MEMORY_TEST 1
Additionally, part of the VDS/VMS boot procedure's memory test
actually executes on the 9000 CPU! If the halt-sweep is not
performed, it is also possible to run into the "Transmit
buffer not emptied" situation here.
| Note: VDS requires that memory be zeroed before it is booted.
| It will fail in an unpredictable manner if @CLEAR_MEMORY is
| not performed before booting VDS when the memory test is
| disabled.
A big problem is that work-around III-A can cause troubles if
III-B is also applied. It appears that the most pain is
generated by sweeps on HALTs being disabled. For this reason,
engineering has determined that they should be enabled in
BL11.0. This does leave the CPU vulnerable to bugs II-A and
II-B, but this only becomes a problem in the case of hardware
error-fault conditions.
ii. Error/Halt sweeps enabled - CPU hardware error faults
Another common failure occurs if a hardware error fault
condition is present in the CPU and work-around III-A is not
invoked, thus leaving the CPU vulnerable to bug II-A. The MBox
will often assert CTU.WBEM.SINGLE_BIT_ERR_TA_H or
CTU.WBEM.DOUBLE_BIT_ERR_TA_H unnecessarily because of this
bug.
V. Summary
In summary, engineering has determined that until the C1 configuration
is implemented in real systems, the error and halt sweeps should be enabled.
In addition, the field should be aware of shortcomings in the hardware, and
the implications of the work-arounds that have been put in place.
If there are *ANY* questions regarding these matters, please don't
hesitate to contact me. My phone number and E-Mail address are available
in the header of this memo.
(mrcsse::public:cache_sweeps.txt)
|
| 78.46 | cache control design bug | KERNEL::WRIGHTON | odd numbered release = bug insert | Fri Sep 21 1990 15:08 | 105 |
|
+---------------------------+TM
! ! ! ! ! ! ! ! i n t e r o f f i c e
! d ! i ! g ! i ! t ! a ! l !
! ! ! ! ! ! ! ! m e m o r a n d u m
+---------------------------+
Date: 21-Sep-1990
To: Distribution From: Gary Shepard
Dept: ISBS/CSSE
NODE: MRCSSE::SHEPARD
DTN: 297-5290
PHONE: 508-467-5290
LOC/MAIL STOP: MR02-3/5E
Subject: BUGCHECK/HALTS Caused by Cache Control Design Bug
_______ _______
Problem Symptom
System crashes with Kernel Mode Halts or Bugchecks. The halts and
bugchecks are at or around the same PC usually in a I/O device driver.
There would most likely be and instruction that will be doing a write
to an I/O device register. The only error bits that may be latched
are NXM errors. In one of the systems increasing the sysgen
paramenter NPAGEDYN by 1,200,000 enabled the system to run without any
halts.
The symptoms vary, but include,
I-stack not valid -- bogus PTE loaded
exception above ASTDEL -- bad i-stream fetched
page-fault, IPL too high -- bogus PTE loaded
HALT -- i-stream fetches zero's
mem nxm, read or write -- wild translation
io nxm, read or write -- wild translation
_________ ___________
Technical Description
The system failures are caused by improper virtual address
translations in the MBox. The effect of the logic bug is that a page
table entry (PTE) is loaded into the translation buffer (TB)
incorrectly.
The bug is provoked by the incidence of a TB miss while a CPU write,
typically to I/O space, is delayed due to a hardware resource wait.
During this delay, cache set selection information is frozen (even if
the CPU write is non-cacheable, as in I/O space writes). To resolve
the TB miss, the fixup processor requests the cache to deliver the
appropriate PTE for loading into the TB. If the PTE resides in the
Page 2
OPPOSITE cache set that is selected during the write-delay, incorrect
data will be delivered to the TB, thus causing an improper virtual
address translation. Only fixup processor requests are vulnerable to
this cache malfunction, because this is the only type of request that
the cache's arbitration logic allows to proceed while CPU writes are
in progress.
The effects of the problem are varied. Improper translations can lead
to a variety of exceptions, and in some cases hardware error
conditions.
____ ______ ___ ___
Work Around and Fix
The FIX for this problem will be Revision B5 release which should
occur sometime in November. The WORK AROUND for this problem is to
disable one of the Cache Sets by depositing the following command in
CSA1:[SYSEXE]SITEINIT.CMD. This work around should be applied only
when absolutely sure that it is need to resolve a particular problem.
Contact CSSE if unsure that disabling half of cache will resolve a
problem. Disabling one cache set could lead to a significant decrease
in performance depending on how the system is used doing mostly I/O or
compute bound jobs. Engineering is currently looking into a VMS and
UCODE change as a workaround.
! DISABLE SET 0
D/CPU=('CPU') CTU.CTMV.SET_SEL_H<1> 1
To Distribution List:
Rory O'DONNELL@UVO,
Dave WRIGHTON@UVO,
Andreas KAEMPFE@SUF,
Thomas RATSCH@MGO,
Gerd GABRYS@COO,
Roberto VERCELLI@TNO,
Maurizio MORRONE@RIO,
Walter GROSSI@MIO,
Daniel GONON@GVO,
MEIR ALON@ISO,
YUVAL Ashkenazi@ISH
|
| 78.47 | Version 11 console | KERNEL::WRIGHTON | odd numbered release = bug insert | Mon Sep 24 1990 15:43 | 76 |
|
+---------------------------+ TM
! ! ! ! ! ! ! ! i n t e r o f f i c e
! d ! i ! g ! i ! t ! a ! l !
! ! ! ! ! ! ! ! m e m o r a n d u m
+---------------------------+
Date: 9/24/90
To: VAX 9000 Technical Distribution From: Butch Leitz
Dept: HPS/C CSSE MEG
DTN: 297-4257
LOC/MAIL STOP: MRO2-3/5E, Pole 2C
Email: HPSMEG::LEITZ
cc:
Subject: Availability of VAX 9000 SPU Base Level 11 from SSB
Base Level 11 software is the FRS version of SPU software. If you
used Base Level 10.5, Base Level 11 is the same kit with an altered
SYSBOOT.EXE to remove references to Field Test and "Internal Use
Only". The only other differences are that the .SPDF files have
been updated, but are still not supported (ie, the scepter
diagnostics should not be used at this time).
There are two kits available.
QZ-K23AA-EW 1.0 is the customer's kit that will ship with each
system. It is also being sent to all the installed base in all
areas to bring the customer up to FRS software levels. It contains
two TK50 tapes with the following part numbers:
QZ-K23AA-EW1.0 - The VAX 9000 Customer Hardware Kit
AQ-PAKHA-ME VAX9000 CONSOLE IMAGE
AQ-PAKJA-ME VAX9000 CNSL UTIL + UCODE
QZ-K23AA-FW 1.0 is the Customer Services kit and it is orderable
from the SSB effective immediately. It contains the two tapes in
the customers hardware kit as well two additional TK50s that
contain licensable diagnostics and proprietary SDD software. The
part numbers of the TK50s in this kit are as follows:
QZ-K23AA-FW1.0 VAX9000 F.S. Diag CMPLT
AQ-PAKHA-ME VAX9000 CONSOLE IMAGE
AQ-PAKJA-ME VAX9000 CNSL UTIL + UCODE
AQ-PAKKA-DE VAX9000 DIAGNOSTICS
AQ-PBE9A-AE VAX9000 FLD SVC SDD
To meet FRS goals, we removed the 9 inch Magtape tapes from the QZ
kits but will probably add them back in at a later time.
All kits should include instructions for updating RD54s. To rebuild
an entire disk from scratch, it takes about 1 1/2 hours. Release
notes will be forthcoming, but refer to the 10.5 notes in the
interim.
To Distribution List:
Rory O'DONNELL@UVO,
Dave WRIGHTON@UVO,
Andreas KAEMPFE@SUF,
Thomas RATSCH@MGO,
Gerd GABRYS@COO,
Roberto VERCELLI@TNO,
Maurizio MORRONE@RIO,
Walter GROSSI@MIO,
Daniel GONON@GVO,
MEIR ALON@ISO,
YUVAL Ashkenazi@ISH
|
| 78.48 | We saw this 6 months ago,took a while to come thru | KERNEL::WRIGHTON | odd numbered release = bug insert | Mon Sep 24 1990 15:57 | 182 |
|
+---------------------------+ TM
! ! ! ! ! ! ! ! i n t e r o f f i c e
! d ! i ! g ! i ! t ! a ! l !
! ! ! ! ! ! ! ! m e m o r a n d u m
+---------------------------+
Date: 9/24/90
To: 9K Tech Dist From: Butch Leitz
Dept: HPS/C CSSE MEG
DTN: 297-4257
LOC/MAIL STOP: MRO2-3/5E, Pole 2C
Email: HPSMEG::LEITZ
cc:
Subject: ITEMS OF INTEREST WITH SPU HANDLING OF OCP
One definite bug and one "feature" has been found with the way
the SPU handles the OCP key switches. Both of these items have
been QAR'd by me into the engineering QAR system (console QARs
90 and 91). The feature listed below as "item 2" represents
potential security issues.
These two items are common to -all- versions of SPU software
available, Base Levels 11.0, 10.5 and under. They specifically
can be found on installations using the MDS01 to RTY port set
up.
Note that in all cases, the keyswitch on the MDS01 provides
absolute security.
Discussion on this follows the descriptions of the items:
Item 1:
-------
The SPU denies access when OCP keyswitch is set to REMOTE/OS.
When remote logins are attempted via the RTY port and REMOTE/OS
is set at the OCP, the error message:
"%CTL-F-DISABLE, interactive logins are currently disabled"
will display on the screen of the remote user every time <CR> is
struck. The bug is that the SPU CLI is denying access to the SPU
- even though access to the operating system is what's being
required. Setting the OCP keyswitch to REMOTE/SPU is the only
way that a remote user can log in. (One caveat to this exists:
Item 2 (see below)).
Item 2:
-------
The SPU will not drop or log out the REMOTE job on the SPU if
the remote line connection is disconnected. The REMOTE job is
terminated only on one of three following events:
1) if the SPU reboots;
2) if a local user manually stops the remote job:
>>> stop/job=<pid_of_remote_job>
3) if the remote user performs a LOGOUT command prior to
disconnecting the remote line.
As long as the REMOTE job remains available, a remote user can
log into the SPU and the operating system REGARDLESS OF THE
KEYSWITCH SETTINGS.
For example:
a) System turned on, SPU boots, system inits, OS boots.
b) OCP keyswitch gets set to REMOTE/SPU to enable remote dial in.
c) Remote user connects to SPU, connects to OS, performs tasks,
then logs out of the OS and disconnects the line.
(Note that the REMOTE job on the SPU was not logged out).
d) Keyswitch is reset to LOCAL/SPU.
e) Remote user dials in, and receives VMS banner and login prompt.
Note that had the previous remote user hit ^P to return to the
SPU prior to disconnecting the line, the SPU prompt would be
displayed at this point. The remote user could do any SPU command
or could type "CONT" to return to VMS.
f) Once connected to the OS, ^P is disabled so the user cannot
return to the SPU (ie, job treated as if switch is set to
REMOTE/OS even though physically set to LOCAL/SPU).
If the line disconnects while the remote user was logged into
VMS, (assuming line disconnects, not due to local user resetting
the REMOTE job on the SPU), the same or new remote user could
connect to the RTY port and automatically be logged into the VMS
job logged in by the previous remote user.
Note this was originally a request from the field to be able to
"get right back in" if the line dropped due to noise. It's also
clearly a risk.
The orange remote access "In Use" LED will be lit whenever the
REMOTE job is established on the SPU. If this remains lit after
the modem has disconnected a call, you know the remote job is
still "logged in" even if the remote port is not in use.
Site representatives, take note:
The current work around to force a log out of the REMOTE job on
the SPU is to use the STOP/JOB command:
>>> SHOW USERS
-
-
>>> STOP/JOB=<pid_of_remote_user_process>
Sometimes this does not work due to ELN process priorities.
Setting the MDS01 keyswitch to "LOCKOUT" or "USER PORT" will
always be effective in restricting remote use of the port.
Support engineers, take note:
Support engineers who dial into sites should be careful to
LOGOUT of the SPU prior to disconnecting the line (^A then DISC
under RSDS or VTERM). Simply disconnecting the line without
logging out of the SPU first will leave the SPU remote process
running, enabling the next remote user to continue a call from
where you left off.
When this gets fixed or modified, memos will be published to
this effect stating what version of SPU software contains the
fix.
When logging into the RTY port, you should see a banner from the
SPU (assuming keyswitch in REMOTE/SPU position) similar to the
following:
%CLI-I-STARTING, EWBAA X10.9(403) starting on node SALONE
%CLI-I-SYSTYPE, system type is VAX9000-2XX
If you don't get this banner but get the SPU prompt or the VMS
login prompt, then you know the previous user disconnected the
line (or got disconnected) without logging out of the SPU first.
Note on OCP keyswitch settings:
-------------------------------
REMOTE/SPU - remote enabled, ^P enabled, access to SPU and OS;
full local (CTY) access.
REMOTE/OS - remote enabled, ^P disabled, access to OS only
(item 1 identified above denies this access)
full local (CTY) access.
LOCAL/SPU - remote disabled, ^P enabled, local access to SPU and OS
(full CTY access)
LOCAL/OS - remote disabled, ^P disabled, local access to OS only
(once "CONT" has been typed at SPU).
Additional notes:
-----------------
The software "SET REMOTE" command under the SPU CLI provides
reliable security once the REMOTE job has been logged out. If
the remote port is disabled via a SET REMOTE OFF command, no
remote access will be allowed. If the REMOTE job is still
enabled, even if SET REMOTE OFF is executed, without logging out
the REMOTE job on the SPU, remote access will still be allowed.
Basically this acts the same as the keyswitches in that the
remote process needs to be logged off first before this command
will take hold.
End of memo.
|
| 78.49 | latest QAR list....be discrete | BEEZER::WRIGHTON | odd numbered release = bug insert | Tue Sep 25 1990 09:40 | 176 |
| -----------------------------------------------------------------------------
Status of P-RQT QARS Database 20 Sept 90
Database #Qars Total Open Closed Maintainer
-------- ----------- ---- ------ ----------
Tech_Mcu 8 5 3 R.Setera
Micro_Pkg 1 1 0 J.Mcphee
9000_200 4 2 2 J.Burroughs
9000_400 8 5 3 J.Burroughs
Power 5 3 2 C.Landino
9000_logic 44 28 16 D.Beaven
Console 6 2 4 D.Beaven
Aqua_Diags 1 0 1 R.Wood
9000_IO 4 2 2 L.Bales
Kernel 6 6 0 L.Millette
--- --- ---
87 (-22) 54 (-31) 33
New Qars for the week: 2
Previous Week: 109 (+8) 85 (-9) 24
9/21- P-RQT Bill Mahoney
Detailed Status Of 25 of the 54 open qars, the rest are under
investigation.
LOGIC
-----
1. Parity errors, on VML and other places, due to alpha-particle-emitting
encapsulent. Plan to use new encapsulent is underway.
Re: QAR 00001
2. Memory ECC errors, caused by data bits getting flipped in DDP memory
gate arrays by simultaneous switching transients. Rework is underway.
Permanent fix is coming in October. (?)
RE: QAR 00008
3. Inability to disable reporting of correctable ECC error. MMCX_D1 fixes
in system config C1.
RE: QAR 00032
4. Built-in self test failures due to occasionally shortened RAS signal
cause good memory to be marked bad in DEFECT_LIST. Workaround procedures
available. Fix to MACs is being designed, now incomplete.
RE: QAR 00075
5. Error recovery procedures fail often, due to I/O timeouts. Plan is to
have I/O drivers disable timeouts for VAX9000.
RE: QAR 00134
6. This is the "missing EB-ADDRESS" stall problem that is being investigated
in the debug lab after being seen on to RQT systems.
RE: QAR 00163
7. This is the JXDI cable timing problem caused by missing A-Latches in some
SCU chips. This is fixed in system config C1.
RE: QAR 00167
8. This is the problem where the SCU branches to an unused ucode location,
causing a control store parity error. This is under investigation in the
debug lab.
RE: QAR 00171
9. This is the "illegal unlock", or "unlock cache consistency" problem
under investigation in the debug lab. It is in the "Block Reserve and
Warning" logic of the Jbox.
RE: QAR 00181
10. This is the "dual vector block swap" problem that occurs on a 420 with
two Vboxes. It is under investigation in the debug lab.
RE: QAR 00210
CONSOLE
-------
1. SPU HANGS WHEN CONNECTED VCS. Connecting VCS to RQT machines for
regression test.
RE: QAR 00028
2. ELN TIMER SERVICES FAIL ON SET TIME .ELN Problem. Can't fix.
RE: QAR 00029
3. Rd54 data corruption? Qar #? Awaiting event and return of RD54 w/ AIO
when same occurs for Console analysis.
Technology
----------
Tech MCU
1. No Problem Found on MCU's. Several MCU have completed F/A in MRO with NPF.
Why? These where real field failures. Qar 69 is an example.
Micro_pkg
2. Cold boot test yet to be conducted in RQT.
RE: QAR 00067
Power
3. MTA Connector issue. Low priority. To be transferred to SASE.
RE: QAR 00006
9000_200
4. JXDI Cable implementation plan now being worked.
RE: 00042
JB input: Vendor trip report will be appended.
Mech design promises ECOs to be written by 9/21/90.
5. Header connector eco required.
RE: QAR 00047
JB input: Will be addressed by Mech design on 9/21/90.
9000_400
6. Sid, needs implementation plan.
RE: QAR 00003
JB input: All documentation complete. Retrofit has
communicated to BTO. This and QAR 00004 will
be closed.
7. Strain relief needs implementation plan.
RE: QAR 00007
LOOSE RD54 CABLE CAUSES BOOTSTRAP FAILURE
Will be addressed by Mech Design 9/21/90.
8. Difficulty installing Z-Flex on 4xx's. Cabinet dimensions and Z-Flex
packaging needs review.
RE QAR: 00012
I/O Engineering
---------------
1. System Hangs......status open
RE QAR: 00021
2. Self Test Fails on KDM....status open
RE QAR: 00022
|
| 78.50 | signals to check for JXDI timing problem | KERNEL::WRIGHTON | odd numbered release = bug insert | Wed Sep 26 1990 10:33 | 47 |
|
There may have been some misunderstanding on how to determine if a
system is displaying the JXDI cable problem. See the following change
listed below.
Gary Shepard
CSSE
DTN 297-5290
508-467-5290
6. Bug: XJA/JXDI/SCU Timing problem
To identify the XJA/JXDI Timing problem, check these
scanlatches at the time of failure.
1. %SCU.CCU.CTLA.PRTERR_H<2> = 1
<<<<<<OR>>>>>>
2. %SCU.CCU.CTLA.2PRTRDY_H<1:0> = 0 or 1 and
%SCU.DA0.JDC0.RCV_CCU.TO_XJA_BUFA_FULL_TB_H = 0 and
%SCU.DA0.JDC0.RCV_CCU.TO_XJA_BUFB_FULL_TB_H = 0 and
%SCU.DA0.JDC0.RCV_CCU.IO_BUFA_BUSY_TB_H = 0 and
%SCU.DA0.JDC0.RCV_CCU.IO_BUFB_BUSY_TB_H = 0
===========================================================
or if XJA2 or XJA3 exists,
1. %SCU.CCU.CTLA.PRTERR_H<5> = 1
<<<<<<OR>>>>>>
2. %SCU.CCU.CTLA.5PRTRDY_H<1:0> = 0 or 1 and
%SCU.DA1.JDC0.RCV_CCU.TO_XJA_BUFA_FULL_TB_H = 0 and
%SCU.DA1.JDC0.RCV_CCU.TO_XJA_BUFB_FULL_TB_H = 0 and
%SCU.DA1.JDC0.RCV_CCU.IO_BUFA_BUSY_TB_H = 0 and
%SCU.DA1.JDC0.RCV_CCU.IO_BUFB_BUSY_TB_H = 0
Cause: Unexpectedly long data path signal between the XJA
and the SCU
Fix: Implemented in 3 Phases
Very Short Term - Do XJA Clock Cable Phase check
Short Term - Replace JXDI Cable with new cable
(17-01786-02)
|
| 78.51 | Configuring HSC's | KERNEL::WRIGHTON | odd numbered release = bug insert | Sat Sep 29 1990 20:03 | 23 |
|
< from Joe Canonica >
There exists some confusion or misunderstanding on
cluster configurations and node numbering of HSCs.
Many of our 9000 sites are being told to NOT configure
HSCs at nodes 0 & 1 to avoid 'HOST CLEAR' problems on heavily
loaded clusters. Also that HSC at node 0 can not be used
as an alternate boot path.
Do NOT take any action on 9000 or other sites regarding
these two issues!!!! And please help to squash these rumors!
The misunderstanding is being addressed...
Will give you all an update when finalized.....
thanks
/joe
|
| 78.52 | VMS 5.4-0A message | KERNEL::WRIGHTON | odd numbered release = bug insert | Tue Oct 02 1990 00:44 | 79 |
|
Info on Special V5.4-0A Patch Kit (compliments Ellen Barden)
+++++++++++++++++++++++++
+ D I G I T A L + INTEROFFICE MEMORANDUM
+++++++++++++++++++++++++
DATE: September 28, 1990
TO: Distribution FROM: Ellen Barden
DEPT: CSSE/32-Bit BSSG
CC: LOC: ZKO1-1/D19
EXT: 381-2801
ENET: CSSE32::BARDEN
SUBJECT: Special VMS V5.4-0A Patch Kit
-------------------------------------------------------------------------------
DIGITAL INTERNAL USE ONLY
-------------------------------------------------------------------------------
Since VMS V5.4 submitted to the SSB in early September, some VMS software
problems have been discovered that may potentially affect the new VAX 9000
and VAX 6000-5xx systems. VMS engineering has decided that a patch kit is
needed for the customers of those new processors only, in order to ensure
their stability. Please note that the VAX 6000 5xx system has not been
announced yet.
This patch kit will be distributed with VAX 9000 and VAX 6000-5xx systems
until VMS V5.4-1 ships (expected date December 1990). All fixes contained
in this patch kit will be part of this VMS release, so all customers will
receive the fixes at that time. The patch kit will also be sent
to all customers worldwide who have already received a VAX 9000 system, and
to any CSC contacts who received a VMS V5.4 pre-release kit(these shipments
should be completed by October 5, 1990).
KIT DESCRIPTION:
The patch kit will be available on TK50, magnetic tape, and CDROM media.
It will update the VMS version number on the system from VMS V5.4 to VMS
V5.4-0A for support reasons. The kit will also include a cover letter
explaining the installation instructions. A postscript file of the cover
letter is being sent to you in a separate mail message.
The VMS V5.4-0A special patch kit contains fixes for the following areas:
o DUDRIVER (Potential data corruption problem - QAR #1482)
o F11BXQP (QAR #1328)
o MARIAH Lurt Table
o MARIAH warm start
o VAX-9000 console security
o VAX-9000 DEMNA driver selfstart
o VAX-9000 SMP Stop/CPU
o VAX-9000 SMP powerfail restart
SSB MANUFACTURING/SHIPMENT PLANS:
The magnetic tape patch kit(part #QA-001AA-TM) will ship on the QA-001AA-HM
kit (VMS V5.4 H kit for VAX 9000 customers) beginning on October 5, 1990.
It will also be incorporated into any VMS V5.4 pre-release kits for the VAX
9000 systems until VMS V5.4 FRS (October 5th).
The TK50 patch kit (part #QA-001AA-T5) or CDROM patch kit (part #QA-001AA-T8)
will be added to the VAX 6000-5xx H/W information kit (Part #QZ-K33AA-EW).
All three media kits will be available in the U.S. via the SSB Fastship program.
Part numbers of these kits are:
o QA-001AA-TM (magnetic tape and cover letter) available Oct. 5, 1990
o QA-001AA-T5 (TK50 cartridge and cover letter) available Oct. 5, 1990
o QA-001AA-T8 (CDROM and cover letter) available Oct. 10, 1990
The SSB will use the Colorado Patch Kit process to log/track/ship the patch
to U.S. customers as necessary. Europe will set up a similar delivery
mechanism with the European CSCs, and GIA CSCs will ensure that the patch
kit is available in their regions.
|
| 78.53 | Covering letter for V5.4-0A (postscript format) | KERNEL::WRIGHTON | odd numbered release = bug insert | Tue Oct 02 1990 00:48 | 1255 |
|
%!PS-Adobe-2.0
%%Creator: VAX DOCUMENT V1.2B
%%+(+1 PSEUDOCONDENSE)
%%+Copyright 1986,1987,1988,1989,1990 DIGITAL EQUIPMENT CORPORATION.
%%+All Rights Reserved.
%%DocumentFonts: (atend)
%%Pages: (atend)
%%EndComments
/DEC_DVC$dict where { %FIND DICTIONARY
pop
}{ %else
/DEC_DVC$dict 300 dict def
} ifelse
/BeginDVC$PSDoc { %BEGIN DOCUMENT
vmstatus pop pop 0 eq {
DEC_DVC$dict begin InitializeState
}{ %else
/DVC$PSJob save def DEC_DVC$dict begin InitializeState
/DVC$PSFonts save def
} ifelse
} def
/EndDVC$PSDoc { %END DOCUMENT
% --- Preserving current page count ---
vmstatus pop pop 0 eq {
end
}{ %else
DVC$PSFonts restore end DVC$PSJob restore
} ifelse
} def
%
DEC_DVC$dict begin
%
mark % CREATE ISOLatin1 ENCODING
/ISOLatin1
8#000 1 8#054 {StandardEncoding exch get} for
/minus
8#056 1 8#217 {StandardEncoding exch get} for
/dotlessi
8#301 1 8#317 {StandardEncoding exch get} for
/space /exclamdown /cent /sterling /currency /yen /brokenbar /section
/dieresis /copyright /ordfeminine /guillemotleft /logicalnot /hyphen
/registered /macron /degree /plusminus /twosuperior /threesuperior /acute
/mu /paragraph /periodcentered /cedilla /onesuperior /ordmasculine
/guillemotright /onequarter /onehalf /threequarters /questiondown /Agrave
/Aacute /Acircumflex /Atilde /Adieresis /Aring /AE /Ccedilla /Egrave /Eacute
/Ecircumflex /Edieresis /Igrave /Iacute /Icircumflex /Idieresis /Eth /Ntilde
/Ograve /Oacute /Ocircumflex /Otilde /Odieresis /multiply /Oslash /Ugrave
/Uacute /Ucircumflex /Udieresis /Yacute /Thorn /germandbls /agrave /aacute
/acircumflex /atilde /adieresis /aring /ae /ccedilla /egrave /eacute
/ecircumflex /edieresis /igrave /iacute /icircumflex /idieresis /eth /ntilde
/ograve /oacute /ocircumflex /otilde /odieresis /divide /oslash /ugrave
/uacute /ucircumflex /udieresis /yacute /thorn /ydieresis
/ISOLatin1 where not {256 array astore def} if
cleartomark
%
/DECMCS ISOLatin1 256 array copy def
mark % CREATE DECMCS ENCODING
8#240 8#244 8#246 8#254 8#255 8#256 8#257 8#264
8#270 8#276 8#320 8#336 8#360 8#376 8#377
counttomark
{DECMCS exch /.notdef put} repeat % STACK NOW CONTAINS MARK
8#250 /currency 8#327 /OE 8#335 /Ydieresis 8#367 /oe 8#375 /ydieresis
counttomark -1 bitshift % DIVIDE BY 2
{DECMCS 3 1 roll put} repeat % STACK NOW CONTAINS MARK
cleartomark
%
/DOCPSE DECMCS 256 array copy def
mark % CREATE DOCPSE ENCODING
8#055 /hyphen
8#201 /bullet 8#202 /emdash 8#203 /endash 8#204 /dagger
8#205 /daggerdbl 8#206 /registered 8#207 /trademark %8#210 /Delta
8#211 /fi 8#212 /fl
counttomark -1 bitshift % DIVIDE BY 2
{DOCPSE 3 1 roll put} repeat % STACK NOW CONTAINS MARK
cleartomark
%
/reencodedict 10 dict def %Local storage for "ReENCODE"
/ReENCODE { % /basefont /newfont encoding ReENCODE
/newencoding exch def %ARG: NAME OF ENCODING VECTOR
/newfontname exch def %ARG: NEW NAME FOR FONT AFTER RE-ENCODING
findfont
/basefontdict exch def %ARG: NAME OF FONT TO BE RE-ENCODED
basefontdict maxlength dict begin %CREATE AND OPEN NEW DICT
basefontdict { %COPY ENTRIES FROM BASE FONT DICT TO NEW ONE
1 index /FID ne {
def %IF NOT THE ONE WE'RE ENCODING, JUST COPY PTRS
} { %else
pop pop %IGNORE FID AND ENCODING FOR ONE WE'RE ENCODING
} ifelse
} forall
/FontName newfontname def %DEFINE NEW NAME
/Encoding newencoding def %DEFINE NEW ENCODING VECTOR
newfontname currentdict definefont %TURN IT INTO A PS FONT
pop %IGNORE MODIFIED DICT RETURNED BY DEFINEFONT
end
} def
%
/cvsstr 64 string def
/tempmatrix matrix def
%
/BP { % BEGIN PAGE
/Magnification exch def
/Colorsused 0 def
/RVmatrix matrix def
/DVC$PSPage save def
} def
%
/EP {DVC$PSPage restore} def % END PAGE
%
/XP { % EXIT PAGE (TEMPORARILY) TO ADD FONTS/CHARS
% SAVE CURRENT POINT AND COLOR INFORMATION SO IT CAN BE RESET LATER
matrix currentmatrix aload pop currentrgbcolor Colorsused
/Xpos where {pop Xpos} {0} ifelse
/Ypos where {pop Ypos} {0} ifelse
/currentpoint cvx stopped {0 0 moveto currentpoint} if
/DVC$PSPage where {pop DVC$PSPage restore} if
moveto
/Ypos exch def /Xpos exch def
/Colorsused exch def setrgbcolor
matrix astore setmatrix
} def
%
/RP {/DVC$PSPage save def} def % RESUME PAGE
%
/PF {GlobalMode LocalMode} def % PURGE FONTS TO RECLAIM MEMORY
%
/GlobalMode { % SWITCH TO BASE SAVE/RESTORE LEVEL, SAVING STATE
RVmatrix aload pop
PortraitMode PaperWidth PaperHeight PxlResolution Resolution
Magnification Ymax Xorigin Yorigin RasterScaleFactor
% SAVE CURRENTPOINT INFORMATION TO RESET LATER
/currentpoint cvx stopped {0 0 moveto currentpoint} if
/DVC$PSPage where {pop DVC$PSPage restore} if
DVC$PSFonts restore RecoverState
} def
%
/RecoverState { % PRESERVE STATE AT BASE LEVEL
18 copy
/Ypos exch def /Xpos exch def /RasterScaleFactor exch def
/Yorigin exch def /Xorigin exch def /Ymax exch def
/Magnification exch def /Resolution exch def /PxlResolution exch def
/PaperHeight exch def /PaperWidth exch def /PortraitMode exch def
matrix astore /RVmatrix exch def
DoInitialScaling
RVmatrix concat
PortraitMode not {PaperWidth 0 SetupLandscape} if
Xpos Ypos moveto
} def
%
/InitializeState { % INITIALIZE STATE VARIABLES TO DEFAULT VALUES
/Resolution 3600 def /PxlResolution 300 def
/RasterScaleFactor PxlResolution Resolution div def
/PortraitMode true def
/Magnification 1000 def /Xorigin 0 def /Yorigin 0 def
/Xpos 0 def /Ypos 0 def /InitialMatrix matrix currentmatrix def
/Colorsused 0 def /RVmatrix matrix def
} def
%
/LocalMode { % SWITCH FROM BASE SAVE/RESTORE LEVEL, RESTORING STATE
/Ypos exch def /Xpos exch def /RasterScaleFactor exch def
/Yorigin exch def /Xorigin exch def /Ymax exch def
/Magnification exch def /Resolution exch def /PxlResolution exch def
/PaperHeight exch def /PaperWidth exch def /PortraitMode exch def
matrix astore /RVmatrix exch def
DoInitialScaling
RVmatrix concat
PortraitMode not {PaperWidth 0 SetupLandscape} if
Xpos Ypos moveto
/DVC$PSFonts save def /DVC$PSPage save def
} def
% % ABBREVIATIONS
/S /show load def
/SV /save load def
/RST /restore load def
/Yadjust {Ymax exch sub} def
%
/SXY { % (x,y) POSITION ABSOLUTE, JUST SET Xpos & Ypos, DON'T MOVE
Yadjust /Ypos exch def /Xpos exch def
} def
%
/XY { % (x,y) POSITION ABSOLUTE
Yadjust 2 copy /Ypos exch def /Xpos exch def moveto
} def
%
/X { % (x,0) POSITION ABSOLUTE
currentpoint exch pop 2 copy /Ypos exch def /Xpos exch def moveto
} def
%
/Y { % (0,y) POSITION ABSOLUTE
currentpoint pop exch Yadjust 2 copy
/Ypos exch def /Xpos exch def moveto
} def
%
/xy { % (x,y) POSITION RELATIVE
neg rmoveto currentpoint /Ypos exch def /Xpos exch def
} def
%
/x { % (x,0) POSITION RELATIVE
0 rmoveto currentpoint /Ypos exch def /Xpos exch def
} def
%
/y { % (0,y) POSITION RELATIVE
0 exch neg rmoveto currentpoint /Ypos exch def /Xpos exch def
} def
%
/R { % DRAW A RULE
/ht exch def /wd exch def gsave
% 0 setgray
currentpoint newpath moveto
0 ht rlineto wd 0 rlineto
0 ht neg rlineto wd neg 0 rlineto
closepath fill grestore wd 0 rmoveto
currentpoint /Ypos exch def /Xpos exch def
} def
%
/RES { % <PXL-file resolution(pix/inch)> <resolution(pix/inch)> RES
/Resolution exch def /PxlResolution exch def
/RasterScaleFactor PxlResolution Resolution div def
DoInitialScaling
} def
%
/DoInitialScaling { % DO INITIAL SCALING
InitialMatrix setmatrix 72 Resolution div dup scale
} def
%
/PM { % <paper-height(pix)> <paper-width(pix)> PM
XP
/PaperWidth exch def /PaperHeight exch def
/Ymax PaperHeight def /PortraitMode true def
DoInitialScaling
RP
} def
%
/SetupLandscape {translate 90 rotate} def
/LM { % <paper-height(pix)> <paper-width(pix)> LM
XP
/PaperWidth exch def /PaperHeight exch def
/Ymax PaperWidth def /PortraitMode false def
DoInitialScaling PaperWidth 0 SetupLandscape
RP
} def
%
/MAG { % CHANGE MAGNIFICATION SETTING
XP /Magnification exch def RP
} def
%
/SPB { % <xoffset><yoffset>SPB - BEGIN "\SPECIAL" MODE
Yadjust /Yorigin exch def /Xorigin exch def
currentrgbcolor Colorsused
GlobalMode Xorigin Yorigin translate
Resolution 72 div dup scale % RESTORE DEFAULT SCALING
Magnification 1000 div dup scale % ADJUST FOR ANY MAGNIFICATION
/Xpos Xpos 72 Resolution div mul 1000 Magnification div mul def
/Ypos Ypos 72 Resolution div mul 1000 Magnification div mul def
/spsavobj save def %SAVE STATE & STACK DEPTH FOR CLEANUP AFTER FIGURE
/showpage {} def %DISABLE DURING FIGURE; `RESTORE' WILL BLOW DEF AWAY
/DEC$EDMS_setrgbcolor /setrgbcolor load def % save standard definition
/setrgbcolor { % create new definition
/DEC$EDMS_SEPARATE_COLORS where % if separating colors
{ pop DEC$EDMS_SEPARATE_COLORS 0 ne % and not on color pass 0
{ pop pop pop 1 1 1 } if % ...then write white
} if
DEC$EDMS_setrgbcolor % set color as now specified
} def
/DEC$EDMS_image /image load def % save standard definition
/image { % create new definition
/DEC$EDMS_SEPARATE_COLORS where % if separating colors
{ pop DEC$EDMS_SEPARATE_COLORS 0 ne % and not on color pass 0
{ gsave % ...save current device state
nulldevice % ...make no marks
DEC$EDMS_image % ...process the image
grestore % ...restore old device state
}
{ DEC$EDMS_image } ifelse % if on color pass 0 - image
}
{ DEC$EDMS_image } ifelse % if not separating colors - image
} def mark
} def
%
/SPE { % SPE - END "\SPECIAL" MODE
cleartomark
spsavobj restore
1000 Magnification div dup scale % UN-ADJUST FOR ANY MAGNIFICATION
72 Resolution div dup scale % RESTORE DEFAULT INTERNAL SCALING
LocalMode
/Colorsused exch def setrgbcolor
} def
%
/PP
%
% If DEC$EDMS_MAKE_FILM is defined, it will add the crop & alignment marks,
% and the document name, page number, & ink color identifiers to the page.
%
% Formal Arguments: None
%
% Referenced Variables: DocumentName
% Colorsused
% Currentpagecount
% DEC$EDMS_MAKE_FILM
%
% Referenced Procedures: AlignMark
%
% Side Effects: Leaves the current font as Helvetica 8 point.
% Creates the variable "junkstr".
%
{ /PageNumber exch def
/DEC$EDMS_MAKE_FILM where % if making film...
{ pop 2 DEC$EDMS_SEPARATE_COLORS exp cvi Colorsused and 0 ne % and if the correct separation
{ /Helvetica findfont 400 scalefont setfont
20 setlinewidth 0 setgray
PaperWidth 150 add PaperHeight 100 add moveto % show the ink color
(Ink: ) show DEC$EDMS_COLOR_NAMES DEC$EDMS_SEPARATE_COLORS get show
PaperWidth 150 add PaperHeight 600 add moveto
(Page: ) show % show the page number
/junkstr 4 string def PageNumber junkstr cvs show
( of ) show DEC$EDMS_TOTAL_PAGES junkstr cvs show
150 PaperHeight 100 add moveto % show the document name
(Document: ) show DEC$EDMS_DOCUMENT_ID show
150 -500 moveto % show ownership text
(This film is the property of Digital Equipment Corporation) show stroke
/mask 15 % all crop marks on by default
/DEC$EDMS_SUPPRESS_CROPMARKS where % if defined, xor in the suppression mask
{ pop DEC$EDMS_SUPPRESS_CROPMARKS xor } if def
mask 1 and 1 eq
{ PaperWidth PaperHeight moveto % Upper Right
450 0 rmoveto 1350 0 rlineto -1800 1800 rmoveto 0 -1350 rlineto } if
mask 2 and 2 eq
{ PaperWidth 0 moveto % Lower Right
450 0 rmoveto 1350 0 rlineto -1800 -1800 rmoveto 0 1350 rlineto } if
mask 4 and 4 eq
{ 0 0 moveto % Lower Left
-450 0 rmoveto -1350 0 rlineto 1800 -1800 rmoveto 0 1350 rlineto } if
mask 8 and 8 eq
{ 0 PaperHeight moveto % Upper Left
-450 0 rmoveto -1350 0 rlineto 1800 1800 rmoveto 0 -1350 rlineto } if
stroke
/mask 15 % all registration marks on by default
/DEC$EDMS_SUPPRESS_REGMARKS where % if defined, xor in the suppression mask
{ pop DEC$EDMS_SUPPRESS_REGMARKS xor } if def
mask 1 and 1 eq % Top Center
{ gsave PaperWidth 2 div PaperHeight
/DEC$EDMS_POSITION_REGMARKS where
{ pop DEC$EDMS_POSITION_REGMARKS -50 mul add } if
translate AlignMark grestore } if
mask 2 and 2 eq % Right Center
{ gsave PaperWidth
/DEC$EDMS_POSITION_REGMARKS where
{ pop DEC$EDMS_POSITION_REGMARKS -50 mul add } if
PaperHeight 2 div translate AlignMark grestore } if
mask 4 and 4 eq % Bottom Center
{ gsave PaperWidth 2 div 0
/DEC$EDMS_POSITION_REGMARKS where
{ pop DEC$EDMS_POSITION_REGMARKS 50 mul add } if
translate AlignMark grestore } if
mask 8 and 8 eq % Left Center
{ gsave 0
/DEC$EDMS_POSITION_REGMARKS where
{ pop DEC$EDMS_POSITION_REGMARKS 50 mul add } if
PaperHeight 2 div translate AlignMark grestore } if
showpage
}
{ erasepage } ifelse
}
{ showpage } ifelse
} def
/CLRP {erasepage} def
%
/DMF { % /font-name <point-size(pix)> DMF
/psz exch def /nam exch def nam findfont psz scalefont setfont
} def
%
/concatnam { % /abcd (xxx) concatnam ==> /abcdxxx
/xxx exch def /nam exch def
/namstr nam cvsstr cvs def
/newnam namstr length xxx length add string def
newnam 0 namstr putinterval
newnam namstr length xxx putinterval
newnam cvn
} def
%
/strip { % /abcdef 2 strip ==> /cdef
/num exch def /nam exch def
/namstr nam cvsstr cvs def
/newlen namstr length num sub def
namstr num newlen getinterval cvn
} def
% ROUTINES TO HANDLE PACKING/UNPACKING NUMBERS
/PackHW { % <target> <pos> <num> PackHW --> <new target>
/num exch def /pos exch def /target exch def
num 16#0000FFFF and 1 pos sub 16 mul bitshift target or
} def
/PackByte { % <target> <pos> <num> PackByte --> <new target>
/num exch def /pos exch def /target exch def
num 16#000000FF and 3 pos sub 8 mul bitshift target or
} def
/UnpkHW { % <pos> <num> UnpkHW --> <unpacked value>
/num exch def /pos exch def
num 1 pos sub -16 mul bitshift 16#0000FFFF and
dup 16#00007FFF gt {16#00010000 sub} if
} def
/UnpkByte { % <pos> <num> UnpkByte --> <unpacked value>
/num exch def /pos exch def
num 3 pos sub -8 mul bitshift 16#000000FF and
dup 16#0000007F gt {16#00000100 sub} if
} def
%
% FOR POSTSCRIPT FONTS, LOOK AT SIZE REQUESTED. IF IT HAS A DECIMAL REMAINDER
% EQUIVALENT TO .001-.009 POINTS (I.E., .050-.450 VAXDOC UNITS), THAT'S A FLAG
% TO STRETCH IT VERTICALLY BY ADDING 1-9 EXTRA POINTS TO THE VERTICAL SCALING.
%
/TESTING false def
%
/ps-scalefont {
% save requested size - as entered and as integer
dup /x-size exch def cvi /x-int exch def
% calc decimal remainder, mul x 1000, round
x-size x-int sub 1000 mul round cvi /remainder exch def
% see how we scale...
remainder 50 lt remainder 450 gt or {
% scale isomorphically
/ystretch 0 def
x-size scalefont
} {
% scale anamorphically
/ystretch remainder def
x-int ystretch add /y-size exch def
[x-int 0 0 y-size 0 0] makefont
} ifelse
%
TESTING {
(\nSIZE ) print x-size 12 string cvs print
(\tINT ) print x-int 12 string cvs print
( REM ) print remainder 12 string cvs print
( +Y ) print ystretch 12 string cvs print
( =\t) print
ystretch 0 eq {
x-size 12 string cvs print
( scalefont) print
} {
([) print x-int 12 string cvs print
( 0 0 ) print y-size 12 string cvs print
( 0 0] makefont) print
} ifelse
} if
} def
%
/DPSF { % /procname size /fontname DPSF
findfont exch ps-scalefont [ exch /setfont cvx ] cvx def
} def
%
/PXLBuildCharDict 17 dict def
/CMEncodingArray 256 array def
0 1 255 {CMEncodingArray exch dup cvsstr cvs cvn put} for
/RasterConvert {RasterScaleFactor div} def
/TransformBBox {
aload pop
/BB-ury exch def /BB-urx exch def /BB-lly exch def /BB-llx exch def
[ BB-llx RasterConvert BB-lly RasterConvert
BB-urx RasterConvert BB-ury RasterConvert ]
} def
/RunLengthToRasters {
% none yet
} def
/GenerateRasters { % GENERATE RASTERS FOR "IMAGEMASK"
rasters runlength 1 eq {RunLengthToRasters} if
} def
%
/int-dict-name {int (-dict) concatnam} def
/int-dict {int (-dict) concatnam cvx load} def
%
/DefinePXLFont {
% <int-font-name><ext-font-name><pt-sz(pix)><PXL mag><num-chars>...
% ...[llx lly urx ury]<newfont-fg>DefinePXLFont
/newfont exch def /bb exch def /num exch def /psz exch def
/dsz exch def /pxlmag exch def /ext exch def /int exch def
/fnam ext (-) concatnam pxlmag cvsstr cvs concatnam def
newfont not {
int-dict-name 13 dict def
int-dict begin
/FontType 3 def /FontMatrix [ 1 dsz div 0 0 1 dsz div 0 0 ] def
/FontBBox bb TransformBBox def /Encoding CMEncodingArray def
/CharDict 1 dict def CharDict begin /Char-Info num array def end
/BuildChar {
PXLBuildCharDict begin
/char exch def /fontdict exch def
fontdict /CharDict get /Char-Info get char get aload pop
/rasters exch def /PackedWord1 exch def
0 PackedWord1 UnpkHW 16#7FFF ne {
/PackedWord2 exch def /wx 0 PackedWord1 UnpkHW def
/rows 2 PackedWord1 UnpkByte def /cols 3 PackedWord1 UnpkByte def
/llx 0 PackedWord2 UnpkByte def /lly 1 PackedWord2 UnpkByte def
/urx 2 PackedWord2 UnpkByte def /ury 3 PackedWord2 UnpkByte def
}{ %else
/PackedWord2 exch def /PackedWord3 exch def /PackedWord4 exch def
/wx 1 PackedWord1 UnpkHW def /rows 0 PackedWord2 UnpkHW def
/cols 1 PackedWord2 UnpkHW def /llx 0 PackedWord3 UnpkHW def
/lly 1 PackedWord3 UnpkHW def /urx 0 PackedWord4 UnpkHW def
/ury 1 PackedWord4 UnpkHW def
} ifelse
rows 0 lt {
/rows rows neg def /runlength 1 def
}{ %else
/runlength 0 def
} ifelse
wx 0
llx RasterConvert lly RasterConvert
urx RasterConvert ury RasterConvert setcachedevice
rows 0 ne {
gsave
cols rows true RasterScaleFactor
0 0 RasterScaleFactor neg llx .5 add neg ury .5 add
tempmatrix astore GenerateRasters imagemask
grestore
} if
end
} def
end
fnam int-dict definefont pop
} if
int-dict-name fnam findfont psz scalefont def
currentdict int [ int-dict /setfont cvx ] cvx put
} def
/PXLF { true DefinePXLFont} def % SIGNAL THAT FONT IS ALREADY LOADED
/PXLNF {false DefinePXLFont} def % SIGNAL THAT FONT IS NOT ALREADY LOADED
%
/PXLC { % <int-font-name><code><wx><llx><lly><urx><ury>...
% ...<rows><cols><runlength><rasters>PXLC
/rasters exch def /runlength exch def /cols exch def /rows exch def
/ury exch def /urx exch def /lly exch def /llx exch def
/wx exch def /code exch def /int exch def
% SEE IF LONG OR SHORT FORMAT IS REQUIRED
true cols CKSZ rows CKSZ ury CKSZ urx CKSZ lly CKSZ llx CKSZ
TackRunLengthToRows {
int-dict /CharDict get /Char-Info get code
[ 0 0 llx PackByte 1 lly PackByte 2 urx PackByte 3 ury PackByte
0 0 wx PackHW 2 rows PackByte 3 cols PackByte rasters ] put
}{ %else
int-dict /CharDict get /Char-Info get code
[ 0 0 urx PackHW 1 ury PackHW 0 0 llx PackHW 1 lly PackHW
0 0 rows PackHW 1 cols PackHW 0 0 16#7FFF PackHW 1 wx PackHW rasters ] put
} ifelse
} def
%
/CKSZ {abs 127 le and} def
/TackRunLengthToRows {runlength 0 ne {/rows rows neg def} if} def
%
/PLOTC {
% <wx><dsz><psz><llx><lly><urx><ury><rows><cols><runlength><rasters>PLOTC
/rasters exch def /runlength exch def /cols exch def /rows exch def
/ury exch def /urx exch def /lly exch def /llx exch def
/psz exch def /dsz exch def /wx exch def
% "PLOT" A CHARACTER'S RASTER PATTERN
rows 0 ne {
gsave
currentpoint translate psz dsz div dup scale
cols rows true RasterScaleFactor 0 0 RasterScaleFactor
neg llx .5 add neg ury .5 add tempmatrix astore
GenerateRasters imagemask
grestore
} if
wx x
} def
%
/AlignMark
%
% This procedure draws an alignment mark centered on the coordinate system
% origin. If the variable DEC$EDMS_SEPARATE_COLORS = 0 then a "positive"
% alignment mark is drawn. If DEC$EDMS_SEPARATE_COLORS <> 0 then a "negative"
% alignment mark is drawn.
%
% Formal Arguments: NONE
%
% Referenced Variables: DEC$EDMS_SEPARATE_COLORS
%
% Referenced Procedures: NONE
%
% Side Effects: NONE
%
{ DEC$EDMS_SEPARATE_COLORS 0 eq
{ 0 0 300 0 360 arc
0 -450 moveto 0 450 lineto -450 0 moveto 450 0 lineto stroke }
{ 0 0 450 0 360 arc fill 1 setgray 0 0 300 0 360 arc
0 -450 moveto 0 450 lineto -450 0 moveto 450 0 lineto stroke 0 setgray }
ifelse
} def
/SC
% If not making film, the following procedure sets the current color using the
% RGB color model. If making film, the procedure notes the "color pass" and,
% if the specified color index matches the color pass, subsequent marks are
% written in black. If the specified color index does not match the color pass,
% marks are written in white. Use of colors on individual pages is also tracked
% to allow pages that don't use a particular color to be suppressed on that
% color pass (by the code in the /PP routine).
%
% Formal Arguments: color index (on stack)
%
% Referenced Variables: Colorsused
% DEC$EDMS_SEPARATE_COLORS
% DEC$EDMS_SUPPRESS_COLOR
%
% Referenced Procedures: NONE
%
% Side Effects: Modifies the variable Colorsused to record use of the color.
%
{ /DEC$EDMS_SUPPRESS_COLOR where % if suppressing color
{ pop 0 setgray pop } % .then set "color" to Black
{ /DEC$EDMS_SEPARATE_COLORS where % .else if separating colors
{ pop dup DEC$EDMS_SEPARATE_COLORS eq % ..and if on this color pass
{ 0 setgray /Colorsused Colorsused % ...then write black (do write)
2 3 index exp cvi or def } % ...and note use of the "color"
{ 1 setgray } ifelse pop } % ...else write white (don't write)
{ dup ( ) cvs dup length 15 add string % ..using the color index,
/tstr exch def % ..build up the name of the
tstr 0 (DEC$EDMS_COLOR_) putinterval % ..potential external color
tstr exch 15 exch putinterval % ..name procedure
tstr cvn where % ..and see if it is defined
{ pop pop tstr cvn cvx exec } % ...if it is, execute it
{ DEC$EDMS_COLOR_ARRAY exch get % ..else execute the internal
exec } ifelse % ..color setting procedure
} ifelse
} ifelse
} def
/RV % .. gross recto/verso translate
{ /DEC$EDMS_ENABLE_RECTOVERSO where
{ pop
/RVmatrix DEC$EDMS_ENABLE_RECTOVERSO 50 mul 0 matrix translate def
RVmatrix concat
} if
} def
end %DEC_DVC$dict
%%EndProlog
%%BeginSetup
/DEC$EDMS_MAKE_FILM where % if we are making film...
{ pop % ..clean up the stack
54 dup translate % ..make room for the film info
} if
BeginDVC$PSDoc
/PaperWidth 8.500 Resolution mul def
/PaperHeight 11.000 Resolution mul def
/Ymax PaperHeight def
CLRP 300 3600 RES
%> Postamble of file WORK1:[GEBURA.EATME]MUP-COVER.DVI_PS.
% DefineFont:F171 Category:15 Pointsize:14
% DownloadPSFont
%!PS-Adobe-2.0
%%Title: PostScript Digital Logo Font, v1.1
%%Creator: Ned Batchelder
%%CreationDate: 9-Nov-87
%%DocumentFonts: Symbol
%%DocumentSuppliedFonts: DigitalLogo
%%EndComments
%
% DIGITAL INTERNAL USE ONLY
%
% INTRODUCTION:
% This rendition of the Digital logo was prepared by Ned Batchelder using
% Adobe Illustrator and hand manipulation of the resulting PostScript code.
% Photographic masters of the logo were obtained from David Comberg in the
% Graphic Design Group. Additional consultation was provided by Elliot
% Hendrickson, one of the original designers of the logo.
%
% USE:
% This file defines a new PostScript font, called /DigitalLogo. It consists
% of three characters. (d) is the entire Digital logo, (t) is a small
% trademark symbol, and (T) is a large trademark symbol. The font is designed
% so that the argument to scalefont is the height of the logo. There is no
% extra white space around the logo at all. The trademarks are designed to be
% shown right after the logo, and they align themselves. The only correct
% strings to show with this font are (d), (dt), and (dT). There is an entry
% (named GapWidth) in the font dictionary which gives the unscaled width of
% the gap between the blocks. This distance is given because it is used as a
% unit to determine how much space to leave around the logo.
%
% HISTORY:
% The logo was designed in 1957 by Elliot Hendrickson, who was then working
% as an independent designer. He was contracted by DEC to do a brochure, and
% DEC wanted a logo to accompany it. The logo up to then had been the letters
% DEC in blocks the shape of the plug-in cards that DEC had been producing.
% Elliot re-worked the logo, incorporating letters which were hand-drawn for
% the purpose by Arthur Hover(?). The logo has been maintained since then in
% conventional technology, ie, film masters. There was at least one reworking
% of the logo at some point.
%
% The masters I received had a number of interesting features. The boxes were
% not all the same width, and there seemed to be no logic to which boxes were
% wider. The 'g' was the narrowest, and the 'i' and 'l' were second widest.
% Also, the two 'i's were not exactly the same shape. On ten-inch masters,
% (one box to an 8�x11 sheet), the boxes were not rectangles, but were very
% slightly tapered in wierd ways. I assume that the tapering is the result of
% too many reproductions, but the difference in widths may have been
% deliberate at some time. Elliot reports that when he drew it, all boxes
% were the same width. I have retained the different widths in my version,
% since the experts I had at hand did not seem to think I should make them
% uniform.
%
% Please feel free to use this logo, but keep in mind the following:
%
% 1. This code is for INTERNAL USE ONLY.
% 2. I am not entirely happy with the final shapes of the letters, and am
% hoping to improve them. Please allow for future updates to this code.
% 3. Only use this logo within the guidelines of the Corporate Identity
% program. If you use this font precisely as is, you can't get in much
% trouble. Don't take the shapes and do strange things with them.
% In particular, the Identity states that the logo is a one-color logo: The
% letters are actually holes in the blocks, through which the background can
% be seen. Do not modify this code so that the letters are always white.
%
% Edit history:
%
% 21-Sep-87 nmb Created as a standalone file with demo.
% 6-Nov-87 nmb Converted to font form.
% 9-Nov-87 nmb Removed // uses for compatibility with LW Classics
%
%%BeginFont: DigitalLogo
10 dict begin
/FontInfo 3 dict def
FontInfo begin
/Notice
(The Digital logo is a registered trademark of Digital Equipment Corporation.)
def
/FullName (Digital logo) def
/version (1.1) def
end
/FontType 3 def % This is a user-defined font
/FontMatrix matrix def % Use an identity transform
/FontBBox [ 0 0 3.383 1 ] def % Logo itself is biggest
/GapWidth .070 def % The width of the gap between boxes
/Encoding 256 array def
0 1 255 { Encoding exch /.notdef put } bind for
Encoding
dup (d) 0 get /DEC-logo put % (d) gives logo
dup (t) 0 get /smalltrademark put % (t) gives small trademark
(T) 0 get /largetrademark put % (T) gives large trademark
/Work 15 dict def % for doing work in font.
/BuildChar {
exch begin % Use the font dictionary
Work begin
Encoding exch get % Look up the character name
load % Pull out the procedure
exec % Run it.
end % Work
end % fontdict
} bind def
Work begin
/.notdef {} def
%
% - `DEC-logo' -
%
% Images a DEC logo with the lower left corner at the current origin, with a
% height of one unit, in the current color.
%
/m /moveto load def
/l /lineto load def
/c /curveto load def
/DEC-logo {
3.383 0 0 0 3.383 1 setcachedevice
{ % D
% d counter
.2930 .3513 m
.2932 .3217 .2587 .2758 .2167 .2757 c
.1719 .2759 .1280 .3165 .1280 .3977 c
.1280 .4801 .1718 .5225 .2153 .5227 c
.2587 .5225 .2932 .4760 .2930 .4407 c
closepath
% d outside
.2953 .5787 m
.2953 .7600 l
.3843 .7600 l
.3843 .1960 l
.2923 .1960 l
.2923 .2220 l
.2848 .2144 .2531 .1813 .1990 .1813 c
.1426 .1812 .0417 .2282 .0417 .3977 c
.0417 .5414 .1171 .6157 .2067 .6157 c
.2399 .6157 .2725 .6039 .2953 .5787 c
closepath
% d box
.432 0.0 m
.432 1.0 l
.000 1.0 l
.000 0.0 l
closepath
} exec
{ % I
% i box
.927 0.0 m
.927 1.0 l
.502 1.0 l
.502 0.0 l
closepath
% i body
.6695 .196 m
.6695 .600 l
.7595 .600 l
.7595 .196 l
closepath
% i dot
.6695 .655 m
.6695 .755 l
.7595 .755 l
.7595 .655 l
closepath
} exec
{ % G
% g counter
1.2813 .4478 m
1.2813 .4837 1.2409 .5208 1.2035 .5208 c
1.1713 .5208 1.1215 .5003 1.1215 .4084 c
1.1215 .3105 1.1827 .2962 1.2030 .2962 c
1.2433 .2962 1.2813 .3239 1.2813 .3667 c
closepath
% g box
0.997 1.0 m
1.415 1.0 l
1.415 0.0 l
0.997 0.0 l
closepath
% g outside
1.2822 .5609 m
1.2729 .5742 1.2424 .6044 1.1988 .6044 c
1.1311 .6043 1.0367 .5652 1.0367 .3955 c
1.0368 .2617 1.1437 .2168 1.1876 .2168 c
1.2350 .2167 1.2702 .2443 1.2798 .2547 c
1.2798 .2126 l
1.2798 .1815 1.2479 .1511 1.1945 .1511 c
1.1485 .1512 1.1437 .1807 1.1437 .1953 c
1.0497 .1953 l
1.0497 .1486 1.0798 .0804 1.1888 .0803 c
1.2864 .0803 1.3186 .1176 1.3325 .1316 c
1.3442 .1434 1.3617 .1758 1.3617 .2017 c
1.3617 .6 l
1.2823 .6 l
closepath
} exec
{ % I
% i box
1.910 0.0 m
1.910 1.0 l
1.485 1.0 l
1.485 0.0 l
closepath
% i body
1.6525 .196 m
1.6525 .6 l
1.7425 .6 l
1.7425 .196 l
closepath
% i dot
1.6525 .655 m
1.6525 .755 l
1.7425 .755 l
1.7425 .655 l
closepath
} exec
{ % T
% t
2.2128 .7525 m
2.1305 .7525 l
2.1305 .6071 l
2.0874 .6071 l
2.0874 .5396 l
2.1305 .5396 l
2.1305 .2852 l
2.1305 .2367 2.1554 .1986 2.2248 .1987 c
2.2573 .1987 2.2560 .1985 2.2842 .2034 c
2.2842 .2874 l
2.2658 .2842 2.2601 .2829 2.2511 .2832 c
2.2338 .2837 2.2128 .2898 2.2128 .3206 c
2.2128 .5395 l
2.2780 .5395 l
2.2780 .6071 l
2.2128 .6071 l
closepath
% t box
2.404 0.0 m
1.980 0.0 l
1.980 1.0 l
2.404 1.0 l
closepath
} exec
{ % A
% a box
2.474 0.0 m
2.474 1.0 l
2.888 1.0 l
2.888 0.0 l
closepath
% a outside
2.5439 .4728 m
2.6210 .4728 l
2.6210 .5138 2.6422 .5353 2.6826 .5353 c
2.7470 .5354 2.7449 .5067 2.7448 .4708 c
2.7050 .4553 2.7087 .4557 2.6480 .4419 c
2.5709 .4241 2.5237 .3911 2.5236 .3112 c
2.5237 .2331 2.5793 .1914 2.6420 .1915 c
2.7048 .1914 2.7178 .2117 2.7438 .2290 c
2.7438 .1978 l
2.8422 .1978 l
2.8190 .2352 2.8251 .2425 2.8249 .2706 c
2.8250 .2926 2.8249 .5080 2.8249 .5080 c
2.8250 .5507 2.8028 .5768 2.7883 .5855 c
2.7521 .6071 2.7074 .6097 2.6826 .6098 c
2.5945 .6096 2.5438 .5653 2.5439 .4728 c
closepath
% a counter
2.7448 .3946 m
2.7448 .3401 l
2.7448 .3152 2.7145 .2670 2.6550 .2669 c
2.6260 .2668 2.6098 .2883 2.6097 .3162 c
2.6098 .3442 2.6335 .3657 2.6536 .3697 c
2.6745 .3739 2.7226 .3862 2.7448 .3946 c
closepath
} exec
{ % L
% l box
3.383 0.0 m
3.383 1.0 l
2.958 1.0 l
2.958 0.0 l
closepath
% l
3.1255 .196 m
3.1255 .765 l
3.2155 .765 l
3.2155 .196 l
closepath
} exec
fill
} bind def
%
% % pct `trademark' --
%
% Borrow the sans-serif trademark symbol from /Symbol. AFM file says:
% C 228 ; WX 786 ; N trademarksans ; B 5 293 725 673 ;
% We scale it down to pct percent of the height of the logo and superscript
% it some, and voila!
%
/trademark {
/s exch .380 div def
/w s .725 mul .070 add def
/u 1 .673 s mul sub def
w 0 0 u w 1 setcachedevice
/Symbol findfont s scalefont setfont
.070 u m % Superscript it
(\344) show
} bind def
%
% These are two different trademarks (just different sizes).
%
/smalltrademark { .15 trademark } def
/largetrademark { .25 trademark } def
end % Work dictionary
currentdict % Get the font dict
end % Close it up
/DigitalLogo exch definefont pop % Define the font.
%%EndFont
% EndDownloadPSFont
/F171 700.0 /DigitalLogo DPSF
% DefineFont:F159 Category:10 Pointsize:8
/NewCenturySchlbk-Roman /NewCenturySchlbk-Roman@DOCPSE DOCPSE ReENCODE
/F159 400.0 /NewCenturySchlbk-Roman@DOCPSE DPSF
% DefineFont:F153 Category:10 Pointsize:10
/NewCenturySchlbk-Bold /NewCenturySchlbk-Bold@DOCPSE DOCPSE ReENCODE
/F153 500.0 /NewCenturySchlbk-Bold@DOCPSE DPSF
% DefineFont:F152 Category:10 Pointsize:10
/NewCenturySchlbk-Italic /NewCenturySchlbk-Italic@DOCPSE DOCPSE ReENCODE
/F152 500.0 /NewCenturySchlbk-Italic@DOCPSE DPSF
% DefineFont:F151 Category:10 Pointsize:10
/F151 500.0 /NewCenturySchlbk-Roman@DOCPSE DPSF
% DefineFont:F98 Category:10 Pointsize:9
/Courier /Courier@DOCPSE DOCPSE ReENCODE
/F98 450.0 /Courier@DOCPSE DPSF
% DefineFont:F36 Category:10 Pointsize:10
/Helvetica-Bold /Helvetica-Bold@DOCPSE DOCPSE ReENCODE
/F36 500.0 /Helvetica-Bold@DOCPSE DPSF
% DefineFont:F34 Category:10 Pointsize:10
/Helvetica /Helvetica@DOCPSE DOCPSE ReENCODE
/F34 500.0 /Helvetica@DOCPSE DPSF
% DefineFont:F32 Category:10 Pointsize:11
/F32 550.0 /Helvetica-Bold@DOCPSE DPSF
% DefineFont:F29 Category:10 Pointsize:12
/Helvetica-BoldOblique /Helvetica-BoldOblique@DOCPSE DOCPSE ReENCODE
/F29 600.0 /Helvetica-BoldOblique@DOCPSE DPSF
%%BeginDEC$EDMSInfo
/DEC$EDMS_DOCUMENT_ID () def
/DEC$EDMS_COLOR_NAMES [ (BLACK) (BLACK) (BLACK) (BLACK) ] def
/DEC$EDMS_COLOR_ARRAY [
{ 0 setgray } %color 0 procedure
{ 0 setgray } %color 1 procedure
{ 0 setgray } %color 2 procedure
{ 0 setgray } %color 3 procedure
] def
/DEC$EDMS_TOTAL_PAGES 0 def
%%EndDEC$EDMSInfo
/DEC$EDMS_MAKE_FILM where
{ pop /DEC$EDMS_SEPARATE_COLORS where
{ pop }
{ (ERROR - DEC$EDMS_MAKE_FILM requires DEC$EDMS_SEPARATE_COLORS be defined) = quit } ifelse
} if
/DEC$EDMS_SEPARATE_COLORS where
{ pop /DEC$EDMS_SUPPRESS_COLOR where
{ pop (ERROR - DEC$EDMS_SEPARATE_COLORS and DEC$EDMS_SUPPRESS_COLOR are mutually exclusive) = quit } if
DEC$EDMS_SEPARATE_COLORS 1 gt { (ERROR - No such color used in this file) = quit } if
} if
/DVC$PSFonts save def
%%EndSetup
%
%%Page: 1 1
%%BeginPageSetup
%%EndPageSetup
%%PageFonts: (atend)
%%PageCustomColors: (atend)
1000 BP PaperHeight PaperWidth PM 0 0 XY
%%BeginCustomColor: 0
0 SC 3899 4297 XY F171(dt)S 3899 5792 XY F29(Cover)S 199 x(Letter)S
200 x(for)S 199 x(VMS)S 199 x(V)S -23 x(ersion)S 200 x(5.4-0)S 2 x(A)S
198 x(Update)S 3899 X 896 y F36(A)S -37 x(V)S -27 x(\203PEW3A\203TE)S
3899 9279 XY F151(The)S 193 x(VMS)S 192 x(V)S -46 x(ersion)S 192 x(5.4-0A)S
193 x(Update)S 192 x(contains)S 192 x(necessary)S 193 x(software)S 192 x
(enhancements)S 193 x(for)S 192 x(the)S 193 x(V)S -56 x(AX)S 192 x(9000)S
192 x(and)S 3899 X 597 y(the)S 141 x(V)S -55 x(AX)S 141 x(6000\203500)S
141 x(series)S 140 x(of)S 142 x(computers.)S 213 x(If)S 141 x(you)S
143 x(have)S 142 x(a)S 141 x(V)S -55 x(AX)S 140 x(9000)S 142 x(or)S
141 x(V)S -55 x(AX)S 140 x(6000\203500)S 141 x(computer)S -36 x(,)S
147 x(you)S 142 x(need)S 3899 X 598 y(to)S 164 x(apply)S 165 x(the)S
164 x(VMS)S 164 x(V5.4-0A)S 164 x(Update)S 164 x(after)S 164 x(installing)S
165 x(or)S 165 x(upgrading)S 165 x(to)S 165 x(V)S -47 x(ersion)S 165 x
(5.4)S 165 x(of)S 164 x(the)S 165 x(VMS)S 164 x(operating)S 3899 X 598 y
(system.)S 221 x(Follow)S 166 x(these)S 166 x(instructions:)S 3899 X
897 y F36(1.)S 631 x F151(If)S 183 x(you)S 183 x(are)S 184 x(installing)S
183 x(VMS)S 182 x(V)S -46 x(ersion)S 183 x(5.4,)S 188 x(follow)S 183 x
(the)S 183 x(instructions)S 183 x(in)S 183 x(Chapter)S 183 x(3)S 183 x
(of)S 183 x(the)S 183 x F152(VMS)S 183 x(V)S -64 x(ersion)S 4945 X 597 y
(5.4)S 166 x(Upgrade)S 167 x(and)S 167 x(Installation)S 167 x(Manual)S
F151(.)S 4945 X 897 y(If)S 117 x(you)S 118 x(are)S 117 x(upgrading)S
119 x(to)S 117 x(VMS)S 116 x(V)S -46 x(ersion)S 118 x(5.4,)S 127 x(follow)S
117 x(the)S 117 x(instructions)S 117 x(in)S 118 x(Chapter)S 117 x(8)S
117 x(of)S 117 x(the)S 117 x F152(VMS)S 117 x(Upgrade)S 4945 X 598 y
(and)S 167 x(Installation)S 167 x(Manual)S F151(.)S 3899 X 896 y F36
(2.)S 631 x F151(After)S 173 x(the)S 173 x(installation)S 173 x(or)S
173 x(upgrade,)S 177 x(boot)S 173 x(the)S 173 x(system)S 173 x(\(if)S
173 x(it)S 173 x(did)S 173 x(not)S 173 x(boot)S 173 x(automatically\))S
173 x(and)S 174 x(log)S 173 x(into)S 4945 X 598 y(the)S 166 x(SYSTEM)S
166 x(account.)S 222 x(For)S 167 x(example:)S 7336 X 747 y F98(Welcome)S
269 x(to)S 269 x(VAX/VMS)S 269 x(V5.4)S 5991 17299 XY(Username:)S
%%EndCustomColor: 0
%%BeginCustomColor: 1
1 SC 468 x(SYSTEM)S
%%EndCustomColor: 1
%%BeginCustomColor: 0
0 SC 5991 X 498 y(Password:)S 3899 X 896 y F36(3.)S 631 x F151(Place)S
238 x(the)S 238 x(tape)S 238 x(cartridge,)S 256 x(compact)S 238 x(disc,)S
256 x(or)S 238 x(magnetic)S 238 x(tape)S 238 x(labeled)S 237 x(`)S -9 x
(`)S(V)S -51 x(AX/VMS)S 238 x(V5.4-0A')S -10 x(')S 237 x(in)S 238 x
(the)S 4945 X 598 y(appropriate)S 194 x(drive.)S 307 x(Substituting)S
194 x(the)S 194 x(name)S 195 x(of)S 194 x(the)S 194 x(drive)S 195 x
(that)S 194 x(contains)S 194 x(the)S 194 x(VMS)S 194 x(V5.4-0A)S 194 x
(Update)S 4945 X 598 y(for)S 166 x F152(device-name)S F151(,)S 167 x
(type)S 166 x(the)S 167 x(following)S 166 x(and)S 166 x(press)S 166 x
(Return:)S 5991 X 747 y F98($)S
%%EndCustomColor: 0
%%BeginCustomColor: 1
1 SC 418 x(@SYS$UPDATE:VMSINSTAL)S 269 x(VMSMUPA054)S 269 x(device-name:)S
%%EndCustomColor: 1
%%BeginCustomColor: 0
0 SC 3899 X 897 y F36(4.)S 631 x F151(The)S 167 x(procedure)S 167 x
(displays)S 165 x(a)S 166 x(series)S 166 x(of)S 166 x(messages)S 165 x
(and)S 166 x(asks)S 166 x(you)S 167 x(some)S 166 x(questions.)S 221 x
(For)S 167 x(example:)S 7336 X 747 y F98(VAX/VMS)S 269 x(Software)S
269 x(Product)S 269 x(Installation)S 269 x(Procedure)S 269 x(V5.4)S
5991 23276 XY(It)S 269 x(is)S 269 x(1-OCT-1990)S 269 x(at)S 269 x(9:00)S
5991 X 498 y(Enter)S 269 x(a)S 269 x(question)S 269 x(mark)S 269 x(\(?\))S
269 x(at)S 269 x(any)S 269 x(time)S 269 x(for)S 269 x(help.)S 5991 X
498 y(*)S 269 x(Are)S 269 x(you)S 269 x(satisfied)S 269 x(with)S 269 x
(the)S 269 x(backup)S 269 x(of)S 269 x(your)S 269 x(system)S 269 x(disk)S
269 x([YES]?)S
%%EndCustomColor: 0
%%BeginCustomColor: 1
1 SC 418 x(Y)S
%%EndCustomColor: 1
%%BeginCustomColor: 0
0 SC 5991 25269 XY(Please)S 269 x(mount)S 269 x(the)S 269 x(first)S
269 x(volume)S 269 x(of)S 269 x(the)S 269 x(set)S 269 x(on)S 269 x(MUA0:.)S
5991 X 498 y(*Are)S 269 x(you)S 269 x(ready?)S
%%EndCustomColor: 0
%%BeginCustomColor: 1
1 SC 468 x(Y)S
%%EndCustomColor: 1
%%BeginCustomColor: 0
0 SC 5991 X 498 y(%MOUNT-I-MOUNTED,)S 269 x(VMSMUP)S 269 x(mounted)S
269 x(on)S 269 x(_MUA0:)S 5991 X 797 y(The)S 269 x(following)S 269 x
(products)S 269 x(will)S 269 x(be)S 269 x(processed:)S 6798 X 797 y
(VMSMUPA)S 269 x(V5.4)S 8143 X 797 y(Beginning)S 269 x(installation)S
269 x(of)S 269 x(VMSMUPA)S 269 x(V5.4)S 269 x(at)S 269 x(9:00)S 5991 X
797 y(%VMSINSTAL-I-RESTORE,)S 269 x(Restoring)S 269 x(product)S 269 x
(save)S 269 x(set)S 269 x(A)S 269 x(...)S 8143 X 797 y(.)S -269 x 498 y
(.)S -269 x 498 y(.)S -269 x 498 y(Now)S 269 x(applying)S 269 x(the)S
269 x(VMS)S 269 x(V5.4-0A)S 269 x(updates...)S 8143 X 499 y(.)S -269 x
498 y(.)S -269 x 498 y(.)S -269 x 498 y(Installation)S 269 x(of)S 269 x
(VMSMUPA)S 269 x(V5.4)S 269 x(completed)S 269 x(at)S 269 x(9:05)S 5991 X
797 y(%VMSINSTAL-I-SHUTDOWN,)S 269 x(This)S 269 x(product)S 269 x(requires)S
269 x(that)S 269 x(the)S 269 x(system)S 268 x(be)S 269 x(rebooted.)S
%%EndCustomColor: 0
1 PP EP
%%PageTrailer
%%PageFonts: DigitalLogo Helvetica-BoldOblique
%%+ Helvetica-Bold NewCenturySchlbk-Roman
%%+ NewCenturySchlbk-Italic Courier
%%PageCustomColors: 0 1
%
%%Page: 2 2
%%BeginPageSetup
%%EndPageSetup
%%PageFonts: (atend)
%%PageCustomColors: (atend)
1000 BP PaperHeight PaperWidth PM 0 0 XY
%%BeginCustomColor: 0
0 SC 3899 3969 XY F36(5.)S 631 x F151(After)S 153 x(you)S 154 x(apply)S
153 x(the)S 154 x(VMS)S 152 x(V5.4-0A)S 153 x(Update,)S 156 x(complete)S
153 x(your)S 154 x(upgrade)S 154 x(or)S 154 x(installation)S 152 x(as)S
153 x(described)S 153 x(in)S 4945 X 598 y(the)S 166 x F152(VMS)S 166 x
(V)S -64 x(ersion)S 167 x(5.4)S 166 x(Upgrade)S 167 x(and)S 167 x(Installation)S
167 x(Manual)S F151(.)S 3899 5763 XY F32(Releas)S -2 x(e)S 183 x(Notes)S
3899 X 797 y F151(When)S 186 x(you)S 186 x(boot)S 186 x(standalone)S
185 x(BACKUP)S 185 x(on)S 186 x(a)S 185 x(V)S -55 x(AX)S 185 x(6000)S
185 x(or)S 186 x(9000)S 185 x(series)S 185 x(system)S 185 x(with)S 186 x
(512Mb)S 185 x(of)S 186 x(memory)S -55 x(,)S 3899 X 597 y(you)S 190 x
(must)S 189 x(perform)S 189 x(a)S 189 x(conversational)S 190 x(boot)S
189 x(and)S 190 x(change)S 190 x(the)S 190 x(SYSGE)S -2 x(N)S 189 x
(parameter)S 189 x(PHYSICALP)S -37 x(AGES)S 188 x(to)S 3899 X 598 y
(1047552)S 166 x(\(less)S 165 x(than)S 166 x(512Mb\).)S 222 x(For)S
167 x(example:)S 4945 X 747 y F98(>>>)S
%%EndCustomColor: 0
%%BeginCustomColor: 1
1 SC 418 x(B/R5:1)S 269 x(du0)S
%%EndCustomColor: 1
%%BeginCustomColor: 0
0 SC 4945 X 498 y(SYSBOOT>)S
%%EndCustomColor: 0
%%BeginCustomColor: 1
1 SC 418 x(SET)S 269 x(PHYSICALPAGES)S 269 x(1047552)S
%%EndCustomColor: 1
%%BeginCustomColor: 0
0 SC 4945 X 499 y(SYSBOOT>)S
%%EndCustomColor: 0
%%BeginCustomColor: 1
1 SC 418 x(CONTINUE)S
%%EndCustomColor: 1
%%BeginCustomColor: 0
0 SC 3899 10495 XY F151(This)S 166 x(will)S 165 x(be)S 166 x(\211xed)S
167 x(in)S 167 x(a)S 166 x(future)S 166 x(release)S 166 x(of)S 166 x
(VMS.)S 3899 11491 XY(After)S 149 x(your)S 151 x(system)S 150 x(is)S
149 x(up)S 150 x(and)S 150 x(runnin)S 2 x(g,)S 154 x(you)S 151 x(can)S
150 x(use)S 150 x(SYSGE)S -2 x(N)S 150 x(to)S 150 x(change)S 151 x(PHYSICALP)S
-37 x(AGE)S -2 x(S)S 150 x(to)S 150 x(1047552)S 3899 X 598 y(to)S 166 x
(avoid)S 166 x(stopping)S 166 x(in)S 167 x(SYSBO)S -2 x(OT)S 166 x(during)S
167 x(each)S 167 x(reboot.)S 222 x(For)S 166 x(example:)S 4945 X 747 y
F98($)S
%%EndCustomColor: 0
%%BeginCustomColor: 1
1 SC 418 x(RUN)S 269 x(SYS$SYSTEM:SYSGEN)S
%%EndCustomColor: 1
%%BeginCustomColor: 0
0 SC 4945 X 498 y(SYSGEN>)S
%%EndCustomColor: 0
%%BeginCustomColor: 1
1 SC 418 x(USE)S 269 x(CURRENT)S
%%EndCustomColor: 1
%%BeginCustomColor: 0
0 SC 4945 X 498 y(SYSGEN>)S
%%EndCustomColor: 0
%%BeginCustomColor: 1
1 SC 418 x(SET)S 269 x(PHYSICALPAGES)S 269 x(1047552)S
%%EndCustomColor: 1
%%BeginCustomColor: 0
0 SC 4945 X 499 y(SYSGEN>)S
%%EndCustomColor: 0
%%BeginCustomColor: 1
1 SC 418 x(WRITE)S 269 x(CURRENT)S
%%EndCustomColor: 1
%%BeginCustomColor: 0
0 SC 4945 X 498 y(SYSGEN>)S
%%EndCustomColor: 0
%%BeginCustomColor: 1
1 SC 418 x(EXIT)S
%%EndCustomColor: 1
%%BeginCustomColor: 0
0 SC 3899 15825 XY F151(T)S -46 x(o)S 162 x(make)S 162 x(this)S 161 x
(permanent,)S 163 x(add)S 162 x(this)S 161 x(value)S 162 x(to)S 161 x
(your)S 163 x(\211le,)S 163 x(SYS$SYSTEM:MODP)S -38 x(ARAMS.DA)S -29 x
(T)S -45 x(.)S 162 x(AUTOGE)S -2 x(N)S 3899 X 598 y(refers)S 166 x(to)S
166 x(this)S 166 x(\211le)S 166 x(to)S 166 x(con\211gu)S 2 x(re)S 166 x
(the)S 166 x(system.)S 14771 17419 XY F153(NOTE)S 4796 X 897 y(Please)S
166 x(note)S 167 x(that)S 167 x(the)S 166 x(V)S -45 x(AX)S 165 x(6000-500)S
166 x(series)S 166 x(does)S 166 x(not)S 167 x(support)S 167 x(the)S
167 x(CIBC)S -2 x(A-A.)S 8543 34745 XY F36(\251)S 150 x(Digital)S 167 x
(Equip)S 2 x(ment)S 166 x(Corporation.)S 223 x(1990.)S 222 x(All)S 166 x
(rights)S 167 x(reserved.)S 3899 X 577 y 6996 24 R 3899 35857 XY F159
(\207)S 199 x(The)S 133 x(following)S 132 x(are)S 133 x(trademarks)S
132 x(of)S 133 x(Digita)S -2 x(l)S 133 x(Equipment)S 132 x(Corporation:)S
177 x(V)S -44 x(AX,)S 131 x(VMS,)S 133 x(and)S 133 x(the)S 133 x(DIGIT)S
-21 x(AL)S 132 x(Logo.)S 15417 37573 XY F34(2)S
%%EndCustomColor: 0
2 PP EP
%%PageTrailer
%%PageFonts: Helvetica-Bold NewCenturySchlbk-Roman
%%+ NewCenturySchlbk-Italic Courier NewCenturySchlbk-Bold
%%+ Helvetica
%%PageCustomColors: 0 1
%
%%Trailer
EndDVC$PSDoc
/DEC$EDMS_MAKE_FILM where % if we are making film...
{ pop % ..clean up the stack
-54 dup translate % ..undo the film translation
} if
%%Pages: 2
%%DocumentFonts: DigitalLogo NewCenturySchlbk-Roman
%%+ NewCenturySchlbk-Bold NewCenturySchlbk-Italic
%%+ Courier Helvetica-Bold Helvetica Helvetica-BoldOblique
%%DocumentCustomColors: 0 1
|
| 78.54 | | KERNEL::WRIGHTON | odd numbered release = bug insert | Tue Oct 02 1990 00:50 | 56 |
|
The new version of SDU for VMS is now available in our public area at:
MRCSSE::PUBLIC:SDU_V.EXE;100
MRCSSE::PUBLIC:SYSMSG.EXE;100
There are many new enhancements, the major ones being:
- Pseudo register support;
- Examine/symbol={signal.label}
- Set Scope;
- Show Snap (tells you current snap file name)
- plus bug fixes and better messaging.
I have not updated PUBLIC:SDU_HELP.TXT with this new info, but will.
Please start using this new rev immediately. Don't forget to copy the
message file as well as the SDU image.
Some short term help on how to build pseduo regs:
Pseudo registers
- Pseudo register definition files look like this:
SYNTAX: define <register-name> <signal-name> [,<signal-name>] ;
ex:
define FOO ! U P P E R C A S E !!!
BAR, !signal 1
FOOBAR<10:0>; !signal 2
- To load a pseudo register definition file:
sdu> load /register foodef.sdf ! default extension is .SDF
- To examine a register:
sdu> examine /register foo !lower case ok, here
also:
sdu> examine /register foo<1:0>
also:
sdu> examine /reg /sym:check_foo foo
Note the big rub: There is currently no way to see
what registers are currently defined, so you have to
keep track of what you define and load. We'll try to
get a SHOW REG command put in.
Ok, never mind the small potatoes, now we can do
creative command files that "buzz out" a snapshot
file in seconds.
(above from mr. leitz)
|
| 78.55 | rude comments about FORTRAN courtesy C.Loane | KERNEL::WRIGHTON | odd numbered release = bug insert | Wed Oct 03 1990 05:49 | 98 |
|
The attached is the official description of a problem that exitst
between fortran (vector or not) and VMS 5.4. We have seen the same problem
throughout the developement of 5.4. They always fix it and then get it
wrong again on the next release.
You may want to send this to engineers who may visit customer
sites.
================================================================================
Note 609.6 FORTRAN RTL images problem on V5.4 6 of 6
QUARK::LIONEL "Free advice is worth every cent" 83 lines 21-SEP-1990 12:08
-< STARS article >-
--------------------------------------------------------------------------------
[This is a corrected version of an earlier posting.]
Attached is a STARS article that will soon be made available
to customers. It describes a problem with linking FORTRAN
programs on newly installed "from scratch" VMS V5.4 systems.
Please distribute this information to any affected users and
customers.
This problem will be "fixed" in the next maintenance update of
VMS, but the solution given in the article can be applied
immediately without interfering with the later VMS fix.
Steve
**********************************************************************
TITLE: LINK-I-DATMISMCH on FORTRAN RTL After Installing VMS V5.4
COMPONENT: Linker Utility OP/SYS: VMS, Version 5.4
LAST TECHNICAL REVIEW: 20-SEP-1990
SOURCE: Customer Support Center/Colorado Springs USA
\ Information in this article was extracted from the
\ VMS_FIELD_TESTS conference, topic 609, entered by
\ Steve Lionel.
SYMPTOM:
After doing an initial installation of VMS V5.4, the FORRTL and
FORRTL2 shareable images are not consistent with what was
inserted into the IMAGELIB.OLB on the kit.
Running the Installation Verification Procedure (IVP) after
installing FORTRAN or VAX FORTRAN-HPO will produce the following
messages:
%LINK-I-DATMISMCH, creation date of 16-JUL-1990 09:47 in
shareable image SYS$COMMON:[SYSLIB]FORRTL.EXE;1
differs from date of 19-JUN-1990 04:43 in shareable
image library SYS$COMMON:[SYSLIB]IMAGELIB.OLB;1
%LINK-I-DATMISMCH, creation date of 16-JUL-1990 09:48 in
shareable image SYS$COMMON:[SYSLIB]FORRTL2.EXE;1
differs from date of 19-JUN-1990 04:44 in shareable
image library SYS$COMMON:[SYSLIB]IMAGELIB.OLB;1
Linking any FORTRAN program will produce these messages.
Programs written in other languages may also include references
to the FORTRAN RTL, and linking those programs will produce the
messages as well.
ANALYSIS:
This behavior only occurs after an initial installation of VMS
V5.4. It does not occur when upgrading to VMS V5.4.
These are informational diagnostic messages, and does not effect
the image being linked.
WORKAROUND:
Replace FORRTL.EXE and FORRTL2.EXE in the IMAGELIB.OLB with the
command:
$ LIBRARY/SHARE/REPLACE SYS$LIBRARY:IMAGELIB SYS$LIBRARY:FORRTL,FORRTL2
NOTE:
If another process has the library open (for example, during a
link operation), you may see errors indicating that the library
file is in use. Wait until this other process is through
linking, and retry the replace operation.
DIGITAL RESPONSE:
This issue has been reported to VMS Engineering.
\\ LINK VER_5.4_VMS
\\ FT
|
| 78.56 | problems with CTMV MCU and BI devices | KERNEL::WRIGHTON | odd numbered release = bug insert | Wed Oct 03 1990 05:50 | 58 |
|
As you know, the VAX 9000 CPU has a bug in the CTMV MCA which is exacerbated
by the presence of BI devices in a configuration. Gary Shepard's recent
memo describes the problem in detail.
A permanent fix is forthcoming in kernel rev B5, and will involve replacing the
MCU containing this MCA (CTU).
As a temporary work-around, the device drivers most likely to encounter this
bug have been modified, and supplied to BTO Manufacturing. (This is not a
100% fix; problems should be escalated via CSSE, and the actions in Gary's
memo followed.)
Manufacturing(Jeff Brasssord) owns distribution of these drivers with new
shipments which contain KDB50, DMB32, and/or DSB32 options.
CSSE (Butch Leitz) owns supplying these drivers (and any necessary updates)
to BI customers shipped without them. CSSE also owns involving the CSCs as
required. In the very rare instances where the symptoms are seen on KDM70
systems, CSSE will distribute PUDRIVER after ascertaining that the root cause
is this bug.
[Note, the following have been placed in MRCSSE::PUBLIC: - butch]
Directory NONAME:[PUBLIC]
LIDRIVER.EXE;4 7 2-OCT-1990 09:27:50.34 (R,RWED,R,)
PUDRIVER.EXE;2 24 2-OCT-1990 09:27:50.46 (R,RWED,R,)
SIDRIVER.EXE;5 50 2-OCT-1990 09:27:50.60 (R,RWED,R,)
YIDRIVER.EXE;7 7 2-OCT-1990 09:27:50.86 (R,RWED,R,)
Everyone distributing these drivers MUST keep track of where they go, as they
will need to be removed following the installation of the new CTU. Also,
because we need to be able to distribute updates.
Because this is NOT a bug in the software, the responsible Engineering group
for these changes is NOT the communications group in Reading, England. Rather,
the modifications(but not the drivers per-se) will be supported thru VAX 9000
Engineering. (Tim Litt)
The symptoms can be subtle, and the work-arounds are not 100% effective. We
WANT to hear about problems; do not heasitate to elevate problems.
To Distribution List:
Rory O'DONNELL@UVO,
Dave WRIGHTON@UVO,
Andreas KAEMPFE@SUF,
Thomas RATSCH@MGO,
Gerd GABRYS@COO,
Roberto VERCELLI@TNO,
Maurizio MORRONE@RIO,
Walter GROSSI@MIO,
Daniel GONON@GVO,
MEIR ALON@ISO,
YUVAL Ashkenazi@ISH
|
| 78.57 | installing new SPU S/W | KERNEL::WRIGHTON | odd numbered release = bug insert | Fri Oct 05 1990 01:28 | 139 |
|
+---------------------------+ TM
! ! ! ! ! ! ! ! i n t e r o f f i c e
! d ! i ! g ! i ! t ! a ! l !
! ! ! ! ! ! ! ! m e m o r a n d u m
+---------------------------+
Date: 10/3/90
To: (VAX 9000 DISTRIBUTION) From: Butch Leitz
Dept: HPS/C CSSE MEG
DTN: 297-4257
LOC/MAIL STOP: MRO2-3/5E, Pole 2C
Email: HPSMEG::LEITZ
cc:
Subject: INSTALLATION INSTRUCTIONS FOR VAX 9000 SPU SOFTWARE
The following instructions are similar to what should be in the
Customer Service kit (QZ-K23AA-FW) for the VAX 9000 SPU
updates. You can use these instructions for installing the
first two tapes received in the Customer update kit
(QZ-K23AA-EW).
AQ-PAKHA-ME = "tape 1" (common to both kits)
AQ-PAKJA-ME = "tape 2" (common to both kits)
AQ-PAKKA-DE = "tape 3" ( -FW kit only )
AQ-PBE9A-AE = "tape 4" ( -FW kit only )
To update the console disk from the Base Level 11 tapes, do the
following (assuming you are updating an existing console) -
Before starting, save a copy of the current SITESPECIFIC.CMD
and SITEINIT.CMD in DUA50:[SYSEXE]. You need these files to
compare the configuation with the updated SITEINIT and
SITESPECIFIC. Simple copy DUA50:[SYSEXE]SITEINIT.CMD to
OLD_SITEINIT.CMD and DUA50:[SYSEXE]SITESPECIFIC.CMD to
OLD_SITESPECIFIC.CMD.
The 4 tapes you have are the full disk including diagnostics.
Tapes 1 and 2 are console specific and go to every customer.
Tape 3 has all the licensed diagnostics. Tape 4 has field
service only - sdd diagnostics. Make sure you keep these tapes
in a safe location secure to Digital personnel only. Under no
circumstances should tapes 3 and 4 be left with the customer.
If you intend to load the diagnostic tape (3), delete the
XB3*.SPDF, XB4*.SPDF, and *.SPDI from DUA50:[SYSMAINT]. This
release contains the newest .spdf files for hardware Rev B3/b4.
To start shutdown vms and bring the console to the SPM-ROM>
prompt.
1. Press the break key on the console terminal. You should get -
SPM-ROM>
2. Put tape 1 into the TK50 transport
3. At the prompt type B MU77
SPM-ROM>B MU77
4. Wait several minutes for the files to be found and
loaded. The console will print several informational
messages and then ask for date and time. Type in the
responose as required.
ENTER THE DATE AND TIME : 11-sep-1990 09:00
5. After entering the date, the console prompt will appear.
Type @install to start the installation.
CONSOLE> @install
6. You will be asked if you want to initiaze the disk. For
the first tape only, answer yes or no. For tapes 2 3 4
always answer no.
WARNING - Responding yes will initialize the disk. This
will effectively delete all the current files.
Only type yes if you want to start fresh or have
a new unused disk.
Initialize DUA50?(Y/N) N
7. Every thing is automatic from here out. When it is
finished typing all the informational messages and copy
information it will print "installation complete" and
return to the console prompt.
Installation Complete
CONSOLE>
8. Remove the tape and repeat steps 5 6 7 for tapes 2 and 3.
9. Set default to DUA50:[SYSEXE] and update siteinit.cmd and
sitespecific.cmd. Compare these cmd files to the old
files you saved before starting. Use edt to make the
update.
10. If the is a new installation, set default to
DUA50:[USERFILES]. Copy the appropriate xxxBOO.CMD to
DEFBOO.CMD and edit defboo.cmd to install the correct
drive numbers etc.
If this is an update, then use the existing DEFBOO.CMD.
11. If you are installing EWKCA, reboot the console. If not
go to step 12. When the console has been rebooted, put
tape 4 in the TK50 drive and follow these instructions:
A. SET DEFAULT DUA50:[SYSMAINT]
B. SET COMMAND [SYSEXE]BACKUP
C. MOUNT MUA7 *
D. BACKUP/LOG MUA7:KITINSTALL.CMD [SYSMAINT]KITINSTALL.CMD
E. @KITINSTALL
When the above sequence has been completed, you will
notified to reboot the console.
12. Reboot the console. After it comes up you should be able
to copy the customer's personal files back to the disk
that you saved initially, if necessary. You might want to
do a file compare (use the DIFF command); if there are
changes in commands in the new files you should edit
files needing site specific data rather than replacing
them with the old files.
[End of installation instructions]
|
| 78.58 | reporting procedure for SPU issues | KERNEL::WRIGHTON | odd numbered release = bug insert | Fri Oct 05 1990 01:29 | 31 |
|
Date: 9/24/90
To: Distribution From: Butch Leitz
Dept: HPS/C CSSE MEG
DTN: 297-4257
LOC/MAIL STOP: MRO2-3/5E, Pole 2C
Email: HPSMEG::LEITZ
cc:
Subject: Reporting VAX 9000 SPU Software Issues
When reporting suspected failures of the VAX 9000 SPU software,
it's extremely important that you refer to the revision or base
level of software in question in initial communications.
We currently have five revisions of SPU base levels in use
today, Base Levels 10.1, 10.3, 10.4, 10.5, and 11.0. Since
there are many bug fixes between 10.3, 10.4, and 10.5, it's
vital to express which version it is you're using when
reporting suspected bugs.
You should be able to find out what revision of media you're
running with by reading a file in the SPU's [SYSEXE] area
called MEDIA_REV.DAT.
|
| 78.59 | fix to RFT problems (don't hold your breath) | KERNEL::WRIGHTON | odd numbered release = bug insert | Sat Oct 06 1990 01:43 | 173 |
|
From: KESU::KECK "Daniel KECK, ASDPO, DTN 828-5590 05-Oct-1990 1501" 5-OCT-1990 15:22:40.08
To: @VAX9000_CST_ISDS
CC: KECK
Subj: U: Solution to RFT to VAX9000 SPU is identified. Procedure to implement will be delevered asap.
Hello,
Most of you already heard about the Remote File Transfer problem with
the VAX 9000 SPU.
The solution is to use asap in all CSC and RD centers the new RFT V3.0.
This RFT V3.0 is independant of the connection mechanism so will work
in all know situations including RSDS, RSF/RSU X1.1, even SET/HOST/DTE
or manual modem connection.
The RFT V3.0 kit is available and can be found together with its
documentation on CLARID::ASDPO_PUBLIC:[ISDS.RSFT10]
Other kits for RSF T1.0 and MODEM_SERVER T1.0 are also in this
directory. You can use them providing you consider these as field test
with some bugs.
A new bug fix version of RSF T1.0 will be available for testing later
in October.
Best regards,
Daniel.
PS: See below the latest message from ASDS engineering Mark Sullivan and RSF
product manager Marian Blackshear.
--------------------------------------------------------------------------------
From: NETMAN::BLACKSHEAR "DIPLOMACY: The art of letting someone else have
your way 05-Oct-1990 0909" 5-OCT-1990 14:38:43.44
To: KESU::KECK
CC: MARX::SULLIVAN,BLACKSHEAR
Subj: RE:A:RSDS/RFT/VAX9000
Daniel
The VAX 9000 has an ELN RFT slave released with the console software.
Because this is a new slave, older versions of the RFT Master do not recognize
it and will not work with it. This is not a bug in the RFT Master. The old
master simply does not recognize the new slave because of the hardcoded
blocksize check. The new version of RFT does not do the blocksize check to
determine which slave it is talking to.
The ideal solution is to get copies of the new RFT to your sites in the
field. This can be done in several ways;
1) Distribute RSF V1.0, and RFT V3.0 and service 9000 sites with
the new tools. I realize this could be difficult and depends
on how soon we can get RSF V1.0 into your ISDS release stream.
2) Distribute RFT V3.0 to your RSDS sites. It can be made to work in
the RSDS environment with no code changes required. We are
writing up the process and will have it to you shortly.
The only other solution is to patch the RSDS/RFT image to branch
around the blocksize check. This is not something we would want to do
nor do we recommend it. Bypassing the block size check should not cause
any problems but it can't be guaranteed.
Mark
From: KESU::KECK "Daniel KECK, ASDPO, DTN 828-5590 01-Oct-1990 0919"
1-OCT-1990 04:31:16.02
To: NETMAN::BLACKSHEAR,NETMAN::MUTAF,MARX::SULLIVAN
CC: KECK
Subj: A: RSDS/RFT/VAX9000, what about the current rsf/rsu (X1.1) RFT?
Hello Marian,
Thank you for the confirmation of the RSDS RFT problem with the VAX9000
SPU. The problem was broadcasted to the VAX9000 community a coup[le of
weeks ago.
The VTERM RFT will not reach the field in Europe before RSF T1.1 is
released and accepted, hopefully in November/December time frame.
Could you please have some one testing the SPU RFTS with the current
tools we have in the field RSU/RFT of RSF X1.1?
If this is not working, we will have to take a decision to either:
1/ Fix the little bug in the RSDS RFT Master.
2/ Start deploying components of RSF T1.0 in the field(All European
CSC's)
3/ Provide an early bug fix release of RSF T1.x.
Since this problem in widely known I am getting questions from many
countries and a little embarrassed to answer properly.
Best regards,
Daniel
________________________________________________________________________________
VAX9000_CST_ISDS Distribution list:
! VAX9000 - VAXft3000 CST
nm%BONNET::BRASSART
nm%BEAGLE::BUI
mrgate"evt::Alain Duber"
mrgate"goz::Augusto Ferrari"
nm%MUNICH::REINHOLD
nm%SHIRE::HARRISON
nm%BRSDVP::HUWAERT
nm%CLADA::HURLEY
nm%BISTRO::JENSEN
nm%JGO::KOEVOETS
mrgate"uto::Jan Kok"
nm%BRSDVP::LIDSKY
mrgate"uvo::Brian Lindley"
nm%MLNCSC::LIVIO
nm%BEANO::LOANE
nm%SHIRE::MANNSBERGER
nm%CLADA::MEDLEY
mrgate"evt::Jean-Claude Mengin"
nm%SHIRE::MILLET
nm%MUNICH::WMUELLER
nm%MACNAS::SPOMPHRETT
nm%MLNCSC::RIVA
nm%BONNET::CARON
nm%MINNIE::SOWTON
nm%BRSPMG::VOGELER
!
!Country implementation managers distribution list 11 May
nm%mrgate"nwo::Hallgeir Juliebo"!Norway
nm%mrgate"soo::ann blomqvist"!Sweden
nm%mrgate"fno::seppo arjasto"!Finland
nm%mrgate"dmo::vicki nielsen"!Denmark
nm%mrgate"ucg::Brian Minter"! - UK
nm%hoo78c::jongenelen!Cees Jongenelen - Holland
nm%mrgate"bro::michel vanwinckel"!Belgium
nm%mrgate"muh::ferdinand poesinger"!Germany
nm%mrgate"rle::hanspeter popp"!Switzerland
nm%mrgate"aui::gerhard schwarzhappel"!Austria
nm%lisvax::teixeira!Carlos Teixeira - Portugal
mrgate"sqo::fernando conde"!Spain
nm%mrgate"evt::frederic stec"!France
nm%mlntsc::tortora!Giacinto Tortora - Italy
!Greece
!Turkey
nm%mrgate"iso::emil abergel"!Israel
!
!CC list:
mrgate"vno::walter egl"!German Country Group
nm%mrgate"uvo::pete alvis"!UK
nm%mrgate"soo::Kjell Ostman"!Sweden
nm%mrgate"iyo::giovanni penazzi"!Italy
veissier
nm%clarid::roemer
nm%clarid::bell
nm%clarid::piriou
nm%bonnet::cole
To Distribution List:
Rory O'DONNELL@UVO,
Dave WRIGHTON@UVO,
Andreas KAEMPFE@SUF,
Thomas RATSCH@MGO,
Gerd GABRYS@COO,
Roberto VERCELLI@TNO,
Maurizio MORRONE@RIO,
Walter GROSSI@MIO,
Daniel GONON@GVO,
MEIR ALON@ISO,
YUVAL Ashkenazi@ISH
|
| 78.60 | The latest bug list | KERNEL::WRIGHTON | odd numbered release = bug insert | Sat Oct 06 1990 01:55 | 1854 |
|
VAX 9000 "BUG" List
Revision/Update Information: 4-October-1990
DIGITAL CONFIDENTIAL
Published by:
o ISBS / CSSE
Digital Equipment Corporation
________________________
Aug 1990
__________
The information in this document is subject to change without
notice and should not be construed as a commitment by Digital
Equipment Corporation. Digital Equipment Corporation assumes no
responsibility for any errors that may appear in this document.
The software described in this document is furnished under a
license and may be used or copied only in accordance with the
terms of such license.
No responsibility is assumed for the use or reliability of
software on equipment that is not supplied by Digital Equipment
Corporation or its affiliated companies.
__________
Copyright �1990 by Digital Equipment Corporation
All Rights Reserved.
Printed in U.S.A.
__________
The postpaid READER'S COMMENTS form on the last page of this
document requests the user's critical evaluation to assist in
preparing future documentation.
The following are trademarks of Digital Equipment Corporation:
DEC DIBOL UNIBUS
DEC/CMS EduSystem VAX
DEC/MMS IAS VAXcluster
DECnet MASSBUS VMS
DECsystem-10 PDP VT
DECSYSTEM-20 PDT
DECUS RSTS
DECwriter RSX DIGITAL
This document was prepared using VAX DOCUMENT, Version 1.2
CONTENTS
Chapter 1 CPU/SCU SUBSYSTEM:............................. 1
1.1 CPU/SCU Subsystem:................................. 1
1.1.1 Minimum Revisions:.............................. 1
1.1.2 Hardware:....................................... 1
1.1.3 uCode:.......................................... 5
1.1.4 Software:....................................... 5
Chapter 2 MASTER CLOCK SUBSYSTEM:........................ 7
2.1 CLOCK BUG #1....................................... 7
2.1.1 Minimum Revisions:.............................. 7
2.1.2 Diagnostics:.................................... 7
2.1.3 Software:....................................... 7
Chapter 3 I/O SUBSYSTEM.................................. 9
3.1 I/O Subsystem:..................................... 9
3.1.1 Minimum Revisions:.............................. 9
3.1.2 Hardware:....................................... 11
3.1.3 uCODE:.......................................... 14
3.1.4 Diagnostics:.................................... 15
Chapter 4 POWER SUBSYSTEM................................ 17
4.1 POWER Subsystem:................................... 17
4.1.1 Minimum Revisions:.............................. 17
4.1.2 Hardware:....................................... 19
4.1.3 uCode:.......................................... 19
4.1.4 Software:....................................... 19
iii
Chapter 5 SPU SUBSYSTEM:................................. 23
5.1 SPU BUG #6......................................... 23
5.2 SPU BUG #5......................................... 24
5.3 SPU BUG #4......................................... 24
5.4 SPU BUG #3......................................... 24
5.5 SPU BUG #2......................................... 24
5.5.1 Minimum Revisions:.............................. 24
5.5.2 Software:....................................... 25
5.6 SPU BUG #1......................................... 25
5.6.1 Minimum Revisions:.............................. 25
5.6.2 Software:....................................... 25
Chapter 6 MEMORY SUBSYSTEM:.............................. 27
6.1 MEMORY Subsystem:.................................. 27
6.1.1 Hardware:....................................... 27
6.1.2 uCode:.......................................... 30
6.1.3 Software:....................................... 30
Chapter 7 INSTALLATION:.................................. 31
7.1 Installation BUG #2................................ 31
7.2 Installation BUG #1................................ 31
7.2.1 Minimum Document Revisions:..................... 31
7.2.2 Tools and Tool Usage:........................... 31
Chapter 8 VMS SUBSYSTEM:................................. 35
8.1 VMS Subsystem:..................................... 35
8.1.1 Minimum Revisions:.............................. 35
8.1.2 Software:....................................... 35
iv
CHAPTER 1
CPU/SCU SUBSYSTEM:
1.1 CPU/SCU Subsystem:
1.1.1 Minimum Revisions:
o Hardware:
_____________________________________________________________
OPTION_________Rev______Comments_____________________________
CPU B4 (CDB revision)
SCU____________B3_______(CDB_revision)_______________________
o uCODE:
_____________________________________________________________
OPTION___Rev______Comments___________________________________
CPU N/A
SCU______N/A_________________________________________________
1.1.2 Hardware:
1. Bug 6: BUGCHECK/HALTS Caused by Cache Control Design Bug
System crashes with Kernel Mode Halts or Bugchecks. The halts
and bugchecks are at or around the same PC usually in a I/O
CPU/SCU Subsystem: 1
device driver. There would most likely be and instruction
that will be doing a write to an I/O device register. The
only error bits that may be latched are NXM errors. In one
of the systems increasing the sysgen paramenter NPAGEDYN by
1,200,000 enabled the system to run without any halts.
The symptoms vary, but include,
I-stack not valid -- bogus PTE loaded
exception above ASTDEL -- bad i-stream fetched
page-fault, IPL too high -- bogus PTE loaded
HALT -- i-stream fetches zero's
mem nxm, read or write -- wild translation
io nxm, read or write -- wild translation
Cause:
The system failures are caused by improper virtual address
translations in the MBox. The effect of the logic bug
is that a page table entry (PTE) is loaded into the
translation buffer (TB) incorrectly.
The bug is provoked by the incidence of a TB miss while
a CPU write, typically to I/O space, is delayed due to
a hardware resource wait. During this delay, cache set
selection information is frozen (even if the CPU write is
non-cacheable, as in I/O space writes). To resolve the TB
miss, the fixup processor requests the cache to deliver
the appropriate PTE for loading into the TB. If the PTE
resides in the OPPOSITE cache set that is selected during
the write-delay, incorrect data will be delivered to the
TB, thus causing an improper virtual address translation.
Only fixup processor requests are vulnerable to this cache
malfunction, because this is the only type of request that
2 CPU/SCU Subsystem:
the cache's arbitration logic allows to proceed while CPU
writes are in progress.
The effects of the problem are varied. Improper
translations can lead to a variety of exceptions, and
in some cases hardware error conditions.
Fix:
This is a hardware problem, but we have some some
WORKAROUNDS:
Systems with BI devices should get:
MRCSSE::NONAME:[PUBLIC]LIDRIVER.EXE
MRCSSE::NONAME:[PUBLIC]PUDRIVER.EXE
MRCSSE::NONAME:[PUBLIC]SIDRIVER.EXE
MRCSSE::NONAME:[PUBLIC]YIDRIVER.EXE
The FIX for this problem will be Revision B5 release
which should occur sometime in November. The WORK
AROUND for this problem is to disable one of the
Cache Sets by depositing the following command in
CSA1:[SYSEXE]SITEINIT.CMD. This work around should be
applied only when absolutely sure that it is need to
resolve a particular problem. Contact CSSE if unsure that
disabling half of cache will resolve a problem. Disabling
one cache set could lead to a significant decrease in
performance depending on how the system is used doing
mostly I/O or compute bound jobs. Engineering is currently
looking into a VMS and UCODE change as a workaround.
! DISABLE SET 0
D/CPU=('CPU') CTU.CTMV.SET_SEL_H<1> 1
CPU/SCU Subsystem: 3
2. Bug 5: MBOX Cache Sweep Problems
Cause:
Fix:
For more information see;
MRCSSE::NONAME:[PUBLIC]CACHE_SWEEPS.TXT
3. Bug 4: Intermittent MULX parity errors on the VML MCU in the
VBOX
4. Bug 3: Intermittent STGX parity errors on the DST MCU or OPU
MCU
5. Bug 2: Intermittent MULX parity errors on the MUL MCU
Cause:
Fix:
For more information see;
MRCSSE::NONAME:[PUBLIC]VML_MULX.TXT
For more information see; MRCSSE::NONAME:[PUBLIC]STGX.TXT
For more information see;
MRCSSE::NONAME:[PUBLIC]MUL_MULX.TXT
6. Bug: SCU Error Reporting is disabled
Cause: Error logic debug is not complete
Fix: Error reporting will be turned on in a future
release of SPU software. Please note, that most errors
are detected and the status is latched in the SCU. The
reporting mechanisms are disabled.
For more information see;
MRCSSE::NONAME:[PUBLIC]SCU_ERR_ENA.TXT
4 CPU/SCU Subsystem:
7. Bug 1: Intermittant VREG, IBANK2, and TBRAMS structure test
failures
Cause: Test setups/phase of moon...etc
Fix: Upgrade SPU to BL 11.0 in SSB now......... The VREG
and IBANK2 failures will be resolved in SPU software
release Base Level 11. Engineering has been unable to
reproduce the TBRAMS failure and would be interested in
hearing about any sequences of events that can produce the
failure.
Note: The TBRAMS failure appears to be the results of some
other structure in some specific state. When the state
of this unknown influence changes, TBRAMS runs without
failure. This is not a hardware problem
1.1.3 uCode:
1. Bug: No Known Problems
Cause:
Fix:
1.1.4 Software:
1. Bug: No Known Problems
Cause:
Fix:
CPU/SCU Subsystem: 5
CHAPTER 2
MASTER CLOCK SUBSYSTEM:
2.1 CLOCK BUG #1
2.1.1 Minimum Revisions:
o Hardware: Master Clock Module 70-25847-02 Revision D
2.1.2 Diagnostics:
o Bug: Running SCAN Hardcore test from SPU on the Master Clock
Module runs fine, but leaves Master Clock Module in incorrect
state. Actual SPU command is ">>>Test/clock <CR>" .
o Cause: SCAN Hardcore Test deficiency.
o Fix: Upgrade to SPU BL11.0. Execute an initialize/clock from
the SPU after running SCAN Hardcore Test on Master Clock
Module. Actual SPU command is ">>>Initialize/clock <CR>" .
2.1.3 Software:
o Bug: SPU command that initializes Master Clock Module doesn't
set the Frequency to system nominal value. Note: SPU commands
that initializes Kernel DOES set system frequency to the
nominal value of 500 MHz.
o Cause: Actual SPU command is ">>>Initialize/clock <CR>" .
MASTER CLOCK Subsystem: 7
o Fix: After using the SPU command ">>>Initialize/clock
<CR>" , then execute the following SPU command ">>>Set
clock/frequency=500 <CR>" , which will set the Master Clock
Module to the system's nominal frequency.
8 MASTER CLOCK Subsystem:
CHAPTER 3
I/O SUBSYSTEM
3.1 I/O Subsystem:
3.1.1 Minimum Revisions:
o Hardware:
_____________________________________________________________
OPTION___________Rev________Comments_________________________
XJA C04
CIXCD
T2080-00 E02
54-20225-01 A01
74-42042-01 Header Cover Top
74-42041-01 Header Cover Bottom
74-42081-01 Header Cover Clip
DEMNA F02 T2030
KDM70 A Two module set
I/O Subsystem 9
_____________________________________________________________
OPTION___________Rev________Comments_________________________
T2022 D01,E01
T2023 C01,C02
DWMBB A04 T2018
DRB32-M C02 T1022
DMB32 L T1012
DHB32 D01 T1044
DSB32 BX01 T1042
DEBNI C5/C6/C7 T1034
KDB50
T1002 N03
T1003 B07
KLESI____________D2_________T1014____________________________
o uCODE:
_____________________________________________________________
OPTION___Rev______Comments___________________________________
XJA V2.3
CIXCD V0.38 Diagnostic
V1.04 Functional
10 I/O Subsystem
_____________________________________________________________
OPTION___Rev______Comments___________________________________
DEMNA V6.02
KDM70 V2.2
DMB32 V13 T1012
DEBNI____3000_____T1034______________________________________
o Software:
_____________________________________________________________
OPTION___________Rev__________Comments_______________________
DMB32 YI Driver Patched Driver in
MRCSSE::PUBLIC:
LI Driver Patched Driver in
MRCSSE::PUBLIC:
SI Driver Patched Driver in
MRCSSE::PUBLIC:
DSB32 SI Driver Patched Driver in
______________________________MRCSSE::PUBLIC:________________
3.1.2 Hardware:
1. Bug: XJA Rev C02
Intermittent self-test failures
EEPROMs corruption on power up
May fail self-test with CIXCD in backplane
I/O Subsystem 11
Occasional fully recoverable JXDI parity errors
Cause:
May have XC ECLiPs parts with signal integrity problems
Some wrong delay lines
No Write Protection for EEPROMs
CIXCD Diagnostic uCODE V0.37
EWCLD V2.1 (XJA Selftest Code)
DC7092B gate array:
Fix:
XJA REV C04
CIXCD Diagnostic uCODE V0.38
2. Bug: XJA Rev C03
Intermittent self-test failures
EEPROMs corruption on power up
May fail self-test with CIXCD in backplane
Occasional fully recoverable JXDI parity errors
Cause:
No Write Protection for EEPROMs
CIXCD Diagnostic uCODE V0.37
EWCLD V2.1 (XJA Selftest Code)
DC7092B gate array:
Fix:
XJA REV C04
CIXCD Diagnostic uCODE V0.38
3. Bug: XJA Rev C04
Occasional fully recoverable JXDI parity errors
Cause:
DC7092B gate array:
Fix: XJA REV D04
12 I/O Subsystem
4. Bug: Can't load new Microcode in XMI Options
Cause: Bad cable from IORIC to XMI Backplane
Fix: New cable - 17-02324-01 (REV C01)
For more detail see the file
MRCSSE::PUBLIC:CIXCD_MICROCODE.TXT
5. Bug: Slow DEMNA Performance
Cause: Unknown
Fix: Unknown
6. Bug: XJA/JXDI/SCU Timing problem
To identify the XJA/XJXI Timing problem, check these
scanlatches at the time of failure.
1. %SCU.CCU.CTLA.PRTERR_H<2> = 1
<<<<<<OR>>>>>>
2. %SCU.CCU.CTLA.2PRTRDY_H<1:0> = 0 or 1 and
%SCU.DA0.JDC0.RCV_CCU.TO_XJA_BUFA_FULL_TB_H = 0 and
%SCU.DA0.JDC0.RCV_CCU.TO_XJA_BUFB_FULL_TB_H = 0 and
%SCU.DA0.JDC0.RCV_CCU.IO_BUFA_BUSY_TB_H = 0 and
%SCU.DA0.JDC0.RCV_CCU.IO_BUFB_BUSY_TB_H = 0
===========================================================
or if XJA2 or XJA3 exists,
1. %SCU.CCU.CTLA.PRTERR_H<5> = 1
<<<<<<OR>>>>>>
2. %SCU.CCU.CTLA.5PRTRDY_H<1:0> = 0 or 1 and
%SCU.DA1.JDC0.RCV_CCU.TO_XJA_BUFA_FULL_TB_H = 0 and
%SCU.DA1.JDC0.RCV_CCU.TO_XJA_BUFB_FULL_TB_H = 0 and
%SCU.DA1.JDC0.RCV_CCU.IO_BUFA_BUSY_TB_H = 0 and
%SCU.DA1.JDC0.RCV_CCU.IO_BUFB_BUSY_TB_H = 0
I/O Subsystem 13
Cause: Unexpectedly long data path signal between the XJA
and the SCU
Fix: Implemented in 3 Phases
Very Short Term - Do XJA Clock Cable Phase check
Short Term - Replace JXDI Cable with new cable
(17-01786-02) and XJA Clock cable (17-02454-01 REV C01).
Long Term - New MCU (Not Required for Model 210 or 4xx)
For more detail see the file
MRCSSE::PUBLIC:XJA_JXDI_CLK.CABLE
3.1.3 uCODE:
1. Bug: Intermittent XJA Selftest Failures
Cause:
CIXCD Diagnostic uCODE V0.37
EWCLD V2.1 (XJA Selftest Code)
Fix:
CIXCD Diagnostic uCODE V0.38
EWCLD V2.3 (XJA Selftest Code) XJA REV C04 For more detail
see the file
MRCSSE::PUBLIC:CIXCD_MICROCODE.TXT
Update: CIXCD uCODE Notification
Please ensure all CIXCD modules are now using CIXCD.BIN
V1.04.
The Latest release can be copied from:
IOENG::XMVDSK:[CIXCD.DIAG]
Please refer to AUGGIE::XCD_FORUM for the latest revision
information.
14 I/O Subsystem
3.1.4 Diagnostics:
1. Bug: EVCLB V1.5
Intermittent diagnostic failure doing Memory LOCKs
Cause: Diagnostic Bug
Fix: EVCLB V1.8
2. Bug: TEST/XJA failures
Cause: Operator Error
Fix:
TEST/XJA requires a working CPU, a complete I/K must be
done before attempting to execute a TEST/XJA command.
3. Bug: TEST/JXDI failures - (Pattern set REV A & B)
SJA Parity error in Test 0
For more detail see file [SYSMAINT]JXDI_HELP.TXT
Cause: Console Software
Fix: Console Software FT10.4 or higher
4. Bug: TEST/XJDI failures - (Pattern set REV B)
Compare error in Test 61
Cause: Error in the Compare Data File for test 61
Fix: Console Software FT11.0 or higher
5. Bug: EVGAA V6.1
Failures if the Autosizer (EVSBA) was used to attach the
CIXCD.
Cause: Unknown
I/O Subsystem 15
Fix: Manually attach CIXCD
6. Bug: EVGAA V6.1
Failures if the cluster size not set to 16
Cause: Unknown
Fix: Use cluster size of 16
7. Bug: EVGAB V6.1
Failures if the cluster size not set to 16
Cause: Unknown
Fix: Use cluster size of 16
16 I/O Subsystem
CHAPTER 4
POWER SUBSYSTEM
4.1 POWER Subsystem:
4.1.1 Minimum Revisions:
o Hardware:
_____________________________________________________________
OPTION_________Rev______Comments_____________________________
H7380 H05
H7382 H04
H7386 C05
H7388 D08
H7389 E07 Model 210
F07 Model 4xx
T1060 D02 Field Test
H03 STEP FIX UPGRADE
54-17895-01 E02 Model 4xx
POWER Subsystem 17
_____________________________________________________________
OPTION_________Rev______Comments_____________________________
54-18672-01 E02 Model 4xx
54-18674-01 E03 Model 4xx
54-18676-01 E03 Model 4xx
54-18678-01 E02 Model 4xx
54-18758-01 C02
54-18792-01 F01 Model 210
54-18800-01 E02 Model 210
54-18802-01 E01 Model 210
54-19021-01 E01 Model 210
54-19028-01 F05 UPC
H05 H7390
J06 STEP FIX UPGRADE
54-19030-01 H02
54-19043-01 D04
54-19045-01 D01
54-19256-01 E02 Model 210
54-20237-01____B01______Model_4xx____________________________
o uCODE:
18 POWER Subsystem
_____________________________________________________________
OPTION___Rev______Comments___________________________________
T1060 8B
H7388 84
H7389____84__________________________________________________
4.1.2 Hardware:
1. Bug: Shock Hazard
Cause: Missing AC Breaker Cover
The AC breaker in the IOA cabinet has exposed terminals
with AC voltage present on it
Fix: Cover is being designed and will be a FCO in the
near future for the short term I recommend taping over the
terminals with electrical tape.
4.1.3 uCode:
1. Bug: No Known Problems
Cause:
Fix:
4.1.4 Software:
1. Bug: Show Environmental displays wrong AIR FLOW sensors
Cause: Display Utility
POWER Subsystem 19
Fix: Future Console Code Update
Use ERF outputs and Power Subsystem Technical Manuals they
have the correct information.
2. Bug: ERF OCP Switch Exception decoded incorrectly
Cause: ERF
Fix: Future ERF Update
ERF Decode the SWITCH register incorrectly, basically the
switch position is the one not reported.
CURRENT OUTPUT OUTPUT SHOULD BE
-------------- ----------------
OLD STATE OLD STATE
SW #1 - LOCAL DISABLED SW #1 - REMOTE DISABLED
SW #1 - LOCAL SW #2 - BOOT
SW #1 - REMOTE
SW #2 - RESTART/BOOT
SW #2 - RESTART/HALT
SW #2 - HALT
NEW STATE NEW STATE
SW #1 - LOCAL DISABLED SW #1 - REMOTE
SW #1 - LOCAL SW #2 - BOOT
SW #1 - REMOTE DISABLED
SW #2 - RESTART/BOOT
SW #2 - RESTART/HALT
SW #2 - HALT
3. Bug: Syndrome code 3091G.000.003 for PCS ELE entries
Cause: Old Version of EWKCF.BCM
20 POWER Subsystem
Fix: MRCSSE::PUBLIC:EWKCF.BCM (REV 1.1(22))
Copy the latest BCM file from MRCSSE::PUBLIC:EWKCF.BCM
on our system. This file goes on the console disk in the
[SYSMAINT] directory.
4. Bug: Lost OCP Codes
Some Service personal have written command procedures to
constantly write the OCP display, and at least two separate
problems have been seen. One problem was caused when the
program was running as a batch job and the log file filled
the disk and the console could not be rebooted. The other was
a lost OCP code because the program running over wrote the
"REAL" OCP code after it was written by the PCS subsystem.
Cause: Operator Error
Fix: Don't run such program
The running of such a program has no real useful purpose
and CSSE recommends that it not be done. If we continue to
see the number of problems grow we will have the ability
for the SPU user to write the OCP Display removed from the
system. If you really want to display a three character
add it to the end of [sysexe]power.cmd command file, don't
write a program to constantly scroll the display.
POWER Subsystem 21
CHAPTER 5
SPU SUBSYSTEM:
5.1 SPU BUG #6
ITEMS OF INTEREST WITH SPU HANDLING OF OCP
Description:
One definite bug and one "feature" has been found
with the way the SPU handles the OCP key switches.
Both of these items have been QAR'd by me into the
engineering QAR system (console QARs 90 and 91). The
feature listed below as "item 2" represents
potential security issues.
These two items are common to -all- versions of SPU
software available, Base Levels 11.0, 10.5 and
under. They specifically can be found on
installations using the MDS01 to RTY port set up.
Note that in all cases, the keyswitch on the MDS01
provides absolute security.
Fix:
For more information see; MRCSSE::NONAME:[PUBLIC]SPU_OCP.TXT
SPU Subsystem: 23
5.2 SPU BUG #5
DIAGNOSTICS UPDATE:
The detailed status report for the functional diagnostics can be
found in:
MRCSSE::NONAME:[PUBLIC]VAX9000_DIAGNOSTICS_STATUS__13-SEP-1990.TXT
5.3 SPU BUG #4
SPU CLI issues addition:
TEST/SCAN/ON_ERROR:ISOLATE has been changed. ISOLATE is now it's
own parameter:
TEST/SCAN/ISO/LOG/TRA/SCU will now provide isolation on error
instead of using the /ON_ERROR switch.
For more information see; MRCSSE::NONAME:[PUBLIC]BL104.NOTES
5.4 SPU BUG #3
We are still re-structuring the SPU portion of the VAX 9000
Buglist. Please reference the following for a summary of the SPU
Bugs known to date.
For more information see; MRCSSE::NONAME:[PUBLIC]BL105.NOTES
5.5 SPU BUG #2
5.5.1 Minimum Revisions:
o Hardware:
o uCode:
o Software: REV FT10.4
24 SPU Subsystem:
5.5.2 Software:
o Bug: The command files in the [TOOLS] area are not fully
tested and supported files. These files should be used with
caution.
o Cause:
o Fix: Release notes will include changes to these files as
they occur.
5.6 SPU BUG #1
5.6.1 Minimum Revisions:
o Hardware:
o uCode:
o Software: FT10.3
5.6.2 Software:
o Bug: On console version FT10.3 the command >>>test/jxdi:0
Will fail the first time it is typed
o Cause: Unknown
o Fix: Update SPU to BL11.0
SPU Subsystem: 25
CHAPTER 6
MEMORY SUBSYSTEM:
6.1 MEMORY Subsystem:
6.1.1 Hardware:
1. Bug 2: Memory Interleaving Bug
There is a design bug in the MICR MCA which can cause
problems when certain memory interleaving modes are used.
The nature of the bug is such that the following interleaving
modes CAN or CAN NOT be used.
If 2 MMUs are present:
4 way CAN BE USED
2 way between units CAN NOT BE USED
2 way within both units CAN NOT BE USED
1 way CAN NOT BE USED
If 1 MMU is present:
2 way within unit CAN BE USED
1 way CAN NOT BE USED
The algorithm which will now determine whether an
interleaving mode is permissible will be:
If either of the PA bits which determine UNIT and SEGMENT are
MEMORY Subsystem: 27
outside the range PA[15:6], then that interleaving mode is
not permitted.
Only "4way/2mmu" and "2 way within unit/1mmu" comply with
this.
Cause:
For more information, please refer to:
MRCSSE::NONAME:[PUBLIC]MEM_INTERLEAVE.TXT
Fix:
2. Bug 1: Errors with memory BIST with cache sweep disabled
The following memo describes the subject bug:
From: AQUA::EVANS
To: MRCSSE::TCOLLENTINE,DELAHUNT,MCCABE,DUSEK
CC:
Subj: Errors with memory BIST with cache sweep disabled
I think I understand why we are seeing problems with
the memory BIST and error sweeps disabled. When error
sweeps are disabled the EBOX will read 256K of memory
to force all blocks out of the cache. The JBOX thinks
the data is in the cache and is read only, as it
actually is. During BIST we must switch the memory
interleave to 1WAY so we can correlate the blocks in
memory which have failed with the bank (the algorithm
is a real bummer if we do not use 1way). The EBOX
reads have been done in 1WAY interleave and the TAGRM
will have addresses in them based on this interleave.
Now we switch the interleave back to 4WAY and will
get TAG address parity errors if we reference any of
the blocks which are marked valid and in the TAG
28 MEMORY Subsystem:
which do not map the same for 1WAY and 4WAY. Now, the
last 128K bytes read will be in the TAG. Locations
20200 - 40200. EWSAA is loaded starting at 10000 and
sure enough, I get SCU errors on address 20240, the
first block marked valid which does not ahve the same
address in 1WAY and 4WAY. VMB is loaded into 200 and
is very small. The SPU will never get errors loading
it, however, I would have to believe that either it
does some magic to clear the TAGRM (by some
writeback/read sequences) before it gets to the bad
locations or it will fail with a hung SCU also. I
have modified a copy of TEST_MEMORY to enable MBOX
sweeps during BIST and this has solved the problem. I
need to discuss this with the MBOX and SCU folks to
determine if this should be a permanent fix.
Steve, can you verify this analysis ? Am I correct in
my assumptions about the TAGRM and is there a
sequence of commands which could overwrite a location
before it is checked for parity such that VMB would
run ? VMB does a clear memory by writing to all of
it. I dont know how they do this but perhaps not all
CPU commands look up the TAG parity ?? Thanks,
Cause:
Fix:
MEMORY Subsystem: 29
6.1.2 uCode:
1. Bug: No Known Problems
Cause:
Fix:
6.1.3 Software:
1. Bug: No Known Problems
Cause:
Fix:
30 MEMORY Subsystem:
CHAPTER 7
INSTALLATION:
7.1 Installation BUG #2
Problem: No Read-Me-First label was found.
Solution: The VAX 9000 Model 200 Installation Guide, page 2-2
states:
"Remove the shipping/accessory list from the customer
services box and check the contents of all boxes
against the shipping list. THIS BOX IS IDENTIFIED BY
THE INTERNATIONAL SYMBOL-A BLUE CIRCLE CONTAINING THE
LETTER I."
7.2 Installation BUG #1
7.2.1 Minimum Document Revisions:
o Install Guide - August 1990
o Site Prep Guide - July 1990, First Edition
7.2.2 Tools and Tool Usage:
Subject: Uncalibrated Torque Tool (P/N: 29-28143-01.A01)
INSTALLATION: 31
PROBLEM:
We have just found indications that there is an uncalibrated
torque device in the VAX 9000 CONNECTOR TORQUE TOOLS KIT (P/N:
29-28143-01.A01).
KIT AFFECTED:
Three of three kits shipped to MRO were received with the Z-FLEX
& MEM/FLEX Torque Tool (P/N: 29-28143-01.A01) uncalibrated. This
tool is essential to the installation of the VAX 9000 Z-FLEX
Cables.
POSSIBLE IMPACT:
We are presently unsure as to the possible symptoms/problems
that could result, but the 20 in-lb value that the uncalibrated
tools are coming in at should establish adequate connector
contact. The addition 7 in-lbs provides long term vibration
resistance for the connection.
PREVENTIVE MAINTENANCE:
Once a correctly calibrated tool is available, all existing
VAX 9000 Installations should be re-visited and all Z-FLEX
connections be re-torqued. We DO NOT recommend separating the
connection, merely tighten the existing connection with the
calibrated tool. This should ensure a robust connection.
QUICK CHECK PROCEDURE:
The best way to determine if the tool you received is properly
calibrated is to look at the butt of the red handle. The number
27 should be stamped next to the "calibration at" label. If no
value is stamped, your tool is likely not calibrated (we have
found them at 20 in-lbs).
32 INSTALLATION:
RECOVERY PROCEDURES:
FASTEST METHOD: The quickest way to get this tool calibrated
involves directly contacting a local machine shop that
calibrates torque devices. It should only take a few minutes
to actually calibrate and stamp/mark the tool. The expense will
vary between calibration shops, but should not cost more than
$10-20 dollars (US).
TORQUE SETTING: 27 in-lbs or 31 cm-Kg
ALTERNATE METHOD: Fast ship (Ex. Federal Express etc) your
Z-Flex Torque tool to:
KAUFMAN COMPANY, INC.
110 Second Street
Cambridge, MA 02141
Attn: Mr. Norman Kaufman
Enclose with the tool a memo listing the address to return
calibrated tool to. Kaufman Co. will fast ship the corrected
tool to you.
Note: The current Z-Flex Torque Tool being shipped has a red
anodized aluminum handle. Some (not all) of the replacement
tools may have blue handles. Refer to the calibration stamp
for setting varification
COMMENT:
Luckily the non calibrated tool is not stored at values above
the 27 in-lbs, so no damage will occur to the connector.
A quality hold has been placed on all kits in inventory and
the vendor will correct this over the next week. Customer
Service Purchasing and Logistics are aware of this and are
taking the necessary steps to ensure correction and future
prevention of this problem.
INSTALLATION: 33
Z-Flex connector cleaning technique
When cleaning the connector on the Z-flex cable use caution
so that the cleaning sticks are not shredded during cleaning.
Use the flat portion of the cleaning stick to wipe across the
connector away from the cable. If the handle on the cleaning
stick bends, you are applying too much pressure.
Clock Cable connector tightening technique
Proper techinique must be used when tightening clock cable to
prevent loosening of cable. Use two hands to connect the clock
cables. Hold the cable with one hand (about three inches from
connector). Feed the cable straight into the jack and release
pressure on cable. Use 8 in-pound torque tool (PN 29-27973-01)
to tighten connectors. While torqueing hte clock connectors,
prevent the cable from twisting inside the housing b wiggling
the cable. Twisting could cause the SMA connector to loosen.
34 INSTALLATION:
CHAPTER 8
VMS SUBSYSTEM:
8.1 VMS Subsystem:
8.1.1 Minimum Revisions:
Version 5.4
8.1.2 Software:
1. Bug:
=======================================================
Note 609.6 FORTRAN RTL images problem on V5 6 of 6
QUARK::LIONEL
"Free advice is worth every cent" 21-SEP-1990
-< STARS article >-
-------------------------------------------------------
[This is a corrected version of an earlier posting.]
Attached is a STARS article that will soon be made
available to customers. It describes a problem with
linking FORTRAN programs on newly installed "from
scratch" VMS V5.4 systems. Please distribute this
information to any affected users and customers.
VMS Subsystem: 35
This problem will be "fixed" in the next maintenance
update of VMS, but the solution given in the article
can be applied immediately without interfering with
the later VMS fix.
Steve
*****************************************************
TITLE: LINK-I-DATMISMCH on FORTRAN RTL After
Installing VMS V5.4
COMPONENT: Linker Utilit OP/SYS: VMS, Version 5.4
LAST TECHNICAL REVIEW: 20-SEP-1990
SOURCE: Customer Support Center/Colorado Springs USA
\ Information in this article was extracted from the
\ VMS_FIELD_TESTS conference, topic 609, entered by
\ Steve Lionel.
SYMPTOM:
After doing an initial installation of VMS V5.4, the
FORRTL and FORRTL2 shareable images are not
consistent with what was inserted into the
IMAGELIB.OLB on the kit.
Running the Installation Verification Procedure (IVP)
after installing FORTRAN or VAX FORTRAN-HPO will
produce the following messages:
%LINK-I-DATMISMCH, creation date of 16-JUL-1990 09:47 in
shareable image SYS$COMMON:[SYSLIB]FORRTL.EXE;1
differs from date of 19-JUN-1990 04:43 in shareable
image library SYS$COMMON:[SYSLIB]IMAGELIB.OLB;1
%LINK-I-DATMISMCH, creation date of 16-JUL-1990 09:48 in
shareable image SYS$COMMON:[SYSLIB]FORRTL2.EXE;1
differs from date of 19-JUN-1990 04:44 in shareable
image library SYS$COMMON:[SYSLIB]IMAGELIB.OLB;1
36 VMS Subsystem:
Linking any FORTRAN program will produce these
messages. Programs written in other languages may
also include references to the FORTRAN RTL, and
linking those programs will produce the messages as
well.
ANALYSIS:
This behavior only occurs after an initial
installation of VMS V5.4. It does not occur when
upgrading to VMS V5.4.
These are informational diagnostic messages, and does
not effect the image being linked.
WORKAROUND:
Replace FORRTL.EXE and FORRTL2.EXE in the
IMAGELIB.OLB with the command:
$ LIBRARY/SHARE/REPLACE SYS$LIBRARY:IMAGELIB SYS$LIBRARY:FORRTL,FORRTL2
NOTE:
If another process has the library open (for example,
during a link operation), you may see errors
indicating that the library file is in use. Wait
until this other process is through linking, and
retry the replace operation.
DIGITAL RESPONSE:
This issue has been reported to VMS Engineering.
\\ LINK VER_5.4_VMS
\\ FT
VMS Subsystem: 37
|
| 78.61 | status of MCA's for B5 and C1 | KERNEL::WRIGHTON | odd numbered release = bug insert | Tue Oct 09 1990 08:30 | 140 |
|
MCA STATUS FOR KERNEL CONFIGURATIONS B5 and C1
ECOSTATUS.MEM
10/4/90
JURGEN
B5:
===
MCU MCA MCA PTOTO MCU PROTO ECO Owner ECO Status
TYPE TYPE FROM MOTO FROM MFG. Kernel 70- P1x 54- 19-
==== ==== ========= ========= ========= ====== === === === ===
CTU 10/8/90 R.Hetherington TBS TBS IR IR
CTMA.D1 Avail. R.Hetherington IR
CTMV.M1 Avail. R.Hetherington IR
C1:
===
MCU MCA MCA PTOTO MCU PROTO ECO Owner ECO Status
TYPE TYPE FROM MOTO FROM MFG. Kernel 70- P1x 54- 19-
==== ==== ========= ========= ========= ====== === === === ===
VAP TBD R.Hetherington TBS TBS TBS TBS
VAPO.H1 D.S. R.Hetherington TBS
CCSQ.H1 Avail. R.Hetherington TBS
CCU TBD S.Delahunt TBS TBS TBS TBS
CTLA.D1 Avail. S.Delahunt TBS
CTLB.D1 Avail. S.Delahunt TBS
CTLD.D1 Avail. S.Delahunt TBS
TAG TBD S.Delahunt TBS TBS TBS TBS
ADRX.D1 Avail. S.Delahunt TBS
DAX Avail. S.Delahunt TBS TBS TBS TBS
DSXX.C1 Avail. T.Fissette TBS
JDCX.C1 Avail. S.Delahunt TBS
DBX TBD T.Fissette TBS TBS TBS TBS
DSXX.C1 Avail. T.Fissette TBS
MMCX.D1 Avail. T.Fissette TBS
Process:
TBS To be supplied
IR In Review
D.F.. Designing a fix for problem
L.B. Loopback Process, i.e. SID Synthesis, Auto Placement, Auto Routing
T.F. Timing Fix resulting from Timing violation with new layout
D.S. Design Services, manually fixing unroutes, Rules Checking
F.C. Final Checking and Sign-off
TO MOT = Back from D.S. plus 2 days
Bug Descriptions:
=================
MBOX VAP VAPO.F1 MAX INSTRUCTION SEQUENCE MISMATCH (MEDIUM
LIKELYHOOD TO OCCUR IN REAL APPLICATIONS)
VAPO.H1 INSV BUG
VAP CCSQ.F1 FOR HIGH I/O LOADS, SINGLE CYCLE VULNERABILITY
TO RETIRE REQUESTS OUT OF ORDER
VAP CCSQ.H1 CACHE SWEEP BUG, CACHE SBE RECOVERY BUG
CTU CTMA.D1 CACHE SWEEP BUG
CTU CTMV.L1 CACHE SWEEP BUG
CTMV.M1 FETCHING BAD PTE BUG
JBOX DBX MMCX.D1 REPORTING SBEs (THAT OCCUR AT HIGH RATE) TO SPU
SLOWS DOWN MEMORY ACCESS
ACCIDENTALLY LEFT OUT FIX IN MMCX.C1 TO
FIX MEM STEP PROBLEM
TAG ADRX.D1 CPU AND SCU CLOCKS MUST BOTH BE TURNED OFF
DURING ERROR RECOVERY, VMS CAN'T DEAL WITH
ALL POSSIBLE TYPES OF RESULTING I/O TIMEOUTS.
DAX,DBX DSXX.C1 - SAME AS ABOVE -
CCU CTLA.D1 - SAME AS ABOVE -
CCU CTLB.D1 - SAME AS ABOVE -
CCU CTLD.D1 1. SPU POWER OK SCAN LATCHES CAUSE SCAN TO
UPSET THE XJA IF THE SCU MCUS ARE
BROADCAST SCANNED, WHICH IS REQUIRED FOR
MEMORY SINGLE STEP.
2. SPU INTERFACE HANGS IF SPU READS MEM AND
GETS DBE.
DISABLING A PARITY CHECK AVOIDS THIS.
3. SOME CHANCE OF SPU INTERFACE HANGING IF
SPU IS POWERED OFF AND MEM HAS ECC EVENT.
4. LOGIC WHICH HANDLES SPU ERRORS REDEFINED.
DBX JDCX.C1 2 LATCHES MISSING CREATES POTENTIAL WORST CASE
TIMING PROBLEM. NEW PROGRAMM. DELAY PROMS IN
MCM CORRECTED PROBLEM IN LAB SYSTEMS
PHASE IN CHIPS (CONFIG.C2)
===================================
BEST CASE
CHIP MCU STATUS AVAIL. STATUS
---- ----- ------ ------- -------
VMLB-C1 VML @MOTO ENG. DEMAND FILLED
VFPK-C1 VAD @MOTO ENG. DEMAND FILLED
USQB-C1 INT @MOTO ENG. DEMAND FILLED
USQA-D1 INT @MOTO ENG. DEMAND FILLED
ISSC-E1 CTL @MOTO ENG. DEMAND FILLED
OSQA-F1 OPU @MOTO ENG. DEMAND FILLED
VMLB.C1 Vector Performance
VFPK-C1 Vector Performance
USQB-C1 Error Interrupt
USQA-D1 Interrupt Scenario
ISSC-E1 MAX with Branches + H-Float Emulation
OSQA-F1 MAX Case Failure
|
| 78.62 | Installing the Vbox | KERNEL::WRIGHTON | odd numbered release = bug insert | Tue Oct 09 1990 08:30 | 224 |
|
From: Tom Collentine
1) After installing the Vbox MCUs.
2) edit [sysexe]sitespecific.cmd Change "DEFINE/SYSTEM SYS$VBOX_MASK 0"
to reflect Vbox installed. I.e CPU0 change 0 to a 1
in above command line. For CPU2 it would be a 4
!!!Vbox will not be present otherwise!!!!
3) Reboot the SPU so [sysexe]sitespecific.cmd changes are taken.
4) >>>sense system
5) >>>show config/rings !should be no mismatches
6) >>>test/scan/cpu:0/log/trace !should be no failures
7) >>>test/structure !some structures may fail see buglist
8) >>>I/K
9) >>>B VDS !RUN STANDALONE VBOX MACRO DIAGS FROM CSA1:[SYSMAINT]
******DIAGS WILL FAIL IF MM IS NOT SET CORRECTLY AND VBOX IS NOT ATTACHED***
DS> set verify
DS> attach kawww hub ka0 0 yes !ka0 select CPU:0, yes vbox present
DS> sel ka0 !select the CPU for testing
DS> set t,h !set vds flags: Trace,Halt
DS> load evkah.exe
DS> set MM ON
DS> start/PASS=0 !start diagnostic forever
DS> set verify
DS> attach kawww hub ka0 0 yes !ka0 select CPU:0, yes vbox present
DS> sel ka0 !select the CPU for testing
DS> set t,h !set vds flags: Trace,Halt
DS> load evkag.exe
DS> set MM ON
DS> start/PASS=0 !start diagnostic
>>>I/K
>>>B !Boot VMS and run UETP (vector tests should run)
After UETP starts running, start a background process from another
terminal running macrodiagnostics EVKAG and EVKAH. Then on another
terminal do a VMS DCL command " MONITOR VECTOR " to check vector stats.
(END OF VECTOR ISSUE)
2. Customer has received BL 11.0 console tapes but has no
instructions as to how to install it.
Kit containes the following QZ-K23AA-EW
o Tapes: AQ-PAKHA-ME VAX9000 CONSOLE IMAGES
AQ-PAKJA-ME VAX9000 CONSOLE UTILITIES & UCODE
o Books: AA-PCJ5A-XE VAX9000 INSTALLATION GUIDE
EK-9201U-UG VAX9000 HARDWARE USERS GUIDE
EK-9000C-CD VAX9000 CONSOLE COMMAND DISCRIPTION
***NOTE*** IN THE ABOVE DOCUMENTATION THERE IS NO MENTION OF THE PROCEDURE
FOR UPGRADING THE CONSOLE SOFTWARE.
The customer also received QA-A93AA-HM as part of order ref #
90E46259Y (Marked NO CHARGE) which is PCSA SRVC FOR PCS V3.1 16MT9
and a manual on Server Communications for LAN. The customer does
not remember ever having ordered this. I suggested to engineer to
check with local sales for any records for this order as it came
in as one order to the customer.
I HAVE JUST RECEIVED THE FOLLOWING INFORMATION FROM CSSE ON THE PROCEDURE
From: MRCSSE::LEITZ "butch leitz, 297-4257, mro2-3/2c, HPS CSSE 03-Oct-1990 1502" 3-OCT-1990 13:20:13.77
To: @AQME,@PUBLIC:9K_TECH,@TRAIN
CC: LEITZ
Subj: Generic Install Instructions for SPU SW
+---------------------------+ TM
! ! ! ! ! ! ! ! i n t e r o f f i c e
! d ! i ! g ! i ! t ! a ! l !
! ! ! ! ! ! ! ! m e m o r a n d u m
+---------------------------+
Date: 10/3/90
To: (VAX 9000 DISTRIBUTION) From: Butch Leitz
Dept: HPS/C CSSE MEG
DTN: 297-4257
LOC/MAIL STOP: MRO2-3/5E, Pole 2C
Email: HPSMEG::LEITZ
cc:
Subject: INSTALLATION INSTRUCTIONS FOR VAX 9000 SPU SOFTWARE
The following instructions are similar to what should be in the
Customer Service kit (QZ-K23AA-FW) for the VAX 9000 SPU
updates. You can use these instructions for installing the
first two tapes received in the Customer update kit
(QZ-K23AA-EW).
AQ-PAKHA-ME = "tape 1" (common to both kits)
AQ-PAKJA-ME = "tape 2" (common to both kits)
AQ-PAKKA-DE = "tape 3" ( -FW kit only )
AQ-PBE9A-AE = "tape 4" ( -FW kit only )
To update the console disk from the Base Level 11 tapes, do the
following (assuming you are updating an existing console) -
Before starting, save a copy of the current SITESPECIFIC.CMD
and SITEINIT.CMD in DUA50:[SYSEXE]. You need these files to
compare the configuation with the updated SITEINIT and
SITESPECIFIC. Simple copy DUA50:[SYSEXE]SITEINIT.CMD to
OLD_SITEINIT.CMD and DUA50:[SYSEXE]SITESPECIFIC.CMD to
OLD_SITESPECIFIC.CMD.
The 4 tapes you have are the full disk including diagnostics.
Tapes 1 and 2 are console specific and go to every customer.
Tape 3 has all the licensed diagnostics. Tape 4 has field
service only - sdd diagnostics. Make sure you keep these tapes
in a safe location secure to Digital personnel only. Under no
circumstances should tapes 3 and 4 be left with the customer.
If you intend to load the diagnostic tape (3), delete the
XB3*.SPDF, XB4*.SPDF, and *.SPDI from DUA50:[SYSMAINT]. This
release contains the newest .spdf files for hardware Rev B3/b4.
To start shutdown vms and bring the console to the SPM-ROM>
prompt.
1. Press the break key on the console terminal. You should get -
SPM-ROM>
2. Put tape 1 into the TK50 transport
3. At the prompt type B MU77
SPM-ROM>B MU77
4. Wait several minutes for the files to be found and
loaded. The console will print several informational
messages and then ask for date and time. Type in the
responose as required.
ENTER THE DATE AND TIME : 11-sep-1990 09:00
5. After entering the date, the console prompt will appear.
Type @install to start the installation.
CONSOLE> @install
6. You will be asked if you want to initiaze the disk. For
the first tape only, answer yes or no. For tapes 2 3 4
always answer no.
WARNING - Responding yes will initialize the disk. This
will effectively delete all the current files.
Only type yes if you want to start fresh or have
a new unused disk.
Initialize DUA50?(Y/N) N
7. Every thing is automatic from here out. When it is
finished typing all the informational messages and copy
information it will print "installation complete" and
return to the console prompt.
Installation Complete
CONSOLE>
8. Remove the tape and repeat steps 5 6 7 for tapes 2 and 3.
9. Set default to DUA50:[SYSEXE] and update siteinit.cmd and
sitespecific.cmd. Compare these cmd files to the old
files you saved before starting. Use edt to make the
update.
10. If the is a new installation, set default to
DUA50:[USERFILES]. Copy the appropriate xxxBOO.CMD to
DEFBOO.CMD and edit defboo.cmd to install the correct
drive numbers etc.
If this is an update, then use the existing DEFBOO.CMD.
11. If you are installing EWKCA, reboot the console. If not
go to step 12. When the console has been rebooted, put
tape 4 in the TK50 drive and follow these instructions:
A. SET DEFAULT DUA50:[SYSMAINT]
B. SET COMMAND [SYSEXE]BACKUP
C. MOUNT MUA7 *
D. BACKUP/LOG MUA7:KITINSTALL.CMD [SYSMAINT]KITINSTALL.CMD
E. @KITINSTALL
When the above sequence has been completed, you will
notified to reboot the console.
12. Reboot the console. After it comes up you should be able
to copy the customer's personal files back to the disk
that you saved initially, if necessary. You might want to
do a file compare (use the DIFF command); if there are
changes in commands in the new files you should edit
files needing site specific data rather than replacing
them with the old files.
[End of installation instructions]
**************************** Digital Internal Use Only *************************
|
| 78.63 | problems with 9000's and VCS | KERNEL::WRIGHTON | odd numbered release = bug insert | Tue Oct 09 1990 08:31 | 50 |
|
There has been some communication from the 'CCD' group in
BTO regarding VCS & the 9000.(attached to the end of this memo)
Yes I know this is not listed as a bug....(supposedly was fixed)
And I am also aware of the marketing push for the use of VCS with 9000s
(as a matter of fact at one time people wanted to bundle it in with every
sale).... But bottom line, It causes the SPU to hang!!(not as described
in the CCD memo) Though one must admit... it still don't work! Yes one
can 'reboot' the SPU, but that is not an acceptable workaround for our
customers.
To compound this according to our LP list, even though listed
as 'partial' test we currently ship this product with the 9000!
In speaking with Butch, it appears it is a flow control problem
between the SPU and VCS. As things progress we will update.
I expect that we will soon see a position statement.....
Just wanted to make you all aware of the issue....
Please advise us as to how many customers in your region could be affected
by this...
thanks
/joe
From: BTOVT::BTOVT::GRAVELIN_T "04-Oct-1990 1014" 4-OCT-1990 10:21:04.66
To: @CCD
CC:
Subj: The Support of VCS with the 9000
Everyone,
Many orders are coming in with the customer wanting to use VCS on the 9000
instead of a VTxxx terminal. At this time, VCS is not supported with the 9000
The 9000 console software hangs the VCS. There is no date set when this will
be supported. I am waiting for a reply from CSSE as to the support plan. MRO
has been testing VCS last night with a new fix in the Console code. AS of this
morning it still fails. please let your Account Teams know of this problem.
Will keep you informed if new developments occure.
Tom
|
| 78.64 | BI device driver problems and workarounds | KERNEL::WRIGHTON | odd numbered release = bug insert | Tue Oct 09 1990 08:32 | 60 |
|
From Butch Leitz
Please take the time to make sure we cover these things on the
sites that are affected. But as stated in the memo from engineering
we must keep track.... So when and if you need this please drop a
line to Mike or I on it, so we can keep Butch updated...
thanks
/joe
From: VINO::TLITT "Tim Litt 01-Oct-1990 1611" 1-OCT-1990 16:43:05.95
To: AQUA::BROMMELHOFF
CC: HPSMEG::LEITZ,TLITT
Subj: Please distribute as needed: BI device driver work-arounds.
As you know, the VAX 9000 CPU has a bug in the CTMV MCA which is exacerbated
by the presence of BI devices in a configuration. Gary Shepard's recent
memo describes the problem in detail.
A permanent fix is forthcoming in kernel rev B5, and will involve replacing the
MCU containing this MCA (CTU).
As a temporary work-around, the device drivers most likely to encounter this
bug have been modified, and supplied to BTO Manufacturing. (This is not a
100% fix; problems should be escalated via CSSE, and the actions in Gary's
memo followed.)
Manufacturing(Jeff Brasssord) owns distribution of these drivers with new
shipments which contain KDB50, DMB32, and/or DSB32 options.
CSSE (Butch Leitz) owns supplying these drivers (and any necessary updates)
to BI customers shipped without them. CSSE also owns involving the CSCs as
required. In the very rare instances where the symptoms are seen on KDM70
systems, CSSE will distribute PUDRIVER after ascertaining that the root cause
is this bug.
[Note, the following have been placed in MRCSSE::PUBLIC: - butch]
Directory NONAME:[PUBLIC]
LIDRIVER.EXE;4 7 2-OCT-1990 09:27:50.34 (R,RWED,R,)
PUDRIVER.EXE;2 24 2-OCT-1990 09:27:50.46 (R,RWED,R,)
SIDRIVER.EXE;5 50 2-OCT-1990 09:27:50.60 (R,RWED,R,)
YIDRIVER.EXE;7 7 2-OCT-1990 09:27:50.86 (R,RWED,R,)
Everyone distributing these drivers MUST keep track of where they go, as they
will need to be removed following the installation of the new CTU. Also,
because we need to be able to distribute updates.
Because this is NOT a bug in the software, the responsible Engineering group
for these changes is NOT the communications group in Reading, England. Rather,
the modifications(but not the drivers per-se) will be supported thru VAX 9000
Engineering. (Tim Litt)
The symptoms can be subtle, and the work-arounds are not 100% effective. We
WANT to hear about problems; do not heasitate to elevate problems.
|
| 78.65 | Working out Ebox Control Store parity errors | KERNEL::WRIGHTON | odd numbered release = bug insert | Tue Oct 09 1990 12:17 | 104 |
|
Subject: Isolating VAX 9000 EBOX Control Store Parity errors.
In order to isolate EBOX control store parity errors to a
failing FRU it is necessary to XOR the syndrome of the
failing micro word with a known good syndrome value.
A syndrome file containing the 4000 locations of good
syndrome will be included with future releases of the console
software. The file will reside in [UCODE] and will be named
AQUARIUS.SYN.
You can utilize the syndrome file in conjunction with the
Theory article to isolate the EBOX CSPE to a faulty MCU.
I have placed syndrome files for EBOX Microcode E315, E316,
and E320 in MRCSSE::NONAME:[PUBLIC].
Directory MRCSSE::NONAME:[PUBLIC]
AQUARIUS_E320.SYN;1 AQUARIUS_E315.SYN;1 AQUARIUS_E316.SYN;1
Total of 3 files.
In some cases it may take several occurrences of a EBOX CSPE
to isolate the failure to a single MCU. In some instances it
will require only one failure.
Since rams are susceptible to transient errors, the failure
may be due to a nonrecurring bit failure caused by alpha
particles emitted from small amounts of radioactive elements
present in the packaging material. As they pass through the
semiconductor material, alpha particles create sufficient
hole-electron pairs to add charge or remove charge from bit
cells.
For the reason noted above, and the fact a single occurrence
for most cases will not isolate the parity error to a single
MCU. CSSE DOES NOT RECOMMEND any replacement action be taken
for a single occurrence of an EBOX Control Store Parity
Errors.
A future version of the error handling code will make EBOX
control store parity errors recoverable. This will be done by
rewriting the the Microword at the failing address from a
SPU memory resident copy of Aquarius Microcode.
Using information contained in the SCAN ELE and information
contained in the AQUARIUS.SYN file an error can be isolated
as follows.
Information from a ELE
CTL.ISSE.LAT_UWORD_ERROR_H = 1 !EBOX CSPE
INT.USQA.PARITY_UPC_H<3:0> = 5(X) !Address 7A5
INT.USQB.PARITY_UPC_H<10:4> = 7A(X)
CTL.ISSE.SYND_EBOX_CTL_STORE_H<22:0> = 520A0D(X)
!syndrome 520A0D
Good syndrome from MRCSSE::Noname:[public]AQUARIUS_E316.SYN
$Search noname:[public]AQUARIUS_E316.SYN
[07A5] 520A0F
An XOR of the good and bad syndromes produces syndrome bit 1.
A partial extract from the theory article for EBOX CSPE's
follows.
********************************************************************
; SYNDROME BIT = 1 PARTIAL PARITY SIGNAL NAME = DST1_UWORD_CHECK_H
;
; Signal source: MCU-UCS/STRAM-CSS48,CSS49
; Signal source: MCU-INT/STRAM-CSS11,CSS13,CSS15
; Signal destination: MCU-DST/MCA-DST1
;
; ULD FROM TO
; BIT ULD FIELD NAME MCU.STRAM MCU.MCA
; ---- --------------------------- ------------ --------
; 025 UAMX_SEL=<25> UCS.CSS48<0> DST.DST1
; 026 UAMX_SEL=<26> UCS.CSS48<1> DST.DST1
; 027 UAMX_SEL=<27> UCS.CSS48<2> DST.DST1
; 028 UBMX_SEL=<28> INT.CSS11<0> DST.DST1
; 029 UBMX_SEL=<29> INT.CSS11<1> DST.DST1
; 030 UVA_ALUMX_SEL=<30> INT.CSS11<2> DST.DST1
; 031 UVA_ALUMX_SEL=<31> INT.CSS11<3> DST.DST1
; 037 UVA_ALU_FUNCTION=<37> INT.CSS13<0> DST.DST1
; 038 UVA_ALU_FUNCTION=<38> INT.CSS13<1> DST.DST1
; 039 UVA_ALU_FUNCTION=<39 INT.CSS13<2> DST.DST1
; 069 URMX_SEL=<69> UCS.CSS49<1> DST.DST1
; 070 UR1MX_SEL=<70> UCS.CSS49<2> DST.DST1
; 071 UVAMX_SEL=<71> INT.CSS13<3> DST.DST1
; 072 UVAMX_SEL=<72> INT.CSS15<0> DST.DST1
; 073 UVAMX_SEL=<73> INT.CSS15<1> DST.DST1
; 074 UVBMX_SEL=<74> INT.CSS15<2> DST.DST1
; 075 UVBMX_SEL=<75> INT.CSS15<3> DST.DST1
; 079 URESMX_SEL=<79> UCS.CSS49<3> DST.DST1
; 084 UMBOX_ADDRMX_SEL=<84> UCS.CSS48<3> DST.DST1
|
| 78.66 | 9000 cluster configurations | KERNEL::WRIGHTON | odd numbered release = bug insert | Wed Oct 10 1990 08:04 | 186 |
|
Subj: Supported VAX 9000 Cluster Configurations
As of this date the following VAX 9000 Cluster configurations are supported:
o A Single VAX 9000-210 or VAX 9000-410 in a cluster
o A single VAX 9000-420 (SMP machine) may be installed in a cluster, but
only under field test agreement
o As many as 2 star couplers within a single cluster
o No more than 4 XCDs per VAX 9000 or VAX 6000
o No more than one XMI per VAX 9000
o At most a single vector box in any VAX 9000
o Currently we do NOT support any BI devices on the VAX 9000 (see note
attached from Ravi Ganesan.
o Host Based Shadowing is NOT supported - use Controller Based Shadowing
instead
o At most 6 KDM70 controllers are supported on a single VAX 9000
o You may configure different XMI devices in the same XMI
o The maximum number of nodes on a single star coupler (CISCE) is 32
o The maximum number of CI connected VAX nodes in a single cluster is 16
o The maximum number of nodes within a cluster is 96 (though we recommend
that you do not exceed a total of 32 host nodes within a single
cluster)
NOTE: Any exception to these configuration restrictions must be explicitly
approved by ISB Product Management (Ed Barker).
DIGITAL CONFIDENTIAL
BI Adapters for VAX 9000 Page 1
Last rev 9/28/90
Current rev 10/05/90
NOTE: SINCE THE XBI+ DIAGNOSTICS ARE INCOMPLETE - THERE IS NO WAY
TO INSURE THAT ANY BI DEVICE IS WORKING PROPERLY (THE XBI+ IS
COMMON TO ALL BI DEVICES ON THE VAX 9000).
THEREFORE, UNTIL THE XBI+ DIAGNOSTICS ARE COMPLETE - WE WILL
NOT SUPPORT ANY BI DEVICE ON THE VAX 9000.
+-----------+------------------------------------------------------+-------+
| BI Device | Qualification Status |Support|
+-----------+------------------------------------------------------+-------+
| DWMBB |Hardware/�code : T2018 A04 : Comp | |
| (XBI+) |Software Driver: : Comp | Yes� |
| |Diagnostics : Level 4 :Not all tests operationl| |
| | : Level 3 : Not ready yet
+-----------+------------------------------------------------------+-------+
| KDB50 |Hardware/�code : T1002 N03, : Comp | |
| | : T1003 B07 : | |
| |Software Driver: PUDRIVER : Comp | Yes |
| |Diagnostics :Levels 2R/3 : Comp | |
| |Special funcn. : Boot : Comp | |
+-----------+------------------------------------------------------+-------+
| DMB32 |Hardware/�code : T1012 L13 : | |
| |Software Driver: SIDRIVER : PTE bug fix (temp) is | Yes� |
| | : LIDRIVER : being tested. | |
| | : YIDRIVER : | |
| |Diagnostics :Levels 2R/3 : Comp | |
+-----------+------------------------------------------------------+-------+
| DSB32 |Hardware/�code : T1042 BX01 : Comp | |
| |Software Driver: SLDRIVER : Comp | Yes� |
| |Diagnostics :Levels 2R/3 :2R tested;3 Being tested| |
+-----------+------------------------------------------------------+-------+
| DHB32 |Hardware/�code : T1044 D01 : PTE bug fix (temp) is | |
| |Software Driver: YIDRIVER : being tested. | Yes� |
| | : : | |
| |Diagnostics :Levels 2R/3 : Comp | |
+-----------+------------------------------------------------------+-------+
| DRB32 |Hardware/�code : T1022 C02 : Comp | |
| -M |Software Driver: UQDRIVER : Comp | Yes� |
| |Diagnostics : Level 3 : Diag supervisor doesn't| |
| | : : work with EVDRH. Being | |
| | : : fixed. | |
+-----------+------------------------------------------------------+-------+
| DRB32 |Hardware/�code :T1022 C02 w/ : Comp | |
| -W | :personality m: | |
| -E |Software Driver: UQDRIVER : Comp | Yes� |
| |Diagnostics : Level 3 : Diag supervisor doesn't| |
| | : : work with EVDRH. Being | |
| | : : fixed. | |
| | : Level 3 : EVDRI,EVDRJ work. | |
+-----------+------------------------------------------------------+-------+
BI Adapters for VAX 9000 Page 2
Last rev 9/28/90
Current rev 10/05/90
+-----------+------------------------------------------------------+-------+
| BI Device | Qualification Status |Support|
+-----------+------------------------------------------------------+-------+
| DRB32 |Hardware/�code :T1022 C02 w/ : Cray Interface remains | |
| -C | :personality m: to be tested | |
| |Software Driver: UQDRIVER : Comp | No� |
| |Diagnostics : Level 3 : Diag supervisor doesn't| |
| | : : work with EVDRH. Being | |
| | : : fixed. | |
| | : Level 3 : EVDRK works. | |
+-----------+------------------------------------------------------+-------+
| DEBNI |Hardware/�code :T1034 C5/3000: 512Mb address problems;| |
| |Software Driver: ETDRIVER : Works well @ <512 | No |
| |Diagnostics :Levels 2R/3 : Comp | |
+-----------+------------------------------------------------------+-------+
| K.LESI |Hardware/�code : T1014 BX01 : Comp | |
| w/RV20 |Software Driver: PUDRIVER : Comp | Yes |
| |Diagnostics :Levels 2R/3 : Comp | |
+-----------+------------------------------------------------------+-------+
| K.LESI |Hardware/�code : T1014 BX01 : | |
| w/RV64 |Software Driver: PUDRIVER : Testing is being done | No |
| | : YIDRIVER : in MRO. | |
| |Diagnostics :Levels 2R/3 : Comp | |
+-----------+------------------------------------------------------+-------+
| Multi-BI | 4 BI channel : : All 4 channels have | Yes |
| | per XMI : : been tested. | |
| | : : | |
+-----------+------------------------------------------------------+-------+
Footnotes:
�: Driver patches are required to get the adapter to function,
till permannent MCU fix is available. The patches to
SIDRIVER,YIDRIVER,LIDRIVER and PUDRIVER are available at:
VINO::RIPPLE:[tlitt.public]. Please refer to the memo on the
next page.
�: Functional Support only without diagnostic fault isolation coverage.
�: Cray interface testing is to be done by SW Eng group in ABQ.
Note:
Diagnostics' status based on their report dated 9/27.
From: VINO::TLITT "Tim Litt 30-Sep-1990 1033" 30-SEP-1990 10:45:23.80
To: TKTVFS::SUGANARA
CC: GWYNED::GANESAN,TLITT
Subj: DMB32 driver (& friends)
We have two interim solutions to the Mbox problem which is often associated
with the DMB32. The problem is described in detail in a recent CSSE advisory
put out by Gary Shepard. The permanent solution will be kernel rev C5.
Interim solution #1 (Recommended for all BI sites):
Install the following device drivers on SYS$LOADABLE_IMAGES:
LIDRIVER.EXE, PUDRIVER.EXE, SIDRIVER.EXE, YIDRIVER.EXE
They may be obtained from VINO::RIPPLE:[TLITT.PUBLIC].
PLEASE NOTE: This is a temporary solution. Save the original drivers,
as they must be restored when the hardware fix is available. Please
notify me of ALL sites which receive this code.
Interim solution #2 (Use only if solution #1 fails to resolve the problem at
a particular site. This is unlikely, but possible.)
1. Escalate to CSSE immediately.
2. Turn off one cache set. This can have a considerable effect on
performance, but is guaranteed to prevent the hardware problem.
Regards.
T
To Distribution List:
Rory O'DONNELL@UVO,
Dave WRIGHTON@UVO,
Andreas KAEMPFE@SUF,
Thomas RATSCH@MGO,
Gerd GABRYS@COO,
Roberto VERCELLI@TNO,
Maurizio MORRONE@RIO,
Walter GROSSI@MIO,
Daniel GONON@GVO,
MEIR ALON@ISO
|
| 78.67 | SJA and DMA's , does it work ? | KERNEL::WRIGHTON | odd numbered release = bug insert | Wed Oct 10 1990 08:05 | 48 |
|
Subject: SET SJA/(NO)DMA Clarifcation
Many of you have been asking about how SET SJA/(NO)DMA works since the
SJA never did do DMA correctly in the first place. We had the
requirement of setting /NODMA under version 10.3, but not for
subsequent releases, so many people are still playing with this switch
trying to see if it helps when they don't know what else to do. In at
least one case, it appeared to help (with a TEST/XJA command.
Unfortunately it's been documented that EVCLA [test/xja] still doesn't
work - even under BL 11, and two succesive runs may give you two
different results).
Since there is some confusion over what this command actually does, I
asked engineering to write me a definitive statement about what the
driver uses the /DMA flag for. Here is their reply:
Certainly, hardware DMA is permanently disabled. The problem is
that the SJA does not arbitrate DMA properly and will hang on
occasion. The software workaround was to program quadword transfers
to simulate the DMA function of the chip. The SJA can do quadword
transfers without using DMA. When a read transfer completes, the
SJA interrupts the uVAX to tell it the data is ready. The /DMA
mechanism will read the data from the SJA and put it in a buffer,
while still in the interrupt service routine. The next transfer
will be started from the interrupt service routine. When the
transfer is finished the interrupt service routine notifies the
driver process which requested the transfer. This saves a context
switch for each quadword and improves performance quite a bit. The
/NODMA mode notifies the process for each quadword. The software
does the same thing in both cases but stays in the interrupt
service routine for /DMA transfers. Write transfers are always
handled in the process as there is no return data. Therefore /DMA
only affects SPU read transfers.
The reason /NODMA mode fixed transfers in 10.3 was that the code in
the interrupt service routine did not do the final quadword. It was
a counter bug. I do not see how the mode could affect anything,
except on 10.3 systems. I believe it is a panacea, which should
only affect read transfer rate. Perhaps this can alter a failure
mode but it will not correct one.
[mrcsse::public:set_sja_dma.txt]
|
| 78.68 | New version of SDU | KERNEL::ODONNELLR | | Wed Oct 10 1990 23:23 | 715 |
| I have copied V2.0 of SDU_V.EXE to EXE$,and I have also copied the
following .CMD files:
CPU_ERRORS.CMD
SCU_ERRORS.CMD
CPU_MISC.CMD
SCUERRSUM.CMD
Following the <FF> a working example of using these .CMD files.
@SDU
AQUARIUS Snapshot Display Utility, V2.0
PROPERTY OF DIGITAL EQUIPMENT CORPORATION
SDU> LOAD/SNAP MERCURY_SNAP.DAT
%SDU-I-SOURCE, Data saved on node FRA at 10-AUG-1990 15:13:58.59
%SDU-I-SID, Saved system SID is 0E80502B
%SDU-I-CDBFILE, CPU 0 CDB filename: B4_CPU
%SDU-I-CDBFILE, SCU CDB filename: B3_SCU
%SDU-I-SNAPTYPE, Snapshot type is TRIGGER
%SDU-I-CDBLOAD, Loading SYS$DATA:B4_CPU.CDB for unit(s) CP0
%SDU-I-CDBLOAD, Loading SYS$DATA:B3_SCU.CDB for unit(s) SCU
SDU> @CPU_ERRORS
[EBOX ERRORS]
Error checking for EBOX - CTL MCU -
%SDU-I-LOADING, Loading descriptors from SYS$DATA:B4_CPU.CDB
Error checking for EBOX - INT MCU -
Error checking for EBOX - DST MCU -
Error checking for EBOX - FAD MCU -
Error checking for EBOX - MUL MCU -
[IBOX ERRORS]
Checking IBOX FETCH ERROR REGISTER
Checking IBOX DECODE ERROR REGISTER
Checking IBOX SPECIFIER ERROR REGISTER
Checking FETCH Errors
Checking DECODE Errors
Checking SPECIFIER Errors
Delayed Errors
[MBOX ERRORS]
Error checking for MBOX - DTA MCU -
Error checking for MBOX - DTB MCU -
Error checking for MBOX - VAP MCU -
%CPU0.VAP.CCSQ.ERROR_CON.ENABLE_ERROR_REP_TA_H<0> = 1
%CPU0.VAP.CCSQ.JCON.NO_ERROR_SWEEP_H<0> = 0
Error checking for MBOX - CTU MCU -
[VBOX ERRORS]
Checking Vbox parity
Vbox errors are disabled
Checking parity on VRG
Checking parity on UCS
Checking parity errors on VAD
Checking parity errors on VML
SDU> @SCU_ERRORS
CTLA detected errors...
Error if any 1's
Scope = %SCU, Model = SCU, Revision = A
%SDU-I-LOADING, Loading descriptors from SYS$DATA:B3_SCU.CDB
%SCU.CCU.CTLA.PRTERR_H<7:0> = 00
%SCU.CCU.CTLA.MRMERR_H<0> = 0
%SCU.CCU.CTLA.CTLCERR_H<0> = 0
%SCU.CCU.CTLA.PRTENAERR_H<0> = 0
%SCU.CCU.CTLA.CDCX_ATTENTION_H<0> = 0
CTLB detected errors...
Error if any 1's
%SCU.CCU.CTLB.CTLC_CTL_PARERR_H<0> = 0
%SCU.CCU.CTLB.CTLA_CTL_PARERR_H<0> = 0
%SCU.CCU.CTLB.MICR_CMD_MPARERR_H<0> = 0
%SCU.CCU.CTLB.MICR_CMD_MCPARERR_H<0> = 0
CTLC detected errors...
Error if any 1's
%SCU.CCU.CTLC.MRMERR_H<0> = 0
%SCU.CCU.CTLC.DSCTERR_H<0> = 0
%SCU.CCU.CTLC.NPAMERR_H<0> = 0
%SCU.CCU.CTLC.MPAMERR_H<0> = 0
%SCU.CCU.CTLC.IPAMERR_H<0> = 0
%SCU.CCU.CTLC.CTLARDYERR_H<0> = 0
%SCU.CCU.CTLC.CTLBERR_H<0> = 0
%SCU.CCU.CTLC.MICRERR_H<0> = 0
%SCU.CCU.CTLC.MICRSRVERR_H<0> = 0
CTLD detected errors...
Error if any 1's
%SCU.CCU.CTLD.ERROR_LAT_H<15:0> = 9000
DSCT detected errors...
Error if any 0's
%SCU.CCU.DSCT.DSCT_CTLC_FATALERR_L<0> = 1
MICR detected errors...
Error if any 1's
%SCU.CCU.MICR.ERROR_LAT_H<14:0> = 0000
ADRX detected errors...
Error if any 1's
%SCU.TAG.ADR0.PAR_ERR_CTLA_B_H<0> = 0
%SCU.TAG.ADR0.PAR_ERR_CTLC_B_H<0> = 0
%SCU.TAG.ADR0.L009.PARITY_ERR_B_H<0> = 0
%SCU.TAG.ADR0.L004.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR0.L005.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR0.L000.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR0.L001.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR0.L002.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR0.L003.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR0.L007.PAR_ERR_PA_B_H<0> = 0
%SCU.TAG.ADR0.L007.PAR_ERR_MMC_B_H<0> = 0
%SCU.TAG.ADR0.L008.PAR_ERR_PA_B_H<0> = 0
%SCU.TAG.ADR0.L008.PAR_ERR_MMC_B_H<0> = 1
%SCU.TAG.ADR0.L006.ADR_PAR_ERR_LK_B_H<0> = 1
%SCU.TAG.ADR0.L030.ADR_PAR_ERR_LK_B_H<0> = 1
%SCU.TAG.ADR1.PAR_ERR_CTLA_B_H<0> = 0
%SCU.TAG.ADR1.PAR_ERR_CTLC_B_H<0> = 0
%SCU.TAG.ADR1.L009.PARITY_ERR_B_H<0> = 0
%SCU.TAG.ADR1.L004.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR1.L005.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR1.L000.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR1.L001.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR1.L002.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR1.L003.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR1.L007.PAR_ERR_PA_B_H<0> = 1
%SCU.TAG.ADR1.L007.PAR_ERR_MMC_B_H<0> = 0
%SCU.TAG.ADR1.L008.PAR_ERR_PA_B_H<0> = 1
%SCU.TAG.ADR1.L008.PAR_ERR_MMC_B_H<0> = 1
%SCU.TAG.ADR1.L006.ADR_PAR_ERR_LK_B_H<0> = 1
%SCU.TAG.ADR1.L030.ADR_PAR_ERR_LK_B_H<0> = 1
%SCU.TAG.ADR2.PAR_ERR_CTLA_B_H<0> = 0
%SCU.TAG.ADR2.PAR_ERR_CTLC_B_H<0> = 0
%SCU.TAG.ADR2.L009.PARITY_ERR_B_H<0> = 0
%SCU.TAG.ADR2.L004.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR2.L005.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR2.L000.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR2.L001.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR2.L002.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR2.L003.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR2.L007.PAR_ERR_PA_B_H<0> = 1
%SCU.TAG.ADR2.L007.PAR_ERR_MMC_B_H<0> = 0
%SCU.TAG.ADR2.L008.PAR_ERR_PA_B_H<0> = 1
%SCU.TAG.ADR2.L008.PAR_ERR_MMC_B_H<0> = 1
%SCU.TAG.ADR2.L006.ADR_PAR_ERR_LK_B_H<0> = 1
%SCU.TAG.ADR2.L030.ADR_PAR_ERR_LK_B_H<0> = 1
%SCU.TAG.ADR3.PAR_ERR_CTLA_B_H<0> = 0
%SCU.TAG.ADR3.PAR_ERR_CTLC_B_H<0> = 0
%SCU.TAG.ADR3.L009.PARITY_ERR_B_H<0> = 0
%SCU.TAG.ADR3.L004.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR3.L005.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR3.L000.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR3.L001.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR3.L002.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR3.L003.PAR_ERR_B_H<0> = 0
%SCU.TAG.ADR3.L007.PAR_ERR_PA_B_H<0> = 1
%SCU.TAG.ADR3.L007.PAR_ERR_MMC_B_H<0> = 0
%SCU.TAG.ADR3.L008.PAR_ERR_PA_B_H<0> = 1
%SCU.TAG.ADR3.L008.PAR_ERR_MMC_B_H<0> = 1
%SCU.TAG.ADR3.L006.ADR_PAR_ERR_LK_B_H<0> = 1
%SCU.TAG.ADR3.L030.ADR_PAR_ERR_LK_B_H<0> = 1
State of the various error enables....
%SCU.CCU.CTLA.DISFATERR_H<0> = 1
%SCU.CCU.CTLB.DISABLERR_H<0> = 0
%SCU.CCU.CTLC.ERRDISA_H<0> = 0
%SCU.CCU.CTLD.ENA_ERR_H<14:0> = 06F3
%SCU.CCU.DSCT.DIS_ERROR_H<1:0> = 0
%SCU.CCU.MICR.ENA_ERR_H<0> = 1
%SCU.TAG.ADR0.L011.QANOT<0> = 1
Scope = %CPU0, Model = CPU, Revision = A
SDU> @CPU_MISC
Get uPC's
Currently executing....
%CPU0.INT.USQA.CHECK_FOR_STOP_BIT_H<0> = 0
%CPU0.INT.USQA.CHECK_FPD_H<0> = 0
%CPU0.INT.USQA.CHECK_INTERRUPT_PARITY_H<0> = 0
%CPU0.INT.USQA.CHECK_UPC_H<3:0> = 8
%CPU0.INT.USQB.CHECK_FPD_H<0> = 0
%CPU0.INT.USQB.CHECK_UPC_H<10:4> = 2B
%CPU0.INT.USQC.CHECK_IF_PME_L<0> = 1
%CPU0.INT.USQC.CHECK_UPC_H<11> = 0
Being accessed....
%CPU0.INT.USQA.THIS_UPC_H<3:0> = 5
%CPU0.INT.USQB.THIS_UPC_H<10:4> = 7B
%CPU0.INT.USQC.THIS_UPC_H<11> = 0
Will produce the 4 microstack locations
%CPU0.INT.USQA.PREV_USTACK_PTR_H<1:0> = 2
%CPU0.INT.USQA.USTACK_0_H<3:0> = E
%CPU0.INT.USQA.USTACK_1_H<3:0> = 4
%CPU0.INT.USQA.USTACK_2_H<3:0> = E
%CPU0.INT.USQA.USTACK_3_H<3:0> = 8
%CPU0.INT.USQA.USTACK_DLY_H<3:0> = 0
%CPU0.INT.USQA.USTACK_PTR_H<1:0> = 2
%CPU0.INT.USQB.PREV_USTACK_PTR_H<1:0> = 2
%CPU0.INT.USQB.USTACK_0_H<10:4> = 46
%CPU0.INT.USQB.USTACK_1_H<10:4> = 00
%CPU0.INT.USQB.USTACK_2_H<10:4> = 46
%CPU0.INT.USQB.USTACK_3_H<10:4> = 23
%CPU0.INT.USQB.USTACK_DLY_H<10:4> = 00
%CPU0.INT.USQB.USTACK_PTR_H<1:0> = 2
%CPU0.INT.USQC.PREV_USTACK_PTR_H<1:0> = 2
%CPU0.INT.USQC.USTACK_0_H<11> = 1
%CPU0.INT.USQC.USTACK_1_H<11> = 1
%CPU0.INT.USQC.USTACK_2_H<11> = 1
%CPU0.INT.USQC.USTACK_3_H<11> = 0
%CPU0.INT.USQC.USTACK_DLY_H<11> = 0
%CPU0.INT.USQC.USTACK_PTR_H<1:0> = 2
Macro PC's (PC queue, load ptr and size of queue)
%CPU0.CTL.QPCS.PC0_H<31:0> = 80E776EA
%CPU0.CTL.QPCS.PC1_H<31:0> = 80E776EF
%CPU0.CTL.QPCS.PC2_H<31:0> = 80E776F5
%CPU0.CTL.QPCS.PC3_H<31:0> = 80E79494
%CPU0.CTL.QPCS.PC4_H<31:0> = 80E75BD0
%CPU0.CTL.QPCS.PC5_H<31:0> = 80E776DC
%CPU0.CTL.QPCS.PC6_H<31:0> = 80E776DF
%CPU0.CTL.QPCS.PC7_H<31:0> = 80E776E3
Fork Queue (Fram output, load ptr, size, remove ptr)
%CPU0.CTL.QPTR.FORKQ0_H<15:0> = 103C
%CPU0.CTL.QPTR.FORKQ1_H<15:0> = 1097
%CPU0.CTL.QPTR.FORKQ2_H<15:0> = 0018
%CPU0.CTL.QPTR.FORKQ3_H<15:0> = 10D0
%CPU0.CTL.QPTR.FORKQ4_H<15:0> = 30E6
%CPU0.CTL.QPTR.FORKQ5_H<15:0> = 3016
%CPU0.CTL.QPTR.FORKQ6_H<15:0> = 00D4
%CPU0.CTL.QPTR.FORKQ7_H<15:0> = 1005
Source Queue, (Remove pointer, size, load ptr)
%CPU0.CTL.QPTR.SRCQ00_H<4:0> = 07
%CPU0.CTL.QPTR.SRCQ01_H<4:0> = 08
%CPU0.CTL.QPTR.SRCQ02_H<4:0> = 09
%CPU0.CTL.QPTR.SRCQ03_H<4:0> = 0A
%CPU0.CTL.QPTR.SRCQ04_H<4:0> = 0B
%CPU0.CTL.QPTR.SRCQ05_H<4:0> = 0C
%CPU0.CTL.QPTR.SRCQ06_H<4:0> = 0D
%CPU0.CTL.QPTR.SRCQ07_H<4:0> = 0E
%CPU0.CTL.QPTR.SRCQ08_H<4:0> = 11
%CPU0.CTL.QPTR.SRCQ09_H<4:0> = 01
%CPU0.CTL.QPTR.SRCQ10_H<4:0> = 02
%CPU0.CTL.QPTR.SRCQ11_H<4:0> = 03
%CPU0.CTL.QPTR.SRCQ12_H<4:0> = 1E
%CPU0.CTL.QPTR.SRCQ13_H<4:0> = 04
%CPU0.CTL.QPTR.SRCQ14_H<4:0> = 05
%CPU0.CTL.QPTR.SRCQ15_H<4:0> = 06
Destination Queue, (Remove ptr, load ptr, size)
%CPU0.CTL.QPTR.DESTQ0_H<4:0> = 03
%CPU0.CTL.QPTR.DESTQ1_H<4:0> = 0E
%CPU0.CTL.QPTR.DESTQ2_H<4:0> = 02
%CPU0.CTL.QPTR.DESTQ3_H<4:0> = 01
%CPU0.CTL.QPTR.DESTQ4_H<4:0> = 15
%CPU0.CTL.QPTR.DESTQ5_H<4:0> = 04
%CPU0.CTL.QPTR.DESTQ6_H<4:0> = 10
%CPU0.CTL.QPTR.DESTQ7_H<4:0> = 11
Result Queue
%CPU0.CTL.ISSB.XRESQUEUE0_00_H<8:0> = 18F
%CPU0.CTL.ISSB.XRESQUEUE0_00_H<26:22> = 0A
%CPU0.CTL.ISSB.XRESQUEUE0_00_L<8:0> = 070
%CPU0.CTL.ISSB.XRESQUEUE0_00_L<26:22> = 15
%CPU0.CTL.ISSB.XRESQUEUE1_00_H<8:0> = 1BF
%CPU0.CTL.ISSB.XRESQUEUE1_00_H<23> = 0
%CPU0.CTL.ISSB.XRESQUEUE2_00_H<8:0> = 184
%CPU0.CTL.ISSB.XRESQUEUE2_00_H<23> = 1
%CPU0.CTL.ISSB.XRESQUEUE2_A00_H<8:0> = 184
%CPU0.CTL.ISSB.XRESQUEUE2_A00_H<23> = 1
%CPU0.CTL.ISSB.XRESQUEUE3_00_H<8:0> = 1B1
%CPU0.CTL.ISSB.XRESQUEUE3_00_H<23> = 1
%CPU0.CTL.ISSB.XRESQUEUE3_A00_H<8:0> = 1B1
%CPU0.CTL.ISSB.XRESQUEUE3_A00_H<23> = 1
%CPU0.CTL.ISSB.XRESQUEUE4_00_H<8:0> = 18F
%CPU0.CTL.ISSB.XRESQUEUE4_00_H<23> = 1
%CPU0.CTL.ISSB.XRESQUEUE4_A00_H<8:0> = 18F
%CPU0.CTL.ISSB.XRESQUEUE4_A00_H<23> = 1
%CPU0.CTL.ISSB.XRESQUEUE5_00_H<8:0> = 18F
%CPU0.CTL.ISSB.XRESQUEUE5_00_H<23> = 0
%CPU0.CTL.ISSB.XRESQUEUE5_A00_H<8:0> = 18F
%CPU0.CTL.ISSB.XRESQUEUE5_A00_H<23> = 0
%CPU0.CTL.ISSB.XRESQUEUE6_00_H<8:0> = 18F
%CPU0.CTL.ISSB.XRESQUEUE6_00_H<23> = 1
%CPU0.CTL.ISSB.XRESQUEUE6_A00_H<8:0> = 18F
%CPU0.CTL.ISSB.XRESQUEUE6_A00_H<23> = 1
%CPU0.CTL.ISSB.XRESQUEUE7_00_H<8:0> = 18F
%CPU0.CTL.ISSB.XRESQUEUE7_00_H<23> = 1
%CPU0.CTL.ISSB.XRESQUEUE7_A00_H<8:0> = 18F
%CPU0.CTL.ISSB.XRESQUEUE7_A00_H<23> = 1
%CPU0.CTL.ISSC.XRESQUEUE0_00_H<9> = 0
%CPU0.CTL.ISSC.XRESQUEUE0_00_H<11> = 0
%CPU0.CTL.ISSC.XRESQUEUE0_00_H<23> = 0
%CPU0.CTL.ISSC.XRESQUEUE1_00_H<9> = 0
%CPU0.CTL.ISSC.XRESQUEUE1_00_H<11> = 0
%CPU0.CTL.ISSC.XRESQUEUE1_00_H<23> = 0
%CPU0.CTL.ISSC.XRESQUEUE2_00_H<9> = 0
%CPU0.CTL.ISSC.XRESQUEUE2_00_H<11> = 0
%CPU0.CTL.ISSC.XRESQUEUE2_00_H<23> = 0
%CPU0.CTL.ISSC.XRESQUEUE3_00_H<9> = 0
%CPU0.CTL.ISSC.XRESQUEUE3_00_H<11> = 0
%CPU0.CTL.ISSC.XRESQUEUE3_00_H<23> = 0
%CPU0.CTL.ISSC.XRESQUEUE4_00_H<9> = 0
%CPU0.CTL.ISSC.XRESQUEUE4_00_H<11> = 0
%CPU0.CTL.ISSC.XRESQUEUE4_00_H<23> = 0
%CPU0.CTL.ISSC.XRESQUEUE5_00_H<9> = 0
%CPU0.CTL.ISSC.XRESQUEUE5_00_H<11> = 0
%CPU0.CTL.ISSC.XRESQUEUE5_00_H<23> = 0
%CPU0.CTL.ISSC.XRESQUEUE6_00_H<9> = 0
%CPU0.CTL.ISSC.XRESQUEUE6_00_H<11> = 0
%CPU0.CTL.ISSC.XRESQUEUE6_00_H<23> = 0
%CPU0.CTL.ISSC.XRESQUEUE7_00_H<9> = 0
%CPU0.CTL.ISSC.XRESQUEUE7_00_H<11> = 0
%CPU0.CTL.ISSC.XRESQUEUE7_00_H<23> = 0
%CPU0.CTL.ISSD.XRESQUEUE0_00_H<11> = 0
%CPU0.CTL.ISSD.XRESQUEUE0_00_H<21:20> = 0
%CPU0.CTL.ISSD.XRESQUEUE0_00_H<23> = 0
%CPU0.CTL.ISSD.XRESQUEUE1_00_H<11> = 0
%CPU0.CTL.ISSD.XRESQUEUE1_00_H<23> = 0
%CPU0.CTL.ISSD.XRESQUEUE2_00_H<23> = 0
%CPU0.CTL.ISSD.XRESQUEUE3_00_H<23> = 0
%CPU0.CTL.ISSD.XRESQUEUE4_00_H<23> = 0
%CPU0.CTL.ISSD.XRESQUEUE5_00_H<23> = 0
%CPU0.CTL.ISSD.XRESQUEUE6_00_H<23> = 0
%CPU0.CTL.ISSD.XRESQUEUE7_00_H<23> = 0
%CPU0.CTL.ISSE.XRESQUEUE0_00_H<22:12> = 000
%CPU0.CTL.ISSE.XRESQUEUE0_00_H<26:24> = 0
%CPU0.CTL.ISSE.XRESQUEUE1_00_H<10> = 0
%CPU0.CTL.ISSE.XRESQUEUE1_00_H<22:12> = 000
%CPU0.CTL.ISSE.XRESQUEUE1_00_H<26:24> = 0
%CPU0.CTL.ISSE.XRESQUEUE2_00_H<10> = 0
%CPU0.CTL.ISSE.XRESQUEUE2_00_H<22:12> = 000
%CPU0.CTL.ISSE.XRESQUEUE2_00_H<26:24> = 0
%CPU0.CTL.ISSE.XRESQUEUE3_00_H<10> = 0
%CPU0.CTL.ISSE.XRESQUEUE3_00_H<22:12> = 000
%CPU0.CTL.ISSE.XRESQUEUE3_00_H<26:24> = 0
%CPU0.CTL.ISSE.XRESQUEUE4_00_H<10> = 0
%CPU0.CTL.ISSE.XRESQUEUE4_00_H<22:12> = 000
%CPU0.CTL.ISSE.XRESQUEUE4_00_H<26:24> = 0
%CPU0.CTL.ISSE.XRESQUEUE5_00_H<10> = 0
%CPU0.CTL.ISSE.XRESQUEUE5_00_H<22:12> = 000
%CPU0.CTL.ISSE.XRESQUEUE5_00_H<26:24> = 0
%CPU0.CTL.ISSE.XRESQUEUE6_00_H<10> = 0
%CPU0.CTL.ISSE.XRESQUEUE6_00_H<22:12> = 000
%CPU0.CTL.ISSE.XRESQUEUE6_00_H<26:24> = 0
%CPU0.CTL.ISSE.XRESQUEUE7_00_H<10> = 0
%CPU0.CTL.ISSE.XRESQUEUE7_00_H<22:12> = 000
%CPU0.CTL.ISSE.XRESQUEUE7_00_H<26:24> = 0
Examine the SLIST and MTEMP valid and fault bits to further
piece things together. Also, whether or not there are
memory faults signaled to the Ebox.
%CPU0.CTL.ISSA.XMEM_TEMP_FAULT_00_H<15:0> = 0000
%CPU0.CTL.ISSA.XSRC_LIST_FAULT_00_H<15:0> = 0000
%CPU0.CTL.ISSA.ZMBOX_EB_PAGE_FAULT_00_H<0> = 0
%CPU0.CTL.ISSA.ZMBOX_EB_PAGE_FAULT_00_L<0> = 1
%CPU0.CTL.ISSC.XDLY_MBOX_FAULT_00_H<0> = 0
%CPU0.CTL.ISSC.XDLY_MBOX_FAULT_00_L<0> = 1
%CPU0.CTL.ISSC.XDLY_MBOX_FAULT_VALID_00_H<0> = 0
%CPU0.CTL.ISSC.XDLY_MBOX_Q_FAULT_00_H<0> = 0
%CPU0.CTL.ISSC.XDLY_MBOX_Q_FAULT_00_L<0> = 1
%CPU0.CTL.ISSC.XDLY_MBOX_Q_FAULT_VALID_00_H<0> = 1
%CPU0.CTL.ISSC.ZMBOX_EB_QFAULT_SYNC_B00_H<0> = 1
%CPU0.CTL.ISSC.ZMBOX_EB_Q_FAULT_SYNC_00_H<0> = 1
%CPU0.CTL.ISSC.ZMBOX_EB_Q_FAULT_SYNC_00_L<0> = 0
%CPU0.CTL.ISSD.TA_MBOX_EB_FAULT_H<0> = 0
%CPU0.CTL.ISSD.TA_MBOX_EB_FAULT_VAL_H<0> = 0
%CPU0.CTL.ISSD.ZMBOX_EB_PAGE_FAULT_A00_H<0> = 0
Macro PC history buffer....
%SDU-W-ERRINDATA, section I_STREAM was collected with errors
History from CPU 0 PCHB buffer
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BB8 instruction decode error
80E75BBB instruction decode error
80E75BAA instruction decode error
80E75BB2 instruction decode error
80E75BC0 instruction decode error
80E75BC3 instruction decode error
80E75BC9 instruction decode error
802B4F24 instruction decode error
802B4F27 instruction decode error
802B4F29 instruction decode error
802B4F2C instruction decode error
802B4F33 instruction decode error
802B4F38 instruction decode error
802B4F3B instruction decode error
802B4F3E instruction decode error
802B4F41 instruction decode error
80E75BCA instruction decode error
80E75BCD instruction decode error
80E75BD0 instruction decode error
80E776DC instruction decode error
80E776DF instruction decode error
80E776E3 instruction decode error
80E776EA instruction decode error
Jbox Micro PC's....
History from SCU MRM buffer
00000000
0000014F
0000006E
00000000
0000014F
0000006E
00000000
0000014F
0000006E
00000000
0000014F
0000006E
00000000
0000014F
0000006E
00000000
0000014F
0000006E
00000000
0000014F
0000006E
00000000
0000014F
0000006E
00000000
0000014F
0000006E
00000000
0000014F
0000006E
00000000
0000014F
0000006E
00000000
0000014F
0000006E
00000000
0000014F
0000006E
00000000
0000014F
0000006E
00000000
0000014F
0000006E
00000000
0000014F
0000006E
00000000
0000014F
Other nice to know scan latches...
%CPU0.INT.RLOG.SPU_OK_H<0> = 1
%CPU0.CTU.CTMV.SET_SEL_H<1:0> = 0
Some other nice SDU commands
System power....
SCU/CPA
BUS A BUS B BUS C BUS D
MARGIN NOM NOM NOM NOM
VOLTS +4.997V +5.000V -3.395V -5.205V AMPS
REG 0 004.0A 004.0A 112.0A 127.0A
REG 1 ----- 008.0A 108.0A 134.0A
REG 2 ----- ----- 112.0A 132.0A
TOTAL 004.0A 012.0A 332.0A 393.0A STATUS
GROUP OK OK OK OK
CROWBAR ----- ----- ----- OK
BUS OK OK OK OK
REG 0 OK OK OK OK
REG 1 ----- OK OK OK
REG 2 ----- ----- OK OK
BIAS 0 OK OK OK OK
CR BIAS 0 ----- ----- ----- OK
XMI power....
XMI A XMI B
7214 A 7215 A 7214 B 7215 B 7214 A 7215 A 7214 B 7215 B
STATUS
REG OK OK OK OK OK OK OK OK OK
BIAS A OK Fail
BIAS B OK OK
BI AA BI AB
REG K1 REG K2 REG K3 REG K4 REG K1 REG K2 REG K3 REG K4
STATUS
REG OK -- -- -- -- -- -- -- --
BI BA BI BB
REG K1 REG K2 REG K3 REG K4 REG K1 REG K2 REG K3 REG K4
STATUS
REG OK -- -- -- -- -- -- -- --
System envirment....
SCU/CPA
AIR
FAN 1 TEMP 21.68C
STATUS NOM
FAN 2 TEMP 20.36C
STATUS NOM
FAN 3 TEMP 23.71C
STATUS NOM
AMBIENT TEMP 18.12C
STATUS NOM
STATUS
AIR FLOW 1 OK
AIR FLOW 2 OK
AIR FLOW 3 OK
AIR FLOW 4 OK
AIR FLOW 5 OK
AIR FLOW 6 OK
XJA registers, check to see if you have a XJA1
ERRS: FFFFFFFF
FCMD: FFFFFFFF
IPINTRSRC: FFFFFFFF
DIAG: FFFFFFFF
DMAFADDR: FFFFFFFF
DMACMD: FFFFFFFF
ERRINTR: FFFFFFFF
CNF: FFFFFFFF
XBIIDA: FFFFFFFF
XBIIDB: FFFFFFFF
ERRSCB: FFFFFFFF
CPU scan rings....
Scan rings saved for CPU 0
MCU: 00, Ring: 0C, Length: 16
MCU: 00, Ring: 0D, Length: 14
MCU: 00, Ring: 0E, Length: 47
MCU: 00, Ring: 0F, Length: 816
MCU: 01, Ring: 0C, Length: 16
MCU: 01, Ring: 0D, Length: 14
MCU: 01, Ring: 0E, Length: 47
MCU: 01, Ring: 0F, Length: 1036
MCU: 02, Ring: 0C, Length: 16
MCU: 02, Ring: 0D, Length: 14
MCU: 02, Ring: 0E, Length: 47
MCU: 02, Ring: 0F, Length: 807
MCU: 03, Ring: 0C, Length: 16
MCU: 03, Ring: 0D, Length: 14
MCU: 03, Ring: 0E, Length: 47
MCU: 03, Ring: 0F, Length: 828
MCU: 04, Ring: 0C, Length: 16
MCU: 04, Ring: 0D, Length: 14
MCU: 04, Ring: 0E, Length: 47
MCU: 04, Ring: 0F, Length: 1158
MCU: 05, Ring: 0C, Length: 16
MCU: 05, Ring: 0D, Length: 14
MCU: 05, Ring: 0E, Length: 47
MCU: 05, Ring: 0F, Length: 1179
MCU: 06, Ring: 0C, Length: 16
MCU: 06, Ring: 0D, Length: 14
MCU: 06, Ring: 0E, Length: 47
MCU: 06, Ring: 0F, Length: 1192
MCU: 07, Ring: 0C, Length: 16
MCU: 07, Ring: 0D, Length: 14
MCU: 07, Ring: 0E, Length: 47
MCU: 07, Ring: 0F, Length: 421
MCU: 08, Ring: 0C, Length: 16
MCU: 08, Ring: 0D, Length: 14
MCU: 08, Ring: 0E, Length: 47
MCU: 08, Ring: 0F, Length: 1058
MCU: 09, Ring: 0C, Length: 16
MCU: 09, Ring: 0D, Length: 14
MCU: 09, Ring: 0E, Length: 47
MCU: 09, Ring: 0F, Length: 1024
MCU: 0A, Ring: 0C, Length: 16
MCU: 0A, Ring: 0D, Length: 14
MCU: 0A, Ring: 0E, Length: 47
MCU: 0A, Ring: 0F, Length: 828
MCU: 0B, Ring: 0C, Length: 16
MCU: 0B, Ring: 0D, Length: 14
MCU: 0B, Ring: 0E, Length: 47
MCU: 0B, Ring: 0F, Length: 1608
MCU: 0C, Ring: 0C, Length: 16
MCU: 0C, Ring: 0D, Length: 14
MCU: 0C, Ring: 0E, Length: 47
MCU: 0C, Ring: 0F, Length: 586
MCU: 0D, Ring: 0F, Length: 1369
MCU: 0E, Ring: 0F, Length: 1640
MCU: 0F, Ring: 0F, Length: 1013
SCU scan rings....
Scan rings saved for SCU
MCU: 00, Ring: 0C, Length: 16
MCU: 00, Ring: 0D, Length: 14
MCU: 00, Ring: 0E, Length: 47
MCU: 00, Ring: 0F, Length: 1345
MCU: 01, Ring: 0C, Length: 16
MCU: 01, Ring: 0D, Length: 14
MCU: 01, Ring: 0E, Length: 47
MCU: 01, Ring: 0F, Length: 1833
MCU: 02, Ring: 0C, Length: 16
MCU: 02, Ring: 0D, Length: 14
MCU: 02, Ring: 0E, Length: 47
MCU: 02, Ring: 0F, Length: 1189
MCU: 03, Ring: 0C, Length: 16
MCU: 03, Ring: 0D, Length: 14
MCU: 03, Ring: 0E, Length: 47
MCU: 03, Ring: 0F, Length: 1729
MCU: 04, Ring: 0F, Length: 1833
MCU: 05, Ring: 0F, Length: 1729
SDU> @SCUERRSUM
Scope = %SCU, Model = SCU, Revision = A
%SCU.CCU.CTLA.CDCX_ATTENTION_H<0> = 0
%SCU.TAG.MTCH.MTCH_CDC_LCK_B_H<0> = 0
%SCU.DA0.JDC0.JDCX_CCU_DAX_FATAL_H<0> = 0
%SCU.DA1.JDC0.JDCX_CCU_DAX_FATAL_H<0> = 0
%SCU.DB0.MMC0.INBF.L136.QA<0> = 0
%SCU.DB0.MMC0.INBF.LATMDPAPERR_H<0> = 0
%SCU.DB0.MMC0.INBF.LATMDPBPERR_H<0> = 0
%SCU.DB0.MMC0.INBF.LATCTLXPERR_H<0> = 0
%SCU.DB0.MMC0.INBF.LATDSA2PERR_H<0> = 0
%SCU.DB0.MMC0.INBF.LATADRXPERR_H<0> = 0
%SCU.DB0.MMC0.INBF.LATDSB2PERR_H<0> = 0
%SCU.DB0.MMC0.INBF.MAC0ADRPERR_H<0> = 0
%SCU.DB0.MMC0.INBF.MAC1ADRPERR_H<0> = 0
%SCU.DB0.MMC0.INBF.MAC2ADRPERR_H<0> = 0
%SCU.DB0.MMC0.INBF.MAC3ADRPERR_H<0> = 0
%SCU.DB0.MMC0.INBF.LATMCDXPERR_H<0> = 0
%SCU.DB1.MMC0.INBF.L136.QA<0> = 0
%SCU.DB1.MMC0.INBF.LATMDPAPERR_H<0> = 0
%SCU.DB1.MMC0.INBF.LATMDPBPERR_H<0> = 0
%SCU.DB1.MMC0.INBF.LATCTLXPERR_H<0> = 0
%SCU.DB1.MMC0.INBF.LATDSA2PERR_H<0> = 0
%SCU.DB1.MMC0.INBF.LATADRXPERR_H<0> = 0
%SCU.DB1.MMC0.INBF.LATDSB2PERR_H<0> = 0
%SCU.DB1.MMC0.INBF.MAC0ADRPERR_H<0> = 0
%SCU.DB1.MMC0.INBF.MAC1ADRPERR_H<0> = 0
%SCU.DB1.MMC0.INBF.MAC2ADRPERR_H<0> = 0
%SCU.DB1.MMC0.INBF.MAC3ADRPERR_H<0> = 0
%SCU.DB1.MMC0.INBF.LATMCDXPERR_H<0> = 0
Scope = %CPU0, Model = CPU, Revision = A
SDU>
|
| 78.69 | | KERNEL::WRIGHTON | odd numbered release = bug insert | Thu Oct 11 1990 08:00 | 65 |
|
****************** WARNING ************************
TO ALL VAX 9000 MODEL 4XX INSTALLERS
Recent airflow modifications in the Model 4XX
have resulted in plastic air shields on the
power backplanes that surround the H7380 output
leads. Unfortunately, this plastic cover the
silkscreened identification for these leads and
a ground (GND) post on the Bus D Backplane is
being mistaken as the Return (RTN) output identifier.
+=============================================================+
# WARNING: The Plastic air seals cover the Silkscreened #
# identification of the H7380 Outputs. #
# #
# Reversing these leads during model 410/420 #
# installation will damage the Master Clock #
# Module and all the System Memory Modules. #
+=============================================================+
If in doubt, carefulley peel back the upper area of
the airseal to reveal the silkscreen identification
View from rear of Model 410 CPA Cabinet
B U S D
(power for system memory)
GND o <--------+ ground post
+---------------------------------------------+
| RTN +5v | <----+ Plastic air seal
| + - - - - - - - - - - - - - - - - - + |
| +==========+ +===========+ |
| | # # # # |<----+ Actual backplane opening
| +==========+ +===========+ |
| + - - - ^ - - - - - - - - ^ - - - + |
+ | | +
\ +- H7380 outputs -+ /
+-----------------------------------------+
GND o <--------+ ground post
+---------------------------------------------+
| RTN +5v | <----+ Plastic air seal
| + - - - - - - - - - - - - - - - - - + |
| +==========+ +===========+ |
| | # # # # |<----+ Actual backplane opening
| +==========+ +===========+ |
| + - - - ^ - - - - - - - - ^ - - - + |
+ | | +
\ +- H7380 outputs -+ /
+-----------------------------------------+
|
| 78.71 | 9000 Diag report | KERNEL::ODONNELLR | | Tue Oct 16 1990 11:57 | 1931 |
|
*********************************
*********************************
Diagnostic Checklist for 10/10/90 10:00:00
*********************************
*********************************
********************************************************
********************************************************
ABSTRACT of changes since last release (11.0)
********************************************************
********************************************************
Now that a 9000_420 (AS1) is available in the lab, we are using
two shifts to run regression test of the diags on a DUAL config.
Additional hardware options are needed to complete these tasks.
VDS/KA9000_210/KA9000_410/KA9000_420
EWSAA - VAX Diag Supervisor 13.2-1253
Author has supplied an PRELIMINARY COPY and we have restarted
regression testing.
VDS/KA9000_420
EVSBA Autosizer (7.2)/EWSAA - VAX Diag Supervisor 13.2-1253
There is a problem when using CPU1 as the primary boot. This
MAY BE the 'ROUND-ROBIN' issue. There is no 'fix' at this moment
but one in the works (Dont run Autosizer or any diags that
interrupt {ie: EVKAS/T or I/O diags etc} when CPU1 is
primary boot - results unpredictable).
KA900/420 DS>START or DS>START/SECTION=DEFAULT
EWKMP - LEVEL 3 Multi-Port Exerciser - V001.004
Test 9 fails when 2 cpus are selected. The interrupt from
CPU1 is not received. Error #8 is the reported error in
subtest 2. Author has supplied an ADVANCE COPY (V1.5) but
this does not fix test 9 failures.
KA900/420 DS>START/SECTION=MULTI
EWKMP - LEVEL 3 Multi-Port Exerciser - V001.004
Test 10 (XJA ARBITRATION ERROR)
There appears to be an 'intermittent' failing of test 10.
This has been seen very intermittently on one machine. Another
machine has failed more frequently. Author has supplied
an ADVANCE COPY (V1.5) and we have started regression testing.
KA900/xxx
EWKAX - LEVEL 3 Kernel Architectural Diag - V001.004
The default of the console reboot bit was not enabled.
Workaround: At the console prompt execute a start up command
(ie: >>>@EWKAX_INIT.CMD ).
KA900/JXDI (TEST/JXDI)
Obtained a prelim copy of V2.2 for JXDI0 and V1.1 for JXDI1 for
evaluation.
On occassion previous versions would fail test 2.
If I/K/B between TEST/JXDI's, it passes but if TEST/JXDI
is followed by another TEST/JXDI without a I/K/B, a failure
of test 2 is reported. The author repositioned this test
and it does not now fail. A new version is being built.
KA900/XBI (TEST/XBI)
Obtained a prelim copy (V1.4) for evaluation. This contains
18 out of 19 tests enabled. The 1 remaining test is in debug.
EVKAG (V3.0) - lvl 2 VAX Vector Instrs 1
The V3.0 version will fail Test 1 (New test added in V3.0) on a
9000_xxx. Author has been notified and we have a working
prelim version (V3.1). There are other changes (other than
9000 CPU's) that will also be in yet a newer version (V3.2).
The V3.1 has been run on CPU0, CPU1, Both and under VMS5-4.
VMS/VDS/KA9000_420
EVKAS (V4.0) - LEVEL 2 VAX Floating Pnt Instrs 1
EVKAT (V4.0) - LEVEL 2 VAX Floating Pnt Instrs 2
There is a problem when using CPU1 as the primary boot.
They will also cause VMS to crash when executed on CPU1.
We have only access to 1 -420 but will try on another soon.
KA900/XJA
EWCLA (V1.9) - LEVEL 4 XJA Adapter Diag
This version has been executed on three different -420
configs and multiple XJA's. Author has supplied an ADVANCE
COPY and we have started regression testing.
KA9000_420
EVCLB (V1.9) - LEVEL 3 XJA Adapter Diag
This version has been executed on three different -420
configs and multiple XJA's. Author has supplied an ADVANCE
COPY and we have started regression testing.
DSB32 EVDAP - LEVEL 3 diagnostic - V001.002 is under evaluation.
Author has supplied an PRELIMINARY COPY with all test fixed.
DRB32-M EVDRH - LEVEL 3 diagnostic - V003.002 is under evaluation.
Author has supplied an PRELIMINARY COPY and we are attempting
to verify all optional program sections operate without error.
There are other DRB-32 options/diags that are also being tested.
VDS/KA9000_420
EVGAC - lvl 3 CI Architecture 3 (1.2)
There is a problem when using CPU1 as the primary boot.
We have only access to 1 -420 but will try on another soon.
________________________________________________________________________________
Diagnostic Checklist for VAX9000-210 Machine Configuration B4 09/12/90
________________________________________________________________________________
DIAGNOSTIC | QA |TRANS|CONFG|CLOCK|VOLT | NOTES
________________________________________|_____|_____|_____|_____|_____|_________
CONSOLE/DIAGNOSTIC FINAL CODE FREEZE | N/A | N/A | N/A | N/A | N/A |
CONSOLE MEDIA MASTER AT SSB | N/A | N/A | N/A | N/A | N/A | 09/04
CONSOLE MEDIA AVAILABLE WORLDWIDE | N/A | N/A | N/A | N/A | N/A | 09/15
DIAGBOOT |DONE |DONE |DONE | N/A | N/A |
EWSAA - VAX Diag Supervisor | | | | N/A | N/A |13.2-1235
EVSBA Autosizer |DONE |DONE |DONE | N/A | N/A |
EVKAA - lvl 4 VAX Hardcore Instrs |DONE |DONE |DONE |WAIV |WAIV |
EVKAQ - lvl 2 VAX Basic Instrs 1 |DONE |DONE |DONE |WAIV |WAIV |
EVKAR - lvl 2 VAX Basic Instrs 2 |DONE |DONE |DONE |WAIV |WAIV |
EVKAS - lvl 2 VAX Floating Pnt Instrs 1|DONE |DONE |DONE |WAIV |WAIV |
EVKAT - lvl 2 VAX Floating Pnt Instrs 2|DONE |DONE |DONE |WAIV |WAIV |
EVKAU - lvl 3 VAX Privileged Instrs 1 |DONE |DONE |DONE |WAIV |WAIV |
EVKAV - lvl 3 VAX Privileged Instrs 2 |DONE |DONE |DONE |WAIV |WAIV |
EVKAG - lvl 2 VAX Vector Instrs 1 |DONE |DONE |DONE |WAIV |WAIV |V2.0
EVKAH - lvl 2 VAX Vector Instrs 2 |DONE |DONE |DONE |WAIV |WAIV |
EWKAX - lvl 3 Kernel Architectural Diag |DONE |DONE |DONE |WAIV |WAIV |
EWKMP - lvl 3 Multi-Port Exerciser |DONE |DONE |DONE |WAIV |WAIV |
TEST/JXDI - JXDI loopback Diags |DONE |DONE |DONE |WAIV |WAIV |
EWCLA - lvl 4 XJA Adapter Diag |DONE |DONE |DONE |WAIV |WAIV |
EVCLB - lvl 3 XJA Diag |DONE |DONE |DONE |WAIV |WAIV |
EWCMA - lvl 4 XBI+ Diag |DONE |DONE |DONE |WAIV |WAIV |4 tests
EVCME - lvl 3 XBI+ Adapter Diag | | | |WAIV |WAIV | HOLD
EVDWC NI Exerciser DEBNI, DEMNA Lvl 2R |DONE |DONE |DONE |WAIV |WAIV |
EVGDB DEMNA EEPROM Update Utility |DONE |DONE |DONE |WAIV |WAIV |
EVDYE DEMNA Level 2R |DONE |DONE |DONE |WAIV |WAIV |
EVDYD DEBNI Level 2R |DONE |DONE |DONE |WAIV |WAIV |RETEST
EVGEA CIXCD Repair Diag. Lvl 3 |DONE |DONE |DONE |WAIV |WAIV |
EVGEB CIXCD Rom Update Utility Lvl 3 |DONE |DONE |DONE |WAIV |WAIV |
EVGAA CI Architecture 1 |DONE |DONE |DONE |WAIV |WAIV | HOLD
EVGAB CI Architecture 2 |DONE |DONE |DONE |WAIV |WAIV | HOLD
EVGAC CI Architecture 3 |DONE |DONE |DONE |WAIV |WAIV | HOLD
EVRLJ - lvl 3 MSCP Exerciser |DONE |DONE |DONE |WAIV |WAIV |
EVRLM - lvl 3 EEPROM Update util KDM70 |DONE |DONE |DONE |WAIV |WAIV |
EVRLN - lvl 3 DUP Driver KDM70 |DONE |DONE |DONE |WAIV |WAIV |
EVRAE - lvl 2R Online MSCP Exerciser |DONE |DONE |DONE |WAIV |WAIV |
EVRLB KDB50 Disk Formatter lvl 3 |DONE |DONE |DONE |WAIV |WAIV |
EVRLF KDB50 Basic Subsystem Test lvl 3 |DONE |DONE |DONE |WAIV |WAIV |
EVRLG KDB50/RAxx/ESE20 lvl 3 Exerciser |DONE |DONE |DONE |WAIV |WAIV |
EVRLK - lvl 3 Bad Block Replace Utility |DONE |DONE |DONE |WAIV |WAIV |
EVRLL - lvl 3 Error Log Utility |DONE |DONE |DONE |WAIV |WAIV |
EVDAJ - DMB32 Level 2R Asynch Lines |WAIV |DONE |DONE |WAIV |WAIV |LOOPBACK
EVDAK - DMB32 Level 3 |DONE |DONE |DONE |WAIV |WAIV |
EVDAL - DMB32 Level 2R Synch Lines |DONE |DONE |DONE |WAIV |WAIV |LOOPBACK
EVDAN - Online Data Comm Link Level 2R |WAIV |WAIV |WAIV |WAIV |WAIV |Need HW
EVDAR - DHB32 Level 3 |DONE |DONE |DONE |WAIV |WAIV |RETEST
EVDAS - DMB32, DHB32 Level 2R |DONE |DONE |DONE |WAIV |WAIV |
EVDAP - DSB32 Level 3 | | | |WAIV |WAIV |Prelim
EVDAQ - DSB32 Level 2R | | | |WAIV |WAIV |HANGS
EVDRH - DRB32 Level 3 |DONE |DONE |DONE |WAIV |WAIV |
EVRVA - KLESI/RV20 Level 3 |DONE |DONE |DONE |WAIV |WAIV |
EVRVB - KLESI/RV20 Level 2R |DONE |DONE |DONE |WAIV |WAIV |
EVRVC - KLESI/RV20/RV64 Level 2R | | | |WAIV |WAIV | HOLD
EVRVG - KLESI/RV64 Level 3 | | | |WAIV |WAIV | HOLD
________________________________________|_____|_____|_____|_____|_____|_________
***CONFIG/NOTES columns:
CPU0/1/B = Executed with CPU0 only, CPU1 only and BOTH selected - OK
CPU0/B = Executed with CPU0 only, and BOTH selected - OK
CPU1 = Problem if executed on CPU1 only -(to be resolved yet)- FAIL
CPU1/VMS = Executed with CPU1 and VMS - BOTH caused halt machine - FAIL
T9/T10 = Executed with errors reported on a -420 config - FAIL
18/19 = 18 out of 19 tests being evaluated - 1 still in debug
PathA/B = Program fails to report the devices connected to Path A or B
FAIL* = See individual program section for details.
________________________________________________________________________________
Diagnostic Checklist for VAX9000-420 Machine Configuration B4
________________________________________________________________________________
DIAGNOSTIC VERSION| QA | CONFIG | NOTES |OWNER
____________________________________#___|_____|__________|_________|____________
DIAGBOOT | | | |BERGAZZI
EWSAA - VAX Diag Supervisor (13.2-1253) |DONE | CPU0/1/B | |BERGAZZI
EVSBA Autosizer (7.2)|FAIL*| | CPU1 |BERGAZZI
EVKAA - lvl 4 VAX Hardcore Instrs (11.0)| | |
EVKAQ - lvl 2 VAX Basic Instrs 1 (4.0)|DONE | CPU0/1/B | |MCCARRON
EVKAR - lvl 2 VAX Basic Instrs 2 (4.0)|DONE | CPU0/1/B | |MCCARRON
EVKAS - lvl 2 VAX Floating Pnt 1 (4.0)|FAIL*| | CPU1/VMS|MCCARRON
EVKAT - lvl 2 VAX Floating Pnt 2 (4.0)|FAIL*| | CPU1/VMS|MCCARRON
EVKAU - lvl 3 VAX Priv Instrs 1 (4.0)|DONE | CPU0/1/B | |MCCARRON
EVKAV - lvl 3 VAX Priv Instrs 2 (4.0)|DONE | CPU0/1/B | |MCCARRON
EVKAG - lvl 2 VAX Vector Instrs 1 (3.1)|DONE | CPU0/1/B | |MCCARRON
EVKAH - lvl 2 VAX Vector Instrs 2 (2.0)|DONE | CPU0/1/B | |MCCARRON
EWKAX - lvl 3 Kernel Arch Diag (1.4)| | | | ECK
EWKMP - lvl 3 Multi-Port Exer (1.4)|FAIL*| | T9/T10 | ECK
TEST/JXDI - lvl 4 JXDI loopback Diag |EVAL | CPU0/1/B | V2.2/1.1| ECK
TEST/XJA - lvl 4 XJA Adapt(EWCLA) (1.9)|EVAL | CPU0/1/B | | ECK
EVCLB - lvl 3 XJA Diag (1.9)|EVAL | CPU0/1/B | | ECK
TEST/XMI - lvl 4 XBI+ Diag (EWCMA)(1.4)|EVAL | | 18/19 | ECK
EVCME - lvl 3 XBI+ Adapter Diag | | | HOLD | ECK
EVDWC - lvl 2R NI ExerDEBNI, DEMNA | | |
EVGDB - lvl 3 DEMNA EEPROM Update Util | | |
EVDYE - lvl 2R DEMNA | | |
EVDYD - lvl 2R DEBNI | | |
EVGEA - lvl 3 CIXCD Repair Diag (2.1)|DONE | CPU0/1/B | | ECK
EVGEB - lvl 3 CIXCD Rom Update Utl (2.0)|DONE | CPU0/1/B | | ECK
EVGAA - lvl 3 CI Architecture 1 (6.2)|FAIL*| CPU0/B | PathA/B | TAYLOR
EVGAB - lvl 3 CI Architecture 2 (6.3)|EVAL | CPU0/1/B | | TAYLOR
EVGAC - lvl 3 CI Architecture 3 (1.2)|EVAL | CPU0/B | CPU1 | TAYLOR
EVRLJ - lvl 3 MSCP Exerciser KDM70 (3.0)|EVAL | CPU0/B |
EVRLM - lvl 3 EEPROM Update KDM70 | | |
EVRLN - lvl 3 DUP Driver KDM70 (1.3)|EVAL | CPU0/B |
EVRAE - lvl 2R Online MSCP Exerciser | | |
EVRLB - lvl 3 KDB50 Disk Formatter (7.4)|EVAL | CPU0/B |
EVRLF - lvl 3 KDB50 Basic Subsystem(9.5)|EVAL | CPU0/B |
EVRLG - lvl 3 KDB50/RAxx/ESE20 Exer(9.4)|EVAL | CPU0/B |
EVRLK - lvl 3 Bad Block Utility (3.4)|EVAL | CPU0/B |
EVRLL - lvl 3 KDB50 Error Log Util (2.3)|EVAL | CPU0/B |
EVDAJ - lvl 2R DMB32 Asynch Lines | | | NEED A DMB32 in AS1
EVDAK - lvl 3 DMB32 | | | NEED A DMB32 in AS1
EVDAL - lvl 2R DMB32 Synch Lines | | | NEED A DMB32 in AS1
EVDAN - lvl 2R Online Data Comm Link | | | NEED 2 DMB32 in AS1
EVDAR - lvl 3 DHB32 | | | NEED A DHB32 in AS1
EVDAS - lvl 2R DMB32, DHB32 | | | NEED A DHB32 in AS1
EVDAP - lvl 3 DSB32 (1.2)|DONE | CPU0/1/B | | QUINN
EVDAQ - lvl 2R DSB32 (1.0)|EVAL | CPU0/B | | QUINN
EVDRH - lvl 3 DRB32 (3.2)|EVAL | CPU0/1/B | |ZECCHINO
EVRVA - lvl 3 KLESI/RV20 | | |
EVRVB - lvl 2R KLESI/RV20 | | |
EVRVC - lvl 2R KLESI/RV20/RV64 | | |
EVRVG - lvl 3 KLESI/RV64 | | |
________________________________________|_____|__________|____________
________________________________________________________________________________
Diagnostic Checklist for VAX9000-440 Machine Configuration B4 09/27/90
________________________________________________________________________________
DIAGNOSTIC | QA |TRANS|CONFG|CLOCK|VOLT | NOTES
________________________________________|_____|_____|_____|_____|_____|_________
CONSOLE/DIAGNOSTIC CODE FREEZE | N/A | N/A | N/A | N/A | N/A |
CONSOLE MEDIA MASTER AT SSB | N/A | N/A | N/A | N/A | N/A |
CONSOLE MEDIA AVAILABLE WORLDWIDE | N/A | N/A | N/A | N/A | N/A |
DIAGBOOT | | | | N/A | N/A |
EWSAA - VAX Diag Supervisor | | | | N/A | N/A |
EVSBA Autosizer | | | | N/A | N/A |
EVKAA - lvl 4 VAX Hardcore Instrs | | | | | |
EVKAQ - lvl 2 VAX Basic Instrs 1 | | | | | |
EVKAR - lvl 2 VAX Basic Instrs 2 | | | | | |
EVKAS - lvl 2 VAX Floating Pnt Instrs 1| | | | | |
EVKAT - lvl 2 VAX Floating Pnt Instrs 2| | | | | |
EVKAU - lvl 2 VAX Privileged Instrs 1 | | | | | |
EVKAV - lvl 2 VAX Privileged Instrs 2 | | | | | |
EVKAG - lvl 2 VAX Vector Instrs 1 | | | | | |
EVKAH - lvl 2 VAX Vector Instrs 2 | | | | | |
EWKAX - lvl 3 Kernel Architectural Diag | | | | | |
EWKMP - lvl 3 Multi-Port Exerciser | | | | | |
TEST/JXDI - JXDI loopback Diags | | | | | |
EWCLA - lvl 4 XJA Adapter Diag | | | | | |
EVCLB - lvl 3 XJA Diag | | | | | |
EWCMA - lvl 4 XBI+ Diag | | | | | |
EVCME - lvl 3 XBI+ Adapter Diag | | | | | |
EVDWC NI Exerciser DEBNI, DEMNA Lvl 2R | | | | | |
EVGDB DEMNA EEPROM Update Utility | | | | | |
EVDYE DEMNA Level 2R | | | | | |
EVDYD DEBNI Level 2R | | | | | |
EVGEA CIXCD Repair Diag. Lvl 3 | | | | | |
EVGEB CIXCD Rom Update Utility Lvl 2R | | | | | |
EVGAA CI Architecture 1 | | | | | |
EVGAB CI Architecture 2 | | | | | |
EVGAC CI Architecture 3 | | | | | |
EVRLJ - lvl 3 MSCP Exerciser | | | | | |
EVRLM - lvl 3 EEPROM Update util KDM70 | | | | | |
EVRLN - lvl 3 DUP Driver KDM70 | | | | | |
EVRAE - lvl 2R Online MSCP Exerciser | | | | | |
EVRLB KDB50 Disk Formatter lvl 3 | | | | | |
EVRLF KDB50 Basic Subsystem Test lvl 3 | | | | | |
EVRLG KDB50/RAxx/ESE20 lvl 3 Exerciser | | | | | |
EVRLK - lvl 3 Bad Block Replace Utility | | | | | |
EVRLL - lvl 3 Error Log Utility | | | | | |
EVDAJ - DMB32 Level 2R Asynch Lines | | | | | |
EVDAK - DMB32 Level 3 | | | | | |
EVDAL - DMB32 Level 2R Synch Lines | | | | | |
EVDAN - Online Data Comm Link Level 2R | | | | | |
EVDAR - DHB32 Level 3 | | | | | |
EVDAS - DMB32, DHB32 Level 2R | | | | | |
EVDAP - DSB32 Level 3 | | | | | |
EVDAQ - DSB32 Level 2R | | | | | |
EVDRH - DRB32 Level 3 | | | | | |
EVRVA - KLESI/RV20 Level 3 | | | | | |
EVRVB - KLESI/RV20 Level 2R | | | | | |
EVRVC - KLESI/RV64 Level 2R | | | | | |
EVRVG - KLESI/RV64 Level 3 | | | | | |
________________________________________|_____|_____|_____|_____|_____|_________
***** CROSS REFERENCE OF DEVICE TO DIAGNOSTIC NAMES ******
--------------------------------------------------------------------------------
Device Diagnostic
--------------------------------------------------------------------------------
KA900 EVKAA EVKAQ EVKAR EVKAS EVKAT EVKAU EVKAV EVKAG EVKAH
EWKAX EWKMP
XJA EWCLA EVCLB
XBI+ EWCMA EVCME
RV20 EVRVA EVRVB EVRVC
RV64 EVRVG EVRVC
RA60 EVRAE EVRLB EVRLF EVRLG EVRLJ EVRLK EVRLL EVRLN
RA70 EVRAE EVRLB EVRLF EVRLG EVRLJ EVRLK EVRLL EVRLN
RA80 EVRAE EVRLB EVRLF EVRLG EVRLJ EVRLK EVRLL EVRLN
RA81 EVRAE EVRLB EVRLF EVRLG EVRLJ EVRLK EVRLL EVRLN
RA82 EVRAE EVRLB EVRLF EVRLG EVRLJ EVRLK EVRLL EVRLN
RA90 EVRAE EVRLB EVRLF EVRLG EVRLJ EVRLL EVRLK EVRLN
ESE20 EVRAE EVRLB EVRLG EVRLJ EVRLL EVRLN
KDB50 EVRLF EVRLG EVRLJ EVRLL EVRLK EVRLB
KDM70 EVRLJ EVRLM EVRLN
CIXCD EVGEA EVGAA EVGAB EVGAC
DMB32 EVDAJ EVDAK EVDAL EVDAS
DHB32 EVDAR EVDAS
DRB32M EVDRH
DRB32W EVDRI
DRB32C EVDRK
DRB32E EVDRJ
DSB32 EVDAP EVDAQ
DEBNI EVDWC EVDYD
DEMNA EVDWC EVDYE EVGDB
--------------------------------------------------------------------------------
VAX9000 CPU Support Utility Status
--------------------------------------------------------------------------------
DIAGBOOT
Current Status:
Current version unknown
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Support Utility Status
--------------------------------------------------------------------------------
EWSAA VDS monitor for the VAX-9000_xxx
Current Status:
EWSAA.EXE;1221 causes problems with EVKAU.
EWSAA.EXE;1235 did not fix EVKAU problem
EWSAA.EXE;1241 is under evaluation for EVDRH (DRB32) problem.
EWSAA.EXE;1253 is under evaluation in 420 conf
Work in progress:
420 qualification testing
Additional work will be needed to support 420 and 440 conf.
Problems:
Version 13.2-1235 (and previous) causes EVDRH to fail when
multiple DRB32's were in the same XBI backplane.
Version 13.2-1241 would sometime machine check before the
VDS banner was reported.
EVSBA Autosizer (7.2)/EWSAA - VAX Diag Supervisor 13.2-1253
There is a problem when using CPU1 as the primary boot. This
MAY BE the 'ROUND-ROBIN' issue. There is no 'fix' at this moment
but one in the works (Dont run Autosizer or any diags that
interrupt {ie: EVKAS/T or I/O diags etc} when CPU1 is
primary boot - results unpredictable).
Temporary Workarounds:
Version 13.2-1235
Relocate individual DRB32 to seperate backplanes.
Left To Be Done:
Regression test version 13.2-1241
Regression test version 13.2-1253
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Support Utility Status
--------------------------------------------------------------------------------
EVSBA (AUTOSIZER)
Current Status:
EVSBA.EXE version 007.002 is latest released
Work in progress:
420 qualification testing
Problems:
EVSBA Autosizer (7.2)/EWSAA - VAX Diag Supervisor 13.2-1253
There is a problem when using CPU1 as the primary boot. This
MAY BE the 'ROUND-ROBIN' issue. There is no 'fix' at this moment
but one in the works (Dont run Autosizer or any diags that
interrupt {ie: EVKAS/T or I/O diags etc} when CPU1 is
primary boot - results unpredictable).
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EVKAA - LEVEL 4 VAX Hardcore Instrs
Current Status:
V011.000 is latest released
Work in progress:
420 qualification testing
Problems:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EVKAQ - LEVEL 2 VAX Basic Instrs 1
Current Status:
V004.000 is latest released
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EVKAR - EVKAR - lvl 2 VAX Basic Instrs 2
Current Status:
V004.000 is latest released
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EVKAS - LEVEL 2 VAX Floating Pnt Instrs 1
Current Status:
V004.000 is latest released
Work in progress:
420 qualification testing
Problems:
VMS V5-4 Crashed VMS when attached to CPU1. No problem
when executed on CPU0. Test 18 (DIVF2) causes
an {{ERROR condition detected on CPU 1 - CPU 1
has halted, Halt code: 60, PC: 0006A000}}
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EVKAT - LEVEL 2 VAX Floating Pnt Instrs 2
Current Status:
V004.000 is latest released
Work in progress:
420 qualification testing
Problems:
VMS V5-4 Crashed VMS when attached to CPU1. No problem
when executed on CPU0. Test 20 (DIVG2) causes
an {{ERROR condition detected on CPU 1 - CPU 1
has halted, Halt code: 60, PC: 0006A000}}
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EVKAU - LEVEL 3 VAX Privileged Instrs 1
Current Status:
V004.000 is latest released
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EVKAV - LEVEL 3 VAX Privileged Instrs 2
Current Status:
V004.000 is latest released
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EWKAX - LEVEL 3 Kernel Architectural Diag
Current Status:
V001.004 is latest released
Work in progress:
420 qualification testing
Problems:
The default of the console reboot bit was not enabled.
Temporary Workarounds:
At the console prompt (>>>) execute @EWKAX_INIT
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EWKMP - LEVEL 3 Multi-Port Exerciser
Current Status:
V001.004 is latest released
Work in progress:
420 qualification testing
T9 fails on _420 conf, T10 fails randomly
Problems:
420 Config (two cpu's)
DS>START or DS>START/SECTION=DEFAULT
Test 9, Subtest 2 ERROR 8 (EXPECTED I/O INTERRUPT NOT RECEIVED)
DS>START/SECTION=MULTI
Test 10 (XJA ARBITRATION ERROR) {Found on Sept 19}
There appears to be an 'intermittent' failing of test 10.
This has been seen very intermittently on one machine.
Another machine has failed more frequently (out of 100 passes,
it failed 44).
Temporary Workarounds:
TEST 9 None
TEST 10 None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EVKAG - LEVEL 2 VAX Vector Instrs Part I
Current Status:
V002.000 is latest released
V003.000 is under evaluation
Work in progress:
420 qualification testing
Working to localize and fix a bug in V3.0 test #1
Problems:
V3.0 Test #1 fails with a reserved operand fault
The author is working on the problem and has found
by limiting the constraints used in the vector length
register to <64, the error does not occur. He has been
in contact with Frank Mckeen for input/feedback.
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EVKAH - LEVEL 2 VAX Vector Instrs Part II
Current Status:
V002.000 is latest released
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EWCLA - XJA Level 4 Diagnostic
Current Status:
V1.6 is latest released (BL11)
V1.8 is under evaluation
V1.9 is under development
Work in progress:
Working on qualification and code cleanup for V1.8
V1.9 has run on multiple XJA's and now starting to
run with multiple CPU's.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVCLB - XJA Level 3 Diagnostic
Current Status:
V001.008 is latest released
V001.009 is about to be released
Work in progress:
New revision of gate array (pass 3) caused problems with V1.8
and the author is fixing them. The next revision will be
released in the near future.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EWCMA - XBI+ Level 4 Diagnostic
Current Status:
V1.2 is latest released
Work in progress:
420 qualification testing
Working on cleanup and qualification of remaining test.
Problems:
1 test remains to be debugged. The test fails on a 9000_xxx
due to differences in memory allocation between 9000 and
other VAX. The test was expecting a machine check due to
non-exsistant memory (page size differences) but on a 9000
that address is still valid.
Temporary Workarounds:
18 tests operational. Only 1 test is stubbed out.
Left To Be Done:
Complete development and debug.
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVCME - XBI+ Level 3 Diagnostic
Current Status:
Not released. Pending completion of EWCMA.
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
Complete development and debug.
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDWC - DEMNA, DEBNI Level 2R Exerciser
Current Status:
V003.002 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDYE - DEMNA Level 2R
Current Status:
V002.000 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDYF - DEBNA Level 3 ***** UNSUPPORTED ON VAX9000 *****
Current Status:
V001.001 does not support the DEBNI. Since the VAX9000 will
not support the DEBNA we will do no further testing on this
diagnostic.
Work in progress:
None.
Problems:
None.
Left To Be Done:
None.
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVGDB - DEMNA EEPROM Update Utility Level 3
Current Status:
V001.003 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVGEA - CIXCD Level 3
Current Status:
V2.01 is latest released
Requires V1.0 of CIXCD.BIN microcode file
V1.4 of CIXCD.BIN microcode file has just been released but
just started regression testing.
Work in progress:
V2.02 is being developed (Several Plus-1 requests) for REL42.
If it is decided to enable hardware EEPROM data protection, the
revision of the program will be changed to V3.0 before release.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVGEB - CIXCD Level 3
Current Status:
V002.000 is latest released
Work in progress:
See EVGEA
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVGAA - CI Architecture 1
Current Status:
V006.001 is latest released
V006.002 is under evaluation but does not display Path A/B
V006.002 is under evaluation
Work in progress:
420 qualification testing
Verify that V006.002 fixes intermittent problem in V006.001
Problems:
V006.001 has intermittent failure caused by unitialized memory
buffer.
V006.002 does not display the Path A and Path B config
correctly at some executions. It does report correctly on
other based cpu's.
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVGAB - CI Architecture 2
Current Status:
V006.001 is latest released
V006.002 is under evaluation
Work in progress:
420 qualification testing
Verify that V006.002 fixes intermittent problem in V006.001
Problems:
V006.001 has intermittent failure caused by unitialized memory
buffer.
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVGAC - CI Architecture 3
Current Status:
V001.001 is latest released
V001.002 is under evaluation
Work in progress:
420 qualification testing
Verify that V001.002 fixes intermittent problem in V001.001
Problems:
V001.001 has intermittent failure caused by unitialized memory
buffer.
Have seen one failure on Test 6 when executed on CPU1 only.
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRLJ - KDM70, ESE20, RAxx ,KDB50 Level 3
Current Status:
V003.000 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRLM - KDM70 Level 3
Current Status:
V001.002 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRLN - KDM70 , RAxx, ESE20 Level 3
Current Status:
V001.002 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRAE - KDM70, KDB50, RAxx, ESE20 Level 2R
Current Status:
V003.004 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRLB - KDB50, RAxx, ESE20 Level 3 Formatter
Current Status:
V007.004 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRLF - RAxx, KDB50 Level 3
Current Status:
V009.005 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRLG - RAxx, KDB50, ESE20 Level 3 Exerciser
Current Status:
V009.004 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRLK - RA60, RA70, RA8x Level 3 Bad Block Utility
Current Status:
V003.004 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRLL - RAxx, KDB50, ESE20 Level 3 Device Error Log Utility
Current Status:
V002.003 is latest released
V003.000 has been submitted for REL42 but we dont have yet.
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDYC - DEBNA Level 3 ***** NOT SUPPORTED ON VAX9000 *****
Current Status:
This diagnostic will not work on a DEBNI.
Since the VAX9000 will not support the DEBNA no further
testing of this diagnostic will be done.
Work in progress:
None.
Problems:
None.
Left To Be Done:
None.
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDYD - DEBNA, DEBNI Level 2R
Current Status:
V002.006 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDAJ - DMB32 Level 2R Asynch Lines
Current Status:
V003.001 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDAK - DMB32 Level 3
Current Status:
V004.001 is latest released but fails test 9.
Work in progress:
V004.002 has been obtained from the developers and
has been run on a 9000_210 without errors.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDAL - DMB32 Level 2R Synch Lines
Current Status:
V004.001 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDAS - DMB32, DHB32 Level 2R
Current Status:
V002.001 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDAR - DHB32 Level 3
Current Status:
V001.005 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDRH - DRB32 Level 3 Functional Test
Current Status:
V003.001 is latest released.
On 9000_xxx, Test 13, Error 3 was detected (Error
interrupt test). Also VDS/EVDRH problems with multi
units were detected. See EWSAA status.
V003.002 has been generated but not all program sections
have been tested to date.
Work in progress:
Attemption to verify all five different sections operate
without errors.
Problems:
None
Temporary Workarounds:
Only execute DEFAULT section of V3.2
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDRI - DRB32-W Level 3
Current Status:
V003.000. This diagnostic will not be tested by the diagnostic
group. The diagnostic group will only test the DRB32-M.
The various DRB32 personality modules variants DRB32-E and
DRB32-W will be tested by SASE as noted in the memo from
Jim McAndrew of VAX9000 Product Management dated 20-FEB-1990.
Work in progress:
Rich Zecchino is currently evaluating this diagnostic to ensure
that it will work in the VAX9000 environment
Problems:
None.
Left To Be Done:
None.
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDRJ - DRB32-E Level 3
Current Status:
This diagnostic will not be tested by the diagnostic
group. The diagnostic group will only test the DRB32-M.
The DRB32 personality module variant DRB32-C
will be tested by the southwest engineering group in ABQ as
noted in the memo from Jim McAndrew of VAX9000 Product
Management dated 20-FEB-1990.
Work in progress:
Rich Zecchino is currently evaluating this diagnostic to ensure
that it will work in the VAX9000 environment
Problems:
None.
Left To Be Done:
None.
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDRK - DRB32-C Level 3
Current Status:
This diagnostic will not be tested by the diagnostic
group. The diagnostic group will only test the DRB32-M.
The DRB32 personality module variant DRB32-C
will be tested by the southwest engineering group in ABQ as
noted in the memo from Jim McAndrew of VAX9000 Product
Management dated 20-FEB-1990.
Work in progress:
Rich Zecchino is currently evaluating this diagnostic to ensure
that it will work in the VAX9000 environment
Problems:
None.
Left To Be Done:
None.
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDAP - DSB32 Level 3
Current Status:
V001.001 is latest released
V001.002 is under evaluation
We have executed the default, selftest, downline, microcode,
interface and manual sections without errors.
Work in progress:
420 qualification testing.
Author has supplied an PRELIMINARY COPY (V001.002) with
all test fixed.
Problems:
V001.001
Test 34 fails - A timer of 64 is used to wait for a queue
operation to complete. This timer is not long
enough on a 9000. Changing it to approx 70 will
cause this test to pass. The timer value will
be doubled to 128.
Test 35/36 The file EVDAPMIC.EXE that was released had an
Test 37/38 "Record format: Undefined" which the 9000
console did not know how to handle. Resulting
in the console hanging and the console had to be
rebooted. (1) Eng. fixed the console software
in BL11 not to hang but report FILE NOT FOUND
error status. (2) Use EVDAPMIC.EXE file that has
had the Record format changed.
Test 37 Fails with error code of 11
Test 38 Fails with error code of 4 or 7 or 11
Temporary Workarounds:
V001.001
Test 34 Install a two loc patch for delay counter.
( BASE=85E4 LOC.183=40>80, LOC.257=40>80 )
Test 35/36 Use BL11 and verify that "DIR/FULL EVDAPMIC.EXE"
Test 37/38 displays "Record format: Fixed length"
Test 37/38 None at present time.
Left To Be Done:
Verify the 'final' version (V001.002) when available from author.
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDAQ - DSB32 Level 2R
Current Status:
V001.000 is latest released.
We have executed the default section.
Work in progress:
420 qualification testing
Problems:
On two different 9000's this program appears to hang and
just issue 1 min status information. It was found that the
microcode file had been corrupted. We have now run with
the default and external loopback (No external clock).
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRVA - RV20 Level 3
Current Status:
V003.001 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRVB - RV20 Level 2R
Current Status:
V003.001 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRVC - RV20/RV60/RV64 Level 2R
Current Status:
V001.000 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
This diagnostic has never been run because we do not have
an RV64 in the lab. Ravi Ganesan is to make arrangements for
obtaining the hardware needed to complete this testing.
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRVG - RV64
Current Status:
V001.003 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
This diagnostic has never been run because we do not have
an RV64 in the lab. Ravi Ganesan is to make arrangements for
obtaining the hardware needed to complete this testing.
420 & 440 qualification testing
|
| 78.73 | problems with V5.4 MUP install | KERNEL::WRIGHTON | odd numbered release = bug insert | Fri Oct 19 1990 10:19 | 62 |
|
SUBJECT: VMS 5.4 Install On 9xxx Systems Hangs during 5.4 MUP install phase.
DESCRIPTION:
After the initial install of 5.4, the MUP tape is requested to be
installed. The installation appears to be going okay until such
time as UPDATE_CONSOLE.COM is invoked to copy VMB9AQ.EXE from
SYSDISK down to CSA1. The following error message is printed out
on the console:
%COPY-E-WRITEERR, Error Writing CSA1:[USERFILES]VMB9AQ.EXE;2
-RMS-F-SYS, QIO System Service Request Failed
-SYS-F-TIMEOUT, Device Timeout
%COPY-W-NOTCOMPLT, SYS$COMMON:[SYSEXE]VMB9AQ.EXE
Not Completely Copied
VMS remains hung at this time and will not continue with the
install. A reboot of VMS at this point brings us back to
INSTALL requesting that the MUP tape be installed and the
same failure.
WORKAROUNDS:
>>>I/K
>>>BOOT/NOSTART "bootfile"
>>>DEPOSIT R5 1
SYSBOOT> SET/STARTUP SYS$SYSTEM:STARTUP.COM
SYSBOOT> CONTINUE
At this point the install is complete except for needing
to @SYS$UPDATE:UPDATE_CONSOLE.COM to update the console RD54
with VMB9AQ.EXE, installing licenses and running AUTOGEN.
To avoid this problem all together. Do the following:
On the initial boot after you have restored the "B" saveset.
>>>I/K
>>>BOOT/NOSTART "bootfile"
>>>DEPOSIT R1 1
SYSBOOT>SET ERRORLOGBUFFERS 64
SYSBOOT>SET ERLBUFFERPAGES 32
SYSBOOT>CONTINUE
Proceed with the installation normally.
\\%VAX 9000 9210 9410 9420 9430 9440 AQUARIUS SOFTWARE NONE VMS 5.4
To Distribution List:
Rory O'DONNELL@UVO,
Dave WRIGHTON@UVO,
Andreas KAEMPFE@SUF,
Thomas RATSCH@MGO,
Gerd GABRYS@COO,
Roberto VERCELLI@TNO,
Maurizio MORRONE@RIO,
Walter GROSSI@MIO,
Daniel GONON@GVO,
MEIR ALON@ISO
|
| 78.74 | latest microcode | KERNEL::WRIGHTON | odd numbered release = bug insert | Fri Oct 19 1990 10:23 | 42 |
|
05-OCT-1990
;**********************************************************************
; Version 322 is ** new **
;**********************************************************************
AQUA::EBOX$DISK:[SAMBERG.B4] -- B4 vector chips
AQUARIUS.*.5020 E322
;**********************************************************************
AQUA::EBOX$DISK:[SAMBERG.C2] -- C2 vector chips
AQUARIUS.*.6001 F317 -- VLR workaround removed
;**********************************************************************
All ucodes use FRAM_A52.*.4000 for vector and
NO_VEC_FRAM_B52.*.4000 for no vector
All ucodes use CONSTANT.*.13 A001
;**********************************************************************
Aquarius versions:
322 In CMPCx and MOVCx, add a write.mreg after a
clear ebox read fault to keep ib
request from fouling up aborted ebox
request that was unsequenced and had
a tb-miss
321 In TBIS, add an ebox request to keep ib
request from getting stale pte
320 Count mm successful retries, but with no hooks
to access it. Counter is in EREG[0DC].
319 On INSV and BBXX, do chk wrt success to prevent
flushes from breaking sequencer operation
317 On REI, avoid stram conflict to avoid situation
that could allow a premature trace
316 (1)On vector stores and scatters, do a check
write success to empty ebox data buffers,
thus avoiding data overrun by the vbox
(2)Implement cpu pause/resume feature using EREG[D1]
315 On cache sweep hack -- If base address found in
EREG[D0] = 0, nop the hack. Also, do
256K so we can use RPB address and still
ensure a sweep
|
| 78.75 | Error signals always present in BL11 console | KERNEL::WRIGHTON | odd numbered release = bug insert | Fri Oct 19 1990 10:26 | 23 |
|
On console ver 11.0 the following errors will be present.
These errors do not indicate the need to replace any MCU's.
>>>>>>>>>>>>>>>>>DO NOT REPLACE ANY MCUs FOR THESE ERRORS<<<<<<<<<<<<<<<<<<<<<<<
SDU> ex %scu.tag.adr%.l005.*err*
%SDU-I-LOADING, Loading descriptors from SYS$DATA:B3_SCU.CDB
%SCU.TAG.ADR0.L005.PAR_ERR_B_H<0> = 1
%SCU.TAG.ADR1.L005.PAR_ERR_B_H<0> = 1
%SCU.TAG.ADR2.L005.PAR_ERR_B_H<0> = 1
%SCU.TAG.ADR3.L005.PAR_ERR_B_H<0> = 1
These errors show up because the following latches are set during
kernel init.
SDU> ex %scu.tag.adr%.l005.l071.qa
%SCU.TAG.ADR0.L005.L071.QA<0> = 1
%SCU.TAG.ADR1.L005.L071.QA<0> = 1
%SCU.TAG.ADR2.L005.L071.QA<0> = 1
%SCU.TAG.ADR3.L005.L071.QA<0> = 1
|
| 78.77 | CDD install error | KERNEL::WRIGHTON | odd numbered release = bug insert | Mon Oct 22 1990 10:09 | 16 |
|
************************ Attention CDD/Plus Customers **************************
SUBJECT:
The VMS V5.4 Upgrade and Installation Manual (Order Number AA-NG61C-TE) has
an error on page D-4 regarding the version of CDD/Plus that is supported for
VMS 5.4. The Manual states that CDD/Plus V4.2 is the minimum required version.
VMS 5.4 requires 4.2A CDD/Plus or later.
SOLUTION:
If you have a requirement to run CDD/Plus please do not install VMS 5.4 until
you have CDD/Plus 4.2A.
|
| 78.78 | Where NOT to put your hands | KERNEL::WRIGHTON | odd numbered release = bug insert | Tue Oct 23 1990 16:08 | 25 |
|
SUBJECT: VAX 9000 Safety Alert
The VAX 9000 still has power applied to some parts of the system even
after you turn the OCP power switch to the OFF position. Do not ASSUME
that because you do not hear the blowers running that there is no power
applied to the system.
The AC Breaker in the VAX 9000 IOA cabinet has exposed terminals and has
power applied to it even when the front panel power switch is turned off.
The top terminals of the breaker are the line or input side of the
breaker, so even when the breaker is placed in the off position there is
still an AC potential between the terminals and the chassis. Also the two
Neon lights in this same cabinet have exposed lugs.
A shield is being considered to cover this area. Adding heat shrink over
the Neon light terminals is also being looked into. For your added
safety, you can add electrical tape over the exposed lugs and terminals.
It is safe to change any MCU or logic module in the XMI, SPU and Memory
Card Cages with only the OCP Power Switch OFF. However, no one should
change any part in the VAX 9000 power or cooling subsystems unless you
turn off the Main AC Breaker(s). Nor should any one attempt to install
any XMI option cables without first shutting off the Main AC Breaker(s)
to the system.
|
| 78.79 | formatting the RD54 | KERNEL::WRIGHTON | odd numbered release = bug insert | Fri Nov 02 1990 20:57 | 39 |
|
Subject: Formatting an RD54...
Several people have correctly noted that the RD54 comes unformatted
when you buy a new one, so there is a preliminary step you need to
do to format the drive before using instructions to build the disk
(as I recently sent around).
Basically, to format a brand new never-been-used disk, install it,
power it on, power on the SPU, then:
SPM-ROM> Z A
T/R
RBDA> D1/TR/C 01 !This step takes a while - up to 30 minutes
RBDA>^P
SPM-ROM>
At this point you can boot from one of the bootable TK50s, either
the one you made from the net release instructions, or tape 1
(AQ-PAKHA-ME) from the SSB kit.
This KFBTA test is described in the fault isolation manual
(maintenance guide volume 2 - EK-KA902-MG), but not very well. It
is slightly better described in the SPU Technical Description
(EK-KA90C-TD) under KFBTA tests, but unit_mask is not described
very well in either case. Using the example above, in RBDA>, the
unit_mask is 01 which reflects winchester "0" on the KFBTA. Since
we only have one RD54 in the SPU, unit_mask is always "01".
A complete description of all KFBTA diagsnotics can be found in the
KFBTA Technical Manual, EK-KFBTA-TM.
Thanks to the CSC and Joe Craparotta for pointing out the
deficiency in the original build instructions. I'll add a note
about formatting the drive in the instruction in AQ$SPU and in
PUBLIC.
|
| 78.80 | BL 11 | KERNEL::WRIGHTON | odd numbered release = bug insert | Mon Nov 05 1990 14:35 | 283 |
|
Subject: VAX 9000 SPU Base Level 11.0 Network Release
I am pleased to announce that the software release kits for the
SPU can now be obtained across the network starting with base level
11.0, effective immediately.
Due to popular demand, CSSE will release SPU software kits via the
network (while continuing to follow the normal SSB release
process). This will not supplant the SSB release.
Two world readable directories have been established and will be
built upon to facilitate network releases. These are on the MRCSSE
cluster and can be accessed through the following two logical
definitions:
MRCSSE::AQ$SPU: and
MRCSSE::AQ$SPU$11:.
Complete instructions for:
1) building 2 TK50s from software release via the net, and
2) installing tapes built via net release onto your target SPU.
The current set of instructions can be found in MRCSSE::PUBLIC: or
MRCSSE::AQ$SPU: as file BL11_NET_BUILD_HELP.TXT.
(Thanks to John Sterner for helping verify the process).
Butch
att:
+---------------------------+ TM
! ! ! ! ! ! ! ! i n t e r o f f i c e
! d ! i ! g ! i ! t ! a ! l !
! ! ! ! ! ! ! ! m e m o r a n d u m
+---------------------------+
Date: 10/20/90
To: VAX 9000 Technical Distribution From: Butch Leitz
Dept: HPS/C CSSE MEG
DTN: 297-4257
LOC/MAIL STOP: MRO2-3/5E, Pole 2C
Email: HPSMEG::LEITZ
cc:
Subject: VAX 9000 SPU 11.0 Net Release Process
Software Upgrade Instructions
This is file MRCSSE::PUBLIC:BL11_NET_BUILD_HELP.TXT.
The following text describes the installation of Base Level 11.0
software on the VAX 9000 SPU RD54, using two TK50s created
through the network release process as defined in Appendix A
below.
Refer to:
MRCSSE::PUBLIC:SPU_SOFTWARE_INSTALLATION.TXT
for instructions on how to (re)build an RD54 from SSB released
tapes.
.-----------------------------------------------------.
| Refer to Appendix A (below) for instructions on |
| creating two TK50 tapes from Base Level 11 save |
| sets released over the network. |
`-----------------------------------------------------'
To install Base Level 11 from TK50s created from the net release
process:
1) Insert tape 1 into the TK50 drive, load it, and boot from the tape:
SPM-ROM> B MU77
2) Type @INSTALL when the SPU has booted (takes about 5 minutes
to reach prompt. Note that the prompt is CONSOLE>.)
CONSOLE> @INSTALL
3) Install will ask you if you want to initialize the disk. In most
cases you will answer "Y" since the new files consume about 115000
blocks. Since you need twice this amount for the installation, you
will generally have to initialize a disk to start from srcatch.
The best thing to do in advance is to create a TK50 from your old
disk containing any files that need to be recreated on the new disk.
You may wish to include...
[sysexe]sitespecific.cmd
[sysexe]siteinit.cmd
[sysexe]startup.cmd
[sysexe]login.cmd
[sysexe]sysinit.cmd
[sysexe]config.dat
[userfiles]defboo.cmd (along with any *boo.cmd variants)
...And any command files or data from user areas you wish to include
on the new disk.
Note that all system files and command procedures will be created
from the INSTALL, so you do not need save any of these over on tape,
but you may wish to use them for comparisons later to ease editing
DEFBOO and SITESPECIFIC, etc.
4) INSTALL.CMD will initialize the disk, create various directories on
DUA50 including [INSTALL], then will copy the 11.0 save sets to
DUA50:[INSTALL] alternatively running BACKUP to unpack the save sets
into their respective directories. This will take approximately an
hour and a half total.
5) Control passes back to INSTALL.CMD when finished which deletes
DUA50:[INSTALL], dismounts the TK50, and prints out the following
message prior to returning you to the prompt:
Installation complete
CONSOLE>
6) At this point, Internal DEC sites may now run PATCH from VMA50:[SYSEXE]
if required. This is not required for external sites. You can do this
by typing @NETINSTALL at the console prompt:
CONSOLE>@NETINSTALL
7) You now have a vanilla 11.0 system on your RD54 (without the SDD
files). You should now mount the tape you made in advance from your
previous system, and restore any files to the new RD54 that you may
require. You do not have to do this, but you will have to edit the
following files to match your site configuration:
DUA50:[SYSEXE]SITESPECIFIC.CMD
Default settings you may need to change:
sys$cpu_mask 1
sys$vbox_mask 1
sys$icu_mask 3
sys$xja_mask 1
sys$mmu_mask 3
sys$default_freq 500
sys$keepalive "on"
DUA50:[USERFILES]*boo.cmd
Copy the appropriate BOO.CMD file to DEFBOO.CMD, then
edit the new DEFBOO.CMD.
8) When all variable files have been edited or restored, hit the
BREAK key and type "B" at the SPM-ROM prompt to boot from the new
software.
The new SPU system should now boot properly. The banner will display:
SPU/ELN Base Level 11.0, 5-aug-1990 20:43
FOR INTERNAL USE ONLY
Followed by the normal SPU startup messages.
9) EWKCA: You will see an error message after EWKCA.CMD has been taken:
%SPU-F-NOTINSTALLED, this image has not been installed
The SPU will boot properly, but EWKCA still needs to be INSTALLed, or
it will not run. The following procedure should be followed:
Place the 2nd tape made from the net release process in the TK50
drive and load it. Then proceed by entering the following commands:
>>> mount mua7 *
>>> set command [sysexe]backup
>>> backup/log mua7:[]kitinstall.cmd dua50:[sysmaint]kitinstall.cmd
Messages will be displayed indicating files being created. An expiration
date will be set on EWKCA.EXE which will cause the code to cease working
one year from the date you are doing this.
10) This completes the 11.0 installation. Entire elapsed time should be
just under 2 hours.
If you didn't make the edit changes in SITESPECIFIC.CMD and
DEFBOO.CMD that are required for your configuration, do so at this
time.
11) You should now reboot the SPU:
>>> reboot/noconf
You may now I/K and BOOT VMS, or use any of the diagnostics available
on the SPU's Base Level 11 kit.
Appendix A:
To build QZ-K23AA-EW onto 2 TK50 tapes from net released savesets, on
your VMS system with accessable TK50 drive:
$ !The following command stream will create one TK50 with all the
$ !VAX 9000 SPU Base Level 11.0 SSB release data from QZ-K23AA-FW
$ !tapes 1,2 and 3.
$ !
$ !Use this as an example. For faster tape builds, copy the save sets
$ !to a local storage area first, then create the tape by copying files
$ !from the local disk to tape.
$ !
$ !Note that the files MUST be in the order specified below for the
$ !installation to work properly.
$
$ INIT MUA0: BL11
$ MOUNT MUA0: BL11
$ COPY MRCSSE::AQ$SPU:SYSBOOT.EXE MUA0:
$ COPY MRCSSE::AQ$SPU:DISK.IMA MUA0:
$ COPY MRCSSE::AQ$SPU$11:KITINSTALL.CMD MUA0:
$ COPY MRCSSE::AQ$SPU$11:SPUBL11_1.SBK;1 MUA0:
$ COPY MRCSSE::AQ$SPU$11:SPUBL11_2.SBK;1 MUA0:
$ COPY MRCSSE::AQ$SPU$11:SPUBL11_3.SBK;1 MUA0:
$ DISMOUNT MUA0
$
$ !End of Base Level 11.0 net build of tape 1.
$ !The following command stream will create one tape with all the
$ !VAX 9000 SPU Base Level 11.0 SSB release data from QZ-K23AA-FW
$ !tape 4, the SDD tape.
$ !
$ !Note that you must use "INSTALL_EWKCA.CMD" from AQ$SPU$11,
$ !and save it on the tape as "KITINSTALL.CMD".
$
$ INIT MUA0: BL11
$ MOUNT MUA0: BL11
$ COPY MRCSSE::AQ$SPU$11:INSTALL_EWKCA.CMD MUA0:KITINSTALL.CMD
$ COPY MRCSSE::AQ$SPU$11:SPUBL11_4.SBK;1 MUA0:
$ DISMOUNT MUA0
$
$ !End of Base Level 11.0 net build of tape 2.
Appendix B:
MRCSSE::AQ$SPU: and MRCSSE::AQ$SPU$11: contents:
Directory VAXPAX$14:[AQUA_SPU]
BACKUP.CLD;2 1 17-OCT-1990 16:08:24.36 (RE,RWED,RE,RE)
BACKUP.EXE;2 102 17-OCT-1990 16:12:59.08 (RE,RWED,RE,RE)
BACKUPVMS.CLD;2 1 17-OCT-1990 16:08:24.66 (RE,RWED,RE,RE)
BACKUPVMS.EXE;25 326 17-OCT-1990 16:12:59.17 (RE,RWED,RE,RE)
BACKUP_HELP.TXT;11 12 17-OCT-1990 16:08:25.03 (RE,RWED,RE,RE)
BACKUP_MAIL.TXT;3 5 17-OCT-1990 16:08:25.10 (RE,RWED,RE,RE)
BL11.DIR;1 1 17-OCT-1990 16:08:25.43 (RE,RWED,RE,RE)
DISK.IMA;3 4992 17-OCT-1990 16:57:16.37 (RE,RWED,RE,RE)
SYSBOOT.EXE;2 1264 17-OCT-1990 16:12:59.22 (RE,RWED,RE,RE)
Directory VAXPAX$14:[AQUA_SPU.BL11]
INSTALL_EWKCA.CMD;2
4 17-OCT-1990 16:07:22.40 (RE,RWED,RE,RE)
KITINSTALL.CMD;2 2 17-OCT-1990 16:06:34.80 (RE,RWED,RE,RE)
SPUBL11_1.SBK;1 24568 17-OCT-1990 15:59:56.26 (RE,RWED,RE,RE)
SPUBL11_2.SBK;1 4502 17-OCT-1990 15:59:56.45 (RE,RWED,RE,RE)
SPUBL11_3.SBK;1 60643 17-OCT-1990 15:59:56.51 (RE,RWED,RE,RE)
SPUBL11_4.SBK;1 1851 17-OCT-1990 15:59:56.73 (RE,RWED,RE,RE)
[MRCSSE::PUBLIC:BL11_NET_BUILD_HELP.TXT]
[MRCSSE::AQ$SPU:BL11_NET_BUILD_HELP.TXT]
|
| 78.81 | latest diagnostic checklist | KERNEL::WRIGHTON | odd numbered release = bug insert | Mon Nov 05 1990 14:36 | 2143 |
|
*********************************
*********************************
Diagnostic Checklist for 10/26/90 14:00:00
*********************************
*********************************
********************************************************
********************************************************
ABSTRACT of changes since last release (11.0)
********************************************************
********************************************************
Now that a 9000_420 (AS1) is available in the lab, we are using
two shifts to run regression test of the diags on a DUAL config.
VDS/KA9000_210/KA9000_410/KA9000_420
EWSAA - VAX Diag Supervisor 13.2-1253
Author has supplied an PRELIMINARY COPY and we have restarted
regression testing.
new> EWSAA - VAX Diag Supervisor x14.2-1271
new> Author has supplied an ADVANCE COPY. This version should repair
new> some problems found when booting from CPU1 and using EWKMP.
VDS/KA9000_420
EVSBA Autosizer (7.2)/EWSAA - VAX Diag Supervisor 13.2-1253
There was a change to the "SITESPECIFIC.CMD" file to change
the default value for CPUCNF. The change made BROADCAST the
default in place of ROUND_ROBIN. Once BROADCAST is the default
the problems encountered executing VDS/SIZER on CPU1 were fixed.
KA900/xxx
new> EVKAA - lvl 4 VAX Hardcore Instrs V011.000
new> There are 3 locations (FE00, FE04, FE08) that are used to
new> change the controlled execution (APT) of this diag. These
new> locations must contain a "0" for a default on a 9000_xxx.
new> Depending upon which bits are set, ^C will echo a "DS>" or
new> the program will not output END_OF_PASS, or ....etc....???
new> An EVKAA_INIT.CMD should be created to deposit the locations
new> to a "ZERO" before program execution.
new> Workaround: At the console prompt execute a start up command
new> (ie: >>>@EVKAA_INIT.CMD ).
KA900/420 DS>START or DS>START/SECTION=DEFAULT
EWKMP - LEVEL 3 Multi-Port Exerciser - V001.004
old> Test 9 fails when 2 cpus are selected. The interrupt from CPU1
old> is not received. Error #8 is the reported error in subtest 2.
new> Author has supplied an ADVANCE COPY (V1.5) in which test 9
new> failures has been fixed and we have started regression testing.
new> See EWKMP detailed section of this report for more info.
KA900/420 DS>START/SECTION=MULTI
EWKMP - LEVEL 3 Multi-Port Exerciser - V001.004
Test 10 (XJA ARBITRATION ERROR)
There appears to be an 'intermittent' failing of test 10.
This has been seen very intermittently on one machine. Another
machine has failed more frequently. Author has supplied
an ADVANCE COPY (V1.5) and we have started regression testing.
KA900/420 DS>START or DS>START/SECTION=DEFAULT or /SECTION=MULTI
EWKMP - LEVEL 3 Multi-Port Exerciser - V001.004
old> Clearing "OPER" flag causes program to default to infinite run
old> time execution. Fixed in V1.5
old> When CPU1 is the default boot cpu and EVSBA (autosizer) is
old> executed, CPU0 is assigned as KA0 and CPU1 is assigned as KA1.
old> When using CPU1 as the default boot cpu, EWKMP reported a
old> "CANNOT BOOT ATTACHED PROCESSOR" error.
old> Operator must execute the DESELECT KA0 command:
old> DS>DES KA0
old> Operator must not execute the START/SEC=MULTI as it will
old> also fail.
new> Author has supplied an ADVANCE COPY (V1.5) and we have
new> started regression testing.
KA900/xxx
old> EWKAX - LEVEL 3 Kernel Architectural Diag - V001.004
old> The default of the console reboot bit was not enabled.
old> Workaround: At the console prompt execute a start up command
old> (ie: >>>@EWKAX_INIT.CMD ).
new> When using CPU1 as the default boot cpu, EWKAX reported errors.
new> I contacted author. He reported other than CPU0 is supported.
new> He will be working with console and VDS people to resolve the
new> problem.
new> DO NOT EXECUTE on other than CPU0 till resolved.
KA900/JXDI (TEST/JXDI) - (Vx.x) - lvl 4
old> Obtained a prelim copy of V2.2 for JXDI0 and V1.1 for JXDI1 for
old> evaluation.
old> On occassion this versions would fail test 2.
old> If I/K/B between TEST/JXDI's, it passes but if TEST/JXDI
old> is followed by another TEST/JXDI without a I/K/B, a failure
old> of test 2 is reported.
new> The author repositioned this test and it does not now fail.
new> Obtained a copy of V1.2 for JXDI1 for
new> evaluation with a 'workaround' installed.
KA900/XBI (TEST/XBI) - EWCMA (V1.5) - lvl 4
old> Obtained a prelim copy (V1.5) for evaluation. This contains
old> 19 tests enabled. We have begun evaluation of V1.5 and will
old> be testing on several configs of XBI's on XJA's on CPU's.
old> Found V1.5 to be slot dependent. I had failures on different
old> configs. Author notified and he is creating V1.6 now.
new> I have tested V1.6 on multiple XBI in single XJA and single
new> XBI in multiple XJA without errors.
EVKAG (V3.0) - lvl 2 VAX Vector Instrs 1
The V3.0 version will fail Test 1 (New test added in V3.0) on a
9000_xxx. Author has been notified and we have a working
prelim version (V3.1). There are other changes (other than
9000 CPU's) that will also be in yet a newer version (V3.2).
The V3.1 has been run on CPU0, CPU1, Both and under VMS5-4.
VMS/VDS/KA9000_420
EVKAS (V4.0) - LEVEL 2 VAX Floating Pnt Instrs 1
EVKAT (V4.0) - LEVEL 2 VAX Floating Pnt Instrs 2
old> There WAS a problem when using CPU1 as the primary boot
old> (HALT attention generated with no HALT code).
old> They will also cause VMS to crash when executed on CPU1.
old> We have only access to 1 -420 but will try on another soon.
old> I have now executed these diags on a different system (P2)
old> and they both pass error free. System AS1 had an open on
old> the FAD mcu and now both tests pass under Standalone VDS
old> and under VMS/VDS.
KA900/XJA (TEST/XJA) - EWCLA (V1.9) - LEVEL 4 XJA Adapter Diag
This version has been executed on three different -420
configs and multiple XJA's. Author has supplied an ADVANCE
COPY and we have started regression testing.
KA9000_420
EVCLB (V1.9) - LEVEL 3 XJA Adapter Diag
This version has been executed on three different -420
configs and multiple XJA's. Author has supplied an ADVANCE
COPY and all tests passed.
old> Still seeing failures of EWKMP test 8 after execution of EVCLB.
old> Have identified the problem and working with author of EVCLB
old> to resolve workaround/repair. I expect a V1.10 soon for testing.
new> We now have V1.10 and have started regression testing on
new> several systems and executing other diags before and after to
new> check for other 'gotchas'.
DSB32 EVDAP - LEVEL 3 diagnostic - V001.002 is under evaluation.
Author has supplied an PRELIMINARY COPY with all test fixed.
DSB32 EVDAP - LEVEL 2R diagnostic - V001.000
On two different 9000's this program appears to hang and
just issue 1 min status information. It was found that the
microcode file had been corrupted.
Found that the driver was also corrupted and have replaced
it. The program now executes properly on a 9000.
DRB32-M EVDRH - LEVEL 3 diagnostic - V004.000
new> Author has supplied an PRELIMINARY COPY.
VDS/KA9000_420
EVGAA - lvl 3 CI Architecture 1 (6.3)
Author has supplied an PRELIMINARY COPY with all test fixed.
VDS/KA9000_420
EVGAB - lvl 3 CI Architecture 2 (6.3)
Author has supplied an PRELIMINARY COPY with all test fixed.
VDS/KA9000_420
EVGAC - lvl 3 CI Architecture 3 (1.2)
old> There is a problem when using CPU1 as the primary boot.
old> We have only access to 1 -420 but will try on another soon.
new> We have executed on another -420 with no problem found. A
new> hardware change was made to the first system and EVGAC now
new> executes without error.
VDS/KA9000_420
EVRLM - lvl 3 EEPROM Update util KDM70 (1.2)
old> This is more a 'operator' problem than any thing else.
old> While attempting to update the EEPROM, the data has
old> been corrupted so that self-test will fail. It is quite
old> possible that the microcode file we have been using has
old> been corrupted.
new> Obtained 'fresh' IMAGE.ECC microcode from CXO and was able
new> to load the 'stricken' KDM70 with this 'fresh' image. Also
new> went back and reloaded bad ucode and then reloaded fresh
new> once again.
________________________________________________________________________________
Diagnostic Checklist for VAX9000-210 Machine Configuration B4
________________________________________________________________________________
DIAGNOSTIC | QA |TRANS|CONFG|CLOCK|VOLT | NOTES
________________________________________|_____|_____|_____|_____|_____|_________
CONSOLE/DIAGNOSTIC FINAL CODE FREEZE | N/A | N/A | N/A | N/A | N/A |
CONSOLE MEDIA MASTER AT SSB | N/A | N/A | N/A | N/A | N/A | 09/04
CONSOLE MEDIA AVAILABLE WORLDWIDE | N/A | N/A | N/A | N/A | N/A | 09/15
DIAGBOOT |DONE |DONE |DONE | N/A | N/A |
EWSAA - VAX Diag Supervisor | | | | N/A | N/A |13.2-1235
EVSBA Autosizer |DONE |DONE |DONE | N/A | N/A |
EVKAA - lvl 4 VAX Hardcore Instrs |DONE |DONE |DONE |WAIV |WAIV |
EVKAQ - lvl 2 VAX Basic Instrs 1 |DONE |DONE |DONE |WAIV |WAIV |
EVKAR - lvl 2 VAX Basic Instrs 2 |DONE |DONE |DONE |WAIV |WAIV |
EVKAS - lvl 2 VAX Floating Pnt Instrs 1|DONE |DONE |DONE |WAIV |WAIV |
EVKAT - lvl 2 VAX Floating Pnt Instrs 2|DONE |DONE |DONE |WAIV |WAIV |
EVKAU - lvl 3 VAX Privileged Instrs 1 |DONE |DONE |DONE |WAIV |WAIV |
EVKAV - lvl 3 VAX Privileged Instrs 2 |DONE |DONE |DONE |WAIV |WAIV |
EVKAG - lvl 2 VAX Vector Instrs 1 |DONE |DONE |DONE |WAIV |WAIV |V2.0
EVKAH - lvl 2 VAX Vector Instrs 2 |DONE |DONE |DONE |WAIV |WAIV |
EWKAX - lvl 3 Kernel Architectural Diag |DONE |DONE |DONE |WAIV |WAIV |
EWKMP - lvl 3 Multi-Port Exerciser |DONE |DONE |DONE |WAIV |WAIV |
TEST/JXDI - JXDI loopback Diags |DONE |DONE |DONE |WAIV |WAIV |
EWCLA - lvl 4 XJA Adapter Diag |DONE |DONE |DONE |WAIV |WAIV |
EVCLB - lvl 3 XJA Diag |DONE |DONE |DONE |WAIV |WAIV |
EWCMA - lvl 4 XBI+ Diag |DONE |DONE |DONE |WAIV |WAIV |4 tests
EVCME - lvl 3 XBI+ Adapter Diag | | | |WAIV |WAIV | HOLD
EVDWC NI Exerciser DEBNI, DEMNA Lvl 2R |DONE |DONE |DONE |WAIV |WAIV |
EVGDB DEMNA EEPROM Update Utility |DONE |DONE |DONE |WAIV |WAIV |
EVDYE DEMNA Level 2R |DONE |DONE |DONE |WAIV |WAIV |
EVDYD DEBNI Level 2R |DONE |DONE |DONE |WAIV |WAIV |RETEST
EVGEA CIXCD Repair Diag. Lvl 3 |DONE |DONE |DONE |WAIV |WAIV |
EVGEB CIXCD Rom Update Utility Lvl 3 |DONE |DONE |DONE |WAIV |WAIV |
EVGAA CI Architecture 1 |DONE |DONE |DONE |WAIV |WAIV | HOLD
EVGAB CI Architecture 2 |DONE |DONE |DONE |WAIV |WAIV | HOLD
EVGAC CI Architecture 3 |DONE |DONE |DONE |WAIV |WAIV | HOLD
EVRLJ - lvl 3 MSCP Exerciser |DONE |DONE |DONE |WAIV |WAIV |
EVRLM - lvl 3 EEPROM Update util KDM70 |DONE |DONE |DONE |WAIV |WAIV |
EVRLN - lvl 3 DUP Driver KDM70 |DONE |DONE |DONE |WAIV |WAIV |
EVRAE - lvl 2R Online MSCP Exerciser |DONE |DONE |DONE |WAIV |WAIV |
EVRLB KDB50 Disk Formatter lvl 3 |DONE |DONE |DONE |WAIV |WAIV |
EVRLF KDB50 Basic Subsystem Test lvl 3 |DONE |DONE |DONE |WAIV |WAIV |
EVRLG KDB50/RAxx/ESE20 lvl 3 Exerciser |DONE |DONE |DONE |WAIV |WAIV |
EVRLK - lvl 3 Bad Block Replace Utility |DONE |DONE |DONE |WAIV |WAIV |
EVRLL - lvl 3 Error Log Utility |DONE |DONE |DONE |WAIV |WAIV |
EVDAJ - DMB32 Level 2R Asynch Lines |WAIV |DONE |DONE |WAIV |WAIV |LOOPBACK
EVDAK - DMB32 Level 3 |DONE |DONE |DONE |WAIV |WAIV |
EVDAL - DMB32 Level 2R Synch Lines |DONE |DONE |DONE |WAIV |WAIV |LOOPBACK
EVDAN - Online Data Comm Link Level 2R |WAIV |WAIV |WAIV |WAIV |WAIV |Need HW
EVDAR - DHB32 Level 3 |DONE |DONE |DONE |WAIV |WAIV |RETEST
EVDAS - DMB32, DHB32 Level 2R |DONE |DONE |DONE |WAIV |WAIV |
EVDAP - DSB32 Level 3 | | | |WAIV |WAIV |Prelim
EVDAQ - DSB32 Level 2R | | | |WAIV |WAIV |HANGS
EVDRH - DRB32 Level 3 |DONE |DONE |DONE |WAIV |WAIV |
EVRVA - KLESI/RV20 Level 3 |DONE |DONE |DONE |WAIV |WAIV |
EVRVB - KLESI/RV20 Level 2R |DONE |DONE |DONE |WAIV |WAIV |
EVRVC - KLESI/RV20/RV64 Level 2R | | | |WAIV |WAIV | HOLD
EVRVG - KLESI/RV64 Level 3 | | | |WAIV |WAIV | HOLD
________________________________________|_____|_____|_____|_____|_____|_________
***CONFIG/NOTES columns:
CPU0/1/B = Executed with CPU0 only, CPU1 only and BOTH selected - OK
CPU0/1 = Executed with CPU0 only, CPU1 only - OK
CPU1 = Problem if executed on CPU1 only -(to be resolved yet)- FAIL
FAIL* = See individual program section for details.
________________________________________________________________________________
Diagnostic Checklist for VAX9000-420 Machine Configuration B4 10/26/90
________________________________________________________________________________
DIAGNOSTIC VERSION| QA | CONFIG | NOTES |OWNER
____________________________________#___|_____|__________|_________|____________
DIAGBOOT | | | |BERGAZZI
EWSAA - VAX Diag Supervisor (13.2-1253)|DONE | CPU0/1/B | -1271 |BERGAZZI
EVSBA Autosizer (7.2)|DONE | CPU0/1/B | |BERGAZZI
EVKAA - lvl 4 VAX Hardcore Instrs (11.0)|DONE | CPU0/1 | |MCCARRON
EVKAQ - lvl 2 VAX Basic Instrs 1 (4.0)|DONE | CPU0/1/B | |MCCARRON
EVKAR - lvl 2 VAX Basic Instrs 2 (4.0)|DONE | CPU0/1/B | |MCCARRON
EVKAS - lvl 2 VAX Floating Pnt 1 (4.0)|DONE | CPU0/1/B | |MCCARRON
EVKAT - lvl 2 VAX Floating Pnt 2 (4.0)|DONE | CPU0/1/B | |MCCARRON
EVKAU - lvl 3 VAX Priv Instrs 1 (4.0)|DONE | CPU0/1/B | |MCCARRON
EVKAV - lvl 3 VAX Priv Instrs 2 (4.0)|DONE | CPU0/1/B | |MCCARRON
EVKAG - lvl 2 VAX Vector Instrs 1 (3.1)|DONE | CPU0/1/B | |MCCARRON
EVKAH - lvl 2 VAX Vector Instrs 2 (2.0)|DONE | CPU0/1/B | |MCCARRON
EWKAX - lvl 3 Kernel Arch Diag (1.4)|FAIL*| CPU0/B | CPU1 | ECK
EWKMP - lvl 3 Multi-Port Exer (1.5)|EVAL | CPU0/B | CPU1 | ECK
TEST/JXDI - lvl 4 JXDI loopback Diag |EVAL | CPU0/1 | V2.2/1.2| ECK
TEST/XJA - lvl 4 XJA Adapt(EWCLA) (1.9)|DONE | CPU0/1 | | ECK
EVCLB - lvl 3 XJA Diag (1.10)|EVAL | CPU0/1/B | Retest | ECK
TEST/XBI - lvl 4 XBI+ Diag (EWCMA)(1.6)|DONE | CPU0/1 | AS1 | ECK
EVCME - lvl 3 XBI+ Adapter Diag | | | HOLD | ECK
EVGDB - lvl 3 DEMNA EEPROM Update (1.3)|DONE | CPU0/1/B |
EVDYE - lvl 2R DEMNA (2.0)|DONE | CPU0/1/B |
EVDYD - lvl 2R DEBNA Func (2.6)|DONE | CPU0/1/B |
EVDWC - lvl 2R DEBNA NI Exer (3.2)|EVAL | CPU0 |
EVGEA - lvl 3 CIXCD Repair Diag (3.0)|DONE | CPU0/1/B | | ECK
EVGEB - lvl 3 CIXCD Rom Update Utl (2.0)|DONE | CPU0/1/B | | ECK
EVGAA - lvl 3 CI Architecture 1 (6.3)|DONE | CPU0/1/B | | TAYLOR
EVGAB - lvl 3 CI Architecture 2 (6.3)|DONE | CPU0/1/B | | TAYLOR
EVGAC - lvl 3 CI Architecture 3 (1.2)|DONE | CPU0/1/B | | TAYLOR
EVRLJ - lvl 3 MSCP Exerciser KDM70 (3.0)|DONE | CPU0/1/B |
EVRLM - lvl 3 EEPROM Update KDM70 (1.2)|EVAL | CPU0/1/B | (New ucode from CXO)
EVRLN - lvl 3 DUP Driver KDM70 (1.3)|DONE | CPU0/1/B |
EVRAE - lvl 2R MSCP Exer KDM70 (3.4)|DONE | CPU0/1/B |
EVRLB - lvl 3 KDB50 Disk Formatter (7.4)|DONE | CPU0/1/B |
EVRLF - lvl 3 KDB50 Basic Subsystem(9.5)|DONE | CPU0/1/B |
EVRLG - lvl 3 KDB50/RAxx/ESE20 Exer(9.4)|DONE | CPU0/1/B |
EVRLK - lvl 3 Bad Block Utility (3.4)|DONE | CPU0/1/B |
EVRLL - lvl 3 KDB50 Error Log Util (2.3)|DONE | CPU0/1/B |
EVDAJ - lvl 2R DMB32 Asynch Lines (3.1)|DONE | CPU0/1/B |
EVDAK - lvl 3 DMB32 (4.2)|DONE | CPU0/1/B |
EVDAL - lvl 2R DMB32 Synch Lines (4.1)|DONE | CPU0/1/B |
EVDAN - lvl 2R Online Comm Link (1.1)|EVAL | CPU0 |
EVDAR - lvl 3 DHB32 (1.5)|DONE | CPU0/1/B |
EVDAS - lvl 2R DMB32, DHB32 (2.1)|DONE | CPU0/1/B |
EVDAP - lvl 3 DSB32 (1.2)|DONE | CPU0/1/B | | QUINN
EVDAQ - lvl 2R DSB32 (1.0)|DONE | CPU0/1/B | | QUINN
EVDRH - lvl 3 DRB32-M (4.0)|DONE | CPU0/1/B | |ZECCHINO
EVRVA - lvl 3 KLESI/RV20 | | | NEED A KLESI in AS1
EVRVB - lvl 2R KLESI/RV20 | | | NEED A KLESI in AS1
EVRVC - lvl 2R KLESI/RV20/RV64 | | | NEED A KLESI in AS1
EVRVG - lvl 3 KLESI/RV64 | | | NEED A KLESI in AS1
________________________________________|_____|__________|____________
________________________________________________________________________________
Diagnostic Checklist for VAX9000-440 Machine Configuration B4
________________________________________________________________________________
DIAGNOSTIC | QA |TRANS|CONFG|CLOCK|VOLT | NOTES
________________________________________|_____|_____|_____|_____|_____|_________
CONSOLE/DIAGNOSTIC CODE FREEZE | N/A | N/A | N/A | N/A | N/A |
CONSOLE MEDIA MASTER AT SSB | N/A | N/A | N/A | N/A | N/A |
CONSOLE MEDIA AVAILABLE WORLDWIDE | N/A | N/A | N/A | N/A | N/A |
DIAGBOOT | | | | N/A | N/A |
EWSAA - VAX Diag Supervisor | | | | N/A | N/A |
EVSBA Autosizer | | | | N/A | N/A |
EVKAA - lvl 4 VAX Hardcore Instrs | | | | | |
EVKAQ - lvl 2 VAX Basic Instrs 1 | | | | | |
EVKAR - lvl 2 VAX Basic Instrs 2 | | | | | |
EVKAS - lvl 2 VAX Floating Pnt Instrs 1| | | | | |
EVKAT - lvl 2 VAX Floating Pnt Instrs 2| | | | | |
EVKAU - lvl 2 VAX Privileged Instrs 1 | | | | | |
EVKAV - lvl 2 VAX Privileged Instrs 2 | | | | | |
EVKAG - lvl 2 VAX Vector Instrs 1 | | | | | |
EVKAH - lvl 2 VAX Vector Instrs 2 | | | | | |
EWKAX - lvl 3 Kernel Architectural Diag | | | | | |
EWKMP - lvl 3 Multi-Port Exerciser | | | | | |
TEST/JXDI - JXDI loopback Diags | | | | | |
EWCLA - lvl 4 XJA Adapter Diag | | | | | |
EVCLB - lvl 3 XJA Diag | | | | | |
EWCMA - lvl 4 XBI+ Diag | | | | | |
EVCME - lvl 3 XBI+ Adapter Diag | | | | | |
EVDWC NI Exerciser DEBNI, DEMNA Lvl 2R | | | | | |
EVGDB DEMNA EEPROM Update Utility | | | | | |
EVDYE DEMNA Level 2R | | | | | |
EVDYD DEBNI Level 2R | | | | | |
EVGEA CIXCD Repair Diag. Lvl 3 | | | | | |
EVGEB CIXCD Rom Update Utility Lvl 2R | | | | | |
EVGAA CI Architecture 1 | | | | | |
EVGAB CI Architecture 2 | | | | | |
EVGAC CI Architecture 3 | | | | | |
EVRLJ - lvl 3 MSCP Exerciser | | | | | |
EVRLM - lvl 3 EEPROM Update util KDM70 | | | | | |
EVRLN - lvl 3 DUP Driver KDM70 | | | | | |
EVRAE - lvl 2R Online MSCP Exerciser | | | | | |
EVRLB KDB50 Disk Formatter lvl 3 | | | | | |
EVRLF KDB50 Basic Subsystem Test lvl 3 | | | | | |
EVRLG KDB50/RAxx/ESE20 lvl 3 Exerciser | | | | | |
EVRLK - lvl 3 Bad Block Replace Utility | | | | | |
EVRLL - lvl 3 Error Log Utility | | | | | |
EVDAJ - DMB32 Level 2R Asynch Lines | | | | | |
EVDAK - DMB32 Level 3 | | | | | |
EVDAL - DMB32 Level 2R Synch Lines | | | | | |
EVDAN - Online Data Comm Link Level 2R | | | | | |
EVDAR - DHB32 Level 3 | | | | | |
EVDAS - DMB32, DHB32 Level 2R | | | | | |
EVDAP - DSB32 Level 3 | | | | | |
EVDAQ - DSB32 Level 2R | | | | | |
EVDRH - DRB32 Level 3 | | | | | |
EVRVA - KLESI/RV20 Level 3 | | | | | |
EVRVB - KLESI/RV20 Level 2R | | | | | |
EVRVC - KLESI/RV64 Level 2R | | | | | |
EVRVG - KLESI/RV64 Level 3 | | | | | |
________________________________________|_____|_____|_____|_____|_____|_________
***** CROSS REFERENCE OF DEVICE TO DIAGNOSTIC NAMES ******
--------------------------------------------------------------------------------
Device Diagnostic
--------------------------------------------------------------------------------
KA900 EVKAA EVKAQ EVKAR EVKAS EVKAT EVKAU EVKAV EVKAG EVKAH
EWKAX EWKMP
XJA EWCLA EVCLB
XBI+ EWCMA EVCME
RV20 EVRVA EVRVB EVRVC
RV64 EVRVG EVRVC
RA60 EVRAE EVRLB EVRLF EVRLG EVRLJ EVRLK EVRLL EVRLN
RA70 EVRAE EVRLB EVRLF EVRLG EVRLJ EVRLK EVRLL EVRLN
RA80 EVRAE EVRLB EVRLF EVRLG EVRLJ EVRLK EVRLL EVRLN
RA81 EVRAE EVRLB EVRLF EVRLG EVRLJ EVRLK EVRLL EVRLN
RA82 EVRAE EVRLB EVRLF EVRLG EVRLJ EVRLK EVRLL EVRLN
RA90 EVRAE EVRLB EVRLF EVRLG EVRLJ EVRLL EVRLK EVRLN
ESE20 EVRAE EVRLB EVRLG EVRLJ EVRLL EVRLN
KDB50 EVRLF EVRLG EVRLJ EVRLL EVRLK EVRLB
KDM70 EVRLJ EVRLM EVRLN
CIXCD EVGEA EVGAA EVGAB EVGAC
DMB32 EVDAJ EVDAK EVDAL EVDAS
DHB32 EVDAR EVDAS
DRB32M EVDRH
DRB32W EVDRI
DRB32C EVDRK
DRB32E EVDRJ
DSB32 EVDAP EVDAQ
DEBNI EVDWC EVDYD
DEMNA EVDYE EVGDB
--------------------------------------------------------------------------------
VAX9000 CPU Support Utility Status
--------------------------------------------------------------------------------
DIAGBOOT
Current Status:
Current version unknown
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Support Utility Status
--------------------------------------------------------------------------------
EWSAA VDS monitor for the VAX-9000_xxx
Current Status:
EWSAA.EXE;1221 causes problems with EVKAU.
EWSAA.EXE;1235 did not fix EVKAU problem
EWSAA.EXE;1241 is under evaluation for EVDRH (DRB32) problem.
EWSAA.EXE;1253 is under evaluation in 420 conf
Work in progress:
420 qualification testing
Additional work MAY be needed to support 420 and 440 conf.
Problems:
Version 13.2-1235 (and previous) causes EVDRH to fail when
multiple DRB32's were in the same XBI backplane.
Version 13.2-1241 would sometime machine check before the
VDS banner was reported.
EVSBA Autosizer (7.2)/EWSAA - VAX Diag Supervisor 13.2-1253
old> There is a problem when using CPU1 as the primary boot. This
old> MAY BE the 'ROUND-ROBIN' issue. There is no 'fix' at this moment
old> but one in the works (Dont run Autosizer or any diags that
old> interrupt {ie: EVKAS/T or I/O diags etc} when CPU1 is
old> primary boot - results unpredictable).
new> There was a change to the "SITESPECIFIC.CMD" file to change
new> the default value for CPUCNF. The change made BROADCAST the
new> default in place of ROUND_ROBIN. Once BROADCAST is the default
new> the problems encountered executing VDS/SIZER on CPU1 were fixed.
Temporary Workarounds:
Version 13.2-1235
Relocate individual DRB32 to seperate backplanes.
Left To Be Done:
Regression test version 13.2-1253
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Support Utility Status
--------------------------------------------------------------------------------
EVSBA (AUTOSIZER)
Current Status:
EVSBA.EXE version 007.002 is latest released
Work in progress:
420 qualification testing
Problems:
EVSBA Autosizer (7.2)/EWSAA - VAX Diag Supervisor 13.2-1253
old> There is a problem when using CPU1 as the primary boot. This
old> MAY BE the 'ROUND-ROBIN' issue. There is no 'fix' at this moment
old> but one in the works (Dont run Autosizer or any diags that
old> interrupt {ie: EVKAS/T or I/O diags etc} when CPU1 is
old> primary boot - results unpredictable).
new> There was a change to the "SITESPECIFIC.CMD" file to change
new> the default value for CPUCNF. The change made BROADCAST the
new> default in place of ROUND_ROBIN. Once BROADCAST is the default
new> the problems encountered executing VDS/SIZER on CPU1 were fixed.
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EVKAA - LEVEL 4 VAX Hardcore Instrs
Current Status:
V011.000 is latest released
Work in progress:
420 qualification testing
Problems:
1. There are 3 locations (FE00, FE04, FE08) that are used to
change the controlled execution (APT) of this diag. These
locations must contain a "0" for a default on a 9000_xxx.
Depending upon which bits are set, ^C will echo a "DS>" or
the program will not output END_OF_PASS, or ....etc....???
new> An EVKAA_INIT.CMD should be created to deposit the locations
new> to a "ZERO" before program execution.
old> 2. This program causes the 9000 console to enter a "HANG" state
old> if executed on CPU1 (Only have access to a 9000_420 now).
old> The console must be re-booted to regain console functions.
new> Identified problem to bad file. Obtained 'fresh' and now
new> have executed on CPU1 for 1 hour without error.
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EVKAQ - LEVEL 2 VAX Basic Instrs 1
Current Status:
V004.000 is latest released
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EVKAR - EVKAR - lvl 2 VAX Basic Instrs 2
Current Status:
V004.000 is latest released
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EVKAS - LEVEL 2 VAX Floating Pnt Instrs 1
Current Status:
V004.000 is latest released
Work in progress:
420 qualification testing
Problems:
VMS V5-4 Crashed VMS when attached to CPU1. No problem
when executed on CPU0. Test 18 (DIVF2) causes
an {{ERROR condition detected on CPU 1 - CPU 1
has halted, Halt code: 60, PC: 0006A000}}
new> I have now executed these diags on a different system (P2)
new> and pass error free. System AS1 had an open on
new> the FAD mcu and now test pass under Standalone VDS
new> and under VMS/VDS.
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EVKAT - LEVEL 2 VAX Floating Pnt Instrs 2
Current Status:
V004.000 is latest released
Work in progress:
420 qualification testing
Problems:
VMS V5-4 Crashed VMS when attached to CPU1. No problem
when executed on CPU0. Test 20 (DIVG2) causes
an {{ERROR condition detected on CPU 1 - CPU 1
has halted, Halt code: 60, PC: 0006A000}}
new> I have now executed these diags on a different system (P2)
new> and pass error free. System AS1 had an open on
new> the FAD mcu and tests pass under Standalone VDS
new> and under VMS/VDS.
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EVKAU - LEVEL 3 VAX Privileged Instrs 1
Current Status:
V004.000 is latest released
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EVKAV - LEVEL 3 VAX Privileged Instrs 2
Current Status:
V004.000 is latest released
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EWKAX - LEVEL 3 Kernel Architectural Diag
Current Status:
V001.004 is latest released
Work in progress:
420 qualification testing
Problems:
old> The default of the console reboot bit was not enabled.
old> When using CPU1 as the default boot cpu, EWKAX reported many
old> errors. I will contact the author and detemine if executing
old> on other than CPU0 supported.
new> When using CPU1 as the default boot cpu, EWKAX reported errors
new> or EWKAX hung.
new> I contacted author. He reported other than CPU0 is supported.
new> He will be working with console and VDS people to resolve the
new> problem.
new> DO NOT EXECUTE on other than CPU0 till resolved.
Temporary Workarounds:
old> At the console prompt (>>>) execute @EWKAX_INIT before running.
new> NONE yet
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EWKMP - LEVEL 3 Multi-Port Exerciser
Current Status:
V001.004 is latest released
V001.005 is being evaluated along with VDS -1271 or later
Work in progress:
420 qualification testing
(V1.4) T9 fails on _420 conf, T10 fails randomly
(V1.5) T9 passes (diag workaround), T10 Passes (not a workaround)
(V1.5) CPU1 as Primary along with VDS -1271 or later
Problems:
420 Config (two cpu's)
(V1.4) DS>START or DS>START/SECTION=DEFAULT
Test 9, Subtest 2 ERROR 8 (EXPECTED I/O INTERRUPT NOT RECEIVED)
(V1.4) DS>START/SECTION=MULTI
Test 10 (XJA ARBITRATION ERROR) {Found on Sept 19}
There appears to be an 'intermittent' failing of test 10.
This has been seen very intermittently on one machine.
Another machine has failed more frequently (out of 100 passes,
it failed 44). Fixed in V1.5
(V1.4)
Clearing "OPER" flag causes program to default to infinite run
time execution. Fixed in V1.5
(V1.4)
When CPU1 is the default boot cpu and EVSBA (autosizer) is
executed, CPU0 is assigned as KA0 and CPU1 is assigned as KA1.
If you "SELECT ALL", and than RUN EWKMP, EWKMP
will reported a "CANNOT BOOT ATTACHED PROCESSOR" error.
Fixed in V1.5 but you must also use VDS -1271 or later
Temporary Workarounds:
(V1.4) TEST 9 None
TEST 10 None
(V1.5) TEST 9 Fixed
(V1.5) TEST 10 Fixed
(V1.4)
When CPU1 is the default boot cpu and EVSBA (autosizer) is
executed, CPU0 is assigned as KA0 and CPU1 is assigned as KA1.
Operator must execute the DESELECT KA0 command:
DS>DES KA0
Fixed in V1.5 but you must also use VDS -1271 or later
Operator must not execute the START/SEC=MULTI as it will
also fail.
Left To Be Done:
V001.005 evaluation
440 qualification testing
************************************************************8
attachment refers to V1.5 changes
************************************************************8
From: AQUA::DELAHUNT 19-OCT-1990 08:42:39.10
To: BROMMELHOFF
CC: HPSCAD::SHOOP,DELAHUNT
Subj: EWKMP
The situation about EWKMP is as follows.
It failed solidly on AS6 for a while, and Mike Badzinski and I started
debugging it there. We discovered that the code is in violation of DEC STD 032
because the code relies on 2 CPUs setting bits in the same byte via BBSS ( and
similar ) instructions. DEC STD 032 says this can give an indeterminate result.
When Mike replaced the BBSS with an interlock instruction ( BBSSI ),
the code then worked on AS6.
HOWEVER, even though the code violated the rules, I could not figure
out what the actual failure mechanism was, so I was unwilling to leave it at
that, in case the interlock instruction had made the problem go away for a
different reason.
We have had plenty of other problems to look at on P2 for the past 2
weeks, so we have never got back to this.
We also believe that the problem is in some way related to whether
interrupts are broadcast, or dispersed in Round Robin mode. Mike B had said
that he thought the problem happened whichever interrupt mode was in use, but
a later test of that theory was inconclusive, the test would not break at that
time.
Since we have found plenty of SCU microcode bugs on P2 during the
last 3 weeks, I ventured the opinion that one of these fixes "might" have
fixed EWKMP. This has not been tested, since we are still at least one bug
away from having ( LINK1I + XCT traffic ) be totally reliable on P2.
Maybe the best solution for the time being is to make the interlock
change to the code, and see if that fixes the problem reliably, on at least
several different duals. In parallel, we should open a QAR, which should not
get closed until we fully understand the problem.
Steve Delahunt
************************************************************8
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EVKAG - LEVEL 2 VAX Vector Instrs Part I
Current Status:
V002.000 is latest released
V003.000 is under evaluation
Work in progress:
420 qualification testing
Working to localize and fix a bug in V3.0 test #1
Problems:
V3.0 Test #1 fails with a reserved operand fault
The author is working on the problem and has found
by limiting the constraints used in the vector length
register to <64, the error does not occur. He has been
in contact with Frank Mckeen for input/feedback.
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 CPU Functional Diagnostic Status
--------------------------------------------------------------------------------
EVKAH - LEVEL 2 VAX Vector Instrs Part II
Current Status:
V002.000 is latest released
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EWCLA - XJA Level 4 Diagnostic
Current Status:
V1.6 is latest released (BL11)
V1.9 is under evaluation
Work in progress:
420 qualification testing
Working on qualification and code cleanup for V1.8
V1.9 has run on multiple XJA's and now starting to
run with multiple CPU's.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVCLB - XJA Level 3 Diagnostic
Current Status:
V001.008 is latest released
V001.009 just released
V001.010 being evaluated
Work in progress:
420 qualification testing
old> New revision of gate array (pass 3) caused problems with V1.8
old> and the author is fixing them. The next revision will be
old> released in the near future.
new> I ran V1.9 on both CPU0 and CPU1 (upside down and backwards)
new> and found no problems executing by its self.
new> V1.9 still has a problem if executed before EWKMP as KMP fails
new> one test (T8, ST1, E2) with buffer data compare error.
new> The author is currently installing some 'clean-up' code and
new> V1.10 is expected today.
Problems:
EVCLB (rev 1.9 or before), may cause EWKMP to fail test 8.
Temporary Workarounds:
After executing EVLCB (rev 1.9 or before), execute the
following:
DS> EXIT
>>> SCLK OFF
>>> I/IO
>>> CONTINUE
DS>
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EWCMA - XBI+ Level 4 Diagnostic
Current Status:
V1.6 being evaluated
Work in progress:
420 qualification testing
V1.6 has run on multiple XBI's and now starting to
run with multiple CPU's and XJA's.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVCME - XBI+ Level 3 Diagnostic
Current Status:
Not released. Pending completion of EWCMA.
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
Complete development and debug.
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDWC - DEBNA, DEBNI Level 2R Exerciser
Current Status:
V003.002 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDYE - DEMNA Level 2R
Current Status:
V002.000 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDYF - DEBNA Level 3 ***** UNSUPPORTED ON VAX9000 *****
Current Status:
V001.001 does not support the DEBNI. Since the VAX9000 will
not support the DEBNA we will do no further testing on this
diagnostic.
Work in progress:
None.
Problems:
None.
Left To Be Done:
None.
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVGDB - DEMNA EEPROM Update Utility Level 3
Current Status:
V001.003 is latest released
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVGEA - CIXCD Level 3
Current Status:
V2.01 is latest released
Requires V1.0 of CIXCD.BIN microcode file
V1.4 of CIXCD.BIN microcode file has just been released but
just started regression testing.
Work in progress:
420 qualification testing
V2.02 is being developed (Several Plus-1 requests) for REL42.
If it is decided to enable hardware EEPROM data protection, the
revision of the program will be changed to V3.0 before release.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVGEB - CIXCD Level 3
Current Status:
V002.000 is latest released
Work in progress:
See EVGEA
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVGAA - CI Architecture 1
Current Status:
V006.001 is latest released
V006.002 is under evaluation but does not display Path A/B
V006.002 is under evaluation
Work in progress:
420 qualification testing
Verify that V006.002 fixes intermittent problem in V006.001
Problems:
V006.001 has intermittent failure caused by unitialized memory
buffer.
V006.002 does not display the Path A and Path B config
correctly at some executions. It does report correctly on
other based cpu's.
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVGAB - CI Architecture 2
Current Status:
V006.001 is latest released
V006.002 is under evaluation
Work in progress:
420 qualification testing
Verify that V006.002 fixes intermittent problem in V006.001
Problems:
V006.001 has intermittent failure caused by unitialized memory
buffer.
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVGAC - CI Architecture 3
Current Status:
V001.001 is latest released
V001.002 is under evaluation
Work in progress:
420 qualification testing
Verify that V001.002 fixes intermittent problem in V001.001
Problems:
V001.001 has intermittent failure caused by unitialized memory
buffer.
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRLJ - KDM70, ESE20, RAxx ,KDB50 Level 3 MSCP Exerciser KDM70
Current Status:
V003.000 is latest released
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRLM - KDM70 Level 3 EEPROM Update util KDM70
Current Status:
V001.002 is latest released
Work in progress:
420 qualification testing
Problems:
We are having trouble update the EEPROM. On two attempts
the data appears to be corrupted and the self test lamps
then fail to light. It is possible that the microcode
file may be corrupted and we are trying to resolve.
new> Obtained 'fresh' IMAGE.ECC microcode from CXO and was able
new> to load the 'stricken' KDM70 with this 'fresh' image. Also
new> went back and reloaded bad ucode and then reloaded fresh
new> once again. The only 'gray' area has to do with reporting
new> the software revision # (Function 8) in that the format
new> is displayed in a different way in the two sections of EVRLM
new> (just an observation not a problem).
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRLN - KDM70 , RAxx, ESE20 Level 3 DUP Driver KDM70
Current Status:
V001.002 is latest released
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRAE - KDM70, KDB50, RAxx, ESE20 Level 2 MSCP Exer KDM70
Current Status:
V003.004 is latest released
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRLB - KDB50, RAxx, ESE20 Level 3 Formatter
Current Status:
V007.004 is latest released
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRLF - RAxx, KDB50 Level 3 KDB50 Basic Subsystem
Current Status:
V009.005 is latest released
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRLG - RAxx, KDB50, ESE20 Level 3 Exerciser
Current Status:
V009.004 is latest released
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRLK - RA60, RA70, RA8x Level 3 Bad Block Utility
Current Status:
V003.004 is latest released
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRLL - RAxx, KDB50, ESE20 Level 3 Device Error Log Utility
Current Status:
V002.003 is latest released
V003.000 has been submitted for REL42 but we dont have yet.
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDYC - DEBNA Level 3 ***** NOT SUPPORTED ON VAX9000 *****
Current Status:
This diagnostic will not work on a DEBNI.
Since the VAX9000 will not support the DEBNA no further
testing of this diagnostic will be done.
Work in progress:
None.
Problems:
None.
Left To Be Done:
None.
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDYD - DEBNA, DEBNI Level 2R
Current Status:
V002.006 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDAJ - DMB32 Level 2R Asynch Lines
Current Status:
V003.001 is latest released
Work in progress:
420 qualification testing
Only DEFAULT section has been tested.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDAK - DMB32 Level 3
Current Status:
V004.001 is latest released but fails test 9.
Work in progress:
420 qualification testing
V004.002 has been obtained from the developers.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDAL - DMB32 Level 2R Synch Lines
Current Status:
V004.001 is latest released
Work in progress:
420 qualification testing
Only DEFAULT section has been tested.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDAS - DMB32, DHB32 Level 2R
Current Status:
V002.001 is latest released
Work in progress:
420 qualification testing
Only DEFAULT section has been tested.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDAR - DHB32 Level 3
Current Status:
V001.005 is latest released
Work in progress:
420 qualification testing
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDRH - DRB32-M Level 3 Functional Test
Current Status:
V003.001 is latest released.
On 9000_xxx, Test 13, Error 3 was detected (Error
interrupt test). Also VDS/EVDRH problems with multi
units were detected. See EWSAA status.
V003.002 has been generated but not all program sections
have been tested to date.
V004.000 has been released.
Work in progress:
420 qualification testing
Problems:
None with V4.0
Temporary Workarounds:
None with V4.0
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDRI - DRB32-W Level 3
Current Status:
V003.000. This diagnostic will not be tested by the diagnostic
group. The diagnostic group will only test the DRB32-M.
The various DRB32 personality modules variants DRB32-E and
DRB32-W will be tested by SASE as noted in the memo from
Jim McAndrew of VAX9000 Product Management dated 20-FEB-1990.
Work in progress:
Rich Zecchino is currently evaluating this diagnostic to ensure
that it will work in the VAX9000 environment
Problems:
None.
Left To Be Done:
None.
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDRJ - DRB32-E Level 3
Current Status:
This diagnostic will not be tested by the diagnostic
group. The diagnostic group will only test the DRB32-M.
The DRB32 personality module variant DRB32-C
will be tested by the southwest engineering group in ABQ as
noted in the memo from Jim McAndrew of VAX9000 Product
Management dated 20-FEB-1990.
Work in progress:
Rich Zecchino is currently evaluating this diagnostic to ensure
that it will work in the VAX9000 environment
Problems:
None.
Left To Be Done:
None.
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDRK - DRB32-C Level 3
Current Status:
This diagnostic will not be tested by the diagnostic
group. The diagnostic group will only test the DRB32-M.
The DRB32 personality module variant DRB32-C
will be tested by the southwest engineering group in ABQ as
noted in the memo from Jim McAndrew of VAX9000 Product
Management dated 20-FEB-1990.
Work in progress:
Rich Zecchino is currently evaluating this diagnostic to ensure
that it will work in the VAX9000 environment
Problems:
None.
Left To Be Done:
None.
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDAP - DSB32 Level 3
Current Status:
V001.001 is latest released
V001.002 is under evaluation
We have executed the default, selftest, downline, microcode,
interface and manual sections without errors.
Work in progress:
420 qualification testing.
Author has supplied an PRELIMINARY COPY (V001.002) with
all test fixed.
Problems:
V001.001
Test 34 fails - A timer of 64 is used to wait for a queue
operation to complete. This timer is not long
enough on a 9000. Changing it to approx 70 will
cause this test to pass. The timer value will
be doubled to 128.
Test 35/36 The file EVDAPMIC.EXE that was released had an
Test 37/38 "Record format: Undefined" which the 9000
console did not know how to handle. Resulting
in the console hanging and the console had to be
rebooted. (1) Eng. fixed the console software
in BL11 not to hang but report FILE NOT FOUND
error status. (2) Use EVDAPMIC.EXE file that has
had the Record format changed.
Test 37 Fails with error code of 11
Test 38 Fails with error code of 4 or 7 or 11
Temporary Workarounds:
V001.001
Test 34 Install a two loc patch for delay counter.
( BASE=85E4 LOC.183=40>80, LOC.257=40>80 )
Test 35/36 Use BL11 and verify that "DIR/FULL EVDAPMIC.EXE"
Test 37/38 displays "Record format: Fixed length"
Test 37/38 None at present time.
Left To Be Done:
Verify the 'final' version (V001.002) when available from author.
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVDAQ - DSB32 Level 2R
Current Status:
V001.000 is latest released.
We have executed the default section.
Work in progress:
420 qualification testing
Problems:
old> On two different 9000's this program appears to hang and
old> just issue 1 min status information. It was found that the
old> microcode file had been corrupted. We have now run with
old> the default and external loopback (No external clock).
new> Found that the driver was also corrupted and have replaced
new> it. The program now executes properly on a 9000.
Temporary Workarounds:
None
Left To Be Done:
440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRVA - RV20 Level 3
Current Status:
V003.001 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRVB - RV20 Level 2R
Current Status:
V003.001 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRVC - RV20/RV60/RV64 Level 2R
Current Status:
V001.000 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
This diagnostic has never been run because we do not have
an RV64 in the lab. Ravi Ganesan is to make arrangements for
obtaining the hardware needed to complete this testing.
420 & 440 qualification testing
--------------------------------------------------------------------------------
VAX9000 I/O Device Functional Diagnostic Status
--------------------------------------------------------------------------------
EVRVG - RV64
Current Status:
V001.003 is latest released
Work in progress:
None.
Problems:
None
Temporary Workarounds:
None
Left To Be Done:
This diagnostic has never been run because we do not have
an RV64 in the lab. Ravi Ganesan is to make arrangements for
obtaining the hardware needed to complete this testing.
420 & 440 qualification testing
|
| 78.82 | Use of lubricant on MCU screws (IMPORTANT !) | KERNEL::WRIGHTON | odd numbered release = bug insert | Tue Nov 06 1990 09:49 | 52 |
|
The following text is VERY important, failure to follow the procedure
may well result in the either the screw snapping off in the planar
or the planar being permanently damaged !!!
Lubricant Application and MCU/Screw Replacement
------------------------------------------------
Ray Molloy.
This PELIMINARY procedure outlines the process for installation of MCU
Upgrades in the Field.
Guidelines:
-----------
- This operation must be executed with EXTREME CARE adhering rigidly
to this procedure thus minimizing the dispersion of Contamination
to Planar Subassemblies/parts.
- Disposable Cleanroom gloves must be used during this Lubrication
process. Never handle any other planar parts/subassemblies except
the MCU Screws when using the disposable gloves as this will aid
in lubricant particulate dispersion.
- Should over-spill occur, use a Wipe to remove any excess lubricant.
- Lubricant must only be applied using a syringe to the specified
areas.
Process.
--------
- Prior to removal of the 4 MCU screws (a) 2 drops of lubrication must be
applied to the MCU screw threads that protrude from the back of the
casting and (b) 1-2 drops of lubrication will be applied directly at
the point were the screw protrudes from the casting (solid body insert).
- Wait for approx 5-10 minutes to allow the lubricant to wick its
way between the mating surfaces of the MCU screw and the solid body
insert in the casting.
- as per the MCU Installation/Removal Spec extract each of the MCU
screws.
- dispose of the 4 removed screws.
- Apply 2-3 drops of lubricant along the BOTTOM HALF of the "unused"
10-32 2A Die cut MCU Screws and remove any excess lubrication (if any)
with a wipe.
- Install the Screws adhering to the MCU Installation/removal Procedure.
|
| 78.83 | latest revsion info | KERNEL::WRIGHTON | odd numbered release = bug insert | Tue Nov 06 1990 10:56 | 273 |
|
Below I have rolled up the MCU,Ucode and SPU revision information.This
is the latest currently available.
MCA STATUS FOR KERNEL CONFIGURATIONS B5 and C1
==============================================
ECOSTATUS.MEM
10/4/90
JURGEN
B5:
===
MCU MCA MCA PTOTO MCU PROTO ECO Owner ECO Status
TYPE TYPE FROM MOTO FROM MFG. Kernel 70- P1x 54- 19-
==== ==== ========= ========= ========= ====== === === === ===
CTU 10/8/90 R.Hetherington TBS TBS IR IR
CTMA.D1 Avail. R.Hetherington IR
CTMV.M1 Avail. R.Hetherington IR
C1:
===
MCU MCA MCA PTOTO MCU PROTO ECO Owner ECO Status
TYPE TYPE FROM MOTO FROM MFG. Kernel 70- P1x 54- 19-
==== ==== ========= ========= ========= ====== === === === ===
VAP TBD R.Hetherington TBS TBS TBS TBS
VAPO.H1 D.S. R.Hetherington TBS
CCSQ.H1 Avail. R.Hetherington TBS
CCU TBD S.Delahunt TBS TBS TBS TBS
CTLA.D1 Avail. S.Delahunt TBS
CTLB.D1 Avail. S.Delahunt TBS
CTLD.D1 Avail. S.Delahunt TBS
TAG TBD S.Delahunt TBS TBS TBS TBS
ADRX.D1 Avail. S.Delahunt TBS
DAX Avail. S.Delahunt TBS TBS TBS TBS
DSXX.C1 Avail. T.Fissette TBS
JDCX.C1 Avail. S.Delahunt TBS
DBX TBD T.Fissette TBS TBS TBS TBS
DSXX.C1 Avail. T.Fissette TBS
MMCX.D1 Avail. T.Fissette TBS
Process:
TBS To be supplied
IR In Review
D.F.. Designing a fix for problem
L.B. Loopback Process, i.e. SID Synthesis, Auto Placement, Auto Routing
T.F. Timing Fix resulting from Timing violation with new layout
D.S. Design Services, manually fixing unroutes, Rules Checking
F.C. Final Checking and Sign-off
TO MOT = Back from D.S. plus 2 days
MCA revisions and Bug Fixes
---------------------------
BOX MCU MCA Bug that is fixed by this revision
--- --- --- ----------------------------------
MBOX VAP VAPO.F1 MAX INSTRUCTION SEQUENCE MISMATCH (MEDIUM
LIKELYHOOD TO OCCUR IN REAL APPLICATIONS)
VAPO.H1 INSV BUG
VAP CCSQ.F1 FOR HIGH I/O LOADS, SINGLE CYCLE VULNERABILITY
TO RETIRE REQUESTS OUT OF ORDER
VAP CCSQ.H1 CACHE SWEEP BUG, CACHE SBE RECOVERY BUG
CTU CTMA.D1 CACHE SWEEP BUG
CTU CTMV.L1 CACHE SWEEP BUG
CTMV.M1 FETCHING BAD PTE BUG
JBOX DBX MMCX.D1 REPORTING SBEs (THAT OCCUR AT HIGH RATE) TO SPU
SLOWS DOWN MEMORY ACCESS
ACCIDENTALLY LEFT OUT FIX IN MMCX.C1 TO
FIX MEM STEP PROBLEM
TAG ADRX.D1 CPU AND SCU CLOCKS MUST BOTH BE TURNED OFF
DURING ERROR RECOVERY, VMS CAN'T DEAL WITH
ALL POSSIBLE TYPES OF RESULTING I/O TIMEOUTS.
DAX,DBX DSXX.C1 - SAME AS ABOVE -
CCU CTLA.D1 - SAME AS ABOVE -
CCU CTLB.D1 - SAME AS ABOVE -
CCU CTLD.D1 1. SPU POWER OK SCAN LATCHES CAUSE SCAN TO
UPSET THE XJA IF THE SCU MCUS ARE
BROADCAST SCANNED, WHICH IS REQUIRED FOR
MEMORY SINGLE STEP.
2. SPU INTERFACE HANGS IF SPU READS MEM AND
GETS DBE.
DISABLING A PARITY CHECK AVOIDS THIS.
3. SOME CHANCE OF SPU INTERFACE HANGING IF
SPU IS POWERED OFF AND MEM HAS ECC EVENT.
4. LOGIC WHICH HANDLES SPU ERRORS REDEFINED.
DBX JDCX.C1 2 LATCHES MISSING CREATES POTENTIAL WORST CASE
TIMING PROBLEM. NEW PROGRAMM. DELAY PROMS IN
MCM CORRECTED PROBLEM IN LAB SYSTEMS
PHASE IN CHIPS (CONFIG.C2)
===================================
BEST CASE
CHIP MCU STATUS AVAIL. STATUS
---- ----- ------ ------- -------
VMLB-C1 VML @MOTO ENG. DEMAND FILLED
VFPK-C1 VAD @MOTO ENG. DEMAND FILLED
USQB-C1 INT @MOTO ENG. DEMAND FILLED
USQA-D1 INT @MOTO ENG. DEMAND FILLED
ISSC-E1 CTL @MOTO ENG. DEMAND FILLED
OSQA-F1 OPU @MOTO ENG. DEMAND FILLED
VMLB.C1 Vector Performance
VFPK-C1 Vector Performance
USQB-C1 Error Interrupt
USQA-D1 Interrupt Scenario
ISSC-E1 MAX with Branches + H-Float Emulation
OSQA-F1 MAX Case Failure
Microcode revisions
===================
26-OCT-1990
;**********************************************************************
AQUA::EBOX$DISK:[SAMBERG.B4] -- B4
AQUARIUS.*.5021 E325
;**********************************************************************
AQUA::EBOX$DISK:[SAMBERG.B5] -- CTMV rev M
AQUARIUS.*.7002 F325
;**********************************************************************
AQUA::EBOX$DISK:[SAMBERG.C2] -- B4 with C2 vector chips
AQUARIUS.*.6001 F317 -- VLR workaround removed
;**********************************************************************
All ucodes use FRAM_A52.*.4000 for vector and
NO_VEC_FRAM_B52.*.4000 for no vector
All ucodes use CONSTANT.*.13 A001
;**********************************************************************
Aquarius versions:
325 (1) Deleted 320
(2) VLR -- added code to vlr hack that does
not change VLR if value unchanged
322 In CMPCx and MOVCx, add a write.mreg after a
clear ebox read fault to keep ib
request from fouling up aborted ebox
request that was unsequenced and had
a tb-miss
321 In TBIS, add an ebox request to keep ib
request from getting stale pte
320 Count mm successful retries, but with no hooks
to access it. Counter is in EREG[0DC].
319 On INSV and BBXX, do chk wrt success to prevent
flushes from breaking sequencer operation
317 On REI, avoid stram conflict to avoid situation
that could allow a premature trace
316 (1)On vector stores and scatters, do a check
write success to empty ebox data buffers,
thus avoiding data overrun by the vbox
(2)Implement cpu pause/resume feature using EREG[D1]
315 On cache sweep hack -- If base address found in
EREG[D0] = 0, nop the hack. Also, do
256K so we can use RPB address and still
ensure a sweep
SPU Revisions (from BL 11 onwards)
==================================
1) release notes.
I realize as well as everybody else this is pain not having these. We actually
have the notes as release by engineering which I could send you 4 guys to
review, but frankly, we held them because we didn't like several references to
pulling MCUs that were included in the Scepter pattern notes buried in the
release notes. We (Dino) asked engineering to rewrite this. I have not had any
response from engineering personally and don't think Dino has either.
2) 11.1
There was/is a kit called 11.1, but to avoid some confusions, I didn't make a
big deal out of releasing it. I worked on the net release of 11.0 first, then
thought I'd create a saveset of the 11.1 stuff and make that available.
The biggest thing in 11.1 is the ucode version ;320 that we have in
MRCSSE::PUBLIC. Since alot of sites that need this have been getting it, it
seemed to be cause for a confusion factor to also announce release of 11.1.
The files in this "release" (more like an update) are:
Directory NONAME:[LEITZ.BL11_1]
AQUARIUS.LOD;10 219 12-OCT-1990 07:43:00.59 (R,RWED,R,)
AQUARIUS.MCR;10 7193 12-OCT-1990 07:43:00.89 (R,RWED,R,)
AQUARIUS_DIFF.TXT;2
6 12-OCT-1990 07:43:01.28 (R,RWED,R,)
CIXCD.BIN;1 353 12-OCT-1990 07:43:01.42 (R,RWED,R,)
MEDIA_REV.DAT;1 1 12-OCT-1990 07:43:01.66 (R,RWED,R,)
Total of 5 files, 7772 blocks.
As you can see, the CIXCD ucode and the Aquarius Ucode have been going out via
our public area (and the CIXCD has been going out via all kinds of
announcements we don't control). The media_rev.dat file merely updates the one
on the target to "11.1" and the .MCR is the listing for ;320. The DIFF file is
just based on ucode and describes (in bullet form) some of the recent changes
in ucode.
I'll put this stuff in AQ$SPU$11_1 eventually and announce it, but we'll be
coming out with other stuff that will cause this to be superceded pretty soon,
so maybe I'll hold off.
FYI, SPU software release schedule:
BL 11.0 available now in SSB and from CSSE via network.
BL 11.1 ucode ;320 upgrade, new CIXCD ucode release elsewhere.
BL 11.2 support for hardware revision B5.
will be a non-SSB patch tape (complete kit) with new files:
- B5 CBD
- B5 SPDF and SPDI files
- possible new SPD.EXE
BL 12.0 hardware B4
BL 12.1 hardware B5
both kits are hardware rev dependent. install procedure will prompt
for what hardware rev you have (we can automatically read the revs
of the system and figure this out, but the CD's haven't been getting
the right etch cuts and REVs of a system can't be defined by the CDs
(yet) as was the original plan)).
The diag tape will be release as a MAGTAPE as well as a TK50 so we
can update the [sysmaint] area from VMS is desired.
This kit will be FT'd at Boeing and Reuters. More on this later.
SSB release planned for 12/25 (Merry Christmas).
BL 13.0 hardware rev C5 support. no more details yet.
There is a "funny" flavor out now on -420 machines that was driven by program
demands on releasing 420s. I think it says 11.2 in the SYSBOOT image when
booting.
I'll chase release notes today.
Butch
|
| 78.84 | latest buglist | KERNEL::WRIGHTON | odd numbered release = bug insert | Thu Nov 08 1990 08:47 | 2000 |
|
VAX 9000 "BUG" List
Revision/Update Information: 7-November-1990
DIGITAL CONFIDENTIAL
Published by:
o ISBS / CSSE
Digital Equipment Corporation
________________________
Aug 1990
__________
The information in this document is subject to change without
notice and should not be construed as a commitment by Digital
Equipment Corporation. Digital Equipment Corporation assumes no
responsibility for any errors that may appear in this document.
The software described in this document is furnished under a
license and may be used or copied only in accordance with the
terms of such license.
No responsibility is assumed for the use or reliability of
software on equipment that is not supplied by Digital Equipment
Corporation or its affiliated companies.
__________
Copyright �1990 by Digital Equipment Corporation
All Rights Reserved.
Printed in U.S.A.
__________
The postpaid READER'S COMMENTS form on the last page of this
document requests the user's critical evaluation to assist in
preparing future documentation.
The following are trademarks of Digital Equipment Corporation:
DEC DIBOL UNIBUS
DEC/CMS EduSystem VAX
DEC/MMS IAS VAXcluster
DECnet MASSBUS VMS
DECsystem-10 PDP VT
DECSYSTEM-20 PDT
DECUS RSTS
DECwriter RSX DIGITAL
This document was prepared using VAX DOCUMENT, Version 1.2
CONTENTS
Chapter 1 CPU/SCU SUBSYSTEM:............................. 1
1.1 CPU/SCU Subsystem:................................. 1
1.1.1 Minimum Revisions:.............................. 1
1.1.2 Hardware:....................................... 1
1.1.3 uCode:.......................................... 5
1.1.4 Software:....................................... 5
Chapter 2 MASTER CLOCK SUBSYSTEM:........................ 7
2.1 CLOCK BUG #1....................................... 7
2.1.1 Minimum Revisions:.............................. 7
2.1.2 Diagnostics:.................................... 7
2.1.3 Software:....................................... 7
Chapter 3 I/O SUBSYSTEM.................................. 9
3.1 I/O Subsystem:..................................... 9
3.1.1 Minimum Revisions:.............................. 9
3.1.2 Hardware:....................................... 11
3.1.3 uCODE:.......................................... 15
3.1.4 Diagnostics:.................................... 15
Chapter 4 POWER SUBSYSTEM................................ 19
4.1 POWER Subsystem:................................... 19
4.1.1 Minimum Revisions:.............................. 19
4.1.2 Hardware:....................................... 21
4.1.3 uCode:.......................................... 22
4.1.4 Software:....................................... 22
4.1.5 Documentation:.................................. 24
iii
Chapter 5 SPU SUBSYSTEM:................................. 27
5.1 SPU BUG #6......................................... 27
5.2 SPU BUG #5......................................... 28
5.3 SPU BUG #4......................................... 28
5.4 SPU BUG #3......................................... 28
5.5 SPU BUG #2......................................... 28
5.5.1 Minimum Revisions:.............................. 28
5.5.2 Software:....................................... 29
5.6 SPU BUG #1......................................... 29
5.6.1 Minimum Revisions:.............................. 29
5.6.2 Software:....................................... 29
Chapter 6 MEMORY SUBSYSTEM:.............................. 31
6.1 MEMORY Subsystem:.................................. 31
6.1.1 Hardware:....................................... 31
6.1.2 uCode:.......................................... 34
6.1.3 Software:....................................... 34
Chapter 7 INSTALLATION:.................................. 35
7.1 Installation BUG #2................................ 35
7.2 Installation BUG #1................................ 35
7.2.1 Minimum Document Revisions:..................... 35
7.2.2 Tools and Tool Usage:........................... 35
Chapter 8 VMS SUBSYSTEM:................................. 39
8.1 VMS Subsystem:..................................... 39
8.1.1 Minimum Revisions:.............................. 39
8.1.2 Software:....................................... 39
iv
CHAPTER 1
CPU/SCU SUBSYSTEM:
1.1 CPU/SCU Subsystem:
1.1.1 Minimum Revisions:
o Hardware:
_____________________________________________________________
OPTION_________Rev______Comments_____________________________
CPU B4 (CDB revision)
SCU____________B3_______(CDB_revision)_______________________
o uCODE:
_____________________________________________________________
OPTION___Rev______Comments___________________________________
CPU N/A
SCU______N/A_________________________________________________
1.1.2 Hardware:
1. Bug 6: BUGCHECK/HALTS Caused by Cache Control Design Bug
System crashes with Kernel Mode Halts or Bugchecks. The halts
and bugchecks are at or around the same PC usually in a I/O
CPU/SCU Subsystem: 1
device driver. There would most likely be and instruction
that will be doing a write to an I/O device register. The
only error bits that may be latched are NXM errors. In one
of the systems increasing the sysgen paramenter NPAGEDYN by
1,200,000 enabled the system to run without any halts.
The symptoms vary, but include,
I-stack not valid -- bogus PTE loaded
exception above ASTDEL -- bad i-stream fetched
page-fault, IPL too high -- bogus PTE loaded
HALT -- i-stream fetches zero's
mem nxm, read or write -- wild translation
io nxm, read or write -- wild translation
Cause:
The system failures are caused by improper virtual address
translations in the MBox. The effect of the logic bug
is that a page table entry (PTE) is loaded into the
translation buffer (TB) incorrectly.
The bug is provoked by the incidence of a TB miss while
a CPU write, typically to I/O space, is delayed due to
a hardware resource wait. During this delay, cache set
selection information is frozen (even if the CPU write is
non-cacheable, as in I/O space writes). To resolve the TB
miss, the fixup processor requests the cache to deliver
the appropriate PTE for loading into the TB. If the PTE
resides in the OPPOSITE cache set that is selected during
the write-delay, incorrect data will be delivered to the
TB, thus causing an improper virtual address translation.
Only fixup processor requests are vulnerable to this cache
malfunction, because this is the only type of request that
2 CPU/SCU Subsystem:
the cache's arbitration logic allows to proceed while CPU
writes are in progress.
The effects of the problem are varied. Improper
translations can lead to a variety of exceptions, and
in some cases hardware error conditions.
Fix:
This is a hardware problem, but we have some some
WORKAROUNDS:
Systems with BI devices should get:
MRCSSE::NONAME:[PUBLIC]LIDRIVER.EXE
MRCSSE::NONAME:[PUBLIC]PUDRIVER.EXE
MRCSSE::NONAME:[PUBLIC]SIDRIVER.EXE
MRCSSE::NONAME:[PUBLIC]YIDRIVER.EXE
The FIX for this problem will be Revision B5 release
which should occur sometime in November. The WORK
AROUND for this problem is to disable one of the
Cache Sets by depositing the following command in
CSA1:[SYSEXE]SITEINIT.CMD. This work around should be
applied only when absolutely sure that it is need to
resolve a particular problem. Contact CSSE if unsure that
disabling half of cache will resolve a problem. Disabling
one cache set could lead to a significant decrease in
performance depending on how the system is used doing
mostly I/O or compute bound jobs. Engineering is currently
looking into a VMS and UCODE change as a workaround.
! DISABLE SET 0
D/CPU=('CPU') CTU.CTMV.SET_SEL_H<1> 1
CPU/SCU Subsystem: 3
2. Bug 5: MBOX Cache Sweep Problems
Cause:
Fix:
For more information see;
MRCSSE::NONAME:[PUBLIC]CACHE_SWEEPS.TXT
3. Bug 4: Intermittent MULX parity errors on the VML MCU in the
VBOX
4. Bug 3: Intermittent STGX parity errors on the DST MCU or OPU
MCU
5. Bug 2: Intermittent MULX parity errors on the MUL MCU
Cause:
Fix:
For more information see;
MRCSSE::NONAME:[PUBLIC]VML_MULX.TXT
For more information see; MRCSSE::NONAME:[PUBLIC]STGX.TXT
For more information see;
MRCSSE::NONAME:[PUBLIC]MUL_MULX.TXT
6. Bug: SCU Error Reporting is disabled
Cause: Error logic debug is not complete
Fix: Error reporting will be turned on in a future
release of SPU software. Please note, that most errors
are detected and the status is latched in the SCU. The
reporting mechanisms are disabled.
For more information see;
MRCSSE::NONAME:[PUBLIC]SCU_ERR_ENA.TXT
4 CPU/SCU Subsystem:
7. Bug 1: Intermittant VREG, IBANK2, and TBRAMS structure test
failures
Cause: Test setups/phase of moon...etc
Fix: Upgrade SPU to BL 11.0 in SSB now......... The VREG
and IBANK2 failures will be resolved in SPU software
release Base Level 11. Engineering has been unable to
reproduce the TBRAMS failure and would be interested in
hearing about any sequences of events that can produce the
failure.
Note: The TBRAMS failure appears to be the results of some
other structure in some specific state. When the state
of this unknown influence changes, TBRAMS runs without
failure. This is not a hardware problem
1.1.3 uCode:
1. Bug: No Known Problems
Cause:
Fix:
1.1.4 Software:
1. Bug: No Known Problems
Cause:
Fix:
CPU/SCU Subsystem: 5
CHAPTER 2
MASTER CLOCK SUBSYSTEM:
2.1 CLOCK BUG #1
2.1.1 Minimum Revisions:
o Hardware: Master Clock Module 70-25847-02 Revision D
2.1.2 Diagnostics:
o Bug: Running SCAN Hardcore test from SPU on the Master Clock
Module runs fine, but leaves Master Clock Module in incorrect
state. Actual SPU command is ">>>Test/clock <CR>" .
o Cause: SCAN Hardcore Test deficiency.
o Fix: Upgrade to SPU BL11.0. Execute an initialize/clock from
the SPU after running SCAN Hardcore Test on Master Clock
Module. Actual SPU command is ">>>Initialize/clock <CR>" .
2.1.3 Software:
o Bug: SPU command that initializes Master Clock Module doesn't
set the Frequency to system nominal value. Note: SPU commands
that initializes Kernel DOES set system frequency to the
nominal value of 500 MHz.
o Cause: Actual SPU command is ">>>Initialize/clock <CR>" .
MASTER CLOCK Subsystem: 7
o Fix: After using the SPU command ">>>Initialize/clock
<CR>" , then execute the following SPU command ">>>Set
clock/frequency=500 <CR>" , which will set the Master Clock
Module to the system's nominal frequency.
8 MASTER CLOCK Subsystem:
CHAPTER 3
I/O SUBSYSTEM
3.1 I/O Subsystem:
3.1.1 Minimum Revisions:
o Hardware:
_____________________________________________________________
OPTION___________Rev________Comments_________________________
XJA C04
CIXCD
T2080-00 E02
54-20225-01 B01 Rev A01 needs cover added
74-42384-01 Header Cover Component
74-42385-01 Header Cover Plate
DEMNA F02 T2030
KDM70 A Two module set
T2022 D01,E01
I/O Subsystem 9
_____________________________________________________________
OPTION___________Rev________Comments_________________________
T2023 C01,C02
DWMBB A04 T2018
DRB32-M C02 T1022
DMB32 L T1012
DHB32 D01 T1044
DSB32 BX01 T1042
DEBNI C5/C6/C7 T1034
KDB50
T1002 N03
T1003 B07
KLESI____________D2_________T1014____________________________
o uCODE:
_____________________________________________________________
OPTION___Rev______Comments___________________________________
XJA V2.3
CIXCD V0.38 Diagnostic
V1.04 Functional
DEMNA V6.04
10 I/O Subsystem
_____________________________________________________________
OPTION___Rev______Comments___________________________________
KDM70 V2.2
DMB32 V13 T1012
DEBNI____3000_____T1034______________________________________
o Software:
_____________________________________________________________
OPTION___________Rev__________Comments_______________________
DMB32 YI Driver Patched Driver in
MRCSSE::PUBLIC:
LI Driver Patched Driver in
MRCSSE::PUBLIC:
SI Driver Patched Driver in
MRCSSE::PUBLIC:
DSB32 SLDRIVER
_________________1.1_________________________________________
3.1.2 Hardware:
1. Bug: XJA Rev C02
Intermittent self-test failures
EEPROMs corruption on power up
May fail self-test with CIXCD in backplane
Occasional fully recoverable JXDI parity errors
Cause:
May have XC ECLiPs parts with signal integrity problems
Some wrong delay lines
I/O Subsystem 11
No Write Protection for EEPROMs
CIXCD Diagnostic uCODE V0.37
EWCLD V2.1 (XJA Selftest Code)
DC7092B gate array:
Fix:
XJA REV C04
CIXCD Diagnostic uCODE V0.38
2. Bug: XJA Rev C03
Intermittent self-test failures
EEPROMs corruption on power up
May fail self-test with CIXCD in backplane
Occasional fully recoverable JXDI parity errors
Cause:
No Write Protection for EEPROMs
CIXCD Diagnostic uCODE V0.37
EWCLD V2.1 (XJA Selftest Code)
DC7092B gate array:
Fix:
XJA REV C04
CIXCD Diagnostic uCODE V0.38
3. Bug: XJA Rev C04
Occasional fully recoverable JXDI parity errors
Cause:
DC7092B gate array:
Fix: XJA REV C05
4. Bug: Can't load new Microcode in XMI Options
Cause: Bad cable from IORIC to XMI Backplane
12 I/O Subsystem
Fix: New cable - 17-02324-01 (REV C01)
For more detail see the file
MRCSSE::PUBLIC:CIXCD_MICROCODE.TXT
5. Bug: Slow DEMNA Performance
Cause:
The problem is caused by the DEMNA responding in an
unusual way to a bad packet on the ENET. It turns out
that the FT 3000 on the standby ENET port sends out test
packets. One of the test packet the FT 3000 sends out
has an incorrect number of bytes. The size of the packet
does not agree with the actual size of the packet. This
bad packett size for the FT3000 is being corrected in the
next version of VMS (V5.4-1). It is possible that other
(NON-Digital) devices on the ENET cause produce the same
type of packets.
Fix: DEMNA uCODE V6.04
The new uCODE is located MRCSSE::PUBLIC:EVGDBQ.BIN
6. Bug: XJA/JXDI/SCU Timing problem
I/O Subsystem 13
To identify the XJA/JXDI Timing problem, check these
scanlatches at the time of failure.
1. %SCU.CCU.CTLA.PRTERR_H<2> = 1
<<<<<<OR>>>>>>
2. %SCU.CCU.CTLA.2PRTRDY_H<1:0> = 0 or 1 and
%SCU.DA0.JDC0.RCV_CCU.TO_XJA_BUFA_FULL_TB_H = 0 and
%SCU.DA0.JDC0.RCV_CCU.TO_XJA_BUFB_FULL_TB_H = 0 and
%SCU.DA0.JDC0.RCV_CCU.IO_BUFA_BUSY_TB_H = 0 and
%SCU.DA0.JDC0.RCV_CCU.IO_BUFB_BUSY_TB_H = 0
===========================================================
or if XJA2 or XJA3 exists,
1. %SCU.CCU.CTLA.PRTERR_H<5> = 1
<<<<<<OR>>>>>>
2. %SCU.CCU.CTLA.5PRTRDY_H<1:0> = 0 or 1 and
%SCU.DA1.JDC0.RCV_CCU.TO_XJA_BUFA_FULL_TB_H = 0 and
%SCU.DA1.JDC0.RCV_CCU.TO_XJA_BUFB_FULL_TB_H = 0 and
%SCU.DA1.JDC0.RCV_CCU.IO_BUFA_BUSY_TB_H = 0 and
%SCU.DA1.JDC0.RCV_CCU.IO_BUFB_BUSY_TB_H = 0
Cause: Unexpectedly long data path signal between the XJA
and the SCU
Fix: Implemented in 3 Phases
Very Short Term - Do XJA Clock Cable Phase check
Short Term - Replace JXDI Cable with new cable
(17-01786-02) and XJA Clock cable (17-02454-01 REV C01).
Long Term - New MCU (Not Required for Model 210 or 4xx)
For more detail see the file
MRCSSE::PUBLIC:XJA_JXDI_CLK.CABLE
14 I/O Subsystem
3.1.3 uCODE:
1. Bug: Intermittent XJA Selftest Failures
Cause:
CIXCD Diagnostic uCODE V0.37
EWCLD V2.1 (XJA Selftest Code)
Fix:
CIXCD Diagnostic uCODE V0.38
EWCLD V2.3 (XJA Selftest Code) XJA REV C04 For more detail
see the file
MRCSSE::PUBLIC:CIXCD_MICROCODE.TXT
Update: CIXCD uCODE Notification
Please ensure all CIXCD modules are now using CIXCD.BIN
V1.04.
The Latest release can be copied from:
IOENG::XMVDSK:[CIXCD.DIAG]
Please refer to AUGGIE::XCD_FORUM for the latest revision
information.
3.1.4 Diagnostics:
1. Bug: EVCLB V1.5
Intermittent diagnostic failure doing Memory LOCKs
Cause: Diagnostic Bug
Fix: EVCLB V1.8
I/O Subsystem 15
2. Bug: TEST/XJA failures
Cause: Operator Error
Fix:
TEST/XJA requires a working CPU, a complete I/K must be
done before attempting to execute a TEST/XJA command.
3. Bug: TEST/JXDI failures - (Pattern set REV A & B)
SJA Parity error in Test 0
For more detail see file [SYSMAINT]JXDI_HELP.TXT
Cause: Console Software
Fix: Console Software FT10.4 or higher
4. Bug: TEST/JXDI failures - (Pattern set REV B)
Compare error in Test 61
Cause: Error in the Compare Data File for test 61
Fix: Console Software FT11.0 or higher
5. Bug: EVGAA V6.1
Failures if the Autosizer (EVSBA) was used to attach the
CIXCD.
Cause: Unknown
Fix: Manually attach CIXCD
6. Bug: EVGAA V6.1
Failures if the cluster size not set to 16
Cause: Unknown
Fix: Use cluster size of 16
16 I/O Subsystem
7. Bug: EVGAB V6.1
Failures if the cluster size not set to 16
Cause: Unknown
Fix: Use cluster size of 16
I/O Subsystem 17
CHAPTER 4
POWER SUBSYSTEM
4.1 POWER Subsystem:
4.1.1 Minimum Revisions:
o Hardware:
_____________________________________________________________
OPTION_________Rev______Comments_____________________________
H7214 B08
H7215 F06
H7380 H05
H7382 H04
H7386 C05
H7388 D08
H7389 E07 Model 210
F07 Model 4xx
T1060 D02 Field Test
POWER Subsystem 19
_____________________________________________________________
OPTION_________Rev______Comments_____________________________
H03 STEP FIX UPGRADE
54-17895-01 E02 Model 4xx
54-18672-01 E02 Model 4xx
54-18674-01 E03 Model 4xx
54-18676-01 E03 Model 4xx
54-18678-01 E02 Model 4xx
54-18758-01 C02
54-18792-01 F01 Model 210
54-18800-01 E02 Model 210
54-18802-01 E01 Model 210
54-19021-01 E01 Model 210
54-19028-01 F05 UPC
H05 H7390
J06 STEP FIX UPGRADE
54-19030-01 H02
54-19043-01 D04
54-19045-01 D01
20 POWER Subsystem
_____________________________________________________________
OPTION_________Rev______Comments_____________________________
54-19256-01 E02 Model 210
54-20237-01____B01______Model_4xx____________________________
o uCODE:
_____________________________________________________________
OPTION___Rev______Comments___________________________________
T1060 8B
H7388 84
H7389____84__________________________________________________
4.1.2 Hardware:
1. Bug: Shock Hazard
Cause: Missing AC Breaker Cover
The AC breaker in the IOA cabinet has exposed terminals
with AC voltage present on it
Fix: Cover is being EVALUATED and if possible will be
added to the product, for the short term I recommend
taping over the terminals with electrical tape.
2. Bug: DEC POWER BUS Problems
Cause: Bad Parts from Vendor
Fix: Check wiring and replace parts if necessary.
For details read file: MRCSSE::PUBLIC:DEC_PWR_BUS.TXT
POWER Subsystem 21
4.1.3 uCode:
1. Bug: No Known Problems
Cause:
Fix:
4.1.4 Software:
1. Bug: Show Environmental displays wrong AIR FLOW sensors
Cause: Display Utility
Fix: Future Console Code Update
Use ERF outputs and Power Subsystem Technical Manuals they
have the correct information.
2. Bug: ERF OCP Switch Exception decoded incorrectly
Cause: ERF
Fix: Future ERF Update
ERF Decode the SWITCH register incorrectly, basically the
switch position is the one not reported.
22 POWER Subsystem
CURRENT OUTPUT OUTPUT SHOULD BE
-------------- ----------------
OLD STATE OLD STATE
SW #1 - LOCAL DISABLED SW #1 - REMOTE DISABLED
SW #1 - LOCAL SW #2 - BOOT
SW #1 - REMOTE
SW #2 - RESTART/BOOT
SW #2 - RESTART/HALT
SW #2 - HALT
NEW STATE NEW STATE
SW #1 - LOCAL DISABLED SW #1 - REMOTE
SW #1 - LOCAL SW #2 - BOOT
SW #1 - REMOTE DISABLED
SW #2 - RESTART/BOOT
SW #2 - RESTART/HALT
SW #2 - HALT
3. Bug: Syndrome code 3091G.000.003 for PCS ELE entries
Cause: Old Version of EWKCF.BCM
Fix: MRCSSE::PUBLIC:EWKCF.BCM (REV 1.1(22))
Copy the latest BCM file from MRCSSE::PUBLIC:EWKCF.BCM
on our system. This file goes on the console disk in the
[SYSMAINT] directory.
4. Bug: Lost OCP Codes
Some Service personal have written command procedures to
constantly write the OCP display, and at least two separate
problems have been seen. One problem was caused when the
program was running as a batch job and the log file filled
the disk and the console could not be rebooted. The other was
a lost OCP code because the program running over wrote the
"REAL" OCP code after it was written by the PCS subsystem.
Cause: Operator Error
POWER Subsystem 23
Fix: Don't run such program
The running of such a program has no real useful purpose
and CSSE recommends that it not be done. If we continue to
see the number of problems grow we will have the ability
for the SPU user to write the OCP Display removed from the
system. If you really want to display a three character
add it to the end of [sysexe]power.cmd command file, don't
write a program to constantly scroll the display.
5. Bug: SDU shows NON-Existent power
SDU Displays 2 XMI card cages in the first IO cabinet and
a second IO cabinet on a model 210 even though they don't
exist. The second cabinet display also shows some BIAS
failures, which can be very confusing.
Cause: SDU
Fix: Future SDU Update
4.1.5 Documentation:
1. Bug: Model 400 OCP Codes not Documented
Cause: Documents were released for Model 210 only
Fix: Future Release of Documents
An advance of of the OCP codes is available in the PUBLIC
area on our system.
MRCSSE::PUBLIC:OCP_CODES.PS
MRCSSE::PUBLIC:OCP_CODES.TXT
2. Bug: Model 210 Troubleshooting Flows not Documented
Cause: Documents were released before Availability
24 POWER Subsystem
Fix: Future Release of Documents
An advance of of the 210 troubleshooting flows is
available in the PUBLIC area on our system.
MRCSSE::PUBLIC:210_PWR_FLOWS.PS
POWER Subsystem 25
CHAPTER 5
SPU SUBSYSTEM:
5.1 SPU BUG #6
ITEMS OF INTEREST WITH SPU HANDLING OF OCP
Description:
One definite bug and one "feature" has been found
with the way the SPU handles the OCP key switches.
Both of these items have been QAR'd by me into the
engineering QAR system (console QARs 90 and 91). The
feature listed below as "item 2" represents
potential security issues.
These two items are common to -all- versions of SPU
software available, Base Levels 11.0, 10.5 and
under. They specifically can be found on
installations using the MDS01 to RTY port set up.
Note that in all cases, the keyswitch on the MDS01
provides absolute security.
Fix:
For more information see; MRCSSE::NONAME:[PUBLIC]SPU_OCP.TXT
SPU Subsystem: 27
5.2 SPU BUG #5
DIAGNOSTICS UPDATE:
The detailed status report for the functional diagnostics can be
found in:
MRCSSE::NONAME:[PUBLIC]VAX9000_DIAGNOSTICS_STATUS__13-SEP-1990.TXT
5.3 SPU BUG #4
SPU CLI issues addition:
TEST/SCAN/ON_ERROR:ISOLATE has been changed. ISOLATE is now it's
own parameter:
TEST/SCAN/ISO/LOG/TRA/SCU will now provide isolation on error
instead of using the /ON_ERROR switch.
For more information see; MRCSSE::NONAME:[PUBLIC]BL104.NOTES
5.4 SPU BUG #3
We are still re-structuring the SPU portion of the VAX 9000
Buglist. Please reference the following for a summary of the SPU
Bugs known to date.
For more information see; MRCSSE::NONAME:[PUBLIC]BL105.NOTES
5.5 SPU BUG #2
5.5.1 Minimum Revisions:
o Hardware:
o uCode:
o Software: REV FT10.4
28 SPU Subsystem:
5.5.2 Software:
o Bug: The command files in the [TOOLS] area are not fully
tested and supported files. These files should be used with
caution.
o Cause:
o Fix: Release notes will include changes to these files as
they occur.
5.6 SPU BUG #1
5.6.1 Minimum Revisions:
o Hardware:
o uCode:
o Software: FT10.3
5.6.2 Software:
o Bug: On console version FT10.3 the command >>>test/jxdi:0
Will fail the first time it is typed
o Cause: Unknown
o Fix: Update SPU to BL11.0
SPU Subsystem: 29
CHAPTER 6
MEMORY SUBSYSTEM:
6.1 MEMORY Subsystem:
6.1.1 Hardware:
1. Bug 2: Memory Interleaving Bug
There is a design bug in the MICR MCA which can cause
problems when certain memory interleaving modes are used.
The nature of the bug is such that the following interleaving
modes CAN or CAN NOT be used.
If 2 MMUs are present:
4 way CAN BE USED
2 way between units CAN NOT BE USED
2 way within both units CAN NOT BE USED
1 way CAN NOT BE USED
If 1 MMU is present:
2 way within unit CAN BE USED
1 way CAN NOT BE USED
The algorithm which will now determine whether an
interleaving mode is permissible will be:
If either of the PA bits which determine UNIT and SEGMENT are
MEMORY Subsystem: 31
outside the range PA[15:6], then that interleaving mode is
not permitted.
Only "4way/2mmu" and "2 way within unit/1mmu" comply with
this.
Cause:
For more information, please refer to:
MRCSSE::NONAME:[PUBLIC]MEM_INTERLEAVE.TXT
Fix:
2. Bug 1: Errors with memory BIST with cache sweep disabled
The following memo describes the subject bug:
From: AQUA::EVANS
To: MRCSSE::TCOLLENTINE,DELAHUNT,MCCABE,DUSEK
CC:
Subj: Errors with memory BIST with cache sweep disabled
I think I understand why we are seeing problems with
the memory BIST and error sweeps disabled. When error
sweeps are disabled the EBOX will read 256K of memory
to force all blocks out of the cache. The JBOX thinks
the data is in the cache and is read only, as it
actually is. During BIST we must switch the memory
interleave to 1WAY so we can correlate the blocks in
memory which have failed with the bank (the algorithm
is a real bummer if we do not use 1way). The EBOX
reads have been done in 1WAY interleave and the TAGRM
will have addresses in them based on this interleave.
Now we switch the interleave back to 4WAY and will
get TAG address parity errors if we reference any of
the blocks which are marked valid and in the TAG
32 MEMORY Subsystem:
which do not map the same for 1WAY and 4WAY. Now, the
last 128K bytes read will be in the TAG. Locations
20200 - 40200. EWSAA is loaded starting at 10000 and
sure enough, I get SCU errors on address 20240, the
first block marked valid which does not ahve the same
address in 1WAY and 4WAY. VMB is loaded into 200 and
is very small. The SPU will never get errors loading
it, however, I would have to believe that either it
does some magic to clear the TAGRM (by some
writeback/read sequences) before it gets to the bad
locations or it will fail with a hung SCU also. I
have modified a copy of TEST_MEMORY to enable MBOX
sweeps during BIST and this has solved the problem. I
need to discuss this with the MBOX and SCU folks to
determine if this should be a permanent fix.
Steve, can you verify this analysis ? Am I correct in
my assumptions about the TAGRM and is there a
sequence of commands which could overwrite a location
before it is checked for parity such that VMB would
run ? VMB does a clear memory by writing to all of
it. I dont know how they do this but perhaps not all
CPU commands look up the TAG parity ?? Thanks,
Cause:
Fix:
MEMORY Subsystem: 33
6.1.2 uCode:
1. Bug: No Known Problems
Cause:
Fix:
6.1.3 Software:
1. Bug: No Known Problems
Cause:
Fix:
34 MEMORY Subsystem:
CHAPTER 7
INSTALLATION:
7.1 Installation BUG #2
Problem: No Read-Me-First label was found.
Solution: The VAX 9000 Model 200 Installation Guide, page 2-2
states:
"Remove the shipping/accessory list from the customer
services box and check the contents of all boxes
against the shipping list. THIS BOX IS IDENTIFIED BY
THE INTERNATIONAL SYMBOL-A BLUE CIRCLE CONTAINING THE
LETTER I."
7.2 Installation BUG #1
7.2.1 Minimum Document Revisions:
o Install Guide - August 1990
o Site Prep Guide - July 1990, First Edition
7.2.2 Tools and Tool Usage:
Subject: Uncalibrated Torque Tool (P/N: 29-28143-01.A01)
INSTALLATION: 35
PROBLEM:
We have just found indications that there is an uncalibrated
torque device in the VAX 9000 CONNECTOR TORQUE TOOLS KIT (P/N:
29-28143-01.A01).
KIT AFFECTED:
Three of three kits shipped to MRO were received with the Z-FLEX
& MEM/FLEX Torque Tool (P/N: 29-28143-01.A01) uncalibrated. This
tool is essential to the installation of the VAX 9000 Z-FLEX
Cables.
POSSIBLE IMPACT:
We are presently unsure as to the possible symptoms/problems
that could result, but the 20 in-lb value that the uncalibrated
tools are coming in at should establish adequate connector
contact. The addition 7 in-lbs provides long term vibration
resistance for the connection.
PREVENTIVE MAINTENANCE:
Once a correctly calibrated tool is available, all existing
VAX 9000 Installations should be re-visited and all Z-FLEX
connections be re-torqued. We DO NOT recommend separating the
connection, merely tighten the existing connection with the
calibrated tool. This should ensure a robust connection.
QUICK CHECK PROCEDURE:
The best way to determine if the tool you received is properly
calibrated is to look at the butt of the red handle. The number
27 should be stamped next to the "calibration at" label. If no
value is stamped, your tool is likely not calibrated (we have
found them at 20 in-lbs).
36 INSTALLATION:
RECOVERY PROCEDURES:
FASTEST METHOD: The quickest way to get this tool calibrated
involves directly contacting a local machine shop that
calibrates torque devices. It should only take a few minutes
to actually calibrate and stamp/mark the tool. The expense will
vary between calibration shops, but should not cost more than
$10-20 dollars (US).
TORQUE SETTING: 27 in-lbs or 31 cm-Kg
ALTERNATE METHOD: Fast ship (Ex. Federal Express etc) your
Z-Flex Torque tool to:
KAUFMAN COMPANY, INC.
110 Second Street
Cambridge, MA 02141
Attn: Mr. Norman Kaufman
Enclose with the tool a memo listing the address to return
calibrated tool to. Kaufman Co. will fast ship the corrected
tool to you.
Note: The current Z-Flex Torque Tool being shipped has a red
anodized aluminum handle. Some (not all) of the replacement
tools may have blue handles. Refer to the calibration stamp
for setting varification
COMMENT:
Luckily the non calibrated tool is not stored at values above
the 27 in-lbs, so no damage will occur to the connector.
A quality hold has been placed on all kits in inventory and
the vendor will correct this over the next week. Customer
Service Purchasing and Logistics are aware of this and are
taking the necessary steps to ensure correction and future
prevention of this problem.
INSTALLATION: 37
Z-Flex connector cleaning technique
When cleaning the connector on the Z-flex cable use caution
so that the cleaning sticks are not shredded during cleaning.
Use the flat portion of the cleaning stick to wipe across the
connector away from the cable. If the handle on the cleaning
stick bends, you are applying too much pressure.
Clock Cable connector tightening technique
Proper techinique must be used when tightening clock cable to
prevent loosening of cable. Use two hands to connect the clock
cables. Hold the cable with one hand (about three inches from
connector). Feed the cable straight into the jack and release
pressure on cable. Use 8 in-pound torque tool (PN 29-27973-01)
to tighten connectors. While torqueing hte clock connectors,
prevent the cable from twisting inside the housing b wiggling
the cable. Twisting could cause the SMA connector to loosen.
38 INSTALLATION:
CHAPTER 8
VMS SUBSYSTEM:
8.1 VMS Subsystem:
8.1.1 Minimum Revisions:
Version 5.4
8.1.2 Software:
1. Bug:
=======================================================
Note 609.6 FORTRAN RTL images problem on V5 6 of 6
QUARK::LIONEL
"Free advice is worth every cent" 21-SEP-1990
-< STARS article >-
-------------------------------------------------------
[This is a corrected version of an earlier posting.]
Attached is a STARS article that will soon be made
available to customers. It describes a problem with
linking FORTRAN programs on newly installed "from
scratch" VMS V5.4 systems. Please distribute this
information to any affected users and customers.
VMS Subsystem: 39
This problem will be "fixed" in the next maintenance
update of VMS, but the solution given in the article
can be applied immediately without interfering with
the later VMS fix.
Steve
*****************************************************
TITLE: LINK-I-DATMISMCH on FORTRAN RTL After
Installing VMS V5.4
COMPONENT: Linker Utilit OP/SYS: VMS, Version 5.4
LAST TECHNICAL REVIEW: 20-SEP-1990
SOURCE: Customer Support Center/Colorado Springs USA
\ Information in this article was extracted from the
\ VMS_FIELD_TESTS conference, topic 609, entered by
\ Steve Lionel.
SYMPTOM:
After doing an initial installation of VMS V5.4, the
FORRTL and FORRTL2 shareable images are not
consistent with what was inserted into the
IMAGELIB.OLB on the kit.
Running the Installation Verification Procedure (IVP)
after installing FORTRAN or VAX FORTRAN-HPO will
produce the following messages:
%LINK-I-DATMISMCH, creation date of 16-JUL-1990 09:47 in
shareable image SYS$COMMON:[SYSLIB]FORRTL.EXE;1
differs from date of 19-JUN-1990 04:43 in shareable
image library SYS$COMMON:[SYSLIB]IMAGELIB.OLB;1
%LINK-I-DATMISMCH, creation date of 16-JUL-1990 09:48 in
shareable image SYS$COMMON:[SYSLIB]FORRTL2.EXE;1
differs from date of 19-JUN-1990 04:44 in shareable
image library SYS$COMMON:[SYSLIB]IMAGELIB.OLB;1
40 VMS Subsystem:
Linking any FORTRAN program will produce these
messages. Programs written in other languages may
also include references to the FORTRAN RTL, and
linking those programs will produce the messages as
well.
ANALYSIS:
This behavior only occurs after an initial
installation of VMS V5.4. It does not occur when
upgrading to VMS V5.4.
These are informational diagnostic messages, and does
not effect the image being linked.
WORKAROUND:
Replace FORRTL.EXE and FORRTL2.EXE in the
IMAGELIB.OLB with the command:
$ LIBRARY/SHARE/REPLACE SYS$LIBRARY:IMAGELIB SYS$LIBRARY:FORRTL,FORRTL2
NOTE:
If another process has the library open (for example,
during a link operation), you may see errors
indicating that the library file is in use. Wait
until this other process is through linking, and
retry the replace operation.
DIGITAL RESPONSE:
This issue has been reported to VMS Engineering.
\\ LINK VER_5.4_VMS
\\ FT
VMS Subsystem: 41
|
| 78.86 | Balance slot usage | KERNEL::WRIGHTON | odd numbered release = bug insert | Thu Nov 29 1990 16:41 | 268 |
|
*** Digital Confidential ***
BALANCE SLOT LIMIT ON LARGE VAX SYSTEMS
Hank Jakiela
VAXcluster Systems Engineering
21 November 1990
SUMMARY
1. There is a limit on the number of processes that can be resident in
memory in one VAX CPU. This particular limit has nothing to do
with the amount of physical memory. Adding more physical memory
would not help. The limiting factor is the size of the S0 virtual
address space and the way that it is currently allocated.
2. When this limit is exceeded, processes must be swapped out.
Excessive swapping may seriously degrade the overall performance of
the system.
3. This limitation applies primarily to large VAX systems, especially
the VAX 9000. Larger VAX 6000-500 systems may also be affected for
some types of applications. The impact on any future VAX machines,
with more CPU power and memory greater than 512 MB, would be
especially severe.
4. This is not a cluster-specific problem. The limit applies to
individual VAX CPU's and affects clustered and non-clustered CPU's
in the same way. A cluster of smaller VAXes would be less affected
by this limit than a single VAX of the same total VUPS.
5. The types of applications most likely to be affected are those that
have a large number of processes resident in memory, either because
of a large number of users (e.g. ALL-IN-1) or because of a large
number of processes per user (e.g. DECwindows terminals).
6. Today, we know that this limitation alone makes the VAX 9000
clearly unsuitable for at least one application at a large customer
site. It is likely that a number of other VAX 9000 configurations
will also be affected.
PROBLEM DESCRIPTION
There is a limit on the number of processes that can be simultaneously
resident in main memory in one VAX (either uniprocessor or SMP). If
this limit is exceeded, some processes must be swapped out. This may
result in excessive swapping, with resulting poor performance.
*** Digital Confidential *** Page 2
Balance Slot Limit on Large VAX Systems 21 November 1990
Actually, there are two such limits. One has to do with the amount of
physical memory in the system. This limit is well known and we'll say
no more about it here.
The other limit is more surprising because it is not related to
physical memory. Adding more physical memory will not raise this
limit. In large systems with many small processes, this second limit
may be reached even though there is plenty of physical memory
available.
The limiting resource is the size of the S0 virtual address space.
(Again, this has nothing to do with the amount of physical memory.) S0
space comprises one quarter of the total range of of 32-bit virtual
addresses, or about 1GB of addresses. S0 space contains the VMS
executive, paged and non-paged pool and the process headers for all
memory-resident processes. The process headers include the page tables
and working set lists for the memory-resident processes.
In some circumstances, the number of virtual addresses needed for
everything mapped into S0 space exceeds the 1GB range of available
addresses. In these cases, most of the addresses are allocated to the
process page tables and working set lists. In order to keep things
simple in the following explanation, we'll ignore everything in S0
space except the process page tables and working set lists. Just
remember that the pieces we ignore make the problem a little more
serious than it appears here.
The number of S0 virtual addresses allocated for the page tables in
each process header is determined by the SYSGEN parameter,
VIRTUALPAGECNT. VIRTUALPAGECNT is the largest number of virtual pages
that any process can use. Similarly, the SYSGEN parameter, WSMAX,
determines the number of S0 virtual addresses allocated for the working
set list of each process. WSMAX is the largest working set size that
any process can get. These parameters can be set only at boot time.
Every process is allocated the same number of S0 addresses for its page
table and working set list. The allocation has to be large enough to
accommodate the largest range of virtual addresses and the largest
working set that will be needed by any process until the next reboot of
VMS. If one process requires a very large virtual address space, it
forces a large allocation of addresses for every process header in S0
space.
The page table requires four bytes for each page of virtual address
space that can be used by the process, and the working set list
requires four bytes for each page in the working set. So, the number
of S0 virtual addresses allocated for the page table and working set
list for each memory-resident process is:
(VIRTUALPAGECNT + WSMAX) * 4
As an example, on a large system, VIRTUALPAGECNT could be 400K and
WSMAX could be 100K. This means that (400K + 100K) * 4 = 2MB of S0
addresses would need to be allocated per process.
*** Digital Confidential *** Page 3
Balance Slot Limit on Large VAX Systems 21 November 1990
Each process resident in memory must have a process header allocated in
S0 space. If the number of processes exceeds the number of process
headers, some processes must be swapped out (even if there is room for
them in physical memory). The SYSGEN parameter, BALSETCNT, determines
the number of process headers allocated at boot time, and, therefore,
limits the number of processes that can be resident in memory.
All of the process headers need to fit in S0 space (1 GB of virtual
addresses). This yields the following inequality.
(VIRTUALPAGECNT + WSMAX) * 4 * BALSETCNT < 1GB
For example, if VIRTUALPAGECNT = 400K and WSMAX = 100K, then BALSETCNT
cannot exceed about 500. Actually, this simple formula just gives an
upper bound. All of the the things we have ignored in this calculation
make the real number closer to 400.
Ordinarily, the BALSETCNT parameter is set by AUTOGEN. In VMS 5.4 and
prior versions, AUTOGEN uses a fairly conservative formula to calculate
BALSETCNT. As a result, the value of BALSETCNT set by AUTOGEN in VMS
5.4 is smaller than it really needs to be. (In VMS 5.4-1, the AUTOGEN
formula has been changed and the calculated value of BALSETCNT is
closer to the actual limit.)
REAL-LIFE CUSTOMER EXAMPLE
One very well known large customer does, in fact, need to set
VIRTUALPAGECNT to 400K and WSMAX to 100K. This limits BALSETCNT to
somewhere in the neighborhood of 400 slots.
This customer runs a large cluster with 14 CPU's (8800's and 6440's).
The customer considered whether it would be practical to replace these
14 CPU's with four VAX 9000's. It turned out to be unworkable because
of the balance slot limitation.
During prime time, this cluster supports about 1,500 simultaneous
users. These users run ALL-IN-1 and other products that make frequent
use of subprocesses. The average user has about 1.5 processes, so the
cluster has about 1.5 * 1,500 = 2,250 user processes. (Fortunately,
they don't use DECwindows terminals!) In addition, there are about 700
DQS print symbionts in this cluster and about 60 other system processes
per node.
During one snapshot, the total number of balance slots used across the
14 CPU's was 3,790. If this workload were run on four large machines,
some system processes which are now replicated on all 14 nodes could be
eliminated, but the cluster-wide total would still be in the
neighborhood of 3,000 slots, or 750 per node. This is many more than
the number of balance slots available per node, and we would expect
significant swapping and serious performance degradation. Replacing
these 14 VAXes with four VAX 9000's would not work for this customer.
*** Digital Confidential *** Page 4
Balance Slot Limit on Large VAX Systems 21 November 1990
This cluster is very large, but the workload is otherwise very standard
technical time sharing. The same argument would apply if the customer
had a smaller cluster and wanted to replace five 6-VUP VAXes with one
VAX 9000.
This same issue can also apply to large VAX 6000's. The total VUPS
provided by the existing 14 CPU's could also be provided by four or
five large VAX 6000-500 SMP machines. However, the number of balance
slots available on a cluster of four or five VAXes would not be enough
to support this workload without significant swapping.
IMPACT ON VAX 9000 CONFIGURATIONS.
For some workloads that have a large number of processes, a very large
VAX may not perform well, even if it has ample CPU power, physical
memory and I/O bandwidth. The limit on the number of memory-resident
processes may cause excessive swapping. Based on our current
understanding and experience, we can identify several "risk factors"
which suggest whether this problem is likely to be seen on a particular
system.
o Extensive use of ALL-IN-1.
ALL-IN-1 users typically use relatively little CPU power, and a
large number of simultaneous users can be supported on one large
machine with a large physical memory. ALL-IN-1 makes some use of
subprocesses, so the total number of user processes would typically
be about 1.5-2.0 times the number of users. In benchmark tests, a
9210 could support over 400 simultaneous ALL-IN-1 users. However,
in many real-life systems, there will be at least one application
that requires a very large VIRTUALPAGECNT or WSMAX, or both. If
there is such an application (e.g. crash-dump analysis), BALSETCNT
will be limited to a few hundred, swapping will be significant, and
interactive response will be poor. VAX 9000 machines beyond the
uniprocessor would make inefficient ALL-IN-1 engines.
o Extensive use of DECwindows terminals.
DECwindows terminal users often have several windows open, each one
connected to a separate process on the host. A group of DECwindows
terminal users would likely create several times as many processes
as the same number of VT terminal users. As a result, the number
of DECwindows users that could be supported on one VAX could be
limited by the number of balance slots rather than CPU power or
memory. The VAX 9000, especially SMP models, might make an
inefficient DECwindows server.
o Consolidation of several small VAXes onto one VAX 9000.
Some of the sales of VAX 9000's are going to sites planning to
consolidate the workload from several smaller VAXes onto one VAX
9000. Since the S0 limit applies per VAX, the number of balance
slots available on the VAX 9000 will be smaller aggregate number
available on the set of small VAXes. In other words, a cluster of
*** Digital Confidential *** Page 5
Balance Slot Limit on Large VAX Systems 21 November 1990
smaller machines could hold more processes in memory than a single
VAX 9000. In some cases, consolidation on a VAX 9000 could result
in an unexpectedly high level of swapping and poor performance.
o Crash dump analysis.
It is reasonable to expect that a VAX should be able to analyze its
own crash dumps (without requiring a set of SYSGEN parameters
different from the normal operating mode). In order to properly
analyze a crash dump, the crash dump analyzer requires a virtual
address space larger than the system's physical memory.
For a VAX with 512 MB of memory, this means that VIRTUALPAGECNT
must be larger than 1,024K. Allocating process headers of this
size would limit the number of balance slots to roughly 200. After
the number of system processes is subtracted, there would be very
few balance slots for user processes.
|
| 78.87 | 9000-420 Qualification Status | KERNEL::WRIGHTON | odd numbered release = bug insert | Thu Nov 29 1990 17:49 | 100 |
|
+---------------------------+ TM
| | | | | | | |
| d | i | g | i | t | a | l | INTEROFFICE MEMORANDUM
| | | | | | | |
+---------------------------+
TO: VAX 9000 Core Team
DATE: 11/27/90
FROM: JOSEPH DZIEDZIC
DEPT: VMS SYSTEMS & SERVERS
EXT: 381-2438
LOC: ZKO3-4/W23
NODE: STAR::DZIEDZIC
SUBJECT: VAX 9000-420 VMS Qualification Status
1 INTRODUCTION
During the past two months we have been testing a VAX 9000-420 system in
the VMS Integration Cluster. Our testing has included some canned test
procedures (such as SITP) which included tests of the vector unit, and
also the normal day-to-day stresses and strains of existence in the
I-Cluster (cluster transitions, satellite serving, shadow set
transitions, builds, etc.). We are currently aware of no issues which
would preclude VMS support for the VAX 9000-420 under the following
conditions:
1. VMS release V5.4-1 is required for VAX 9000-420 support
2. CVG successfully completes their test plan for VAX 9000-420
qualification
3. (for vector support) Successful completion of the VMS vector test
plan and resolution of any problems/issues identified
These conditions will be detailed below.
1.1 VMS V5.4-1 Release
VMS version V5.4-1 is scheduled for SSB submission around the third week
of November. Any change in that schedule will impact VMS' ability to
support the VAX 9000-420.
1.2 CVG Testing
CVG is currently testing a VAX 9000-420 in a cluster. VMS would like
CVG's assurance that they have seen no cluster problems which they feel
are specifically related to the VAX 9000-420.
Page 2
1.3 Vector Processing Issue
Chris Mega's SITP testing on AS5 has revealed cases of data compare
mismatches. SITP testing in MRO has not reproduced this problem. VMS
will be running additional tests with the latest SJA firmware to
determine whether the problem recurs. This problem must be understood
before VMS will commit to VAX 9000-420 vector support.
2 OBSERVATIONS FROM TESTING
2.1 VMS Problems Found In 9000-420 Testing
There were very few SMP-related problems in VMS discovered during
multi-processor configuration testing; this is due to prior availability
of such configurations in MRO which allowed the more obvious problems to
be found and corrected before "real" SMP qualification began. The two
problems reported by Mike Evans of the console group were related with
processing of STOP/CPU/FOREVER and system-initiated automatic reboots.
The minor fixes for these problems are in VMS version V5.4-1.
2.2 Hardware Problems Found In 9000-420 Testing At ZKO
We did not find any "new" hardware problems in our testing. During the
first few weeks of testing we did trip over several known hardware
problems; firmware changes were supplied by MRO for these problems.
The reliability of AS5 during the first month of testing was very poor.
This was eventually traced to a defective FAD MCU. A replacement was
procured and installed, but did not correct the problems. It was
discovered the replacement MCU was of the wrong physical revision; a
correct replacement was installed, and AS5's reliability improved
dramatically. We have seen uptimes (excluding scheduled system
shutdowns) of close to a week between hardware incidents.
|
| 78.88 | SPU S/W status | KERNEL::WRIGHTON | odd numbered release = bug insert | Thu Nov 29 1990 17:49 | 90 |
|
Here's a brief status on SPU software currently in use:
"Current" implies what is latest. I've heard of sites still running 10.3 and
10.5 software. All sites should be at 11.0 by now at a minimum.
current 9210s: BL 11.0 minimum (an 11.1 upgrade was
made available but not widely used for
various reasons. 11.0 is a must at this
point, however, for all 9210s. 11.1's
biggest plus was the ucode which was
distributed over the net seperately).
current 94xx : "FT11.1" in sysboot, BL 11.2 in
[SYSEXE]MEDIA_REV.DAT (released via MFG only,
not available anywhere else)
coming:
B5 upgrade (CTU):
There will be a patch tape sent with every B5
upgrade kit that will include new software to
support the new CTU, to update ucode, jcode,
lword, scepter pattern files (SPDFs and SPDIs),
and CDBs.
You MUST be at least using 11.0 to install this software.
Two savesets will be included on the tape, one for
the new B5 support, one to regress to B4 if needed.
Instructions will be included in the kit.
The B5 patch tape and instructions will be shipped
to BTO for release with the kits by next tuesday
or wednesday - I'm not sure when the whole kit
starts getting shipped to the field.
BL12: BTO has of this writing shipped at least two
systems with the new BL12 (not sure, but I think
these say "FT12" in the media_rev.dat file).
The RELEASE NOTES FOR BL 12 can be found in MRCSSE::PUBLIC:
BL12_RELEASE_NOTES.PS (yes: postscript).
BL 12 will be released over the net and from BTO and GAO.
There will also be tapes job-shopped out of a division of
SSB so that we'll have kits sent pre-made to ESSB and
Canada (hopefully getting around the hassles we had
getting BL 11 out to the field from SSB - ie, avoiding
long turn-around cycles).
The Net-release savesets and instructions for BL12
should be ready by early next week if not by the end
of this week. We're reviewing the instructions for
tape creation and installation now, and as soon as we
verify the instructions, I'll send a notice of it's
availability.
Ok, a bound to be asked Question:
Why release BL 12 and B5 patch tapes at the same time? Why not
just release BL 12 to all the B5 upgrade sites?
Answer:
We're doing this as a safety net more than anything else.
The BL 12 kits will support B4 and B5 systems, but to make
absolutely sure we got the B5 CDBs to you with the hardware
we thought it best to use a seperate tape to patch BL 11 systems
with that actually shipped with the hardware.
Since we weren't sure when B5 support vs the BL 12 software
would be available, this seemed to make sense at the time.
(I think it still makes sense - maybe overkill - but you'll
have the right software at the right time).
The B5 patch tape should set MEDIA_REV.DAT to either 11.4 or 11.5 depending on
if you went up to B5 or dropped back to B4 afterwards.
The BL 12 distribution kits should set MEDIA_REV.DAT to "12" - sysboot will
show the same thing - not "FT12".
It hasn't been determined what minor revs will be called yet depending on B4
or B5 support from the BL 12 kit. I'll send out more details when I announce
availability of the network release kit.
That's it for now. You'll hear more by next week.
Butch
|
| 78.90 | | KERNEL::WRIGHTON | odd numbered release = bug insert | Tue Dec 04 1990 07:10 | 147 |
|
Subject: BLITZ for the VAX 9000 ECO Upgrade for MCUs
The VAX 9000 Program is preparing to distribute the VAX 9000 Upgrade
Kits to the Field. In the initial MCU upgrade shipments, you will
find the attached procedures detailing the use of a LPS1 lubrication
kit. This kit will also be included with the initial MCU upgrade
package.
We are providing this LPS1 Kit in an effort to eliminate any
possibility of MCU screw failure during the removal of an MCU during
the upgrade. We have experienced a field failure (thread stripout)
which required the complete replacement of a planar assembly. We
suspect that a small percentage of the original stainless steel
screws used to fasten an MCU to the planar may gall and possibly
strip. The odds of this happening are slim, but the result are bad
with regards to Customer satisfaction and expense to Digital.
All new production VAX 9000 systems will use the new zinc plated MCU
screws so this problem will cease to exist. CSSE will be requesting
that all future MCU FRUs will come with 4 of the new plated screws.
The upgrade kits will come with these screws. Do not re-use the
stainless steel screws in this upgrade.
This is a one time application. Lubricate all of the exposed screw
tips from the back of the UNI CPU planar. This will provide full
protection for the CPU MCUs. We do not have direct access to a DUAL
CPU or SCU MCU screws like we have with the UNI configuration. Do
not perform any disassembly to access the rear of these planars
mentioned above. The risk is small enough for these to be left
alone.
This is a redundant precaution.
[1m
NOTE to Field Engineer:
[0m
The attached procedure has been added to the normal MCU removal and
replacement steps described in the VAX 9000 Maintenance Guide.
The customer systems requiring the material upgrades you have
received have had an occurrence where a stainless MCU screw stripped
in a planar casting and required complete replacement of planar
assembly. In an effort to eliminate even the most remote chance of
this happening to you, we have provided the enclosed lubrication kit
and instructions for use along with new zinc plated screws.
Once you have applied lubricant to all the existing CPU screws, you
need not perform this task again.
Sheet 1 of 2
ERRATA
CSSE MCU REMOVAL & INSTALLATION - B5 FIELD UPGRADE
----------------------------------------------------------------------------
SCREW REMOVAL PROCEDURE USING LPS1 LUBRICANT
----------------------------------------------------------------------------
MATERIALS:
Each MCU upgrade kit shipped to the Field should contain the following:
(a) 5 screws, 4 for the MCU and 1 spare. The MCU screw will be one of
the following types:
10-32 2A Zinc Chromate Plated screw.
(b) 1 pair of disposable cleanroom gloves.
(OAK, pink anti-static, powder-free, #96-333)
(c) 1 can (2 oz.) of LPS1 non-silicon based lubrication.
(d) 1 Syringe for LPS1 application.
(B-D 5cc syringe, Reorder No. 5603)
(e) 2 Applicator tip(s) to be inserted (screw attached) to end of syringe.
(#995518 Loctite Teflon Needle Nose)
(f) 3 Cleanroom (non-linting) wipes (in zip-lock bag).
PRECAUTIONS:
It is essential that this operation be executed with EXTREME CARE, adhering
rigidly to this procedure so as to minimize the risk of dispersion of
contamination within the system.
- All application of LPS1 will be limited to lubricating the exposed
threads of MCU screws from the rear of CPU Planars.
DO NOT apply lubricant to the new screws.
- Disposable Cleanroom gloves must be used during this Lubrication
process.
DO NOT handle any other planar parts/subassemblies EXCEPT
the MCU Screws when using the disposable gloves as this will
aid in lubricant particulate dispersion.
- The LPS1 Aerosol Container must NEVER be used to apply Lubricant
to the Keenserts or MCU Screws imbedded in the casting as overspray
will occur.
Lubrication can only be applied to the specified areas using
the syringe WITH applicator.
- Should over-spill occur, remove any excess lubricant with a lint-free
wipe provided.
Sheet 2 of 2
ERRATA
CSSE MCU REMOVAL & INSTALLATION - B5 FIELD UPGRADE
----------------------------------------------------------------------------
SCREW REMOVAL PROCEDURE USING LPS1 LUBRICANT
----------------------------------------------------------------------------
APPLICATION OF LPS1 LUBRICATION TO THE MCU SCREWS:
- PRIOR TO REMOVAL of the 4 MCU SCREWS, using the syringe, with the
cleanroom wipe present at the application point, APPLY:
(a) 2 drops of lubrication to the MCU screw shaft/threads that
protrude from the back of the casting and
(b) 1-2 drops of lubrication directly at the point where the screw
protrudes from the casting (solid body insert).
- Wait for approx 5-10 minutes to allow the lubricant to wick its
way along the threads of the screw and between the mating surfaces
of the MCU screw and the solid body insert in the casting.
- As per the MCU Installation/Removal Spec extract each of the MCU
screws from the Planar.
- Dispose of the 4 removed screws.
- Open the bag containing the 5 new & unused zinc chromate screws.
- Install the Screws, adhering to the MCU Installation/Removal Procedure.
|
| 78.91 | H7214 bad Hybrids | KERNEL::WRIGHTON | odd numbered release = bug insert | Tue Dec 04 1990 07:13 | 129 |
|
PART NUMBER: H7214-A, 20-22943-01
REASON FOR ACTION: FSL MATERIAL UNFIT-FOR-USE
WHERE USED (OPTION): VAX 6000/9000
LOG NUMBER: 90023
SEVERITY: CONDITIONAL, AUDIT AND PURGE.
ACTION EXTENT : W/W - N
: USA - Y
: EUR - N
: GIA - Y
: LOC - Y
ABSTRACT:
DETAILED ANALYSIS HAS DETERMINED THAT THE USE OF UN-COATED CONTROL HYBIRD
MODULES (20-22943-01) IN H7214-A POWER SUPPLIES CAUSES CUSTOMER DOWN
FAILURES.
PROBLEM STATEMENT:
CSSE AND SASE HAVE DETERMINED THAT THE USE OF UN-COATED CONTROL HYBIRD
MODULES (20-22943-01) INTERNAL TO H7214-A POWER SUPPLIES CAUSE CUSTOMER
DOWN FAILURES ON THE H7214-A DUE TO SILVER MIGRATION.
CORRECTIVE ACTIONS TO BE TAKEN
PLEASE AUDIT and PURGE ALL NON-COMPLIANT FSL MATERIAL as follows.
AUDIT PROCEDURE:
ALL STOCKING LOCATIONS SHOULD BE 100% AUDITED; SEGREGATING FIT-FOR-USE
HYBRID/H7214-A PRODUCT FROM SUSPECT PRODUCT.
VISUAL MECHANICAL INSPECTION CRITERIA FOR BOTH THE H7214-A & 20-22943-01.
------------------------------------------------------------------------
H7214-A POWER SUPPLIES SHOULD BE REMOVED FROM STOCK AND RETURNED
TO SR. 126 IF THE SERIAL NUMBERS FALL WITHIN THE FOLLOWING
RUN:
AUGUST OF 1989 (SN. ME930XXXXX) THROUGH APRIL OF 1990 (SN. ME017XXXXX)
-------
THE ABOVE SERIAL NUMBER IDENTIFICATION BREAKDOWN:
ME = NEW BUILD ... CHIHUAHUA, MEXICO
930 = WEEK 30 OF 1989
017 = WEEK 17 OF 1990
***************************************************************************
* - EXCEPTION EXPLANATION - *
* *
* ACCORDING TO CSSE; AT THE PRESENT TIME UN-COATED HYBRIDS HOUSED *
* IN THE H7214-A POWER SUPPLIES STAMPED FROM AGO AND KLO *
* SHOULD BE ASSUMED GOOD, NON-CONTAMINATED PRODUCT *
* AND PUT BACK IN STOCK. *
***************************************************************************
==========================================================================
THE HYBRID CONTROL MODULE, 20-22943-01 SHOULD BE 100% AUDITED
TO DETERMINE WHETHER THE MODULES HAVE PHENOLIC RESIN COATING .
AUDIT/INSPECTION PROCESS:
------------------------
* A FIT-FOR-USE 20-22943-01 HYBRID MODULE WILL BE COATED
WITH A VISIBLE BROWN/TAN OR YELLOW PHENOLIC RESIN.
* ALL 20-22943-01 MODULES WITHOUT THIS BROWN/TAN OR YELLOW
RESIN SHOULD BE PURGED AND RETURNED TO SR. 126.
--------------------------------------------------------------------------
DISPOSITION OF NON-COMPLIANT MATERIAL:
BRANCHES/DLO'S:
--------------
RETURN ALL SUSPECTED BAD H7214-A'S AND 20-22943-01
HYBRID MODULES TO SR. 126.
RETURN ALL GOOD PRODUCT TO STOCK.
IN THE CIRCUMSTANCE THAT A STOCKING LOCATION IS DEPLETED OF INVENTORY
OF H7214-A/20-22943-01 AS A RESULT OF THE AUDIT; .... ORDERS SHOULD BE
PLACED AS P1's TO MANUFACTURING.
MANUFACTURING WILL ISSUE NEW BUILD POWER SUPPLIES & HYBIRD MODULES
UPON P1 REQUEST.
THESE DISPOSITION INSTRUCTIONS WILL BE UPDATED WHEN CSSE RELEASES
THE FCO WHICH ADDRESSES FINAL RESOLUTION.
IF THERE ARE ANY SPECIFIC QUESTIONS REFERENCING MATERIAL LOGISTICS
PLEASE CALL WILLIE EWING (PROD. MGR) DTN: 275-2286.
IF THERE ARE ANY TECHNICAL QUESTIONS/CONCERNS REFERENCING FCO/ECO
RELEASE/DETAIL PLEASE CALL PETE WISHNEUSKY OR RICK GROGAN (CSSE),
DTN: 247-2559.
SHORT TERM NEEDS:
WHERE MATERIAL SHORTAGE IS AN ISSUE .... P1 THE H7214-A/20-22943-01
AS NEEDED FROM MANUFACTURING.
LONG TERM NEEDS:
ISSUE AND IMPLEMENTATION OF FCO BY CSSE.
DURATION OF ACTION:
THIS PRODUCT ACTION WILL BE EFFECTIVE FROM 11-27-90 THROUGH 12-21-90.
REQUESTORS SUGGESTED RESPONSIBILITIES:
* PETE WISHNEUSKY/RICK GROGAN,(CSSE) 247-2559 RESPONSIBLE FOR FCO.
* WILLIE EWING (LBU PROD. MGR.) RESPONSIBLE FOR MATERIAL LOGISTICS
AND OVERALL DISPOSITION PLAN.
* DAVE CONTANT (LBU QUALITY) RESPONSIBLE FOR THE OVERALL PRODUCT
ACTION DOCUMENT.
|
| 78.92 | CONFIG.DAT problems | KERNEL::WRIGHTON | odd numbered release = bug insert | Tue Dec 04 1990 09:42 | 41 |
|
Subject: CONFIG.DAT Bugs Found In BL10, BL11 SPU Releases
We requested (and received) several "bad" CONFIG.DAT files from
the field and had engineering look at them. These files were
called "bad" because the SPU would hang during a SENSE command,
and upon renaming the CONFIG.DAT file to something else, SENSE
would then complete.
In looking at the CONFIG.DAT files that we got back, two distinct
bugs were found in SPU code that accessed this file. These bugs
had been identifified in a recent push to clean up CONFIG.DAT
handling, and the fixes are in Base Level 12 of the SPU (to be
generally released later this week [already released on new ships
from BTO starting last week]).
1) The first bug allows ill-formatted entries to be added to the
config.dat file for certain types of SPU adapter changes. This
does not affect the errorlog's configuration-change entries.
2) The second bug is encountered when the funny entry is read
from the config.dat file and not detected as being invalid, which
leads to the hang.
Both of these problems are already fixed in the BL12 code. If the
BL12 code encounters a bad entry in an existing history file it
reports the failure without hanging. However, the bad config.dat
file will have to be deleted for SENSE to be work correctly. The
BL12 code will no longer generate these ill-formed CONFIG.DAT
entries.
In BL 10 and 11 SPU's avoiding the SET SERIAL command for SPU
devices (SCM, AIO, AIE) may keep this error from happening. In
any event, these issues are fixed in BL12.*.
Butch
|
| 78.93 | error in 9210 Install Guide (blocking diode) | KERNEL::WRIGHTON | odd numbered release = bug insert | Wed Dec 05 1990 07:12 | 9 |
|
There is an error in the VAX 9000 Model 210 Installation Guide, in
section 4.3.8 (Blocking Diode cable). The figure (4-20) shows the cable
being attached to the minus (-) lead of the blocking diode. This is
incorrect and it should be connected to the positive (+) lead of the
blocking diode. The cable is currently marked "BLOCKING DIODE (-)", this
will be changed in future systems to "BLOCKING DIODE (+)".
|
| 78.94 | correction to EWKCK.BCM memo | KERNEL::WRIGHTON | odd numbered release = bug insert | Wed Dec 05 1990 14:32 | 151 |
| -----------------------------
| | | | | | | |
| d | i | g | i | t | a | l | I N T E R O F F I C E M E M O
| | | | | | | |
-----------------------------
TO: 9K_TECH.DIS DATE: December 5,1990
FROM: Tom Krehel
DEPT: Corporate Field Support
CC: DTN: 297-4508
ENET: HPSMEG::Krehel
LOC/MS: MRO2-3/E5
SUBJECT: Correction to EWKCK memo (memo follow this correction)
Mark Licata has brought to my attention the fact that MEDIA_REV.DAT did
not say 11.3 on the machine at BP. BP was the first machine that I saw
that tripped across the bogus SCU therories that indict all SCU MCUs due
to FREDDIE Flip Flops being set to a one.
My last mail on this topic said you could look in MEDIA_REV.DAT to
determine if you needed the new BCM file. Well, it appears that this
is not a foolproof approach.
Perhaps the best approach is to look in SITEINIT.CMD. If you have a line
in SITEINIT.CMD that deposits a "0" into %SCU.CCU.CTLA.DISFATERR_H, (see
example below) then you have a machine that needs the new BCM file which
can still be copied from the PUBLIC area on MRCSSE.
From SITEINIT.CMD on our machine:
! Enable SCU fatal errors
D/SCU CCU.CTLA.DISFATERR_H 0
I have also been told that the filename I chose causes some problems in
transfering the file....it didn't like the "-" in the filename, but "_"
works okay. I only include to REVn-n-n to discriminate between others I
have in my directory. Call it whatever you like when you transfer it.
The bottom line is; it must end up as [SYSMAINT]EWKCK.BCM.
The original memo follows
-----------------------------
| | | | | | | |
| d | i | g | i | t | a | l | I N T E R O F F I C E M E M O
| | | | | | | |
-----------------------------
TO: 9K_TECH DATE: November 27,1990
FROM: Tom Krehel
DEPT: Corporate Field Support
CC: DTN: 297-4508
ENET: HPSMEG::Krehel
LOC/MS: MRO2-3/E5
SUBJECT: New SCU BCM file
If you have a relatively new machine that is running SPU BL11.3 (type
[SYSEXE]MEDIA_REV.DAT) you need a new BCM file:
MRCSSE::NONAME:[PUBLIC]EWKCK_REV1-4-6.BCM
This file must replace the old EWKCK.BCM which now resides in the
[SYSMAINT] area of BL11.3 console disks. Just delete the one that is
there now and replace it with the one above.
When you are done, this new file must be in [SYSMAINT] and must have the
filename; EWKCK.BCM.
For reasons that I am at a loss to explain, SCU error reporting has been
turned on in BL11.3 which is apparently shipping from Burlington (and
probably Galway) right now.
For other reasons that I am just beginning to understand, the BCM file
that deals with SCU SCAN Error Log Entries has a major problem in that
it declares all MCUs in the SCU to be bad due to the fact that all the
FREDDIE Flip Flops are set to "1".
Whenever the CPU or SCU Error Log Entries include data that indicts any
part of the clocking for the MCUs, all other errors are ignored. So,
this very unfortunate bug in the SCU's BCM file masks the real problem
for which the SCU SCAN Error Log Entry was created. On the plus side, if
the FREDDIE Flip Flops happen to all be on a "0" (50/50 shot),
everything will work just fine.
As I'm sure you all know, when all the FREDDIE Flip FLops are in the
same state (0 or 1), this is not an error condition. The problem has
been found and corrected in the BCM file that now resides in the public
area on MRCSSE.
In the mean time, if you have already seen this problem, you can
manually peruse the SCAN Error Log Entry that was created for the SCU
Page 1 of 2
error to determine what went wrong. Keep in mind that some of the errors
have been disabled (ref MRCSSE::NONAME:[PUBLIC]SCU_ERR_ENA.TXT) and
should be ignored if set in the SCU SCAN Error Log Entry.
TY MRCSSE::NONAM:[PUBLIC]SCU_ERR_ENA.TXT
>>>@[tools]all_error_latches all
* %SCU.CCU.CTLD.ERROR_LAT_H<12> = 1
; SPU Handshake Parity Error, Known design problem, no current plans to be
; fixed.
* %SCU.DA1.IRC0.JDC1_IRCX_ERR_H<0> = 1
; The IRCX is not used in DA1, many input signals are unconnected.
* %SCU.DA1.JDC0.HOLD_CTLD_PE_H<0> = 1
; SPU Handshake Parity Error, DA1 inputs are unconnected since SPU Control is
; on DA0.
* %SCU.TAG.ADR0.L006.ADR_PAR_ERR_LK_B_H<0> = 1
* %SCU.TAG.ADR0.L030.ADR_PAR_ERR_LK_B_H<0> = 1
* %SCU.TAG.ADR1.L030.ADR_PAR_ERR_LK_B_H<0> = 1
* %SCU.TAG.ADR2.L006.ADR_PAR_ERR_LK_B_H<0> = 1
* %SCU.TAG.ADR2.L030.ADR_PAR_ERR_LK_B_H<0> = 1
* %SCU.TAG.ADR3.L006.ADR_PAR_ERR_LK_B_H<0> = 1
* %SCU.TAG.ADR3.L030.ADR_PAR_ERR_LK_B_H<0> = 1
; Known design problem, some of the Super Macros in the ADRXs cannot be
; initialized which results in parity errors.
* %SCU.TAG.ADR0.L005.PAR_ERR_B_H<0> = 1
* %SCU.TAG.ADR1.L005.PAR_ERR_B_H<0> = 1
* %SCU.TAG.ADR2.L005.PAR_ERR_B_H<0> = 1
* %SCU.TAG.ADR3.L005.PAR_ERR_B_H<0> = 1
; ICU1 Receive Address Parity Error, this is caused by improper setting of a
; parity flip bit during initialization. Always occurs when ICU1 is installed.
* %SCU.TAG.ADR1.L007.PAR_ERR_PA_H<0> = 1
* %SCU.TAG.ADR1.L008.PAR_ERR_PA_H<0> = 1
* %SCU.TAG.ADR2.L007.PAR_ERR_PA_H<0> = 1
* %SCU.TAG.ADR2.L008.PAR_ERR_PA_H<0> = 1
* %SCU.TAG.ADR3.L007.PAR_ERR_PA_H<0> = 1
* %SCU.TAG.ADR3.L008.PAR_ERR_PA_H<0> = 1
; These are unconnected inputs on the ADR1, ADR2, and ADR3.
; ADR0 should never see this error.
|
| 78.95 | Blower problems | KERNEL::WRIGHTON | odd numbered release = bug insert | Fri Dec 07 1990 08:42 | 33 |
|
VAX 9000 Fan Motor Controller, 12-28382-01
Some incidents of failure have been reported from the field on this part.
The part has been upgraded for various engineering changes, however the
latest changes most affecting reliablity bring the part from the vendor's
revision 5 to their revision 7. Four field failures have been reported
from machines that are either at pre-customer checkout or on site. For
that reason, an upgrade of all field spares presently stocked is being
recommended. Existing stock can be returned for upgrade. This part is
not currently on the returns list, but is being added for this upgrade and
for repair in the future.
An ECO is in process to require the DEC revision to be marked on the units.
The upgraded revision will be Rev D. This will be equivalent to the vendor's
revision 8. Revision 7 units in the field should be used as they have the
circuit changes installed. Units with vendor revisions 4, 5, or 6 should
be returned for this upgrade. These units have no DEC revision identifica-
tion.
A cautionary note for FE's working with this unit. The unit should never
be connected or disconnected from either the 280v buss or the motor while
any voltage is present on the buss, or while the blower rotor is in motion.
Incidents of failure have been reported in Mfg. due to premature unplugging.
|
| 78.96 | F330 microcode !!! | KERNEL::WRIGHTON | odd numbered release = bug insert | Fri Dec 07 1990 08:43 | 35 |
|
SUBJECT: URGENT!!! - F330 Microcode problems
************************************************************************
IF YOU HAVE A MACHINE THAT IS CURRENTLY RUNNING F330 MICROCODE, YOU MUST
INSTALL E330 AS SOON AS POSSIBLE!
************************************************************************
There are apparently some sites out there that are running F330
microcode in the EBOX. This microcode is known to have problems and
should not be used in the field.
The currently supported and released microcode for the VAX 9000 EBOX is
revision E330.
If you don't have this version, it can be copied from:
MRCSSE::NONAME:[PUBLIC]AQUARIUS_E330.LOD
A little history....
F330 was intended to be the official release for B5. We were positioned
to start shipping it to the field with the B5 upgrade and also as the
default microcode on B5 machines coming from manufacturing. Then a
problem wass found, and we dropped back to E330 which works on both B4
and B5 machines.
Symptoms may vary with F330 microcode. It absolutely has problems in
multiple CPU configurations and has also been linked to Double Bit
Errors during Cache Writebacks (E330 masks this problem by handling
writebacks differently).
We are still investigating the distribution issue that allowed F330 to
get out to the field.
|
| 78.97 | BL12 Upgrade Instructions | KERNEL::WRIGHTON | odd numbered release = bug insert | Sat Dec 08 1990 16:14 | 337 |
|
+---------------------------+ TM
! ! ! ! ! ! ! ! i n t e r o f f i c e
! d ! i ! g ! i ! t ! a ! l !
! ! ! ! ! ! ! ! m e m o r a n d u m
+---------------------------+
Date: 12/7/90
To: VAX 9000 Tech Dist From: Butch Leitz
Dept: HPS/C CSSE MEG
DTN: 297-4257
LOC/MAIL STOP: MRO2-3/5E, Pole 2C
Email: HPSMEG::LEITZ
cc:
Subject: VAX 9000 SPU 12.0 Net Release Process
Software Upgrade Instructions
This is file MRCSSE::AQ$SPU:BL12_NET_BUILD_HELP.TXT.
This memo describes the installation of Base Level 12.0 software
on the VAX 9000 SPU RD54, using two TK50s created through the
network release process as defined in Appendix A or Appendix B
below depending on what hardware revision you have installed at
the target system.
W A R N I N G !
Instructions follow for building tapes to update your VAX 9000
SPU to BL12 depending on whether or not the hardware revision is
B4 or B5.
YOU CAN NOT INITIALIZE A SYSTEM WITH B5 HARDWARE USING B4 SOFTWARE.
If the target system is at a B4 HARDWARE REVISION, refer to
Appendix A for instructions on creating two TK50 tapes to update
this system to Base Level 12 using save sets released over the
network.
If the target system is at a B5 HARDWARE REVISION, refer to
Appendix B for instructions on creating two TK50 tapes to update
this system to Base Level 12 using save sets released over the
network.
NOTE:
If The Target System Is At B4 But Is Having A
Simultaneous Hardware Upgrade To B5 (via the B5
CTU Upgrade) , Use The Procedures Found In
Appendix B To Create Update Tapes For This System.
Install The Software Prior To Shutting Down For
The Hardware Upgrade.
NOTE REGARDING MULTI-CPU MULTI-REV SUPPORT:
Mult-revision support of systems is possible. If
CPUs are at two different hardware revisions, you
can edit SITESPECIFIC.CMD to support this. Do not
use the instructions in this document to build
update tapes for multi-rev systems. Specific
instructions apply. Contact me directly for
details.
IF YOU HAVE NOT BUILT THE BL12 TK50S, PROCEED TO APPENDIX A FOR B4 SYSTEMS
OR PROCEED TO APPENDIX B FOR B5 SYSTEMS.
INSTALLATION OF BL12 USING TAPES MADE FROM NETWORK RELEASE PROCESS
AS DEFINED IN THIS TEXT:
-------------------------------------------------------------------
Note regarding new RD54s:
.-----------------------------------------------------.
| Preliminary step: If you are attempting to build |
| the kit on a brand new RD54, you must format the |
| drive before initializing it in the build |
| procedure below. Read the instructions in Appendix |
| C if you are installing new software on a new RD54 |
| that has never been used before. |
`-----------------------------------------------------'
-------------------------------------------------------------------
To install Base Level 12 from TK50s created from APPENDIX A or
APPENDIX B onto the target SPU, proceed as follows:
1) Use the tape labeled BL12B4 created from Appendix A for a B4 system.
Use the tape labeled BL12B5 created from Appendix B for a B5 system.
Insert the tape into the TK50 drive, load it, and boot from it:
SPM-ROM> B MU77
2) Type @INSTALL when the SPU has booted (takes about 5 minutes
to reach prompt. Note that the prompt is CONSOLE>.)
CONSOLE> @INSTALL
3) Install will ask you if you want to initialize the disk. In most
cases you will answer "Y" since the new files consume from 80,000
to 130,000 blocks depending on hardware rev.
You may wish to create a TK50 from your old disk containing any
files that need to be recreated on the new disk, or simply print
out the following files on hardcopy for reference later.
You may wish to include...
[sysexe]sitespecific.cmd
[sysexe]siteinit.cmd
[sysexe]startup.cmd
[sysexe]login.cmd
[sysexe]sysinit.cmd
[sysexe]config.dat
[userfiles]defboo.cmd (along with any *boo.cmd variants)
...And any command files or data from user areas you wish to include
on the new disk.
Note that all system files and command procedures will be created
from the INSTALL, so you do not need save any of these over on tape,
but you may wish to use them for comparisons later to ease editing
DEFBOO and SITESPECIFIC, etc. You will want to recopy any personal
command files onto the new SPU. Avoid overlaying old system .CMD
files over the same files created by the install process.
4) INSTALL.CMD will initialize the disk, create various directories on
DUA50 including [INSTALL], then will copy the 12.0 save sets to
DUA50:[INSTALL] alternatively running BACKUP to unpack the save sets
into their respective directories. This will take approximately an
hour and a half total.
5) Control passes back to INSTALL.CMD when finished which deletes
DUA50:[INSTALL], dismounts the TK50, and prints out the following
message prior to returning you to the prompt:
Installation complete
CONSOLE>
6) At this point, Internal DEC sites may now run PATCH from
VMA50:[SYSEXE] if required. This is not required for customer sites.
You can do this by typing @NETINSTALL at the console prompt:
CONSOLE>@NETINSTALL
7) You now have a 12.0 system on your RD54 (without the SDD files). You
should now mount the tape you made in advance from your previous
system, and restore any files to the new RD54 that you may require.
You do not have to do this, but you will have to edit the following
files to match your site configuration:
DUA50:[SYSEXE]SITESPECIFIC.CMD
Default settings you may need to change:
SYS$CPU_MASK
SYS$VBOX_MASK
SYS$PRIMARY
SYS$ICU_MASK
SYS$XJA_MASK
SYS$MMU_MASK
SYS$KEEPALIVE "MANUAL"
DUA50:[USERFILES]*boo.cmd
Copy the appropriate BOO.CMD file to DEFBOO.CMD, then
edit the new DEFBOO.CMD.
8) When all files have been edited or updated, reboot the SPU:
>>> REBOOT/NOCONFIRM
The new SPU system should now boot properly.
Followed by the normal SPU startup messages.
9) EWKCA: You will see an error message after EWKCA.CMD has been taken:
%SPU-F-NOTINSTALLED, this image has not been installed
The SPU will boot properly, but EWKCA still needs to be INSTALLed, or
it will not run. The following procedure should be followed:
Place the 2nd tape made from the net release process in the TK50
drive and load it. Then proceed by entering the following commands:
>>> mount mua7 BL12SDD
>>> set command [sysexe]backup
>>> backup/log mua7:[]kitinstall.cmd dua50:[sysmaint]kitinstall.cmd
>>> @[sysmaint]kitinstall.cmd
Messages will be displayed indicating files being created. An expiration
date will be set on EWKCA.EXE which will cause the code to cease working
one year from the date you are doing this.
10) This completes the 12.0 installation. Entire elapsed time should be
just under 2 hours.
If you didn't make the edit changes in SITESPECIFIC.CMD and
DEFBOO.CMD that are required for your configuration, do so at this
time.
11) You should now reboot the SPU:
>>> REBOOT/NOCONF
You may now I/K and BOOT VMS, or use any of the diagnostics available
on the SPU's Base Level 12 kit.
Appendix A: UPGRADING ***< B 4 >*** SYSTEMS TO BL12:
To build a bootable TK50 to update a VAX 9000 SPU to Base Level 12:
$ !The following command stream will create one TK50 with all the
$ !VAX 9000 SPU Base Level 12.0 data required to update an SPU on a
$ !system at
$ ! B 4 H A R D W A R E R E V I S I O N
$ !
$ !The save sets to be put on one tape mimic the first 3 tapes of
$ !a standard SPU release from SSB (QZ-K23AA-FW).
$ !
$ !Use this as an example. FOR FASTER TAPE BUILDS, COPY THE SAVE SETS
$ !TO A LOCAL STORAGE AREA FIRST, then create the tape by copying files
$ !from the local disk to tape.
$
$ INIT MUA0: BL12B4
$ MOUNT MUA0: BL12B4
$ COPY MRCSSE::AQ$SPU:SYSBOOT.EXE MUA0:
$ COPY MRCSSE::AQ$SPU:DISK.IMA MUA0:
$ COPY MRCSSE::AQ$SPU$12:B4_KITINSTALL.CMD MUA0:KITINSTALL.CMD
$ COPY MRCSSE::AQ$SPU$12:SPUBL12_A.SBK;1 MUA0:
$ COPY MRCSSE::AQ$SPU$12:SPU_LOG_B4_B.SBK;1 MUA0:
$ COPY MRCSSE::AQ$SPU$12:SPU_DIAG_42_B4_A.SBK;1 MUA0:
$ DISMOUNT MUA0
$
$ !End of Base Level 12.0 net build of primary update tape for B4 systems
$ !The following command stream will create one tape with all the
$ !VAX 9000 SPU Base Level 12.0 SSB release data (tape 4, the SDD tape).
$ !
$ INIT MUA0: BL12SDD
$ MOUNT MUA0: BL12SDD
$ COPY MRCSSE::AQ$SPU$12:INSTALL_EWKCA.CMD MUA0:KITINSTALL.CMD
$ COPY MRCSSE::AQ$SPU$12:SPU_SDD_12_A.SBK;1 MUA0:
$ DISMOUNT MUA0
$
$ !End of Base Level 12.0 net build of tape 2.
Appendix B: UPGRADING ***< B 5 >*** SYSTEMS TO BL12:
To build a bootable TK50 to update a VAX 9000 SPU to Base Level 12:
$ !The following command stream will create one TK50 with all the
$ !VAX 9000 SPU Base Level 12.0 data required to update an SPU on a
$ !system at (or going to) a
$ ! B 5 H A{R D W A R E R E V I S I O N
$ !
$ !The save sets to be put on one tape mimic the first 3 tapes of
$ !a standard SPU release from SSB (QZ-K23AA-FW).
$ !
$ !Use this as an example. FOR FASTER TAPE BUILDS, COPY THE SAVE SETS
$ !TO A LOCAL STORAGE AREA FIRST, then create the tape by copying files
$ !from the local disk to tape.
$
$ INIT MUA0: BL12B5
$ MOUNT MUA0: BL12B5
$ COPY MRCSSE::AQ$SPU:SYSBOOT.EXE MUA0:
$ COPY MRCSSE::AQ$SPU:DISK.IMA MUA0:
$ COPY MRCSSE::AQ$SPU$12:B5_KITINSTALL.CMD MUA0:KITINSTALL.CMD
$ COPY MRCSSE::AQ$SPU$12:SPUBL12_A.SBK;1 MUA0:
$ COPY MRCSSE::AQ$SPU$12:SPU_LOG_B5_B.SBK;1 MUA0:
$ COPY MRCSSE::AQ$SPU$12:SPU_DIAG_42_B5_A.SBK;1 MUA0:
$ DISMOUNT MUA0
$
$ !End of Base Level 12.0 net build of primary update tape for B5 systems.
$ !The following command stream will create one tape with all the
$ !VAX 9000 SPU Base Level 12.0 SSB release data (tape 4, the SDD tape).
$ !
$ INIT MUA0: BL12SDD
$ MOUNT MUA0: BL12SDD
$ COPY MRCSSE::AQ$SPU$12:INSTALL_EWKCA.CMD MUA0:KITINSTALL.CMD
$ COPY MRCSSE::AQ$SPU$12:SPU_SDD_12_A.SBK;1 MUA0:
$ DISMOUNT MUA0
$
$ !End of Base Level 12.0 net build of tape 2.
Appendix C: Formatting the RD54:
Basically, to format a brand new never-been-used disk, install it,
power it on, power on the SPU, then:
SPM-ROM> Z A
T/R
RBDA> D1/TR/C 01 !This step takes a while - up to 30 minutes
RBDA>^P
SPM-ROM>
At this point you can boot from one of the bootable TK50s, either
the one you made from the net release instructions, or tape 1
(AQ-PAKHA-ME) from the SSB kit.
This KFBTA test is described in the fault isolation manual
(maintenance guide volume 2 - EK-KA902-MG), but not very well. It
is slightly better described in the SPU Technical Description
(EK-KA90C-TD) under KFBTA tests, but unit_mask is not described
very well in either case. Using the example above, in RBDA>, the
unit_mask is 01 which reflects winchester "0" on the KFBTA. Since
we only have one RD54 in the SPU, unit_mask is always "01".
A complete description of all KFBTA diagsnotics can be found in the
KFBTA Technical Manual, EK-KFBTA-TM.
[MRCSSE::AQ$SPU:BL12_NET_BUILD_HELP.TXT]
|
| 78.98 | SIP problems during install | KERNEL::WRIGHTON | odd numbered release = bug insert | Mon Dec 10 1990 16:49 | 46 |
|
Subject: Problem with SIP connector J9 during installation
Problem Symptom
o If you see any of these errors during system installation or the
installation of the SFM upgrade you could have a cable installed
backwards in either the SFM,SIP or MCM.
o MCM acknowledge timeouts when trying to do anything with the clock
o TEST/CLOCK will fail on subtest 2
>>>test/clock
%TEST-I-ERROR, error detected by hardcore test version 14.0
Subtest number: 2
Test description: MCM Transfer ACK Test
Pass number: 0
Fix/Workaround
o There has been a problem reported in the field with TWO SIPs. It
appears that the connector J9 has been mounted backwards on the
SIP. No matter how J9 is mounted on the SIP the cable must be
installed with its key facing the lights. Connector J9(SIP) is
connected to J1 in the SFM module. The plug should go into J9
with the key facing the lights. This means that the connector J9
on the SIP should have its middle slot facing the lights. The
suspect SIP's will have the middle slot facing the back. I have
alerted Logistics and Manufacturing about this problem and have
requested that the SIP modules be checked.
| | o
| | o
| o
| o
| | o
^ ^
^ ^
^ ^
J9 LIGHTS
|
| 78.99 | fuse problem | KERNEL::WRIGHTON | odd numbered release = bug insert | Thu Dec 13 1990 14:22 | 37 |
|
===========================================================
Initial reports from Manufacturing and the Field indicate that some
of the primary buss fuses in the PIP may be blowing during power
disturbances. It appears that they are blowing due to a "hot inrush".
The fuses in PIP 1 and 2 are Fj and Fk, 40 amp tab-mounted units.
These are "very fast blow" units. Additionally, Fa and Fe have been
reported blowing. These are DC rated KTK types, 30 amp rating.
Engineering is aware of the problem and is working to find
replacements that have a higher inrush capacity.
Meanwhile, these fuses should only be replaced with identical parts
to assure that UL requirements are not violated. The correct part
numbers are:
12-32726-06 30 ampere KTK
12-28011-01 40 ampere
The input fuses in the H7214 and H7215 are also reported to be
blowing. These parts, along with the 40 amp part above, will be added
to spares stock and should be available shortly.
The fuse for the H7214 is 12-17199-02, 8amps
The fuse for the H7215 is 12-17199-00, 3amps.
Replace the fuses in the H7214 and H7215 before swapping the actual
power modules since the reliability of the H7214 in spares stock may
not be as good as the screened units which have been shipped in VAX
94XX systems.
===========================================================
|
| 78.100 | Latest Bug list (14-Dec-1990) | KERNEL::WRIGHTON | odd numbered release = bug insert | Tue Dec 18 1990 10:30 | 3710 |
|
VAX 9000 "BUG" List
Revision/Update Information: 14-December-1990
DIGITAL CONFIDENTIAL
Published by:
o ISBS / CSSE
Digital Equipment Corporation
________________________
Aug 1990
__________
The information in this document is subject to change without
notice and should not be construed as a commitment by Digital
Equipment Corporation. Digital Equipment Corporation assumes no
responsibility for any errors that may appear in this document.
The software described in this document is furnished under a
license and may be used or copied only in accordance with the
terms of such license.
No responsibility is assumed for the use or reliability of
software on equipment that is not supplied by Digital Equipment
Corporation or its affiliated companies.
__________
Copyright �1990 by Digital Equipment Corporation
All Rights Reserved.
Printed in U.S.A.
__________
The postpaid READER'S COMMENTS form on the last page of this
document requests the user's critical evaluation to assist in
preparing future documentation.
The following are trademarks of Digital Equipment Corporation:
DEC DIBOL UNIBUS
DEC/CMS EduSystem VAX
DEC/MMS IAS VAXcluster
DECnet MASSBUS VMS
DECsystem-10 PDP VT
DECSYSTEM-20 PDT
DECUS RSTS
DECwriter RSX DIGITAL
This document was prepared using VAX DOCUMENT, Version 1.2
CONTENTS
Chapter 1 CPU SUBSYSTEM.................................. 1
1.0.1 Minimum Revisions:.............................. 2
1.0.2 Hardware:....................................... 3
1.0.3 uCode:.......................................... 19
1.0.4 Software:....................................... 21
Chapter 2 CLOCK SUBSYSTEM................................ 23
2.1 MASTER CLOCK Subsystem............................. 24
2.1.1 Minimum Revisions:.............................. 24
2.1.2 Diagnostics:.................................... 25
2.1.3 Software:....................................... 26
Chapter 3 I/O SUBSYSTEM.................................. 29
Chapter 4 POWER SUBSYSTEM................................ 43
Chapter 5 SPU SUBSYSTEM.................................. 59
Chapter 6 MEMORY SUBSYSTEM:.............................. 67
Chapter 7 VAX 9000 INSTALLATION.......................... 69
Chapter 8 VMS SUBSYSTEM:................................. 75
8.1 VMS Subsystem:..................................... 75
8.1.1 Minimum Revisions:.............................. 75
8.1.2 Software:....................................... 75
iii
CHAPTER 1
CPU SUBSYSTEM
CPU Subsystem 1
DIGITAL INTERNAL USE ONLY
Date: 14-Dec-1990 Reference #'s: N/A
CSSE Contact: Chris Demos
DTN: 297-5147
Node: MRCSSE::DEMOS
Title: CPU/SCU Subsystem
1.0.1 Minimum Revisions:
o Hardware:
_____________________________________________________________
OPTION_________Rev______Comments_____________________________
CPU B4/B5 (CDB revision)
SCU____________B3/B5____(CDB_revision)_______________________
o uCODE:
_____________________________________________________________
OPTION___Rev______Comments___________________________________
CPU E330
SCU______N/A_________________________________________________
2 CPU Subsystem
DIGITAL INTERNAL USE ONLY
Date: 14-Dec-1990 Reference #'s: N/A
CSSE Contact: Chris Demos
DTN: 297-5147
Node: MRCSSE::DEMOS
Title: CPU/SCU Subsystem
1.0.2 Hardware:
1. PROBLEM:
Various SCU errors remain disabled when SCU error reporting
is on
Cause:
Various bugs in the way that errors are detected and
reported in the SCU have resulted in erroneous error
conditions in the SCU.
Fortunately the design of the SCU error logic had to
account for configuration dependencies and therefore
many pieces of the error detection logic can be disabled
independent of the other parts of the SCU error logic.
CPU Subsystem 3
SOLUTION/WORKAROUND:
For the currently released SCU hardware, these erroneous
error conditions have been eliminated by disabling the
individual error checkers that produce erroneous er-
rors. The disables are implemented via commands in [SY-
SEXE]SITEINIT.CMD (which is how SCU error reporting is
turned on too).
The majority of the SCU error checkers are now enabled and
will create SCAN Error Log Entries in the error log when
they are detected.
Ultimately, these erroneous errors will be resolved in a
future release of the SCU hardware.
For more information see the new and improved version of:
MRCSSE::NONAME:[PUBLIC]SCU_ERR_ENA.TXT
4 CPU Subsystem
DIGITAL INTERNAL USE ONLY
Date: 14-Dec-1990 Reference #'s: N/A
CSSE Contact: Chris Demos
DTN: 297-5147
Node: MRCSSE::DEMOS
Title: CPU/SCU Subsystem
2. PROBLEM:
CTU.WBEM.DOUBLE_BIT_ERR_TA_H and/or CTU.WBEM.SINGLE_BIT_ERR_
TA_H true with no other errors bits set.
Cause:
During MBOX cache sweeps there is a problem in the sweep
logic on the CTMV MCA that results in addressing the data
cache incorrectly while trying to sweep the first block of
set 0. The data does not match the check bits in the ECC
store, so an error is reported. This can occur in any VAX
9000 configuration.
SOLUTION/WORKAROUND:
Ebox Microcode revision E330 implements a cache sweep via
microcode thus eliminating the possibility that the CTMV
bug will occur. This microcode feature is implemented
CPU Subsystem 5
for EBOX HALTS and normal sweeps requested via an MTPR
instruction.
There is still a possibility that this problem may occur
during a sweep that has been requested due to an Error
condition in the VAX 9000 CPU or SCU. These conditions
cause a sweep to occur via the ERROR_SWEEP signal from the
EBOX. This path does not take advantage of the microcodeed
cache sweep and is therefore vulnerable.
The long term fix for this problem is incorporated into
the next revision of the VAP MCU which will upgrade the
CPU to B6.
For more information see; MRCSSE::NONAME:[PUBLIC]CACHE_
SWEEPS.TXT
6 CPU Subsystem
DIGITAL INTERNAL USE ONLY
Date: 14-Dec-1990 Reference #'s: N/A
CSSE Contact: Chris Demos
DTN: 297-5147
Node: MRCSSE::DEMOS
Title: CPU/SCU Subsystem
3. PROBLEM:
Keep Alive Failures due to MBOX design bug
Cause:
The MBOX TB arbitration logic hangs after receiving an
ABORT from the EBOX. The EBOX sends the ABORT to indicate
that it has received all required data in the source
specified by a CMPC3 or CMPC5 instruction.
SOLUTION/WORKAROUND:
EBOX microcode version E330 has been modified to disal-
low prefetching the source data during CMPC3 and CMPC5
instructions. This approach eliminates the sequence of
events that lead to this problem.
The long term fix for this problem is incorporated into
the next revision of the VAP MCU which will upgrade the
CPU Subsystem 7
CPU to B6.
For more information see; MRCSSE::NONAME:[PUBLIC]MBOX_TB_
ARB.TXT
8 CPU Subsystem
DIGITAL INTERNAL USE ONLY
Date: 14-Dec-1990 Reference #'s: N/A
CSSE Contact: Chris Demos
DTN: 297-5147
Node: MRCSSE::DEMOS
Title: CPU/SCU Subsystem
4. PROBLEM:
BUGCHECK/HALTS Caused by Cache Control Design Bug
System crashes with Kernel Mode Halts or Bugchecks. The halts
and bugchecks are at or around the same PC usually in a I/O
device driver. There would most likely be and instruction
that will be doing a write to an I/O device register. The
only error bits that may be latched are NXM errors. In one
of the systems increasing the sysgen paramenter NPAGEDYN by
1,200,000 enabled the system to run without any halts.
The symptoms vary, but include:
I-stack not valid -- bogus PTE loaded
exception above ASTDEL -- bad i-stream fetched
page-fault, IPL too high -- bogus PTE loaded
HALT -- i-stream fetches zero's
mem nxm, read or write -- wild translation
io nxm, read or write -- wild translation
Cause:
The system failures are caused by improper virtual address
CPU Subsystem 9
translations in the MBox. The effect of the logic bug
is that a page table entry (PTE) is loaded into the
translation buffer (TB) incorrectly.
The bug is provoked by the incidence of a TB miss while
a CPU write, typically to I/O space, is delayed due to
a hardware resource wait. During this delay, cache set
selection information is frozen (even if the CPU write is
non-cacheable, as in I/O space writes). To resolve the TB
miss, the fixup processor requests the cache to deliver
the appropriate PTE for loading into the TB. If the PTE
resides in the OPPOSITE cache set that is selected during
the write-delay, incorrect data will be delivered to the
TB, thus causing an improper virtual address translation.
Only fixup processor requests are vulnerable to this cache
malfunction, because this is the only type of request that
the cache's arbitration logic allows to proceed while CPU
writes are in progress.
The effects of the problem are varied. Improper
translations can lead to a variety of exceptions, and
in some cases hardware error conditions.
SOLUTION/WORKAROUND:
This is a hardware problem which will be fixed by a new
revision of the VAP MCU. The B5 CTU upgrade addressing
some circumstances under which this problem may occur.
There remain other scenarios in which this problem might
occur. These will be fixed in the new VAP MCU currently
planned to be designated as the B6 upgrade.
For the interim, there are some WORKAROUNDS:
10 CPU Subsystem
Systems with BI devices should get:
MRCSSE::NONAME:[PUBLIC]LIDRIVER.EXE
MRCSSE::NONAME:[PUBLIC]PUDRIVER.EXE
MRCSSE::NONAME:[PUBLIC]SIDRIVER.EXE
MRCSSE::NONAME:[PUBLIC]YIDRIVER.EXE
The FIX for this problem will be in CPU Revision B6 which
will introduce a new VAP MCU.
The WORK AROUND for this problem is to disable one of
the Cache Sets by depositing the command shown below in
CSA1:[SYSEXE]SITEINIT.CMD.
! DISABLE SET 0
D/CPU=('CPU') CTU.CTMV.SET_SEL_H<1> 1
This work around should be applied only when absolutely
sure that it is needed to resolve a particular problem.
Contact CSSE if unsure that disabling half of cache will
resolve a problem. Disabling one cache set could lead to
a significant decrease in performance depending on how
the system is used doing mostly I/O or compute bound jobs.
Engineering is currently looking into a VMS and UCODE
change as a workaround.
CPU Subsystem 11
DIGITAL INTERNAL USE ONLY
Date: 14-Dec-1990
Reference #'s: N/A
CSSE Contact: Chris Demos
DTN: 297-5147
Node: MRCSSE::DEMOS
Title: CPU/SCU Subsystem
5. PROBLEM:
MBOX Cache Sweep Problems
Cause:
SOLUTION/WORKAROUND:
For more information see;
MRCSSE::NONAME:[PUBLIC]CACHE_SWEEPS.TXT
12 CPU Subsystem
DIGITAL INTERNAL USE ONLY
Date: 14-Dec-1990
Reference #'s: N/A
CSSE Contact: Chris Demos
DTN: 297-5147
Node: MRCSSE::DEMOS
Title: CPU/SCU Subsystem
6. PROBLEM:
Intermittent MULX parity errors on the VML MCU in the VBOX
Cause:
SOLUTION/WORKAROUND:
For more information see;
MRCSSE::NONAME:[PUBLIC]VML_MULX.TXT
7. PROBLEM:
Intermittent STGX parity errors on the DST MCU or OPU MCU
Cause:
CPU Subsystem 13
SOLUTION/WORKAROUND:
For more information see; MRCSSE::NONAME:[PUBLIC]STGX.TXT
14 CPU Subsystem
DIGITAL INTERNAL USE ONLY
Date: 14-Dec-1990
Reference #'s: N/A
CSSE Contact: Chris Demos
DTN: 297-5147
Node: MRCSSE::DEMOS
Title: CPU/SCU Subsystem
8. PROBLEM:
Intermittent MULX parity errors on the MUL MCU
Cause:
SOLUTION/WORKAROUND:
For more information see;
MRCSSE::NONAME:[PUBLIC]MUL_MULX.TXT
CPU Subsystem 15
DIGITAL INTERNAL USE ONLY
Date: 14-Dec-1990
Reference #'s: N/A
CSSE Contact: Chris Demos
DTN: 297-5147
Node: MRCSSE::DEMOS
Title: CPU/SCU Subsystem
9. PROBLEM:
SCU SDD theories/syndromes calling out all SCU MCUs
Cause:
The BCM file for the SCU has an error in the algorithms
that interpret FREDDIE Flip Flop inconsistencies.
SOLUTION/WORKAROUND:
Install the new BCM file in the [SYSMAINT] area on the
SPU's RD54. The file must be named EWKCK.BCM.
For more information see;
MRCSSE::NONAME:[PUBLIC]EWKCK_UPDATE.TXT
16 CPU Subsystem
DIGITAL INTERNAL USE ONLY
Date: 14-Dec-1990
Reference #'s: N/A
CSSE Contact: Chris Demos
DTN: 297-5147
Node: MRCSSE::DEMOS
Title: CPU/SCU Subsystem
10.PROBLEM:
Intermittent VREG, WBUF, IBANK2, and TBRAMS structure test
failures
Cause:
Although the specific set of circumstances leading up
to these failures has been very difficult to pin down,
the problems are due to STRUCTURE definitions that lack
proper setups to get around the conditions that cause
these failures.
SOLUTION/WORKAROUND:
The VREG and IBANK2 failures are resolved in SPU software
release Base Level 11.
The TBRAMS and WBUF structure failures have been fixed in
the B5 CDB file which is now shipping with new machines
CPU Subsystem 17
and is also part of the field upgrade package.
18 CPU Subsystem
DIGITAL INTERNAL USE ONLY
Date: 14-Dec-1990 Reference #'s: N/A
CSSE Contact: Chris Demos
DTN: 297-5147
Node: MRCSSE::DEMOS
Title: CPU/SCU Subsystem
1.0.3 uCode:
1. PROBLEM:
F330 Microcode problems
Cause:
F330 microcode was to be the revision that supports B5
CPUs. As such it removed some patches that were installed
to address problems that were to be resolved by the B5
upgrade of the CTU MCU. During testing some problems were
discovered in the F330 revision.
CPU Subsystem 19
SOLUTION/WORKAROUND:
Use E330 microcode for all machines and configurations.
For more information see;
MRCSSE::NONAME:[PUBLIC]F330_UCODE_BUG.TXT
20 CPU Subsystem
DIGITAL INTERNAL USE ONLY
Date: 14-Dec-1990 Reference #'s: N/A
CSSE Contact: Chris Demos
DTN: 297-5147
Node: MRCSSE::DEMOS
Title: CPU/SCU Subsystem
1.0.4 Software:
1. PROBLEM: No Known Problems
Cause:
SOLUTION/WORKAROUND:
CPU Subsystem 21
CHAPTER 2
CLOCK SUBSYSTEM
CLOCK Subsystem 23
DIGITAL INTERNAL USE ONLY
Date: 14-Dec-1990 Reference #'s: N/A
CSSE Contact: Chris Demos
DTN: 297-5147
Node: MRCSSE::DEMOS
Title: MASTER CLOCK Subsystem:\clock
2.1 MASTER CLOCK Subsystem
2.1.1 Minimum Revisions:
o Hardware: Master Clock Module 70-25847-02 Revision D
24 CLOCK Subsystem
DIGITAL INTERNAL USE ONLY
Date: 14-Dec-1990 Reference #'s: N/A
CSSE Contact: Chris Demos
DTN: 297-5147
Node: MRCSSE::DEMOS
Title: MASTER CLOCK Subsystem:\clock
2.1.2 Diagnostics:
o PROBLEM:
Running SCAN Hardcore test from SPU on the Master Clock
Module runs fine, but leaves Master Clock Module in incorrect
state. Actual SPU command is ">>>Test/clock <CR>" .
o Cause:
SCAN Hardcore Test deficiency.
o SOLUTION/WORKAROUND:
Upgrade to SPU BL11.0. Execute an initialize/clock from the
SPU after running SCAN Hardcore Test on Master Clock Module.
Actual SPU command is ">>>Initialize/clock <CR>" .
CLOCK Subsystem 25
DIGITAL INTERNAL USE ONLY
Date: 14-Dec-1990 Reference #'s: N/A
CSSE Contact: Chris Demos
DTN: 297-5147
Node: MRCSSE::DEMOS
Title: MASTER CLOCK Subsystem:\clock
2.1.3 Software:
o PROBLEM:
SPU command that initializes Master Clock Module doesn't set
the Frequency to system nominal value. Note: SPU commands
that initializes Kernel DOES set system frequency to the
nominal value of 500 MHz.
o Cause:
Actual SPU command is ">>>Initialize/clock <CR>" .
o SOLUTION/WORKAROUND:
After using the SPU command ">>>Initialize/clock <CR>" , then
execute the following SPU command ">>>Set clock/frequency=500
26 CLOCK Subsystem
<CR>" , which will set the Master Clock Module to the
system's nominal frequency.
CLOCK Subsystem 27
CHAPTER 3
I/O SUBSYSTEM
I/O Subsystem 29
DIGITAL INTERNAL USE ONLY
Date: 07-Dec-1990 Reference #'s: N/A
CSSE Contact: Charlie Kretz
DTN: 297-4948
Node: MRCSSE::KRETZ
Title: Minimum I/O Subsystem Hardware Revisions for VAX 9000
Problem: Problems can occur if the I/O subsystem components are
not at the correct revision.
________________________________________________________________
OPTION___________Rev________Comments____________________________
XJA C04
CIXCD
T2080-00 E02
54-20225-01 B01 Rev A01 needs cover added
74-42384-01 Header Cover Component
74-42385-01 Header Cover Plate
DEMNA F02 T2030
KDM70 A Two module set
30 I/O Subsystem
________________________________________________________________
OPTION___________Rev________Comments____________________________
T2022 D01,E01
T2023 C01,C02
DWMBB A04 T2018
DRB32-M C02 T1022
DMB32 L T1012
DHB32 D01 T1044
DSB32 BX01 T1042
DEBNI C5/C6/C7 T1034
KDB50
T1002 N03
T1003 B07
KLESI____________D2_________T1014_______________________________
Solution/Workaround: None
Addition Comments: None
Update: None
I/O Subsystem 31
DIGITAL INTERNAL USE ONLY
Date: 07-Dec-1990 Reference #'s: N/A
CSSE Contact: Charlie Kretz
DTN: 297-4948
Node: MRCSSE::KRETZ
Title: Minimum I/O Subsystem uCODE Revisions for VAX 9000
Problem: Problems can occur if the I/O subsystem components do
not have the correct revision uCODE loaded.
________________________________________________________________
OPTION___Rev______Comments______________________________________
XJA V2.3
CIXCD V0.38 Diagnostic
V1.09 Functional
DEMNA V6.05
KDM70 V2.4 Patch coming soon
DMB32 V13 T1012
DEBNI____3000_____T1034_________________________________________
32 I/O Subsystem
Solution/Workaround: None
Addition Comments: None
Update: None
I/O Subsystem 33
DIGITAL INTERNAL USE ONLY
Date: 07-Dec-1990 Reference #'s: N/A
CSSE Contact: Charlie Kretz
DTN: 297-4948
Node: MRCSSE::KRETZ
Title: XJA Rev C03 self-test failures
Problem: Intermittent self-test failures can occur if a CIXCD
is configured on the XMI Bus. Also the EEPROMs have no write
protection and it is possible that they get corrupted at power
up.
Solution/Workaround: The final resolution to this problem is
to replace the XJA with a Rev C04 module. There is a temporary
workaround for the CIXCD interaction problem, and that is to
ensure that the CIXCD has V0.38 of the selftest diagnostic
code loaded. this diagnostic code is bundled in with the CIXCD
functional microcode.
Addition Comments: None
Update: The latest CIXCD functional microcode V1.09 which has
V0.38 of the diagnostic microcode bundled with it is available
on our system.
MRCSSE::PUBLIC:CIXCD.BIN
34 I/O Subsystem
DIGITAL INTERNAL USE ONLY
Date: 07-Dec-1990 Reference #'s: N/A
CSSE Contact: Charlie Kretz
DTN: 297-4948
Node: MRCSSE::KRETZ
Title: Slow DEMNA Performance
Problem: The problem is caused by the DEMNA responding in an
unusual way to a bad packet on the ENET. It turns out that the
FT 3000 on the standby ENET port sends out test packets. One of
the test packet the FT 3000 sends out has an incorrect number
of bytes. The size of the packet does not agree with the actual
size of the packet. This bad packet size for the FT3000 is being
corrected in the next version of VMS (V5.4-1). It is possible
that other (NON-Digital) devices on the ENET cause produce the
same type of packets.
Solution/Workaround: DEMNA uCODE V6.05
The new uCODE is located MRCSSE::PUBLIC:EVGDBQ.BIN
Addition Comments: None
Update: Original uCODE fix (V6.04) had a diagnostic bug and has
been replaced with V6.05 uCODE.
I/O Subsystem 35
DIGITAL INTERNAL USE ONLY
Date: 07-Dec-1990 Reference #'s: N/A
CSSE Contact: Charlie Kretz
DTN: 297-4948
Node: MRCSSE::KRETZ
Title: XJA/JXDI/SCU Timing problem
Problem: Unexpectedly long data path signal between the XJA and
the SCU
To identify the XJA/JXDI Timing problem, check these
scanlatches at the time of failure.
1. %SCU.CCU.CTLA.PRTERR_H<2> = 1
<<<<<<OR>>>>>>
2. %SCU.CCU.CTLA.2PRTRDY_H<1:0> = 0 or 1 and
%SCU.DA0.JDC0.RCV_CCU.TO_XJA_BUFA_FULL_TB_H = 0 and
%SCU.DA0.JDC0.RCV_CCU.TO_XJA_BUFB_FULL_TB_H = 0 and
%SCU.DA0.JDC0.RCV_CCU.IO_BUFA_BUSY_TB_H = 0 and
%SCU.DA0.JDC0.RCV_CCU.IO_BUFB_BUSY_TB_H = 0
===========================================================
or if XJA2 or XJA3 exists,
1. %SCU.CCU.CTLA.PRTERR_H<5> = 1
<<<<<<OR>>>>>>
36 I/O Subsystem
2. %SCU.CCU.CTLA.5PRTRDY_H<1:0> = 0 or 1 and
%SCU.DA1.JDC0.RCV_CCU.TO_XJA_BUFA_FULL_TB_H = 0 and
%SCU.DA1.JDC0.RCV_CCU.TO_XJA_BUFB_FULL_TB_H = 0 and
%SCU.DA1.JDC0.RCV_CCU.IO_BUFA_BUSY_TB_H = 0 and
%SCU.DA1.JDC0.RCV_CCU.IO_BUFB_BUSY_TB_H = 0
Solution/Workaround: Implemented in 3 Phases
Very Short Term - Do XJA Clock Cable Phase check
Short Term - Replace JXDI Cable with new cable (17-01786-02) and
XJA Clock cable (17-02454-01 REV C01).
Long Term - New MCU (Not Required for Model 210 or 4xx)
For more detail see the file
MRCSSE::PUBLIC:XJA_JXDI_CLK.CABLE
Addition Comments: None
Update: None
I/O Subsystem 37
DIGITAL INTERNAL USE ONLY
Date: 07-Dec-1990 Reference #'s: N/A
CSSE Contact: Charlie Kretz
DTN: 297-4948
Node: MRCSSE::KRETZ
Title: XJA Diagnostic EVCLB V1.5 Failures
Problem: Intermittent diagnostic failure doing Memory LOCKs
Solution/Workaround: XJA Diagnostic EVCLB V1.8
Addition Comments: None
Update: None
38 I/O Subsystem
DIGITAL INTERNAL USE ONLY
Date: 07-Dec-1990 Reference #'s: N/A
CSSE Contact: Charlie Kretz
DTN: 297-4948
Node: MRCSSE::KRETZ
Title: TEST/XJA failures caused by Operator Error
Problem: TEST/XJA requires a working CPU, a complete I/K must
be done before attempting to execute a TEST/XJA command. If a
working initialized CPU is not available TEST/XJA will fail.
Solution/Workaround: Issue an I/K before TEST/XJA
Addition Comments: None
Update: None
I/O Subsystem 39
DIGITAL INTERNAL USE ONLY
Date: 07-Dec-1990 Reference #'s: N/A
CSSE Contact: Charlie Kretz
DTN: 297-4948
Node: MRCSSE::KRETZ
Title: TEST/JXDI failures - (Pattern set REV A & B)
Problem: SJA Parity error in Test 0
For more detail see file [SYSMAINT]JXDI_HELP.TXT
Solution/Workaround: Console Software FT10.4 or higher
Addition Comments: None
Update: None
40 I/O Subsystem
DIGITAL INTERNAL USE ONLY
Date: 07-Dec-1990 Reference #'s: N/A
CSSE Contact: Charlie Kretz
DTN: 297-4948
Node: MRCSSE::KRETZ
Title: TEST/JXDI failures - (Pattern set REV B)
Problem: Compare error in Test 61
Solution/Workaround: Console Software FT11.0 or higher
Addition Comments: None
Update: None
I/O Subsystem 41
CHAPTER 4
POWER SUBSYSTEM
POWER Subsystem 43
DIGITAL INTERNAL USE ONLY
Date: 07-Dec-1990 Reference #'s: N/A
CSSE Contact: Charlie Kretz
DTN: 297-4948
Node: MRCSSE::KRETZ
Title: Minimum Power Subsystem Hardware Revisions for VAX 9000
Problem: Problems can occur if the power subsystem components
are not at the correct revision.
________________________________________________________________
OPTION_________Rev______Comments________________________________
H7214 B08
H7215 F06
H7380 H05
H7382 H04
H7386 C05
H7388 D08
H7389 E07 Model 210
F07 Model 4xx
44 POWER Subsystem
________________________________________________________________
OPTION_________Rev______Comments________________________________
T1060 D02 Field Test
H03 STEP FIX UPGRADE
54-17895-01 E02 Model 4xx
54-18672-01 E02 Model 4xx
54-18674-01 E03 Model 4xx
54-18676-01 E03 Model 4xx
54-18678-01 E02 Model 4xx
54-18758-01 C02
54-18792-01 F01 Model 210
54-18800-01 E02 Model 210
54-18802-01 E01 Model 210
54-19021-01 E01 Model 210
54-19028-01 F05 UPC
H05 H7390
J06 STEP FIX UPGRADE
54-19030-01 H02
54-19043-01 D04
POWER Subsystem 45
________________________________________________________________
OPTION_________Rev______Comments________________________________
54-19045-01 D01
54-19256-01 E02 Model 210
54-20237-01____B01______Model_4xx_______________________________
Solution/Workaround: None
Addition Comments: None
Update: None
46 POWER Subsystem
DIGITAL INTERNAL USE ONLY
Date: 07-Dec-1990 Reference #'s: N/A
CSSE Contact: Charlie Kretz
DTN: 297-4948
Node: MRCSSE::KRETZ
Title: Minimum Power Subsystem uCODE Revisions for VAX 9000
Problem: Problems can occur if the power subsystem components do
not have the correct revision uCODE loaded.
________________________________________________________________
OPTION___Rev______Comments______________________________________
T1060 8B
H7388 84
H7389____84_____________________________________________________
Solution/Workaround: None
Addition Comments: None
Update: None
POWER Subsystem 47
DIGITAL INTERNAL USE ONLY
Date: 07-Dec-1990 Reference #'s: N/A
CSSE Contact: Charlie Kretz
DTN: 297-4948
Node: MRCSSE::KRETZ
Title: AC Breaker Shock Hazard
Problem: The AC breaker in the IOA cabinet has exposed terminals
with AC voltage present on it.
Solution/Workaround: Cover is being EVALUATED and if possible
will be added to the product, for the short term I recommend
taping over the terminals with electrical tape.
Addition Comments: None
Update: After review of the problem by Customer Service Safety
Organization it has been determined that this is not a safety
issue. No cover will be added as a result of this determination,
some small changes will be made to the documentation.
48 POWER Subsystem
DIGITAL INTERNAL USE ONLY
Date: 07-Dec-1990 Reference #'s: N/A
CSSE Contact: Charlie Kretz
DTN: 297-4948
Node: MRCSSE::KRETZ
Title: DEC POWER BUS Problems
Problem: Bad DEC POWER BUS Filters from Vendor
Solution/Workaround: Check wiring and replace parts if
necessary.
Addition Comments: For details read file:
MRCSSE::PUBLIC:DEC_PWR_BUS.TXT
Update: None
POWER Subsystem 49
DIGITAL INTERNAL USE ONLY
Date: 07-Dec-1990 Reference #'s: N/A
CSSE Contact: Charlie Kretz
DTN: 297-4948
Node: MRCSSE::KRETZ
Title: H7214 Uncoated Hybrid Problem
Problem: Uncoated Hybrid causes H7214 failures
Solution/Workaround: Replace H7214
Addition Comments: For details read file:
MRCSSE::PUBLIC:H7214_HYBRID.PROBLEM
Update: None
50 POWER Subsystem
DIGITAL INTERNAL USE ONLY
Date: 07-Dec-1990 Reference #'s: N/A
CSSE Contact: Charlie Kretz
DTN: 297-4948
Node: MRCSSE::KRETZ
Title: Show Environmental displays wrong AIR FLOW sensors
Problem: The SHOW ENVIRONMENT display Utility displays the wrong
sensor number.
Solution/Workaround: Use the ERF output and the Power Subsystem
Technical manual, they have the correct information.
Addition Comments: Problem will be resolved in a future Console
Code Update.
Update: None
POWER Subsystem 51
DIGITAL INTERNAL USE ONLY
Date: 07-Dec-1990 Reference #'s: N/A
CSSE Contact: Charlie Kretz
DTN: 297-4948
Node: MRCSSE::KRETZ
Title: ERF OCP Switch Exception decoded incorrectly
Problem: ERF Decode the SWITCH register incorrectly, basically
the switch position is the one not reported.
CURRENT OUTPUT OUTPUT SHOULD BE
-------------- ----------------
OLD STATE OLD STATE
SW #1 - LOCAL DISABLED SW #1 - REMOTE DISABLED
SW #1 - LOCAL SW #2 - BOOT
SW #1 - REMOTE
SW #2 - RESTART/BOOT
SW #2 - RESTART/HALT
SW #2 - HALT
NEW STATE NEW STATE
SW #1 - LOCAL DISABLED SW #1 - REMOTE
SW #1 - LOCAL SW #2 - BOOT
SW #1 - REMOTE DISABLED
SW #2 - RESTART/BOOT
SW #2 - RESTART/HALT
SW #2 - HALT
Solution/Workaround: None
52 POWER Subsystem
Addition Comments: Will be corrected in a future update to ERF
Update: None
POWER Subsystem 53
DIGITAL INTERNAL USE ONLY
Date: 07-Dec-1990 Reference #'s: N/A
CSSE Contact: Charlie Kretz
DTN: 297-4948
Node: MRCSSE::KRETZ
Title: Syndrome code 3091G.000.003 for PCS ELE entries
Problem: An old version of EWKCF.BCM can cause syndrome code
3091G.000.003
Solution/Workaround: MRCSSE::PUBLIC:EWKCF.BCM (REV 1.1(22))
Copy the latest BCM file from MRCSSE::PUBLIC:EWKCF.BCM on our
system. This file goes on the console disk in the [SYSMAINT]
directory.
Addition Comments: None
Update: EWKCF.BCM has been updated to REV 1.2(23)
54 POWER Subsystem
DIGITAL INTERNAL USE ONLY
Date: 07-Dec-1990 Reference #'s: N/A
CSSE Contact: Charlie Kretz
DTN: 297-4948
Node: MRCSSE::KRETZ
Title: Lost OCP Codes
Problem: Some Service personal have written command procedures
to constantly write the OCP display, and at least two separate
problems have been seen. One problem was caused when the program
was running as a batch job and the log file filled the disk and
the console could not be rebooted. The other was a lost OCP code
because the program running over wrote the "REAL" OCP code after
it was written by the PCS subsystem.
Solution/Workaround: The running of such a program has no real
useful purpose and CSSE recommends that it not be done. If we
continue to see the number of problems grow we will have the
ability for the SPU user to write the OCP Display removed from
the system. If you really want to display a three character add
it to the end of [sysexe]power.cmd command file, don't write a
program to constantly scroll the display.
Addition Comments: None
Update: None
POWER Subsystem 55
DIGITAL INTERNAL USE ONLY
Date: 07-Dec-1990 Reference #'s: N/A
CSSE Contact: Charlie Kretz
DTN: 297-4948
Node: MRCSSE::KRETZ
Title: SDU shows NON-Existent power
Problem: SDU Displays 2 XMI card cages in the first IO cabinet
and a second IO cabinet on a model 210 even though they don't
exist. The second cabinet display also shows some BIAS failures,
which can be very confusing.
Solution/Workaround: None
Addition Comments: This problem will be correct in some future
release of SDU
Update: None
56 POWER Subsystem
DIGITAL INTERNAL USE ONLY
Date: 07-Dec-1990 Reference #'s: N/A
CSSE Contact: Charlie Kretz
DTN: 297-4948
Node: MRCSSE::KRETZ
Title: Model 400 OCP Codes not Documented
Problem: The early release of the Power Subsystem documents only
supported the model 210 system.
Solution/Workaround: A copy of the complete set of OCP codes is
available in the PUBLIC area on our system.
MRCSSE::PUBLIC:OCP_CODES.PS
MRCSSE::PUBLIC:OCP_CODES.TXT
Addition Comments: None
Update: None
POWER Subsystem 57
DIGITAL INTERNAL USE ONLY
Date: 07-Dec-1990 Reference #'s: N/A
CSSE Contact: Charlie Kretz
DTN: 297-4948
Node: MRCSSE::KRETZ
Title: Model 210 Troubleshooting Flows not Documented
Problem: Documents were released before the availability of the
troubleshooting flows.
Solution/Workaround: A copy of the model 210 flows is available
in the PUBLIC area on our system.
MRCSSE::PUBLIC:210_PWR_FLOWS.PS
Addition Comments: None
Update: None
58 POWER Subsystem
CHAPTER 5
SPU SUBSYSTEM
SPU Subsystem 59
DIGITAL INTERNAL USE ONLY
Date: 12-Dec-1990 Reference #'s: N/A
CSSE Contact: Butch Leitz
DTN: 297-4257
Node: MRCSSE::LEITZ
Title: Sr. Hardware Engineer
Problem:
BL 12.0 SET CLOCK bug in muli-CPU environments
Typing console command: >>> SET CLOCK/SCU/CPU:ALL OFF will
not allow you to access registers with examine or deposits
afterwards. An error message is displayed saying that system
clocks are still running. A SHOW CLOCK commands displays clocks
as STOPped.
Solution/Workaround:
None. Being investigated by SPU engineering.
Addition Comments:
Engineering has been notified and this has been QAR'd.
Update:
60 SPU Subsystem
DIGITAL INTERNAL USE ONLY
Date: 12-Dec-1990 Reference #'s: N/A
CSSE Contact: Butch Leitz
DTN: 297-4257
Node: MRCSSE::LEITZ
Title: Sr. Hardware Engineer
Problem:
BL 12.0 Bug found in SJADRIVER that in some instances keeps
error log entries created on SPU from being sent up to VMS.
Solution/Workaround:
Make sure that error logs on both the SPU and VMS are checked
when examining failures.
Addition Comments:
Engineering has been notified and this has been QAR'd.
Update:
SPU Subsystem 61
DIGITAL INTERNAL USE ONLY
Date: 12-Dec-1990 Reference #'s: N/A
CSSE Contact: Butch Leitz
DTN: 297-4257
Node: MRCSSE::LEITZ
Title: Sr. Hardware Engineer
Problem:
SHOW CLOCK displays CPU 2 clock ON with 9420
Performing the console command SHOW CLOCK results in a display
of CPU2 clock ON along with CPU0 and CPU1. This is observed on
a 9420 dual cpu system when the system is running VMS with both
CPUs on, and the operator does a CTRL-P out of VMS followed by a
SHOW CLOCK at the console prompt. There is no CPU2 installed in
system.
The problem was first noticed using console software v10.3 and
it still occurs with v12.0.
Solution/Workaround:
None. Being worked by engineering.
Addition Comments:
Engineering has been notified and this has been QAR'd.
Update:
62 SPU Subsystem
DIGITAL INTERNAL USE ONLY
Date: 12-Dec-1990 Reference #'s: N/A
CSSE Contact: Butch Leitz
DTN: 297-4257
Node: MRCSSE::LEITZ
Title: Sr. Hardware Engineer
Notice:
VAX 9000 SPU Base Level 12.0 software kits supporting B4 or
B5 hardware revisions can be built at the branch level using
savesets release by CSSE acorss Digital's Ethernet.
Read MRCSSE::AQ$SPU:BL12_NET_BUILD_HELP.TXT for complete details
on how to build these kits.
SPU Subsystem 63
DIGITAL INTERNAL USE ONLY
Date: 12-Dec-1990 Reference #'s: N/A
CSSE Contact: Butch Leitz
DTN: 297-4257
Node: MRCSSE::LEITZ
Title: Sr. Hardware Engineer
Notice:
From: MRCSSE::LEITZ "butch leitz, 297-4257, mro2-3/2c, HPS CSSE" 5-DEC-1990 16:11:11.86
To: @PUBLIC:9K_TECH
CC: LEITZ
Subj: Use of COPY vs BACKUP on SPU
+---------------------------+ TM
! ! ! ! ! ! ! ! i n t e r o f f i c e
! d ! i ! g ! i ! t ! a ! l !
! ! ! ! ! ! ! ! m e m o r a n d u m
+---------------------------+
Date: 12/5/90
To: (9k dist) From: Butch Leitz
Dept: HPS/C CSSE MEG
DTN: 297-4257
LOC/MAIL STOP: MRO2-3/5E, Pole 2C
Email: HPSMEG::LEITZ
cc:
64 SPU Subsystem
Subject: Use of BACKUP on VAX 9000 SPU
Because of more and more use of TK50s in the field I thought I'd make
sure everybody understood a couple fundamental things about BACKUP under
the SPU as opposed to BACKUP under VMS. Also, a word about the use of the
COPY command under the SPU when reading/writing TK50s:
1) SPU BACKUP AND VMS BACKUP ARE NOT COMPATIBLE.
To build or read an SPU BACKUP compatible saveset, you have to
use the BACKUPVMS.EXE (and BACKUPVMS.CLD) file(s) in MRCSSE's
public area:
MRCSSE::NONAME:[PUBLIC]BACKUPVMS.CLD
MRCSSE::NONAME:[PUBLIC]BACKUPVMS.EXE
BACKUPVMS.* will allow files created with BACKUP on the SPU to be
read (restored) under VMS. BACKUPVMS will also allow you to
create savesets under VMS to be read by BACKUP on the SPU. When
you use BACKUPVMS.EXE under VMS, the command defined by
BACKUPVMS.CLD is TBACKUP so you won't be confused with the VMS
BACKUP command.
Read MRCSSE::PUBLIC:BACKUP_HELP.TXT for more information on how
to use these commands.
2) USE BACKUP ON THE SPU FOR -ALL- TK50 ACCESS.
When on the SPU, you may (and -should-) use SPU BACKUP whenever
you are are reading or writing files to the TK50.
BACKUP on the SPU, unlike BACKUP under VMS, does not require
files to be in save sets on the tape. And BACKUP does data
tranfers to and from the tape using block-mode transfers - which
the COPY command does not do. Consequently you end up burning
alot more time using the COPY command than if you use BACKUP -as-
a "copy" command.
For example, (A) and (B) below are equivalent.
But (B) will finish faster.
(A)
SPU Subsystem 65
>>> copy mua7:[]foobar.bcm dua50:[sysmaint]foobar.bcm
(B)
>>> backup/log mua7:[]foobar.bcm dua50:[sysmaint]foobar.bcm
66 SPU Subsystem
CHAPTER 6
MEMORY SUBSYSTEM:
MEMORY Subsystem: 67
DIGITAL INTERNAL USE ONLY
Date: 12-Dec-1990 Reference #'s: N/A
CSSE Contact: Mohammed Riaz
DTN: 297-2219
Node: MRCSSE::Riaz
Title: Hardware Engineer
Problem:
N/A.
Solution/Workaround:
Addition Comments:
Update:
68 MEMORY Subsystem:
CHAPTER 7
VAX 9000 INSTALLATION
VAX 9000 INSTALLATION 69
DIGITAL INTERNAL USE ONLY
Date: 13-Dec-1990 Reference #'s: N/A
CSSE Contact: Alice Jacobson
DTN: 297-2926
Node: MRCSSE::JACOBSON
TITLE: DOCUMENTATION
Problem: There is an error in the VAX 9000 Model 210
Installation Guide, in section 4.3.8 (Blocking Diode cable).
The figure (4-20) shows the cable being attached to the minus
(-) lead of the blocking diode. This marking is incorrect.
Solution/workaround: It should be connected to the positive
(+) lead of the blocking diode. The cable is currently marked
"BLOCKING DIODE (-)", this will be changed in future systems to
"BLOCKING DIODE (+)".
Problem: No Read-Me-First label was found.
Solution/Workaround: The VAX 9000 Model 200 Installation Guide,
page 2-2 states:
"Remove the shipping/accessory list from the customer
services box and check the contents of all boxes
against the shipping list. THIS BOX IS IDENTIFIED BY
THE INTERNATIONAL SYMBOL-A BLUE CIRCLE CONTAINING THE
LETTER I."
Problem: Minimum Document Revisions that should be used during
installation.
Solution/workaround:
70 VAX 9000 INSTALLATION
Install Guide 9200- August 1990
Site Prep Guide - July 1990, First Edition
Install Guide 9410/9420 - draft
VAX 9000 INSTALLATION 71
DIGITAL INTERNAL USE ONLY
Date: 13-Dec-1990 Reference #'s: N/A
CSSE Contact: Alice Jacobson
DTN: 297-2926
Node: MRCSSE::JACOBSON
TITLE: TOOLS AND USAGE
PROBLEM: Uncalibrated Torque Tool P/N: 29-28143-01.A01
We have just found indications that there is an uncalibrated
torque device in the VAX 9000 CONNECTOR TORQUE TOOLS KIT (P/N:
29-28143-01.A01).
KIT AFFECTED:
Three of three kits shipped to MRO were received with the Z-FLEX
& MEM/FLEX Torque Tool (P/N: 29-28143-01.A01) uncalibrated. This
tool is essential to the installation of the VAX 9000 Z-FLEX
Cables.
POSSIBLE IMPACT:
We are presently unsure as to the possible symptoms/problems
that could result, but the 20 in-lb value that the uncalibrated
tools are coming in at should establish adequate connector
contact. The addition 7 in-lbs provides long term vibration
resistance for the connection.
72 VAX 9000 INSTALLATION
PREVENTIVE MAINTENANCE:
Once a correctly calibrated tool is available, all existing
VAX 9000 Installations should be re-visited and all Z-FLEX
connections be re-torqued. We DO NOT recommend separating the
connection, merely tighten the existing connection with the
calibrated tool. This should ensure a robust connection.
Solution/Workaround: The best way to determine if the tool
you received is properly calibrated is to look at the butt of
the red handle. The number 27 should be stamped next to the
"calibration at" label. If no value is stamped, your tool is
likely not calibrated (we have found them at 20 in-lbs).
The quickest way to get this tool calibrated involves directly
contacting a local machine shop that calibrates torque devices.
It should only take a few minutes to actually calibrate and
stamp/mark the tool. The expense will vary between calibration
shops, but should not cost more than $10-20 dollars (US).
TORQUE SETTING: 27 in-lbs or 31 cm-Kg
ALTERNATE METHOD: Fast ship (Ex. Federal Express etc) your
Z-Flex Torque tool to:
KAUFMAN COMPANY, INC.
110 Second Street
Cambridge, MA 02141
Attn: Mr. Norman Kaufman
Enclose with the tool a memo listing the address to return
calibrated tool to. Kaufman Co. will fast ship the corrected
tool to you.
Note: The current Z-Flex Torque Tool being shipped has a red
anodized aluminum handle. Some (not all) of the replacement
tools may have blue handles. Refer to the calibration stamp for
setting varification
Problem: There have been questions concerning the cleaning
technique or the Z-flex connectors
Solution/workaround: When cleaning the connector on the Z-flex
cable use caution so that the cleaning sticks are not shredded
VAX 9000 INSTALLATION 73
during cleaning. Use the flat portion of the cleaning stick to
wipe across the connector away from the cable. If the handle on
the cleaning stick bends, you are applying too much pressure.
Problem: There have been questions on how to properly tighten
clock cable connectors.
Solution/workaround: Proper techinique must be used when
tightening clock cable to prevent loosening of cable. Use
two hands to connect the clock cables. Hold the cable with
one hand (about three inches from connector). Feed the cable
straight into the jack and release pressure on cable. Use 8
in-pound torque tool (PN 29-27973-01) to tighten connectors.
While torqueing hte clock connectors, prevent the cable from
twisting inside the housing b wiggling the cable. Twisting could
cause the SMA connector to loosen.
74 VAX 9000 INSTALLATION
CHAPTER 8
VMS SUBSYSTEM:
8.1 VMS Subsystem:
8.1.1 Minimum Revisions:
Version 5.4
8.1.2 Software:
1. Bug:
=======================================================
Note 609.6 FORTRAN RTL images problem on V5 6 of 6
QUARK::LIONEL
"Free advice is worth every cent" 21-SEP-1990
-< STARS article >-
-------------------------------------------------------
[This is a corrected version of an earlier posting.]
Attached is a STARS article that will soon be made
available to customers. It describes a problem with
linking FORTRAN programs on newly installed "from
scratch" VMS V5.4 systems. Please distribute this
information to any affected users and customers.
VMS Subsystem: 75
This problem will be "fixed" in the next maintenance
update of VMS, but the solution given in the article
can be applied immediately without interfering with
the later VMS fix.
Steve
*****************************************************
TITLE: LINK-I-DATMISMCH on FORTRAN RTL After
Installing VMS V5.4
COMPONENT: Linker Utilit OP/SYS: VMS, Version 5.4
LAST TECHNICAL REVIEW: 20-SEP-1990
SOURCE: Customer Support Center/Colorado Springs USA
\ Information in this article was extracted from the
\ VMS_FIELD_TESTS conference, topic 609, entered by
\ Steve Lionel.
SYMPTOM:
After doing an initial installation of VMS V5.4, the
FORRTL and FORRTL2 shareable images are not
consistent with what was inserted into the
IMAGELIB.OLB on the kit.
Running the Installation Verification Procedure (IVP)
after installing FORTRAN or VAX FORTRAN-HPO will
produce the following messages:
%LINK-I-DATMISMCH, creation date of 16-JUL-1990 09:47 in
shareable image SYS$COMMON:[SYSLIB]FORRTL.EXE;1
differs from date of 19-JUN-1990 04:43 in shareable
image library SYS$COMMON:[SYSLIB]IMAGELIB.OLB;1
%LINK-I-DATMISMCH, creation date of 16-JUL-1990 09:48 in
shareable image SYS$COMMON:[SYSLIB]FORRTL2.EXE;1
differs from date of 19-JUN-1990 04:44 in shareable
image library SYS$COMMON:[SYSLIB]IMAGELIB.OLB;1
76 VMS Subsystem:
Linking any FORTRAN program will produce these
messages. Programs written in other languages may
also include references to the FORTRAN RTL, and
linking those programs will produce the messages as
well.
ANALYSIS:
This behavior only occurs after an initial
installation of VMS V5.4. It does not occur when
upgrading to VMS V5.4.
These are informational diagnostic messages, and does
not effect the image being linked.
WORKAROUND:
Replace FORRTL.EXE and FORRTL2.EXE in the
IMAGELIB.OLB with the command:
$ LIBRARY/SHARE/REPLACE SYS$LIBRARY:IMAGELIB SYS$LIBRARY:FORRTL,FORRTL2
NOTE:
If another process has the library open (for example,
during a link operation), you may see errors
indicating that the library file is in use. Wait
until this other process is through linking, and
retry the replace operation.
DIGITAL RESPONSE:
This issue has been reported to VMS Engineering.
\\ LINK VER_5.4_VMS
\\ FT
VMS Subsystem: 77
|
| 78.101 | Tools list | KERNEL::WRIGHTON | odd numbered release = bug insert | Tue Dec 18 1990 10:34 | 1695 |
|
VAX 9000 Customer Service Tools
& Test Equipment List
Revision/Update Information: December 14, 1990
DIGITAL CONFIDENTIAL
The following is a listing of all known tools
required to service all of the VAX 9000 subsystems.
Author :
o Tom Daley
Organization:
o ISBS / CSSE
Digital Equipment Corporation
ii
________________________
Aug 1989
__________
The information in this document is subject to change without
notice and should not be construed as a commitment by Digital
Equipment Corporation. Digital Equipment Corporation assumes
no responsibility for any errors that may appear in this
document.
The software described in this document is furnished under a
license and may be used or copied only in accordance with the
terms of such license.
No responsibility is assumed for the use or reliability
of software on equipment that is not supplied by Digital
Equipment Corporation or its affiliated companies.
__________
Copyright �1989 by Digital Equipment Corporation
All Rights Reserved.
Printed in U.S.A.
__________
The postpaid READER'S COMMENTS form on the last page of this
document requests the user's critical evaluation to assist in
preparing future documentation.
The following are trademarks of Digital Equipment Corpora-
tion:
DEC DIBOL UNIBUS
DEC/CMS EduSystem VAX
DEC/MMS IAS VAXcluster
DECnet MASSBUS VMS
DECsystem-10 PDP VT
DECSYSTEM-20 PDT
DECUS RSTS
DECwriter RSX DIGITAL
This document was prepared using VAX DOCUMENT, Version 1.2
Contents________________________________________________________
Chapter_1__INTRODUCTION_________________________________________
Chapter_2__EXISTING_SYSTEM_ENGINEER_TOOL_KIT_CONTENTS___________
Chapter_3__VAX_9000_SPECIFIC_TOOLS_and_TEST_EQUIPMENT___________
3.1 VAX 9000 CONNECTOR TORQUE TOOLS KIT *.................3-1
3.2 COMBINATION WRENCH SET PACKAGE.......................3-4
3.3 3/8" DRIVE RATCHET and SOCKET SET....................3-5
3.4 3/8" DRIVE TORQUE WRENCH.............................3-6
3.5 9/16" THIN HEAD WRENCH...............................3-7
3.6 9/16" DEEP WELL, 3/8" DRIVE, SOCKET..................3-8
3.7 CLOCK CABLE TORQUE TOOL..............................3-9
3.8 VAXBI/XMI TOOL KIT..................................3-10
3.9 BI/XMI CARDCAGE CLEANING KIT.........................3-12
3.10 TK50/TK70/TZ30 HEAD CLEANING KIT.....................3-13
3.11 FUSE PULLER.........................................3-15
3.12 150 PIN LOGIC ANALYZER PROBE KIT.....................3-16
3.13 LOGIC ANALYZER......................................3-17
3.14 UNIVERSAL LIFT DEVICE...............................3-20
3.15 DRANETZ MONITOR CABLE ADAPTOR........................3-23
3.16 POWER SERVICING and SAFETY TOOL KIT.................3-24
iii
Tables__________________________________________________________
3-1 VAX 9000 Connector Torque Tools Kit:...........3-1
3-2 Combo. Wrench Set Price List:..................3-4
3-3 3/8" Drive Ratchet and Socket Set Price List:..3-5
3-4 3/8" Drive Torque Wrench Price List:...........3-6
3-5 9/16" Thin Head Wrench Price List:.............3-7
3-6 9/16" Deep Well Socket Price List:.............3-8
3-7 Clock Cable Torque Tool Price List:............3-9
3-8 VAXBI/XMI Tool Kit Price List:................3-10
3-9 BI/XMI Cardcage Cleaning Kit Price List:......3-12
3-10 TK50/TK70/TZ30 Head Cleaning Kit Price List:..3-13
3-11 Fuse Puller Price List:.......................3-15
3-12 CAMM Price List:..............................3-16
3-13 Logic Analyzer Price List:....................3-17
3-14 Lifting Device Price List:....................3-20
3-15 Dranetz Monitor Cable Adaptor:................3-23
iv
Chapter__1______________________________________________________
INTRODUCTION
The purpose of this tools document is to provide a complete
listing and description of those tools that will be required
to service the VAX 9000 Family of systems above and beyond
the standard CS Tool Kit. In some cases, tools described
are already available. They are listed because the VAX
9000 needs them also. Some of the tools described would be
more economical to rent and in some cases may be already
available through CS Tools. Those tools that fit the previous
descriptions will be annotated as such.
INTRODUCTION 1-1
Chapter__2______________________________________________________
EXISTING SYSTEM ENGINEER TOOL KIT CONTENTS
System Engineer Tool Kit (29-27339-01)
o Tools:
1. Alignment Tool - screwdriver - screwdriver/hex
2. Cleaning Brush
3. Burnisher - contact, fine finish
4. Case, Tool, w/pallets
5. Pop Fastener
6. Feeler Gauge Set
7. Plastic Flashlight
8. Hammer, two tips
9. Knife, retractable w/clip
10.Magnet, extendible, 18"
11.Mirror, 7/8" dia plastic
12.Multimeter, 3 1/2 digit
13.Oiler, pocket
14.Parts Box
15.Pliers/Cutters/Strippers
- cutters, diag. 5"
- plier,needle nose 4"
- Snap ring
EXISTING SYSTEM ENGINEER TOOL KIT CONTENTS 2-1
- vise grip 6"
- stripper, multipurpose
16.Screwdrivers
- Offset ratchet(PHandSL)
- Pocket clip (PHandSL)
- Starter (PHandSL)
- Stubby (PH)
- Stubby (SL)
17.Screwdriver blades
- Ballpoint hex (1/16", 5/64", 3/32", 7/64", 1/8",
9/64", 5/32", 3/16")
- Extension 7"
- Handle (standard and junior)
- Nutdriver (3/16", 7/32", 1/4", 9/32", 5/16", 11/32",
3/8", 7/16", 1/2")
- Phillips (0, 1, 2)
- slotted (1/8", 3/16", 5/16")
18.Socket Set, Mini, 1/4" drive
19.Spring hook, push/pull
20.Tape, electrical
21.Wire wrap accessories - hand wrap/unwrap tool, wire
30awg 50'
22.Wrenches
- Allen (7 pc. set)
- Crescent (8")
- Mini combo
2-2 EXISTING SYSTEM ENGINEER TOOL KIT CONTENTS
Chapter__3______________________________________________________
VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT
3.1 VAX 9000 CONNECTOR TORQUE TOOLS KIT *
Table_3-1:__VAX_9000_Connector_Torque_Tools_Kit:________________
Vendor/Part
DEC_P/N___________Components________________Cost_($)__#_________
29-28230-01 Complete Connector $510.00
Torque Tool Kit (e)
Individual Components
29-27897-01.A01 MCU 40" lb (46 cm. Kg.) $75.00 Seekonk/BT-
Torque Tool 1-BO-40
29-27895-01.A01 1/4" Drive Ratchet $32.00 Snap-
Adptr. On/TM67A
29-27892-01.A01 2 ea. TORX 20 Bits, 2 $6.00 Mountz/120-
3/4" T20
29-27896-01.A01 1/4" Drive Bit Holder $2.00 Apex/825
29-28006-01.A01 MCU Removal Tool $250.00 Kaufman/DPI-
2500
VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT 3-1
Table_3-1_(Cont.):__VAX_9000_Connector_Torque_Tools_Kit:________
Vendor/Part
DEC_P/N___________Components________________Cost_($)__#_________
29-28007-01.A01 2 ea. MCU Locating Pins $25.00 Kaufman/DPI-
2501
29-28089-01.A01 T20 Screwdriver $10.45 Snap-
On/SDTX420
29-28143-01.A01 Z-FLEX & MEM/FLEX Torque $80 .00 Mountz
Tool 27" lb (31 cm. Kg) Tools/02-
0075
29-28267-01.A01 25 ea. CHEMSWAB Cleaning $25.00 Chemtronics/CS25
Sticks
29-27898-01.A01 Carrying Case $25.00 Kaufman/BTA706
____________________________________________----________________
o VAX 9000 FRU THAT REQUIRES THIS KIT:
1. All MCUs in the CPU and SCU cabinets
2. Memory Flex Connectors in SCU cabinet
3. All Z-Flex Connectors in SCU and CPU cabinets
o FUNCTION (of tool):
1. MCU & MEM/FLEX 40" lb (46 cm. Kg.) Torque Tool, Ratchet
Adapter,Bit Holder and Bit-Used to torque MCU to
CPU/SCU Planars. (40+/-3 in. lbs.) and the Memory Flex
Connectors to the SCU Planar.
3-2 VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT
2. MCU Removal Tool-Attaches to MCU prior to removal.
Extracts MCU from the its planar site while loosening
the MCU mounting screws. Also functions as a "handle"
for the MCU during removal and installation.
3. 2 ea. MCU Locating Pins - Used to maintain proper MCU
alignment during MCU Removal and Replacement
4. T20 Screwdriver-Used to loosen MCU fasteners
5. Z-Flex Torque Tool-Used to torque Z-Flex Connector to
the SCU and CPU Planars. (27 +/- 1 in lbs)
6. 24 ea. Localized Cleaning Sticks-Used to locally clean
the MCU site, on the backplane, prior to MCU insertion.
7. Carrying Case-Will be used to contain all components of
the MCU Tool Kit
o LEVEL OF DISTRIBUTION:
- Branch Level
VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT 3-3
3.2 COMBINATION WRENCH SET PACKAGE
Table_3-2:__Combo._Wrench_Set_Price_List:_______________________
Vendor/Part
DEC_P/N___________Components________________Cost_($)__#_________
29-27899-01.A01 Wrenches, 1/4"- $65.00 S-K Hand
7/8"(w/pouch) Tool
Inc./1713
----
__________________Total_____________________$65.00______________
o VAX 9000 FRU THAT REQUIRES THIS TOOL:
1. SCU/CPU Power Dividers
2. SCU/CPU Planars
3. Assorted other cabinet fasteners
o FUNCTION (of tool):
1. Remove fasteners that secure a variety of FRUs in VAX
9000 cabinet subassemblies.
o COMPONENT PARTS:
o Combination (box end-open end) wrench sizes;1/4",5/16",
3/8", 7/16", 1/2", 9/16", 5/8", 11/16", 3/4", 13/16",
7/8", 15/16", vinyl roll pouch
o LEVEL OF DISTRIBUTION:
- VAX 9000 Trained Customer Service Engineer
3-4 VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT
3.3 3/8" DRIVE RATCHET and SOCKET SET
Table_3-3:__3/8"_Drive_Ratchet_and_Socket_Set_Price_List:_______
Vendor/Part
DEC_P/N___________Components________________Cost_($)__#_________
29-27443-01.A01 3/8" DRIVE RATCHET and $21.50 Time
SOCKET SET Motion
Tools/TMT-
91-220A
---
__________________Total_____________________$21.50______________
o VAX 9000 FRU THAT REQUIRES THIS KIT:
1. SCU and CPU Planars mounting bolts
2. SCU/CPU Buss bars connections
3. Power Regulator output connectors
4. Variety of fasteners in the CPU,SCU,XMI and UPC cabs
that require more torque than a 1/4" drive ratchet can
safely provide.
o FUNCTION (of tool):
1. Loosen and tighten a variety of fasteners.
o COMPONENT PARTS:
o Socket sizes;3/8", 7/16", 1/2", 9/16", 5/8", 11/16",
3/4", 7/8", Reversible ratchet handle, 3" extension,
fitted molded plastic case
o LEVEL OF DISTRIBUTION:
- VAX 9000 Trained Customer Service Engineer
VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT 3-5
3.4 3/8" DRIVE TORQUE WRENCH
Table_3-4:__3/8"_Drive_Torque_Wrench_Price_List:________________
Vendor/Part
DEC_P/N___________Components________________Cost_($)__#_________
29-19734-00.A01 3/8" Drive Ratchet $92.19 J.H.
Torque Wrench, 10-250 Williams/BTW-
In. Lbs. (12-288 cm. 1RC
Kg.)
---
__________________Total_____________________$92.19______________
o VAX 9000 FRU THAT REQUIRES THIS KIT:
1. H7380 Output power tabs,
2. Planar mounting bolts,
3. Bussbar connections
o FUNCTION (of tool):
1. Properly tighten torque sensitive connections.
o LEVEL OF DISTRIBUTION:
- VAX 9000 Trained Customer Service Engineer
3-6 VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT
3.5 9/16" THIN HEAD WRENCH
Table_3-5:__9/16"_Thin_Head_Wrench_Price_List:__________________
Vendor/Part
DEC_P/N___________Components________________Cost_($)__#_________
29-27444-01.A01 9/16" Thin Wrench $12.60 Snap-On /
LTA1618
----
__________________Total_____________________$12.60______________
o VAX 9000 FRU THAT REQUIRES THIS KIT:
1. All VAX 9000 Cabinet leveling pads
o FUNCTION (of tool):
1. The hex portion of the leveler pads cannot be accessed
with a conventional open end wrench when they are in
their full up position. This thin head (tappet) wrench
will allow access to this hex head.
o LEVEL OF DISTRIBUTION:
- VAX 9000 Install/De-install Team
VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT 3-7
3.6 9/16" DEEP WELL, 3/8" DRIVE, SOCKET
Table_3-6:__9/16"_Deep_Well_Socket_Price_List:__________________
Vendor/Part
DEC_P/N___________Components________________Cost_($)__#_________
29-28499.A01 9/16" Deep Well Socket $8.20 Snap-On /
SFS181
----
__________________Total_____________________$8.20_______________
o VAX 9000 FRU THAT REQUIRES THIS KIT:
1. DC input lugs on PIP
o FUNCTION (of tool):
1. The DC input (+/-140 VDC) lug lengths on the PIP
require a deep well socket to reach the lug nuts.
o LEVEL OF DISTRIBUTION:
- VAX 9000 Install/De-install Team
3-8 VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT
3.7 CLOCK CABLE TORQUE TOOL
Table_3-7:__Clock_Cable_Torque_Tool_Price_List:_________________
Vendor/Part
DEC_P/N___________Components________________Cost_($)__#_________
29-27973-01.B01 Clock Cable Torque Tool $85.00 Snap-
On/QTSP-
128CTT
----
__________________Total_____________________$85.00______________
o VAX 9000 FRU THAT REQUIRES THIS KIT:
1. All SMA Connectors (clock coax cables)
o FUNCTION (of tool):
1. This tool will be needed to torque clock cable
connections to the MCM, bulkhead and power dividers.
Rating: 128" oz. (8 in. lbs./9.2 cm. Kg.)
2. This tool is custom made by Snap-On. Point of Contact:
o Walter Parks,Snap-On Tool Co., 192 South Street,
Hopkinton, MA, 01748, Tel: (508) 429-7325
3. LEVEL OF DISTRIBUTION:
- Branch Level
VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT 3-9
3.8 VAXBI/XMI TOOL KIT
CURRENTLY AVAIL. THROUGH CS TOOLS
Table_3-8:__VAXBI/XMI_Tool_Kit_Price_List:______________________
Vendor/Part
DEC_P/N___________Components________________Cost_($)__#_________
29-17381-00 Screwdriver, Torque $48.54
(1-36 " lb./1-42 cm.
Kg.)
29-25609-00 Screwdriver, Offset PH $3.23
and SL
29-25610-00 Drill Bit, Slotted $.66
w/notch
29-25611-00 Drill Bit, Phillips #1 $.51
29-25612-00 Extension, 6" long $4.12
29-25613-00 Adapter, hex $3.07
----
A2-M1094-10 Complete VAXBI/XMI $60.13
__________________Special_Tool_Kit______________________________
o VAX 9000 FRU THAT REQUIRES THIS KIT:
1. SPU (Console/BI Cardcage)
2. XMI Cardcage
o FUNCTION (of tool):
1. This kit contains all the specialized hand tools needed
to properly service BI and XMI cardcages.
3-10 VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT
o LEVEL OF DISTRIBUTION:
- Branch Level
VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT 3-11
3.9 BI/XMI CARDCAGE CLEANING KIT
CURRENTLY AVAIL. THROUGH CS TOOLS
Table_3-9:__BI/XMI_Cardcage_Cleaning_Kit_Price_List:____________
Vendor/Part
DEC_P/N___________Components________________Cost_($)__#_________
12-26321-05 VAXBI Paddle Wipes (5 $31.25
Segment)
12-26321-06 VAXBI Paddle Wipes (4 $31.25
Segment)
47-00116-02 Cleaning Handle $7.60
49-01603-02 Gold Wipes $26.74
29-16141-00 Goggles $2.76
29-26403-00 Nitrile Gloves $17.85
----
A2-M1096-10 Complete BI/XMI Cardcage $64.65
__________________Cleaning_Kit__________________________________
o VAX 9000 FRU THAT REQUIRES THIS KIT:
1. ZIF connectors in the BI and XMI Cardcages
o FUNCTION (of tool):
1. Clean the ZIF connectors in the BI card cage
o LEVEL OF DISTRIBUTION:
- Branch Level
3-12 VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT
3.10 TK50/TK70/TZ30 HEAD CLEANING KIT
CURRENTLY AVAIL. THROUGH CS TOOLS
Table_3-10:__TK50/TK70/TZ30_Head_Cleaning_Kit_Price_List:_______
Vendor/Part
DEC_P/N___________Components________________Cost_($)__#_________
22-00436-01 TK50/TK70/TZ30 HEAD $11.00
CLEANING KIT
22-00436-02_______REFILL_KIT________________$12.00______________
o VAX 9000 FRU THAT REQUIRES THIS KIT:
1. TK50 Tape Drive (VAX 9000 Console)
o FUNCTION (of tool):
1. This head cleaning kit has been created to fix
Media related problems using the TK50-K and TK52-K
cartridges, such as:
- REPEATED UNCOVERABLE READ ERRORS
- DATA ERRORS
- FAILURE TO INITIALIZE OR MOUNT
- HARD READ/WRITE ERRORS DURING BACKUP OR COPY
OPERATIONS
2. Oxide and other elements are removed from the media
as the tape travels past the read / write head during
multiple read and write operations, associated with
backup / copy operations. This is sometimes commonly
known as a "dirty head", a term that is associated with
Products that use magnetic tape media.
3. Digital has created a TK/TZ Tape Drive Head Cleaning
Kit available through DECdirect.
VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT 3-13
4. Customer Services Engineers should be able to order
the Kits through SR17 using the above 22 class part
numbers. User instructions are located inside every
cleaning / refill kit package.
o KIT CONTENTS:
- 22-00436-01 CLEANING KIT
- 1 UNIVERSAL CARTRIDGE
- 10 CLEANING WANDS
- 10 ALCOHOL APPLICATORS
- 22-00436-02 REFILL KIT
- 20 CLEANING WANDS
- 20 ALCOHOL APPLICATORS
o LEVEL OF DISTRIBUTION:
- Branch Level
3-14 VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT
3.11 FUSE PULLER
Table_3-11:__Fuse_Puller_Price_List:____________________________
Vendor/Part
DEC_P/N___________Components________________Cost_($)__#_________
29-27445-01.A01 Fuse Puller $2.10 Snap-
On/FZ4A
----
__________________Total_____________________$2.10_______________
o VAX 9000 FRU THAT REQUIRES THIS KIT:
1. All power fuses.
o FUNCTION (of tool):
1. This tool will be used to pull the fuses used
throughout the VAX 9000 cabinets.
o LEVEL OF DISTRIBUTION:
- VAX 9000 Trained Engineer
VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT 3-15
3.12 150 PIN LOGIC ANALYZER PROBE KIT
[VAX 9000 Logic Analyzer Probe Card Kit alias the CAMM]
Table_3-12:__CAMM_Price_List:___________________________________
Vendor/Part
DEC_P/N___________Components________________Cost_($)__#_________
NOT ACCOMPLISHED CAMM
----
Total $2,500.00
____________________________________________(e)_________________
o SUGGESTED MANUFACTURER/PART NUMBER:
1. /
o VAX 9000 FRU THAT REQUIRES THIS KIT:
1. SCU and CPU Logic
o FUNCTION (of tool):
1. Allows connection to the CSSE connector on each CPU and
SCU Planar assy.
2. Will be used in conjunction with the H.P. Logic
Analyzer when available. The field will be notified
when this tool is completed and available.
o LEVEL OF DISTRIBUTION:
- Support Level
3-16 VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT
3.13 LOGIC ANALYZER
Table_3-13:__Logic_Analyzer_Price_List:_________________________
Vendor/Part
DEC_P/N___________Components________________Cost_($)__#_________
FC-10139-AC.A01 Complete Logic Analyzer $21,200.00Hewlet-
Kit Packard/16500A-
DEC
FC-10147-AC.A01 Log. Analysis Mainframe $6,600.00 Hewlet-
Packard/HP
16500A
FC-10148-AC.A01 16 chan. 1 GHz Master $7,200.00 Hewlet-
Card Packard/HP
16515A
FC-10149-AC.A01 16 chan. 1 GHz Expansion 6,300.00 Hewlet-
Card Packard/HP
16516A
---
Total $20,160.00
to pur-
____________________________________________chase_______________
This equipment can be rented through Hewlett-Packard Company.
They have a program called "HP Easyrent". The program offers
12 month or greater plans that charge 3.25% of the purchase
price of equipment valued at $10,000.00 or more. 65% of the
monthly payments can be put towards a final purchase. See
your local H-P Representative for more details.
VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT 3-17
ISBS CSSE is currently looking into the Tektronics PRISM 3000
Logic Analyser. It does not have as much channel capacity
as the H-P product, but it looks like it will handle about
90% of the typical tasks we would need accomplished by a
logic analyser. We have provide more details as they become
available.
o CSSE EVALUATION SAMPLE STATUS:
1. HPS CSSE will work directly with Hewlett Packard and
Tektronics
o SUGGESTED MANUFACTURER/PART NUMBER:
1. Complete Logic Analyzer Kit-16500A-DEC
2. Log. Analysis Mainframe-Hewlett Packard / HP 16500A
3. 16 chan. 1 GHz Master Card-Hewlett Packard / HP 16515A
4. 16 chan. 1 GHz Expansion Card-Hewlett Packard / HP
16516A
o VAX 9000 FRU THAT REQUIRES THIS KIT:
1. CPU and SCU Logic
o FUNCTION (of tool):
1. This tool will be used to debug system logic problems.
This will have to be used with the Logic Analyzer Probe
Card Kit(CAMM).
2. The performance needs dictated by the VAX 9000 Logic
combined with the portability needs of the field leave
this HP product as our only real option. A DAS 9200
was considered but is a lab type design that is much
to large to consider as a "travelable" piece of test
equipment.
o COMPONENT PARTS:
1. Complete package of the following: FC-10139-AC.A01
o Log. Analysis Mainframe
3-18 VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT
o 16 chan. 1 GHz Master Card
o 16 chan. 1 GHz Expansion Card
o LEVEL OF DISTRIBUTION:
- Support/Branch Level
VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT 3-19
3.14 UNIVERSAL LIFT DEVICE
Table_3-14:__Lifting_Device_Price_List:_________________________
DEC_P/N___________Components________________Cost________________
29-27561-01.A01 Complete Lift Device Kit $4,900.00
Individual Replacement
Components
29-28217-01.A01 Lifting Device Upright $980.00
29-28895-01.A01 Brakes, Left & Right $210.00
Assemblies
29-28135-01.A01 Lifting Device Base $1,449.00
29-28508-01.A01 CPU/SCU Brackets (Left), $1,100.00
VAX 9000 Lift Device
29-28509-01.A01 CPU/SCU Brackets $1,100.00
(Right), VAX 9000 Lift
Device
29-28218-01.A01 Quick Release/Lock Pins $119.00
29-28896-01.A01 Hinge Release Pins $210.00
(Retractable Plungers)
29-28897-01.A01 Gas Spring $210.00
3-20 VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT
Table_3-14_(Cont.):__Lifting_Device_Price_List:_________________
DEC_P/N___________Components________________Cost________________
29-28898-01.A01 Collet Lock (Thumbscrew $126.00
Assy)
29-28154-01.A01 CPU Gage Bars (2 ea.) $39.20
29-28155-01.A01 SPU Gage Bars (2 ea.) $39.20
29-28231-01.A01 Extended Planar $20.00
Capscrews (3 ea.)
29-28486-01.A01 Lift Devices Accessories $12.80
Case
29-28136-01.A01 Fork Arms $490.00
29-28403-01.A01 Transit Caster $10.00
________________________________________________________________
o VAX 9000 FRU THAT REQUIRES THIS KIT:
1. CPU and SCU Planars (Power Dividers as well)
2. UPC TRANSFORMER
3. H7390 DC POWER SUPPLY
4. H7390 CAPACITOR BANK
5. MEMORY Cardcage Assembly
o FUNCTION (of tool):
1. This lifter has been designed to accommodate the
lifting requirements of a variety FRUs in the VAX
9000 family of products. With the Lift forks, this
lifter can satisfy the lifting needs of other products.
VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT 3-21
Should a future product require a "custom" bracket,
this bracket can be designed to clip onto the Lift
Device Base. This lifter was developed in an effort to
eliminate the need to populate the field with numerous
"unique" function lifters. It will be rated at 400 lb
max lift capacity.
o LEVEL OF DISTRIBUTION:
- Branch Level
3-22 VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT
3.15 DRANETZ MONITOR CABLE ADAPTOR
Table_3-15:__Dranetz_Monitor_Cable_Adaptor:_____________________
DEC_P/N___________Components________________Cost_($)____________
17-02664-01 Dranetz Monitor Cable $200.00
Adaptor
---
__________________Total_____________________$200.00_____________
o VAX 9000 FRU THAT REQUIRES THIS KIT:
1. H7392(UPC)
2. H7390
o FUNCTION (of tool):
1. This new cable will be VAX 9000 specific and will
perform the function that cable P/N 17-00932-01 does in
the A2-M0961-10, VAX 8600 Cable Branch Kit.
o LEVEL OF DISTRIBUTION:
- Branch Level
VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT 3-23
3.16 POWER SERVICING and SAFETY TOOL KIT
o CSSE EVALUATION SAMPLE STATUS:
1. Joint effort with Env. Prod. CSSE, F.S. Product Safety
o DEC PART NUMBER/PRICE:
1. 22-00518-01 / $740.00
o CUSTOMER SERVICE TOOLS and TEST EQUIPMENT ACTION
REQUIRED:
1. Provide CSSE with the final Manufacturer and Manu. Part
Number.
o SUGGESTED MANUFACTURER/PART NUMBER:
1. Kaufman Co.
o VAX 9000 FRU THAT REQUIRES THIS KIT:
1. UPC
2. Environmental Products - PDS,PCS,UPS
o FUNCTION (of tool):
1. Provide DEC part numbered tools and safety devices
necessary for safe servicing of our "power" products.
o COMPONENT PARTS:
* Insulated Screwdrivers: (11)
- Philips #0, #1, #2
- Slotted 1/8", 1/4", 5/16"
- Torx T-10, T-15, T-20
- Posi-drive #1, #2
* Insulated Wrenches:
- Adjustable Wrench, 8"
- Open-end Set, 9pc 1/4" - 3/4" (single-ended)
3-24 VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT
- Box-end Ratchet Set, 1/4" - 3/4"
- Torque Ratchet, Adj 3/8" Sq Dr (5-75"lbs.) Utica
TCI-75FRN
- Sockets, 1/4" - 3/4" (9PC Set)
* Insulated Pliers/Cutters:
- Needle Nose, 6"
- Diagonal Cutters, 5"
- Diagonal Cutters, 8"
- Pliers w/Cutters, 8"
* Hex Key:
- T-hex, 1/4" (No Plastic Coating)
* Goggles:
- Soft-sided
* Face Sheild:
- Full Facial Cover
* Insulated Gloves:
- Class #0,(5KV Max/16" Long/2 Pair)
* Cane/Hot Stick:
- 24" Length w/Insulated Head
* Lock-Out Tags:
- 2 sided / BRADY #76194
* Lock Hasps: (2 ea.)
* Lock: (2 ea.)
* Warning Tape:
- "CAUTION - DO NOT ENTER" / BRADY #91224
VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT 3-25
* Warning Signs:
- 2-Sawhorse, "HIGH VOLTAGE/RESTRICTED AREA" Brady
FS-9
* Insulated Mat:
- "Insulated" (printed on both sides) 30" x 45"
* Fuse Puller:
- Multi Size
* Alignment Tool:
- Slotted, Dual-Ended
* Smock:
- Cotton Material (Velcro Snaps)
* Anode Discharge Tool:
- w/Insulated Probe Shaft
* Breaker Sleeves:
- various styles, (Qty of 6 for each type of sleeve
required)
* Wiggey:
- Power "present" Tester
* MultiMeter:
- Analog
o LEVEL OF DISTRIBUTION:
- Branch Level
3-26 VAX 9000 SPECIFIC TOOLS and TEST EQUIPMENT
|
| 78.102 | demna diagnostic failure | KERNEL::WRIGHTON | odd numbered release = bug insert | Sat Dec 22 1990 20:13 | 147 |
|
From: MACNAS::JOTOOLE "John O'Toole. GAO. dtn:822-2954. 19-Dec-1990 1749" 19-DEC-1990 17:48:10.01
To: @AQUA_TECH,JWAFER,JHESNAN
CC: @AQUA_ESASE,TKILLARNEY,JOTOOLE
Subj: DEMNA waiver
I have received the following message from BTO re. an EVDYE diagnostic
failure (I've seen the same error on the 420):
---------------------------------------------------------------------------
" On several different DEMNAs on several different VAX9000s, we've
seen timeouts occur when running EVDYE. The failure is always error number
60. I have a printout of one of the failures in front of me:
: : : : : : :
: : : : : : :
Test 3: Transmit and Receive 802 Packets Test
******** ZZ-EVDYE DEMNA NI Functional Diagnostic - 2.0 ********
Pass 1, test 3, subtest 0, error 60, 28-NOV-1990 22:17:49.34
System fatal error while testing EXD0: ** QIO setchar function failed **
System condition value returned:
%SYSTEM-F-ABORT, abort
IO Status Block: 0000002C(x)
00010200(x)
Status bits indicate: Timeout occurred
Summary of error:
Error shutting down a DEMNA port user
******** End of System fatal error number 60 ********
..Halt on error at PC 0000109C(X)
DS>
There have been similar failures with error 60 on
different test numbers".
------------------------------------------------------------------------
This problem has been investigated by DEMNA SASE and found to be
due to a ucode bug which manifests itself only in the diagnostic and
not in normal operating conditions. A general waiver (attached) has
been issued to allow shipment of modules displaying the failure.
Therefore you may ignore any identical DEMNA failures until further
notice.
Thanks,
John.
From: SASE::SOFKA "Rita Sofka 04-Dec-1990 1718" 4-DEC-1990 17:22:49.53
To: @DEMNA_WAIVER.DIST
CC: SOFKA
Subj: URGENT!! WAIVER APPROVED For EVDYE Diagnostic which will allow MFG. to ship DEMNA's that exhibit the error 60 problem with EVDYE!!
-----------------------------
| | | | | | | |
| d | i | g | i | t | a | l | INTEROFFICE MEMORANDUM
| | | | | | | |
-----------------------------
TO: DISTRIBUTION DATE: December 4,1990
FROM: Rita Sofka
DEPT: SASE PROGRAM MANAGEMENT
DTN : 293-5413
MAIL: BXB2-1/G13
cc: Dave O'Keefe
Kevin O'Donnell
Mike Person
Bill Long
SUBJECT: Waiver Approved for EVDYE Diagnostic For Aquarius Shipment
The waiver has been approved to allow manufacturing to ship DEMNA's
that exhibit the error 60 problem with the EVDYE diagnostic. This problem
is a known problem and is currently being worked by SASE. It has been
entered into the PCIS database and has been assigned as QAR 3758.
This error will not affect the integrity of the module or inhibit the
performance of the network. The error only occurs on shutdown commands to
the DEMNA port and occurs intermittently.
This waiver will be in effect until QAR 3758 is closed.
Please indicate below whether or not you support this WAIVER, include any
appropriate comments, and return your vote to me ASAP. Thank You.
------------------------------------------------------------------------
| NAME | 5X5 FUNCTION | SUPPORT MFG WAIVER |
| | | WAIVER - YES / NO
------------------------------------------------------------------------
| Dave O'Keefe | Engineering |YES December 4,1990
------------------------------------------------------------------------
| Kevin O' Donnell | Product Management |YES December 4,1990
------------------------------------------------------------------------
| Mike Person | CSSE |YES December 4,1990
------------------------------------------------------------------------
| Bill Long | Manufacturing |YES December 4, 1990
------------------------------------------------------------------------
COMMENTS: No Comments received.
DISTRIBUTION:
COM:
Jose Diaz
Pedro Lasalde
Eddie Mercado
Candido Molinary
Angel Rivera
Carlos Rivera
Jorge Rodriguez
Luis Sierra
Michel Velez
GAO:
Pat Boland
BTO:
Linda Glover
Mitch Casey
Gary Hicks
BXB2:
Jonathan Mooty
TWO:
Maureen Jean
Greg Walsh
Lynn Woods
|
| 78.103 | | KERNEL::WRIGHTON | odd numbered release = bug insert | Sat Dec 22 1990 20:14 | 21 |
|
PLEASE INFORM YOUR COUNTRY CONTACTS CSL & CSSE TO BE AWARE THAT
THE NECESSARY CONSOLE S/W TK50 PATCH TAPE CONTAINING THE B4 TO B5
UPGRADE HAS NOT SHIPPED WITH THE SYS UPGRADE.
DUE TO PART NUMBER ADMIN ISSUES IN ESSB INCORRECT PATCH TAPES WERE
DELIVERED CONTAINING UNRELEASED VMS VERSION 5.4-1. THIS SHOULD NOT
BE ALLOWED TO GO TO CUSTOMER SITE.
AN ORDER OF THE CORRECT TAPE IS NOW ENROUTE FROM THE S/W "JOB SHOP"
IN THE US AND IT IS OUR INTENTION TO DELIVER TO ALL SPARES LOCATIONS
AND WITH ALL FUTURE SPARES AND SYS UPGRADE SETS FROM NEXT WEEK.
APOLOGIES FOR THIS PROBLEM. FIELD ENGINEERS MUST NOW CONTINUE TO PULL
THE NECESSARY S/W UPGRADE OVER THE NET.
REGARDS.
|
| 78.104 | Info on B5 upgrade and BI related problems | KERNEL::WRIGHTON | odd numbered release = bug insert | Sat Dec 22 1990 20:15 | 106 |
|
Some confusion has developed on whether or not these drivers should be backed
out when following the VAX 9000 ECO FIELD IMPLEMENTATION PLAN on page 5.
MRCSSE::NONAME:[PUBLIC]LIDRIVER.EXE
MRCSSE::NONAME:[PUBLIC]PUDRIVER.EXE
MRCSSE::NONAME:[PUBLIC]SIDRIVER.EXE
MRCSSE::NONAME:[PUBLIC]YIDRIVER.EXE
The B5 CTU upgrade addresses some circumstances under which this problem
may occur. There remain other scenarios in which this problem still exists.
These will be fixed in the new VAP MCU currently planned to be
designated as the B6 upgrade.
If you have installed any of these drivers as a workaround leave them installed
until the new VAP B6 mcu is installed.
When this bug was first posted it was believed that all the below listed
problems would be fixed in CTU B5 mcu but this was not the case.
4. PROBLEM:
BUGCHECK/HALTS Caused by Cache Control Design Bug
System crashes with Kernel Mode Halts or Bugchecks. The halts
and bugchecks are at or around the same PC usually in a I/O
device driver. There would most likely be and instruction
that will be doing a write to an I/O device register. The
only error bits that may be latched are NXM errors. In one
of the systems increasing the sysgen paramenter NPAGEDYN by
1,200,000 enabled the system to run without any halts.
The symptoms vary, but include:
I-stack not valid -- bogus PTE loaded
exception above ASTDEL -- bad i-stream fetched
page-fault, IPL too high -- bogus PTE loaded
HALT -- i-stream fetches zero's
mem nxm, read or write -- wild translation
io nxm, read or write -- wild translation
Cause:
The system failures are caused by improper virtual address
translations in the MBox. The effect of the logic bug
is that a page table entry (PTE) is loaded into the
translation buffer (TB) incorrectly.
The bug is provoked by the incidence of a TB miss while
a CPU write, typically to I/O space, is delayed due to
a hardware resource wait. During this delay, cache set
selection information is frozen (even if the CPU write is
non-cacheable, as in I/O space writes). To resolve the TB
miss, the fixup processor requests the cache to deliver
the appropriate PTE for loading into the TB. If the PTE
resides in the OPPOSITE cache set that is selected during
the write-delay, incorrect data will be delivered to the
TB, thus causing an improper virtual address translation.
Only fixup processor requests are vulnerable to this cache
malfunction, because this is the only type of request that
the cache's arbitration logic allows to proceed while CPU
writes are in progress.
The effects of the problem are varied. Improper
translations can lead to a variety of exceptions, and
in some cases hardware error conditions.
SOLUTION/WORKAROUND:
This is a hardware problem which will be fixed by a new
revision of the VAP MCU. The B5 CTU upgrade addresses
some circumstances under which this problem may occur.
There remain other scenarios in which this problem might
occur. These will be fixed in the new VAP MCU currently
planned to be designated as the B6 upgrade.
For the interim, there are some WORKAROUNDS:
Systems with BI devices should get:
MRCSSE::NONAME:[PUBLIC]LIDRIVER.EXE
MRCSSE::NONAME:[PUBLIC]PUDRIVER.EXE
MRCSSE::NONAME:[PUBLIC]SIDRIVER.EXE
MRCSSE::NONAME:[PUBLIC]YIDRIVER.EXE
The FIX for this problem will be in CPU Revision B6 which
will introduce a new VAP MCU.
The WORK AROUND for this problem is to disable one of
the Cache Sets by depositing the command shown below in
CSA1:[SYSEXE]SITEINIT.CMD.
! DISABLE SET 0
D/CPU=('CPU') CTU.CTMV.SET_SEL_H<1> 1
This work around should be applied only when absolutely
sure that it is needed to resolve a particular problem.
Contact CSSE if unsure that disabling half of cache will
resolve a problem. Disabling one cache set could lead to
a significant decrease in performance depending on how
the system is used doing mostly I/O or compute bound jobs.
Engineering is currently looking into a VMS and UCODE
change as a workaround.
|
| 78.105 | New Vbox Microcode (fixes all known problems) | KERNEL::WRIGHTON | odd numbered release = bug insert | Sat Dec 22 1990 20:16 | 79 |
|
PROBLEM:
VAX 9000 systems with a VBOX may see failures when running
vector code that uses SITP benchmark test "V_Euler". This
resulted in the following errors:
1) Data mis-compare;
2) Arithmetic Fault;
3) Floating point overflow.
RESOLUTION/WORKAROUND:
New microcode (AQUARIUS.LOD) has been produced which fixes
this problem. The new microcode is version 332.
Version 332 is available now in the CSSE PUBLIC directory at
the following location:
MRCSSE::PUBLIC:AQUARIUS.LOD;332
MRCSSE::PUBLIC:AQUARIUS.MCR;332
ADDITIONAL COMMENTS:
Process context switches have been optimized so that the
vector registers are only saved if a subsequent process
executes vector instructions. The SRM requires that a Vector
Processor Disabled fault be taken on issuing any vector
instruction. This insures that the context of the previous
vector process is saved.
The case with Euler was that the previous vector process left
the Vector Length Register (VLR) with a value of zero. The
initial vector code in Euler looks similar to the following:
VLDx
.
.
.
B: Some vector instruction
Because VLR=0 from the previous vector process, the VLDx
would complete as a NOP, thus causing the Vector Processor
Disabled fault to NOT be taken. The instruction at B:,
however, would cause the Vector Processor Disabled fault and
a SAVE/RESTORE would occur and the flow would get restarted
from B:.
Thus, it's as if the VLDx never took place.
This is a �code bug in the flow of VLDL, VLDQ, and VSYNC
vector instructions.
The fix is to make sure the �code takes a Vector Processor
Disabled fault for these instructions. Version 332 proves
this to be a valid fix.
BTO and GAO will start releasing version 332 as part of BL 12
on all systems shipping from manufacturing as of today. It
will be included in any subsequent VAX 9000 SPU Base Level
release kits.
AQUARIUS.LOD;332 is NOT included in the current BL12 Network
Release savesets, however instructions have been added to the
network release build procedures that identify how to
incorporate the new code into the kit automatically.
*** DIGITAL INTERNAL USE ONLY ***
|
| 78.106 | Go to UK_9000 | KERNEL::WRIGHTON | A +L-14005 is all you need ! | Wed Jan 30 1991 08:32 | 8 |
|
As this note is getting a bit unwieldy I will in future be adding
new information to the UK_9000 notesfile. This notesfile is members only,
restricted at the moment to those who are 9000 trained but if you
would like access see either me or Roland Scott.
Dave Wrighton
|