Banner
HomeTOCPrevNextGlossSearchHelp

PDF

Table of Contents

Hardware Troubleshooting

Hardware Troubleshooting

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.

fig_1.gif


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-Tests," 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-Tests" 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 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 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-Tests" 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° F (40° 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-Tests

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.

  • -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 sections "NP Tests with Special Requirements" and "Line Card Tests with Special Requirements" later in this chapter.

  • -m invokes the manufacturing diagnostics, described in the section "Manufacturing Diagnostics" later in this chapter. If you use test -m, enter ~q to return from the diagnostic interface to the CLI.

  • -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 will be skipped---this is normal.) When the tests complete, you are returned to the CLI.

  • -r retrieves and displays the status of field diagnostics. Use this command after running one of the other test commands.

  • -s 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 sections "NP Tests with Special Requirements" and "Line Card Tests with Special Requirements."

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

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

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.


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 backup 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 Manufacturing diagnostics can only be used on a backup NP, not an active one. Instructions for forcing the active NP to be backup are in the section entitled "Field 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

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:

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

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.

  • 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 are testing is operating; use the appropriate procedure from the "Line Card Tests with Special Requirements" section to disable the system first.

  • run <test#> allows you to run or rerun specific tests by number. To see a list of tests and test numbers, use the lst all command or turn to the appendix "Diagnostic Tests."

  • Other commands are discussed later in this chapter, in the "Command Reference" section.

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 example, 03.01, 03.04, 03.07) for these test categories: 03, 07 to 17, 30 to 38
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 example, 03.01, 03.04, 03.07) for these test categories: 03, 07 to 16, 26 to 30, 32, 33

Tests That Send Data to the Switch Card---Table 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:

  • Enter `. to get a TCS hub prompt.

  • Enter 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 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 Plugs---Table 3-2 lists the tests that fall in this category for each card type. The following points pertain to these tests:

  • The looping plug tests listed in Table 3-2 result in card failure if they are run on a system that does not have looping plugs installed on the I/O ports. (The PLC tests require that looping cables be installed on the I/O ports instead.) In field diagnostics, you can invoke these tests by using the test command's -l switch.

  • If you do not have looping plugs (or cables, in the PLC case), do not run these tests.

  • The PLC tests vary, depending on whether the PLC is paired with a serial access card, an FDDI access card, an Ethernet access card, a fiber Ethernet access card, or a CEMAC.

  • The CLC tests vary, depending on whether the CLC is paired with an OC3AC or a T3/E3AC.

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 (55.01 through 55.15), 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.

  • If the card fails a test in the range 1 to 40, 52 to 78, or 80 to 118, replace the line card.

  • If the card fails a test in the range 41 to 51 or test 79, replace the access card.

Note Tests 111 to 118 result in failure if you run them in an operating system 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.

  • If the card fails any test from 1 to 80, replace the line card.

  • If the card fails any test from 81 to 95, replace the access card.

Note Ignore any failure in tests 70 to 80 if you run them in an operating system 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=sel14-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.
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.
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, 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.
exit exit

Halts the diagnostics, resets the board, and transfers control to POST. (Same as quit.)
Availability: All pages.
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 low-speed line card presents V.35 or RS-449 interfaces
Type of fantail connected to the LSC. Note, however, that an X.21 fantail displays as RS-449.
Availability: LSC 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.
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

HomeTOCPrevNextGlossSearchHelp
-

Copyright 1988-1996 © Cisco Systems Inc.