cc/td/doc/product/atm/l2020/2020r21x
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Hardware Troubleshooting
Safety Instructions
General Troubleshooting
Overview of Diagnostic Testing
Power-on Self Test
Field Diagnostics
Manufacturing Diagnostics
Command Reference

Hardware Troubleshooting


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

This chapter is divided into the following sections:

Also, look at the appendix "LEDs," which explains the different LED states, and the appendix "Diagnostic Tests," which lists all the diagnostic tests available for network processor and line cards.

Safety Instructions

Before removing any components from the chassis, read these safety instructions.

LS2020 switches 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 Protection

Static electricity or electrostatic discharge (ESD) can damage electronic components. Before you expose circuitry, make sure that your body, the rack, and the circuit boards are at the same ground potential. 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.

General Troubleshooting

General troubleshooting tasks help you identify faults in NPs, switch cards, and line cards, and they are the only means of identifying faults in subsystems not covered by POST or diagnostics, such as blowers and power supplies. These tasks can be performed before, after, instead of, or in addition to running the diagnostic software. Some of these procedures require you to be in the same room with the faulty system; others can be performed remotely.

Table 3-1 lists symptoms and recommendations by component. Before referring to the table or running diagnostics, first do the following:

If a card's fault (FLT) LED is lit, see the appendix entitled "LEDs" for a list of possible causes and solutions.

For information on replacing FRUs and returning failed FRUs to Cisco, refer to the chapter entitled "Replacing FRUs."

Table 3-1   Symptoms and Recommendations by Component

Component Symptom Recommendation
Switch card

A slot fails regardless of the kind of card put in it.

Test the switch card's switching fabric by running tests that loop data through the switch card on NPs and line cards in every slot in the chassis.

The POST results in failure. (The FLT LED on the card's bulkhead stays lit, and checking the POST results, as directed in the section "Power-on Self Test," shows a problem.)

Replace switch card.

The switch card fails even when moved to the other slot.

Replace switch card.

Diagnostics that loop data through the switch card result in failure of two or more function cards.

Replace switch card.

The card fails to come up or to select a TCS hub.

Replace switch card.

Traffic is not passing through the switch card(s), but the line cards and NPs are OK.

Replace switch card.

The system has data transmission problems that do not go away when you replace the FRU that appears to be failing, or that occur in several FRUs simultaneously.

Troubleshoot midplane; if problem is not with midplane, replace switch card.

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.

NP cards

The NP card fails to power up.

Check its access card at the back of the chassis. An NP requires an NP access card (NPAC); it cannot operate with any other kind of access card.

POST fails (the FLT LED on the card's bulkhead stays lit, and checking the POST results as directed in the section "Power-on Self Test" shows a problem).

Replace NP card.

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.)

Replace NP card.

Field or manufacturing diagnostic tests fail to run.

Replace NP card.

You can't get to CLI in order to run the diagnostics.

Switch NP card with its backup. If it still fails, replace it.

The card fails to load.

Replace NP card.

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.

System fails to boot.

This could indicate 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. Replace NP card.

Interface modules

Card fails. Can't tell if the problem is with the line or access card.

  • Determine if the problem is with the line card or the access card by swapping a card with another one of the same type. Do not swap one line card for another unless you are sure that the cards are of the same type.

For example, if you swap one cell line card with another and the problem persists, the access card is probably at fault. If the problem goes away, the first line card is probably the source of the problem.

  • 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.
  • For other ways to determine if the problem exists on the line card or the access card, refer to the section entitled "Running Manufacturing Diagnostics ."

The module does 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 requires a low-speed access card. See the chapter entitled "Interface Modules" for more information.

FDDI module does not pass traffic.

Make sure the FDDI cables for each port are attached to the proper connectors. If you are 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.)

A serial access module, a low-speed module, or an E1 circuit emulation (CEMAC) module fails to come up.

Make sure the interface jumpers on the access card are set properly. See the chapter "Hardware Configuration" for more information on interface jumpers.

