【エラッタ】Ryzen SEGV問題 情報交換【フリーズ】

1 ：Socket774：2017/06/21(水) 11:31:47.10 ID:X64ca18/.net

Ryzen SEGV問題についての情報交換スレです

B2ステッピング登場？
https://twitter.com/CPCHardware/status/876193860946468865

2 ：Socket774：2017/06/21(水) 11:43:50.40 ID:0CWlMU1S.net

これってWindows上でgccでsegv出る条件でコンパイルしても出るの？

3 ：Socket774：2017/06/21(水) 12:47:59.94 ID:9XaKsthO.net

出る

4 ：Socket774：2017/06/21(水) 14:33:42.83 ID:0CWlMU1S.net

それは初耳
スクショとかある？
自分でやってないなら出た人のtwitterのツイートとかでもいいけど

5 ：Socket774：2017/06/21(水) 17:11:47.35 ID:o24PzCa3.net

くこか
ペンギン村にもカキコしたけどここでも
http://hayabusa6.2ch.net/test/read.cgi/linux/1316419256/210

https://twitter.com/satoru_takeuchi/status/877324605706313728
交換品はB2かな？wktk

6 ：Socket774：2017/06/21(水) 17:19:44.44 ID:FEthGAzE.net

AMDから直接送られて来るのかこのツイートでは分からんから現状なんとも言えんな
続報を待つとしよう

7 ：Socket774：2017/06/21(水) 17:33:26.32 ID:o24PzCa3.net

ここでメモ
https://twitter.com/hashtag/Ryzen_SEGV_Battle?src=hash
https://search.yahoo.co.jp/realtime/search/Ryzen_SEGV_Battle/

>>6
https://twitter.com/satoru_takeuchi/status/876914187573710848
AMDサポートが個別対応とのことだけど、やっぱりどーなるんだろ？
ｗｋｔｋのAA省略

8 ：Socket774：2017/06/21(水) 17:35:27.30 ID:OPsh8Z6s.net

Ryzen General Protection Exception
http://www.e-hdk.com/diary/d201706c.html#20-2

9 ：Socket774：2017/06/21(水) 17:44:04.34 ID:FEthGAzE.net

>>7
AMDから個別対応扱いになってたのか
ならその前提で続報待ちだな

10 ：Socket774：2017/06/21(水) 17:46:56.40 ID:FEthGAzE.net

>>8
これはビルドしたカーネルが仮想マシン上で動かない件の詳細な調査事例
残念ながらエラッタがある模様
マイクロコードで直せるレベルなのか？

11 ：Socket774：2017/06/21(水) 17:54:38.63 ID:o24PzCa3.net

>>10
仮想鯖もするとこあるはず
んで、発表会のデモ↓
https://twitter.com/Hyper_beta/status/877408252937424896
> EPYCのデモでAMDがLinuxをビルドして見せたのは、メッセージなのかもしれない？
> #Ryzen_SEGV_Battle

直ったのかな？

12 ：Socket774：2017/06/21(水) 17:58:20.26 ID:o24PzCa3.net

スラドでトピが立った>>8
<title>Ryzen SEGV Battle、原因の一端が解明される | スラド Submission</title>
https://srad.jp/submission/71785/

13 ：Socket774：2017/06/21(水) 17:59:01.60 ID:FEthGAzE.net

EPYCはB2ステップなんでしょ
マイクロコードで直るのかはB1ステップを使ってる者として心配という意味

14 ：Socket774：2017/06/21(水) 18:03:01.17 ID:o24PzCa3.net

(｡･･｡)(｡. .｡)ｳﾝ

15 ：Socket774：2017/06/21(水) 18:24:41.89 ID:FEthGAzE.net

スラドのトピックの書き方だと>>8の現象が仮想マシンでのカーネル起動失敗とgcc segvの両方に関係するように読める
B2ステップでは直してるだろうけど、B1ステップをどうするかがまだ決まってなくてAMDとしては現時点では話を大きくしたくないのだろうなと感じる
続報待ちだな

16 ：Socket774：2017/06/21(水) 18:47:34.88 ID:IaXmZvmE.net

まあIntelもTSXとかマイクロコードで修正むりなのやらかしてるしな

17 ：Socket774：2017/06/21(水) 18:57:20.69 ID:FEthGAzE.net

