Linux

Linux 7.0、Zen 3の誤検知エラーを土壇場で抑制

情報の灯台

情報の灯台

Linux 7.0、Zen 3の誤検知エラーを土壇場で抑制
AMD

Linux 7.0安定版のリリースが予定される当日、AMD Zen 3のユーザーを長らく悩ませてきた誤検知のハードウェアエラーを黙らせるパッチが、土壇場で送り込まれた。原因はハードウェアではなかった。

リリース当日の駆け込みパッチ

Linux 7.0安定版のリリース当日、AMDのマシンチェック例外（MCE）ドライバに対する修正パッチが、ギリギリのタイミングでLinus Torvaldsへ送られた。送り主はx86メンテナのIngo Molnar。件名は素っ気なく、「Zen3クライアントで発生する誤ったハードウェアエラーをフィルタする」とだけ書かれていた。

変更行数はたった8行、対象ファイルは arch/x86/kernel/cpu/mce/amd.c の一か所のみ。リリース直前にカーネルへ入れるにしては、あまりに慎ましい修正だ。だが、この8行の裏には、Ryzen 5000シリーズのユーザーが抱え続けてきた不安があった。

Linux 7.0 直前パッチの概要
送信者Ingo Molnar（x86メンテナ）
宛先Linus Torvalds
件名x86/mce fix
対象ファイルarch/x86/kernel/cpu/mce/amd.c
変更行数8行（挿入のみ）
対象CPUAMD Zen 3 / Ryzen 5000シリーズ
症状L3キャッシュのdeferred errorが誤検知として出力
判定方法CPU ID・モデル・ステッピングで対象を絞る
投入先Linux 7.0（リリース直前に追加）
波及先stable系列にもバックポート予定
Ingo Molnarによる x86/mce fix プルリクエスト（Linux Kernel Mailing List、2026年4月12日）。

ユーザーを混乱させた「L3キャッシュのゴミ値」

問題が顕在化したのは、最近のLinuxカーネルでエラー処理コードが書き換えられた後のことだ。Zen 3、つまりRyzen 5000シリーズを使う一部のユーザーのdmesgに、L3キャッシュのdeferred errorという見慣れない警告が流れ始めた。

mce: [Hardware Error] という文字列は、普通のユーザーにとって「CPUが不調に陥っている」と読める。しかし今回のケースでは、その警告の中身は実体のない数値、つまり「ゴミ値」だった。

ハードウェア自体はまったく正常。にもかかわらず、カーネルが丁寧にそれを拾い上げ、ログへ叩きつけていた。結果としてバグレポートがLinuxコミュニティに流れ込むことになる。「自分のCPUはもう寿命なのか」と疑ったユーザーは、決して少なくなかったはずだ。

悪いのはCPUではなく、書き換えたばかりのコード

原因を追っていくと、犯人は直近のエラーハンドリングのリワークそのものだった。改善のために入れたコードが、本来は黙って捨てるべきイベントまで律儀に報告していた。

直すつもりが、壊した。オープンソースの開発ではときどき起きることだが、影響範囲がRyzen 5000という広いユーザー層に及んだのが今回の厄介なところだ。

そもそも「ハードウェアのエラー報告」は、誰のための仕組みなのか。異常を早く検知するための仕掛けが、正常なチップに不吉な診断書を発行し続けるなら、その仕掛けは逆に信頼を損ねる。狼少年の話と構造は同じだ。

応急処置であって、根本治療ではない

では今回のパッチは、エラー処理のリワークそのものを見直したのか。答えはノーだ。入ったのは、CPUのID・モデル・ステッピングを見て、該当するZen 3チップではMCEメッセージを黙らせるだけ。要するに応急処置だ。

対象のCPUだったらログに出さない。それだけの話である。潔いといえば潔いが、根本原因の掘り下げは宿題として別に残されている。

Phoronixも指摘しているように、リリース直前のこの段階で安全に入れられるのは、こうした限定的なフィルタまでだ。カーネルのリリースサイクルは信頼の上に成り立っている。土壇場でエラー処理ロジックそのものに手を入れる方が、よほどリスクが高い。

誤検知エラーが修正に至るまでの流れ
1 エラー処理コードのリワーク
改善目的で書き換えたコードが、本来は捨てるべきイベントを拾う副作用を生む
↓
2 Zen 3でL3キャッシュ誤検知
正常なチップのdmesgに、実体のない「ゴミ値」がハードウェアエラーとして流れ始める
↓
3 ユーザー混乱とバグ報告の流入
CPU故障を疑ったRyzen 5000ユーザーからバグレポートがコミュニティに集まる
↓
4 8行のフィルタでMCEメッセージを抑制
Linux 7.0リリース当日、IngoからLinusへ駆け込みプルリクエスト。該当するCPU ID・モデル・ステッピングのMCEイベントを黙らせる応急処置
根本原因（エラーハンドリングのリワーク側）の掘り下げは、このパッチには含まれていない。

既存の安定版にもバックポートへ

このフィックスはLinux 7.0だけで終わる話ではない。stable kernelチームに向けたバックポート対象としてマークされており、現行の安定版シリーズにも順次取り込まれていく見込みだ。

つまり、UbuntuやFedoraのように、stableカーネルを定期的に取り込むディストリビューションを使っていれば、特別なことをしなくてもいずれ直る。不気味なログは、自分のマシンから黙って姿を消すはずだ。

ハードウェアの誤検知は、オープンソースのカーネル開発では珍しい話ではない。今回の一件で救いなのは、誰かが気づいて、8行で黙らせたことだ。

美しい解決ではない。だが、偽の警告がユーザーの画面から消えるなら、いまはそれで十分だ。

参照元

他参照

関連記事

Read more