【エラッタ?】Ryzen SEGV検証Part.3【おま環?】at JISAKU
【エラッタ?】Ryzen SEGV検証Part.3【おま環?】 - 暇つぶし2ch341: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
というか、これは謝罪しないと
まともに同期処理や排他制御が出来てるかどうかはコードを見てないので知らんけど

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回中1回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
あなたもちゃんとコード読んでくれw
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を用いているわけです。
ここはマルチスレッドプログラミングの相談スレではないので、
繰り返しになりますが、コードを読んだうえで具体的に問題がある部分をご指摘願います。

486:Socket774 (ワッチョイ ff63-pw7F)
17/07/10 09:25:13.12 zPTrTH910.net
>>477
>ただこれだけだと不十分で、メモリシリアライズより前のタイミングでスレッドが切り替わった場合の動作保証ないからユーザーモードで確実にやるには割り込み禁止かけるなどちゃんと手順踏む必要あったはずなんだけどどうですかね?
そういう記述はどこにありますか?
「8.3 SERIALIZING INSTRUCTIONS」のセクションには例として特権命令と非特権命令が挙げられていますが、
非特権命令が存在する時点でユーザーモードからの実行を認めているということでしょう。
割り込み云々はOSが面倒を見るべきことですね。
例えばLinuxのsync_core()内でまさにiretqというserializing instructionが実行されてます。
仮にユーザーコード側でcpuidを行ったあとコードを実行する前に割り込みが入り、
戻ってきたとき違うコアに移動していたとしても、
それはOSが制御を戻す前にiretqでまさにシリアライズが行われた後ということになります。

487:Socket774 (スップ Sd3f-0UkT)
17/07/10 09:26:47.67 yRv01w3yd.net
自己改変コードじゃなくて発生できるならそれに越したことはない

488:Socket774 (ワッチョイ 9703-/HDW)
17/07/10 12:20:12.98 D5J0IeMz0.net
>>379
使ってるスクリプト違うんですね
揃えてみようかな
今まで使ってたのはコレ(NG出ても続行する)
>>167

489:Socket774 (ワッチョイ 17e5-FjRN)
17/07/10 12:46:11.95 gF0m4kO40.net
団子ここでも知ったかで邪魔してんよかよウゼーな

490:Socket774 (ラクッペ MM8b-ay8l)
17/07/10 12:47:45.90 xsaaAYEoM.net
>>483
解ってないなら黙ってろよカス

