http://anago.2ch.sc/test/read.cgi/jisaku/1498012307
【エラッタ】Ryzen SEGV問題 情報交換【フリーズ】
5 :Socket774:2017/06/21(水) 17:11:47.35 ID:o24PzCa3.net[1/8]
くこか
ペンギン村にもカキコしたけどここでも
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[1/6]
AMDから直接送られて来るのかこのツイートでは分からんから現状なんとも言えんな
続報を待つとしよう
7 :Socket774:2017/06/21(水) 17:33:26.32 ID:o24PzCa3.net[2/8]
ここでメモ
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サポートが個別対応とのことだけど、やっぱりどーなるんだろ?
wktkの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
10 :Socket774:2017/06/21(水) 17:46:56.40 ID:FEthGAzE.net[3/6]
>>8
これはビルドしたカーネルが仮想マシン上で動かない件の詳細な調査事例
残念ながらエラッタがある模様
マイクロコードで直せるレベルなのか?
11 :Socket774:2017/06/21(水) 17:54:38.63 ID:o24PzCa3.net[3/8]
>>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[4/8]
スラドでトピが立った>>8
<title>Ryzen SEGV Battle、原因の一端が解明される | スラド Submission</title>
https://srad.jp/submission/71785/
15 :Socket774:2017/06/21(水) 18:24:41.89 ID:FEthGAzE.net[5/6]
スラドのトピックの書き方だと>>8の現象が仮想マシンでのカーネル起動失敗とgcc segvの両方に関係するように読める
B2ステップでは直してるだろうけど、B1ステップをどうするかがまだ決まってなくてAMDとしては現時点では話を大きくしたくないのだろうなと感じる
続報待ちだな
21 :Socket774:2017/06/21(水) 21:28:44.46 ID:H8KNizh3.net
>>15
むしろcall命令で呼び出し先が-64バイトずれたら、もっと多様な問題が起きると思うが
発現頻度がかなり低いか、特定の条件があるのか
AMDが問題をどれだけ早く認識していたかによってはB2 steppingでも直ってないかもしれない。
29 :Socket774:2017/06/22(木) 00:09:02.14 ID:M4vWvYHl.net[2/2]
http://satoru-takeuchi.hatenablog.com/entry/2017/04/24/135914
何かしら負荷がかかるとマズイらしい
ちなみにSEGV起きない人は起きないらしいので
167 :Socket774:2017/06/23(金) 02:28:55.73 ID:TLn+gW9j.net
>>29
>>166
165 :Socket774:2017/06/23(金) 01:52:04.97 ID:TLn+gW9j.net
ブートでコケるやつはryzenを認識できない事による対応命令の誤認識ってやつでしょ
ブログに情報が出てたよ
SEGVはuopcache切っても発生して、
ipは正しいんだからL1i-cacheに病気持ってるってことに見える
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だと報告が無いんだ?
40 :Socket774:2017/06/22(木) 02:43:01.53 ID:dJdn60bH.net
こういうのがあるからAMDは仕事用に採用しにくいんだよなぁ
良い製品が出来たのにほんともったいない
42 :Socket774:2017/06/22(木) 02:51:46.24 ID:CAw/d0dR.net
>>34
64バイト前方にずれるので同じ命令を二度実行しても、データや結果が不正に化けるだけでエラーにならない場合もある。
WindowsはLinuxみたいなシステムと違って、エラーメッセージが貧弱だから問題が起きてもブルースクリーンが出たで済まして
原因究明する利用者が少ない
>>40
本当にウキウキな気分だったのに泣きたい
I wanna cry.
70 :32:2017/06/22(木) 12:01:22.32 ID:VF+YIWhe.net
>>42
64ずれるってのがわからない
プログラムカウンタズレてそれだけってことあるのかな
それともスタックフレームを意味してる?
73 :Socket774:2017/06/22(木) 13:23:02.39 ID:ByYNIDAF.net
>>70
プログラムカウンタがずれたんじゃなくて、データがずれたんでしょ
86 :32:2017/06/22(木) 16:46:47.40 ID:oZ/YjweJ.net
>>73
だからスタックフレーム言うとるのよ
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
起きるパターンは負荷テストを止めてほんの 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
コピペ3
BitVisor から覗いて見てわかったのは、ミスって #VMEXIT の状況を
うまく確認できるようにしていなかったことだw Local APIC の書き込みアクセスで
#VMEXIT したところだけ見えていて、果たして NMI が出ているのかはっきりしなかった。 (ω)しょぼーん。
これはさすがにやっぱり CPU 内部関係かなという感じがとてもする。
キャッシュがどうのこうのという感じではない。
レジスターの内容はこうして追ってみると一理ある感じなので、命令の実行が何かおかしいの?である。
(↓おそらく64bit先のに飛ぶことのかと)
LastExceptionToIP がなぜかユーザー空間のアドレスになっていることが多々ある。
例外の遷移先だから、カーネル空間でないとおかしい。VMM が絡んで変なことになるにしても、
それなら VMM の使っているアドレス空間でなければおかしいだろう。LastExceptionFromIP も
ユーザー空間にあるのは別にそれでもいいとも言えるのだが、そこに明らかに LastExceptionToIP にジャンプする命令が入っているというのはこれまたおかしな話である。
内容に矛盾はなく、本当に、ページフォールトだけがおかしいのである。
まるで 0x40 ズレた、手前の位置の命令を実行しようとしていたかのように。ハードだとしてもそうなる原因わかんね。。
80 :Socket774:2017/06/22(木) 14:33:36.34 ID:aV35CHfS.net
起こってるやつはメモリと各電圧の値含めて全環境を提示してみてくれ
そういう情報が一切無いからどうにもだ
ちなみに、定格とかじゃ無くて具体的な数字を上げてくれ
144 :Socket774:2017/06/23(金) 00:00:05.66 ID:dr/cl1ft.net
KaliLinux 64bit
http://egg.2ch.net/test/read.cgi/jisaku/1498034171/153
153 名前:Socket774 (オッペケ Sr0b-1uIF):2017/06/22(木) 23:56:34.57 ID:OeveasXtr
>>80
よし以下スペック
CPU Ryzen 1700X
GPU 玄人志向 GF-GTX1080-E8GB/OC/DF 2枚HBSLI
SSD Crucial CT275MX300SSD1
HDD WD WD30EZRZ-00Z5HB0 2台
マザボ Asrock X370Taich uefiバージョンはP2.20
メモリ crucial CT8G4DF8213 を4枚計32GB
147 :Socket774:2017/06/23(金) 00:20:08.49 ID:vFfxwILR.net
>>144 に書いてある153の人は、他のスレでKaliLinux 64bitで起動時にsegv出ると言っていた人
環境詳しく晒せと言われていた所までは読んでた
150 :Socket774:2017/06/23(金) 00:46:38.37 ID:OdgI64oV.net
>>144
これ投稿したやつだけどryzen購入時期は発売直後
分岐予測とかSMT切っても発生した
あとメモリのプロファイルはDDR-2134, cas-latencyが16.0, ras-toCASが15, ras-prechargeが15, tRASが36,tRCが50という値になっていた
cpu-zから確認した
185 :Socket774:2017/06/23(金) 12:15:15.29 ID:5O4DTjPI.net
けど基本的な構成データは欲しいとは思う
>>144みたいなメモリのサポート外ということもあるし
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お得意の、他に経費をなすりつけるためだろ
これならすでに製造した欠陥メモコン入ダイを全て捨てる必要がなくなる
93 :Socket774:2017/06/22(木) 18:27:46.36 ID:5V34xtZ3.net
AMDとかGentooとか各フォーラムに事例が連日報告されてる
再現方法が完全に分かってるわけじゃなくて、全ての個体に起きてるわけじゃないようだけど
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とかやってる人たちはハッカーとして面白いからやってるんであって消費者としての立場でやってるわけじゃないと思うな
100 :Socket774:2017/06/22(木) 19:08:35.25 ID:cBELvyWC.net
>>97
今回のエラッタは全環境で発生してないからな
AMDへの情報提供量が少ないだけ発見修正の時間がかかる
103 :Socket774:2017/06/22(木) 19:22:01.71 ID:yesur6tC.net
>>96
ありがとう、後で見てみる
>>97
そう思うなら賛同・参加しなければいい
AMDのアクションが鈍い(公式な情報公開が全くない)事もあって、不安に思うユーザーは日々少しずつ増えている
ならユーザーレベル範囲で不安の軽減策として何かやれないかと思って一手段として書いてみたまで
(賛同は得られないだろう事は承知の上)
AMDに不具合報告を上げるのも手段としては有効だろう
現状おそらく報告件数が少なすぎるのがアクションが鈍い要因と思われる
件数が増えれば増える程AMDに重大かつ緊急の問題と認識させられるだろうから
148 :135:2017/06/23(金) 00:22:46.42 ID:vFfxwILR.net
連投すまん
再度幾つかのページ見てきたけど、やはり自分で環境作って実際にsegv出してみないと現象に対する理解が深まらない事が分かった
またハード的に幾つか試したい事も思いついたので出直してくる
あと変なのに絡まれてるからこれ以上スレに迷惑かけるのも嫌だし
ちなみに石交換になった人のページ見てたら、石交換は単に故障かどうかを切り分けるためで、同じ機種の別の個体と交換という事らしい
(B2ステップとの交換ではない模様)
453 :Socket774:2017/06/24(土) 08:09:59.80 ID:z/bCphdQ.net
ubuntuで耐久テストばりに負荷かけて暗号通貨掘ってるがCPUでエラーとか出ないな