| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 133.1 | ?52 ROM revision mismatch | KERNEL::ROBB | | Wed Mar 20 1991 15:10 | 27 |
| Hi All,
Just a reminder of compatibility problems on 6000 system processors.
The message about rom / eeprom mismatch is informational only. It does not mean
they will not work together and processors / roms should ***NOT*** be changed
to get rid of this message. CPUs will boot and run together.
Example of message during boot
?52 ROM revision mismatch. Secondary processor has rom revision x.xx
?54 EEPROM revision mismatch. Secondary processor has eeprom revision x.xx/y.yy
If you need to check the state of any CPU on a running system use the
"$SHOW CPU/FULL" command.
The exception is on RIGEL (6000-400) systems when processors with rev 1 roms
(rev H CPU) are mixed with higher rev CPUs with rev 2 or 3 roms (rev J,K,L,AJ,
AK,AL CPUs) Rev 2 and 3 roms will work together.
If the system has any rev H CPUs it should be remembered that they will not work
with any new modules coming out of logistics. More than one module or set of
upgrade roms may need to be called out when calling out spares.
UPDATE / SAVE / RESTORE should NEVER be used with mixed rev roms and it is
strongly suggested that EVUCA should be used for ALL updating with all other
information typed in from the keyboard. On any telesupport involving EVUCA find
out the revisions of the modules in the system.
|
| 133.2 | Rack Mountable Systems. | KERNEL::JAMES | Alan James CSC Basingstoke | Wed Apr 03 1991 19:48 | 22 |
| VAX 6000 RACK MOUNTABLE SERIES SYSTEMS
--------------------------------------
A 6000 system can be purchased as a rack-mountable system. These
are already installed at Mercury Communications.
A system consists of BA60-BB Box containing the XMI and 6000 control
panel, above a BA61-BB box containing the BI and TK70.
Main Differences :-
Single Phase Supply.
Different Power Supply.
Mains on/off Rocker Switch on Front of cabinet between BA6X boxes.
Drawers pull forward to expose Modules.
Modules are positioned "handles uppermost".
Two guides concerning these systems are on Kens desk. They should be
in the library soon.
Alan.
|
| 133.3 | CDROM Part #'s for 6xxx Systems | KERNEL::BLAND | toward 2000 ... | Thu Apr 04 1991 08:07 | 18 |
| Available from JAN/91
=====================
for the 6XXX console only AI-PDYQC-BE VAX 6000 CONS CD-ROM KIT
which will contain AG-PDWVC-RE
for 6XXX console w/diags AI-PDZZC-BE VAX 6000 CMPLT DIAG CE-ROM KT
which will contain AG-PDWWC-RE
************************************************************************
Available from 6 MAY/91
=======================
for the 6XXX console only AI-PDYQD-BE VAX 6000 CONS CD-ROM KIT
which will contain AG-PDWVD-RE
for 6XXX console w/diags AI-PDZZD-BE VAX 6000 CMPLT DIAG CE-ROM KT
which will contain AG-PDWWD-RE
|
| 133.4 | EEPROM problem with CIXCD | KERNEL::BLAND | toward 2000 ... | Mon Apr 08 1991 20:56 | 184 |
| Although this info' is in TIMASTARS for all to see, it is a new entry
and I wanted to bring it to your attention sooner than later. NORMAN
CIXCD Failures
******************** CAUTION: FOR INTERNAL USE ONLY *********************
* *
* THIS INFORMATION IS FOR USE BY DIGITAL EQUIPMENT CORP. AND ITS *
* EMPLOYEES ONLY. PLEASE USE EXTREME CARE IF YOU MUST DISCUSS ANY *
* PART OF THIS INFORMATION WITH ANYONE WHO IS NOT A DIGITAL EMPLOYEE. *
* *
******************************************************************************
+---------------------------+
| | | | | | | |
| d | i | g | i | t | a | l | TIME DEPENDENT CASE
| | | | | | | |
+---------------------------+
TITLE: CIXCD Failures
DATE: Mar. 28, 1991
AUTHOR: Bob Aston TD #: 000655
DTN: 297-4851
ENET: MRCSSE::ASTON 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 CIXCD used EEPROMS to store the diagnostic and functional
Microcode. This Microcode when needed, is down line loaded into
the faster rams on the module for execution. This Microcode
is reloadable from other load media, such as CD, TK, and RD.
PROBLEM:
The EEPROMS that the CIXCD uses are experiencing a higher than
average fall out rate. The problems seen both at the operating
system level or diagnostic level show up as single or double bit
errors and are not typically solid faults. By solid I mean that if
the Microcode is reloaded, the failing cell is recharged in the
EEPROM and the problem "seems" to have gone away. In actual fact,
the cell will again loose its charge somewhere down the line and
another Customer failure will occur resulting in a service call.
There is no time frame for these errors to occur, it is based on
how strong the cells are when the EEPROM is manufactured at the
Vendor level.
The CIXCD uses 11 of these EEPROMS and the problem will show up
at random, it could be any component and any bit within the
component and at any time.
The following diagnostic report of EVGEA shows what an EEPROM
error might look like. Remember the error may be in different
locations, EEPROMS, bits, or even random order in both the
Functional and Diagnostic areas of the Microcode. The VERIFY
section of EVGEA is used to compare the EEPROM code to the
Microcode version stored on a separate load media. REMEMBER to
use the same version of Microcode when doing the comparison. In
this example, the CIXCD had Version 1.04, the Microcode version
that it is compared to was also 1.04.
[Start of diagnostic report]
--------------------------------------------------------------------------------
DS> LOAD EVGEA
DS> ATTACH CIXCD HUB PAA1 B 10
DS> SELECT PAA1
DS> START/SECTION=ERRORLOG
.. Program: EVGEA CIXCD Functional Level 3 Diag , revision 2.1, 25 tests,
at 19:39:03.42.
Testing _PAA1
Test 16: CIXCD EEPROM UTILITY - Examine DCB/ERRORLOG
CIXCD EEPROM examine DCB ERRORLOG header utility
The current CIXCD XMI node number is 0B
The current date and time is = 13-MAR-1991 19:39:04.44
EEPROM UPDATE date and time is = 13-MAR-1991 01:08:29.04
Values currently read from EEPROM
Module Serial Number = ASO4002086
Module H/W revision- = E03
Functional Microcode revision- - - - = 1.04
This version of Microcode supports 1K Packet buffer size
Diagnostic Microcode revision- - - - = 0.38
Functional Microcode region Checksum = 069EAA7E
Diagnostic Microcode region Checksum = CE1C9493
Diagnostic Control Block Checksum- - = 00000000
Number of valid ERRORLOG entries = 03
Number of EEPROM write cycles = 0001
.. End of run, 0 errors detected, pass count is 1,
time is 13-MAR-1991 19:39:20.58
DS> Clear halt
DS> start/section=verify
.. Program: EVGEA CIXCD Functional Level 3 Diag , revision 2.1, 25 tests,
at 19:42:11.61
Testing _PAA1
CIXCD EEPROM verify utility
The current CIXCD XMI node number is 0B
Input the CIXCD BINARY file name to use [default is = CIXCD.BIN]: CIXCD.BIN;116
Microcode file already loaded in VAX ram memory
<------------------ start of Microcode file header text block --------------->
Copyright (c) Digital Equipment Corporation 1990. All rights reserved.
Diagnostic Firmware Revision 0.38 , Functional Firmware Revision 1.04
<-------------------- end of Microcode file header test block --------------->
******** EVGEA CIXCD Functional level 3 Diag - 2.1 ********
Pass 1, test 13, subtest 0, error 6, 13-MAR-1991 19:42:18.52
Hard error while testing PAA1: EEPROM region data did not VERIFY correctly
Xored CS EEPROM = 00000000 00000000 01000000
Reading CS EEPROM = 00030000 01798002 2B000743
Verify ucode file = 00030000 01798002 2A000743, loc 41F4
******** End of Hard error number 6 ******
There were 1. EEPROM addresses in error
composite of all CS EEPROM XOR'd bits in error - 00000000 00000000 01000000
Module H/W revision- = E03
Chip fault data 00 00 00 00 00 00 00 01 00 00 00
Chip fault list E62
Verifying EEPROM has been completed
[End of diagnostic report]
--------------------------------------------------------------------------------
Workaround:
At this time, when the errors described above occur, do NOT reload
the Microcode. Replace the module.
Long Term fix:
Digital is now receiving a better quality EEPROM from the Vendor
and plans are in place to incorporate a better all around EEPROM
strategy and component.
*** DIGITAL INTERNAL USE ONLY***
|
| 133.5 | | KERNEL::MOUNTFORD | | Wed Apr 10 1991 15:24 | 55 |
| From: COMICS::LINDLEY "Brian Lindley, U.K. Support 833-3659 09-Apr-1991 1758" 9-APR-1991 18:02:18.90
To: @6000,@EURO_6000
CC: LINDLEY
Subj: Problem booting 6000s into a cluster will latest EEPROM patches
Gentlemen,
The latest revisions of EEPROM patches on both 6300 and 6400 systems
have been reported to be giving problems when the system is booted
in a cluster environment. These patch levels are 3.03 for the 6400
and 4.8 for the 6300, and is thought that the latest EEPROM patches
for the 6200 and 6500 will exhibit the same problem.
These EEPROM patches are distributed with VAXPAX #43.
The mode of failure is as follows :-
The system will fail to boot depending on what is specified in the
/NODE qualifier, and which node is specify as the primary and
secondary path to the HSC.
An example is as follows :-
/NODE:00000E0F !fails when the system disk is mounted through HSC = F.
When the secondary path is used no failure occurs.
/NODE:00000F0E !VMS boots when the system disk is mounted through HSC =F.
When the primary path is used alone no failure occurs.
/NODE:0000000F !VMS boots when the system disk is mounted through HSC = F.
On first analysis it appears that if the secondary path specified
is a lesser node number than the primary, it appears that if the
boot through the primary fails, the secondary path will not be
tried. Failover at this level should occur.
Another example that has been found was using node 4 and node 7 as
the HSC node numbers. The system disk was only accessible though
node 4. So if /NODE:00000407 was used the system would not boot. If
/NODE:00000704 was used the system boot O.K.
Engineering are aware of the problem and are working on a fix. The
short term solution is to go back to VAXPAX 42. The individual
revisions are as follows ( the ones that work ) :-
6300 EEPROM Patch 4.7
6400 EEPROM Patch 3.02
Please contact me if you have any queries regarding this mail.
Regards
Brian
|
| 133.6 | 64xx EEPROM patch problem/fix | KERNEL::BLAND | toward 2000 ... | Wed Apr 10 1991 22:29 | 20 |
| Although this is specific to 64xx, we appear to have the same issue on
other 6xxx systems, hence I have posted this note here. Norman
<<< SASE::WRKD:[NOTES$LIBRARY]CALYPSO.NOTE;3 >>>
-< CALYPSO -- VAX 6000-xxx Family Notes >-
================================================================================
Note 861.6 Boot problem on 6440 with EEPROM 3.03 6 of 7
NOXORC::CROXON "reenignE elosnoC xxx6XAV ESAS" 9 lines 10-APR-1991 08:06
--------------------------------------------------------------------------------
Hello, I have been loooking into this error.
6400 patch 3.03 (A halt PC = 20105261.)
The problem is with a timer started when you check the availability status
of the tape drive to load the CICBA-A microcode. Even if you don't have
a CIBCA-A the timer is started. The lengthy boot time of failing on the
primary HSC and switching to secondary HSC exhausts the timer. This
problem will be fixed in SSB Release #45.
|
| 133.7 | VMS V5.4-2. 6000 EEPROM requirements | KERNEL::ROBB | | Tue May 14 1991 12:28 | 179 |
|
I N T E R O F F I C E M E M O R A N D U M
Date: 13-May-1991 04:14pm BST
From: LINDLEY
LINDLEY@COMICS@KERNEL@MRGATE@THESUN@UVO
Dept:
Tel No:
TO: See Below
Subject: VMS V5.4-2. 6000 EEPROM requirements.
PROBLEM:
It is stated in the "Cover Letter for VMS Version 5.4-2"
( AV-PG8CB-TE ) and the VAX/VMS V5.4-2 Release notes that there is a
minimum console level requirement on 6000 based systems for Version
5.4-2. This information is on Page 4 Table 1, and is also shown
below.
This information is mis-leading as most of the time the console
firmware or EEPROM does NOT need to be upgraded for VMS version
5.4-2 . It is the hardware configuration which dictates this console
version number required.
-----------------------------------------------------------------
Table 1: Required Console Microcode Versions ( EEPROM levels )
-----------------------------------------------------------------
Minimum Required Version Number
------------------------------------------
VAX 6000 Scalar Vector Platform Enhancements
---------------- ------ ------ (PLEN)
---------------------
Model 200 Series 3.8 5.1
Model 300 Series 4.7 6.1
Model 400 Series 1.03 2.02 3.02
Model 500 Series 2.02 2.02 2.02
RESOLUTION/WORKAROUND:
Ensure the proper revision of Console/Diagnostic Code is present to
support the devices configured regardless of the VAX/VMS version.
For example, if your system disk is a DSSI device, the minimum
console microcode versions listed above *ARE* required prior to
upgrading to VMS V5.4-2. However, if your system disk is NOT a DSSI
device and the device can be successfully configured and booted, the
minimum console microcode versions (for all VAX 6000 models) listed
above are *NOT* required prior to upgrading to VMS V5.4-2.
ADDITIONAL COMMENTS:
The following is EEPROM revision option support information for the
following systems:
VAX 6000-2xx
VAX 6000-3xx
VAX 6000-4xx
VAX 6000-5xx
EEPROM update patch release notes and console change information for
the systems stated above is included.
VAX 62xx Processor Console and RBD ROM Revision V3.1 and V5.0:
EEPROM Update Patch Release Note
Rom V3.1 EEPROM 3.8
Rom V5.0 EEPROM 5.1
Console Changes for 62xx systems:
Added booting support for NI/CDRom (InfoServer100), CIXCD
and KFMSA (DSSI) devices.
Fixed problem when booting through TK devices when not at BOT.
Fixed timing problem when booting DSSI RF72 drives.
VAX 63xx Processor Console and RBD ROM Revision V4.1 and V6.0:
EEPROM Update Patch Release Note
Rom V4.1 EEPROM 4.7
Rom V6.0 EEPROM 6.1
Console Changes for 63xx systems:
Added booting support for KFMSA (DSSI) devices.
Fixed problem when booting through TK devices when not at BOT.
Fixed timing problem when booting DSSI RF72 drives.
VAX 64xx Processor Console and RBD ROM Revision V1.0, V2.0 and V3.0:
EEPROM Update Patch Release Note
Rom V1.00 EEPROM 1.03
Rom V2.00 EEPROM 2.03
Rom V3.00 EEPROM 3.02
a. Console Changes for Roms version V1.00 - The following problems
were fixed in this patch 1.03:
Added booting support for NI/CDRom (InfoServer100) and
KFMSA (DSSI), and CIXCD.
Fixed problem when booting through TK devices when not at BOT.
Fixed timing problem when booting DSSI RF72 drives.
b. Console Changes for Roms version V2.00 - The following problems
were fixed in the patch V2.03:
Added booting support for KFMSA (DSSI) devices.
Fixed problem when booting through TK devices when not at BOT.
Fixed timing problem when booting DSSI RF72 drives.
c. Console Changes for Roms version V3.00 - The following problems
were fixed in this patch 3.02:
Added booting support for KFMSA (DSSI) devices.
Fixed problem when booting through TK devices when not at BOT.
Fixed timing problem when booting DSSI RF72 drives.
VAX 65xx Processor Console and RBD ROM Rev V2.00
EEPROM Update Patch Release Note
Rom V2.00 EEPROM 2.02
Console Changes for Roms version V2.00 - The following problems were
fixed in this patch 2.02:
Fixed problem when booting throught TK devices when not at BOT.
Fixed timing problem when booting DSSI RF72 drives.
DIGITAL INTERNAL USE ONLY:
The following is information for internal hardware engineers on how
to bring an EEPROM up to minimum revision:
EVUCA
This program is the recommended utility to update the EEPROM on all
VAX 6000 series processors:
KA62A
KA62B
KA64A
KA65A
All processors in a system can be updated concurrently. A system
having processors with different ROM revisions can be updated.
However, a processor's diagnostic and console ROMs must have the
same major revisions.
Hardware Requirements for VAX 6000 systems:
VAX 6000-200, VAX 6000-300, VAX 6000-400 or VAX 6000-500.
Software Requirements:
This program requires the VAX Diagnostic Supervisor (VAX/DS) Version
14.0 or later. For each VAX 6000 system, a binary file is required.
The files are:
VAX 6000-200 ELUCA.BIN
VAX 6000-300 ELUCB.BIN
VAX 6000-400 ERUCA.BIN
VAX 6000-500 EMUCA.BIN
|
| 133.8 | MORE on EEPROM PATCHes from VAXXPAX release 43 | KERNEL::BLAND | toward 2000 ... | Mon May 20 1991 21:14 | 74 |
| This BLITZ clarifies the situation with EEPROM PATCHes released with
VAXPAX 43.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: BEEZER::TIMA_MGR 19-MAY-1991 23:36:15.59
To: KERNEL::BLAND
CC:
Subj: GRAM: RELEASE 43 CONSOLE/DIAGNOSTIC PATCH PROBLEM (BLITZ)
Author : RODNEY BOYLE
User type : USER
Location : CSSE
Vaxmail address : CSSE::BOYLE
+---------------------------+TM
| | | | | | | |
| d | i | g | i | t | a | l | TIME DEPENDENT BLITZ
| | | | | | | |
+---------------------------+
BLITZ TITLE: RELEASE 43 CONSOLE/DIAGNOSTIC PATCH PROBLEM (ALL 6000)
DATE: 13-MAY-1991
AUTHOR: JIM VERMETTE TD #: 000701
DTN: 247-2555
ENET: VOLKS::VERMETTE CROSS REFERENCE #'s:
DEPARTMENT: VAX System Support CSSE (PRISM/TIME/CLD#'s)
INTENDED AUDIENCE: ALL PRIORITY LEVEL: 1
(USA/EUR/GIA) (1=TIME CRITICAL,
2=NON-TIME CRITICAL)
System(s): 6000-XXX
Device(s): SCALAR PROCESSORS
=====================================================================
PROBLEM:
The following Console/Diagnostic patch files (*.BIN) contained in
VAXPAX Release 43 exhibit a VAX/VMS boot path failure.
ELUCA.BIN (Contains Patch V3.9 and V5.2)
ELUCB.BIN (Contains Patch V4.8 and V6.2)
ERUCA.BIN (Contains Patch V1.04, V2.04 and V3.03)
EMUCA.BIN (Contains Patch V2.03)
The failure is dependent on the configuration hardware. It must be a
Cluster configuration utilizing two HSCXX devices plus a CIBCA-B or
CIXCD. If the boot specification /NODE qualifier is setup to use either
HSCXX (example; /NODE:0E0F) and the VAX/VMS System Disk is mounted
through the secondary HSC path (0F) the boot will fail with a ?06 halt
condition. If the boot specification is /NODE:0F then the "0F" is
copied into the primary byte and the boot will be successful.
RESOLUTION/WORKAROUND:
Next release of console code (Release 44) will rectify the problem.
Workaround is too back down the code to the previous patch level.
ADDITIONAL COMMENTS:
EMUCA.BIN (V2.04) has been prereleased to solve a Vector RBD#57 failure.
This version also contains the above failure. If a situation occurs
whereas a VAX 6000 Model 500 contains a Vector Processor and the above
scenario please contact CSSE.
*** DIGITAL INTERNAL USE ONLY ***
|
| 133.9 | More info on EEPROM v VAXPAX #*! | KERNEL::BLAND | I wanna be a slug | Wed Sep 25 1991 12:56 | 72 |
| I do not believe this BLITZ to be 100% correct but the bottom line is
that it highlights a problem and it mentions the releases in VAXPAX 45
which hopefully fix this problem. Norman
**********************************************************************
Author : RODNEY BOYLE
User type : PFE
Location : CSSE
Vaxmail address : CSSE::BOYLE
+---------------------------+TM
| | | | | | | |
| d | i | g | i | t | a | l | TIME DEPENDENT BLITZ
| | | | | | | |
+---------------------------+
BLITZ TITLE: VAX6000 ALL MODELS FAILURE TO BOOT SHADOW SET
DATE: 24-SEP-1991
AUTHOR: JIM VERMETTE TD #: 000825
DTN: 247-2555
ENET: VOLKS::VERMETTE CROSS REFERENCE #'s:
DEPARTMENT: VAX System Support CSSE (PRISM/TIME/CLD#'s)
INTENDED AUDIENCE: ALL PRIORITY LEVEL: 1
(USA/EUR/GIA) (1=TIME CRITICAL,
2=NON-TIME CRITICAL)
System(s): 6000-2XX,6000-3XX,6000-4XX,6000-5XX
Device(s): PROCESSOR CONSOLE CODE
=====================================================================
PROBLEM:
The following versions of VAX6000 Model 200,300,400,500
Console/Diagnostic code fail to boot the VMS system disk in a
Shadow Set configuration. The problem resides in the CIBOOKA
module of the console code. Failure is exhibited by the error;
"Failed intializing I/O device".
VAXPAX Release 43 VAXPAX Release 44 MODEL
----------------- ----------------- -----
ELUCA.BIN V3.9, V5.2 ELUCA.BIN V3.B, V5.4 200
ELUCB.BIN V4.8, V6.2 ELUCB.BIN V4.A, V6.4 300
ERUCA.BIN V1.04, V2.04, V3.04 ERUCA.BIN V1.06, V2.06, V3.05 400
EMUCA.BIN V2.03 EMUCA.BIN V2.05 500
RESOLUTION/WORKAROUND:
Refrain from installing the above version of Console/Diagnostic code.
VAXPAX Release 45 will contain the following versions which has
corrected the CIBOOKA module within the Console code. VAXPAX Release 45
is scheduled for release on October 14, 1991. However, if the Release 45
versions are needed they may be obtained from the following directories;
VAXPAX Release 45 DIRECTORY MODEL
----------------- --------- -----
ELUCA.BIN V3.C, V5.5 VOLKS::CALYPSO$:ELUCA_REL45.BIN 200
ELUCB.BIN V4.B, V6.5 VOLKS::HYPERIO$:ELUCB_REL45.BIN 300
ERUCA.BIN V1.07, V2.07, V3.06 VOLKS::RIGEL$:ERUCA_REL45.BIN 400
EMUCA.BIN V2.06 VOLKS::MARIAH$:EMUCA.BIN 500
ADDITIONAL COMMENTS:
*** DIGITAL INTERNAL USE ONLY ***
|
| 133.10 | New ROMS for 6000 Systems | KERNEL::BLAND | I wanna be a slug | Fri Sep 27 1991 02:32 | 44 |
| Here is yet another new set of ROMS for the 6000 series that you should
be aware of.
Note 991.0 New VAX 6xxx Console and RBD ROMs
2 replies
NOXORC::CROXON "reenignE elosnoC xxx6XAV ESAS" 33 lines
11-SEP-1991 21:21
Please be advised that new Console and ROM-BASED Diagnositc
ROMs
have been released. The main focus of the new ROMs were for XVME and
DSSI support. The .MEM files mentioned below are in sub-directory 6000
in RDC$COMMON.
VAX62x0 CPU new CONSOLE and ROM-BASE Diagnostic V7.0
VAX63x0 CPU new CONSOLE and ROM-BASE Diagnostic V8.0
VAX64x0 CPU new CONSOLE and ROM-BASE Diagnostic V4.00
VAX65x0 CPU new CONSOLE and ROM-BASE Diagnostic V3.00
Release notes can be found at:
PROXY::PROXY_PUBLIC:[HYP_CONSOLE.RELEASE]V80_V70_RELEASE_NOTE.M
EM
PROXY::PROXY_PUBLIC:[RIG_CONSOLE.RELEASE]V40_RELEASE_NOTE.MEM
PROXY::PROXY_PUBLIC:[T2052_CON.RELEASE]V30_RELEASE_NOTE.MEM
The new ROMs contain boot support for:
o CIBCA-A o KDB50
o CIBCA-B o KDM70
o CIXCD o KFMSA-DI (DSSI Disk)
o DEBNA o KFMSA-MI (DSSI Tape)
o DEBNI o TBK50
o DEMNA o TBK70
o DEMFA o CSA1
Nigel Croxon
SASE Console Engineer
247-2197
NOXORC::CROXON
|
| 133.11 | DATARAM (Third Party) Memory on XMI | KERNEL::BLAND | I wanna be a slug | Tue Oct 08 1991 13:12 | 55 |
| Gentlemen, On the 26th September I got a TELESUPPORT call from engineer
Richard Noble enquiring about any potential problems installing extra
memory on a 6000 system. This appeared very straight forward until I
realised that the memory to be installed was from a THIRD PARTY company
DATARAM. I told Richard that the XMI was a private bus and that I was
not aware of any company that had been licenced to use the XMI corner.
Richard then told me that the same customer had some of this memory
already installed on a 6000 system at another site.
I asked Richard to contact his service centre and make his Manager and
Contracts aware of the situation. I contacted Brian Lindley and asked
him to investigate the issue; the following mail has been received from
Brian.
Regards, Norman Bland
From: COMICS::LINDLEY "Brian Lindley, U.K. Support 833-3659" 3-OCT-1991 14:19:08.88
To: KERNEL::BLAND
CC:
Subj: DATARAM infrigment!!!
From: VOLKS::VERMETTE "Jim/VAX Systems Support CSSE/DTN: 247-2555/ TWO/A4" 30-SEP-1991 17:55:59.43
To: COMICS::LINDLEY
CC:
Subj: DATARAM infrigment!!!
From: LANDO::ODONNELL "DCSS Product Management BXB2-2/F10 F3 293-5193" 30-SEP-1991 12:47:25.85
To: VOLKS::VERMETTE
CC: VOLKS::GROGAN,ODONNELL
Subj: re: VAX 6000 and foreign memory (Dataram)
Jim,
Nothing is allowed on any bus of DIGITAL's, unless it is an OPEN bus(i.e.
VME), or if the bus has been properly licensed. In the case of DATARAM, they
have not been licensed, and they are being sued by DIGITAL for patent
infingement currently. Litigations are in process, no decision has been
passed down at this time. DIGITAL does not recognise their right to have
their equipment plugged to out backplane.
_Kevin
From: VOLKS::VERMETTE "Jim/VAX Systems Support CSSE/DTN: 247-2555/ TWO/A4" 27-SEP-1991 09:12:41.46
To: LANDO::ODONNELL
CC: VERMETTE
Subj: VAX6000 and foriegn memory
Hi Kevin,
Is foriegn memory allowed on the VAX6000 XMI bus? I thought the XMI
corner was not licensed to anyone. The vendor's name is DATARAM over in the
U.K.
Please advise,
Jim
|
| 133.12 | kfmsa ucode workaround | KERNEL::ROBB | | Fri May 15 1992 03:37 | 41 |
| 133.13 | Rules for 4 node DSSI configuration | KERNEL::BLAND | Norman Bland 833 3797 CSC, Basingstoke | Tue Jan 05 1993 15:27 | 94 |
| ----------------------------- TM
| | | | | | | |
| d | i | g | i | t | a | l | INTEROFFICE MEMORANDUM
| | | | | | | |
-----------------------------
TO: Tom Rosenstein DATE: 9 NOVEMBER 1992
FROM: JIM COLEMAN
cc: Steve George DEPT: SASE PROGRAM MANAGEMENT
DTN : 247-2528
MAIL: TWO/A5
ENET: SASE::COLEMAN
SUBJECT: VAX6000/7000/10000 QUAD-Host DSSI VAXcluster Rules
The following additional configuration rules apply "specifically"
to VAX6000/7000/10000 QUAD-Host DSSI VAXcluster Systems.
1. Maximum DSSI bus length cannot exceed 27 meters (89 feet) and
ground offset voltage cannot exceed 30mv (dc) or 10.5mv (rms).
The following table shows how the VAX6000/7000/10000 QUAD-Host
bus length rule compares to existing DSSI VAXcluster System
bus length rules.
Bus Length Allowable Offset
Meters/Feet (DC) (AC)
----------- ----------------
up to 20/65 200mv 70mv (rms)
20-25/65-82 40mv 14mv (rms)
VAX6000 QUAD-Host--> 27/89 30mv 10.5mv (rms)
VAX7000
VAX10000
2. DSSI ISE disks or tapes must be placed at the end of the DSSI
bus and termination at the ISE end of the bus must be imple-
mented at the ISE, not at the bulkhead. If 2 SF2xx or SF400
cabs are required, 1 must be placed physically at each end of
the cluster (see RULE #4).
+--------+ +--------+ +--------+ +--------+ +-------+
|VAX6000 | |VAX6000 | |VAX6000 | |VAX6000 | |SF2xx |
|VAX7000 | |VAX7000 | |VAX7000 | |VAX7000 | |SF400 |
|VAX10000| |VAX10000| |VAX10000| |VAX10000| | |
| +---+ | | +---+ | | +---+ | | +---+ | | |
| |#|.|* | | |.|.| | | |.|.| | | |.|.| | |S # |
| +--:+ | | +:-:+ | | +:-:+ | | +:-:+ | |F +-+ |
| v | | ^ v | | ^ v | | ^ v | |7 |.| |
| :...|.>.|..: :...|.>.|..: :...|.>.|..: :...|.. |3 +-+ |
| | | | | | | | : | ^ |
| | | | | | | | : | : |
| | | | | | | | : |-------|
| | | | | | | | : | : |
+--------+ +--------+ +--------+ +--------+ v +-------+
* Shows 1 I/O port on a KFMSA-BA/CK-KFMSA-LN : ^
# DSSI termination :.....:
QUAD-Host (cont.) page 2
3. In order to meet the QUAD-Host 89 foot bus length restriction,
only 9 foot cab to cab DSSI cables are allowed for connections
between system boxes, only 9 foot cables are allowed for con-
nections between system boxes and SF2xx storage cabinets, and
only 16 foot cables are allowed for connections between system
boxes and SF400 storage cabinets. There are "no" exceptions
to this rule.
4. If 2 SF2xx or 2 SF400s (or one of each) cabs are required, 1
must be placed physically at each end of the cluster because
neither the 9 foot intercab cables required for SF2xx connect-
ions or the 16 foot intercab cables required for SF400 con-
nections are long enough to reach from a system cab to a stor-
age cab if there is another storage cab in between.
----- ----- ----- ----- ----- -----
|SF | |VAX| |VAX| |VAX| |VAX| |SF |
| | |#1-|-->|-1-|-->|-1-|-->|-1-|-->|-1#| DSSI
| | |#2-|-->|-2-|-->|-2-|-->|-2-|-->|-2#| BUS 1&2
| | | | | | | | | | | |
DSSI |#3-|<--|-3-|<--|-3-|<--|-3-|<--|-3#| | |
BUS 3&4 |#4-|<--|-4-|<--|-4-|<--|-4-|<--|-4#| | |
| | | | | | | | | | | |
----- ----- ----- ----- ----- -----
# DSSI Termination
5. Up to 4 RF ISEs "or" 2 TF ISEs are allowed on the same DSSI
bus; combinations of RF ISEs and TF ISEs are "not" allowed on
the same DSSI bus. All RF ISEs on any single DSSI bus must re-
side in the same SF72, SF73, or SF35 storage array. All TF
ISEs on any single DSSI bus must reside in the same cabinet.
|