第四章：命令提交与调度故障

好，咱们今天聊聊驱动层里最让人头疼的一类问题——命令提交与调度故障。说白了，就是CPU把活儿派下去了，GPU却迟迟不干，或者干脆卡死了。我这些年调试下来，发现这类问题占了驱动故障的六成以上。

4.1 Job超时：GPU“罢工”了

Job超时，是驱动层最常见的报错。你想想看，驱动往硬件里扔了一个任务，等了半天没反应，最后超时机制触发了。这时候驱动会怎么做？一般会重置GPU，或者干脆触发一个panic。

为什么会超时？我个人习惯把原因分成三类：

• 任务本身太重：比如一个compute shader循环次数太多，或者纹理采样太密集。我在项目中遇到过，一个粒子系统每帧要更新几十万粒子，结果GPU直接超时。
• 硬件卡死：比如某个ALU单元挂了，或者纹理单元死锁。这种情况比较少见，但一旦出现，基本就是硬件bug。
• 驱动调度问题：比如命令缓冲区没及时提交，或者同步信号量没处理好。嗯，这里要注意，很多时候超时不是GPU慢，而是驱动没把活儿派下去。

我曾经遇到过一个案例：某款芯片在跑特定游戏时，每30秒必超时一次。查了三天，最后发现是驱动里一个环形缓冲区的写指针没更新，导致命令一直没发出去。你想想看，这种问题多隐蔽。

4.2 Ring Buffer溢出：缓冲区“撑爆”了

Ring Buffer，环形缓冲区，是CPU和GPU之间传递命令的通道。驱动往里面写命令，GPU从里面读命令。如果驱动写得太快，GPU读得太慢，缓冲区就满了——这就是溢出。

溢出的典型表现：驱动调用submit时返回-ENOSPC，或者直接卡死在等待缓冲区空闲的循环里。

我建议你在设计驱动时，一定要给Ring Buffer留够余量。怎么留？看几个关键参数：

参数	说明	建议值
缓冲区大小	总字节数	至少4KB，复杂场景建议16KB
写指针追赶阈值	写指针距离读指针多远时触发等待	缓冲区大小的75%
最大命令长度	单条命令的最大字节数	不超过缓冲区大小的50%

还有一个容易忽略的点：Ring Buffer的读写指针必须是原子操作。我见过一个驱动，写指针更新用了非原子操作，结果GPU读到一半的数据，直接崩溃。嗯，这种问题查起来特别费劲。

4.3 硬件调度器死锁：GPU“僵住了”

硬件调度器死锁，是最高级的故障。说白了，就是硬件内部的调度逻辑卡死了，所有任务都停在那里，谁也动不了。

死锁的典型场景：

• 资源竞争：两个任务同时要使用同一个纹理单元，但硬件没做好互斥。
• 依赖循环：任务A等任务B完成，任务B等任务A完成——死循环了。
• 中断丢失：GPU发了一个完成中断，但CPU没收到，导致驱动一直等。

我记得有一次，某款芯片在跑多线程渲染时，经常死锁。查了硬件文档才发现，硬件调度器对同一个渲染管线的并发任务数有限制，超过4个就会死锁。驱动里加了个限制，问题就解决了。

怎么预防死锁？我建议你在驱动里加一个超时检测机制。比如，每个任务提交后，启动一个定时器。如果超过一定时间还没完成，就主动重置调度器。虽然粗暴，但有效。

4.4 实战：一个典型的调度故障排查

好，咱们来个实战案例。假设你遇到了这样一个问题：

• 现象：跑某个benchmark时，GPU偶尔卡死，驱动报“Job timeout”
• 频率：大约每10次运行出现1次
• 环境：Linux + DRM驱动 + 某款自研GPU

我的排查步骤：

1. 先看日志：dmesg里有没有Ring Buffer溢出的提示？如果有，先查缓冲区大小。
2. 再看硬件状态：通过debugfs读取调度器状态寄存器，看看有没有任务卡住。
3. 加打印：在submit和complete路径上加时间戳，看看是提交慢还是执行慢。
4. 复现并抓取：用ftrace抓取调度事件，看看有没有异常的中断或信号量。

我那次排查的结果是：驱动在提交命令时，忘了更新Ring Buffer的写指针。GPU读到的命令是旧的，自然就卡住了。修复方法就一行代码，但查了整整两天。

4.5 总结与建议

好，这一章的内容就这些。我最后给你几个实用建议：

• Ring Buffer一定要留余量：别抠门，多给点空间。
• 加超时机制：不管是Job还是调度器，超时了就要处理。
• 多打日志：尤其是提交和完成路径，关键时刻能救命。
• 别怕重置：如果GPU卡死了，果断重置，别死等。

嗯，这一章就到这里。下一章咱们聊聊内存管理故障，那又是另一片天地了。