Linux查看硬件中断信息的方法与命令教程

排查 Linux 中断异常时，先查看 /proc/interrupts，通常是最轻量、也最值得信赖的第一步。但不要只看一眼就仓促下结论，IRQ 编号、各 CPU 的计数变化、设备名称等列信息都需要结合分析；再配合动态监控，例如 watch -n 1 'grep eth0 /proc/interrupts'，以及借助 trace-cmd 做中断耗时分析，才能真正判断异常硬件中断到底来自哪里，并把问题精准定位。

直接查看 /proc/interrupts 仍然是唯一轻量且可靠的起点，但如果只是简单 cat 一下很容易误判——它只记录中断次数，并不会直接告诉你是谁在触发、触发频率有多高、每次处理又耗费了多久。

怎么看懂 /proc/interrupts 的行和列

执行 cat /proc/interrupts 后，第一列是 IRQ 编号（例如 42、25），后续每一列分别对应一个 CPU（CPU0、CPU1…），最后一列则是中断来源描述。常见形式包括：

• IO-APIC 16：传统中断控制器，编号通常与物理引脚绑定
• PCI-MSI 0000:01:00.0：PCIe 设备通过 MSI 方式申请的中断，IRQ 编号与设备地址关联明显
• IR-PCI-MSI 32768：在虚拟化环境启用中断重映射后，IRQ 编号已经和物理引脚解耦，不能单纯按编号猜测硬件来源
• eth0、nvme0n1、i915：这是内核驱动注册时填写的设备名，也是判断中断归属最直观的线索

还要注意：0 不等于“没有工作”——当网卡启用 NAPI 或轮询模式（例如 ethtool -C eth0 rx off）后，中断计数可能归零，但网络流量依然会正常收发。

怎么快速定位正在猛打 CPU 的中断源

不要盯着整屏数据发呆，最好用过滤配合动态观察，专门盯住跳变速度：

• 按设备名实时监控：执行 watch -n 1 'grep -E "(eth|enp|ens|eno|nvme)" /proc/interrupts'，把 eth 替换成你实际的网卡名称（如 ens33）或 NVMe 设备名（如 nvme0n1）
• 重点观察某一行中的某一列（例如 CPU0）是否每秒增长几百甚至上千；如果其他列几乎不变化，往往说明该中断正在单核上集中打满，造成 CPU 压力
• 如果末尾出现 rx-0、tx-1 这类后缀，表示这是网卡多队列中断，对应多个 IRQ 可以进一步调优；如果只有一行且没有后缀，大概率说明网卡没有启用多队列
• 若 RES（重调度）、CAL（IPI）、TIMER 持续快速上升，通常不是硬件中断故障，而更可能是内核调度异常或 busy-loop 导致，不要误把问题归到驱动上

为什么改了 smp_affinity 却没生效

手动写入后过几秒又恢复原样？大多数情况下是 irqbalance 在后台把你的设置覆盖了：

• 先确认是否真的被接管：查看 /proc/irq//effective_affinity，如果它与 smp_affinity_list 不一致，就说明 irqbalance 或内核自动管理机制正在干预
• 不要优先直接写 smp_affinity（十六进制掩码）——x86 和 ARM 的位宽不同，写错可能直接导致中断无法触发；更推荐使用 smp_affinity_list（输出十进制 CPU 编号，更容易阅读和校验）
• 某些中断（如 BMC、老旧 RAID 卡）会被固件锁定，写入时可能报 Operation not permitted；动手前先执行 ls -l /proc/irq//，确认是否存在 smp_affinity* 文件
• 在 NUMA 架构下，网卡 IRQ 应优先绑定到与该网卡直连的 CPU 节点，可通过 lscpu 与 lspci -vv -s $(ethtool -i eth0 | grep 'bus-info' | awk '{print $2}') 交叉核对 NUMA node 信息

中断耗时必须用 trace-cmd，不是 perf

/proc/interrupts 只能提供总量统计，遇到系统卡顿、延迟抖动这类问题时，必须进一步查看单次 handler 从入口到出口的纳秒级耗时：

• 先确认当前内核支持 ftrace：grep CONFIG_IRQSOFF_TRACER /boot/config-$(uname -r) 返回 y 或 m
• 抓取 5 秒数据：trace-cmd record -e irq:irq_handler_entry -e irq:irq_handler_exit -T 5
• 分析时重点盯住 delta 字段（单位纳秒），如果超过 100μs，就值得怀疑驱动在中断上下文里做了不该做的重操作（例如大块数据 memcpy）
• 不要使用 perf record -e irq:*——它无法保证入口和出口严格配对，采样精度也不足，因而不能准确计算真实的 handler 耗时

真正难处理的地方，从来不只是看哪一行数字涨得最快，而是要分清这波增长究竟属于硬件层面的抖动、驱动代码中的 bug，还是系统配置没有调优好。表面上看，这三类问题的症状往往非常相似，但一旦方向判断错误，后续排障和修复就很容易彻底跑偏。以 nvme0n1 中断突然飙升为例，背后可能是 PCIe 链路误报，也可能是驱动没有启用 polling mode，甚至还有可能是 SSD 固件本身出现异常。因此，这类 Linux 硬件中断问题不能依赖单点结论，必须结合 trace-cmd、/proc/softirqs 和 smartctl 进行交叉验证，少看任何一项都不够稳妥。