Spurious interrupts

[m.iancu]

this is from cisco site:

"Spurious interrupts might be caused by defective hardware, but this is very rare. Instead, they are very often caused by software, usually on new platforms when you have forgotten to program a specific type of interrupt. Most of the time, this has no side-effect on the expected behavior of the router or switch."

i'm not sure i understand what this means ... to program a specific interrupt ..

i have in my logs from time to time this output:

Mar 18 11:04:04 core05.40nr-1 26: Mar 18 16:01:30: %ALIGN-3-SPURIOUS: Spurious memory access made at 0x6046CAE8 reading 0x0

Mar 18 11:04:04 core05.40nr-1 27: Mar 18 16:01:30: %ALIGN-3-TRACE: -Traceback= 6046CAE8 606FBEF4 606FF708 606F1004 60714068 6028E85C 6028E848 00000000

Mar 18 11:04:04 core05.40nr-1 28: Mar 18 16:01:30: %ALIGN-3-TRACE: -Traceback= 6046CAEC 606FBEF4 606FF708 606F1004 60714068 6028E85C 6028E848 00000000

Mar 18 11:04:04 core05.40nr-1 29: Mar 18 16:01:30: %ALIGN-3-TRACE: -Traceback= 609C971C 609F1AD4 609F167C 609F0F9C 606FBEF4 606FF708 606F1004 60714068

Mar 18 11:04:04 core05.40nr-1 30: Mar 18 16:01:30: %ALIGN-3-TRACE: -Traceback= 609C971C 609F1D40 609F174C 609F12CC 606FBEF4 606FF708 606F1004 60714068

another thing that worries me is that on my box the "Spurious interrupts: " counter increases with 3-5 units in let's say 10 mins .... which is not good ....

any help will be appreciated - thank you

[donewald]

What version of code are you running, and what is your image name? This can be used to decode your tracebacks which might provide good information as to what process is doing this.

Regards,

Don

[m.iancu]

here you are:

IOS (tm) C6400R Software (C6400R-G4P5-M), Version 12.1(5)DC1, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)

System image file is "flash:c6400r-g4p5-mz.121-5.DC1.bin"

are you talking about the Output Interpreter?

thank you,

mihai iancu

ps: just out of curiosity ... how can i find .... those "symbol files" :)

[donewald]

This is not the output interpretor.. Internal tool (sorry).

Looks like most of the processes going on are SNMP related (0x606F1004:SrDoSnmp(0x606f09e8)+0x61c ) going on during your tracebacks. WIthout knowing what you are doing on your 6400 it's hard to say what exactly is the cause to this issue.

609C971C 609F1AD4 609F167C 609F0F9C 606FBEF4 606FF708 606F1004 60714068

0x609C971C:l2x_get_closest_tunnel(0x609c96ec)+0x30

0x609F1AD4:vpnmib_getnext_tunnel(0x609f1a88)+0x4c

0x609F167C:k_cvpdnTunnelAttrEntry_get(0x609f1614)+0x68

0x609F0F9C:cvpdnTunnelAttrEntry_get(0x609f0e7c)+0x120

0x606FBEF4:GetNextObjectInstance(0x606fbdcc)+0x128

0x606FF708:do_response(0x606ff5ec)+0x11c

0x606F1004:SrDoSnmp(0x606f09e8)+0x61c

0x60714068:local_snmp_engine(0x60713f54)+0x114

6046CAE8 606FBEF4 606FF708 606F1004 60714068 6028E85C 6028E848 00000000

0x6046CAE8:chassis_get(0x6046ca2c)+0xbc

0x606FBEF4:GetNextObjectInstance(0x606fbdcc)+0x128

0x606FF708:do_response(0x606ff5ec)+0x11c

0x606F1004:SrDoSnmp(0x606f09e8)+0x61c

0x60714068:local_snmp_engine(0x60713f54)+0x114

0x6028E85C:r4k_process_dispatch(0x6028e848)+0x14

0x6028E848:r4k_process_dispatch(0x6028e848)+0x0

0x00000000

609C971C 609F1AD4 609F167C 609F0F9C 606FBEF4 606FF708 606F1004 60714068

0x609C971C:l2x_get_closest_tunnel(0x609c96ec)+0x30

0x609F1AD4:vpnmib_getnext_tunnel(0x609f1a88)+0x4c

0x609F167C:k_cvpdnTunnelAttrEntry_get(0x609f1614)+0x68

0x609F0F9C:cvpdnTunnelAttrEntry_get(0x609f0e7c)+0x120

0x606FBEF4:GetNextObjectInstance(0x606fbdcc)+0x128

0x606FF708:do_response(0x606ff5ec)+0x11c

0x606F1004:SrDoSnmp(0x606f09e8)+0x61c

0x60714068:local_snmp_engine(0x60713f54)+0x114

Hope this helps you,

Don

[ruwhite]

You could probably do a bug search on this, or open a tac case. Any time you see spurious memory access it's a bug of some type, so you should get it chased down, and find out if it's one that's already fixed someplace.

Russ