パスワードを忘れた? アカウント作成
13318555 story
AMD

Ryzenで発生しているSEGV問題、原因はCPUのキャッシュ? 70

ストーリー by hylom
すごい解析力だ 部門より
あるAnonymous Coward 曰く、

AMDの新CPU「Ryzen」でLinuxカーネルやgccをビルドするとセグメンテーション違反が発生する場合がある問題が確認されている。これはRyzen SEGV Battleと呼ばれて流行中だが、EIRAKU氏によるとSEGVの発生原因はインストラクションポインタから64バイトズレた位置の命令を実行してしまうことだそうだ。

この問題についてはsatoru_takeuchi氏による「Ryzenにまつわる2つの問題」という記事が詳しいが、再現性が低く、また確実な対処方法も判明していないという状況であった。

EIRAKU氏はBitVisorというハイパーバイザで検証を行い、call命令を起点にインストラクションポインタから64バイト手前にある命令を実行してしまう現象を確認したそうだ。この現象の結果、ズレた位置にある命令が不正なアドレスにアクセスしセグメンテーション違反や一般保護違反が起こっていたという。この64バイトという数値はキャッシュラインサイズと一致しており、命令デコーダかL1命令キャッシュ、あるいはRyzenで新設されたμOPキャッシュ辺りに問題がある可能性が高く、Twitterではマイクロコードの更新で直るのか疑問視する意見もあった。