最悪コーディングレベルの回避方法が出るだけでもいいとは思う
リコールは今のAMDとしては避けたいだろう
下手すりゃ倒産するか買収される
折角インテルのケツをけっとばせたのにまたサボりボッタクリに戻ってしまう

18 ：Socket774：2017/06/21(水) 19:20:18.30 ID:o24PzCa3.net

https://twitter.com/Star_Craft/status/875594079534325766
> #Ryzen_SEGV_Battleの動画

こりか
Ryzen SEGV Battle
https://youtu.be/n4n84W0XUvM
ライブ配信だったのでチャットはない
4時間……

19 ：Socket774：2017/06/21(水) 19:24:11.70 ID:o24PzCa3.net

ほぼ5時間だたー

20 ：Socket774：2017/06/21(水) 19:42:57.54 ID:o24PzCa3.net

あっちのスレでEPYCがB1だってホント？
マザボで合わせてるのかな？
RyzenもBIOSとかのうｐだてで対応できる？

21 ：Socket774：2017/06/21(水) 21:28:44.46 ID:H8KNizh3.net

>>15
むしろcall命令で呼び出し先が-64バイトずれたら、もっと多様な問題が起きると思うが
発現頻度がかなり低いか、特定の条件があるのか

AMDが問題をどれだけ早く認識していたかによってはB2 steppingでも直ってないかもしれない。

22 ：Socket774：2017/06/21(水) 21:44:48.27 ID:O3AdHp42.net

これLinuxだけの問題じゃないよね
Windowsでも起きうるよね？

23 ：Socket774：2017/06/21(水) 21:49:12.59 ID:PoBhi1hr.net

詫び石配布まだ？

24 ：Socket774：2017/06/21(水) 22:05:15.48 ID:qnN59nBM.net

スパッと例外で死んでくれたからまだマシだけど
64バイトずれたら何が起こってもおかしくないよね
データが漏洩するとか、間違った額を送金しちゃうとか、爆音がなるとか、データ消失とか、....

地雷を抱えたCPU

25 ：Socket774：2017/06/21(水) 22:20:38.36 ID:WYbxIJuK.net

後から出てくるバグほど影響のデカいのが多いからな

26 ：Socket774：2017/06/21(水) 23:59:35.67 ID:ZgJd4ynH.net

命令デコーダの異常か…
デコード後のμOPsがキャッシュからあふれた時の処理がおかしいんだろうな

27 ：Socket774：2017/06/22(木) 00:03:52.11 ID:M4vWvYHl.net

問題を修復した人発見

0384 Socket774 2017/06/21 21:53:06
>>375
Linuxで相性の悪いメモリ使っててカーネルコンパイルするとランダムで起きる
そしてコンパイル通った場合でも、そのカーネルに書き換えるとカーネルパニック起こして起動しなくなる
メモリを交換するとSEGVは起きなくなったんだよな
とにかくメモリ相性が厳しいからなあ

28 ：Socket774：2017/06/22(木) 00:07:19.05 ID:FIBEIjRR.net

B2ステッピングはメモコンバグ修正だから直るかもね
B1はおつでしたわ

29 ：Socket774：2017/06/22(木) 00:09:02.14 ID:M4vWvYHl.net

http://satoru-takeuchi.hatenablog.com/entry/2017/04/24/135914

何かしら負荷がかかるとマズイらしい

ちなみにSEGV起きない人は起きないらしいので

30 ：Socket774：2017/06/22(木) 00:16:09.57 ID:mqDKtpKE.net

VRMが貧弱・フェーズ数少ない安マザーでコアOCしている
メモリVRMが1フェーズで出来のよくない安マザーでメモリOCしている
とかいうオチだったら笑うわ

31 ：Socket774：2017/06/22(木) 00:59:28.12 ID:JsuK1VJz.net

＞0x40バイトずれた命令を実行
CPUとして販売できないレベルだろこれ

32 ：Socket774：2017/06/22(木) 01:17:57.86 ID:xJt0aGN3.net

>>31
元はともかく、そういうことをわかってないレベルのやつが今騒いでんだろ

33 ：Socket774：2017/06/22(木) 01:35:12.07 ID:JsuK1VJz.net

>>32
逆汗して解説してくれてる人いるから見てこいよ
騒ぐ騒がないというレベルの問題じゃないから

