17/07/01 18:36:05.32 IrZEpoL90.net
結局はエラッタじゃなくコンパイラーが腐ってただけか
そりゃ環境や状況揃えても再現出来ないわな
51:Socket774 (ワッチョイ 066c-MxJY)
17/07/01 18:45:32.59 k5sCmtIe0.net
>>48
プログラムがスパゲッティとかラーメン構造の橋とか美味しそうな名前で好き
52:Socket774 (ワッチョイ 2e63-k1q/)
17/07/01 18:50:00.93 WW/T/mcD0.net
>>50
んなわけねーだろ
どんな腐ったプログラム実行しても、命令ポインタがずれて実行されるなんてことは起こらない
53:Socket774 (ワッチョイ 2e63-k1q/)
17/07/01 18:56:09.96 WW/T/mcD0.net
アーキテクチャが変わって最適化が不十分でパフォーマンスが発揮されない、
とかの問題と、
そもそもプログラムが正常に動作しないってことの違いぐらいは区別付けてくれ
百歩譲って対応してない命令を実行したとかで動作しないことがあったとしても、
(実際にFXで対応していたいくつかの命令はZENで非対応になってる)
それと命令ポインタがずれることは全くレベルが違う問題
54:Socket774 (ブーイモ MMb6-ovUu)
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はもうとっくに原因解析してわかってるはず
なぜダンマリなのかはわからん
1.BIOSアップデートで対応可能、後日発表
2.BIOSで修正不可、コストがかかる全数リコールしなくてもいいように、
法務や弁護士等と対応策を打ち合わせてる
このどちらかとおもう
案外2.なのでは?
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
それのほうがいいなw
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回あたり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だったわw
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の公表したエラッタには普通、ワークアラウンドが用意されている。
それに従って改変したものは、当然x86バイナリであるから、
エラッタのある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回連続でビルド成功が続いてるw
なんだこれw
>>183
1800X, asrock AB350 gamingK4 biosは最新&デフォルト設定, メモリは忘れたw
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
エラッタww
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
変な奴に絡まれてるなww
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で落ちたのが1回 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
なんでパートナーにまでだんまり決め込んでると判るの?
これまで3桁にものぼるエラッタを公表してきたのに、それ、全部一般に認識されてる?
むしろ一緒に検証してる最中かも、と考えられなくもないと思うけども。
てか、もしだんまり決め込まれてるとしたら、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はいつも激怒してるw
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まず1回テスト
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ちゃんねるのスレが役立つと思ってるほうがウケるw
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ダウンロードしてテストしてくれと言ってもやるような人たちじゃないだろうけどw
自分が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回中1回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をなんだと思ってるんだw
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回中1回segfault(#275)でしたと
最適化は効果なかったかな
その環境は捨ててarch 0701版で追試中
5回回らないうちに1回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
というか、これは謝罪しないと
まともに同期処理や排他制御が出来てるかどうかはコードを見てないので知らんけど