【エラッタ？】Ryzen SEGV検証Part.3【おま環？】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
!extend:on:vvvvv:1000:512
↑を2行冒頭に書いて下さい。(1行分は消えて表示されません)
次スレは>>960を目処に。重複防止の為、宣言してからスレ立てをお願いします。
前スレ：
【エラッタ】Ryzen SEGV問題 Part.2【AMD】
http://egg.2ch.net/test/read.cgi/jisaku/1498476311/
参考リンク：
gcc segmentation faults on Ryzen / Linux
https://community.amd.com/thread/215773
Ryzenにまつわる2つの問題 - 覚書
http://satoru-takeuchi.hatenablog.com/entry/2017/04/24/135914
日記 (2017 年 6 月下旬) - hdk のページ
http://www.e-hdk.com/diary/d201706c.html
GitHub - hayamdk/ryzen_segv_test: RYZEN SEGV test code
https://github.com/hayamdk/ryzen_segv_test
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured 例の日記更新されたけど珍しく苦戦してるね
>>26
Updated??September 29, 2011 SEGV自体は発生するもんだし
頻度がryzenはおかしくない？って話だわな >>26
それはコンパイルした結果のコードを実行した際にSEGVが出る原因を解説した記事であって
プログラムの書き方とかIntelコンパイラの仕様の話だと
前スレでも指摘されてるのに懲りないのな >>23
不良品という言い方をするならCoreiもXeon選別を通らなかった不良品なんだが >>31
サポートにubuntuが入ってるな
clangって書いてあるけども？ 4コアの不良品を2コアとして低級品に再利用してるのも不良品の有効活用なわけで
別にCPUに限った話じゃなく、建材だってA級品B級品あるわけで、抵抗やコンデンサ、コイルやFETもそうでしょ
んな当たり前のこと知らない人居るのかな >>31
これでryzen-testコンパイルして実行したらどうなんやろ >>27
今回の件は不具合の出やすい個体／出にくい個体があるみたいだから
これを選別してるんじゃないかと勘繰るのは仕方がない。
特定の回路でタイミング制約を間違って論理合成したか
メタステーブル対策をミスったんだろう。
まともに選別すると歩留まりが悪すぎたんで、ごく稀に誤動作する程度のものは
出荷することにしたんだと思う。 石の製造国2つあるけど関係ないんかな
誰も書いてないけど >>34
AMDのRyzenは8コアﾀﾞｲしかないんだろ。それの不良品やコア殺しを下位に回すって感じだからな
Intelの105xものは4コア、2コアﾀﾞｲがあるって聞いたことがあるが。
まぁ、安くてx8より個数が出るであろうRyzenの6・4コアを8コアﾀﾞｲの不良を期待して作るって
かなりの不良率期待になるからな。で、生産コストは上位の8コアと一緒 コンパイラ変えたらNGでなくなったけどどういった理由なんだろ >>43
そう
ちょっとやってみたらエラー出なくなった AMDのLinuxでコンパイルするときはGCCではなく、AMD提供のAOCCを使えってこどだな。
このClang/LLVMコンパイラはカーネルもビルドできるようにAMDが頑張ったんだろな GCCの中身が超スパゲティでデバッグできなかったので作ったってオチじゃ、、、 RYZEN用に最適化が完全にできてないだけ
最初からわかってる事
新しいアーキテクチャなんだからよくあること
交換騒いだやつは土下座 結局はエラッタじゃなくコンパイラーが腐ってただけか
そりゃ環境や状況揃えても再現出来ないわな >>48
プログラムがスパゲッティとかラーメン構造の橋とか美味しそうな名前で好き >>50
んなわけねーだろ
どんな腐ったプログラム実行しても、命令ポインタがずれて実行されるなんてことは起こらない アーキテクチャが変わって最適化が不十分でパフォーマンスが発揮されない、
とかの問題と、
そもそもプログラムが正常に動作しないってことの違いぐらいは区別付けてくれ
百歩譲って対応してない命令を実行したとかで動作しないことがあったとしても、
（実際にFXで対応していたいくつかの命令はZENで非対応になってる）
それと命令ポインタがずれることは全くレベルが違う問題 エラッタをソフト側で吸収してくれるコンパイラってことかもな
そもそもエラッタではなく仕様ですAMDのコンパイラ使ってくださいと言われたら終わりな話に まあ仮にそういうことだとしたら、
AMDがそれでいいと判断したならそれが全てだな Haswell向けのコード走らせたらフリーズするやつ思い出す >>44
何ループくらいOKでした？
パス代えるだけで行けますか？ twitter勢でAMDから替え玉来た人の見たけど
手元の1700とmicrocode一緒だ >>58
実行ファイルを新しい奴で上書き
20000回でNGなし 5/1付でAMDの対応は終わっていた訳だな
そりゃあフォーラムから追い出されたりAMDに塩対応されたりしても仕方無いわ 素人ながらに少し調べてみたんだが
AMDフォーラムではLow-Latence-Kernel（ASLRオフ）で60時間以上エラーなしということで
このカーネルがどう違うのかという所でubuntu studioのwikiより
・カーネルにCONFIG_PREEMPT_RTパッチを適用したリアルタイムカーネルを利用する
・カーネルの設定を変更しタイマー割り込みの頻度を増やす
・PAMの設定を変更し、アプリケーションのカーネル・スケジューラー内での処理の優先度を変更する
ここでタイマー割り込みの頻度を増やすという所をまず調べてみた
かなり古い記事なんだけどここを見ると
http://www.atmarkit.co.jp/flinux/rensai/watch2005/watch08a.html
カーネル2.6.13-rc1にて、タイマー割り込みの頻度「HZ」がデフォルト1000から250に変更されている
今現在のカーネルのデフォルト値がどうなのか分からないが取りあえず1000に戻してみるのもいいかもしれない
（ubuntu studioは1000）
＞割り込み頻度（つまりHZの値）を歴史的に見ると、
＞例えばi386アーキテクチャにおいては「100」というように、
＞アーキテクチャごとにそれぞれの値が設定されていました。
ともあるようにデフォルト値ではZenアーキにそぐわない値なのかもしれない
PAM設定というのがよくわからないのだけれども
処理の優先度を変更は具体的にどう変更したらいいのかはわからない
詳しい人補足・修正よろしく >>61
ありがと
>>60
例のkernel開発者様がretweetしてるよ >>67
自分のSEGV出る1700も同じだったよ
メモコンの出来にバラツキがあってメモリとの相性が悪いだけなのかも まとめるとこんな感じかな。
WinでもLinuxでも汎用カーネル使うと色々問題が起こるから
Zen用にチューンしたカーネルをWinでもLinuxでも使ってね(ASLRがOFFってセキュリティ的にどうなんだ感があるが)。
そして、汎用カーネルだと既存のソフトで問題が生じる場合があるから、その時は
Zen用のWin/Linuxコンパイラでコンパイルしたのを使ってねと言うことだろう。
と言ううことで、時期にMSがZen用Winカーネル、そして、AMDがWin用コンパイラ出すだろう。 WINDOWSに関してはRyzenが乗ってるマシンにアプデでパッチ当てれば済むだろうね >>65
250ってマジか
WindowsみたいなクソデブOSでも1000なのに >>69
まとめるまえに、カーネルがなんなのかを勉強したほうがいいよ。 >>71
大きけりゃいいってもんじゃないからな
リアルタイム用途、デスクトップ、サーバーでは最適な値は異なる
Windowsも単純に1msの割り込みということではなかったはずだが？
timeBeginPeriodの設定値とかによって変動するはず
そして、Linuxでは最近は一定の割り込み周期じゃないTicklessカーネルになってたような AMDがどうのではなく
検証コードをclangでビルドしても再現しないってだけじゃないのという気もする clangでもmakeでエラー出たって
amdの公式スレに書かれてたから
gccだけの問題ではないかもしれないし
別かもしれない AMDはもうとっくに原因解析してわかってるはず
なぜダンマリなのかはわからん
１．BIOSアップデートで対応可能、後日発表
２．BIOSで修正不可、コストがかかる全数リコールしなくてもいいように、
法務や弁護士等と対応策を打ち合わせてる
このどちらかとおもう
案外２．なのでは？ 一応補足
例の検証コードはCPUの内部状態がある特定の状態になったら異常が起きるのではという仮定のもと
最小限の特定の命令パターンを実行することでそれを再現しようとしているので
コンパイラが変わることで微妙に動作が変わり再現しなくなってもおかしくはない
よって、あるコンパイラでこの検証コードをビルドしてもNGが出ないからといって
検証コード以外でもそのコンパイラを使えば常にOK、という話ではない >>78
せめてAMD公式スレに社内で再現した再現しないよ程度のレスは欲しいですね
見落としかもしれませんが ポインタが不可解にズレること自体は事実なんだよね？
そこんとこはっきりしてほしい >>81
ttp://www.e-hdk.com/diary/d201706c.html#20-2 スレの範疇を超えてるので回答がないね
>>76
済まない何が知りたいのか良く解らないけど
見てると思われるubuntu studio wikipedia日本語の内容は古いので
PAM認証は忘れて英語版を見て欲しいってのと
公式スレでlowlatencykernelって言ってる人は
perf: interrupt took too longメッセージを
回避するにはコアのロックが問題っぽいので
方法としてコレを試したら安定したって所を
ゆっくり読んで欲しい
（内容が正しいとは言ってない）
なんとかtimerのdefault設定とか知りたいならできるだけ
新しいmenuconfigによるkernel設定などをググってみると
全貌が掴めるかも >>75
結論はそういうことだ
コンパイラ側の調整不足
AMDはRYZEN用にコンパイラ公開してるし答える必要も無いと判断してると思うぞ って書いてたらsegfault出てた
kernelソース一式をwd740 (raptor) に入れて-j16
internal compiler error: segmentation fault
1回/33回
■環境 要望あれば詳細も
1700@3.0GHz&Spire, AB350M Pro4
Corsair VenLPX M2Z 2666 8GBx2
960EVO (, WD740),ファンx2(open)
SST-ET550-B 1系統専有/接地無/50Hz
xubuntu 17.04 & apt upgrade済
tmpfs無し、涼し目の環境
■履歴
テストa) -j16で1/50 ill inst
テストb) -j1 *16 で1/64 segf
テストc) -j4 *1で0/10(遅過ぎで中断)
ここまで全て960evoのみ接続
テストd) evo+hdd -j16で1/33 segf
後はなんだっけ？ 次はclang/llvmで検証かな
ttps://community.amd.com/message/2806915#comment-2806915 >>83
ありがとう
OSだとかLinuxなんか特に分からないから
指摘されたところ調べてみるわ というかEPYCのレビュー色々見たけどSEGVのことスルーして絶賛ばかりだな
それもWindows上のベンチだけじゃなくSPECとか測ってるような連中が
サーバーで致命的とかいう話は何処にいったんだろう >>88
VisualStudio2015とか7zipとか古い結果と比較できるように2年以上前の使ってるんじゃないかな
全部取り直すなら最初からVS2017使えば良いわけで
SDKも15063使わないならスレッドの割り当てうまくいかなくて遅くなるかもね
まぁ2017は拡張機能とか対応してるのが2015より少ないから手動で環境変数設定したりちょっと面倒な点はあるけど
それが出来ないほどアホじゃないだろうし この騒動は次のステージに突入
交換要求したがB1送られる
石はテストで問題無い物が送られてるのは当然でB1には問題ないことが判明
交換品で問題出たらコンパイラ側の設定や最適化に問題
AMDはryzen用に謹製コンパイラ公開済み
satと取り巻きは早とちりの土下座レベル メモリ、マザーボードの初期不良同様3回目の修理に出して販売店や代理店に任せておけばいいものを
早とちりというよりはフリーランスになったから自分の宣伝をしたかったんだろう
6月24日に広報とか言ってるツイートがあるが、この言葉が本音を表しているとしか思えない 替えのCPU届いた人、交換後はエラー出てないようだ
エラッタじゃなくて不良品だったということなのかな 中身はRyzenPro同等品だったりして
企業向けな分選別厳しそうだからそれをクリアしたものなら出無さそう ryzen買ったらgccで動作確認するのが当たり前だよね
ってか？ OCしてOCCTやPrime95動かすのと似たようなもんでしょ 自分もb2待ちだけど、cygwin使う事前提なんだよね
cygwinのgccも大丈夫だろうか？＜b2 >>94
世の中には定格だから動いて当たり前と思っていてPrime95すら回さない馬鹿が居る
そういうやつは初期不良の切り分けも出来ない、さっさと初期不良交換してもらえば済む話なのにな
うちの1700もメモリOCしたりしてPrime95でエラー吐く設定ならNG出ることあるけど、
Prime95でエラー吐かない設定ならNG出ないし
RyzenはDDR4-3200 CL16でOCCT:CPU/Linpackが1時間通っても、
Prime95 FFTsize=384を回すと即エラー出たりするからね(CL緩めると出ない)
AVX頼みのIntel用の負荷テストプログラムじゃまともに負荷かからんのよ
Prime95みたいにカスタム設定あるやつはまだ何とかなるけどOCCTみたいな細かい設定が出来ないやつはRyzenだとエラー出にくいブロックサイズで延々回すだけだし
問題無いように見えてもopcache切ってキャッシュヒット率下げてメインメモリのアクセス頻度上げたらPrime95即落ちってのもあった 俺の1700はPrime95なら何時間でもパスするけど、
NGは即出るわ >>99
俺環ではPrime95 FFTsize=384ての試して問題ないけどNG出たよ
メモリHynixだけどね >>92
ソースどこ？
しかし石の交換だけで直ったのなら
なおさら石の不良ということにならないか？ おま環だからCPUに問題がないなんてことはないんだけど このスレの人たちですら実用上問題ないと言ってるからな、普通に使ってる人はSEGVの存在すら知らないだろう >>107
だったらCPUに問題があることを証明しろよ… 段々とsatと取り巻きのエラー検証に無理が来てるのが分かる
普通に考えて交換品で問題あるやつ送るわけないだろ
さっさと土下座しとけって 吉報かな？
gcc 7.1.1 (fedora26beta)
56scriptでkernel make -j16
1100回回してエラー0
環境は前回と同じ(hddは外した)
一周20秒ってなんか爆速なんだが
make cleanはしてるみたいだ
出来る人は追試頼みます 厳密にはmake対象のstable kernelが
.7から.8に変わってる(kernel.org側)
fedora側も同じ系統
後はカーネル屋さん達に任せよう なんか、linuxの環境変数が変な値を設定していて
それを忘れていて、実行してエラーとか、
そういう気配すら感じる
ハード的・ソフト的両面でおま環・・・・ fedora25/CentOS7では試してないので
比較したら面白いかも
でもなんでこんなに早くなったのか
全然わからん sat周辺は苦しい言い訳続いてるわ
交換品まで文句つける有り様 B2送られてくると思い込んでたら送られてきたのがB1だから目論見外れて日和ってんだろ 結局エラー出たのかよ
あとはB2でもエラーでるかどうかか そもそもSEGVを理由にすれば当りを引けるまで何度でもおかわり出来る時点で問題だな
そのうち交換品を代理店側でチェックしてからじゃないと発送しないとかになりそう どんな不具合があろうと、AMDが公式に記載するまではエラッタではない
エラッタってどういう意味の言葉だと思ってる？ 調べてきた
エラッタ 【 errata 】 エラータ
誤字、誤植、誤写などの意味を持つ英単語。
また、転じて、印刷物の誤字などの訂正表、正誤表という意味もある。
“errata” は複数形(「正誤表」の意味では単数形)で、単数形は “erratum”。
半導体の分野では、LSIチップの論理回路などに存在する
構造上の欠陥や設計ミスなどのことをエラッタということがある。
また、出荷後の製品に存在するそうした欠陥や本来の仕様との相違などを
まとめた文書のことをエラッタという場合もある。
ふんわりしててよくわからないや 本来は正誤表という意味
そこから派生して、「本来の仕様との相違などをまとめた文書」が半導体の文脈でいうエラッタ
つまり文章にまとめられるまではいくら状況証拠的に不具合があろうとそれはエラッタではない ■ このスレッドは過去ログ倉庫に格納されています