491:,,・´∀`・,,)っ-○○○ (ブーイモ MMdb-8o87)
17/07/10 13:45:51.21 vNc9M597M.net
今日から俺も団子になる!

492:Socket774 (ワッチョイ ffa3-kNtm)
17/07/10 14:05:22.18 afYdRrtv0.net
>>491
死ね

493:Socket774 (ワッチョイ f78e-9ibE)
17/07/10 14:10:10.11 BDzCukHt0.net
RYZEN SEGV test codeの使い方がわからねぇ・・・
./run.sh 8 2500000
って入力したら「許可がありません」って出るし
sudo ./run.sh 8 2500000
ってやったら「コマンドが見つかりません」って出るしどうすりゃいいんだ・・・

494:Socket774 (スプッッ Sd3f-f1dv)
17/07/10 14:33:30.75 N1uqdIZrd.net
コンパイラがチンチンでした、またはメモリ回りが不安定で出てました辺りに落ち着くんかね

あと団子が引っ掻き回したくてしょうがないというどうでも良いことくらいか

495:Socket774 (ワッチョイ d7ec-TkOv)
17/07/10 14:57:39.61 vUhtUjpU0.net
>>486
あなたのコードには実際には一度もlock prefixかかってないんですよ。gcc5.4.0~gcc7.1.0でも確認済み…
Sequentially consistencyすら理解できていないからatomic_intをvolatile intのように扱ってしまう。
同時にlock_enter()/lock_leave()できるlockって何ですか…
勉強しなおしてください。
もうこのスレッドとは関係なくなりましたね。

496:Socket774 (オイコラミネオ MM4f-mx7j)
17/07/10 15:05:18.87 mfYsQ4wlM.net
技術者バトル面白いやりあってくれて構わない
twitterじゃこうバチバチやりにくいだろうし

497:Socket774 (ワッチョイ ff63-pw7F)
17/07/10 15:26:00.06 zPTrTH910.net
>>495
>あなたのコードには実際には一度もlock prefixかかってないんですよ
xchg命令は片方がメモリオペランドの場合「暗黙に」lock prefixがかかってるんですよ
そしてx86のxchgはこのような用途に使える(単純なスピンロック)に使えることは有名です
だからこそatomic_exchangeは単なるxchgにコンパイルされるんですよ
これは僕が馬鹿なわけでもコンパイラが馬鹿なわけでもなく、x86のxchgはそういう命令だからです
あなたこそx86のメモリモデルや命令についてもう少しお勉強なさってはどうでしょう
>同時にlock_enter()/lock_leave()できるlock
よってそれはできません

498:Socket774 (ワッチョイ ff63-pw7F)
17/07/10 15:39:57.45 zPTrTH910.net
ほんとなんでx86アセンブリ入門みたいなスレでもないのに、
x86のxchgの解説なんてしなきゃいけないんだ
しかも教わるべきほうがもうこのスレッドとは関係なくなりましたねなんて言ってる始末

499:Socket774 (スップ Sd3f-6cEx)
17/07/10 15:55:53.53 6SD4edDAd.net
初めからメモリーが悪いって結論ありきで騒いでるから
生半可な知識で原因()を特定したつもりになってそれ以上調べないんだろうな
C++11のstd::atomicとC11のstdatomicを混同したり
gccとmsvcのifdef切り分けが読めなかったり

500:Socket774 (アウアウカー Sa2b-nSBM)
17/07/10 16:57:46.76 +MQIIZL3a.net
プログラムが不正だったからコンパイラによってエラーがでたりでなかったりってことかね?

501:Socket774 (スップ Sd3f-0UkT)
17/07/10 17:42:56.88 yRv01w3yd.net
トンチンカンな指摘してるのは団子だから、無視するに限る

502:Socket774 (スップ Sd3f-0UkT)
17/07/10 17:43:28.80 yRv01w3yd.net
団子はアセンブラが書けない

503:Socket774 (スプッッ Sdbf-ay8l)
17/07/10 19:14:11.53 9HHBRBqLd.net
いくら団子でも簡単なハンドアセンブル位できるだろ?

504:Socket774 (スップ Sd3f-0UkT)
17/07/10 19:19:35.72 yRv01w3yd.net
数行のアセンブラでバグ入り
明らかにアセンブラは苦手ですって感じなコード
アセンブラで組むヤツはバカって感じな言い訳してたな

505:Socket774 (ワッチョイ b7ec-rvkC)
17/07/10 19:37:36.95 v4LJgRvu0.net
6
4












506:Socket774 (スップ Sd3f-0UkT)
17/07/10 19:41:28.77 yRv01w3yd.net
そうだね
64バイトくらいでいちいち気にしてたらAMDユーザーはつとまらん

507:Socket774 (バッミングク MM9b-M+1A)
17/07/10 20:56:49.52 xXdT4h8CM.net
いろんなgccでlockかかっていないとか変なこと言うより
ひとつのgccでSオプション付けたのの該当関数部分を貼ってほしいw

508:Socket774 (ワントンキン MM7f-AnYK)
17/07/10 20:58:04.51 1KC+tQwdM.net
端から見た感想
プライドが無駄に高いのはわかった
しかしコード読めは無いわ
ちゃんと最初に実装の意図まで全部説明せえよ
お前が逆の立場で俺様のコード完璧だからコード読めと言われて素直に応じるのかと
普通にお前のコードバグってるだけじゃねって疑うだろ?

509:Socket774 (ワッチョイ ff63-pw7F)
17/07/10 21:11:41.42 zPTrTH910.net
>>508
そう感じさせたなら申し訳ないです
実際そういう部分もあると思うので自戒しないとですね
ただ、いきなり
>>389
>>393
>>399
こういう対応されたらさすがにカチンときますよ
こちらのコードを実装の意図から丁寧説明する気にはさすがに……
最初から
「あなたのプログラムを検証したいが、○○という部分はどういうこと?」
「このプログラムの趣旨はどういう処理なのか?」
と聞かれたらそりゃこちらも喜んで説明しますよ

510:Socket774 (ワッチョイ f784-AoV0)
17/07/10 21:12:36.59 HVYV2gd80.net
別に仕事でやってるわけじゃなし
そんなもんだろ

511:Socket774 (ワンミングク MM7f-AnYK)
17/07/10 21:22:40.45 U+eH9RMWM.net
どういう部分が疑わしいからこういうコードで検証することによって再現しないだろうかって説明するだけだと思うが
それすら難しいというのはそもそも自分だけが正しいという前提に立っちゃってる
端から見てると突っ込みに対して自分が正しいという立場を絶対に崩したくないようにしか見えない
だからコードを修正するというアプローチは取らない
客観的な妥当性よりもプライドを優先しているんだよね

512:Socket774 (スップ Sd3f-6cEx)
17/07/10 21:24:53.28 /3T//w/Vd.net
お勉強しましょうねーなんて言われて1から説明とかありえないだろ
特に相手の勘違いが初っ端からアホなレベルなら尚更
CとC++の勘違いだそ?拡張子すら見てない
プログラミング分かった気でいるだけの知ったか野郎に懇切丁寧に教える必要は皆無

513:Socket774 (スップ Sd3f-6cEx)
17/07/10 21:25:30.16 /3T//w/Vd.net
あ、これ触っちゃいけない類だw

514:Socket774 (ワッチョイ bf53-1B52)
17/07/10 21:31:12.20 ANxjsTok0.net
もう良いから結論だけ言ってくれw

515:Socket774 (ワッチョイ ff63-pw7F)
17/07/10 21:31:16.45 zPTrTH910.net
>>511
間違ってることを間違ってるというだけでなぜここまで言われなければいけないのか
しかも下手すりゃこちら以上に相手がケンカ腰な場面なのに

516:Socket774 (ワントンキン MM7f-AnYK)
17/07/10 21:31:28.86 /ONVIAvWM.net
あークリティカルヒットしちゃったか

517:Socket774 (ブーイモ MMcf-3Bfy)
17/07/10 21:34:15.07 cNZJCUwZM.net
プログラム公表した段階で説明書きちゃんとしてればこんなややこしいことにはならなかったような
趣味の領域の検証だからしょうがないけど

518:Socket774 (ワッチョイ 97c6-KuRC)
17/07/10 22:13:29.28 6itlFmR40.net
そもそもIntelでもAMDでもSEGVやらmismatch起こしてるのに
ぼくは間違ってない、CPUが全部バグってるんだというのは通らないと思う
AMDもIntelも間違ってる俺が正しいって言ってごらん

519:Socket774 (ワッチョイ 1764-u6mz)
17/07/10 22:25:53.32 vPCPTIwQ0.net
>>515
あんた2ちゃんねるには向いてないからtwitterに帰った方がいい
ここは都合の悪い者をブロックすることもできない
今の段階でまだまだマシな方だ
それで耐性がない位だから長居すればもっとひどいことになるだろう
自信作のプログラムも2ちゃんねるでの一切の取り扱いを禁止します、とかにしておけばここで語られることもなくなるだろう

520:Socket774 (オイコラミネオ MM4f-BuHV)
17/07/10 22:26:27.71 sm+QqFHZM.net
>>518
嘘つきは死んでくれや

521:Socket774 (ワッチョイ d7ec-TkOv)
17/07/10 23:00:39.28 vUhtUjpU0.net
あのさ、で、結局ぼくの考えた最強のmutexを再実装しなきゃいけない理由。とは?
flgも条件変数で構わない。(最悪これならvolatile intでいいや)
あれだけ大騒ぎされたのでccNUMAとしてCCXのそれぞれのL3が振る舞っていないのか、
私も疑ったくらいだがxchg mem,regがLOCK Assertionなしでも動くのは知っている。
おめでとう。xchg m, rはmを指す範囲でCoherentでした(いや知ってた)。
で、何がしたかったの?CPUのキャッシュがおかしい水準の議論がしたいのに、何このコード…
ぼくの考えた前提(採用はIntel Core Micro-architectureで動くもの)、ぼくの考えた仮説、…
「ワタシチョットmfense()ツカエル」
わかった、わかった。
でも、あなたのせいでとんでもない時間と電力を消費したかもしれないユーザーのことも考えてほしい
あなたが検証ではない目的で作っただけのプログラムは誰かに貢献したか?
…していない。無駄に時間取られた。あほか。私はメモリの設定を見なおして使える水準になった。
で、あなたが奪ったものは?
1日回すと電気代っていくら?200W*24h = 4.8kWh -> 30JPY*4.8 =144円!
試した人が100人いたら、1万4千円だよ!発展途上国に食品を400人に分け与えられる額だよ!
ばっちゃが言っていた。人の命はお金に替えられないって。
でも、400人分の命は5000兆円くらいにはなると思う。あなたはそれを奪ったんだ!

522:Socket774 (ワッチョイ 7f91-v6iG)
17/07/10 23:02:11.63 u0lxVD+H0.net
ID:zPTrTH910が>>497でID:vUhtUjpU0に勉強しろとレスしたのは>>495のレスに対してなので、まぁ、売り言葉に買い言葉。
ID:zPTrTH910が直接コードを読んでくれとレスしたのは>>451のクソコテに対してなので、それはそれで至って正論。
なので、そのままID:zPTrTH910は続けたまえw

523:Socket774 (ワッチョイ ff63-pw7F)
17/07/10 23:04:46.21 zPTrTH910.net
2ch的にはここで俺はどう続ければいい?
5 0 0 0 兆 円 欲 し い
(あればIntelもAMDも買収できるなー)
てな感じすか?

524:Socket774 (ワッチョイ 9f6e-n4zL)
17/07/10 23:11:31.57 nWbQqh6I0.net
まあここでレスバトルしてもしゃーない
ID:vUhtUjpU0 はもうSEGV起こる気がしないと、そこの設定を教えてもらえれば
ID:zPTrTH910 にはSEGV TESTでi7でも失敗している理由についてはどう推測しているのかとか

525:Socket774 (ワッチョイ 9774-jTKI)
17/07/10 23:13:09.94 orokq4bl0.net
ここはもうダメだww

526:Socket774 (ササクッテロラ Spcb-L5XL)
17/07/10 23:18:31.14 4M//3aw4p.net
Twitterで好きなだけバトってくれよ

527:Socket774 (ワッチョイ ffa3-kNtm)
17/07/10 23:20:14.34 afYdRrtv0.net
ダメってこたないだろ

528:Socket774 (バッミングク MM9b-M+1A)
17/07/10 23:20:57.93 xXdT4h8CM.net
むしろここ以外でレスバトルする場所もないしいいぞもっとやれって感じだわw

529:Socket774 (ワッチョイ ff63-pw7F)
17/07/10 23:36:41.54 zPTrTH910.net
>>524
それは本当に分からん
なんせ自分のIntelマシンでは丸一日とかでも大丈夫なので詳しく調べられない
(特に昨日その話聞いてから改めて今まで丸一日以上回してみてる)
Intelマシン(1)
マザー:DH67HD
CPU:i7-2600(定格)
FAN:リテールファン
メモリ:適当な余りパーツ DDR3-1333 4GB*4
SATA: 適当な余りHDD 250GB
Video:iGPU
電源:適当な余りパーツ
ケース: 適当な余りパーツ(FDDスロットとかあるレベルの)
OS:ubuntu17.04 ja(x86_64) 標準kernel & aptで最新upgrade
GCC: gcc version 6.3.0 20170406 (Ubuntu 6.3.0-12ubuntu2)
UEFI(BIOS): AAG10206-205
適当な余りパーツが多いのは申し訳ないが、起こらないよって話なのでこのぐらいで勘弁を
オプション: 8 2500000
ログの末尾のほう:
52995: 2017年 7月 10日 月曜日 23:21:03 JST: OK
Intelマシン(2)
マザー:DB75EN
CPU:i3-3220T(定格)
FAN:リテールファン
メモリ:W3U1600HQ DDR3-1600 8GBx2+4GBx2 たぶんCL11(もしかするとCL9で動いてるかも)
SSD: INTEL SSDSA2M040G2GC(40GB)
SATA: その他HDD計14台(PCIe1xにSATA-IFと、PCIe16xにN8103-150)
Video:iGPU
電源:FPS AU-400
ケース: MasterCase 5
OS:Ubuntu16.04 ja(x86_64) 4.4.0-79-generic #100-Ubuntu
GCC: gcc version gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
UEFI(BIOS):AAG39650-400
オプション: 4 2500000
ログの末尾のほう:
39148: 2017年 7月 10日 月曜日 23:31:48 JST: OK
こちらのほうは3770K+Ubuntu16.04で起こったってのと条件は近めなので何か起こるかも?と思いましたが何も起こらず。
2コアなのと、そもそもサーバーとして実用してるやつなのでHDD無駄に多かったり、
同時に他にプロセスが動きまくってるので参考にはならないかもしれませんね。

530:Socket774 (ワッチョイ bfdd-BuHV)
17/07/10 23:53:48.58 AnrY96n20.net
一週間くらい回せ

531:Socket774 (ワッチョイ ff63-pw7F)
17/07/10 23:56:09.60 zPTrTH910.net
そうしようと思うが、その前にマシン(1)をUbuntu16.04にしてみるわ

532:Socket774 (ワッチョイ 9fc4-ZuCk)
17/07/11 00:08:41.89 Cik7mZOX0.net
そういやQVL合わせの検証結果あったっけ?
ぶっちゃけQVLしか信じてないけど

533:Socket774 (ワッチョイ 9703-/HDW)
17/07/11 00:14:42.68 AGam0RWs0.net
>>529
検証乙

534:Socket774 (ワッチョイ 9787-pw7F)
17/07/11 01:03:51.11 smjOApgg0.net
>>521
むちゃくちゃだわ。
そんな屁理屈がとおるなら、ゲームどころかPC使うなって話だわ。
他人に言う前に、キミの資産は全部ユニセフに寄付したのかね?って次元の話。

535:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 01:05:01.54 nnG1B4ZV0.net
これでJEDECプロファイルで問題出なかったらまじかーとなるので追試を走らせているのだが、
長時間ベンチマークを走らせる人達に対してはそれがどれだけ無意味になるか知ってもらいたい。
(BIOS落ちだったらまじかー)
Reliability (and Security) Issues of DRAM and NAND Flash Scaling
HPCA Memory Reliability Workshop March 13, 2016 CMU
URLリンク(people.inf.ethz.ch)
Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors
URLリンク(users.ece.cmu.edu)
英語嫌いな人向け超絶引用 (1個目の論文から)
> Most DRAM Modules Are Vulnerable
「ほとんどのメモリモジュールは脆弱である」…えっ…
code1a:
 move X <- %RegisterA
 move Y <- %RegisterB
 Flush Cache Line [X] (clflush X)
 Flush Cache Line [Y] (clflush Y)
 Memory Fence (さらに念の為)
 jump code1a
で、3社から合計129個のDDR3メモリを買いました。エラーが生じた率は…?
2GBの構成で100万回テストしました。
Haswell 22871回のビット反転
Ivy Bridge 20722回の…
Sandy Bridge 16117回の…
Piledriver 59回の…
Non-ECCの品質ってこんなもんです。短期的なベンチマーク重視ならもっとひどいかも?
(Piledriverの回路はコンサバで半分の速度だけれどもエラー少ないのね)
で、100万回?1GHzのCPU使っていたら何回かなんて、お前は何を言っているんだっていう…
1日の保証?(私は本当にひどいめにあったが)特にHaswellユーザーは問題なかったのかと。
そりゃLinux Kernel(.oの総量6GBの最小近くであっても)の持久走には耐えられないよね…
つまり、あれですよ、code1a:のコードですら間違えるって言われているのだから、ぼくの(略)の長時間とかないわーっていう

536:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 01:12:18.04 nnG1B4ZV0.net
>>534
問題の特定ができていないのに冗長かつ読みづらく何がしたいのかもよくわからなくて
しかも再現性のない(確率的)なコードをひけらかして何か楽しいの?自称作者さん。
なお、資本主義経済下においては絶対的貧困は引き上げられる(平準化する)という立場ではあるが、ふるさと納税ではなく寄付はしている。

537:Socket774 (ワッチョイ 9787-pw7F)
17/07/11 01:17:21.67 smjOApgg0.net
>>536
よくみろ、別人だ。
はたからみてて、煽ってるだけで技術的議論になってない。
感情論に走るなら、技術者づらして偉そうに語るな。
ましてや、作者は走らせてくれとも、ここで取り上げてくれとも言ってない。
見るに見かねて登場したら、待ってましたとばかりに吊し上げくらってるだけだ。
ぼくのなんちゃらは、現時点でみんながそう。
誰もAMDの代弁なんて頼んでないし、たどり着けやしない。

538:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 01:21:17.69 nnG1B4ZV0.net
Haswell/LGA2011v3+DDR4は本当にQVLの品買うべきだったと非常に後悔した。
何しろメインのパラメータ tCL,tRCD,tRP,tRAS,tRFC,TREFI,tWR,tWTR,tWTR_L,tRRD,tRRD_L,tRTP,tFAW,tWCL,tCKE,tCCD,tCCD_L,tCCD_WR,tCCD_WR_L,...あたり?
に、さらにチップごとのtIOL,tRTLを合わせろとかもう冗談だろーっていう、ね

539:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 01:26:04.73 nnG1B4ZV0.net
>>537
別人かどうかわからないのがややこしいのが2chに久々に来た感
私も最初はCCX間のCache Coherency疑ったりと散々悩んだけど、
まさかの古いBIOSがおかしい…となって、大騒ぎしている約一名と
分析能力あるのにBIOS更新しない約一名、便乗している自称なんとかさん数名のせいで話おかしくなってる?
って、がっくりきているっていう。もう、ね

540:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 01:29:22.15 nnG1B4ZV0.net
あと、最近のCPUはDDRのDQ/DQSの遅延差を学習するので(FPGAでDDRやったことある人はわかるかと)、
試行を変える際には電源断(PSU)からはじめないとですよ…

541:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 07:25:08.32 nnG1B4ZV0.net
やはり古いBIOSだと出るな…
...
48 2017/07/11-05:12:33
<built-in>: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
make[2]: *** [drivers/acpi/numa.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [drivers/acpi] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs....
mv: cannot stat 'core': No such file or directory

542:Socket774 (ササクッテロリ Spcb-9DAm)
17/07/11 07:36:30.83 f70+ICl1p.net
所詮はおま環か、、、、

543:Socket774 (ブーイモ MMcf-3Bfy)
17/07/11 07:40:28.33 oB+VTaucM.net
DDR4自体が糞ってのもあるわな
いろいろとシビア過ぎるわ

544:Socket774 (ワッチョイ 9787-k5yk)
17/07/11 07:51:42.17 hE77DJ/D0.net
>>736
leapmotionはカスメ以外使い道無いかも
ソフトやドライバの更新も止まっている感じ
持ってるけど、微妙な性能だし、誤検出も多い
買うなら中古で十分かもね

545:Socket774 (ブーイモ MMdb-/9RP)
17/07/11 07:57:10.03 fO4Qx2lSM.net
大山鳴動して猫一匹ってやつか

546:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 08:05:50.45 nnG1B4ZV0.net
発生確率を上げるためにわざわざUbuntu16.04のデフォルトインストール、アップデートなしを選択しなきゃならないのはどうかと
このバージョンのLinuxが認識しているトポロジー
URLリンク(www.gazo.cc)

547:Socket774 (ササクッテロレ Spcb-9DAm)
17/07/11 08:09:37.61 xxd3he5Zp.net
>>545
それ言うなら、鼠一匹だろ?www.

548:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 08:14:01.45 nnG1B4ZV0.net
URLリンク(github.com)

549:Socket774 (スプッッ Sd3f-/2Bv)
17/07/11 08:49:03.38 nkTSbBIDd.net
>>177
Pentium と Excel

550:Socket774 (ワッチョイ ffe6-RQru)
17/07/11 08:58:52.28 z2mlHI6T0.net
>>546
>>375
もしそうなら参考にしたいので >>480のテンプレでHW構成と
デフォルトから変更したBIOS設定を教えていただけませんか

551:Socket774 (ワッチョイ ff74-x/VO)
17/07/11 10:07:52.39 FKhMoH350.net
>>535
Non-ECCならエラー率はそんなものだし、サーバーでECC使うのもそれが理由だからな。
エラー出るって言ってるやつがHynixとMicronばかりなのが気になる。
古いBIOSでSEGV出るのもメモリ互換性修正前のBIOSなら珍しくも何とも無い、Samsungはそんなでも無いみたいだけど。
現状ではBIOS Ver違うだけでtREFが560だったり600だったりサブタイミングが色々違って来るからな
一番の問題なのはメーカーによってAGESA1006のBIOSがまだ出てないという点だろうけど(サブタイミングがAUTOのみ)

552:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 10:50:37.95 nnG1B4ZV0.net
>>550
トレーニングの結果を反映してさらにコンサバティブな設定に変えたので昨日の試験とは設定違うが、参考になれば
M/B : ASRock A320M (BIOS 2.60)
CPU : AMD Ryzen 5 1600 Six-Core Processor 3200.000MHz, Microcode 0x8001126 (AGESA 1.0.0.6)
FAN : Wraith SPIRE
RAM : Crucial Technology Ballistix Sport 8GB DDR4-2400 UDIMM x2 (16-16-16-39)
古いBIOSだとこれしかいじれないから終わってる
tCL 16
tRCDRD 16
tRCDWR 16
tRP 16
tRAS 39
tRRD_S 5
tRRD_L 7
tFAW 28
tWTR_S 4
tWTR_L 10
tWR 19
Trcpage 340
TrdrdScL 5
TwrwrScL 5
tRFC 313
tRFC2 193
tRFC4 133
tCWL 14
tRTP 10
Trdwr 9
Twrrd 3
TwrwrSc 1
TwrwrSd 7
TwrwrDd 7
TrdrdSc 1
TrdrdSd 5
TrdrdDd 5
tCKE 6
CR 2T
とんでもなくコンサバティブな設定だが、0.2%の性能差求めてないのと、
このメモリ、Haswellで苦労しただめな子なので1日問題がなければいいやっていう

553:Socket774 (ワッチョイ 57b4-tYQy)
17/07/11 10:57:36.27 eOXhTDCw0.net
>>546
トチ狂ってるようにみえる

554:Socket774 (ワッチョイ ffe6-RQru)
17/07/11 11:04:17.07 z2mlHI6T0.net
>>552
おお詳しくありがとうございます
メモリのサブタイミングだけでコア部分の設定とか電圧とかは変更してない感じですかね?

555:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 11:07:13.88 nnG1B4ZV0.net
>>551
1時間で発生させられないものは、メモリ問題の発生率を超えられていないので相手にしたくないのだけれども、
なぜに実行者の忍耐力試験としか思えない実証コードが出まわるのかさっぱりわからない
16スレッドで1日となると1GHzのCPUでは10^15のオーダーでサイクル回せるわけですから、もう、あのー…
このようにNon-ECCでRowHammer問題が起きる確率は1e-3ですから、
こんな世界で1e15オーダーの試験で問題提起したつもりになれる人には大丈夫ですか?と言いたくもなる

556:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 11:12:02.36 nnG1B4ZV0.net
>>554
すべて定格です。一度もオーバークロックなどさせていません。
繰り返しになりますが、このタイミングはDDR4-2400においてはかなりコンサバティブなので、
これで動かないか、これ以下のXMP Profileを持っているメモリは捨てたほうがよいと思います。。
あと、L3に16MBもあると、瞬間的なベンチマーク目的外ではDDR4-2133より速くても2%影響あるかどうか。
これは、Intelであっても同じ話ですが。

557:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 11:24:26.23 nnG1B4ZV0.net
>>553
なぜこうなったかというと、
「Bulldozerのコアはモジュールに関係なく扱おう」
-> a33d331761bc5dd330499ca5ceceb67f0640a8e6
「お前のせいでゲームがかくかくするので、元の戦略に戻す(元のコードに戻すのではなく味付けした)」
-> 79a8b9aa388b0620cc1d525d7c0f0d9a8a85e08e
「おい、Zenの対応忘れてね?」←2017-02-05の出来事
-> 08b259631b5a1d912af4832847b5642f377d9101

558:Socket774 (ワッチョイ 57b4-tYQy)
17/07/11 11:38:51.10 eOXhTDCw0.net
>>557
ガバガバじゃないか

559:Socket774 (ワッチョイ 9f53-kNtm)
17/07/11 11:40:00.44 UQzj+lrS0.net
自称作者はどこ行ったの

560:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 11:48:32.41 nnG1B4ZV0.net
>>558
AMDのCPUが使われなくなって何年も経っているから「おれが正しい!」コードが普通にコミットされていたっていう。
安定的に動くカーネルが提供されるまでにあと半年はかかるんじゃないかな。なのに大騒ぎに合わせてLinux 4.8.0をを使わざるを得ないつらさ
BKDG出てないから中の人かNDA結んでいる会社以外の個人レベルで勝手な議論をしても仕様でした落ちになりかねないわけで…何がしたいんだろうね?

561:Socket774 (ラクッペ MM8b-ay8l)
17/07/11 11:58:30.52 6+W8d/FKM.net
団子みたいな奴だな

562:Socket774 (ワッチョイ 9f5f-m5Ug)
17/07/11 12:02:47.88 nAHhye7I0.net
>>552
tRCはいくつ?

563:Socket774 (ワッチョイ 17ea-u6mz)
17/07/11 12:09:26.06 O/1RDMq30.net
メモリの信頼性云々はこれの事を言ってる模様
Row Hammer問題
プロセス微細化に伴い無視できなくなってきたデータ化け問題
(後藤の記事)
URLリンク(pc.watch.impress.co.jp)
Rowhammer問題私的まとめ
Google作成のRow Hammerテストツールの事が書いてある
URLリンク(blog.daionet.gr.jp)
テストツールは後でやってみよう
丁度この頃はPCパーツ殆ど買ってないから知らんかったわ

564:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 12:09:29.14 nnG1B4ZV0.net
>>562
tRC 55
抜けてた… orz

565:Socket774 (ワッチョイ 9f5f-m5Ug)
17/07/11 12:33:54.16 nAHhye7I0.net
>>564
ググったらSPDと値は同じようだけどどこか手動で変更した箇所あるのかな

566:Socket774 (ワッチョイ d73e-p/Om)
17/07/11 12:36:10.51 3PQOIgv80.net
サムスンBダイ搭載の72bit幅モジュール、M391A1K43BB1が欲しいけど入手性が……

567:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 12:41:15.14 nnG1B4ZV0.net
>>565
はい、古いBIOSでもいじれるものはSPDのものをそのまま採用しています。
>>552 に書いたように、DDR4-2400 (16-16-16-39)の例でサブパラメータの網羅を提供するのが目的でした
tRC>=tRAS+tRPの関係からtRPは55以上になります。一般的には足し算だけで十分なはずです。
もちろん、これは一例なので16-16-16-39でなければtCL,tRCD,tRP,tRASの値は変わってきます。
コンサバティブな設定と言いながらTwrwrScL 7としなかったのは失敗…

568:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 12:43:52.73 nnG1B4ZV0.net
>>567 >>565
また間違った…技術云々の前に自分の頭のネジが抜けとる orz
誤) tRC>=tRAS+tRPの関係からtRPは55以上になります。
正) tRC>=tRAS+tRPの関係からtRCは55以上になります。

569:Socket774 (ワッチョイ ff63-pw7F)
17/07/11 12:49:14.74 bfq4vYgh0.net
>>559
いやまあメモリが悪いんだっていう話もそれはそれであると思うんで
その探究に文句をつけたり特に何か異論を挟むつもりは無いですね
ただ、メモリの信頼性のオーダーから考えて長時間のテストは無意味みたいな点については反論を。
まず参考に挙げてるメモリの信頼性に関する話は
再現のためメモリに対して作為的なアクセスパターンで行うとこんなにビットエラーが出ますっていう話で
あらゆるメモリアクセスが10^-3オーダーの確率でおかしくなるわけではないということ。
だったら非ECC環境ではとっくにあらゆるアプリが誤作動しまくりだし、
memtestなんてコンマ何秒で失敗するのが当たり前な世界になってないとおかしい。
それに加えて、キャッシュでメモリアクセスが隠蔽される効果も全く考えていない点。
ryzen_segv_testなんて高々KiBオーダーの領域しか使わないテストなんで、
それが秒数回程度プロセスが立ち上がろうがそんなものはほぼキャッシュの上の話。
なのでCPUのサイクル数のオーダーとメモリアクセス回数のオーダーを比較することは全く無意味な比較と思いますがどうでしょう?
もしそうじゃないなら何のためにキャッシュが存在しているんだっていう。
ちなみに僕のRYZEN環境ではryzen_segv_testをgccでコンパイルすれば分に何回レベルでsegfaultしますよ。
仮にそれがメモリの問題だとして、メモリの設定変えたらこの頻度がどれだけ変わるかは試してみたいですね。
(出先なので今は書いてないですが、必要があれば環境は後でまとめます)

570:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 12:55:04.66 nnG1B4ZV0.net
>>569
で、あなたは何を実証したの?

571:Socket774 (オイコラミネオ MM4f-BuHV)
17/07/11 12:58:21.40 6gtQbqP6M.net
>>569
あくしろよ

572:Socket774 (オイコラミネオ MM4f-mx7j)
17/07/11 12:58:53.89 vc5Bt3bAM.net
横レスだがメモリクロック緩めるだけでエラー頻度は減るというのがここでの結果

573:Socket774 (ワッチョイ ff63-pw7F)
17/07/11 13:00:59.58 bfq4vYgh0.net
>>570
RYZENとそれ以外のプロセッサで顕著にsegfaultする確率が異なる自己書き換えパターンがあるっぽいということですね

574:Socket774 (スップ Sd3f-0UkT)
17/07/11 13:04:03.07 qXQ+fGYDd.net
まだメモリが原因とか言ってるアホがいるのか
さすがに電源はいなくなったか

575:Socket774 (ササクッテロラ Spcb-L5XL)
17/07/11 13:05:08.15 /XFGRwkJp.net
gccが稀に触ってしまう微妙なレースコンディションが有るよということではないの?
x86の仕様としてあるものをRyzenが正しく実装してないか、
gccのコード側でプロセッサにドキュメント外の動作を想定してるせいかは知らないが

576:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 13:06:31.47 nnG1B4ZV0.net
$ git clone URLリンク(github.com)
$ cd ryzen_segv_test/
$ make
cc -O2 -Wall -c ryzen_segv_test.c -o ryzen_segv_test.o
cc -pthread -o ryzen_segv_test ryzen_segv_test.o
$ ./run.sh 8 2500000
...10分待った。まだ止めてないけど、segfault まだかなあ。
$ tail -f log.txt
...
483: 2017年 7月 11日 火曜日 13:02:44 JST: OK
PID:8269 CPU:6
478: 2017年 7月 11日 火曜日 13:02:44 JST: OK
PID:8274 CPU:1
476: 2017年 7月 11日 火曜日 13:02:44 JST: OK
PID:8279 CPU:5
478: 2017年 7月 11日 火曜日 13:02:44 JST: OK
PID:8284 CPU:4
> ちなみに僕のRYZEN環境ではryzen_segv_testをgccでコンパイルすれば分に何回レベルでsegfaultしますよ。
ほほう。大騒ぎ界隈で言われている所謂当たり石をお持ちなのですか!羨ましい
20分待ったけれども何も起きないや。忍耐なくてごめんね

577:Socket774 (スップ Sd3f-0UkT)
17/07/11 13:07:58.01 qXQ+fGYDd.net
簡単にメモリエラーが出るPCなら使い物にならんから捨ててしまえ
>>569ではないが、>>569は正論

578:Socket774 (ワッチョイ ff63-pw7F)
17/07/11 13:09:36.61 bfq4vYgh0.net
>>575
gcc自体がビルド中にSEGVするよって話とはまた別に、
gccでビルドした結果のバイナリの動作時の話なのでそれは関係ないかと
しかもそのバイナリ自体もとても小さいくて全部アセンブリを見たって把握できる程度のものですし

579:Socket774 (ワッチョイ ff63-pw7F)
17/07/11 13:12:16.37 bfq4vYgh0.net
>>576
いやいやそれほどでもー
単に僕のマザボ(AB350M Pro4)のデフォルトのメモリ設定がクソなだけとか、
メモリが腐ってるだけかもしれないじゃないですかー
あなたの理論によれば

580:Socket774 (スップ Sd3f-0UkT)
17/07/11 13:12:40.44 qXQ+fGYDd.net
>>572
それでメモリが原因と決めつけちゃうのが素人
このスレに非常に多い

581:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 13:14:53.67 nnG1B4ZV0.net
>>579
反例を挙げるのに10倍の時間では足りないのですか?当たり石をお持ちなんて本当に羨ましい笑

582:Socket774 (ワッチョイ ff63-pw7F)
17/07/11 13:19:26.15 bfq4vYgh0.net
>>581
いや、どうでしょう。
僕も何十台もRYZEN機を触ったわけではないので個体によって幅がどのぐらいあるのか知らないので。
あなたのはカーネルビルドでもわりと出にくい個体のように見受けられるので。
ほぼ影響がないレベルの当たり(外れ?)が存在する可能性も否定できないです。
ただ、一つ言えるなら6コアなら6 2500000のほうがいいかもなーってのと、
一応僕が起こることを確認してるのはUbuntu17.04とその付属gccです。

583:Socket774 (スップ Sd3f-0UkT)
17/07/11 13:21:29.36 qXQ+fGYDd.net
これだけ時間と人をかけて、何の切り分けも出来てないっていう
素人は何人集まっても素人

584:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 13:26:33.95 nnG1B4ZV0.net
>>582
>>569 の自己矛盾っぷりはどうしたらよいものか。しばらく眺めていようっと笑
> あなたのはカーネルビルドでもわりと出にくい個体のように見受けられるので。
> ほぼ影響がないレベルの当たり(外れ?)が存在する可能性も否定できないです。
いやだから、昨晩わざと古いBIOSにして引っかかってるしな… >>541
で、メモリの設定を見なおしたら落ちないんだけれど、どうしたらいいのかなー
購入前の古いBIOSにすると私のRyzenも当たり石に進化して詫び石もらえるの?笑
それを世間では当たり屋って呼ぶんだよ

585:Socket774 (ワッチョイ ff63-pw7F)
17/07/11 13:31:31.52 bfq4vYgh0.net
>>584
こちらは詫び石だとか一言も言ってもいないし交換にも出していないし、
そもそも交換しましょうか?って言ってるのはAMDなのでそれをこちらに言われても全くお門違いもいいところ
詫び石欲しいなら古いBIOSで報告して勝手にやれば?としか言いようがない

586:Socket774 (アウアウカー Sa2b-SB+D)
17/07/11 13:34:17.61 6qhIHX6Wa.net
眺めてるとたまたま不良品を&#25681;まされた人が
初期不良で交換せずに騒いでる様に見える

587:Socket774 (スップ Sd3f-Mv6b)
17/07/11 13:38:21.17 IPeYaAe7d.net
切り分けできるわけ無いでしょう。
ずれることは確定と言いながら、ソースをお願いしたら無視する人とか、自分の中だけで確定していることを、事実だと思っている人ばかりですから。

588:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 13:40:18.63 nnG1B4ZV0.net
じゃあ交換してもらえばいいじゃん…他人に迷惑かけるなよ

589:Socket774 (スップ Sd3f-6cEx)
17/07/11 13:42:26.91 6ftCfTNBd.net
公開されてるってだけのコードを勝手に実行しといて迷惑かけられたと主張するのか……

590:Socket774 (ワッチョイ ff63-pw7F)
17/07/11 13:47:32.61 bfq4vYgh0.net
個人的にはよく確認もしないで誤解に基づき
>何が起きたかって「私は並列プログラミングできません」と書かれたコードを世界中に晒したっていう
とかいきなり言われちゃうことが迷惑だったんですけど
それに関してのフォローは特には無かったですよね
まあそれは別にもういいんですが、
技術的な話じゃなくて迷惑がどうこうという話を持ち出されると……

591:Socket774 (ワッチョイ d7ec-TkOv)
17/07/11 14:01:24.27 nnG1B4ZV0.net
だって私はあなたの指導教員ではないので。細かいフォローをする必要などありませんし
まあ、がんばってください。携帯電話も併用して、ね。

592:Socket774 (ワッチョイ ff63-pw7F)
17/07/11 14:06:16.68 bfq4vYgh0.net
人に対して謂れのない理由で非礼を働いておいて、
そのフォローはないのかと問われて
>あなたの指導教員ではないので。細かいフォローをする必要などありません
だって
大爆笑だね

593:Socket774 (バッミングク MM9b-M+1A)
17/07/11 14:07:38.22 n7FYcdyiM.net
指導教員って学生かよww


最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch