Linux 中断机制:从硬件响应到驱动调试

关注+星标公众号，不容错过精彩

作者：HywelStar

做嵌入式 Linux 开发，中断几乎绕不开。

按键按下需要中断，触摸屏有数据需要中断，传感器 Data Ready 需要中断，UART 收到数据、DMA 搬运完成、网卡收到数据，同样都离不开中断。

驱动里面也经常能看到：

request_irq()devm_request_irq()devm_request_threaded_irq()

以及：

irq_handler()

表面上看，中断好像就是：

硬件发生事件    ↓Linux收到中断    ↓执行irq_handler()

但实际上，一次真正的硬件中断背后连接着：

外部设备   ↓GPIO / 外设控制器   ↓Interrupt Controller   ↓CPU   ↓Linux IRQ 子系统   ↓设备驱动

而在实际驱动开发中，中断又经常是问题比较集中的地方：

中断不进中断只进一次中断不停地进CPU占用突然升高多核CPU只有一个核特别忙

所以理解中断，不能只记住几个 API，更重要的是搞清楚：

一个硬件事件到底是怎么走到 Linux 驱动里的，以及出了问题以后应该怎样一级一级往下查。

1. 什么是中断

1.1 为什么要有中断

CPU 要知道外设有没有事件，最简单的方法其实是轮询。

例如检测一个 GPIO：

while (1) {    if (gpio_get_value(KEY_GPIO) == 0)        handle_key();    msleep(10);}

CPU 会不断去问：

按键按了吗？有数据了吗？设备有事件了吗？

这种方式实现简单，但效率并不高。

很多外设绝大部分时间都没有事情发生，如果 CPU 一直去读它的状态，就会浪费很多处理时间。

中断的思路刚好相反：

平时：CPU继续执行自己的任务事件发生：设备主动通知CPU

所以中断可以简单理解成：

当某个事件发生时，硬件主动通知 CPU，让 CPU 暂时处理这个事件。

这也是为什么很多要求快速响应的硬件都会使用中断。

1.2 硬中断和软中断

Linux 中断相关的概念很多：

Hard IRQSoftIRQTop HalfBottom HalfThreaded IRQWorkqueue

刚开始很容易混在一起。

其实首先记住一个原则就可以：

硬件中断阶段只做必须马上完成的事情，复杂工作尽量放到后面。

1.2.1 硬中断

例如：

GPIO电平变化DMA传输完成网卡收到数据UART收到数据Timer到期

硬件产生 IRQ：

Hardware   ↓Interrupt Controller   ↓CPU

CPU 会暂时打断当前正在执行的代码，进入 Linux 的中断处理流程。

这就是通常所说的：

Hard IRQ

硬中断有几个很明显的特点：

响应快不能长时间运行不能随便Sleep应该尽快退出

因为 CPU 原本可能正在执行某个用户程序：

Application    │    ├──── IRQ    │      ↓    │   Handler    │      ↓    └──── 返回

如果 Handler 里面做了大量耗时操作，整个系统都会受到影响。

所以硬中断里通常只做：

读取状态清除中断保存必要数据安排后续处理

1.2.2 软中断

Linux 里还有：

SoftIRQ

这里很容易被名字误导。

软中断并不是外部设备产生了另外一种“软件中断信号”。

它更像是：

Linux 内核把一部分不需要立刻完成的工作，延迟到后面继续处理。

例如网卡收到一个数据包：

网卡收到数据    ↓硬件IRQ    ↓快速处理硬件    ↓NET_RX_SOFTIRQ    ↓继续处理网络协议栈

如果所有网络协议处理都放在硬中断里面完成，中断时间会非常长。

因此传统上会把中断处理分成：

Top Half   ↓Bottom Half

也就是：

上半部下半部

上半部处理紧急工作，下半部完成后续处理。

1.3 Threaded IRQ 和 Workqueue

现在做普通设备驱动时，更常见的还有：

Threaded IRQWorkqueue

比如一个 I2C Sensor 产生中断以后，需要继续通过 I2C 读取寄存器。

这类操作不适合全部塞到硬中断 Handler 中。

于是可以使用：

devm_request_threaded_irq(dev,                          irq,                          NULL,                          sensor_irq_thread,                          IRQF_ONESHOT,                          "sensor",                          data);

然后：

static irqreturn_t sensor_irq_thread(int irq, void *data){    read_interrupt_status();    read_sensor_data();    return IRQ_HANDLED;}

整体可以理解成：

