mjhjmtu

Playing aroud looking at /proc/interrupts The output below shows ERR and MIS on lines 26 and 27 respectively. What are these and why do they have counts (albeit of zero) for CPU0 but no others, as well as no description? Am I right to think they're actually to do with if the PIC errors itself?

Thanks ErikF for the reply. Why do these interrupts only appear for CPU0? Is it because only that CPU will receive an interrupt if there is an error with the PIC/Interrupt System?

 1. username@domain:/proc$ cat interrupts 
 2. CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 
 3. 0: 1221738 0 0 0 0 0 0 0 IO-APIC 2-edge timer 
 4. 1: 9 0 0 0 0 0 0 0 IO-APIC 1-edge i8042 
 5. 6: 3 0 0 0 0 0 0 0 IO-APIC 6-edge floppy 
 6. 8: 0 0 0 0 0 0 0 0 IO-APIC 8-edge rtc0 
 7. 9: 0 0 0 0 0 0 0 0 IO-APIC 9-fasteoi acpi 
 8. 12: 169 0 0 0 0 0 0 0 IO-APIC 12-edge i8042 
 9. 14: 0 0 0 0 0 0 0 0 IO-APIC 14-edge ata_piix 
 10. 15: 96 65508 0 0 0 0 0 0 IO-APIC 15-edge ata_piix 
 11. NMI: 0 0 0 0 0 0 0 0 Non-maskable interrupts 
 12. LOC: 402 123 273 78 134 110 118 110 Local timer interrupts 
 13. SPU: 0 0 0 0 0 0 0 0 Spurious interrupts 
 14. PMI: 0 0 0 0 0 0 0 0 Performance monitoring interrupts 
 15. IWI: 95 83 81 94 90 97 86 76 IRQ work interrupts 
 16. RTR: 0 0 0 0 0 0 0 0 APIC ICR read retries 
 17. RES: 2769117 3625540 1918695 3115064 2249434 2089381 1783180 2173439 Rescheduling interrupts 
 18. CAL: 3468 22419 21729 15320 20704 31602 15100 18188 Function call interrupts 
 19. TLB: 11579 12003 12034 10741 10855 11647 9593 11018 TLB shootdowns 
 20. TRM: 0 0 0 0 0 0 0 0 Thermal event interrupts 
 21. THR: 0 0 0 0 0 0 0 0 Threshold APIC interrupts 
 22. DFR: 0 0 0 0 0 0 0 0 Deferred Error APIC interrupts 
 23. MCE: 0 0 0 0 0 0 0 0 Machine check exceptions 
 24. MCP: 224 224 224 224 224 224 224 224 Machine check polls 
 25. HYP: 2620495 2791215 12310023 2806541 2615199 1920111 2463082 2627540 Hypervisor callback interrupts 
 26. ERR: 0 
 27. MIS: 0 
 28. PIN: 0 0 0 0 0 0 0 0 Posted-interrupt notification event 
 29. PIW: 0 0 0 0 0 0 0 0 Posted-interrupt wakeup event 

You are correct: they relate to the IO-APIC system. ERR is documented in the kernel documentation in Documentation/filesystems/proc (lines 677-680):

ERR is incremented in the case of errors in the IO-APIC bus (the bus
that connects the CPUs in a SMP system. This means that an error has
been detected, the IO-APIC automatically retry the transmission, so it
should not be a big problem, but you should read the SMP-FAQ.

AFAICT you shouldn't see this unless there is a hardware issue. As the documentation indicates, it's something that you show note and investigate if it happens frequently.

MIS doesn't show up in the documentation, but this Gentoo forum message from 2005 talks about it. The current arch/x86/apic/io_apic.c (lines 1797-1806) has the following comment:

It appears there is an erratum which affects at least version 0x11 of
I/O APIC (that's the 82093AA and cores integrated into various
chipsets). Under certain conditions a level-triggered interrupt is
erroneously delivered as edge-triggered one but the respective IRR bit
gets set nevertheless. As a result the I/O unit expects an EOI
message but it will never arrive and further interrupts are blocked
from the source. The exact reason is so far unknown, but the
phenomenon was observed when two consecutive interrupt requests from a
given source get delivered to the same CPU and the source is
temporarily disabled in between.

As this comment (and code) haven't significantly changed in over 10 years (other than kernel restructuring), I'm not sure how relevant it is today, but it is very small and protects against a strange hardware quirk.

The files that I looked at were from version 4.15.10 of the kernel. Your sources may vary.