34 ：Socket774：2017/06/22(木) 01:41:45.60 ID:m/BlxFkL.net

これ何でWindowsだと報告が無いんだ？

35 ：Socket774：2017/06/22(木) 01:44:39.12 ID:d6WPfqXO.net

全然良くわかってないんだがこれ科学とか数学の厳密な計算とか大丈夫なのか？

36 ：Socket774：2017/06/22(木) 01:52:41.81 ID:8hvYDhQG.net

>>35
ただのビルドなんで
gccを並列ビルドしないだけでも大方問題は解決するんじゃないか

というより現象が人によって様々なんだろう
多分上の人が言ってるようにメモリーが不安定なのかもしれんな

37 ：Socket774：2017/06/22(木) 01:53:16.54 ID:AAuLBcJr.net

オワータ

38 ：Socket774：2017/06/22(木) 01:59:46.44 ID:8hvYDhQG.net

メモリー入れ替えてなおった人が居るんで
なおらないことはない

Linuxによくある相性の問題かと

39 ：Socket774：2017/06/22(木) 02:40:41.51 ID:uilJeQWm.net

この人ソフト屋さんだからソフト面で頑張って調査してるけど発生の有無とかランダム性を考えるとハード不良もしくは相性な気がする
上でメモリ交換で直ったって話もあるけどとりあえず
コア電圧とメモリ電圧盛ってみてほしいわ
場合によってはsoc電圧もか

あとlinuxにあるのか知らないけどモニタリングソフトでクロックとか電圧をモニタリングしながらコンパイルしてその変動がトリガーなのかどうか調べてみてほしいところ

40 ：Socket774：2017/06/22(木) 02:43:01.53 ID:dJdn60bH.net

こういうのがあるからAMDは仕事用に採用しにくいんだよなぁ
良い製品が出来たのにほんともったいない

41 ：Socket774：2017/06/22(木) 02:50:58.36 ID:u0oVCB5S.net

まーいいじゃん主張した人はCPU交換してもらえたみたいだし
7700Kの温度スパイク問題みたいに
ユーザー「ファンが唸ってるんですけど」
intel「そんな現象は発生しません。」
でフォロー無しで終わった
あっちの方が被害大きいだろ

42 ：Socket774：2017/06/22(木) 02:51:46.24 ID:CAw/d0dR.net

>>34
64バイト前方にずれるので同じ命令を二度実行しても、データや結果が不正に化けるだけでエラーにならない場合もある。
WindowsはLinuxみたいなシステムと違って、エラーメッセージが貧弱だから問題が起きてもブルースクリーンが出たで済まして
原因究明する利用者が少ない

>>40
本当にウキウキな気分だったのに泣きたい
I wanna cry.

43 ：Socket774：2017/06/22(木) 02:52:44.49 ID:0/xQ9Cor.net

これCPU原因なら近年まれに見るバグだな
いきなり新アーキだからしょうがないのかもしれんが

44 ：Socket774：2017/06/22(木) 02:57:57.46 ID:u0oVCB5S.net

どっちもどっちだって
Intelもここ10年内に登場したCPUに潜むリモート操作される脆弱性とかって修正だしとったでしょ
リモート管理機能のバグで
コンピューターを遠隔でフルコントロールされる危険性があることが判明し、
2017年5月1日にIntelは脆弱性を修復する緊急パッチをリリースとか

45 ：Socket774：2017/06/22(木) 03:09:04.19 ID:mqDKtpKE.net

あれってAMTだけと言ってるが、実はME搭載機全部(Core iシリーズほとんど)じゃないかと思ってる
また10年後に実は・・・とか言いそう

あとatom C2000の突然死問題の方がよっぽど致命的だな
あれは運用開始後に発覚してるから、ネットワーク機器の会社が頭抱える羽目になったとか

46 ：Socket774：2017/06/22(木) 03:12:27.02 ID:+p6sApUG.net

Intelの話はスレチ

47 ：Socket774：2017/06/22(木) 03:18:25.87 ID:mqDKtpKE.net

スレチだが、近年まれに見るという話だったから、他の近年まれに見る事例の話になったと思う
まあ止めとくわ

48 ：Socket774：2017/06/22(木) 03:40:12.51 ID:YeF0hlKQ.net

Pentium 66Mhz並のバグか？
全数リコールｗ