硬件事件   ↓Hard IRQ   ↓快速响应   ↓Threaded IRQ / Workqueue / SoftIRQ   ↓完成后续处理

其中 SoftIRQ 更多由 Linux 网络、Timer、RCU 等核心子系统使用。

而普通外设驱动中：

Threaded IRQWorkqueue

更加常见。

2. 一个中断到底是怎么走到驱动里的

下面用一个比较典型的 I2C Sensor 举例。

假设一个 IMU 接到 SoC：

              SoC               │SDA ───────────┤SCL ───────────┤INT ───────────┤ GPIO3_IO15               │             Sensor

Sensor 通过 I2C 和 CPU 通信。

同时还有一个：

INT

中断引脚。

当 Sensor 采集到一组新数据以后，把 INT 从高电平拉到低电平：

HIGHHIGHHIGHLOW   ← Data Ready

硬件真正做的事情，其实只是：

1 → 0

它并不知道 Linux，更不知道什么 irq_handler()。

2.1 从 INT Pin 到中断控制器

INT 接到：

GPIO3_IO15

GPIO Controller 可以配置：

上升沿下降沿高电平低电平

假设配置为下降沿。

当：

HIGH → LOW

GPIO Controller 检测到以后，就认为 GPIO15 发生了中断。

于是：

Sensor   ↓INT Pin   ↓GPIO Controller

外部电平变化变成了 SoC 内部的中断事件。

对于 ARM SoC，后面一般还有：

GICGeneric Interrupt Controller

SoC 中可能有很多中断源：

UARTI2CSPIUSBGPIODMACameraGPUVPUNPUTimer...

这些中断最终由 GIC 统一管理。

所以整个硬件链路可以理解成：

Sensor   ↓GPIO Controller   ↓GIC   ↓CPU

GIC 还会负责：

中断优先级中断屏蔽中断路由分配到哪个CPU

2.2 CPU 收到中断以后

CPU 收到 IRQ 后，会暂停当前执行流程，保存必要的现场，然后进入 CPU 架构定义好的异常入口。

之后 Linux 中断子系统接管：

CPU IRQ Exception        ↓Linux IRQ Entry        ↓Interrupt Controller Driver        ↓IRQ Domain        ↓Linux IRQ        ↓Generic IRQ        ↓Driver Handler

最终才真正执行：

sensor_irq_handler()

或者：

sensor_irq_thread()

所以从一个真实硬件事件到驱动，大概经历：

Sensor Data Ready       ↓INT Pin       ↓GPIO Controller       ↓GIC       ↓CPU       ↓Linux IRQ       ↓Driver Handler

2.3 Device Tree 和 request_irq() 在其中做什么

例如设备树：

sensor@68 {    compatible = "vendor,my-sensor";    reg = <0x68>;    interrupt-parent = <&gpio3>;    interrupts = <15 IRQ_TYPE_EDGE_FALLING>;};

它实际上是在描述：

这个Sensor   ↓中断属于GPIO3   ↓GPIO15   ↓下降沿触发

Linux 根据这些硬件信息建立 IRQ 映射。

驱动最终可能得到：

irq = platform_get_irq(...);

或者：

irq = gpiod_to_irq(...);

例如：

irq = 123

这里的 123 通常是 Linux IRQ Number。

它和：

GPIO NumberHardware IRQGIC Interrupt ID

并不一定相同。

Linux 中间通过 IRQ Domain 等机制做映射。

随后驱动调用：

request_irq(irq,            sensor_irq_handler,            flags,            "sensor",            data);

可以简单理解为：

把 Linux IRQ 和自己的处理函数绑定起来。

于是以后 IRQ 123 到来：

IRQ 123   ↓Linux Generic IRQ   ↓找到Driver Handler   ↓sensor_irq_handler()

3. 驱动收到中断以后做什么

假设 Sensor 产生 Data Ready 中断。

Handler 里面可能做：

static irqreturn_t sensor_irq_thread(int irq, void *data){struct sensor_data *sensor = data;    read_interrupt_status(sensor);    read_sensor_data(sensor);    return IRQ_HANDLED;}

通常包括几个动作：

读取Interrupt Status确认中断原因清除Interrupt Flag读取数据通知后续模块

其中：

清中断是非常重要的一步。

很多芯片产生低电平中断以后：

INT = LOW

只有读取某个状态寄存器，或者写：

INT_CLEAR

以后才会恢复：

INT = HIGH

如果驱动没有正确清除：

IRQ进入   ↓Handler执行   ↓返回   ↓INT仍然有效   ↓再次IRQ

