17/07/01 18:57:19.79 Y/Kt/HDRM.net
エラッタをソフト側で吸収してくれるコンパイラってことかもな
そもそもエラッタではなく仕様ですAMDのコンパイラ使ってくださいと言われたら終わりな話に
55:Socket774 (ﾜｯﾁｮｲ 2e63-k1q/)
17/07/01 18:58:34.02 WW/T/mcD0.net
まあ仮にそういうことだとしたら、
AMDがそれでいいと判断したならそれが全てだな
56:Socket774 (ﾜｯﾁｮｲ 42c4-OZRj)
17/07/01 19:01:49.92 MoMk/IOn0.net
Haswell向けのコード走らせたらフリーズするやつ思い出す
57:Socket774 (ﾜｯﾁｮｲ 2d63-CicO)
17/07/01 19:09:49.45 IrZEpoL90.net
>>54
なるほど解りやすい
58:Socket774 (ﾜｯﾁｮｲ c103-edpK)
17/07/01 19:37:31.63 rzVPMPVv0.net
>>44
何ループくらいOKでした？
パス代えるだけで行けますか？
59:Socket774 (ﾜｯﾁｮｲ c103-edpK)
17/07/01 19:43:24.89 rzVPMPVv0.net
twitter勢でAMDから替え玉来た人の見たけど
手元の1700とmicrocode一緒だ
60:Socket774 (ﾜｯﾁｮｲ 425f-X7Kb)
17/07/01 19:45:58.78 0on31ltG0.net
>>59
URL頼んます
61:Socket774 (ﾜｯﾁｮｲ c167-XQUB)
17/07/01 19:58:20.44 z1mI5osj0.net
>>58
実行ファイルを新しい奴で上書き
20000回でNGなし
62:Socket774 (ｵｯﾍﾟｹ Sr71-E8g9)
17/07/01 19:58:50.21 CEGrKWBJr.net
5/1付でAMDの対応は終わっていた訳だな
そりゃあフォーラムから追い出されたりAMDに塩対応されたりしても仕方無いわ
63:Socket774 (ﾜｯﾁｮｲ b175-ImDA)
17/07/01 20:08:22.16 FdZURsFs0.net
B1
URLﾘﾝｸ(mobile.twitter.com)
64:Socket774 (ﾜｯﾁｮｲ 425f-X7Kb)
17/07/01 20:10:55.57 0on31ltG0.net
>>63
自分のも同じだった
65:Socket774 (ﾜｯﾁｮｲ 426e-D66J)
17/07/01 20:38:18.70 ejAhFLTl0.net
素人ながらに少し調べてみたんだが
AMDフォーラムではLow-Latence-Kernel（ASLRオフ）で60時間以上エラーなしということで
このカーネルがどう違うのかという所でubuntu studioのwikiより
・カーネルにCONFIG_PREEMPT_RTパッチを適用したリアルタイムカーネルを利用する
・カーネルの設定を変更しタイマー割り込みの頻度を増やす
・PAMの設定を変更し、アプリケーションのカーネル・スケジューラー内での処理の優先度を変更する
ここでタイマー割り込みの頻度を増やすという所をまず調べてみた
かなり古い記事なんだけどここを見ると
URLﾘﾝｸ(www.atmarkit.co.jp)
カーネル2.6.13-rc1にて、タイマー割り込みの頻度「HZ」がデフォルト1000から250に変更されている
今現在のカーネルのデフォルト値がどうなのか分からないが取りあえず1000に戻してみるのもいいかもしれない
（ubuntu studioは1000）
＞割り込み頻度（つまりHZの値）を歴史的に見ると、
＞例えばi386アーキテクチャにおいては「100」というように、
＞アーキテクチャごとにそれぞれの値が設定されていました。
ともあるようにデフォルト値ではZenアーキにそぐわない値なのかもしれない
PAM設定というのがよくわからないのだけれども
処理の優先度を変更は具体的にどう変更したらいいのかはわからない
詳しい人補足・修正よろしく
66:Socket774 (ﾜｯﾁｮｲ 61be-+k/C)
17/07/01 20:39:48.88 OfdPNs6P0.net
この騒動起こした本人の土下座はまだかね
67:Socket774 (ﾜｯﾁｮｲ c103-edpK)
17/07/01 20:41:22.31 rzVPMPVv0.net
>>61
ありがと
>>60
例のkernel開発者様がretweetしてるよ
68:Socket774 (ﾜｯﾁｮｲ 425f-X7Kb)
17/07/01 20:46:14.24 0on31ltG0.net
>>67
自分のSEGV出る1700も同じだったよ
メモコンの出来にバラツキがあってメモリとの相性が悪いだけなのかも
69:Socket774 (ﾜｯﾁｮｲ 2e5c-uerO)
17/07/01 20:59:41.84 fg4ZRu/30.net
まとめるとこんな感じかな。
WinでもLinuxでも汎用カーネル使うと色々問題が起こるから
Zen用にチューンしたカーネルをWinでもLinuxでも使ってね(ASLRがOFFってセキュリティ的にどうなんだ感があるが)。
そして、汎用カーネルだと既存のソフトで問題が生じる場合があるから、その時は
Zen用のWin/Linuxコンパイラでコンパイルしたのを使ってねと言うことだろう。
と言ううことで、時期にMSがZen用Winカーネル、そして、AMDがWin用コンパイラ出すだろう。
70:Socket774 (ﾜｯﾁｮｲ 426e-D66J)
17/07/01 21:15:58.67 ejAhFLTl0.net
WINDOWSに関してはRyzenが乗ってるマシンにアプデでパッチ当てれば済むだろうね
71:Socket774 (ﾜｯﾁｮｲ f9b4-ahFv)
17/07/01 21:17:50.78 fz72Ccm70.net
>>65
250ってマジか
WindowsみたいなクソデブOSでも1000なのに
72:Socket774 (ﾜｯﾁｮｲ 6187-k1q/)
17/07/01 21:29:40.66 EEZQHSVK0.net
>>69
まとめるまえに、カーネルがなんなのかを勉強したほうがいいよ。
73:Socket774 (ﾜｯﾁｮｲ 2e63-k1q/)
17/07/01 21:38:33.40 WW/T/mcD0.net
>>71
大きけりゃいいってもんじゃないからな
リアルタイム用途、デスクトップ、サーバーでは最適な値は異なる
Windowsも単純に1msの割り込みということではなかったはずだが？
timeBeginPeriodの設定値とかによって変動するはず
そして、Linuxでは最近は一定の割り込み周期じゃないTicklessカーネルになってたような
74:Socket774 (ﾜｯﾁｮｲ 6d84-DVJb)
17/07/01 21:41:47.97 JvIBA16V0.net
AMDがどうのではなく
検証コードをclangでビルドしても再現しないってだけじゃないのという気もする
75:Socket774 (ﾜｯﾁｮｲ c5c8-a07H)
17/07/01 21:42:38.42 KpktUIoQ0.net
結局戦犯はコンパイラだったということ？
76:Socket774 (ﾜｯﾁｮｲ 426e-D66J)
17/07/01 21:53:06.39 ejAhFLTl0.net
>>73
分からないので調べた
ticklessでアイドル時間を長くして消費電力を抑えるということですな
これだけがエラーを引き起こす原因だとは言えないのですね
URLﾘﾝｸ(sssslide.com)
URLﾘﾝｸ(mako-limone.blogspot.jp)
それとは関係なくPAM設定による優先設定なんかは分かりますか？
77:Socket774 (ﾜｯﾁｮｲ c103-edpK)
17/07/01 21:54:33.13 rzVPMPVv0.net
clangでもmakeでエラー出たって
amdの公式スレに書かれてたから
gccだけの問題ではないかもしれないし
別かもしれない
78:Socket774 (ﾜｯﾁｮｲ 2e5c-wjSU)
17/07/01 21:59:14.16 nlNUMe+k0.net
AMDはもうとっくに原因解析してわかってるはず
なぜダンマリなのかはわからん
１．BIOSアップデートで対応可能、後日発表
２．BIOSで修正不可、コストがかかる全数リコールしなくてもいいように、
法務や弁護士等と対応策を打ち合わせてる
このどちらかとおもう
案外２．なのでは？
79:Socket774 (ﾜｯﾁｮｲ 6d84-DVJb)
17/07/01 22:02:56.96 JvIBA16V0.net
一応補足
例の検証コードはCPUの内部状態がある特定の状態になったら異常が起きるのではという仮定のもと
最小限の特定の命令パターンを実行することでそれを再現しようとしているので
コンパイラが変わることで微妙に動作が変わり再現しなくなってもおかしくはない
よって、あるコンパイラでこの検証コードをビルドしてもNGが出ないからといって
検証コード以外でもそのコンパイラを使えば常にOK、という話ではない
80:Socket774 (ﾜｯﾁｮｲ c103-edpK)
17/07/01 22:16:27.48 rzVPMPVv0.net
>>78
せめてAMD公式スレに社内で再現した再現しないよ程度のレスは欲しいですね
見落としかもしれませんが
81:Socket774 (ﾜｯﾁｮｲ 428c-jrEh)
17/07/01 22:17:56.07 iXGoeVAy0.net
ポインタが不可解にズレること自体は事実なんだよね？
そこんとこはっきりしてほしい
82:Socket774 (ﾜｯﾁｮｲ c103-edpK)
17/07/01 22:36:36.61 rzVPMPVv0.net
>>81
URLﾘﾝｸ(www.e-hdk.com)
83:Socket774 (ﾜｯﾁｮｲ c103-edpK)
17/07/01 23:47:22.10 rzVPMPVv0.net
スレの範疇を超えてるので回答がないね
>>76
済まない何が知りたいのか良く解らないけど
見てると思われるubuntu studio wikipedia日本語の内容は古いので
PAM認証は忘れて英語版を見て欲しいってのと
公式スレでlowlatencykernelって言ってる人は
perf: interrupt took too longメッセージを
回避するにはコアのロックが問題っぽいので
方法としてコレを試したら安定したって所を
ゆっくり読んで欲しい
（内容が正しいとは言ってない）
なんとかtimerのdefault設定とか知りたいならできるだけ
新しいmenuconfigによるkernel設定などをググってみると
全貌が掴めるかも
84:Socket775 (ﾜｯﾁｮｲ 61be-+k/C)
17/07/02 00:19:17.03 YLeJweeH0.net
>>75
結論はそういうことだ
コンパイラ側の調整不足
AMDはRYZEN用にコンパイラ公開してるし答える必要も無いと判断してると思うぞ
85:Socket774 (ﾜｯﾁｮｲ c103-edpK)
17/07/02 00:23:30.61 MBJ3PhJy0.net
って書いてたら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
後はなんだっけ？
86:Socket774 (ﾜｯﾁｮｲ c103-edpK)
17/07/02 00:25:57.23 MBJ3PhJy0.net
次はclang/llvmで検証かな
URLﾘﾝｸ(community.amd.com)
87:Socket774 (ﾜｯﾁｮｲ 426e-D66J)
17/07/02 00:48:35.10 A6bW7S6z0.net
>>83
ありがとう
OSだとかLinuxなんか特に分からないから
指摘されたところ調べてみるわ
88:Socket774 (ﾜｯﾁｮｲ 2e5c-uerO)
17/07/02 00:54:21.38 J53tUuZp0.net
RyzenはIntelと比較してあんまりコンパイル性能が良くないんだよな
(他のベンチ性能はそれなりに良いんだけど)
URLﾘﾝｸ(www.anandtech.com)
Ryzenは今回のSEGVと言いなんかコンパイルは激しく苦手なのかな
89:Socket774 (ﾜｯﾁｮｲ 2ea3-W7+W)
17/07/02 02:15:28.05 1KG6GYLL0.net
>>88
コンパイル性能ってなに？
90:Socket774 (ﾜｯﾁｮｲ c5c8-a07H)
17/07/02 02:25:42.36 tU+tq0050.net
というかEPYCのレビュー色々見たけどSEGVのことスルーして絶賛ばかりだな
それもWindows上のベンチだけじゃなくSPECとか測ってるような連中が
サーバーで致命的とかいう話は何処にいったんだろう
91:Socket774 (ﾜｯﾁｮｲ 6e74-uerO)
17/07/02 03:42:37.41 TZ+M2J1n0.net
>>88
VisualStudio2015とか7zipとか古い結果と比較できるように2年以上前の使ってるんじゃないかな
全部取り直すなら最初からVS2017使えば良いわけで
SDKも15063使わないならスレッドの割り当てうまくいかなくて遅くなるかもね
まぁ2017は拡張機能とか対応してるのが2015より少ないから手動で環境変数設定したりちょっと面倒な点はあるけど
それが出来ないほどアホじゃないだろうし
92:Socket774 (ﾜｯﾁｮｲ 61be-+k/C)
17/07/02 03:55:02.16 YLeJweeH0.net
この騒動は次のステージに突入
交換要求したがB1送られる
石はテストで問題無い物が送られてるのは当然でB1には問題ないことが判明
交換品で問題出たらコンパイラ側の設定や最適化に問題
AMDはryzen用に謹製コンパイラ公開済み
satと取り巻きは早とちりの土下座レベル
93:Socket774 (ﾜｯﾁｮｲ b16a-ImDA)
17/07/02 05:28:31.26 UbBDqQPp0.net
メモリ、マザーボードの初期不良同様3回目の修理に出して販売店や代理店に任せておけばいいものを
早とちりというよりはフリーランスになったから自分の宣伝をしたかったんだろう
6月24日に広報とか言ってるツイートがあるが、この言葉が本音を表しているとしか思えない
94:Socket774 (ﾜｯﾁｮｲ 425f-X7Kb)
17/07/02 12:43:13.22 rzgx1i0Q0.net
替えのCPU届いた人、交換後はエラー出てないようだ
エラッタじゃなくて不良品だったということなのかな
95:Socket774 (ﾜｯﾁｮｲ c5c8-a07H)
17/07/02 13:26:46.87 tU+tq0050.net
中身はRyzenPro同等品だったりして
企業向けな分選別厳しそうだからそれをクリアしたものなら出無さそう
96:Socket774 (ﾜｯﾁｮｲ 6174-R8v4)
17/07/02 13:39:30.12 MItDo5em0.net
ryzen買ったらgccで動作確認するのが当たり前だよね
ってか？
97:Socket774 (ﾜｯﾁｮｲ c5c8-a07H)
17/07/02 13:42:18.05 tU+tq0050.net
OCしてOCCTやPrime95動かすのと似たようなもんでしょ
98:Socket774 (ﾜｯﾁｮｲ c23b-WwN4)
17/07/02 13:50:45.65 Vq/ULSbh0.net
自分もb2待ちだけど、cygwin使う事前提なんだよね
cygwinのgccも大丈夫だろうか？＜b2
99:Socket774 (ﾜｯﾁｮｲ 6e74-d1DY)
17/07/02 14:51:39.49 TZ+M2J1n0.net
>>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即落ちってのもあった
100:Socket774 (ﾜｯﾁｮｲ 2e63-k1q/)
17/07/02 15:00:49.95 BTrSzPRI0.net
俺の1700はPrime95なら何時間でもパスするけど、
NGは即出るわ
101:Socket774 (ﾜｯﾁｮｲ 425f-X7Kb)
17/07/02 15:15:38.07 rzgx1i0Q0.net
>>99
俺環ではPrime95 FFTsize=384ての試して問題ないけどNG出たよ
メモリHynixだけどね
102:Socket774 (ﾜｯﾁｮｲ c1e5-CicO)
17/07/02 16:26:13.52 JCU0d2D50.net
>>92
ソースどこ？
しかし石の交換だけで直ったのなら
なおさら石の不良ということにならないか？
103:Socket774 (ｽｯﾌﾟ Sd62-Pf3w)
17/07/02 16:27:55.86 KybUHtmtd.net
クレーマーに対してだけ選別品に交換
104:Socket774 (ﾜｯﾁｮｲ c21d-nP2k)
17/07/02 16:38:45.63 3ud9yQM60.net
交換したやつも早速エラー出てるじゃん
105:Socket774 (ｽｯﾌﾟ Sd62-Pf3w)
17/07/02 16:39:56.67 KybUHtmtd.net
なんだ、ガセかよ
>>92
106:Socket774 (ﾜｯﾁｮｲ 4667-nP2k)
17/07/02 16:48:47.45 Q1kGwoA70.net
>>104
おま環臭がする
107:Socket774 (ｽｯﾌﾟ Sd62-Pf3w)
17/07/02 16:52:41.44 KybUHtmtd.net
おま環だからCPUに問題がないなんてことはないんだけど
108:Socket774 (ﾜｯﾁｮｲ c5c8-a07H)
17/07/02 16:53:47.45 tU+tq0050.net
このスレの人たちですら実用上問題ないと言ってるからな、普通に使ってる人はSEGVの存在すら知らないだろう
109:Socket774 (ﾜｯﾁｮｲ 0653-nP2k)
17/07/02 18:35:30.23 IIm9oWiW0.net
>>107
だったらCPUに問題があることを証明しろよ…
110:Socket774 (ﾜｯﾁｮｲ 2e5c-+k/C)
17/07/02 18:42:44.53 lyWo1AGy0.net
段々とsatと取り巻きのエラー検証に無理が来てるのが分かる
普通に考えて交換品で問題あるやつ送るわけないだろ
さっさと土下座しとけって
111:Socket774 (ﾜｯﾁｮｲ c103-edpK)
17/07/02 18:50:40.64 MBJ3PhJy0.net
吉報かな？
gcc 7.1.1 (fedora26beta)
56scriptでkernel make -j16
1100回回してエラー0
環境は前回と同じ(hddは外した)
一周20秒ってなんか爆速なんだが
make cleanはしてるみたいだ
出来る人は追試頼みます
112:Socket774 (ﾜｯﾁｮｲ c103-edpK)
17/07/02 19:00:37.61 MBJ3PhJy0.net
厳密にはmake対象のstable kernelが
.7から.8に変わってる(kernel.org側)
fedora側も同じ系統
後はカーネル屋さん達に任せよう
113:Socket774 (ﾜｯﾁｮｲ b164-ImDA)
17/07/02 19:01:00.98 1+B9hEtV0.net
>>63の人は交換品も出ている
URLﾘﾝｸ(mobile.twitter.com)
114:Socket774 (ﾜｯﾁｮｲ c23b-WwN4)
17/07/02 19:04:44.82 Vq/ULSbh0.net
なんか、linuxの環境変数が変な値を設定していて
それを忘れていて、実行してエラーとか、
そういう気配すら感じる
ハード的・ソフト的両面でおま環・・・・
115:Socket774 (ﾜｯﾁｮｲ b175-ImDA)
17/07/02 19:05:20.91 jLxLJdn00.net
そういえばRedHat系で出た話は聞かないな
116:Socket774 (ﾜｯﾁｮｲ c103-edpK)
17/07/02 19:19:26.07 MBJ3PhJy0.net
fedora25/CentOS7では試してないので
比較したら面白いかも
でもなんでこんなに早くなったのか
全然わからん
117:Socket774 (ﾜｯﾁｮｲ 2e5c-+k/C)
17/07/02 19:22:47.78 lyWo1AGy0.net
sat周辺は苦しい言い訳続いてるわ
交換品まで文句つける有り様
118:Socket774 (ﾜｯﾁｮｲ b1c0-ImDA)
17/07/02 19:50:59.86 YN7u6avN0.net
B2送られてくると思い込んでたら送られてきたのがB1だから目論見外れて日和ってんだろ
119:Socket774 (ﾜｯﾁｮｲ 425f-X7Kb)
17/07/02 20:21:55.43 rzgx1i0Q0.net
結局エラー出たのかよ
あとはB2でもエラーでるかどうかか
120:Socket774 (ﾜｯﾁｮｲ 6e74-d1DY)
17/07/02 22:08:47.00 TZ+M2J1n0.net
そもそもSEGVを理由にすれば当りを引けるまで何度でもおかわり出来る時点で問題だな
そのうち交換品を代理店側でチェックしてからじゃないと発送しないとかになりそう
121:Socket774 (ﾜｯﾁｮｲ 06dd-ynbO)
17/07/02 22:11:18.87 5qzhcyz50.net
エラッタじゃなかったのか…
122:Socket774 (ﾜｯﾁｮｲ c167-XQUB)
17/07/02 22:15:13.67 oLO6ZR+W0.net
誰かAMDのコンパイラーで実験してむてくれ
123:Socket774 (ﾜｯﾁｮｲ 2e63-izR5)
17/07/02 22:15:49.34 BTrSzPRI0.net
どんな不具合があろうと、AMDが公式に記載するまではエラッタではない
エラッタってどういう意味の言葉だと思ってる？
124:Socket774 (ﾜｯﾁｮｲ 2d63-CicO)
17/07/02 22:49:04.33 SH3p82Xk0.net
調べてきた
エラッタ 【 errata 】 エラータ
誤字、誤植、誤写などの意味を持つ英単語。
また、転じて、印刷物の誤字などの訂正表、正誤表という意味もある。
“errata” は複数形(「正誤表」の意味では単数形)で、単数形は “erratum”。
半導体の分野では、LSIチップの論理回路などに存在する
構造上の欠陥や設計ミスなどのことをエラッタということがある。
また、出荷後の製品に存在するそうした欠陥や本来の仕様との相違などを
まとめた文書のことをエラッタという場合もある。
ふんわりしててよくわからないや
125:Socket774 (ﾜｯﾁｮｲ 422e-Vv/M)
17/07/02 22:54:12.06 YNSGkrzE0.net
認めない限りエラッタじゃない、てことか。
126:Socket774 (ﾜｯﾁｮｲ 2e63-k1q/)
17/07/02 22:54:51.64 BTrSzPRI0.net
本来は正誤表という意味
そこから派生して、「本来の仕様との相違などをまとめた文書」が半導体の文脈でいうエラッタ
つまり文章にまとめられるまではいくら状況証拠的に不具合があろうとそれはエラッタではない
127:Socket774 (ﾜｯﾁｮｲ 2d63-CicO)
17/07/02 22:59:08.02 SH3p82Xk0.net
>>126
なるほど
128:Socket774 (ﾜｯﾁｮｲ 2e63-k1q/)
17/07/02 23:02:44.96 BTrSzPRI0.net
とはいえ、ソーシャルゲームなどの「課金」の誤用と同じで、
単なる不具合のことをエラッタと称する流れはもはや止めようがなくて、
新しい言葉の使い方として受け入れなければいけない時は近いなぁと諦めかけてはいる
129:Socket774 (ﾜｯﾁｮｲ c537-ahFv)
17/07/02 23:10:07.84 fPqSZgVT0.net
>>128
違う呼び方を広まらせればええんやで
適正な単語がないからそう呼ばざるを得ないからであって、それを与えれば当然呼び分けると思うよ
130:Socket774 (ﾜｯﾁｮｲ 2e63-k1q/)
17/07/02 23:17:41.67 BTrSzPRI0.net
>>129
いやそれなら不具合とか誤動作とかいくらでも既存の用語で言いようはあるでしょ
131:Socket774 (ﾜｯﾁｮｲ 9235-k1q/)
17/07/02 23:18:55.60 tesaY+Tz0.net
hardware bugでしょ
132:Socket774 (ﾜｯﾁｮｲ 2e63-k1q/)
17/07/02 23:19:27.87 BTrSzPRI0.net
それのほうがいいなｗ
133:Socket774 (ｽｯﾌﾟ Sd62-Pf3w)
17/07/02 23:25:33.86 KybUHtmtd.net
おまいら、エラッタの意味を知らないで使ってたのか
134:Socket774 (ﾜｯﾁｮｲ c1e5-CicO)
17/07/02 23:35:54.37 JCU0d2D50.net
エライコッタ
135:Socket774 (ﾜｯﾁｮｲ c103-edpK)
17/07/02 23:37:46.21 MBJ3PhJy0.net
Fedora25 ｲﾝｽｺ & dnf up 終了
25の4.8.6だとまだzen未対応かな?
gcc 6.3.1
10回20回だとエラー出ないのが普通なので
最低50出来れば100回は必要だけど
今回は１回あたり1分30秒位な模様
念のため一番最初にmake cleanした
結果は明日
136:Socket774 (ﾜｯﾁｮｲ c5c8-a07H)
17/07/02 23:38:23.10 tU+tq0050.net
>>126
そういう屁理屈は別にいいんよ
バグでもエラーでも不具合でも不良でも言葉や意味の差に興味はない
結局何が悪かったのかだろう
137:Socket774 (ﾜｯﾁｮｲ 2e63-k1q/)
17/07/02 23:50:15.36 BTrSzPRI0.net
>>136
＞結局何が悪かったのかだろう
んなことはAMDしかわからんのじゃボケ
138:Socket774 (ﾜｯﾁｮｲ f9b4-ahFv)
17/07/03 00:14:50.94 UgXlfvbR0.net
AMDから出てる資料で手に入らないものが多いから何とも
BKDG欲しい
139:Socket774 (ﾜｯﾁｮｲ 6187-k1q/)
17/07/03 00:34:53.32 SxqwPHE10.net
>>138
URLﾘﾝｸ(support.amd.com)
ここにないのかね？
140:Socket774 (ﾜｯﾁｮｲ c937-Pf3w)
17/07/03 00:35:41.14 e1KME8Um0.net
>>136
AMDが悪い
ということだけはわかる
141:Socket774 (ｵｲｺﾗﾐﾈｵ MMd6-ynbO)
17/07/03 01:02:28.22 Z65Du+ckM.net
>>140
君のおつむが悪いのはわかる
142:Socket774 (ｱｳｱｳｳｰ Sa25-ahFv)
17/07/03 02:21:29.79 K3Cfl1opa.net
>>139
残念ながら最新のものでもFam15h-60h-6FhだからK15.3、つまりExcavator迄だな
一応今調べてみたらAPMが軒並み更新されてた
#24593とか
143:Socket774 (ｲﾓｲﾓ Se86-3z8c)
17/07/03 07:31:09.41 4ZptWAj5e.net
キャッシュ管理をAIなんかに
やらせてるから挙動が予測しずらいじゃないか？
144:Socket774 (ﾜｯﾁｮｲ 6187-k1q/)
17/07/03 09:49:56.11 SxqwPHE10.net
>>143
名前がそれっぽいだけだから、あれは
145:135 (ﾜｯﾁｮｲ c103-edpK)
17/07/03 12:24:56.03 M6eJiJzJ0.net
うーん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:Socket774 (ﾜｯﾁｮｲ 425f-X7Kb)
17/07/03 12:30:13.42 i3kjPewc0.net
>>145
マザーとメモリは何？
147:135 (ﾜｯﾁｮｲ c103-edpK)
17/07/03 18:29:01.83 M6eJiJzJ0.net
色々書いてたら2chgear落ちたよ...
148:135 (ﾜｯﾁｮｲ c103-edpK)
17/07/03 18:38:06.93 M6eJiJzJ0.net
>>146
構成は>>85に書いた通りで
マザーのUEFIは最初から2.50に本能的に上げてある
メモリ補足するとcorsairのryzen対応メモリ
2666 x 2枚組でdual channel
たったいま800回OK到達した
NG出てない
xubuntu17.04だと50回以内に出たんで
ハードが原因なの？って気はする
memtestしてないとか初期BIOSのままとかの人は別として
149:Socket774 (ｵｲｺﾗﾐﾈｵ MMd6-PC1I)
17/07/03 18:58:27.32 tTzlvh4EM.net
3.0GHz固定？
150:135 (ﾜｯﾁｮｲ c103-edpK)
17/07/03 19:27:52.47 M6eJiJzJ0.net
>>149
boostの話だったら無効にはしてない
クロックの話ならocもdcもしてない
メモリもね
151:135 (ﾜｯﾁｮｲ c103-edpK)
17/07/03 19:28:56.98 M6eJiJzJ0.net
そもそもboost切る項目ってあったかな
今見れないし
152:135 (ﾜｯﾁｮｲ c103-edpK)
17/07/03 21:05:16.87 M6eJiJzJ0.net
manjaro kernel 4.11.7-1(guiで上げた)
gcc 7.1.1で4.11.8一周1:46秒と速い
これで明日まで回してみる
153:135 (ﾜｯﾁｮｲ c103-edpK)
17/07/04 05:52:44.60 vcQG7X9e0.net
manjaro make 300回ノーエラーで回った
NG出そうな気もしないので止めようか迷ってる
構成で書き忘れてたけどradeon r5 230 1GB で manjaroはnon-free driver
他OSでは指定無し
もう一回xubuntu17.04やり直しするか
または他の道(bsd)に行くかお悩み中
AOCCでkernel makeは多分やらない(ムズそう)
154:135 (ﾜｯﾁｮｲ c103-edpK)
17/07/04 06:39:41.11 vcQG7X9e0.net
まとめ
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設定が何か変わった可能性(低い)
を消していかないといけないが全部は無理っす
長文ｽﾏｿ
155:Socket774 (ｵｲｺﾗﾐﾈｵ MMd6-PC1I)
17/07/04 06:41:47.42 lq/Bx23wM.net
コピペ
スケジューラー怪しいぞ
関係あるのか知らないがなんか来てる
Scheduler Improvements Set For Linux 4.13
URLﾘﾝｸ(www.phoronix.com)
scheduler changes for v4.13
URLﾘﾝｸ(lkml.iu.edu)
156:Socket774 (ｵｲｺﾗﾐﾈｵ MMd6-PC1I)
17/07/04 06:43:22.44 lq/Bx23wM.net
>>154
おつ
157:Socket774 (ﾜｯﾁｮｲ 61c6-wjSU)
17/07/04 06:56:22.56 A8jXZE/D0.net
>>154
検証乙
158:Socket774 (ｵｲｺﾗﾐﾈｵ MMd6-ynbO)
17/07/04 07:35:01.29 Cg/Hup+qM.net
Linux欠陥だらけで普及してない
159:Socket774 (ｽｯｯﾌﾟ Sd62-GoLR)
17/07/04 07:58:49.80 YFrdfBmUd.net
>>158
Androidから書き込んどいて何言ってんだ
160:Socket774 (ﾜｯﾁｮｲ f9b4-ahFv)
17/07/04 08:45:01.62 VdnAyj8O0.net
泥初期は地獄でした、、、
161:Socket774 (ｵｲｺﾗﾐﾈｵ MMd6-ynbO)
17/07/04 09:41:31.45 Cg/Hup+qM.net
>>159
それLinuxとは違うよ
162:Socket774 (ｵｯﾍﾟｹ Sr71-W7+W)
17/07/04 11:02:58.39 rD5zL4cFr.net
>>161
カーネル違うの？
初耳だ
163:Socket774 (ｵｲｺﾗﾐﾈｵ MMd6-ynbO)
17/07/04 11:15:16.53 Cg/Hup+qM.net
>>162
そもそも関係ないから
164:Socket774 (ﾜｯﾁｮｲ 2eec-CicO)
17/07/04 12:16:51.14 wOCmEgdp0.net
前スレでキャッシュ階層エラーを書いたものだが
CPU交換したら治った
165:135 (ﾜｯﾁｮｲ c103-edpK)
17/07/04 12:21:26.86 vcQG7X9e0.net
>>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もやってみよ
166:Socket774 (ｵｲｺﾗﾐﾈｵ MMd6-PC1I)
17/07/04 12:31:46.66 hUV2Z1DMM.net
debian問題なさそうなのか
debianベースにしたubuntuとは何なのか
167:135 (ﾜｯﾁｮｲ c103-edpK)
17/07/04 14:10:40.01 vcQG7X9e0.net
検証人が増えることを願って
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/を../とかに変更
168:Socket774 (ｵｲｺﾗﾐﾈｵ MMd6-ynbO)
17/07/04 14:11:40.46 oidkhAJ7M.net
>>162
ｽﾚﾘﾝｸ(linux板:429番)
169:135 (ﾜｯﾁｮｲ c103-edpK)
17/07/04 14:36:01.82 vcQG7X9e0.net
debian9.0で209回目に4.11.8のmakeでsegfault出現した
これで4.11.7と8の違いの線は消えたと
あと最低回数が210回になる
確率の問題だけど
次はubuntu 16.04.02で追試かな
範囲が段々狭まってきた
170:Socket774 (ﾜｯﾁｮｲ 6174-R8v4)
17/07/04 15:07:12.94 LUEGUcoR0.net
コアダンプはどうしてるん
171:Socket774 (ｱｳｱｳｳｰ Sa25-CicO)
17/07/04 15:36:15.96 FGDutGKNa.net
Linuxの問題じゃないCPUの問題なんだああああああああああああ
って主張してた自称ソフト屋さん息してるの？
172:135 (ﾜｯﾁｮｲ c103-edpK)
17/07/04 15:43:25.26 vcQG7X9e0.net
>>170
スクリプトで回してるのでその場で止めてないし
gdbもよく知らないからスルー
そういうのは得意な人に任せます
こっちは環境による発生頻度の違いを見てる
ただの自作erに出来るのはその程度
一応nativeに拘って仮想は使ってない
本音は8コア16スレッド+NVMのスピードで
ﾋｬｯﾊｰしたいだけwww
htopが真っ赤っかだぜー
173:Socket774 (ﾜｯﾁｮｲ 426c-Wf61)
17/07/04 16:10:22.92 zgUempLj0.net
>>54
それ、既存バイナリの動作を保証しないと言ってるに等しいけどそういうことなの？
174:Socket774 (ｽｯﾌﾟ Sdc2-CG5Q)
17/07/04 16:14:19.12 dW/ewFsId.net
CPUのエラッタを回避する特殊なコンパイラが提供されたら、
既存の普通のコンパイラをバグ扱いする頭の弱い人がいるからね
175:Socket774 (ﾜｯﾁｮｲ 6187-k1q/)
17/07/04 16:21:29.59 0K0v5KUL0.net
>>174
特殊でもなんでもなく、普通に回避してると思うけど。
エラッタは公表された時点で、ほぼ仕様と化すからねぇ。
176:Socket774 (ﾜｯﾁｮｲ 0653-nP2k)
17/07/04 16:24:16.63 JZRVqQvT0.net
>>174
状況がよくわかってないことがよくわかるw
177:Socket774 (ｽｯﾌﾟ Sd62-Pf3w)
17/07/04 17:12:11.46 ZfRSUEzad.net
OSならともかく、普通のアプリが特定のCPUのエラッタ回避なんてしないよ
178:Socket774 (ﾜｯﾁｮｲ 6187-k1q/)
17/07/04 17:35:39.34 0K0v5KUL0.net
>>177
コンパイラのはくコードのこといってんじゃないの？
てか、アップデートで回避するとおもうよ、まともな会社のアプリなら
179:Socket774 (ﾜｯﾁｮｲ 6e63-BKVk)
17/07/04 18:04:19.90 fmX08bB60.net
X370carbonの人、BIOSベータ3来た
今回は来るの早かった
但し手持ちのMateではベータ3にしても改善しなかった
AGESAがバージョンアップしないと変化は期待できない可能性があるのでそのつもりでどうぞ
180:Socket774 (ﾜｯﾁｮｲ 6e63-BKVk)
17/07/04 19:16:07.04 stZoFlOw0.net
X370carbonは正式版1.7も出てた
試すならこっちの方がいいかも
181:Socket774 (ｽｯﾌﾟ Sd62-Pf3w)
17/07/04 20:36:14.56 ZfRSUEzad.net
>>178
しないしないwww
182:Socket774 (ﾜｯﾁｮｲ 1987-H6j/)
17/07/04 20:44:15.11 WAoveGpA0.net
完全におま環だけどFedora25にしたらむしろセグメンテーション違反が増えた
ubuntu16.04だと100回に1,2回程度だったけど、現在は10回に4回は発生してる
183:135 (ﾜｯﾁｮｲ c103-edpK)
17/07/04 20:51:43.58 vcQG7X9e0.net
>>182
それはすごいですね
構成教えて
184:Socket774 (ｽｯﾌﾟ Sd62-Pf3w)
17/07/04 20:52:53.98 ZfRSUEzad.net
>>182
解析よろしく！
185:182 (ﾜｯﾁｮｲ 1987-H6j/)
17/07/04 20:54:49.94 WAoveGpA0.net
Fedora25でビルドしてたのが4.12だったわｗ
4.11.8にしたら即NG出てたのがなくなったのでとりあえず流し続けてみる
186:Socket774 (ﾜｯﾁｮｲ 0651-Ut2Z)
17/07/04 21:12:04.42 44fyhJ2z0.net
>>179
おけー、やってみる
187:Socket774 (ﾜｯﾁｮｲ 2e5c-vtNh)
17/07/04 21:19:33.10 0x2sCf7L0.net
>>174
普通逆なんだよ
こんなんだからsat周辺はゴミ扱いされてんの
188:Socket774 (ﾜｯﾁｮｲ 6e63-BKVk)
17/07/04 21:37:49.19 stZoFlOw0.net
>>185
Kernel4.12のビルドでSEGV？出るのはRyzen関係ないのかね？
Intel環境で4.12のビルド試せば分かる話だが
189:135 (ﾜｯﾁｮｲ c103-edpK)
17/07/04 21:42:31.58 vcQG7X9e0.net
>>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ではない)
190:Socket774 (ﾜｯﾁｮｲ 6187-k1q/)
17/07/04 21:49:42.79 0K0v5KUL0.net
>>181
なんのことを指して回避といっているのかわからんけども、
インテルもしくはAMDの公表したエラッタには普通、ワークアラウンドが用意されている。
それに従って改変したものは、当然ｘ８６バイナリであるから、
エラッタのあるCPUで正常に動かなかったものが、単にすべてのx86CPUで動くようになるだけだよ。
そして、アセンブラで書いてない限りは、更新されたコンパイラでリビルドするだけさね。
191:Socket774 (ﾜｯﾁｮｲ c937-Pf3w)
17/07/04 21:57:49.85 eUNtuxMG0.net
大量に存在するx86コードを全てリビルド？
ないない
192:Socket774 (ﾜｯﾁｮｲ c937-Pf3w)
17/07/04 21:58:33.67 eUNtuxMG0.net
リビルドするってことは評価もやり直し
193:Socket774 (ﾜｯﾁｮｲ c937-Pf3w)
17/07/04 22:00:28.08 eUNtuxMG0.net
OSやBIOSで対応出来るなら対応するだろうけど
194:Socket774 (ﾜｯﾁｮｲ 0651-Ut2Z)
17/07/04 22:03:52.96 44fyhJ2z0.net
>>189
え？
一周80sで終わるってこと？
いくらなんでも早すぎ
195:Socket774 (ｵｯﾍﾟｹ Sr71-E8g9)
17/07/04 22:11:06.62 EtivTfMar.net
Skylakeには膨大なx86資産（16bitバイナリ）の正常な動作を保証できないという重大かつ致命的な欠陥があるよね
196:Socket774 (ﾜｯﾁｮｲ 6187-k1q/)
17/07/04 22:11:50.89 0K0v5KUL0.net
>>191
なんのことを言ってるのかわからないんですけど。
197:182 (ﾜｯﾁｮｲ 1987-H6j/)
17/07/04 22:13:11.42 WAoveGpA0.net
4.11.8で30回中2回発生で目に見えて発生回数減ったので
再度カーネル4.12で回してみたら序盤10回で5割NGのあとは30回連続でビルド成功が続いてるｗ
なんだこれｗ
>>183
1800X, asrock AB350 gamingK4 biosは最新&デフォルト設定, メモリは忘れたｗ
Fedora25(workstation)はdnf updateとnvidiaのドライバ導入済
198:Socket774 (ﾜｯﾁｮｲ 6d84-DVJb)
17/07/04 22:21:45.86 7oNJGefQ0.net
>>197
なんかもうどのバージョンが良いとか悪いとかではなくて
たまたまメモリとかキャッシュとかのハードウェア的な状態がどうなってるかで変わってるような印象を受けるな
うちの環境はどうやらメモリ電圧に強く影響を受けてる感じなのが分かってきたので
安定する設定がないか模索中
まとまったらここでも報告するつもり
199:135 (ﾜｯﾁｮｲ c103-edpK)
17/07/04 22:56:42.64 vcQG7X9e0.net
>>194
早すぎです？でもずっとその間隔ですね
NVMeの威力かと思ってるけど16GBあるので
相当DDR4にcacheしてるのかもしれない
(確かにそれが化けたらアウトだ)
56scriptにはmake clean入ってるし
最初にmake clean make defconfigしてるし
なんか間違ってたら教えて
>>197
結構構成似てますが違いはnvidia位ですね
AMDにNVIDIA挿すのはﾔﾒﾀﾏｴってどっかで見たんで
洒落で今回はradeon R5にしてます
メモリは最初memtestかけまくりでした
いま25回全部OKなので明日まで放置
今回終わったらケースに入れる
200:Socket774 (ﾜｯﾁｮｲ c937-Pf3w)
17/07/04 23:23:38.86 eUNtuxMG0.net
>>196
おれはお前が何をいってるのかわからん
エラッタがOSやBIOSで回避するならするだろう
そうじゃなくて、現存する多くのアプリのバイナリを直さなきゃならないなら世の中にあるほとんどのx86コードは対応しない
あり得ない仮定だが、もしも例のコンパイラだけで問題が発生する非常に特殊なエラッタであれば、当然修正する可能性はある
201:Socket774 (ﾜｯﾁｮｲ 6187-k1q/)
17/07/04 23:46:44.55 0K0v5KUL0.net
>>200
あのね、今後、もしくは今でもメンテナンスされているアプリのことを言ってる。
そしてその対応のために、インテルもAMDも資料を提供してるよ。
URLﾘﾝｸ(www3.intel.com)
URLﾘﾝｸ(support.amd.com)
この手の資料は、別に伊達や酔狂で用意されたものではない。
202:Socket774 (ﾜｯﾁｮｲ c937-Pf3w)
17/07/05 00:02:18.34 ZleLyr3g0.net
>>201
普通のアプリ開発でそんなもんを見て作ってると思ってるのか？
お目出度い奴だな
203:Socket774 (ｱｳｱｳｶｰ Sae9-HpRm)
17/07/05 00:04:09.97 3dzao0iza.net
>>195
64ビットOSではもともと動かないしWindows Serverも2008以降32ビット版の提供自体やめてるけど何か問題でも？
204:Socket774 (ﾜｯﾁｮｲ c937-Pf3w)
17/07/05 00:05:38.50 ZleLyr3g0.net
16bitコード？
そんなもん誰が使ってんの？
205:Socket774 (ﾜｯﾁｮｲ 6187-k1q/)
17/07/05 00:08:29.79 jofwUHAp0.net
>>202
なにを思ってるって？？（笑
てか、資料も見ずに組むいい加減なやつが多いから、トラブルが減らない現実（笑
コンパイラ作ってるとこは、間違いなく見てるよ。
206:Socket774 (ｽｯﾌﾟ Sd62-GoLR)
17/07/05 00:10:32.95 bmxXp2HAd.net
つまりコンパイラは普通のアプリ
普通のアプリでセグテンテーション違反がランダムで起こるRyzenは糞
おしまい
207:Socket774 (ﾜｯﾁｮｲ c937-Pf3w)
17/07/05 00:13:03.32 ZleLyr3g0.net
>>205
もうちょっと世の中を知った方が良いぞ
ちょっと痛すぎる
208:Socket774 (ｱｳｱｳｶｰ Sae9-HpRm)
17/07/05 00:14:07.60 gLlbvgPBa.net
DOSの資産なんてMicrosoftすらとっくに互換保証断ち切ってるがFreeDOSなどで運用するにしてもVortex86とかQuarkあたりのシングルコアで十分だ
どのみちハードウェアスレッドを想定してないからマルチコアやSMT環境下では正常に動作しない
209:Socket774 (ﾜｯﾁｮｲ 6187-k1q/)
17/07/05 00:19:51.78 jofwUHAp0.net
>>205
狭い世の中なんだね、ご愁傷様
210:Socket774 (ｱｳｱｳｶｰ Sae9-HpRm)
17/07/05 00:28:10.75 gLlbvgPBa.net
自爆？
211:Socket774 (ﾜｯﾁｮｲ 06dd-ynbO)
17/07/05 00:28:58.24 sJzwRIa50.net
>>174
頭がバグってますねぇw
212:Socket774 (ﾜｯﾁｮｲ 6174-R8v4)
17/07/05 00:36:54.95 h5ZYDtvF0.net
>>209
エラッタｗｗ
213:Socket774 (ﾜｯﾁｮｲ 0651-uQz6)
17/07/05 07:34:57.82 1UkpjBYJ0.net
>>199
うーん、なんでそんな早いんだろ
おれの環境では、メモリ36G、そのうち18GをRAMディスクにして、その上でコンパイルしてる。
この環境でおよそ10分
configの仕方かな？
カーネルだけコンパイルして、モジュールコンパイルしてないとか？？
あ、おれはmake oldconfigでやってる
214:Socket774 (ｽｯﾌﾟ Sdc2-CG5Q)
17/07/05 07:51:51.72 74tMUe7xd.net
Ryzenはバカと無知を晒してでも擁護したいと思わせるほど魅力的なCPUだということが証明されつつあるな。
215:Socket774 (ｵｯﾍﾟｹ Sr71-E8g9)
17/07/05 07:52:18.30 EWebkYzCr.net
>>203
MicrosoftがWindows10 32bitとWow32のサポートを継続している以上問題は大アリだ
RyzenをGCCが動かせない欠陥CPUとするなら、SkylakeはWoW32を動かせない欠陥CPUって事になる
216:135 (ﾜｯﾁｮｲ c103-edpK)
17/07/05 08:02:41.36 APDeEym30.net
朝の段階で360回ノーエラー
これはどういうことなんだろう？
こちらのやり方が間違っているのか
make回数が足りないのか
やはりメモリ辺りの関係なのか
USB最小限だからかグラボなのか
UEFI最新だからなのか
>>213
>>167を使ってるんだけど
make defconfigはs氏の真似をしただけ
oldconfigでもやってみますね
217:135 (ﾜｯﾁｮｲ c103-edpK)
17/07/05 08:09:26.98 APDeEym30.net
make clean
make oldconfig
script
で約1:36ですね
他の人はどうなんでしょう？
と振りつつ一旦抜け
218:135 (ﾜｯﾁｮｲ c103-edpK)
17/07/05 08:26:02.15 APDeEym30.net
make clean
make mrproper
make defconfig
で1:25だた
219:Socket774 (ｻｻｸｯﾃﾛﾗ Sp71-HpRm)
17/07/05 09:10:00.85 lX5Ra4pJp.net
現在稼働中のカーネルの
.config でビルドしないと。
/proc/config.gz を展開して
.config にリネーム
make menuconfig でryzenに関連ありそうな
オプションをチェック
220:135 (ﾜｯﾁｮｲ c103-edpK)
17/07/05 09:47:11.87 APDeEym30.net
defconfigだと記事の構成で60秒切れるみたい
URLﾘﾝｸ(www.phoronix.com)
>>219
今回はkernel makeの確認だけで使わないんですが
menuconfig要ります？
221:Socket774 (ｽﾌﾟｯｯ Sde1-wKS4)
17/07/05 10:04:17.68 sswx1m2Xd.net
>>207
URLﾘﾝｸ(www.iarsys.co.jp)
コレがコンパイラ屋の対応
M Sじゃないとかダダこねるなよ
222:Socket774 (ﾜｯﾁｮｲ 1987-HpRm)
17/07/05 10:10:41.75 eS9+1zcd0.net
ryzen でビルドしたカーネルを
使ってテストする必要性ないの？
223:Socket774 (ﾜﾝﾄﾝｷﾝ MM92-PA5H)
17/07/05 11:21:19.69 dQhBuXHlM.net
うどんワールドですね、わかります
224:Socket774 (ﾜｯﾁｮｲ 2e63-k1q/)
17/07/05 11:38:26.54 Op+WGhW+0.net
>>221
MSというか、組み込みとPC用プロセッサじゃ何もかもが違う文化なんですが
x86でCPUのバグをソフトウェア側で対処した例って、
有名なF00Fバグとかぐらいで数少ないんじゃないすかね
第一コンパイラで対処が必要な不具合があるならさっさとエラッタとして公開して、
幅広いソフトウェアが対応できるようにしろって話で
自社のコンパイラだけにひっそりと搭載してだんまりでいいわけがない（仮にそうだとしたら）
225:Socket774 (ｵｯﾍﾟｹ Sr71-E8g9)
17/07/05 12:32:42.46 EWebkYzCr.net
AMD CPUよりパフォーマンスが低いバグに対応するためソフトウェア側で対処させたりとか日常茶飯事だろ
226:Socket774 (ﾌﾞｰｲﾓ MM05-ovUu)
17/07/05 12:33:41.74 jNi+Z4KxM.net
エラッタとして公開しろやって直接AMDに言い続けないとなーなーになって終わる
227:Socket774 (ﾜｯﾁｮｲ 3ead-B/AS)
17/07/05 12:33:45.20 TdY/AuwX0.net
幅広いソフトウェアが対応できるようにしろ、というか、限られたソフトで問題出てるというのが現状だからな
そんなに問題が幅広かったら、日本人が騒ぐ前に海外発信のニュースがネット上を飛び交ってるよ
228:Socket774 (ﾜｯﾁｮｲ 2e63-k1q/)
17/07/05 13:00:13.98 Op+WGhW+0.net
本当に問題が限られたソフトでしか出ないのか判断するためにも、
さっさとエラッタとして公開しろって話
ソフト側に問題があるならそれはそれでさっさとそう断言すればいいだけの話
ネットでニュースが飛び交う度合い（＝問題の幅広さ？）については
なにも言及していないのでいきなり持ち出されてもコメントに困る
229:Socket774 (ﾜｯﾁｮｲ 0653-nP2k)
17/07/05 13:11:34.22 sIWQ1h/L0.net
AMD
「 なんか馬鹿が勝手に騒いでるわーw
え？疑惑を持たれた側に挙証責任があるとでも？w 」
230:Socket774 (ﾜﾝﾄﾝｷﾝ MM92-AaO7)
17/07/05 13:15:10.16 oB7x18zjM.net
自分の環境だとカーネルビルドにかかる時間はdefconfigでだいたい80秒
>>222
現状コンパイル時に内部コンパイルエラーが起きてるんだから、カーネルが正常にできているかは内部エラーが全く起きななくなったときに改めて確認すればいいよ
どうせ現状でビルドしたカーネルを使う人はいない
231:Socket774 (ﾜｯﾁｮｲ 2e63-k1q/)
17/07/05 13:16:42.01 Op+WGhW+0.net
証明責任（しょうめいせきにん）とは、裁判をするにあたって
裁判所又は裁判官がある事実の有無につき確信を抱けない場合（真偽不明、non liquet）に、
その事実の有無を前提とする法律効果の発生ないし不発生が認められることにより被る、
当事者一方の不利益のことをいう。挙証責任、立証責任ということもある
（Wikipediaより）
はてこの喩えでいうと、どこで裁判が行われていて、だれが裁判所又は裁判官なのだろう？
232:Socket774 (ｽｯﾌﾟ Sd62-Pf3w)
17/07/05 13:19:04.44 NrnqkOBbd.net
変なのが来たな
233:Socket774 (ﾜｯﾁｮｲ 2e63-k1q/)
17/07/05 13:24:08.65 Op+WGhW+0.net
俺が変なのは否定できないが、
法的トピックでもない場面でいきなり挙証責任とかわけ分からん用語を持ち出すやつも大概ではないのか？
234:Socket774 (ﾜｯﾁｮｲ 0653-nP2k)
17/07/05 14:29:14.44 sIWQ1h/L0.net
おつかれさんw
235:Socket774 (ﾜｯﾁｮｲ 6174-R8v4)
17/07/05 15:02:27.39 h5ZYDtvF0.net
変な奴に絡まれてるなｗｗ
236:Socket774 (ﾜｯﾁｮｲ 6187-k1q/)
17/07/05 15:38:03.53 jofwUHAp0.net
>>224
えと、>>174 あたりから読んでほしいとこだけども、文化の違いとかじゃなく
なんでもCPUエラッタの退避コードはくコンパイラは特殊らしいよ？って話
237:Socket774 (ﾜｯﾁｮｲ 6187-k1q/)
17/07/05 15:38:47.29 jofwUHAp0.net
↑回避
238:Socket774 (ｱｳｱｳｶｰ Sae9-HpRm)
17/07/05 15:43:40.06 f2vF0U6Va.net
>>215
Windows 10 32bitは元々SkylakeをサポートしてないしIntelも64ビット用のドライバしか出してない
Wow32でも16ビットプログラムは動作しないし、VS2010以降の開発ツール、延長サポート対象のWindows 7もVS2005以降が対象で、[a-d]hへの部分書き込みをするコードを生成するコンパイラはそもそもとっくにサポート対象外
残念だったね
239:Socket774 (ﾜｯﾁｮｲ 2e63-k1q/)
17/07/05 15:49:21.26 Op+WGhW+0.net
>>236
もちろんそこから読んでるから大丈夫
＞CPUエラッタの退避コードはくコンパイラは特殊
いやだからね、汎用x86コンパイラにおいてはかなり特殊でしょうと
わざわざすべての文章に（※汎用x86コンパイラに限る話）
ってつけなきゃいけないのか？
240:Socket774 (ﾄﾞｺｸﾞﾛ MMe1-uQz6)
17/07/05 15:51:12.79 vHImh/w1M.net
>>216
すみません、おれがアホでしたorz
過去にビルドしたことないのに、make oldconfigしてたわ
大量の質問すべてEnter押してたので、もしかしたら巨大なカーネル作ってたのかもしれん。
家帰ったらdefconfigでやってみるわ
241:Socket774 (ｱｳｱｳｶｰ Sae9-HpRm)
17/07/05 15:53:37.24 f2vF0U6Va.net
>>239
「汎用でないコンパイラ」を例示して見てくれ
242:Socket774 (ﾜｯﾁｮｲ 2e63-k1q/)
17/07/05 15:55:45.18 Op+WGhW+0.net
>>241
URLﾘﾝｸ(qiita.com)
243:Socket774 (ｱｳｱｳｶｰ Sae9-HpRm)
17/07/05 16:03:58.60 f2vF0U6Va.net
それより古い設計のコンパイラだとVS2005から導入されたバッファオーバーランチェックも非対応でかつVista以降のASLRも使えないセキュリティ的にザルなプログラムってことになるけどさすがに動作保証以前の問題なのでは
Microsoftがサポートしてるから動作保証するべきって考え方は逆に言うとサポートを打ち切ったソフトは速やかに捨てるべきってことなんだよな
244:Socket774 (ｱｳｱｳｶｰ Sae9-HpRm)
17/07/05 16:10:15.56 8jM9wdqwa.net
>>242
そのコンパイラじゃah～dhの部分書き込みのコードを生成しないみたいだけど君頭大丈夫？
245:Socket774 (ﾜｯﾁｮｲ 2e63-k1q/)
17/07/05 16:23:16.23 Op+WGhW+0.net
>>244
それはSkylake,Kabylakeのエラッタの話だろう
そんなものをコンパイラで回避する云々などという話はもともとしていない
それに限らずエラッタを回避する汎用x86コンパイラの例はあるかということならば、
無いことはないだろうけど珍しいんじゃない？ということを言っているので俺に例を求められても困る
246:Socket774 (ﾜｯﾁｮｲ 6e74-uerO)
17/07/05 16:26:36.42 W/UAlt9o0.net
>>242
かなり面倒くさそうだな、ようやるわ・・・
＞3日探していたバグをやっと見つけた。CALL命令を呼ぶ前後でスタックポインタのアドレスをプラスマイナス16すると、
＞第2世代のコンパイラが正しい入力に対してコンパイルエラーのメッセージを出力するという謎の現象。
＞素直にSEGVってくれればいいんだけど、中途半端に動作するこの手の問題は追跡しにくい。
＞
＞結局原因は、リテラルの構造体で指定されていないフィールドを0で初期化するのを忘れていたということだった。
＞イニシャライザがある場合、初期値の与えられていないフィールドは0で埋めなければいけないんだけど、
＞それをしていなかったので、構造体がスタック上のゴミで初期化されていて、それがヒープにコピーされたあと
＞シンボルテーブルに保存されて後で問題を引き起こしていたのだった。
＞どのゴミを拾うかというのがスタックの位置によって変わってくるので微妙なバグになっていた。
247:Socket774 (ｱｳｱｳｶｰ Sae9-HpRm)
17/07/05 16:37:08.56 8jM9wdqwa.net
>>245
安定動作実績が世間に認められたもの存在しないならないのと同じだよ
誰がそんなあるのかないのかわからないコンパイラが安定動作することを保証すんの？
248:Socket774 (ﾜｯﾁｮｲ 2e63-k1q/)
17/07/05 16:57:49.86 Op+WGhW+0.net
>>247
申し訳ないが何が言いたいのか分からない
249:Socket774 (ｱｳｱｳｶｰ Sae9-HpRm)
17/07/05 17:06:25.89 8jM9wdqwa.net
多くの環境で動作実績のあるUbuntu,GCCすらまず先にCPUのせいじゃないソフトのせいだと要らぬ言いがかりつけられるレベルなのに海のものとも山のものとも知れないソフトを信用して使う人が存在することを仮定するのがそもそも無理があるだろうと言うお話
250:Socket774 (ｱｳｱｳｶｰ Sae9-HpRm)
17/07/05 17:07:44.71 8jM9wdqwa.net
そして緊急にエラッタを修正する必要性は微塵もない
251:Socket774 (ｱｳｱｳｶｰ Sae9-HpRm)
17/07/05 17:11:29.67 8jM9wdqwa.net
>>224
GCCとかエラッタの修正の山ですけど？
組み込みプロセッサでもバグを仕様と言い張ってソフト側で修正求めたケースは多々あり
お前何も知らないんだな
252:Socket774 (ﾜｯﾁｮｲ 2e63-k1q/)
17/07/05 17:14:14.83 Op+WGhW+0.net
>>249
いやー、そんな話はしてないんだよなぁ
俺が言ってるのは汎用のx86コンパイラ（≒お前さんの言う「多くの環境で動作実績のある」コンパイラ）
ではCPUのエラッタをコンパイラ側で回避するって例は珍しいってこと
それだけ
253:Socket774 (ﾜｯﾁｮｲ 2e63-k1q/)
17/07/05 17:15:29.27 Op+WGhW+0.net
>>251
それは不勉強だった、申し訳ない
できれば具体的な例を挙げてもらえるとありがたい
254:Socket774 (ﾜｯﾁｮｲ 2e63-k1q/)
17/07/05 17:16:37.61 Op+WGhW+0.net
組み込みでは多々そういうことがあるのは知っている（だから組み込みでは文化が違うと最初から言ってる）
なんせ、組み込みなんてのは特定のボード専用の開発ツール一式なんてのが存在しうる世界だから
255:Socket774 (ｱｳｱｳｶｰ Sae9-HpRm)
17/07/05 17:30:57.45 8jM9wdqwa.net
>>252
組み込みでは～とかドヤった挙句、AVRやPICにも半ば仕様扱いされたバグある現実つきつけられて支離滅裂モード入りましたね
もう消えていいよ？
なんの説得力もないから
gccのコミットログ見たこともないんだね
Core2にもコンパイラが通常生成しない命令の組み合わせで起こるバグは複数存在したけど結局実害ないからディスコンまで放置された例がある
256:Socket774 (ｱｳｱｳｶｰ Sae9-HpRm)
17/07/05 17:32:05.02 8jM9wdqwa.net
ARMだと比較的新しいのではCortex-A53のエラッタのパッチ当たってる
257:Socket774 (ｱｳｱｳｶｰ Sae9-HpRm)
17/07/05 17:47:56.77 8jM9wdqwa.net
ググればいくらでも出てくるし
URLﾘﾝｸ(patches.linaro.org)
AMDにも普通にワークアラウンドの前科ある
URLﾘﾝｸ(gcc.gnu.org)
258:Socket774 (ﾜｯﾁｮｲ 2e63-k1q/)
17/07/05 18:02:32.20 Op+WGhW+0.net
>>255
x86のgccでエラッタをコンパイラ側で対応する例はそう珍しくはないという点は了解した
ほぼねーだろみたいな知ったかぶりをしたことは誠に申し訳ない
ところで、今回のRYZENのSEGVが仮にCPUのエラッタだとして、
これは単なる局所的な命令の並びだけがトリガーなのではなく、
カーネル⇔ユーザーコードの切り替えや、あるいは他のスレッドの動作具合も影響するかなり複雑な状況がトリガーになってるっぽくて、
単にコンパイラの吐くコードだけで対処するのは難しいっぽい気はするがどうだろう？
むしろカーネルでコンテキストスイッチするときに本来不要なコストのかかる処理をかならず呼ぶようにするとか、
そういう対処のほうがまだ可能性ありそうなのだが
259:Socket774 (ﾜｯﾁｮｲ c103-edpK)
17/07/05 18:10:19.05 APDeEym30.net
全然話し違いますがマザーの設定の中に
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の次の項目
260:Socket774 (ｽﾌﾟｯｯ Sdc2-GoLR)
17/07/05 18:51:00.47 uGihz4E+d.net
>>259
XV Core = eXcaVator core
CZ A0 = Carrizo
なんでZenのマザボに項目が残ってるんだろ
261:Socket774 (ﾜｯﾁｮｲ 06dd-ynbO)
17/07/05 18:55:46.93 sJzwRIa50.net
changelogくらい普通見るでしょ
毎回ここ見るたび頭がバグってる人が来ているね
262:Socket774 (ﾜｯﾁｮｲ b1a5-ImDA)
17/07/05 18:57:14.05 ott4ASVn0.net
>>260
鰤用でしょ
263:Socket774 (ﾜｯﾁｮｲ c103-edpK)
17/07/05 19:11:42.74 APDeEym30.net
>>260
あ、なーる
264:Socket774 (ｵｲｺﾗﾐﾈｵ MMd6-ynbO)
17/07/05 19:35:00.57 yB5eXowZM.net
おま環ドヤ顔まで参加したか…頭が弱い
265:Socket774 (ｽﾌﾟｯｯ Sdc2-GoLR)
17/07/05 19:48:01.09 uGihz4E+d.net
>>262
Bristol RidgeってModel 65h-6fhでCarrizoの一部だったのか
そりゃ残ってるわな
266:Socket774 (ﾜｯﾁｮｲ b175-ImDA)
17/07/05 19:53:04.27 e6Kmg9EW0.net
そこまで詳細に考えなくても鰤はAM4でExcavatorコアだから
それ用のエラッタ対策入っててもおかしくはないと思っただけ
267:Socket774 (ｽｯﾌﾟ Sdc2-Pf3w)
17/07/05 20:41:18.42 dXZxRBH7d.net
単純な除算バグもコンパイラじゃ対応出来ないのに、今回のキャッシュっぽいのが対応出来るわけないと思う
268:Socket774 (ﾜｯﾁｮｲ 6187-k1q/)
17/07/05 20:51:24.69 jofwUHAp0.net
>>267
除算バグは単純じゃなかろ？
269:Socket774 (ﾜｯﾁｮｲ 6174-R8v4)
17/07/05 21:07:43.58 h5ZYDtvF0.net
>>263
下ネタ禁止
270:Socket774 (ﾜｯﾁｮｲ c937-Pf3w)
17/07/05 21:49:25.32 ZleLyr3g0.net
>>268
超単純
特定の値を入れると値を間違う
何の不確定性も無い
271:Socket774 (ﾜｯﾁｮｲ 61e0-CicO)
17/07/05 21:50:48.66 YksKTANz0.net
キャッシュっぽいってのも、キャッシュなら対応できないっても推測でしかなかろう
CPU設計の専門家でもないのに何が分かる
真相はAMDにしか分からないって可能性もある
例えばシステムマネジメントモードというものがある
URLﾘﾝｸ(ja.wikipedia.org)
Wikipediaにも書いてあるが、こいつはOSからは透過なことが特徴だ
つまりOSからはCPUがシステムマネジメントモードで何やってるのか見えないし
システムマネジメントモードから復帰すると前と同じ状態に戻るから
システムマネジメントモードに入ったことにOSから気づくことも簡単ではない
例えば、ファームウェアがシステムマネジメントモードでコードを実行して、OSに処理が戻った後
CPU内部の状態によってはインストラクションポインターとずれた命令を実行する、みたいな状況なら
OSからトラブルシュートするのは極めて困難で、真相はAMDにしか分からないだろう
もしこういうシナリオならファームウェアの方でワークアラウンドがあるかもしれん
が、俺もCPU設計の専門家ではないので以上の説明にどれだけの妥当性があるかは全然分からん
俺はAMDを待つよ
272:Socket774 (ﾜｯﾁｮｲ 6187-k1q/)
17/07/05 22:00:40.96 jofwUHAp0.net
>>270
ではなく、除算アルゴリズムはご存知だろ？
命令の代替なんて、処理速度も含め、そんな単純な問題じゃない。
単純な処理ってのは、手順を変えるだけでなおるとか、ある処理の前にある処理をしないとか、そーゆーの。
273:135 (ﾜｯﾁｮｲ c103-edpK)
17/07/05 22:09:51.86 APDeEym30.net
改めてxubuntu17.04で追試
make中に間違えて手動でソフトウェアの更新を起動した時に
cc1がsegvで落ちたのが１回 orz...
それ以外はOKで現在30周通過
対象は4.11.8/1:35@1700
>>269 ｲｶﾝﾄ?
274:Socket774 (ﾜｯﾁｮｲ c937-Pf3w)
17/07/05 23:30:00.37 ZleLyr3g0.net
>>272
対策は単純じゃないが、問題は単純
今回の問題は問題自体がはるかに複雑に見える
275:Socket774 (ﾜｯﾁｮｲ 6187-k1q/)
17/07/05 23:43:51.00 jofwUHAp0.net
>>274
普通に考えたら、AMDも調査に手こずってるんだろうね。
まぁ、隠蔽の疑惑持ってる人もいるみたいだけども、隠すメリットが思いつかない。
276:Socket774 (ﾜｯﾁｮｲ c103-edpK)
17/07/05 23:46:53.22 APDeEym30.net
gcc修正
URLﾘﾝｸ(mag.osdn.jp)
277:Socket774 (ﾜｯﾁｮｲ c937-Pf3w)
17/07/05 23:46:57.50 ZleLyr3g0.net
隠すメリットが思い付かないって
ずいぶんと発想が乏しくないか？
278:Socket774 (ｱｳｱｳｶｰ Sae9-hQ0r)
17/07/05 23:51:55.59 4DQ9peqRa.net
>>277
隠して後で大爆発するよりかはメリットあるわ
279:Socket774 (ｱｳｱｳｳｰ Sa5b-L5XL)
17/07/06 00:21:11.41 saKL8fNpa.net
AMDがだんまりを決め込んでる今できる対策としてEPYC導入を表明してるDropboxについてはOneDriveとかGoogleDriveにデータの引越し済ませて解約することだけ。
発生条件が特定できない以上サービスプロバイダ側も対策は不可能だしデータが消えてからでは遅いからな。
280:Socket774 (ｱｳｱｳｶｰ Sa2b-9oNx)
17/07/06 00:26:21.99 q2l5oMhIa.net
確かにそれが正解やね
んでCPUもIntelに交換するのが正解
281:Socket774 (ﾜｯﾁｮｲ 9787-pw7F)
17/07/06 00:26:29.28 0ybnWFsu0.net
>>279
なんでパートナーにまでだんまり決め込んでると判るの？
これまで３桁にものぼるエラッタを公表してきたのに、それ、全部一般に認識されてる？
むしろ一緒に検証してる最中かも、と考えられなくもないと思うけども。
てか、もしだんまり決め込まれてるとしたら、Dropboxの対応が遅いでしょ。
282:Socket774 (ﾜｯﾁｮｲ 9fd1-RF1/)
17/07/06 00:47:12.49 odJavO6+0.net
OneDriveたまにデータ消えるからやめとけよ
283:Socket774 (ﾜｯﾁｮｲ 17a5-u6mz)
17/07/06 04:21:31.82 p4HM/goD0.net
>>276
Segfaultが出る不具合の修正がいくつかあるな
Ryzen SEGVに影響あるかは分からんが
284:Socket774 (ｱｳｱｳｶｰ Sa2b-L5XL)
17/07/06 07:07:04.55 EnBajYy1a.net
RyzenのSEGVはjmp/jcc命令実行時に「RIPが64バイトずれる現象」の副作用であって
むしろズレた先が有効なアドレスならズレた状態でも動いてしまうから問題（例えば壊れたプログラムがあたかも正常であるがごとくビルドされる）なんだよ？
アドレスが即値指定されてるjmp命令のアドレスが間違うなんてCPUが正常に動いてない以外の原因ないだろ
だからgccの修正とはなんの関係もない
285:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/06 07:12:42.72 AueRn8iw0.net
信者はどうしてもCPU以外のせいにしたいらしいから
286:Socket774 (ﾜｯﾁｮｲ 9fd1-RF1/)
17/07/06 07:15:19.01 odJavO6+0.net
>>284
64バイトズレるパターンが1番再現率高いから確定にいつ変わったんだよ
287:Socket774 (ｱｳｱｳｶｰ Sa2b-L5XL)
17/07/06 07:30:49.09 G2WMIbEea.net
>>286
誤ったジャンプ先がたまたま範囲外アドレスでSEGVで止まってくれるケースが現象を追いかけやすいだけで
ジャンプ先がズレた状態で動いてしまうほうがCPUの暴走を検出しにくいからね。
その範囲内だったケースもほぼエビデンスとれてる状態だろ今？
自己書き換えプログラムでもない限りRIP相対即値が書き換わることなんてあり得ないし自己書き換えする際にはL1Iをフラッシュして再ロードしないといけない。そんな操作はコンパイラ内でやってるわけがないのでソフト側でジャンプ先アドレスを間違うほうが無理がある。
288:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/06 07:37:40.40 AueRn8iw0.net
団子か
289:Socket774 (ｵｲｺﾗﾐﾈｵ MM4f-BuHV)
17/07/06 07:45:50.04 MqhrhM4YM.net
64バイトズレル？
本当か？
AMDは何て言ってるの？
290:Socket774 (ﾜｯﾁｮｲ 97c6-KuRC)
17/07/06 07:52:07.68 nsbpDhQA0.net
>>289
調査中
CPU以外の部品交換とか電圧設定変更とかで頻度が激減したりするので
単なるロジックの問題ではなくおま環由来がかなり含まれていて難しい
291:Socket774 (ﾜｯﾁｮｲ 9f1d-1B52)
17/07/06 07:52:53.56 dNCJ06qV0.net
そもそも毎回同じプログラムを走らせて
エラーが出たり出なかったりってのがコンパイラのせいとかおかしくね
リーク以外でランダム要素ある?
292:Socket774 (ﾜｯﾁｮｲ 97c6-KuRC)
17/07/06 07:57:30.78 nsbpDhQA0.net
>>291
キツキツのマルチスレッドだからなんぼでもランダムになりますよ
何年か前のgccでLinus激怒というのがありまして
SEGVで落ちるわぐちゃぐちゃな出力出すわという酷いもの
293:Socket774 (ﾜｯﾁｮｲ 97c6-KuRC)
17/07/06 07:59:40.42 nsbpDhQA0.net
ただし、ロウレイテンシカーネルの人はgccの問題じゃなく
こりゃカーネル/Ryzenのすりあわせだなという結論になった模様
294:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/06 08:18:30.85 AueRn8iw0.net
>>290
原因と関係ない要素で発生率が変わるなんてごくごく普通のことだぞ
非常に特別なことみたいに書いてるが
295:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/06 08:18:58.37 AueRn8iw0.net
さすが素人の解析ごっこ
296:Socket774 (ｱｳｱｳｶｰ Sa2b-L5XL)
17/07/06 08:57:54.45 zWNt78Fha.net
カーネルをローレイテンシにしたら改善云々の話、コンテクストスイッチの問題と仮定するなら結局タイミングによって内部状態の復帰が正常にできてないってことで普通にそれもCPUのバグなんだろうけどな
それすらRIPが64バイトずれる現象自体の説明にはまるでなってないし
297:Socket774 (ﾜｯﾁｮｲ 1706-u6mz)
17/07/06 10:56:07.47 Bl4FS0hJ0.net
>>292
>>293
gccも結構な前科持ちなんだな
今回の修正点リストといい、gccに対するイメージが変わったわ
盲目的に信用はできないな
Linusが激怒する位なら、いずれプランBのコンパイラも出てきそう
Law latency kernelは挙動が(良い方向に)変わったからそう考えるのは自然な流れか
どのみち対応待ちになるのが辛い所だが
298:Socket774 (ﾜｯﾁｮｲ 9787-pw7F)
17/07/06 11:00:17.01 0ybnWFsu0.net
64バイトずれるのさぁ、誰も追試しないのなぜ？
299:Socket774 (ﾌﾞｰｲﾓ MMfb-RF1/)
17/07/06 11:05:27.96 6F6GL3wMM.net
64バイトズレるで確定してないから
300:Socket774 (ﾜｯﾁｮｲ 9787-pw7F)
17/07/06 11:12:22.88 0ybnWFsu0.net
>>299
まぁ、証言ひとりではね。
知らんだけで追試情報あればごめんだけど。
301:Socket774 (ﾜｯﾁｮｲ 17d6-u6mz)
17/07/06 11:14:51.36 jRPArVgD0.net
>>297
つづりまちがい
Low latency kernelだった
302:Socket774 (ﾜｯﾁｮｲ 9f6c-TkOv)
17/07/06 11:28:36.71 KYaNISLa0.net
>>297
clang以外にも出てくるという予想？
あとLinuxはいつも激怒してるｗ
URLﾘﾝｸ(www.google.co.jp)
303:Socket774 (ｵｯﾍﾟｹ Srcb-kNtm)
17/07/06 11:55:31.35 +GsoNQnpr.net
おーえすが激怒なんてしないだろー
304:Socket774 (ﾜｯﾁｮｲ 17c0-u6mz)
17/07/06 17:29:55.45 VXW3uuYP0.net
>>302
clangというのがプランBなのか
勉強不足でスマソ
Linusが怒る話はそこそこ聞いた事はある
(nVのドライバとかSE LinuxとかXenとか)
ただgcc絡みでも怒った話は初めて聞いた
商売っ気のないJobsみたいな人だと思ってる
305:Socket774 (ﾜｯﾁｮｲ ffec-rvkC)
17/07/06 20:14:19.68 4JHE/Ugo0.net
たかが64バイトくらい気にすんなや！！！！！！！！！！！111111111
306:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/06 20:14:36.00 AueRn8iw0.net
だね
307:Socket774 (ﾜｯﾁｮｲ 9f6e-pw7F)
17/07/06 20:30:58.47 Qj3iDYS70.net
>>304
はっきり言ってgccは時代遅れで、これからはclang (LLVM)って流れは5年くらい前から見た
確かにgccは付け焼き刃の繰り返しで大きくなってしまった
308:Socket774 (ｵｲｺﾗﾐﾈｵ MM4f-mmpI)
17/07/06 20:36:00.25 4wfBgvNBM.net
ただLinuxのカーネルってGNUの独自拡張構文に依存してるとかで、
gcc以外でビルドできないんだよね？
そんでもってclang/llvm側はそんな独自拡張を実装する気はさらさらないと明言
ってのが数年前だったけど最近はどうなんだろう
相変わらずカーネルをgcc以外でビルドしてるって話は聞かないし
309:Socket774 (ﾜﾝﾄﾝｷﾝ MM7f-AnYK)
17/07/06 20:39:17.50 SnTMk+RyM.net
clangが主流になるにはlinux kernelが素のままビルド出来ようにならないと・・・
310:Socket774 (ﾜｯﾁｮｲ 9f6e-pw7F)
17/07/06 20:48:50.41 Qj3iDYS70.net
>>308
FreeBSDはclangでビルドできるように修正をした。(2013年頃)
そもそもclangやC言語標準でコンパイルが通らないような規格外の独自拡張を悪と見なす方針だろう
Linux側がなんとかするべきだろうね
311:Socket774 (ﾜｯﾁｮｲ 9787-pw7F)
17/07/06 20:49:17.18 0ybnWFsu0.net
>>305 >>306
ウソん・・・1バイトでも大問題www
312:Socket774 (ﾜｯﾁｮｲ 171d-u6mz)
17/07/06 20:49:52.77 EBj3RnTJ0.net
少なくともkernelビルドにおいてはclangはプランBではないのか
OSSの世界も色々大変だな
そこまで動向ウォッチしてないから勉強にはなるが
313:Socket774 (ﾜｯﾁｮｲ 171d-u6mz)
17/07/06 20:51:16.48 EBj3RnTJ0.net
訂正
少なくともLinux kernelビルドにおいては、だな
314:Socket774 (ｵｲｺﾗﾐﾈｵ MM4f-mmpI)
17/07/06 20:57:38.59 4wfBgvNBM.net
>>310
まあLinux側もパフォーマンスとか構文のシンプルさとかわけがあってそうしてる部分もあるんだろうけど、
GNUと心中しない道を選ぶならLinux側でなんとかしなきゃいけないだろうな
その口ぶりだとさすがにまだLinux側のコードはGNU依存のままなのかな
315:Socket774 (ｱｳｱｳｳｰ Sa5b-tYQy)
17/07/06 21:01:34.65 AhnSK8wva.net
>>296
RIP関連仕様かなんかそんな事が書いてある場所があった気がするけど思い出せん
何処で見たんだろうか
316:Socket774 (ｻｻｸｯﾃﾛﾗ Spcb-L5XL)
17/07/06 22:21:05.73 YVeAF4CDp.net
世界は今日から君のもの
AMDが迅速な対応さえすれば、ね
317:Socket774 (ｱｳｱｳｳｰ Sa5b-L5XL)
17/07/06 23:12:49.28 c1rB1f/Da.net
Firefoxもしかり、オープンソースソフトって企業に見放されるとメジャーバージョンのインクリメントが加速する法則があるよな
318:135 (ﾜｯﾁｮｲ 9703-/HDW)
17/07/06 23:38:05.42 J8f+nglM0.net
xubuntu17.04で300回以上回して(314回?)
昨日書いた手動でのcc1のエラー以外は確認できず
起きないのではなくて300回で足りないだけかもしれないけど
最初に報告したときと違うのは
1. make対象カーネルの違い(.7と.8)
SEGV頻度に影響あるかは全く不明
2. 最初の頃にdefconfigが抜けていた可能性
(既存の.configをコピーした気もする)
だから時間かかっていたのかも
3. もしかして最初はメモコンが安定していなかった可能性
(例えmemtest86が通っていても)
boot順とか変える時にXMP Profileとか
選んだりしてたし何かあってもおかしくない
はいはいおま環乙
次 gentoo は後にして dragonflybsd+gcc
buildworld と buildkernelまず１回テスト
319:Socket774 (ﾜｯﾁｮｲ ff63-zXPy)
17/07/07 01:26:16.93 8DrUBwiX0.net
gcc6.4.0をubuntu16.04でビルドしてみた
2.5時間程かかった
これでkernel4.11.7をビルドすると5分程遅い
今連続ビルド中
まだ4回目だけど今の所順調
しばらく回しておく
320:Socket774 (ﾜｯﾁｮｲ ff63-zXPy)
17/07/07 03:10:53.22 8DrUBwiX0.net
6回目でSEGVとwaitが同時発生した
(同時発生は初）
この実験は一時中断する
321:Socket774 (ｵｲｺﾗﾐﾈｵ MM4f-pkl0)
17/07/07 06:41:17.06 sCRDUjRcM.net
うえああおつかれ
redhat系が良さそうな
epycがさわれる環境もCentOSみたいだよ
322:Socket774 (ﾜｯﾁｮｲ 7703-TkOv)
17/07/07 07:24:11.67 PS8sxaRN0.net
Ryzen 1600
os ubuntu 17.10 alpha
clang 4.0.1
Makefile gcc ->clang
ワーニングが出たけどvmlinuzができた。
323:Socket774 (ﾜｯﾁｮｲ 7703-TkOv)
17/07/07 07:26:02.93 PS8sxaRN0.net
kernel 4.12 を 書き忘れた。
324:Socket774 (ｵｯﾍﾟｹ Srcb-+Bwc)
17/07/07 08:32:09.80 XpJ/QV+Dr.net
>>319
gccリビルドしても改善はしなかったですか。
検証乙です。
325:Socket774 (ｱｳｱｳｶｰ Sa2b-L5XL)
17/07/07 13:34:41.58 eP7chihEa.net
sat氏のおかわり後レポート次第かな
個体差で片付くか、あるいはもっと根の深い問題か
326:Socket774 (ﾜｯﾁｮｲ 17d6-u6mz)
17/07/07 15:01:30.94 a/N3Nj6+0.net
>>320
乙
できれば4.11系の新しめのカーネルの環境でも試してもらいたい
>>321
fedora26は7/11に正式版になるようだ
CentOSはEPYCに合わせて出るのかね
>>322
乙
clangでkernel4.12のビルドは(動くかどうかは別として)通るのか
並列ビルドで連続ビルドしたらどうなるかは気になる所
327:Socket774 (ｽｯｯﾌﾟ Sdbf-0UkT)
17/07/07 17:23:27.27 WB7MYMird.net
素人の解析ごっこ
お疲れさまです
328:Socket774 (ｵｲｺﾗﾐﾈｵ MM4f-BuHV)
17/07/07 17:38:21.39 h0SWYKE6M.net
役に立たない懐石がまさにこれ
329:Socket774 (ﾜｯﾁｮｲ 9f6e-pw7F)
17/07/07 18:35:12.68 8uxsS8Rn0.net
クロスコンパイルというか非Linux環境で
gccでLinuxカーネルをビルドする場合はどうなんだろう
330:Socket774 (ﾜﾝﾄﾝｷﾝ MM7f-M+1A)
17/07/07 18:38:27.15 2NDA6ATdM.net
むしろこんな2ちゃんねるのスレが役立つと思ってるほうがウケるｗ
331:Socket774 (ﾜｯﾁｮｲ ff5c-Razr)
17/07/07 19:18:12.66 LgSgh/qx0.net
sat周り（特定4名くらい）はだいぶ苦しくなってきてどうするんだろ
だんだん醜い言い訳になってるわ
332:Socket774 (ﾜｯﾁｮｲ ff63-zXPy)
17/07/07 21:02:18.00 8DrUBwiX0.net
>>324
gcc自体のビルドはmake中に3回ビルドして結果を比較し一致しないと成功扱いにならないそうだ
3回とも同じ失敗をする可能性もあるけど一応kernelビルドが通る場合が多い位だし失敗したとは考えにくい
あと時間がかかるのがね...
>>326
バージョンが大きく異なるkernelだけ入れ替えは動かなくなったりすると自分の手に負えない
最初からkernel4.11系のディストリを使う事になる
やるとしたらfedora26辺りで実験してみようと思う
333:Socket774 (ﾜｯﾁｮｲ 17c0-u6mz)
17/07/07 21:13:56.39 i56t0pE40.net
>>329
WindowsでMinGWとかCygwinとか？
試したという話は聞かないが、そもそもそういう環境でx64カーネルビルドが通るのかね
334:Socket774 (ﾜｯﾁｮｲ 17c0-u6mz)
17/07/07 21:19:29.43 i56t0pE40.net
>>331
ウォッチ乙
もはや見に行く気もしないから現状が分かるだけで助かるわ
335:Socket774 (ﾜｯﾁｮｲ 17bd-u6mz)
17/07/07 21:21:20.78 /aL+fc7M0.net
>>318
色々試して乙
336:Socket774 (ﾜｯﾁｮｲ 9f5f-m5Ug)
17/07/08 01:05:35.38 I9LZNJo90.net
CPUノーマルにメモリ設定総当たりしたりしても全くNG消えなくてTaichiの新BIOS待ちしてたけど
全然新BIOS来ないからちょっとレジストリでASLR無効にしてWin版やってみたらNG出なくなった
ASLRのエラッタじゃねーのこれ
337:Socket774 (ﾜｯﾁｮｲ 1764-u6mz)
17/07/08 01:18:11.23 ++4GvUvK0.net
LinuxはASLR切ってもダメらしい
WindowsでASLR切った話は初めて聞いた
メモリ管理の挙動が変わるから、たまたま良くなった可能性もある
338:Socket774 (ﾜｯﾁｮｲ 9f5f-m5Ug)
17/07/08 01:33:02.07 I9LZNJo90.net
Linuxでエラー出てるのはOCCTとかメモリに高負荷かけたことない環境で設定が甘いんじゃないかと思うけどな
試しにWin10ダウンロードしてテストしてくれと言ってもやるような人たちじゃないだろうけどｗ
自分がLinuxメインにしてた頃はPC組んだら先にWinインストールして耐久テスト完了してからやるようにしてたよ
使っててたまにクラッシュするのが直らなくてWinで確認したらメモリの相性だったことがあったからだけど
LinuxにもOCCTとかIntelBURNtestみたいに手軽にテストできるアプリがあればいいんだけどね
339:Socket774 (ﾜｯﾁｮｲ 57b4-tYQy)
17/07/08 01:38:37.76 VXaQYJ3m0.net
kernel-buildテストがあるじゃ無いかw
low-latencyカーネルでやると大丈夫って話もあったな
340:Socket774 (ﾜｯﾁｮｲ 9f5f-m5Ug)
17/07/08 01:47:19.50 I9LZNJo90.net
部屋暑くて辛い・・・
とりあえずOK2万超えたら止めて寝るわ
341:135 (ﾜｯﾁｮｲ 9703-/HDW)
17/07/08 01:57:58.31 RvbdKEE90.net
>>335
ありがとう
dragonflybsd buildworld buildkernelのセット
10週ok
もっとやろうと思ったけどdiskfullになり
原因不明のため中止(cache以外に何か残ってる？)
いまgentoo vannila kernel(4.12)で開始
対象は4.11.8に
gcc5だけど後で6に上げるられるので
ひとまずこれで開始 詳細略
342:Socket774 (ﾜｯﾁｮｲ bfdd-BuHV)
17/07/08 05:05:48.46 lhFE9WgY0.net
>>330
頭大丈夫か？
343:Socket774 (ﾜｯﾁｮｲ 57b4-tYQy)
17/07/08 05:34:37.02 VXaQYJ3m0.net
>330が呼吸して酸素を浪費してるのが最も無駄だと思う
344:Socket774 (ﾜｯﾁｮｲ ff74-x/VO)
17/07/08 05:45:37.19 1G43keIM0.net
>>338
Prime95ならLinux版あるからそれで良いのでは？
誰かがブータブルイメージ作れば皆が使ってくれそうだけど
345:135 (ﾜｯﾁｮｲ 9703-/HDW)
17/07/08 08:28:34.74 RvbdKEE90.net
>>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
346:135 (ﾜｯﾁｮｲ 9703-/HDW)
17/07/08 08:31:45.30 RvbdKEE90.net
>>345
修正 make対象は4.11.9だったｽﾏｿ
347:Socket774 (ﾗｸｯﾍﾟ MM8b-dXzr)
17/07/08 12:51:03.60 6UmToCDlM.net
相当にニッチな用途の上におま環かどうかも解らない程度の問題
348:Socket774 (ﾜｯﾁｮｲ b77c-rgmT)
17/07/08 13:02:44.67 S6JCmAzM0.net
これってエンコード後にファイルが壊れたりするって事？
ryzen使っててファイル壊れたとか実害報告でてるの？
349:Socket774 (ｱｳｱｳｶｰ Sa2b-9oNx)
17/07/08 13:39:29.39 X5bvsE8Da.net
>>348
そんな報告が出てるならもっと大問題になってる
どうしても心配なら使わないのが正解
350:Socket774 (ﾜｯﾁｮｲ b7c8-gXZb)
17/07/08 13:40:52.94 jWvIU67o0.net
EPYC界隈じゃ何の話題にもなってないし販売にも影響し無さそうだし、サーバー分野じゃ解決してそう
351:Socket774 (ﾜｯﾁｮｲ f78e-rvkC)
17/07/08 13:47:32.11 k8Mmudb10.net
>>348
普通に使ってファイル壊れるならとっくに大問題になってる
352:Socket774 (ﾜｯﾁｮｲ b77c-rgmT)
17/07/08 13:58:33.86 S6JCmAzM0.net
>>349-351
ありがとう。録画エンコ機用にryzen買った後にこの話題知ったから少し不安だった
気にせず組むわ
353:Socket774 (ﾜｯﾁｮｲ 9774-jTKI)
17/07/08 14:12:46.62 bgpZ+5Eu0.net
火を噴く訳じゃないからな、有ったとしてもブルースクリーンが出るくらいだよ
354:Socket774 (ﾜｯﾁｮｲ 9f8c-ujmL)
17/07/08 15:21:45.64 X8vyviL/0.net
ポインタがズレるってことは、
データがぶっ壊れる可能性もなくはないんだよね
355:Socket774 (ｱｳｱｳｶｰ Sa2b-L5XL)
17/07/08 15:37:21.88 rzMeL2tva.net
もし仮にループのjccでRIP化けが起こると少し前本来1回しか通してはいけない初期化処理を通してしまってループカウンタが初期化されてオーバーランしてしまう、SEGVにならないのでまま出力データが化けてるのに気づかない、なんてことも起こりうるね
356:Socket774 (ﾄﾞｺｸﾞﾛ MMdf-9wqu)
17/07/08 15:40:36.51 R77p5prdM.net
そもそもズレること自体が致命的
357:Socket774 (ﾜｯﾁｮｲ 9787-pw7F)
17/07/08 16:27:17.46 hsUqKgsF0.net
ホントにずれてるんなら、高確率で暴走して停止だと思うけども？
なんでSEGVなんて、ある意味行儀のよいトラブルだけが目立つのか。
また、そんなうまい具合に出力データだけ書き換えて、何事もなく動作を続けられるのか。
358:Socket774 (ﾜｯﾁｮｲ b7c8-gXZb)
17/07/08 17:14:50.14 jWvIU67o0.net
ECCで回避できないエラーなのかな
359:Socket774 (ﾜｯﾁｮｲ ff5c-x/VO)
17/07/08 17:16:26.04 pHDomEF+0.net
>>357
IntelならOS、ついでにHDD/SSSDも道連れに大クラッシュなんだけど
AMDには強力な保護機能を搭載しているからよ
カーネル空間、ユーザー空間ってのがあって、AMDはIntelと違いカーネル空間動作のものが
大クラッシュしても何事もなく動作するってすごいもの。さすが、天才設計のAMDだよな
一方、Intelはユーザー空間のクラッシュが何とかそのプログラムのクラッシュですむって軟弱保護
360:Socket774 (ﾜｯﾁｮｲ d771-XAlt)
17/07/08 17:52:09.83 U5h19fxE0.net
>>358
ECCをなんだと思ってるんだｗ
361:Socket774 (ﾜｯﾁｮｲ 9774-jTKI)
17/07/08 19:26:03.29 bgpZ+5Eu0.net
英会話だろ
362:Socket774 (ﾜｯﾁｮｲ d70c-Mv6b)
17/07/08 20:16:14.47 +Hh7GS610.net
ずれるのって確定してたっけ。
何か確定してるみたいに、印象操作されてるみたいでやな感じ。
363:Socket774 (ｽｯｯﾌﾟ Sdbf-MVao)
17/07/08 20:36:27.87 kHnZJOoqd.net
>>163
Androidの中身はLinuxだって覚えとけよ、ボク
364:Socket774 (ﾜｯﾁｮｲ 9fba-3Bfy)
17/07/08 21:36:56.02 oMda4HEI0.net
>>362
ズレは確定どうズレるかは不確定
365:Socket774 (ｽｯﾌﾟ Sdbf-Mv6b)
17/07/08 21:49:50.14 M9Nol9Jqd.net
>>364
ありがとうございます。
認識不足でした。
それでしたら、ずることが確定のソースを教えていただけませんか。
366:Socket774 (ｽｯﾌﾟ Sdbf-Mv6b)
17/07/08 21:59:31.99 M9Nol9Jqd.net
〉〉365
ずる〉〉ずれる
367:Socket774 (ﾜｯﾁｮｲ 9703-/HDW)
17/07/09 01:30:12.02 fqwmRv8J0.net
何度もｽﾏｿ
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
368:Socket774 (ﾜｯﾁｮｲ 9f1d-1B52)
17/07/09 03:09:34.35 U8h6wyBl0.net
超高負荷でエラーが出る場合は
普段使いで数週間に1回だけ異常が出るか出ないかって感じ
負荷テストではエラー吐いたけど
普段はそんなに重い作業はしないので問題なしとしてる
ブログの人がたまにいるけど俺的には無理
369:Socket774 (ﾜｯﾁｮｲ ffa3-kNtm)
17/07/09 07:16:54.24 PuuvI7tH0.net
>>168
ニュースとして知ってるが、それは先の話で姑息なすり替えだね
370:Socket774 (ﾜｯﾁｮｲ 9735-KuRC)
17/07/09 08:03:12.70 vH6PuI050.net
>> 358
そこで切り分けできれば原因がECCよりも外側か内側(CPU側)か特定できる。
ECCが有効な状態でこの不具合が起きるなら、CPU側なので厄介。
だれかECC付きのシステムで試せないか？
371:Socket774 (ﾜｯﾁｮｲ bf51-2GVV)
17/07/09 08:31:35.88 o+k/ASSH0.net
>>338
OCCTで24h問題なしだったマシンで、Linuxで30分程度でsegvでたよ
372:Socket774 (ﾜｯﾁｮｲ bf51-2GVV)
17/07/09 08:33:18.66 o+k/ASSH0.net
>>367
つscreen
373:Socket774 (ﾜｯﾁｮｲ ff74-x/VO)
17/07/09 12:38:36.42 7N0pzCfH0.net
>>371
OCCT6時間終わってCPUクロックが切り替わった時に青画面とか普通にあるからな
CPUクロックと共にメモリクロックも下がるからこうなる場合がある
ビデオカードもHynixのVRAMで過去に問題が起きて、修正BIOSではVRAMクロックが固定化されたこともある
負荷かけて全速の時は良いがクロックが切り替わる時にコケることも少ない無いからね
特にコンパイルだと負荷変動があるのでOCCTより不安定になる事があるのでは
374:Socket774 (ﾜｯﾁｮｲ 9774-jTKI)
17/07/09 14:53:22.85 lTBY4ahB0.net
>>373
メモリクロックもスピードステップみたいになってるの？
もしそれで落ちたら笑う
375:Socket774 (ﾜｯﾁｮｲ d7ec-TkOv)
17/07/09 16:23:37.20 P60p5X3m0.net
ずれてる理論の人は、メモリの設定ミスが原因で不正なバイト列をデコーダに食わせただけだろうなあ。
現在のLinuxが取り扱えるMCEはメモリ周りのみ。Zen世代のMSR,MCEについてドキュメントがないのだからしょうがない。
AMDは早く17h Family BKDG出してください...
376:Socket774 (ﾜｯﾁｮｲ d7ec-1siI)
17/07/09 16:30:34.45 P60p5X3m0.net
SIGSEGV(一般的には Page Fault), SIGILL(Undefined Opcode)が起きてもコアダンプが正常であるなど普通に起こりうるのですよ。
実行時にInstruction Cacheが汚染されたとしても、片っ端からダンプを吐き出す作業中にその時のCacheが保持されている保証がない。
ECCメモリがおすすめされるのはこの手の起こりようがないエラーが報告として上がってしまうためなのです。
377:Socket774 (ﾜｯﾁｮｲ d7ec-1siI)
17/07/09 16:44:48.99 P60p5X3m0.net
連投すまん。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は黙ったまま)、
勝手に放火しているだけ。活発化したって、めちゃくちゃな英文で内容のない文句ばかりになったからまともな人まで相手にされなくなっただけ。。
恥ずかしいのでやめてください…
378:Socket774 (ﾜｯﾁｮｲ b737-tYQy)
17/07/09 16:53:03.49 6aBPIfsU0.net
>>377
素人に毛が生えた程度かな?
とは思う
379:Socket774 (ﾜｯﾁｮｲ d7ec-1siI)
17/07/09 17:03:21.87 P60p5X3m0.net
何も貢献しないのもあれなんで、無限コンパイル & コアダンプ保存のために使っているワンライナー置いておきますね。
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
…一晩走らせてみようっと
380:Socket774 (ﾜｯﾁｮｲ 5787-M+1A)
17/07/09 18:40:26.29 KqRzrJ620.net
たしかに現在の現象（負荷のかかるときにランダムでエラー）だと見た目では起動できているように見えても実はちゃんとした設定で起動できていないだけって感じもするよなぁ
初物で設定がシビアなCPUのはずなのになんでこんなSEGV騒いでるんだろう...
381:Socket774 (ﾜｯﾁｮｲ bfdd-BuHV)
17/07/09 19:34:45.07 MpTQDpGF0.net
頭がバグっているのが日本人だと思われているからな
382:Socket774 (ﾜｯﾁｮｲ 97c6-KuRC)
17/07/09 19:44:25.76 DOWGy17H0.net
とりあえず一方の言い分だけ見て物を考えるのは危険だと分かった
AMDフォーラムとかgentooフォーラム見ての感想
383:375 ( = 376-377, 379) (ﾜｯﾁｮｲ d7ec-TkOv)
17/07/09 19:47:19.67 P60p5X3m0.net
落ちない。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
384:Socket774 (ﾜｯﾁｮｲ 9767-nSBM)
17/07/09 19:47:42.62 Qvr4ECcR0.net
amdの奴でコンパイルしたryzen_test
エラーでないんだが?
385:Socket774 (ﾜｯﾁｮｲ b7c8-gXZb)
17/07/09 19:48:40.25 buEYTw/40.net
もうほとんど騒がれてないよ
他のスレじゃ全く気にされてないし、たまに団子がAMD煽るために持ち出すくらい
386:Socket774 (ﾜｯﾁｮｲ d7ec-TkOv)
17/07/09 19:56:02.46 P60p5X3m0.net
結局一部が馬鹿騒ぎしただけって落ちか。。
#自動でハッシュ表示されるから名前いらんのね。
387:Socket774 (ﾜｯﾁｮｲ d7ec-TkOv)
17/07/09 20:10:41.02 P60p5X3m0.net
>>384
あれは出るか出ないかは確率。Intel IA-32 Architecture的には出ても構わない。
強いCache Coherentが保証されるマルチプロセッサ構成では出ないし、
そうでなければ確率的に出る。それはIntelのCPUを使っていても変わらないです。
…つまり、試験をしている気分になれる試験
388:Socket774 (ﾜｯﾁｮｲ 9f5f-m5Ug)
17/07/09 20:28:06.80 8zydOYyY0.net
ちなみに暑くてもうやるのやめたけどASLR無効でもNG出たよ
今のところ新BIOS待ちだけど新しいのでもNGは出るんだろうなとは思う
あとは誰かがB2で試してNG出るかどうかかな
389:Socket774 (ﾜｯﾁｮｲ d7ec-TkOv)
17/07/09 20:29:25.38 P60p5X3m0.net
>>384>>387
std::atomic_intを使っているのかと思ったら
URLﾘﾝｸ(github.com)
> typedef volatile long atomic_int;
ってギャグ？これはひどい。貶すためにこんなものまで出回ってるのかー
本当の意味でのatomic_intと使用方法は以下の記事を参照してくださいな。
URLﾘﾝｸ(qnighy.hatenablog.com)
ここでのatomic_intは記事中の ./main 2 の実行結果と同じで結果は不定です。
390:Socket774 (ﾜｯﾁｮｲ b7c8-gXZb)
17/07/09 20:35:50.18 buEYTw/40.net
試しにLinux板の勢いが10超えてるスレ全部のレスでSEGV検索したけどHit 0だった
スレどころかレスもないし、実害被りそうな連中が全く気にしてないから、まあそういうことでしょうかね
391:Socket774 (ｱｳｱｳｳｰ Sa5b-tYQy)
17/07/09 20:37:16.50 +QrfFod0a.net
>>390
しょっちゅう出るからじゃ無いかな
392:Socket774 (ﾜｯﾁｮｲ 97c6-KuRC)
17/07/09 20:38:13.70 DOWGy17H0.net
>>389
意味が分からないんだが
atomic_intという名前のlongなのか
393:Socket774 (ﾜｯﾁｮｲ d7ec-TkOv)
17/07/09 20:58:18.04 P60p5X3m0.net
>>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で足りないケース
本当ははこの人は、実行されるコードを動的に変更して一貫性があるかどうかの差を見せたかったんだろうけど
何が起きたかって「私は並列プログラミングできません」と書かれたコードを世界中に晒したっていう
394:Socket774 (ﾜｯﾁｮｲ d7ec-TkOv)
17/07/09 21:00:47.33 P60p5X3m0.net
>>393
スペースは除去されるのね。しかも間違った orz
test1:
move %temp, *p <- pの中身をtempレジスタに入れる
add 2, %temp <- tempレジスタに2を足す
move *p, %temp <- tempレジスタの内容をpに入れる
return
395:Socket774 (ﾜｯﾁｮｲ 9f6e-n4zL)
17/07/09 21:00:49.18 w8qXKp8V0.net
なんか突然このスレきちんとした技術者が現れたな
396:Socket774 (ﾜｯﾁｮｲ d7ec-TkOv)
17/07/09 21:06:01.82 P60p5X3m0.net
>>390
確かに、（自称でない）Linuxガチ勢は問題ないでしょうね。
>>388
めげずにメモリの設定を見なおしてみてください。
BIOSのXMP,JEDEC設定、Advanced設定のスクリーンショットなどあればアドバイスできる…かも？
...
115 2017/07/09-21:00:04
116 2017/07/09-21:02:49
最初はBIOSデフォルトで死んでばかりだったが、もう失敗する気がしない。
397:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/09 21:07:36.68 9/b1+l3a0.net
コードは見てないけど、例の問題の現象とは合ってるの？
398:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/09 21:08:24.26 9/b1+l3a0.net
結局ソフトのバグだったってこと？
399:Socket774 (ﾜｯﾁｮｲ d7ec-TkOv)
17/07/09 21:12:41.27 P60p5X3m0.net
>>397
ryzen_testという名前のもの？中身はただのゴミですよ。擬似的に表現すると、
ぼくが考えた最強の試験()
{
while (お前の忍耐が切れるまで) {
CPUを食い潰す（）;
if (乱数(0~1.0) < 0.0001)
表示("失敗")
}
}
400:Socket774 (ﾜｯﾁｮｲ bf53-1B52)
17/07/09 21:13:44.32 LXE6oT0P0.net
www
401:Socket774 (ﾜｯﾁｮｲ 9fd1-3Bfy)
17/07/09 21:15:03.41 KKGf+Q0T0.net
>>399
超たまーに失敗でたのはわざとかよ
402:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/09 21:18:23.16 9/b1+l3a0.net
>>399
コンパイラの例外とは関係ないコード？
じゃあどうでもいい
403:Socket774 (ﾜｯﾁｮｲ 9f5f-m5Ug)
17/07/09 21:20:08.72 8zydOYyY0.net
>>396
メモリは総当たりやったよ今までで500回近く再起動してる
さすがに疲れた・・・
2133でも無理だったしまずクロックの変化ではまったく変化なしだな
今は今朝CMOSクリアした後のAutoのまま使ってるよ
最近は面倒でスクショすら貼る気なし暑いし
逆にそちらの設定教えてもらいたいくらい
404:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/09 21:21:30.86 9/b1+l3a0.net
誰か、今までを簡単にまとめてくれるとうれしい！
405:Socket774 (ｽﾌｯ Sdbf-9Dr/)
17/07/09 21:21:40.53 m1GumbATd.net
つまりB2ステッピング待つ必要ない感じですか？
406:,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｳｰ Sa5b-L5XL)
17/07/09 21:24:38.18 gJGagwd6a.net
なんか書こうと思ったけど腹筋崩壊して無理だったん
407:Socket774 (ﾜｯﾁｮｲ d7ec-TkOv)
17/07/09 21:25:09.12 P60p5X3m0.net
>>402
>>1 にあるryzen_segv_testというコードです。名前はryzen_testではありませんでした。すみません
URLﾘﾝｸ(github.com)
Linux kernelをコンパイルするのが流行っているのは試験としては
・負荷がかかる
・実用的メモリテスト、キャッシュを兼ねる
・コンパイル時にコンパイルするための実行ファイルを動的生成するのでバグに当たる確率が跳ね上がる
単純化するとgccに負荷をかけた際に問題が生じる確率pとして、動的生成されたコードpによって同じくpの確率で問題が生じる
-> 1-(1-p)^2 ~= 1-p^2 (pが0に近い場合
.-> 問題が表面化する確率が2乗になる
という理由ですね。
408:Socket774 (ﾜｯﾁｮｲ 9fd1-3Bfy)
17/07/09 21:25:16.31 KKGf+Q0T0.net
ryzenテストみたいなプログラムがゴミだったというだけだろ
B2待てるなら他にも細かいバグいくつか修正されるだろうから待ったほうがいい
409:Socket774 (ﾜｯﾁｮｲ d7ec-TkOv)
17/07/09 21:26:37.66 P60p5X3m0.net
>>403
ちょっと出かけちゃうので明日こちらの構成を書きますね。
...
123 2017/07/09-21:22:04
124 2017/07/09-21:24:50
410:Socket774 (ﾜｯﾁｮｲ d7ec-TkOv)
17/07/09 21:27:59.44 P60p5X3m0.net
現世代のマザーボードとメモリの組み合わせには疑問があるので待てるなら待ったほうがよいのでは？
411:Socket774 (ﾜｯﾁｮｲ ffa3-kNtm)
17/07/09 21:28:28.86 PuuvI7tH0.net
>>406
説明できないのが団子クオリティ
412:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/09 21:28:31.69 9/b1+l3a0.net
>>407
すいませんが全く意味がわかりません
413:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/09 21:30:18.08 9/b1+l3a0.net
とくに確率計算がチンプンカンプンです
414:Socket774 (ｵｲｺﾗﾐﾈｵ MM4f-mmpI)
17/07/09 21:30:26.15 Scd+neCuM.net
>>389
隠す必要も無いので白状するが、このコードの作者なのだが、あまりにひどい誤解に基づいているので何点か補足を。
Linux版（というかMSVC以外）のコードを見てくれ。
君の言う悪いtypedefはMSVC以外では行われない定義だ。そしてstdatomicを使った正しいコードになっているはず。
まず精髄反射的にあげつらうのではなく、コードをちゃんと読んでからコメントをしてくれ。
そして、Windowsでもコード書き換えのスレッドとその実行スレッドの同期はMSVCプラットホーム固有のマルチスレッド同期用のプリミティブを使って正しく同期が行われているはず。
volatileに頼った不正なマルチスレッドプログラムではない。（そもそもその同期プリミティブの変数型がvolatileなのでそれに合わせているだけ）
また、atomic_tとかにtypedefしてるのはLinux用のコードとなるべく共通化するためで全くギャグなどの意図はない。
他にも幾つか突っ込みたい点はあるが、まずはこの点についてご確認いただけるとありがたい。
415:Socket774 (ｽﾌｯ Sdbf-9Dr/)
17/07/09 21:30:55.42 m1GumbATd.net
>>408
頑張って待ちます……！
416:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/09 21:33:03.27 9/b1+l3a0.net
早とちりで >>389 を書いちゃったとしたらはずかしすぎるな
417:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/09 21:34:57.38 9/b1+l3a0.net
というか、これは謝罪しないと
まともに同期処理や排他制御が出来てるかどうかはコードを見てないので知らんけど
418:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/09 21:36:42.91 9/b1+l3a0.net
非常に単純なコードで問題が再現するようになったのであれば、解析としては一歩前進
419:,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｳｰ Sa5b-L5XL)
17/07/09 21:40:46.21 gJGagwd6a.net
たぶん古いVC使ってたんじゃない？
2017にはさすがにC++1y（追加で1zの一部も？）対応してるよ
なんとなくバグの検証の効果としてはともかく古いVCなら_InterlockedIncement使うべきコードってのはわかる。
420:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/09 21:46:18.95 9/b1+l3a0.net
勘違いしたのは団子か
421:Socket774 (ｵｲｺﾗﾐﾈｵ MM4f-mmpI)
17/07/09 21:52:52.41 Scd+neCuM.net
んでもって、マルチスレッドのデータ同期としてはここまで書かれてるようなことに気をつければよくそこまで難しい話ではないし、
稀に失敗するというようなことはあってはならないしあればとっくにあらゆるマルチスレッド系のアプリで問題が出てるはず。
問題はデータとして書き込んだ命令の実行のときであって、
命令はデータとは独立したキャッシュなどを備えているのでデータ的に同期が取れているだけでは不十分で、
追加の（しかも非常にCPUのアーキテクチャ依存の）操作が必要となる。
詳しくは省略するが、AMDやintelのドキュメントで言及されているserializing instructionという命令を使用する必要がある。
このテストコードではそれを正しく使用しているはずだが、
たしかにこれについては事例も少なく非常にプラットホーム依存で難しい話なので100%の自信があるわけではないし、不備があったら教えていただきたい。
（というかx86は強いコヒーレンシが保証されてないからコード書き換えとその実行は確率的に失敗するようなものなのか？それを保証するためのシリアライズ命令というバカみたいにペナルティ大きい命令ではないのか）