查看 /proc/interrupts 下面的输出分别在第 26 行和第 27 行显示了 ERR 和 MIS。这些是什么?为什么它们有 CPU0 的计数(尽管为零)但没有其他计数,也没有描述?我认为它们实际上与 PIC 本身错误有关吗?
感谢 ErikF 的回复。为什么这些中断只出现在CPU0上?是否是因为如果 PIC/中断系统出现错误,只有该 CPU 才会收到中断?
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
答案1
你是对的:它们与 IO-APIC 系统有关。ERR
记录在内核文档中在Documentation/filesystems/proc
(第 677-680 行):
ERR
如果 IO-APIC 总线(SMP 系统中连接 CPU 的总线)出现错误,则递增。这意味着检测到错误,IO-APIC 会自动重试传输,因此不应是一个很大的值问题,但您应该阅读 SMP-FAQ。
AFAICT 除非存在硬件问题,否则您不应该看到此内容。正如文档所示,您应该注意并调查它是否经常发生。
MIS
没有出现在文档中,但是2005 年的 Gentoo 论坛消息谈论它。目前的arch/x86/apic/io_apic.c
(第 1797-1806 行)有以下评论:
似乎有一个勘误表至少影响 I/O APIC 的 0x11 版本(即 82093AA 和集成到各种芯片组中的内核)。在某些情况下,电平触发中断会被错误地传递为边沿触发中断,但相应的 IRR 位仍然会被设置。结果,I/O 单元期望 EOI 消息,但它永远不会到达,并且进一步的中断被阻止来自源。确切的原因目前尚不清楚,但当来自给定源的两个连续中断请求被传递到同一个 CPU 并且中间源被暂时禁用时,就会观察到这种现象。
由于此注释(和代码)在 10 多年来没有发生重大变化(除了内核重组),我不确定它在今天有多重要,但它非常小,并且可以防止奇怪的硬件怪癖。
我查看的文件来自内核版本 4.15.10。您的来源可能有所不同。