It appears that the files in /proc/irq/*/spurious basically show a breakdown of where any spurious interrupts have occurred.
Your embedded system looks slightly different than my desktop system, but if I do:
`cat /proc/interrupts` I get the following:
Code:
sh-3.1# cat /proc/interrupts
CPU0 CPU1
0: 335 0 IO-APIC-edge timer
1: 30764 0 IO-APIC-edge i8042
6: 4 0 IO-APIC-edge floppy
7: 1 0 IO-APIC-edge
9: 0 0 IO-APIC-fasteoi acpi
12: 881584 0 IO-APIC-edge i8042
14: 375849 0 IO-APIC-edge ide0
15: 85 0 IO-APIC-edge ide1
18: 4462873 0 IO-APIC-fasteoi nvidia, nvidia
19: 0 0 IO-APIC-fasteoi serial
20: 3394343 0 IO-APIC-fasteoi HDA Intel
21: 231 0 IO-APIC-fasteoi ehci_hcd:usb1
22: 40497 0 IO-APIC-fasteoi sata_nv, eth0
23: 135 0 IO-APIC-fasteoi sata_nv, ohci_hcd:usb2
NMI: 0 0 Non-maskable interrupts
LOC: 6222105 7073890 Local timer interrupts
SPU: 0 0 Spurious interrupts
RES: 44719 87819 Rescheduling interrupts
CAL: 7339 12277 Function call interrupts
TLB: 19512 23211 TLB shootdowns
TRM: 0 0 Thermal event interrupts
ERR: 1
MIS: 0
sh-3.1#
So as you can see, there's a line there for 'spurious' which your embedded system doesn't show (probably for space/memory reasons I suppose, but I really don't know-- maybe that's why the 'BAD' line is there). Now, *IF* for example my above listing showed a number of spurious interrupts, I would need to look into /proc/irq/*/spurious to find out exactly where they occurred.
The file you showed above at /52/spurious tells us that there were 11 interrupts in total, and that there are/were zero unhandled interrupts. An unhandled interrupt is one for which there was no software or kernel code waiting for it or prepared to deal with it, and therefore an unhandled interrupt just kinda flies off into space
I'm guessing now: I think the 'last_unhandled' field would indicate how long the interrupt line was held by the unhandled interrupt, in milliseconds; I did no research on this though, so I could be wrong here.. Just a logical guess.
I have no clue as to whether the interrupt you are looking at for the item labeled '52' is correct, or edge-triggered, or what. I'd have to go with what the kernel says: It's a PIC generated, edge-triggered interrupt; that's what the kernel has determined from the hardware.
Finally, what is a spurious interrupt? While I'm not able to give an engineer's prespective, here's something I read just the other day when looking into some kernel driver parameters (paraphrase):
"Many motherboards/BIOS's generate a spurious interrupt early during boot"... For legacy reasons of some kind...
For the longest time, I ALWAYS got a spurious interrupt early in boot, on my desktop motherboard. It isn't harmful, but just gave an annoying message in dmesg. If I recall, it was on IRQ7 which is associated with the LP/Parallel Printer port.
The latest kernel has some fixes to deal with these legacy spurious interrupts, and if nothing else, I think since my last upgrade that I no longer see those messages
-- I'm sure the interrupt is still happening, but probably the kernel has just stopped telling me about it.
Hope this helps!
Remember, this is all based on my own reading of stuff here and there, and not on any engineering background I have (which I don't have!) so if you need more/concrete information, Google is your best friend.
Sasha
