AMDがRyzenのSEGV問題を確認 Windows環境、EPYCとThreadripperでは発生せず

Ryzenプロセッサの特定のLinuxワークロード(並列コンパイル作業負荷など)で発生するセグメンテーションエラー(SEGV問題)をAMDが確認したことをPhoronix.comが伝えた。

AMDはこの問題がEPYCやThreadripperプロセッサには存在せず、初期のRyzenプロセッサでのみ且つLinux上で再現するとのこと(AMDの検証ではWindowsでは再現できず)。

AMDによれば、これはマザーボードの問題ではなく、CPU自体の問題であるという。AMDではこの問題によって影響を受けると考えられる顧客に対してカスタマーケアに問い合わせすることを呼びかけている。

http://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response

Sponsored Link

828: Socket774 2017/08/08(火) 17:07:47.47 ID:gce6gYFR0

834: Socket774 2017/08/08(火) 19:30:10.03 ID:UIaUxIkS0
>>828 Linuxサポート入って大勝利じゃん。

AMDの分析では、これらのRyzenにおけるsegfaultは特定のマザーボードベンダーの問題ではなくプロセッサー自体の問題です。
AMDは影響を受けていると考えているお客様に、AMD Customer Careに問い合わせていただきたいと申し出ています。

segfaultに関して連絡をされた人たちの中には、廃熱や電力などの問題を抱えている人もいるが、
AMDはLinuxにおけるこのようなマージンの問題に遭遇した人たちと協力することを確約している。AMDは今後、コンシューマ向け製品においてLinuxテスト/ QAも強化する予定です。

815: Socket774 2017/08/08(火) 07:34:43.80 ID:IDWMZhns0
ThreadripperとEPYCでは起きないんですね良かった 

