9 月 27 日，Solidot 轉述了 Debian 開發者披露的一份龍芯 CPU 勘誤報告。故事從今年 2 月開始：Debian 13 的龍芯架構移植版 loong13 維護者在編譯打包時，發現數學套件 normaliz 自帶的測試會死鎖、導致打包超時。第一輪排查後，問題指向一個令人不安的方向：原子加指令在特定情況下會丟失更新，但當時找不到原因。
先講清楚「原子加」是什麼，以及它為什麼不能出錯。想像一間辦公室只有一臺咖啡機，大家約定好排隊用，一次一個人，用完再換下一個。原子指令就是 CPU 裡的這條排隊規則：多個程式執行緒同時要對同一個記憶體位置加一時，硬體保證一次只讓一個做完，結果不會互相覆蓋。這個保證是整個多工系統的地基。鎖、引用計數、統計計數器，全都建立在「原子指令一定原子」這個前提上。它一旦偶爾失效，症狀不會是跳錯誤訊息，而是程式莫名其妙慢下來、卡死，或者算出誰也解釋不了的數字，就像排隊規則偶爾失效，兩個人同時按了咖啡機，最後只有一杯咖啡，另一人的紀錄憑空消失。
8 月，開發者重啟調查，這次多了一個幫手：AI。開發者的角色是決定調查方向，AI 負責窮舉式地收斂，把正常測試逐步削減，逼近最小重現程式。大約兩天後，一個穩定的重現程式出來了，根源也跟著現形：CPU 的原子加法指令，偶爾真的不原子。
這裡值得停下來看「偶爾」兩個字。確定性 bug 好抓，跑一次崩一次，除錯器一開就現形。機率性 bug 是另一回事，就像家裡電燈偶爾閃一下，你站在旁邊盯著它偏不閃。傳統做法是人工砍測試碼，砍到剩幾十行，往往要花上數週。這次開發者把「砍程式碼」這件最枯燥的事交給 AI，自己守住「該往哪個方向砍」的判斷，兩天就把重現程式隔離出來。對寫程式的人來說，這個分工方式比 bug 本身更有參考價值：AI 負責體力活，人負責提問。
問題回報給龍芯後，兩週內拿到修復的測試韌體，確認解決。龍芯表示會在 10 月 1 日國慶前正式發布韌體。受影響的範圍主要限於使用 LA664 核心的 3C6000/S 與 3A6000 兩款處理器。
從事件時序看，有三個訊號值得記下。第一，是發現管道。這個錯誤不是龍芯自己驗證抓到的，而是社羣在實際打包工作中撞見、再由開發者自費時間挖出來的。開源移植版在這裡扮演了免費的野外測試場，Debian 這類發行版的持續整合流程，等於幫硬體廠商跑著一套廠內未必會跑的長時間壓力測試。第二，是回應速度。從 8 月定位問題、回報，到 9 月底承諾發布修復韌體，節奏相當快，對照處理器產業裡勘誤往往沉默到下一代晶片才悄悄處理的慣例，公開報告加限期修復算是相對透明的做法。第三，是修復形態。用韌體更新處理，通常代表問題出在微碼或電源管理之類可事後調整的環節，而非電路結構本身，不過來源並未說明具體根因，這點仍屬未知，不宜過度推測。
對實際持有 3A6000 或 3C6000/S 機器的使用者，接下來該做的只有一件事：等國慶前的正式韌體出來後更新，並留意 Debian loong13 這邊是否有後續公告。對更廣的讀者，這件事的用處在於看清一個現實：CPU 也會有 bug，而且這種 bug 的症狀永遠長得像軟體的錯。當程式出現無法解釋的偶發死鎖，問題不一定在你的程式碼，硬體勘誤清單有時比除錯器更值得先翻。而這次案例也留下了一個工作方法上的參考：把最小重現這類機械式收斂工作交給 AI、人守住調查方向，已經在真實的底層除錯場景裡跑通了流程。
主題