【エラッタ？】Ryzen SEGV検証Part.3【おま環？】 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
!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 intel(Broadwell-E)検証報告
100回やって0/100
キリがいいから一旦検証は休止しようかと
●環境
【CPU】i7 6850K@4.2Ghz(Cache 3.3Ghz)
【M/B】X99 Taichi
【BIOS】1.40(現状最新)
【MEM】CFD Micron Q4U2400CM-8G(8GB×4)@2400 15-15-15-35-1T
【HDD】発掘したSeagate 500GB
【VGA】R9 290
【PSU】銀石 SST-ST85F-G-E
【OS】Ubuntu 16.04
【冷却】水冷(EKのCPU/VGAブロック)+マザボVRMにファンで風当て
●流れ
2回目までは手動
3〜86回目は前スレ>>56のスクリプトを-j12で実行
87〜100回目は前スレ>>875にコア数+1という数字を見たものの負荷にならないのでスレッド数+1にして-j13で実行
●未検証
・ストレージをSSDにするとハングアップエラー発生率が上がる？(前スレ>>836)
※手持ちに余りのSSDがないため検証できず
・電源の極性入れ替え
※そもそもエラーが出ないので入れ替える意味がなさそう
●結論
うちの環境だと100回程度ではエラーが出ない(または起こりにくい)
試行回数がまだ少ないもののRyzenユーザーは100回以内に発生してる傾向にあるのでこちらの環境では発生率が低いと結論づけて良さそう
元々メモリの相性が厳しくない&4枚刺しなので相性問題が起こりにくいことが原因？
8枚刺しにすればまた変わりそうな予感もするがメモリが値上がりすぎてて買う気にならず ペンギン村は早くても3年落ち、5年落ち10年落ちのメーカー製の「おさがり」が普通なぬであまり話題になりにくいのね
検証されるみなさん" ﾟ☆,｡･:*:･ﾟ★o(´▽｀*)/♪Thanks♪＼(*´▽｀)oﾟ★,｡･:*:･☆ﾟ"
,．-―― 、
／ ,．- ┴- 、
/.| ／:´ : : : : : : : :ヽ
. / :! i{: : : :/＼;/ V }: :ゝ
〈._＿Ｖ l:l:V-‐ ´ ‐ ,'l:/ >>1乙でゲソ！！
. ヽ|: l: l､ ヮ_.ノ:l
. ＿/:/｀,}:｀ｽ/￣￣￣￣/
／: : :(__::::つ/ くコ:彡 / ｶﾀｶﾀ
..￣￣￣￣￣＼/＿＿＿＿/￣￣
Ryzen_SEGV_Battle
https://twitter.com/hashtag/Ryzen_SEGV_Battle?src=hash
https://twitter.com/hashtag/Ryzen_SEGV_Battle?f=tweets&;vertical=default
https://search.yahoo.co.jp/realtime/search/Ryzen_SEGV_Battle/
https://search.yahoo.com/search?p=%22Ryzen_SEGV_Battle%22
https://www.google.com/search?num=100&;safe=off&newwindow=1&complete=0&filter=0&q=%22Ryzen_SEGV_Battle%22
https://www.google.com/search?num=100&;safe=off&filter=0&newwindow=1&complete=0&tbs=qdr:y100,sbd:1&q=%22Ryzen_SEGV_Battle%22
Ryzen segfault
https://twitter.com/search?q=Ryzen%20segfault&;src=typd
https://twitter.com/search?f=tweets&;vertical=default&q=Ryzen%20segfault&src=typd
https://search.yahoo.co.jp/realtime/search/Ryzen%20segfault/
https://search.yahoo.com/search?p=Ryzen+segfault
https://www.google.com/search?num=100&;safe=off&newwindow=1&complete=0&filter=0&q=Ryzen+segfault
https://www.google.com/search?num=100&;safe=off&filter=0&newwindow=1&complete=0&tbs=qdr:y100,sbd:1&q=Ryzen+segfault >>3
乙
＞●未検証
＞・ストレージをSSDにするとハングアップエラー発生率が上がる？(前スレ>>836)
＞※手持ちに余りのSSDがないため検証できず
これはハングアップエラー発生率ではなくSEGV発生率 AMD信者がCPUのバグを勝手におま環認定したりIntelモーとか
必死過ぎてわらう サーバ機の場合、100万回並列コンパイルして1回でもハードウェアが原因のエラーが出れば、ハードの欠陥だからね
デスクトップ用とは求められる信頼性の桁が違う
デスクトップ用ならどこまで許されるのかはわからんが、
多い人は10回に1回とか100回に1回とか出てるので、これはあきらかにハードが悪いといえる じゃあこんな所にいなくてもいいんじゃないですかね
煽ってるの？ いままでの重大バグの対応
○Pentium FDIVバグ
石交換
○Pentium F00Fバグ
OSで対策することで対処可能
○Phenom TLBバグ
BIOSアップデートでTLBキャッシュ無効化で修正、ただしパフォーマンス低下
○Sandy intel 6チップセット SATAバグ
マザーボード交換
○Haswell TSXバグ
修正不可能、BIOSアップデートでTSXまるごと無効化される
○Atom C2000シリーズ
どんどん壊れる重大バグ発覚、ただし一般ユーザー向けに直接販売はしてないために対応は不明
○Skylakeフリーズ
BIOSアップデートで修正
○Skylake/KabyLake HTバグ
BIOSアップデートで修正
○Ryzen SEGV
いまのところAMDからアナウンスなし
AMDに連絡すれば個別対応(石交換)してもらえるらしい キャッシュ階層エラーとかAGESA1004a以降のBIOSでは見たこと無いけど、
うちの1700でもAGESA1004a以前はテスト用EXEで一発ブラックアウトだったけど今は問題無いな。
AGESA1006でも未だに発生してるなら初期不良で交換してもらった方が良いよ
OCとか、BIOS更新してないとかは問題外。
そういや、電源のコイルが容量抜けしてコンデンサ鳴きしてるやつだと何やっても安定しなかったな、今は交換したけど。
※電源分解して耳にシリコンチューブ当てて聴診器変わりにして鳴いてる部品を特定
http://i.imgur.com/KuthSwm.png
>>10
まずECCメモリじゃない時点でお察し
相性きついのもXMPで動かないから手動でサブタイミング設定しないといけないのもRyzenメモリスレ見れば分かるわけだし
特にHynixモジュールは定格でBIOS起動すらしないからタイミング緩めるもクソも無いとか酷い相性出る場合があるわけで
価格COM辺り見てくれば何件もあるからね、Intel環境では動くのにってパターン
Hynix DDR4-3200は未だに8割方まともに動かなくて海外フォーラムでも2933止まりとか3066止まりとかやってるのが現状
SkylakeでもあったけどB0ガーバー基板だとIntel環境でも相性出るぐらいだから
8コアで入れ食い状態になるRyzen環境だとかなり厳しい
＞同じ「DDR4」で何が違う? - センチュリーマイクロのDDR4 DIMMで検証する「B1ガーバー」の効果
http://news.mynavi.jp/articles/2015/09/29/ddr4/001.html
http://news.mynavi.jp/articles/2015/09/29/ddr4/002.html Atom C2000バグは新ステッピングにて修正済み、順次新ステッピング提供へ
だけどブラジルのメーカーとかに訴えられてるぐらいには酷い対応 >>13
intel系バグ 温度スパイク問題(いきなり温度が上昇して元に戻る→ファンが高速回転しては元に戻る）
intel「そんな問題は発生しません」で解決
http://ascii.jp/elem/000/001/504/1504060/img.html
↑
あれ？アイドル時凄い温度上下してるけど、、 温度スパイクに対する正式回答
Hello Everyone,
We appreciate the feedback you have provided, and your patience as we investigated this behavior.
The reported behavior of the 7th Generation Intel® Core™ i7-7700K Processor,
showing momentary temperature changes from the idle temperature,
is normal while completing a task (like opening a browser or an application or a program).
In our internal investigation, we did not observe temperature variation outside of the expected behavior and recommended specifications.
For processor specifications, please refer to the Intel® Core™ i7-7700K Processor Product Specifications.
Most motherboard manufacturers offer customizable fan speed control settings that may allow for smoother transition of fan revolutions per minute (rpm).
Please consult your motherboard manufacturer’s manual or website for instructions on how to change default fan speed control settings.
We do not recommend running outside the processor specifications, such as by exceeding processor frequency or voltage specifications, or removing of the integrated heat spreader (sometimes called “de-lidding”).
These actions will void the processor warranty.
Kindest Regards,
Ronald M.
流石インテル 要約すると
Intel「そんな問題は無い。OCは保証外の行為で推奨しないからよろしく」 アイドル時に30℃幅で温度が乱降下するとかIntelCPUなら珍しくも何とも無い
BIOSで時間平均出してファンコントロールするから何も問題無いし演算エラーでも無いのに不具合と認めるわけないでしょ
ファンコン制御がダメならファン回転数まで乱降下するかもしれないけど
そんな糞BIOS出すところはまず無いわけで 明日はryzen+hddで再現テストやろかな
-j16と-j1*16は爆速で盛り上がったけど
-j4を一発はやってて正直タルいし
１回１時間で最低50回は回したいから週末潰れそう >>19
どこまで誤魔化しきれるかの問題だな
使えば使うほど悪化して行くらしいんで
マザーとCPUの寿命がどこまで持つのか
そもそもそんな状態で使用して
正常と言える状態を維持しているのかどうか >>3
遅ればせながら乙です。
-j13がエラーなく通ったという事実は重要ですね。 http://pc.watch.impress.co.jp/docs/news/1068131.html
米AMDは29日(現地時間)、ビジネス向けのハイエンドデスクトップCPU「Ryzen PRO」シリーズを発表した。
https://www.amd.com/en/ryzen-pro
--- Commercial Grade Quality ---
Processors selected from wafers to ensure commercial grade quality.
Processor specifications are set to meet long term reliability.
選別品ってことか。
逆に一般向けには選別に通らない不良品をまわしてるってことかもな。 >>19
しかも7740Xになって現象が悪化してるように見える
任意の1個でこのレベル
やはり限界を超えている >>23
この場合電圧とか発熱とかハズレ値を引きにくい対象を選別しているのであって機能不全品をより分けているわけじゃない 例の日記更新されたけど珍しく苦戦してるね
>>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チップの論理回路などに存在する
構造上の欠陥や設計ミスなどのことをエラッタということがある。
また、出荷後の製品に存在するそうした欠陥や本来の仕様との相違などを
まとめた文書のことをエラッタという場合もある。
ふんわりしててよくわからないや 本来は正誤表という意味
そこから派生して、「本来の仕様との相違などをまとめた文書」が半導体の文脈でいうエラッタ
つまり文章にまとめられるまではいくら状況証拠的に不具合があろうとそれはエラッタではない とはいえ、ソーシャルゲームなどの「課金」の誤用と同じで、
単なる不具合のことをエラッタと称する流れはもはや止めようがなくて、
新しい言葉の使い方として受け入れなければいけない時は近いなぁと諦めかけてはいる >>128
違う呼び方を広まらせればええんやで
適正な単語がないからそう呼ばざるを得ないからであって、それを与えれば当然呼び分けると思うよ >>129
いやそれなら不具合とか誤動作とかいくらでも既存の用語で言いようはあるでしょ Fedora25 ｲﾝｽｺ & dnf up 終了
25の4.8.6だとまだzen未対応かな?
gcc 6.3.1
10回20回だとエラー出ないのが普通なので
最低50出来れば100回は必要だけど
今回は１回あたり1分30秒位な模様
念のため一番最初にmake cleanした
結果は明日 >>126
そういう屁理屈は別にいいんよ
バグでもエラーでも不具合でも不良でも言葉や意味の差に興味はない
結局何が悪かったのかだろう >>136
＞結局何が悪かったのかだろう
んなことはAMDしかわからんのじゃボケ AMDから出てる資料で手に入らないものが多いから何とも
BKDG欲しい >>138
ttps://support.amd.com/en-us/search/tech-docs#k=bkdg
ここにないのかね？ >>139
残念ながら最新のものでもFam15h-60h-6FhだからK15.3、つまりExcavator迄だな
一応今調べてみたらAPMが軒並み更新されてた
#24593とか キャッシュ管理をAIなんかに
やらせてるから挙動が予測しずらいじゃないか？ うーん500回以上回してるけど出ない
f25自体はkernel 4.8台なんだが
fedora25/26bのkernel configが良いのか
make対象のkernel 4.11.8が良いのか
手元の自作機が素晴らしいのか判らないが
少なくとも自分の環境ではfedoraなら
gcc 7.1.1/6.3.1でもエラーは出なかったということは言えそう
UEFI(BIOS)は2.50で多分最新
但しfedora26bでのmake時間だけ異様に速かったので
なにか失敗してた可能性もある
56のスクリプトは信じてるんだが...
後はarch系の最新環境でやってみよか
事前情報ではfedora26bにかなり近い
versionみたいなんで万次郎とか >>146
構成は>>85に書いた通りで
マザーのUEFIは最初から2.50に本能的に上げてある
メモリ補足するとcorsairのryzen対応メモリ
2666 x 2枚組でdual channel
たったいま800回OK到達した
NG出てない
xubuntu17.04だと50回以内に出たんで
ハードが原因なの？って気はする
memtestしてないとか初期BIOSのままとかの人は別として >>149
boostの話だったら無効にはしてない
クロックの話ならocもdcもしてない
メモリもね そもそもboost切る項目ってあったかな
今見れないし manjaro kernel 4.11.7-1(guiで上げた)
gcc 7.1.1で4.11.8一周1:46秒と速い
これで明日まで回してみる manjaro make 300回ノーエラーで回った
NG出そうな気もしないので止めようか迷ってる
構成で書き忘れてたけどradeon r5 230 1GB で manjaroはnon-free driver
他OSでは指定無し
もう一回xubuntu17.04やり直しするか
または他の道(bsd)に行くかお悩み中
AOCCでkernel makeは多分やらない(ムズそう) まとめ
xubuntu17.04で4.11.7は50回行かないでill inst(-j16)またはsegfault(-j1*16)
fedora26bで4.11.8は1000やってエラーなし
fedora25で4.11.8は850やってもエラーなし
manjaro xfce(arch系)4.11.7-1 gcc7.1.1で4.11.8を300やってエラーなし
多分だけど
(最初ここで言われてた)gccの-j16は問題なし
過負荷による問題でもない
NVMでもHDDでも起きているから速度は関係無い
ryzen対応前のkernel(f25)でもエラー起きてないから関係無い
全てSMT, μop cache有効なので関係無い
あとは
distro間のmenuconfigの違いの可能性
(例えばFedoraとubuntu17.04)
binutilその他ライブラリの違い
make対象kernelソースの違い(可能性低い)
テスト中にM/B設定が何か変わった可能性(低い)
を消していかないといけないが全部は無理っす
長文ｽﾏｿ コピペ
スケジューラー怪しいぞ
関係あるのか知らないがなんか来てる
Scheduler Improvements Set For Linux 4.13
http://www.phoronix.com/scan.php?page=news_item&;px=Linux-4.13-Scheduler-Work
scheduler changes for v4.13
http://lkml.iu.edu/hypermail/linux/kernel/1707.0/00517.html >>158
Androidから書き込んどいて何言ってんだ 前スレでキャッシュ階層エラーを書いたものだが
CPU交換したら治った >>156>>157
ありがとう
中間報告
debian 9.0.0 (4.9.0-3) gcc6.3.0 で4.11.8
130回エラーなしで進行中 一周1:40
UEFI 2.50(AGESA1.0.6)
※謎解きを揶揄する意図はありません
終わったら念のため4.11.7もやってみよ debian問題なさそうなのか
debianベースにしたubuntuとは何なのか 検証人が増えることを願って
56スクリプト転載
#!/bin/sh
COUNT=0
while :
do
COUNT=$(( COUNT + 1 ))
make -j 16 2>>/root/log.txt
if [ "$?" -eq 0 ]
then
echo "${COUNT}: $(date): OK" >>/root/log.txt
else
echo "${COUNT}: $(date): NG" >>/root/log.txt
fi
make clean
done
※ユーザー権限の場合は/root/を../とかに変更 debian9.0で209回目に4.11.8のmakeでsegfault出現した
これで4.11.7と8の違いの線は消えたと
あと最低回数が210回になる
確率の問題だけど
次はubuntu 16.04.02で追試かな
範囲が段々狭まってきた Linuxの問題じゃないCPUの問題なんだああああああああああああ
って主張してた自称ソフト屋さん息してるの？ >>170
スクリプトで回してるのでその場で止めてないし
gdbもよく知らないからスルー
そういうのは得意な人に任せます
こっちは環境による発生頻度の違いを見てる
ただの自作erに出来るのはその程度
一応nativeに拘って仮想は使ってない
本音は8コア16スレッド+NVMのスピードで
ﾋｬｯﾊｰしたいだけwww
htopが真っ赤っかだぜー >>54
それ、既存バイナリの動作を保証しないと言ってるに等しいけどそういうことなの？ CPUのエラッタを回避する特殊なコンパイラが提供されたら、
既存の普通のコンパイラをバグ扱いする頭の弱い人がいるからね >>174
特殊でもなんでもなく、普通に回避してると思うけど。
エラッタは公表された時点で、ほぼ仕様と化すからねぇ。 >>174
状況がよくわかってないことがよくわかるw OSならともかく、普通のアプリが特定のCPUのエラッタ回避なんてしないよ >>177
コンパイラのはくコードのこといってんじゃないの？
てか、アップデートで回避するとおもうよ、まともな会社のアプリなら X370carbonの人、BIOSベータ3来た
今回は来るの早かった
但し手持ちのMateではベータ3にしても改善しなかった
AGESAがバージョンアップしないと変化は期待できない可能性があるのでそのつもりでどうぞ X370carbonは正式版1.7も出てた
試すならこっちの方がいいかも 完全におま環だけどFedora25にしたらむしろセグメンテーション違反が増えた
ubuntu16.04だと100回に1,2回程度だったけど、現在は10回に4回は発生してる Fedora25でビルドしてたのが4.12だったわｗ
4.11.8にしたら即NG出てたのがなくなったのでとりあえず流し続けてみる >>174
普通逆なんだよ
こんなんだからsat周辺はゴミ扱いされてんの >>185
Kernel4.12のビルドでSEGV？出るのはRyzen関係ないのかね？
Intel環境で4.12のビルド試せば分かる話だが >>169 自分にアンカーしとく
ubuntu16.04.02 kernel 4.8.0-58 generic
gcc 5.4.0-6 要はｲﾝｽｺ&apt update済
make -j16 で 4.11.8 一周約1:20
300回ノーエラー
ちょっと期待と違った
打ち切ってubuntu 17.04で締める
(xubuntuではない) >>181
なんのことを指して回避といっているのかわからんけども、
インテルもしくはAMDの公表したエラッタには普通、ワークアラウンドが用意されている。
それに従って改変したものは、当然ｘ８６バイナリであるから、
エラッタのあるCPUで正常に動かなかったものが、単にすべてのx86CPUで動くようになるだけだよ。
そして、アセンブラで書いてない限りは、更新されたコンパイラでリビルドするだけさね。 大量に存在するx86コードを全てリビルド？
ないない >>189
え？
一周80sで終わるってこと？
いくらなんでも早すぎ Skylakeには膨大なx86資産（16bitバイナリ）の正常な動作を保証できないという重大かつ致命的な欠陥があるよね >>191
なんのことを言ってるのかわからないんですけど。 4.11.8で30回中2回発生で目に見えて発生回数減ったので
再度カーネル4.12で回してみたら序盤10回で5割NGのあとは30回連続でビルド成功が続いてるｗ
なんだこれｗ
>>183
1800X, asrock AB350 gamingK4 biosは最新&デフォルト設定, メモリは忘れたｗ
Fedora25(workstation)はdnf updateとnvidiaのドライバ導入済 >>197
なんかもうどのバージョンが良いとか悪いとかではなくて
たまたまメモリとかキャッシュとかのハードウェア的な状態がどうなってるかで変わってるような印象を受けるな
うちの環境はどうやらメモリ電圧に強く影響を受けてる感じなのが分かってきたので
安定する設定がないか模索中
まとまったらここでも報告するつもり >>194
早すぎです？でもずっとその間隔ですね
NVMeの威力かと思ってるけど16GBあるので
相当DDR4にcacheしてるのかもしれない
(確かにそれが化けたらアウトだ)
56scriptにはmake clean入ってるし
最初にmake clean make defconfigしてるし
なんか間違ってたら教えて
>>197
結構構成似てますが違いはnvidia位ですね
AMDにNVIDIA挿すのはﾔﾒﾀﾏｴってどっかで見たんで
洒落で今回はradeon R5にしてます
メモリは最初memtestかけまくりでした
いま25回全部OKなので明日まで放置
今回終わったらケースに入れる >>196
おれはお前が何をいってるのかわからん
エラッタがOSやBIOSで回避するならするだろう
そうじゃなくて、現存する多くのアプリのバイナリを直さなきゃならないなら世の中にあるほとんどのx86コードは対応しない
あり得ない仮定だが、もしも例のコンパイラだけで問題が発生する非常に特殊なエラッタであれば、当然修正する可能性はある >>200
あのね、今後、もしくは今でもメンテナンスされているアプリのことを言ってる。
そしてその対応のために、インテルもAMDも資料を提供してるよ。
ttps://www3.intel.com/content/dam/www/public/us/en/documents/specification-updates/desktop-6th-gen-core-family-spec-update.pdf
ttp://support.amd.com/TechDocs/51810_16h_00h-0Fh_Rev_Guide.pdf
この手の資料は、別に伊達や酔狂で用意されたものではない。 >>201
普通のアプリ開発でそんなもんを見て作ってると思ってるのか？
お目出度い奴だな >>195
64ビットOSではもともと動かないしWindows Serverも2008以降32ビット版の提供自体やめてるけど何か問題でも？ >>202
なにを思ってるって？？（笑
てか、資料も見ずに組むいい加減なやつが多いから、トラブルが減らない現実（笑
コンパイラ作ってるとこは、間違いなく見てるよ。 つまりコンパイラは普通のアプリ
普通のアプリでセグテンテーション違反がランダムで起こるRyzenは糞
おしまい >>205
もうちょっと世の中を知った方が良いぞ
ちょっと痛すぎる DOSの資産なんてMicrosoftすらとっくに互換保証断ち切ってるがFreeDOSなどで運用するにしてもVortex86とかQuarkあたりのシングルコアで十分だ
どのみちハードウェアスレッドを想定してないからマルチコアやSMT環境下では正常に動作しない >>199
うーん、なんでそんな早いんだろ
おれの環境では、メモリ36G、そのうち18GをRAMディスクにして、その上でコンパイルしてる。
この環境でおよそ10分
configの仕方かな？
カーネルだけコンパイルして、モジュールコンパイルしてないとか？？
あ、おれはmake oldconfigでやってる Ryzenはバカと無知を晒してでも擁護したいと思わせるほど魅力的なCPUだということが証明されつつあるな。 >>203
MicrosoftがWindows10 32bitとWow32のサポートを継続している以上問題は大アリだ
RyzenをGCCが動かせない欠陥CPUとするなら、SkylakeはWoW32を動かせない欠陥CPUって事になる 朝の段階で360回ノーエラー
これはどういうことなんだろう？
こちらのやり方が間違っているのか
make回数が足りないのか
やはりメモリ辺りの関係なのか
USB最小限だからかグラボなのか
UEFI最新だからなのか
>>213
>>167を使ってるんだけど
make defconfigはs氏の真似をしただけ
oldconfigでもやってみますね make clean
make oldconfig
script
で約1:36ですね
他の人はどうなんでしょう？
と振りつつ一旦抜け make clean
make mrproper
make defconfig
で1:25だた 現在稼働中のカーネルの
.config でビルドしないと。
/proc/config.gz を展開して
.config にリネーム
make menuconfig でryzenに関連ありそうな
オプションをチェック defconfigだと記事の構成で60秒切れるみたい
ttp://www.phoronix.com/scan.php?page=news_item&px=MTAyNjU
>>219
今回はkernel makeの確認だけで使わないんですが
menuconfig要ります？ ryzen でビルドしたカーネルを
使ってテストする必要性ないの？ >>221
MSというか、組み込みとPC用プロセッサじゃ何もかもが違う文化なんですが
x86でCPUのバグをソフトウェア側で対処した例って、
有名なF00Fバグとかぐらいで数少ないんじゃないすかね
第一コンパイラで対処が必要な不具合があるならさっさとエラッタとして公開して、
幅広いソフトウェアが対応できるようにしろって話で
自社のコンパイラだけにひっそりと搭載してだんまりでいいわけがない（仮にそうだとしたら） AMD CPUよりパフォーマンスが低いバグに対応するためソフトウェア側で対処させたりとか日常茶飯事だろ エラッタとして公開しろやって直接AMDに言い続けないとなーなーになって終わる 幅広いソフトウェアが対応できるようにしろ、というか、限られたソフトで問題出てるというのが現状だからな
そんなに問題が幅広かったら、日本人が騒ぐ前に海外発信のニュースがネット上を飛び交ってるよ 本当に問題が限られたソフトでしか出ないのか判断するためにも、
さっさとエラッタとして公開しろって話
ソフト側に問題があるならそれはそれでさっさとそう断言すればいいだけの話
ネットでニュースが飛び交う度合い（＝問題の幅広さ？）については
なにも言及していないのでいきなり持ち出されてもコメントに困る AMD
「 なんか馬鹿が勝手に騒いでるわーw
え？疑惑を持たれた側に挙証責任があるとでも？w 」 自分の環境だとカーネルビルドにかかる時間はdefconfigでだいたい80秒
>>222
現状コンパイル時に内部コンパイルエラーが起きてるんだから、カーネルが正常にできているかは内部エラーが全く起きななくなったときに改めて確認すればいいよ
どうせ現状でビルドしたカーネルを使う人はいない 証明責任（しょうめいせきにん）とは、裁判をするにあたって
裁判所又は裁判官がある事実の有無につき確信を抱けない場合（真偽不明、non liquet）に、
その事実の有無を前提とする法律効果の発生ないし不発生が認められることにより被る、
当事者一方の不利益のことをいう。挙証責任、立証責任ということもある
（Wikipediaより）
はてこの喩えでいうと、どこで裁判が行われていて、だれが裁判所又は裁判官なのだろう？ 俺が変なのは否定できないが、
法的トピックでもない場面でいきなり挙証責任とかわけ分からん用語を持ち出すやつも大概ではないのか？ >>224
えと、>>174 あたりから読んでほしいとこだけども、文化の違いとかじゃなく
なんでもCPUエラッタの退避コードはくコンパイラは特殊らしいよ？って話 >>215
Windows 10 32bitは元々SkylakeをサポートしてないしIntelも64ビット用のドライバしか出してない
Wow32でも16ビットプログラムは動作しないし、VS2010以降の開発ツール、延長サポート対象のWindows 7もVS2005以降が対象で、[a-d]hへの部分書き込みをするコードを生成するコンパイラはそもそもとっくにサポート対象外
残念だったね >>236
もちろんそこから読んでるから大丈夫
＞CPUエラッタの退避コードはくコンパイラは特殊
いやだからね、汎用x86コンパイラにおいてはかなり特殊でしょうと
わざわざすべての文章に（※汎用x86コンパイラに限る話）
ってつけなきゃいけないのか？ >>216
すみません、おれがアホでしたorz
過去にビルドしたことないのに、make oldconfigしてたわ
大量の質問すべてEnter押してたので、もしかしたら巨大なカーネル作ってたのかもしれん。
家帰ったらdefconfigでやってみるわ >>239
「汎用でないコンパイラ」を例示して見てくれ それより古い設計のコンパイラだとVS2005から導入されたバッファオーバーランチェックも非対応でかつVista以降のASLRも使えないセキュリティ的にザルなプログラムってことになるけどさすがに動作保証以前の問題なのでは
Microsoftがサポートしてるから動作保証するべきって考え方は逆に言うとサポートを打ち切ったソフトは速やかに捨てるべきってことなんだよな >>242
そのコンパイラじゃah〜dhの部分書き込みのコードを生成しないみたいだけど君頭大丈夫？ >>244
それはSkylake,Kabylakeのエラッタの話だろう
そんなものをコンパイラで回避する云々などという話はもともとしていない
それに限らずエラッタを回避する汎用x86コンパイラの例はあるかということならば、
無いことはないだろうけど珍しいんじゃない？ということを言っているので俺に例を求められても困る >>242
かなり面倒くさそうだな、ようやるわ・・・
＞3日探していたバグをやっと見つけた。CALL命令を呼ぶ前後でスタックポインタのアドレスをプラスマイナス16すると、
＞第2世代のコンパイラが正しい入力に対してコンパイルエラーのメッセージを出力するという謎の現象。
＞素直にSEGVってくれればいいんだけど、中途半端に動作するこの手の問題は追跡しにくい。
＞
＞結局原因は、リテラルの構造体で指定されていないフィールドを0で初期化するのを忘れていたということだった。
＞イニシャライザがある場合、初期値の与えられていないフィールドは0で埋めなければいけないんだけど、
＞それをしていなかったので、構造体がスタック上のゴミで初期化されていて、それがヒープにコピーされたあと
＞シンボルテーブルに保存されて後で問題を引き起こしていたのだった。
＞どのゴミを拾うかというのがスタックの位置によって変わってくるので微妙なバグになっていた。 >>245
安定動作実績が世間に認められたもの存在しないならないのと同じだよ
誰がそんなあるのかないのかわからないコンパイラが安定動作することを保証すんの？ >>247
申し訳ないが何が言いたいのか分からない 多くの環境で動作実績のあるUbuntu,GCCすらまず先にCPUのせいじゃないソフトのせいだと要らぬ言いがかりつけられるレベルなのに海のものとも山のものとも知れないソフトを信用して使う人が存在することを仮定するのがそもそも無理があるだろうと言うお話 >>224
GCCとかエラッタの修正の山ですけど？
組み込みプロセッサでもバグを仕様と言い張ってソフト側で修正求めたケースは多々あり
お前何も知らないんだな >>249
いやー、そんな話はしてないんだよなぁ
俺が言ってるのは汎用のx86コンパイラ（≒お前さんの言う「多くの環境で動作実績のある」コンパイラ）
ではCPUのエラッタをコンパイラ側で回避するって例は珍しいってこと
それだけ >>251
それは不勉強だった、申し訳ない
できれば具体的な例を挙げてもらえるとありがたい 組み込みでは多々そういうことがあるのは知っている（だから組み込みでは文化が違うと最初から言ってる）
なんせ、組み込みなんてのは特定のボード専用の開発ツール一式なんてのが存在しうる世界だから >>252
組み込みでは〜とかドヤった挙句、AVRやPICにも半ば仕様扱いされたバグある現実つきつけられて支離滅裂モード入りましたね
もう消えていいよ？
なんの説得力もないから
gccのコミットログ見たこともないんだね
Core2にもコンパイラが通常生成しない命令の組み合わせで起こるバグは複数存在したけど結局実害ないからディスコンまで放置された例がある ARMだと比較的新しいのではCortex-A53のエラッタのパッチ当たってる >>255
x86のgccでエラッタをコンパイラ側で対応する例はそう珍しくはないという点は了解した
ほぼねーだろみたいな知ったかぶりをしたことは誠に申し訳ない
ところで、今回のRYZENのSEGVが仮にCPUのエラッタだとして、
これは単なる局所的な命令の並びだけがトリガーなのではなく、
カーネル⇔ユーザーコードの切り替えや、あるいは他のスレッドの動作具合も影響するかなり複雑な状況がトリガーになってるっぽくて、
単にコンパイラの吐くコードだけで対処するのは難しいっぽい気はするがどうだろう？
むしろカーネルでコンテキストスイッチするときに本来不要なコストのかかる処理をかならず呼ぶようにするとか、
そういう対処のほうがまだ可能性ありそうなのだが 全然話し違いますがマザーの設定の中に
RedirectForReturnDisっていうのがあって
workaround for GCC/C000005 issue for XV Core on CZ A0
ってあるんですがこのGCCってcompilerのGCCですかね？
asrock AB350M Pro4>Advanced>AMD CBS>Zen common option
SMT Modeの次の項目 >>259
XV Core = eXcaVator core
CZ A0 = Carrizo
なんでZenのマザボに項目が残ってるんだろ changelogくらい普通見るでしょ
毎回ここ見るたび頭がバグってる人が来ているね >>262
Bristol RidgeってModel 65h-6fhでCarrizoの一部だったのか
そりゃ残ってるわな そこまで詳細に考えなくても鰤はAM4でExcavatorコアだから
それ用のエラッタ対策入っててもおかしくはないと思っただけ 単純な除算バグもコンパイラじゃ対応出来ないのに、今回のキャッシュっぽいのが対応出来るわけないと思う >>268
超単純
特定の値を入れると値を間違う
何の不確定性も無い キャッシュっぽいってのも、キャッシュなら対応できないっても推測でしかなかろう
CPU設計の専門家でもないのに何が分かる
真相はAMDにしか分からないって可能性もある
例えばシステムマネジメントモードというものがある
https://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88%E3%83%A2%E3%83%BC%E3%83%89
Wikipediaにも書いてあるが、こいつはOSからは透過なことが特徴だ
つまりOSからはCPUがシステムマネジメントモードで何やってるのか見えないし
システムマネジメントモードから復帰すると前と同じ状態に戻るから
システムマネジメントモードに入ったことにOSから気づくことも簡単ではない
例えば、ファームウェアがシステムマネジメントモードでコードを実行して、OSに処理が戻った後
CPU内部の状態によってはインストラクションポインターとずれた命令を実行する、みたいな状況なら
OSからトラブルシュートするのは極めて困難で、真相はAMDにしか分からないだろう
もしこういうシナリオならファームウェアの方でワークアラウンドがあるかもしれん
が、俺もCPU設計の専門家ではないので以上の説明にどれだけの妥当性があるかは全然分からん
俺はAMDを待つよ >>270
ではなく、除算アルゴリズムはご存知だろ？
命令の代替なんて、処理速度も含め、そんな単純な問題じゃない。
単純な処理ってのは、手順を変えるだけでなおるとか、ある処理の前にある処理をしないとか、そーゆーの。 改めてxubuntu17.04で追試
make中に間違えて手動でソフトウェアの更新を起動した時に
cc1がsegvで落ちたのが１回 orz...
それ以外はOKで現在30周通過
対象は4.11.8/1:35@1700
>>269 ｲｶﾝﾄ? >>272
対策は単純じゃないが、問題は単純
今回の問題は問題自体がはるかに複雑に見える >>274
普通に考えたら、AMDも調査に手こずってるんだろうね。
まぁ、隠蔽の疑惑持ってる人もいるみたいだけども、隠すメリットが思いつかない。 隠すメリットが思い付かないって
ずいぶんと発想が乏しくないか？ >>277
隠して後で大爆発するよりかはメリットあるわ AMDがだんまりを決め込んでる今できる対策としてEPYC導入を表明してるDropboxについてはOneDriveとかGoogleDriveにデータの引越し済ませて解約することだけ。
発生条件が特定できない以上サービスプロバイダ側も対策は不可能だしデータが消えてからでは遅いからな。 確かにそれが正解やね
んでCPUもIntelに交換するのが正解 >>279
なんでパートナーにまでだんまり決め込んでると判るの？
これまで３桁にものぼるエラッタを公表してきたのに、それ、全部一般に認識されてる？
むしろ一緒に検証してる最中かも、と考えられなくもないと思うけども。
てか、もしだんまり決め込まれてるとしたら、Dropboxの対応が遅いでしょ。 >>276
Segfaultが出る不具合の修正がいくつかあるな
Ryzen SEGVに影響あるかは分からんが RyzenのSEGVはjmp/jcc命令実行時に「RIPが64バイトずれる現象」の副作用であって
むしろズレた先が有効なアドレスならズレた状態でも動いてしまうから問題（例えば壊れたプログラムがあたかも正常であるがごとくビルドされる）なんだよ？
アドレスが即値指定されてるjmp命令のアドレスが間違うなんてCPUが正常に動いてない以外の原因ないだろ
だからgccの修正とはなんの関係もない 信者はどうしてもCPU以外のせいにしたいらしいから >>284
64バイトズレるパターンが1番再現率高いから確定にいつ変わったんだよ >>286
誤ったジャンプ先がたまたま範囲外アドレスでSEGVで止まってくれるケースが現象を追いかけやすいだけで
ジャンプ先がズレた状態で動いてしまうほうがCPUの暴走を検出しにくいからね。
その範囲内だったケースもほぼエビデンスとれてる状態だろ今？
自己書き換えプログラムでもない限りRIP相対即値が書き換わることなんてあり得ないし自己書き換えする際にはL1Iをフラッシュして再ロードしないといけない。そんな操作はコンパイラ内でやってるわけがないのでソフト側でジャンプ先アドレスを間違うほうが無理がある。 64バイトズレル？
本当か？
AMDは何て言ってるの？ >>289
調査中
CPU以外の部品交換とか電圧設定変更とかで頻度が激減したりするので
単なるロジックの問題ではなくおま環由来がかなり含まれていて難しい そもそも毎回同じプログラムを走らせて
エラーが出たり出なかったりってのがコンパイラのせいとかおかしくね
リーク以外でランダム要素ある? >>291
キツキツのマルチスレッドだからなんぼでもランダムになりますよ
何年か前のgccでLinus激怒というのがありまして
SEGVで落ちるわぐちゃぐちゃな出力出すわという酷いもの ただし、ロウレイテンシカーネルの人はgccの問題じゃなく
こりゃカーネル/Ryzenのすりあわせだなという結論になった模様 >>290
原因と関係ない要素で発生率が変わるなんてごくごく普通のことだぞ
非常に特別なことみたいに書いてるが カーネルをローレイテンシにしたら改善云々の話、コンテクストスイッチの問題と仮定するなら結局タイミングによって内部状態の復帰が正常にできてないってことで普通にそれもCPUのバグなんだろうけどな
それすらRIPが64バイトずれる現象自体の説明にはまるでなってないし >>292
>>293
gccも結構な前科持ちなんだな
今回の修正点リストといい、gccに対するイメージが変わったわ
盲目的に信用はできないな
Linusが激怒する位なら、いずれプランBのコンパイラも出てきそう
Law latency kernelは挙動が(良い方向に)変わったからそう考えるのは自然な流れか
どのみち対応待ちになるのが辛い所だが >>299
まぁ、証言ひとりではね。
知らんだけで追試情報あればごめんだけど。 >>297
つづりまちがい
Low latency kernelだった >>302
clangというのがプランBなのか
勉強不足でスマソ
Linusが怒る話はそこそこ聞いた事はある
(nVのドライバとかSE LinuxとかXenとか)
ただgcc絡みでも怒った話は初めて聞いた
商売っ気のないJobsみたいな人だと思ってる たかが64バイトくらい気にすんなや！！！！！！！！！！！111111111 >>304
はっきり言ってgccは時代遅れで、これからはclang (LLVM)って流れは5年くらい前から見た
確かにgccは付け焼き刃の繰り返しで大きくなってしまった ただLinuxのカーネルってGNUの独自拡張構文に依存してるとかで、
gcc以外でビルドできないんだよね？
そんでもってclang/llvm側はそんな独自拡張を実装する気はさらさらないと明言
ってのが数年前だったけど最近はどうなんだろう
相変わらずカーネルをgcc以外でビルドしてるって話は聞かないし clangが主流になるにはlinux kernelが素のままビルド出来ようにならないと・・・ >>308
FreeBSDはclangでビルドできるように修正をした。(2013年頃)
そもそもclangやC言語標準でコンパイルが通らないような規格外の独自拡張を悪と見なす方針だろう
Linux側がなんとかするべきだろうね >>305 >>306
ウソん・・・1バイトでも大問題www 少なくともkernelビルドにおいてはclangはプランBではないのか
OSSの世界も色々大変だな
そこまで動向ウォッチしてないから勉強にはなるが 訂正
少なくともLinux kernelビルドにおいては、だな >>310
まあLinux側もパフォーマンスとか構文のシンプルさとかわけがあってそうしてる部分もあるんだろうけど、
GNUと心中しない道を選ぶならLinux側でなんとかしなきゃいけないだろうな
その口ぶりだとさすがにまだLinux側のコードはGNU依存のままなのかな >>296
RIP関連仕様かなんかそんな事が書いてある場所があった気がするけど思い出せん
何処で見たんだろうか 世界は今日から君のもの
AMDが迅速な対応さえすれば、ね Firefoxもしかり、オープンソースソフトって企業に見放されるとメジャーバージョンのインクリメントが加速する法則があるよな xubuntu17.04で300回以上回して(314回?)
昨日書いた手動でのcc1のエラー以外は確認できず
起きないのではなくて300回で足りないだけかもしれないけど
最初に報告したときと違うのは
1. make対象カーネルの違い(.7と.8)
SEGV頻度に影響あるかは全く不明
2. 最初の頃にdefconfigが抜けていた可能性
(既存の.configをコピーした気もする)
だから時間かかっていたのかも
3. もしかして最初はメモコンが安定していなかった可能性
(例えmemtest86が通っていても)
boot順とか変える時にXMP Profileとか
選んだりしてたし何かあってもおかしくない
はいはいおま環乙
次 gentoo は後にして dragonflybsd+gcc
buildworld と buildkernelまず１回テスト gcc6.4.0をubuntu16.04でビルドしてみた
2.5時間程かかった
これでkernel4.11.7をビルドすると5分程遅い
今連続ビルド中
まだ4回目だけど今の所順調
しばらく回しておく 6回目でSEGVとwaitが同時発生した
(同時発生は初）
この実験は一時中断する うえああおつかれ
redhat系が良さそうな
epycがさわれる環境もCentOSみたいだよ Ryzen 1600
os ubuntu 17.10 alpha
clang 4.0.1
Makefile gcc ->clang
ワーニングが出たけどvmlinuzができた。 >>319
gccリビルドしても改善はしなかったですか。
検証乙です。 sat氏のおかわり後レポート次第かな
個体差で片付くか、あるいはもっと根の深い問題か >>320
乙
できれば4.11系の新しめのカーネルの環境でも試してもらいたい
>>321
fedora26は7/11に正式版になるようだ
CentOSはEPYCに合わせて出るのかね
>>322
乙
clangでkernel4.12のビルドは(動くかどうかは別として)通るのか
並列ビルドで連続ビルドしたらどうなるかは気になる所 クロスコンパイルというか非Linux環境で
gccでLinuxカーネルをビルドする場合はどうなんだろう むしろこんな2ちゃんねるのスレが役立つと思ってるほうがウケるｗ sat周り（特定4名くらい）はだいぶ苦しくなってきてどうするんだろ
だんだん醜い言い訳になってるわ >>324
gcc自体のビルドはmake中に3回ビルドして結果を比較し一致しないと成功扱いにならないそうだ
3回とも同じ失敗をする可能性もあるけど一応kernelビルドが通る場合が多い位だし失敗したとは考えにくい
あと時間がかかるのがね...
>>326
バージョンが大きく異なるkernelだけ入れ替えは動かなくなったりすると自分の手に負えない
最初からkernel4.11系のディストリを使う事になる
やるとしたらfedora26辺りで実験してみようと思う >>329
WindowsでMinGWとかCygwinとか？
試したという話は聞かないが、そもそもそういう環境でx64カーネルビルドが通るのかね >>331
ウォッチ乙
もはや見に行く気もしないから現状が分かるだけで助かるわ CPUノーマルにメモリ設定総当たりしたりしても全くNG消えなくてTaichiの新BIOS待ちしてたけど
全然新BIOS来ないからちょっとレジストリでASLR無効にしてWin版やってみたらNG出なくなった
ASLRのエラッタじゃねーのこれ LinuxはASLR切ってもダメらしい
WindowsでASLR切った話は初めて聞いた
メモリ管理の挙動が変わるから、たまたま良くなった可能性もある Linuxでエラー出てるのはOCCTとかメモリに高負荷かけたことない環境で設定が甘いんじゃないかと思うけどな
試しにWin10ダウンロードしてテストしてくれと言ってもやるような人たちじゃないだろうけどｗ
自分がLinuxメインにしてた頃はPC組んだら先にWinインストールして耐久テスト完了してからやるようにしてたよ
使っててたまにクラッシュするのが直らなくてWinで確認したらメモリの相性だったことがあったからだけど
LinuxにもOCCTとかIntelBURNtestみたいに手軽にテストできるアプリがあればいいんだけどね kernel-buildテストがあるじゃ無いかw
low-latencyカーネルでやると大丈夫って話もあったな 部屋暑くて辛い・・・
とりあえずOK2万超えたら止めて寝るわ >>335
ありがとう
dragonflybsd buildworld buildkernelのセット
10週ok
もっとやろうと思ったけどdiskfullになり
原因不明のため中止(cache以外に何か残ってる？)
いまgentoo vannila kernel(4.12)で開始
対象は4.11.8に
gcc5だけど後で6に上げるられるので
ひとまずこれで開始 詳細略 >330が呼吸して酸素を浪費してるのが最も無駄だと思う >>338
Prime95ならLinux版あるからそれで良いのでは？
誰かがブータブルイメージ作れば皆が使ってくれそうだけど >>341 自レス
gentoo linux vanila kernel 4.12.0
heap allocation有効でスケはCFQ
gcc 5.4.0-r3 で kernel 4.11.8をmake -16
320回中１回segfault #141
一周約1:22
お次はgcc6 >>345
修正 make対象は4.11.9だったｽﾏｿ 相当にニッチな用途の上におま環かどうかも解らない程度の問題 これってエンコード後にファイルが壊れたりするって事？
ryzen使っててファイル壊れたとか実害報告でてるの？ >>348
そんな報告が出てるならもっと大問題になってる
どうしても心配なら使わないのが正解 EPYC界隈じゃ何の話題にもなってないし販売にも影響し無さそうだし、サーバー分野じゃ解決してそう >>348
普通に使ってファイル壊れるならとっくに大問題になってる >>349-351
ありがとう。録画エンコ機用にryzen買った後にこの話題知ったから少し不安だった
気にせず組むわ 火を噴く訳じゃないからな、有ったとしてもブルースクリーンが出るくらいだよ ポインタがズレるってことは、
データがぶっ壊れる可能性もなくはないんだよね もし仮にループのjccでRIP化けが起こると少し前本来1回しか通してはいけない初期化処理を通してしまってループカウンタが初期化されてオーバーランしてしまう、SEGVにならないのでまま出力データが化けてるのに気づかない、なんてことも起こりうるね ホントにずれてるんなら、高確率で暴走して停止だと思うけども？
なんでSEGVなんて、ある意味行儀のよいトラブルだけが目立つのか。
また、そんなうまい具合に出力データだけ書き換えて、何事もなく動作を続けられるのか。 >>357
IntelならOS、ついでにHDD/SSSDも道連れに大クラッシュなんだけど
AMDには強力な保護機能を搭載しているからよ
カーネル空間、ユーザー空間ってのがあって、AMDはIntelと違いカーネル空間動作のものが
大クラッシュしても何事もなく動作するってすごいもの。さすが、天才設計のAMDだよな
一方、Intelはユーザー空間のクラッシュが何とかそのプログラムのクラッシュですむって軟弱保護 ずれるのって確定してたっけ。
何か確定してるみたいに、印象操作されてるみたいでやな感じ。 >>163
Androidの中身はLinuxだって覚えとけよ、ボク >>364
ありがとうございます。
認識不足でした。
それでしたら、ずることが確定のソースを教えていただけませんか。 何度もｽﾏｿ
gentoo で gcc6は作業中なので出来ず
通称うどんワールド後に追試した結果
300回中１回segfault(#275)でしたと
最適化は効果なかったかな
その環境は捨ててarch 0701版で追試中
5回回らないうちに１回segfault出たけど
このまま回す予定
gcc 7.1.1 kernel 4.11.7(かな?) xなし
make対象は4.11.9 defconfig 一周約1:30
おっと今回だけssh越しにmake仕掛けてしまった
明日やり直そうww 超高負荷でエラーが出る場合は
普段使いで数週間に1回だけ異常が出るか出ないかって感じ
負荷テストではエラー吐いたけど
普段はそんなに重い作業はしないので問題なしとしてる
ブログの人がたまにいるけど俺的には無理 >>168
ニュースとして知ってるが、それは先の話で姑息なすり替えだね >> 358
そこで切り分けできれば原因がECCよりも外側か内側(CPU側)か特定できる。
ECCが有効な状態でこの不具合が起きるなら、CPU側なので厄介。
だれかECC付きのシステムで試せないか？ >>338
OCCTで24h問題なしだったマシンで、Linuxで30分程度でsegvでたよ >>371
OCCT6時間終わってCPUクロックが切り替わった時に青画面とか普通にあるからな
CPUクロックと共にメモリクロックも下がるからこうなる場合がある
ビデオカードもHynixのVRAMで過去に問題が起きて、修正BIOSではVRAMクロックが固定化されたこともある
負荷かけて全速の時は良いがクロックが切り替わる時にコケることも少ない無いからね
特にコンパイルだと負荷変動があるのでOCCTより不安定になる事があるのでは >>373
メモリクロックもスピードステップみたいになってるの？
もしそれで落ちたら笑う ずれてる理論の人は、メモリの設定ミスが原因で不正なバイト列をデコーダに食わせただけだろうなあ。
現在のLinuxが取り扱えるMCEはメモリ周りのみ。Zen世代のMSR,MCEについてドキュメントがないのだからしょうがない。
AMDは早く17h Family BKDG出してください... SIGSEGV(一般的には Page Fault), SIGILL(Undefined Opcode)が起きてもコアダンプが正常であるなど普通に起こりうるのですよ。
実行時にInstruction Cacheが汚染されたとしても、片っ端からダンプを吐き出す作業中にその時のCacheが保持されている保証がない。
ECCメモリがおすすめされるのはこの手の起こりようがないエラーが報告として上がってしまうためなのです。 連投すまん。Ryzenに問題があるかどうかはともかく、大騒ぎしている約一名は痛すぎるな。追試してみるか…
> BIOS: 1.0.0.4a(設定はデフォルト)
AGESA1.0.0.6が出るまで、出てからもメモリのコンフィグレーションの更新がされているのにデフォルトってだけ？
それで動くほどDDR4-2400って枯れていたっけ。パラメータの調整すらできないだろうから、彼の周囲だけは一生問題が解決しないだろうな。
> OS: Ubuntu 16.04
> kernel: 4.8.0-54-generic
ここもツッコミどころ。linux-image-4.8.0-36-genericがデフォルトのはずなのに4.8.0-58でもなくなんで-54?
> 問題が大きく扱われるようになる
> AMDサポートコミュニティが活発化したり(AMDは黙ったまま)、
勝手に放火しているだけ。活発化したって、めちゃくちゃな英文で内容のない文句ばかりになったからまともな人まで相手にされなくなっただけ。。
恥ずかしいのでやめてください… 何も貢献しないのもあれなんで、無限コンパイル & コアダンプ保存のために使っているワンライナー置いておきますね。
Hideki EIRAKUさんの日記で紹介されていたものの改変です。
while test true; do a=1;while test $a -gt 0;do make clean>/dev/null&&make -j12 >/dev/null&&echo $a `date +%Y/%m/%d-%H:%M:%S`&&a=$(($a+1))||a=0;done;mv core ~/core.`date +%m%d-%H%M`;done
1 2017/07/09-15:50:37
2 2017/07/09-15:53:22
...
27 2017/07/09-17:01:44
…一晩走らせてみようっと たしかに現在の現象（負荷のかかるときにランダムでエラー）だと見た目では起動できているように見えても実はちゃんとした設定で起動できていないだけって感じもするよなぁ
初物で設定がシビアなCPUのはずなのになんでこんなSEGV騒いでるんだろう... とりあえず一方の言い分だけ見て物を考えるのは危険だと分かった
AMDフォーラムとかgentooフォーラム見ての感想 落ちない。4時間弱で判断するなって煽られそうだが87回は成功している。
これで一晩動いたらもうメモリが原因でファイナルアンサーだな…
現在構成を Ryzen 1600 6C12T で -j12 しているので1回あたり3分弱なのでこんなもの。
$ cp /boot/config-$(uname -r) .config; yes "" | make localmodconfig; yes "" | make oldconfig
BIOSのメモリ設定がRyzenのほうではなく過去のAM4プロセッサを向いているんじゃないか疑惑。
落とすために今まで試みてきたこととか、Windowsユーザーでも4GBのUSBメモリでUbuntu起動して同じことを試す方法をまとめたら需要あります？
...
86 2017/07/09-19:40:12
87 2017/07/09-19:42:56
88 2017/07/09-19:45:41 amdの奴でコンパイルしたryzen_test
エラーでないんだが? もうほとんど騒がれてないよ
他のスレじゃ全く気にされてないし、たまに団子がAMD煽るために持ち出すくらい 結局一部が馬鹿騒ぎしただけって落ちか。。
#自動でハッシュ表示されるから名前いらんのね。 >>384
あれは出るか出ないかは確率。Intel IA-32 Architecture的には出ても構わない。
強いCache Coherentが保証されるマルチプロセッサ構成では出ないし、
そうでなければ確率的に出る。それはIntelのCPUを使っていても変わらないです。
…つまり、試験をしている気分になれる試験 ちなみに暑くてもうやるのやめたけどASLR無効でもNG出たよ
今のところ新BIOS待ちだけど新しいのでもNGは出るんだろうなとは思う
あとは誰かがB2で試してNG出るかどうかかな >>384>>387
std::atomic_intを使っているのかと思ったら
https://github.com/hayamdk/ryzen_segv_test/blob/master/ryzen_segv_test.c#L15
> typedef volatile long atomic_int;
ってギャグ？これはひどい。貶すためにこんなものまで出回ってるのかー
本当の意味でのatomic_intと使用方法は以下の記事を参照してくださいな。
http://qnighy.hatenablog.com/entry/2015/11/20/152617
ここでのatomic_intは記事中の ./main 2 の実行結果と同じで結果は不定です。 試しにLinux板の勢いが10超えてるスレ全部のレスでSEGV検索したけどHit 0だった
スレどころかレスもないし、実害被りそうな連中が全く気にしてないから、まあそういうことでしょうかね >>389
意味が分からないんだが
atomic_intという名前のlongなのか >>392
専門的な話題で申し訳ない。volatile longはlongと少し違うが、同期実行のためには全然足りない。
void test1(long *p) {
++*p; ++*p;
} は
test1:
increment *p <- pの中にp+1を入れる（内部的にはp読み出し、1加算、p書き込み)
increment *p <- 2個目
return
とコンパイルされるが(擬似コード)、二度書き込むのもったいないから
test1:
move %temp, *p <- pの中身をtempレジスタに入れる
add 2, %temp <- tempレジスタに2を足す
move %temp, *p <- tempレジスタの内容をpに入れる
return
と1回の書き込みに最適化される(可能性がある）。それを明示的に書かれた回数通りにするのがvolatile修飾
void test2(volatile long *p) {
++*p; ++*p;
} はpに対するそれぞれの操作が必ず1度書き込まれることが保証されるので1つ目の擬似コードが出力される。
C++で導入されたstd::atomic_intは、複数のコアで同時実行されても結果が保証されるようになる。
void test3(std::atomic_int *p) {
++*p; ++*p;
} は
test3:
lock increment *p <- lockがすべてのCPUで調停する命令(プレフィックス)
lock increment *p
return
ここで、lock prefixがついていないincrement *pが同時実行されると
Core0 Core1
load *p
load *p
++temp
store temp
++temp
store temp
と実行順序が一貫性を失うことが起こりうる。これがvolatileで足りないケース
本当ははこの人は、実行されるコードを動的に変更して一貫性があるかどうかの差を見せたかったんだろうけど
何が起きたかって「私は並列プログラミングできません」と書かれたコードを世界中に晒したっていう >>393
スペースは除去されるのね。しかも間違った orz
test1:
move %temp, *p <- pの中身をtempレジスタに入れる
add 2, %temp <- tempレジスタに2を足す
move *p, %temp <- tempレジスタの内容をpに入れる
return >>390
確かに、（自称でない）Linuxガチ勢は問題ないでしょうね。
>>388
めげずにメモリの設定を見なおしてみてください。
BIOSのXMP,JEDEC設定、Advanced設定のスクリーンショットなどあればアドバイスできる…かも？
...
115 2017/07/09-21:00:04
116 2017/07/09-21:02:49
最初はBIOSデフォルトで死んでばかりだったが、もう失敗する気がしない。 コードは見てないけど、例の問題の現象とは合ってるの？ >>397
ryzen_testという名前のもの？中身はただのゴミですよ。擬似的に表現すると、
ぼくが考えた最強の試験()
{
while (お前の忍耐が切れるまで) {
CPUを食い潰す（）;
if (乱数(0~1.0) < 0.0001)
表示("失敗")
}
} >>399
コンパイラの例外とは関係ないコード？
じゃあどうでもいい >>396
メモリは総当たりやったよ今までで500回近く再起動してる
さすがに疲れた・・・
2133でも無理だったしまずクロックの変化ではまったく変化なしだな
今は今朝CMOSクリアした後のAutoのまま使ってるよ
最近は面倒でスクショすら貼る気なし暑いし
逆にそちらの設定教えてもらいたいくらい >>402
>>1 にあるryzen_segv_testというコードです。名前はryzen_testではありませんでした。すみません
https://github.com/hayamdk/ryzen_segv_test/blob/master/ryzen_segv_test.c
Linux kernelをコンパイルするのが流行っているのは試験としては
・負荷がかかる
・実用的メモリテスト、キャッシュを兼ねる
・コンパイル時にコンパイルするための実行ファイルを動的生成するのでバグに当たる確率が跳ね上がる
単純化するとgccに負荷をかけた際に問題が生じる確率pとして、動的生成されたコードpによって同じくpの確率で問題が生じる
-> 1-(1-p)^2 ~= 1-p^2 (pが0に近い場合
.-> 問題が表面化する確率が2乗になる
という理由ですね。 ryzenテストみたいなプログラムがゴミだったというだけだろ
B2待てるなら他にも細かいバグいくつか修正されるだろうから待ったほうがいい >>403
ちょっと出かけちゃうので明日こちらの構成を書きますね。
...
123 2017/07/09-21:22:04
124 2017/07/09-21:24:50 現世代のマザーボードとメモリの組み合わせには疑問があるので待てるなら待ったほうがよいのでは？ >>389
隠す必要も無いので白状するが、このコードの作者なのだが、あまりにひどい誤解に基づいているので何点か補足を。
Linux版（というかMSVC以外）のコードを見てくれ。
君の言う悪いtypedefはMSVC以外では行われない定義だ。そしてstdatomicを使った正しいコードになっているはず。
まず精髄反射的にあげつらうのではなく、コードをちゃんと読んでからコメントをしてくれ。
そして、Windowsでもコード書き換えのスレッドとその実行スレッドの同期はMSVCプラットホーム固有のマルチスレッド同期用のプリミティブを使って正しく同期が行われているはず。
volatileに頼った不正なマルチスレッドプログラムではない。（そもそもその同期プリミティブの変数型がvolatileなのでそれに合わせているだけ）
また、atomic_tとかにtypedefしてるのはLinux用のコードとなるべく共通化するためで全くギャグなどの意図はない。
他にも幾つか突っ込みたい点はあるが、まずはこの点についてご確認いただけるとありがたい。 早とちりで >>389 を書いちゃったとしたらはずかしすぎるな というか、これは謝罪しないと
まともに同期処理や排他制御が出来てるかどうかはコードを見てないので知らんけど 非常に単純なコードで問題が再現するようになったのであれば、解析としては一歩前進 たぶん古いVC使ってたんじゃない？
2017にはさすがにC++1y（追加で1zの一部も？）対応してるよ
なんとなくバグの検証の効果としてはともかく古いVCなら_InterlockedIncement使うべきコードってのはわかる。 んでもって、マルチスレッドのデータ同期としてはここまで書かれてるようなことに気をつければよくそこまで難しい話ではないし、
稀に失敗するというようなことはあってはならないしあればとっくにあらゆるマルチスレッド系のアプリで問題が出てるはず。
問題はデータとして書き込んだ命令の実行のときであって、
命令はデータとは独立したキャッシュなどを備えているのでデータ的に同期が取れているだけでは不十分で、
追加の（しかも非常にCPUのアーキテクチャ依存の）操作が必要となる。
詳しくは省略するが、AMDやintelのドキュメントで言及されているserializing instructionという命令を使用する必要がある。
このテストコードではそれを正しく使用しているはずだが、
たしかにこれについては事例も少なく非常にプラットホーム依存で難しい話なので100%の自信があるわけではないし、不備があったら教えていただきたい。
（というかx86は強いコヒーレンシが保証されてないからコード書き換えとその実行は確率的に失敗するようなものなのか？それを保証するためのシリアライズ命令というバカみたいにペナルティ大きい命令ではないのか） >>419
残念ながらMSVCはC言語のほうはやる気がなく、最新の言語仕様全然取り入れられないんすよね 確かどっかの文章でlockじゃ不十分だからMFENCEとやらとかCPUIDとやらとかを使えって書いてあったが、そういった話だろうか コンテクストスイッチに起因する問題とするならスレッド起こしまくってみるのが良いのでは >>421
作った本人が自信が無いようなコードじゃ、検証としてはちょっと... ていうか、誰もコンテクストスイッチの問題なんていう話題はしてないけど なんとなくマルチスレッド化できてだれがやっても同じ答えが出るべき問題、たとえばN-Queen問題あたりを検証するといいかも、と思いました。
まあ、それでバグ踏むとは限らないけど ちょっとは上の文を読んでから書いた方が良いと思うよ 多少でもプログラムを知ってたら、>>421の書き込みを読んだ後に>>430の書き込みは有り得ない >>422
待たなくていい
買いたいときに買えばいい
SEGV騒いでる奴は勘違い君 永遠に次を待ち続けるような人でしょ
B2がでたらB3を待つような >>367 時流に乗り遅れてるけど
arch 4.11.9-1-ARCH & GCC 7.1.1
実機直接起動で500回中１回segfault(#230)
make -j16 で対象は4.11.9 defconfig
ssh経由でscript起動した時はすぐエラー出たけど
直接だと通常通りだった
shellのレスポンスとか関係あるのかな?
lowlatencyがーっていう報告もあったぐらいだし
distro間の違いはそれほど大きくは無かったから
非PIE原因説も証明はされてないみたいだしね
結局のところkernelを300回以上makeして
gccのエラーが出なかった人は国内にはいないのかな？
いたらハード構成とdistribution教えてほしいな
(追試した本人に限る) >>432
そもそも自己書き換えに意味があると思ってないからね
gccに該当する処理はないはず JITの検証という意味では、いまどきのJITコンパイラは既に実行属性が与えられてる命令列を書き換えるのではなく新たに領域を割り当ててコード列を書き込んで実行属性を書き換えます
ページ属性を書き換えてデータとして書き込んでまた実行属性戻すとか、メモリがよっぽど足りない環境でない限りは普通やらないですね
コンパクトな実装ではXbyakがIntel公式のライブラリにに採用された実績がありますよ >>439
結論出ないまま自然消滅かと思ってたところに、375からの流れだったので。 >>437
つまり、
流れを読まずに唐突に自分の思い付きを語ったわけだ gccのなかで自己書き換えやってるコードがあるならまだわかるけど無いでしょ？
それでたまたま不具合見つけてもgccのSEGVとはまた別の問題だと思いますけど（CPUの問題ですら無い可能性も 普通に作ったN-Queen問題なんかで発生するならもっと大きな問題になってるでしょ もしメモリに問題があるならマルチスレッド化したN-QueenとかPiでも問題が出る可能性は高いと思ってますがね >>441
うーん、というかコード全く読まない（読めない？）人が
頓珍漢な指摘を連投しただけで、それに対するツッコミだけで、
基本的には何ら新しいことは書いてないっす
今ここで話題になってる程度のことは各所で散々語られてますし
>>443
自己書き換えが手っ取り早くL1Iやuopcacheを汚染する手段だからやってるだけで、
別に自己書き換えが直接的だと言いたいわけではないです
まあおっしゃるとおりこのコードの再現するものがgcc等のSEGVと同じ問題と断言はしないです
根底で共通する部分があるんだろうと僕はにらんでますが（L1Iやuopcacheの同期まわり） ちなみに大量にメモリ上に配置した関数をランダムに呼ぶとかで
命令キャッシュまわりを混乱させるプログラムは作ってみましたが、
まあその程度ではSEGVしませんでしたね。
あとリンクやOSの動的リンクでは大量の関数を自在に配置するのは面倒で、
メモリに自在に配置するには自己書き換えが一番手っ取り早く、
それをやってたら発見したというのが今のコードです
ランタイムの自己書き換え無しでSEGV起こせるコード見つかったら
それは大変説得力あるので（自己書き換えにバグあるんだろうという懸念を排除できる）
ぜひ頑張って作ってほしいと思う次第 マルチスレッドPiってy-cruncherじゃだめなの >>445
メモリの問題として、なぜその二つ？
もっと普通のテスト用コードを書いた方がマシだと思うけど ページの実行属性取り上げて書きこみ可能の属性与える段階で一旦命令キャッシュをフラッシュするのが規定の動作のはずなので
自己書き換えによって命令キャッシュが汚染されるということが起こりうるという仮説をまず疑う必要があるかなと思いますね。
それともOSによってはExecutableとWritableの属性同時につけるの許可してるの？ >>450
正常に動いていれば誰でも同じ出力になるので再現性があるし、スパコンのハードの動作検証でよく使われてきたから >>451
あなたもちゃんとコード読んでくれｗ
Linuxならmmap、WindowsならVirtualAllocで余裕でできる。
もちろん正規の方法でリンクされたコード領域はWritableにならないのは近代的なCPU+OSなら普通。 >>452
誰でも同じ出力になる
よりも
正しいか正しくないかが他と比べなくても単独でわかる方が良い
メモリテストであれば、演算はどちらかというと軽い方が良い
という事で、クイーンもパイも不適切
という個人の感想 単独で分かるとかいうが今はそのプログラムは本当に正しいのかって言われてるんだと思うぞ
まずは既に実績のあるプログラムで比較するのが先で、そこで問題が再現してから問題の部分を絞り込んでいく方が説得力がある
もちろん実績のあるプログラムもシンプルで検証しやすいものを選択する
gccはデカすぎて絞り込みの難度が高すぎるんじゃないか？ いずれにしてもコヒーレントを保つために書き換えたキャッシュラインは無効化されるのが規定の動作のはずなので、命令列を書き換えた時点で（おそらくL0,L1もろとも）流れるんじゃないかな？
どのみち意味があると思えないな ＞いずれにしてもコヒーレントを保つために書き換えたキャッシュラインは無効化されるのが規定の動作のはず
その根拠をお願いします
むしろ勝手に無効化はしないから同期が必要な場合はserializeしろってAMD、Intel共にドキュメントに書いてあるように読み取れるんだが
ちなみにcpuidやmfenceを外すと余裕であらゆるプロセッサでSEGVるので明示的にこういう命令がまさに必要ということでは CPUIDやMFENCE使うんだろ？
そこでキャッシュコントローラが変更検出したら無効化よ
単にキャッシュラインのクリアしたいだけならclflashというZen専用命令があるぜ >>458
いや、だから明示的に無効化（に加えて実行パイプラインも全部破棄）してるんですよ
なのに、segfaultするからおかしいでしょ？っていう話なんですよ
パイプラインまわりのロジックに不備があって古いuopかL1I由来のものを実行してしまう不具合があるんじゃないかって話で いつまでも大規模プログラムでガラガラポンはおかしいわな >>459
団子氏と何を議論しても無駄だよ？
彼は、実行可能なソースコードを晒すなんて危険な行為は絶対にしないし、
インテル至上主義のアンチAMDだから、テスト環境を購入することすら金の無駄だと考える。
つまり、理屈はこねるが実践はない。 そら金のためにしかコードは書かないよ
自分の技術を安売りするなは職人だった叔父の遺言だ とはいえXbyakとかJTRにコードコミットしてんだけどな、昔 もうこんな時間…すみません。。 > 誰か
>>414
私もあなたも名無しさんですから、自称作者さんということにしておきますね。私もただの通りすがりの一人
gccには-Sオプションがあります。あとはgrep -w "lock"はわかりますよね？それが第一歩です
次にatomic_compare_exchange_(strong|weak)とatomic_exchange_explicitの違いについて学習しましょう。
Acquire/Release, Release/Acquireを学ぶ前にSequentially-consistentを学びましょう。
mfense系のintrinsic命令はそれからです。
もしここで作者がこれを取り下げるとforkが増えてしまう気がするのでそれは望ましくないのですが(見ているかもしれませんし)、
もし作者がこれらの命令について十分な知識があると主張されていて、>>1 に書かれるように実証として
これが特定の対象への価値毀損の主張に用いられていることも知っていたとしたらどうでしょうか？
…まあ、ただの通りすがり同士の独り言のすれ違いということで、
こういう時はマンガかアニメから台詞でも引用してみたいところです。 Ryzenだけが悪いのではなくBIOSが悪い(>>383 >>396)と言いたかったついでに喋りすぎた…
>>403
メモしわすれたので、明日夜の報告になってしまうと思います。すみません
DDR4-2400についてCrutial BLS8G4Dxxxxxx,M16... 8GB x2構成となります。
>>383
...
260 2017/07/10-03:34:57
261 2017/07/10-03:37:41 >>412 >>413
簡略化しすぎました。特にscripts/genksyms以下は単なるスクリプトではなくmake時コンパイルです。
このscirpts/genksyms/genksymsはlexer,parserを持ち影響を及ぼすので一種のコンパイラとして動きます。
そのため、make時にコンパイルされた一種のコンパイラがその後のmakeの実行に影響を与えてしまいます。
「一種のコンパイラ」のコンパイルに成功しなければならず、
その後の動作は「コンパイラ」と「『一種のコンパイラ』を生成したコンパイラ」の正確性に依存するのです。
その前後に対する定数項は無視しても構わなくなり（これは非常に正確ではないが最悪の推定でもある）、
簡略化するとあのように2乗の項が出てしまいます。
その後の話は… >>436 >>462 以外の長文はよくわからないです。ごめんなさい、大丈夫ですか？ う、ミススペリング…Crucial Technologyですね。申し訳なく
>>461
なるほど、それでこうなったのか…ありがとうございます
>>436
> gccのエラーが出なかった人は国内にはいないのかな？
> いたらハード構成とdistribution教えてほしいな
> (追試した本人に限る)
ハードウェアのテンプレとかあればご教授いただければと
OSは再現率を上げるためにUbuntu16.04 (kernel-image-4.8.0-36-generic)、gccは5.4.0です。
もう少しで300回のハードルをクリアできそうです
>>379 から開始、依然問題なし
...
264 2017/07/10-03:45:58
265 2017/07/10-03:48:44 >>399
やっとあのプログラムの第三者レビューが来たのか
それもやらずにこのスレに持ち込んでエラーが出たとか騒がれているのは正直迷惑だった 数人の日本人が馬鹿みたいに騒いで(単独では)問題のない商品の価値毀損して回っている状況…
なだけに正当な議論の中にいたいがために正確に記述を重ねていこうと思うとつらさあります。訴えられたくないし
でたらめ多すぎもいい加減にしてほしい。日本人が騒いでいるために英文の検索結果まで汚染とかまじかー
28h46m50s-15h50m37s = 12h56m13s in 286 iterations near equals 2m43s.
...
285 2017/07/10-04:44:04
286 2017/07/10-04:46:50 どうでもいいけどTwitter名にSEGVをつけて検索で妨害かけた結果、は功績大きいのだけれど、文脈的にはLCAに確認取ったほうがいいんじゃないの…っていう… >>379
1 2017/07/09-15:50:37
2 2017/07/09-15:53:22
3 2017/07/09-15:56:04
...
298 2017/07/10-05:20:04
299 2017/07/10-05:22:49
300 2017/07/10-05:25:34
はい、300回連続成功(dmesgも暇だし何か起きるのこれ？)
結局初期のHaswell/LGA2011v3の設定と変わらない時間かかった。もうDDR4は嫌い…
ただ、 >>466 の3行、3行に込めた思いは名無しとして名無しさんには受け取ってもらいたい
大騒ぎしていた一派が成し遂げたことって、問題解決の妨害だけじゃないか。よくあんなことができるなー ということはあの一行ってとんでもないことやってるんだと… >>383
で終了じゃないの？一週間このようなものを動かせって言われたらECCメモリを要求する( >>376 )が、
Non-ECCメモリのHaswellで同じことをやって同じことを成功させろと言われたらXeon買ってくれ、ECCメモリくれとしか言いようがない…
壊れる環境(BIOS Default)と、今現在書いているこれ(Chrome/Ryzen w/ while test true do make -j12; done 環境) が存在しました、原因はCPU？
...
306 2017/07/10-05:42:02
307 2017/07/10-05:44:44
308 2017/07/10-05:47:27 結局のところスレタイ通りのおま環だったのだけど、まずRyzenの
プラットフォームが未成熟で若干メモリに渋いのと、意図的かどうかは
ともかく間違った検証用プログラムに依るエラーが混ざって原因を
見えにくくしていた、ということなのかな？ そもそもこのgccと全く関係ないプログラムが正常に動く環境どんだけあんの？
自己書き換えの決まりごとのうち、もとの命令列を書き換える場合、すなわちオプション2の場合はCPUIDなどのシリアライズ命令を発行しろとある
Java HotSpotやXbyakはオプション1の方法を使っててカーネルコールで実行属性書き換えるだけでいい
http://www.dotup.org/uploda/www.dotup.org1303183.jpg.html
https://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-manual-325462.html
ただこれだけだと不十分で、メモリシリアライズより前のタイミングでスレッドが切り替わった場合の動作保証ないからユーザーモードで確実にやるには割り込み禁止かけるなどちゃんと手順踏む必要あったはずなんだけどどうですかね？
HotSpotとかXbyakはユーザーモードで保証するのが結局めんどくさいからオプション1の方法を使ってたはず >>383
＞BIOSのメモリ設定がRyzenのほうではなく過去のAM4プロセッサを向いているんじゃないか疑惑。
これはどういう意味？
BIOSのメモリ周りがRyzenをBristolRidgeと勘違いしているという事？
何をもってそう判断したか聞きたい
あと詳しそうだから一つ意見を聞きたい
Low latency kernelを使うとSEGV出なくなるらしい(48時間位の実績あり)のだが、これについてはどう考える？ >>469
テンプレを兼ねて環境書いておきます
OSは初期の環境です
■環境
マザー：Asrock B350M Pro4 (Twitterな人ではない)
CPU：Ryzen7 1700 3.0GHz(定格)
FAN：Wraith Spire 95W対応 Fan-RGB接続済
メモリ：Corsair Vengence LPX(M2Z) 2666MHz(定格) 8Gx2 (Auto)
※メモリ型番は略
SSD：Sam 960EVO m.2 (x4) + ainex Heatsink
SATA: 未使用
Video：Radeon R5 230 1GB
電源：Silverstone ETS550-B 550W (壁から1系統）
ケース：バラックで1500rpmファンMEM/SSD冷却
OS：xubuntu17.04(x86_64) 標準kernel & aptで最新upgrade
GCC: x.x.x(忘れた)?? ??make -j16 tmpfs未使用
対象:kernel 4.11.9 defconfig
UEFI(BIOS)：2.50(最新)
■経緯
UEFI verup(1.00→2.50 NetworkUpdate)
メモリ設定後memtest86 >>479
このプログラムが自己書き換え時のキャッシュ同期ミスってるだけなのでメモリ買い換える必要もない
そしてgccの現象は全く別原因 >>446
＞次にatomic_compare_exchange_(strong|weak)とatomic_exchange_explicitの違いについて学習しましょう。
＞Acquire/Release, Release/Acquireを学ぶ前にSequentially-consistentを学びましょう。
端的に言うとそれらの話はこのプログラムとは全く関係ない話。
なぜなら、データを書き換えた後ロックを出る前にmfenceを実行しているので、
mfenceの前後でのメモリの書き換えの順序は保障されているから。
あなたの挙げているmemory_orderの話も結局マシン語レベルに還元するとlockやmfenceといったものに還元されるだけ。
さらにいえば、stdatomicのmemory_orderをいくら正しく使っても、
それはアトミック変数の観測順序を保障してくれるにすぎず、
アトミック変数ではないもの（この場合では書き換える命令コード）については全く面倒は見てくれない。
なので明示的にmfenceを用いているわけです。
ここはマルチスレッドプログラミングの相談スレではないので、
繰り返しになりますが、コードを読んだうえで具体的に問題がある部分をご指摘願います。 >>477
＞ただこれだけだと不十分で、メモリシリアライズより前のタイミングでスレッドが切り替わった場合の動作保証ないからユーザーモードで確実にやるには割り込み禁止かけるなどちゃんと手順踏む必要あったはずなんだけどどうですかね？
そういう記述はどこにありますか？
「8.3 SERIALIZING INSTRUCTIONS」のセクションには例として特権命令と非特権命令が挙げられていますが、
非特権命令が存在する時点でユーザーモードからの実行を認めているということでしょう。
割り込み云々はOSが面倒を見るべきことですね。
例えばLinuxのsync_core()内でまさにiretqというserializing instructionが実行されてます。
仮にユーザーコード側でcpuidを行ったあとコードを実行する前に割り込みが入り、
戻ってきたとき違うコアに移動していたとしても、
それはOSが制御を戻す前にiretqでまさにシリアライズが行われた後ということになります。 自己改変コードじゃなくて発生できるならそれに越したことはない >>379
使ってるスクリプト違うんですね
揃えてみようかな
今まで使ってたのはコレ(NG出ても続行する)
>>167 RYZEN SEGV test codeの使い方がわからねぇ・・・
./run.sh 8 2500000
って入力したら「許可がありません」って出るし
sudo ./run.sh 8 2500000
ってやったら「コマンドが見つかりません」って出るしどうすりゃいいんだ・・・ コンパイラがﾁﾝﾁﾝでした、またはメモリ回りが不安定で出てました辺りに落ち着くんかね
あと団子が引っ掻き回したくてしょうがないというどうでも良いことくらいか >>486
あなたのコードには実際には一度もlock prefixかかってないんですよ。gcc5.4.0~gcc7.1.0でも確認済み…
Sequentially consistencyすら理解できていないからatomic_intをvolatile intのように扱ってしまう。
同時にlock_enter()/lock_leave()できるlockって何ですか…
勉強しなおしてください。
もうこのスレッドとは関係なくなりましたね。 技術者バトル面白いやりあってくれて構わない
twitterじゃこうバチバチやりにくいだろうし >>495
＞あなたのコードには実際には一度もlock prefixかかってないんですよ
xchg命令は片方がメモリオペランドの場合「暗黙に」lock prefixがかかってるんですよ
そしてx86のxchgはこのような用途に使える（単純なスピンロック）に使えることは有名です
だからこそatomic_exchangeは単なるxchgにコンパイルされるんですよ
これは僕が馬鹿なわけでもコンパイラが馬鹿なわけでもなく、x86のxchgはそういう命令だからです
あなたこそx86のメモリモデルや命令についてもう少しお勉強なさってはどうでしょう
＞同時にlock_enter()/lock_leave()できるlock
よってそれはできません ほんとなんでx86アセンブリ入門みたいなスレでもないのに、
x86のxchgの解説なんてしなきゃいけないんだ
しかも教わるべきほうがもうこのスレッドとは関係なくなりましたねなんて言ってる始末 初めからメモリーが悪いって結論ありきで騒いでるから
生半可な知識で原因()を特定したつもりになってそれ以上調べないんだろうな
C++11のstd::atomicとC11のstdatomicを混同したり
gccとmsvcのifdef切り分けが読めなかったり プログラムが不正だったからコンパイラによってエラーがでたりでなかったりってことかね? トンチンカンな指摘してるのは団子だから、無視するに限る いくら団子でも簡単なハンドアセンブル位できるだろ？ 数行のアセンブラでバグ入り
明らかにアセンブラは苦手ですって感じなコード
アセンブラで組むヤツはバカって感じな言い訳してたな 6
4
バ
イ
ト
く
ら
い
気
に
す
ん
な そうだね
64バイトくらいでいちいち気にしてたらAMDユーザーはつとまらん いろんなgccでlockかかっていないとか変なこと言うより
ひとつのgccでSオプション付けたのの該当関数部分を貼ってほしいｗ 端から見た感想
プライドが無駄に高いのはわかった
しかしコード読めは無いわ
ちゃんと最初に実装の意図まで全部説明せえよ
お前が逆の立場で俺様のコード完璧だからコード読めと言われて素直に応じるのかと
普通にお前のコードバグってるだけじゃねって疑うだろ？ >>508
そう感じさせたなら申し訳ないです
実際そういう部分もあると思うので自戒しないとですね
ただ、いきなり
>>389
>>393
>>399
こういう対応されたらさすがにカチンときますよ
こちらのコードを実装の意図から丁寧説明する気にはさすがに……
最初から
「あなたのプログラムを検証したいが、○○という部分はどういうこと？」
「このプログラムの趣旨はどういう処理なのか？」
と聞かれたらそりゃこちらも喜んで説明しますよ どういう部分が疑わしいからこういうコードで検証することによって再現しないだろうかって説明するだけだと思うが
それすら難しいというのはそもそも自分だけが正しいという前提に立っちゃってる
端から見てると突っ込みに対して自分が正しいという立場を絶対に崩したくないようにしか見えない
だからコードを修正するというアプローチは取らない
客観的な妥当性よりもプライドを優先しているんだよね お勉強しましょうねーなんて言われて1から説明とかありえないだろ
特に相手の勘違いが初っ端からアホなレベルなら尚更
CとC++の勘違いだそ？拡張子すら見てない
プログラミング分かった気でいるだけの知ったか野郎に懇切丁寧に教える必要は皆無 >>511
間違ってることを間違ってるというだけでなぜここまで言われなければいけないのか
しかも下手すりゃこちら以上に相手がケンカ腰な場面なのに プログラム公表した段階で説明書きちゃんとしてればこんなややこしいことにはならなかったような
趣味の領域の検証だからしょうがないけど そもそもIntelでもAMDでもSEGVやらmismatch起こしてるのに
ぼくは間違ってない、CPUが全部バグってるんだというのは通らないと思う
AMDもIntelも間違ってる俺が正しいって言ってごらん >>515
あんた2ちゃんねるには向いてないからtwitterに帰った方がいい
ここは都合の悪い者をブロックすることもできない
今の段階でまだまだマシな方だ
それで耐性がない位だから長居すればもっとひどいことになるだろう
自信作のプログラムも2ちゃんねるでの一切の取り扱いを禁止します、とかにしておけばここで語られることもなくなるだろう あのさ、で、結局ぼくの考えた最強のmutexを再実装しなきゃいけない理由。とは？
flgも条件変数で構わない。(最悪これならvolatile intでいいや)
あれだけ大騒ぎされたのでccNUMAとしてCCXのそれぞれのL3が振る舞っていないのか、
私も疑ったくらいだがxchg mem,regがLOCK Assertionなしでも動くのは知っている。
おめでとう。xchg m, rはmを指す範囲でCoherentでした(いや知ってた)。
で、何がしたかったの？CPUのキャッシュがおかしい水準の議論がしたいのに、何このコード…
ぼくの考えた前提(採用はIntel Core Micro-architectureで動くもの)、ぼくの考えた仮説、…
「ワタシチョットmfense()ツカエル」
わかった、わかった。
でも、あなたのせいでとんでもない時間と電力を消費したかもしれないユーザーのことも考えてほしい
あなたが検証ではない目的で作っただけのプログラムは誰かに貢献したか？
…していない。無駄に時間取られた。あほか。私はメモリの設定を見なおして使える水準になった。
で、あなたが奪ったものは？
1日回すと電気代っていくら？200W*24h = 4.8kWh -> 30JPY*4.8 =144円！
試した人が100人いたら、1万４千円だよ！発展途上国に食品を400人に分け与えられる額だよ！
ばっちゃが言っていた。人の命はお金に替えられないって。
でも、400人分の命は5000兆円くらいにはなると思う。あなたはそれを奪ったんだ！ ID:zPTrTH910が>>497でID:vUhtUjpU0に勉強しろとレスしたのは>>495のレスに対してなので、まぁ、売り言葉に買い言葉。
ID:zPTrTH910が直接コードを読んでくれとレスしたのは>>451のクソコテに対してなので、それはそれで至って正論。
なので、そのままID:zPTrTH910は続けたまえw 2ch的にはここで俺はどう続ければいい？
5 0 0 0 兆 円 欲 し い
（あればIntelもAMDも買収できるなー）
てな感じすか？ まあここでレスバトルしてもしゃーない
ID:vUhtUjpU0 はもうSEGV起こる気がしないと、そこの設定を教えてもらえれば
ID:zPTrTH910 にはSEGV TESTでi7でも失敗している理由についてはどう推測しているのかとか むしろここ以外でレスバトルする場所もないしいいぞもっとやれって感じだわｗ >>524
それは本当に分からん
なんせ自分のIntelマシンでは丸一日とかでも大丈夫なので詳しく調べられない
（特に昨日その話聞いてから改めて今まで丸一日以上回してみてる）
Intelマシン(1)
マザー：DH67HD
CPU：i7-2600(定格)
FAN：リテールファン
メモリ：適当な余りパーツ DDR3-1333 4GB*4
SATA: 適当な余りHDD 250GB
Video：iGPU
電源：適当な余りパーツ
ケース: 適当な余りパーツ(FDDスロットとかあるレベルの)
OS：ubuntu17.04 ja(x86_64) 標準kernel & aptで最新upgrade
GCC: gcc version 6.3.0 20170406 (Ubuntu 6.3.0-12ubuntu2)
UEFI(BIOS): AAG10206-205
適当な余りパーツが多いのは申し訳ないが、起こらないよって話なのでこのぐらいで勘弁を
オプション: 8 2500000
ログの末尾のほう:
52995: 2017年 7月 10日 月曜日 23:21:03 JST: OK
Intelマシン(2)
マザー：DB75EN
CPU：i3-3220T(定格)
FAN：リテールファン
メモリ：W3U1600HQ DDR3-1600 8GBx2+4GBx2 たぶんCL11（もしかするとCL9で動いてるかも）
SSD: INTEL SSDSA2M040G2GC(40GB)
SATA: その他HDD計14台（PCIe1xにSATA-IFと、PCIe16xにN8103-150）
Video：iGPU
電源：FPS AU-400
ケース: MasterCase 5
OS：Ubuntu16.04 ja(x86_64) 4.4.0-79-generic #100-Ubuntu
GCC: gcc version gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
UEFI(BIOS)：AAG39650-400
オプション: 4 2500000
ログの末尾のほう:
39148: 2017年 7月 10日 月曜日 23:31:48 JST: OK
こちらのほうは3770K+Ubuntu16.04で起こったってのと条件は近めなので何か起こるかも？と思いましたが何も起こらず。
2コアなのと、そもそもサーバーとして実用してるやつなのでHDD無駄に多かったり、
同時に他にプロセスが動きまくってるので参考にはならないかもしれませんね。 そうしようと思うが、その前にマシン(1)をUbuntu16.04にしてみるわ そういやQVL合わせの検証結果あったっけ？
ぶっちゃけQVLしか信じてないけど >>521
むちゃくちゃだわ。
そんな屁理屈がとおるなら、ゲームどころかPC使うなって話だわ。
他人に言う前に、キミの資産は全部ユニセフに寄付したのかね？って次元の話。 これでJEDECプロファイルで問題出なかったらまじかーとなるので追試を走らせているのだが、
長時間ベンチマークを走らせる人達に対してはそれがどれだけ無意味になるか知ってもらいたい。
(BIOS落ちだったらまじかー)
Reliability (and Security) Issues of DRAM and NAND Flash Scaling
HPCA Memory Reliability Workshop March 13, 2016 CMU
https://people.inf.ethz.ch/omutlu/pub/onur-dram-and-flash-scaling-reliability-and-security_hpca16-memforum_talk.pdf
Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors
https://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf
英語嫌いな人向け超絶引用 (1個目の論文から)
> Most DRAM Modules Are Vulnerable
「ほとんどのメモリモジュールは脆弱である」…えっ…
code1a:
move X <- %RegisterA
move Y <- %RegisterB
Flush Cache Line [X] (clflush X)
Flush Cache Line [Y] (clflush Y)
Memory Fence (さらに念の為)
jump code1a
で、3社から合計129個のDDR3メモリを買いました。エラーが生じた率は…？
2GBの構成で100万回テストしました。
Haswell 22871回のビット反転
Ivy Bridge 20722回の…
Sandy Bridge 16117回の…
Piledriver 59回の…
Non-ECCの品質ってこんなもんです。短期的なベンチマーク重視ならもっとひどいかも？
(Piledriverの回路はコンサバで半分の速度だけれどもエラー少ないのね)
で、100万回？1GHzのCPU使っていたら何回かなんて、お前は何を言っているんだっていう…
1日の保証？(私は本当にひどいめにあったが)特にHaswellユーザーは問題なかったのかと。
そりゃLinux Kernel(.oの総量6GBの最小近くであっても)の持久走には耐えられないよね…
つまり、あれですよ、code1a:のコードですら間違えるって言われているのだから、ぼくの(略)の長時間とかないわーっていう >>534
問題の特定ができていないのに冗長かつ読みづらく何がしたいのかもよくわからなくて
しかも再現性のない(確率的)なコードをひけらかして何か楽しいの？自称作者さん。
なお、資本主義経済下においては絶対的貧困は引き上げられる(平準化する)という立場ではあるが、ふるさと納税ではなく寄付はしている。 >>536
よくみろ、別人だ。
はたからみてて、煽ってるだけで技術的議論になってない。
感情論に走るなら、技術者づらして偉そうに語るな。
ましてや、作者は走らせてくれとも、ここで取り上げてくれとも言ってない。
見るに見かねて登場したら、待ってましたとばかりに吊し上げくらってるだけだ。
ぼくのなんちゃらは、現時点でみんながそう。
誰もAMDの代弁なんて頼んでないし、たどり着けやしない。 Haswell/LGA2011v3+DDR4は本当にQVLの品買うべきだったと非常に後悔した。
何しろメインのパラメータ tCL,tRCD,tRP,tRAS,tRFC,TREFI,tWR,tWTR,tWTR_L,tRRD,tRRD_L,tRTP,tFAW,tWCL,tCKE,tCCD,tCCD_L,tCCD_WR,tCCD_WR_L,...あたり？
に、さらにチップごとのtIOL,tRTLを合わせろとかもう冗談だろーっていう、ね >>537
別人かどうかわからないのがややこしいのが2chに久々に来た感
私も最初はCCX間のCache Coherency疑ったりと散々悩んだけど、
まさかの古いBIOSがおかしい…となって、大騒ぎしている約一名と
分析能力あるのにBIOS更新しない約一名、便乗している自称なんとかさん数名のせいで話おかしくなってる？
って、がっくりきているっていう。もう、ね あと、最近のCPUはDDRのDQ/DQSの遅延差を学習するので(FPGAでDDRやったことある人はわかるかと)、
試行を変える際には電源断(PSU)からはじめないとですよ… やはり古いBIOSだと出るな…
...
48 2017/07/11-05:12:33
<built-in>: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
make[2]: *** [drivers/acpi/numa.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [drivers/acpi] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs....
mv: cannot stat 'core': No such file or directory DDR4自体が糞ってのもあるわな
いろいろとシビア過ぎるわ >>736
leapmotionはカスメ以外使い道無いかも
ソフトやドライバの更新も止まっている感じ
持ってるけど、微妙な性能だし、誤検出も多い
買うなら中古で十分かもね 発生確率を上げるためにわざわざUbuntu16.04のデフォルトインストール、アップデートなしを選択しなきゃならないのはどうかと
このバージョンのLinuxが認識しているトポロジー
http://www.gazo.cc/up/248543.png >>546
>>375？
もしそうなら参考にしたいので >>480のテンプレでHW構成と
デフォルトから変更したBIOS設定を教えていただけませんか >>535
Non-ECCならエラー率はそんなものだし、サーバーでECC使うのもそれが理由だからな。
エラー出るって言ってるやつがHynixとMicronばかりなのが気になる。
古いBIOSでSEGV出るのもメモリ互換性修正前のBIOSなら珍しくも何とも無い、Samsungはそんなでも無いみたいだけど。
現状ではBIOS Ver違うだけでtREFが560だったり600だったりサブタイミングが色々違って来るからな
一番の問題なのはメーカーによってAGESA1006のBIOSがまだ出てないという点だろうけど(サブタイミングがAUTOのみ) >>550
トレーニングの結果を反映してさらにコンサバティブな設定に変えたので昨日の試験とは設定違うが、参考になれば
M/B : ASRock A320M (BIOS 2.60)
CPU : AMD Ryzen 5 1600 Six-Core Processor 3200.000MHz, Microcode 0x8001126 (AGESA 1.0.0.6)
FAN : Wraith SPIRE
RAM : Crucial Technology Ballistix Sport 8GB DDR4-2400 UDIMM x2 (16-16-16-39)
古いBIOSだとこれしかいじれないから終わってる
tCL 16
tRCDRD 16
tRCDWR 16
tRP 16
tRAS 39
tRRD_S 5
tRRD_L 7
tFAW 28
tWTR_S 4
tWTR_L 10
tWR 19
Trcpage 340
TrdrdScL 5
TwrwrScL 5
tRFC 313
tRFC2 193
tRFC4 133
tCWL 14
tRTP 10
Trdwr 9
Twrrd 3
TwrwrSc 1
TwrwrSd 7
TwrwrDd 7
TrdrdSc 1
TrdrdSd 5
TrdrdDd 5
tCKE 6
CR 2T
とんでもなくコンサバティブな設定だが、0.2%の性能差求めてないのと、
このメモリ、Haswellで苦労しただめな子なので1日問題がなければいいやっていう >>552
おお詳しくありがとうございます
メモリのサブタイミングだけでコア部分の設定とか電圧とかは変更してない感じですかね？ >>551
1時間で発生させられないものは、メモリ問題の発生率を超えられていないので相手にしたくないのだけれども、
なぜに実行者の忍耐力試験としか思えない実証コードが出まわるのかさっぱりわからない
16スレッドで1日となると1GHzのCPUでは10^15のオーダーでサイクル回せるわけですから、もう、あのー…
このようにNon-ECCでRowHammer問題が起きる確率は1e-3ですから、
こんな世界で1e15オーダーの試験で問題提起したつもりになれる人には大丈夫ですか？と言いたくもなる >>554
すべて定格です。一度もオーバークロックなどさせていません。
繰り返しになりますが、このタイミングはDDR4-2400においてはかなりコンサバティブなので、
これで動かないか、これ以下のXMP Profileを持っているメモリは捨てたほうがよいと思います。。
あと、L3に16MBもあると、瞬間的なベンチマーク目的外ではDDR4-2133より速くても2%影響あるかどうか。
これは、Intelであっても同じ話ですが。 >>553
なぜこうなったかというと、
「Bulldozerのコアはモジュールに関係なく扱おう」
-> a33d331761bc5dd330499ca5ceceb67f0640a8e6
「お前のせいでゲームがかくかくするので、元の戦略に戻す(元のコードに戻すのではなく味付けした)」
-> 79a8b9aa388b0620cc1d525d7c0f0d9a8a85e08e
「おい、Zenの対応忘れてね？」←2017-02-05の出来事
-> 08b259631b5a1d912af4832847b5642f377d9101 >>558
AMDのCPUが使われなくなって何年も経っているから「おれが正しい！」コードが普通にコミットされていたっていう。
安定的に動くカーネルが提供されるまでにあと半年はかかるんじゃないかな。なのに大騒ぎに合わせてLinux 4.8.0をを使わざるを得ないつらさ
BKDG出てないから中の人かNDA結んでいる会社以外の個人レベルで勝手な議論をしても仕様でした落ちになりかねないわけで…何がしたいんだろうね？ メモリの信頼性云々はこれの事を言ってる模様
Row Hammer問題
プロセス微細化に伴い無視できなくなってきたデータ化け問題
(後藤の記事)
http://pc.watch.impress.co.jp/docs/column/kaigai/678795.html
Rowhammer問題私的まとめ
Google作成のRow Hammerテストツールの事が書いてある
http://blog.daionet.gr.jp/knok/2015/03/13/rowhammer/
テストツールは後でやってみよう
丁度この頃はPCパーツ殆ど買ってないから知らんかったわ >>564
ググったらSPDと値は同じようだけどどこか手動で変更した箇所あるのかな サムスンBダイ搭載の72bit幅モジュール、M391A1K43BB1が欲しいけど入手性が…… >>565
はい、古いBIOSでもいじれるものはSPDのものをそのまま採用しています。
>>552 に書いたように、DDR4-2400 (16-16-16-39)の例でサブパラメータの網羅を提供するのが目的でした
tRC>=tRAS+tRPの関係からtRPは55以上になります。一般的には足し算だけで十分なはずです。
もちろん、これは一例なので16-16-16-39でなければtCL,tRCD,tRP,tRASの値は変わってきます。
コンサバティブな設定と言いながらTwrwrScL 7としなかったのは失敗… >>567 >>565
また間違った…技術云々の前に自分の頭のネジが抜けとる orz
誤) tRC>=tRAS+tRPの関係からtRPは55以上になります。
正) tRC>=tRAS+tRPの関係からtRCは55以上になります。 >>559
いやまあメモリが悪いんだっていう話もそれはそれであると思うんで
その探究に文句をつけたり特に何か異論を挟むつもりは無いですね
ただ、メモリの信頼性のオーダーから考えて長時間のテストは無意味みたいな点については反論を。
まず参考に挙げてるメモリの信頼性に関する話は
再現のためメモリに対して作為的なアクセスパターンで行うとこんなにビットエラーが出ますっていう話で
あらゆるメモリアクセスが10^-3オーダーの確率でおかしくなるわけではないということ。
だったら非ECC環境ではとっくにあらゆるアプリが誤作動しまくりだし、
memtestなんてコンマ何秒で失敗するのが当たり前な世界になってないとおかしい。
それに加えて、キャッシュでメモリアクセスが隠蔽される効果も全く考えていない点。
ryzen_segv_testなんて高々KiBオーダーの領域しか使わないテストなんで、
それが秒数回程度プロセスが立ち上がろうがそんなものはほぼキャッシュの上の話。
なのでCPUのサイクル数のオーダーとメモリアクセス回数のオーダーを比較することは全く無意味な比較と思いますがどうでしょう？
もしそうじゃないなら何のためにキャッシュが存在しているんだっていう。
ちなみに僕のRYZEN環境ではryzen_segv_testをgccでコンパイルすれば分に何回レベルでsegfaultしますよ。
仮にそれがメモリの問題だとして、メモリの設定変えたらこの頻度がどれだけ変わるかは試してみたいですね。
（出先なので今は書いてないですが、必要があれば環境は後でまとめます） 横レスだがメモリクロック緩めるだけでエラー頻度は減るというのがここでの結果 >>570
RYZENとそれ以外のプロセッサで顕著にsegfaultする確率が異なる自己書き換えパターンがあるっぽいということですね まだメモリが原因とか言ってるアホがいるのか
さすがに電源はいなくなったか gccが稀に触ってしまう微妙なレースコンディションが有るよということではないの？
x86の仕様としてあるものをRyzenが正しく実装してないか、
gccのコード側でプロセッサにドキュメント外の動作を想定してるせいかは知らないが $ git clone https://github.com/hayamdk/ryzen_segv_test.git
$ cd ryzen_segv_test/
$ make
cc -O2 -Wall -c ryzen_segv_test.c -o ryzen_segv_test.o
cc -pthread -o ryzen_segv_test ryzen_segv_test.o
$ ./run.sh 8 2500000
...10分待った。まだ止めてないけど、segfault まだかなあ。
$ tail -f log.txt
...
483: 2017年 7月 11日 火曜日 13:02:44 JST: OK
PID:8269 CPU:6
478: 2017年 7月 11日 火曜日 13:02:44 JST: OK
PID:8274 CPU:1
476: 2017年 7月 11日 火曜日 13:02:44 JST: OK
PID:8279 CPU:5
478: 2017年 7月 11日 火曜日 13:02:44 JST: OK
PID:8284 CPU:4
> ちなみに僕のRYZEN環境ではryzen_segv_testをgccでコンパイルすれば分に何回レベルでsegfaultしますよ。
ほほう。大騒ぎ界隈で言われている所謂当たり石をお持ちなのですか！羨ましい
20分待ったけれども何も起きないや。忍耐なくてごめんね 簡単にメモリエラーが出るPCなら使い物にならんから捨ててしまえ
>>569ではないが、>>569は正論 >>575
gcc自体がビルド中にSEGVするよって話とはまた別に、
gccでビルドした結果のバイナリの動作時の話なのでそれは関係ないかと
しかもそのバイナリ自体もとても小さいくて全部アセンブリを見たって把握できる程度のものですし >>576
いやいやそれほどでもー
単に僕のマザボ（AB350M Pro4）のデフォルトのメモリ設定がクソなだけとか、
メモリが腐ってるだけかもしれないじゃないですかー
あなたの理論によれば >>572
それでメモリが原因と決めつけちゃうのが素人
このスレに非常に多い >>579
反例を挙げるのに10倍の時間では足りないのですか？当たり石をお持ちなんて本当に羨ましい笑 >>581
いや、どうでしょう。
僕も何十台もRYZEN機を触ったわけではないので個体によって幅がどのぐらいあるのか知らないので。
あなたのはカーネルビルドでもわりと出にくい個体のように見受けられるので。
ほぼ影響がないレベルの当たり（外れ？）が存在する可能性も否定できないです。
ただ、一つ言えるなら6コアなら6 2500000のほうがいいかもなーってのと、
一応僕が起こることを確認してるのはUbuntu17.04とその付属gccです。 これだけ時間と人をかけて、何の切り分けも出来てないっていう
素人は何人集まっても素人 >>582
>>569 の自己矛盾っぷりはどうしたらよいものか。しばらく眺めていようっと笑
> あなたのはカーネルビルドでもわりと出にくい個体のように見受けられるので。
> ほぼ影響がないレベルの当たり（外れ？）が存在する可能性も否定できないです。
いやだから、昨晩わざと古いBIOSにして引っかかってるしな… >>541
で、メモリの設定を見なおしたら落ちないんだけれど、どうしたらいいのかなー
購入前の古いBIOSにすると私のRyzenも当たり石に進化して詫び石もらえるの？笑
それを世間では当たり屋って呼ぶんだよ >>584
こちらは詫び石だとか一言も言ってもいないし交換にも出していないし、
そもそも交換しましょうか？って言ってるのはAMDなのでそれをこちらに言われても全くお門違いもいいところ
詫び石欲しいなら古いBIOSで報告して勝手にやれば？としか言いようがない 眺めてるとたまたま不良品を摑まされた人が
初期不良で交換せずに騒いでる様に見える 切り分けできるわけ無いでしょう。
ずれることは確定と言いながら、ソースをお願いしたら無視する人とか、自分の中だけで確定していることを、事実だと思っている人ばかりですから。 じゃあ交換してもらえばいいじゃん…他人に迷惑かけるなよ 公開されてるってだけのコードを勝手に実行しといて迷惑かけられたと主張するのか…… 個人的にはよく確認もしないで誤解に基づき
＞何が起きたかって「私は並列プログラミングできません」と書かれたコードを世界中に晒したっていう
とかいきなり言われちゃうことが迷惑だったんですけど
それに関してのフォローは特には無かったですよね
まあそれは別にもういいんですが、
技術的な話じゃなくて迷惑がどうこうという話を持ち出されると…… だって私はあなたの指導教員ではないので。細かいフォローをする必要などありませんし
まあ、がんばってください。携帯電話も併用して、ね。 人に対して謂れのない理由で非礼を働いておいて、
そのフォローはないのかと問われて
＞あなたの指導教員ではないので。細かいフォローをする必要などありません
だって
大爆笑だね >>592
とりあえず ID:nnG1B4ZV0 については勝利宣言の構えに入ってるみたいだし、
後はスルーしておけばいいんじゃないかな すみません
技術的な話はまだしも、それ以外むやみやたらに食いつかないようにします 3770KでSEGV出たと言ったな？
どんなコードだった？
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/3rd-gen-core-desktop-specification-update.pdf#page22
BV92. The Processor May Not Properly Execute Code Modified Using A Floating-Point Store
※ただし発生条件を浮動小数点数のストアの利用に限定してる時点で、それ以外の条件では発生しないことを検証済みと思われ
さて、飽くまで本老害としては少なくともgccでのデータ化けは自己書き換えによるキャッシュ不整合でもなければメインメモリの書き込み不良とも全く関係ないという考えだが、RowHammer問題は正しくリフレッシュされないとCPUコア上のキャッシュやTLBでも起こりうると思ってる
Ryzenの命令キャッシュの構成を確認してみよう。
なぜずれるのがちょうど64バイトなのか？
もちろんcc1の問題について俺が怪しいと睨んでるのは命令フロントエンドであって、命令の書き換えによって起こるわけではないので別問題として考えるべきですな >>596
キャッシュはSRAMなんだからリフレッシュとか関係ないのでは？ 自己書き換えするとシリアライズ時にキャッシュだけでなくメインメモリも書き換えるので、メモリの当該領域が破損してるとSEGVは理屈上あると思います
メインメモリから動的に関数ポインタ値とってくる汎用レジスタ相対じゃなくてRIP＋オフセットによるジャンプでアドレスが化けるcc1の事象はコア/命令キャッシュ側の異常でしか起こりえないのですよ >>597 その認識で正しいです。
この、団子とか呼ばれている人、大丈夫？ >>597
省電力制御あるじゃんなんって言ったっけ？ みたらしと三色、2本づつよろしく
ポインタがズレるってよく考えたらあり得るのか?
そこだけでズレるってんなら条件揃えれば出る筈ではあるけど、起こらないんっしょ?
トポロジ認識の件もだけどどうもクッサいよな 分析気取りなのはEIRAKUってやつだろ？
検証環境は最初と変わらずゴミなやつでしょ
メモリぐらい変えて検証したらどうだ？ このスレまだ続いてたのか
最初は電源ユニットが疑われてたけど、今はメインメモリ？ 別に、1ビット反転とか、サーバーでもたまに起こってるだろう。
ECCのログで案外見かけるし。
さくらインターネットで借りた商用VPSでも落ちるときは落ちる。
15ヶ月間動かしっぱなしの自作ゲームサーバーがこの前何故か落ちてたが、
ログ見るとあり得ないポインタエラーで落ちてたし。 >>607
EIRAKU氏の昨日付の記事読むといいよ。
今日、もしくは明日、もっと先かもしれないけど、続きがどうなるのかが気になる内容。
http://www.e-hdk.com/diary/d201707b.html#10 特定のアドレス関係なしにどこのアドレスでも必ず-64バイトのオフセットがかかるのはメモリの不具合ではありえないよ >>609
ビット反転されてるんなら+64のこともありうるよな
このアドレス通りなら64バイト「引き算」なんだよなぁ
AMD-64 報告いろいろ見る限りCPUのエラーにしか見えんなぁ
AMDだんまり続けてるけどマイクロコードで対応できるのか、全数交換などに発展するのか
EPYCはどうなのか、とにかく今は情報収集しかない >>607
この人は、SOC電圧を意味もわからず試しに+0.2V上げてみた、とかやってる位だから、どれくらいハードの組合せやハード設定に熟知してるのか不安な所がある ずれる理論、結局なんの説明にもなっていない
64バイトと主張されているものもあるが、
私の手元で拾ったものにはそうでないものが多く含まれていてなんだかなあ
http://www.e-hdk.com/diary/d201707b.html
ずれる理論でも結局64バイト固定になっていないし、64バイト境界でもない。
しっかし、よくまあ6時間半で16回もダンプ吐かせられるものだと
BIOSは更新していないんでしょ？彼は何と戦っているんだ…
別に私はメモリが問題の全てだと言いたいわけではなくて、
とりあえず、BIOS更新するとサブパラメータがトレーニングされている様子が見て取れて、
落ちる落ちないで言ったら、落ちなくなっていくよ、なにこれっていう話をしているだけ。
差があることは数日かけて確認したし、自称なんちゃらのプログラムは役に立たなかった。
メモリが信用できないレベルのBIOS、マイクロコードで何を語ろうとも、何の意味もない
だが、Ryzenに問題がないとも思っていない。DDR4が扱い難しいのはそりゃそうだし、
XMPがIntel向きになってしまっているのも実際そうなんだけれども、
いくらなんでも設定緩くしなきゃならない限度にも程があるでしょ…っていう >>616
歯切れの悪い事を言っていますが、ずばり原因はどこにあるのでしょうか。 確かに昔のBIOS(購入時前。笑)にすれば、6時間半で16回はダンプ取れるか…なんだか嬉しくないなそれ… 取り敢えずBIOS更新が先だな
あとCMOSクリアからデフォロードで初期化後、念の為システムを入れ直してクリーンにセットしないと
あの調子じゃ何処がおかしいかなんてわからんだろ >>618
原因なあ。OpCacheが本当に異常なケースをうまくハンドルできているのか疑問はある
…のだけれど、OpCacheを切っても性能ほとんど下がらないからどうでもよかったりするんだよね
あと、OpCacheの挙動自体はMicrocodeでかなりの部分が更新できるので
致命的だと思っていたら特殊命令系の複数uop吐く命令で積極的Flushで対応するだけ。
ここまで長引かせる必要性は感じられないんだよなあ
まあ、少なくともメモリ周りには問題ありそうだよね。いきなりDDR4で投入はきつすぎたのでは？
サーバー用途なら大量購入はECC,選別品に落ち着くだろうから先のことは心配ないと思うが、
今のステッピングなあ。QVLですら怪しいんじゃないかっていうくらいメモリ周りが不安定な感じ まあ、メモリ周りおかしいままで変な命令列食わせるんだったら、
DDR4-2133でJEDECなコンサバティブな設定で、まずは確率的な話から足を洗うべきだろう。
その環境で、自由な命令列を片っ端から生成して試せばいい
test+conditional jumpのfuseが怪しいんじゃね？などの
仮説自体は今までのダンプから立っているわけで、総当り的にやるという話ではなく、ね >>622
メモリ回りかぁ。メインメモリ、キャッシュメモリ、メモリコントローラあたり？
B2 ステップではこの問題は解消しない(対応リストに無い)んだっけか >>624
メモリコントローラだろうな。元々市中に出回っているDDR4の品質悪すぎっていうのもある。
安定志向ならAGESA 1.0.0.6以降が標準搭載になって、明示的にステッピング変わるまで待ったほうがよいのでは？
DDR4-2400表記のメモリをDDR4-2133として使う、みたいな対応も当面はありうるかも。
実は先に貼り付けたサブパラメータはLGA2011v3に繋いでみたら全然違うじゃねーか、あほかー
ってことで移植したものなんだよね。なんじゃそりゃ？って感じだが、現在のBIOSのXMP対応状況ってこんな程度 AMDもさすがに馬鹿じゃないだろうから…というのは
このRyzenのCCXを使いまわさなければならないほどに開発資源がない状況(おかげでRyzenではECCメモリが使えたり…)
だから、どこかにAMDが試験に用いていたリファレンスメモリがあるはずなのだが、何その聖杯戦争 インテルもDDR4使ってるのに、市場の品質云々とは。 >>624
メモコンの改善も含まれてるっぽいよ。不安定性の発現でしか無いと
いうのが正しければ、他の全ての環境同様0にはならないだろうけど、
減る可能性は高いんじゃない？ >>628
そもそもDRAM作っている会社なんて数社、まともな最先端のファブは以下略。
なのに子会社だ、関連会社だとブランド名を変えてへんてこメモリだらけなのはおかしいと思わないか？
選別がIntelとの相性、で相性のよくなるパラメータがXMP。AMDはここ数年あまり相手にされてない… BIOSの更新はしない、メモリは変えない、推奨メモリ使った環境は無し
なんだこれ >>630
その線でいくと、世のメモリは（SEGV起こすような）不良品のが多いってことになるだろ？
んで、インテルなら不良品でも動きますってか。
なぜなら、インテルにあわせて不良品を調整して出荷するから？
それ、もう規格じゃないから。 誰かほかに当たり個体持ってる人がEIRAKU氏あたりにリモートログイン環境貸し出してみたらいい予感
つかこの人の筑波大時代の論文がガチすぎる NVIDIAの時みたく、AMD Memory Profileでも作ったらいいんじゃない？苦笑
さっき書いたように、XMPもまだきちんと読み取ってくれていない感のあるBIOSっていう >>636
ならAMDの問題だろうに。
メモリメーカーが文句言われる筋合いじゃない。
それじゃ、ただのクレーマーだ。 EIRAKU氏に不満あるならTL炎上させたら良いんじゃないですかね
ハードの構成見直しやBIOSアップデートで完治する問題にいちいちいちゃもんつけるモンクレだと >>640
だから、現状のBIOSのメモリ対応状況はだめだーと言っているのだ
市中のメモリの品質が悪いのは事実だよ。
XMP通りに動くとは限らない。Haswellで苦労したのはそれ… ていうか心配なら使わないのか一番しゃね？
>>642
あまり相手しないほうがいい 煽って喜んでるだけだし >>642
んで？インテルでは問題ならない品質だけども、AMDでは問題になる粗悪品ばかりだと言いたいわけかな？
どうも、インテルにあわせたメモリは品質が低い、と言いたいのか？と勘ぐりたくなるけども。 >>643
うむー。相手にしないほうが良さそうだね。忠告ありがとう ま、「互換品」なんてそんなもん、という現状の評価ではあるのか。
それを受け入れた上で戦って勝たなければ状況は改善しない。 XMPってIntelの提唱してる拡張規格だしねぇ
AMDでは不具合起こることもありえるんやろね… >>643
喜んでんじゃなくて、腹立たしいの。
不確定な要素をどんどん広げてって、混乱させてるだけだろ？
メモリが問題かも、には文句はないよ、そうかもしれないし、そうじゃないかもしれない。
けど、メモリの品質がSEGV引き起こしてるってのはどうかね？納得できるかね？？ 腹立ってるならさっさと売り飛ばしたら？
新設計の初物とか不確定要素しかないんだし バグ個体って売れるのかしら？
次使う人のためにAMDにおかわりもらって安定動作確認してから売った方が良くない？
中古だと交換保障してくれなさそうだし とりあえずjmp時にポインタズレるのはメモリの問題じゃない >>653
ここでの検証が楽しみだな
これでダメだということなら国内殆どの所でEPYC早期導入は見合わせるはず 540 名前：,,・´∀｀・,,）っ-○○○[sage] 投稿日：2016/10/12(水) 21:45:48.40 ID:ijYX/87D [5/21]
Zenが高くないと買えない自分を正当化できないもんな
大丈夫だよ、8コア最上位でも3万円切るから
お前みたいな無職大貧民には大金だけどな
545 名前：,,・´∀｀・,,）っ-○○○[sage] 投稿日：2016/10/12(水) 22:03:09.78 ID:ijYX/87D [8/21]
最上位で3万円切るって宣言した俺の発言ログとっとけよ
148 名前：,,・´∀｀・,,）っ-○○○[] 投稿日：2016/11/14(月) 20:21:39.52 ID:0Q4rwlJ0 [5/9]
まあ、本当にBroadwellの性能超えたら32コアOpteronデュアル機組んでAMDを応援してやるよ
351 名前：,,・´∀｀・,,）っ-○○○[sage] 投稿日：2017/01/10(火) 21:24:59.71 ID:deU 9WJv [4/7]
リアル春にはAMD冬の時代になるから今のうちに春を楽しんで置きたまえ 揚げ足取りではないのだが
HaswellはDDR3では？
>>552でHaswellで使ってたメモリとあるが、Broadwell-E辺りと勘違いしてない？ >>648
それを一つ一つあたるのが検証ってもんでは？ 付き合いたい人が
やれば良い。FUD目的じゃないんだよね？ sat周辺が苦し紛れに喚いてるようにしか見えないわ
だいたい特定されてるけどな そんなわけで、BIOS 2.00では >>541 となったが、DDR4-2133で >>567 設定で
1 2017/07/11-15:41:38
2 2017/07/11-15:44:22
...
71 2017/07/11-18:54:25
72 2017/07/11-18:57:12
と3時間正常。ずれる理論の環境だったら、8個はダンプ取れてるな… FUD目的なわけないでしょうが。どう見たらそうなるのかとー
古いBIOS,メモリの設定見直し、…で、無駄に電力使って検証しているだけよ？ まてまて、>>642氏は「市中のメモリの品質が悪い」という事実を指摘しただけで、それが問題の原因とは言っていないよな Haswell-E(5960Xとか)はDDR4だったのか
調べたら確かにそうだった
興味なかったから知らんかった
失礼した
メモリの人の「Haswell」は「Haswell-E」と読み替えるわ >>651
現物交換だよ
つかEPYCは許したるからThreadripperいけよな
2020年まではインテルと離れてみろ 今のところ言えるのは、
BIOS2.00...
AGESA1.0.0.4a,メモリ周りでいじれるのがtCL,tRCDRD,tRCDWR,tRP,tRASだけ。ではDDR4-2400 XMP Profileでは >>541
BIOS2.60...AGESA1.0.0.6 メモリ周りでいじれるのが >>552 に増加でコンサバティブな設定で
DDR4-2400 >>473 (実際には480回くらいで止めた)
現在試行中 DDR-2133 >>663
と、騒いでいる約一名の土俵で落ちない環境作れるんだけど、ああ、エラッタ説に対するFUDにはなるかこれ… FUD云々はエラッタ説をゴリ押ししてる人に言ってるんで、広い目で
見て検証しようとしている人はお疲れさまだよ。 ふむ、メインメモリは無関係でFAかな？
残る原因は何なんだろうか 団子予言でCPUが原因ではないから、残るはコードかメモリかBIOSか… >>674
団子氏はメモリは関係ないとも言ってたからソフトかbiosかな 何が言いたいかって、古いBIOSだといじれないしXMPきちんと読んでくれないので結果、
大騒ぎされているように落ちる >>541 が、
BIOS更新とAGESA1.0.0.6で少しマシになって、
あとは手書きでパラメータ修正したら現在合計27時間落ちてない
という客観的な事実を示したわけです。
変な分析やる前に先にこれ確認したら？ってだけ。まあ落ちなかったら分析も何もないか。笑 あとは現状、BIOS2.60でもXMP全て読み込んでくれているように見えないので対応に期待したい
BIOSが更新されていって対応メモリ表が増えていけば手作業なんて必要なくなるんじゃね？ってだけ。 初期の、しかもいきなりDDR4なんてこんなもんでしょ？
枯れてきたなーって思われる前に買うなら、このくらい自分でいじる覚悟があっての自作じゃないの 俺みたいにメモリSPDから超ユルユルまで試してもエラーでるのはCPUが不良って事なんかな
てか新BIOSまだかよasrock >>681
カーネルビルドも例のスクリプトも両方ダメ
素のUbunruじゃなくてWin10のWSLだけど 将来ubuntu入れたら毎月のカーネルリビルドの時間短縮できるなと思って8コア選んだんだけどガッカリだなぁ・・・ WindowsならRyzen Timing Checkerでタイミング指定が有効になっているか確認するといいですよ
できればスクリーンショットほしい… はじめからおま環だときめつけて叩いてるから支離滅裂になるんだよ 世界にPC用DRAMメーカーなんて片手で数えるほどしか無いんだし、
どこかのメーカーのメモリが仕様通り動かなかったとして、
BIOS等でそれに対応するワークアラウンドをいれるのはCPUメーカーの責任だといえる
もしくはRyzenのアンコア部の設計・実装等の影響で
メモリが仕様通り動かない場合があるとかの可能性はある >>685
いつもタイミング設定後にすぐBIOS入ってシャットダウンしてるから毎度反映された状態で試してるよ
組んで初めての時に3200で動かそうとしててわかったんだけど
BIOSで設定しても再起動後はちゃんと反映されてないようだったからね
今はBIOSで2133のSPD指定した状態で他に何もしてないからスクショ上げる意味ないよｗ
テストも部屋暑くてやめてるしね
スクショ上げるのは新BIOS出てテスト開始してからかな >>689
TaichiのBIOSだけど多分BootTrainingてのが関係してるような気がする >>691
BootTrainingは起動時にその設定で起動できる水準かタイミング調整と検証を行う機能です。
3200では無理と判断されてデグレードされたのかと…。この辺の余裕がなさすぎなのは次のステッピング待ちかな >>692
ちゃんと反映されてなかったというのは3200で動いてないというのでなくて
3200ではクロックは反映されて起動できてるけどサブタイミングがしっかり合わせられてない感じで
電源断からスタートするとしっかりサブタイミングが調整されるようだった
今はサブタイミング指定できるBIOSになったからいきなり3200とか3333でサブタイミングも指定して
一発で狙った設定で起動はできるけど一応指定できないところの事も考えてシャットダウンからやってる >>552の設定を自分の環境と見比べて感じたのは特に次の2点が大きく異なる事
(1)tRFC、tRFC2、tRFC4がかなり短い(設定可能な最小値？)
(2)tRCPAGEに0以外の値(340)を設定している
(1)はRowHammer問題対策の一手段として使われる「DRAMリフレッシュ頻度を増やす」ためと思われる
(2)は手持ちのMSI、BIOSTARのM/Bでは「0」しか見た事がなく手動で設定した事もない
これ絡みでAMDが特許を取っているよう(後述)なのでIntelにはないパラメータの可能性があり、M/Bメーカーもよく分からんから0にしとけ、とかやってる可能性があるかもしれない
どういう働きをするパラメータなのかも分からんが、これが0なのは本当はマズイのかも
AMDの特許
(tRCPAGEで日本語限定でググるとこの1ページしか出てこない)
https://astamuse.com/ja/published/JP/No/2016536666 >>687
？？？「うちのCPUはアンコア部の設計・実装の都合でメモリが仕様通り動かなかったけど全部モジュール側で対応させたった」 >>695
tRFCがかなり短いとのことですが、極端に小さくすると重たいリフレッシュ動作に時間を取られて周波数を上げられなくなります。
tRCPAGEはAPUのみに関係するパラメータだったはずなのですが…残念ながらBKDGが出ていないので適用対象かわからないです。 CPU: Ryzen7 1700
MB: BIOSTAR X370GTN X37AK623.BSS
Mem: G.Skill F4-2400C16D-16GFX
Cooler: Wraith Spire
SSD: WDS240G1G0B-00RC30
Graphic: Sapphire Radeon HD7850
PSU: Seasonic SS-860XP2S
OS: Ubuntu 17.04
kernel: 4.10.0-26-generic
gcc: Ubuntu 6.3.0-12ubuntu2
ASLR有効（スタックヒープlibアドレスは実行毎に異。PIEではないっぽい）、SMT有効
CMOSクリア後メモリタイミングを>>552にしてmesa (58d337941e...) ビルドテスト
SSD上のファイルシステムで./configure --with-gallium-drivers=r600 後 make -j16
自分の環境だとダメですね XMP読みAutoと特に変わった感じはしないかな？（まああくまで感覚ですが）
[ 1403.367382] bash[31618]: segfault at 25 ip 0000000000435d7e sp 00007ffce5bb0340 error 6 in bash[400000+100000]
[ 2200.630820] traps: bash[18963] trap invalid opcode ip:435dc9 sp:7fffb6f0ece0 error:0
[ 2200.630825] in bash[400000+100000]
1800X+Taichi（QVLに当メモリの記載あり）環境もあるのでそちらでOS再インストール後追試してみます >>697
tRFC関係は性能と信頼性のどちらを取るか、という事にもなるわけか
個人的にはRowHammer問題対策なら周波数上げられなくても止むを得ないと思う
(データ化けるよりはちょっと遅い方がまだマシ)
tRCPAGEはFM2のAGESAのドキュメントも見つけたんだけど、203ページ辺りにそれらしい事は書いてある
ただRyzenでどうかはこの資料では分からないね
近々自分で試してみる
https://support.amd.com/TechDocs/44065_Arch2008.pdf なんだか自分だけ解決してしまって申し訳ないです
>>699
tRFCには仕様上の下限があるので、最近のDDR4-2400で16GBなモジュールなら、
tRFC1>550,tRFC2>350,tRFC3>260(単位はns)を守らないといけないので目安にしてください。
Row Hammer対策はtREFIなんじゃないかな…
私のはtRFC1 260.0ns指定(313clk)がSPDにあったのでそれを参考にしましたが、
最近の微細化が進んでいるモジュールでは上の値を採用したほうがよさそうですね。 「ポインタがずれる」というのは団子の劣化コピーです
元の文章にはそんな事は書かれていません うぎゃ。 >>698 さんが、まさに >>770 制約破ってしまっている… orz 総当たりしたときの記録にtRCPAGEを340に近いところだと150hで試して×マーク付けてあるな
俺環だとなにも変化なかったということだった >>700
参考ページ読み直したらRowHammer問題対策はtREFIでした
勘違いスマソ
しかしMSIとBIOSTARにはtREFIが無い
それでtRFCで代替するしかないと勘違いしたのかもしれない
>>703
情報ありがとう
やはりAPU用の設定なのだろうか 交換対応で届いたブツでテストしてるけど、今のところ問題は再現してない。
今24時間だから、もう24時間くらい耐えてくれれば、うちでは解決ってことでいいのかも メモリ設定そこまで細かくやらないといかんかったのか >>707
もともとかなり強引な規格だしな
直接外部から駆動するって点ではHDDで言うとST-506位まで遡るくらいだし >>705
自己レス
Ryzenの場合tREFIと似た(同じ？)パラメータtREFを内部的には持っていて、自動的に設定される
Ryzen Timing Checkerで確認できる
逆に言うと現状手動で設定はできない
ただRowHammer問題対策を加味した値になっている模様
(例えば2933MHzの場合で約7.8μs) >>709
訂正(何度もすいません)
tREFIとtREFは同じパラメータで単位が違うだけ
(tREFIはns、tREFはサイクル)
tREFIはDDR4の規格で7800ns(7.8μs)と決められている
なのでRyzenの場合現状7800ns固定となる
7800nsにRowHammer問題対策が加味されているかは分からない
RowHammerテストツールでエラーが出るようなメモリは別な機種にするしかないかもしれない 一昨日ぐらいにi7 3770KでSEGVした人がまたSEGVしたっていってCoreDumpファイルとログを出してるね >>710
調べてみた
されてないようだ、7800は標準値で触れないんじゃどうしようもない
他の値で何とか出来ねぇかな >>552の設定で動かしてみたけど
ryzen_segv_testが相変わらず1分に数回ぐらいの頻度でNGになるなぁ
tRCだけ>>552になかったのでAUTO
M/B : ASRock AB350M (BIOS 2.50)
CPU : AMD Ryzen 7 1700 Eight-Core Processor 3000.000MHz, Microcode 0x8001126 (AGESA 1.0.0.6)
FAN : リテール
RAM : W4U2666BMT-8G (2枚) 2400動作(Manual1200MHz設定)
OS : Ubuntu17.04 ja x86_64
Kernel : Linux ryzen 4.10.0-26-generic #30-Ubuntu
gcc : gcc version 6.3.0 20170406 (Ubuntu 6.3.0-12ubuntu2)
./run.sh 8 2500000
Windowsとのデュアルブートなんで、Ryzen Timing Checkerでも確認したほうがいいすかね？
カーネルビルドはもともと数時間に一回ぐらいしか出なかったので確認は時間かかるかも すんません、
M/B : ASRock AB350M Pro4
でした >>712
やはり加味されてなかったのか
残念
>>563で挙げた参考ページには
tREFIとtREFIx9, tRFCだけでなくtWRも関係してくるわけか・・・
という記載(昔この板にあったmemtestスレの転載)がある
Ryzenでいじれるパラメータが現状tRFCとtWRだけなので、やるならこれで出来る範囲でいじってみる事になる
範囲が比較的狭そうなので効果は薄いかもしれないが パフォーマンスイベントのログも拾ったほうがいいかもね >>654
団子はな、買わない言い訳にすがりついてんだよ 8コアを8個欲しいとは思わないだけだよ
Skylakeの32コアはGoogle用の特注版しかなさそだ >>639
AMD Memory Profileずばりそのものが（DDR3で）あったんだよなぁ…
DDR4でもやってほしいけど、マザーの設定項目にないあたりやらないんかね
それともRyzenヒットしたからそのうちやる可能性はあるかな？ >>713
ryzen_segv_test なんて >>399 だから時間の無駄だよ >>721
なにがどう違うの？
8車線道路だと思ったら東西南北各方向に2車線でしたとかなんの冗談だ？ 言い訳が自分がPhenom2馬鹿にしてたのはね返ってんぞ >>723
デュアルepycで構わんよ。
クダグダ言うというと言う事は
罰ゲームとして尚の事ぴったりだな。
ホラsegv検証の尻馬に乗っかって盛大にdisれるよ。 >>723
LGA2011の複線リングがSky-Xでは１車線メッシュに置き変わってて全然笑えないぞ
1スレッド帯域がRyzen以下とか…
http://n.mynv.jp/articles/2017/07/10/corex/images/g035l.jpg >>722
その疑似コード通りだったらあらゆる環境で平均して同じ頻度で失敗になるはずだけど、
あなたのPCだと少なくとも20分は大丈夫なんですよね
何が違うのか不思議だな〜 >>728
そりゃ、実際にはとんでもない量のメモリアクセスはあるので。
ただ、 https://twitter.com/homuh0mu/status/884814116442984448 って、ね…
もしかしてIntelもずれるのかな？笑 >>731
ひとまずそのダンプではずれてるとは言えないでしょう
3770Kにエラッタが存在する可能性、メモリがおかしい可能性、どれも否定はできないです。
RYZENの場合は書き換えた関数の中ではなくthread1でSEGVして、
かつそのときのripがメモリの途中を指していているから明らかにズレが生じてるんですよ。
確かに書き換えた関数の中でSEGVしてるなら同期の問題かも？と疑う余地もありますが、
thread1自体は書き換え不可な至って普通なコード領域なので常にキャッシュに乗ってるはずで、
このコード特有のメモリどうのこうのの影響は無いはずですね。 tREFIは基本7.8(単位はus)ですが、実際のリフレッシュ間隔は温度によって変わります。
冷却した状態で電源を落とした直後に持ち運ぶと読み出せてしまう原理と同じで、
DRAMは一種のコンデンサですから、電荷が逃げ出してしまう時間が温度依存なのです。
また、tRASは32..tREFI*9の範囲でなければなりません。 >>732 >>576 となった私はどうしたらいいの…gcc 5.4.0ではだめなのかな？ あと、相互にコード書き換えするプログラムなんてめったにないわけで、何と戦っているの？感
昔はページテーブル書き換えですらIPI使ったことがあったくらい、
現実の実装はもっと強力に同期するし、まずはプログラムに問題がないことを証明していただき、
これが何と戦っていて、実際にそれがよく使われる何かで問題が起きることを説明していただかないと。笑 プログラムにバグが無いことの証拠を明確に示せ
悪魔の証明すね 他にも、書き換えた情報はDRAMに書き戻されずにL3で都合よく交換されたりしませんよ…？ >>736
＞まずはプログラムに問題がないことを証明していただき
AMDやIntelのマニュアルにこうやれと書いてあることを素直に実装しただけなので、
むしろそれでは不備がある（お前がマニュアルで見落としている部分がある等）点があれば指摘していただければこちらもとても助かります。
プログラムが完全であることを証明することは難しくても、不完全であることの証明は一点でも不備があることを指摘すればいいだけですから。
＞現実の実装はもっと強力に同期するし
それについて是非詳しくお願いします
ぜひ強力な同期とやらを試してみたいと思います >>737
gcc5.4.0でコンパイルすることは作者にも可能なのだからなぜ問題なかったのか、
コンパイラによって結果が変わるようなコードなのであれば書き方が悪いだけなので
それを検証することは可能ｰ>悪魔の証明ではないですよ？ そんなわけで、今日もカーネルビルド。defconfigだと早いなー
200回行ったら止めて、DRAMのパラメータ書きますね。
1 2017/07/12-06:40:30
2 2017/07/12-06:42:14
...
178 2017/07/12-11:47:51
179 2017/07/12-11:49:36 >>740
ハードの不具合を追っかけてるんでコンパイラ変えて結果が変わることは普通でしょうに
そもそもALSRの有無で結果が変わるようなコードは書き方が悪いともいえるので、
じゃあそのことをもってgccも問題があるプログラムといえるのかと >>743
コンパイラ依存のコードで検証できます！って言われるくらいなら全部ハンドアセンブリングしろよっていう 別に全部である必要はない
コンパイラ依存部分だけで十分
てことで、>>744 よろしく！ コンパイラ依存というか、
ある特定の命令やデータの並びがたまたまクリティカルにヒットするという感じなので、
変数を一つ加えたりしただけでも発生確率はがくんと変わる
再現性を高めるならもはやUbuntu17.04のgcc6.3でビルドしたバイナリを配布するレベルになってしまう >>745 しらねーよ！作者が環境指定するか自分で検証しろよっていうｗ
>>746 もしUbuntu17.04のgcc6.3依存で落ちてたら笑えねーぞ
大騒ぎ一派は引くに引けなくなってるのかねえ
このまま何一つErratum見つけられなかったら損害賠償請求ものだものな >>741
...
199 2017/07/12-12:24:36
200 2017/07/12-12:26:22
BIOS行ってきまーす >>747
だからコンパイラが腐ってていくらおかしなコード出してたって、
それはダンプで落ちた理由が分かるまっとうなSEGVで落ちるだけでしょうと M/B : ASRock A320M (BIOS 2.60)
CPU : AMD Ryzen 5 1600 Six-Core Processor 3200.000MHz, Microcode 0x8001126 (AGESA 1.0.0.6)
FAN : Wraith SPIRE
RAM : Crucial Technology Ballistix Sport 8GB DDR4-2400 UDIMM x2 (16-16-16-39) @ DDR4-2400 1.2V
tCL 16
tRCDRD 16
tRCDWR 16
tRP 16
tRAS 39
tRC 55
tRRD_S 4
tRRD_L 6
tFAW 28
tWTR_S 3
tWTR_L 9
tWR 19
Trcpage 383
TrdrdScL 3
TwrwrScL 3
tRFC 660
tRFC2 420
tRFC4 312
tCWL 12
tRTP 10
Trdwr 9
Twrrd 1
TwrwrSc 1
TwrwrSd 6
TwrwrDd 6
TrdrdSc 1
TrdrdSd 4
TrdrdDd 4
tCKE 6
CR 2T >>750
それおれの責任じゃないからｗ Ubuntuなら
USBにISO焼いてTry Ubuntuで試せばいいだけでしょ。30分あればできる話 まあさすがにUbuntu16.04も今夜試しますって
昨晩はRowHammerを念のため回してたんでできなかったんですよ >>949
いやそれはAPIが悪いんじゃなくてドライバが腐ってるだけの話では？ はい、6指定でテストしましたよ。
$ tail log.txt
...
440: 2017年 7月 12日 水曜日 12:41:58 JST: OK
PID:15649 CPU:7
437: 2017年 7月 12日 水曜日 12:41:58 JST: OK
PID:15654 CPU:7 >>754
ドライバ出してるのどこの会社？
AMD Gaming Evolvedってなに？ これでもう安定した感あるので試験目的だけにRyzen使うのやめるけど、流れのまとめとしては
QVLにも載っていないRAMをBIOS更新もかけずに使用->落ちる
->Errataだと決めつけて海外フォーラムに放火。つたない英語でスルーされるもさらに日本人数名が放火に参戦
->話を聞いて自称分析できる人、自称再現コード書ける人が明後日なことをやりはじめる
->放火している界隈がTwitterで大騒ぎ
...
->対応していないメモリで再現させてみたら確かにSEGV起きることを確認
->パラメータ見なおして再現しなくなった…えっ？
で、何だったの。これがいわゆるおま環？ >>761
お疲れ様でした
B2ステッピングでても症状出ればエラッタエラッタ騒ぐ連中はいるだろうな
海外から笑われてるとは知らずに >>762
結局、40時間くらいLinuxカーネルをビルドしたと思うと笑える。
海外ではいい笑いものだよねえ。メモリ周り渋すぎだろって声は海外でもあるので今後に期待
個人的にはIntelさん最近ぼったくりすぎだったので、これで拮抗してくれると助かるｗ >>761
まとめるくらい完璧ならスクショ貼ったらどうかな
俺にメモリ設定のスクショ希望するくらいなのに自分はスクショも無しとか
それじゃ本当にテストして完了したのか信用できないよ
俺のようにメモリ設定緩めようが全くエラーの無くならない人もいるわけだし
まとめるなら信用できる情報を頼む >>765
BIOSでスクリーンショット取れないのだが、画面撮影がいい？
それとも何かのアプリのほうがいいっすか？ ちなみに、スクリーンショット希望したのはそちらの環境なんとかしてあげたいのだが、
文字でコミュニケーションしていると抜け漏れが生じるのでという理由からです… 一ついえるのは古いBIOSでがんばっているひてがいるみたいだが、メーカーは何の参考にもしません
開発元は新しいバージョンを試せといってくるだけ。
これはどこのメーカーも同じ >>767
テストが無事完了したかどうかなんだけど
メモリの設定は自分で設定して試せばいいだけだから
本当にエラーなく終わったかどうかの証明ね >>767
FAT32のUSBメモリさしてF12押せばスクショ保存できるはず >>770
YouTubeでライブでもしろってなるの… WSL辞めてからスクショ貼れと騒げばいいのに
WSLはWSLでまたryzenの動作おかしな場合だってある 他、なんかほしいのがあれば張るよ(ただしBIOSのスクリーンショットに限る) >>541 からの、
>>552 の結果が >>671 の試験で 100回くらいでやめたんだっけ
>>770 受けての >>751 で >>748
の画面がこれ >>780
いや成功した回数と日付が延々と流れているだけだから普通にコピペしてすでに貼っているわけだがお前は何をいっているのかと >>782
カウントしないでテスト完了とか言ってんのかよハゲｗ >>779
>>781 が経緯ね。で、XMPプロファイル読み込ませたはずが決め打ち指定を
現在のXMPプロファイル扱いするので、あれ、T(wr|rd)(wr|rd)*の初期値微妙なんじゃ？
と思って >>677
で、自分が思う結末は >>761 >>782
何の話をしているんだ？Linuxカーネルビルドしかやってないぞ？ これから大騒ぎしていた連中が問題をうやむやにするためにここでも騒ぎ出すのかな？ｗ >>785
どうも
前から疑ってはいたんだわ、メモリ周り
全く違う古いDDR3環境で反証やった時に例の現象が起きるのって故意にメモリをヤバくした時だけだったんだよね
ただRyzen持ってないから俺がやる意味はほぼ無かった(←アホ)
夏には買えそうだから参考にさせて頂きます 他にも >>14 みたいな人いるんだがなあ。本当にうやむやにしたいんだろうな
カウンタってのがあの何がしたいかよくわからないプログラムのことを指しているのであればもう貼られてる
>>14
http://i.imgur.com/KuthSwm.png >>789
Q3まで待てるならメモリ周りに余裕のできる(と言われている)、
消費者品質ではない商用品質のPROシリーズ出るからそれ待っては？ >>693 >>791
まぁ色々考えてはみるよ
正直言って今の使い方だとMBの面積そのものが足りなくなりそうな状態で、、、 >>794
確かに。もうUbuntuはArtfulにアップグレードしてしまったので >>541 の追試はもうごめんだが、
BIOSを2.00に落として、CMOSクリア、Windowsの起動くらいはできるだろうから >>14 のように画面を取得
BIOSを2.60に再度上げて、CMOSクリア、XMPプロファイル初期値がどうだったのか書き出し
で、もう普通に使うんで現在の設定に戻して通常運用。くらいなら協力できるが、それでいいかな？ って、なんだ。騒いでいる一派の人か。どうでもいいな >>796
より正確には、>>794は「ただ」騒いでる派じゃないかな
>>783を見るに >>795
16.04での結果しか見てない気がしますが
BIOS2.60 + 16.10/17.04/Artful + それぞれのgccでのカーネルビルドって試されました？ >>797
騒いでいる派でもいいけど、もう相手にしたくないわ…
>>798
試したほうがよければ試すけれども、200回パスする状況ではもう普通に使いたいですｗ
何度か200回以上の試験をすればそりゃSEGVすることもあるだろうけれど、
それは1,000回パスさせろって話なのでECCメモリ買ってこなきゃって世界… ここ変えたらエラー無くなったくらい言わねーとダメなんじゃないかという話よ
一発で決まったというなら別だがｗ AMD品質だと1000回でエラーは当たり前なのか？
こわいこわい >>799
あれ、>>741>>748の200回パスってArtfulでのテストでした？
常用予定の17.04でどうしてもNGが解決しないんで他のバージョンも試そうかと考えていて
既に他にやってる方がいたら自分でやる範囲減るなーという甘えなので追加の試験は結構ですよｗ >>801
暇ならIntelでもAMDでもいいから、Non-ECC UDIMM DDR4-2400 x2以上構成、
Ubuntu16.04 64bitデフォルトインストールgccも標準のもの使用、
make distclean; make loadmodconfig; make oldconfig; make -j `getconf _NPROCESSORS_ONLN` で
1,000回でも10,000回でも回して結果報告してくれると助かるわ笑
>>803
さっきまで16.04でしたよ。16.04付属のgcc5.4.0も怪しい気がしたんだけどね。なお、成功するタイミングで累計600回は回した…
すまんね、最初からArtfulを使う目的だったもので >>804
そうですかー
いやご丁寧にどうもでした
メモリタイミングは参考にさせていただきます >>805
元はHaswell/LGA2011v3が読み込んだ設定から引っ張って来ただけだったのですが、参考になれば。
ここでパラメータの議論をすると変なのが湧いてくるので、あのテンプレでメモリスレでも探して
議論してもらったらいいんじゃないかなーと他力本願モード… >>804
一応
$ sudo mount -t tmpfs -o size=10G none source/tmpfs/;cd source/tmpfs/;tar xf ~/Downloads/linux-4.12.tar.xz ;cd linux-4.12/
~/source/tmpfs/linux-4.12$ cp /boot/config-$(uname -r) .config
~/source/tmpfs/linux-4.12$ make defconfig
~/source/tmpfs/linux-4.12$ while test true; do a=1;while test $a -gt 0;do make clean>/dev/null&&make -j12 >/dev/null&&echo $a `date +%Y/%m/%d-%H:%M:%S`&&a=$(($a+1))||a=0;done;mv core ~/core.`date +%m%d-%H%M`;done
1 2017/07/12-17:50:15
2 2017/07/12-17:52:05
3 2017/07/12-17:53:55
4 2017/07/12-17:55:46
...
111 2017/07/12-21:14:20
112 2017/07/12-21:16:13 ま、PIE採用された17.10以降では発生率に差は出るだろうね
#自前buildです
$ uname -s -r -v
Linux 4.12.0 #2 SMP Wed Jul 12 17:35:52 JST 2017
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=17.10
DISTRIB_CODENAME=artful
DISTRIB_DESCRIPTION="Ubuntu Artful Aardvark (development branch)" hwlocは直ってないなー。likwid-topologyの結果は正しいんだけど、Ubuntu16.04だとどうだったっけか
https://pastebin.com/aA6GKt41 >>795 やるためにちょっとWindows行ってきますね。
...
124 2017/07/12-21:38:35
125 2017/07/12-21:40:28 ashes of singularity benchmarkに期待 Ryzen MasterもASUSのも動かなかったｗ
Windows Server 2016はだめだって < Ryzen Master
さてどうしよう？ >>753
メモリ設定は基本>>751に合わせて
Ubuntu16.04(.0ja)、USBメモリで起動したままのパッケージでryzen_segv_test回したところ10分ではNG出ず
PC環境は>>713
リブートしてUbuntu17.04に戻るとやはり1分に数回程度NG出るので、
そのバイナリをUbuntu16.04に持っていくとやはりそちらでも同じような頻度でNG
Ubuntu17.04のgcc6.3の吐き出す命令の並びのパターンがクリティカルにヒットするんだと思う
Ubuntu16.04と17.04のカーネルの違いも考えたけどそれは関係無さそうかな はい、戻ってきました。死ぬかと思った
手順
1.BIOS2.60の現在の設定で取得
http://www.gazo.cc/up/248724.png -> 正常再起動
2.BIOS2.00に落とす。デフォルト設定
http://www.gazo.cc/up/248730.png -> 正常シャットダウンできず
3.BIOS2.00でXMP Profile v.2を読み込む
http://www.gazo.cc/up/248727.png -> 正常シャットダウンできず
4.BIOS2.60に更新。デフォルト設定
... -> 起動すらできなくなってたー
5.BIOS2.60で先の設定に戻す
http://www.gazo.cc/up/248731.png -> 正常終了もできた 変わってたのは結局、tWR,tCWL,tRTP,tRDWR,tWRWRDDか。
>>751 のTrdwrは9->10にしたほうがよさそう。適用してこようっと
一番効いたのはtRTPかね？ >>816 ryzen_segv_test？Linuxカーネルビルド？ >>816 >>819 自己レス。前者ね…あれ意味ないよ…？ ryzen_segv_testでNGが出るのは、最初に問題になったgccがSEGVで落ちるのと
全く何の関係ないので分析の人のやっていることとも違うし、ここでやっても意味ないー >>822
やろうとしていることがそもそも実環境で生じない、
で、書き方が以下略だからコンパイラ依存でどうのこうの
あれでOK出てもNG出ても、ふーん、あっそ？としか思わない >>821
すみません、入れ違いになりました
全く何の関係もないかどうかについては現時点ではこちらも言えないですが、
・少なくとも僕の所有するこのRYZEN機以外ではあらゆるOSで一度もNGを出せないこと
・メモリ設定を見直して問題がなくなった人もやはりryzen_segv_testはNGが出ないと報告している（>>14）こと
の点から正しい状態で動いているマシンではNGが出ないものと考え、
ひとまずは結果が迅速に分かるryzen_segv_testでやってみているところですね。
とりあえず>>14の人と合わせてWindowsでも試してみようと思います
Linuxのようなてんでバラバラのカーネルやコンパイラを使ってると同じバイナリではないので再現性がいまいちで、
ひとまず>>14の人と同じ状態であることが期待できるWindowsのほうがいいかなと もうプログラム板にでも行ったほうがいいんじゃないの… volatileの使い方覚えようか
あるいは-O0指定
スピンロックがスピンロックになってない >>826
ひとまずここで長々やってもしょうがないんで、ツイッターか
あるいはプログラミング板のしかるべきところでやりません？ いや勝手にやってくれとしか言いようがなくって、
これがRyzen絡みでSEGVと関係あると思われているのほんと迷惑だよなー
プロジェクト名がもうそう誤認させることを意図しているし、
作者もそれを意図しているからどうしようもないんだけっど
時間と電力の無駄 とどの詰まりメモリ設定を緩々にして使えって事かい？ DDR4は元々skylakeでも問題出してたんだろ？確かメモコンが仕様を満たしてないとかで
それでintelの威光でメモリモジュールを修正させたって経緯だったそうで
amdからしたらある意味後発でintel様仕様のメモリによく合わせて来たなあって感じがするけど
だからCPUのエラッタエラッタ騒ぐのはその辺が臭いんだよなあ >>833
【AMD】Ryzen メモリースレ 4枚目【AM4】での評価
http://egg.2ch.net/test/read.cgi/jisaku/1498558737/147-
しまった、目が覚めてしまった。
>>812 からの追加分
1 2017/07/12-23:29:43
2 2017/07/12-23:31:35
...
96 2017/07/13-02:26:16
97 2017/07/13-02:28:10
計222回は回った。
$ sudo mount -t tmpfs -o size=10G none source/tmpfs/;cd source/tmpfs/;tar xf ~/Downloads/linux-4.12.tar.xz ;cd linux-4.12/
$ make defconfig
$ while test true; do a=1;while test $a -gt 0;do make clean>/dev/null&&make -j12 >/dev/null&&echo $a `date +%Y/%m/%d-%H:%M:%S`&&a=$(($a+1))||a=0;done;mv core ~/core.`date +%m%d-%H%M`;done http://egg.2ch.net/test/read.cgi/jisaku/1498558737/148
OCCT-Linpackとやらに興味があるので一旦止めますね。
...
133 2017/07/13-03:35:51
134 2017/07/13-03:37:46
計8時間ちょい OCCT Linpack 1時間正常動作したので戻ってきた。
ごちゃごちゃいじっていた間にWindows Server 2016のほうはぶっ壊れたなー 結局、自分のメモリはJEDECプロファイルで既定動作するが、他はそうではないって落ちか
市中に品質の悪いメモリが〜ってのは1.2V既定値で動作しないものをXMPで1.35ならもっと速く動くから！と売れちゃうのが問題なんだよな
・一般的に信じられていること
このメモリ、DDR4-2666以上で動くんだぜ！選別品を合わせてプロファイルがチューニングされているっ
・現実
大多数のモジュールメーカー:チップのグレードで決まってるし、その通りにプロファイル書き込んでますよ
少数のモジュールメーカー :チップのグレードじゃ利ざや稼げないからヒートシンクつけて無茶なプロファイル書き込んでますよ ソフト名をロックスピナーに変えて一人でやってほしい予感 >>839
お前は一人でpostitにでもコメント書いてろよ。 volatileを正しく使わないと仕様通りに書いたつもりでも正しく動かないものができるというごくあたりまえの例 誰か EIRAKU氏に BIOS更新のやり方教えてあげたら？
わざわざ SEGVする BIOS、メモリ設定で解析がどーのとか gdb使える自慢かよ 古いBIOSで現象でましたってメーカーに報告してもBIOSあげてねしか返ってこないのにねぇ >>847
これが結論なんだよなー…
satとかhomuh0muとかEIRAKUとか何なのコイツら… SEGV の人（）
+64 の人（）
ロックスピナー（） ← NEW!! volatile修飾した変数を非volatile修飾で参照すると動作未定義ってCの仕様にも書いてある(JIS X3010 2003の80ページ) >>838
2133/2400動作のメモリは選別落ちだから、Intel向けできっちり選別してるとRyzen環境では高確率でまともに動かないのが現実。
8コアからアクセス集中するからSkylakeで相性問題出た時よりもメモリ負荷高いしこうなって当然だと思う。
CPUの方の口コミにもIntel環境で使ってたDDR4がRyzenだとメモリ相性で起動しないとかいくつも報告あるんだよね。
大抵は起動してもぎりぎりの所で動いてる場合が少なくないんじゃないかな。
何故かHynixモジュールで相性多いのが謎だけど。
http://bbs.kakaku.com/bbs/K0000904466/#tab
CorsairのHPではRyzen対応を謳っていますが、自分の環境（Ryzen 1600X ASUS PRIME 370X-PRO）ではBIOSさえも立ち上がりませんでした。（ver.5.29）
同様の環境でこのメモリの使用を検討されている方はご注意下さい。
当方では当初このメモリしかなかったのでBIOSは古いままでしたが、
相性を確認して頂いたショップでは最新のBIOSでもNGでした。
（他のお客さんで同様にNGだった方も全く同じ型番とver.だったそうです）ASUSのQVLではこの型のひとつ前のC14が掲載されていたので、これでも大丈夫だろうと思っていました。
（ASUSのHP上ではRyzen対応を謳っている頁にこの型番があったので） >>850
お前の噛み合わない話は必要ないから黙っておけ >>851
何か勘違いしているのでは？
8コアからアクセスが集中することと DDR4の取り扱いが難しいのは別の話です。
Trdrdや Twrrd といったパラメータは、先に DRAM側に命令を発行しておいて、
といったパイプライン動作が DDR3より複雑になっているために生じているものです。
Skylake で問題になったというのも、この CPU のメモリコントローラーと
DRAM側で保証できる応答時間の組み合わせが複雑になりすぎている一方、
CPU側の対応が進んで複雑な読み書きの発行が可能になったことによるものでしょう。
しかし、Intel のメモリーコントローラーに対応した XMP Profile v.2 が
AMD のまだ仕様も一般には公開されていないコントローラーでは
十分なマージンが得られず問題が起きているものと推察しています。
QVLは、こういった事情から BIOS とその時点で検証されたモジュールは
チップのグレードレベルで合致しなければ成り立ちません。
さらに話をややこしくしているのが、ゲーマー向けの高価なマザーボードのほうが
その配線の信頼性を頼ってより厳しめの設定を初期に選んでしまう傾向にもあるでしょうね。 >>852-853
何も話題についていけてないのに煽るだけのお前が不要 >>854
こわいこわい。T(rd)(wr).*を可能な最小値にしたら、
リセット後にVGAのファンが数度停止、OS起動せず…
http://www.gazo.cc/up/248759.png やはり、Ryzen対応とM/B対応は別じゃね… XMP変な読みすると死ぬぞこれ… 参考までに比較
項目 私 : >>14
TrdrdScL 5 : 5
TwrwrScL 5 : 5
Trdwr 10 : 6
Twrrd 3 : 2
TwrwrSc 1 : 1
TwrwrSd 7 : 6
TwrwrDd 7 : 6
TrdrdSc 1 : 1
TrdrdSd 5 : 5
TrdrdDd 5 : 5 CMK16GX4M2A2400C16は型番が同じでもメモリチップはおみくじ、問題が起きてるのはHynixチップが載ってる物。(Ver5系)
同じ型番でもSamsungチップのVer4系は問題ない。
本来チップが異なれば適切なサブタイミングも異なるので別商品として売らないといけないが、
面倒くせぇからチップ関係無く全部同じタイミング書き込んでおけば良いや、ってなってるのが原因の1つ。
おかげでQVLリストが無意味なものになってしまっている事も少なくないし、
Aさんが〇〇のメモリで動いたといっても、それチップ何よ？ ってなるわけで参考にならない。 いつも大体3000くらいでエラー出るほぼSPDのメモリ設定のままPLLだけ2.1Vに昇圧して例のスクリプトのWin版やってみたら初めてエラー無しで20000超えた
もう合格ってことでいいかな暑いし >>14 のok:87917 ng:0 others:0の合計が2500000にならないことはスルーでいいの… >>865
100万回ならとかきりがない話になるので 前のBIOSだとマザーボードによってはECCうまく動作しなかったりしたけど今は大丈夫なんかなぁ https://github.com/hayamdk/ryzen_segv_test/blob/master/launcher_win/launcher.c#L122
ret = WaitForMultipleObjects(j, wait_handles, FALSE, 1000);
if (ret == WAIT_FAILED) {
printerr(L"WaitForMultipleObjects");
} else if(ret >= WAIT_OBJECT_0 && ret < WAIT_OBJECT_0 + j) {
exitchild = ret - WAIT_OBJECT_0;
GetExitCodeProcess(sets[exitchild].process, &childret);
CloseHandle(sets[exitchild].process);
なるほど。n個終了しても1個しか計数しないのか。そりゃ数が合わないわ
足 し 算 の で き な い 試 験 プ ロ グ ラ ム >>869
APIのリファレンスをちゃんと読みましょう
https://msdn.microsoft.com/ja-jp/library/cc429423.aspx
fWaitAll
待機のタイプを指定します。TRUE を指定すると、lpHandles 配列内のすべてのオブジェクトがシグナル状態になったときに制御が返ります。
FALSE を指定すると、lpHandles 配列内のオブジェクトのどれか 1 つがシグナル状態になったときに制御が返ります。
この場合、戻り値は、関数が制御を返す状況をもたらした（つまり、シグナル状態になった）オブジェクトを表します。 別にこちらも完全無欠な人間なわけじゃないんで、
こちらが間違ってることもあるだろうし、そういう指摘は甘んじて受けるつもりですが、
あまりに「どうせこいつは間違ってるんだろう」という先入観が入りすぎてませんか？
あなたはプログラミングにかなり詳しそうですから、そんなショボい勘違いAPIのリファレンスちゃんと読んでたらするはずないでしょう
というかここじゃなくてプログラミング板とかツイッターとかでやっていいんですよ あ、いた。いやー、不思議な書き方するよねっと
WFMOでSignal状態は解除されるので最終段ではひたすらループすればいいのにそうしないし、
Timeout指定しているのにWAIT_TIMEOUTは気にしないんだーとか面白くてね、つい。笑 たしかにそこは分かりにくいですね
自分でも今見返しててなんでそんな分かりにくいフローにしたんだろうと思いますわ
別にmmap/VirtualAllocした直後にエラーチェックして
普通にreturn(NG扱いにするのもあれなんでリターンコードは0で)しときます Invalid OpCode Exception飛ぶ命令列をひたすらL1Iに食わせてOpCacheを
汚染させるケーステストをやったほうが名をあげられられる可能性高いのに、なんだかなあ pthread_createで作ったスレッドの実行順序がFIFOとは限らない と思うならやるのはあなたでしょう！
ぜひ名を上げられてください
僕はもうここであれこれ応酬してるだけで精一杯ですので volatileつけ忘れたか。まあいいや、イメージ 今回、Erratumがもし存在するとしたら、予想では
|Op1|Op2|...|OpN|(16x4Bytes境界)において、jmp,jccの直前にInvalid OpCodeを置くと
|Op1|InvOp|Jcc|...|OpN|に引っかかった際にfix-upがまだAGESA1.0.0.6にも含まれてなくて
#UD飛ばすべきなのに、#PFになる。みたいな落ち。通常はjump boundaryでopは区切れるので生じない。みたいな C++ならatomicクラスあるのにな
volatile修飾子外すポカもだいぶ減るよ >>877
例外をカーネルに捕捉されて汚染ライン流されるだけでは？ 名を上げるには、とにかく簡単なコード、小さなコードで発生させること
せっかく発生するコードがあるんだから、これを小さくシンプルにしていくのが普通だが、仕事じゃなければバクチで>>877みたいなコードから試すのも有りかと
元々バクチなんで、>>885みたいな指摘はナンセンス 現実のワークロードでありえないコードシーケンスでなにか問題見つけた時点でIntelの対応みたいにパッチもワークアラウンドもしめさずただリストに書くだけで放置のオチになるだけですよ
ちょうどIvyBridgeの自己書き換えコードのエラッタみたいにね
gccの問題を解決するにはgccのワークロードを分析する以外ないと思うけど？
それともただバグ掘りやりたいだけ？ ECCメモリでライゼンバーグ発現した人いまのところいないんでしょ
（逆にいうとECCついてないひとのところでしかプログラムカウンタ化けは起きてない） 不正命令例外も知らない >>886 は無理に入ってこなくていいから いや、>>886 の通りでしょう。今回の流れのおかしなところは、LinuxでどうもSEGVが出ると
そんなことはLinuxに限らず珍しくもなんともないのだけれども、
gccで大規模にコンパイルをすると出るらしい。ここで規模の拡大での観察
ここまではよかった。でも、反例として、メモリ回りがどうも怪しいのではないか？
出る確率は…観察できないほどに減った。逆にメモリ回りをおかしくすることで出る確率を増やすこともできた
では、メモリは無視できるか？大きな要因の一つとして考えられるだろう。
もしこのスレで続いてメモリ回りでの改善が得られた人が出たら、
それで説明される、となる。もし出ても異常な状態による不定動作として >>887 のように扱われる
しかし、なぜ#PF,#UD(それぞれSIGSEGV,SIGILLとして)が観察されたのか。
ここで仮説を立てて、問題を探す。範囲の縮小での観察。これが面白いのではないだろうか。
一方で、お祭りに仕立てあげて実際にはSEGVを起こしていないものまでSEGVと騒ぎだした人々がいた
海外ではそれを日本から来た人と呼んだ 発起人のsat氏はgccのコンパイルが正常に通るようになりさえすればなんでもよくてあとは勝手にやれというスタンスに見えるけどお前ら誰を巻き込みたくて騒いでる？
ぶっちゃけるとTwitterの方々は問題の出た人の「当たり石」をECC持ちの人に貸し出して検証させれば、それで全て終わりじゃないかしら
問題が出なければマザーかメモリか電源が悪い、出れば石の個体が悪い、ってことで SEGVが出るハード環境で>>552の設定でテストを始めた
メモリはHynix 2400 1R 4GBx2
マザーはMSI BIOSは1.0.0.6正式版
全体的にサブパラメータの殆どの値が増える(ゆるゆるになる)状態になった
現在memtest中
次にOCCT、Prime95でガッチリチェックして、続いて今回初のRowHammerテストツールも行う
2日位掛かりそうだ
それから連続ビルドを行う予定
テスト終了したら報告しようと思う 普通に代理店にCPUと検証用のHDDイメージバックアップしたBD-R送り付ければ済むんじゃね？
流石にLinux使える人間が1人も居ないとかは無いだろうし
何なら起動したら自動でテスト走るようにしとけば良いわけで
あとは代理店が判断する、在庫品でSEGV出なかったらCPUの初期不良で交換になるだけだろう しかしまあどんだけ指摘されても一切対応しないねこいつは
リファレンスがどうとか言ってるがそれが間違いならそれをAMDに指摘すればいい
現象が再現しなくなると都合が悪いわけでもあるまいし
それとも目的はCPUのバグ調査ではないのか 追記しとくとAMDコミュニティで相手にされなくて複アカ自演してるわ ECCメモリでも修復不可能なエラーだとNMIかかって
panicだっけ？
panicしないで落ちるってことはやはりメモリモジュールではなくメモリバス（のタイミング）ってことかな？ >>893
むしろお前が大騒ぎした張本人だろ？
自作板のスレ荒らし回っておいて何他人事のようにしてんだ？
お前本当ポジションかなトークで荒らしたいだけのクズだよな >>78 に
３．詫び石とか騒いでいる日本人に対する訴訟検討中。日本法に詳しい法務と相談中
を追加したほうがいいんじゃね。笑 satがランダムハングアップ（信憑性無し）とかおかしな言い訳始めてるが完全に頭おかしくなったな
早めに土下座しとけばいいものを 結局、海外では相手にされず、頭にErrata(複数形)って落ち？ メモリの内容をハードディスクに保存しておけばいいんだよ >>906
記事の方にだけ追記でこっそりLinuxカーネルとUEFIをアップデートした事を記載。そりゃ誰がどう考えても事象変わるに決まってるだろ
もう確信犯でやってるなこれ
http://satoru-takeuchi.hatenablog.com/entry/2017/04/24/135914
＞交換した石
＞
＞諸々の手続きなどを含め3週間ほど経過した後にようやく交換品が届きました。早速make -j16によるlinux v4.12(執筆時点での最新版)をテストしてみました。
＞
＞冒頭に記載した環境からの差分は次の通り。
＞
＞kernelは4.8.0-58-genericとv4.12
＞BIOSは1.0.0.6a WindowsユーザーのためのUbuntu16.04でカーネルビルド無限ループさせたい人向け手順
1. 16GB以上の空きメモリのあるマシンと空のUSB Memory(4GB以上)を用意します
2. http://releases.ubuntu.com/16.04/ から ubuntu-16.04.2-desktop-amd64.iso を入手
3. ISOイメージをUSB Memoryに焼くために Rufus を https://rufus.akeo.ie/ から入手 (Rufus 2.15 Portableで構いません)
4. USB Memoryに2.でダウンロードしたイメージをインストール
5. 再起動、BIOSでF11を押してUSBから起動、Try Ubuntuを選択
6. 起動したら、左上のボタンを押してTerminalと入力、コンソールが開きます
7. 手順に従っって延々とビルドしてください… https://pastebin.com/bPEAVz5e
おまけ。Ubuntu16.04のgcc 5.4.0を再コンパイルしたい人へ
(コアダンプ解析したいとか。apt source 使うべきなのかもしれませんが、ここでは本家を採用)
https://pastebin.com/k9YpeqS3 空きメモリってなんだよ…とか修正は適宜つっこんでいただければとー システムハングだとやっぱり信号系で、ACKが返って来てないみたいな感じに思えるが、騒いでる奴らが怪しくなりすぎて、なんともな・・・
>>913
短期的に見れば営業面ではネガキャンになるかも知れないけど、長期的に見ればryzenの検証が進むだけキツくなるのはintelだと思うんだよね F 恐怖-訴えられた場合に対応できるのだろうか…
U 不安-もし自分だけが間違っていたとしたら…
D 疑念-もしかするとエラッタじゃないかもしれない… まあ、自動設定で一発で動いてトラブル皆無、というのが自作だと
思う人はKabylakeに行くかB2を待った方が良いのは事実かもね。 ただBIOSの対応弱すぎでしょってのは事実だし、OpCache無効にすると挙動変わるので、
メモリの読み取りおかしいとかで変な命令食わせたら結果がさらにおかしくなるのはあるでしょうねー 一方でデコーダーが6uops/cycle発行できるためOpCache切っても性能は数%しか下がらない。
実はデコーダーの省エネ機能なんじゃねーの…っていうあれなのでAMDとしては余裕だろうな… >>920
そこはQVL見とけば大丈夫じゃないかなぁ 自動設定だとXMPオンになってたりdr4枚で2400MHzになってたりするのよ
単にメモリのSPD見てるだけで組み合わせまでは見てないっぽい こんな証言あるし
165 Socket774 (ﾜｯﾁｮｲ 06d7-cI7G) sage 2017/07/14(金) 14:12:36.18 ID:y60707FA0
>>66
厳密に言えばgccが糞なのだろう
実はうちのi5でも複負けするとSEG Vでるよ
昔から-jは勇者の証だったから >>925 それがなぜ >>916 に gcc選ぶ選択肢入れたか、なのです… 「GCC 6.4」リリース、不具合修正がメイン
https://mag.osdn.jp/17/07/05/153000
satが使ってるのは5.4 扱い辛いコンパイラとかって話だが、最新版がコケるわけねーだろ!イグゾォォォ!
つってgcc7.1でやったらFXでも変なWorn出まくったもんなぁ、、、 >>927
gcc5.4.0にはそんなにバグないですよ
https://gcc.gnu.org/bugzilla/buglist.cgi?cf_known_to_fail=5.4.0&;cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&component=c&product=gcc&query_format=advanced gcc6.4.0で試した人の話が>>319 >>320にあるがSEGVは出たそうだ そもそも動作ベースの方のkernelが対応してキチンと認識できる状態で動かさないと出る筈よね
トポロジ認識トチ狂ってたろ カーネル開発者か何か知らんがBIOSはあげたら
でなけりゃただのクレーマーでしかないべ エラー出たとか言っても再現報告なし。
陰ドチンピラによるねつ造の可能性の方が高い皮肉 しかし、メモリの設定きつくしても64バイト問題起きないんだよなあ
どちらかのメモリチャンネルのDQ[5]ピン痛めてるなんて落ちはないんだよね？ >>931
現状、NUMA扱いはされていないのでLinuxで別の問題が起きるとしたら
むしろKASLR(ユーザー空間ではなくカーネルの空間のASLR)が有効になる、Linux4.12以降かな
さすがにこれを混ぜる馬鹿はいないだろ… >>934
そういえばメモリの逆挿しかなにかで真っ赤になったんだっけ？
たしかに可能性はありそう
それで、その解析した人以外で64byteズレの報告ってあるの？ 最近の情報を見てると
・メモリ／電圧設定で直った人（AMDサポート推奨設定含む）
・マザーボードメーカーのQVLに載ってない廉価メモリを刺してハングアップするようになったとか言ってるsat
の二通りしか見当たらないんだが satは様子見ないまま勝手にエラッタ騒いで言い訳する始末かよ
これタチ悪すぎだろ
土下座まだか？ 余裕のある人、 >>916 追試か、メモリ報告 >>751 テンプレやってくれるとうれしいな >>936
その人だけって噂があるんだけど、どうしよう？うちのSIGILL(#UD)は64バイト関係ない、よ？ ・悪意のある(修正する気の無い)バグ入りコードでFUD
・DDR4設定はメモリベンダやマザボベンダにとっても難しい
・gccはintelでも落ちる なんつぅか原因調査ができてなさすぎに見えるんだよなあsat何とかは
働いたことないのかな >>935
> さすがにこれを混ぜる馬鹿はいないだろ…
>>909
＞冒頭に記載した環境からの差分は次の通り。
＞
＞kernelは4.8.0-58-genericとv4.12
＞BIOSは1.0.0.6a うーん・・・
sat氏は「uOpcache無効化は問題発生の確率（？）を下げるだけ」としてるけど無効化してSEGV治らなかった人っている？
色々BIOS設定・HW構成試してきて、結局uOpcache無効化するだけで一気に様相が変わった感
なんでもう少し早いタイミングで試さなかったのかは自分でも謎だけど先入観に引っ張られたかな・・・ >>946 治ると思いますよ。かつ、 >>922 に書かれているようにパフォーマンス低下はほとんどないはずなんですが、どうです？
Boostかかる頻度を気にしなければ、gccの連続実行のようなALU/AGUのみ使用のケースでは性能劣化ないはずなのですが。
問題なのは変な命令列を食わせてOpCacheのTagがおかしくなった時で、これは >>882 のようにfix-up不足なのでは？を支持かな >>947
最近ずっとメモリ2133とか2400でうんうん唸ってたところから3200で動かしてる向上分が大きすぎてよくわからんですなｗ
一晩〜テストかけて自分の中で納得いったら自分のケースとしてまとめます
自分は、他の何をやっても解決しなかったのでuOpcache周りのせいだとしたいですが、
無効化せずとも他の設定で解決する報告があるんで回路なりuCodeなりの不具合と結論するのは乱暴なんでしょうね
まあ、もう随分時間も金も気力も使ってしまったので、性能劣化が許容範囲なら無効化して静観モードに入ろうかなと思ってます 各種タイミングぎりぎりに厳しくして電圧上げて高いクロックで
動かせば発生しやすいいうんだから、その状態でuOpcache無効化して
確認すればいいさ。 新BIOSにしたから新しいsegvtestのwin版試したら1000台でエラーだったのがopcache controlをdisableにしたら10000超えてもエラー無しだわ
メモリのタイミングも各種電圧設定も総当たりで試してダメだったからこれでエラー出なくなったらスッキリすんだけどなぁ >>944
satなんとかだけじゃない
Ryzenユーザー全員 初めて30000超えた
俺環では原因はuopcacheということかな
で、これどこまでやればいいのよ ryzen_segv_testのOK/NGは実環境のSEGVに一切関係ないと何度言えば… 細かい事だけどなんでこれIntel64のデータシート参照してるんだろうか?
AMD64の筈だろ >>916 追試か、QVLな人はメモリ報告 >>751 テンプレでうｐしてくれ ryzen_segv_testの自称作者はプログラムの妥当性の証明と
シングルスレッドのgccでいつ自己書き換えが起きるのか、
実際の環境でどういったプログラムが自己書き換えをこの程度のロックで行っているのか
https://github.com/hayamdk/ryzen_segv_test/commit/d93a41af640db21d8f8b99539f205bf545963db8#diff-eb6b6c90251ab33cee784713c451e6d8R2
「自分の考えでは」はどうでもいいから、いい加減説明してくれ satと同じでEIRAKUとか言うの頭おかしいな
こいつ自分を知らなすぎるわ
永遠に何と戦ってるんだ？
https://twitter.com/hdk_2/status/885814883031203840
こいつも土下座まだかな？ biosアップデートしたら負けだと思っている。
(aa略) 起きて見たら71875でエラー無し
スクショとるつもりが消してしまった・・・
俺環ではuopcacheが不良だったって事で
とりあえず寝る ryzen_segv_testはオフセットを変えて書き込む際にnop埋めをしていない
不正な命令列をL1IなりOpCacheに食わせていることになる…実際にそんな状況あるの？ JavaScriptのJITでもそんなひどい実装はみたことがない
nバイトずらして別の命令として解釈される例なら面白いかも 昔の8bitマイコンみたいにフリフェッチもキャッシュも無けりゃいいけど
今時そんなもんきちんと動くこと想定するほうがどうかしてるかと >>964
ちゃんと >>916 追試か、QVLな人はメモリ報告 >>751 テンプレにしてくれ
あとBIOSの話もちゃんとテンプレ化してくれ。
スレたてたならそれくらい責任もて エラー出る>>751の設定テンプレにしてどうすんだｗ >>966
はい？済まないが見落としていたかもしれん。レス番教えてくれ >>966
やっと見つけた >>816 で合ってるかい？ >>967
実際やってエラー直ってないからｗ
めんどくさいから報告してねーけど
だいたい変えても変化の無いtrcpageに値入ってんのがうさんくせえ >>969
Crucial Technology Ballistix Sport自分も使ってるがこれ一応選別チップのメモリーだしな
安メモリーならもっと緩めないといけないわ opcache control無効だけどCinebenchの結果がメモリクロック3200でも有効にした2133に余裕で負ける・・・ >>972
opcacheの性質上同じ処理を繰り返し実行するレンダリング・エンコード系は落ちると思う >>972
μops cacheを有効にしてwinのスーパーフェッチ無効だとどうなる？
自分はkp41病がこれで直ったから興味本位で試してくれたら嬉しいな SSE/AVXは命令長いから命令フェッチ帯域のほうに引っかかってんでしょ >>975
スーパーフェッチはクリーンインストールした後すぐに無効にしてあったから無理だね >>969
スクショすら上げないやつのために報告テンプレ作っただけじゃ？
tCL, tRCDRD, tRCDWR, tRP, tRAS, tRC はいわゆるスピードグレード
tCL-tRCD-tRP-tRAS 表記で 16-16-16-39 ってのがそれ。
一般的には tRCDRD>=tRCDWR, tRC>=tRAS+tRPの関係式
tRRD_S, tRRD_L, tFAW, tWTR_S, tWTR_L, tWR, tRTP がメモリチップ依存。一般的には
DDR4-2133 : tRRD_S >= 4, tRRD_L >=4, tFAW >= 23, tWTR_S >= 3, tWTR_L >= 8, tWR >= 16, tRTP >= 8, tCKE >= 6
DDR4-2400 : tRRD_S >= 5, tRRD_L >=5, tFAW >= 26, tWTR_S >= 3, tWTR_L >= 9, tWR >= 18, tRTP >= 9, tCKE >= 6
安定させたければ増やすべき。関係式は
tCWL = tFAW - Min(tRRD_L, tRRD_S) - Min(tWTR_L, tWTR_S) - tRTP
だったっけ…自信ない
tRFC, tRFC2, tRFC4 もメモリ依存なのだがこいつは世代によって大きく変わる。最近の最小値は
DDR4-2133 : tRFC >= 587, tRFC2 >= 374, tRFC2 >= 278
DDR4-2400 : tRFC >= 660, tRFC2 >= 420, tRFC2 >= 312
Trdwr, Twrrd, TrdrdScL, TwrwrScL, TwrwrSc, TwrwrSd, TwrwrDd, TrdrdSc, TrdrdSd, TrdrdDd, CR が
メモリコントローラの性能とメモリの性能、周波数で変わってくるのだが、これがわかっていないので QVL 持ちは教えてほしいっていう あと Trcpage は APU 環境だろ。AM4 には関係ねえ… >>972
整数命令のみぶん回すなら関係ないが、uops/insnが大きい浮動小数点命令系は命令フェッチ帯域が先に間に合わなくなる
>>973
>>916 (Linux カーネルビルドでのgcc SEGV問題) やるならいいけど、ryzen_segv_test は何の意味もないから ECC 関係なくエラー出ると思うよ…
>>974
同じ処理っていうか、整数命令のみかどうかだね。AVXぶん回されるとフェッチが間に合わない
>>975
スーパーフェッチはOpCache関係ねえ… B350M MORTARとBLT4G4D26AFTA.8FBD持ってるけど
よく調べてみたらQVLはBLT4G4D26AFTA.8FADGだし
Ryzen Timing CheckerでもBIOSのMEMORY-Zとかでも出てこない値あるから
ちょっと力になれそうにないわすまんな >>981 Ryzen Timing Checkerのスクショだけでも非常に参考になるのでお願いしたい… >>977
レスｔｈｘ
元から無効で発生してたなら関係なしか >>982
M/B : MSI B350M MORTAR
CPU : AMD Ryzen 5 1500X
FAN : Wraith SPIRE
RAM : Crucial BLT4G4D26AFTA.8FBD（但し、QVLはBLT4G4D26AFTA.8FADG）
BIOS1.3
ttp://i.imgur.com/zVwdLuw.png
BIOS1.5
ttp://i.imgur.com/yFnz6pI.png
ttp://i.imgur.com/HeCuuOF.png
ttp://i.imgur.com/8aOsekG.png
1.3のままなの忘れてたからせっかくだから両方
1.5の更新履歴にはUpdated AGESA Code 1.0.0.6って書いてあるけど
BIOSをバイナリエディタで開くと1.0.0.4って書いてある謎
でもメモリ設定項目増えてるからたぶん1.0.0.6だよね SETTINGSのSystem Statusとかいう項目に入ってMicrocodeのVerを確認
8001126なら1.0.0.6 >>978
> tCWL = tFAW - Min(tRRD_L, tRRD_S) - Min(tWTR_L, tWTR_S) - tRTP
> だったっけ…自信ない
tCWL = 11 or 14 (DDR4-2133), 12 or 16 (DDR4-2400) 800111C が AGESA 1.0.0.4 だね。 埋めついでに、せっかくなので定格（2400）も
ttp://i.imgur.com/VQHBg7Y.png
ttp://i.imgur.com/eB8BeFW.png
ttp://i.imgur.com/ih1zVzn.png >>994
1チップあたりの容量が少ないならデフォルトはこんなもんでしょ >>994
と言われても見ての通りAutoやしSPD値のままやで 次スレにあるけどこんな感じ
4GbチップのDRなら妥当
29 Socket774 (ﾜｯﾁｮｲ dfec-Xm5V) sage 2017/07/16(日) 15:52:02.27 ID:sWuKSMyk0
>>27
>>19 ではないが、tRFC 350(ns) ということは最近の DDR4 8Gb チップかと。
4Gb tRFC1 >= 260ns, tRFC2 >= 160ns, tRFC4 >= 110ns
8Gb tRFC1 >= 350ns, tRFC2 >= 260ns, tRFC4 >= 160ns
16Gb tRFC1 >= 550ns, tRFC2 >= 350ns, tRFC4 >= 260ns
CLK換算だと (DDR4-2400)
4Gb tRFC1 >= 312, tRFC2 >= 192, tRFC4 >= 132
8Gb tRFC1 >= 420, tRFC2 >= 312, tRFC4 >= 192
16Gb tRFC1 >= 660, tRFC2 >= 420, tRFC4 >= 312
参考) http://egg.2ch.net/test/read.cgi/jisaku/1498815128/978 1台のマシンが組み上がりました。。。
新しい筐体を用意してくださいです。。。。
自作PC板＠2ch http://anago.2ch.net/jisaku/
life time: 17日 12時間 19分 48秒 ２ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ ２ちゃんねる専用ブラウザからの広告除去
★ ２ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.2ch.net/
▼ 浪人ログインはこちら ▼
https://login.2ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
