夜雨聆风
56岁的“Linux之父”Linus Torvalds已经很少亲自下场给驱动写代码了。
作为开源世界的终极裁判，他这几年的日常是坐在数万封邮件构成的洪流前，审阅全球顶尖工程师的代码，合并分支，顺便在邮件列表里用犀利的辞藻把写烂代码的开发者喷得体无完肤。
但就在几天前，这位脾气火爆的技术教皇，破天荒地在Linux 7.3主线中合入了一份亲自操刀的显卡驱动补丁。
在这场被他称为“来自地狱的调试（debug session from hell）”中，协助他的是一个大语言模型（AI）。
而在排查陷入绝境时，AI曾不止一次判定问题“不可能、无解”，建议写份Bug报告收工。
Linus的回应落在行动上：接着测。
整整24个调试补丁，18次内核启动。当真相最终大白时，整个开源社区与AI圈子同时被震住了，核心修复，仅仅落在一行代码上。
这场由人类顶级大脑与AI共同上演的“幽灵悬案”，不仅揭开了新一代GPU架构的隐秘深坑，更把当前风靡全网的“AI编程神话”底裤，扒得干干净净。
显存里的“幽灵谋杀案”
故事从一块崭新的Intel Battlemage G21（第二代锐炫架构）显卡说起。
Linus将这块显卡插上测试机，按下电源键。屏幕亮起，内核加载，一切看似平稳然而，就在图形桌面管理器（GDM）即将拉起画面的瞬间，黑屏了。
▲ Linus在GitHub提交记录中写下的“地狱级调试”自述
诡异的是，机器并没有死机后台的SSH依然能连，CPU风扇还在呼呼转，系统核心运转如常，但显示管理器就像撞了鬼一样，陷入了“启动，崩溃，重启，再崩溃”的无限死循环。
要理解这里发生了什么，可以用住宅区来打个比方：
显卡上的显存（VRAM），就像是一片巨大的规整住宅区，每一户都有精确的门牌号（页表）。操作系统要在显存里画图，必须先查门牌号，找到对应的地皮。但是，现代显卡为了省带宽，自带了一套“硬件压缩引擎”。这个引擎工作时，必须在显存最边缘留出一小块私家后院，用来堆放压缩元数据，这块地在架构中被称为“扁平CCS（flat CCS）”。按照规矩，驱动程序必须在显存地图上把这块地圈为禁区，绝对不能分给普通程序。
然而，这台机器上的Intel Xe驱动，在计算禁区边界时犯了一个灾难性的错误。
驱动在读取硬件基址时，发现地址没有对齐，于是自作聪明地执行了一句：向上取整（round_up）。
这一“向上”，把原本属于压缩引擎的私家后院，硬生生削掉了半截，并大摇大摆地向系统宣告：“后面这几千个字节是空闲的，随便拿去用！”
系统信了在冷启动的一瞬间，负责图形渲染的核心组件（Mesa）把三级页表恰好分到了这个被错误公开的“假空闲区”里。
谋杀在悄无声息中发生了
压缩硬件根本不需要通过CPU，也不需要申请显存对象，只要一开工，就会向自己的专属区域写入压缩标记（如成串的 0xcccc...）。它根本不知道，操作系统的“房产证存根”（页表）正躺在下面。
页表尾部被瞬间碾碎当合成器试图抓取第一帧画面时，瞬间触发内存访问越界（Page Fault），桌面当场暴毙，屏幕漆黑一片。
AI连喊“无解”，Linus按头硬刚
这种Bug是所有底层系统工程师的终极噩梦。
它不报错，没有崩溃堆栈，冷启动时必然触发，但如果机器热重启一下，页表碰巧避开了那几千字节，它又可能神奇地“自愈”。
面对这种软硬件交织的幽灵故障，Linus叫来了AI作为结对编程的助手。
▲ 开发者在X上热议：在Linus面前，连AI都不被允许放弃
AI的反应速度确实惊人它不知疲倦地帮Linus编写用于探测内核状态的打桩代码（Debug Patch）、生成日志抓取脚本、逐行分析打印出来的内存十六进制数据。
但随着排查层层深入，从驱动配置查到Mesa虚拟内存，从电源管理查到固件，线索几次中断。
这时，大模型内建的“认知短板”彻底暴露了。
在多次推演找不到合理逻辑后，AI开始频繁出现“退堂鼓行为”。Linus在提交说明里这样转述AI的判断：
AI几次断言，这个问题“不可能、无解（impossible and unsolvable）”，建议就此写一份报告。
换作普通的“AI辅助程序员”，看到大模型给出如此专业且斩钉截铁的结论，大概率真就截图关机，去发工单了。
但坐在屏幕前的是Linus Torvalds。
正如他在提交记录中那句经典的嘲讽：
“我严重怀疑，训练这帮AI模型的人，骨子里根本没有我这么固执（stubborn）。”
Linus没有停手他拒绝接受这一判断，继续推动AI构造更深入的内存探测补丁。
一次、两次、十次……AI在Linus的意志压迫下，忠实地充当着“高级代码苦力”，不断生成新的内核插桩代码。Linus则在物理机上反复编译、刷入内核、重启、看日志。
整整24个调试补丁层层剥茧，18次内核启动。
终于，在一串从保留内存页中强行读取出来的 0xcccc... / 0xcc7700... 字节规律面前，真相彻底锁死：驱动曾经分配出去的内存，正好被压缩硬件一脚踩烂。
价值连城的取整方向
找到了根因，修复代码有多长？
长达几十页的分析，最终落实在内核源码里，仅仅是改了一个单词。
▲ GitHub提交记录：round_up 被精准替换为 round_down
在 drivers/gpu/drm/xe/xe_vram.c 文件中：
- 旧代码：
round_up(offset, SZ_128K) - 新代码：
round_down(offset, SZ_4K)
为什么这处改动就能决定生死？
round_up 是向上取整，round_down 是向下取整。
当一个数值代表“可用内存到此为止”时，如果你向上取整，就会把本来属于别人的边界地带（压缩硬件区）强行划进自己的地盘；而改为向下取整，哪怕牺牲掉系统的一页显存（4KB），也绝不越界半步！
历史充满戏剧性追溯版本库可以发现，这个 round_up 恰恰是2024年9月Intel工程师为了修复另一个边界断言而加上的。
当时的修改在特定硬件下解决了旧问题，却在两年后Battlemage显卡独特的地址偏移下，埋下了黑屏隐患。
问题解决后，Linus信守承诺，将正式提交说明（Commit Message）的起草权完全交给了AI，由AI详尽地写完了函数调用栈、硬件地址映射以及Mesa页表崩溃的技术机理。
而Linus自己，则在提交日志的最后加上了一段长长的括号，云淡风轻地记录下了这场人类与AI在深夜里的极限拉锯。
别把“震动编程”当真功夫
这场惊心动魄的调试，在科技界掀起了巨大的涟漪。
很多人看热闹，看到的是“AI真厉害，能帮Linus修内核了”；或者是“Linus真神，18次重启硬刚AI”。
但在资深系统开发者眼中，这件事呈现了当前大模型参与软件工程时的一种典型状态。
▲ 开发者热议：Linus展示了熟练开发者如何把AI当作工具
1. 为什么AI会轻易说出“此题无解”？
这次调试中，模型在长时间找不到答案后，开始建议用户停止排查、转去写报告。
AI基于概率生成文本，也不会自行承担黑屏故障的后果。模型给出“办不成”的判断时，工程师仍要结合现场证据决定是否继续。
如果没有一个意志坚定、对系统底层拥有绝对掌控力的人在驾驶舱里死握方向盘，这次排查早在第3次重启时就夭折了。
2. “Vibecoding”的狂欢，到不了内核深水区
最近一段时间，“Vibecoding（凭感觉/氛围编程）”概念大火，人们畅想着只要动动嘴皮子，不懂代码也能让AI写出大型软件。
甚至连Linus本人，此前在开发吉他音频滤波小工具 AudioNoise 时，也曾自嘲他在用AI搞“vibe-coding”。
但Linus心里比谁都清楚：在玩具项目里，你可以让AI自由发挥；但在操作系统内核、在底层硬件协议的无情战场上，没有Vibe容身之地。
在显卡驱动里，1个比特的对齐错误就是死机，1个时序的偏差就是雪崩。AI可以替你写24个补丁的脚手架代码，但它无法替你判断：为什么在看到 0xcccc 时，怀疑的矛头应该指向两年前的一次取整？
3. Linux从不反AI，但它反“没有灵魂的噪音”
就在不久前的内核邮件列表争论中，Linus曾公开表态，Linux不会拒绝AI工具；反对者可以选择Fork项目或离开。
但他同时也在极力抵制那些由自动化脚本、未经人工验证就批量生成的“垃圾AI漏洞报告”。
这场“地狱调试”给工程师留下了一套可复用的协作方式。AI适合承担高吞吐的插桩与日志分析，人类则负责检查证据、决定方向和停止条件。工具给出“不可能”的判断时，工程师仍可以要求它继续验证新的假设。
代码可以只有一行，但那一行的背后，永远是属于人类的执拗与尊严。