49 ：Socket774：2017/06/22(木) 06:16:44.81 ID:mxoD2KmK.net

メモリ交換で命令デコーダのバグが直るってどういう仕組みだよ

50 ：Socket774：2017/06/22(木) 06:52:47.37 ID:bQjMVwt5.net

>>39
ハード不良の原因をソフトで絞るのはよくあることだと思うけど

51 ：Socket774：2017/06/22(木) 06:54:25.81 ID:bQjMVwt5.net

>>49
たまたまタイミングがずれてその場所では発生しなくなるとか

52 ：Socket774：2017/06/22(木) 06:55:34.74 ID:bQjMVwt5.net

>>48
演算結果不定よりは動作不定の方が一般的には重い

53 ：Socket774：2017/06/22(木) 07:09:22.76 ID:FIBEIjRR.net

AMDにとっては幸いなことにgcc以外でバグが発生してないからな
リコールはない

54 ：Socket774：2017/06/22(木) 07:13:55.63 ID:bQjMVwt5.net

発生してないなんてわからんでしょ

55 ：Socket774：2017/06/22(木) 07:26:54.14 ID:FIBEIjRR.net

デコーダー異常なんて発生したらフリーズするから誰でもすぐわかるがな
誰しもバグが発生しPCの使用に支障が出てる訳ではない

56 ：Socket774：2017/06/22(木) 07:36:21.00 ID:GqAhxk8U.net

出ない人もいる
メモリ相性電圧冷却クロックで出方が変わる
Ｂ２でアンコアに修正入る

相性厳しかったんだなという印象

57 ：Socket774：2017/06/22(木) 07:48:44.07 ID:VJO9OE+8.net

ECCメモリも使えないような環境でデータ化けの心配をするとか、一体どういう神経してるんだろう
EPYCなら致命的だがRyzenはホビーユースで出してる製品だろうに…

58 ：Socket774：2017/06/22(木) 08:05:36.93 ID:GLGMajwN.net

ホビーじゃないだろ
ビジネスにも使われるぜ
正直今回のエラッタは深刻だと思うけどな
とっとと糞石処分してB2買いたいわ

59 ：Socket774：2017/06/22(木) 08:11:01.40 ID:AhK4zRCq.net

ECCは宇宙線なんんかの特殊なエラーから守るためのものであって、
普段からエラーでっぱなしとかたとえデスクトップ用でも欠陥品だろ

60 ：Socket774：2017/06/22(木) 08:12:04.08 ID:cBELvyWC.net

何が深刻かって現象の程度ではなくAMDが対応策発表しない点だな
100%発生するパターンがないから発表のしようがないのかもしれんが
解決策発表しないとソフト側も対応出来ないから放置のままだし

61 ：Socket774：2017/06/22(木) 08:16:21.70 ID:bQjMVwt5.net

>>55
発生してないなんてわからん

62 ：Socket774：2017/06/22(木) 08:18:31.56 ID:bQjMVwt5.net

今のところ表だって騒いでる人がいない
というだけ

63 ：Socket774：2017/06/22(木) 08:28:34.06 ID:rpPjaOns.net

AMDも理由があって現時点で何も言わないor言えないんだろ
公式発表を待つしかあるまい
幸い発生条件が限定されてるようだし
メモリ交換で直った事例があるならCPUエラッタなのかマザーの設計が悪いのか個体差なのか単なる故障なのかも判断できない

ここで騒いだところで何も解決はしない
文句あるやつはAMDに直接問い合わせた方がいい
問い合わせ件数が多くなれば早々に何らかのアクションを起こすだろ

64 ：Socket774：2017/06/22(木) 08:34:59.70 ID:cBELvyWC.net

PhenomやSkylakeはエラッタ解決のために性能落とされたからな
どうなることやら

65 ：Socket774：2017/06/22(木) 09:00:28.60 ID:/EJsO549.net

OCやらメモリの相性やらBIOSだとかLinuxメンテナフォーラムでさんざん議論われて今更感
あまり関係ない雰囲気がボランティアの対策チームの認識になりつつある

幸いなことに対応している人たちはAMDのフロント対応が杜撰な事に不平はいっているが
FUD/プロパガンダ等の押し並べて煽って騒ぎたててる訳ではないし

エラッタの振る舞いが判った今、あとは発生条件を調べて
あとはAMDにハードウェア的に対策してもらうだけだろ
PhenomのTLBみたいな事にならなきゃいいが

