1. 那个凌晨三点的事故现场
凌晨三点十五分，产线控制系统的监控大屏突然开始疯狂刷屏。原本平稳运行的六轴机械臂突然像发疯一样抽搐，传送带上的工件开始堆积碰撞。值班工程师的电话瞬间被打爆——这不是普通的程序崩溃，而是整个车间的设备集体失控。
当我赶到现场时，内核日志里已经塞满了数千条中断超时警告。irq 17: nobody cared!的报错像病毒一样蔓延。重启系统后问题暂时消失，但我知道这不过是暴风雨前的宁静。果然，三小时后，同样的问题再次爆发。
这次事故让我付出了惨痛代价：产线停工8小时，报废了价值二十万的精密部件。但更重要的是，它逼着我彻底搞懂了Linux中断处理中"顶半部"（top half）和"底半部"（bottom half）的设计哲学。现在回想起来，那次中断风暴就像一记重拳，打碎了我对中断处理的肤浅认知。
2. 中断处理的二分法：为什么要有顶半部和底半部？
2.1 中断响应的两难困境
当硬件中断触发时，内核需要立即响应——这是中断的本质要求。但现代复杂设备的中断处理往往需要完成大量工作：读取设备寄存器、数据拷贝、协议解析、状态更新...如果全部在中断上下文中完成，会导致两个致命问题：
- 中断屏蔽时间过长：其他中断无法响应，高优先级设备被阻塞
- 调度延迟暴增：用户空间进程得不到CPU时间，系统表现为"卡死"
RH850等现代MCU的中断控制器(INTC)通常支持多级优先级。但在我们的案例中，即使配置了优先级，依然出现了级联故障。这是因为所有中断服务例程(ISR)都在做繁重的数据处理。
2.2 二分法的工程智慧
Linux的解决方案是将中断处理拆分为两个阶段：
c复制// 典型的驱动中断处理模板
irqreturn_t xxx_interrupt(int irq, void *dev_id)
{
/* 顶半部：紧急任务 */
read_registers();
ack_interrupt();
schedule_work(&my_work); // 触发底半部
return IRQ_HANDLED;
}
void xxx_work_handler(struct work_struct *work)
{
/* 底半部：耗时任务 */
process_data();
update_status();
wake_up_userspace();
}
顶半部(top half)的黄金法则：
- 必须在中断上下文中执行
- 只做最紧急的硬件操作
- 绝对禁止：
- 内存分配（可能触发页错误）
- 用户空间数据访问（可能缺页）
- 任何可能休眠的操作（mutex_lock等）
底半部(bottom half)的灵活空间：
- 在进程上下文中执行
- 可以休眠、调度、使用完整内核API
- 适合复杂数据处理和系统调用
3. 那次中断风暴的病理分析
3.1 灾难的伏笔
回顾事故前的驱动代码，我们发现这样的危险结构：
c复制// 错误示范！不要在顶半部做的事情全做了
static irqreturn_t faulty_isr(int irq, void *dev_id)
{
struct device *dev = dev_id;
struct packet *pkt = kmalloc(sizeof(*pkt), GFP_KERNEL); // 可能阻塞
usb_fill_bulk_urb(dev->urb, dev->udev, pipe,
dev->buffer, size, complete_cb, dev);
usb_submit_urb(dev->urb, GFP_KERNEL); // 更可能阻塞
parse_protocol(dev->buffer); // 耗时操作
update_stats(dev); // 锁操作
return IRQ_HANDLED;
}
这段代码犯了几乎所有顶半部的禁忌：
- 内存分配使用
GFP_KERNEL标志（可能触发直接内存回收） - USB URB提交可能因资源不足等待
- 协议解析消耗大量CPU时间
- 统计更新使用了未标记为
_irq的锁函数
3.2 风暴的形成过程
当产线设备负载突增时：
- 第一个中断触发，进入faulty_isr()
- kmalloc()因内存压力进入直接回收路径，耗时15ms
- 在此期间，其他设备中断被屏蔽
- 硬件中断控制器丢失中断信号（RH850的IRQ FIFO溢出）
- 恢复执行后，usb_submit_urb()又因URB池耗尽等待
- 最终导致中断响应延迟超过设备超时阈值（约100ms）
此时设备检测到超时，触发硬件复位。但复位过程本身又会产生新中断，形成恶性循环——这就是典型的中断风暴(interrupt storm)。
4. 正确的打开方式：现代Linux底半部机制选型
4.1 可选方案对比
| 机制 | 执行上下文 | 调度方式 | 延迟特性 | 适用场景 |
|---|---|---|---|---|
| Tasklet | 软中断上下文 | 串行执行 | 低延迟(μs级) | 简单快速的小任务 |
| Workqueue | 进程上下文 | 线程池调度 | 中等(ms级) | 可能休眠的操作 |
| Threaded IRQ | 专用内核线程 | 实时调度 | 可配置 | 需要确定性的处理 |
| SoftIRQ | 软中断上下文 | 并行执行 | 最低 | 网络/块设备等核心层 |
4.2 我们的修复方案
针对产线设备的特点（实时性要求高、数据处理复杂），最终采用线程化中断(threaded IRQ)+工作队列的混合方案：
c复制// 正确的顶半部：仅做最必要的硬件操作
static irqreturn_t safe_hardware_isr(int irq, void *dev_id)
{
struct device *dev = dev_id;
u32 status = readl(dev->reg_base + REG_STATUS);
if (!(status & INT_MASK))
return IRQ_NONE;
writel(status, dev->reg_base + REG_STATUS); // 清中断
dev->raw_data = readl(dev->reg_base + REG_DATA);
return IRQ_WAKE_THREAD; // 唤醒线程化处理
}
// 线程化底半部：可以安全使用各种内核API
static irqreturn_t safe_threaded_isr(int irq, void *dev_id)
{
struct device *dev = dev_id;
struct payload *pl = &dev->payload;
if (decode_protocol(dev->raw_data, pl)) {
queue_work(dev->wq, &dev->post_work); // 复杂工作推入工作队列
}
return IRQ_HANDLED;
}
// 工作队列处理：最耗时的操作
static void post_process_work(struct work_struct *work)
{
struct device *dev = container_of(work, struct device, post_work);
generate_report(dev);
notify_userspace(dev);
}
关键改进点：
- 顶半部执行时间从原来的>100ms降低到<5μs
- 硬件相关操作与业务逻辑彻底解耦
- 工作队列采用专用高优先级线程池（
WQ_HIGHPRI） - 为RH850配置了正确的IRQ触发类型（边沿触发优于电平触发）
5. 调试中断问题的实战工具箱
5.1 关键诊断命令
bash复制# 查看中断统计
watch -n1 "cat /proc/interrupts | grep -E 'CPU0|eth0'"
# 检测软中断负载
watch -n1 'cat /proc/softirqs'
# 追踪特定中断
trace-cmd record -e irq_handler_entry -f 'irq==17'
# 测量中断延迟
cyclictest -t1 -p80 -n -i 1000 -l 10000
5.2 内核调试选项
makefile复制CONFIG_DEBUG_SHIRQ=y # 检测共享中断问题
CONFIG_IRQSOFF_TRACER=y # 跟踪中断关闭时间
CONFIG_LOCKDEP=y # 中断上下文锁依赖检测
5.3 我们的诊断过程
-
锁定异常中断源：
bash复制# 发现USB中断计数异常增长 grep usb /proc/interrupts | awk '{print $2,$NF}' -
测量顶半部延迟：
c复制// 在ISR中加入时间测量 ktime_t start = ktime_get_ns(); // ...ISR操作... pr_err("ISR latency: %lld ns\n", ktime_get_ns() - start); -
检测调度延迟：
bash复制# 使用ftrace记录调度事件 echo 1 > /sys/kernel/debug/tracing/events/sched/sched_switch/enable cat /sys/kernel/debug/tracing/trace_pipe | grep -A10 'usb_isr'
那次事故后，我们建立了中断处理的代码审查清单：
- [ ] 顶半部是否超过10μs执行时间？
- [ ] 是否有内存分配（特别是
GFP_KERNEL）？ - [ ] 是否调用了可能阻塞的函数？
- [ ] 共享中断是否返回
IRQ_NONE？ - [ ] 底半部机制是否匹配任务特性？
现在当新人提交驱动代码时，我总会问："你的中断处理能经受住产线满负荷冲击吗？"——这是用二十万买来的教训。