There are signal quality problems with a physical interface on an access card.

  • If your cable is too long or if your optical signal passes through too many connectors, signal attenuation will result. See the chapter entitled "Interface Modules" for information on allowable signal loss (for optical interfaces) or maximum cable lengths (for electrical interfaces).
  • If your optical 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). You can clean the connectors on most cables 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.
  • To prevent complications from dirty or damaged connectors, keep any unused optical connector covered with its protective cap.

POST results in failure. (The FLT LED on the line card's bulkhead stays lit, and checking the POST results as directed in the section "Power-on Self Test" shows a problem.)

Replace card.

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.)

Replace card.

Hardware diagnostics show a failure.

Replace card.

The line card fails to load.

Replace card.

The line card hangs repeatedly.

Run field or manufacturing diagnostics; consider replacing card.

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.

Two or more ports are passing no traffic, dropping many cells, or flapping—coming up and down repeatedly.

Refer to the looping tests described in the LightStream 2020 Network Operations Guide . (If only one port has symptoms, look for a problem with the line, the external DSU/CSU if one is present, the access card, or the remote device.)

Blowers

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.

Confirm the card temperature with the CLI command show tcs <slot#> or the TCS command show <slot#> temperature.

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 that the temperature in the system area does not exceed 104\xb0 F (40\xb0 C).

The system is powered on, but the blower is not turning, making noise, or exhausting air.

Replace blowers Verify this by looking through the holes in the cover of the rear blower and by removing the front blower cover to examine the front blower.

CAUTION: 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.

Two minutes after the system is powered on, the blowers fail to reduce their speed in a room temperature environment.

Replace blowers. 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.

The system is powered on, but the blower's green LED is off.

Replace blowers. 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.

Bulk power trays

In a system with one power tray, no power is present if the power tray is faulty.

 

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 read "Empty.")

cli> show chassis powersupply

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

A status line for an occupied slot says anything other than Good.

Check the faulty power tray to see that it is properly connected. (Power tray slot A is on top; slot B is on the bottom.) If the problem persists, replace the power tray.

Disk assemblies

The node fails to boot.

Replace disk assembly.

Files become corrupted.

Replace disk assembly

The system fails to read or write floppy diskettes.

Check the write protect switch on the diskette. Otherwise, replace disk assembly.

The system does not boot or you are unable to access the hard disk.

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, reinstall the software, using the procedure described in the LightStream 2020 Network Operations Guide. If that does not 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.

In a system with two NPs, the primary NP appears to fail and the backup takes over—but the failed NP passes diagnostics.

Replace disk assembly.

Midplane

A card fails in one slot but operates normally in other slots.

Check midplane.

Data transmission problems do not go away when you replace the FRU that appears to be failing, or the problems occur in several FRUs simultaneously.

Check switch card. If switch card is okay, the problem is probably with the midplane.

You cannot fully insert a card 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.

Electrical problems (including electrical failure) do not go away when you replace the FRU that appears to be failing, or they occur in several FRUs simultaneously. Electrical problems include out-of-range voltages, indicated by trap NPTMM_6.

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>

Overview of Diagnostic Testing

LS2020 hardware diagnostics are used to discover the location of hardware faults.The diagnostics reside on each NP's hard disk, and are for testing NP cards, line cards, associated access cards, and the disk drives associated with the NP.

You use one of the following to diagnose hardware problems:

Manufacturing diagnostics are initiated with the CLI test -m command; however, a manual loading procedure is required to start manufacturing diagnostics on a system with a single NP module. For more information, see the section "Manufacturing Diagnostics ." (For a complete list of manufacturing diagnostics tests, see the appendix "Diagnostic Tests.")


Note      Manufacturing diagnostics and field diagnostics can only be used on a backup NP, not an active one. For more information, see the section entitled "Using the test Command on a Backup NP."


