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は強いコヒーレンシが保証されてないからコード書き換えとその実行は確率的に失敗するようなものなのか？それを保証するためのシリアライズ命令というバカみたいにペナルティ大きい命令ではないのか）
422:Socket774 (ﾜｯﾁｮｲ b7c8-gXZb)
17/07/09 21:55:29.40 buEYTw/40.net
>>404
B2待ち
423:Socket774 (ｵｲｺﾗﾐﾈｵ MM4f-mmpI)
17/07/09 21:56:28.69 Scd+neCuM.net
>>419
残念ながらMSVCはC言語のほうはやる気がなく、最新の言語仕様全然取り入れられないんすよね
424:Socket774 (ｱｳｱｳｳｰ Sa5b-tYQy)
17/07/09 21:58:51.38 lAbyLl8pa.net
確かどっかの文章でlockじゃ不十分だからMFENCEとやらとかCPUIDとやらとかを使えって書いてあったが、そういった話だろうか
425:Socket774 (ｵｲｺﾗﾐﾈｵ MM4f-mmpI)
17/07/09 21:59:38.28 Scd+neCuM.net
>>424
具体的にはそれらの命令ですね
426:,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｳｰ Sa5b-L5XL)
17/07/09 22:00:33.10 gJGagwd6a.net
コンテクストスイッチに起因する問題とするならスレッド起こしまくってみるのが良いのでは
427:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/09 22:02:49.96 9/b1+l3a0.net
>>421
作った本人が自信が無いようなコードじゃ、検証としてはちょっと...
428:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/09 22:04:14.03 9/b1+l3a0.net
>>426
言い出しっぺの法則
429:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/09 22:05:42.91 9/b1+l3a0.net
ていうか、誰もコンテクストスイッチの問題なんていう話題はしてないけど
430:,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｳｰ Sa5b-L5XL)
17/07/09 22:09:05.85 gJGagwd6a.net
なんとなくマルチスレッド化できてだれがやっても同じ答えが出るべき問題、たとえばN-Queen問題あたりを検証するといいかも、と思いました。
まあ、それでバグ踏むとは限らないけど
431:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/09 22:11:59.55 9/b1+l3a0.net
ちょっとは上の文を読んでから書いた方が良いと思うよ
432:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/09 22:18:15.29 9/b1+l3a0.net
多少でもプログラムを知ってたら、>>421の書き込みを読んだ後に>>430の書き込みは有り得ない
433:Socket774 (ｵｲｺﾗﾐﾈｵ MM4f-BuHV)
17/07/09 22:18:26.56 TOa3RctGM.net
>>422
待たなくていい
買いたいときに買えばいい
SEGV騒いでる奴は勘違い君
434:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/09 22:20:53.17 9/b1+l3a0.net
永遠に次を待ち続けるような人でしょ
B2がでたらB3を待つような
435:,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｳｰ Sa5b-L5XL)
17/07/09 22:23:56.63 gJGagwd6a.net
いまココ読んでる
（藤井さんはuop cacheが怪しいとみてる1人）
URLﾘﾝｸ(fujii.github.io)
436:Socket774 (ﾜｯﾁｮｲ 9703-/HDW)
17/07/09 22:25:00.45 fqwmRv8J0.net
>>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教えてほしいな
(追試した本人に限る)
437:,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｳｰ Sa5b-L5XL)
17/07/09 22:26:20.24 gJGagwd6a.net
>>432
そもそも自己書き換えに意味があると思ってないからね
gccに該当する処理はないはず
438:Socket774 (ｵｯﾍﾟｹ Srcb-+Bwc)
17/07/09 22:26:21.80 a+BgklOkr.net
急にマトモな議論が始まった感
wktk
439:Socket774 (ｱｳｱｳｳｰ Sa5b-tYQy)
17/07/09 22:28:02.30 lAbyLl8pa.net
>>438
そうか?
440:,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｳｰ Sa5b-L5XL)
17/07/09 22:37:09.92 gJGagwd6a.net
JITの検証という意味では、いまどきのJITコンパイラは既に実行属性が与えられてる命令列を書き換えるのではなく新たに領域を割り当ててコード列を書き込んで実行属性を書き換えます
ページ属性を書き換えてデータとして書き込んでまた実行属性戻すとか、メモリがよっぽど足りない環境でない限りは普通やらないですね
コンパクトな実装ではXbyakがIntel公式のライブラリにに採用された実績がありますよ
441:Socket774 (ｵｯﾍﾟｹ Srcb-+Bwc)
17/07/09 22:37:33.75 a+BgklOkr.net
>>439
結論出ないまま自然消滅かと思ってたところに、375からの流れだったので。
442:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/09 22:41:36.32 9/b1+l3a0.net
>>437
つまり、
流れを読まずに唐突に自分の思い付きを語ったわけだ
443:,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｳｰ Sa5b-L5XL)
17/07/09 22:41:40.18 gJGagwd6a.net
gccのなかで自己書き換えやってるコードがあるならまだわかるけど無いでしょ？
それでたまたま不具合見つけてもgccのSEGVとはまた別の問題だと思いますけど（CPUの問題ですら無い可能性も
444:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/09 22:44:09.54 9/b1+l3a0.net
普通に作ったN-Queen問題なんかで発生するならもっと大きな問題になってるでしょ
445:,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｳｰ Sa5b-L5XL)
17/07/09 22:44:51.87 gJGagwd6a.net
もしメモリに問題があるならマルチスレッド化したN-QueenとかPiでも問題が出る可能性は高いと思ってますがね
446:421 (ﾜｯﾁｮｲ ff63-pw7F)
17/07/09 22:46:06.79 EXx9vkeL0.net
>>441
うーん、というかコード全く読まない（読めない？）人が
頓珍漢な指摘を連投しただけで、それに対するツッコミだけで、
基本的には何ら新しいことは書いてないっす
今ここで話題になってる程度のことは各所で散々語られてますし
>>443
自己書き換えが手っ取り早くL1Iやuopcacheを汚染する手段だからやってるだけで、
別に自己書き換えが直接的だと言いたいわけではないです
まあおっしゃるとおりこのコードの再現するものがgcc等のSEGVと同じ問題と断言はしないです
根底で共通する部分があるんだろうと僕はにらんでますが（L1Iやuopcacheの同期まわり）
447:Socket774 (ｱｳｱｳｳｰ Sa5b-tYQy)
17/07/09 22:46:43.40 lAbyLl8pa.net
>>445
じゃあ作ってくれ
448:Socket774 (ﾜｯﾁｮｲ ff63-pw7F)
17/07/09 22:51:47.99 EXx9vkeL0.net
ちなみに大量にメモリ上に配置した関数をランダムに呼ぶとかで
命令キャッシュまわりを混乱させるプログラムは作ってみましたが、
まあその程度ではSEGVしませんでしたね。
あとリンクやOSの動的リンクでは大量の関数を自在に配置するのは面倒で、
メモリに自在に配置するには自己書き換えが一番手っ取り早く、
それをやってたら発見したというのが今のコードです
ランタイムの自己書き換え無しでSEGV起こせるコード見つかったら
それは大変説得力あるので（自己書き換えにバグあるんだろうという懸念を排除できる）
ぜひ頑張って作ってほしいと思う次第
449:Socket774 (ﾜｯﾁｮｲ 9f6e-n4zL)
17/07/09 22:52:11.90 w8qXKp8V0.net
マルチスレッドPiってy-cruncherじゃだめなの
450:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/09 22:52:30.21 9/b1+l3a0.net
>>445
メモリの問題として、なぜその二つ？
もっと普通のテスト用コードを書いた方がマシだと思うけど
451:,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｳｰ Sa5b-L5XL)
17/07/09 23:06:27.19 gJGagwd6a.net
ページの実行属性取り上げて書きこみ可能の属性与える段階で一旦命令キャッシュをフラッシュするのが規定の動作のはずなので
自己書き換えによって命令キャッシュが汚染されるということが起こりうるという仮説をまず疑う必要があるかなと思いますね。
それともOSによってはExecutableとWritableの属性同時につけるの許可してるの？
452:,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｳｰ Sa5b-L5XL)
17/07/09 23:08:27.20 gJGagwd6a.net
>>450
正常に動いていれば誰でも同じ出力になるので再現性があるし、スパコンのハードの動作検証でよく使われてきたから
453:Socket774 (ﾜｯﾁｮｲ ff63-pw7F)
17/07/09 23:08:30.94 EXx9vkeL0.net
>>451
あなたもちゃんとコード読んでくれｗ
Linuxならmmap、WindowsならVirtualAllocで余裕でできる。
もちろん正規の方法でリンクされたコード領域はWritableにならないのは近代的なCPU+OSなら普通。
454:Socket774 (ﾜｯﾁｮｲ d737-0UkT)
17/07/09 23:13:36.53 9/b1+l3a0.net
>>452
誰でも同じ出力になる
よりも
正しいか正しくないかが他と比べなくても単独でわかる方が良い
メモリテストであれば、演算はどちらかというと軽い方が良い
という事で、クイーンもパイも不適切
という個人の感想
455:Socket774 (ﾜｯﾁｮｲ 9f63-AnYK)
17/07/09 23:25:35.40 wp7EeTxf0.net
単独で分かるとかいうが今はそのプログラムは本当に正しいのかって言われてるんだと思うぞ
まずは既に実績のあるプログラムで比較するのが先で、そこで問題が再現してから問題の部分を絞り込んでいく方が説得力がある
もちろん実績のあるプログラムもシンプルで検証しやすいものを選択する
gccはデカすぎて絞り込みの難度が高すぎるんじゃないか？
456:,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｶｰ Sa2b-L5XL)
17/07/09 23:29:29.92 Kdzq/R6Ia.net
いずれにしてもコヒーレントを保つために書き換えたキャッシュラインは無効化されるのが規定の動作のはずなので、命令列を書き換えた時点で（おそらくL0,L1もろとも）流れるんじゃないかな？
どのみち意味があると思えないな
457:Socket774 (ﾜｯﾁｮｲ ff63-pw7F)
17/07/09 23:34:36.08 EXx9vkeL0.net
＞いずれにしてもコヒーレントを保つために書き換えたキャッシュラインは無効化されるのが規定の動作のはず
その根拠をお願いします
むしろ勝手に無効化はしないから同期が必要な場合はserializeしろってAMD、Intel共にドキュメントに書いてあるように読み取れるんだが
ちなみにcpuidやmfenceを外すと余裕であらゆるプロセッサでSEGVるので明示的にこういう命令がまさに必要ということでは
458:,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｳｰ Sa5b-L5XL)
17/07/09 23:49:48.65 gJGagwd6a.net
CPUIDやMFENCE使うんだろ？
そこでキャッシュコントローラが変更検出したら無効化よ
単にキャッシュラインのクリアしたいだけならclflashというZen専用命令があるぜ
459:Socket774 (ﾜｯﾁｮｲ ff63-pw7F)
17/07/09 23:53:41.83 EXx9vkeL0.net
>>458
いや、だから明示的に無効化（に加えて実行パイプラインも全部破棄）してるんですよ
なのに、segfaultするからおかしいでしょ？っていう話なんですよ
パイプラインまわりのロジックに不備があって古いuopかL1I由来のものを実行してしまう不具合があるんじゃないかって話で
460:Socket774 (ﾜｯﾁｮｲ ffa3-kNtm)
17/07/09 23:57:38.11 PuuvI7tH0.net
いつまでも大規模プログラムでガラガラポンはおかしいわな
461:Socket774 (ﾜｯﾁｮｲ 9787-pw7F)
17/07/10 00:10:32.57 xsG24xip0.net
>>459
団子氏と何を議論しても無駄だよ？
彼は、実行可能なソースコードを晒すなんて危険な行為は絶対にしないし、
インテル至上主義のアンチAMDだから、テスト環境を購入することすら金の無駄だと考える。
つまり、理屈はこねるが実践はない。
462:Socket774 (ﾜｯﾁｮｲ ff63-Razr)
17/07/10 00:21:11.31 btQHcaKW0.net
3770Kでもsegvが出たという報告があるな
URLﾘﾝｸ(twitter.com)
463:,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｳｰ Sa5b-L5XL)
17/07/10 00:24:13.99 OA9AmyQya.net
そら金のためにしかコードは書かないよ
自分の技術を安売りするなは職人だった叔父の遺言だ
464:,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｳｰ Sa5b-L5XL)
17/07/10 00:29:40.37 OA9AmyQya.net
とはいえXbyakとかJTRにコードコミットしてんだけどな、昔
465:Socket774 (ｱｳｱｳｳｰ Sa5b-tYQy)
17/07/10 02:22:13.93 ztovuboUa.net
jなしのmakeって再現例あったっけ
466:Socket774 (ﾜｯﾁｮｲ d7ec-RBu5)
17/07/10 03:10:58.67 vUhtUjpU0.net
もうこんな時間…すみません。。 > 誰か
>>414
私もあなたも名無しさんですから、自称作者さんということにしておきますね。私もただの通りすがりの一人
gccには-Sオプションがあります。あとはgrep -w "lock"はわかりますよね？それが第一歩です
次にatomic_compare_exchange_(strong|weak)とatomic_exchange_explicitの違いについて学習しましょう。
Acquire/Release, Release/Acquireを学ぶ前にSequentially-consistentを学びましょう。
mfense系のintrinsic命令はそれからです。
もしここで作者がこれを取り下げるとforkが増えてしまう気がするのでそれは望ましくないのですが(見ているかもしれませんし)、
もし作者がこれらの命令について十分な知識があると主張されていて、>>1 に書かれるように実証として
これが特定の対象への価値毀損の主張に用いられていることも知っていたとしたらどうでしょうか？
…まあ、ただの通りすがり同士の独り言のすれ違いということで、
こういう時はマンガかアニメから台詞でも引用してみたいところです。
467:Socket774 (ﾜｯﾁｮｲ d7ec-TkOv)
17/07/10 03:39:48.32 vUhtUjpU0.net
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
468:Socket774 (ﾜｯﾁｮｲ d7ec-TkOv)
17/07/10 03:41:27.19 vUhtUjpU0.net
>>412 >>413
簡略化しすぎました。特にscripts/genksyms以下は単なるスクリプトではなくmake時コンパイルです。
このscirpts/genksyms/genksymsはlexer,parserを持ち影響を及ぼすので一種のコンパイラとして動きます。
そのため、make時にコンパイルされた一種のコンパイラがその後のmakeの実行に影響を与えてしまいます。
「一種のコンパイラ」のコンパイルに成功しなければならず、
その後の動作は「コンパイラ」と「『一種のコンパイラ』を生成したコンパイラ」の正確性に依存するのです。
その前後に対する定数項は無視しても構わなくなり（これは非常に正確ではないが最悪の推定でもある）、
簡略化するとあのように2乗の項が出てしまいます。
その後の話は… >>436 >>462 以外の長文はよくわからないです。ごめんなさい、大丈夫ですか？
469:Socket774 (ﾜｯﾁｮｲ d7ec-TkOv)
17/07/10 03:58:13.80 vUhtUjpU0.net
う、ミススペリング…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
470:Socket774 (ﾜｯﾁｮｲ 17f8-u6mz)
17/07/10 04:08:39.29 nllT4Noz0.net
>>399
やっとあのプログラムの第三者レビューが来たのか
それもやらずにこのスレに持ち込んでエラーが出たとか騒がれているのは正直迷惑だった
471:Socket774 (ﾜｯﾁｮｲ d7ec-TkOv)
17/07/10 04:54:07.34 vUhtUjpU0.net
数人の日本人が馬鹿みたいに騒いで(単独では)問題のない商品の価値毀損して回っている状況…
なだけに正当な議論の中にいたいがために正確に記述を重ねていこうと思うとつらさあります。訴えられたくないし
でたらめ多すぎもいい加減にしてほしい。日本人が騒いでいるために英文の検索結果まで汚染とかまじかー
28h46m50s-15h50m37s = 12h56m13s in 286 iterations near equals 2m43s.
...
285 2017/07/10-04:44:04
286 2017/07/10-04:46:50
472:Socket774 (ﾜｯﾁｮｲ d7ec-TkOv)
17/07/10 04:56:28.45 vUhtUjpU0.net
どうでもいいけどTwitter名にSEGVをつけて検索で妨害かけた結果、は功績大きいのだけれど、文脈的にはLCAに確認取ったほうがいいんじゃないの…っていう…
473:Socket774 (ﾜｯﾁｮｲ d7ec-TkOv)
17/07/10 05:33:04.70 vUhtUjpU0.net
>>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行に込めた思いは名無しとして名無しさんには受け取ってもらいたい
大騒ぎしていた一派が成し遂げたことって、問題解決の妨害だけじゃないか。よくあんなことができるなー
474:Socket774 (ｱｳｱｳｶｰ Sa2b-sYsE)
17/07/10 05:39:07.57 GjW3DRqYa.net
ということはあの一行ってとんでもないことやってるんだと…
475:375 (ﾜｯﾁｮｲ d7ec-TkOv)
17/07/10 05:53:05.58 vUhtUjpU0.net
>>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
476:Socket774 (ﾜｯﾁｮｲ ff01-1B52)
17/07/10 06:14:46.48 XWwUfyfu0.net
結局のところスレタイ通りのおま環だったのだけど、まずRyzenの
プラットフォームが未成熟で若干メモリに渋いのと、意図的かどうかは
ともかく間違った検証用プログラムに依るエラーが混ざって原因を
見えにくくしていた、ということなのかな？
477:,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｶｰ Sa2b-L5XL)
17/07/10 07:50:01.44 XRoJrlAOa.net
そもそもこのgccと全く関係ないプログラムが正常に動く環境どんだけあんの？
自己書き換えの決まりごとのうち、もとの命令列を書き換える場合、すなわちオプション2の場合はCPUIDなどのシリアライズ命令を発行しろとある
Java HotSpotやXbyakはオプション1の方法を使っててカーネルコールで実行属性書き換えるだけでいい
URLﾘﾝｸ(www.dotup.org)
URLﾘﾝｸ(www.intel.com)
ただこれだけだと不十分で、メモリシリアライズより前のタイミングでスレッドが切り替わった場合の動作保証ないからユーザーモードで確実にやるには割り込み禁止かけるなどちゃんと手順踏む必要あったはずなんだけどどうですかね？
HotSpotとかXbyakはユーザーモードで保証するのが結局めんどくさいからオプション1の方法を使ってたはず
478:名無しさん＠そうだ選挙に行こう！ Go to vote! (ﾜｯﾁｮｲ 1757-u6mz)
17/07/10 08:04:06.31 mYneS+wI0.net
>>383
＞BIOSのメモリ設定がRyzenのほうではなく過去のAM4プロセッサを向いているんじゃないか疑惑。
これはどういう意味？
BIOSのメモリ周りがRyzenをBristolRidgeと勘違いしているという事？
何をもってそう判断したか聞きたい
あと詳しそうだから一つ意見を聞きたい
Low latency kernelを使うとSEGV出なくなるらしい(48時間位の実績あり)のだが、これについてはどう考える？
479:名無しさん＠そうだ選挙に行こう！ Go to vote! (ｱｳｱｳｶｰ Sa2b-nSBM)
17/07/10 08:21:39.89 deizR1yRa.net
結局プログラムに問題があるってことでいいの
480:Socket774 (ﾜｯﾁｮｲ 9703-/HDW)
17/07/10 08:38:12.14 D5J0IeMz0.net
>>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
481:,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｶｰ Sa2b-L5XL)
17/07/10 08:42:59.16 C8+wZvtra.net
改行コード化けてるのエラッタのせい？
482:Socket774 (ｽｯﾌﾟ Sd3f-0UkT)
17/07/10 08:50:52.64 yRv01w3yd.net
団子のエラッタは親のせい？
483:,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｶｰ Sa2b-L5XL)
17/07/10 09:03:42.74 C8+wZvtra.net
>>479
このプログラムが自己書き換え時のキャッシュ同期ミスってるだけなのでメモリ買い換える必要もない
そしてgccの現象は全く別原因
484:Socket774 (ｽｯﾌﾟ Sd3f-0UkT)
17/07/10 09:05:57.62 yRv01w3yd.net
IPが64バイトずれるんだっけ？
485:Socket774 (ﾜｯﾁｮｲ ff63-pw7F)
17/07/10 09:11:06.69 zPTrTH910.net
>>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を用いているわけです。
ここはマルチスレッドプログラミングの相談スレではないので、
繰り返しになりますが、コードを読んだうえで具体的に問題がある部分をご指摘願います。