| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 49.1 | MODULE HANDLING | KERNEL::MOUNTFORD | | Fri Jul 14 1989 11:23 | 108 |
| From: KERNEL::COMICS::LINDLEY "Brian Lindley, U.K. Support 833-3659 13-Jul-1989 1430" 13-JUL-1989 14:34:44.16
To: @6200
CC: LINDLEY
Subj: Handling Precautions for 6000-4XX CPU module
Hello All
The following is a memo from Gerry Reilly and contains an
attachment from the Quality Engineer outlining the static
precautions for Rigel module handling. There is a section
which describes the usage of ESD coats. This is currently
being investigated and the impact being assessed.
If you have any problems/concerns please contact me.
Regards
Brian
********************************************************************************
Subj: Rigel T2015 module handling (For info)
The Rigel quality engineer has documented the attached which
outlines certain precautions which manufacturing personnel must
take while working with the new Rigel T2015 module. I am not
sure as to the level of awareness in the field around the
sensitivity of this module but anyone likely to come into
contact with this board should be aware of its associated
handling criteria.
With regard to the section on Clothing,this is a manufacturing
guideline and I am not sure as to the field requirement.
Regards,
Gerry.
Author: DES KELLY @GAO
Date: 14-Mar-1989
Posted-date: 14-Mar-1989
RIGEL T2015 MODULE HANDLING CRITERIA
====================================
It is imperative that the criteria outlined below are adhered
to , at all times , to prevent the modules being damaged .
HOLDING THE MODULE :
-- Modules should remain in field service boxes during all
handling . Modules should ONLY be stored in proper XRP field
service boxes . They should NOT be stored in Anti-Static bags,
under any circumstances.
-- Do not touch the goldfingers or module surface , carry the
module by the edges ONLY .
-- Do NOT bend/flex the module .
WORK AREA :
-- As the T2015 has components on both sides , please ensure
that it is not left directly on any surface - ALWAYS USE A
MODULE BOX .
-- Do not press on heatsinks or other components .
-- Never poke or pull at leads with tweezers , fingers , etc .
CLOTHING :
-- Always wear ESD coat , wrist strap and two toe/heel straps
when handling modules .
To be effective, coats must touch skin for grounding purposes.
XRP modules contain CMOS 2 Technology chips , which are very
prone to damage by static .
-- Prevent jewellery (watches etc.), clothing from touching
components and module surface as the may get caught on
components , especially the AC Terminators, thus lifting pads .
NB. COMPONENTS MOST EASILY DAMAGED ARE :
1. THE HEATSINKS :
Do not press on them .
2. 25 MIL LEADS :
Twice as sensitive as 50 mil leads . Touching with fingers ,
etc , will bend them. The seven 25 mil devices on the module
range in cost from $2,000 - $300 each.
3. AC TERMINATOR BODY AND BONDS ON TOP OF BODY :
Will catch on clothing, jewellery etc.
|
| 49.2 | Rigel Documentation | KERNEL::LINDLEY | | Wed Jul 19 1989 14:29 | 38 |
| There is now a RIGEL documentation set available in CSG. This set
is the support starter kit and consists of :-
VAX 6000-400 Options and Maintenance
VAX 6000-400 Mini Reference Guide
VAX 6000-400 Installation Guide
VAX 6000-400 Owner's Manual
Norm Pettet has now got this set of documentation.
I also send a copy of this documentation out to every Regional
Technical Group and every District office. The contacts I sent them
to are listed below.
Brian
nm%42073::mckee ! Willie @ Livingstone
nm%bahtat::lawrence ! Terry @ Newcastle
nm%brew11::bayliss ! Pete @ Birmingham
nm%brunel::daveo ! Mr Oatway @ Bristol
nm%dub01::ashford ! Gerry @ Dublin
nm%gallop::bushm ! Mike @ Newmarket
nm%grot::leate ! Adrain @ South RTG
nm%sedsws::davies_d ! Dyfrig @ Leatherhead
nm%thesun::mrgate::"ubo::ian pratt" ! Ian @ Basingstoke
nm%vivian::house ! Dennis @ London
nm%war750::roberts ! Graham @ North RTG
nm%welsws::griffin ! Pete @ Welwyn
nm%bahtat::rushworth ! Paul @ Leeds
nm%not001::stanley ! Phil @ Nottingham
nm%belfst::c_mcclintock ! Clifford McClintock @ Belfast
nm%jockey::allenk ! Keith in Central RTG
nm%vivian::gathercole ! Brent in London RTG
! Warrington didn't give me a name
! Send to Willie McKee for Brian Murdoch in Aberdeen
|
| 49.3 | Handling Precautions for T2015 | KERNEL::LINDLEY | | Thu Jul 20 1989 16:03 | 1 |
|
|
| 49.4 | Static Precautions for T2015 | KERNEL::LINDLEY | | Thu Jul 20 1989 16:06 | 108 |
| Sorry about the last entry.... I forgot to include the text !
Hello All,
I have spoken to several CSSE and Engineering representatives
with regard to static precautions on the 6000-4XX CPU. They
have issued me with the following document which has been
implemented in the U.S. There is no mention of ESD coats and
were thought not to be necessary in the field, as long as the
following preceedures are adhered to.
Regards
Brian
***************************************************************
Subj: New VAX6000-4XX CPU Module (T2015) - Extremely Fragile
NEW SENSITIVE TECHNOLOGY
Two things that you need to be aware of.....
1. Leads on the chips on the T2015 are very small and fragile.
The chips are attached to the module using 25 mil leads
that bend very easily.
2. The CMOS 2 technology is used in extensively on this module.
This technology is more sensitive to ESD dammage than
previous technologies.
HOLDING the MODULE
Please follow these procedures when handling the XRP.
The proper way to hold the module is by the edges, with hands
flat and perpendicular to the module.
Be sure your hands do not touch any components or leads. When
inserting it in or removing it from the XMI card cage, grasp
the module only in the area near the LEDs and the VIB
connector, always avoiding the 25 mil components (the BIG
chips). Do not use any component as a handle, and be sure not
to touch any leads. Be careful so that the module does not come
into contact with any surfaces while handling it.
NECESSARY PRECAUTIONS
To avoid damaging the module, please follow these handling
procedures:
o Always wear an antistatic wrist strap.
o Before removing the module from its ESD box, place the box on
a clean, stable surface.
o Be sure the box will not fall or slide. NEVER place the box
on the floor. And be sure no tools, papers, manuals,
or anything else that might damage the module are near
it. Components on this module are susceptible to damage
by a 600-volt static charge. Paper carries a 1000 volt charge.
o Hold the module only by the edges.
o Do not hold the module so that your fingers touch any
components or leads. Be sure you do not bend the module as
you are holding it.
o Be sure nothing touches the module surface or any of its
components.
INSTALLING the XRP
If anything touches the module, components or leads can be
damaged. This includes the antistatic wrist strap, clothing,
jewelry, cables, repair tags, and components on other modules.
Remove your jacket and roll up your sleeves before handling the
module. Also remove any jewelry. Be sure, when inserting the
module in or removing it from the XMI card cage, that no part
of the module comes in contact with another module or a cable.
When swapping out a module, set the module you remove, in an
unused XMI slot until it can be placed in an empty ESD box. If
an empty XMI slot is not available, place the module on a
grounded anti-static surface, side two down (side two has only
components with 50 mil leads, side one contains the BIG chips
with 25 mil leads).
Hold the XMI card cage handle while removing or inserting the
module. If it is not held in place, the handle can spring down
and damage the module.
When inserting the module in the card cage, grasp the module
only in the area near the LEDs and the VIB connector, and slide
it slowly and gently into the slot.
REPAIR TAG
DO NOT attach repair tag to module. Place the repair tag in the
plastic bag attached to the ESD box.
|
| 49.5 | all you need to know? | KERNEL::ANTHONY | | Tue Aug 29 1989 21:49 | 10 |
|
Hot off the press...
Maintenance Advisory now available. I have copied it to rdc$common.
The file is rigel_maint_adv.ps (postscript)
You can print it using the following command :
print/notify/que=ln03r_postscript/params=data=post rigel_maint_adv.ps
Brian
|
| 49.6 | DEBNI | KERNEL::BLAND | toward 2000 ... | Sat Oct 21 1989 14:10 | 24 |
| <<< KERNEL::DISK$APD1:[NOTES$LIBRARY]CSGUK_SYSTEMS.NOTE;1 >>>
-< CSGUK_SYSTEMS >-
================================================================================
Note 49.6 RIGEL 6400 topics. 6 of 6
KERNEL::BLAND "toward 2000 ..." 15 lines 21-OCT-1989 13:06
-< DEBNI >-
--------------------------------------------------------------------------------
6000-4x0 systems are shipped with a DEBNI ethernet adapter.
Module #: T1034-YA. Device Type Code: 0118.
VMS VER: 5.2 Reqd. DEBNA Upgrade: A DEBNA to DEBNI kit.
TKxx Support: A DEBNI has no TKxx support.
DEBNI's may be found on other BI systems in the future.
The upgrade kit contains four ROMS. NB. If you upgrade DEBNA
you will lose TK50 support.
This info and other good stuff on the DEBNI can be found in
an informative STARS article in database # 79 named "DEBNI new
product information"
Regards, Norman Bland
|
| 49.7 | Another "D" word to remember... | KERNEL::EDMUNDS | | Sat Oct 21 1989 15:21 | 3 |
|
DS5800 (ISIS) will also ship with DEBNI.
|
| 49.8 | RIGEL VMS V5.2 Install Problem | KERNEL::BLAND | toward 2000 ... | Sun Oct 22 1989 12:04 | 11 |
| There is a useful STARS article in Database 83 regarding a problem
with installing VMS V5.2 on 6000-4x0 systems.
During the installation the name for the TK70 changes (ie from MUB6
to MUA6) but Standalone Backup does not let you know. The name reverts
back once the Mandatory patch(es) have been applied.
To find: With database 83 selected, type "V5.2 TBK70" at the query
window.
Regards, Norman Bland
|
| 49.9 | show/unibus causes system crash | KERNEL::ROBB | | Sat Dec 02 1989 11:01 | 38 |
| Extract from calypso notes file
<<< SASE::WRKD:[NOTES$LIBRARY]CALYPSO.NOTE;2 >>>
-< CALYPSO -- VAX 6000-xxx Family Notes >-
================================================================================
Note 456.0 SYSGEN>SHOW/UNIBUS causes system crash on 6000-410 8 replies
--------------------------------------------------------------------------------
================================================================================
Note 456.4 SYSGEN>SHOW/UNIBUS causes system crash on 6000-410 4 of 8
-< sho/uni and unexpioint with KLESI. >-
--------------------------------------------------------------------------------
regards
================================================================================
Note 456.6 SYSGEN>SHOW/UNIBUS causes system crash on 6000-410 6 of 8
STAR::JACOBI "Paul Jacobi - VAX/VMS Development" 0 lines 17-NOV-1989 16:49
-< We are aware of the problem - fixed in a future release >-
--------------------------------------------------------------------------------
================================================================================
Note 456.8 SYSGEN>SHOW/UNIBUS causes system crash on 6000-410 8 of 8
STAR::JACOBI "Paul Jacobi - VAX/VMS Development" 10 lines 28-NOV-1989 08:38
-< Description of the fix >-
--------------------------------------------------------------------------------
The "fix" that I refered to is in the error handling code , which will prevent
the system crash.
SGN-40 notes that the SYSGEN>SHOW/UNIBUS should *NEVER* be used on a running
system. This command is only valid during a conversational bootstrap. This is
because the command may destroy some valued device status.
-Paul
|
| 49.10 | milti processor bug | COMICS::ROBB | | Thu Feb 01 1990 14:45 | 252 |
|
+-------------+
| | | | | | | |
|d|i|g|i|t|a|l| I N T E R O F F I C E M E M O R A N D U M
| | | | | | | |
+-------------+
To: list Date: 10 January 1990
From: Richard Holstein
Chris Mega
Dept: VMS Development
DTN: 381-1513, 381-0553
L/MS: ZKO3-4/W23
Net: STAR::HOLSTEIN
STAR::CMEGA
Subject: The "PC�4" Problem on VAX 6000 Model 400 Systems
A few internal sites using VAX 6000 Model 400 systems have seen a
series of crashes, inexplicable until recently. Most often, the
crashes were SSRVEXCEPT bugchecks within RMS. They've been given the
nickname "PC�4" because analysis showed it was possible to understand
the crash if one assumed the PC had been offset by four bytes
(typically, although sometimes other offsets were possible). For
example, the exception PC could show a valid instruction, but the
exception could only have come from an instruction four bytes away.
In other cases, the exception PC would point to an obviously bogus
instruction, but the instruction stream should have executed an
instruction at a offset of plus or minus four bytes.
The bug causing the crashes has been identified. It is in the
CPU chip microcode, and affects only multiprocessing systems. In
brief, two CPUs want to execute from the same page mapped by the same
PTE. The PTE is not valid, and the first CPU gets a page fault. VMS
handles the page fault exception normally, and reaches the instruction
where the first CPU is ready to validate the PTE (by setting PTE<31>).
At that point, a second CPU begins its access of the page through the
invalid PTE. There is a brief window (dependent on cache contents and
XMI traffic) between the point at which the microcode on the second
CPU detects the invalid page and the point at which it again accesses
the PTE to signal the exception. It is in this window that the first
CPU marks the PTE valid. The second access of the PTE by the second
CPU finds a valid PTE. The microcode attempts to recover by restoring
the PC, but the value it uses is left over from previous operations
and corrupts the PC.
Page 2
Under current and previous releases of VMS, only pageable system
space uses shared PTEs, particularly RMS and pageable system services.
(See below for a discussion of future enhancements to VMS.) Shared
global sections are not affected, as each process maps them
separately. Third party or customer-written applications which load
code into pageable system space may be susceptible to the bug.
Increased system page faults increase the probability of seeing the
bug.
Most crashes caused by this bug leave enough of a trace to
identify the cause. The SDA command procedure appended to this memo
gives an example of how to see the bug in a typical crash. Other
crashes will show references to the same page by more than one CPU on
either the kernel or executive mode stacks. In such cases, the
exception PC is often at, or just beyond, the entry point of a
subroutine.
A microcode fix for the bug has been identified and is being
implemented. Plans for its introduction into the field are being
discussed.
Until a hardware fix is available, a software workaround will be
provided. We expect it to have some small impact on system
performance based on the rate of system page faults incurred; a more
precise value for its impact should be available in a few weeks. In
brief, the workaround prevents simultaneous access of the invalid PTE
by causing an interprocessor interrupt when the first CPU is ready to
set the valid bit. This action synchronizes the CPUs, guaranteeing
the validity of the PTE before another CPU attempts to access it.
This temporary workaround will be made available as a VMSINSTAL kit.
On some systems, it may be easier to increase the system working
set count (the SYSGEN SYSMWCNT parameter) until the system page fault
rate is approximately one or two per second. Because it is very
difficult to characterize such a workload-dependent change, and
because it does not absolutely prevent the problem, we are not
generally recommending this change. We emphasize that unlike the
VMSINSTAL kit mentioned above, this change cannot guarantee that the
bug will not occur, but will prevent it on most systems.
The previous paragraphs have included such wording as
"temporary", "current and previous versions of VMS" and "workaround."
The intent is to make it clear that we believe that a complete,
permanent and properly performing fix cannot be done by the software.
The reasons for that belief are:
� It is a poor software engineering practice.
While there have been any number of temporary changes made to
VMS to work around hardware problems, and even a very few
permanent changes, this CPU-specific change differs in that
it is on a path accessible to all CPUs, accessed frequently
during normal operation. CPU-specific code in a generic path
complicates the code and makes it harder to maintain. We
would need to be aware of, and possibly re-implement the
workaround for changes to VMS which perform PTE validation.
Page 3
The same applies to any third party or customer-written
software which handles page faults.
� Future enhancements to VMS will include PTE sharing of P0 and
P1 PTEs.
One of the projects scheduled for the "Thunderbolt" VMS
release includes the ability for a process to split its work
across more than one CPU simultaneously, what we call
multithreaded processes. Such processes will be sharing the
same page tables. A software workaround would then no longer
be able to restrict itself to system page faults, and *all*
page faults would incur the synchronization overhead.
We understand that the cost to Digital of implementing and
retrofitting another pass of the Rigel chip will be several millions
of dollars. Regardless, our recommendation is that a microcode fix to
the PC�4 problem be pursued with high priority, and that it be
retrofitted to all multiprocessing systems.
APPENDIX A
EXAMINING A PC�4 CRASH DUMP
The following command procedure can be invoked under SDA when
examining a suspect crash dump. Most of the time it will enable you
to see the "smoking gun" from the bug -- an indication that the page
containing the exception PC was recently faulted into the system
working set. Failure to find such an indication should not
necessarily be taken to mean that the bug did not occur, just that the
procedure is very limited and simple.
! SMOKING-GUN.COM 30-Oct-1989 Richie Holstein, VMS Development
!
! An SDA command file to show the correspondence between the exception
! PC and recently faulted exec pages for Rigel PC�4 crashes. This
! procedure does not attempt the other part of the proof: showing that
! some other CPU has recently attempted to reference the page on which
! the exception occurred.
!
! Because SDA can't do conditionals, this procedure can only do some of
! the mechanics of finding the faulting PC and the address -- the reader
! has to do the rest.
!
! This procedure assumes that one is set to the crashing CPU, the default
! when SDA is entered.
!
!
!
! Show the PC at which the exception was reported.
!
! Point to argument count in exception frame
Define EXC_FRAME = @SP+1C
! Get the count
Define ARG_COUNT = @@EXC_FRAME
! Point to the exception PC
Define EXC_PC = @EXC_FRAME + (ARG_COUNT-1) * 4
! Examine a bogus "symbol" to produce an SDA message
Examine SHOW_THE_EXCEPTION_PC
Examine EXC_PC
!
!
! Show the last few pages faulted in by the exec. While not definitive,
EXAMINING A PC�4 CRASH DUMP Page A-2
! it is extremely likely that this will show an address in the same page
! as the exception PC. It would be preferable to use an SDA SEARCH
! command instead of an EXAMINE, but there's no way to mask off the low
! order nine bits.
!
! PHD pointer to next available WSE
Define PHD$L_WSNEXT = 18
! Offset to recent WSE slot
Define WSNEXT = @(@MMG$GL_SYSPHD + PHD$L_WSNEXT) * 4
! Examine a bogus "symbol" to produce an SDA message
Examine SHOW_RECENTLY_FAULTED_SYSTEM_PAGES
! Examine a bogus "symbol" to produce an SDA message
Examine THE_PAGE_CONTAINING_THE_EXCEPTION_PC_SHOULD_APPEAR_HERE
! Find page on which exception occurred
Examine @MMG$GL_SYSPHD + WSNEXT-10;14
EXAMINING A PC�4 CRASH DUMP Page A-3
Distribution List
CXO
Steven Brissette
Michael Lehan
Dan Pauly
HLO
Rick Calcagni
Bill LaPrade
Steve Latorella
Al Michaud
Mike Uhler
BXB
John Croll
Ric Haskins
Steve Holmes
Patty Makrianis
John Stevens
Sue Usilton
ZKO
Stan Amway
John Andruszkiewicz
Wayne Cardoza
Stuart Davidson
Stu Farnham
Rod Gamache
Paul Jacobi
Brian Porter
Jean Proulx
|
| 49.11 | Bug mentioned in .10 | KERNEL::WRIGHTON | Pass me a +L-14005 | Fri Feb 02 1990 08:39 | 158 |
|
This is an example of the bug that is detailed in the previous note
-------------------------------------------------------------------
SSRVEXCEPT - EXE$GETJPI+16A R207477J8
TITLE: Bug in 6400 machines
BADGE # OF AUTHOR: 111579
AUTHOR NAME: Dave Wrighton
DATE: 1-Feb-1990
SOURCE: UVO
VMS VERSION: 5.2 ( but could affect all later versions )
BUGCHECK TYPE: SSRVEXCEPT
CPU TYPE: 6420
CURRENT PROCESS:
SIGNAL ARRAY COUNT:
EXCEPTION CODE: Accvio
REASON MASK:
FAULTING VA: AF9466F0 ! remember this for later , its important
EXCEPTION PC: 801A1052
PSL: 00C00000
FAILED INSTRUCTION: BSBW EXE$GETJPI+53C
MODULE OF CRASH: EXE$GETJPI
MODULE OFFSET: 16A
DESCRIPTION:
This is a really good one , so bear with me while I go
around the houses a bit ..... There's no way we can have
an ACCVIO during a BSBW instruction , if anything went
wrong then we only find out when we got there , so the
PC should be the code we went to rather than where we
came from . The VA is really crazy ( AF9466F0 ) , how
did we generate it ? certainly not from the BSBW !
Then , I found out there was a little buggette in the 6400
that could mean that the PC saved on the stack is not
always the PC of the failed instruction !!!
There is a problem ( not annouced yet 1-FEB-1990 ) that
can cause the PC of the failed instruction to be offset
by upto 4 bytes from the instruction that we intended to
execute . Bearing in mind that the PC maybe out by 4 bytes
I then did EX/I EXE$GETJPI+167 ( 4 bytes off PC )
This gave the instruction ....
XORW3 @03CF301D(R0) , @ 558E(R0) , 2F312150(R9)
( R9 contains 806345A0 )
Taking just the 2F312150(R9) , we get ....
R9 = 806345A0
+ 2F312150
--------
AF9466F0 the VA !!
So we must have executed the XORW3 rather than the BSBW
instruction !
This is believed to be a H/W problem in the CPU module
that will not be fixed no how much plating is done . The
real fix will probably be a new rev CPU module , in the
mean time a VMS "fix" should be available "soon" .
I have included part of the session below so we can all
have heart attacks .
The PC on the stack is NOT the PC of the failed instruction
it is the PC+4 !
VAX/VMS System dump analyzer
Dump taken on 31-JAN-1990 16:40:51.90
SSRVEXCEPT, Unexpected system service exception
SDA>sho stack
Process stacks (on CPU 01)
--------------------------
Current operating stack (KERNEL):
7FFE7740 806345A0
7FFE7744 00000000
7FFE7748 001000AF UCB$M_DISMOUNT+000AF
7FFE774C 7FFE7778 CTL$GL_KSTKBAS+00578
7FFE7750 7FFE7760 CTL$GL_KSTKBAS+00560
7FFE7754 7FFE7758 CTL$GL_KSTKBAS+00558
7FFE7758 8000239E EXE$EXCPTN+00006
7FFE775C 00000000
SP => 7FFE7760 00000000
7FFE7764 00000000
7FFE7768 7FF18F50
7FFE776C 7FFE77E4 CTL$GL_KSTKBAS+005E4
7FFE7770 80000014 EXE$QIOW_3+00004
7FFE7774 80174AF2 EXE$CONTSIGNAL+0007C
7FFE7778 00000002
7FFE777C 7FFE779C CTL$GL_KSTKBAS+0059C
7FFE7780 7FFE7784 CTL$GL_KSTKBAS+00584
7FFE7784 00000004
7FFE7788 7FFE77E4 CTL$GL_KSTKBAS+005E4
7FFE778C FFFFFFFD
7FFE7790 00000001 **** R0
7FFE7794 00000415 BUG$_UNXINTEXC+00005
7FFE7798 000008F8 BUG$_INVCTERMMSG+00028
7FFE779C 00000005
7FFE77A0 0000000C
7FFE77A4 00000005
7FFE77A8 AF9466F0 ! VA
7FFE77AC 801A1052 EXE$GETJPI+0016A ! PC but not real one
7FFE77B0 00C00004
7FFE77B4 7FF18F8C
7FFE77B8 00000000
7FFE77BC 7FFE6600 CTL$GL_KRP+00600
7FFE77C0 80173D68 BUG$REBOOT+00B74
7FFE77C4 7FF1BC28
7FFE77C8 00000001
SDA>ex/i 801a1052-20;20
EXE$GETJPI+0014A: NOP
EXE$GETJPI+0014B: XORW3 @-52FF1FC7(R0),@-52FC1FFB(R4),@-52FB1FD1(R0)
EXE$GETJPI+0015B: INSV #2A,@-3FA6(R6),R6,04(SP)
EXE$GETJPI+00163: BRB EXE$GETJPI+0016D
EXE$GETJPI+00165: BBS #01,-10(FP),EXE$GETJPI+00187
EXE$GETJPI+0016A: BSBW EXE$GETJPI+0053C
SDA> ex/i exe$getjpi+167
EXE$GETJPI+00167: XORW3 @03CF301D(R0),@558E(R0),2F312150(R9)
CPU 01 Processor crash information
----------------------------------
General registers:
R0 = 00000000 R1 = 80002398 R2 = 00000004 R3 = 00000004
R4 = 7FFBBCA0 R5 = 00000000 R6 = 00000004 R7 = 7FF18F70
R8 = 7FF18F74 R9 = 806345A0 R10 = 00000000 R11 = 001000AF
AP = 7FFE7778 FP = 7FFE7760 SP = 7FFE7760 PC = 8000239E
PSL = 00000000
TECHNIQUE(s) FOR CONFIRMATION:
SOLUTION/RECO:
PRAY !
REFERENCE:
|
| 49.12 | 6000-4xx RBD Failure | KERNEL::BLAND | toward 2000 ... | Mon Feb 05 1990 06:00 | 84 |
| Subj: BZ 6000-4XXX RDB fails
PROBLEM:
If you bring a VAX 6000-400 series system down using OPCRASH and then
run RBD diagnostics, self-test 0 test 2 will fail unless an INIT is
performed first.
The following failure or one somewhat similar will result if this sequence
of instructions are executed.
$ run sys$system:opccrash
^p
>>> T/R
RBD1> ST0/TR
;XRP_ST 1.00
; T0001 T0002
; F 1 8082 1
; HE UNEXP XX T0002
; 01 00000000 00000014 FFFFFFFF 80000000 2006232B 99
;00000808 05800000 20069678 00000008 000092A8 000055F0 05240001 00000041
; F 1 8082 1
;00000000 00000001 00000000 00000000 00000000 00000000 00000000
RBD1> ST0/TR
;XRP_ST 1.00
; T0001 T0002
; F 1 8082 1
; HE UNEXP XX T0002
; 01 00000000 0000001D 00000060 80000008 2006232B 99
;00000808 05800000 20069678 00000008 000093C0 000055F0 05240001 80010049
; F 1 8082 1
;00000000 00000001 00000000 00000000 00000000 00000000 00000000
RBD1> ST0/TR
;XRP_ST 1.00
; T0001 T0002 T0003 T0004 T0005 T0006 T0007 T0008 T0009 T0010
; T0011 T0012 T0013 T0014 T0015 T0016 T0017 T0018 T0019 T0020
; T0021 T0022 T0023 T0024 T0025 T0026 T0027 T0028 T0029 T0030
; T0031 T0032 T0033 T0034 T0035 T0036 T0037
; P 1 8082 1
;00000000 00000000 00000000 00000000 00000000 00000000 00000000
RBD1>
RESOLUTION/WORKAROUND:
After an unorthodox/catastrophic shutdown, INIT the system before running
RBDs. The above failure would not be seen if the Reset button were hit
or if the system were booted because both methods run through the INIT
routine before running the diagnostics.
ADDITIONAL COMMENTS:
Test 2 of RBD Test 0 is the IPL step down test. In the above case it
fails at IPL 14 and 1D but is not necessarily regular in its failure.
When OPCCRASH halts the CPUs the disk controller, the KDB50, which has an
IPL of 14, recognizes that the CPUs have stopped and sends an interrupt
at IPL 14. However no CPUs are available to service the interrupt.
In addition an Interrupt at IPL 1D is likely to be pending also due
to the REXMI interface second error bit becomming set. (see second
error bit discussion)
Test 2 of RBD 0 considers these as unexpected hard errors and fails.
*** DIGITAL INTERNAL USE ONLY ***
|
| 49.13 | 6000-4xx LA75 cause Hang/Crash | KERNEL::BLAND | toward 2000 ... | Mon Feb 05 1990 06:27 | 41 |
| Subj: BZ 6000-4XX LA75 cause hang/crash
PROBLEM:
The LA75 printer on a VAX 6000-400 system could run out of paper,
hang the console and cause either a system hang or a system crash
after some period of time.
The console hangs. Nothing echoes on the screen. Control P does
not work. No console commands work. If you bring the system down
in an orderly fashion and then try to clear the condition by Resetting
the System using the reset button or rebooting, self test will show a
failure in the LEDs and still not print to the console terminal
suggesting that the primary XRP is bad. NOT SO, OH DIGITAL FIELD SERVICE
GURU! YOU ARE HEADING DOWN THE WRONG PATH!
RESOLUTION/WORKAROUND:
The fault light on the printer should be on. If you have more paper,
put it in the printer and hit Ready button, the printer will begin printing
immediately whatever is in its buffer and the terminal will start receiving
from the CPU. If you do not have more paper, turn off the printer, enter
set up mode on the terminal and clear the condition by selecting the
Printer Set-Up screen and toggling to Normal Print Mode - this allows
you to control the print function from the terminal keyboard. Upon exiting
from Set Up Mode you should start receiving properly.
ADDITIONAL COMMENTS:
Alternatively you could set the printer characteristics to No XOFF. This
of course causes a different set of problems. One being that when you run
out of paper you do not get a record of messages sent to the console. A
second being that XOFF is used to control characters being sent to the printer.
The LA75 has a 2Kbyte buffer and can print up to 250 characters/sec. If the
console baud rate remains at its default setting of 1200 baud, having no
XOFF should not be a problem. However, if the console baud rate is set to
9600, it will be possible to overflow the printer.
*** DIGITAL INTERNAL USE ONLY ***
|
| 49.15 | field microcode message | COMICS::ROBB | | Mon Feb 05 1990 22:18 | 176 |
| ***************************************************************************
This is the statement that has been sent out to the field
***************************************************************************
From: KERNEL::COMICS::BEDDALL "Peter Beddall - Product and Technology Group 05-Feb-1990 1717" 5-FEB-1990 17:22:03.54
To: @6000.DIS,@RTMS.DIS,MEGARITY
CC: BEDDALL
Subj: 6000-400 PC Problem in Multiprocessor Environments
+-------------+
| | | | | | | |
|d|i|g|i|t|a|l| Product and Technology Group
| | | | | | | |
+-------------+
Interoffice Memorandum
To: All 6000 Engineers Date: 5-FEB-1990
From: Peter Beddall
cc: RTMs Ext: 781 4158
Loc/mail stop: UCG Basingstoke
DECnet: COMICS::BEDDALL
Subject: Vax 6000-400 PC Problem in Multiprocessor Environments
There currently exists a problem in the VAX 6000-400 (Rigel) series
of systems which gives rise to apparently random bugchecks, although
most often, the crashes are SSRVEXCEPT bugchecks within RMS.
Although the problem exists in the microcode of the VAX 6000-400 it
is only manifest in multiprocessor configurations, as explained in
more detail below. There is a software workaround for this problem,
and the VMS patch can be obtained by calling the System Diagnosis
Group in the Customer Support Center, who will either be able to
downline load the patch onto the target system or supply it across
the network.
I suggest that for the time being, that this patch is only installed
on affected systems. Again details on identifying affected systems
are given below.
If anyone requires any further details on this, then please do not
hesitate to call.
Regards
Pete Beddall
ANALYSIS
The bug causing the crashes is within the CPU chip microcode, and
affects only multiprocessing systems. In brief, two CPUs want to
execute from the same page mapped by the same PTE. The PTE is not
valid, and the first CPU gets a page fault. VMS handles the page
fault exception normally, and reaches the instruction where the
first CPU is ready to validate the PTE (by setting PTE<31>). At that
point, a second CPU begins its access of the page through the
invalid PTE. There is a brief window (dependent on cache contents
and XMI traffic) between the point at which the microcode on the
second CPU detects the invalid page and the point at which it again
accesses the PTE to signal the exception. It is in this window that
the first CPU marks the PTE valid. The second access of the PTE by
the second CPU finds a valid PTE. The microcode attempts to recover
by restoring the PC, but the value it uses is left over from
previous operations and corrupts the PC.
The failures have been given the nickname "PC�4" because analysis
showed it was possible to understand the crash if one assumed the PC
had been offset by four bytes (typically, although sometimes other
offsets were possible). For example, the exception PC could show a
valid instruction, but the exception could only have come from an
instruction four bytes away. In other cases, the exception PC would
point to an obviously bogus instruction, but the instruction stream
should have executed an instruction at a offset of plus or minus
four bytes.
EXAMINING A PC�4 CRASH DUMP
The following command procedure can be invoked under SDA when
examining a suspect crash dump. Most of the time it will enable you
to see the "smoking gun" from the bug -- an indication that the page
containing the exception PC was recently faulted into the system
working set. Failure to find such an indication should not
necessarily be taken to mean that the bug did not occur, just that
the procedure is very limited and simple.
! SMOKING-GUN.COM 30-Oct-1989 Richie Holstein, VMS Development
!
! An SDA command file to show the correspondence between the exception
! PC and recently faulted exec pages for Rigel PC�4 crashes. This
! procedure does not attempt the other part of the proof: showing that
! some other CPU has recently attempted to reference the page on which
! the exception occurred.
!
! Because SDA can't do conditionals, this procedure can only do some of
! the mechanics of finding the faulting PC and the address -- the reader
! has to do the rest.
!
! This procedure assumes that one is set to the crashing CPU, the default
! when SDA is entered.
!
!
!
! Show the PC at which the exception was reported.
!
! Point to argument count in exception frame
Define EXC_FRAME = @SP+1C
! Get the count
Define ARG_COUNT = @@EXC_FRAME
! Point to the exception PC
Define EXC_PC = @EXC_FRAME + (ARG_COUNT-1) * 4
! Examine a bogus "symbol" to produce an SDA message
Examine SHOW_THE_EXCEPTION_PC
Examine EXC_PC
!
!
! Show the last few pages faulted in by the exec. While not definitive,
! it is extremely likely that this will show an address in the same page
! as the exception PC. It would be preferable to use an SDA SEARCH
! command instead of an EXAMINE, but there's no way to mask off the low
! order nine bits.
!
! PHD pointer to next available WSE
Define PHD$L_WSNEXT = 18
! Offset to recent WSE slot
Define WSNEXT = @(@MMG$GL_SYSPHD + PHD$L_WSNEXT) * 4
! Examine a bogus "symbol" to produce an SDA message
Examine SHOW_RECENTLY_FAULTED_SYSTEM_PAGES
! Examine a bogus "symbol" to produce an SDA message
Examine THE_PAGE_CONTAINING_THE_EXCEPTION_PC_SHOULD_APPEAR_HERE
! Find page on which exception occurred
Examine @MMG$GL_SYSPHD + WSNEXT-10;14
Distribution:
! Regional Technical Managers Dist List
NM%thesun::mrgate::"UVO::GERRY COLE"
NM%thesun::mrgate::"DBO::PAT CRAWFORD"
NM%thesun::mrgate::"OLO::DAVE GRIEVE"
NM%WELMTS::HEAD
NM%thesun::mrgate::"HHL::PETER WITTON"
nm%42073::mckee
nm%bahtat::lawrence
nm%bahtat::rushworth
nm%brew11::bayliss
nm%brunel::daveo
nm%comics::beddall
nm%comics::lindley
nm%dub01::ashford
nm%gallop::bushm
nm%grot::leate
nm%jockey::allenk
nm%kernel::bland
nm%kernel::robb
nm%kernel::wibrew
nm%neeps::murdoch
nm%not001::stanley
nm%sedsws::davies_d
nm%thesun::mrgate::"ubo::allen maskell"
nm%vivian::house
nm%vivian::langford
nm%warnut::roberts
nm%war750::ball
nm%welsws::griffin
|
| 49.16 | t2015 handling procedures | COMICS::ROBB | | Mon Feb 05 1990 22:20 | 156 |
| Subj: T2015 (Rigel CPU) Handling Procedures
+-------------+
| | | | | | | |
|d|i|g|i|t|a|l| Product and Technology Group
| | | | | | | |
+-------------+
Interoffice Memorandum
To: All 6000 Engineers Date: 5-FEB-1990
From: Peter Beddall
cc: RTMs Ext: 781 4158
Loc/mail stop: UCG Basingstoke
DECnet: COMICS::BEDDALL
Subject: T2015 (Rigel CPU) Module Handling
The T2015 the CPU module in the 6000-400 system is especially
sensitive to mechanical handling. Recently on several sites, a
number of CPU modules have been damaged, requiring repair. The T2015
module is a very expensive module, and costs Customer Services
$1000.50 for each repair, (excluding engineer time, handling,
shipping...) As the module technology advances this problem will
only grow, for example the Rigel Vector module uses 25 mil
components on both sides. It is therefore essential that we learn
good module handling practices now, before the cost of damaged
modules escalates further. This memo highlights some of the
precautions that should be taken in handling these modules.
Reference is made to a new module shipping box, which is blue or
grey in colour and is part number 99-08536-01. I suggest that each
branch order about 10 empty boxes from logistics to assist in
upgrades/downgrades/fault situations where T2015 modules are
remove/transported but other source of module containers are
unavailable. In order to assist logistics with purchasing these
parts that are normally not stocked, could you send your
requirements, marked for the attention of Mohammed Siddiq at
Winnersh within the next 2 weeks.
Information about module handling, plus other additional VAX
6000-400 information is available within the maintenance Advisory,
available electronically from:
COMICS::SYS$PUBLIC:RIGEL_MAINT_ADV.PS
COMICS::SYS$PUBLIC:RIGEL_MAINT_ADV_INDX.PS
If anyone requires any further information then please do not
hesitate to call.
Regards
Pete Beddall
HOLDING the T2015 MODULE
o Always wear an anti-static wrist strap.
o Before removing the module from its ESD box, place the box on
a clean, stable surface.
o Be sure the box will not fall or slide. NEVER place the box
on the floor. And be sure no tools, papers, manuals,
or anything else that might damage the module are near
it. Components on this module are susceptible to damage
by a 600-volt static charge. Paper carries a 1000 volt charge.
o Hold the module only by the edges.
o Do not hold the module so that your fingers touch any
components or leads. Be sure you do not bend the module as
you are holding it.
o Be sure nothing touches the module surface or any of its
components.
INSTALLING the T2015
If anything touches the module, components or leads can be damaged.
This includes the anti-static wrist strap, clothing, jewellery,
cables, repair tags, and components on other modules. Remove your
jacket and roll up your sleeves before handling the module. Also
remove any jewellery. Be sure, when inserting the module in or
removing it from the XMI card cage, that no part of the module comes
in contact with another module or a cable.
When swapping out a module, set the module you remove, in an unused
XMI slot until it can be placed in an empty ESD box. If an empty XMI
slot is not available, place the module on a grounded anti-static
surface, side two down (side two has only components with 50 mil
leads, side one contains the BIG chips with 25 mil leads). NEVER
stack modules one on another.
Hold the XMI card cage handle while removing or inserting the
module. If it is not held in place, the handle can spring down and
damage the module.
When inserting the module in the card cage, grasp the module only in
the area near the LEDs and the VIB connector, and slide it slowly
and gently into the slot.
NEVER place a T2015 module in the black plastic module boxes used
for other XMI modules. The foam in these boxes will damage
components. Only use the special blue or grey boxes 99-08536-01,
which secure the module by its edge only.
REPAIR TAG
DO NOT attach repair tag to module. Place the repair tag in the
plastic bag attached to the ESD box.
Distribution:
! Regional Technical Managers Dist List
NM%thesun::mrgate::"UVO::GERRY COLE"
NM%thesun::mrgate::"DBO::PAT CRAWFORD"
NM%thesun::mrgate::"OLO::DAVE GRIEVE"
NM%WELMTS::HEAD
NM%thesun::mrgate::"HHL::PETER WITTON"
nm%42073::mckee
nm%bahtat::lawrence
nm%bahtat::rushworth
nm%brew11::bayliss
nm%brunel::daveo
nm%comics::beddall
nm%comics::lindley
nm%dub01::ashford
nm%gallop::bushm
nm%grot::leate
nm%jockey::allenk
nm%kernel::bland
nm%kernel::robb
nm%kernel::wibrew
nm%neeps::murdoch
nm%not001::stanley
nm%sedsws::davies_d
nm%thesun::mrgate::"ubo::allen maskell"
nm%vivian::house
nm%vivian::langford
nm%warnut::roberts
nm%war750::ball
nm%welsws::griffin
|
| 49.17 | Subj: T2015 (Rigel CPU) Handling Procedures | COMICS::ROBB | | Tue Feb 06 1990 18:24 | 124 |
| *****************************************************************************
Message as sent to the field. please do not hesitate to remind engineers
when giving assistance
*****************************************************************************
+-------------+
| | | | | | | |
|d|i|g|i|t|a|l| Product and Technology Group
| | | | | | | |
+-------------+
Interoffice Memorandum
To: All 6000 Engineers Date: 5-FEB-1990
From: Peter Beddall
cc: RTMs Ext: 781 4158
Loc/mail stop: UCG Basingstoke
DECnet: COMICS::BEDDALL
Subject: T2015 (Rigel CPU) Module Handling
The T2015 the CPU module in the 6000-400 system is especially
sensitive to mechanical handling. Recently on several sites, a
number of CPU modules have been damaged, requiring repair. The T2015
module is a very expensive module, and costs Customer Services
$1000.50 for each repair, (excluding engineer time, handling,
shipping...) As the module technology advances this problem will
only grow, for example the Rigel Vector module uses 25 mil
components on both sides. It is therefore essential that we learn
good module handling practices now, before the cost of damaged
modules escalates further. This memo highlights some of the
precautions that should be taken in handling these modules.
Reference is made to a new module shipping box, which is blue or
grey in colour and is part number 99-08536-01. I suggest that each
branch order about 10 empty boxes from logistics to assist in
upgrades/downgrades/fault situations where T2015 modules are
remove/transported but other source of module containers are
unavailable. In order to assist logistics with purchasing these
parts that are normally not stocked, could you send your
requirements, marked for the attention of Mohammed Siddiq at
Winnersh within the next 2 weeks.
Information about module handling, plus other additional VAX
6000-400 information is available within the maintenance Advisory,
available electronically from:
COMICS::SYS$PUBLIC:RIGEL_MAINT_ADV.PS
COMICS::SYS$PUBLIC:RIGEL_MAINT_ADV_INDX.PS
If anyone requires any further information then please do not
hesitate to call.
Regards
Pete Beddall
HOLDING the T2015 MODULE
o Always wear an anti-static wrist strap.
o Before removing the module from its ESD box, place the box on
a clean, stable surface.
o Be sure the box will not fall or slide. NEVER place the box
on the floor. And be sure no tools, papers, manuals,
or anything else that might damage the module are near
it. Components on this module are susceptible to damage
by a 600-volt static charge. Paper carries a 1000 volt charge.
o Hold the module only by the edges.
o Do not hold the module so that your fingers touch any
components or leads. Be sure you do not bend the module as
you are holding it.
o Be sure nothing touches the module surface or any of its
components.
INSTALLING the T2015
If anything touches the module, components or leads can be damaged.
This includes the anti-static wrist strap, clothing, jewellery,
cables, repair tags, and components on other modules. Remove your
jacket and roll up your sleeves before handling the module. Also
remove any jewellery. Be sure, when inserting the module in or
removing it from the XMI card cage, that no part of the module comes
in contact with another module or a cable.
When swapping out a module, set the module you remove, in an unused
XMI slot until it can be placed in an empty ESD box. If an empty XMI
slot is not available, place the module on a grounded anti-static
surface, side two down (side two has only components with 50 mil
leads, side one contains the BIG chips with 25 mil leads). NEVER
stack modules one on another.
Hold the XMI card cage handle while removing or inserting the
module. If it is not held in place, the handle can spring down and
damage the module.
When inserting the module in the card cage, grasp the module only in
the area near the LEDs and the VIB connector, and slide it slowly
and gently into the slot.
NEVER place a T2015 module in the black plastic module boxes used
for other XMI modules. The foam in these boxes will damage
components. Only use the special blue or grey boxes 99-08536-01,
which secure the module by its edge only.
REPAIR TAG
DO NOT attach repair tag to module. Place the repair tag in the
plastic bag attached to the ESD box.
|
| 49.18 | Subj: Rigel pc-/+ 4 problem | COMICS::ROBB | | Tue Feb 06 1990 18:27 | 27 |
| ********************************************************************************
Patch for PC +- 4 problem
********************************************************************************
COMPANY CONFIDENTAIL
A microcode problem affecting Rigel Multi CPU systems,
6000-420 - 6000-460, has recently come to light. A full description
can be found in NOTES conf VMS_PATCHES note 102.
The patch is available on COMICS or KERNEL
VMSPC4052.A and VMSPC4052.README
In order to assist ESASE and Engineering it is most important that we
log each time the problem is seen. Please write a reply to
VMS_patches note 102 if you identify the problem on a system and/or
supply the patch.
Just a general reminder - If you identify a problem thats fixed with
a patch, please reply to the notes artice on VMS_patches. If the notes
artcle does not exsist, then please advise TSC.
|
| 49.19 | Subj: T2012 Problems - URGENT!! | COMICS::ROBB | | Tue Feb 06 1990 19:33 | 331 |
| Subj: T2012 Problems - URGENT!!
To 6000 Engineers,
Enclosed is a memo detailing a manufacturing problem with the T2012
(XBIA) module that will impact machines about to be installed, and some
already installed. It has already been sent to Installation Managers.
I am trying to find more technical details around which component is
incorrect, and possible problem symptoms, which I will forward when I
receive it. In the meantime if you have any technical concerns then
please contact me.
Regards
Pete Beddall
From: NAME: GERRY REILLY @GAO
FUNC: QUALITY ASSURANCE
TEL: 7822-2465 <REILLY.GERRY AT GAOV08A1 at GAOV08 at GAO>
To: See Below
CC: See Below
Attached is the description of the problem and a listing of all
the Dec Numbers involved for week 3 and 4 shipments. Please
note all the Dec Numbers within your area and take the
appropriate action.
Please let me know by return which Dec numbers each of you will
actually work so that none slip through the cracks.
I N T E R O F F I C E M E M O R A N D U M
Date: 01-Feb-1990 03:29pm GMT
From: JACQUELINE BURKE @GAO
BURKE.JACQUELINE
Dept: IE MSSB QUALITY
Tel No: 2652
TO: Dist. List Suppressed type "SH" to view
Subject: XBIA - (T2012) PROBLEM
TO ALL CUSTOMER Q.A. PROJECT MANAGERS
Due to an error in the XBIA manufacturing process, a number of
modules have been shipped in 6000-XXX systems which may cause intermittent
errors. The problem was caused by the placement of a capacitor of wrong
value in one location on the board. Due to the fact that the problem
manifests itself intermittently, under specific voltage conditions, some of
the modules escaped our test process. It is difficult to determine whether
and to what extent they will now fail in the field. The fact that there is
doubt is sufficient to warrant their replacement.
Please note the following facts:
- The problem is confined to shipments from the Galway plant in
weeks 3 and 4 of January. 74 DEC numbers (148 modules) are
affected.
- All the affected DEC Numbers and related module serial numbers
have been identified.
- Replacement modules are being provided by the plant and will be
shipped from here no later than Tuesday the 6th of February.
Since those systems shipped in the past three weeks, it is likely
that a number of them have not yet been installed. We would like to get
the modules to the customer sites prior to installation to reduce the
visibility to our customers. Please organize with the relevant
installation teams the process for sending out the replacements and the
returning of the affected modules. We will do all we can to accommodate
any priority installations before the full batch of replacements are ready
on Tuesday.
Be assured that an investigation has been carried out to understand
the failing in our process which allowed this to happen. This is now
understood and rectified.
Regards,
Jacqui Burke
Senior Quality Engineer
I have arranged the following plan with Wim Koevoets in Nijmegen
(JGO).
1. Galway will ship the 148 replacement modules to Logistics in
Nijmegen next Tuesday along with a listing of all defective Dec
Numbers shipped.
(The following inputs are from Wim Koevoets)
>>> COUNTRY INSTALLATION MANAGERS SHOULD CONTACT THEIR CLO
SERVICES MATERIAL PLANNER (FOR CALYPSO) AND INFORM
THEM:
- WHAT'S GOING ON
- THAT SOON THEY WILL BE REQUESTED TO PLACE AN ORDER
FOR THE COUNTRY ALLOCATION
- HOW THAT ALLOCATION WILL BE HANDLED INSIDED THE
COUNTRY
- WHEN AND HOW THE SUSPECT MODULES WILL GET BACK TO THE
CLO
- THAT THIS QUANTITY AND ONLY THIS QUANTITY WILL FALL
UNDER THIS SPECIAL PROGRAM
- HOW THEY EXPECT THE COUNTRY INTERNAL FLOW TO BE
ARRANGED
2. Wim will organize the logistics of distributing the
replacements to the various countries.
>>> AS FOLLOWS:
WIM WILL ALLOCATE THE MODULES TO COUNTRIES IN
ACCORDANCE WITH THE INFORMATION PROVIDED
(DECNO'S/COUNTRY)
NIJMEGEN CUSTOMER SERVICES DESK WILL APPROACH COUNTRY
LOGISTICS PLANNERS TO PLACE ORDER FOR THEIR ALLOCATED
LOT.
3. All the defectives will be returned to JGO on a swap basis
for subsequent return to Galway Plant.
>>> AT THE SAME TIME AS 2. WE WILL GATHER INFORMATION FROM
THE PLANNER WHEN (SEE 1) WE CAN EXPECT THE RETURNS.
AT THAT POINT IN TIME NIJMEGEN WILL PROVIDE RA TO
RETURN THEM FROM EACH COUNTRY.
Please inform your local and Country Logistics organizations of
the problem and replacement plan so that we can ensure a smooth
recovery.
If there are problems as a result of this plan dont hesitate to
contact me.
Rgds for now.
Frank
WK3 JANUARY
------------
ENGLAND:
F.S.CODE CUSTOMER NAME DEC NO SERIAL NUMBERS
OF T2012's
7A5 DIGITAL EQUIPMENT CO 900310157 GA95038918
GA94938875
7A5 U.K ATOMI 900287503 GA95038931
GA95038938
7A5 DIGITAL EQUIPMENT CO 900310079 GA94538571
L78 DIGITAL EQUIPMENT CO 900310135 GA95038901
GA95038900
7A5 DIGITALEQUIPMENT CO 900310175 GA00139041
GA00138955
GA95038901
GA95038920
7A5 DIGITAL EQUIPMENT CO 900310155 GA95038811
GA95038922
GA95038811
GA95038922
7A8 GLAXO GROUB RESEARCH 900292102 GA00138972
GA95038944
7OC ARMITAGE SHANKS LTD 890319592 GA95038912
GA00138971
WEST GERMANY:
9MN BOGE GMBH 900104117 GA00139036
GA95038926
730 DIGITAL EQUIPMENT GM 900150192 GA93937899
GA94938867
GA00139017
GA95038929
730 DIGITAL EQUIPMENT GM 900150313 GA95038917
GA95038883
GA95038904
GA95038914
9MH MICHELIN REIFENWERKE 900126793 GA95038925
GA93937900
730 DIGITAL EQUIPMENT GM 900150178 GA00139044
GA00138976
730 DIGITAL EQUIPMENT GM 900150176 GA94738763
GA95038907
7OD ROBERT BOSCH GMBH 900124135 GA00138979
GA95038903
730 SIEMENS AG 900134118 GA95038889
GA95038898
730 DLR DEUTSCHE FORSCH 900133465 GA94938801
GA95038886
7OD VOLKSWAGEN AG 900093212 GA95038895
GA95038915
NETHERLANDS:
7YS PTT TELECOM BV 900163605 GA00138958
GA94738781
7YT DSM LIMBURG SERVICES 900163509 GA00138988
GA00139026
7YT DIGITAL EQUIPMENT 900159988 GA00138982
GA95038905
GA94238230
GA00138947
FINLAND:
74B VALIO MEIJERIEN KESK 900039209 GA94938879
GA94738764
74B VALIO MEIJERIEN KESK 900039192 GA00138976
B GA00138796
74B DATIVO Oy 900039226 GA95038924
GA95038909
SWITZERLAND:
7DY GENERALDIREKTION PTT 900269469 GA95038882
GA94738780
GA00138983
GA00139017
GC9 DIGITAL EQUIPMENT 900940661 GA95038923
GA94938802
MIDDLE EAST:
7P4 NATCOM 900304687 GA94938868
GA95038940
FRANCE:
G8F CP GESTION 900069454 GA94338370
GA00138919
ITALY:
9LZ AGENZIA ANSA AG.NAZ 900202612 GA95038906
GA95038899
SWEDEN:
DIGITAL EQUIPMENT 900243278 GA00138981
GA94638612
BELGIUM:
7Q2 LABORELEC SC CV 900025737 GA95038910
ISRAEL:
LWG DIGITAL EQUIPMENT 900174583 GA00138957
GA95038921
WK4 JAN
F.S. CODE CUSTOMER NAME DEC NO SERIAL NO
ENGLAND: 7A8 MCDONNELL DOUGLA IN 900302439 GA95038932
GA95038939
7OC BRITISH GAS 900293826 GA00239048
GA00139028
GA00139033
GA00138959
GA00139044
GA00138991
7OA INMOS LTD 900289935 GA00239049
GA00239053
L78 CENTRAL ELECTRICITY 900281509 GA0023907
GA00138968
7J5 BP INTERNATIONAL 900281518 GA00138978
L78 MITSUI TRUST BANKI 900284683 GA95038902
GA94338366
70A RSRE 900286035 GA00139013
GA00139020
L78 NORFOLK HOUSE DATA L 900280434 GA00139012
GA00138946
7J5 CRANFIELD INSTITUDE 900293267 GA00139035
GA00139034
7OA FERRANTI COMPUTER SY 900289931 GA00239067
GA94938878
L78 MITUSI TRUST BANKI 900284682 GA00139002
GA00139046
7LD BP CHEMICALS LTD 900281519 GA95038943
GA95038934
FRANCE: 7Y8 SNCF 900076701 GA00139043
GA00138945
7Y8 SNCF 900076698 GA00138948
GA00139030
7Q3 INSTITUT NATIONAL DE 900073022 GA00138954
L3D DIRECTION DES CONSTR 900062119 GA95038944
GA00239062
G8H SPOT IMAGE 900061548 GA00138987
GA00138981
L4N STE BOURSE NOUAILHET 900053605 GA94938804
GA95038891
73D COMPAGNIE NATIONAILE 900057979 GA00138989
GA00139007
W.GERMANY LID MICHELIN REIFENWERKE 900126812 GA94338455
GA95038913
LID LANDESMUSEUM FUR TEC 900117967 GA00138970
GA00138973
9MH LUK LAMELLEN-U.KUPPL 900125888 GA00138974
GA95038942
7I8 SIEMENS AG 900587507 GA00138990
GA00139010
SWITZERLAND 7OF ELEKTROWATT 900264185 GA3379612
GA00139042
LAF METAUX PRECIEUX S.A. 900276215 GA00239064
GA00239063
LAF BOBST S.A. 900276224 GA00138977
GA93937898
BELGIUM: 7Q2 FORD MOTOR COMPANY B 900025598 GA00138994
GA00239060
7Q2 KEMIRA SA NV 900025702 GA94738684
GA94938876
ITALY: 7YG ITALTEL SOCIETA ITA 900179682 GA00239074
GA00239051
GA00139032
GA00138993
NETHERLANDS:78G LUMMUS CREST BV 900161391 GA95038927
GA00139024
SWEDEN: LDY RADIOTJANST I KIRUNA 900249334 GA00139013
DENMARK: 73H JYDSK TELEFON A/S 90003207 GA93737564
GA95038935
|
| 49.20 | Subj: Incorrect Revision Labels on T2015 modules | COMICS::ROBB | | Wed Feb 07 1990 20:36 | 48 |
| Subj: Incorrect Revision Labels on T2015 modules
+-------------+
| | | | | | | |
|d|i|g|i|t|a|l| Product and Technology Group
| | | | | | | |
+-------------+
Interoffice Memorandum
To: 6000 Engineers Date: 7-FEB-1990
From: Peter Beddall
cc: Ext: 781 4158
Loc/mail stop: UCG Basingstoke
DECnet: COMICS::BEDDALL
Subject: Identifying Correct T2015 Module Revisions
During the implementation of an ECO in Galway, taking the T2015
module from revision F04 to H04, several modules were correctly
ECO'd but failed to update the module revision labels. The labels
indicated that the module was revision F04, but in fact it was
really H04. 12% of the modules returned to Galway for repair,
believed to be below revision suffered this problem. In order to
reduce the module return rate, for these otherwise functional
modules, then the following identifies the true module revision. If
an incorrect label is identified, then please modify it accordingly.
Rigel module revisions: The T2015 went from F04 to H04 with the
following component changes:
21-25087-01 in location E26 changed to 21-25087-05
12-23825-49 in location R66 changed to 13-23825-53
The T2015 went from H04 to H05 with the new etch layout, removing
all the ECO wires.
Regards
Pete
|
| 49.21 | Subj: Recovery from EEPROM corruption on VAX 6000-400 | COMICS::ROBB | | Wed Feb 07 1990 20:37 | 80 |
| Subj: Recovery from EEPROM corruption on VAX 6000-400
+-------------+
| | | | | | | |
|d|i|g|i|t|a|l| Product and Technology Group
| | | | | | | |
+-------------+
Company Confidential Interoffice Memorandum
To: 6000 Engineers Date: 6-FEB-1990
From: Peter Beddall
cc: Ext: 781 4158
Loc/mail stop: UCG Basingstoke
DECnet: COMICS::BEDDALL
Subject: T2015 EEPROM Failures and spares
There is currently a shortage of replacement T2015 modules in
Europe, hence there is a need to replace only those T2015 modules
that are actually defective, hence this memo, and the previous ones.
I will also continue to send out as much information as possible
over the next few weeks, in an effort to reduce T2015 module
consumption. In addition if any engineers have any information
regarding module failures that may assist Galway Manufacturing or
the field, then would they please pass that information on to me or
Brian Lindley (who is away for the next three weeks)
Galway, who repair the T2015 module, report that 8% of module
returns are due to EEPROM corruption. In general, all instances of
EEPROM corruption are fixable in the field and do not require
replacement modules. It does, in many cases, however require some
forethought.
EEPROM contents can be restored from TK tape using the RESTORE
EEPROM command from the affected processor, provided of course that
a SAVE EEPROM has been done at some time previously. It is
therefore a good idea that EEPROM contents are saved at system
installation time after it has been correctly configured.
A difficulty that may be encountered is the correct identification
of a corrupt EEPROM. In a multiprocessor configuration, then
generally any node with a bad EEPROM would fail its power-up self
test, the results of which would be printed out. It would then be
necessary to further identify the failure by running RBDs on the
failing CPU. If the RBDs indicate the EEPROM failure (typically RBD
0 T0009) then a restore of the EEPROM should be attempted.
If, as would be the case in a single CPU environment, all
processors fail self test, then little or no printout would be
obtained and the console would appear dead. In this case the
command >>n, where n is the CPU node number, would force the
console to that node, and then normal console commands and RBDs can
be used, including RESTORE EEPROM.
However, if the Console were unable to read the correct baud rate
from the EEPROM, then it would default to 1200 Baud. It is
therefore suggested that all consoles are set and left at 1200 Bd.
In summary, please try and identify further all CPU failures by
running RBDs, and if necessary attach to the CPU by means of >>n
and possibly setting the baud rate to 1200 Bd. If EEPROM corruption
is a possibility then please try and restore it. Details on the
console commands and RBD failures are to be found in the VAX
6000-400 Options and Maintenance Guide.
Regards
Pete
|
| 49.22 | Subj: CI Microcode revision problem on new 6000 systems | COMICS::ROBB | | Fri Feb 09 1990 16:37 | 181 |
| *******************************************************************************
This problem can be fixed remotely if no site engineer..... Ken
********************************************************************************
From: KERNEL::COMICS::BEDDALL "Peter Beddall - Product and Technology Group 09-Feb-1990 0940" 9-FEB-1990 09:53:57.44
To: @6000.DIS
CC: BEDDALL
Subj: CI Microcode revision problem on new 6000 systems
Hi All,
This is another thing to look out for on new installs.
As always, any problems let me know.
cheers
Pete
A number of 6000 series systems have been shipped from Galway during
December '89 and January '90 which have the wrong version of CIBCI-B
microcode loaded.
This results in catastrophic errors when the new machine is booted
into the cluster.There are two symptoms -
i)The other nodes in the cluster gradually hang.
ii)Errors and logged against PA00 on CI members of the cluster,these
errors are of the format PACKET SIZE VIOLATION with the remote
node being the new 6400.
iii)CI node eventually crashes with a SSRVEXCEPT, Unexpected system
service exception and on reboot hangs until 6400 is taken down.
SOLUTION
Identify the revision of CI microcode.
On a running system use the SHOW CLUSTER/CONTIN ultility and add the
revision fields using the ADD RP_REV command within the utility. If the
CIBCA revision is shown as 40024001 then this is the old revision of
microcode and must be updated. The correct version will be shown as
40054002.
The version of microcode can also be identified and upgraded by using
the diagnostic EVGDA, the EEPROM programming and update tool.
ANALYSIS
A typical errorlog highlighting the problem is shown below
V A X / V M S SYSTEM ERROR REPORT COMPILED 8-FEB-1990 10:53
PAGE 37.
******************************* ENTRY 278. *******************************
ERROR SEQUENCE 2588. LOGGED ON: SID 0A000002
DATE/TIME 5-FEB-1990 19:19:49.09 SYS_TYPE 02310001
SCS NODE: LOOKIN VAX/VMS V5.2
ERL$LOGMESSAGE ENTRY KA62A CPU REV# 3. FW REV# 3.1
XMI NODE # 1.
BI SUB-SYSTEM, _LOOKIN$PAA0: - PORT WILL BE RE-STARTED
SOFTWARE SHUTTING DOWN PORT
LOCAL STATION ADDRESS, 000000000003 (HEX)
LOCAL SYSTEM ID, 00000000A627 (HEX)
REMOTE STATION ADDRESS, 000000000002 (HEX)
REMOTE SYSTEM ID, 00000000A42A (HEX)
UCB$B_ERTCNT 0B
11. RETRIES REMAINING
UCB$B_ERTMAX 32
50. RETRIES ALLOWABLE
UCB$W_ERRCNT 0028
40. ERRORS THIS UNIT
PPD$B_PORT 02
REMOTE NODE #2.
PPD$B_STATUS E1
FAIL
PACKET SIZE VIOLATION
PPD$B_OPC 10
DATSNT
PPD$B_FLAGS 60
PACKET MULTIPLE 6
- PACKET SIZE 3584. BYTES
PORT RESPONSE
AA6D0003
9761001F
00000108
6F08003B
00000000
0EB1000A
00000000
81D957C0
00FB0000
80F8CFFC
00000000
00000000
00000000
00000000
00000000
811EAB53
811EAB3F
V A X / V M S SYSTEM ERROR REPORT COMPILED 8-FEB-1990 10:53
PAGE 38.
******************************* ENTRY 280. *******************************
ERROR SEQUENCE 2618. LOGGED ON: SID 0A000003
DATE/TIME 5-FEB-1990 20:19:00.91 SYS_TYPE 02310001
SCS NODE: LOOKIN VAX/VMS V5.2
FATAL BUGCHECK KA62A CPU REV# 4. FW REV# 3.1
XMI NODE # 2.
SSRVEXCEPT, Unexpected system service exception
PROCESS NAME DDS$55_i1
PROCESS ID 0001008F
ERROR PC 8000239E
ERROR PSL 00020000
INTERRUPT PRIORITY LEVEL = 02.
PREVIOUS MODE = KERNEL
CURRENT MODE = KERNEL
STACK POINTERS
KSP 7FFE76E4 ESP 7FFE9764 SSP 7FFED800 USP 7FF53278 ISP 808211F8
GENERAL REGISTERS
R0 00000000 R1 80002398 R2 4F525252 R3 7FFE77A8 R4 81148CA0
R5 80004DA8 R6 7FF658B8 R7 02000000 R8 7FF532E8 R9 7FFE77D0
R10 7FFE77D8 R11 001F2B00 AP 7FFE7768 FP 7FFE7750 SP 7FFE7748
SYSTEM REGISTERS
P0BR 8A31B000
P0 PTE BASE (VIRT ADDRS)
P0LR 00001DFE
TOTAL P0 PAGES
P1BR 89D3DE00
P1 PTE BASE (VIRT ADDRS)
P1LR 001FFA88
TOTAL NON-EXISTENT P1 PAGES
SBR 07A58600
SYSTEM PTE BASE (PHYS ADDRS)
SLR 00167B00
TOTAL PAGES "SYSTEM" VIRT MEM
PCBB 059F3820
PCB BASE (PHYS ADDRS)
SCBB 07A4C000
SCB BASE (PHYS ADDRS)
ASTLVL 00000004
NO AST'S PENDING
SISR 00000000
INTERRUPT REQUEST ACTIVE = 0.
ICCS 00000040
INTERRUPT ENABLE
TODR 2275DAF8
|
| 49.23 | Subj: More info on T2015 repairs | COMICS::ROBB | | Fri Feb 09 1990 16:39 | 146 |
| From: KERNEL::COMICS::BEDDALL "Peter Beddall - Product and Technology Group 09-Feb-1990 1007" 9-FEB-1990 10:18:55.69
To: @6000.DIS
CC:
Subj: More info on T2015 repairs
Hi All,
I have had a request to send out more details on the T2015 problems, and
how Galway are doing their best to tackle it, and so in turn assist you
in understanding and fixing the problems in the field today. So here is
the information. If you have any feedback or comments on it, then please
pass it via me. Also remember to keep this information
********************
COMPANY CONFIDENTIAL.
********************
Cheers
Pete
The following is a status update on the T2015's returned to
Galway for repair. Of 38 modules returned to date, we have analyzed/repaired
25. The problem breakdown was:
No Problem Found 28%
ECO wire short/open 24%
Solder short/Dry joint 16%
Wrong rev label on module 12%
Corrupt EEPROM 8%
Part electrically bad 8%
Module out of rev 4%
All the NPF's were tested extensively..72 hours in Burn-in and
a further 14 hours in system level test. It is difficult to say what caused
the module to appear defective in the field. We will do some more detailed
analysis on future NPF's provided there is not a turn around time constraint on
returning the repairs to the field. Wim, we can talk about this.
As you can see from the above, 44% of all returns had no
"functional" problem. We have put corrective actions in place to deal with
the process problems, particularly the wiring faults we have seen. Note that
while wiring on a board may appear unattractive, it is an acceptable
manufacturing process. The presence of wires on a board does not deem it
unreliable. The suggestion to replace all wired boards in the field is neither
necessary nor viable.
We are very keen to understand exactly what the issues are
with Rigel modules in the field. There has been a lot of "hype" about Rigel
failing "all over the place", and when I tried to determine the exact details,
I found that there were just 3 customer problems which got a lot of visibility.
It was from those three problems that rumor spread about Rigel being
unreliable. While I am very concerned and interested in understanding the
facts about the products performance, I would stress the importance of keeping
rumor to a minimum and reporting factual specific data. This way we can
understand whether we actually have a problem and if so, solve it.
We will continue to analyze the returns as we get them and I
will continue to report the results. Keep the information flowing in.
regards,
Jacqui
MODULE DETAIL IS ATTACHED......WIDE DOCUMENT
RETURN DETAIL
SERIAL NO DATE INTO REPAIRED? FAILURE DETAIL TAG DETAIL COMMENT FROM INCOMING VMI
GALWAY
GA93656177 28-11 Y E2.2 ECO WIRE SHORT.
GA93656084 28-11 Y CORRUPT EEPROM
NI91900472 2-12 Y E10 ELECT BAD.
GA93956289 28-11 Y CORRUPT EEPROM
GA92655054 28-11 Y E2.8 ECO WIRE SHORT.
NI90100064 28-11 SCRAP
GA92355023 13-12 Y UPDATED REV ON MODULE.
GA91555002 14-12 Y Y3 PART OPEN.
GA92255945 9-1 Y E38.137 ECO WIRE SHORT.
GA92255020 9-1 Y NO FAULT FOUND.
GA92355023 16-1 Y UPDATED REV ON MODULE. WRONG REV ON
MODULE
GA93856224 16-1 Y UPDATED REV ON MODULE. NO INFO ON TAG
GA93556046 16-1 Y NO FAULT FOUND.
GA93656195 16-1 Y ECO WIRE OPEN. DON'T WANT TO
RISK INSTALLING
- WIRES LOOSE
GA92755057 16-1 Y NO FAULT FOUND. FAILED AFTER 1ST
DID 72 HRS B/I & COMMAND >>B
14 HRS SYS TEST.
GA94456793 16-1 Y NO FAULT FOUND. CACHE ERRORS
DID 72 HRS B/I & FATAL BUG CHECKS
14 HRS SYS TEST.
GA93656161 16-1 Y NO FAULT FOUND. "SEE ATTACHED"!
BUT NOTHING WAS
ATTACHED.
GA93656188 16-1 Y E63.12 ECO WIRE OPEN. FAILED SELFTEST
GA92955897 16-1 Y E2.9 ECO WIRE OPEN. ECO WIRE OFF
E2.9
GA93457116 Y NO FAULT FOUND
GA94456780 Y SOLDER SHORT & DRY JOINT
GA92155003 14-12 Y PART ELEC BAD
GA93455947 16-1 Y NO FAULT FOUND
GA93956319 25-1 Y DRY JOINT DRY JOINT ON Y3
GA94256581 25-1 Y SOLDER SHORT
GA94056397 14-12 N
GA93956200 16-1 N
GA92955902 16-1 N
GA93656196 25-1 N
GA93455964 25-1 N
GA93855268 25-1 N
GA93656077 25-1 N
NI90300098 25-1 N
GA93456014 25-1 N
GA93455955 N NO DATA ON TAG WIRES LIFTED
GA94156473 N EEPROM CORRUPT FLUX ON SIDE 2
EXTENDED S/TEST WIRES LIFTED
FAILED..INTERMI-
TTENT LED CODE.
GA94656982 N REPORT ATTACHED LOOKS GOOD
GA92755062 N CPU FAILS TO PINS BENT ON E10
RESPOND TO CPU FLUX BOTH SIDES
SANITY TIMER.
|
| 49.24 | machine checks on 5.2 | KERNEL::ROBB | | Wed Mar 21 1990 12:08 | 214 |
| Don't get caught out with this machine check. (Fixed in VMS V 5.3)
All is not as it appears.......
What happens is this:-
The XMI has a parity error which is a soft error which VMS will try to recover
from. It should not be a fatal error and the system should not go down.
However what happens is MCHECK9RR goes out to scan the XMI registers it starts
at lowest known node and works it's way up.
All is well until it gets to the first memory node when it gets a machine
check examining BB+8 (Memory XFADR which does not exist) This causes a machine
check which should be ignored but is not. It is retried 3 times then exceeds
the machine check threshold.
The machine check in the errorlog is the last of these secondary machine checks
and nothing to do with the original problem which was probably an int54.
IDENTIFICATION
--------------
*To identify this problem look match in XBE
*PCERR will have the XMI XFADR address for first memory array
*Fault Code = 11
*XMA NODE no = first memory array only
All marked with *
The real problem with the system is probably a parity error on the XMI.
All nodes monitor at all times for parity errors but the calypso does not have
transmitter during fault bit (On other systems this bit would give an
indication as to the most likely node to have caused the error).
FIX
---
If possible upgrade to 5.3
This may or may not give some more useful information in errorlog but at least
the system has a good chance of staying up unless the original problem is
fatal.
Pete Beddall is looking at the possibility of creating a patch... I will keep
you informed.
SEE ME!
-------
The original int54 / int60 will be in an int54 / int60 data structure in memory
I am working on a procedure to decode the data structures but in the mean time
I am interested in seeing any crash which I may be able to get some info out to
help determine the cause of the original problem.
ELSE
----
ANY node on the XMI could have caused the parity error however experience has
shown XBIA to be the most troublesome module and this should be eliminated
first unless there is evidence indicating some other module.
If memory needs to be eliminated this can be done with the set memory command
without removing it
If a cpu needs to be eliminated this can be done with the set cpu command
The XARB is also a potential cause of XMI parity errors if it grants the bus to
more than one node at a time.
EXAMPLE!
--------
------- ------- ------- ------- ------------ -------------
TOTALS 0. 8. 0. 0. 0. 0.
SUMMARY OF ALL ENTRIES LOGGED BY SID 0B000004
MACHINE CHECK 9.
SYSTEM START-UP 9.
FATAL BUGCHECK 5.
TIME-STAMP 16.
ERL$LOGMESSAGE 18.
DATE OF EARLIEST ENTRY 17-MAR-1990 09:58:55.95
DATE OF LATEST ENTRY 19-MAR-1990 08:12:58.55
******************************* ENTRY 6270. *******************************
ERROR SEQUENCE 798. LOGGED ON: SID 0B000004
DATE/TIME 18-MAR-1990 02:26:24.33 SYS_TYPE 02100101
SCS NODE: BEVX04 VAX/VMS V5.2
MACHINE CHECK KA64A CPU FW REV# 4. CONSOLE FW REV# 1.0
XMI NODE # 1.
REVISION 00000000
SW FLAGS 00008000
00402000
XMI TTO CNAK ERROR
CACHE/VBOX SUBSYS ENABLED FOR ALL CPUS
LOGGING OFF 00000000
00000000
ACTIVE CPUS 00000006
HW REVISION 01000000
34304820
SERIAL NUMBER 30373339
38303130
RESRC DISABLE 0000
PHYS ADR 21880000
NODE 1.
XDEV 00088082
KA64A
DEVICE REV = 8.
* XBE 8080A041
READ CMD
FAILING COMMANDER = NODE #1.
TRANSACTION TIMEOUT
COMMAND NOACK
PARITY ERROR
ERROR DETECTED
XFADR 00000C76
FAILING ADDR = 00000C76(X)
FAILING LENGTH = 0.
XGPR 00000002
RCSR 412C0001
XCA REVISION = 1.
WRITE BUFFER ENABLED
AUTO RETRY ENABLED
SELF INVALIDATES DISABLED
XMI INTERPROCESSOR INTERRUPTS ENABLED
NORMAL TIMEOUT SELECTED: 16.77MS
CACHE RAM SPEED = FAST
CRD INTERRUPTS ENABLED
CORRECTED CONF INTERRUPTS ENABLED
THIS NODE IS BOOT PROCESSOR
COMMANDER RECEIVED NOACK
LOCKOUT TIME SELECT SET AT: 256 CYC
XDP1 PE ON XMI BUS
INTERLOCK LOCKOUT AVOIDANCE ENABLED
CONSOLE IPL = 15.
BCSTS 042A0000
CYCLE TYPE = DAL BUS
DMA CACHE FILL
PREDICTED PARITY BIT = 01(X)
BACKUP CACHE TAG COMPARE SET
PRIMARY CACHE TAG HIT (1ST HALF)
BCCTL 00000008
BACKUP CACHE TAG STORE DISABLED
PRIMARY CACHE TAG STORE DISABLED
REFRESH ENABLED
TWO CYCLE RAM SPD = FAST
BCERR 0B9496E8
ERROR ADDR REG: NON-APPLICABLE
PCSTS 00000888
PRIMARY CACHE DISABLED
PRIMARY CACHE REFRESH ENABLED
MICROTRAP 1 SET
BUS ERROR SET
BACKUP CACHE MISS
* PCERR 21B00008
P-CACHE ERROR ADDR = 21B00008(X)
SSCBTR 00017700
DAL BUS TIMEOUT = 96000. uSEC
VINTSR 00000001
XVP UNIT PRESENT
VECTOR MODULE RESET = 0.
VECTOR INTERFACE FUNCTION ENABLED
ERROR COUNTERS
XMI TTO CNAK 00000001
STACK FRAME
* FAULT CODE 80000011
MCHK FAULT CODE = 0011(X)
_DAL BUS OR DATA PE DURING READ
RESTART BIT SET
VADDR 80D2EBA2
VIRTUAL ADDR = 80D2EBA2(X)
VIBA 80D27114
MBOX PREFETCH VA = 80D27114(X)
SISR/ICCS 00400000
INTERVAL TIMER ENABLED
INTERNAL STATE 0600050E
RN = 0E(X)
OPCODE = 05(X)
EBOX DATA LEN = BYTE
ADR TYPE = READ
DELTA PC = 06(X)
SC 00000004
PC 80D27111
ERROR PSL 041F0008
N-BIT
INTERRUPT PRIORITY LEVEL = 31.
PREVIOUS MODE = KERNEL
CURRENT MODE = KERNEL
INTERRUPT STACK
ADAPTER DATA
* XMA NODE # 6.
PHYS ADR 21B00000
NODE 6.
XDEV 00024001
MS62A
DEVICE REV = 2.
XBE 80800000
PARITY ERROR
ERROR DETECTED
SEADR 08000002
4 WAY INTERLEAVE
_ADDRESSING POSITION 1.
STARTING ADR = 0. MB
ENDING ADR = 128. MB
MCTL1 02024000
MEMORY VALID
MEMORY SIZE = 0.MB ARRAY
RAM TYPE = 1MB
MECER 00000000
ECC ERROR SYNDROME = 0.
MECEA 00000000
ERROR ADDRESS = 00000000(X)
MCTL2 00000025
DIABLED HOLD
ARB SUPPRESS MODE:
_ASSERTED WHEN 1 CMD IN QUE
REFRESH RATE = 1.
|
| 49.25 | rigel update | KERNEL::ROBB | | Fri Apr 06 1990 19:21 | 269 |
| From: KERNEL::COMICS::LINDLEY "Brian Lindley, U.K. Support 833-4568 06-Apr-1990 1430" 6-APR-1990 15:01:38.73
To: @6000
CC: LINDLEY
Subj: 6000-400 Update
+-------------+
| | | | | | | |
|d|i|g|i|t|a|l| Product and Technology Group
| | | | | | | |
+-------------+
Interoffice Memorandum
To: Distribution Date: 6-APR-1990
From: Brian Lindley
cc: Ext: 833 4568
Loc/mail stop: UVO Basingstoke
DECnet: COMICS::LINDLEY
Subject: 6000-400 update
This is just to keep you all updated about the status of Rigel
Systems and problems in the field. You will be pleased to know that
the availability of Rigel CPU modules has improved. Unfortunately
consumption is increasing and the number of modules consumed has
been increasing consistantly each month, and has doubled between
February and March.
To help reduce the consumption, I have included a list of new issues
and problems detailed below. If any of you have any further
questions or problems regarding 6000 systems then please call Peter
Beddall ( DTN 833 3804 ) or myself.
i) VMS version 5.2 Machine Check Handler bug
ii) System clock running slow
iii) No-error errorlog problem
iv) Incorrect XFADR contents
v) Bent pins on Rigel chips
vi) Self-test fails test 35 (Floating Point)
vii) Fault tags and module serial numbers
i) VMS Version 5.2 Machine Check Handler bug
There is currently a problem within the V5.2 Rigel machine check
handler. If the system encounters an INT54 error, for example an XMI
parity error, the system should simply snapshot the XMI register
contents to the errorlog and continue. Unfortunately there is an
error in the code such that it machine checks whilst accessing the
address of what would be the first memory nodes XFADR, this is
fatal. This problem is fixed in VMS 5.3. For customers experiencing
this problem I have a patch that can be made available. For further
information please contact either Peter Beddall, Ken Robb or myself.
ii) System Clock Running slow
6000 systems can experience a system time loss ($ show time) of a
few minutes to hours per day. The loss can appear to be erratic and
can vary depending on the number of users on the system. This could
be due to lost clock interrupts (IPL 22) caused by an excessive
number of ECC errors, reported via an INT54 (IPL 26). It is also
possible that these ECC errors will not be logged in the errorlog,
as the machine check handler only records an entry if 16 ECC errors
occur at the different locations. If the errors are at the same memory
location then no errors are recorded in the errorlog unless the system
suffers a machine check or is shutdown when the buffers are flushed.
In cases of slow system clocks check for ECC memory errors first,
before replacing CPU modules.
eg.
This is a technique for finding CRD errors on a running Calypso
(62xx or 63xx) or Rigel (64xx) system. The reason this technique
is needed is that these systems do NOT report CRD's to the global
memory error count ($SHOW ERROR command), and they do NOT log CRD's
to the errorlog until the system is shutdown or crashes with a
Fatal Bugcheck.
***** Note that since CRD's are only logged when the system
is going down that these entries will look like they
were logged just prior to a crash! Be careful here as
there is no way to associate the time that the CRD's
actually occured with the time on the errorlog entry!
This technique should be useful for the problems discussed in
several previous notes where the system is loosing time and XMI
errors are being logged with "No Error Found".
Another symptom we would like to start tracking is when a 6000
series multi-processor crashes with a CPU Sanity Timer Expiration
Bugcheck. It is felt this could be another symptom of extended
time at IPL 29 to log CRD errors.
If you have any questions/comments on this technique or any
feedback on the CPU Sanity Timer Expiration Bugchecks please
contact Alan Davison (CSC32::A_DAVISON) or Mark Fisher
(CSC32::M_FISHER) or reply to this note.
________________________________________________________________________________
Technique to find CRD Errors on the live system.
________________________________________________________________________________
$ sho sys ***** Find out the version of VMS *****
VAX/VMS V5.2 on node xxxxxx 27-MAR-1990 16:37:05.74 Uptime 28 00:01:23
***** Determine correct offset into SYSLOA for your *****
***** system type and version of VMS from chart below *****
***** This example was on a 64x0 system. *****
Offset of MOVAx instruction in SYSLOA
VMS MCHECK9CC MCHECK9RR
Ver. (62/63xx) (64xx)
5.0 5CED
5.1 5701
5.2 5817 6688
5.3 5CED 6C0A
5.4 6374 88D2
$ ana/sys ***** Enter online SDA *****
VAX/VMS System analyzer
SDA> ex/i sysloa+6688 ***** Examine instruction at offset found above *****
80C36998: MOVAB 80C3E9AC[R3],R4
|
|---- ***** This is the address of the *****
***** CRD Error Buffer. *****
SDA> sh sta 80c3e9ac;100 or
SDA> ex 80c3e9ac;100 ***** Examine the CRD Buffer. *****
00003542 21D00000 21D00000 000A00A7 �.....!....!B5.. 80C3E9AC
00000000 00000000 00000000 00000001 ................ 80C3E9BC
Zeros suppressed from 80C3E9CC through 80C3EAAB
***** Now decode the buffer contents using the *****
***** following footprint templates. This *****
***** example is shown to the right side of *****
***** the 64x0 template. *****
Format of CRD footprint
for 64x0
31 0
+--------------------------------------+
| Primary footprint |->| 000A00A7
+--------------------------------------+ |
| Lowest detected address | | 21D00000
+--------------------------------------+ |
| Highest detected address | | 21D00000
+--------------------------------------+ |
| Count of CRD's | | 00003542 (13634 decimal)
+--------------------------------------+ |
| flags for this footprint | | 00000001
+--------------------------------------+ |
|
Format of Primary Footprint |
15 0 |
+--------------------------------------+ |
| ECC syndrome bits |<-| 00A7
+--------------------------------------+
| FRU id | 000A (XMI Node #)
+--------------------------------------+
Format of CRD footprint
for 62x0/63x0
+-+---------+--------------------------+
|0| Node ID | Bits 3-29 MECEA register |
+-+---------+---------+----------------+
| | Bits 0-7 MECER |
+---------------------+----------------+
| count of CRDs |
+--------------------------------------+
| flags for this footprint |
+--------------------------------------+
iii) No error errorlog problem
Adapter errors can appear in errorlog entries with no error bits
set. These errors appear on either or both XMI ( DWMBA ) for any
6000 system. This problem is also as a result of memory ECC errors.
When the XBI interrupts and the only error is a CRD error VMS does
not make a direct entry in the error log. Instead it includes the
error information in its internal CRD buffers, and clears down the
error bits. However if the XBI receives another CRD response before
the first interrupt has been serviced, then the XBI remembers this
fact and causes a second interrupt. Unfortunately by this time VMS
has cleared down the error bits, (it can't stop the second
interrupt) and it will therefore receive an error interrupt with no
error bits set. This it treats as an error and logs it immediately.
The SW Flags for the entry will report "NO ERROR FOUND".
As mentioned previously, there may or may not be an associated ECC
errorlog entry, depending upon whether its threshold of 16 errors
for a single location has been reached.
iv) Incorrect XFADR Contents
Many of you may have noticed how on several errorlog entries the
XFADR address is often reported as C76 or a similar low value. In
cases where this is relevant (e.g. timeouts etc) it should be the
same address as that contained in the PCERR. This is a bug in the
errorlog formatter and is fixed in VMS 5.3. When using a lower
version the correct contents of the XFADR can be obtained using
$anal/err/brief.
v) Bent Pins on Rigel Chips
We are still seeing cases of bent pins on Rigel CPU modules. It is
not clear if these have been present since the system was shipped,
or were introduced later. I would just urge all of you to continue
to treat all Rigel CPU modules with extra care, even the module is
defective.
The pins in question are those on the very large VLSI chips. The
wire is so fine they bend very easily ( 25 mil ).
Before installing any Rigel CPU module I strongly recommend that you
give the module a good visual inspection before placing the module
in the system.
If any pins are touching, or are potentially touching then do not
use that module. Please contact your local 6000 specialist, Peter
Beddall, Ken Robb or myself. The pins that are normally subject to
damage are the corner pins of the chips particularly those to the
edge of the module and if any modifications are present on the
module, the pins which are close to wire runs.
vi) Self-test fails test 35 (Floating Point)
We are receiving reports of a higher than expected incidence of
Rigel CPU modules failing self-test at test 35 (Floating Point).
Peter and I would be very interested to hear of any instances of
this failure. Would all engineers replacing CPU modules therefore
check the failing test number, either from the printout or led code,
and call us as necessary, quoting CPU Module and System serial
numbers. This will enable to track the module through the repair
loop.
vii) Fault tags and module serial numbers
To ensure quality modules are returned to the field after repair,
could I once again ask that all fault tags be filled in with as much
detail as possible, and attach system printout/errorlogs as
necessary. These are really used, and applies to any module.
When trying to investigate problems, the module serials numbers are
especially useful. Could engineers when replacing modules please
record the old (faulty) module's serial number in the site log.
Regards
Brian Lindley
|
| 49.26 | rigel vector | COMICS::ROBB | | Tue May 15 1990 15:22 | 103 |
|
+---------------------------+TM
| | | | | | | |
| d | i | g | i | t | a | l | TIME DEPENDENT CASE
| | | | | | | |
+---------------------------+
TITLE: Rigel VECTOR FRS Customer Services Release notes.
DATE: May 8, 1990
AUTHOR: John Stevens TD #:000275
DTN: 293-5447
ENET: MSBCS::STEVENS CROSS REFERENCE #'s:
DEPARTMENT: CSSE Low End Mid Range (PRISM/TIME/CLD#'s)
INTENDED AUDIENCE: Customer Services PRIORITY LEVEL: 1
(U.S./EUROPE/GIA) all areas (1=TIME CRITICAL,
2=NON-TIME CRITICAL)
=====================================================================
PROBLEM:
There are several issues related to the introduction of VAX 6000 4XX
VECTORS of which Customer Service Personnel need to be made aware.
Limited shipments commence May 11.
1. VAX 6000 - 4XX VECTORs (T2017) require a REV K Scalar (T2015)
to be attatched to the VECTOR.
2. In sytems that have VECTORS all Scalar modules must be at REV K
or REV J.
3. Only a Memory module can be placed to the left of a VECTOR module
in the XMI backplane, otherwise damage can occur.
4. VECTOR modules can be shipped only in the ESD Box, 99-08536-02,
otherwise damage can occur. This is a REV change from the original
XMI ESD box. The part number will be on a label on the top of
the box. No other identifier is supplied.
5. For each VECTOR, a system should have 64 megabytes of memory to
have reasonable performance.
6. Dual Scalar Vector pairs will not be supported until Q2 of FY 91.
Testing has reveeled that this configuration is not working
properly.
7. Diagnostics: Prerelease kits may be ordered from the SSB
VAX6400 VECTOR Cmplt Diag Set (TK50) AQ-PBPRA-DE
VAX6400 VECTOR Cmplt Diag Set (Mag tape) BB-PBPSA-DE
or
Copied from VOLKS::RIGEL$DIAG_VECTORS:
8. Documentation: At FRS most Customer Service manuals will be
preliminary. Listed below are manuals most pertinent to VECTORS.
VAX 6000 Series Upgrade Manual (VCT Install) EK-600EB-UP-002
VAX 6000 VECTOR Processor Owner's Manual EK-60VAA-OM-001
VAX 6000-400 System Technical User's Guide EK-640EA-TM-002
VAX 6000-400 Option & Manintenance Manual EK-640EB-MG-002
VAX 6000-400 VECTOR Proc. Programer's Guide EK-64VEA-OM-001
VECTOR Processing Concepts Student Workbook EY-9876E-SG-001
VAX VECTOR Processing Handbook EC-H0419-46/89
RESOLUTION/WORKAROUND:
1. REV K of the Scalar module (T2015) is the minimum Rev that can be
attached to a VECTOR (T2017) module.
2. The current Rev of the Scalar module is Rev. H. It is
incompatible with Rev. K. Customer Service personnel can build a
Rev. J which is compatible by replacing the console and diagnostic
ROMs on Rev. H modules. ROMs and instructions are in the initial
released kit of the VECTOR option.
3. Place no other modules but memories next to the VECTOR.
4. Use only the 99-08536-02 ESD box with a VECTOR Module.
5. Inform the customer and Digital sales personnel of the correct
size of memory.
6. Dual Scalar Vector pairs do not work properly and are not
supported. Customers should NOT cofigure their systems with Dual
Scalar Vector pairs!
ADDITIONAL COMMENTS:
The VECTOR Module, the T2017, will require an FCO to fix known
hardware problems that in the current version are worked around
either in hardware and software or in product restrictions. To
become familiar with these restrictions read the VAX 6000 Series
Vector Option Release Notes.
*** DIGITAL INTERNAL USE ONLY ***
|
| 49.27 | 6000-400 update | COMICS::ROBB | | Fri May 18 1990 17:08 | 32 |
| Subject: T2015 (Rigel CPU) Status
The consuption rate of the T2015 module is still high, and there are
a number of factors which contribute to this high rate. By far the
biggest contributing factor is the F-chip problem which accounts for
80% of all T2015 module returns.
The F-chip problem has been identified and new pass of the chip has
been produced and is currently in field test. So that the situation
can be more accurately monitored with regards to upgrades and
repairs the Q.A. Department in Galway would like to be informed of
information relevant to the mode in which the module failed. The
contact in Galway is Brendan Duffy and he can be contacted by
VAXmail on CLADA::BDUFFY or on DTN 7784-2834. The information
Brendan is particularily interested in is :-
o Situation of the failure - how it fails. i.e Were there any
events leading up to the failure.
o Serial number.
o Errorlog printouts.
o Has this module been installed in the system less than five days ?
It is essential to communicate the above information to enable us to
understand the on-going impact of the F-chip problem. Could you
please copy me on any mail you send to Brendan.
If anyone would like a slide set of the current 6000 status, to use
as handouts or to present to engineers, please contact me for either
the .LN03 file or the Document source file.
Brian Lindley
|
| 49.28 | 6420 losing time example | KERNEL::BLAND | toward 2000 ... | Thu May 31 1990 14:22 | 48 |
| <<Here is an example of a 6420 which was losing time and the reason.>>
<<I looked at INT54/INT60 as well as CRD's just for the experience.>>
$ ana/sys
VAX/VMS System analyzer
SDA> define 60base=429C !** for VMS V5.2 **
SDA> define 54base=3E92 !** for VMS V5.2 **
SDA> define crdbase=6688 !** for VMS V5.2 **
SDA> define x600+@(@sysloa+60base+3)+sysloa+60base+7)
SDA> define x601=@(@(sysloa+60base+3)+sysloa+60base+7)+1*66
SDA> exam/time x600
4-JAN-1978 09:54:51.52 !INT60 logged at boottime (expected)
SDA> exam/time x601
17-NOV-1858 00:00:00.00 !No INT60 on CPU #1
SDA> define x540=@(@(sysloa+54base+3)+sysloa+54base+7)
SDA> define x541=@(@(sysloa+54base+3)+sysloa+54base+7)+1*66
SDA> exam/time x540
18-MAY-1990 14:39:09.07 !INT54 error (caused by CRD, see later)
SDA> exam/time x541
18-MAY-1990 14:39:10.93 !INT54 error (caused by CRD, see later)
SDA> exam (@(sysloa+crdbase+3)+crdbase+7)+sysloa+crdbase+7);10*14
0000663E 21B80000 21B80000 000700D0 �.....�!..�!>f.. 80BAABAC
00000000 00000000 00000000 00000001 ................ 80BAABBC
Zeros suppressed from 80BAABCC through 80BAACEB
Format of CRD footprint for 64x0 Actual values from above
+----------------+----------------+ +----------------+----------------+
| node # |ECC syndrome | | 0007 | 00D0 |
+----------------+----------------+ +----------------+----------------+
| lowest detected adress | | 21B80000 |
+----------------+----------------+ +----------------+----------------+
| hihgest detected address | | 21B80000 |
+----------------+----------------+ +----------------+----------------+
| count of CRD's in HEX | | 663E |
+----------------+----------------+ +----------------+----------------+
| flags for this footprint | | 00000001 |
+----------------+----------------+ +----------------+----------------+
cheers .. norman B
|
| 49.29 | rigel cpu modules | COMICS::ROBB | | Sat Jun 09 1990 02:32 | 100 |
| From: KERNEL::COMICS::LINDLEY "Brian Lindley, U.K. Support 833-4568 07-Jun-1990 1013" 7-JUN-1990 10:16:46.28
To: @6000.DIS
CC: LINDLEY
Subj: T2015 Revision H. and Revision K. information
Hello Gents
Today we have some good news and some bad news.... The good
news is that to help alleviate the spares shortage, we are
getting loads of T2015 ( Rigel CPU module ) from Manufacturing
in Galway. The bad news is that they are all Rev. K modules and
are incompatible with the currently installed modules in the
field all of which are Rev H !!!!! Please read on for more
details...
Rev. K of the T2015 is for Rigel Vector support. Unfortuately
it does not cure any of the "known problems" currently
impacting the reliability of the T2015.
The reason for this incompatibility is that Rev. K utilises
version 2.0-06 of the console ROMs, and Rev. H uses version
1.0. There are however ROMs available to enable the upgrade
from console version 1.0 to console version 2.0-06, which
changes the revision of T2015 from H to J. The part numbers for
these ROMS are 23-26E9 and 23-27E9. These ROMs are obtainable
from Logistics but Rev. J of the module is not. Please see
below for compatibility matrix.
It is planned that this upgrade will be done only on multi-cpu
6400s when a CPU in the system fails. i.e. There is no FCO for
this ROM change. There will be two separate part numbers for
the different revisions of module. Part number F6-T2015 will
get you a T2015 at minimum rev. K. Part number T2015 will get
you revision H.
Therefore depending on the configuration of the 6400 and what
revision the CPUs in the system are, will depend on which
option you need to order ( T2015 or F6-T2015 ) and how many
set of ROMs.
Compatibility Matrix.
---------------------
The following matrix explains the required actions in each
situation :
Defective T2015
----------------
H J K
-------------------------------------------------
| | Upgrade Spare | Upgrade Spare |
Spare | No Problem | to rev. J | to rev. J |
----- H | | with ROMs | with ROMs |
- | | | |
|---------------|---------------|---------------|
T2015 | Upgrade other | | |
----- K | CPUs in system| No Problem | No Problem |
- | to rev. J | | |
| with ROMs | | |
-------------------------------------------------
The way Logistics now stock the Rigel CPU modules means that
there will be more than one method of obtaining the correct
material to fix the customers broken system.
e.g. If one CPU in a 6430 is defective and is at rev H, you can
order either a T2015 *OR* a F6-T2015 plus two sets of ROMs to
upgrade the good CPUs in the system.
If all three modules in the system were rev K. you could order
a F6-T2015 *OR* T2015 plus one set of ROMs.
I would strongly recommend that the old revision of ROMs are
disposed of effectively.
How do you tell what revision of module you have without
physically looking at the module ?........( As you may speaking
to the customer over the phone and be remotely diagnosing the
problem.) There are several methods, but the quickest is to
look at last line of the self-test/power up. Just after the
memory configuration and between the >>> prompt all the ROM
revision information is given. e.g. for rev K. :-
ROM0 = V2.00 ROM1 = V2.00 EEPROM = 1.00/1.02 SN = XXXXXX
The value of the ROM on the printout will indicate what rev
level of module is currently in the system and hence what is
required to FIX the system.
Please contact me if you have any concerns or queries about
the above information.
Regards
Brian
|
| 49.30 | rigel upgrad procedure | COMICS::ROBB | | Sat Jun 09 1990 02:33 | 564 |
| From: KERNEL::COMICS::LINDLEY "Brian Lindley, U.K. Support 833-4568 08-Jun-1990 1455" 8-JUN-1990 15:00:55.96
To: @6000
CC: LINDLEY
Subj: Procedure to Upgrade T2015 Console Version 1.0 to 2.0-06
Gentlemen
The following is the procedure describing the installation of the
ROMs to upgrade the T2015 from revision H to J. This upgrade
involves replacing the console and diagnositic ROMs which results
in the console version changing from version 1.0 to 2.0-06.
This procedure should be shipped with the ROMs but experience has
shown this is not the case. Please distribute this information as
it is critical that this procedure is carried out in the correct
order, or you can end up corrupting the EEPROM.
Following this note there will be a message which will
be a schematic and the T2015 showing the location of the ROMs.
Regards
Brian
UPGRADING T2015 CONSOLE AND DIAGNOSTIC ROMS
Part Number: EK-64RMA-UP-001
************************************************************
* *
* These instructions are to be used in any of the *
* following situations. The VAX 6000 Series Upgrade *
* Manual (EK-600EB0UP-003) contains instructions to *
* perform 1 and 2 below. *
* *
* 1. When installing a VECTOR Option to a *
* VAX 6000/4xx machine. *
* *
* A) The Scalar conected to the Vector *
* must be at Rev. K *
* *
* B) All other Scalars in the system must *
* be at Rev. J or greater. *
* *
* C) Scalars removed from the system should *
* be returned through Logistics. *
* *
* 2. When installing an Upgrade CPU module(s) *
* that are Rev. K and the modules in the *
* system are at Rev. H. *
* *
* A) All other Scalars in the system must *
* be at Rev. J or greater. *
* *
* B) Scalars removed from the system should *
* be returned through Logistics. *
* *
************************************************************
* *
* THESE INSTRUCTIONS APPLY ONLY TO REV 2 CONSOLE ROMS *
* *
************************************************************
* DIGITAL CONFIDENTIAL *
Updating Rigel Console ROMs
************************************************
* NOTE *
* DIGITAL CONFIDENTIAL *
* *
* DO NOT LEAVE AT CUSTOMER SITE! *
************************************************
VERSION INFORMATION
These installation instructions apply to Rev. 2.0 console ROMs.
Read these instructions thoroughly before you begin. There are
several pitfalls along the way. Pay particular attention to the
Caution before step 21 and 22.
PRELIMINARY INFORMATION
Updating T2015 console ROMs uses several steps that must be
followed EXACTLY AND IN ORDER. Failure to follow the steps can lead
to delays and even having to replace the EEPROM on the Rigel board.
These instructions assume your Rigel system includes no failing
processor boards. If a board fails selftest during this process,
and you cannot correct the problem by ensuring all processor boards
are seated in the backplane correctly, then you should remove that
processor board from the upgrade process.
There are some commands that you may not be familiar with that you
will be asked to perform. These commands like <ESC><DEL>SET MANU-
FACTURING are used in manufacturing to place the module serial and
revision information in the EEPROM. Another is the JSB instruction
which jumps to executable code in the console ROM that blasts the
EEPROM with a default image.
*****************************************************************
* NOTE *
* Working main memory with no bad arrays is necessary *
* for successful EEPROM blasting. *
*****************************************************************
In order to update the Rigel processor boards in your system, you
have to do several tasks. You have to record information stored in
the EEPROMs of each processor. Some of this information, like stored
boot specifications and the system serial number, is the same on each
Rigel processor. You can display this information from one processor;
you do not have to select each processor and display the information.
Likewise, when you enter the boot specifications after the ROMs have
been installed, you need only do this from one processor, because
a SET BOOT command causes the boot specification you enter to be
copied to all processors.
* DIGITAL CONFIDENTIAL *
Other information, like manufacturing information, is different on each
processor, and you must select each processor, using the SET CPU
command, to display and record this information. Likewise, when you
replace this information, you must select each processor and replace
the information you recorded for that processor.
Then, after recording this information, you have to disable the EEPROM
of each processor. Disabling the EEPROM prevents the new console ROMs
you install from using the old patch table in the EEPROM. Again, you
must select each processor, using SET CPU, to disable the EEPROM.
**************************************************
* NOTE *
* This note pertains to Step 5 and Step 6. *
**************************************************
If your console is connected to VCS (VAX Cluster Console) and the
VCS baud rate is not set to 1200 baud then you must either switch to
a hard copy console, or return VCS to 1200 baud. (Switching to a hard
copy console line is probably preferable and easiest.) The reason for
this is the default console baud rate is 1200 baud. During the upgrade
process, the system is powered up with disabled EEPROMs to prevent the
new console from using the patch vector of the previous console.
Since the EEPROM is disabled, the console will use the default baud
rate, i.e., 1200 baud.
Steps 5 and 6 are to ensure the terminal line speed is set to 1200.
If the console is connected to VCS and VCS's default line speed is
1200 baud, then the speed of the terminal is not important. Therefore,
in the case of a console connected to VCS and the default rate is
1200 baud, you may skip Steps 5 and 6.
BEFORE YOU REPLACE CONSOLE ROMS
Since this procedure requires recording several pieces of information
you might want to have the hardcopy printer on. Take the output with
you when you leave the site.
1. Shut down the operating system, if it is running, using the
approved methods, like @SYS$SYSTEM:SHUTDOWN on VMS. If using
SHUTDOWN, answer all prompts by typing a carriage return, except
the last prompt, which should be answered by entering REBOOT_CHECK.
* DIGITAL CONFIDENTIAL *
Here is a sample of a VMS shutdown session:
$ @sys$system:shutdown
SHUTDOWN -- Perform an Orderly System Shutdown on node PEEVEE
How many minutes until final shutdown [0]:
Reason for shutdown [Standalone]:
Do you want to spin down the disk volumes [NO]?
Do you want to invoke the site-specific shutdown procedure [YES]?
Should an automatic system reboot be performed [NO]?
When will the system be rebooted [later]:
Shutdown options (enter as a comma-separated list):
REMOVE_NODE Remaining nodes in the cluster should adjust quorum
CLUSTER_SHUTDOWN Entire cluster is shutting down
REBOOT_CHECK Check existence of basic system files
SAVE_FEEDBACK Save AUTOGEN feedback information from this boot
Shutdown options [NONE]: reboot
VMS will issue several messages indicating it is shutting down.
Finally, VMS will issue:
SYSTEM SHUTDOWN COMPLETE - USE CONSOLE TO HALT SYSTEM
2. At this point type a Control-P to halt the primary processor.
The console will print the following, but the numeric values may
not match the example, which is all right:
?02 External halt (CTRL/P, break, or external halt)
PC = 801C7F92 | Output may differ
PSL = 001F8200 | dependent on Operating
KSP = 7FFE7768 | System version
>>>
3. Enter INITIALIZE at the >>> prompt. This will reset the whole
system and force all processors into console mode.
4. You should examine the console map to determine the location of
each Rigel processor in your system. Record the location of each
processor. The map denotes a processor by printing an uppercase
letter P on the TYP line.
5. Record the position of the lower front panel keyswitch and then
set it to UPDATE.
* DIGITAL CONFIDENTIAL *
****************************************************
* NOTE *
* Before executing Steps 6, read the note about *
* VCS in the introduction to these instructions. *
****************************************************
6. When you put in the new ROMs, the console baud rate will be 1200.
The following two steps ensure that condition is set up. Enter
the following command to ensure the baud rate is set to 1200:
>>> SET TERMINAL/SPEED:1200
Do not worry if the console writes strange characters after issuing
the command. This means your terminal is set to some baud rate
other than 1200 baud. If you press the carriage return key, and
the console issues the console prompt >>>, you can skip Step 7 and
go to Step 8.
7. Press the SETUP key on your terminal, and set the baud rate of your
terminal 1200 baud and SAVE this setting. Now, you should be able
to issue more console commands.
8. Enter the SHOW ALL command, and record all paramaters.
Specifically the /NOPRIMARY, the /INTERLEAVE, the /SCOPE, the
/SPEED, the /BREAK, the Ethernet address, and the boot specifica-
tions. Here is a sample of the latter part of the command output:
>>> SHOW ALL
.
.
.
Current Primary 1
/NOENABLE !All CPUs are enabled
/NOPRIMARY 2, 4 !CPUs at nodes 2 and 4 cannot be primaries
F E D C B A 9 8 7 6 5 4 3 2 1 0 NODE #
. . . . . A1 A2 A3 A4 . . . . . . . ILV
. . . . . 32 32 32 32 . . . . . . . 128 Mb
/INTERLEAVE:DEFAULT
/SCOPE /SPEED: 1200 /BREAK ! Shows the terminal characteristics
English ! Shows the language mode
XMI:D BI:6 08-00-2B-08-3D-64 ! Shows the Ethernet address
DEFAULT /XMI:E /BI:4 DU3D ! Shows the Boot specifications
R54A /R5:00000001/XMI:E/BI:4 DU4A
DIAG /R5:00000010/XMI:E/BI:4 DU15
R5 /R5:00000001/XMI:E/BI:4 DUD
* DIGITAL CONFIDENTIAL *
*************************************************
* NOTE *
* The following steps are used to connect *
* console terminal to each processor in the *
* system beginning with the porcessor at the *
* lowest node and progressing to the highest. *
*************************************************
9. Look at the console map and determine which nodes contain pocessors
then connect the terminal to the processor at the lowest node by
entering
>>> SET CPU n where n is the node number
10. Enter the <ESC><DEL>SHOW SYSTEM SERIAL command, and record the
system serial number. Here is a sample of the command output:
>>> $^?SHOW SYSTEM SERIAL
System serial number: AG83701988
11. Enter the <ESC><DEL>SHOW MANUFACTURING command, and record the
module serial number and revision of the current XRP board. Make
sure you match this information with the number of the processor
you are currently set to. When you blast the EEPROM this informa-
tion is lost and must be entered manually into each module's EEPROM.
Currently the last 3 fields in the manufacturing area are not used.
Here is a sample of the command output:
>>> $^?SHOW MANUFACTURING
Manufacturing parameters are as follows:
Module serial number: NI84800046
Module revision: H03
REX520 revision
FPU revision:
RSSC revision:
12. Deposit a zero into the EEPROM header to disable console patches by
entering the following instruction:
>>>D/U 20080000 0
13. If your system has only one XRP board, go to step 15. Else enter
SET CPU n to the next node, whose manufacturing parameters need
to be recorded and whose EEPROM header must be corrupted, where
n equals the XMI node number of a processor.
14. Repeat steps 11, 12, and 13 until you have recorded the manufactur-
ing parameters and deposited a 0 into 20080000 (disabled the
console patches) for each processor in your system.
15. Note the position of the upper keyswitch and then power down the
system by setting the upper front panel keyswitch to "0" or the
off position.
* DIGITAL CONFIDENTIAL *
****************************************************************
* C A U T I O N *
* *
* All VAX modules contain electrostatic discharge *
* sensitive devices (ESDS). The use of the VELOSTAT *
* kit is essential to prevent damage which may not *
* be noticed immediately. *
****************************************************************
16. Set up VELOSTAT KIT
a. Unfold the VELOSTAT mat to full size (24" x 24").
b. Attach the 15 foot ground cord to the VELOSTAT
snap fastener on the mat.
c. Attach the alligator clip end of the ground cord
to a good ground on the system.
d. Attach the wrist strap to either wrist and the
alligator clip to a convenient portion of the mat.
17. Remove the first Rigel module, handling it properly and laying it
on the mat. Carefully remove the Diagnostic ROM (PN 23-020E9-00)
from E77 and put in the new Diagnostic ROM in its place (PN 23-
026E9-00). Carefully remove the Console ROM (PN 23-019E9-00)
from E97 and replace it with the new Console ROM (PN 23-027E9-00).
Be sure that the ROM is placed in the socket correctly and that
there are no bent pins. See picture on last page of this document.
18. Place the Wire Markers on the module in the appropriate places
according to the following chart.
-------------
| H03 | J03 |
MODULE ------------- MODULE
REVISION | H04 | J04 | REVISION
WAS ------------- BECOMES
| H05 | J05 |
-------------
19. Replace the module in the system making sure you know what the
module serial number is.
20. Repeat Step 16, 17 and 18 until you have installed ROMs and wire
markers on all processor boards in the system.
21. Power on the system, by setting the upper front panel keyswitch
to ENABLE. If some modules fail selftest, you may have to ensure
the processor modules are seated correctly in the backplane. It
is not uncommon to have to reseat the boards once or twice. Once
all boards pass selftest, the boot processor will issue several
messages about its own corrupt EEPROM and unusable patches and
similar messages for all secondary processors. This is expected
behavior.
22. To blast the default EEPROM image enter:
>>> JSB 20054600
* DIGITAL CONFIDENTIAL *
******************************************************************
* CAUTION *
* *
* Before executing the next step, step 23, MAKE SURE YOU MAKE *
* NO TYPING MISTAKES. If you use the DELETE key to correct a *
* typing mistake, the EEPROM blasting program, at the address *
* you will be entering, will interpret the DELETE key as a *
* character. It will treat CTRL U the same way. Therefore, *
* if you make a typing mistake, you will have to press the *
* RESET button on the front of the cabinet, and, NOTE THIS, *
* use the SET CPU command to the current module you were *
* updating at the time you made the typing mistake. *
* *
******************************************************************
23. Answer the Source Addr:, by entering 20054A00, and enter this
carefully. A set of '*'s are printed to the console as the
EEPROM is blasted. The process takes about 20 seconds.
24. This step is used to make sure that the EEPROM is blasted properly.
Enter the <ESC><DEL>LKUPVER command, (Look UP VERsion command)
and to be sure you see an 81 as the first number of the output. If
you see another number, like 53, repeat the previous two steps to
reblast the EEPROM. If you still do not see an 81, replace the
EEPROM.
25. Enable RBD error logging, by entering the following command:
>>> D/U/P/L 200800A0 F
26. Enter the <ESC><DEL>SET MANUFACTURING command and enter the
module's serial number and the new revision based on the revision
you recorded in step 11. You can enter a carriage return for the
remaining parameters. Here is sample output from the command:
>>> $^?SET MANUFACTURING
Module Serial Number>>> NI84800046
Module Revision>>> J03
REX520 Revision>>>
FPU Revision>>>
RSSC Revision>>>
Fields are as follows:
Module serial number: NI84800046
Module revision: J03
REX520 revision
FPU revision:
RSSC revision:
Update EEPROM? (Y or N) >>> Y
?71 Manufacturing parameters updated.
* DIGITAL CONFIDENTIAL *
27. Enter the <ESC><DEL>SET SYSTEM SERIAL command, using the serial
number you recorded in Step 12. Here is sample output from the
command:
>>> $^?SET SYSTEM SERIAL
System Serial Number>>> AG83701988
Serial number read as: AG83701988
Update EEPROM? (Y or N) >>> Y
?73 System serial number updated.
******************************************************
* NOTE *
* You could enter the system serial number once and *
* use the update command, but this method is faster.*
******************************************************
28. If your system has only one T2015 board, go to step 29. Else enter
SET CPU n to the next node, so you can blast the default EEPROM,
enable error logging, enter the manufacturing information, and set
the system serial number for that processor.
29. Use the SET CPU [n] command to step through to each CPU in the
system and repeat Steps 21 through 27 until you have updated all
processor boards in your system.
30. Now, enter the boot specifications you saved in Step 8, using the
SET BOOT command. Here is sample output from the command:
*******************************************************
* NOTE *
* If you found no boot specification was saved, when *
* you executed Step 8, you might want to check if *
* the system manager would like you to enter any *
* boot specifications. *
*******************************************************
>>> SET BOOT DEFAULT /XMI:E/BI:4 DU3D
It may be helpful to check the boot specification you just entered.
Enter the SHOW BOOT command to check the boot specification or
specifications. If your system contains more than one processor,
entering the SET BOOT command causes the boot specification to be
copied to all processors, so this command does not need to be
repeated on each processor.
* DIGITAL CONFIDENTIAL *
31. In step 8 you also recorded several parameters using the SHOW ALL
Command. In this Step you need to use a series of SET commands
to return the system to its original state. The following are
examples.
To set the language: >>>SET LANGUAGE INTERNATIONAL
OR >>>SET LANGUAGE ENGLISH
To not allow a CPU
to be a primary: >>>SET CPU 2 /NOPRIMARY
To set the Terminal: >>>SET TERM/[NO]SCOPE/SPEED:9600/[NO]BREAK
If you use the SET TERMINAL command to change the SPEED recorded
in the EEPROM, you will need to change the baud rate of the terminal
itself.
32. Now, press RESET or enter the INITIALIZE command, and ensure the
console prints no error messages concerning console patches or
corrupt EEPROMs or Serial Number mismatches.
33. Return the lower front panel keyswitch to the position you recorded
in step #5. Return the upper keyswitch to the position you
recorded in step #15.
The ROM update is complete and you can boot the system.
34. Boot the system.
*****************************************
* BE SURE YOU TAKE THESE *
* INSTRUCTIONS AND CONSOLE *
* PRINT OUT WHEN YOU LEAVE !!! *
*****************************************
35. Update the Site Management Guide to reflect any module revisions.
* DIGITAL CONFIDENTIAL *
|
| 49.31 | rigel schmatic post script | COMICS::ROBB | | Sat Jun 09 1990 02:35 | 1960 |
| %!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: 1 1
1000 BP 39600 30600 PM 0 0 XY
3899 4198 XY
3899 25119 SPB
% Begin Plot (msb0193a.ps)
26.000 -8.000 translate
%!PS-Adobe-2.0 EPSF-1.2
%%Creator: Adobe Illustrator 88(TM) 1.8.3
%%For: (Documentation Group) (Low End Mid-range Systems \(MSB\))
%%Title: (msb0193A.ps)
%%CreationDate: (5/4/90) (9:31 AM)
%%DocumentProcSets: Adobe_packedarray 0 0
%%DocumentSuppliedProcSets: Adobe_packedarray 0 0
%%DocumentProcSets: Adobe_cmykcolor 0 0
%%DocumentSuppliedProcSets: Adobe_cmykcolor 0 0
%%DocumentProcSets: Adobe_cshow 0 0
%%DocumentSuppliedProcSets: Adobe_cshow 0 0
%%DocumentProcSets: Adobe_customcolor 0 0
%%DocumentSuppliedProcSets: Adobe_customcolor 0 0
%%DocumentProcSets: Adobe_Illustrator881 0 0
%%DocumentSuppliedProcSets: Adobe_Illustrator881 0 0
%%ColorUsage: Black&White
%%DocumentProcessColors: Black
%%DocumentFonts: Helvetica-Bold
%%+ Helvetica
%%BoundingBox:-26 8 403 328
%%TemplateBox:227 179 227 179
%%TileBox:-637 509 -85 1239
%%EndComments
%%BeginProcSet: Adobe_packedarray 0 0
% packedarray Operators
% Version 1.0 5/9/1988
% Copyright (C) 1987, 1988
% Adobe Systems Incorporated
% All Rights Reserved
userdict /Adobe_packedarray 5 dict dup begin put
/initialize % - initialize -
{
/packedarray where
{
pop
}
{
Adobe_packedarray begin
Adobe_packedarray
{
dup xcheck
{
bind
} if
userdict 3 1 roll put
} forall
end
} ifelse
} def
/terminate % - terminate -
{
} def
/packedarray % arguments count packedarray array
{
array astore readonly
} def
/setpacking % boolean setpacking -
{
pop
} def
/currentpacking % - setpacking boolean
{
false
} def
currentdict readonly pop end
%%EndProcSet
Adobe_packedarray /initialize get exec
%%BeginProcSet: Adobe_cmykcolor 0 0
% cmykcolor Operators
% Version 1.1 1/23/1989
% Copyright (C) 1987, 1988, 1989
% Adobe Systems Incorporated
% All Rights Reserved
currentpacking true setpacking
userdict /Adobe_cmykcolor 4 dict dup begin put
/initialize % - initialize -
{
/setcmykcolor where
{
pop
}
{
userdict /Adobe_cmykcolor_vars 2 dict dup begin put
/_setrgbcolor
/setrgbcolor load def
/_currentrgbcolor
/currentrgbcolor load def
Adobe_cmykcolor begin
Adobe_cmykcolor
{
dup xcheck
{
bind
} if
pop pop
} forall
end
end
Adobe_cmykcolor begin
} ifelse
} def
/terminate % - terminate -
{
currentdict Adobe_cmykcolor eq
{
end
} if
} def
/setcmykcolor % cyan magenta yellow black setcmykcolor -
{
1 sub 4 1 roll
3
{
3 index add neg dup 0 lt
{
pop 0
} if
3 1 roll
} repeat
Adobe_cmykcolor_vars /_setrgbcolor get exec
pop
} def
/currentcmykcolor % - currentcmykcolor cyan magenta yellow black
{
Adobe_cmykcolor_vars /_currentrgbcolor get exec
3
{
1 sub neg 3 1 roll
} repeat
0
} def
currentdict readonly pop end
setpacking
%%EndProcSet
%%BeginProcSet: Adobe_cshow 0 0
% cshow Operator
% Version 1.1 1/23/1989
% Copyright (C) 1987, 1988, 1989
% Adobe Systems Incorporated
% All Rights Reserved
currentpacking true setpacking
userdict /Adobe_cshow 3 dict dup begin put
/initialize % - initialize -
{
/cshow where
{
pop
}
{
userdict /Adobe_cshow_vars 1 dict dup begin put
/_cshow % - _cshow proc
{} def
Adobe_cshow begin
Adobe_cshow
{
dup xcheck
{
bind
} if
userdict 3 1 roll put
} forall
end
end
} ifelse
} def
/terminate % - terminate -
{
} def
/cshow % proc string cshow -
{
exch
Adobe_cshow_vars
exch /_cshow
exch put
{
0 0 Adobe_cshow_vars /_cshow get exec
} forall
} def
currentdict readonly pop end
setpacking
%%EndProcSet
%%BeginProcSet: Adobe_customcolor 0 0
% Custom Color Operators
% Version 1.0 5/9/1988
% Copyright (C) 1987, 1988
% Adobe Systems Incorporated
% All Rights Reserved
currentpacking true setpacking
userdict /Adobe_customcolor 5 dict dup begin put
/initialize % - initialize -
{
/setcustomcolor where
{
pop
}
{
Adobe_customcolor begin
Adobe_customcolor
{
dup xcheck
{
bind
} if
pop pop
} forall
end
Adobe_customcolor begin
} ifelse
} def
/terminate % - terminate -
{
currentdict Adobe_customcolor eq
{
end
} if
} def
/findcmykcustomcolor % cyan magenta yellow black name findcmykcustomcolor object
{
5 packedarray
} def
/setcustomcolor % object tint setcustomcolor -
{
exch
aload pop pop
4
{
4 index mul 4 1 roll
} repeat
5 -1 roll pop
setcmykcolor
} def
/setoverprint % boolean setoverprint -
{
pop
} def
currentdict readonly pop end
setpacking
%%EndProcSet
%%BeginProcSet: Adobe_Illustrator881 0 0
% Adobe Illustrator (TM) Prolog
% Version 1.19 1/23/1989
% Copyright (C) 1987, 1988, 1989
% Adobe Systems Incorporated
% All Rights Reserved
currentpacking true setpacking
userdict /Adobe_Illustrator881 72 dict dup begin put
% initialization
/initialize % - initialize -
{
userdict /Adobe_Illustrator881_vars 29 dict dup begin put
% paint operands
/_lp /none def
/_pf {} def
/_ps {} def
/_psf {} def
/_pss {} def
% text operands
/_a null def
/_as null def
/_tt 2 array def
/_tl 2 array def
/_tm matrix def
/t {} def
% color operands
/_gf null def
/_cf 4 array def
/_if null def
/_of false def
/_fc {} def
/_gs null def
/_cs 4 array def
/_is null def
/_os false def
/_sc {} def
/_i null def
Adobe_Illustrator881 begin
Adobe_Illustrator881
{
dup xcheck
{
bind
} if
pop pop
} forall
end
end
Adobe_Illustrator881 begin
Adobe_Illustrator881_vars begin
newpath
} def
/terminate % - terminate -
{
end
end
} def
% definition operators
/_ % - _ null
null def
/ddef % key value ddef -
{
Adobe_Illustrator881_vars 3 1 roll put
} def
/xput % key value literal xput -
{
dup load dup length exch maxlength eq
{
dup dup load dup
length 2 mul dict copy def
} if
load begin def end
} def
/npop % integer npop -
{
{
pop
} repeat
} def
% marking operators
/sw % ax ay length string sw x y
{
stringwidth
exch 5 -1 roll 3 index 1 sub mul add
4 1 roll 3 1 roll 1 sub mul add
} def
/ss % ax ay length string matrix ss -
{
3 -1 roll pop
4 1 roll
{
2 npop (0) exch
2 copy 0 exch put pop
gsave
false charpath
currentpoint
4 index setmatrix
stroke
grestore
moveto
2 copy rmoveto
} exch cshow
3 npop
} def
% path operators
/sp % ax ay length string sp -
{
exch pop
{
2 npop (0) exch
2 copy 0 exch put pop
false charpath
2 copy rmoveto
} exch cshow
2 npop
} def
% path construction operators
/pl % x y pl x y
{
transform
0.25 sub round 0.25 add exch
0.25 sub round 0.25 add exch
itransform
} def
/setstrokeadjust where
{
pop true setstrokeadjust
/c % x1 y1 x2 y2 x3 y3 c -
{
curveto
} def
/C
/c load def
/v % x2 y2 x3 y3 v -
{
currentpoint 6 2 roll curveto
} def
/V
/v load def
/y % x1 y1 x2 y2 y -
{
2 copy curveto
} def
/Y
/y load def
/l % x y l -
{
lineto
} def
/L
/l load def
/m % x y m -
{
moveto
} def
}
{
/c
{
pl curveto
} def
/C
/c load def
/v
{
currentpoint 6 2 roll pl curveto
} def
/V
/v load def
/y
{
pl 2 copy curveto
} def
/Y
/y load def
/l
{
pl lineto
} def
/L
/l load def
/m
{
pl moveto
} def
} ifelse
% graphic state operators
/d % array phase d -
{
setdash
} def
/cf % - cf flatness
currentflat def
/i % flatness i -
{
dup 0 eq
{
pop cf
} if
setflat
} def
/j % linejoin j -
{
setlinejoin
} def
/J % linecap J -
{
setlinecap
} def
/M % miterlimit M -
{
setmiterlimit
} def
/w % linewidth w -
{
setlinewidth
} def
% path painting operators
/H % - H -
{} def
/h % - h -
{
closepath
} def
/N % - N -
{
newpath
} def
/n % - n -
/N load def
/F % - F -
{
_pf
} def
/f % - f -
{
closepath
F
} def
/S % - S -
{
_ps
} def
/s % - s -
{
closepath
S
} def
/B % - B -
{
gsave F grestore
S
} def
/b % - b -
{
closepath
B
} def
/W % - W -
{
clip
} def
% text painting operators
/ta % length string ta ax ay length string
{
_as moveto
_tt aload pop 4 -2 roll
} def
/tl % - tl -
{
_tl aload pop translate
} def
/as % - as array
{
{
0 0
}
{
2 copy _tt aload pop 4 -2 roll sw
exch neg 2 div exch neg 2 div
}
{
2 copy _tt aload pop 4 -2 roll sw
exch neg exch neg
}
{
0 0
}
} cvlit def
/z % literal size leading tracking align z -
{
/_a exch ddef
/_as as _a get ddef
_a 2 le
{
0 _tt astore pop
0 exch neg _tl astore pop
}
{
0 exch neg _tt astore pop
neg 0 _tl astore pop
} ifelse
exch findfont exch scalefont setfont
} def
/tm % matrix tm -
{
_tm currentmatrix pop
concat
} def
/I % matrix I -
{
tm
/t
{
ta sp
tl
} ddef
} def
/o % matrix o -
{
tm
/t
{
ta 4 npop
tl
newpath
} ddef
} def
/e % matrix e -
{
tm
/t
{
ta _psf
tl
newpath
} ddef
} def
/r % matrix r -
{
tm
/t
{
ta _tm _pss
tl
newpath
} ddef
} def
/a % matrix a -
{
tm
/t
{
2 copy
ta _psf
newpath
ta _tm _pss
tl
newpath
} ddef
} def
/T % - T -
{
_tm setmatrix
} def
% font operators
/Z % array literal literal direction Z -
{
pop
findfont begin
currentdict dup length 1 add dict begin
{
1 index /FID ne
{
def
}
{
2 npop
} 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
} def
% group operators
/u % - u -
{} def
/U % - U -
{} def
/q % - q -
{
gsave
} def
/Q % - Q -
{
grestore
} def
% place operators
/` % matrix llx lly urx ury string ` -
{
/_i save ddef
6 1 roll 4 npop
concat
userdict begin
/showpage {} def
false setoverprint
pop
} def
/~ % - ~ -
{
end
_i restore
} def
% color operators
/O % flag O -
{
0 ne
/_of exch ddef
/_lp /none ddef
} def
/R % flag R -
{
0 ne
/_os exch ddef
/_lp /none ddef
} def
/g % gray g -
{
/_gf exch ddef
/_fc
{
_lp /fill ne
{
_of setoverprint
_gf setgray
/_lp /fill ddef
} if
} ddef
/_pf
{
_fc
fill
} ddef
/_psf
{
_fc
exch pop
ashow
} ddef
/_lp /none ddef
} def
/G % gray G -
{
/_gs exch ddef
/_sc
{
_lp /stroke ne
{
_os setoverprint
_gs setgray
/_lp /stroke ddef
} if
} ddef
/_ps
{
_sc
stroke
} ddef
/_pss
{
_sc
ss
} ddef
/_lp /none ddef
} def
/k % cyan magenta yellow black k -
{
_cf astore pop
/_fc
{
_lp /fill ne
{
_of setoverprint
_cf aload pop setcmykcolor
/_lp /fill ddef
} if
} ddef
/_pf
{
_fc
fill
} ddef
/_psf
{
_fc
exch pop
ashow
} ddef
/_lp /none ddef
} def
/K % cyan magenta yellow black K -
{
_cs astore pop
/_sc
{
_lp /stroke ne
{
_os setoverprint
_cs aload pop setcmykcolor
/_lp /stroke ddef
} if
} ddef
/_ps
{
_sc
stroke
} ddef
/_pss
{
_sc
ss
} ddef
/_lp /none ddef
} def
/x % cyan magenta yellow black name gray x -
{
/_gf exch ddef
findcmykcustomcolor
/_if exch ddef
/_fc
{
_lp /fill ne
{
_of setoverprint
_if _gf 1 exch sub setcustomcolor
/_lp /fill ddef
} if
} ddef
/_pf
{
_fc
fill
} ddef
/_psf
{
_fc
exch pop
ashow
} ddef
/_lp /none ddef
} def
/X % cyan magenta yellow black name gray X -
{
/_gs exch ddef
findcmykcustomcolor
/_is exch ddef
/_sc
{
_lp /stroke ne
{
_os setoverprint
_is _gs 1 exch sub setcustomcolor
/_lp /stroke ddef
} if
} ddef
/_ps
{
_sc
stroke
} ddef
/_pss
{
_sc
ss
} ddef
/_lp /none ddef
} def
% locked object operators
/A % value A -
{
pop
} def
currentdict readonly pop end
setpacking
%%EndProcSet
%%EndProlog
%%BeginSetup
Adobe_cmykcolor /initialize get exec
Adobe_cshow /initialize get exec
Adobe_customcolor /initialize get exec
Adobe_Illustrator881 /initialize get exec
%%BeginEncoding: _Helvetica-Bold Helvetica-Bold
[
39/quotesingle 96/grave 128/Adieresis/Aring/Ccedilla/Eacute/Ntilde/Odieresis
/Udieresis/aacute/agrave/acircumflex/adieresis/atilde/aring/ccedilla/eacute
/egrave/ecircumflex/edieresis/iacute/igrave/icircumflex/idieresis/ntilde
/oacute/ograve/ocircumflex/odieresis/otilde/uacute/ugrave/ucircumflex
/udieresis/dagger/degree/cent/sterling/section/bullet/paragraph/germandbls
/registered/copyright/trademark/acute/dieresis/.notdef/AE/Oslash
/.notdef/plusminus/.notdef/.notdef/yen/mu/.notdef/.notdef
/.notdef/.notdef/.notdef/ordfeminine/ordmasculine/.notdef/ae/oslash
/questiondown/exclamdown/logicalnot/.notdef/florin/.notdef/.notdef
/guillemotleft/guillemotright/ellipsis/.notdef/Agrave/Atilde/Otilde/OE/oe
/endash/emdash/quotedblleft/quotedblright/quoteleft/quoteright/divide
/.notdef/ydieresis/Ydieresis/fraction/currency/guilsinglleft/guilsinglright
/fi/fl/daggerdbl/periodcentered/quotesinglbase/quotedblbase/perthousand
/Acircumflex/Ecircumflex/Aacute/Edieresis/Egrave/Iacute/Icircumflex
/Idieresis/Igrave/Oacute/Ocircumflex/.notdef/Ograve/Uacute/Ucircumflex
/Ugrave/dotlessi/circumflex/tilde/macron/breve/dotaccent/ring/cedilla
/hungarumlaut/ogonek/caron
]/_Helvetica-Bold/Helvetica-Bold 0 Z
%%EndEncoding
%%BeginEncoding: _Helvetica Helvetica
[
39/quotesingle 96/grave 128/Adieresis/Aring/Ccedilla/Eacute/Ntilde/Odieresis
/Udieresis/aacute/agrave/acircumflex/adieresis/atilde/aring/ccedilla/eacute
/egrave/ecircumflex/edieresis/iacute/igrave/icircumflex/idieresis/ntilde
/oacute/ograve/ocircumflex/odieresis/otilde/uacute/ugrave/ucircumflex
/udieresis/dagger/degree/cent/sterling/section/bullet/paragraph/germandbls
/registered/copyright/trademark/acute/dieresis/.notdef/AE/Oslash
/.notdef/plusminus/.notdef/.notdef/yen/mu/.notdef/.notdef
/.notdef/.notdef/.notdef/ordfeminine/ordmasculine/.notdef/ae/oslash
/questiondown/exclamdown/logicalnot/.notdef/florin/.notdef/.notdef
/guillemotleft/guillemotright/ellipsis/.notdef/Agrave/Atilde/Otilde/OE/oe
/endash/emdash/quotedblleft/quotedblright/quoteleft/quoteright/divide
/.notdef/ydieresis/Ydieresis/fraction/currency/guilsinglleft/guilsinglright
/fi/fl/daggerdbl/periodcentered/quotesinglbase/quotedblbase/perthousand
/Acircumflex/Ecircumflex/Aacute/Edieresis/Egrave/Iacute/Icircumflex
/Idieresis/Igrave/Oacute/Ocircumflex/.notdef/Ograve/Uacute/Ucircumflex
/Ugrave/dotlessi/circumflex/tilde/macron/breve/dotaccent/ring/cedilla
/hungarumlaut/ogonek/caron
]/_Helvetica/Helvetica 0 Z
%%EndEncoding
%%EndSetup
0 R
0 G
0 i 0 J 0 j 1.5 w 10 M []0 d
%%Note:
257 155.124 m
250 155.124 l
248 154.943 248 153.562 v
248 151.687 250 151.999 y
257 151.999 l
257 73.624 l
253 73.624 l
253 77.624 l
246.5 77.624 l
246.5 74.624 l
24.5 74.624 l
24.5 266.624 l
24 268.124 l
254 268.124 l
254 264.124 l
257 264.124 l
257 155.124 l
S
0 A
u
0.5 w
144 92.999 m
173 92.999 l
173 81.499 l
144 81.499 l
144 85.499 l
149.125 86.999 144 89.249 v
144 92.999 l
s
U
u
0 O
0.7 g
184 109.249 m
217.25 109.249 l
217.25 97.749 l
184 97.749 l
184 101.749 l
189.125 103.249 184 105.499 v
184 109.249 l
b
U
u
183.75 92.749 m
217.25 92.749 l
217.25 81.249 l
183.75 81.249 l
183.75 85.249 l
188.875 86.749 183.75 88.999 v
183.75 92.749 l
b
U
u
134.5 235.75 m
134.5 258.25 L
111.5 258.25 L
111.5 235.75 L
134.5 235.75 L
s
123 247 m
S
U
u
131.8 198 m
131.8 216 L
113.4 216 L
113.4 198 L
131.8 198 L
s
122.6 207 m
S
U
u
235.5 167.999 m
235.5 185.499 L
216.5 185.499 L
216.5 167.999 L
235.5 167.999 L
s
226 176.749 m
S
U
u
236 194.249 m
236 211.749 L
217 211.749 L
217 194.249 L
236 194.249 L
s
226.5 202.999 m
S
U
u
236.5 220.749 m
236.5 238.249 L
217.5 238.249 L
217.5 220.749 L
236.5 220.749 L
s
227 229.499 m
S
U
u
236.5 246.249 m
236.5 263.749 L
217.5 263.749 L
217.5 246.249 L
236.5 246.249 L
s
227 254.999 m
S
U
u
192.797 175.84 m
192.797 208.159 L
159.202 208.159 L
159.202 175.84 L
192.797 175.84 L
s
176 192 m
S
U
u
257 159.499 m
257 187.999 L
248.5 187.999 L
248.5 159.499 L
257 159.499 L
s
252.75 173.749 m
S
U
u
257 120.249 m
257 148.749 L
248.5 148.749 L
248.5 120.249 L
257 120.249 L
s
252.75 134.499 m
S
U
u
256.75 197.249 m
256.75 225.749 L
248.25 225.749 L
248.25 197.249 L
256.75 197.249 L
s
252.5 211.499 m
S
U
u
256.75 232.749 m
256.75 261.249 L
248.25 261.249 L
248.25 232.749 L
256.75 232.749 L
s
252.5 246.999 m
S
U
u
257 85.749 m
257 114.249 L
248.5 114.249 L
248.5 85.749 L
257 85.749 L
s
252.75 99.999 m
S
U
242.5 267.999 m
242.5 74.999 l
S
207.5 267.999 m
207.5 162.999 l
242.5 162.999 l
S
u
u
u
37.5 85.312 m
37.5 87.562 L
33 87.562 L
33 85.312 L
37.5 85.312 L
s
35.25 86.437 m
S
U
33 87.562 m
32.005 87.625 32.062 86.375 v
32.125 85 33 85.312 y
S
U
u
u
37.5 87.687 m
37.5 89.937 L
33 89.937 L
33 87.687 L
37.5 87.687 L
s
35.25 88.812 m
S
U
33 89.937 m
32.005 90 32.062 88.75 v
32.125 87.375 33 87.687 y
S
U
u
u
37.5 90.125 m
37.5 92.375 L
33 92.375 L
33 90.125 L
37.5 90.125 L
s
35.25 91.25 m
S
U
33 92.375 m
32.005 92.438 32.062 91.187 v
32.125 89.812 33 90.125 y
S
U
u
u
37.5 92.5 m
37.5 94.75 L
33 94.75 L
33 92.5 L
37.5 92.5 L
s
35.25 93.625 m
S
U
33 94.75 m
32.005 94.813 32.062 93.562 v
32.125 92.187 33 92.5 y
S
U
u
u
37.562 94.875 m
37.562 97.125 L
33.062 97.125 L
33.062 94.875 L
37.562 94.875 L
s
35.312 96 m
S
U
33.062 97.125 m
32.068 97.188 32.125 95.937 v
32.187 94.562 33.062 94.875 y
S
U
u
u
37.625 97.25 m
37.625 99.5 L
33.125 99.5 L
33.125 97.25 L
37.625 97.25 L
s
35.375 98.375 m
S
U
33.125 99.5 m
32.13 99.563 32.187 98.312 v
32.25 96.937 33.125 97.25 y
S
U
u
u
37.5 83.125 m
37.5 85.375 L
33 85.375 L
33 83.125 L
37.5 83.125 L
s
35.25 84.25 m
S
U
33 85.375 m
32.005 85.438 32.062 84.188 v
32.125 82.813 33 83.125 y
S
U
U
u
30 107.875 m
28.375 108.06 28.5 105.875 v
28.625 103.687 30 104.125 y
S
u
38 104.125 m
38 107.875 L
30 107.875 L
30 104.125 L
38 104.125 L
s
34 106 m
S
U
U
0.2 w
148.5 87.999 m
S
213 104 m
279 104 l
S
u
264 263.999 m
266.5 264.499 266.5 257.999 v
266.5 251.499 266.5 178.499 y
267.5 174.499 270.5 172.999 v
264.5 172.499 265.5 166.499 v
265.5 81.999 l
266.125 79.999 261.5 76.499 v
S
U
0 O
0 g
1 w
/_Helvetica 7.45 8 0 0 z
[1 0 0 1 277 180]e
3 (ZIF)t
9 (CONNECTOR)t
8 (SEGMENTS)t
T
/_Helvetica 6.45 8 0 2 z
[1 0 0 1 392 24]e
12 (msb-0193A-89)t
T
u
0 R
0 G
0.5 w
192.709 222.514 m
192.709 254.833 L
159.115 254.833 L
159.115 222.514 L
192.709 222.514 L
s
175.912 238.674 m
S
U
u
193.797 128.84 m
193.797 161.159 L
160.202 161.159 L
160.202 128.84 L
193.797 128.84 L
s
177 145 m
S
U
u
81.797 226.84 m
81.797 259.159 L
48.202 259.159 L
48.202 226.84 L
81.797 226.84 L
s
65 243 m
S
U
0.2 w
203.5 87.999 m
204 62 l
S
u
u
0.5 w
81.327 84.624 m
97.904 84.624 l
97.904 78.499 l
81.367 78.499 l
81.367 80.624 l
82.548 80.249 82.548 81.749 v
82.548 83.249 81.327 82.562 y
81.327 84.624 l
s
U
u
101.96 84.625 m
118.537 84.625 l
118.537 78.5 l
102 78.5 l
102 80.625 l
103.181 80.25 103.181 81.75 v
103.181 83.25 101.96 82.563 y
101.96 84.625 l
s
U
u
60.628 84.624 m
77.205 84.624 l
77.205 78.499 l
60.667 78.499 l
60.667 80.624 l
61.849 80.249 61.849 81.749 v
61.849 83.249 60.628 82.562 y
60.628 84.624 l
s
U
U
u
u
81.327 95.124 m
97.904 95.124 l
97.904 88.999 l
81.367 88.999 l
81.367 91.124 l
82.548 90.749 82.548 92.249 v
82.548 93.749 81.327 93.062 y
81.327 95.124 l
s
U
u
101.96 95.125 m
118.537 95.125 l
118.537 89 l
102 89 l
102 91.125 l
103.181 90.75 103.181 92.25 v
103.181 93.75 101.96 93.063 y
101.96 95.125 l
s
U
u
60.628 95.124 m
77.205 95.124 l
77.205 88.999 l
60.667 88.999 l
60.667 91.124 l
61.849 90.749 61.849 92.249 v
61.849 93.749 60.628 93.062 y
60.628 95.124 l
s
U
U
u
u
81.327 105.624 m
97.904 105.624 l
97.904 99.499 l
81.367 99.499 l
81.367 101.624 l
82.548 101.249 82.548 102.749 v
82.548 104.249 81.327 103.562 y
81.327 105.624 l
s
U
u
101.96 105.625 m
118.537 105.625 l
118.537 99.5 l
102 99.5 l
102 101.625 l
103.181 101.25 103.181 102.75 v
103.181 104.25 101.96 103.563 y
101.96 105.625 l
s
U
u
60.628 105.624 m
77.205 105.624 l
77.205 99.499 l
60.667 99.499 l
60.667 101.624 l
61.849 101.249 61.849 102.749 v
61.849 104.249 60.628 103.562 y
60.628 105.624 l
s
U
U
u
u
81.327 116.124 m
97.904 116.124 l
97.904 109.999 l
81.367 109.999 l
81.367 112.124 l
82.548 111.749 82.548 113.249 v
82.548 114.749 81.327 114.062 y
81.327 116.124 l
s
U
u
101.96 116.125 m
118.537 116.125 l
118.537 110 l
102 110 l
102 112.125 l
103.181 111.75 103.181 113.25 v
103.181 114.75 101.96 114.063 y
101.96 116.125 l
s
U
u
60.628 116.124 m
77.205 116.124 l
77.205 109.999 l
60.667 109.999 l
60.667 112.124 l
61.849 111.749 61.849 113.249 v
61.849 114.749 60.628 114.062 y
60.628 116.124 l
s
U
U
u
87.797 164.84 m
87.797 197.159 L
54.202 197.159 L
54.202 164.84 L
87.797 164.84 L
s
71 181 m
S
U
u
135.297 139.84 m
135.297 172.159 L
101.702 172.159 L
101.702 139.84 L
135.297 139.84 L
s
118.5 156 m
S
U
0 O
0 g
1 w
/_Helvetica 7.45 8 0 2 z
[1 0 0 1 168 46]e
6 (EEPROM)t
T
u
0 R
0 G
0.2 w
153.5 87.999 m
154 57 l
S
U
u
0.8 G
2 w 4 M
202.199 119.151 m
202.199 263.028 L
151.8 263.028 L
151.8 119.151 L
202.199 119.151 L
s
176.999 191.089 m
S
U
0 G
0.4 w
29.5 180.937 m
46 181 l
46 121.5 l
29.5 121.5 l
29.5 125 l
31.812 125 l
31.875 126.75 l
33.75 126.75 l
33.75 175.5 l
31.25 175.5 l
31.25 177.25 l
29.5 177.25 l
29.5 180.937 l
s
32.437 180.937 m
21.75 184.5 l
21.75 178.5 l
23.5 174.75 l
26 174.75 l
24.75 177.25 l
29.5 177.25 l
S
u
32.25 121.5 m
21.75 117.75 l
21.75 123.75 l
23.5 127.5 l
26 127.5 l
24.75 125 l
29.5 125 l
S
U
0 O
0 g
1 w
/_Helvetica-Bold 12 13 0 0 z
[1 0 0 1 -19 318]e
18 (VAX 6000 Model 400)t
16 (CPU Module T2015)t
T
/_Helvetica-Bold 10 10 0 0 z
[1 0 0 1 287 99]e
20 (Diagnostic ROM \(E77\))t
22 ( Remove 23-020E9-00)t
25 ( Insert 23-026E9-00)t
T
[1 0 0 1 198 44]e
17 (Console ROm \(E97\))t
23 ( Remove 23-019E9-00)t
26 ( Insert 23-027E9-00)t
T
0.7 g
0 R
0 G
0.5 w 10 M
-21 302 m
398 302 l
B
-21 12 m
398 12 l
B
%%Trailer
Adobe_Illustrator881 /terminate get exec
Adobe_customcolor /terminate get exec
Adobe_cshow /terminate get exec
Adobe_cmykcolor /terminate get exec
% 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
26934 37373 XY F36(1)S
PP
EP
%%Trailer
EndDVC$PSDoc
%%DocumentFonts: Helvetica-Bold@DOCPSE
%%Pages 1
|
| 49.32 | t2015 update | COMICS::ROBB | | Thu Jun 14 1990 12:41 | 111 |
| From: KERNEL::COMICS::LINDLEY "Brian Lindley, U.K. Support 833-4568 12-Jun-1990 1408" 12-JUN-1990 14:11:28.81
To: @6000
CC: LINDLEY
Subj: T2015 Update
Gentlemen
This mail is again related to the problems with the T2015. For ease
of reading I have split it into the following sections :-
o More on the "Known Problems" with the T2015.
o Technical Update on the fixes for "Known Problems"
o Position of Console and Diagnostic ROMs ( for console upgrade )
o Corporate "Party Line"
o More on the "Known Problems" with the T2015.
The high consuption rate of the T2015 has prompted investigations
from Nijmegen and Galway. The most common failure mode of the
module is the F-chip problem, which is itself can show itself in
different ways :-
+ Failing tests T35-T37 of Power Up/RBDs.
+ CPUSPINWAIT Bugchecks.
+ DAL Parity Errors.
+ System crashes with MULL2 or MULL3 instructions being pointed
to by the failing PC.
All of the above, with the exception of the DAL Parity Errors, have
been found to be caused by Dendritic Growth ( similar to Silver
Migration ). CSSE Would like any modules which are showing DAL
parity errors in order to establish if there is a similar link.
A cleaning and sealing process has been established to prevent the
dendritic growth. This process started in Nijmegen and Galway last
week, and Engineering are looking at longer term solutions as well.
The key to the failure modes are the MULL2 and MULL3 instructions.
Analysis of test T35-T37 failures have shown that its the MULL3
instruction at fault. Analysis of the CPUSPINWAIT bugchecks have
also shown the MULL3 instruction to be at fault. ( The Spinwait
routine uses this instruction to calculate the time spent waiting
for a spinlock. )
As detailed in the last communication, Logistics are currently
purchasing 150 T2015s from manufacturing to aid spares situation. I
have been assured by Nijmegen that we will have on-the-self spares
within two weeks and we will not have to P1 orders from Nijmegen.
o Technical Update on fixes for "Known Probems"
Revision L. of the T2015 will cure all outstanding "Known
Problems" :-
+ All the above mentioned problems.
+ MOVC5 Problem
+ PC +/- 4 Problem
Unfortuately this revision of the module will not be available
until the October timeframe, and until then we have to keep
sufficient stock in place to address the product problems.
o Position of Console and Diagnostic ROMs ( for console upgrade )
Some of the upgrade documentation is not clear on the position of
the Console and Diagnostic ROMs. There is a schematic of the T2015
on page 3-2 of the VAX 6000-400 Options and Maintenance manual,
which can be used as a reference. The two ROMs are labelled ROM0
and ROM1.
+ ROM0 is E97 and is the Console ROM. The part number is 019E9
( for Console Version 1.0 ) or 027E9 ( for Console Version
2.0 ).
+ ROM1 is E77 and is the Diagnostic ROM. The part number is
020E9 ( for Console Version 1.0 ) or 026E9 ( for Console
Version 2.0 ).
o Corporate "Party Line"
The following is a statement released by Product Management and
"Should be communicated directly to effected customers only. By
communicating it provides the customer with a Digital contact."
"THIS MESSAGE IS NOT FOR GENERAL RELEASE"
********************************************************************
SUBJECT: VAX 6000-400 PARTY-LINE MESSAGE
Your site is one of a limited number of Digital sites that have
recently experienced an above average number of VAX 6000-4xx
failures. The problem has been narrowed to the CPU module. Isolation
and resolution of these failures has been designated the highest
priority, and all necessary resources have been dedicated to this
problem. We will continue to insure that adequate spares are
available to support customer needs.
In recognition of your understanding while we resolve this issue,
Digital will continue providing warranty support until we
effectively and permanently resolve the current situation.
********************************************************************
If you have any questions or quiries with regard to any of the
above ( or you have a T2015 which is giving DAL parity errors )
please contact me.
Regards
Brian
|
| 49.33 | erkax failures on rev K | COMICS::ROBB | | Thu Jun 14 1990 16:35 | 96 |
| From: KERNEL::COMICS::LINDLEY "Brian Lindley, U.K. Support 833-4568 12-Jun-1990 1902" 12-JUN-1990 19:06:46.60
To: @6000
CC: LINDLEY
Subj: Diagnostic ERKAX failure on T2015 Rev J. or Rev. K
Gentlemen,
There is a problem when running ERKAX ( KA64A Manual Diagnostic )
on Revision K of the T2015.
The problem does not occur if a T2017 Vector module is attached to
the Rev K05 T2015. If the T2015 module is a rev H05 with V2.0 ROMs
(i.e a Rev J05 T2015) then the same problem causes test 10 to fail.
When executing ERKAX, test 20 will fail only if all the manual tests
(1-6) are run initially. The fix included below works only with
Diagnostic Supervisor ERSAA-12.6-733.
The diagnostic fails after Test 20 with the following error:
?? Software detected error in "DISPATCH", error #1, 1-JAN-1990 00:06:12.12
PC: 0002A698 PSL: 00000000
R0: 00005D54 R1: 00000000 R2: 22222222 R3: 00006C38
R4: 00001744 R5: 0000000D R6: 66666666 R7: 0000000E
R8: 88888888 R9: 99999999 R10: AAAAAAAA R11: BBBBBBBB
DSA$GL_Flags: 00003400(X) DS$GL_Flags: 00860086(X) Version: 12.6-733
0004D398:00000000 2FFC0000 00000518 0004D3E8 0002A698 22222222 00006C38 00001744
0004D3B8:0000000D 66666666 0000000E 88888888 99999999 AAAAAAAA BBBBBBBB 00000003
0004D3D8:00000001 00000000 00013E34 0003672F 0002B9A8 20000000 CCCCCCCC 00000000
0004D3F8:00020E48 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0004D418:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0004D438:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0004D458:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0004D478:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
******** End of Software detected error number 1 ********
The problem has been found to be a corrupt memory location following
a WARM RESTART. After a WARM RESTART is executed, a location in the
dispatch table used by the VAX Diagnostic Supervisor (VAX/DS) to
execute tests is corrupted. When the VAX/DS indexes into the
dispatch table to begin executing Test 21, the address containing
the test mask for Test 21 has been overwritten. The VAX/DS compares
this test mask with the current test it should be executing and
issues the above error because the two values are not equal.
Workaround:
----------
The above problem can be corrected with a simple DEPOSIT command
from the console. After executing Test 20 of ERKAX, the terminal
displays the following:
Test 20: ACV or TNV During Machine Check Halt Test
Do the following to continue from console mode:
D/I 4 0004DC00 <CR>
S 100 <CR> to continue or S 50 <CR> to abort
HALT expected with the following printout:
?10 ACV/TNV occurred during machine check processing.
PC = 00005F45
?10 ACV/TNV occurred during machine check processing.
PC = 00005F45
PSL = 041F9000
ISP = 00006E24
>>>
Instead of typing:
>>>D/I 4 0004DC00 <CR>
>>>S 100 <CR>
The operator should type:
>>>D/I 4 0004DC00 <CR>
>>>D/P/L 518 6010 <CR> <--- Note new DEPOSIT command
>>>S 100
A DEPOSIT of 6010 to location 518 will restore the address in the
dispatch table which was overwritten. The diagnostic will then
proceed normally.
The long term solution will be a fix in the Console ROM.
Regards
Brian
|
| 49.34 | Rigel Vector release notes | COMICS::ROBB | | Thu Jun 14 1990 16:40 | 94 |
| From: KERNEL::COMICS::LINDLEY "Brian Lindley, U.K. Support 833-4568 12-Jun-1990 1930" 12-JUN-1990 20:10:04.89
To: @6000
CC: LINDLEY
Subj: Rigel Vector Release Notes
Gentlemen
The following is the release notes for the Rigel Vector ( T2017 ).
This is for imformation only as we have not sold any Vector options
in the U.K. as yet. Please be aware of the last paragraph
"Additional Comments".
Regards
Brian
***********************************************************************
There are several issues related to the introduction of VAX 6000 4XX
VECTORS of which Customer Service Personnel need to be made aware.
Limited shipments commence May 11.
1. VAX 6000 - 4XX VECTORs (T2017) require a REV K Scalar (T2015)
to be attatched to the VECTOR.
2. In sytems that have VECTORS all Scalar modules must be at REV K
or REV J.
3. Only a Memory module can be placed to the left of a VECTOR module
in the XMI backplane, otherwise damage can occur.
4. VECTOR modules can be shipped only in the ESD Box, 99-08536-02,
otherwise damage can occur. This is a REV change from the original
XMI ESD box. The part number will be on a label on the top of
the box. No other identifier is supplied.
5. For each VECTOR, a system should have 64 megabytes of memory to
have reasonable performance.
6. Dual Scalar Vector pairs will not be supported until Q2 of FY 91.
Testing has reveeled that this configuration is not working
properly.
7. Diagnostics: Prerelease kits may be ordered from the SSB
VAX6400 VECTOR Cmplt Diag Set (TK50) AQ-PBPRA-DE
VAX6400 VECTOR Cmplt Diag Set (Mag tape) BB-PBPSA-DE
or
Copied from VOLKS::RIGEL$DIAG_VECTORS:
8. Documentation: At FRS most Customer Service manuals will be
preliminary. Listed below are manuals most pertinent to VECTORS.
VAX 6000 Series Upgrade Manual (VCT Install) EK-600EB-UP-002
VAX 6000 VECTOR Processor Owner's Manual EK-60VAA-OM-001
VAX 6000-400 System Technical User's Guide EK-640EA-TM-002
VAX 6000-400 Option & Manintenance Manual EK-640EB-MG-002
VAX 6000-400 VECTOR Proc. Programer's Guide EK-64VEA-OM-001
VECTOR Processing Concepts Student Workbook EY-9876E-SG-001
VAX VECTOR Processing Handbook EC-H0419-46/89
RESOLUTION/WORKAROUND:
1. REV K of the Scalar module (T2015) is the minimum Rev that can be
attached to a VECTOR (T2017) module.
2. The current Rev of the Scalar module is Rev. H. It is
incompatible with Rev. K. Customer Service personnel can build a
Rev. J which is compatible by replacing the console and diagnostic
ROMs on Rev. H modules. ROMs and instructions are in the initial
released kit of the VECTOR option.
3. Place no other modules but memories next to the VECTOR.
4. Use only the 99-08536-02 ESD box with a VECTOR Module.
5. Inform the customer and Digital sales personnel of the correct
size of memory.
6. Dual Scalar Vector pairs do not work properly and are not
supported. Customers should NOT cofigure their systems with Dual
Scalar Vector pairs!
ADDITIONAL COMMENTS:
The VECTOR Module, the T2017, will require an FCO to fix known
hardware problems that in the current version are worked around
either in hardware and software or in product restrictions. To
become familiar with these restrictions read the VAX 6000 Series
Vector Option Release Notes.
|
| 49.35 | FCHIP SELFTEST FAILURE example | KERNEL::BLAND | toward 2000 ... | Fri Jun 15 1990 01:56 | 132 |
| Here is an example of a RIGEL FCHIP selftest failure (TEST 35),
the "forcing" of a BOOT CPU and the SYSTEM booting with the
FCHIP disabled.
REM> tr
* Had to type >>1 (force boot CPU) twice to get the selftest map *
* printed out. Once to get to the selftest and the second to get *
* the extended selftest. *
F E D C B A 9 8 7 6 5 4 3 2 1 0 NODE #
A A . . M M . . . . . . . P TYP
o o . . + + . . . . . . . - STF
. . . . . . . . . . . . . B BPD
. . . . . . . . . . . . . - ETF
. . . . . . . . . . . . . B BPD
. . . . A2 A1 . . . . . . . . ILV
. . . . 32 32 . . . . . . . . 64 Mb
ROM0 = V1.00 ROM1 = V1.00 EEPROM = 1.00/1.00 SN = GA94300188
>>> T/R
RBD1> ST 0/TR/HE !execute RBD0
;XRP_ST 1.00
; T0001 T0002 T0003 T0004 T0005 T0006 T0007 T0008 T0009 T0010
; T0011 T0012 T0013 T0014 T0015 T0016 T0017 T0018 T0019 T0020
; T0021 T0022 T0023 T0024 T0025 T0026 T0027 T0028 T0029 T0030
; T0031 T0032 T0033 T0034 T0035
; F 1 8082 1
; HE F-CHIP XX T0035
; 25 1194A200 001194A2 00000000 00000000 20067CAD 04
; F 1 8082 1
;00000000 00000001 00000000 00000000 00000000 00000000 00000000
RBD1> ST 0/TR/HE !and again
;XRP_ST 1.00
; T0001 T0002 T0003 T0004 T0005 T0006 T0007 T0008 T0009 T0010
; T0011 T0012 T0013 T0014 T0015 T0016 T0017 T0018 T0019 T0020
; T0021 T0022 T0023 T0024 T0025 T0026 T0027 T0028 T0029 T0030
; T0031 T0032 T0033 T0034 T0035
; F 1 8082 1
; HE F-CHIP XX T0035
; 25 1194A200 001194A2 00000000 00000000 20067CAD 04
; F 1 8082 1
;00000000 00000001 00000000 00000000 00000000 00000000 00000000
* Failing test 35 (F-Chip test) - MULL3 instruction *
RBD1> QUIT
?06 Halt instruction executed in kernel mode.
PC = 200601D8
PSL = 041F0604
ISP = 201405B4
>>> E/I 28
I 00000028 00000000 !ACCS reg, bit 1 clear, F-Chip disabled
>>> SH CONF
Type Rev
1- KA64A (8082) 0008 !CPU failed selftest
9+ MS62A (4001) 0002
A+ MS62A (4001) 0002
D+ DWMBA/A (2001) 0002
E+ DWMBA/A (2001) 0002
XBI D
1+ DWMBA/B (2107) 000A
6+ DEBNI (0118) 0200
XBI E
1+ DWMBA/B (2107) 000A
4+ CIBCB (0108) 41C1
6+ TBK70 (410B) 0307
>>> SH BOOT
DEFAULT /R5:30000000 /R3:80000000 /XMI:E /BI:4 /NODE:00000100 DU0
CONV /R5:30000001 /R3:80000000 /XMI:E /BI:4 /NODE:00000100 DU0
DIAG /R5:30000010 /XMI:E /BI:4 /NODE:00000100 DU0
STAB /R5:E0000000 /XMI:E /BI:4 /NODE:00000100 DU0
>>> B
Initializing system.
#123456789 0123456789 0123456789 012345
* Hung after failing test 35, forced boot CPU twice *
F E D C B A 9 8 7 6 5 4 3 2 1 0 NODE #
A A . . M M . . . . . . . P TYP
o o . . + + . . . . . . . - STF
. . . . . . . . . . . . . B BPD
. . . . . . . . . . . . . - ETF
. . . . . . . . . . . . . B BPD
. . . . A2 A1 . . . . . . . . ILV
. . . . 32 32 . . . . . . . . 64 Mb
ROM0 = V1.00 ROM1 = V1.00 EEPROM = 1.00/1.00 SN = GA94300188
Loading system software.
* system booted up at this stage *
%SET-I-INTSET, login interactive limit = 0, current interactive value = 0
5-JUN-1990 09:33:47
Reply received on BYPS3 from user SYSTEM at BYPS3 Batch 09:33:48
VAX now accepting logins
SYSTEM job terminated at 5-JUN-1990 09:33:48.77
Accounting information:
Username: FIELD
Password:
Welcome to VAX/VMS V5.2
Last interactive login on Thursday, 31-MAY-1990 11:14
SYSGEN> SH BUGCHECKFATAL
Parameter Name Current Default Minimum Maximum Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
BUGCHECKFATAL 1 0 0 1 Boolean D
SYSGEN> EXIT
* seemed like a good idea *
$
* Hit control P here to look at ACCS reg *
?02 External halt (CTRL/P, break, or external halt)
PC = 801B5CA4
PSL = 04C38201
ISP = 80BCF200
>>> E/I 28
I 00000028 00000000 !ACCS reg, bit 1 clear, F-Chip disabled
>>> C
$
|
| 49.36 | patched sysloa9rr.exe | KERNEL::ROBB | | Thu Jul 26 1990 23:55 | 21 |
|
Hi All,
I gave some good news on a SYSLOA9RR for V5.2 machine check problem.
One of the software engineers in Holland has written a patch to prevent the
system crashing with int54 errors caused by XMI parity problems. The patched
version of SYSLOA9RR.EXE is in our old patches directory in RDC$COMMON and is
available for any engineer who would benefit from having it on site.
Please bear in mind that until we know for ourselves that it will not cause
any problems I would suggest that it initially only used on a clustered system
or one where it is possible to get in and rename it to something harmless should
the system fail to boot.
Note this is an "UNOFFICIAL" patch and should only be used on systems that are
crashing anyway due to XMI parity errors.
Regards,
Ken.
|
| 49.37 | XBIB PROBLEM | KERNEL::BLAND | toward 2000 ... | Thu Aug 09 1990 12:26 | 91 |
| Author : BARBARA GILBERT
User type : AIM
Location : TIMA
Vaxmail address : TIMA::GILBERT
The attached information is from the CSSE Mid-Range Support Group.
It contains important information regarding, XBIB CAUSING MEMORY AND/OR
IO ADAPTER ERRORS.
This information can be found through TIMA STARS
Database: CSSE_TIME_CRITICAL
============================[ Start Message ]==============================
+---------------------------+TM
| | | | | | | |
| d | i | g | i | t | a | l | TIME DEPENDENT CASE
| | | | | | | |
+---------------------------+
TITLE: XBIB CAUSING MEMORY AND/OR IO ADAPTER ERRORS.
DATE:3-AUG-1990
AUTHOR: Jim Vermette TD #: 000363
DTN: 240-6496
ENET: VOLKS::VERMETTE CROSS REFERENCE #'s: NONE
DEPARTMENT: CSSE MID-RANGE SUPPORT (PRISM/TIME/CLD#'s)
INTENDED AUDIENCE: ALL PRIORITY LEVEL: 1
(U.S./EUROPE/GIA) (1=TIME CRITICAL,
2=NON-TIME CRITICAL)
=====================================================================
PROBLEM:
Multiple BI errors, INTR60 (READ ERROR RESPONSE, WRITE ERROR INTERRUPT),
BI ADAPTER INTERRUPTS (NACK to MULTI-RESPNODER CMD RECVD) and MEMORY
CONTROLLER ERROR, have been exhibited on 6000 series systems. It is
also likely that the system will expierence UNEXPECTED I/O ADAPTER INT
bugchecks. Due to the variety of these errors occurring on the BI Bus,
Customer Service Engineers are involved in extensive troubleshooting,
module swapping, and even system swaps.
It has been determined that a problem exist within the XBIB
(T1043) module.
Currently their is a suspicion that the problems may be
caused by a PAL located on the XBIB. The problem, at this
point in time, appears to be a chip vendor related issue. This
is only a preliminary analysis.
Texas Instrument and National Semiconductor manufactured chips
are suspected to be related to this problem. Another vendor
type chip, AMD, used in this application, does not seem to be
related to the problem.
RESOLUTION/WORKAROUND:
If you are experiencing the above mentioned symptoms it is advised
that you check all XBIB modules for the chip type. The location
of the chip in question is at E8. Holding the module component side
facing up and with the BI corner at the lower right hand corner,
the chip is located about half way up the module between the BI
corner and the top right hand corner of the module. E8 is etched
just below the chip.
If the module contains a TI or NS chip at E8 and the system is
experiencing the above mentioned symptoms, order a new XBIB.
Be aware that there is not a guarantee that you will receive an
XBIB with an AMD chip.
ADDITIONAL COMMENTS:
It should be noted that these problems are being seen on new
systems only but may also be present in systems with newly
replaced XBIBs. The PAL problem is marginal and it is possible
that a TI or NS PAL will work.
Engineering is continuing to work this problem. CSSE will continue
to pursue an immediate resolution to the problem and will inform
Customer Services as soon as a solution is in place.
*** DIGITAL INTERNAL USE ONLY ***
=============================[ End Message ]===============================
|
| 49.38 | >>>ESC DEL LKUPVER command | KERNEL::BLAND | toward 2000 ... | Thu Aug 09 1990 14:29 | 88 |
| ================================================================================
Note 94.0 LKUPVER: A Mini-Tutorial No replies
WONDER::NORTON "Charles McKinley Norton | MSB" 83 lines 16-MAR-1989 09:31
--------------------------------------------------------------------------------
********************* PLEASE NOTE ******************************
The enclosed information is for example purposes, only. The output
you will see bears no resemblence to field test console.
********************* END NOTE **********************************
I am writing this note to explain the output from <CTRL/3><ESC>LKUPVER.
(The $^? is what you see when you type <CTRL/3><ESC>.)
>>> $^?LKUPVER?VER 81 0106 10 0106 0100 0100 0000000000
I am including this mini-tutorial, because of the many cards and
letters we received asking why the examples in the console release
notes did not always match the what you see in the field.
(You can see the example above definitely does not match what's in the
field; that is because I copied it from the console emulator.)
When you enter this command, you are asking the console to lookup the
revision levels of several areas in EEPROM and the console ROM
revision.
Based on the example above, here is a descripton of each field.
?VER
----
Response message from the command.
81
--
this is the status code of the LKUPVER command.
^x81 indicates the command completed successfully, indicating nothing
is wrong with the contents of the EEPROM.
^x53 means that when console calculated a checksum on the EEPROM header
(the first longword of EEPROM at ^x20080000), the checksum failed. You
would expect to see this, because console release notes instruct you to
zero the EEPROM header, before replacing console ROMs.
^x57 means one of the EEPROM areas failed the checksum. You probably
will not see this, but, if you do, it could meand the EEPROM did
not blast correctly.
^x81 is what you want to see after blasting an EEPROM. ^x53 is what
you want to see, right after depositing zero into the EEPROM header
before installation of new console ROMs. This means the console will
assume the EEPROM is corrupted and will not turn on patches, when new
console ROMS are installed. This prevents a new console image from
using the patch vector from a previous console.
0106
----
This is the EEPROM format revision. It will change if the format
of the EERPOM changed.
10
--
This is the console ROM revision.
0106
----
This is the console patch revision.
0100
----
This is the console parameter revision.
0100
----
This is the console bootspec area revision.
0000000000
----------
This is the system serial number.
In some instances, a difference in the numbers the release
notes say you should see and the numbers you see, might make a
difference. For the most part, however, the status code is the
make or break thing to see.
Charles Norton
Rigel System Integration/Console Development
Low-End Mid-Range VAX Systems Business | BXB2-2/F02 | DTN: 293-5487
|
| 49.39 | Proactive Swap Program | KERNEL::LINDLEY | | Fri Aug 10 1990 17:45 | 33 |
| The 64XX systems have been showing very poor reliability over
the past few months, the major cause of which being Dendritic
growth. To regain customer confidence in the product a
decision has been taken to implement a proactive swap, so as
to be able to give customers the "more reliable" cleaned and
coated modules. Only Multi-CPU systems will be effected.
This program is particularily targeted at :-
o Customers who have seen Product problems
o Customers who suffer from many CPU failures
o Strategic Customers... i.e. The Big Ones !!!
It is planned that we will replace 25 % of the entire
population of Rigel CPU modules over the next 10 weeks, with
this plan. All FCO co-ordinators in the regions would
contacted and asked to supply the number of modules they would
require, as it is Customer Services who is paying for all this.
There are two senerios as to when T2015 modules will be
replaced :-
o By arrangement with the customer
o If one CPU in the system goes down, all other uncoated
modules should also be replaced.
Extra stock has been perchased to support this plan, so there
should be plenty of T2015s around.
If you have any queries, please contact myself of Dave Hessom.
Brian
|
| 49.40 | Confusion on the Proactive Swap Plan | KERNEL::LINDLEY | | Tue Sep 04 1990 17:02 | 26 |
|
There seems to be some confusion with regard to the sitution
with the T2015, the 6400 CPU module. As I am sure you are
aware there have been several product related problems with
the T2015, all of which will be fixed when rev L of the module
becomes available, later on this year.
In the meantime, Customer Services have put together a
pro-active swap plan to target Strategic customers and
customers who have seen the product problems. As it is
Customer Services who have to pay for these "extra" modules,
it was decided that the local Service Operation would make the
decision as to which customers would benefit from these latest,
"more reliable" modules. It is therefore the Service Operation
who decide when and where these modules are replaced, and of
course it would be desireable if this could be done at the
same time as a CPU failure. Could I therefore ask you not to
send updates to the field to change all CPUs in a system, as
this would have a disasterous effect on the availability of
the module. It is the responsibility of the local office to
include any CPU changes with the pro-active swap program.
If you have any questions or concerns, please contact me.
Regards
Brian
|
| 49.41 | How to recover from EEPROM problems | KERNEL::BLAND | toward 2000 ... | Wed Sep 26 1990 14:32 | 52 |
| Just used this to save a 6000-410 module that had its EEPROM
screwed by an attempt to restore EEPROM to a rev J module from a
rev H module. Problem was EEPROM checksum error. I used RIGEL V2.0
below.
<<< SASE::WRKD:[NOTES$LIBRARY]CALYPSO.NOTE;3 >>>
-< CALYPSO -- VAX 6000-xxx Family Notes >-
================================================================================
Note 684.5 Need help on corrupted EEPROM 5 of 5
PROXY::CROXON "Comming soon to a planet near you..." 37 lines 24-SEP-1990 12:14
-< EEPRom Addresses for blaster >-
--------------------------------------------------------------------------------
5-Aug-1990
A true to form list of addresses to restore the
EEPROM on VAX 6000-xxx series machines. - NJC
Calypso V3.1 >>> jsb 20052A00
Hyperion V4.1 XMA Source Address: 20052E00
EEPROM Destination Address: 20080000
Length: 8000
EEPROM Size <8,32>: 32
Calypso V5.0 >>> jsb 20055000
Hyperion V6.0 XMA Source Address: 20055400
EEPROM Destination Address: 20080000
Length: 8000
EEPROM Size <8,32>: 32
Rigel V1.0 >>> jsb 20053600
XMA Source Address: 20053A00
EEPROM Destination Address is 20080000 (Hex)
The Length is 8000 (hex) -- The entire EEPROM
Assuming write buffer size of 8Kb: 16 bytes per page.
Rigel V2.0 >>> jsb 20054600
XMA Source Address: 20054A00
EEPROM Destination Address is 20080000 (Hex)
The Length is 8000 (hex) -- The entire EEPROM
Assuming write buffer size of 8Kb: 16 bytes per page.
Rigel V3.0 >>> jsb 20055C00
XMA Source Address: 20056000
EEPROM Destination Address is 20080000 (Hex)
The Length is 8000 (hex) -- The entire EEPROM
Assuming write buffer size of 8Kb: 16 bytes per page.
|
| 49.42 | crd's in 6000 | KERNEL::ODONNELLR | | Thu Nov 01 1990 23:01 | 96 |
|
Here is an additional method of finding the CRD buffers for
6000 series systems that does not require a table of offsets
(Thanks to Dave Jansen in IISG). Also, it appears that starting
in version 5.4 all 6000 systems use a common error template. An
example is shown below.
*****************************************************************************
62/63xx Example.
_____________________________________________________________________________
Under SDA do the following command:
(this is from LITE, a 6360 running vms 5.4)
SDA> search/length=word/step=byte sysloa;f000 439e
Searching from 80CC2760 to 80CD1760 in BYTE steps for 439E...
Match at 80CC59FA -----
Match at 80CC5A30 |
Match at 80CCFAE6 |
Match at 80CCFB53 |
SDA> e/i 80cc59fa <----
-----> 80CC59FA: MOVAB @80CC5ADC[R3],R4
|
|
------ This is a code change from VMS 5.3 and below, however it is still a
MOVAB XXXXXXXX[R3],R4. The first match should be the correct
instruction (subject to change, as it has in every version to
date!). The key to look for is the instruction type of MOVAB,
the index mode off of R3, and the destination of R4.
SDA> ex @80cc5adc;100
00000003 06819BE0 06819BE0 000B00AB �...�...�....... 80A523E0
00000000 00000000 00000000 00000001 ................ 80A523F0
Zeros suppressed from 80A52400 through 80A524DF
This entry indicates 1 error was encountered on XMI NODE B.
*****************************************************************************
64xx Example.
_____________________________________________________________________________
(the following is from BUDDRY, a 6430-VP running VMS 5.4)
SDA> search/length=word/step=byte sysloa;f000 439e
Searching from 809FE0A0 to 80A0D0A0 in BYTE steps for 439E...
Match at 80A01852 -----
Match at 80A01888 |
Match at 80A04F10 |
Match at 80A06334 |
Match at 80A067B8 |
Match at 80A06828 |
Match at 80A068F0 |
Match at 80A080D8 |
Match at 80A08117 |
Match at 80A081CC |
Match at 80A085D7 |
SDA> e/i 80a01852 <----
80A01852: MOVAB @80A01934[R3],R4
SDA> ex @80a01934;100
00000001 00080000 00080000 00090020 ............... 80796210
00000000 00000000 00000000 00000001 ................ 80796220
Zeros suppressed from 80796230 through 8079630F
This entry indicates 1 error was encountered on XMI NODE 9.
*****************************************************************************
Common template to use on all 6000 systems starting in version 5.4
_____________________________________________________________________________
Format of CRD footprint
31 0
+--------------------------------------+
| Primary footprint |->|
+--------------------------------------+ |
| Lowest detected address | |
+--------------------------------------+ |
| Highest detected address | |
+--------------------------------------+ |
| Count of CRD's | |
+--------------------------------------+ |
| flags for this footprint | |
+--------------------------------------+ |
|
Format of Primary Footprint |
15 0 |
+--------------------------------------+ |
| ECC syndrome bits |<-|
+--------------------------------------+
| FRU id | (XMI Node #)
+--------------------------------------+
|
| 49.43 | H7214 bad Hybrids | KERNEL::WRIGHTON | odd numbered release = bug insert | Tue Dec 04 1990 07:12 | 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.
|
| 49.44 | Subj: UETP Errors on 6400/6500 with Vector Unit present | COMICS::ROBB | | Sun Dec 16 1990 09:27 | 72 |
| From: KERNEL::COMICS::LINDLEY "Brian Lindley, U.K. Support 833-3659 10-Dec-1990 1707" 10-DEC-1990 17:09:34.09
To: @6000
CC: LINDLEY
Subj: UETP Errors on 6400/6500 with Vector Unit present
PROBLEM:
While VAX6000-4xx and VAX6000-5xx are running UETP test with a
VECTOR processor, the Errors may be encountered (see example).
These errors exist in VMS V5.4-0A or earlier release. The
problem already fixed in VMS V5.4-1, which is to be released in
December.
RESOLUTION/WORKAROUND:
These UETP/VECTOR configuration errors should be ignored since
they are not Hardware related errors. Below , you can see an
example of UETP test errors presented in VAX6000-500 system
with Vector option running UETP test under VMS V5.4 -0A.
N.B. The order number for FV64A Maintenance Advisory is
EK-FV64A-MA-001
Example of Vector/UETP problem
You can choose one or more of the following phases:
DEVICE, LOAD, DECNET, CLUSTER
Phase(s): load
How many passes of UETP do you wish to run [1]?
How many simulated user loads do you want [165]? 10
Do you want Long or Short report format [Long]?
UETP starting at 15-NOV-1990 09:46:14.52 with parameters:
LOAD phases, 1 pass, 10 loads, long report.
%UETP-I-BEGIN, UETLOAD00 beginning at 15-NOV-1990 09:46:15.23
%UETP-I-BEGIN, UETLOAD02_0000 beginning at 15-NOV-1990 09:46:15.55
%UETP-I-BEGIN, UETLOAD03_0001 beginning at 15-NOV-1990 09:46:15.76
%UETP-I-BEGIN, UETLOAD04_0002 beginning at 15-NOV-1990 09:46:15.96
%UETP-I-BEGIN, UETLOAD05_0003 beginning at 15-NOV-1990 09:46:16.15
%UETP-I-BEGIN, UETLOAD06_0004 beginning at 15-NOV-1990 09:46:16.35
%UETP-I-BEGIN, UETLOAD07_0005 beginning at 15-NOV-1990 09:46:16.54
%UETP-I-BEGIN, UETLOAD08_0006 beginning at 15-NOV-1990 09:46:16.74
%UETP-I-BEGIN, UETLOAD09_0007 beginning at 15-NOV-1990 09:46:16.95
%UETP-I-BEGIN, UETLOAD10_0008 beginning at 15-NOV-1990 09:46:17.16
%UETP-I-BEGIN, UETLOAD11_0009 beginning at 15-NOV-1990 09:46:17.40
**********************
15-NOV-1990 09:47:18.80 THEMUT * UETVECTOR *
15-NOV-1990 09:47:18.85 THEMUT * Error count = 1 *
15-NOV-1990 09:47:18.86 THEMUT **********************
15-NOV-1990 09:47:18.95 THEMUT -UETP-E-MSTINTERR, Error initializing master process.
15-NOV-1990 09:47:18.98 THEMUT %SYSTEM-F-IVCHAN, invalid I/O channel
15-NOV-1990 09:47:19.10 THEMUT %PPL-F-NOINIT, PPL$INITIALIZE was not called
15-NOV-1990 09:47:19.80 THEMUT %SYSTEM-F-IVCHAN, invalid I/O channel
15-NOV-1990 09:47:20.80 THEMUT %UETP-I-ENDED, UETLOAD02_0000 ended at 15-NOV-1990 09:46:25.67
15-NOV-1990 09:47:25.80 THEMUT %UETP-I-ENDED, UETLOAD06_0004 ended at 15-NOV-1990 09:46:32.56
15-NOV-1990 09:47:39.80 THEMUT %UETP-I-ENDED, UETLOAD10_0008 ended at 15-NOV-1990 09:46:46.85
15-NOV-1990 09:47:49.80 THEMUT %UETP-I-ENDED, UETLOAD03_0001 ended at 15-NOV-1990 09:46:56.80
15-NOV-1990 09:48:25.80 THEMUT %UETP-I-ENDED, UETLOAD07_0005 ended at 15-NOV-1990 09:47:33.36
15-NOV-1990 09:48:46.80 THEMUT %UETP-I-ENDED, UETLOAD11_0009 ended at 15-NOV-1990 09:47:53.62
15-NOV-1990 09:49:06.80 THEMUT %UETP-I-ENDED, UETLOAD09_0007 ended at 15-NOV-1990 09:48:13.79
15-NOV-1990 09:49:15.80 THEMUT %UETP-I-ENDED, UETLOAD04_0002 ended at 15-NOV-1990 09:48:22.56
15-NOV-1990 09:49:29.80 THEMUT %UETP-I-ENDED, UETLOAD05_0003 ended at 15-NOV-1990 09:48:36.95
15-NOV-1990 09:51:11.36 THEMUT %UETP-I-ENDED, UETLOAD08_0006 ended at 15-NOV-1990 09:50:18.97
15-NOV-1990 09:51:11.80 THEMUT %UETP-I-ENDED, UETLOAD00 ended at 15-NOV-1990 09:50:19.17
|
| 49.45 | Subj: GRAM: CSSE VAX6000/Dual Vector Configurations (BLITZ) | COMICS::ROBB | | Sun Dec 16 1990 09:33 | 86 |
| Subj: GRAM: CSSE VAX6000/Dual Vector Configurations (BLITZ)
Author : BARBARA PATTENDEN
User type : DBA
Location : CSSE
Vaxmail address : CSSE::PATTENDEN
+---------------------------+TM
| | | | | | | |
| d | i | g | i | t | a | l | TIME DEPENDENT CASE
| | | | | | | |
+---------------------------+
TITLE: VAX 6000-4xx VECTOR DATE: December 11, 1990
Customer Service Release notes.
VAX 6000-5xx VECTOR
Customer Service Release notes.
AUTHOR: Ella Libkind TD #:000505
DTN: 293-5022
ENET: MSBCS::LIBKIND CROSS REFERENCE #'s:
DEPARTMENT: CSSE Low End Mid Range (PRISM/TIME/CLD#'s)
INTENDED AUDIENCE:W/W PRIORITY LEVEL: 1
(U.S./EUROPE/GIA) W/W (all areas) (1=TIME CRITICAL,
2=NON-TIME CRITICAL)
=====================================================================
PROBLEM:
Necessity to identify ALL EXTERNAL and INTERNAL
VAX 6000-4xx DUAL VECTOR customers and
VAX 6000-5xx DUAL VECTOR customers.
ALL Customers must be identified ASAP , because
the design problems exist in T2017 (VECTOR module)
used in DUAL VECTOR configuration.
The following is a description of the current design problem:
1. Dual Vector configurations may hang and abort processes
under a particular VECTOR PARALLEL DECOMPOSED application.
2. Dual Vector configurations under heavy system load may
align internal data movement events such that data integrity
would be compromised.
The Problem is corrected with the new revision J02, J03
( ECO T2017-TWO04).
RESOLUTION/WORKAROUND:
=======================
All W/W Field Service Branches who have Customers with
VAX 6000-4xx or VAX 6000-5xx DUAL VECTOR configuration
PLEASE response with following information:
Branch's name -------------------------------
Customer's name------------------------------
GEO code ------------------------------------
Quantity of the Dual VECTOR Systems----------
System installation date (if available)------
ALL information should be send to:
MSBCS::LIBKIND
/CSSE Low End Mid Range in BXB2 ; dtn 293-5022/
ADDITIONAL COMMENTS:
====================
Please send your response ASAP to support a proper FCO
implementation.
***************** DIGITAL INTERNAL USE ONLY **************
|
| 49.46 | Subj: location of 6500 info | COMICS::ROBB | | Mon Dec 17 1990 11:53 | 47 |
| Subj: Location of handouts
Hello All,
Following the two recent 6500 Seminars, I have now placed all
the material discussed at the seminars in the following
directory :-
COMICS::DISK$TECH:[MARIAH]
6000_UPGRADE_AND_INST_SUP.PS;1 ! VMS 6XXX Installation Documentation
955
6500_INST_GUIDE.PS;1
2000 ! VAX 6000-500 Hardware Inst Guide
6500_MAINT_ADV.LN03;1
591 ! 6500 Maintenance Advisory
6500_RELEASE_NOTES.PS;1
267 ! VMS Release notes for 6500
6500_SLIDES.PS;1 79 ! Slides for 6500 Presentation
DIAGS.DIR;1 13 ! Sub-directory for all 6500 related diags
EVUCA_NOTES.PS;1 103 ! Notes on how to run EVUCA
H7236A_INST.PS;1 1483 ! New BBU ( H7236A ) Installation Guide
INFO_SLIDES.PS;1 60 ! Slides from InfoServer Presentation
MS65A_INST_GUIDE.PS;1
418 ! MS65A Installation Guide
PLEN_ADVISORY.PS;2 336 ! Platform Enhancement Advisory
PLEN_SLIDES.PS;1 54 ! Platform Enhancement Slides
POWER_AND_PACKAGE_UPGRADE.PS;1
3595 ! Full Upgrade Installation Guide
RIGEL_VECTOR_ADVISORY.PS;1
1556 ! Rigel/Mariah Vector Advisory
ROM_UPGRADE.PS;1 296 ! ROM Upgrade proceedures for PLEN systems
All the 6500 related diagnostics are in a sub-directory i.e.
COMICS::DISK$TECH:[MARIAH.DIAGS]
I would like to know if there is a requirement to give anymore
of these seminars. If you feel there is a requirement please
contact me.
Please note I have been given my old extension number back,
7833 3659.
Regards
Brian
|
| 49.47 | ROM/EEPROM REV for 62/63/64/65xx | KERNEL::BLAND | toward 2000 ... | Tue Dec 18 1990 15:56 | 61 |
| Gentlemen,
Manufacturing in Galway and the Repair Centre in Nijmegan are
now shipping the latest revision console/diagnostic ROMs on
the 6200/6300/6400 CPU modules. i.e. T2011, T2011YA, and T2015.
The primary reason for these new console and diagnostic ROMs
are to support the MS65A memory. The new ROMs also incorporate
support for the following :-
o DEMNA, XMI to Ethernet adapter, T2020
o KDM70, XMI to SI adapter, T2022 & T2023
o DWMBB, "enhanced" XMI to VAXBI adapter, T2018
o CIXCD, XMI to CI adapter, T2080
The following chart summaries the compatibilty of these ROMs.
The new revision console are 5.0 for 6200, 6.0 for 6300 and
3.0 for 6400. The numbers under the older revision of consoles
are the EEPROM patch required to support a given device.
VAX 6200 VAX 6300 VAX 6400
___________ ___________ ___________________
---------------------------------------------------------------
ROM rev 3.1 5.0 4.1 6.0 1.0 2.0 3.0
---------------------------------------------------------------
CIXCD 3.8 yes 4.6 yes no 2.1 yes
DEMNA 3.7 yes 4.5 yes 1.02 yes yes
DWMBB no yes no yes no no yes
KDM70 3.6 yes 4.4 yes 1.02 yes yes
MS65A no yes no yes no no yes
InfoServer 3.8 yes 4.6 yes no yes yes
---------------------------------------------------------------
With the introduction of these new revisions of ROMs, the
ability to mix revision level is now available. BUT only with
the previous revision. i.e. revision 3.0 on the 6400 can only
be mixed with revision 2.0 ( T2015 rev J/L ) and not revision
1.0.( T2015 rev H ). The revision of the module will be changed
to reflect these latest ROMs. There will be an "A" in rev
level. Therefore a T2015 rev L will therefore be a T2015 rev
AL.
However, there will be appropreiate console error messages i.e.
ROM Revision Mismatch and EEPROM Revision Mismatch. The system
will however boot O.K. and all CPUs will join the active set.
It is strongly recommended that the UPDATE comand is no longer
used to update the EEPROM, and that the level 3 diagnostic
EVUCA is used when patches are applied. EVUCA is available in
COMICS::DISK$TECH:[MARIAH.DIAGS] along with all the other
latest stuff.
There is also two InfoServer manuals, the Installation and
Owners Guide and the System Users guide in
COMICS::DISK$TECH:[MARIAH].
Well that's all I can think of now.
Have a very MERRY Christmas and a Happy New Year.
Brian
|
| 49.48 | Subj: Diagnostic ERKAX failure on T2015 Rev J. or Rev. K | COMICS::ROBB | | Fri Dec 28 1990 10:44 | 95 |
| From: KERNEL::COMICS::LINDLEY "Brian Lindley, U.K. Support 833-4568 12-Jun-1990 1902" 12-JUN-1990 19:06:46.60
To: @6000
CC: LINDLEY
Subj: Diagnostic ERKAX failure on T2015 Rev J. or Rev. K
Gentlemen,
There is a problem when running ERKAX ( KA64A Manual Diagnostic )
on Revision K of the T2015.
The problem does not occur if a T2017 Vector module is attached to
the Rev K05 T2015. If the T2015 module is a rev H05 with V2.0 ROMs
(i.e a Rev J05 T2015) then the same problem causes test 10 to fail.
When executing ERKAX, test 20 will fail only if all the manual tests
(1-6) are run initially. The fix included below works only with
Diagnostic Supervisor ERSAA-12.6-733.
The diagnostic fails after Test 20 with the following error:
?? Software detected error in "DISPATCH", error #1, 1-JAN-1990 00:06:12.12
PC: 0002A698 PSL: 00000000
R0: 00005D54 R1: 00000000 R2: 22222222 R3: 00006C38
R4: 00001744 R5: 0000000D R6: 66666666 R7: 0000000E
R8: 88888888 R9: 99999999 R10: AAAAAAAA R11: BBBBBBBB
DSA$GL_Flags: 00003400(X) DS$GL_Flags: 00860086(X) Version: 12.6-733
0004D398:00000000 2FFC0000 00000518 0004D3E8 0002A698 22222222 00006C38 00001744
0004D3B8:0000000D 66666666 0000000E 88888888 99999999 AAAAAAAA BBBBBBBB 00000003
0004D3D8:00000001 00000000 00013E34 0003672F 0002B9A8 20000000 CCCCCCCC 00000000
0004D3F8:00020E48 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0004D418:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0004D438:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0004D458:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0004D478:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
******** End of Software detected error number 1 ********
The problem has been found to be a corrupt memory location following
a WARM RESTART. After a WARM RESTART is executed, a location in the
dispatch table used by the VAX Diagnostic Supervisor (VAX/DS) to
execute tests is corrupted. When the VAX/DS indexes into the
dispatch table to begin executing Test 21, the address containing
the test mask for Test 21 has been overwritten. The VAX/DS compares
this test mask with the current test it should be executing and
issues the above error because the two values are not equal.
Workaround:
----------
The above problem can be corrected with a simple DEPOSIT command
from the console. After executing Test 20 of ERKAX, the terminal
displays the following:
Test 20: ACV or TNV During Machine Check Halt Test
Do the following to continue from console mode:
D/I 4 0004DC00 <CR>
S 100 <CR> to continue or S 50 <CR> to abort
HALT expected with the following printout:
?10 ACV/TNV occurred during machine check processing.
PC = 00005F45
?10 ACV/TNV occurred during machine check processing.
PC = 00005F45
PSL = 041F9000
ISP = 00006E24
>>>
Instead of typing:
>>>D/I 4 0004DC00 <CR>
>>>S 100 <CR>
The operator should type:
>>>D/I 4 0004DC00 <CR>
>>>D/P/L 518 6010 <CR> <--- Note new DEPOSIT command
>>>S 100
A DEPOSIT of 6010 to location 518 will restore the address in the
dispatch table which was overwritten. The diagnostic will then
proceed normally.
The long term solution will be a fix in the Console ROM.
Regards
Brian
|
| 49.49 | Subj: Rigel Vector Release Notes | COMICS::ROBB | | Fri Dec 28 1990 10:45 | 93 |
| From: KERNEL::COMICS::LINDLEY "Brian Lindley, U.K. Support 833-4568 12-Jun-1990 1930" 12-JUN-1990 20:10:04.89
To: @6000
CC: LINDLEY
Subj: Rigel Vector Release Notes
Gentlemen
The following is the release notes for the Rigel Vector ( T2017 ).
This is for imformation only as we have not sold any Vector options
in the U.K. as yet. Please be aware of the last paragraph
"Additional Comments".
Regards
Brian
***********************************************************************
There are several issues related to the introduction of VAX 6000 4XX
VECTORS of which Customer Service Personnel need to be made aware.
Limited shipments commence May 11.
1. VAX 6000 - 4XX VECTORs (T2017) require a REV K Scalar (T2015)
to be attatched to the VECTOR.
2. In sytems that have VECTORS all Scalar modules must be at REV K
or REV J.
3. Only a Memory module can be placed to the left of a VECTOR module
in the XMI backplane, otherwise damage can occur.
4. VECTOR modules can be shipped only in the ESD Box, 99-08536-02,
otherwise damage can occur. This is a REV change from the original
XMI ESD box. The part number will be on a label on the top of
the box. No other identifier is supplied.
5. For each VECTOR, a system should have 64 megabytes of memory to
have reasonable performance.
6. Dual Scalar Vector pairs will not be supported until Q2 of FY 91.
Testing has reveeled that this configuration is not working
properly.
7. Diagnostics: Prerelease kits may be ordered from the SSB
VAX6400 VECTOR Cmplt Diag Set (TK50) AQ-PBPRA-DE
VAX6400 VECTOR Cmplt Diag Set (Mag tape) BB-PBPSA-DE
or
Copied from VOLKS::RIGEL$DIAG_VECTORS:
8. Documentation: At FRS most Customer Service manuals will be
preliminary. Listed below are manuals most pertinent to VECTORS.
VAX 6000 Series Upgrade Manual (VCT Install) EK-600EB-UP-002
VAX 6000 VECTOR Processor Owner's Manual EK-60VAA-OM-001
VAX 6000-400 System Technical User's Guide EK-640EA-TM-002
VAX 6000-400 Option & Manintenance Manual EK-640EB-MG-002
VAX 6000-400 VECTOR Proc. Programer's Guide EK-64VEA-OM-001
VECTOR Processing Concepts Student Workbook EY-9876E-SG-001
VAX VECTOR Processing Handbook EC-H0419-46/89
RESOLUTION/WORKAROUND:
1. REV K of the Scalar module (T2015) is the minimum Rev that can be
attached to a VECTOR (T2017) module.
2. The current Rev of the Scalar module is Rev. H. It is
incompatible with Rev. K. Customer Service personnel can build a
Rev. J which is compatible by replacing the console and diagnostic
ROMs on Rev. H modules. ROMs and instructions are in the initial
released kit of the VECTOR option.
3. Place no other modules but memories next to the VECTOR.
4. Use only the 99-08536-02 ESD box with a VECTOR Module.
5. Inform the customer and Digital sales personnel of the correct
size of memory.
6. Dual Scalar Vector pairs do not work properly and are not
supported. Customers should NOT cofigure their systems with Dual
Scalar Vector pairs!
ADDITIONAL COMMENTS:
The VECTOR Module, the T2017, will require an FCO to fix known
hardware problems that in the current version are worked around
either in hardware and software or in product restrictions. To
become familiar with these restrictions read the VAX 6000 Series
Vector Option Release Notes.
|
| 49.50 | Subj: Latest console information for 6000s. | COMICS::ROBB | | Fri Dec 28 1990 10:46 | 65 |
| From: KERNEL::COMICS::LINDLEY "Brian Lindley, U.K. Support 833-3659 18-Dec-1990 1509" 18-DEC-1990 15:12:28.91
To: @6000
CC: LINDLEY
Subj: Latest console information for 6000s.
Gentlemen,
Manufacturing in Galway and the Repair Centre in Nijmegan are
now shipping the latest revision console/diagnostic ROMs on
the 6200/6300/6400 CPU modules. i.e. T2011, T2011YA, and T2015.
The primary reason for these new console and diagnostic ROMs
are to support the MS65A memory. The new ROMs also incorporate
support for the following :-
o DEMNA, XMI to Ethernet adapter, T2020
o KDM70, XMI to SI adapter, T2022 & T2023
o DWMBB, "enhanced" XMI to VAXBI adapter, T2018
o CIXCD, XMI to CI adapter, T2080
The following chart summaries the compatibilty of these ROMs.
The new revision console are 5.0 for 6200, 6.0 for 6300 and
3.0 for 6400. The numbers under the older revision of consoles
are the EEPROM patch required to support a given device.
VAX 6200 VAX 6300 VAX 6400
___________ ___________ ___________________
---------------------------------------------------------------
ROM rev 3.1 5.0 4.1 6.0 1.0 2.0 3.0
---------------------------------------------------------------
CIXCD 3.8 yes 4.6 yes no 2.1 yes
DEMNA 3.7 yes 4.5 yes 1.02 yes yes
DWMBB no yes no yes no no yes
KDM70 3.6 yes 4.4 yes 1.02 yes yes
MS65A no yes no yes no no yes
InfoServer 3.8 yes 4.6 yes no yes yes
---------------------------------------------------------------
With the introduction of these new revisions of ROMs, the
ability to mix revision level is now available. BUT only with
the previous revision. i.e. revision 3.0 on the 6400 can only
be mixed with revision 2.0 ( T2015 rev J/L ) and not revision
1.0.( T2015 rev H ). The revision of the module will be changed
to reflect these latest ROMs. There will be an "A" in rev
level. Therefore a T2015 rev L will therefore be a T2015 rev
AL.
However, there will be appropreiate console error messages i.e.
ROM Revision Mismatch and EEPROM Revision Mismatch. The system
will however boot O.K. and all CPUs will join the active set.
It is strongly recommended that the UPDATE comand is no longer
used to update the EEPROM, and that the level 3 diagnostic
EVUCA is used when patches are applied. EVUCA is available in
COMICS::DISK$TECH:[MARIAH.DIAGS] along with all the other
latest stuff.
There is also two InfoServer manuals, the Installation and
Owners Guide and the System Users guide in
COMICS::DISK$TECH:[MARIAH].
Well that's all I can think of now.
Have a very MERRY Christmas and a Happy New Year.
Brian
|
| 49.51 | Subj: Logistics don't stock latest ROMs ! | COMICS::ROBB | | Fri Dec 28 1990 10:47 | 14 |
| From: KERNEL::COMICS::LINDLEY "Brian Lindley, U.K. Support 833-3659 18-Dec-1990 1635" 18-DEC-1990 16:38:03.04
To: @6000
CC: LINDLEY
Subj: Logistics don't stock latest ROMs !
Allo Allo,
Sorry, I forgot to mention in the last mail message that these
latest console/diagnostic ROMS CANNOT be ordered though
logistics. There are no plans to do so. The reason is that
these ROMs should be sold by sales as part of the MS65A
upgrade, and not "given" away by Customer Services !
Brian
|
| 49.52 | Subj: GRAM: VMS V5.4-1 Will Cause VAX 6000-400 to Crash When Booting (blitz) | COMICS::ROBB | | Fri Dec 28 1990 10:48 | 396 |
| From: KERNEL::BEEZER::TIMA_MGR 27-DEC-1990 10:47:00.45
To: KERNEL::ROBB
CC:
Subj: GRAM: VMS V5.4-1 Will Cause VAX 6000-400 to Crash When Booting (blitz)
Author : RODNEY BOYLE
User type : USER
Location : CSSE
Vaxmail address : CSSE::BOYLE
+---------------------------+TM
| | | | | | | |
| d | i | g | i | t | a | l | TIME DEPENDENT CASE
| | | | | | | |
+---------------------------+
Title/Problem Summary: VMS Version 5.4-1 will cause VAX 6000-400 Series
computers to crash when booting.
DATE: December 20, 1990
AUTHOR: Paul Lacombe TD #: 000527
DTN: 381-1697
ENET: VMSSPT::Lacombe CROSS REFERENCE #'s:
DEPARTMENT: CSSE/VMS Support Group (SPR's, CLD's, TD's)
INTENDED AUDIENCE: U.S./EUROPE/GIA PRIORITY LEVEL: 1
(1 = Time Critical,
2 = NON-Time Critical)
See attachment below
for additional info.
---------------------------------------------------------------------
*** DIGITAL INTERNAL USE ONLY ***
Author Identification:
----------------------
Name : Jason Gallant
DTN : 381-2358
Mail Stop : ZKO1-1/F22
E-net: CSSE32::GALLANT
Department : CSSE/VMS
Article Identification:
-----------------------
Title/Problem Summary: VMS Version 5.4-1 will cause VAX 6000-400
Series computers to crash when booting.
Do not install VMS Version 5.4-1 on these
systems. Install VMS Version 5.4-1A kit on
VAX 6000-400 Series computers.
Operating System/Layered Product: VMS
Component/Utility: VMS Version 5.4-1
Version Information: VMS Version 5.4-1
Is the problem reproducible at will?: Yes
DETAILED Problem Information:
-----------------------------
Problem Description/Symptoms :
After applying VMS Version 5.4-1, the system will not boot on VAX 6000-400
series systems. The BUGCHECK type is "INVEXCEPTN, Exception while above
ASTDEL or on interrupt stack."
Hardware configuration specifics :
VAX 6000-400 series systems.
Potential Impact on System Operation :
The system will not boot. The BUGCHECK type is "INVEXCEPTN, Exception
while above ASTDEL or on interrupt stack."
Frequency of Occurrence : All the time.
DETAILED Resolution Information:
--------------------------------
Problem Resolution/Work-around Description :
A new kit, VMS Version 5.4-1A, is a replacement kit for VMS Version
5.4-1 for VAX 6000-400 systems.
U.S. Customers who are owners of VAX 6000-400 Series systems can obtain
VMS Version 5.4-1A by calling 1-800-448-6387. Customers should request
part number QA-001AA-T55.41 to obtain VMS Version 5.4-1A on TK50 media
or part number QA-001AA-TM5.41 to obtain VMS Version 5.4-1A on
magnetic tape. This information is explained in the Cover Letter
for Owners of VAX 6000-400 Series Systems which is included in
the VMS Version 5.4-1 kit.
Europe and GIA have local plans.
New VAX 6000-400 customers will receive the VMS Version 5.4-1A kit
with the VAX 6000-400 Hardware Information Kit.
Digital internal users can copy the VMS Version 5.4-1A kit
over the network from the normal VMS distribution points. CSSE/VMS
recommends this approach for Digital internal users since the exception
order process is very expensive for the corporation. The network
distribution points are listed at the end of this memo.
When is the final fix expected (Version/Timeframe)? :
VMS Version 5.4-1 kit began shipping from the SSB December 14, 1990.
VMS Version 5.4-1A is currently available for customers by calling
the 800 number listed above.
VMS Version 5.4-1A will be shipping with the VAX 6000-400 Hardware
Information Kit as of December 27, 1990 for new customers.
VMS Version 5.4-1A is available on the network for Digital internal
users.
Can the fix be engineered/applied to any previous
versions? If so - when? : No.
Installation Instructions :
To install and run VMS Version 5.4-1A on all VAX 6000-400 systems,
follow the update procedure provided with the VMS Version 5.4-1 cover
letter. Replace the installation command line in the Version 5.4-1
update procedure with the following command line:
$@SYS$UPDATE:VMSINSTAL VMSU1A054 ddcu: OPTIONS N
Additional Comments :
If your VAX 6000-400 system is VAXcluster member,you can run VMS
Version 5.4-1A on all nodes, or run in a mixed-version cluster
with VMS Version 5.4 or VMS Version 5.4-1.
The following files comprise the V5.4-1A kit.
Directory BULOVA::SYS$KITS:[VMS0541]
VMSU1A054.A;2 216 17-DEC-1990 12:20:51.00 (RWED,RWED,RE,RE)
VMSU1A054.B;1 17946 17-DEC-1990 12:21:22.00 (RWED,RWED,RE,RE)
VMSU1A054.COVER_LETTERS;1
4 18-DEC-1990 18:51:25.00 (RWED,RWED,RWED,RE)
Total of 3 files, 18166 blocks.
The .A saveset contains a new kitinstal to allow for V5.4-1A's
installation.
The .B saveset contains a new SYSLOA to address the above problem, and
the V5.4-1A system version patch.
Distribution sites have just been very recently notified of the
V5.4-1A kit. Please allow them sufficient time to obtain it.
Below is a description of the VMS Version 5.4-1A Network kit
and where it is located:
!
!++ NOTE:
! These kits are for INTERNAL USE ONLY!
!
!
!DECnet Areas with Distribution Sites:
! 1,2,3,4,7,8,10,15,16,17,18,19,21,25,27,28,29,30,31
! 32,33,34,36,37,38,41,42,43,45,47,48,49,50,51,55,56,58,59
!
!New England
!-----------
!
!Directory: SQM::SYS$KITS:<VMS0541>
!Location: ZKO - Nashua, NH (Area 2)
!Contact: David SQM::WARRINER
!
!Directory: PAGODA::KITS:<VMS0541>
!Location: ZKO2 - Nashua, NH (Area 2)
!Contact: Paul PSW::WINALSKI
!
!Directory: ATSE::SYS$KITS:<VMS0541>
!Location: MKO1 - Merrimack, NH (Area 3)
!Contact: Kevin ATSE::COTE
!DFS access point: mko.s.atse.kits
!
!Directory: FDCV14::SYS$KITS:<VMS0541>
!Location: DDD - Nashua, NH (Area 3)
!Contacts: Glenn FDCV14::DOTEN
!DFS access point: .Sale_SERV.US.USIS.TIS.VMS$Kits
!
!Directory: LIOTH""::SYS$KITS:<VMS0541>
!Location: LKG - Littleton, MA (Area 4)
!Contact: Kevin SMAUG::MURPHY
!
!Directory: MIVC::KITS_DISK:[VMS.VMS054]
! [VMS.VMS0541]
!Location: LKG - Littleton/King St. (Area 4)
!Contact: Dave Klinkhamer DELNI::KLINK
!DFS access point: LKG.S.TANTS.KITS_DISK
!
!Directory: THEVUP::SYS$KITS:<VMS0541>
!Location: MRO1 - Marlboro, MA (Area 7)
!Contact: Marc HPSRAD::DUFRESNE
!
!Directory: CABOOS::SYS$KITS:<VMSU1054>
!Location: APO1 - Andover, Ma (Area 15)
!Contact: Steve CABOOS::WRIDE
!DFS access point: .Mfg.SCO.APO_CR.VMSKits
!
!Directory: MILK""::SYS$KITS:<VMS0541>
!Location: BTO - Burlington, VT (Area 17)
!Contact: Bill TALK::W_PIPER
!
!Directory: MPGS::VMS$KITS:<VMS0541>
!Location: SHR - Shrewsbury, Mass (Area 18 and 27)
!Contact: John (Harley) Privitera MPGS::HARLEY
!DFS access point: .Eng.Stor_Sys.SHRISG.MPGS_VMS$kits
!Directory: VMSKIT::SYS$KITS:<VMS0541>
!Location: ZK03 - Nashua, NH (Area 19)
!Contact: Jody STAR::LITTLE
!Contact: Tiph STAR::WORLEY
!
!Directory: MUDDIN::VMS$KITS:<VMS054-1>
!Location: MRO4 - Marlboro, MA (Area 21)
!Contact: Robin MUDDIN::MUNROE
!
!Directory MVBLAB::SYS$KITS:<VMS0541>
!Location MLO - MAYNARD, MA (AREA 25)
!CONTACT: Jon DIODE::CROWELL
!Note: Area 5 is on the same ethernet
!
!Directory: SHORE::SYS$KITS:[VMS0541]
!Location: MLO - Maynard, MA (Area 25)
!Contact: Paul WRKSYS::Fazio
!
!Directory: IAMA::VMS$KITS:<VMS0541>
!Location: BXB - Boxboro, MA (Area 29)
!Contact: Kevin Meany IAMA::MEANY
!
!Directory: BM1GSG::
!Location: MK02, Merrimack, NH (Area 31)
!Contact: Ira BM1GSG::GROLLMAN
!Available by mail back. To use, send mail to: BM1GSG::vms0541
!Subj:doesn't matter
!first line of message to contain destination as node::device:[directory]
!which must have world write access to allow BM1GSG::kitname proxy access.
!To obtain kit directory, send mail to BM1GSG::DISTRIBUTE
!
!Directory: MILKWY::SYS$KITS:<VMS0541>
!Location: LMO2 - Marlboro, MA (Area 37)
!Contact: Jerry MILKWY::PARISH
!
!Directory: MIDEVL::KIT$DISK:<VMS0541>
!Location: DLB5 - Marlboro, MA (Area 37)
!Contacts: Mark AISG::OTOOLE or Peter DSCVRY::PBRIGGS
!
!Directory: PIPLIN::SYS$KITS:<VMS0541>
!Location: PDM1 - Marlboro, MA (Area 38)
!Contact: Jim CONCRT::KEHOE
!DFS access point: .PDM.S.DFS_PIPLIN.KITS_1
!
!Directory: REFINE::TASTE$KITS:<VMS0541>
!Location: DSG1 - Westford, MA (Area 55)
!Contact: REFINE::KIT_MANAGER
!DFS: .DSG.S.TASTE.DFS.TASTE$KITS
!
!Directory: STOW::SYS$KITS:<VMS0541>
!Location: OGO - Stow, MA (Area 56)
!Contact: Rick OGOMTS::LAFLAMME
!NOTE: access limited to proxy accounts
!United States:
!--------------
!Directory: RESOLV::SYS$KITS:
!Location: CXO - COLORADO SPRINGS (Area 8 and 28)
!Contact: Bob BSS::Mulligan
!send mail to NOETIC::MULLIGAN
!DFS access point: .cxo.csc.isg.kit
!
!Directory: TPWEST::SYS$KITS:
!Location: UCS - Mtn View, CA (Area 10)
!Contact: Al NDEVOR::SERA or TPWEST::SYSTEM
!
!Directory: DLOACT""::SYS$KITS:<VMS0541>
!Location: SCA - Dallas, TX (Area 16)
!Contact: John DLOACT::HILDEBRAND
!DFS access point: .SCA.S.ACT.kits
!
!Directory: PYRO::SYS$KITS:[VMS0541]
!Location: UCF - Cupertino, CA (Area 30)
!Contact: Ron van Zuylen - WLDWST::RVANZUYLEN
!DFS Access: .ucf.s.dfs.vms_kits
!
!Directory: SICVAX::SYS$KITS:
!Location: NYO - New York, NY (Area 32)
!Contact: Patrick SICVAX::SWEENEY
!
!Directory: FINALY::SYS$KITS:[VMS0541]
!Location: CEO, Charlotte, NC (Area 33)
!Contact: Chip Council FINALY::SYSTEM
!
!Directory: SHAM00::SYS$KITS:[VMS0541]
!Location: RDC - Schaumburg, IL (Area 34)
!Contact: Ed SHAMOO::HERRICK
!
!Directory: UFP::SYS$KITS:<VMS0541>
!Location: DCO - Washington, DC (Area 36)
!Contact: Rick UFP::MURPHY
!DFS access point: .dco.s.eis.dfs.ufp_kits
!
!Directory: SCAACT""::SYS$KITS:<VMS0541>
!Location: Worldwide ACTnet, SCA - DALLAS, TX (Area 45)
!Contact: John SCAACT::HILDEBRAND
!DFS access point: .SCA.S.ACTNET.kits
!
!International:
!--------------
!
!Directory: WARNUT::SYS$KITS:[000000]
!Location: OLO Warrington, UK (Area 41)
!Contact: Laurence WARNUT::FOSSEY or WOTVAX::FOSSEY
! & Simon Dodsley WOTVAX::DODSLEYS
!
!Directory: MARVIN::SYS$KITS:<VMS0541>
!Location: REO2 - Reading UK (Areas 1,42)
!Contact: Margaret MARVIN::MORRISON
!Contact: Trevor MARVIN::WARWICK
!DFS access point: .Eng.NaC.WACE.MARVIN_DFS.disk$kits
!Directory: IRNBRU::SYS$KITS:<VMSxxx>
!Location: AYO - Ayr, Scotland (Area 43)
!Contact: IRNBRU::EDDIE McInally
!
!Directory: FRKITS::SYS$KITS:
!Location: EVO - Evry, France (Area 47)
!Contact: Pierre Peine FRKITS::DISTRIB
!
!Directory GVPROD""::SYS$KITS:<VMS0541>
!Location: Geneva - Switzerland (Area 48)
!Contact: Michel SHIRE::MSTEINER
!
!Directory: DCC::SYS$KITS:[vms.v54-1]
!Location: RTO - Munich, W. Germany (Area 49)
!Contact: Dennis DCC::HAGARTY
!DFS access point: .rto.act.kits
!
!Directory: KIPPIS"VMSKITS"::SYS$KITS:<VMS0541>
!Location: FNO - Helsinki, Finland (Area 50)
!Contact: Pekka KIPPIS::PEURA
!
!Directory: VISA::SYS$KITS:<VMS0541>
!Location: VBE - Valbonne, France (Area 51)
!Contact: Dave VISA::MONAHAN
!
!Directory: SQMJPN::VMS$KITS:[VMSU1054]
!Location: JRD - Yokohama, Japan (Area 58)
!Contact: Takehumi SQMJPN::KAKIMOTO
!DFS access point: .JRD.S.DFS.SQM_VMS$KITS
!
!Directory: GIDDAY::SYS$KITS:<VMS.*>
!Location: STL 3/3 - Sydney, Australia (Area 59)
!Contact: JOHN GIDDAY::BRODRIBB
!DFS access point: .STL.S.DFS.Kits
!
!
*** DIGITAL INTERNAL USE ONLY ***
---------------------------------------------------------------------
|
| 49.53 | MARIAH UPGRADE POTENTIAL PROBLEM | KERNEL::BLAND | toward 2000 ... | Wed Jan 09 1991 00:08 | 83 |
| Author : RODNEY BOYLE
User type : USER
Location : CSSE
Vaxmail address : CSSE::BOYLE
+---------------------------+TM
| | | | | | | |
| d | i | g | i | t | a | l | TIME DEPENDENT CASE
| | | | | | | |
+---------------------------+
TITLE: H7214 Power Supply
DATE: January 7,1991
AUTHOR: Jerry Wernicki TD #: 000542
DTN: 293-5667
ENET: MSBCS::WERNICKI CROSS REFERENCE #'s:
DEPARTMENT: CSSE Mid Range (PRISM/TIME/CLD#'s)
INTENDED AUDIENCE:(U.S./EUROPE/GIA) PRIORITY LEVEL: 1
(U.S./EUROPE/GIA) (1=TIME CRITICAL,
2=NON-TIME CRITICAL)
=====================================================================
PROBLEM:
When performing a full power and package upgrade from an existing
VAX 6000-XXX system to a VAX 6000-5XX or when installing an add-on
VAXBI Backplane in the H9657 cabinet, there is a potential to short
out the power supply.
The reason for the short is that both 10/32 x 7/16 and 10/32 x 5/16
screws are used in the cabinet. There is a potential that the
engineer could use the wrong size screw to attach the bus bars to
the H7214.
If the 10/32 x 7/16 screws are used to attach the bus bars to the
regulator the screw will touch a coil inside the regulator and short
the output of the H7214 to ground.
IT IS IMPERATIVE THAT THE 10/32 x 5/16 SCREWS BE USED ON THE POWER
CABLE CONNECTIONS.
RESOLUTION/WORKAROUND:
The following has or will be done to help avoid this situation:
1. All documentation (XMI Conversion Manual and the BI
Installation Manual) have CAUTION advisories embedded
in the text for reminders.
2. We are looking into having inserts placed into all
H7214 parts that warn of the possibility.
or
Placing an insert highlighting this possibility in
the Full Power and Package Upgrade and BI addons when
they are shipped from the factory.
3. A techtip has been generated regarding the problem.
ADDITIONAL COMMENTS:
In most circumstances when the 10/32 x 7/16 screws are used instead of
the 10/32 x 5/16 the regulator crowbars and there is no damage to the
regulator. Once the proper screws are used the regulator will function.
However, on occasion, sufficient force used on the 10/32 x 7/16 screws
will cause the screw to damage the internal coil and damage the
windings. It will be necessary to replace the regulator should the
this happen.
***************** DIGITAL INTERNAL USE ONLY **************
|
| 49.54 | 64XMX FCO IMPLEMENTATION/CRITICAL INFORMATION | KERNEL::BLAND | toward 2000 ... | Tue Jan 29 1991 13:54 | 86 |
| Author : RODNEY BOYLE
User type : USER
Location : CSSE
Vaxmail address : CSSE::BOYLE
+---------------------------+TM
| | | | | | | |
| d | i | g | i | t | a | l | TIME DEPENDENT CASE
| | | | | | | |
+---------------------------+
TITLE: 64XMX FCO IMPLEMENTATION/CRITICAL INFORMATION
AUTHOR: Rose Murphy DATE: 25 JAN 91
DTN: 247-2547 TD# : 000568
ENET: VOLKS::MURPHY CROSS REFERENCE #'s:
DEPARTMENT: CSSE VAX SYSTEM SUPPORT (PRISM/TIME/CLD#'s)
INTENDED AUDIENCE: PRIORITY LEVEL: 1
(U.S./EUROPE/GIA) (1=TIME CRITICAL,
2=NON-TIME CRITICAL)
=====================================================================
PROBLEM: There seems to be much confusion on the strategy of
implementing the 64XMX-O002 fco. This is due to the fact
that the implementation plans which were distributed are
outdated and we have had a delay in obtaining fco material.
Listed below is the most current strategy for implementing
the fco for both the T2015 and T2017 modules:
1 - T2015 SPARES UPGRADE ONLY - began late Nov, 1990.
Kits SHOULD NOT BE USED TO UPGRADE SYSTEMS AT THIS TIME.
The spares portion will end Jan 31, 1991.
2 - DUAL VECTOR CUSTOMERS - has begun (Jan, 1991).
This is being managed by CSSE/PMO. Branches supporting
these customers are being contacted directly by CSSE.
If you are not contacted and you are supporting an
installed DUAL VECTOR system, contact the writer to
arrange acquiring a kit. Material is short and is only
for DUAL VECTOR customers.
3 - SYSTEMS with T2015 only - start February 4, 1991.
4 - SERVER SYSTEMS which contain the T2015-YA should also
be upgraded. This info was inadvertently omitted when
previous plans and Blitz notices were published.
Kits should be available week 4 Feb, 1991.
4 - VECTOR SPARES (T2017) - to start March timeframe.
5 - SYSTEMS with both T2015 and T2017 - late March/early April.
Implementation of the FCO should occur in the above order ONLY.
YOU WILL BE OFFICIALLY NOTIFIED WHEN TO ORDER by your FCO
coordinator. The above is only to notify you that the
dates in previous Blitz notices or previous implementation
plans have changed.
The above implementation strategy is based on material
availability and customer need. Please implement according
to plan.
RESOLUTION/WORKAROUND: Follow above implementation
ADDITIONAL COMMENTS: There has been much concern over disposition of
the additional T2015 modules as a result of the Vector upgrade process.
Any old T2015 modules which were removed from a customer's system when
the Vector upgrade was installed can be returned through the normal
Logistics process since the module is on the R&R and is coded "A".
This means the branch will not be required to order another module.
The branch will receive credit for the returned module less the repair
cost. Since the branches have acquired the modules at "no cost" the
small repair cost should not be a problem.
*** DIGITAL INTERNAL USE ONLY ***
|
| 49.55 | ERSAA Problems with VAXPAX 42 | KERNEL::BLAND | toward 2000 ... | Tue Feb 05 1991 09:47 | 97 |
| From: BEEZER::TIMA_MGR 5-FEB-1991 02:25:20.63
To: KERNEL::BLAND
CC:
Subj: GRAM: VAX Diagnostics Supervisor ELSAA.EXE & ERSAA.EXE (blitz)
Author : RODNEY BOYLE
User type : USER
Location : CSSE
Vaxmail address : CSSE::BOYLE
+---------------------------+TM
| | | | | | | |
| d | i | g | i | t | a | l | TIME DEPENDENT CASE
| | | | | | | |
+---------------------------+
TITLE: VAX DIAGNOSTIC SUPERVISOR ELSAA.EXE and ERSAA.EXE
DATE: 04-JAN-1991
AUTHOR: JIM VERMETTE TD #: 000579
DTN: 247-2555
ENET: VOLKS::VERMETTE CROSS REFERENCE #'s:
DEPARTMENT: CSSE SYSTEM SUPPORT (PRISM/TIME/CLD#'s)
INTENDED AUDIENCE: U.S./EUROPE/GIA PRIORITY LEVEL: 1
(U.S./EUROPE/GIA) (1=TIME CRITICAL,
2=NON-TIME CRITICAL)
=====================================================================
PROBLEM:
- VAX Diagnostic Supervisor (ELSAA) version 14.1, release 42
Systems affected: 58xx, VAX 62xx, 63xx
- VAX Diagnostic Supervisor (ERSAA) version 14.1, release 42
Systems affected: VAX 64xx
- Level 3 XMI Adapter Diagnostic Failures
A problem has been discovered with the VDS within the channel services
routine which causes general purpose registers to be corrupted or stack
imbalance. Only level 3 diagnostic programs which test XMI adapters are
affected. It does not affect BI adapter diagnostics. The affected
programs use the $DS_CHANNEL service functions, CHC$_STATUS or CHC$_ENINT.
The symptom has been seen while testing the CIXCD with program EVGAA - CI
Functional Test Part I, in test 1, as follows:
?? Access control violation Fault through SCB vector: 20(X)
Virtual Address: 00000005(X)
Fault type: 00000000(X)
PC at error: 00004D16(X)
PSL at error: 00000000(X) ; CUR=KERNEL,PRV=KERNEL,IPL=00
User return PC: 00004D16(X)
The problem may cause other XMI I/O Adapter diagnostics to show different
symptoms.
RESOLUTION/WORKAROUND:
A workaround for this problem includes utilizing the VDS EXAMINE/DEPOSIT
commands to change the following locations:
The permanent modification will be incorporated within the next release of
the VDS.
For ELSAA,
DS> EXAMINE/BYTE 2714C ; Should be 40
DS> DEPOSIT/BYTE 2714C 20
DS> EXAMINE/BYTE 27889 ; Should be D0
DS> DEPOSIT/BYTE 27889 05
For ERSAA,
DS> EXAMINE/BYTE 2730C ; Should be 40
DS> DEPOSIT/BYTE 2730C 20
DS> EXAMINE/BYTE 27A49 ; Should be D0
DS> DEPOSIT/BYTE 27A49 05
ADDITIONAL COMMENTS: N/A
*** DIGITAL INTERNAL USE ONLY ***
|
| 49.56 | Correction to FCO DOC in reply .54 | KERNEL::BLAND | toward 2000 ... | Thu Feb 14 1991 09:51 | 412 |
| From: VOLKS::BONNIE "I'D RATHER BE SAILING...BONNIE GAYTON, DTN 247-2550" 12-FEB-1991 08:05:30.60
To: VERMETTE
CC:
Subj: CORRECTED COPY OF THE 64XMX-O002 FA DOC
______________________________________________________________________________
| DIGITAL FCO CATEGORY PAGE 1 |
| [O] OF 7 |
|______________________________________________________________________________|
| FIELD CHANGE ORDER NUMBER: 64XMX-O002 |
|______________________________________________________________________________|
| APPLICABILITY: This FCO should be installed in all 64XMX systems and spares. |
| It incorporates ECOs T2015-TW007, T2015-TW008, T2015-TW010, T2017-LTN04. |
| |
|______________________________________________________________________________|
| PROBLEM & SYMPTOM: See Page 2. |
| |
| |
|______________________________________________________________________________|
| SOLUTION: Replace all T2015 modules below Revision "L", all T2015-YA modules |
| below Revision "D" and all T2017 modules below Revision "J". |
|______________________________________________________________________________|
| QUICK CHECK: T2015--component at location E29 is p/n 21-25087-09 for Rev "L";|
| T2015-YA--component at location E29 is p/n 21-25087-09 for Rev "D" and for |
| T2017 PAL at location E6 is 23-210K4-00 for Rev "J". |
|______________________________________________________________________________|
| PRE/COREQUISITE FCO: N/A | MTTI HRS |
| | 1 Hr. |
|___________________________________________________________________|__________|
| TOOL/TEST EQUIPMENT: Field Service Tool Kit. |
|______________________________________________________________________________|
| FCO PARTS INFORMATION |
|______________________________________________________________________________|
| FCO KIT NO. | DESCRIPTION OF CONTENTS | EQ KIT VARIATION |
|______________|____________________________________________| APPLICABILITY |
|EQ-01591-XX | See Page 2 for Contents of EQ Kits. | |
|FA-04921-01 | FCO Document | YES |
| | | |
|______________|____________________________________________|__________________|
| FCO CHARGING INFORMATION |
|______________________________________________________________________________|
| WARRANTY/CONTRACT || NONWARRANTY/NONCONTRACT |
|___________________________||_________________________________________________|
| ON-SITE | OFF-SITE || ON-SITE | OFF-SITE | MATERIAL ONLY |
|_____________|_____________||_____________|_____________|_____________________|
|TRAVEL/| EQ | | EQ ||TRAVEL/| EQ | | EQ |ORDER-ADMIN,HANDLING |
|INSTALL| KIT |INSTALL| KIT ||INSTALL| KIT |INSTALL| KIT |PKG,SHIPPING & EQ KIT|
|_______|_____|_______|_____||_______|_____|_______|_____|_____________________|
| DEC | DEC | DEC | DEC || CUS | CUS | CUS | CUS | CUS |
|_______|_____|_______|_____||_______|_____|_______|_____|_____________________|
| APPROVALS |
|______________________________________________________________________________|
| CSSE | FSHQ LOGISTICS | FS PRODUCT SAFETY |
| Jim Vermette | Len Pellerin | Robert Brister |
|___________________|____________________________|_____________________________|
| CSSE MANAGER |This document is published | FCO RELEASE DATE |
| Ric Grogan |on multiple media including | 4 February 1991 |
|___________________|hardcopy, Customer Services |_____________________________|
| MICROMEDIA |Microfiche Libraries, | FCO REVISION |
| Diane MacDonald |Customer Services CD-ROM and| A |
|___________________|MDS Microfiche Libraries. |-----------------------------|
| POPULATION | | PARTS AVAILABILITY |
| 5,500 | | 4 February, 1991 |
|___________________|____________________________|_____________________________|
_ _ _ _ _ _ _ | FCO 64XMX-O002
| | | | | | | | |
|d|i|g|i|t|a|l| | PAGE 2 OF 7
|_|_|_|_|_|_|_| |
|
_______________________________|_________________________________________
Problem/Symptoms: (Continued from Page 1)
This FCO solves the following problems with the T2015 module:
1. MOVC5 and CMPC5 Instructions with length values of zero may change
an internal temporary register causing the next instruction to fail.
2. V1.0/V2.0 Console/Diag ROMs do not support Vector/dual Vector
options respectively.
3. The PC may be misaligned by plus or minus 4 bytes during
multi-processing operations.
4. The VC chip can, in certain instances, resend an instruction to an
attached Vector Processor that has already been executed.
5. Dendritic growth on LDCCs can cause intermittent system interrupts.
This FCO solves the following problems with the T2017 module:
1. Load/Store chips could hang while executing a STORE class
instruction due to INVALIDATE traffic in dual Vector configurations.
2. Excessive undershoot and ringing on duplicate tag address may
cause reliability and timing problems.
3. Vectl chip fix - a combination of instructions if used together
break the architectural spec.
4. Dual Vector configurations may hang and abort processes under
a particular Vector Parallel Decomposed application.
5. Dual Vector configurations under heavy system loads may align
internal data movement events such that data integrity could
be compromised.
FCO Parts Information (Continued from Page 1)
| FCO KIT NO. | DESCRIPTION OF CONTENTS
|______________|____________________________________________
| EQ-01591-01 | T2015 CPU Timeshare Module
| FA-04921-01 | FCO Document
| EQ-01591-02 | T2017 Vector Module
| FA-04921-01 | FCO Document
| EQ-01591-05 | T2015-YA CPU Server Module
| FA-04921-01 | FCO Document
_ _ _ _ _ _ _ | FCO 64XMX-O002
| | | | | | | | |
|d|i|g|i|t|a|l| | PAGE 3 OF 7
|_|_|_|_|_|_|_| |
|
_______________________________|_________________________________________
FIELD INSTALLATION AND TEST PROCEDURE FOR 64XMX-O002
====================================================
1. Shut down the operating system using the approved methods,
such as @SYS$SYSTEM:SHUTDOWN for VMS. If using SHUTDOWN,
answer all prompts accordingly.
Here is a sample of a shutdown session:
$ @sys$system:shutdown
SHUTDOWN -- Perform an Orderly System Shutdown on node XXX
How many minutes until final shutdown [0]:
Reason for shutdown [Standalone]:
Do you want to spin down the disk volumes [NO]?
Do you want to invoke the site-specific shutdown procedure [YES]?
Should an automatic system reboot be performed [NO]?
When will the system be rebooted [later]:
Shutdown options (enter as a comma-separated list):
REMOVE_NODE Remaining nodes in the cluster should adjust quorum
CLUSTER_SHUTDOWN Entire cluster is shutting down
REBOOT_CHECK Check existence of basic system files
SAVE_FEEDBACK Save AUTOGEN feedback information from this boot
Shutdown options [NONE]: reboot, remove
VMS will issue several messages indicating it is shutting down.
VMS will issue:
SYSTEM SHUTDOWN COMPLETE - USE CONSOLE TO HALT SYSTEM
2. At this point type a Control-P to halt the primary processor.
3. Move the lower key switch to the HALT position and record the
original position.
4. Enter INITIALIZE at the >>> prompt. This will reset the whole
system and force all processors into console mode.
5. You should examine the console map to determine the location of
each Rigel processor in your system. Record the location of each
processor. The map denotes a processor by printing an uppercase
letter P on the TYP line. Note which processors have been
disabled from becoming the Boot Processor. The BPD line gives
this information: an E indicates that the processor may be a
Boot Processor, a D indicates that it may not.
_ _ _ _ _ _ _ | FCO 64XMX-O002
| | | | | | | | |
|d|i|g|i|t|a|l| | PAGE 4 OF 7
|_|_|_|_|_|_|_| |
|
_______________________________|_________________________________________
6. Look at the console map and determine which nodes contain
processors then connect the terminal to the processor at the
lowest node or to a processor specifically designated as the
primary by entering -
>>> SET CPU n where n is the node number
7. Enter the SHOW BOOT command, and record the saved boot specific-
ations. Here is a sample of the command output:
>>> SHOW BOOT
DEFAULT /XMI:E /BI:4 DU3D
R54A /R5:00000001/XMI:E/BI:4 DU4A
DIAG /R5:00000010/XMI:E/BI:4 DU15
R5 /R5:00000001/XMI:E/BI:4 DUD
If the SHOW BOOT command prints no information, that is okay. It
means there was no stored boot specification.
8. Enter the <CTRL/3><DEL>SHOW SYSTEM SERIAL command, and record the
system serial number. Here is a sample of the command output:
>>> $^?SHOW SYSTEM SERIAL
System serial number: AG83701988
****************************************************************
* C A U T I O N *
* *
* All VAX modules contain electrostatic discharge *
* sensitive devices (ESDS). The use of an antistatic *
* wrist strap attached to the cabinet is essential when *
* when handling modules. *
****************************************************************
9. Before powering down the system, set the console terminal speed
to 1200.
Do not worry if the console writes strange characters after issuing
the command. This means your terminal is set to some baud rate
other than 1200 baud.
10. Press the SETUP key on your terminal and set the baud rate of your
terminal to 1200 baud. SAVE this setting. This allows you to
issue console commands once the new T2015 is installed.
11. Power down the system by turning the upper key switch on the
front control panel to the OFF position. Pull the circuit breaker
on the AC power controller (H405) to the OFF position and unplug the
system from the source.
12. Open the front cabinet door.
_ _ _ _ _ _ _ | FCO 64XMX-O002
| | | | | | | | |
|d|i|g|i|t|a|l| | PAGE 5 OF 7
|_|_|_|_|_|_|_| |
|
_______________________________|_________________________________________
13. Remove the clear plastic cover in front of the XMI cage.
14. Remove all T2015 CPU modules below revision "L" and all T2015-YA
modules below revision "D" using all ESD procedures.
******************************************************************
* **NOTE 1** *
* THE T2015-00 REVISION "AL" CONTAINS THE V3.0 CONSOLE/DIAGNOSTIC*
* ROM. THE V3.0 ROM SUPPORTS MIXED VERSIONS OF THE CONSOLE/ *
* DIAGNOSTIC ROM. THEREFORE, IF THE SYSTEM CONTAINS A MIX OF *
* REVISION "L" WHICH HAS THE V2.0 CONSOLE/DIAGNOSTIC ROM SET AND *
* REVISION "AL", THERE WILL BE NO COMPATIBILITY ISSUES. *
* *
* YOU WILL SEE CONSOLE ROM MISMATCH MESSAGES PRINTED DURING *
* SYSTEM INITIALIZATIUON. THESE DO NOT IDENTIFY A PROBLEM. THESE *
* SHOULD BE CONSIDERED INFORMATIONAL FOR LISTING ROM REVISIONS. *
* *
* THERE IS ONE EXCEPTION TO HAVING CONSOLE ROMS AT DIFFERENT *
* REVISIONS WITHIN THE SAME SYSTEM. THE VAX 6000 MODEL 400 *
* PROCESSOR CONSOLE ROM REVISION "V1" HAS A COMPATIBILITY PROBLEM*
* WITH REVISION "V2" OR "V3". THEY SHOULD NEVER BE MIXED IN THE *
* SAME SYSTEM. *
* *
* **NOTE 2** *
* DO NOT USE "UPDATE ALL" COMMAND WITH MIXED VERSIONS OF CONSOLE/*
* DIAGNOSTIC ROMS. USE INSTEAD, "PATCH UPDATE UTILITY", EVUCA *
******************************************************************
15. Replace all T2015 modules below revision "L" with EQ-01591-01
and all T2015-YA modules below revision "D" with EQ-01591-05
ensuring all new modules are placed in the same slots from
which the originals were removed.
16. Remove all T2017 CPU modules below revision "J" using all ESD
procedures.
17. Replace all T2017 modules below revision "J" with EQ-01591-02
ensuring all new modules are placed in the same slots from
which the originals were removed.
16. Return the clear plastic cover of the XMI cage.
17. Power on the system by setting the upper front panel keyswitch
to ENABLE. Ensure Self Test is completed successfully on all
T2015 and T2017 modules. If some modules fail selftest, you may
have to ensure the processor modules are seated correctly in
the backplane. It is not uncommon to have to reseat the boards
once or twice.
_ _ _ _ _ _ _ | FCO 64XMX-O002
| | | | | | | | |
|d|i|g|i|t|a|l| | PAGE 6 OF 7
|_|_|_|_|_|_|_| |
|
_______________________________|_________________________________________
18. Move the lower key switch to the Update position and restore
the system serial number and boot specifications recorded in
Steps 7 and 8, to the T2015's just installed. Do the following:
>>>SET CPU n
where n is the node number.
19. Enter the <CTRL/3><DEL>SET SYSTEM SERIAL command, using the serial
number you recorded in Step 8. Each T2015 must be done individually.
Following is a sample output from the command:
>>> $^?SET SYSTEM SERIAL
System Serial Number>>> AG83701988
Serial number read as: AG83701988
Update EEPROM? (Y or N) >>> Y
?73 System serial number updated.
20. Now, enter the boot specifications you saved in Step 7, using the
SET BOOT command. Here is sample output from the command:
>>> SET BOOT DEFAULT /XMI:E/BI:4 DU3D
It may be helpful to check the boot specification you just entered.
Enter the SHOW BOOT command to check the boot specification or
specifications. If your system contains more than one processor,
entering the SET BOOT command causes the boot specification to be
copied to all processors, so this command does not need to be
repeated on each processor.
21. In Step 5 you recorded which of the CPUs were prevented from
becoming primaries. You need to set that condition again.
>>> SET CPU [n] /NOPRIMARY
where n equals the node number.
22. Press RESET on the control panel or enter the INITIALIZE command
and ensure the console prints no error messages.
23. Return the lower front panel keyswitch to the position you recorded
in Step 3.
24. Boot the VAX Diagnostic Supervisor (VAX/DS), ERSAA.
25. Load and run ERKAX, ERKMP, EVKAQ, EVKAR, EVKAS, EVKAT, EVKAV,
EVKAV to test the T2015 modules. For the T2017, load and run
EVKAG and EVKAH.
26. Upon successful completion of the diagnostics, exit the VAX/DS.
_ _ _ _ _ _ _ | FCO 64XMX-O002
| | | | | | | | |
|d|i|g|i|t|a|l| | PAGE 7 OF 7
|_|_|_|_|_|_|_| |
|
_______________________________|_________________________________________
27. Update the Site Management Guide to reflect this FCO.
28. Report this FCO activity on the LARS form in the "Fail Area/
Module/FCO/Comments" column as described on Page 7.
LARS EXAMPLE
CATEGORY O USA GIA EUROPE
Activity -
(a)Contract and Warranty W U Y
(b)IN-DEC Contract & Warranty K
Hardware Segment Code 111
Non Contract/Non Warranty F F F
(c)RTD/Off-site Agreement F
Product Line 01
DEC Option 64XMX 64XMX 64XMX
Type of Call M M M
Action Taken D D I
Fail Area-Module-FCO-Comments 64XMX-O002 64XMX-O002 64XMX-O002
Material Used EQ-01591-01/ EQ-01591-01/ EQ-01591-01/
EQ-01591-02/ EQ-01591-02/ EQ-01591-02/
EQ-01591-05 EQ-01591-05 EQ-01591-05
(a) Warranty Optimum, Warranty Standard and Warranty Basic (on-site)
Agreements.
(b) Applies to INDEC AREA ONLY
(c) RTD=Return to Digital or Off-site Agreements; If Field Engineer
On-site, use Activity Code "F".
|
| 49.57 | PREVIOUS REPLY SHOULD BE IGNORED - 49.56 | KERNEL::BLAND | toward 2000 ... | Mon Mar 04 1991 18:20 | 7 |
| IGNORE THE PREVIOUS REPLY (FCO).
This FCO information was generated in USA and does not apply to Europe.
Watch this space for any further developments.
Norman
|
| 49.58 | BAD VDS Can cause format of wrong drive | KERNEL::BLAND | toward 2000 ... | Wed Mar 20 1991 12:08 | 233 |
| 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: Diagnostic may format the SYSTEM DISK
DATE: 18-MAR-1991
AUTHOR: JOHN KOWALL TD #: 000633
DTN: 522-3881
ENET: GENRAL::KOWALL CROSS REFERENCE #'s:
DEPARTMENT: Continuation Engineering (PRISM/TIME/CLD#'s)
INTENDED AUDIENCE: ALL PRIORITY LEVEL: 1
(U.S./EUROPE/GIA) (1=TIME CRITICAL,
2=NON-TIME CRITICAL)
=====================================================================
PROBLEM:
WARNING! Three versions of VAX Diagnostic 6000 Supervisors may test
the wrong drive!!! This may be the System Disk.
Products affected are from diagnostic release revision C only:
ELSAA - version 14.4-2438, VAX Diagnostic Supervisor
Systems affected: 58xx, VAX 6000-2xx, 6000-3xx
EMSAA - version 14.4-703, VAX Diagnostic Supervisor
Systems affected: VAX 6000-5xx
ERSAA - version 14.4-1127, VAX Diagnostic Supervisor
Systems affected: VAX 6000-4xx
NOTE: Also anyone with a proxy may have copied the above supervisors plus
EBSAA - version 14.4-2185
The part numbers for the Rev. C "SSB" release media (it will continue
to ship until May) are as follows:
AG-PDWVC-RE VAX 6000 CONSOLE CD-ROM
AG-PDWWC-RE VAX 6000 CMPLT DIAG CD-ROM
AQ-PDYPC-ME VAX 6000 CONSOLE TK50
AQ-PDWXC-DE VAX 6000 CMPLT DIAG TK50
BB-PDWYC-DE VAX 6000 CMPLT DIAG 16MT9
Caution: There are several EDIT versions of these supervisors now in
circulation. All read 14.4. You should run the D.S. to verify
what version you have and then determine if it must be patched
before running the following diagnostics:
EVRLB - VAX RA60/80/81 FORMATTER
EVRLF - UDA50/KDB50 BASIC SYBSYS DIAG
EVRLG - UDA50/KDB50 DISK DRIVE EXERCISER
EVRLJ - VAX UDA50/KDB50/KDM70 EXERCISER
EVRLK - VAX BAD BLOCK REPLACE UTILITY
The problem with the diagnostics EVRLB, EVRLF,EVRLG, EVRLJ, and EVRLK and
the supervisors have now been corrected. In order to aide you in determining
whether or not you have a good or bad version of these files, I have listed
the versions below. Two versions of diagnostic supervisor and diagnostics
are INCOMPATIBLE with each other:
1/ Early release 43 supervisors (14.4-*) with release 42 diags.
SSB release "C"
2/ Early release 43 supervisors (14.4-*) with early release 43 diags.
If you have copied any of these files from:
YODA::SYS$ARCHIVE: or
YODA::RELD$0:[ARCHIVE...] or
YODA::RELD$0:[43...]
Then, those diagnostics should be deleted.
The most serious symptom occurs with EVRLB, which will always format drive #0.
Diagnostic Version Review
_________________________
GOOD GOOD GOOD
Bad Versions Release 42 Release 43 Release C
Delete Versions Versions after patching
EBSAA 14.4-2185 14.1 14.4-PAT1 14.4-PAT2
ELSAA 14.4-2438 14.1 14.4-PAT1 14.4-PAT2
EMSAA 14.4-704 -- 14.4-PT1 14.4-PT2
ERSAA 14.4-1127 14.1 14.4-PAT1 14.4-PAT2
EVRLB 8.2 8.0 8.3 8.0
EVRLF 10.3 10.0 10.4 10.0
EVRLG 10.2 10.0 10.3 10.0
EVRLJ 4.2 4.0 4.3 4.0
EVRLK 4.2 4.0 4.3 4.0
=====================================================================
Symptom:
Drive #0 is always tested, regardless of which disk units were selected for
testing. In the case of the formatter, EVRLB, drive #0 would always be
formatted. If drive #0 does not exist, no diagnostic can be run, an error
message similar to the following will appear:
******** EVRLF - VAX UDA50/KDB50 BASIC SUBSYSTEM DIAGNOSTIC - 10.1 ********
Pass 1, test 3, subtest 0, error 5000, 8-FEB-1990 08:24:27.10
Device fatal error while testing DUC95: DM PROGRAM REPORTING AN ERROR
DISK FUNCTION DM PC: 5344 Controller at address 100362 (O) DRIVE _DUC95
UNABLE TO FIND REQUESTED DRIVE FOR TESTING
THE FOLLOWING IS VISIBLE ON THE PORTS
CONTROLLER PORT 0 -- DRIVE 95
CONTROLLER PORT 1 -- NO DRIVE ATTACHED
CONTROLLER PORT 2 -- NO DRIVE ATTACHED
CONTROLLER PORT 3 -- NO DRIVE ATTACHED
******** End of Device fatal error number 5000 ********
=====================================================================
RESOLUTION/WORKAROUND: Wait/Copy/Patch
Wait:
The diagnostic release "D" will be available from SSB which is
scheduled for May 6,1991). It will have release 43 (D) diagnostics.
Copy:
The Diagnostics Supervisors can be copied over the network:
COPY YODA::DISK$DS:[DS.GLOBAL.RELEASE.REVC_COM]*.EXE *
Patch:
The following procedures can be used to apply patches to the Rev. C
versions of diagnostic supervisors:
I. CD-ROM booting
A. Apply the patches by hand.
Do the following:
1)Boot the diagnostic supervisor from CD-ROM
2)Type the commands from the appropriate command file.
or
B. Load the patch command file from another drive.
Do the following:
1)Copy the appropriate patch command file and
autosizer (EVSBA.EXE) to another drive
2)Boot the diagnostic supervisor from CD-ROM
3)Run the autosizer (RUN EVSBA)
4)Set the load path to access the command file
(SET LOAD dev:[dir])
5)Execute the command file (@E%SAA.COM)
II. Non CD-ROM booting
A. Use the VMS PATCH utility to permanently apply the patches to the
supervisor executable E%SAA.EXE. Copy the patched supervisor to
the boot device:[directory].
or
B. Apply the patches via automatic command file executed at boot time
Do the following:
1)Copy the appropriate patch command file to the boot
device:[directory] with the name VDSSCRIPT.COM
2)Boot the diagnostic supervisor, specifying autocom feature
B/R5:8010 ...
or
C. Apply the patches by hand.
Follow procedure A from part I above.
or
D. Load the patch command file from a drive other than the boot drive.
Follow procedure B from part I above.
The order of the above steps must be followed exactly. The command files are
modifying code which accesses the device ptables, so once the patches are
applied the ptables must be rebuilt. This is why the autosizer is run after
the patches are applied. Some sites may use command files to ATTACH devices,
so the command file should be executed in place of running the autosizer.
In some cases, the diagnostic supervisor attaches device ptables in the boot
path, which the autosizer does not subsequently reattach. If this happens,
a "File Read Error" will result when trying to load diagnostics, take a
directory, or get help. This can be recovered from by reattaching
the suspect ptable, or resetting the load path (SET LOAD) to the device name
which the autosizer built.
The command files for patching REV "C" supervisors and the patched
supervisors which are in the final Release 43 are available world readable
from:
YODA::DISK$DS:[DS.GLOBAL.RELEASE.REVC_COM]
ELSAA.COM EMSAA.COM ERSAA.COM
EBSAA.EXE ELSAA.EXE EMSAA.EXE ERSAA.EXE
=====================================================================
ADDITIONAL COMMENTS:
Please note that the physical labels on the CD-ROMs do not match their volume
labels. The physical label will read 6000_CONS_C and 6000_DIAG_C, but the
volume label (service name of CD-ROM) will read 6000_CONS_B and 6000_DIAG_B.
*** DIGITAL INTERNAL USE ONLY ***
|
| 49.59 | European 6000-400 FCO | KERNEL::ROBB | | Thu May 16 1991 12:53 | 62 |
| I N T E R O F F I C E M E M O R A N D U M
Date: 01-May-1991 11:29pm BST
From: HESSOM
HESSOM@KERNEL@KERNEL@MRGATE@THESUN@UVO
Dept:
Tel No:
TO: See Below
Subject: 64XMX-O002 FCO
Dear Ladies and Gentlemen,
In the past year, 601 T2015 modules have been consumed in the UK,
on an installed base of approximately 700 modules. If this is not a
real product issue God only knows what is, but the only way to fix
it is with this FCO.
As we have nearly swapped the installed base in 12 months, it is
logical to assume that the FCO could have been completed in the
same period, its just a great pity the EQ kits were not available a
year ago!
As we are still consuming the T2015 at a high rate, I propose that
for the next 12 months we remove the T2015 line item from stockroom
shelves and replace it with EQ-01591-01 (containing a revision "AL"
T2015). The FCO strategy will be "Fit on Failure", and for ANY 64XX
call, engineers will use the EQ kit, and not the T2015, booking the
call to "Y". Of course critical sites, especially those that have
been waiting long for the FCO can have their modules swapped under
the FCO, but please bear in mind material availability constraints.
Please let me know ASAP if this is acceptable.
I thank everybody for responding to the population request, its
been good as a sanity check if nothing else. I attach the latest
feedback.
Yours sincerely,
David.
o EDO 52 Stephen Tennant
o WLO 84 Dave Bazley
o BIO 91 Steven Allen
o HHL 137 Janice Johnson
o OLO 70 Paul Walton
o UBO 23 Janet Blythe
o BSO 73 Jo Israel
o ESO 13 Wayne Walker
o LZO/RKA 57 Trevor Bromley
o EOO 35 Ian Pepper
o BVO 5 Colin Houston
Total 640
|