You can use field or manufacturing diagnostics on a line card or a backup NP while the rest of the system continues to operate. With interface modules, only the card under test comes out of service during the diagnostics. In systems with backup NP modules, the same is true. In systems that have a single NP module, you must take the system off line to test its NP card.

You can run diagnostics remotely over a Telnet or modem connection or locally from a console connected to the console port. However, running diagnostics on the sole NP in a nonredundant system requires a local console or a modem.

The remainder of this chapter provides procedures for working with POSTs, field diagnostics, and manufacturing diagnostics. The last section, "Command Reference ," summarizes key commands available in the diagnostic packages.

Power-on Self Test

Power-on self test (POST) diagnostics are the first line of defense for identifying hardware problems. These diagnostics run automatically on each card whenever the system or the slot is powered up or when the card is reset; they take about 90 seconds. There are POSTs for NP cards and line cards. The POST for each line card also checks the accompanying access card.

To display POST results, use one of these commands:


Note      The CLI show tcs commands do not work on Sun workstations.


Typical output from the TCS show <slot#> post command looks like this:

TCS HUB<<B>> show 4 post
Line card POST information (slot 4):
POST Revision: 0.185
POST Compiled: Feb 3 1996
POST Results: PASSED

Typical output from the TCS show <slot#> post all command looks like this:

TCS HUB<<B>> show 4 post all
Line card POST information (slot 4):
POST Revision: 0.185
POST Compiled: Feb 3 1996
POST Results: PASSED
CP_Flash_Checksum_Test : PASSED
CP_to_DRAM_Tests : PASSED
CP_Parity_Tests : PASSED
OSMC_uStore_Tests : PASSED
ISMC_uStore_Tests : PASSED
NQP_uStore_Tests : PASSED
DQP_uStore_Tests : PASSED
NQP_B_uStore_Tests : PASSED
DQP_B_uStore_Tests : PASSED
.
.
.
TCS HUB<<B>>

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. Generally, a card that fails POST needs to be replaced.


Note      The FLT LED does not necessarily indicate a POST failure or a disabled application; the LED stays on under other conditions as well. (See the appendix "LEDs" 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 "General Troubleshooting" for the card in question. In most cases, you should also run the field or manufacturing diagnostics to confirm that a problem exists.

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. Field diagnostics is a subset of manufacturing diagnostics, and is designed to provide information quickly and easily. For your own convenience, you should run field diagnostics before resorting to the more complex and time consuming 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 test command impedes normal traffic flow. If you are unsure of the potential impact of this command on your network, contact Cisco customer support. If using multiple switches with the test command, give each switch a - (minus) sign and separate each switch with a space. For example:

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.

Typical field diagnostic tests takes about 15 minutes to run. To display the status of the tests, enter test <slot#> -r.

The syntax of the CLI test command is as follows:

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

Where


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


Typical output from field diagnostics, using the test -p command, looks like this:

*cli> test 4 -p
Executing field diagnostics for CLC1 card in slot 4
Loading diagnostics file: /usr/diag/diag_clc1.aout
Begin Testing
Test 1.
Test 3.6..
Test 6.
Test 14.3.
Test 27.5..
Test 27.6....
Test 28.5...
Test 28.6...
Test 29.2.
Test 30.5..
Test 30.6....
Test 32.6.
Test 33.5..
Test 33.6...
Test 36.2.
Test 41.
Test 42.
Test 43..
Test 49.31..........
Test 49.32......
Test 49.33......
Test 49.37.........
Diagnostics PASSED
*cli>

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 are 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 do not know the appropriate community name for this system, contact the network administrator.) The example 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

This command reports whether the card passed or failed the tests. It also tells you if the tests are still running. For example, if the tests are still running, a message like the following one is displayed:

Diagnostics are running, test 73, heartbeat = 18673

If the tests are still running, wait for them to finish and run the command again.

Step 7   If the tests indicate that the card is all right, go to the next step.

