Panther LakeでElden Ring・RDR2が落ちる原因はGPUでなくCPUのFREDバグ、回避策はfred=off
本記事にはアフィリエイト広告（Amazon・楽天市場等）のリンクが含まれています。
Mesaに上がっていた2件のバグ報告も、カーネル1本のパッチで解決する形に
出典：Phoronix「Linux Ready With Fix For Intel’s FRED Crashing Some Games Under Wine / Steam Play」、Linuxカーネルメーリングリスト「x86/fred: Reconstruct the #GP context for rejected INT instructions」パッチ本文、lore.kernel.orgレビューコメント（H. Peter Anvin氏）、Phoronix「Linux 7.1 Is A Big Win For Intel Panther Lake With FRED Enabled By Default」、kernel.org公式「The kernel’s command-line parameters」、Intel公式「Core Ultra X7 processor 358H」製品仕様（いずれも2026年9月19日確認）にもとづきます。
Intel Core Ultra Series 3「Panther Lake」を積んだLinux機で『ELDEN RING』が起動から2〜3分でフリーズし、『Red Dead Redemption 2』(レッド・デッド・リデンプション2、以下RDR2)は起動とクラッシュを繰り返す。この症状が海外で報告されたとき、真っ先に疑われたのは内蔵GPU「Arc B390」でした。
しかし実際に特定された原因は、GPUでもグラフィックスドライバーでもありませんでした。Panther Lakeが初めて実際に使う、CPU側の新しいイベント配送の仕組み「FRED」を処理するLinuxカーネル側の実装バグです。開発者が突き止めた不具合の中身は、WineがWindows由来の例外を再現する仕組みそのものに関わるものでした。
疑われていたArc B390のGPUドライバーが実際には無関係だった理由、FREDというCPU機能の正体、修正パッチの技術的な中身、そして2026年9月19日時点でどこまで直っていて手元で何ができるかを、一次情報にもとづいて整理します。
目次
症状Elden RingがフリーズしRDR2はクラッシュを繰り返した
Panther Lake搭載のLinux環境で、『ELDEN RING』が起動から2〜3分ほどでフリーズする不具合が報告されました。同じ環境ではRDR2も起動とクラッシュを繰り返し、どちらもまともにプレイできない状態でした。
最初に疑われたのは、Panther Lakeに内蔵されたXe3世代GPU「Intel Arc B390」と、それを制御するオープンソースのIntelグラフィックスドライバー「Mesa」でした。実際にMesaのGitLabには、この症状に対応する2件のバグ報告(Work Item #15745、#16132)が上がっており、GPUドライバー側の不具合という見立ては的外れな推測ではありませんでした。
真因原因はGPUでなくCPU新機能「FRED」を扱うカーネルのバグだった
しかし実際に特定された原因は、GPUでもMesaでもありませんでした。CPU側の新しいイベント配送の仕組み「FRED(Flexible Return and Event Delivery)」を処理する、Linuxカーネル側の実装バグです。
FREDはIntelが策定した新しいイベント配送・復帰の方式です。従来のx86 CPUは、割り込みや例外が発生した際にIDT(Interrupt Descriptor Table)を使ってイベントを配送し、IRET命令で元の処理へ復帰していました。FREDはこの仕組みを、ERETU(リング0からリング3への復帰)とERETS(リング0にとどまる復帰)という2つの新しい命令による、より低遅延な遷移に置き換えます。
Panther Lakeは、このFREDを実際に使う最初のクライアント向けCPU世代です。Linuxカーネル自体のFRED対応はLinux 6.9から存在していましたが、当初はオプトイン方式でデフォルト無効でした。2026年4月公開のLinux 7.1で、コードが十分にテストされたとしてオプトアウト方式へ切り替わり、FREDに対応したCPUに対してデフォルトで有効化されています。
WineのINT 0x2d再現が誤って壊れていた
FRED自体の設計に欠陥があったわけではありません。問題は、FRED使用時にLinuxカーネルが、ユーザー空間から実行された「拒否されるINT n命令」を処理する経路にありました。
WindowsゲームをLinuxで動かす互換レイヤー「Wine」は、Windows由来の例外処理の一部を、あえて許可されないINT命令を実行させることで再現しています。従来のIDT方式では、ユーザー空間から許可されないINT命令を実行するとGeneral Protection Fault(#GP)が発生し、Wineはこのときのエラーコードと命令ポインターの値を見て、Windows側の例外(『ELDEN RING』が使っていたのは「INT 0x2d」というWindowsのデバッグ・例外処理に関わる命令)を再現します。
ところがFREDのイベント配送はIDTを使わないため、ユーザーのINT nを拒否する際のゲートDPLチェックがソフトウェア側に落ちてきます。開発者Matthew Schwartz氏が提出したパッチ「x86/fred: Reconstruct the #GP context for rejected INT instructions」の説明によると、この経路で生成されるエラーコードが0になり、保存される命令ポインターもINT命令の位置ではなくその直後を指してしまうという誤りがありました。この誤った情報のせいでWineはINT 0x2dを正しく認識できず、本来処理できるはずの状態を誤ってアクセス違反として扱ってしまい、『ELDEN RING』が異常終了していました。
Schwartz氏のパッチは、拒否されたINT命令の#GPコンテキストを、IDT方式と互換になるよう再構築します。IDT互換のセレクタ形式エラーコード「(vector << 3) | 2」を合成し直す、命令ポインターをINT命令の直後からその命令自体の位置まで巻き戻す「regs->ip -= regs->fred_ss.insnlen」、RFフラグ(X86_EFLAGS_RF)を立てる、ソフトウェアイベントフラグ(fred_ss.swevent)をクリアする、という4つの処理です。同パッチはMesaのWork Item #15745と#16132を”Closes”として紐付けており、Mesa側で報告されていたバグはこのカーネル側修正で解決する形になっています。
パッチの説明で具体的な破損経路が明示されているのは『ELDEN RING』のINT 0x2dのケースのみです。RDR2についても同じカーネル修正で解決する対象として扱われていますが、RDR2の症状がまったく同じINT 0x2d経由の破損だったとまでは明言されていません。
検証修正版はリグレッションテストで29項目すべて成功
パッチにはリグレッション検出用のselftestが追加されています。32bit・64bitを含む29項目のテストを、条件の異なる3つの環境で実行した結果は次の通りです。
29項目すべて成功
同じ29項目すべて成功
Signal Context関連16項目と、最初のptrace命令ポインターテストの計17項目が失敗
修正版はFREDが有効なPanther LakeとFREDを使わないAMD環境の両方で結果が一致しており、IDT方式との互換性が取れていることを裏付けています。
展開状況2026年9月19日時点ではまだ手元のLinuxに届いていない
この修正パッチは、2026年9月18日時点でLinuxカーネルのx86/urgentブランチへキューされ、Linux 7.3への投入が見込まれています。Linux 7.3自体は2026年8月30日にリリースサイクル最初のrc1が公開済みですが、x86/urgentのような緊急度の高い修正はrc期間中に追加でメインラインへマージされるのが通例です。
x86開発者のH. Peter Anvin氏は、このパッチへのレビューで「This really should go into -stable(安定版シリーズにも入れるべきだ)」と述べています。ただしこれはレビューコメントの段階であり、実際にstableへバックポートされることが確定したわけではありません。
2026年9月19日時点で分かっているのは、修正パッチが用意されx86/urgentブランチへキューされた段階だということです。Linux 7.3の正式リリースはまだ先で、各Linuxディストリビューションが提供するパッケージにこの修正がいつ反映されるかも、現時点では分かっていません。
対処症状が出ている場合に今すぐできること
手元のPanther Lake搭載Linux機で『ELDEN RING』やRDR2が同様の症状を起こしている場合、恒久的な修正が降ってくるまでの切り分け・回避策として、Linuxカーネルの起動パラメーター「fred=off」を使う方法があります。kernel.org公式のドキュメントでは、fred=onがFRED搭載CPUでの既定の動作、fred=offがFREDを無効化する設定と説明されています。ブートローダーのカーネルコマンドラインへfred=offを追加して再起動すると、イベント配送に旧来のIDT方式が使われるようになり、今回の不具合を回避できる可能性があります。
ただしこれはあくまで一時的な切り分け・回避策です。FRED自体はI/O負荷の高い処理などで応答性を高める効果があり、対応CPUでは現在標準で有効になっています。修正版のカーネルが行き渡った後は、fred=offの設定を外して元の状態に戻すことをおすすめします。
今回名前が挙がっているのは『ELDEN RING』とRDR2の2本ですが、修正内容自体はこの2本専用の対応ではなく、Linuxカーネルが拒否されたINT命令を処理する経路そのものに対する一般的な修正です。理論上は、WineやProtonを介して同じ経路を通る他のWindowsゲームでも、同様のクラッシュが起きていた可能性があります。ただし、Linux上のゲームクラッシュがすべてFREDで説明できるわけではありません。他の原因による不具合と混同しないよう、まずは自分の環境がPanther Lake搭載機かどうかを確認してください。
今回の一連の騒動で誤解しないでおきたいのは、Arc B390のグラフィックス性能やドライバー品質そのものに問題があったわけではないという点です。原因はCPU側の例外処理であり、GPUの描画性能やMesaドライバーの完成度とは無関係でした。Arc B390は12基のXeコア、最大2.5GHzのGPUクロックを備えた内蔵GPUで、実際のゲーミング性能は別記事で検証しています。
FAQよくある質問
総括まとめ｜疑うべきはGPUでなくCPUとカーネルのバージョン
Panther Lake搭載Linux機での『ELDEN RING』のフリーズとRDR2のクラッシュは、内蔵GPU「Arc B390」やMesaドライバーではなく、CPUの新機能FREDを処理するLinuxカーネルの実装バグが原因でした。開発者Matthew Schwartz氏のパッチが、拒否されたINT命令の#GPコンテキストをIDT方式と互換になるよう再構築し、Mesa側に上がっていた2件のバグ報告も解決する形になっています。
Panther Lake搭載Linux機でWine・Proton経由のゲームがクラッシュする場合、まずGPUドライバーではなくCPU・カーネル側を疑ってください。修正パッチは2026年9月18日時点でx86/urgentブランチへキューされ、Linux 7.3への収録が見込まれていますが、9月19日時点ではまだ手元のカーネルに届いていない段階です。症状が出ているなら、ブートパラメーター「fred=off」を一時的な回避策として試す選択肢があります。ただしFREDは対応CPUで標準有効の機能であり、恒久的にオフのまま使い続けることはおすすめできません。修正版のカーネルが配布され次第、fred=offの設定を外し、標準の状態に戻してください。
あわせて読みたい
