System information

Book Title
Memory Maps and Troubleshooting
B-504
Bus Error
The system encounters a bus error when the processor tries to use a device or a memory location that
either does not exist or does not respond properly. Bus errors typically indicate either a software bug
or a hardware problem. The address the processor was trying to access when the system crashed
provides a key as to whether the failure is due to software or hardware.
If the operand address is valid, the problem is probably in the hardware. The memory maps listed
later in this appendix list addresses for selected hardware platforms.
Bus errors on an address not in the map usually indicate a software bug.
Address Error
Address errors occur when the software tries to access data on incorrectly aligned boundaries. For
example, 2- and 4-byte accesses are allowed only on even addresses. An address error usually
indicates a software bug.
Watchdog Timeout
Cisco processors have timers that guard against certain types of system hangs. The CPU periodically
resets a watchdog timer. If the timer is not reset, a trap will occur. Failure to service the watchdog
timer indicates either a hardware or a software bug.
Parity Error
Parity errors indicate that internal hardware error checks have failed. A parity failure is almost
always due to a hardware problem. Use the memory maps listed later in this chapter to identify the
affected hardware.
Emulator Trap
Emulator traps indicate that the processor has executed an illegal instruction. Emulator traps can be
caused either by software taking illegal branches or by hardware failures, notably ROM failures.
Error Addresses
By observing the operand address, you can locate the general area of the router where the error
occurred. Hardware problems can be inferred only from a bus error on a legal address, not from an
emulator trap or illegal instruction trap. When looking at the bus error, the operand address—not the
program counter address—provides the memory map location of the error.
show stacks Command
You can use the show stacks exec command to display data saved by the ROM monitor, which
includes a failure type, an operand address, and a failure program counter. This data is overwritten
when the system is reloaded, so you might want to check your configuration register settings and
decide how you want to recover from system crashes. Stack traces can be used by qualified technical
support representatives who have access to symbol tables, object files, and source code.
Figure B-1 shows an example of the show stacks output from a software failure. The message
“Software forced crash” indicates that the software detected a condition it did not expect and from
which it could not recover. A technical support representative can use the listed program counter as
a trace to the code responsible for the failure.