If the tests result in failure, 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 enter test -r, and return that information 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

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

The test command can only be run on a backup NP, not an active NP. The first procedure below explains how to force the active and backup NPs to switch roles; this is necessary only if the NP you want to test is currently active. The second procedure tells you how to run the diagnostics.


Note      If your system has only one NP, see the procedure "Loading Manufacturing Diagnostics into a Lone NP" later in this chapter.


This task requires either a local console connected to the switch under test or a modem connection. You cannot use Telnet.

Forcing the Active NP to Become Backup

If the NP you want to test is currently operating as the backup, skip to the next procedure, "Testing the Backup NP." If you are 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 1   Warn anyone who will be affected that you are taking the system off the network for a few minutes.

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 port to use.)

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

Step 4   At the TCS hub prompt, use the connect <slot#> command to connect to the NP you want to test. The example below shows slot 1 being used.

TCS hub<<A>> connect 1

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

Step 6   At the prompt, enter reboot -n.

Step 7   Enter `. to return to the TCS hub.

Step 8   Go to step 3 of the next procedure.

Testing the Backup NP

Step 1   If you have not 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, enter `. 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 will use this NP, which must be active, to test the other one. The example below shows a connection to the NP in slot 2.

TCS hub<<A>> connect 2

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

Step 5   Enter protected mode:

cli> protected

You are 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 do not know the appropriate community name for this system, contact the network administrator.) The example 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 are 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


This command indicates whether the card passed or failed or whether the tests are still running. For example, if the tests are still running, a message like the following one is displayed:

Diagnostics are running, test 73, heartbeat = 18673

If the tests are still running, wait for them to finish and run the command again.

Step 9   If the NP passed the tests, go to the next step. If it 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 enter 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>

Manufacturing Diagnostics

Manufacturing diagnostics include a full array of tests, allowing you to diagnose problems with memory, NetTime, peripherals, the Test and Control System, and so on. A complete list of the tests appears in the appendix "Diagnostic Tests." This section provides procedures for running manufacturing diagnostics, and lists some of the more common testing routines.

This section contains the following procedures:

Loading Manufacturing Diagnostics into a Line Card or Backup NP

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


Note      In a redundant system, manufacturing diagnostics can only be used on the backup NP, not an active one. Instructions for forcing the active NP to be backup are in the section "Field Diagnostics." If your system has only one NP, see the procedure "Loading Manufacturing Diagnostics into a Lone NP" later in this chapter.



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

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

Step 3   Use the set command to set the SNMP community to a community with write privileges. (If you do not 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>

This command 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.

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 will 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]->

Step 5   For instructions on executing tests, see the section, "Running Manufacturing Diagnostics ."


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


Loading Manufacturing Diagnostics into a Lone NP

You must use manufacturing diagnostics to test the single NP in a nonredundant system. After loading the diagnostics, see the section "Running Manufacturing Diagnostics " for instructions on what to do next.

This procedure explains how to load the manufacturing diagnostics into the sole NP in a nonredundant system. 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.


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, enter `. to get a TCS hub prompt.

Step 4   At the TCS hub prompt, use the connect <slot#> command to connect to the NP. In the example below, the NP is assumed to be in slot 1.

TCS hub<<A>> connect 1

Where

connect 1 establishes a terminal connection to the card in slot 1.

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

Step 6   Enter reboot -n to enter the boot sequence. You will see the following display:

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

Memory Autosizing ... (32 Meg) ... Done
Clearing 32 Meg Memory... Done

NP1 POST Version 0.225 Feb 21, 1995


NP1 POST Summary
----------------

0 Tests Failed

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   Enter 6 at the prompt to escape to the bootstrap command line interpreter:

Option> 6

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, you will enter a command that tells the NP to load the file diag_np1.aout:

Boot: (sd0b)diag/diag_np1.aout

After entering this command, you will 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 following section, "Running Manufacturing Diagnostics ."

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

Running Manufacturing Diagnostics

Read this section for information on running manufacturing diagnostics. You can run either sets of tests or specific tests with the following commands:

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.

Depending on the line card and access card being tested, it can take from 10 minutes to an hour for the run command to complete its test routine.

Typical output from the run command looks like this:

CLC1 Diag Monitor[04]-> 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
.
.
.
47 RATO_lpbk_Tsu_A_Int_SWA_Test PASSED
48 Metering__Tsu_A_Int_SWA_Test PASSED
49 CBR_Access_Card_Tests PASSED
CLC1 Diag Monitor[04]->

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 leave diagnostics when your session is finished.

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

NP Tests

Use this procedure to run diagnostics on an NP card. You are assumed to have already loaded the diagnostics onto the card, as described in the preceding sections.


Step 1   At the prompt, enter run to run a set of tests. (See the section, "Running Manufacturing Diagnostics ," 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.)


Note      See the next heading, "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

Step 3   Use the status command to learn 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 run diagnostics on a lone 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 enter `., 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 in to 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

