Hardware Troubleshooting

Caution Before removing any components from the chassis, read the safety instructions below. If you handle components without taking proper ESD precautions, you may damage the system.

Warning LightStream 2020 switches are designed and manufactured to meet accepted safety standards. However, improper use can result in electrical shock, fire hazards, and personal injury. Read all of the following instructions carefully before installation and use. Note and adhere to all Cautions and Warnings.

Electrostatic Discharge (ESD) Protection

Static electricity can damage or degrade electronic components. To avoid damage, observe the following precautions when you touch hardware.

Grounding Procedure

Before you expose circuitry, make sure that your body, the rack, and the circuit boards are at the same ground potential to prevent damaging ESD. To connect yourself to ground, use a wrist strap connected to one of the system's grounding jacks, or to the bare metal surface of the system frame.

Card Protection

All spare cards are shipped in reusable antistatic shielding bags. When cards are not installed in the machine, keep them in antistatic bags. Do not remove cards from their bags unless you are grounded. Do not place these bags on exposed electrical contacts, where they can cause short circuits.

Overview

This chapter will help you isolate problems in a LightStream 2020 switch to a single field-replaceable unit (FRU), such as a line card, blower, or power supply. Once you've identified the faulty FRU, refer to the chapter "Replacing FRUs" for instructions on removing and replacing it.

This section briefly describes three methods of identifying problems in a LightStream 2020 switch:

Power-on self test (POST) diagnostics (run by the system)
General troubleshooting
Hardware diagnostics (run by you)

POST diagnostics are described below, and instructions for general troubleshooting and running hardware diagnostics are provided later in this chapter.

About Power-On Self Tests

Power-on self test (POST) diagnostics are the first line of defense for identifying hardware problems. POST runs automatically on each card whenever the system or the slot is powered up or when the card is reset; it takes about 90 seconds. There are POSTs for the following components:

NP
Low-speed line card
Medium-speed line card
Cell line card
Packet line card

The POST for each line card also checks the accompanying access card.

If a card passes POST, the green RDY LED on its front bulkhead turns on. If a card fails POST, its yellow FLT LED turns on. To display POST results, use one of these commands:

In TCS: show <slot#> post
In CLI: show tcs <slot#> state

In the resulting display, look at the POST: line and the Application: line. If the Application: line says DISABLED, you may be able to correct the problem by enabling (activating) the card. See the LightStream 2020 Network Operations Guide for instructions.

Note The FLT LED doesn't necessarily indicate a POST failure or a disabled application; the LED stays on under other conditions as well. (See the "LED Descriptions" section in the chapter "Hardware Description" for more information on the FLT LED.) If the LED is on but the POST result is OK, try operating the card.

If a card fails POST, review the portion of the section "Troubleshooting" for the card in question. In most cases, you should also run the hardware diagnostics to confirm that a problem exists. (Hardware diagnostics are described briefly below; the instructions for running them appear in the section "Using the Diagnostic Software".)

About Hardware Diagnostics

