Digital Equipment Corporation
Maynard, Massachusetts
August, 1994
Digital Equipment Corporation makes no representations that the use of its products in the
manner described in this publication will not infringe on existing or future patent rights, nor do
the descriptions contained in this publication imply the granting of licenses to make, use, or sell
equipment or software in accordance with the description.
Possession, use, or copying of the software described in this publication is authorized only
pursuant to a valid written license from Digital or an authorized sublicensor.
This guide describes the procedures and tests used to maintain and
troubleshoot VAX 4000 Model 500A, 505A, 600A, 700A, and 705A systems,
which use the following kernels:
SystemKernel
VAX 4000 Model 500AKA681
VAX 4000 Model 505A/600AKA691
VAX 4000 Model 700AKA692
VAX 4000 Model 705AKA694
Intended Audience
This guide is intended for use by Digital Equipment Corporation Service
personnel and qualified self-maintenance customers.
Warnings, Cautions, Notes
Warnings, cautions, and notes appear throughout this guide. They have the
following meanings:
Preface
WARNINGProvides information to prevent personal injury.
CAUTIONProvides information to prevent damage to equipment or software.
NOTEProvides general information about the current topic.
Conventions
The following convention indicates that the user enters the command at the
system prompt.
>>>SHOW DSSI
xv
System Maintenance Strategy
Any successful maintenance strategy is predicated on the proper understanding
and use of information services, service tools, service support and escalation
procedures, and field feedback. This chapter lists the various service
tools, information services, and service delivery methods used in system
maintenance.
1.1 Service Delivery Methodology
Before beginning any maintenance operation, you should be familiar with the
following:
•The site agreement
•Your local and area geography support and escalation procedures
•Your Digital Services product delivery plan
Service delivery methods are part of the service support and escalation
procedure. When appropriate, remote services should be part of the initial
system installation. Methods of service delivery include the following:
1
•Local support
•Remote call screening
•Remote diagnosis and system initiated service requests (using DSNLink,
SICL, MDS01, modem, etc.)
The recommended system installation includes:
•Hardware installation and acceptance testing. Acceptance testing
(Chapter 4) includes running ROM-based diagnostics and running
MDM to test Q–bus options.
•Software installation and acceptance testing. For example, using OpenVMS
Factory Installed Software (FIS), and then acceptance testing with UETP.
System Maintenance Strategy 1–1
System Maintenance Strategy
1.1 Service Delivery Methodology
•Installation of the Symptom-Directed Diagnosis (SDD) toolkit
(VAXsimPLUS and SPEAR) and remote services tools and equipment
(this includes installing DSNlink, modems, etc., and enabling SICL). When
the installation is complete, the system should be able to dial out using
SICL, and the Digital Service Center should be able to call into the system.
Refer to your remote service delivery strategy.
If your service delivery methodology is not followed, service expenses for any
product could be excessive.
1.2 Product Service Tools and Utilities
This section lists the array of service tools and utilities available for acceptance
testing, diagnosis, and overall serviceability; and it provides recommendations
as for their use.
•OpenVMS Operating System Error Handling/Logging
The OpenVMS operating system provides recovery from errors, fault
handling, and event logging. The Error Report Formatter (ERF)
provides bit-to-text translation of the event logs for interpretation.
RECOMMENDED USE: Analysis of error logs is the primary method
of diagnosis and fault isolation. If the system is up, or the customer
allows the service engineer to bring the system up, this information
should be looked at first. Refer to Section 5.2 for information on
Product Fault Management and Symptom-Directed Diagnosis.
SDD tools are used primarily for notification of the existence of errors
that have reached a critical threshold. SDD tools must be installed
during system installation or as soon as product support is provided.
SDD tools are not bundled with the OpenVMS operating system.
RECOMMENDED USE: Used primarily for onsite notification to
the user via mail or to a remote Digital support center via System
Initiated Call Logging (SICL). Refer to Section 5.2.9 for information on
VAXsimPLUS and SICL.
1–2 System Maintenance Strategy
•ROM-Based Diagnostics
ROM-based diagnostics have significant advantages:
Load time is virtually nonexistent.
The boot path is more reliable.
Diagnosis is done in a more primitive state.
RECOMMENDED USE: The CPU ROM-based diagnostic facility is the
primary means of offline testing and diagnosis of the CPU, memory,
Ethernet, and DSSI subsystems. The ROM-based diagnostics are
used in the acceptance test procedures (Section 4.4) when installing
a system, adding a memory module, or replacing the following: CPU
module, memory module(s), backplane, DSSI device, or H3604 console
module. Use the ROM-based diagnostic error messages in Table 5–9 to
isolate FRUs.
•Firmware Console Commands
Several commands and utilities are needed in configuring a system and
setting and examining system and device parameters. For example, the
CONFIGURE command is used to determine the proper CSR addresses
for modules; the SHOW MEMORY, SHOW DSSI, and SHOW QBUS
commands are used to examine the configuration and memory error
status; and the SET HOST command is used to access the DUP driver
to configure DSSI parameters.
System Maintenance Strategy
1.2 Product Service Tools and Utilities
RECOMMENDED USE: Use console commands to configure the system
and in setting and examining device parameters. Refer to Section 3.8
for information on firmware commands and utilities. Appendix A
provides information on all available console commands.
•Option LEDs During Power-Up
Many options and modules have LEDs that display pass/fail self-test
results.
RECOMMENDED USE: Monitor option and module LEDs during
power-up to see if they pass their self-tests. Refer to Sections 4.2.2 and
4.2.3 for information on power-up tests for Q–bus and mass storage
devices. For more information on individual options, refer to your
Microsystems Options manual.
System Maintenance Strategy 1–3
System Maintenance Strategy
1.2 Product Service Tools and Utilities
•Operating System Exercisers (OpenVMS UETP)
The User Environment Test Package (UETP) is an OpenVMS software
package designed to test whether the OpenVMS operating system is
installed correctly.
RECOMMENDED USE: Use UETP as part of acceptance testing to
ensure that the OpenVMS operating system is correctly installed.
UETP is also used to stress test the user’s environment and
configuration by simulating system operation under heavy loads.
•MicroVAX Diagnostic Monitor (MDM)
The loadable diagnostic MDM requires a minimum of Release 139 to
support VAX 4000 Model 500A/505A/600A/700A/705A systems. Consult
your MicroVAX Diagnostic Monitor User’s Guide for instructions on
running MDM.
RECOMMENDED USE: MDM is used primarily for testing Q–bus
options.
•Loopback Tests
Internal and external loopback tests can be used to isolate a failure
by testing segments of a particular control or data path. The loopback
tests are a subset of the ROM-based diagnostics and MDM diagnostics.
RECOMMENDED USE: Loopback tests can be used to isolate problems
with the console port, DSSI adapters, Ethernet controller, and many
common Q–bus options. Refer to Section 5.7 for instructions on
performing loopback tests.
•Crash Dumps
For fatal errors, the OpenVMS operating system will save the contents
of memory to a crash dump file, e.g., fatal bugchecks.
RECOMMENDED USE: Crash dump file analysis should be
performed by support. Saving a crash dump file for analysis requires
proper system settings. Refer to your OpenVMS operating system
documentation for instructions.
1–4 System Maintenance Strategy
1.3 Information Services
Digital Services engineers may access several information resources, including
advanced database applications, online training courses, and remote diagnosis
tools. A brief description of some of these resources follows:
•Technical Information Management Architecture (TIMA)
TIMA is used by Digital Services to deliver technical and reference
information to its service engineers. One of the main benefits of TIMA
is the pooling of worldwide knowledge and expertise. Both service and
customer documentation for VAX 4000 systems are available on TIMA.
•Entry Systems Service Information Kits
Service documentation containing information on enclosures, CPUs,
and options, makes up the Entry Systems Service Information Kit.
The manual you are reading is part of the kit. Refer to your Guideto Entry Systems Service Information Kits (EK–276A*–MI) for more
information.
•Training
Computer Based Instruction (CBI) and lecture lab courses are available
from the Digital training center:
System Maintenance Strategy
1.3 Information Services
VAX 4000 Model 500 System Installation and Troubleshooting (CBI
course, EY–I089E–EO (applicable for VAX 4000 Model 500A/505A
/600A /700A/705A systems)).
MicroVAX Installation and Troubleshooting (Lecture lab course,
EY–9408E–LO)
•Digital Services Product Delivery Plan (Hardware or Software)
The Product Delivery Plan documents Digital Services delivery
commitments. The plan is the communications vehicle used among the
various groups responsible for ensuring consistency between Digital
Services delivery strategies and engineering product strategies.
•Blitzes
Technical updates are ‘‘blitzed’’ to the field using mail and TIMA.
System Maintenance Strategy 1–5
System Maintenance Strategy
1.3 Information Services
•Storage and Retrieval System (STARS)
Stars is a worldwide database for storing and retrieving technical
information. The STARS databases, which contain more than 150,000
entries, are updated daily.
Using STARS, a service specialist can quickly retrieve the most
up-to-date technical information via DSNlink or DSIN.
•VAX Notes
The company notes network has many conferences on the VAX. Review
the list of conferences in TURRIS::EASYNET_CONFERENCES.
•DSNlink
DSNlink software application lets the Digital Services Center
communicate electronically with the customer site. DSNlink serves as
the platform for the delivery of electronic services.
1.4 Field Feedback
Providing the proper feedback to the corporation is essential in closing the loop
on any service call. Consider the following when completing a service call:
•Repair tags should be filled out accurately and with as much symptom
information as possible so that repair centers can fix a problem.
•Call closeout information for Labor Activity Reporting System (LARS) or
Call-Handling and Management Planning (CHAMP) needs to be accurate.
•The site maintenance log, whether hardcopy or electronic, should provide a
chronicle of the performed maintenance.
1–6 System Maintenance Strategy
CPU System Overview
This chapter provides an overview of the components that make up
KA681/KA691/KA692/KA694-based systems. These components are listed
below:
•CPU: KA681 (L4005–BA), KA691 (L4005–AA), KA692 (L4006–AA), or
KA694 (L4006–BA)
•MS690 memory modules
•BA440 enclosure components
H3604 console module
System control panel (SCP)
BA440 backplanes
Power supply
Fans
Caution
Static electricity can damage integrated circuits. Always use a
grounded wrist strap (PN 29–11762–00) and grounded work surface
when working with the internal parts of a computer system.
2
CPU System Overview 2–1
CPU System Overview
2.1 CPU Module Features
2.1 CPU Module Features
The KA681/KA691/KA692/KA694 CPUs are quad-height VAX processor
modules that use the Q22–bus and DSSI bus. The CPUs are used in the
following systems:
SystemCPU
VAX 4000 Model 500AKA681
VAX 4000 Model 505A/600AKA691
VAX 4000 Model 700AKA692
VAX 4000 Model 705AKA694
The CPU module is designed for use in high-speed, real-time applications
and for multiuser, multitasking environments. The KA681/KA691/KA692
/KA694 employ multiple levels of cache memory to maximize performance. See
Figure 2–1 for a view of the major chips, LEDs, and connectors. Table 2–1
describes the CPU module components. See Figure 2–2 and Figure 2–3 for
block diagrams of the major functions.
The CPU module and MS690 memory modules combine to form the CPU
/memory subsystem that uses DSSI buses to communicate with mass storage
devices, the Q22–bus to communicate with I/O devices, and the Ethernet to
communicate across the network.
The CPU module and optional DSSI daughter board combine to expand the
DSSI buses’ capability to four ports. See Figure 2–5 for a view of the major
chips and connectors.
The CPU module is configured as an arbiter CPU on the Q22–bus, where it
arbitrates bus mastership and fields any on-board interrupt requests.
2–2 CPU System Overview
CPU System Overview
2.1 CPU Module Features
Figure 2–1 KA681/KA691/KA692/KA694 CPU Module Component Side
Console Connector, J2
BCache
(Tag
Store)
Run LED
DC246
NVAX
Diagnostic LEDs
DC243
NCA
DC541
SGEC
E-Net ROM
CDAL 2 Connector
DC542
SHAC
CLK
DC511
Firmware
ROMs
SSC
B-CACHE
(Data Store)
Backplane Connector, J1
DC244
NMC
Obit Rams
DC527
CQBIC
CDAL 1 Connector
DC542
SHAC
MLO-010827
CPU System Overview 2–3
CPU System Overview
2.1 CPU Module Features
Table 2–1 KA681/KA691/KA692/KA694 CPU Module Components
ComponentsFunction
DC246 (NVAX)Central processor unit. Contains a 64-entry translation buffer
KA694: Central processor unit has 9-ns cycle time.)
Backup cache RAMsKA681: 128-KB backup cache (B-cache).
KA694: 2-MB backup cache (B-cache).)
DC243 (NCA)NDAL to CDAL I/O bus interface chip.
DC244 (NMC)Main memory controller (also provides ECC protection).
DC527 (CQBIC)Q22–bus interface.
DC541 (SGEC)Ethernet interface.
Ethernet Station Address ROMProvides unique hardware address.
DC542 (SHAC)DSSI interface chips (2).
DC511 (SSC)System support chip.
DC509 (CLK)Clock.
Firmware ROMsTwo resident firmware chips, each 256 K by 8 bits of FLASH
Obit RAMsThe ECC protected ownership-bit RAMs provide coherency
Console connector100-pin for connection to the H3604 console module (J2).
Backplane connector270-pin for connection to backplane for Q22–bus, DSSI bus,
Run LEDIndicates that the CPU module is receiving power.
Diagnostic LEDsA hexadecimal value displays on the four diagnostic LEDs.
integral floating-point unit, 2-KB virtual instruction stream
cache (VIC), 8-KB physical instruction and data stream
primary cache (P-cache), and backup cache control and error
correction code (ECC).
KA681: Central processor unit has 14-ns cycle time.
KA691: Central processor unit has 12-ns cycle time.
KA692: Central processor unit has 10-ns cycle time.
The values correspond to the decimal value displayed on the
H3604 console module LED.
2–4 CPU System Overview
CPU System Overview
2.1 CPU Module Features
Figure 2–2 KA681/KA691/KA692/KA694 Kernel System Functional Diagram
CDAL 2 Connector
(96-Pin)
Backplane Interconnect
DSSI Bus #1
Ethernet
Serial Line
H3604
Console
Module
CDAL 1 Connector
(96-Pin)
Ribbon
Cable
Console Connector
(100-Pin)
CPU
Module
DSSI
Daughter
Board
Backplane Connector
DSSI Bus #0
(270-Pin)
Q22-bus
NMI Bus (150-Pin)
MS690 Memory Modules
(1 minimum/4 maximum)
DSSI Bus #2
DSSI Bus #3
To Mass Storage
Slots
To Q22-bus Slots
MLO-010206
CPU System Overview 2–5
CPU System Overview
2.1 CPU Module Features
Figure 2–3 KA681/KA691/KA692/KA694 CPU Module Block Diagram
B-cache
Optional
via
KFDDB DSSI
Daughter Board
NVAX
CPU
P-cache
VIC
NDAL
NCA
CDAL 1
SSC
ROM
CDAL 2
SHAC3
SHAC4
To Console Module
SHAC1
SHAC2
SGEC
CQBIC
NMC
DSSI #2
DSSI #3
DSSI #1
DSSI #0
Ethernet
Q22-bus
To Memory
To QBus
Bukkhead
To QBus
Bukkhead
To BA440
Disks
To Console
Module
To BA440
Backplane
MLO-007262
2.2 MS690 Memory Modules
The MS690 memory module is a double-sided, quad-height memory board that
uses a 150-pin, high-density connector to communicate to the CPU module.
MS690 memory modules are ECC protected via the NMC chip on the CPU
module.
The MS690 memories are available in four variations:
•MS690–BA (L4004–BA) 32 MB memory (not used on KA692 or KA694)
•MS690–CA (L4004–CA) 64 MB memory
•MS690–DA (L4004–DA) 128 MB memory
2–6 CPU System Overview
CPU System Overview
2.2 MS690 Memory Modules
KA681/KA691/KA692/KA694-based systems allow for any combination of up to
four MS690 memory arrays providing a memory capacity from 32 Mbytes up to
512 Mbytes, with the exception that the MS690-BA may not be used with the
KA692 or KA694.
Figure 2–4 shows a sample memory module, which, like the CPU module,
uses ejector handles designed to ensure proper seating of the modules in the
backplane connectors.
Figure 2–4 Ratchet Handles for CPU and Memory Modules
Ejector
Handles
2.3 (Optional) DSSI Daughter Board
KA681/KA691/KA692/KA694-based systems have a connector for an optional
DSSI bus daughter board. The optional DSSI daughter board contains two
SHAC chips which increase the CPU’s total DSSI bus capability to four ports.
See Figure 2–5 for a view of the major chips and connectors. Table 2–2
describes the DSSI bus daughter board components and their functions.
MLO-004227
CPU System Overview 2–7
CPU System Overview
2.3 (Optional) DSSI Daughter Board
Figure 2–5 (Optional) DSSI Module Component Side
Bus 3
DSSI Connector
DSSI 3
Terminator
Sockets
DC542
SHAC
DC542
SHAC
Bus 2
DSSI Connector
DSSI 2
Terminator
Sockets
96-Pin
Mother Board
Connector
2–8 CPU System Overview
MLO-010209
Loading...
+ 328 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.