See below for remedial steps.

NP Tests with Special Requirements

Tests that write data to the hard disk—Tests 43 to 46 write data to the hard disk. Because these tests are disabled by default, you must explicitly enable them in order to run them. Do not run the tests, though, unless you are testing a new disk drive or you think there may be a fault in your hard disk.

Tests that send data through the switch card—Tests 78, 80, and 82 to 93 send data through the switch card. Take the LS2020 node off line before running these tests (see the procedure described later in this section). Do not run them on a system that is 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.)

To run these tests, use the following procedure to disable the system and all the other cards in the chassis. Doing so 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 prompt, use the command reboot -n to bring down the NP. (Bring down both if there are two.)

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

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

Step 5   Enter 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.

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> 6

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—Tests 13, 14, and 33 result in failure 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, you should not run these tests:

Tests That Require a Scratch Diskette—Tests 47 to 49 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, you should not run these tests.

Long-Running Memory Tests—Tests 08, 09, and 93 take longer than 1 minute to run. Some take many minutes. (In field diagnostics, these tests are invoked when you use the test command -x switch.)

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 result in failure, you will be prompted to reset the clock. You must supply the current time and date. If the system under test has two NPs, their clocks must agree to within 1 minute or file consistency problems between the two NPs may result.

Remedial Steps

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

If a card passes all tests but you are still experiencing a problem, test the other cards in the chassis. Consider replacing any cards that fail diagnostics. If the problem persists, investigate causes outside the LS2020 hardware, including leased lines and edge devices.

Line Card Tests

Use this procedure to run line card tests. The procedure is good for a low-speed line card (LSC), a medium-speed line card (MSC), a packet line card (PLC), or a cell line card (CLC). Once you run the tests, go to the "Remedial Steps" section for help in working with the results of the tests you have run and for more information on the test you are running.

If you need to return to CLI before completing the diagnostics session, you can enter 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.

You are assumed to have already loaded the diagnostics onto the card, with the procedures provided earlier in this chapter.


Note      PLC and CLC diagnostics determine which type of access card is installed with the line card under test. Tests appropriate for that access card are then enabled. To find out the access card type, use the access command. (See the "Command Reference " section later in this chapter.)



Step 1   At the prompt, enter run to run a set of tests. (See the section, "Running Manufacturing Diagnostics ," for information.) As the tests run, the system displays the name of each test and indicates whether the card passed or failed. (Depending on your configuration, a test may produce a "not run" result. This is not a problem.)

Step 2   To run or rerun a test or group of tests, use the run command and specify the test numbers. For example:

diags> run 5-15

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


Note      When simultaneously testing multiple CLCs in the same chassis, you should deselect all NetTime tests.


Step 3   Use the status command to obtain the status of diagnostic tests. Use status fail to obtain information on tests that have failed.

Step 4   For explanations of the error codes used in the status display, enter help and the number of the test in question. For example:

diags> help 10

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

