Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ソフトウェア技術者によるハードウェア問題の解析

 ソフトウェア技術者によるハードウェア問題の解析

以下動画のテキストです

https://youtu.be/0TshIz5W3Hg

Satoru Takeuchi

August 09, 2020
Tweet

More Decks by Satoru Takeuchi

Other Decks in Technology

Transcript

  1. はじめに • 題材 ◦ 数年前にAMD Ryzen 1000系CPUの一部に存在した問題 ◦ 上記CPUのユーザ少なくとも数十名が遭遇した ◦

    Ryzen2000系以上、Thread Ripper, EPYCでは問題は起きない • 真面目に話すと大変なので要点だけを簡単に説明 ◦ 解決までに数か月を要した ◦ 登場人物がすごく多い ◦ カーネル屋さんかそれに近い人でないと理解が難しい • 詳細はブログで ◦ https://satoru-takeuchi.hatenablog.com/entry/2017/04/24/135914 2
  2. どういう問題か • Linuxカーネルをビルドしていたらgccがsegmentation faultによって失敗 ◦ 普通こんなところでは失敗しない 5 ./include/trace/perf.h:41:9: internal compiler

    error: Segmentation fault struct hlist_head *head; \ ^ ./include/trace/trace_events.h:60:2: note: in expansion of macro 'DECLARE_EVENT_CLASS' DECLARE_EVENT_CLASS(name, \ ^ ./include/trace/events/oom.h:31:1: note: in expansion of macro 'TRACE_EVENT' TRACE_EVENT(reclaim_retry_zone, ^ Please submit a full bug report, with preprocessed source if appropriate. See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
  3. 考えられる原因 8 gcc Linuxカーネル メモリ、マザーボード、 CPU、その 他いろいろ ソフトウェア ハードウェア gccが使うライブラリ

    ユーザ空間 カーネル空間 • PCでは普通はソフトウェアを疑う ◦ ハードウェアは莫大な試験を経てリリースされている 試験中のハードウェアなどでは話は別
  4. gccが原因かどうか • やったこと ◦ 何度もビルドして再現性を確認 • 結果 ◦ ランダムに発生する ◦

    segmentation faultが発生する場所は毎回異なる ◦ Linuxカーネル以外のコードをビルドしても発生する • gccは入力が同じなら同じ出力を吐く ◦ 入力: ソースコード、コンパイルオプション ◦ 出力: アセンブリソース • 少なくとも問題はgcc(もっと言うならユーザプログラム)ではありえない 11
  5. Linuxカーネルが原因かどうか • やったこと ◦ 複数のOSカーネル上で再現試験 (gccでビルド) • 複数のOSにおいて問題発生 ◦ Windows

    Subsystem for Linux(WSL) ▪ gccの並列ビルド時のfork()が失敗 ▪ WSLのカーネルはMicrosoftの完全独自実装 ◦ 別のかたのNetBSD環境 ▪ gccがsegmentation faultで異常終了 • Linuxカーネルが原因の可能性は非常に低い ◦ 3つのOSカーネル全てに同じ /類似バグがある確率 <<< ハード問題の確率 13 gcc WSLの カーネル NetBSDの カーネル Linux カーネル
  6. どのハードウェアが原因か • 候補 ◦ メモリ、マザーボード、 CPUなどなど色々 • ソフト屋さんによるハードウェア障害調査の手段 ◦ 自分で作っていないので「このパーツが問題」という証明は難しい

    ◦ 「ソフトウェアの問題では説明できない /しづらい」ことを示す (前節の通り) ◦ 「他のパーツの問題では説明できない /しづらい」ことを示す (これから) 16
  7. メモリに問題はないか • やったこと ◦ メモリテストツールMemtest86を一晩流した ◦ メモリの型番が問題ないかを AMDに確認 • 結果

    ◦ Memtest86はパス ◦ サポートされる型番リストには載っていないものの問題ないだろうという言質をとった • memtest86で検出できる程度の壊れ方はしていない ◦ memtest64をパス != メモリは正常 17
  8. エアフローに問題はないか • やったこと ◦ AMDの技術者に確認 ◦ CPUの温度を確認 • 結果 ◦

    PC内部の画面を見ながらテキストチャットをして、問題ないだろうという言質をとった ◦ CPUは異常な温度にはなっていなかった • 見ただけでわかるような問題はなかった 18
  9. インターネット上の調査 • やったこと ◦ AMDフォーラムというAMD製品のユーザが集うフォーラムでの調査 • 結果 ◦ 数十人が同じ事象に遭遇していた ◦

    Ryzen1000系以外に使っているパーツはバラバラ • CPUがかかわっている可能性が高い ◦ 他のパーツだけの問題だとすると全員の環境で同じ事象が起きていることが説明しづらい 19
  10. 事の顛末 • 問題に遭遇したユーザたちが調査を続け、AMDに説明を求め続けた ◦ わたしもソフト面から解析して「 CPU以外の原因では説明がつきづらい」ことを訴え続けた • 最終的にAMDがphoronix上で問題を認めた ◦ https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response

    ◦ Ryzen 1000系でのみ発生する、 (当時の)Thread RipperやEPYCでは発生しないと回答 ◦ 問題が発生する人には回収すると回答 ◦ 原因は“performance marginality issue”と表現された • 特定の負荷をかけたら挙動が怪しくなる不良品が良品として出荷された? 20
  11. まとめ • トラブルシューティングのコツ ◦ 問題が発生させうる仮説を羅列する ◦ 確率の高そうなものから一つずつ潰す • ソフト屋さんが特定ハードウェアの問題を主張する方法 ◦

    自分は作ってないので「このハードが悪い」と直接証明するのは難しい ◦ 「ソフトウェアの問題では説明つかない」ことを訴える ◦ 「他のハードウェアの問題では説明つかない」ことを訴える 22