For this high cpu issues, we suggest access via console, to get some commands, like show proc cpu, and verify what could be the cause.
if the router hangs again, please try to capture some information like a stack trace (see below)from rommon as well as sh tech (includes sh ver,
sh run, sh int) and sh log outputs.
Here is some helpful info:
Console Not Responding
Console problems occur when the router becomes unresponsive to input at
the console port. If
the console is not responsive, it means that a high priority process
prevents the console driver
from responding to input.
Troubleshooting Steps
Verify cable connectivity.
Verify that the power supply is on and running.
Verify the router LED status. If all LEDs are down, it is most likely an
issue with the power supply of the
router.
If traffic is still flowing through the router:
Try disconnecting network interfaces and see if the router starts
responding. Many times the router thinks it is
doing something too important to service exec sessions.
You can also attempt to reproduce the problem after issuing the
following commands:
On the Cisco 7200 and 7500 series:
configure terminal
scheduler allocate 3000 1000
The scheduler allocate command guarantees CPU time for low priority
processes by putting a maximum
time allocated to fast-switching (3000 microseconds - usec) and
process-switching (1000 usec) per network
interrupt context.
On all other platforms, use:
configure terminal
scheduler interval 500
The scheduler interval command allows low priority processes to be
scheduled every 500 usec, thereby
allowing some commands to be typed even if CPU usage is at 100%.
Obtaining a Stack Trace from ROM Monitor
K-trace refers to the procedure used to obtain a stack trace from the
router from ROM Monitor. On routers with
older ROM Monitor code, a stack trace is obtained with the k command. On
routers running more recent ROM
Monitor code, the stack command can also be used. The procedure for
obtaining stack traces from a router that is
not responding is provided below:
1.Enable the break sequence by changing the configuration register
value. The eighth bit value must be set to
zero so that break is not ignored. A value of 0x2002 works.
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#config-register 0x2002
2.Reload the router so that the new configuration register value is
used.
3.Send the break sequence when the problem occurs. The ROM Monitor
prompt ">" or "rommon 1 >" should
be displayed.
4.Capture a stack trace by collecting the output from either the k 50 or
stack 50 commands. Adding 50 to the
command prints a longer stack trace.
5.Issue the c or cont command to continue.
6.Repeat the three last steps several times to ensure that multiple
points in a continuous loop have been
captured.
7.After several stack traces have been obtained, reboot the router to
recover from the hung state.
Here is an example of this procedure:
User break detected at location 0x80af570
rommon 1 > k 50
Stack trace:
PC = 0x080af570
Frame 00: FP = 0x02004750 RA = 0x0813d1b4
Frame 01: FP = 0x02004810 RA = 0x0813a8b8
Frame 02: FP = 0x0200482c RA = 0x08032000
Frame 03: FP = 0x0200483c RA = 0x040005b0
Frame 04: FP = 0x02004b34 RA = 0x0401517a
Frame 05: FP = 0x02004bf0 RA = 0x04014d9c
Frame 06: FP = 0x02004c00 RA = 0x040023d0
Frame 07: FP = 0x02004c68 RA = 0x04002e9e
Frame 08: FP = 0x02004c78 RA = 0x040154fe
Frame 09: FP = 0x02004e68 RA = 0x04001fc0
Frame 10: FP = 0x02004f90 RA = 0x0400c41e
Frame 11: FP = 0x02004fa4 RA = 0x04000458
Suspect bogus FP = 0x00000000, aborting
rommon 2 > cont
This procedure should be repeated several times in the event of a system
problem to collect multiple instances of
that stack trace.
let me know if you have any questions
Yesua