なお、AMDはこの件について現時点ではメディアを通じてのアナウンスはしておらず、コミュニティでの対応とサポートリクエストを発行した人に対する交換対応のみ行っている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 訂正依頼 (スコア:3, 参考になる)

    by satoru_takeuchi (48095) on 2017年06月23日 19時39分 (#3233148)
    > なお、AMDはこの件について現時点ではメディアを通じてのアナウンスはしておらず、コミュニティでの対応とサポートリクエストを発行した人に対する交換対応のみ行っている。

    現時点でAMDは交換対応すると明に言ったわけではなく、個別に対応すると言っただけです。私は既にAMDに色々情報を伝えていたためか、すぐに交換対応になりましたが、サポートリクエストを発行したものの、ハード構成など色々な情報を聞かれている途中の人もいます。
  • by Anonymous Coward on 2017年06月23日 17時08分 (#3233071)

    命令デコーダかL1命令キャッシュ、あるいはRyzenで新設されたμOPキャッシュ辺りに問題がある可能性が高く、Twitterではマイクロコードの更新で直るのか疑問視する意見もあった。

    マイクロコードか設定でキャッシュを無効化する対策がされるだろうから、修正できるでしょ。
    #あれ、なんか既視感 [wikipedia.org]がある話の気が

    • タレコミのリンク先を見てると、分岐予測で何かコケてる気がするんですけどね。
      http://www.4gamer.net/games/300/G030061/20170228119/ [4gamer.net]
      分岐予測で、積極的にニューラルネットワークを使ってるので、そこのアルゴリズムのバグが絡んでるんじゃないかという臭いがプンプンしますけどね。変なアドレスに飛ばすとか、キャッシュページ間違えるとか、分岐予測の結果を出すときか外した時に間違ったアドレスを振り出してるような…

      となると、マイクロコードかもしれないし、ハードコーディングされてるかもしれない(;´Д`)

      親コメント
      • もう一つありました。
        「分岐予測しなくていいのに発動してしまう」。
        非常にレアケースということで、ブランチ命令でもないのに分岐予測を呼び出して、その結果、おかしなアドレスを振り出して分岐判断しちゃうとか…
        # JMPとかCALLで起こってるのだとしたら、尚更…

        親コメント
      • 私も分岐予測系だと思うけど、ロジックじゃなくて内部ノイズかクロストークで弱い FF がラッチできないか反転しているような顔つきかなと。

        石によって頻度がばらつくようですし、リンク手繰るような分岐では出なくて、分岐で処理を大きく変える処理が多いようなアプリで出ているっぽい。
        親コメント
        • by Anonymous Coward on 2017年06月24日 0時20分 (#3233254)
          あのさあ、お前らバカだろ

          分岐予測は予測でしかないから、本来とは違うものが出力されても遅くなるだけでプログラムは正しく実行されるんだよ
          親コメント
          • あきれた。CPU 知らないでしょ。分岐予測 Hit で違うストリーム教えられたらまともに動くわけもない。
            • by Anonymous Coward

              お前、正しい動作と単に(すごく)遅いのことの区別もついていないのかよ……

              • 必ずしも投機実行ではない。分岐予測はその本来の目的からしてかならず分岐先の命令をプリフェッチするので、それが狂ったら投機実行などやっていなくても動作はめちゃめちゃになる。

                #但し、Rizen は投機実行するアーキなのは知られているので、そもそも遅くなるとか馬鹿じゃないかとしか思えないけど。

                親コメント
              • 分岐判定と投機実行は一応別の話だということがわかっていないようだが、Rizen は投機実行なアーキなので、投機と組み合わせた場合で話をしようか。

                現代のアークテクチャは分岐多段で複数のストリームで投機実行をかけますが、ここでは話を簡単にするために一方向の分岐で考えましょう。
                命令実行時、デコーダで分岐命令が検知された場合は、分岐先を登記実行するわけですけど、その際にそのストリームについているタグとして、普通は当該分岐命令で分岐したかしないかが必ず含まれます。
                また、分岐先アドレスと分岐先フェッチに使うアドレスは別のゲートですから、同じであるという保証なんかどこにもないです。今そういうレベルの話をしている。
                で、実際に分岐判定が下ったとき、どのストリームを選択するかの判定をしなければいけないわけですが、この際にストリームの判定をするのに使うのも、当該分岐命令で分岐したかしないかで、いまはその分岐命令の判定時のフラグ判定が化けたか、あるいは分岐先アドレスのフェッチが化けたか、っていっているわけですから、プロセッサ実行時にそれが検知できるわけがないし、実行結果も正しくない。

                親コメント
          • by Anonymous Coward

            このCPUは知らないけど、一般的なCPUでは分岐する時には既に予測に従って実行(投機実行)されてるんだよ
            予測先が間違ってれば、既に実行されている結果も間違ってるわけで

            • どこにぶら下げるか迷ったんですが、ここに。
              なんかね、言葉の定義の問題ですれ違ってるだけで、それを説明しないといつまで経っても平行線でしょう。

              ・狭義の(本来の)「分岐予測」
               条件分岐命令で、「分岐する場合と分岐しない場合と、どちらが確率が高いか」を判定するもの。分岐予測器の出力に基づいて、分岐する可能性が高いなら分岐先の命令を投機実行するし、分岐しない可能性が高いなら続く命令を投機実行するだけ。
               その後、実際の条件判定結果に基づいて、当たっていればそのまま実行継続するし、外れたなら既に実行された結果を差し戻す。
               分岐予測には「予測先」なんて概念はありません。分岐予測が「分岐する」と判定した時に投機実行するのは、「実際の分岐命令の分岐先」であり、「予測」ではありません。だから、「分岐予測を間違えても遅くなるだけで結果はおかしくならない」です。

              ・狭義の分岐予測とは異なる「分岐先予測」
              分岐予測とは別に「分岐先予測」という技術もあります。「分岐するかどうか」ではなく、「分岐先がどこになるか」を予測することで、分岐先命令のフェッチ待ち時間によるオーバーヘッドを減らす技術

              ・広義の(CPU構成要素としての)「分岐予測ユニット」
              Ryzenの「分岐予測ユニット」は、分岐予測と分岐先予測とμOpキャッシュとが一体になっていて、
              予測に基づいて実行すべきμOpコードを直接出力します。
              ここが間違えたら、まったく異なる命令を実行してしまう可能性があります。

              この「狭義の分岐予測」と「分岐予測ユニット」のどちらについて語るのかを明確にせずに議論してるからすれ違ってる感じですね。

              親コメント
            • 予測先が間違ってれば、既に実行されている結果も間違ってるわけで

              そのどっちが正しいかという予測が間違ってるんじゃなく、予測先が実行できないような変なところを指してるから問題になってる。

              上のコメントにも出てたけど、CPUはケーキか煎餅どちらか予測していて
              いつもは、ああケーキだね、こんどは煎餅だねってなるんだけど、

              今回の件は、ケーキだと予測したけど本当は煎餅だったね、てへ☆彡って話じゃなく、
              ごく希に片方が毒饅頭にかわるからヤベェって話だよ

              親コメント
              • >ACさんが言ってる"遅くなるだけ"というのは、投機実行やキャッシュ機構にバグがなければ、毒饅頭はそのまま捨てられてキャッシュメモリ帯域や容量が無駄になるだけ、全体的に遅くなるだけだということ。

                これは間違い。分岐予測の誤動作ってのは、分岐予測ミスなら上記の通りですけど、分岐予測 Hit の場合、要するに判定として分岐方向を間違うということだから、全体に遅くなるだけなんて程度ですむ訳がない。
                親コメント
              • すみません、直下にぶら下がってないのでコメントに気づいてませんでした。

                ケーキと煎餅の例で言うならば、
                ・(狭義の)分岐予測: どちらの注文が入るか確定していない状況で、どちらを注文する確率が高いか予想する部分。
                ・投機実行: 予測に基づいて調理を始める。予測が当たれば出来たをものそのまま提供。外れたら作りかけのものは捨てて、注文通りのものを調理する。
                ・(広義の)分岐予測: 狭義の分岐予測に基づいて厨房にオーダーを出すところまでひっくるめた大枠。
                と考えるべきでしょう。

                > 理論的にはケーキと毒饅頭を持ってくるまでが分岐予測

                違います。「(狭義の)分岐予測」はあくまで「ケーキか煎餅かを予測」するところまで。分岐予測が間違えても注文処理に時間がかかる(遅くなる)だけ。
                「煎餅が来るはずなのに毒饅頭が出てきた」としたら、それは「(狭義の)分岐予測は煎餅と予想した」が、「厨房が毒饅頭を作ってきた」という状況。
                で、「実際の注文は煎餅だった(予測が当たった)ので、できたものをそのまま客に出す」ことにした場合、その結果は「客に毒饅頭を食わせる」ことになります。

                これは、「狭義の分岐予測」には問題はないが、予測に基づいた厨房処理のどこかに問題ある状況であり、
                それをひっくるめた全体の「広義の分岐予測」には問題がある状態。

                たとえを止めて普通に書くと、
                「(広義の)分岐予測」=「(狭義の)分岐予測」+「分岐先予測」+「分岐予測・分岐先予測の結果に基づいた命令フェッチ」
                という処理構成において、「分岐予測に基づいた『命令フェッチ処理』がおかしい」と推測される状況で、
                あるAC氏他は「それは『(狭義の)分岐予測』の問題ではない」と主張していますし、
                alp氏他は「それは『(広義の)分岐予測』の問題である」と主張しているわけですが、
                これは分岐予測の定義がずれてるだけで、どちらが間違っているとかいう話ではないでしょう。

                親コメント
          • by Anonymous Coward

            「分岐予測」がどのような処理なのか知っていたら決して出てこないような煽り文句ですね…。

    • by Anonymous Coward

      マイクロコードか設定でキャッシュを無効化する対策がされるだろうから、修正できるでしょ。

      パフォーマンス爆下げの悪寒。
      マイクロコードでの修正不可の場合は全数交換、そしてAMDは伝説へ。

      • by Anonymous Coward

        ステッピングが上がれば解決するし一部のユーザはキャッシュバックで済むかも。
        AMDの良心やらなんやらが試されている訳だから今後の対応に期待したいところだ。

        • Re: (スコア:0, 興味深い)

          by Anonymous Coward

          > 一部のユーザはキャッシュバックで済むかも。
           
          キャッシュだけに。

    • by Anonymous Coward

      >> なお、AMDはこの件について現時点ではメディアを通じてのアナウンスはしておらず、コミュニティでの対応と

      > マイクロコードか設定でキャッシュを無効化する対策がされるだろうから、修正できるでしょ。

      AMDはコミュニティでOPCacheを無効にしろって言っているよね。実際にBIOSでOPCacheを無効化するとこの問題は止まるし、OPCacheからの供給が必要になる場面は現状ないので性能もほとんど変わらない。コンパイラーが間に合っていないのでつらいのはIntelも同じ。

      >> サポートリクエストを発行した人に対する交換対応のみ行っている。

      約一名に対して?

      • by Anonymous Coward

        > 実際にBIOSでOPCacheを無効化するとこの問題は止まるし

        それで解決しない人が何人もいるからここまで騒ぎが大きくなってるわけですが。

        > 約一名に対して?

        なぜ息をするように嘘を書けるんだろうね?

        • by Anonymous Coward

          それで解決しない人が何人もいるからここまで騒ぎが大きくなってるわけですが。

          騒いでいる人が約一名いるからでは?笑

  • by Anonymous Coward on 2017年06月25日 11時58分 (#3233737)
    EIRAKU氏の日記によると、
    http://www.e-hdk.com/diary/d201706c.html#22-3 [e-hdk.com]

    > これ。 エラーコードが 6 で、書き込み時のページフォールトを表し、アクセス先のアドレスは 0xa。 しかし %rip が指す命令は、全然違うアドレスの読み取り。 そしてちょうど 64 バイト手前にそれっぽい命令があるという形。 この 64 バイトはただの偶然の可能性もあったが、その後も LBR や call 先のズレなどの形で現れたというわけ。 なお、このページフォールトの件ではこの 0x113f57d の直前にジャンプ命令などなく、レジスターの中身を見ても直前までは順番に実行されてきたとしか思えない状態。

    キャッシュラインの途中でいきなり死んだ模様

    一般的にデコーダにはキャッシュラインサイズのバッファがついていて、命令の切り出しはここから行う
    命令キャッシュの出力がこのバッファに入る
    x86はキャッシュラインをまたいだ命令がありうるから、最低2個のバッファが必要
    分岐をまたいで例えば4wayのデコードするなら、分岐命令があるラインのバッファと、分岐先の命令があるラインの別のバッファが必要

    add
    bra L1
    ...
    L1:
    sub
    mul
    という列を考えると、addとbraが乗ったラインと、subとmulが乗ったラインを別々のバッファに入れて、2つのバッファから4命令を並列にデコードする

    EIRAKU氏の日記のように、キャッシュラインの途中でいきなり変な命令を実行してしまった、というのはどういう場合に起こりえるかというと
    1. ラインの途中でデコード対象のバッファが切り替わってしまった
    2. 読出し中のバッファの内容が書き換わってしまった
    の二つの場合が考えられる
    2については、ズレたアドレスのキャッシュラインを読みだして、デコーダが読出し中で排他制御されているバッファのほうに書き込まなければならない
    だから2が起きるためにはエラーが二か所同時に発生しなければならない
    したがって2より1のほうが可能性は高いと考えている

    実際のところどこが悪いのかさっぱりわからんのだがね
  • by Anonymous Coward on 2017年06月23日 17時13分 (#3233073)

    なんか特定条件で特定のビットが0に落ちるのかなぁ
    64バイト手前といっても減算されるわけじゃないだろうから、callの先を0x80にアラインすればおいしく使えそう

    • by minet (45149) on 2017年06月24日 8時41分 (#3233320) 日記

      交換するとは言ったが、交換で直るとは言ってない。
      煽りではなく、個別の不良品である可能性を検証するためにまずは交換で対応(報告のあった現物を調査)しているフェーズと思われます。

      親コメント
  • by Anonymous Coward on 2017年06月23日 17時36分 (#3233080)

    Pentium FDIVバグみたいに詫び石配布はまだですか?

    • by Anonymous Coward

      そもそも詫びてないんだよなぁ

      • by Anonymous Coward on 2017年06月24日 10時19分 (#3233353)

        下手に詫びると裁判で不利になるからアイムソーリー法なんてものを作る羽目になったくらいだからね。しかたないね。

        親コメント
    • by Anonymous Coward

      石の意味が一般的な詫び石と違う気がする

  • by Anonymous Coward on 2017年06月23日 17時51分 (#3233088)

    よく訓練されたLinuxユーザー「プロセスが死んだ…CPUのバグでは?」
    よく訓練されたWindowsユーザー「プロセスが死んだ…アプリケーションのバグでは?よくあることだな」

    • by Anonymous Coward on 2017年06月23日 18時12分 (#3233094)

      LinuxのGUIアプリで平均的Windowsアプリよりはるかに不安定なのがいっぱいあるのを知ってるので、こんな感想は出てこないな。
      OS関係なく、この発生頻度で一般ユーザが追及するのは無理だろ。
      Linuxユーザが気づいたのは、gccでlinuxカーネルのビルド中に落ちたっていうのが大きい。

      親コメント
      • by Anonymous Coward

        だからよく訓練されたユーザーしか気が付かないという話になるのでは?
        あまり訓練されていないユーザーだとカーネルビルド中に落ちてもまあそんなものか、で済ませますし。

        • by Anonymous Coward
          Linuxカーネルとか世界で一番頻繁にビルドされてるプログラムだろうから他の環境で落ちるとか落ちないとか比較しやすかったんじゃないの
          • by Anonymous Coward

            そうは言ってもよほど訓練されてなければ疑わないです。
            再現性が低いのなら、なおさら。

    • by Anonymous Coward

      既に書かれて居る様に
      「AMDの初物か。良くあることだな」
      って感じだろ。
      ま実際はAMDに限らず初物では良くあるのがこの業界だしな。

      • by Anonymous Coward

        故に「人柱」って言葉が使われてますもんねぇ。

        ※この場合、「率先して犠牲になってやろうじゃないか」という心意気なので、ドMの方が合ってる気がしますけどね。

    • by Anonymous Coward

      よく訓練されたLinuxユーザー「プロセスが死んだ…フリーだから」

      • by Anonymous Coward

        よく訓練されたWindowsユーザー「プロセスが死んだ…Windowsだから」

        • by Anonymous Coward

          よく訓練されたLinuxユーザー「プロセスが死んだ…Linuxだから」

        • by Anonymous Coward

          WindowsだとMS製以外のアプリがメモリアクセス違反とかで落ちたときも
          なぜか邪悪なM$(笑)が叩かれるからなww

    • by Anonymous Coward

      Windowsには発生条件が作られないバグがあるのでしょう

    • by Anonymous Coward

      カーネルのビルドでgccが落ちたら、真っ先にgcc疑うからね
      どうせgccのバグだろって言われて終わり

  • by Anonymous Coward on 2017年06月23日 18時45分 (#3233119)

    命令飛ばしてる可能性有る方が問題でしょ
    暫くメモリ関連の命令じゃなかったりたまたまレジスタ値のアドレスが有効範囲に収まっててエラー起さず
    変な値でもって突き進む

    • by Anonymous Coward

      あ、さすがに命令飛ばしてんじゃなくスーパースカラ用のアドレスキャプチャ失敗してるのかもしれんな

      • マザーボードとの相性問題で、特にX370系のチップセットを使ってるマザーボードで、一部のメーカのものだと、DDR4メモリがうまく使えないケースがあるというのが問題になってましたが(マイクロコードの更新で改善した?)、
        その辺りの話かもしれませんね。
        メモリの読み書きの時にビットごとの遅延時間の誤差が出てデータが化ける場合があるとか、キャッシュでその手のことを起こしてるとか…
        最初からうまく行ってたメーカのマザーボードは、「運が良かった」だけだったとか、ありそう…

        親コメント
  • by Anonymous Coward on 2017年06月24日 4時03分 (#3233290)

    てぃーおー

  • by Anonymous Coward on 2017年06月24日 7時32分 (#3233308)

    タイミング検証漏れでメタステーブルが起きてるだけだったりして。

typodupeerror

犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー

読み込み中...