66 ：Socket774：2017/06/22(木) 09:06:43.70 ID:FZacNf/c.net

http://twitter.com/satoru_takeuchi/status/877346684853866496
この理論が正しければWindowsでも
RAMディスク使ってスワップ起こるまで使えばエラーになるんじゃね

67 ：Socket774：2017/06/22(木) 09:17:30.50 ID:jh4b+C0+.net

Phenomみたいに性能落とされなければ
PhenomのTLBみたいに

これ自体がFUDにしか見えない

68 ：Socket774：2017/06/22(木) 09:43:46.94 ID:g2y5mabY.net

対策が入っても性能が維持できるかどうか、というのは皆が気になる所

69 ：Socket774：2017/06/22(木) 09:54:23.74 ID:jh4b+C0+.net

そんなの対策されるまで分からんだろう
初物買ったんだから最悪の事態は覚悟の上だろ
待てないならAMDに問い合わせろ

70 ：32：2017/06/22(木) 12:01:22.32 ID:VF+YIWhe.net

>>42
64ずれるってのがわからない

プログラムカウンタズレてそれだけってことあるのかな
それともスタックフレームを意味してる？

71 ：Socket774：2017/06/22(木) 12:06:59.91 ID:5V34xtZ3.net

Linuxだと出やすい条件の命令なのかもしれない
カーネルパニックしろブルースクリーンにしろ、何かしらシスログなりイベントログは残る

72 ：Socket774：2017/06/22(木) 12:40:38.25 ID:VJO9OE+8.net

>>58
X.M.Pプロファイルでメモリ設定しているビジネスユースなんて一体何処の世界に存在してるんだよ
そんなのAMDの責任範疇の外だろう全く呆れるわ
メモリがSPD設定しか読まないガッチガチのビジネスモデルで検証したのなら理解出来るが…

73 ：Socket774：2017/06/22(木) 13:23:02.39 ID:ByYNIDAF.net

>>70
プログラムカウンタがずれたんじゃなくて、データがずれたんでしょ

74 ：Socket774：2017/06/22(木) 13:24:32.70 ID:+1FDFXpu.net

コピペ　

ただし、一点希望が持てることが明らかになりました。
CPUコアを1つにして、かつマルチスレッド無効化しても問題は発生することがわかりました。
これによって、別コア(スレッド)との相互作用が無くても単一CPUだけでも問題は
発生しうると言えます。これまでは、あるCPUにおいてSEGVが発生した際に、それ以外の
CPUの挙動が謎だったために、再現プログラムの作成難易度が相当高いと思っていました。
ただ、SEGV発生時のCPUの挙動だけを真似れば理屈上再現プログラムが作れることがわかったので、作成の敷居は下がりました。

75 ：Socket774：2017/06/22(木) 13:31:07.29 ID:ByYNIDAF.net

希望か

76 ：Socket774：2017/06/22(木) 13:54:55.42 ID:+1FDFXpu.net

コピペ２

起きるパターンは負荷テストを止めてほんの 2, 3 分程度の頃が多い。
何時間も負荷テストをする必要もない。
電源管理まわりの設定を変えると改善するとの噂があるが、設定の仕方がまだわかってない。

rcu_sched detected stalls on CPUs/tasks はたぶんスケジューラー的にコイツ動いてないよ
というたぐいのメッセージ。 これを放置して触っていると、TLB shootdown か何かの処理が
終わらなくなるようで (CPU0 が応答しないのだとすれば当然)、他の CPU も巻き添えを
食って止まり始めるが、他の CPU では NMI watchdog が出る。CPU0 も /proc/interrupts
を見る限りは NMI が出続けているのだが、なぜか watchdog は出てこないんだよな。

さて、idle が怪しいと見ていろいろ試したが、idle=poll も効果無し。（SEGV出ず）

Linux を BitVisor 上で動かし続けて 24 時間超えた。 マジで
rcu_sched detected stalls on CPUs/tasks のほうは ”BitVisor ”上では再現しないたぐいの問題なのか?
Ubuntu 16.04 でやって報告しまくっている第一人者の話があるので、
試しに debootstrap で chroot の” Ubuntu 16.04 ”環境をこしらえた。
schroot というのが便利だというので使ってみている。 それでいざカーネルビルドさせてみたらほんの 5 回ほどで segfault 出てしまったよ!

