[解決済] AMD Ryzen 1700 + Linux Kernel 4.11 でカーネルがフリーズする問題

投稿者 投稿日:
このエントリーをはてなブックマークに追加

この問題は無事解決した。

我が家の自宅サーバは 10 年近く Xeon X3350 で稼働していたが、

  • さすがに 10 年も経つと HDD のセクタ置換済みが結構増えてきた。
  • 別に Phenom II 1065T で稼働する KVM マシンがあるが、電気代の関係で 1 台にまとめたい。
  • 1.5TB が溢れそうになってきた。

こともあって、最近リリースされた Ryzen 1700 でリプレイスすることにした。

しかし、実際に稼働させてみると 24 時間も経たずにカーネルがクラッシュしてしまう問題がある。


問題

概要

Ryzen 上の Linux で少しでも負荷がかかるとカーネルごとクラッシュする。ほとんどのケースでは Kernel Panic すら吐かないが、一度だけ以下が表示されていた。

なお、全コアを回してコンパイルするといった高めの負荷をかけなくても再現する。

稀にプロセスが Segmentation Fault で落ちたり gcc が Internal Error で落ちる程度で済むことがある。

gcc の Internal Error

上で書いたとおり、稀に gcc が Internal Error で落ちることはある。ただ、確実に落ちる状況もあって、それはカーネルが 4.11 未満で gcc 6.3 をコンパイルするタイミングになる。この場合は ACCEPT_KEYWORDS="~amd64" で /usr/portage/scripts/bootstrap.sh から始めたりemerge -e system せずにまずは最新のカーネルでインストールし、再起動後にやればほぼ上手くコンパイルが通るようになる。

環境

稼働させている環境は以下。「→」は検証のために交換しているが、交換前後で問題が解消することはなかった。

リソース

改めて関係しそうなサイトを検索してみるといくつか見つかった。

切り分け

ハードウェア

当然だが最初はメモリの相性を疑った。実際、AGESA 1.0.0.4 で DDR4-2400 8GB x 4 枚構成だと DDR4-2400 では動作せず、DDR-2166 に落として動作させる必要がある。だがしかし、hynix 製チップ搭載の CORSAIR DDR4-2666 VENGEANCE LPX CMK32GX4M2A2666C16 に差し替えても改善しなかった。

次に疑ったのはマザーボードだが、Ryzen はメモリコントローラを内蔵しているので、ここはそんなにいうほど可能性はない。あり得るとしたらメモリまでの配線でノイズを拾うことだが、もしそうならそもそも起動しないレベルになるだろう。実際、交換しても改善はしなかった。

コンパイルオプション

gcc 6.x 以降では --mtune=znver1 --march=znver1 で Ryzen 向けの最適化が可能だが、Ryzen では FMA3 命令セットを食わせると落ちる問題があったので、Ryzen 向けに最適化することでそういった地雷を踏んだことを考えた。

しかし、実際に --mtune=generic で一般的な　amd64 CPU 向けにコンパイルしても問題が解消することはなかった。

KVM

今回は、

  • ホスト側で libvirt などの KVM 管理環境と PostgreSQL / MySQL / Samba などのストレージ回り
  • WordPress や各 Web サービスのバックエンドは KVM 上の仮想環境で

という切り分けを考えていた。KVM 側で地雷コードを踏む可能性もあったので、

  1. KVM 側で --march=generic ですべて再コンパイル
  2. Gentoo Linux のようなエッジの効いたディストリビューションではなく、CentOS で稼働する仮想環境に換える
  3. そもそも KVM を起動しない

を試してみたが、3. で何も負荷をかけない限りはすべて改善しなかった。

PostgreSQL / MySQL を止めてみる

新サーバでは WordPress 向けの MySQL, 各種サービス向けの PostgreSQL 双方が稼働している。そこで、

  1. PostgreSQL / MySQL 両方とも走らせる
  2. PostgreSQL のみ走らせる
  3. MySQL のみ走らせる
  4. PostgreSQL / MySQL 両方とも止める

で試してみたが、4. で何も負荷をかけない限りはすべて改善しなかった。

フォーラムなどで出ていた workaround

フォーラムを見た限り、以下がワークアラウンドとして挙げられていた。

  • SMT を off
  • C’n’Q を off
  • μOP Cache を off

すべて試したが、最終的にクラッシュする事象に変化はなかった。

現状と考えられる原因

今回、本当に色々と試してみた。

だが結局のところ問題は解決していないので、この blog も含め旧ファイルサーバにすべて突っ込んで対応している。

考えられる問題としては

  • Ryzen CPU そのもののハードウェアに起因するバグで回避不可能
  • Ryzen CPU そのもののバグだが、マイクロコードの改修で回避可能
  • メモリ回りの問題
  • カーネルそのもののバグ

といったところだろうか。フォーラムは割と深刻に捉えていなさそうなので軽くコメントしておいたが、解決するのか非常に心配ではある。

が、Twitter で

こういう話もあるので、Linux カーネル側のバグの可能性もある。

いずれにしても、AMD のフォーラムにあるスレッドをウォッチしていこうと思うが、この状況で Threadripper をリリースしてもいいのか心配ではある。

Twitter にもこう書いたが、アーキテクチャそのものにはほとんど差はないだろうし、この状況で Linux が多用されるであろうエンタープライズに投入すると悲劇が起きると思うのだが……


このエントリーをはてなブックマークに追加

投稿者: Kenta ONISHI