The purpose of this document is to describe three types of errors - spurious accesses, alignment errors, and spurious interrupts - that may be encountered on devices running Cisco IOS® software.
There are no specific requirements for this document.
The command is not supported on all platforms (only in reduced instruction set computing [RISC] processors).
The show alignment command was introduced in 12.3(7)T, and it was hidden in earlier versions.
Spurious access is an attempt by Cisco IOS software to access memory in a restricted location. An example of system log output for a spurious access is shown below:
%ALIGN-3-SPURIOUS: Spurious memory access made at 0x60968C44 reading 0x0
%ALIGN-3-TRACE: -Traceback= 60968C44 60269808 602389D8 00000000 00000000 00000000
A spurious access occurs when a process attempts to read from the lowest 16 KB region of memory. This portion of memory is reserved and should never be accessed. A read operation to this region of memory is usually caused when a nonexisting value is returned to a function in the software, or in other words, when a null pointer is passed to a function.
Cisco IOS Software Handling
Depending on the platform, Cisco IOS software handles spurious accesses differently. On platforms where this is possible, the Cisco IOS software code handles these invalid accesses by returning a value of zero and recording the event. If this is not supported on the platform, then the router will crash with a SegV error. Since any spurious access is inappropriate, spurious accesses always point to a bug.
Verifying Spurious Access Errors
Spurious accesses are counted and recorded, if possible, by Cisco IOS software. This information is available with the show alignment command. The traceback information is necessary to determine the cause and the fix of the spurious accesses.
Note: The show alignment command is hidden and undocumented. The command is also not supported on all platforms (only reduced instruction set computing [RISC] processors). A sample output from show alignment command is provided below:
Alignment data for:
GS Software (RSP-PV-M), Version 11.1(26.1)CC, EARLY DEPLOYMENT MAINTENANCE INTER
Compiled Thu 27-May-99 20:48 by jjgreen
No alignment data has been recorded.
Total Spurious Accesses 167110746, Recorded 2
Address Count Traceback
0 10474 0x6012D488 0x6020FFB4 0x601D5CE0
0 49008 0x6012D488 0x6020D25C 0x6020E744 0x602106B4
Correcting Spurious Access Errors
Spurious access errors are always caused by a Cisco IOS software bug. To correct this, upgrade to the latest version in your release train (for example, if you are running Cisco IOS Software Release 11.2(14), upgrade to the latest 11.2(x) image. If this doesn't solve the problem, or if it's not possible to upgrade the router, contact the Cisco TAC. When opening a case to report spurious accesses, please include the following:
output from the show alignment command
output from the show tech-support command
relevant system logs
The following is an example of system log output for an alignment error:
%ALIGN-3-CORRECT: Alignment correction made at 0x60262478 reading/writing 0x60A9FF5C
Alignment errors are caused by misaligned reads and writes. For example, a two byte read where the memory address is not an even multiple of two bytes is an alignment error. Alignment errors are caused by a software bug.
Verifying Alignment Errors
Alignment errors are reported in the log and recorded by the router. Output from the show alignment command provides a record of these errors along with potentially useful tracebacks. The tracebacks for alignment errors can generally be decoded to reveal the function causing the alignment problems.
Note: The show alignment command is hidden and undocumented. The command is also not supported on all platforms (only high-end routers support it). A sample output from the show alignment command is provided below:
Alignment data for:
RSP Software (RSP-ISV-M), Version 11.3(3a), RELEASE SOFTWARE (fc1)
Compiled Fri 01-May-98 18:28 by phanguye
Total Corrections 6, Recorded 2, Reads 6, Writes 0
Address Count Access Type Traceback
60EF3765 3 32bit read 0x60262474 0x601AC594 0x601AC580
60EF3761 3 32bit read 0x60262478 0x601AC594 0x601AC580
No spurious memory references have been recorded.
Correcting Alignment Errors
Alignment errors can generally be corrected by software and, if so, will not cause a crash. Correcting alignment errors does, however, consume processor resources and can result in a performance penalty. If there are continuous alignment errors, the router can spend most of its time fixing them, increasing the CPU utilization. These errors are corrected at interrupt.
Spurious interrupts are not the same as spurious memory accesses.
A spurious interrupt occurs when an unnecessary interrupt is raised for an already processed packet, possibly due to an internal race condition, or improper initialization of interrupt handling routines. There is no discernable impact on the behavior of the router due to spurious interrupts. They may safely be ignored as long as there isn't a high and increasing number of spurious interrupts, along with some dropped packets or degraded performance. Otherwise, the root cause must be investigated.
The show align command provides information on spurious memory accesses, but not spurious interrupts. The only information on spurious interrupts that can be obtained from the system is in the show stacks output, where there is a counter that counts how many have occurred.
Minimum process stacks:
3692/4000 DHCPD Receive
4796/6000 Router Init
3408/4000 RADIUS INITCONFIG
4228/5000 DHCP Client
Interrupt level stacks:
Level Called Unused/Size Name
3 0 3000/3000 Serial interface state change interrupt
4 54351439 1760/3000 Network interfaces
5 64181 2872/3000 Console Uart
Spurious interrupts: 29
Spurious interrupts may be caused either by defective hardware or by software. Most of the time, this has no side-effect on the expected behavior of the router or switch. They are only counted for monitoring purposes.
A couple of spurious interrupts do not cause much CPU utilization. If this is the only symptom occurring on a router or switch, and everything else is working as expected (no packet drops and so on), then the spurious interrupts may be ignored.
Cisco routers based on the 68k processor (that is, the Cisco 1000, 1600, 2500, 4000, and 7000 (RP)) can be configured to generate a coredump if a certain threshold of spurious interrupts is reached.
core-file Set name of core dump file
crashinfo Crashinfo collection
dump Set name of host to dump to
flash Set the device and erase permission
memory Memory leak debugging
protocol Set protocol for sending core file
region-size Size of region for exception-time memory pool
spurious-interrupt Crash after a given number of spurious interrupts
Router(config)#exception spurious-interrupt ?
<1-4294967295> Spurious interrupt threshold
For more information on coredump generation, see Creating Core Dumps. This information might be requested by our Technical Assistant Center in the case of performance degradation due to spurious interrupts. If that is the case, there should be a high and increasing number of spurious interrupts, along with some packet drops or degraded performance.
Information to Collect if You Create a TAC Service Request
If you still need assistance after following the troubleshooting steps above and want to create a service request (registered customers only) with the Cisco TAC, be sure to attach the following information to your case for troubleshooting spurious accesses, alignment errors, and spurious interrupts:
Troubleshooting performed before creating the service request
show technical-support output (in enable mode, if possible)
show alignment output (if not already included in the show technical-support output)
show log output or console captures, if available
Please attach the collected data to your service request in non-zipped, plain text format (.txt). You can attach information to your service request by uploading it using the TAC Service Request Tool (registered customers only) . If you cannot access the Service Request Tool, you can attach the relevant information to your service request by sending it to firstname.lastname@example.org with your service request number in the subject line of your message.
Note: Please do not manually reload or power-cycle the router before collecting the above information, unless required to troubleshoot spurious accesses, alignment errors, and spurious interrupts, as this can cause important information to be lost that is needed for determining the root cause of the problem.