林纳斯与 AI 找到 Intel Xe 显卡驱动的一行修复

一个看似只需改动一行代码的 Intel Xe 显卡驱动 bug，背后却是一场“地狱级调试”。Linus Torvalds 表示，AI 助手在排查过程中“提供了巨大的帮助”，但也曾多次断言问题“不可能解决”，甚至建议直接写报告放弃。最终，林纳斯和 AI 一起经过 24 个调试补丁版本、18 次内核启动测试，才锁定了真正的原因。

一行代码改了什么？

问题出在 Intel Xe 驱动对普通显存与保留的 flat Compute Command Streamer（CCS）存储区域边界的计算上。概念上，相关操作从：

round_up(value, SZ_128K)

改成了：

round_down(value, SZ_128K)

这里的数值代表的是“可供显存分配器使用的内存在哪里结束”，而不是一个需要向上对齐的起始地址。向上取整会把真实边界与取整后边界之间的一小段区域误标记为可用显存；但这部分空间实际上属于 CCS 压缩元数据。向下取整则能让分配器始终停留在安全边界以内。

错误的取整为何会破坏 GPU 内存？

当显存分配器把 CCS 存储误认为普通 VRAM 后，普通分配就可能覆盖 GPU 使用的压缩元数据。被破坏的数据包括与页表相关的内容，最终表现为画面异常、黑屏以及 GDM 显示管理器不断重启。在 Intel Battlemage G21 硬件上，这一问题会让图形系统陷入反复启动失败的循环。

因此，这并不只是一个简单的算术错误，更是一个语义错误：代码把一个表示“可用内存终点”的上限，当成了适合向上对齐的地址。也正因为如此，最后的补丁很小，定位过程却异常困难。

24 个补丁和 18 次启动如何缩小范围

Torvalds 将整个过程称为一次“来自地狱的调试会话”。他与 AI 助手不断加入和修改针对性的调试插桩，追踪驱动中的显存计算，并比较硬件报告的 CCS 位置与传递给 VRAM 分配器的边界。经过 24 个调试补丁版本和 18 次重启、测试，错误的对齐方向才逐渐浮出水面。

反复启动测试并非多余。这个故障最终出现在硬件和显示系统层面，而不是一眼就能从某行源代码中看出的异常。每次实验都帮助排除其他可能性，确认问题确实与显存分配边界有关。

AI 加快了排查，但没有替林纳斯做决定

在这次工作中，AI 更像一个交互式调试助手，而不是自动写补丁的代理。它帮助提出插桩方案、追踪驱动代码路径，并分析连续实验的输出，从而减少了重复性工作。

但它并不可靠。Torvalds 说，AI 曾多次得出问题无法解决的结论，甚至建议停止调查、改写报告。真正让排查继续推进的是林纳斯：他选择下一步实验，识别错误解释，理解偏移量在显存分配模型中的含义，并最终判断哪一行代码违反了边界语义。

这正是本次事件最值得注意的分工：AI 负责生成可能性和执行机械性任务，专家负责提供上下文、设计可证伪的测试、坚持追查并作出最终判断。

修复已进入上游，但稳定版信息仍需确认

Torvalds 亲自编写并提交了 Intel Xe 驱动修复，补丁进入了上游 Linux 内核。现有报道显示，受影响的维护中稳定内核系列预计会按照通常流程获得回移（backport），但目前提供的资料并不能可靠确认具体稳定版本或发布时间。

因此，现在不宜仅凭现有证据点名某些具体版本。使用相关硬件的用户，应以发行版或内核维护者公告为准，确认所安装的内核是否已经包含该修复。

这对 AI 辅助内核开发意味着什么？

这起事件并不是对“AI 自动生成内核代码”的全面背书。它展示的是一种更谨慎、也更可行的用法：由熟悉子系统的专家主导调查，让 AI 加速调试循环，同时由人负责假设、实验设计、代码审查和最终补丁。

这与未经测试、未经解释就向维护者发送 AI 生成的补丁或漏洞报告，完全是两回事。Linux 内核维护者曾形容机器生成提交如同“猛烈来袭”；staging 子系统和网络子系统的维护者也都报告了低价值、重复或缺乏理解的 AI 提交带来的压力。

外界经常提到的“提交量增长 2700%”则应谨慎看待。现有资料没有明确说明这一数字的统计口径、时间范围，或它究竟指全部提交、某个子系统还是某类补丁。更稳妥的结论是：AI 降低了生成代码和报告的成本，但筛选、验证和审查这些内容的工作，仍然落在人工维护者身上。

Torvalds 也曾表示，Linux 并不排斥 AI 工具，尤其是在代码审查等场景中，AI 确实可能有用。 这次 Intel Xe 调试则清楚展示了边界：AI 可以成为严谨工程流程中的加速器，却不能替代子系统知识、可复现测试，也不能替人承担最终责任。

最后的补丁只有一行。真正困难的部分，是找出应该改动的那一行，并在 AI 说“找不到答案”时，仍然继续验证。