833: Socket774 2017/08/08(火) 19:22:00.39 ID:JhBnwMO7M
逆に不思議なのは、B1ステッピングのはずのThreadripperでは問題確認出来ていない事だな
あくまで初期生産のRyzen固有の問題とか書いてある(本当だろうか?

838: Socket774 2017/08/08(火) 20:05:14.33 ID:bBXr67Yu0
>>833
RMA交換品で他変えずに治った人もいるしRyzenはコンシューマ向けだからってことで品質テストを緩くしてたんじゃないの
あくまで製造不良が有意な量紛れ込んでるだけなんじゃない?(だとすればよりタチが悪いんだけど・・・)

840: Socket774 2017/08/08(火) 20:13:55.07 ID:uf0uiHM/a
むしろ最初に騒いだ当たり屋のせいで遅れたんじゃ無いのコレ?

842: Socket774 2017/08/08(火) 20:28:09.66 ID:i8xwWMGhM
初期個体というより初期BIOSでメモコンぶっ壊した連中に対して保証という感じに見える
初期のryzenで確認出来るってAMDの認め方なんか変だし

801: Socket774 2017/08/08(火) 19:30:23.54 ID:vJw1Ss/d
認めるがリコールはしないってふざけてるな。誰かリコールに追い込めよ。

803: Socket774 2017/08/08(火) 19:48:06.83 ID:JhBnwMO7
リコールにしないのではなく、リコールに踏み込めないんじゃないか?
恐らくAMD内部でも「(初期生産Ryzenと後期生産Ryzenと)何が違うのかが分からない、どれぐらいの規模になるのかも不明」
でまだ特定に至らずで調査中なのかと
中にはPCの環境(スペックやBIOS設定等)のせいで起きている事例も集まっているから余計にややっこしいことになってるとかな

EPYCはともかく、B1ステッピングのはずのThreadripperでは起きてないらしいからさ

847: Socket774 2017/08/08(火) 20:41:43.34 ID:Q+A7ScK/0
ぶっちゃけ最初はおま環かと思ってたけど、
uOPキャッシュ切ってメモリタイミングを正規化して走らせたら3日以上問題無く通ったっていう検証が出てきた辺りからやっぱりCPUもおかしいんじゃないかと思ってたわ

ただし、
・おま環も荷担している
・CPU依存の問題だからWindowsでも起こる時は起こる
・B1ステッピング固有の問題か、Zenコア全体の問題のどちらか
だと思ってたら半分違った

AMDによると
・CPUにも問題あるが、おま環も荷担している
・少なくともAMDの環境ではEPYC,B1ステッピングのはずのThreadripperでも起きていない
・RyzenでもWindowsでは発生していない
・あくまで初期生産のRyzen固有の問題
ということなのね

848: Socket774 2017/08/08(火) 20:44:29.72 ID:NxPDYL2v0
初期と今で何が変わってるかってM/BのBIOSくらいだと思うがな・・・

849: Socket774 2017/08/08(火) 20:44:31.87 ID:B6kc3hRc0
初期よりも1.0.0.4aBIOSもやばいと思うけどな
6nsのDRAMのレイテンシ改善のシワ寄せがどこにいったでしょうかという話だし

853: Socket774 2017/08/08(火) 20:55:58.96 ID:nbM0Utlf0
>>849
> 6nsのDRAMのレイテンシ改善

すっかり忘れてたが確かに・・

851: Socket774 2017/08/08(火) 20:47:26.69 ID:Q+A7ScK/0
それよりもSEGVしないとAMDが主張しているWindowsとSEGVが出ているLinuxの差の解明をだな

852: Socket774 2017/08/08(火) 20:51:24.97 ID:cF9bWEbu0
AMD Customer Careとやらに問い合わせてみるか(うちのもしっかりsegfaultするので)

『AMDがRyzenのSEGV問題を確認 Windows環境、EPYCとThreadripperでは発生せず』へのコメント

  1. 名前:名無しの自作er 投稿日:2017/08/08(火) 22:26:23 ID:e8f7b0eab 返信

    発見者を誹謗中傷してた奴らちゃんと謝れよ。

    • 名前:名無しの自作er 投稿日:2017/08/08(火) 22:57:10 ID:09c037cd8 返信

      最初に騒いでた低スペのアホは明らかにおま環でしょ
      電源やメモリ糞過ぎだったし

      • 名前:名無しの自作er 投稿日:2017/08/08(火) 23:00:52 ID:886d60f2c 返信

        大本営がごめんなさいしても信者は認めないんだね(ゲッソリ)
        ほんとAMDにとっては信者が害悪だわ。

        • 名前:名無しの自作er 投稿日:2017/08/08(火) 23:06:04 ID:2ffd03581 返信

          あんな無茶苦茶な組み立て環境で原因究明なんてする方が無駄にしか思わないだろ普通

          • 名前:名無しの自作er 投稿日:2017/08/08(火) 23:27:49 ID:d608f176e 返信

            アムダーは懲りぬ媚びぬ省みぬだもんな。

            • 名前:名無しの自作er 投稿日:2017/08/09(水) 00:15:18 ID:c839c4a45

              あなたもですね

      • 名前:名無しの自作er 投稿日:2017/08/09(水) 02:29:12 ID:3c7a79dc5 返信

        最初に問題点を指摘した人や、最初の頃にLinuxフォーラムなんかで真面目に検証してた時期の人はいい人たちじゃんよ
        その後、この問題が騒がれだした後に煽りだしたバカどもがダメなだけ

    • 名前:名無しの自作er 投稿日:2017/08/08(火) 23:02:22 ID:e1d2c4fb6 返信

      ryzen_segv_testとかいう欠陥コードで問題究明を妨害した奴らか

      結局基準が示されてないのが怪しいよな
      メモリが原因の場合もあるからまずBIOSを最新、すべて定格にして、
      Linuxカーネルビルドしろってか?

  2. 名前:名無しの自作er 投稿日:2017/08/08(火) 22:26:59 ID:fdc6d4335 返信

    マイクロコードで直せなかったのか…

  3. 名前:名無しの自作er 投稿日:2017/08/08(火) 22:50:43 ID:3045f5652 返信

    AMDやっちまったな。しかし、なんでLinuxだけw
    まあ、あのgccが変なプログラムだってのは分かるけどな。>誰も解析できない。

    g++でも再現するのかな?
    C++コードってもっぱらg++でしかコンパイルしてるけど。

    • 名前:名無しの自作er 投稿日:2017/08/08(火) 23:34:37 ID:04549e2c4 返信

      タイミングをポーリングで取るような処理でCPUに近い処理を叩くような奴かな。
      クロックの影響受けるので。

      インテルのエラッタの時もあったが「そんな書き方止めろ」になるんじゃね?

      ただイベント駆動(Linuxだとシグナル)を頑なに拒む輩がLinux系には特に多いからねえ。つか窓でもそういうアレな奴が居る。

      • 名前:名無しの自作er 投稿日:2017/08/09(水) 07:54:22 ID:995119c30 返信

        C++のPGから見ると、イベント駆動を拒む感情は分からなくも無いですね。
        どのタイミングでイベントが発生するかまったく不明のプログラムを書こうとすると複雑怪奇なコードになる事が多い。

        とくにシグナルだと、処理途中にも関わらず強制的にシグナルに処理が移るから、排他制御するとデッドロックする可能性も考慮に入れないといけなくなるし・・・

  4. 名前:名無しの自作er 投稿日:2017/08/08(火) 22:55:43 ID:46e05235c 返信

    忘れちゃ困るがIntelもやっちまってるからな

    • 名前:名無しの自作er 投稿日:2017/08/08(火) 23:05:25 ID:e8f7b0eab 返信

      ねえねえIntelくんだっていけないんだよ〜
      って子供かよ。

      • 名前:名無しの自作er 投稿日:2017/08/08(火) 23:16:12 ID:2ffd03581 返信

        まるでインテルは少しも悪くないみたいな言い草だな

        • 名前:名無しの自作er 投稿日:2017/08/09(水) 01:13:33 ID:26f44785c 返信

          Intelさんアムダーにぬれぎぬ着せられてお気の毒。

          • 名前:名無しの自作er 投稿日:2017/08/09(水) 07:14:04 ID:c21b3e1e9 返信

            Intel CPUでも起きることをそんなに隠したいのかー

    • 名前:名無しの自作er 投稿日:2017/08/08(火) 23:05:41 ID:a24c168a8 返信

      まあ、結局どっちもどっちって感じだな

      • 名前:名無しの自作er 投稿日:2017/08/09(水) 00:00:34 ID:dcda1383a 返信

        既にマイクロコードで修正済のIntelとどっちもどっちってワロタ

        早くRyzenも修正しろよw

        • 名前:名無しの自作er 投稿日:2017/08/09(水) 01:14:25 ID:26f44785c 返信

          先に直した方が偉いんだぜ。

          • 名前:名無しの自作er 投稿日:2017/08/09(水) 11:16:23 ID:bd5f7b61b 返信

            ふーん
            で、GhostHook問題はいつ直るの?

        • 名前:名無しの自作er 投稿日:2017/08/09(水) 01:27:05 ID:88d33f82b 返信

          SkyとKabyのエラッタじゃなくて、SEGVの話じゃないの?あれはIvyでも出てた気がするが

    • 名前:名無しの自作er 投稿日:2017/08/08(火) 23:27:34 ID:ac3f2e802 返信

      でも、あっちは問題発覚後比較的速やかに修正のマイクロコード出してきたけど
      こっちは、やっと現象を確認した(原因がわかったとは言ってない)レベルだからなあ…
      トラブル発生時の地力はやはり違うわ。

      • 名前:名無しの自作er 投稿日:2017/08/08(火) 23:30:43 ID:e1d2c4fb6 返信

        マイクロコード出して結局半年も反映されなかったけどなw

      • 名前:名無しの自作er 投稿日:2017/08/09(水) 01:27:55 ID:88d33f82b 返信

        IntelもSEGV問題は解決してねぇだろ

      • 名前:名無し 投稿日:2017/08/09(水) 03:14:50 ID:d8858aea2 返信

        intelのLGA1151のHTのエラッタは修正済みになってるが半年前の修正は意味がない。ミスリードでintel自身が勘違いしていたためごく最近の修正でやっと直り始めたところなので、マザーによってはいまだに修正BIOS出してないとこも多数ある

        それとは関係なしにintelでもSAGVは起こってる。むしろ対応まったくやってないぶんSAGV問題に関してはintelのほうが遅れてるだろ

    • 名前:名無しの自作er 投稿日:2017/08/09(水) 03:20:24 ID:3c7a79dc5 返信

      そもそも、これが騒ぎになったのは、元々Intel CPU環境で出来ていたLinuxのカーネルとかのビルドが、Ryzenだとエラーが出てできないって話
      すなわち、Skylake以前のIntel CPUでは問題が出てなかったわけで、これは、今回の発表で初期のRyzenの問題だと確定した

      じゃあ、Intel CPUでも起きたという報告が複数あるじゃんという話はどうなのといえば、過去に、SEGV(セグメンテーション違反)が起きたという話があっても、報告者からの書き込みなどが結局は立ち消えになって、それでエラーが確実に発生するという話がない
      セグメンテーション違反なんてのは、ソフト環境や(メモリ相性などの)ハード環境でも普通に出る
      おそらく、おま環ってのが結論でしょ
      でなきゃ、何年も前から、LinuxフォーラムとかでIntel CPUの欠陥だとして話がくすぶってるって

  5. 名前:名無しの自作er 投稿日:2017/08/08(火) 23:04:54 ID:e1d2c4fb6 返信

    初期BIOSでメモコンぶっ壊した奴らへの救済っぽいな
    初期生産品だから今のと違うとは考えにくいし

  6. 名前:名無しの自作er 投稿日:2017/08/08(火) 23:06:37 ID:886d60f2c 返信

    「Zenすごい!初期ロットから8割強の歩留まり!!」
    って無邪気に喜んでたら検品がスカスカだっただけというオチだな。
    スリッパはちゃんとバリデート通ったヤツだけ乗せるんだろう。

  7. 名前:名無しの自作er 投稿日:2017/08/08(火) 23:09:13 ID:19458cc7e 返信

    ま、Windowsしか使ってないからどーでも

  8. 名前:名無しの自作er 投稿日:2017/08/08(火) 23:11:28 ID:d886644e0 返信

    AMDのニュースルームに記事ないけど信じていいの?
    Linuxなんて仮想マシン内でしか動かさないけど
    買ったの3月下旬だし少し気になる

    • 名前:名無しの自作er 投稿日:2017/08/08(火) 23:14:23 ID:e8f7b0eab 返信

      あー、多分ダメ石だな。

  9. 名前:名無しの自作er 投稿日:2017/08/08(火) 23:17:24 ID:56e4f22ca 返信

    AMDはコレでなくちゃなwwwwwwwwwwwwwwwww

  10. 名前:名無しの自作er 投稿日:2017/08/08(火) 23:19:01 ID:7f7f583e1 返信

    正常動作品と交換って無いの?

  11. 名前:名無しの自作er 投稿日:2017/08/08(火) 23:26:55 ID:f513e2ec4 返信

    Intelの石でも同じの出てたのはどうなったんや

    • 名前:名無しの自作er 投稿日:2017/08/08(火) 23:58:23 ID:0aa9e3c2c 返信

      それはそれ
      Ivyの隠れた不具合かもしれないしそもそもプログラム自体検証不足だしAMDもPhoronixも言及していない

      make -j16を現実的な時間動かすだけでRyzen環境でのみ特異に発生するので困る、というのがそもそもで
      AMDはそういう問題が存在することを認めて、問題発生してる人には交換対応しますよーっていう話ね

      • 名前:名無しの自作er 投稿日:2017/08/09(水) 00:04:00 ID:f076f2f29 返信

        それは分かっとるんだが、どうもこの件が喉に刺さった小骨みたいで気持ち悪いなあと思って
        結局あっちの方はなんで出たのか究明はされてないのな

  12. 名前:名無しのAMDer@Y市ASH区 投稿日:2017/08/08(火) 23:28:56 ID:47d67d13b 返信

    初期の同一ステップの同一ライン上で出来にムラがあったって事かねぇ。
    選別落ちにはならなかったけど使い方によっては結構ギリギリでしたみたいなの。

  13. 名前:名無しの自作er 投稿日:2017/08/08(火) 23:47:04 ID:8c75c2606 返信

    Ivy bridgeのi7で同じエラーが出てたのはなんだったんだろう
    あっちはあっちでまた別口で問題があるってことか?

  14. 名前:名無しの自作er 投稿日:2017/08/09(水) 02:51:53 ID:a56a130f6 返信

    そもそもコンパイルでSEGVが起きる事自体は昔からよくある話でPhoronixの管理者も言及してるがこれに限った話ではない

  15. 名前:名無しの自作er 投稿日:2017/08/09(水) 08:04:13 ID:995119c30 返信

    セグメンテーションエラーって事は、
    確保したメモリーを超えて読み書き→アクセス違反が発生→プロセス強制終了ってことだな。

  16. 名前:名無しの自作er 投稿日:2017/08/09(水) 08:57:26 ID:93e6cb43c 返信

    これがAMDerだ

  17. 名前:名無しの自作er 投稿日:2017/08/09(水) 09:25:16 ID:81e1b3ba2 返信

    案の定Windows使いのアホどもが大騒ぎしててワロタ

  18. 名前:名無しの自作er 投稿日:2017/08/09(水) 09:56:40 ID:2c6510f31 返信

    結局は原因不明で幕引きって事なのかな?
    再現性が低いとは言え、不安が払拭されず残念だ

  19. 名前:名無しの自作er 投稿日:2017/08/09(水) 11:25:41 ID:8afd2dfe8 返信

    この問題って結局は電源、マザー、メモリの相性問題な気がするんだが死角が消えたのは間違いない

  20. 名前:名無しの自作er 投稿日:2017/08/09(水) 11:28:48 ID:4477d4870 返信

    1600ワイは1~2年たった頃に交換してもらおかな
    今だとまだ安定側に振っただけで性能や消費電力は下がるとかありそう

  21. 名前:名無しの自作er 投稿日:2017/08/09(水) 11:49:19 ID:f264f81a2 返信

    Windowsで何も起こらなきゃどうでもいい

  22. 名前:名無しの自作er 投稿日:2017/08/09(水) 12:20:02 ID:11670e1e4 返信

    IntelCPUでも起きたりEPYCでは起きないって言ったりもうわけがわからんな
    Linuxでコンパイルしたとき限定とか微妙すぎる

    コンパイラ側に一切バグがないって保証もない
    どうやって解決するんだ

    • 名前:名無しの自作er 投稿日:2017/08/10(木) 06:47:18 ID:d5e7b4a82 返信

      まあ、IT業界でよくある話だな。

      古株の人ほど口うるさく、声がデカい、上から目線。
      自分のプログラムにミスは無いと激昂し、周りが苦労する。
      ミスが明らかになると今度は「仕様が悪い」「なんで教えなかった!」と大騒ぎ・・・

      GCC作った人もこんな感じだよ。誰も手が付けられない。解析できない。
      あんな古い複雑なプログラム、バグが無いわけが無い。

  23. 名前:名無しの自作er 投稿日:2017/08/09(水) 13:41:21 ID:6d69c79b6 返信

    ざっと techpowerup を読んだ感じだと、初期シリコンの品質にまつわる問題だとか
    Linux 上で高負荷のワークロード実行中に発生するかも知らんと
    今後は、開発時の Linux 上での QA を改善していくそうで
    問い合わせれば交換してくれるみたいよ
    Intel でコケるってのは gcc 自体がもう並列度を高めると原因不明で落ちるなんてのはよくある話なので別問題だろうね

    • 名前:名無しの自作er 投稿日:2017/08/09(水) 20:19:56 ID:a56a130f6 返信

      Phoronixの元の回答は初期シリコンの品質とか言われてはいない

  24. 名前:名無しの自作er 投稿日:2017/08/09(水) 21:15:41 ID:a71d1674b 返信

    SEGV問題・・・SEGV・・・SEG∀・・・SEGA・・・SEGA

    つまりそういうことか!

  25. 名前:名無しの自作er 投稿日:2017/08/09(水) 23:11:48 ID:02f7cc4eb 返信

    騒ぎ立てたい人達が知識無さ過ぎて静まり返ってる図