show stacks Command
show stacks is an exec command that is commonly used to diagnose system crash situations. The first section of this command's output displays stack utilization of processes and interrupt routines, and the reason for the last system reboot. When a system crash happens, failure type, failure program counter (PC), address (operand address), and a stack trace are saved by the ROM Monitor. The show stacks command displays the data saved by the ROM Monitor. The stack trace is displayed in the second section of the show stacks command output (if there has been a system failure).
In the past, support engineers would submit the stack trace of their router to Cisco System's technical support representatives, who had access to symbol tables, object files, source code, and the stack decoder software. Today, the stack decoder is available online (from the CCO) and you can cut your router's stack trace from the output of the show stacks command and paste it in the input field of the stack decoder software. Stack decoder decodes the stack trace and creates a symbol file. The symbol file (perhaps along with other information in the trace) usually provides enough information to isolate the cause of any problems that were experienced.
Example 4-12 shows an example of the show stacks output from a bus error. The message "System was restarted by bus error" indicates that the processor tried to use a device or a memory location that either did not exist or did not respond properly (this could be due to a software bug or a hardware problem). Operand address, the address the processor was trying to access when the system crashed, is used as the clue to tell if the failure was due to software or hardware. If the operand address (reported on the output of the show stacks command) is valid, the problem is probably in the hardware. In other words, the operand address, not the program counter, provides the memory map location of the error, which can be used to infer the general area of the router where the error occurred.
Example 4-12 A Sample Output of the show stacks Command
|
Router# show stacks |
|
|
|
Minimum process stacks: |
|
Free/Size Name |
|
652/1000 Router Init |
|
726/1000 Init |
|
744/1000 BGP Open |
|
686/1200 Virtual Exec |
|
Interrupt Level stacks: |
|
Level Called Free/Size Name |
|
1 0 1000/1000 env-flash |
|
3 738 900/1000 Multiport Communications Interfaces |
|
5 178 970/1000 Console UART |
|
System was restarted by bus error at PC 0xAD1F4, address 0xD0D0D1A |
|
GS Software (GS3), Version 10.2 |
|
Compiled Tue 11-Aug-94 13:27 by jthomas |
|
Stack trace from system failure: |
|
FP: 0x29C158, RA: 0xACFD4 |
|
FP: 0x29C184, RA: 0xAD20C |
|
FP: 0x29C1B0, RA: 0xACFD4 |
|
FP: 0x29C1DC, RA: 0xAD304 |
|
FP: 0x29C1F8, RA: 0xAF774 |
|
FP: 0x29C214, RA: 0xAF83E |
|
FP: 0x29C228, RA: 0x3E0CA |
|
FP: 0x29C244, RA: 0x3BD3C |
Failure types are usually one of the following: bus error, address error, watchdog timeout, parity error, or emulator trap. Table 4-9 displays common failure types with a brief description for each of them.
Table 4-9 Common Failure Types Reported by the show stacks Command
|
Failure Type |
Description |
|
Bus error |
The processor tried to use a device or a memory location that either did not exist or did not respond properly (could be due to software bug or hardware error). |
|
Address error (software forced crash) |
The software tried to access data on incorrectly aligned boundaries (usually indicates a software bug). |
|
Watchdog timeout |
Watchdog timer was not reset and caused a trap. Watchdog timers are used by Cisco processors to prevent certain system hangs (indicates a hardware or software bug). |
|
Parity error |
Internal hardware checks have failed (this is due to hardware problems). |
|
Emulator trap |
Processor executed an illegal instruction (illegal branching). A hardware problem, such as ROM failure, can also cause an emulator trap error. |