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

AMD、RyzenのSEGV問題を認める 76

ストーリー by hylom
結局どれがセーフなのだろう 部門より
shesee曰く、

Linux上で、kernelやgccなど大きなソフトウェアを繰り返しMakeするとコンパイラがSegmentation Faultで失敗する問題についてAMDは問題の存在を認めたようです(techpowerupHotHardware)。

AMDは問題がマザーボードやメモリではなくCPUの問題であること、Linuxで発生するもWindowsでは再現しないこと、初期のRyzenで発生するもEPYCやThreadripperでは発生しない事を報告しました。その上で、影響を受けるユーザーに対してはカスタマサポートで個別対応するようです。

また、どうやらWindowsユーザに対しては交換対応はしないようです。株価が上がったとはいえ、AMDにはリコールする財務的余裕はなさそうです。

B2ステップでアンコアの修正をするとの話が出てましたが、ThreadripperはB1ステップですので、製造上の問題なのでしょうか。市場にあるRyzenプロセッサーのどれが問題ないのか区別する方法が無いのもちょっと不誠実さを感じます。

  • マザーボードのファームウェア更新で解消したとか、メモリ設定を正しく読めていなかったことが原因とか、マザーボードの設定を
    AMDのサポートの指示通りに変更すると、パフォーマンスが大幅に落ちるが解消するとかいう話が出てました。
    動作保証できない条件で出荷していたのか、単に後から問題が見つかったのか。個人では速くてちゃんと動けばなんでもいいんですけどね。

    ここに返信
  • by Anonymous Coward on 2017年08月09日 19時12分 (#3258785)

    https://twitter.com/fujii0/status/895072079980015616 [twitter.com]
    > 2個目の交換品到着。噂通り stepping は変わってなくて、謎の刻印は UA 1725SUS。噂では 2017年第25週(6/19の週)の意。ちなみに最初に購入したのは UA 1707PGT で、1個目のRMAが UA 1716PGT。

    https://twitter.com/fujii0/status/895072079980015616 [twitter.com]
    > 2回目のRMA交換品でデフォルトのBIOS設定(SMT有効,OPキャッシュ有効)、ASLR有効で13時間以上テストしてSEGVなし。これ以上のテストは必要なさそうなので、あとはまだ手元にある1回目の交換品を返送して、それで私の #Ryzen_SEGV_Battle はおしまい。

    ということだそうで、最初に購入したCPUと、AMDから送られてきた1回目の交換品ではダメだったけど、
    2回目の交換品では直ってたと。

    Threadripper で発生しないというのは、最近の生産品だからなんでしょうか。

    ここに返信
  • by Anonymous Coward on 2017年08月10日 13時29分 (#3259340)

    https://www.techpowerup.com/forums/threads/amd-confirms-ryzen-marginal... [techpowerup.com]

    ここを読めば、おおよその事は分かるでしょう。ワークアラウンドは、μ op cache を切ることです。ただ、設定自体が存在していない M/B が大半なので、M/B メーカーの対応待ちでしょうか (自分で mod BIOS を作るか)

    FreeBSD で出た、特定のメモリ空間をアクセスすると問題が発生するのは、新しい石が来ても解決しないようです。μ op cache と関連性があるかは、現段階では不明です。

    同じく %rip register (64bit Instruction Pointer) が、特定の条件で 64 Bytes ズレるのも、μ op cache disable だけで解決するか、不明です。

    AMD は linux だけと言いたいようですが、各 OS で問題は発生しており、Windows で発生しないという根拠は示されていません。

    なぜ Ryzen TR や、EPYC では問題が発生しないのかも、説明が行われていません。

    メモリタイミングを正しく設定しない M/B が販売されていた事、GCC の segv は歴史的に出て当たり前など、様々な事が重なって、問題に対して発表が遅くなったみたいですね (QA が下手というか、していないというのに等しい気がしますが)

    以下は噂話です。

    製造プロセスの過程に問題があって、それらが改善された週の物は、(一部の問題を除いて) 動くようです。14nm LPP をどこの会社が作ったか考えると、想像に難しくない話しかと。

    今まで黙っていたのは、Ryzen TR, EPYC への影響や、株価の低迷を避けたかったという憶測もありますが、ユーザーが問題を提起してから 4 ヶ月近く放置していたのですから、そう言われても、致し方ないでしょう。

    ここに返信
  • by Anonymous Coward on 2017年08月09日 18時49分 (#3258773)

    makeを繰り返さなければ問題ないのか?

    ここに返信
    • by Anonymous Coward

      SEGVなんかにmakeないで!という

    • by Anonymous Coward

      makeするやつらは負け組って事だな

    • by Anonymous Coward

      makeしたと思うまで ryzenはmakeしない

      i5で妥協した俺

    • by Anonymous Coward

      makeは単に複雑で負荷が高いから、それで気付いた、ってだけのようですよ。

      現象から見ると、どんなプログラムでいつ起きてもおかしくない、エラーで落ちる以外にもデータの破壊等が起きてるかもしれない(気付いてないだけ)、という可能性も否定できない、というか十分ありそうとのこと。

      Windowsで発生しない理由は不明ですけどね…。

      • Re:繰り返し (スコア:2, 参考になる)

        by Anonymous Coward on 2017年08月09日 21時02分 (#3258872)

        makeというかgccによるコンパイルですね。
        今回に限らず、gccだけで症状が出るハードウェアの個別不良ってよくあって、以下のようにFAQ にまでなってます。
        https://linuxjf.osdn.jp/JFdocs/GCC-SIG11-FAQ/sig11faq.html [linuxjf.osdn.jp]
        一番よくあるのがメモリ不良で、今回もみんな最初はそちらを疑ってたんですが、色々調べているうちにどうやらメモリじゃないっぽいなということに。

        ハードウェア不良なわけで他の処理で症状が出ても不思議はないんですが、他では症状がでなくてgccだけで出るせいでgccの方のバグだと疑われることも多く、FAQにまでなってるのはその辺の事情もあります。

        • 6月頭のPhoronixの記事に対するコメントで、 [phoronix.com]
          「ハイパースレッディングを有効化していて、二つある内の一つのスレッドが(CPUコアをまたがずに収まる?)ループにある時に、もう片方のスレッドに割り込みがかかると、割り込み処理が終わった時のIRETQで復帰するタイミングでCPUが不安定化する」みたいなことを書いて、調査データをAMDに送付した。と言う人がいましたから、そこら辺の状況確認がやっと出来たんじゃないですかね。
          で、Linuxのスケジューラがどういうコア割付してるかはともかく、gccみたいにシングルスレッドをガンガン廻していくソフトだと、割り込み時処理のスレッドと、処理のスレッドが同じコアで共存しやすいとかそういう話なんでしょうかね。

          --
          --暮らしの中に修行あり。
          新しいblogはじめました。 [hateblo.jp]
      • by Anonymous Coward

        > kernelやgccなど大きなソフトウェアを繰り返し

        ですからね。直接的なmakeの話ではなくて大事なのはこっちでしょう。

  • CPUを買ったらmake耐久テストをしてから使えばいいんですね。

    ここに返信
  • 懲りないAMD (スコア:0, フレームのもと)

    by Anonymous Coward on 2017年08月09日 20時06分 (#3258821)

    その昔PhenomのTLBエラッタ食らったので、こちらはそれに懲りて、それ以降AMD製CPU買ってない。

    やっぱ買わなくて正解だったんだと改めて確認できたわ。

    ここに返信
    • by Anonymous Coward

      エラッタならintelにもあるんですけどね

    • by Anonymous Coward

      早くAMDが滅んでIntelの独占になるといいですね!

    • by Anonymous Coward

      Intelのエラッタは良いエラッタ
      Haswellで実はトランザクションメモリが使用できなくても良いエラッタ

      • by Anonymous Coward

        データ破壊・システム停止の可能性がないんだから良いエラッタでしょ
        そこはSkylake/Kaby LakeのHTT挙げなきゃ

        • by Anonymous Coward

          いやHaswellのはデータ破壊の可能性あったんじゃないかな。
          Transactional memory 機能の不具合なんだから、トランザクションの整合性が失われるような問題だった筈。
          Haswell でラッキーだったのは、新命令の不具合なのでその命令をなかったことにするだけで済み、ハードウェア交換までする必要はなかった点だね。
          ごくごく少数、Transactional memory 命令を試してみたくて発売から発覚までの2ヶ月の間にHaswellを買った人がいて、そういう人はちょっと可哀想だったなあ。

  • by Anonymous Coward on 2017年08月09日 20時28分 (#3258841)

    それ、Linuxのバグじゃないの?

    ここに返信
    • by Anonymous Coward on 2017年08月09日 21時22分 (#3258883)

      Linuxカーネルで特異な部分が原因というと、jump label (*) などの自己書き換えコードが怪しいような?
      cross-modifying codeでSEGVが起きる [github.com]との情報もあるし、誰かjump label切ったカーネルを試してほしい

      * 自己書き換えでnop命令とjmp命令を切り替えることにより、分岐の効率化を行う機能

    • by Anonymous Coward

      WSLでも再現するって言ってなかったっけ?

    • by Anonymous Coward

      新しいCPUのレジスタをフルサイズ全部使っているよ、ということなのかな

    • by Anonymous Coward

      FreeBSDでは発生するらしい。
      Linux subsystem for windowsで発生するという報告もある。
      発生する条件はかなりシビアらしくて誰の言ってることが正しいのかもはっきり言ってよく分からない。

      • by Anonymous Coward on 2017年08月09日 21時15分 (#3258879)

        Linuxだけではなく、少なくともDragonflyBSD、NetBSD、FreeBSDで症状が報告されてます。
        さらに、AMDが公式にCPUの問題だったと認めている上、AMDから送られてきたCPUに交換するだけで直った報告もありますから、もはやLinuxやgcc側の問題であるという可能性は残っていません。

        発生する条件は確かにシビアなんですが、今は数時間程度で症状を再現できるテストプログラムが公開されていますから、問題のあるチップか否かの判別は確実にできます。

    • by Anonymous Coward

      仮に「8TB-128TBの仮想メモリアドレスにアクセスすると問題が起きるCPU」があったとして原因が分かってない段階で「Windows 10で問題が起きてWindows 7で起こらないんだからWindows 10のバグ」って言ってるようなもの

typodupeerror

人生の大半の問題はスルー力で解決する -- スルー力研究専門家

読み込み中...