最终可能出现：

Interrupt Storm

也就是中断风暴。

反过来，如果中断清除方式或者触发类型配置不正确，也可能出现：

只进一次中断

这种情况。

4. 中断调试

实际开发中，经常遇到：

request_irq()返回成功

但硬件触发以后：

驱动完全没反应

这时候最容易做的一件事情就是：

printk("irq enter\n");

但如果连 Handler 都没有进入，这个日志其实帮不了太多。

调试中断真正有效的方法是：

沿着中断链路一级一级确认，它到底断在什么位置。

4.1 先确认硬件信号

第一步通常不是 Linux，而是硬件。

直接用：

示波器逻辑分析仪

观察 INT Pin。

例如预期：

HIGH → LOW

如果实际没有任何变化，那么 Linux 后面的部分都不用查。

优先确认：

芯片内部IRQ有没有EnableInterrupt Mask有没有打开INT Pin配置上拉/下拉硬件连接设备是否真正产生事件

这是驱动调试里非常重要的一条经验：

先证明问题已经到达软件这一侧。

4.2 再确认 Pinmux、DTS 和 IRQ 注册

如果引脚上已经有波形，下一步看：

PinmuxGPIODTSIRQ

一个 SoC Pin 往往能够复用成：

GPIOUARTI2CSPIPWM

外部虽然有电平变化，如果 Pinmux 配错，GPIO Controller 仍然可能收不到。

可以检查：

/sys/kernel/debug/pinctrl/

具体路径根据平台不同会有所差异。

然后检查设备树：

interrupt-parentinterruptsGPIO编号Trigger Type

尤其注意：

IRQ_TYPE_EDGE_RISINGIRQ_TYPE_EDGE_FALLINGIRQ_TYPE_LEVEL_HIGHIRQ_TYPE_LEVEL_LOW

接下来确认驱动到底拿到了哪个 IRQ：

dev_info(dev, "irq = %d\n", irq);

并检查：

ret = devm_request_irq(...);if (ret)    dev_err(dev, "request irq failed: %d\n", ret);

不能看到 request_irq() 就默认一定成功。

4.3 /proc/interrupts 是最重要的工具之一

中断注册以后：

cat /proc/interrupts

可能看到：

           CPU0       CPU1       CPU2       CPU3 42:       1020          0          0          0  GIC   uart123:        100          0          0          0  GPIO  sensor

IRQ Number中断次数处理CPUInterrupt Controller设备名称

调试时甚至可以直接：

watch -n 1 cat /proc/interrupts

然后触发设备。

如果：

100101102

说明 Linux 已经收到 IRQ。

这时候问题范围已经缩小到：

HandlerThreaded IRQ驱动后续逻辑

如果数字一直不变：

100100100

说明应该继续往前查：

硬件PinmuxGPIODTSTrigger TypeInterrupt Controller

这一招实际上非常重要。

因为它能帮我们快速判断：

问题是在 IRQ 到达 Linux 之前，还是之后。

4.4 Handler  printk

低频中断调试时：

dev_info(dev, "irq enter\n");

当然非常直接。

但如果是：

CameraEthernetDMA高速串口

这种高频 IRQ，在 Handler 里面不断打印日志，很可能让问题变得更严重。

甚至出现：

中断很多+printk很多=系统直接变卡

这时候更适合用 Linux tracing。

例如查看 IRQ Trace Event：

cat /sys/kernel/debug/tracing/available_events | grep irq

可能看到：

irq:irq_handler_entryirq:irq_handler_exit

可以开启：

echo 1 > /sys/kernel/debug/tracing/events/irq/irq_handler_entry/enableecho 1 > /sys/kernel/debug/tracing/events/irq/irq_handler_exit/enableecho 1 > /sys/kernel/debug/tracing/tracing_on

然后查看：

cat /sys/kernel/debug/tracing/trace

哪个IRQ进来了什么时候进入什么时候退出在哪个CPU执行

如果还要分析 Handler 执行时间、关中断时间过长等问题，可以继续使用：

ftracetrace-cmdperfirqsoff tracer

所以实际调试工具可以逐渐从：

printk   ↓/proc/interrupts   ↓ftrace / tracepoint   ↓perf / latency分析

一步一步深入。

5. 几种非常典型的中断故障

5.1 中断完全不进

可以按照下面顺序查：

