AMD、RyzenのSEGV問題を認める 77
ストーリー by hylom
結局どれがセーフなのだろう 部門より
結局どれがセーフなのだろう 部門より
shesee曰く、
Linux上で、kernelやgccなど大きなソフトウェアを繰り返しMakeするとコンパイラがSegmentation Faultで失敗する問題についてAMDは問題の存在を認めたようです(techpowerup、HotHardware)。
AMDは問題がマザーボードやメモリではなくCPUの問題であること、Linuxで発生するもWindowsでは再現しないこと、初期のRyzenで発生するもEPYCやThreadripperでは発生しない事を報告しました。その上で、影響を受けるユーザーに対してはカスタマサポートで個別対応するようです。
また、どうやらWindowsユーザに対しては交換対応はしないようです。株価が上がったとはいえ、AMDにはリコールする財務的余裕はなさそうです。
B2ステップでアンコアの修正をするとの話が出てましたが、ThreadripperはB1ステップですので、製造上の問題なのでしょうか。市場にあるRyzenプロセッサーのどれが問題ないのか区別する方法が無いのもちょっと不誠実さを感じます。
一部ではBIOS更新で解消したとか (スコア:2)
マザーボードのファームウェア更新で解消したとか、メモリ設定を正しく読めていなかったことが原因とか、マザーボードの設定を
AMDのサポートの指示通りに変更すると、パフォーマンスが大幅に落ちるが解消するとかいう話が出てました。
動作保証できない条件で出荷していたのか、単に後から問題が見つかったのか。個人では速くてちゃんと動けばなんでもいいんですけどね。
Re:一部ではBIOS更新で解消したとか (スコア:4, すばらしい洞察)
> 個人では速くてちゃんと動けばなんでもいいんですけどね。
ちなみに法人でもそうです。
Re:一部ではBIOS更新で解消したとか (スコア:2, おもしろおかしい)
ネットイナゴとしては大いにけしからん、的な
Re:一部ではBIOS更新で解消したとか (スコア:1)
法人によっては、時間や権威による保証が要求されるんじゃないか?
Re: (スコア:0)
AMDのサポートの指示通りに変更しても解決しないという話も出てました
Re: (スコア:0)
出荷テストで遅延故障を落とせなかったのかもね。
それで追加のテストパタンで不良品をリジェクトしたと。
Re: (スコア:0)
運用でカバー
Re: (スコア:0)
個人的にはStepping B2のRyzen待ちですね。
その頃には値段もこなれてくるだろうし。
Re:一部ではBIOS更新で解消したとか (スコア:1)
日本の場合はASK次第です。
Re:一部ではBIOS更新で解消したとか (スコア:1)
日本AMDが代理店丸投げでIntelのように協力的では無いからね。仕方ないね。
# それでも今更Intelプラットフォームには移れない…
Re: (スコア:0)
再現試験だとメモリの設定を手動で緩めたら解消したという報告が多い(というかメモリ設定を緩めても再現した報告あるのかな?)ので
B1ステッピングのメモリ周りがシビアすぎる&初期のファームウェアがメモリチップの検出に失敗して結果としてメモリをOC設定してしまう
の合わせ技っぽい感じですね。
B2の改良もコアではなくメモコンって話ですし。
なので
メモリ設定を手動で緩めると直る→実はそれが自動検出されているべき本来の正しい設定なので直る
ファーム更新すると直る→メモリが本来の(遅い)設定になるので直る
B2で直る→メモコンの改善で多少無理が利くようになった
ということかと。
Re:一部ではBIOS更新で解消したとか (スコア:2, 興味深い)
> (というかメモリ設定を緩めても再現した報告あるのかな?)
緩めても再現してますね。
https://twitter.com/ruby_U/status/885465722612142080 [twitter.com]
> #Ryzen_SEGV_Battle メモリタイミングを https://gist.github.com/rubyu/d45082932da1e7b7a0de6bf9e4c159df [github.com] … に固定してbtfs-progsを48時間で20977回コンパイルしてエラーなし。以前はどうしても数回エラーが出てた。参考: http://egg.2ch.net/test/read.cgi/ [2ch.net]
と、メモリ設定緩めると直ったかと思いきや...
https://twitter.com/ruby_U/status/885589846726660096 [twitter.com]
> 25000時点で1個エラーが…。ダメかー
https://twitter.com/ruby_U/status/886018801673715712 [twitter.com]
> さらにメモリ設定を緩めてテスト。18-18-18-39。Advanced->DRAM Timing...から設定。参考 https://egg.2ch.net/test/read.cgi/jisaku/1495164659/564 [2ch.net]
https://twitter.com/ruby_U/status/886907612620509185 [twitter.com]
> 実はこの後エラーが出ました(約4万回で1エラー)。どうしようもないなーと思いRMA手続き中です。最初からRMAの話をしたせいか、AMDから回避策の話はなかったので私見ですが、メモリタイミングより電圧盛りのほうが効果はありそうな気がしてます。AMDに指示を仰いでみてはどうでしょうか
というわけで、メモリ設定を緩めると頻度が下がるものの、解決するわけではないということでした。
twitterで情報交換してた人達の間では、この 7月13日から17日くらいに、この話は知れ渡ってましたね。
twitter以外で情報集めてた人は、こういう話を知らなかったんでしょうか...
Re:一部ではBIOS更新で解消したとか (スコア:2)
要は性能を落としたら安定しましたという風にも言えることですよね。
μOPキャッシュの無効化ってさらっと書きますよねえ。元ACさんは不誠実と言わざるを得ない。
Re:一部ではBIOS更新で解消したとか (スコア:2)
元コメントからそれが読み取れると仰る?
新しめのロットでは直ってるっぽい? (スコア:1)
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 で発生しないというのは、最近の生産品だからなんでしょうか。
Re:新しめのロットでは直ってるっぽい? (スコア:1)
マスクは変えないけど、準ハードコード的なパラメタが変更されると治る、とかかなあ?
# 昔のCPUみたく安定化のためのチップコンデンサが増えてたりして
M-FalconSky (暑いか寒い)
Re:新しめのロットでは直ってるっぽい? (スコア:1)
Threadripperはコア数が最低12個
カーネルのコンパイルはコアを全部使う(よね?)
だから各コアはMAXまでクロックが上がらないから、問題が顕在化しないとか?
Re:新しめのロットでは直ってるっぽい? (スコア:1)
メニーコアだと必ずしもそうとも限らないんだな、これが。
72コアのXeon Phiでちょっとおおきめのソフトをいくつかコンパイルする必要があったんだが、並列コンパイルNGなのが2個、並列コンパイルOKなのが2個あったので、4個X端末を開いて、
term1 : make -j 32 all
term2 : make -j 32 all
term3 : make all
term4 : make all
みたいな感じで66コア使ってコンパイルしたぞ。あとの6コアはOSで好きに使え、ってことで。
Re: (スコア:0)
うちはAMDじゃないけど、Haswell買ったときに高負荷時にキャッシュメモリのエラーが出て交換してもらったことがあります。
最近のCPUはチップ毎にコア電圧が異なったりするので、微妙な動作するものも発生しやすくなってるのかも。
購入する前に (スコア:1)
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 ヶ月近く放置していたのですから、そう言われても、致し方ないでしょう。
繰り返し (スコア:0)
makeを繰り返さなければ問題ないのか?
Re: (スコア:0)
SEGVなんかにmakeないで!という
勝てばいいんだろ? (スコア:0)
# ln -s make /usr/bin/kachi
これで勝ったな。
Re: (スコア:0)
makeするやつらは負け組って事だな
Re: (スコア:0)
makeしたと思うまで ryzenはmakeしない
i5で妥協した俺
Re: (スコア:0)
makeは単に複雑で負荷が高いから、それで気付いた、ってだけのようですよ。
現象から見ると、どんなプログラムでいつ起きてもおかしくない、エラーで落ちる以外にもデータの破壊等が起きてるかもしれない(気付いてないだけ)、という可能性も否定できない、というか十分ありそうとのこと。
Windowsで発生しない理由は不明ですけどね…。
Re:繰り返し (スコア:2, 参考になる)
makeというかgccによるコンパイルですね。
今回に限らず、gccだけで症状が出るハードウェアの個別不良ってよくあって、以下のようにFAQ にまでなってます。
https://linuxjf.osdn.jp/JFdocs/GCC-SIG11-FAQ/sig11faq.html [linuxjf.osdn.jp]
一番よくあるのがメモリ不良で、今回もみんな最初はそちらを疑ってたんですが、色々調べているうちにどうやらメモリじゃないっぽいなということに。
ハードウェア不良なわけで他の処理で症状が出ても不思議はないんですが、他では症状がでなくてgccだけで出るせいでgccの方のバグだと疑われることも多く、FAQにまでなってるのはその辺の事情もあります。
Re:繰り返し (スコア:1)
6月頭のPhoronixの記事に対するコメントで、 [phoronix.com]
「ハイパースレッディングを有効化していて、二つある内の一つのスレッドが(CPUコアをまたがずに収まる?)ループにある時に、もう片方のスレッドに割り込みがかかると、割り込み処理が終わった時のIRETQで復帰するタイミングでCPUが不安定化する」みたいなことを書いて、調査データをAMDに送付した。と言う人がいましたから、そこら辺の状況確認がやっと出来たんじゃないですかね。
で、Linuxのスケジューラがどういうコア割付してるかはともかく、gccみたいにシングルスレッドをガンガン廻していくソフトだと、割り込み時処理のスレッドと、処理のスレッドが同じコアで共存しやすいとかそういう話なんでしょうかね。
Re: (スコア:0)
> kernelやgccなど大きなソフトウェアを繰り返し
ですからね。直接的なmakeの話ではなくて大事なのはこっちでしょう。
要するにメモリを買ったらMEMTEST86耐久やるのと同じように (スコア:0)
CPUを買ったらmake耐久テストをしてから使えばいいんですね。
Re: (スコア:0)
make
make
make
…あれ、2回目以降あまり負荷がかかってない!
Re: (スコア:0)
make for me
make for you
make for god
他人に負担をかけない自己犠牲の鏡
Re:要するにメモリを買ったらMEMTEST86耐久やるのと同じように (スコア:5, おもしろおかしい)
orz
Re: (スコア:0)
「じじいのmakeの方がまだ気合いが入ってる!」
Re: (スコア:0)
負け
懲りないAMD (スコア:0, フレームのもと)
その昔PhenomのTLBエラッタ食らったので、こちらはそれに懲りて、それ以降AMD製CPU買ってない。
やっぱ買わなくて正解だったんだと改めて確認できたわ。
Re: (スコア:0)
エラッタならintelにもあるんですけどね
Re: (スコア:0)
早くAMDが滅んでIntelの独占になるといいですね!
Re: (スコア:0)
Intelのエラッタは良いエラッタ
Haswellで実はトランザクションメモリが使用できなくても良いエラッタ
Re: (スコア:0)
データ破壊・システム停止の可能性がないんだから良いエラッタでしょ
そこはSkylake/Kaby LakeのHTT挙げなきゃ
Re: (スコア:0)
いやHaswellのはデータ破壊の可能性あったんじゃないかな。
Transactional memory 機能の不具合なんだから、トランザクションの整合性が失われるような問題だった筈。
Haswell でラッキーだったのは、新命令の不具合なのでその命令をなかったことにするだけで済み、ハードウェア交換までする必要はなかった点だね。
ごくごく少数、Transactional memory 命令を試してみたくて発売から発覚までの2ヶ月の間にHaswellを買った人がいて、そういう人はちょっと可哀想だったなあ。
Linuxで発生するもWindowsでは再現しないこと (スコア:0)
それ、Linuxのバグじゃないの?
Re:Linuxで発生するもWindowsでは再現しないこと (スコア:2, 興味深い)
Linuxカーネルで特異な部分が原因というと、jump label (*) などの自己書き換えコードが怪しいような?
cross-modifying codeでSEGVが起きる [github.com]との情報もあるし、誰かjump label切ったカーネルを試してほしい
* 自己書き換えでnop命令とjmp命令を切り替えることにより、分岐の効率化を行う機能
Re: (スコア:0)
WSLでも再現するって言ってなかったっけ?
Re: (スコア:0)
新しいCPUのレジスタをフルサイズ全部使っているよ、ということなのかな
Re: (スコア:0)
FreeBSDでは発生するらしい。
Linux subsystem for windowsで発生するという報告もある。
発生する条件はかなりシビアらしくて誰の言ってることが正しいのかもはっきり言ってよく分からない。
Re:Linuxで発生するもWindowsでは再現しないこと (スコア:2, 参考になる)
Linuxだけではなく、少なくともDragonflyBSD、NetBSD、FreeBSDで症状が報告されてます。
さらに、AMDが公式にCPUの問題だったと認めている上、AMDから送られてきたCPUに交換するだけで直った報告もありますから、もはやLinuxやgcc側の問題であるという可能性は残っていません。
発生する条件は確かにシビアなんですが、今は数時間程度で症状を再現できるテストプログラムが公開されていますから、問題のあるチップか否かの判別は確実にできます。
Re: (スコア:0)
でもほんの数日前までそのテストプログラムも怪しかったわけでしょ
http://www.phoronix.com/scan.php?page=article&item=ryzen-segv-cont... [phoronix.com]
Re:Linuxで発生するもWindowsでは再現しないこと (スコア:1)
> でもほんの数日前までそのテストプログラムも怪しかったわけでしょ
おいおい、ちゃんと記事読もうよ。
phoronixの人がずっと Ryzen を常用してて、ベンチマークの負荷とかもかけてたりしたのに
全く問題なかった。でもその同じハードウェアで、1ヶ月くらい前から公開されていた
https://github.com/suaefar/ryzen-test/commits/master [github.com]
を実行してみたら、たったの88秒でくだんの問題が再現したって記事だよ。
つまりテストプログラムは1ヶ月くらい前にはもうあったわけ。
数日前までわかってなかったのは phoronixの人だけ。
前から AMD に相談していた人は、このプログラムのことは既にみんな知ってたんだよ。
Re: (スコア:0)
仮に「8TB-128TBの仮想メモリアドレスにアクセスすると問題が起きるCPU」があったとして原因が分かってない段階で「Windows 10で問題が起きてWindows 7で起こらないんだからWindows 10のバグ」って言ってるようなもの