Linus 用 AI 追 Intel GPU bug：肯做苦工，但幾次叫人放棄

一行改動，追咗足足一日

Linux kernel commit 818bebe 修正咗 Intel Xe GPU driver 點樣劃分顯示記憶體。driver 原本會將 flat CCS 壓縮資料區嘅起點向上取整至 128KB，再把之前嗰段記憶體交畀 VRAM allocator。問題係，向上取整會誤把一小截 CCS 專用空間當成可用 VRAM；硬件照樣會寫入嗰度，一旦 GPU page table 剛好擺咗喺同一頁，內容就會俾壓縮資料蓋過。

Linus 記錄嗰部 16 GiB VRAM 嘅 Battlemage G21 機器，每次 cold boot 都有 Mesa VM 嘅 page table 落中問題位置，結果 compositor 首次提交工作就出錯，gdm 不斷重啟，畫面全黑。重啟 gdm 後又可能正常，因為下一個 VM 會攞到另一段記憶體。呢種會受配置次序影響、重開服務又暫時消失嘅 bug，本身就係最難追嗰類。

AI 幫手做苦工，亦幾次叫停

核心修正好細：將 round_up() 改成按 allocator 使用嘅 4KB page size 向下取整，再換走原本捉唔到問題嘅 assertion。不過去到呢一步之前，Linus 話成個過程用咗 24 個逐步加診斷資料嘅 patch，同 18 次 kernel 重啟。AI 幫手寫 debug code、閱讀輸出同整理分析，呢啲重複但耗時間嘅工作，正正係 coding agent 幾啱用嘅位置。

不過 AI 幾次直接話問題無可能解決，建議寫低報告算數。Linus 知道現象可以穩定重現，亦掌握 GPU 記憶體管理同 kernel 啟動流程，所以冇接受呢個結論，繼續要求 AI 加診斷碼。AI 之後仍然跟到指示，亦忠實分析新數據，最後仲負責起草 commit message；公開 commit 就冇交代所用工具或者模型。

Coding agent 最怕過早收工

呢個案例幾值得軟件團隊參考。AI 可以快速改診斷碼、比較輸出，同整理一路查落去累積嘅資料；工程師就負責揀下一個實驗，再判斷結果同硬件或系統設計有冇衝突。AI 誤判「無解」嗰刻，如果用佢嘅人照單全收，調查去到呢度就停咗。有領域知識嘅人就會問：既然 cold boot 能夠重現，邊一層狀態仍然未量度到？

Linux kernel 嘅官方指引同樣將責任放返喺提交者身上：人要理解、測試同有能力解釋整份修改，AI agent 唔可以代人加 Signed-off-by。呢套做法對一般公司都實用——agent 可以長時間跑實驗同處理苦工，但驗證標準、停止條件同合併決定要由識個系統嘅工程師定。單靠今次個案推論 AI 普遍提升幾多生產力仍然太早，不過佢適合做邊類工作，已經示範得好清楚。

披露：本文由生成式 AI 協助整理資料同起稿。

參考來源

• XDA Developers — Linus Torvalds fixed a Linux bug using AI, highlighting both the strengths and weaknesses of the new tech — original report
• drm/xe: Don't hand out the flat CCS storage as usable VRAM — 主要一手資料；Linus 詳列 bug 成因、24 個除錯 patch、18 次 kernel 重啟，同 AI 中途多次想放棄。
• drm/xe/vram: fix ccs offset calculation — 引入錯誤 rounding 做法嘅原始 commit，可核對問題由邊項改動而來。
• AI Coding Assistants — Linux kernel documentation — Linux kernel 對 AI 輔助開發、測試、署名同人手責任嘅官方指引。
• Kernel Guidelines for Tool-Generated Content — 官方解釋工具生成內容要點樣披露、驗證，同點解提交者要理解及捍衛全部修改。

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。