LightStream 2020 hardware diagnostics are used to discover the location of hardware faults. You can run diagnostics on a line card or a backup NP while the rest of the system continues to operate. Generally, only the card under test comes out of service during the diagnostics. (The exception is when you're testing the single NP in a non-redundant system; this requires taking the system off line.)

Note that certain tests should not be run while the system is operating, and other restrictions may apply as well. See the "Test Notes" section for details.

You can run diagnostics either remotely over a telnet or modem connection, or locally from a console connected to the console port. (The exceptional case is running diagnostics on the sole NP in a non-redundant system. This task requires a local console.)

The diagnostics reside on each NP's hard disk. Several parts of the system can be tested:

NP diagnostics test the NP card, the associated disk drives, and the NP access card
LSC diagnostics test low-speed line cards and associated access cards
MSC diagnostics test medium-speed line cards and associated access cards
PLC diagnostics test packet line cards and associated access cards
CLC diagnostics test cell line cards and associated access cards

Procedures for running the diagnostics appear in the section "Using the Diagnostic Software."

About Troubleshooting

General troubleshooting tasks can be performed before, after, instead of, or in addition to running the diagnostic software. These tasks provide additional ways of identifying faults in NPs, switch cards, and line cards. They are the only way to identify faults in subsystems that are not covered by POST or diagnostics, such as blowers and power supplies. The section that follows describes general troubleshooting tasks.

Troubleshooting

Use the information in this section to help isolate faults in a LightStream 2020 switch. This section is to be used in conjunction with the diagnostic software. Some of these procedures require you to be in the same room with the faulty system; others can be performed remotely.

When the Problem Won't Go Away

If your LightStream 2020 switch doesn't operate properly after you've tried the suggestions below, call your customer support representative.

Connection Problems

Before resorting to the diagnostics or to complex troubleshooting, check simple things:

Are the power cord(s) and data cables firmly connected at both ends?
Are all the cards (front and back of the chassis) firmly seated in the midplane and screwed securely to the chassis?
Are the power supplies, blowers and disk drives properly connected and screwed securely to the chassis?

Configuration Problems

If you're bringing up a new LightStream 2020 node, a new card, or a new kind of port for the first time, a likely source of problems is configuration. The problem may exist at either the LightStream side or the remote side of the connection; be sure to check both configurations. Refer to the LightStream 2020 Configuration Guide for information on software configuration.

Troubleshooting Switch Cards

The symptoms listed below indicate problems that may require replacement of a switch card. Switch card replacement instructions appear in the chapter "Replacing FRUs".

POST fails (the FLT LED on the card's bulkhead stays lit and checking POST results as directed in the section "About Power-On Self Tests" shows a problem)
The switch card fails even when moved to the other slot. (If the card fails in one slot but operates properly in the other, suspect a problem with the midplane.)
Diagnostics that loop data through the switch card fail on two or more function cards

Note To test the switch card's switching fabric, do one or both of the following:

Run tests that loop data through the switch card on NPs and/or line cards in every slot in the chassis.
Use the test_node utility, which loops data through the switching fabric from all low-speed line card interfaces and from all trunk interfaces. (The utility does not test other interfaces in this fashion.) test_node is described in the LightStream 2020 NP O/S Reference Manual.

The card fails to come up or to select a TCS hub
Traffic isn't passing through the system, but the line cards and NPs are OK
The system has data transmission problems that don't go away when you replace the FRU that appears to be failing, or that occur in several FRUs simultaneously. (Problems of this type may also indicate a faulty midplane.)
The switch card cannot be fully inserted into its slot. This probably indicates damage to the connectors on either the card or the midplane. Inspect all the connectors; if you find damage, replace the card or the midplane. (See the chapter "Replacing FRUs" for instructions.)

Note If the switch card's fault (FLT) LED is lit, see the "LED Descriptions" section in the chapter "Hardware Description" for a list of possible causes and solutions.

Troubleshooting NPs

If the NP fails to power up, check its access card at the back of the chassis. An NP requires an NP access card (NPAC); it can't operate with any other kind of access card.

Note If the NP's fault (FLT) LED is lit, see the "LED Descriptions" section in the chapter "Hardware Description" for a list of possible causes and solutions.

Replace the NP if any of the following applies. NP replacement instructions appear in the chapter "Replacing FRUs."

POST fails (the FLT LED on the card's bulkhead stays lit and checking POST results as directed in the section "About Power-On Self Tests" shows a problem)
The NP fails even when moved to the other slot. (If the card fails in one slot but operates properly in the other, suspect a problem with the midplane.)
Hardware diagnostics fail
You can't get to CLI in order to run the diagnostics
The card fails to load
The NP or its access card cannot be fully inserted into its slot. This probably indicates damage to the connectors on either the card or the midplane. Inspect all the connectors; if you find damage, replace the card or the midplane. (See the chapter "Replacing FRUs" for instructions.)

If the system fails to boot, it could indicate either a problem with the NP itself, a problem with the NP's hard disk drive, or a problem with the software on the hard drive.

Troubleshooting Interface Modules

This section provides information on how to isolate faults in interface modules. (An interface module consists of a line card and its access card.)

Note If the line card's fault (FLT) LED is lit, see Table 1-4 in the chapter "Hardware Description" for a list of possible causes and solutions.

The following will help you distinguish between problems in a line card and problems in an access card.

Run the manufacturing diagnostics and read the "How to Proceed" section following the procedure for the line card in question. Information is provided on which tests check the access card.
If you have another line card of the same type as the one that seems to be malfunctioning, swap the two cards. If the second card has the same problem as the first one, the access card is probably at fault. If the second card works properly, the first line card is likely to be the source of the problem. (You can make a similar deduction by swapping access cards.)

Caution Do not swap one line card for another unless you're sure that the cards are of the same type. Most line cards can be configured as either edge or trunk cards. You can't determine by looking at a card whether it's an edge or a trunk; check by using the show card command in CLI.

Faults in the line card are more common than faults in the access card. If you can't determine which card is causing a problem, try replacing the line card.
Use the looping tests described in the LightStream 2020 Network Operations Guide.

If you're having trouble bringing up an interface module, check the following:

If the module will not power up, look at the back of the chassis. The access card behind the line card must be compatible with the line card. For example, a low-speed line card can't operate with a medium-speed access card; it requires a low-speed access card. See the "Access Cards" section of the chapter entitled "Hardware Description" for information on compatibility between line cards and access cards.
If an FDDI module will not pass traffic, make sure the FDDI cables for each port are attached to the proper connectors. If you're not sure, try reversing the cables on the A and B connectors. (If the cables are properly keyed, you will not be able to misconnect them.)
If you're bringing up a low-speed module, make sure the interface jumpers on the access card are set to match the physical interfaces marked on the fantails (V.35, X.21 or RS-449). See the chapter "Hardware Configuration" for more information on interface jumpers.
If you're bringing up an E1 circuit emulation (CEMAC) module, make sure the interface jumpers on the access card are set properly. See the chapter "Hardware Configuration" for details.

If you're having signal quality problems with a physical interface on an access card, check the following:

If your cable is too long or if your signal passes through too many connectors, you will suffer from signal attenuation. See the "Access Cards" section in the chapter "Hardware Description" for information on allowable signal loss (for optical interfaces) or maximum cable lengths (for electrical interfaces).
If your connectors are damaged, you may experience signal attenuation or data loss.
- Check optical connectors for dirt or scratches on the optical surface. If a connector is dirty, clean it by blowing compressed air from a distance of 3 inches (8 centimeters). The connectors on most cables may be cleaned with a cotton swab covered with an alcohol-moistened, lint-free wipe. (Check the cable manufacturer's cleaning instructions.)
- For electrical connectors, check that pins are not bent, broken, or loose.

Note To prevent complications from dirty or damaged connectors, keep any unused optical connector covered with its protective cap.

The following conditions may require replacement of either a line card or its access card. Replacement instructions appear in the chapter "Replacing FRUs."

POST fails (the FLT LED on the line card's bulkhead stays lit and checking POST results as directed in the section "About Power-On Self Tests" shows a problem)
A card fails even when moved to another slot. (When you move a line card, be sure to pair it with an appropriate access card; likewise, when you move an access card, pair it with an appropriate line card.)
Hardware diagnostics fail
The line card fails to load
The line card hangs repeatedly
The line card or access card cannot be fully inserted into its slot. This probably indicates damage to the connectors on either the card or the midplane. Inspect all the connectors; if you find damage, replace the card or the midplane. (See the chapter "Replacing FRUs" for instructions.)
Two or more ports are passing no traffic, dropping many cells, or flapping---coming up and down repeatedly. (If only one port has symptoms, suspect a problem with the line, the external DSU/CSU if one is present, the access card, or the remote device. The looping tests described in the LightStream 2020 Network Operations Guide may help to isolate the problem.)

Troubleshooting Blowers

The following conditions indicate failure of a blower. See the chapter "Replacing FRUs" for replacement instructions.

The temperature on one or more cards is out of the recommended range. This is indicated by the appearance of the temperature trap, NPTMM_6. (To display the temperatures on a particular card, use the CLI command show tcs <slot#> or the TCS command show <slot#> temperature.) If you detect a temperature problem, confirm the source of the problem as described below before replacing a blower. If you have an out-of-range temperature but the blowers are working, make sure the chassis is properly closed (all components, cards, bulkheads and filler panels must be in place), and that vents in the chassis and the rack panels are not blocked. Also check the temperature in the system area; it should not exceed 104° F (40° C).
The system is powered on, but the blower is not turning, making noise, or exhausting air. Problems in the rear blower are easier to detect because of the holes in the cover. Remove the front blower cover to examine the front blower.

Note Check the blowers carefully. A blower that appears to be turning on its own may be moving due to the breeze created by the other blower.

Warning The impeller inside the blower box may still be turning. Keep fingers, screwdrivers and other objects away from the perforations in the blower's housing.

The system is powered on, but the blower's green LED is off. The LED indicates that the blower is turning at a rate of at least 1500 rotations per minute. You can see the LED through the holes in the rear blower cover; you must remove the blower cover to see the front blower's LED.

Troubleshooting Bulk Power Trays

In a system with one power tray, no power will be present if the power tray is faulty. Suspect a problem with the power tray if cycling the system's power has no effect.

A system with two power trays can operate normally when only one is working; if you suspect a problem, use the CLI command show chassis powersupply. The display for a healthy dual-tray system is shown below. (In a system with only one power tray, both lines for the unused slot will read "Empty.")

cli> show chassis powersupply
Power Supply A: Power Supply A Type: Power Supply B: Power Supply B Type: cli>
Good 1200W AC Power Supply Good 1200W AC Power Supply

If a status line for an occupied slot says anything other than Good, check the faulty power tray to see that it's properly connected. (Power tray slot A is on top; slot B is on the bottom.) If the problem persists, replace the power tray as described in the section "Replacing a Power Tray" in the chapter "Replacing FRUs."

Troubleshooting Disk Assemblies

Disk assembly problems are indicated by the following symptoms:

The node fails to boot
Files become corrupted
In a system with two NPs, the primary NP appears to fail and the backup takes over---but the failed NP may pass diagnostics
The system fails to read or write floppy diskettes (In the case of a write failure, check the write protect switch on the diskette.)

If a disk problem is indicated, check the disk assembly connector for bent or broken pins. To do so, remove the disk assembly as described in the section "Replacing a Disk Assembly" in the chapter "Replacing FRUs." Then examine the 64-pin male connector at the back of the slot. If any pins are bent or damaged, they are the likely source of the problem. Replace the disk assembly connector as described in the chapter "Replacing FRUs."

If the connector is in good condition, the problem may be in the disk assembly itself, or in the software on the disk. If you suspect a problem with the software, you should be able to correct it by reinstalling the software as described in the LightStream 2020 Network Operations Guide. If that doesn't solve the problem, or if you believe the problem lies in the hardware, see the section "Replacing a Disk Assembly" in the chapter "Replacing FRUs" for instructions on replacing the disk assembly.

Troubleshooting the Midplane

Midplane problems are indicated by the following symptoms. Midplane replacement instructions appear in the section "Replacing the Midplane" of the chapter "Replacing FRUs."

A card fails in one slot but operates normally in other slots.
Data transmission problems don't go away when you replace the FRU that appears to be failing, or occur in several FRUs simultaneously. (Problems of this type may also indicate a faulty switch card.)
Failure of a card to fully insert into its slot. This probably indicates damage to the connectors on either the card or the midplane. Inspect all the connectors; if you find damage, replace the card or the midplane. (See the chapter "Replacing FRUs" for instructions.)
Electrical failure or electrical problems that don't go away when you replace the FRU that appears to be failing, or that occur in several FRUs simultaneously. Electrical problems include out-of-range voltages, indicated by trap NPTMM_6. You can check card voltages in the CLI using the command show tcs <slot#> voltage, as shown below, or from TCS using the command show <slot#> voltage all.


cli> show tcs 1 voltage

Slot  1 Voltage: 

   TCS VCC Voltage:        5.053 (Normal Range: 4.614 / 5.371)

   VCC Voltage:            5.029 (Normal Range: 4.370 / 5.615)

   SCSI Voltage:           4.833 (Normal Range: 4.614 / 5.371)

   VPP Voltage*:           0.000 (Normal Range: 11.067 / 12.858)

       *VPP Voltage Is Valid Only During FLASH Initialization

cli>

Using the Diagnostic Software

This section tells you how to run diagnostics on specified cards in a LightStream 2020 switch. You can access the diagnostics in three ways:

Using CLI's test command, you can run field diagnostics and view the results. This is the quickest and easiest approach and is adequate for most purposes. Note, however, that you cannot use the test command on an active NP.
Using CLI's test -m command, you can run manufacturing diagnostics on a line card or a backup NP. The manufacturing diagnostics have a command-driven interface that gives you more control over which tests you run and how you run them; however, the tests are the same ones you run in field diagnostics. You cannot test an active NP using this method.
Using a manual loading procedure, you can run manufacturing diagnostics. This is the only way to test the single NP in a nonredundant system.

The rest of this section is divided into the following subsections:

"Running Field Diagnostics" explains how to use the test command in CLI to run tests on a specified card and view the results.
"Loading Manufacturing Diagnostics" explains how to load the manufacturing diagnostics software into a nonredundant NP.
"Running Manufacturing Diagnostics" explains how to run the manufacturing diagnostics on a specified card.
"Test Notes" describes special requirements for certain tests.
"Command Reference" lists and describes commands you can use in the manufacturing diagnostics.

Running Field Diagnostics

This section tells you how to use the test command in CLI to run field diagnostics on a line card in a specified slot or on a backup NP.

Note You cannot use the test command to run diagnostics on an active NP. Instead, you must load the diagnostics manually and use the manufacturing diagnostic interface. The procedures describing this task appear in the sections "Loading Manufacturing Diagnostics" and "Running Manufacturing Diagnostics."

The first subsection below describes the switches you can use with the test command. The second subsection explains how to use the test command to test a line card, and the third tells you how to use the test command to test a backup NP.

The test Command

The syntax of the CLI test command is as follows:

test <slot#> [-l -p -s -x -r -m] [-F<filename>]

where

slot# is the number of the slot holding the card you wish to test. Slot 1 always holds an NP; slot 2 holds the second NP if one is present and otherwise may be a line card; slots 3 through 10 are line cards if they are populated.
-l runs loopback tests. This switch is typically used only by customer service representatives. Do not use this switch unless you have looping plugs installed. For lists of the tests run on each card by the -l switch, see the "Test Notes" section.
-p polls the diagnostics about every second so you can monitor the progress of the tests while they run. (When you use this switch, some test numbers are displayed, but some are skipped---this is normal.) When the tests complete, you are returned to CLI.
-s is for use by customer support only. Runs tests that loop data through the switch card.
-x runs extended memory tests. These can add as much as 40 minutes to the running time of the diagnostics. For lists of the tests run on each card by the -x switch, see the "Test Notes" section.
-r retrieves and displays the status of the diagnostics. (Does not work if you ran test with -m switch.)
-m invokes the manufacturing diagnostics, giving you access to a command-driven interface. This interface is described in the section "Running Manufacturing Diagnostics." When you use test -m, type ~q to return from the diagnostic interface to the CLI.
-Ffilename loads diagnostics from the specified file instead of from the default file for the card. The file you specify must be a moved or renamed copy of the default file, and you must match the file to the card type. The default diagnostics files in each LightStream 2020 reside on the NP's hard disk in the directory /usr/diag:
- diag_np1.aout : NP diagnostics
- diag_clc1.aout: Cell line card diagnostics
- diag_plc1.aout : Packet line card diagnostics
- diag_ls1.aout : Low-speed line card diagnostics
- diag_ms1.aout : Medium-speed line card diagnostics

Note The /usr/diag directory also includes a file of switch card diagnostics. These diagnostics are reserved for use by customer service personnel.

If you use the test command with multiple switches, you must enter each one with its own - (minus) character and separate the switches with spaces. For example:

Command with valid switches: test 4 -p -x
Command with invalid switches: test 4 -px

If you run the test command with no switches, diagnostics are loaded and run on the specified card in the background, and your CLI prompt returns so you can perform other tasks. The diagnostics complete in a minimum of 5 minutes. To display their status, type test <slot#> -r.

Using the test Command on a Line Card

This procedure explains how to use the test command in CLI to run diagnostics on a line card. CLI must be running on the system you plan to test.

Step 1 If the card you plan to test is passing traffic, warn anyone who will be affected that you are taking it out of service to run diagnostics.

Step 2 Log in to CLI.

Step 3 Enter protected mode:


cli>


protected

You will be prompted to enter the protected mode password.

Step 4 Use the set command to set the SNMP community to a community with write privileges. (If you don't know the appropriate community name for this system, contact the network administrator.) The example below gives the syntax of the command; replace write-community with a real community name.


*cli>


 set snmp community <write-community>

Step 5 Issue the test command. (Replace the 4 in the example below with the number of the card you want to test, and add any switches you need.)


*cli>


test 4

Step 6 Wait at least 15 minutes for the diagnostics to load and run. If you used the -x switch with test, wait at least 30 minutes. Then use the following command to retrieve test results, replacing the 4 with the slot number of the card you just tested:


*cli>


test 4 -r




Diagnostics are running, test 73, heartbeat = 18673




*cli>

The result indicates that the tests passed, that they failed, or (as shown above) that they're still running. In the last case, wait a few minutes for the tests to finish and type test 4 -r again.

Step 7 If the tests passed, the card is OK---skip to the next step.

If the tests failed, replace the card; see the chapter "Replacing FRUs" for instructions. In the case of failure, you should also record the list of test numbers and error numbers displayed when you type test -r, and return this list to the repair depot along with the failed card.

Step 8 To return a card to service after running diagnostics, use the following command:


*cli>


set card <slot#> active

Note After you set the card back to active status, you can no longer use test -r to retrieve diagnostic results.

Step 9 Use the set command to change the SNMP community back to a read-only community. Replace read-community in the example below with the name of a read-only SNMP community.


*cli>


 set snmp community <read-community>

Using the test Command on a Backup NP

Follow the procedures in this section to use the test command in CLI to run diagnostics on a backup NP. (If you need to test a lone NP, see the procedure "Loading Manufacturing Diags into a Lone NP.") This task requires either a local console connected to the switch under test or a modem connection. You cannot use telnet.

The first procedure below explains how to force the active and backup NPs to switch roles; this is only necessary if the NP you want to test is currently active. The second procedure tells you how to run the diagnostics.

Forcing the Active NP to Become Backup

Step 1 Warn anyone who will be affected that you are taking the system off the network temporarily.

Step 2 If the NP you want to test is currently operating as the backup, skip to the next procedure. If the NP to be tested is active, you must force it to become backup before you can run diagnostics.

If you're not sure which NP is primary, use the CLI command show chassis general and look for Slot of Primary NP in the resulting display.

Step 3 Establish a local console connection or a modem connection to the system under test. (See the LightStream 2020 Installation Guide for information on terminal settings and how to determine which port to use.)

Step 4 If the command line prompt you see does not contain the words TCS hub, type `. to get a TCS hub prompt.

Step 5 At the TCS hub prompt, use the connect <slot#> command to connect to the NP you want to test. The example below assumes that you will test the NP in slot 1.


TCS hub<<A>>


connect 1

Step 6 When you connect, you'll see a login prompt. Log in as root or fldsup.

Step 7 At the bash prompt, type reboot -n.

Step 8 Type `. to return to the TCS hub.

Step 9 Go promptly to step of the next procedure.

Testing the Backup NP

Start with step 1 of this procedure unless you just completed the previous procedure.

Step 1 If you haven't already done so, establish a local console connection or a modem connection to the switch under test. (See the LightStream 2020 Installation Guide for information on terminal settings and how to determine which port to use.)

Step 2 If the command line prompt you see does not contain the words TCS hub, type `. to get a TCS hub prompt.

Step 3 At the TCS hub prompt, use connect <slot#> to connect to the NP that you do not want to test. You'll use this NP, which must be active, to test the other one. The example below assumes that you are connecting to the NP in slot 2.


TCS hub<<A>>


connect 2

Step 4 Log in and, if necessary, type cli to start the CLI.

Step 5 Enter protected mode:


cli>


protected

You will be prompted to enter the protected mode password.

Step 6 Use the set command to set the SNMP community to a community with write privileges. (If you don't know the appropriate community name for this system, contact the network administrator.) The example below gives the syntax of the command; replace write-community with a real community name.


*cli>


 set snmp community <write-community>

Step 7 Issue the test <slot#> command, where slot# is 1 or 2---the number of the backup NP you're testing. If you need to add any switches to the test command, refer to the section "The test Command" for details.


*cli>


test 1

Step 8 Wait at least 15 minutes for the diagnostics to load and run. If you used the -x switch with test, wait at least 30 minutes. Then use the following command to retrieve test results, replacing the 1 with the slot number of the card you just tested:


*cli>


test 1 -r




Diagnostics are running, test 73, heartbeat = 18673




*cli>

Step 9 If the tests passed, the card is OK---skip to the next step. If the tests failed, you should replace the card; see the chapter "Replacing FRUs" for instructions. (In the case of failure, you should also record the list of test numbers and error numbers displayed when you type test -r, and return this list to the repair depot along with the failed card.)

Step 10 To return a card to service after running diagnostics, use the following command:


*cli>


set card <slot#> active

Note After you set the card back to active status, you can no longer use test -r to retrieve diagnostic results.

Step 11 Use the set command to change the SNMP community back to a read-only community. Replace read-community in the example below with the name of a read-only SNMP community.


*cli>


 set snmp community <read-community>

Loading Manufacturing Diagnostics

You must use manufacturing diagnostics to test the single NP in a nonredundant system. If you wish, you can also use them to test backup NPs and line cards.

This section contains the following procedures:

After loading the diagnostics, see the section "Running Manufacturing Diagnostics" for instructions on what to do next.

Loading Manufacturing Diags into a Lone NP

This procedure explains how to load the manufacturing diagnostics into the sole NP in a nonredundant system. Note that this procedure requires the system under test to stop passing traffic. It also requires you to have a local console connection or a modem connection to the switch whose NP you are testing. You cannot use telnet or rlogin.

The commands used in the procedure are listed below, followed by the procedure itself.

connect <slot#>

Establishes a terminal connection to the card in the specified slot.

reboot -n

Starts the reboot sequence that will allow you to load the diagnostic software.

(sd0b)diag/diag_np1.aout

Tells the NP to load the file diag_np1.aout.

Step 1 Warn anyone who will be affected that you are taking the system off the network temporarily.

Step 2 Establish a local console connection or a modem connection to the system under test. (See the LightStream 2020 Installation Guide for information on terminal settings and how to determine which console port to use.)

Step 3 If the command line prompt you see does not contain the words TCS hub, type `. to get a TCS hub prompt.

Step 4 At the TCS hub prompt, use the connect <slot#> command to connect to the NP. The example below assumes that the NP is in slot 1.


TCS hub<<A>>


connect 1

Step 5 When you connect, you'll see a login prompt. Log in as root or fldsup.

Step 6 Type reboot -n to enter the boot sequence. You'll see the following display:


**** LynxOS [rebooted by /bin/reboot] is down ****



Network Processor bootstrap (version 1.3: Sep 13 1993)

  1-Boot ATM switch application

  2-Begin full installation with boot from floppy disk

  3-List contents of hard disk root directory

  4-List contents of floppy disk root directory

  5-Boot system single-user

  6-Escape to full set of bootstrap options

  7-Extended help

Option>

Step 7 Type 6 at the prompt to escape to the bootstrap command line interpreter:


Option>

The following is displayed:


Network Processor bootstrap (version 1.3: Sep 13 1993)

Enter "help" for documentation on extended bootstrap options

Default:  (sd0a)lynx.os

Boot:

Step 8 At the boot prompt, enter the following command to load the diagnostic software:


Boot:


(sd0b)diag/diag_np1.aout

You'll see the following display:


booting: drive:0, partition:1, kernel:"diag/diag_np1.aout", flags:0x4201

Resetting SCSI bus

Diagnostic linked for 0x0

LOAD AT 0x0

        442980+0+0

START AT 0x5000



RMeg Bit value = 0

Configuring Main Memory for 32 Megabytes



*****************************************

*  Network Processor Debug Monitor      *

*              RELEASE 1.00             *

*  Revision 1.371  (Sep  1 1993)        *

*  Type 'help' or '?' for help          *

*****************************************




NP Mfg Debug Monitor[01]->

Step 9 For instructions on executing tests in NP diagnostics, see the section "Running Manufacturing Diagnostics."

Step 10 When you finish your diagnostic session, you must reset the NP. Type `. to return to the TCS hub. Then use the command reset <slot#> to reset the NP.

Loading Manufacturing Diags into a Line Card or Backup NP

If you wish, you can use the manufacturing diagnostics to test backup NPs and line cards. Use the procedure in this section to load the manufacturing diagnostics, then go on the following section, "Running Manufacturing Diagnostics," for further instructions.

As you follow the procedure below, you'll use these commands:

protected

Invokes protected mode in the CLI, allowing you to use test and other protected commands. You must enter a password to enter protected mode.

set snmp community <community>

Sets the SNMP community of the target node to community, a valid community name. You must set to a community with write privileges in order to load and run the diagnostics.

test <slot#> -m

Loads diagnostics into the card indicated by slot#, then passes you to the command-driven interface of the manufacturing diagnostics.

Step 1 If the card you plan to test is passing traffic, warn anyone who will be affected that you are taking it out of service to run diagnostics.

Step 2 Log into the node to be tested, start CLI and enter protected mode:

cli> protected

You will be prompted to enter the protected mode password.

Step 3 Use the set command to set the SNMP community to a community with write privileges. (If you don't know the appropriate community name for this system, contact the network administrator.) The example below gives the syntax of the command; replace write-community with a real community name.


*cli>


 set snmp community <write-community>

Step 4 Issue the test command with the -m switch, which loads manufacturing diagnostics. Replace slot# below with a real slot number.


*cli>


 test <slot#> -m

You'll see a display that resembles this one:


fcload: (ls2_1) compiled Aug 04 1995 @ 06:07:15 [version 1.79.2.1]


fcload: slot 7: taking per-slot synchronization lock


fcload: slot 7: initialization of VCIs complete


fcload: slot 7: disabling switch interface...


fcload: slot 7: resetting card...


fcload: slot 7: waiting for initialization...........initialization sequence complete


fcload: slot 7: (clc1 card oc3 accesscard) starting SWACC loader


fcload: slot 7: waiting for initialization.initialization sequence complete


fcload: slot 7: waiting for remote SWACC loader to initialize:.Ready


Loading "/usr/diag/diag_clc1.aout" into clc1 card oc3 accesscard in slot 7 via SWITCH (409 6 bytes per dot)


Loading 467728 (0x72310) bytes starting at 0x10000000..................................... ...........................


...................................................Done


Loading 452064 (0x6e5e0) bytes starting at 0x10072310.............


................................................................


..................................Done


NOT clearing 63360 (0xf780) bytes of bss starting at 0x100e08f0!


fcload: slot 7: (clc1 card oc3 accesscard) starting SRAM image


fcload: slot 7: setting start address to 0x10000408


fcload: slot 7: releasing per-slot synchronization lock


>>>>>>>>>>>>>>>-----CONNECT----->>>>>>>>>>>>>>>


User 'root' (localhost) connected at Fri Sep  1 17:35:44 1995


>>>>>>>>>>>>>>>-----CONNECT----->>>>>>>>>>>>>>>


connected


 ******************************************


 * CLC1 Diag Monitor                      *


 * Revision 1.410 (Jul 27 1995)           *


 * Type  'help'  or  '?'  for help        *


 ******************************************


CLC1 Diag Monitor[07]->

Note You may need to press [Return] after you see the word "connected" in order to display the diagnostics banner and command prompt.

You can use the run command in any diagnostic package to run a preselected set of tests. See the section "Running Manufacturing Diagnostics" for detailed procedures on running tests.

If you need to return to CLI before completing your session with the diagnostics, you can toggle back and forth as follows: from the diagnostics, use the command ~q to get to CLI; from CLI, use connect <slot#> diagnostic to return to the diagnostics. Be sure to use the exit command to exit from the diagnostics when your session is finished.

For information on diagnostics commands, refer to the "Command Reference" section at the end of this chapter.

Running Manufacturing Diagnostics

Read this section for information on running manufacturing diagnostics. The first subsection, "Running Sets of Tests," applies to all of the test procedures that follow it.

Running Sets of Tests

In each of the diagnostics packages, commands are provided to run preselected sets of tests:

run
run executes a set of tests that have been designed to run quickly and safely on a system that is operating. The tests omitted by run are as follows:
- In NP and LSC diagnostics: long-running memory tests, tests that require looping plugs, switch interface tests and tests that check the disk drives
- In PLC and CLC diagnostics: long-running memory tests and tests that require looping plugs
- In MSC diagnostics: tests that require looping plugs

Note that if you use the sel or dsel commands, the tests executed by run may change. run executes tests that are currently selected; the test set outlined here is selected by default, but you can change it.

Approximate run times for run are as follows:

NP diagnostics: 7 minutes
LSC diagnostics: 12 minutes
MSC diagnostics: 57 minutes
PLC diagnostics: 9 minutes
CLC diagnostics: 8 minutes

arun

arun selects every test in the test package and runs it once. Note that arun includes some tests that you might not wish to run routinely (such as loopback tests, which require looping plugs, switch interface tests that send data to the switch card, and time-consuming memory tests). Do not use arun if the system you're testing is operating; use the appropriate procedure from the "Test Notes" section to disable the system first.

_0, which is a macro, runs a larger set of tests than run does; however, it does not run loopback tests or switch interface tests that send data to the switch card. Therefore, _0 can be run while a system is operating. Note that _0 is not available in CLC or PLC diagnostics.

Approximate run times for _0 are as follows:

NP diagnostics: 3 hours, 10 minutes
LSC diagnostics: 1 hour
MSC diagnostics: 57 minutes

_1, also a macro, is identical to _0 except that it does run switch interface tests, and is therefore not suited to use in a system that's operating. Note that _1 is not available in CLC or PLC diagnostics. (See the section "Macros" for more information on creating your own macros.)

NP Test Procedure

Use this procedure to run diagnostics on an NP card. It assumes that you have already loaded the diagnostics onto the card, as described in the section "Loading Manufacturing Diagnostics."

Step 1 At the prompt, type run or _0 to run a set of tests. (run is quicker.) As the tests run, the system displays the name of each test and a pass or fail indication, as shown below. (Depending on your configuration, some tests may display as "not run." This is not a problem.)

Note The screens that follow use the arun command in order to display a complete list of tests. It is recommended that you use _0 or run instead.

Figure 2-1 : NP diagnostics output.

Figure 2-2 : NP diagnostics output, continued.

Figure 2-3 : NP diagnostics output, concluded.

Note See the section "NP Tests with Special Requirements" for notes on tests with special requirements such as looping plugs.

Step 2 To run or rerun a particular test or group of tests, you can use the run command in conjunction with test numbers. For example:


diags>


run 5-15

(To display a list of tests and test numbers, use the lst all command.)

Step 3 The status command displays a message giving the status of diagnostic tests. Use status fail to get information only on tests that have failed.

Step 4 For explanations of the error codes used in the status display, use the help command in conjunction with the number of the test in question. For example,


diags>


help 10

Note If you need to return to CLI before completing your session with the diagnostics, you can toggle back and forth using the command ~. to get to CLI and connect <slot#> diagnostic to return to the diagnostics. Be sure to exit from the diagnostics when your session is finished.

Step 5 If the card passes the diagnostics, return the card to active mode. First exit from the diagnostics:


diags>


exit

Note If you're running diagnostics on an active NP, the exit command has no effect; you must reset the NP. You can either press the reset button on the front of the card, or type

`.

, then reset <slot#> to reset the NP, then connect <slot#> to reconnect to the NP. Replace <slot#> with the slot number of the card you were testing.

Step 6 When the login prompt appears, log into the node, enter CLI's protected mode, and use the set command as shown below to reset the card's status to active. Replace <slot#> with the slot number of the card you were testing.


*cli>


set card <slot#> active

How to Proceed

If any tests fail, replace the card being tested. Replacement procedures appear in the chapter "Replacing FRUs."

If all tests pass but you're still experiencing a problem, test the other cards in the chassis. Replace any cards that fail diagnostics. If the problem persists, investigate causes outside the LightStream hardware, including leased lines and edge devices.

LSC Test Procedure

Use this procedure to run diagnostics on a low-speed line card. It assumes that you have already loaded the diagnostics onto the card, as described in the section "Loading Manufacturing Diagnostics."

Note The screens that follow use the arun command in order to display a complete list of tests. It is recommended that you use _0 or run instead.

Figure 2-4 : Low-speed line card diagnostics output.

Figure 2-5 : Low-speed line card diagnostics output, continued.

Figure 2-6 : Low-speed line card diagnostics output, concluded.

Note Tests flagged in the list above with (L) require looping plugs. See the section "LSC Tests with Special Requirements" for details on tests that have special requirements.

Step 2 To run or rerun a particular test or group of tests, you can use the run command in conjunction with test numbers. For example:


diags>


run 5-15

(To display a list of tests and test numbers, use the lst all command.)

Step 3 The status command displays a message giving the status of diagnostic tests. Use status fail to get information only on tests that have failed.

Step 4 For explanations of the error codes used in the status display, use the help command in conjunction with the number of the test in question. For example,


diags>


help 10

Step 5 If the card passes the diagnostics, return the card to active mode. First exit from the diagnostics:


diags>


exit

Step 6 When the login prompt appears, log into the node, enter CLI's protected mode, and use the set command as shown below to reset the card's status to active. Replace <slot#> with the slot number of the card you were testing.


*cli>


set card <slot#> active

How to Proceed

If any tests fail you may need to replace either the line card being tested or its access card. (Replacement procedures appear in the chapter "Replacing FRUs.") Look at the numbers of the tests that failed to determine which card to replace:

Replace the line card if any test fails in the ranges 1 - 40, 52 - 78, and 80 - 118.

Note Tests 111-118 normally fail if you run them in an operating system using test -m; this failure does not indicate a problem and should be ignored.

Replace the access card if tests 41 - 51 or 79 fail.

Note Tests 43, 46 and 50 pass only when looping plugs are installed; disable or disregard them when testing without looping plugs.

MSC Test Procedure

Use this procedure to run diagnostics on a medium-speed line card. It assumes that you have already loaded the diagnostics onto the card, as described in the section "Loading Manufacturing Diagnostics."

Step 1 At the prompt, type run or _0 to run a set of tests. (run is preferred.) As the tests run, the system displays the name of each test and a pass or fail indication, as shown below. (Depending on your configuration, some tests may display as "not run." This is not a problem.)

Note The screens that follow use the arun command in order to display a complete list of tests. It is recommended that you use _0 or run instead.

Figure 2-7 : Medium-speed line card diagnostics output.

Figure 2-8 : Medium-speed line card diagnostics output, continued.

Figure 2-9 : Medium-speed line card diagnostics output, concluded.

Note See the section "MSC Tests with Special Requirements" for notes on tests with special requirements.

Step 2 To run or rerun a particular test or group of tests, you can use the run command in conjunction with test numbers. For example:


diags>


run 5-15

(To display a list of tests and test numbers, use the lst all command.)

Step 3 The status command displays a message giving the status of diagnostic tests. Use status fail to get information only on tests that have failed.

Step 4 For explanations of the error codes used in the status display, use the help command in conjunction with the number of the test in question. For example,


diags>


help 10

Step 5 If the card passes the diagnostics, return the card to active mode. First exit from the diagnostics:


diags>


exit


*cli>


set card <slot#> active

How to Proceed

Replace the line card if any test from 1 to 80 fails.

Note Tests 70 - 80 normally fail if you run them in an operating system using test -m; this failure does not indicate a problem and should be ignored.

Replace the access card if any test from 81 to 95 fails.

Note Test 95 passes only on the E3 access card; disable or disregard it when testing a T3 card. Tests 93 and 94 pass only when looping plugs are installed; disable or disregard them when testing without looping plugs.

PLC Test Procedure

Use this procedure to run diagnostics on a packet line card. It assumes that you have already loaded the diagnostics onto the card, as described in the section "Loading Manufacturing Diagnostics."

When they are loaded, the PLC diagnostics determine which type of access card is installed with the line card under test. Tests appropriate for the access card are enabled. You can use the access command, described in the section "Command Reference," to display the type of the access card.

Step 1 At the prompt, type run to run a set of tests. (See the section "Running Sets of Tests" for information on run.) As the tests run, the system displays the name of each test and a pass or fail indication, as shown below. (Depending on your configuration, some tests may display as "not run." This is not a problem.)


PLC1 Diag Monitor[08]-> run


 01          CP_Flash_Checksum_Test                   PASSED


 02          EEPROM_Checksum_Tests                    PASSED


 03          CP_DRAM_Tests                            PASSED


 04          CP_Parity_Test                           PASSED


 05          CP_Parity_Buffer_Test                    PASSED


 06          CP_Parity_DRAM_Test                      PASSED


 07          CP_PDBL_SRAM_Tests                       PASSED


 08          TSU_NQP_uStore_Memory_Tests              PASSED


 09          TSU_DQP_uStore_Memory_Tests              PASSED


 10          TSU_Internal_Timer_SRAM_Tests            PASSED


 11          TSU_Internal_CellFifo_SRAM_Tests         PASSED


 12          FSU_OSMC_uStore_Memory_Tests             PASSED


 13          FSU_ISMC_uStore_Memory_Tests             PASSED


 14          TLU_TLP_uStore_Memory_Tests              PASSED


 15          TLU_RP_uStore_Memory_Tests               PASSED


 16          FLU_FLP_uStore_Memory_Tests              PASSED


 17          FLU_ALF_uStore_Memory_Tests              PASSED


 18          TSU_Register_Walking_1s_and_0s_Test      PASSED


 19          FSU_Register_Walking_1s_and_0s_Test      PASSED


 20          TLU_Register_Walking_1s_and_0s_Test      PASSED


 21          FLU_Register_Walking_1s_and_0s_Test      PASSED


 22          TSU_uDiagnostic_Tests                    PASSED


 23          FSU_uDiagnostic_Tests                    PASSED


 24          TLU_uDiagnostic_Tests                    PASSED


 25          FLU_uDiagnostic_Tests                    PASSED


 26          FSU_RealTimeClock_Test                   PASSED


 27          FSU_IntervalTimer_Test                   PASSED


 28          TLU_HoldoffTimer_Test                    PASSED


 29          TCS_NMI_Test                             PASSED


 30          TSU_Internal_ScratchPad_SRAM_Tests       PASSED


 31          TSU_External_CellBuffer_DRAM_Tests       PASSED


 32          TSU_External_Control_DRAM_Tests          PASSED


 33          FSU_Internal_SRAM_Tests                  PASSED


 34          FSU_External_LRIC_SRAM_Tests             PASSED


 35          FSU_External_CRIC_DRAM_Tests             PASSED


 36          TLU_External_DRAM_Tests                  PASSED


 37          FLU_External_ParseGraph_SRAM_Tests       PASSED


 38          FLU_External_Protocol_DRAM_Tests         PASSED


 39          TSU_Functional_Register_Tests            PASSED


 40          FSU_Functional_Register_Tests            PASSED


 41          TLU_Functional_Register_Tests            PASSED


 42          FLU_Functional_Register_Tests            PASSED


 43          TSU_FSU_SWA_External_Lpbk_Test           PASSED


 44          TSU_FSU_SWA_Internal_Lpbk_A_Test         PASSED


 45          TSU_FSU_SWA_Internal_Lpbk_B_Test         PASSED


 46          TSU_FSU_SWB_External_Lpbk_Test           PASSED


 47          TSU_FSU_SWB_Internal_Lpbk_B_Test         PASSED


 48          TSU_FSU_SWB_Internal_Lpbk_A_Test         PASSED


 49          TSU_FSU_MultiCast_Internal_Lpbk_Test     PASSED


 50          TSU_FSU_Smoothing_Internal_Lpbk_Test     PASSED


 51          TSU_FSU_RATO_Internal_Lpbk_Test          PASSED


 52          TSU_TLU_Internal_Lpbk_Test               PASSED


 53          FLU_FSU_Internal_Lpbk_Test               PASSED


 54          FLU_TLU_Internal_Lpbk_Test               PASSED


 55          FDDI_Access_Card_Tests                   PASSED


 55          Ethernet_Access_Card_Tests               PASSED


 55          Cemac_Tests                              PASSED


PLC1 Diag Monitor[08]->

Note See the section "PLC Tests with Special Requirements" for notes on tests with special requirements.

Step 2 To run or rerun a particular test or group of tests, you can use the run command in conjunction with test numbers. For example:


diags>


run 5-15

(To display a list of tests and test numbers, use the lst all command.)

Step 3 The status command displays a message giving the status of diagnostic tests. Use status fail to get information only on tests that have failed.

Step 4 For explanations of the error codes used in the status display, use the help command in conjunction with the number of the test in question. For example,


diags>


help 10

Note If you need to return to CLI before completing your session with the diagnostics, you can toggle back and forth using the commands ~. to get to CLI and connect <slot#> diagnostic to return to the diagnostics. Be sure to exit from the diagnostics when your session is finished.

Step 5 If the card passes the diagnostics, return the card to active mode. First exit from the diagnostics:


diags>


exit


*cli>


set card <slot#> active

How to Proceed

If test 55 (or any of its subtests, 55.01 through 55.15) fails, this indicates a failure in the access card. In this case replace the access card, as described in the chapter "Replacing FRUs."

If any other tests fail, replace the card being tested. Replacement procedures appear in the chapter "Replacing FRUs."

CLC Test Procedure

Use this procedure to run diagnostics on a cell line card. It assumes that you have already loaded the diagnostics onto the card, as described in the section "Loading Manufacturing Diagnostics."

When they are loaded, the CLC diagnostics determine which type of access card is installed with the line card under test. Tests appropriate for the access card are enabled. You can use the access command, described in the section "Command Reference," to display the type of the access card.

Step 1 At the prompt, type run to run a set of tests. (See the section "Running Sets of Tests" for the information on run.) As the tests run, the system displays the name of each test and a pass or fail indication, as shown below. (Depending on your configuration, some tests may display as "not run." This is not a problem.)


CLC1 Diag Monitor[07]-> run


 01          CP_Flash_Checksum_Test                   PASSED


 02          EEPROM_Checksum_Tests                    PASSED


 03          CP_DRAM_Tests                            PASSED


 04          CP_Parity_Test                           PASSED


 05          CP_Parity_Buffer_Test                    PASSED


 06          CP_Parity_DRAM_Test                      PASSED


 07          TSU_NQP_uStore_Memory_Tests              PASSED


 08          TSU_DQP_uStore_Memory_Tests              PASSED


 09          TSU_Internal_Timer_SRAM_Tests            PASSED


 10          TSU_Internal_CellFifo_SRAM_Tests         PASSED


 11          TSU_B_NQP_uStore_Memory_Tests            PASSED


 12          TSU_B_DQP_uStore_Memory_Tests            PASSED


 13          TSU_B_Internal_Timer_SRAM_Tests          PASSED


 14          TSU_B_Internal_CellFifo_SRAM_Tests       PASSED


 15          FSU_OSMC_uStore_Memory_Tests             PASSED


 16          FSU_ISMC_uStore_Memory_Tests             PASSED


 17          TSU_Register_Walking_1s_and_0s_Test      PASSED


 18          TSU_B_Register_Walking_1s_and_0s_Test    PASSED


 19          FSU_Register_Walking_1s_and_0s_Test      PASSED


 20          TSU_uDiagnostic_Tests                    PASSED


 21          TSU_B_uDiagnostic_Tests                  PASSED


 22          FSU_uDiagnostic_Tests                    PASSED


 23          FSU_RealTimeClock_Test                   PASSED


 24          FSU_IntervalTimer_Test                   PASSED


 25          TCS_NMI_Test                             PASSED


 26          TSU_Internal_ScratchPad_SRAM_Tests       PASSED


 27          TSU_External_CellBuffer_DRAM_Tests       PASSED


 28          TSU_External_Control_DRAM_Tests          PASSED


 29          TSU_B_Internal_ScratchPad_SRAM_Tests     PASSED


 30          TSU_B_External_CellBuffer_DRAM_Tests     PASSED


 31          FSU_Internal_SRAM_Tests                  PASSED


 32          FSU_External_LRIC_SRAM_Tests             PASSED


 33          FSU_External_CRIC_DRAM_Tests             PASSED


 34          TSU_Functional_Register_Tests            PASSED


 35          TSU_B_Functional_Register_Tests          PASSED


 36          FSU_Functional_Register_Tests            PASSED


 37          Cell_lpbk_Tsu_A_Ext_SWA_Test             PASSED


 38          Cell_lpbk_Tsu_A_Ext_SWB_Test             PASSED


 39          Cell_lpbk_Tsu_B_Ext_SWA_Test             PASSED


 40          Cell_lpbk_Tsu_B_Ext_SWB_Test             PASSED


 41          Cell_lpbk_Tsu_A_Int_SWA_Test             PASSED


 42          Cell_lpbk_Tsu_A_Int_SWB_Test             PASSED


 43          Cell_lpbk_Tsu_B_Int_SWA_Test             PASSED


 44          Cell_lpbk_Tsu_B_Int_SWB_Test             PASSED


 45          Cell_lpbk_Tsu_A_Int_SWA_FSU_B_Test       PASSED


 46          Cell_lpbk_Tsu_A_Int_SWB_FSU_A_Test       PASSED


 47          RATO_lpbk_Tsu_A_Int_SWA_Test             PASSED


 48          Metering__Tsu_A_Int_SWA_Test             PASSED


 49          OC3_Access_Card_Tests                    PASSED


49          T3_Access_Card_Tests                      PASSED


49          E3_Access_Card_Tests                      PASSED


CLC1 Diag Monitor[07]->

Note See the section "CLC Tests with Special Requirements" for notes on tests with special requirements.

Step 2 To run or rerun a particular test or group of tests, you can use the run command in conjunction with test numbers. For example:


diags>


run 5-15

(To display a list of tests and test numbers, use the lst all command.)

Step 3 The status command displays a message giving the status of diagnostic tests. Use status fail to get information only on tests that have failed.

Step 4 For explanations of the error codes used in the status display, use the help command in conjunction with the number of the test in question. For example,


diags>


help 10

Step 5 If the card passes the diagnostics, return the card to active mode. First exit from the diagnostics:


diags>


exit


*cli>


set card <slot#> active

How to Proceed

If test 51 (or any of its subtests) fails, this indicates a failure in the access card. In this case replace the access card, as described in the chapter "Replacing FRUs."

If any other tests fail, replace the card being tested. Replacement procedures appear in the chapter "Replacing FRUs."

Test Notes

This section lists special requirements for tests in each diagnostic package.

NP Tests with Special Requirements

Tests that Write to the Hard Disk

The NP tests listed below write data to the hard disk. These tests are disabled by default; you must explicitly enable them in order to run them. Unless you are testing a new disk drive or have reason to suspect a fault in your hard disk, it's recommended that you avoid running these tests:

43 -->  Hard_Drive_Self_Test
44 -->  Hard_Drive_Seek_Test
45 -->  Hard_Drive_Write_Read_Test
46 -->  Hard_Drive_Write_Read_Interrupt_Tst

Tests that Send Data to the Switch Card

The NP tests listed below send data through the switch card. Take the LightStream 2020 node off line before running these tests, as described in the procedure following the list of tests. Do not run them on a system that's passing traffic. (If the node is running, these tests may fail when they would otherwise pass. In addition, the "bad" data passed to the switch by the tests may cause traps.)

78 --> CMP_SL_Push_Cell_SOB_Test

80 --> Raw_Cell_External_Loopback_Test

82 --> Data_Gram_External_Loopback_Test

83 --> Data_Gram_Metered_Loopback_Test

84 --> Multi_DataGram_Metered_Loopback_Test

85 --> Chained_Data_Gram_Loopback_Test

86 --> Iso_Sngle_Cast_Loopback_Test

87 --> Multi_Cast_Data_Gram_Loopback_Test

88 --> Comp_Data_Gram_Loopback_Test

89 --> Multi_Cast_IsoLoopback_Test

90 --> FSU_RATO_Test

91 --> FSU_fast_dropper_Test

92 --> FSU_VRAM_mem_Test

93 --> FSU_VRAM_refresh_Test

If you wish to run these tests, use the procedure below to disable the system and all the other cards in the chassis. This prevents the other cards from sending packets to the card under test that cause these tests to fail even when no problem exists.

Step 1 Log in as root or fldsup on the system you want to test.

Step 2 At the bash prompt, use the command reboot -n to bring down the NP. (Bring down both if there are two.)

Step 3 Type `. to get a TCS hub prompt.

Step 4 From the TCS hub, type reset <slot#> to reset each slot that has a line card in it. (Don't reset the switch card or NP slots.)

Step 5 Type connect <slot#> to return to the NP, then press [Return] to display a menu of boot options.

Step 6 At the menu's Option prompt, enter 6, as shown below.


Network Processor bootstrap (version 1.3: Sep 13 1993)

        1 - Boot ATM switch application

        2 - Begin full installation with boot from floppy disk

        3 - List contents of hard disk root directory

        4 - List contents of floppy disk root directory

        5 - Boot system single-user

        6 - Escape to full set of bootstrap options

        7 - Extended help

Option>

Step 7 The system displays the following message and a boot prompt. Enter the string shown below to load the NP diagnostics.


Network Processor bootstrap (version 1.3: Sep 13 1993)

Enter "help" for documentation on extended bootstrap options

Default: (sd0a)lynx.os



Boot:


(sd0b)diag/diag_np1.aout

Step 8 When the diagnostics finish loading, you can select and run the desired tests.

Tests that Require Looping Plugs

The NP tests listed below will fail if they are run on a system that does not have looping plugs installed on the NP Ethernet port and Diag2 port. (In field diagnostics, these tests are invoked when you use the test command's -l switch.) If you do not have looping plugs installed, it's recommended that you avoid running these tests:

13 --> Ethernet_External_Loopback_Test

14 --> Ethernet_External_Chaining

33 --> SCC_ChB_External_Loopback_Tst

Tests that Require a Scratch Diskette

The NP tests listed below will fail if they are run on a system that does not have writable diskettes in its floppy disk drives. If you do not have a scratch diskette in each floppy drive, it's recommended that you avoid running these tests:

47 -->  FLoppy_Drive_Self_Test
48 -->  Floppy_Drive_Seek_Test
49 -->  Floppy_Drive_Write_Read_Test

Long-Running Memory Tests

The NP memory tests listed below take longer than one minute to run. (Some take many minutes.) Avoiding these tests saves time. (In field diagnostics, these tests are invoked when you use the test command's -x switch.)

08 --> Address_Independence_Memory_Test

09 --> MarchingBit_Memory_Test

93 --> FSU_VRAM_refresh_Test

BB-RAM Clock Test

The NP diagnostics include tests for the battery-backed RAM clock that keeps time for the whole system. If the tests fail, you will be prompted to reset the clock; you must supply the current time and date. If the system under test has two NPs, make certain that their clocks agree to within one minute. (If the clocks don't agree, file consistency problems between the two NPs may result.)

LSC Tests with Special Requirements

Tests that Send Data to the Switch Card

The low-speed line card tests listed below send data through the switch card. (In field diagnostics, these tests are invoked when you use the test command's -s switch.) Take the LightStream 2020 node off line before running these tests. Do not run them on a system that's passing traffic. (If the node is running, these tests may fail when they would otherwise pass. In addition, the "bad" data passed to the switch by the tests may cause traps.)

111 --> DataGram_SingleCast__External_Lpbk_Test

112 --> DataGram_MultiCast___External_Lpbk_Test

113 --> DataGram_Metered_____External_Lpbk_Test

114 --> DataGram_MtCast_Metd_External_Lpbk_Test

115 --> Isochronous_SinglCst_External_Lpbk_Test

116 --> Isochronous_MultiCst_External_Lpbk_Test

117 --> FSU_Dropped_Cell_Test_(PIT)

118 --> FSU_RATO_Test_(PIT)

If you wish to run these tests, use the procedure below to disable the system and all the other cards in the chassis, and then to load the diagnostics into the card you wish to test. This procedure prevents the other cards from sending packets to the card under test that cause these tests to fail even when no problem exists.

Step 1 Log in as root or fldsup on the system you want to test.

Step 2 At the bash prompt, enter the command reboot -n to bring down the NP. If your system has two NPs, do the following to reboot the second one:

Type `. to get a TCS hub prompt.
Type connect <slot#> to get to the other NP, replacing <slot#> with the number of the NP's slot in the chassis.
Log in to the NP as root or fldsup.
At the bash prompt, enter the command reboot -n to bring down the NP.

Step 3 Type `. to get a TCS hub prompt.

Step 4 From the TCS hub, type reset <slot#> to reset each slot that has a line card in it. (Don't reset the switch card or NP slots.)

Step 5 Type connect <slot#> to return to the NP, then press [Return] to display a menu of boot options.

Step 6 At the menu's Option prompt, enter 6, as shown below.


Network Processor bootstrap (version 1.3: Sep 13 1993)

        1 - Boot ATM switch application

        2 - Begin full installation with boot from floppy disk

        3 - List contents of hard disk root directory

        4 - List contents of floppy disk root directory

        5 - Boot system single-user

        6 - Escape to full set of bootstrap options

        7 - Extended help

Option>

Step 7 The system displays the following message and a boot prompt. Enter the string shown below to load the system monitor, which you will use to load the diagnostics.


Network Processor bootstrap (version 1.3: Sep 13 1993)

Enter "help" for documentation on extended bootstrap options

Default: (sd0a)lynx.os



Boot:


(sd0b)diag/sys_np1.aout

Step 8 When the system monitor finishes loading, you'll see an identifying message and a prompt, as shown below. To load diagnostics, type the command shown, replacing <slot#> with the number of the card you want to test.


 ******************************************

 * System Diagnostic Debug Monitor        *

 * Revision 1.258 (Jun 15 1994)           *

 * Type  'help'  or  '?'  for help        *

 ******************************************




System Monitor->


load <slot#> (sd0b)diag/diag_ls1.aout

Step 9 Wait about 5 minutes for the diagnostics to load. Then type `. to return to the TCS hub.

Step 10 At the TCS hub prompt, use the command connect <slot#> to connect to the card you just loaded.

Step 11 Run the desired tests.

Tests that Require Looping Plugs

The LSC tests listed below will fail if they are run on a system that does not have looping plugs installed on the I/O ports. (In field diagnostics, these tests are invoked when you use the test command's -l switch.) If you do not have looping plugs installed, it's recommended that you avoid running these tests:

08 --> mc68340_UART_B_External_Loopback_Tst(L)

43 --> CP_LineChip_External_Loopback_Test (L)

46 --> PaddleCard_Octart_External_Lpbk_Test(L)

50 --> PaddleCard_Extern_Clock_Monitor_Test(L)

Long-Running Memory Tests

The low-speed line card memory tests listed below take longer than one minute to run. (Some take many minutes.) Avoiding these tests saves time. (In field diagnostics, these tests are invoked when you use the test command's -x switch.)

09 --> CP_to_DRAM_AddrBus_Indep_Test

15 --> CP_to_DRAM_Marching_1s_Test

17 --> CP_to_SharedMem_AddrBus_Indep_Test

23 --> CP_to_SharedMem_Marching_1s_Test

66 --> PP_to_SharedMem_DataBus_WalkingBit_Test

69 --> PP_to_SharedMem_Marching_1s_Test

MSC Tests with Special Requirements

Tests that Send Data to the Switch Card

The medium-speed line card tests listed below send data through the switch card. (In field diagnostics, these tests are invoked when you use the test command's -s switch.) Take the LightStream node off line before running these tests. Do not run them on a system that's passing traffic. (If the node is running, these tests may fail when they would otherwise pass. In addition, the "bad" data passed to the switch by the tests may cause traps.)

70 --> SCastDgm_SWA_Cntrl__Fifo_External_Lpbk

71 --> MCastDgm_SWA_Cntrl__Fifo_External_Lpbk

72 --> SCastSch_SWA_Cntrl__Fifo_External_Lpbk

73 --> MCastSch_SWA_Cntrl__Fifo_External_Lpbk

74 --> SCastDgm_SWB_Cntrl__Fifo_External_Lpbk

75 --> MCastDgm_SWB_Cntrl__Fifo_External_Lpbk

76 --> SCastSch_SWB_Cntrl__Fifo_External_Lpbk

77 --> MCastSch_SWB_Cntrl__Fifo_External_Lpbk

79 --> FSU_Payload_LRC_Error_Test

78 --> FSU_Header_LRC_Error_Test

80 --> FSU_VRAM_Refresh_Test

Step 1 Log in as root or fldsup on the system you want to test.

Step 2 At the bash prompt, enter the command reboot -n to bring down the NP. If your system has two NPs, do the following to reboot the second one:

Type `. to get a TCS hub prompt.
Type connect <slot#> to get to the other NP, replacing <slot#> with the number of the NP's slot in the chassis.
Log in to the NP as root or fldsup.
At the bash prompt, enter the command reboot -n to bring down the NP.

Step 3 Type `. to get a TCS hub prompt.

Step 4 From the TCS hub, type reset <slot#> to reset each slot that has a line card in it. (Don't reset the switch card or NP slots.)

Step 5 Type connect <slot#> to return to the NP, then press [Return] to display a menu of boot options.

Step 6 At the menu's Option prompt, enter 6, as shown below.


Network Processor bootstrap (version 1.3: Sep 13 1993)

        1 - Boot ATM switch application

        2 - Begin full installation with boot from floppy disk

        3 - List contents of hard disk root directory

        4 - List contents of floppy disk root directory

        5 - Boot system single-user

        6 - Escape to full set of bootstrap options

        7 - Extended help

Option>

Step 7 The system displays the following message and a boot prompt. Enter the string shown below to load the system monitor, which you will use to load the diagnostics.


Network Processor bootstrap (version 1.3: Sep 13 1993)

Enter "help" for documentation on extended bootstrap options

Default: (sd0a)lynx.os



Boot:


(sd0b)diag/sys_np1.aout


 ******************************************

 * System Diagnostic Debug Monitor        *

 * Revision 1.258 (Jun 15 1994)           *

 * Type  'help'  or  '?'  for help        *

 ******************************************




System Monitor->


load <slot#> (sd0b)diag/diag_ms1.aout

Step 9 Wait about 5 minutes for the diagnostics to load. Then type `. to return to the TCS hub.

Step 10 At the TCS hub prompt, use the command connect <slot#> to connect to the card you just loaded.

Step 11 Run the desired tests.

Tests that Require Looping Plugs

The MSC tests listed below will fail if they are run on a system that does not have looping plugs installed on the I/O ports. (In field diagnostics, these tests are invoked when you use the test command's -l switch.) If you do not have looping plugs installed, it's recommended that you avoid running these tests:


93 --> T3/E3_PLPP_TrunkA_Fifo_External_Lpbk

94 --> T3/E3_PLPP_TrunkB_Fifo_External_Lpbk

Long-Running Memory Tests

The medium-speed line card memory tests listed below take longer than one minute to run. (Some take many minutes.) Avoiding these tests saves time. (In field diagnostics, these tests are invoked when you use the test command's -x switch.)

14 --> CP_to_DRAM_AddrBus_Indep_Test

15 --> CP_to_DRAM_Marching_1s_Test

24 --> CP_to_TSU_CntrlRAM_AddrBus_Indep_Test

25 --> CP_to_TSU_CntrlRAM_Marching_1s_Test

54 --> CTP_Control_Ram_StuckBit_Test

56 --> CTP_Control_Ram_DataBus_WalkingBit_Tst

57 --> CTP_Control_Ram_RamData_Pattern_Test

61 --> CTP_Cell_Buffer_RamData_Pattern_Test

80 --> FSU_VRAM_Rrefresh_Test

PLC Tests with Special Requirements

Tests that Send Data to the Switch Card

The packet line card tests listed below send data through the switch card. (In field diagnostics, these tests are invoked when you use the test command's -s switch.) Take the LightStream 2020 node off line before running these tests. Do not run them on a system that's passing traffic. (If the node is running, these tests may fail when they would otherwise pass. In addition, the "bad" data passed to the switch by the tests may cause traps.)

43          TSU_FSU_SWA_External_Lpbk_Test

46          TSU_FSU_SWB_External_Lpbk_Test

Step 1 Log in as root or fldsup on the system you want to test.

Step 2 At the bash prompt, enter the command reboot -n to bring down the NP. If your system has two NPs, do the following to reboot the second one:

Type `. to get a TCS hub prompt.
Type connect <slot#> to get to the other NP, replacing <slot#> with the number of the NP's slot in the chassis.
Log in to the NP as root or fldsup.
At the bash prompt, enter the command reboot -n to bring down the NP.

Step 3 Type `. to get a TCS hub prompt.

Step 4 From the TCS hub, type reset <slot#> to reset each slot that has a line card in it. (Don't reset the switch card or NP slots.)

Step 5 Type connect <slot#> to return to the NP, then press [Return] to display a menu of boot options.

Step 6 At the menu's Option prompt, enter 6, as shown below.


Network Processor bootstrap (version 1.3: Sep 13 1993)

        1 - Boot ATM switch application

        2 - Begin full installation with boot from floppy disk

        3 - List contents of hard disk root directory

        4 - List contents of floppy disk root directory

        5 - Boot system single-user

        6 - Escape to full set of bootstrap options

        7 - Extended help

Option>

Step 7 The system displays the following message and a boot prompt. Enter the string shown below to load the system monitor, which you will use to load the diagnostics.


Network Processor bootstrap (version 1.3: Sep 13 1993)

Enter "help" for documentation on extended bootstrap options

Default: (sd0a)lynx.os



Boot:


(sd0b)diag/sys_np1.aout


 ******************************************

 * System Diagnostic Debug Monitor        *

 * Revision 1.258 (Jun 15 1994)           *

 * Type  'help'  or  '?'  for help        *

 ******************************************




System Monitor->


load <slot#> (sd0b)diag/diag_plc1.aout

Step 9 Wait about 5 minutes for the diagnostics to load. Then type `. to return to the TCS hub.

Step 10 At the TCS hub prompt, use the command connect <slot#> to connect to the card you just loaded.

Step 11 Run the desired tests.

Tests that Require Looping Plugs

The PLC tests listed in this section will fail if they are run on a system that does not have looping cables installed on the I/O ports. (In field diagnostics, these tests are invoked when you use the test command's -l switch.) The individual tests vary depending on whether your PLC is paired with an FDDI access card, an Ethernet access card, a fiber Ethernet access card, or a CEMAC. If you do not have looping cables installed, it's recommended that you avoid running these tests.

FDDI

55.06       Serial_Clk_Loopback_Test(64)

55.07       Serial_Clk_Loopback_Test(1520)

55.08       Serial_CSU_DSU_Loopback_Test

55.11       FDDI_Loopback_Test

Ethernet

55.06       Serial_Clk_Loopback_Test(64)

55.07       Serial_Clk_Loopback_Test(1520)

55.08       Serial_CSU_DSU_Loopback_Test

55.11       Ethernet_Bus_External_Test

55.14       Ethernet_XC_E_Loopback_Test

CEMAC


55.06       Serial_Clk_Loopback_Test(64)

55.07       Serial_Clk_Loopback_Test(1520)

55.08       Serial_CSU_DSU_Loopback_Test

If you choose to run these tests, use looping cables to connect the ports on the Ethernet card to each other in the following manner:

connect port 0 to port 1
connect port 2 to port 3
connect port 4 to port 5
connect port 6 to port 7

Note This list uses the port numbers as shown on the Ethernet card, but the diagnostics number the ports 1 through 8 instead of 0 through 7.

Long-Running Memory Tests

The packet line card memory tests listed below take longer than one minute to run. (Some take many minutes.) Avoiding these tests saves time. (In field diagnostics, these tests are invoked when you use the test command's -x switch.)

03.01       CP_to_DRAM_AddrBus_Indep_Test

03.04       CP_to_DRAM_DataBus_WalkingBit_Test

03.07       CP_to_DRAM_Marching_1s_Test

03.08       CP_to_DRAM_Refresh_Test

07.01       CP_to_PDBL_SRAM_AddrBus_Indep_Test

07.04       CP_to_PDBL_SRAM_DataBus_WalkingBit_Test

07.07       CP_to_PDBL_SRAM_Marching_1s_Test

22.12       TSU_NQP_RamTests

22.13       TSU_DQP_RamTests

23.13       FSU_ISMC_RamTests

23.14       FSU_OSMC_RamTests

24.08       TLU_RP_RamTests

24.09       TLU_TLP_RamTests

25.06       FLU_ALF_RamTests

31.01       TSU_CBuf_DRAM_AddrBus_Indep_Test

31.04       TSU_CBuf_DRAM_DataBus_WalkingBit_Test

31.07       TSU_CBuf_DRAM_Marching_1s_Test

32.01       TSU_Ctrl_DRAM_AddrBus_Indep_Test

32.04       TSU_Ctrl_DRAM_DataBus_WalkingBit_Test

32.07       TSU_Ctrl_DRAM_Marching_1s_Test

34.01       FSU_LRIC_SRAM_AddrBus_Indep_Test

34.04       FSU_LRIC_SRAM_DataBus_WalkingBit_Test

34.07       FSU_LRIC_SRAM_Marching_1s_Test

35.01       FSU_CRIC_DRAM_AddrBus_Indep_Test

35.04       FSU_CRIC_DRAM_DataBus_WalkingBit_Test

35.07       FSU_CRIC_DRAM_Marching_1s_Test

36.01       TLU_Ext_DRAM_AddrBus_Indep_Test

36.04       TLU_Ext_DRAM_DataBus_WalkingBit_Test

36.07       TLU_Ext_DRAM_Marching_1s_Test

37.01       FLU_Parse_SRAM_AddrBus_Indep_Test

37.04       FLU_Parse_DRAM_DataBus_WalkingBit_Test

37.07       FLU_Parse_DRAM_Marching_1s_Test

38.01       FLU_Proto_DRAM_AddrBus_Indep_Test

38.04       FLU_Proto_DRAM_DataBus_WalkingBit_Test

38.07       FLU_Proto_DRAM_Marching_1s_Test

CLC Tests with Special Requirements

Tests that Send Data to the Switch Card

The cell line card tests listed below send data through the switch card. (In field diagnostics, these tests are invoked when you use the test command's -s switch.) Take the LightStream 2020 node off line before running these tests. Do not run them on a system that's passing traffic. (If the node is running, these tests may fail when they would otherwise pass. In addition, the "bad" data passed to the switch by the tests may cause traps.)

36          Cell_lpbk_Tsu_A_Ext_SWA_Test

37          Cell_lpbk_Tsu_A_Ext_SWB_Test

38          Cell_lpbk_Tsu_B_Ext_SWA_Test

46          RATO_lpbk_Tsu_A_Ext_SWA_Test

47          Metering_lpbk_Tsu_A_Ext_SWA_Test

Step 1 Log in as root or fldsup on the system you want to test.

Step 2 At the bash prompt, enter the command reboot -n to bring down the NP. If your system has two NPs, do the following to reboot the second one:

Type `. to get a TCS hub prompt.
Type connect <slot#> to get to the other NP, replacing <slot#> with the number of the NP's slot in the chassis.
Log in to the NP as root or fldsup.
At the bash prompt, enter the command reboot -n to bring down the NP.

Step 3 Type `. to get a TCS hub prompt.

Step 4 From the TCS hub, type reset <slot#> to reset each slot that has a line card in it. (Don't reset the switch card or NP slots.)

Step 5 Type connect <slot#> to return to the NP, then press [Return] to display a menu of boot options.

Step 6 At the menu's Option prompt, enter 6, as shown below.


Network Processor bootstrap (version 1.3: Sep 13 1993)

        1 - Boot ATM switch application

        2 - Begin full installation with boot from floppy disk

        3 - List contents of hard disk root directory

        4 - List contents of floppy disk root directory

        5 - Boot system single-user

        6 - Escape to full set of bootstrap options

        7 - Extended help

Option>

Step 7 The system displays the following message and a boot prompt. Enter the string shown below to load the system monitor, which you will use to load the diagnostics.


Network Processor bootstrap (version 1.3: Sep 13 1993)

Enter "help" for documentation on extended bootstrap options

Default: (sd0a)lynx.os



Boot:


(sd0b)diag/sys_np1.aout


 ******************************************

 * System Diagnostic Debug Monitor        *

 * Revision 1.258 (Jun 15 1994)           *

 * Type  'help'  or  '?'  for help        *

 ******************************************




System Monitor->


load <slot#> (sd0b)diag/diag_clc1.aout

Step 9 Wait about 5 minutes for the diagnostics to load. Then type `. to return to the TCS hub.

Step 10 At the TCS hub prompt, use the command connect <slot#> to connect to the card you just loaded.

Step 11 Run the desired tests.

Tests that Require Looping Plugs

The CLC tests listed below will fail if they are run on a system that does not have looping plugs installed on the I/O ports. (In field diagnostics, these tests are invoked when you use the test command's -l switch.) If you do not have looping plugs installed, it's recommended that you avoid running these tests:

48.03       OC3_Port_Extrnl_Loopback_Test

48.06       OC3_Port_0_1_X_Cross_Test

48.07       OC3_Port_0_1_X_Cross_Test_2

48.03       T3_Port_Lim_Loopback_Test

Long-Running Memory Tests

The cell line card memory tests listed below take longer than one minute to run. (Some take many minutes.) Avoiding these tests saves time. (In field diagnostics, these tests are invoked when you use the test command's -x switch.)


03          CP_to_DRAM_AddrBus_Indep_Test

06          CP_to_DRAM_DataBus_WalkingBit_Test

09          CP_to_DRAM_Marching_1s_Test

10          CP_to_DRAM_Refresh_Test

26.13       FSU_ISMC_RamTests

26.14       FSU_OSMC_RamTests

27.12       TSU_NQP_RamTests

27.13       TSU_DQP_RamTests

28.12       TSU_B_NQP_RamTests

28.13       TSU_B_DQP_RamTests

29.01       TSU_CBuf_DRAM_AddrBus_Indep_Test

29.04       TSU_CBuf_DRAM_DataBus_WalkingBit_Test

29.07       TSU_CBuf_DRAM_Marching_1s_Test

30.01       TSU_Ctrl_DRAM_AddrBus_Indep_Test

30.04       TSU_Ctrl_DRAM_DataBus_WalkingBit_Test

30.07       TSU_Ctrl_DRAM_Marching_1s_Test

31.01       TSU_CBuf_DRAM_AddrBus_Indep_Test

31.04       TSU_CBuf_DRAM_DataBus_WalkingBit_Test

31.07       TSU_CBuf_DRAM_Marching_1s_Test

32.01       TSU_Ctrl_DRAM_AddrBus_Indep_Test

32.04       TSU_Ctrl_DRAM_DataBus_WalkingBit_Test

32.07       TSU_Ctrl_DRAM_Marching_1s_Test

34.01       FSU_LRIC_SRAM_AddrBus_Indep_Test

34.04       FSU_LRIC_SRAM_DataBus_WalkingBit_Test

34.07       FSU_LRIC_SRAM_Marching_1s_Test

35.01       FSU_CRIC_DRAM_AddrBus_Indep_Test

35.04       FSU_CRIC_DRAM_DataBus_WalkingBit_Test

35.07       FSU_CRIC_DRAM_Marching_1s_Test

Command Reference

This section alphabetically lists and describes selected commands that are available in LightStream 2020 hardware diagnostic packages. Many commands are available in all three packages; others are specific to one or two packages. Each entry lists the packages in which the command is available.

Note LightStream 2020 diagnostics contain many commands that are not listed in this section. Such commands are for use by support personnel only.

!

! <command>

Causes the specified command to loop indefinitely. For example, the arun command runs all tests once; !arun cycles through all the tests repeatedly until you stop the loop, or, if stop on fail mode is on, until a test fails.

Availability: all packages

?

? [<command>]

Without argument: Displays a list of available commands.
With argument: Displays information on the specified command.

Availability: all packages

access

In PLC diagnostics:


access [cemac | ethernet | fddi | fiberenet | serial]

In CLC diagnostics:


access [oc3 | t3 | e3 | t1e1]

With no argument, displays the type of access card installed with the line card under test. With an argument, forces activation of the access card tests for the access card type indicated.

Availability: PLC and CLC diags

arun

arun

Runs all tests once. Not recommended if you don't have looping plugs or if you are running diagnostics remotely, as this command runs tests that require looping plugs.

Availability: all packages

bb_battery

bb_battery

Checks the status of the battery for the NP's battery-backed RAM. A screen display tells you that the battery is OK, or that it's low. Note that the results of this command are valid only the first time the command is executed after powering up the NP. To get valid results again, you must power cycle the board.

Availability: NP diags

blink

blink [green | yellow | both] [1hz | 2hz | 4hz] [on | off]

In NP diags: Causes the green RDY LED and/or the yellow FLT LED on the NP bulkhead to blink, turn on, or turn off.

blink [on | off]

In PLC and CLC diags: Causes LNS OK LED on the bulkhead to blink (on) or not blink (off) during long-running tests. Blinking gives an indication that the tests are still running.

chprmpt

chprmpt <string>

Changes the diagnostics command prompt. Maximum prompt length is 30 characters.

Availability: all packages

cnt

cnt [<loop count>]

Specifies the count, or number of times the selected tests will be executed when you use the run command. Use cnt with no argument to display the current loop count.

Availability: all packages

dsel

dsel {all | <test#> | <test# range>}

Deselects all selected tests, a particular test, or a range of tests.

Availability: all packages

dsp_ver

dsp_ver

Displays the firmware revision levels of the switch interface daughterboard's PCP, CMP, and FSU digital signal processors.

Availability: NP diags

env

env

Displays the current test run environment as selected with the mod command.

Availability: all packages

execute

execute [<test#> | <test# range>] [<-switches>] [argument] [argument] [argument] 
[argument]

Runs selected tests (with no argument), or specified tests. The switches, which temporarily override the mode settings, are as follows:

-l Loops specified test or tests indefinitely; press any key to stop the loop
-s Stops looping if a test fails
-f Starts looping on a test that fails
-v Turns on verbose mode
-q Turns on quiet mode (that is, turns off verbose mode)

execute is the same as run and go.
Availability: all packages

You can also run tests using the execute or go commands, or by typing specific test numbers or ranges of numbers. (For example, type 22 to run test 22.) You can use the switches for the run command with test numbers as well. Thus, for example, these two commands both cause tests 22 through 24 to loop indefinitely:

run 22-24 -l

22-24 -l

Availability: all packages

exit

exit

Halts the diagnostics, resets the board, and transfers control to POST. (Same as quit.)

Availability: all packages

fl_format

fl_format

Formats the diskette in the floppy drive.

Availability: NP diags

fl_inq

fl_inq

Displays information on the floppy disk drive, including firmware revision level and model number.

Availability: NP diags

go

go [<test#> | <test# range>] [<-switches>] [argument] [argument] [argument] [argument]

Runs the specified test or range of tests. go is the same as execute and run.

Availability: all packages

help

help [<command> | <test#>]

Provides three kinds of help:

Without an argument, help lists all commands.
With a command as an argument (e.g. help go), help describes the syntax and purpose of the specified command.
With a test number as an argument (e.g. help 42), help describes the error codes used for that test in the display produced by the status command.

Availability: all packages

history

history

Displays the last 50 commands entered. This command is useful in conjunction with ^P, which you can use to yank previous commands from the history buffer.

Availability: all packages

jumpers

jumpers

Displays the following:

the current setting of the jumpers that determine whether the low-speed line card presents V.35 or RS-449 interfaces
the type of fantail connected to the LSC. Note, however, that an X.21 fantail will display as RS-449.

Availability: LSC diags

led

led [<on | off>] [<channel>]

Turns the channel LEDs on the line card bulkhead on or off. Without an argument, led flashes the LEDs in succession until you press any key to stop the test. led on turns all the LEDs on; led off turns them all off. In conjunction with the on/off argument, the channel argument lets you turn particular LEDs on or off. On medium-speed cards, the channels are 0 and 1; on low-speed cards, the channels are 0 - 7. The following command turns LED 0 on:

led on 0

Availability: LSC and MSC diags

loop

loop [<loopcount>]

Sets the loop counter to the specified number. When you use execute, go or run, the selected tests repeat, or loop, the specified number of times.

Availability: all packages

list
lst

l[i]st [all] [<test#> | <test# range>]

Lists selected tests (with no argument), all tests, a specific test, or a range of tests. (A range is expressed with a dash. For example, you might type lst 1-6.)

In PLC and CLC diagnostics, tests are numbered hierarchically using both decimal and whole numbers. Similar tests are grouped together under the same number. For example, all the access card tests in PLC diagnostics are subtests of test number 55, and are numbered 55.01 to 55.15. If you type lst or list in PLC or CLC diags, only the top-level tests are listed. Type lst all to list all the tests, including subtests.

Availability: all packages

macro

macro

Lists all installed macros. Refer to the section "Macros" for information on installing and using macros.

Availability: all packages

mod

mod <mode> = <0 | 1> | <on | off> | <number> | <off | hard | 

soft | detailed | info>

Sets up the test environment, where mode is one of the following:

sof: stop on fail
lof: loop on fail
lot: loop on test
def: default modes (sof off, lof off, lot off, count=1.)

0 turns the specified mode off; 1 turns it on. For example, mod sof = 1 turns stop on fail mode on. 0 and 1 can be replaced with off and on. Thus, mod sof = on has the same effect as mod sof = 1.

Availability: all packages

quit

quit

Halts the diagnostics, resets the board, and transfers control to POST. (Same as exit.)

Availability: NP diags

rev

rev

Displays information identifying the current revision of the diagnostics. rev is the same as ver.

Availability: all packages

run

run [<test#> | <test# range>] [<-switches>] [argument] [argument] [argument] [argument]

Runs selected tests (with no argument), or specified tests. The switches, which temporarily override the mode settings, are as follows:

-l Loops specified test or tests indefinitely; press any key to stop the loop
-s Stops looping if a test fails
-f Starts looping on a test that fails
-v Turns on verbose mode
-q Turns on quiet mode (and turns off verbose)

run is the same as execute and go.

You can also run tests using the execute or go commands, or by typing specific test numbers or ranges of numbers. (For example, type 22 to run test 22.) You can use the switches for the run command with test numbers as well. Thus, for example, these two commands both cause tests 22 through 24 to loop indefinitely:

run 22-24 -l

22-24 -l

Availability: all packages

scsi_reset

scsi_reset

Resets the SCSI bus that communicates with the hard and floppy disk drives.

Availability: NP diags

sel

sel [<test#> | <test# range> | all]

Selects the test or tests to be run. The argument can be a single test number, a range of numbers (6 - 12, for example), or all (select all tests). Use run to execute selected tests. Use dsel to deselect tests.

Availability: all packages

status

status [all | clr | fail | <test#> | <test# range>]

Displays the status of selected tests (with no argument); all displays status for all tests; clr clears the status of selected tests; and fail displays the status of failed tests only. To display detailed status, use status and help together:

status <test#>; help <test#>

The help display explains the error codes used in the status display.

Availability: all packages

temp

temp

Displays temperature readings for the card under test.

Availability: all packages

tod

tod

Displays the current setting of the NP's time of day clock in Greenwich Mean Time.

Availability: NP diags

ver

ver

Displays information identifying the current version of the diagnostics. ver is the same as rev.

Availability: all packages

voltage

voltage

Displays voltage information for the card under test, as measured and reported by the TCS.

Availability: all packages

Abbreviating Commands

Any command can be abbreviated to the shortest string that uniquely identifies it in its diagnostic package. For example, you can enter ve to execute the ver (version) command.

Macros

Each diagnostics package lets you configure up to five macros, numbered 0 through 4. (Macros 0 and 1 are preconfigured in NP, LSC and MSC diagnostics; see the section "Running Sets of Tests" for descriptions of what they do.) A macro can be a command or string of commands. Use the following syntax to install a macro:

_x=<command>

Where x is a macro number (0 - 4), and command is a command or a chain of commands.

In the following example, two macros are installed; the second incorporates the first.

_3=sel14-18; run
_4=_3; status

To execute a macro, type its number preceded by an underscore: for example, _1. To list all the installed macros, use the macro command.

Table of Contents

Forcing the Active NP to Become Backup

Testing the Backup NP

How to Proceed

How to Proceed

How to Proceed

How to Proceed

How to Proceed

Tests that Write to the Hard Disk

Tests that Send Data to the Switch Card

Tests that Require Looping Plugs

Tests that Require a Scratch Diskette

Long-Running Memory Tests

BB-RAM Clock Test

Tests that Send Data to the Switch Card

Tests that Require Looping Plugs

Long-Running Memory Tests

Tests that Send Data to the Switch Card

Tests that Require Looping Plugs

Long-Running Memory Tests

Tests that Send Data to the Switch Card

Tests that Require Looping Plugs

Long-Running Memory Tests

Tests that Send Data to the Switch Card

Tests that Require Looping Plugs

Long-Running Memory Tests