現象

• 突然画面が緑色になったあと、再起動される
• WindowsでもLinuxでも発生する。Windowsのほうがずっと多い
• 頻度は以前は数日に数回程度、今回は1ヶ月ほどあいた。

推察に基づく

「温度ではないか?」が私の推察だ。

これは、問題がこのマシン(Ryzen7 3700X, B550 AORUS ELITE, Radeon EX5700XT)のケースをRL07にしてから発生している。 RL07はもともとファンが「排気1」のみと極端に貧弱なものである。

この冷却性能の低さから、Windowsでは全体的に温度が高めとなっていた。

追加できるのはフロント120/140mmを3つとかなり少なく、ケース自体の冷却性能がかなり低い。 しかし、120mmファンを2つ追加した後、問題は明らかに発生しづらくなっている。

WindowsでもLinuxでも同様に発生する以上、ハードウェアの問題である可能性が高い。 また、Windowsのほうが常に負担をかけるため、Windowsで発生しやすいのも納得できる。

ただし、疑問もある。

• 発生したときは、必ずしも高温の状態ではない (モニターしていた)
• サーキュレーターを用いて冷却しても発生する場合があった
• Linuxにおいて高負荷ではないときに落ちたこともある

判断が難しいが、RL07があまりいいケースでないのは事実だ。 ペラペラで同じメーカーのSETA A1と比べ明らかに低品質だというのもあるが、冷却能力はかなり低い。 3700X/RX5700XTともワットパフォーマンスに優れ、そこまで負担が大きいわけではないが、それでもやや不安な排熱力だ。 サイドもトップも完全に閉じているというのも大きい。

そのため、望ましいということでいえばRL07をより冷却力の高いケースに代えるというのがある。 ただし、RL07はデザイン自体はよく、また静音であるというメリットもあるため、即座に決断はし難い。

調査に基づく

Linuxでクラッシュしたことは4回しかなく、以前journalを読んでも特に異常は見つけられなかったのだが、今回はMCEが残っていた。

1月 09 02:36:40 snowdrop kernel: microcode: CPU0: patch_level=0x08701021
1月 09 02:36:40 snowdrop kernel: microcode: CPU1: patch_level=0x08701021
1月 09 02:36:40 snowdrop kernel: microcode: CPU2: patch_level=0x08701021
1月 09 02:36:40 snowdrop kernel: microcode: CPU3: patch_level=0x08701021
1月 09 02:36:40 snowdrop kernel: microcode: CPU4: patch_level=0x08701021
1月 09 02:36:40 snowdrop kernel: microcode: CPU5: patch_level=0x08701021
1月 09 02:36:40 snowdrop kernel: microcode: CPU6: patch_level=0x08701021
1月 09 02:36:40 snowdrop kernel: microcode: CPU7: patch_level=0x08701021
1月 09 02:36:40 snowdrop kernel: microcode: CPU8: patch_level=0x08701021
1月 09 02:36:40 snowdrop kernel: microcode: CPU9: patch_level=0x08701021
1月 09 02:36:40 snowdrop kernel: microcode: CPU10: patch_level=0x08701021
1月 09 02:36:40 snowdrop kernel: microcode: CPU11: patch_level=0x08701021
1月 09 02:36:40 snowdrop kernel: microcode: CPU12: patch_level=0x08701021
1月 09 02:36:40 snowdrop kernel: microcode: CPU13: patch_level=0x08701021
1月 09 02:36:40 snowdrop kernel: microcode: CPU14: patch_level=0x08701021
1月 09 02:36:40 snowdrop kernel: microcode: CPU15: patch_level=0x08701021
1月 09 02:36:40 snowdrop kernel: microcode: Microcode Update Driver: v2.2.
1月 09 02:36:40 snowdrop kernel: mce: [Hardware Error]: Machine check events logged
1月 09 02:36:40 snowdrop kernel: mce: [Hardware Error]: CPU 2: Machine Check: 0 Bank 5: bea0000000000108
1月 09 02:36:40 snowdrop kernel: fbcon: Taking over console
1月 09 02:36:40 snowdrop kernel: mce: [Hardware Error]: TSC 0 ADDR 8e647a MISC d0130fff00000000 SYND 4d000000 IPID 500b000000000 
1月 09 02:36:40 snowdrop kernel: mce: [Hardware Error]: PROCESSOR 2:870f10 TIME 1641663390 SOCKET 0 APIC 4 microcode 8701021
1月 09 02:36:40 snowdrop kernel: mce: [Hardware Error]: Machine check events logged
1月 09 02:36:40 snowdrop kernel: mce: [Hardware Error]: CPU 13: Machine Check: 0 Bank 5: bea0000000000108
1月 09 02:36:40 snowdrop kernel: mce: [Hardware Error]: TSC 0 ADDR 1ffffc04aa388 MISC d0130fff00000000 SYND 4d000000 IPID 500b000000000 
1月 09 02:36:40 snowdrop kernel: mce: [Hardware Error]: PROCESSOR 2:870f10 TIME 1641663390 SOCKET 0 APIC b microcode 8701021

MCEはハードウェア異常の記録である。

私はこれまでRASを有効にしていなかった(rasdarmonをインストールし、同ユニットを有効にする必要がある)ため詳細がない。

しかしRyzenのMCEについてユーティリティを書いている人がいた

結果

❯ ./run.py 5 bea0000000000108
Bank: Execution Unit (EX)
Error: Watchdog Timeout error (WDT 0x0)

尻尾をつかんだかと思ったが、Watchdogということで何の参考にもならない内容である。 だが、全く同じ例が書かれていた。

It’s the most known error on a Ryzen. To fix it, you need to disable C-States in the BIOS or to set the boot parameter processor.max_cstate=5.

とりあえず、BIOSの設定でGlobal C-State SettingsをAUTOからDisableに変更した。

むすび

今のところ再現していないが、結論を出すことはできない。

もし、これで解決すれば良し、解決しなければケースを変更することになるだろう。