diags> exit

Step 6   When the login prompt appears, log in to the node, enter CLI protected mode, and use the set command to reset the card's status to active:

*cli> set card <slot#> active

Replace <slot#> with the slot number of the card you were testing.

See below for remedial steps.

Line Card Tests with Special Requirements

Table 3-2 lists the tests with special requirements that pertain to the four different line card types listed here (low-speed, medium-speed, PLC, and CLC). The appendix "Diagnostic Tests" has more information on the tests listed in the table. The paragraphs following Table 3-2 discuss the three test categories that appear in the table: (1) tests that send data to the switch card, (2) tests that require looping plugs, and (3) long-running memory tests.

Table 3-2   Line Card Tests with Special Requirements

Line Card Tests That Send Data to the Switch Card Tests That Require Looping Plugs Long-Running Memory Tests

LSC

111 to 116

08, 43, 46, and 50

09, 15, 16, 17, 23, 24, 29, 35, 56, 62, 63, 69, 71, 77

MSC

70 to 77

93 and 94

13 to 15, 24, 25

PLC

43 and 46

CEMAC: 55.13, 55.14

FDDI: 55.12

Ethernet: 55.09. 55.12, 55.15

Fiber ethernet: 55.13

Serial: 55.05, 55.07 to 55.09, 55.13, 55.14

03.08, 04.0, 05.0, 26, 27

Any .01, .04, or .07 subtest for these test categories: 03, 07 to 17, and 30 to 38 (for example, 03.01, 03.04, 03.07)

 

CLC

37 to 40

OC-3c: 49.13 to 49.20

T3/E3: 49.11

03.08, 04.0, 05.0, 23, 24, 49.14.07

Any .01, .04, or .07 subtest for these test categories: 03, 07 to 16, 26 to 30, 32, and 33 (for example, 03.01, 03.04, 03.07)

Tests That Send Data to the Switch CardTable 3-2 lists line card tests that send data through the switch card. (In field diagnostics, these tests are invoked when you use the test command -s switch.) Take the LS2020 node off line before running these tests. Do not run them on a system that is 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.)

To run these tests, use the following procedure to (1) disable the system and all the other cards in the chassis and (2) load the diagnostics into the card you wish to test. This procedure prevents the other cards from sending packets to the card under test. Such packets could 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:

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

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

Step 5   Enter connect <slot#> to return to the NP, and press Return to display a menu of boot options.

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

Network Processor bootstrap (version 1.3: Sep 13 1995)
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> 6

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 will see an identifying message and a prompt, as shown below. To load diagnostics, enter the command shown, replacing <slot#> with the number of the card you want to test. Replace /diag_xxx.aout with an entry appropriate for the type of card you are testing: /diag_lsl.aout for a low-speed line card, /diag_msl.aout for a medium-speed card, /diag_plcl.aout for a packet line card, and /diag_clcl.aout for a cell line card.

******************************************
* System Diagnostic Debug Monitor *
* Revision 1.405 (Jul 18 1995) *
* Type 'help' or '?' for help *
******************************************

System Monitor-> swload <slot#> (sd0b)diag/diag_xxx.aout