77 ：Socket774：2017/06/22(木) 13:57:27.46 ID:+1FDFXpu.net

コピペ３

BitVisor から覗いて見てわかったのは、ミスって #VMEXIT の状況を
うまく確認できるようにしていなかったことだw Local APIC の書き込みアクセスで
#VMEXIT したところだけ見えていて、果たして NMI が出ているのかはっきりしなかった。 （ω）しょぼーん。

これはさすがにやっぱり CPU 内部関係かなという感じがとてもする。
キャッシュがどうのこうのという感じではない。
レジスターの内容はこうして追ってみると一理ある感じなので、命令の実行が何かおかしいの？である。

（↓おそらく64bit先のに飛ぶことのかと）
LastExceptionToIP がなぜかユーザー空間のアドレスになっていることが多々ある。
例外の遷移先だから、カーネル空間でないとおかしい。VMM が絡んで変なことになるにしても、
それなら VMM の使っているアドレス空間でなければおかしいだろう。LastExceptionFromIP も
ユーザー空間にあるのは別にそれでもいいとも言えるのだが、そこに明らかに LastExceptionToIP にジャンプする命令が入っているというのはこれまたおかしな話である。

内容に矛盾はなく、本当に、ページフォールトだけがおかしいのである。
まるで 0x40 ズレた、手前の位置の命令を実行しようとしていたかのように。ハードだとしてもそうなる原因わかんね。。

78 ：Socket774：2017/06/22(木) 14:01:07.50 ID:u0oVCB5S.net

この問題は放置だな

Ubuntu 16.04で問題出たと言っても
ryzen対応のUbuntu 17.04が出てる訳で
問題があるならそこで問題になっている

79 ：Socket774：2017/06/22(木) 14:15:21.65 ID:DDbmQj7H.net

intel使えば問題ない

80 ：Socket774：2017/06/22(木) 14:33:36.34 ID:aV35CHfS.net

起こってるやつはメモリと各電圧の値含めて全環境を提示してみてくれ
そういう情報が一切無いからどうにもだ

ちなみに、定格とかじゃ無くて具体的な数字を上げてくれ

81 ：Socket774：2017/06/22(木) 14:47:37.81 ID:Sa/AvY1y.net

この話、4月から言ってるのにいまだに反応には似たようなもんだな

82 ：Socket774：2017/06/22(木) 14:56:54.53 ID:n6gc1f5S.net

重大な問題ならば、各MB、PCメーカーが黙っているはずもなく、販売中止もしくは延期を発表するはず。
だから重大ではないとは言えないが、そんな動きがまったく無いのが不思議だよ。

EPYCもmicronあたりが盛大にラインナップ発表したらしいし？
EPYCで解決してるなら、その故と販売済みRyzenへの対策が発表されるだろし。

誰か、この問題がユーザーサイドではなくメーカーサイドで取り扱われたソース知ってる？
予定していた購入は、そこらへんの情報が揃うまで待つよ。

83 ：Socket774：2017/06/22(木) 15:30:20.65 ID:GLGMajwN.net

>>72
SEGVエラーはメモリ関係ないCPUのエラッタなんだが

84 ：Socket774：2017/06/22(木) 15:50:18.65 ID:cBELvyWC.net

>>83
断定されてないんだが
あくまでだろう止まりなんだが

それにメモリーというよりメモコンの話でしょ

85 ：Socket774：2017/06/22(木) 16:06:33.00 ID:WpCOFs3O.net

必ず発症する状況、環境というのが存在しないのと
発症した人が大半「どういうハードウェア的な検証したのか」を公開しないから問題の切り分けがいつまでもできない
自作PC板的にチェックするようなところが殆どスルーされて非公開だからCPUの問題だと確定できないんだよな

http://damelog.com/

例えばこの人とか、M/B交換とメモリ交換を行ったことはわかるけど、
BIOSバージョン不明、メモリ設定詳細不明、電源型番及び使用期間不明、使用CPUクーラー不明、
関係なさそうだとしても使用GPU不明、使用USBポート不明、ARC-1214-4i使用スロット不明

言い出した人の環境に関してはCPU以外一切不明だし進歩ないのは仕方ないと思う

