无论何时一个硬件中断到达处理器, 一个内部的计数器递增, 提供了一个方法来检查设备 是否如希望地工作. 报告的中断显示在 /proc/interrupts. 下面的快照取自一个双处理 器 Pentium 系统:
[email protected]:/bike/corbet/write/ldd3/src/short# m /proc/interrupts
|
CPU0 |
CPU1 |
|||
|
0: |
4848108 |
34 |
IO-APIC-edge |
timer |
|
2: |
0 |
0 |
XT-PIC |
cascade |
|
8: |
3 |
1 |
IO-APIC-edge |
rtc |
|
10: |
4335 |
1 |
IO-APIC-level |
aic7xxx |
|
11: |
8903 |
0 |
IO-APIC-level |
uhci_hcd |
|
12: |
49 |
1 |
IO-APIC-edge |
i8042 |
|
NMI: |
0 |
0 |
||
|
LOC: |
4848187 |
4848186 |
||
|
ERR: |
0 |
|||
|
MIS: |
0 |
|||
第一列是 IRQ 号. 你能够从没有的 IRQ 中看到这个文件只显示对应已安装处理的中断. 例如, 第一个串口(使用中断号 4)没有显示, 指示 modem 没在使用. 事实上, 即便如果 modem 已更早使用了, 但是在这个快照时间没有使用, 它不会显示在这个文件中; 串口表 现很好并且在设备关闭时释放它们的中断处理.
/proc/interrupts 的显示展示了有多少中断硬件递交给系统中的每个 CPU. 如同你可从 输出看到的, Linux 内核常常在第一个 CPU 上处理中断, 作为一个使 cache 局部性最大 化的方法.[37] 最后 2 列给出关于处理中断的可编程中断控制器的信息(驱动编写者不必关 心), 以及已注册的中断处理的设备的名子(如同在给 request_irq 的参数 dev_name 中 指定的).
/proc 树包含另一个中断有关的文件, /proc/stat; 有时你会发现一个文件更加有用并且 有时你会喜欢另一个. /proc/stat 记录了几个关于系统活动的低级统计量, 包括(但是不 限于)自系统启动以来收到的中断数. stat 的每一行以一个文本字串开始, 是该行的关键 词; intr 标志是我们在找的. 下列(截短了)快照是在前一个后马上取得的:
intr 5167833 5154006 2 0 2 4907 0 2 68 4 0 4406 9291 50 0 0
第一个数是所有中断的总数, 而其他每一个代表一个单个 IRQ 线, 从中断 0 开始. 所有 的计数跨系统中所有处理器而汇总的. 这个快照显示, 中断号 4 已使用 4907 次, 尽管 当前没有安装处理. 如果你在测试的驱动请求并释放中断在每个打开和关闭循环, 你可能 发现 /proc/stat 比 /proc/interrupts 更加有用.
2 个文件的另一个不同是, 中断不是体系依赖的(也许, 除了末尾几行), 而 stat 是; 字 段数依赖内核之下的硬件. 可用的中断数目少到在 SPARC 上的 15 个, 多到 IA-64 上的 256 个, 并且其他几个系统都不同. 有趣的是要注意, 定义在 x86 中的中断数当前是 224, 不是你可能期望的 16; 如同在 include/asm-i386/irq.h 中解释的, 这依赖 Linux 使用 体系的限制, 而不是一个特定实现的限制( 例如老式 PC 中断控制器的 16 个中断源).
下面是一个 /proc/interrupts 的快照, 取自一台 IA-64 系统. 如你所见, 除了不同硬 件的通用中断源的路由, 输出非常类似于前面展示的 32-位 系统的输出.
|
||||||||||||||||||||||||||||||||||||||||||||||
perfmon
254: 67575 52815
SAPIC IPI
NMI: 0 0
ERR: 0
原文地址：https://www.cnblogs.com/fanweisheng/p/11142271.html