设备有没有产生INT？      ↓示波器有没有波形？      ↓Pinmux是否正确？      ↓DTS是否正确？      ↓IRQ Number是否正确？      ↓request_irq是否成功？      ↓/proc/interrupts是否增加？      ↓Handler是否执行？

如果 /proc/interrupts 都没有增加，就不要急着查 Handler。

5.2 中断只进一次

重点检查：

中断状态有没有ClearINT脚有没有恢复Edge / Level配置Trigger Type设备Interrupt Status

例如硬件本来要求：

读状态寄存器后清中断

结果驱动没有读。

或者硬件是低电平触发，却配置成错误的边沿方式。

都会造成这种问题。

5.3 中断不停地进

如果：

cat /proc/interrupts

看到数字：

100100010000100000

快速增长，同时 CPU 占用异常，就要怀疑：

Interrupt Storm

常见原因包括：

中断没有ClearINT脚一直有效Trigger Type错误硬件异常共享IRQ处理错误

这种时候最好马上减少 Handler 里面的打印。

5.4 网络等场景还要看 SoftIRQ

如果调试：

NetworkTimerBlock IORCU

仅看 /proc/interrupts 还不够。

还可以：

cat /proc/softirqs

HITIMERNET_TXNET_RXBLOCKTASKLETSCHEDRCU

例如网络负载很高时：

NET_RX

可能增长非常快。

说明 CPU 不一定忙在硬 IRQ，而可能大量时间消耗在后续 SoftIRQ 处理中。

所以：

/proc/interrupts+/proc/softirqs

一起看，会更加完整。

6. 中断也是有成本的

中断可以说是一种资源。

但现代系统里，它“宝贵”的地方，并不只是 IRQ Number 数量有限。

真正需要关注的是：

CPU时间上下文切换Cache影响实时性功耗

每次中断到来：

CPU正在执行任务      ↓IRQ      ↓保存现场      ↓执行Handler      ↓可能触发SoftIRQ/Thread      ↓恢复原任务

这些都是有成本的。

6.1 高速设备不能一个字节一个中断

假设数据速率：

100 MB/s

如果一个字节触发一次 IRQ：

约1亿次IRQ/s

CPU 基本什么事情都不用做了。

所以高速设备一般都会配合：

FIFODMARing BufferBatchInterrupt Coalescing

例如：

设备产生一批数据      ↓DMA搬到Memory      ↓达到一定数量      ↓产生一次IRQ

而不是：

一个数据 ↓一个IRQ

所以驱动设计中：

中断不是越多越好。

而是需要在：

响应速度CPU占用吞吐量功耗实时性

之间找到合适的平衡。

6.2 多核系统还要看 IRQ Affinity

现在很多 SoC 都是：

CPU0CPU1CPU2CPU3

查看：

cat /proc/interrupts

有时会发现：

             CPU0    CPU1    CPU2    CPU3eth0        80000       0       0       0camera      50000       0       0       0sensor       2000       0       0       0

大量 IRQ 全部压在 CPU0。

最终表现可能就是：

CPU0很忙其他CPU却很空

这时候就需要关注：

IRQ Affinity

例如：

/proc/irq/<IRQ>/smp_affinity# 比如# cat /proc/irq/196/smp_affinity_list0-3

对于：

网卡CameraPCIe高速DMA

等场景，IRQ 分配在哪个 CPU 上，可能直接影响整个系统性能。

7. 总结

Linux 中断表面上并不复杂。

驱动中可能只是：

request_irq();

加上：

irq_handler();

但这两行代码背后实际上连接了：

硬件事件   ↓INT Pin   ↓GPIO / Peripheral Controller   ↓Interrupt Controller   ↓CPU   ↓Linux IRQ   ↓Driver

而 Linux 又通过：

Hard IRQSoftIRQThreaded IRQWorkqueue

把不同的工作安排到合适的阶段处理。

真正做驱动开发以后，我觉得比记住几个 API 更重要的是建立这样一种调试思路：

先看硬件信号     ↓再看Pinmux / DTS     ↓再看IRQ有没有进入Linux     ↓再看Handler     ↓最后看业务逻辑

以后碰到：

中断不进中断只进一次中断一直进CPU占用很高某个CPU特别忙

就可以沿着这条链路一点点往下缩小范围。

而不是一遇到问题就：

加printk   ↓没看到   ↓继续加printk

中断本身并不可怕。

真正麻烦的是：

不知道这个中断现在走到哪一层了。

只要把硬件信号到 Linux 驱动这条链路建立起来，中断问题往往就会从一个“很玄学的问题”，变成一个可以一级一级验证的工程问题。