
Create a landscape editorial hero image for this Studio Global article: How did Linus Torvalds use an AI assistant to diagnose and fix a two-year-old Intel Xe graphics-driver bug on Battlemage G21 hardware—what w. Article summary: Torvalds used the AI as an interactive debugging aide, not as an autonomous patch author: he directed experiments, had it help generate and interpret instrumentation, and personally validated the result. The final remedy. Topic tags: general, general web, user generated. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fa
一行程式碼,修好了 Intel Xe 顯示驅動在 Battlemage G21 硬體上的嚴重錯誤。但真正值得注意的,並不是修正本身有多複雜,而是找出它之前,Linus Torvalds 與 AI 助手經歷了 24 個除錯補丁版本,以及 18 次 Linux 核心重新開機測試。Torvalds 形容這是一場「地獄級除錯」,並表示 AI 在其中幫了很大的忙;不過,AI 也曾多次斷言問題不可能解決,甚至建議乾脆寫報告了事。
問題出在 Intel Xe 驅動計算一般 VRAM 與保留給扁平 Compute Command Streamer(CCS)的儲存區之間界線時,使用了錯誤的對齊方向。概念上,程式碼由:
round_up(value, SZ_128K)改為:
round_down(value, SZ_128K)這個數值代表的是「可供 VRAM 配置器使用的記憶體到哪裡結束」,也就是一個上限,而不是記憶體區段的起始位置。向上取整後,實際界線與取整界線之間的一小段空間可能會被誤認為是可用 VRAM;但那段區域其實屬於 CCS 壓縮中繼資料。改為向下取整,才能讓配置器停在安全界線之內。
當 VRAM 配置器把 CCS 儲存區當成一般可用記憶體後,普通配置就可能與 CCS 區域重疊,進而覆寫 GPU 使用的壓縮中繼資料。受損內容包括與頁表相關的資料,最終造成畫面異常,以及 GNOME Display Manager(GDM)不斷重啟等症狀;這些問題出現在採用 Battlemage G21 的硬體上。
因此,這不只是單純的算術錯誤,更是「語意與程式操作不匹配」:程式把一個表示可用記憶體終點的上限,當成了適合向上對齊的起始位址。也正因如此,最終補丁雖然只有一行,卻很難在一開始就鎖定。
Torvalds 與 AI 助手在除錯過程中加入並反覆修改針對性的檢測程式碼,追蹤驅動程式如何計算記憶體位置,再把硬體回報的 CCS 位置,與傳給 VRAM 配置器的界線互相比對。整個調查共經歷 24 個除錯補丁版本,以及 18 次重新開機與測試,才逐漸確認問題出在對齊方向。
這些重複開機測試並非多餘。錯誤的表現不只是一行可疑的原始碼,而是延伸到硬體與顯示系統層面的記憶體損毀。每次實驗都協助團隊排除其他可能性,分辨究竟是 VRAM 配置行為出了問題,還是顯示堆疊中的其他環節導致故障。
在這次調查中,Torvalds 把 AI 當成互動式的除錯夥伴,而不是能獨立負責的修補程式作者。AI 協助提出檢測方式、追蹤驅動程式的執行路徑,並分析每一輪實驗產生的結果,減少了反覆撰寫與整理測試程式碼的工作量。
但 AI 並不可靠到可以取代專家判斷。Torvalds 表示,AI 曾多次認定這個問題「不可能」或「無法解決」,並建議停止調查、改寫報告。他仍持續推動流程,決定下一個實驗,辨識哪些解讀不正確,並理解該偏移量在記憶體配置模型中的真正意義。
這正是整起事件最重要的分工:AI 負責產生可能性與處理機械性工作;專家則負責提供子系統背景、設計可證偽的測試、持續追查,以及對最終結果作出判斷。
Torvalds 親自撰寫並提交了 Intel Xe 驅動修正,程式碼已進入上游 Linux 核心。現有報導指出,受影響且仍受維護的穩定版核心系列預計會依照一般回移(backport)流程取得這項修正;不過,目前提供的來源不足以可靠確認具體版本與發布日期。
因此,現階段不宜僅根據現有資料指名哪些穩定版核心一定已包含修正。使用相關硬體的使用者,應以 Linux 發行版或核心維護者的公告為準,確認特定版本是否已納入補丁。
這起事件並不是對「AI 產生核心程式碼」的全面背書,而是示範了一種更狹義、也更穩妥的用法:由熟悉子系統的專家主導,讓 AI 加速艱難的除錯循環,同時由人類負責提出假設、設計測試、審查變更,並對補丁負責。
這與未經測試、未經理解就大量寄出的 AI 產生補丁或漏洞報告,完全是兩回事。Linux 核心維護者曾形容自己正面對這類提交的「猛烈攻勢」;staging 子系統也表明,除了已在真實硬體上驗證的安全修正外,將拒絕大多數由大型語言模型產生的補丁。網路子系統維護者同樣反映,AI 產生的補丁數量正造成沉重負擔。
外界經常提到提交量增加 2,700% 的說法,但應保持謹慎。現有報導並未充分交代這個數字的計算方式、統計期間,或它究竟指所有提交、特定子系統,還是特定類型的補丁。因此,較有證據支持的結論是:AI 降低了產生程式碼與報告的成本,但審查與分流這些內容的時間成本,仍由人類維護者承擔。
Torvalds 也曾表示,Linux 並非一個從根本上排斥 AI 的專案,尤其在程式碼審查等用途上,AI 確實可能派上用場。 這次 Intel Xe 除錯則清楚劃出了實務界線:AI 可以在嚴謹的工程流程內發揮作用,但無法取代子系統知識、可重現的測試,以及人類對成果的所有權與責任。
最後的補丁只有一行。真正困難的,是找出應該改動的那一行,並在 AI 宣稱「找不到答案」時,仍然不放棄繼續追查。
Studio Global AI
這個頁面包含附來源佐證的答案,你可以在 Studio Global 內繼續追問。
Intel Xe 驅動的關鍵修正,是將 round up(value, SZ 128K) 改為 round down(value, SZ 128K)。
Intel Xe 驅動的關鍵修正,是將 round up(value, SZ 128K) 改為 round down(value, SZ 128K)。 Torvalds 使用 AI 協助加入檢測、追蹤程式碼路徑與分析結果,但並未讓 AI 自主撰寫或決定最終修補內容。
這起事件顯示,AI 適合在專家主導的除錯流程中加速重複工作;未經驗證、直接送出的 AI 產生核心補丁與漏洞報告,則可能加重維護者的審查與分流負擔。