86 ：32：2017/06/22(木) 16:46:47.40 ID:oZ/YjweJ.net

>>73
だからスタックフレーム言うとるのよ

87 ：Socket774：2017/06/22(木) 17:17:00.67 ID:GLGMajwN.net

>>84
メモコンはCPUの機能だろうが。オンダイだぞ。

88 ：Socket774：2017/06/22(木) 17:23:14.80 ID:cBELvyWC.net

>>87
メモコンとメモリー間の相性悪いからって意味ね
当然メモリーが規格に適したものであるならryzen側が修正しないといけないが

89 ：Socket774：2017/06/22(木) 17:41:27.92 ID:yesur6tC.net

朝はグダグダだったのに今見たらスレタイに即した内容になってて草

検証できる有志は検証環境のハード・ソフト構成と結果を挙げて行ったらいいのでは？
集計すれば何か傾向など分かるかもしれない
(例えばこのマザーだと出ないとか、等)

CPU・マザー・メモリはできれば製造週と製造国も
CPU・メモリは定格かOCか
AGESAによる変化はあるか、もあればなお良し(Ver.Up毎にメモコンいじってるし)
テンプレも作った方がいい

あと検証したいが何をしたら良いかわからない有志候補のために、検証の仕方の手順を作ってくれる有志もいるといいと思う
(そういうサイトがあればその案内でも可)

俺は残念ながら有志候補レベルだが、テンプレ草案位は作れると思う

90 ：Socket774：2017/06/22(木) 17:44:30.71 ID:VJO9OE+8.net

ttp://news.mynavi.jp/articles/2015/09/29/ddr4/
腐ってたのはCPU側Skylakeのメモコンが原因でメモリの品質には全く問題は無かった訳だが、何故かモジュール側で対応させてるよね

91 ：Socket774：2017/06/22(木) 17:51:57.38 ID:yesur6tC.net

Intelお得意の、他に経費をなすりつけるためだろ
これならすでに製造した欠陥メモコン入ダイを全て捨てる必要がなくなる

92 ：Socket774：2017/06/22(木) 18:17:24.89 ID:DDbmQj7H.net

AMDもやれば良いべ？

93 ：Socket774：2017/06/22(木) 18:27:46.36 ID:5V34xtZ3.net

AMDとかGentooとか各フォーラムに事例が連日報告されてる
再現方法が完全に分かってるわけじゃなくて、全ての個体に起きてるわけじゃないようだけど

94 ：Socket774：2017/06/22(木) 18:40:48.66 ID:yesur6tC.net

>>92
AMDはメモリモジュールメーカーに圧力かける必要ないからな
そもそもなんでお前このスレにいんの？
ネガキャンのネタ探しか？

95 ：Socket774：2017/06/22(木) 18:51:22.82 ID:yesur6tC.net

連投すまんが
>>93
その各フォーラムのリンク貼ってもらえないか？

96 ：Socket774：2017/06/22(木) 18:56:13.09 ID:mxoD2KmK.net

>>95
https://community.amd.com/message/2800014
https://forums.gentoo.org/viewtopic-t-1061546.html

97 ：Socket774：2017/06/22(木) 18:56:49.89 ID:AhK4zRCq.net

>>89
そんなの本来AMDがやることだろ
なんで購入者がそこまでやらないといけないんだよ

不具合報告を上げたら、AMDが詳細条件とか調査してバグ修正すればいい

98 ：Socket774：2017/06/22(木) 19:05:31.86 ID:mxoD2KmK.net

Ryzen Segv Battleとかやってる人たちはハッカーとして面白いからやってるんであって消費者としての立場でやってるわけじゃないと思うな

99 ：Socket774：2017/06/22(木) 19:07:57.15 ID:u0oVCB5S.net

放っとけばいい

メモリ交換して問題が起きなくなった人がいるんだし
同じ現象起きたくない人はその人と同じメモリ付けときゃいい訳だ

そうやっていろいろ議論するのがLinuxユーザーの楽しみ方の一つで
昔もLinuxでは使えないとかあって
ペンギンシールが貼ってあるものはLinux動作確認済みですとかやってたんだけどな

100 ：Socket774：2017/06/22(木) 19:08:35.25 ID:cBELvyWC.net

>>97
今回のエラッタは全環境で発生してないからな
AMDへの情報提供量が少ないだけ発見修正の時間がかかる