Step 9   Wait about 5 minutes for the diagnostics to load, and then enter `. 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 PlugsTable 3-2 lists the tests that fall in this category for each card type. The following points pertain to these tests:

Long-Running Memory Tests—The line card memory tests listed in Table 3-2 take longer than 1 minute to run. Some take many minutes. (In field diagnostics, these tests are invoked when you use the test command's -x switch.)

Remedial Steps

When you have completed the line card test procedure, you may need to take one or more of the steps outlined here. Refer to the paragraphs that pertain to the type of card you are testing.

PLC

If the card fails test 55 (or any of its subtests), there is a problem with the access card. Replace the access card, using the procedure described in the chapter "Replacing FRUs."

If a card fails any other test, replace the card being tested, using the procedures described in the chapter "Replacing FRUs."

If the card passes all tests but you still experience a problem, test the other cards in the chassis. Consider replacing any cards that fail diagnostics. If the problem persists, look for causes outside the LS2020 hardware, including leased lines and edge devices.

CLC

If the card fails test 49 (or any of its subtests), there is a problem with the access card. Replace the access card, using the procedure described in the chapter "Replacing FRUs."

If a card fails any other test, replace the card being tested, using the procedure described in the chapter "Replacing FRUs."

If the card passes all tests but you still experience a problem, test the other cards in the chassis. Consider replacing any cards that fail diagnostics. If the problem persists, look for causes outside the LS2020 hardware, including leased lines and edge devices.

LSC

If the line card fails a test, you may need to replace it or its access card. (Replacement procedures are in the chapter "Replacing FRUs.") The number of the test that the card failed determines which card to replace.


Note      Tests 111 to 118 result in failure if you run them in an operating node using test -m. This failure does not indicate a problem, though, and should be ignored. The card passes test 43, 46, and 50 only if looping plugs are installed. Disable or disregard these tests if you are testing without looping plugs.


If the card passes all tests but you still experience a problem, test the other cards in the chassis. Consider replacing any cards that fail diagnostics. If the problem persists, look for causes outside the LS2020 hardware, including leased lines and edge devices.

MSC

If the card fails a test, you may need to replace it or its access card. (Replacement procedures are in the chapter "Replacing FRUs.") The number of the test that the card failed determines which card to replace.


Note      Ignore any failure in tests 70 to 80 if you run them in an operating node using test -m. Only the E3 access card can pass test 95; disable or disregard that test if you are testing a T3 card. Tests 93 and 94 require that looping plugs be installed; disable or disregard them if you are testing without looping plugs.


If the card passes all tests but you still experience a problem, test the other cards in the chassis. Consider replacing any cards that fail diagnostics. If the problem persists, investigate causes outside the LS2020 hardware, including leased lines and edge devices.

Command Reference

This section alphabetically lists and describes selected commands that are available in LS2020 hardware diagnostic packages. Each entry in Table 3-3 lists the packages in which the command is available. All packages means the command will work with any line card.


Note      LS2020 diagnostics contain many commands that are not listed in this section. Such commands are for use by customer service personnel only.


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.

Each diagnostics package lets you configure up to five macros, numbered 0 through 4. (Macros 0 and 1 are preconfigured to run sets of NP, LSC, and MSC diagnostic tests.) 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=sel 14-18; run
_4=_3; status

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

Table 3-3   Hardware Diagnostic Commands

Command Description

!

! <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>]

With argument: Displays information on the specified command.

Without 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: All packages

arun

arun
 

Runs all tests once. Not recommended if you do not 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 is low. 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 diagnostics

blink

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

In NP diagnostics: 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 diagnostics: 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.

Availability: NP, PLC, and CLC diagnostics

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 diagnostics

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.

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

execute 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 diagnostics

fl_inq

fl_inq

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

Availability: NP diagnostics

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 (for example, help go), help describes the syntax and purpose of the specified command.
  • With a test number as an argument (for example, 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:

  • Current setting of the jumpers that determine whether the LSC or PLC presents V.35 or RS-449 interfaces
  • Type of fantail connected to the LSC or PLC. Note, however, that an X.21 fantail displays as RS-449.

Availability: LSC and PLC diagnostics

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 diagnostics

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

 

[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 enter 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 enter lst or list in PLC or CLC diagnostics, only the top-level tests are listed. Enter lst all to list all the tests, including subtests.

Availability: All packages

macro

macro

Lists all installed macros. Refer to the beginning of this section 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 diagnostic, resets the board, and transfers control to POST. (Same as exit.)

Availability: NP diagnostics

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, enter 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 diagnostics

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 diagnostics

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


hometocprevnextglossaryfeedbacksearchhelp
Posted: Wed Jan 22 23:52:41 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.