【エラッタ】Ryzen SEGV問題 Part.4【AMD】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>578
OCメモリ使ってなくても出とりますやん
>>579
２０１８年１月更新のBIOSでも出とりますやん AMDは無償交換してくれるけど、インテルは放置か。 そもそもAMD自身が個別対応するから連絡してくれって言ってるのにな
もう面倒だから日本国内のAMDに似た謎の会社が自分たちの所に問い合わせがこないようにおま環呼ばわりして回ってると思うことにした >>589
最初はIntelマシンをゲーム用に、コア数の多いRyzenはLinux環境で使おうとしたんだけど、
原因不明のSEGVが発生するので結局逆にして使ってた。
その後CPUを2700Xに買い替えたので1700はRMAに出すことにした。
SEGV問題発生当時はCPU電圧上げてみてくれとか色々AMDサポートに言われたりしたみたいだけど、
今ではスクショ一枚送るだけで返送先住所とFedexやUPSのアカウントID（送料はAMD負担）を連絡してくれるから楽になった。
海外に送るのもインボイス3枚(同じもの)用意するぐらいで後は国内の返品と大差無い。
https://i.imgur.com/akAw68K.png satとかいうの関係なしにSEGVするからしょうがない そもそもメモリーの品番とセッティング、ママンの品名なーんもださねーくせにSEGV連呼されてもな。
もう頭くるくるパーの妄言にしか聞こえねーよ、キチガイにとっての真実とやらはもうおなかいっぱいなんだわ Fedexって結構送料高いな、集荷依頼してから3時間ぐらいで来たから配達も早そうだけど
自分で負担したら1万3千円だからAMDのFedexID指定するの忘れたら涙目だなこれ
>>593
2700XじゃSEGV発生しないけど、そのままCPUだけ初期ロットの1700に戻したらSEGVするんだよね(CMOSリセットのみ)
基本AMDのサイトに動画付きで説明があるからその通りにやってRMAするだけだし >>595
君、そのスクショを何に使うのか言ってごらん？
まさかパクってジャンクCPUをRMAしようとか考えてないよな >>594は変な奴に対するコメントかと思ってたら違った
5chの外だと現実を見ないといけないからここに引きこもるしかないんやな いや、もう終わった話をいつまでもグヂグヂ引っ張る奴が悪い
初期ロットは比較的不良品が多いって話で終わっただろ(良くは無いけどさ)
煽ってた奴らはさもryzen全体の欠陥みたいに騒いでたけどね 今やググればサポートとのやりとり含めて多くの事例が出てくるしこのスレが役目を終えたのは確かだな
しかし当たりを引いた立場からしたら根拠もなくおま環言って騒いでる奴らは問題解決に何の役にも立たずクッソ邪魔だったぞ 最初に騒いだ人らがいきなりぶっ壊してたり、わざわざ特殊な環境下で特殊な事してたりしたから余計におま環言われやすかったのも事実
何故かこのスレでAMDに対して声を上げて欠陥を認めさせましょうみたいな呼びかけをしつこくしてた人もいたね
全部あいつらのせいだろw 確かに基本的な切り分け手順がなってない人とか
何やってるかよく分からんテストプログラムをよく分からないまま走らせて騒いでた人がいて混乱した節はある
しかしそもそも何のせいかって話ならそいつらは関係ないでしょ
不良品のせい以外の何者でもねーわ 1700の初期ロットと2700XでCPUだけ交換して同じ処理やらせても1700じゃすぐSEGV出てたな
2700Xは10分以上回してもSEGV出ない（修正済だから当たり前だが）
RMA申請して受理されると、AMDはFedex（もしくはUPS）に電話しろとか言って来るけどこれだけはいただけない。
電話して集荷するとその場で書類書かないといけないから待たせることになる、
アカウント取ってオンラインで伝票とインボイス書いて印刷しておいた方が良い
1700 (2分後)
https://i.imgur.com/ukAj8Jl.jpg
2700X (10分後)
https://i.imgur.com/yz39qT7.jpg
製造周
https://imgur.com/Iq48u6Q.jpg
>>603
全部ならともかく一部のロット不良はほんとに厄介
店で交換してもらっても古いロットだと再発するしぐぐれば同じ症例で何度もRMAやった人の記事とか出て来る
当初原因がよく分かってなかった頃にサポセンとやり取りした人には感謝してるわ 今だからこそ不良品の所為でしたで済むけどねぇ…
当時の検証を邪魔してたのはどっちですかね？
あぁ、騒いでた本人ですか、そうですか。
今更な話をもったいぶってやるなら多分ツイッターの方が構ってもらえるよ
初期ロットはヤッパリ怪しいからやめといた方が良いですねで良いじゃん なんか見えない敵と戦ってるな…
Ryzenの本スレとかに今更持ち込もうとしてるっていうならともかく
このスレでやる分には単にスレタイ通りの話をしてるだけやんけ スレタイ通りっていうと誤解されそうなので一応言っておくと
当時スレタイにエラッタを頑なに入れようとする勢力と
入れさせまいとする勢力が謎の争いをしていて
俺はそんなもんどっちでもいいから両方くたばれと思っていた 何で興奮してんの？この人
つか、最初から単に煽ってるだけだねコレ 原因はエラッタでないのは判明したわけだし
次スレのスレタイは「エラッタ」から「製造不良」に変えるべきだな もうRMAしたら終わりの問題だし次スレはないだろう 影響がある人間なんてユーザー全体の1%もいないだろうに
必要以上に騒がれた印象はあるな RyzenのSEGV問題はまだお笑いネタになるからいいじゃない
Intelの投機的実行絡みの脆弱性問題なんて草すら生えない状況だぞ >>615
この間このIntelの問題の影響でSEが死んだらしい てかintelの製品新旧問わずSEGVでてるやんwwww
メルトなんちゃらスペなんちゃらセカンドなんちゃら
どうしますんの？これ 全ての面に於いて手抜きで有名なIntelのことだし別に不思議でもない >>616
SEとかPGってしょっちゅう死んでるだろうから
あんまり変わらんけどな >>620
intelは交換する“直ったモノ”が未だ一切無い件 BIOS更新しないわ、OCメモリ使ってるわでRMAしている奴居たしな…
クズですわ RMAするとOCメモリに古いBIOSでもSEGVしないんやで いや、SEGVはそういう問題じゃないから。
スレを遡って読めないイケヌマとかいわれるよ。 2700XだとWows(WinE)とかやりながらビルドループしてもやっぱSEGV出ないな
>>620
AMDは初期ロットのみだからRMAで後期ロットへの交換対応だけど、
Intelは修正済のCPUはまだ出てないから無理、年末には対策済のCPUが出まわってるはず
対策品が製造開始されてもIntelが交換するかは知らんが 常識的に考えてOCやBIOSバージョンの問題ならRMAリクエストに対してサポートから指示があるがな クソ電源な上に組み立てミスってた奴もいたな
そこまでやったら壊したか不良品かわかんねーよみたいな奴
そんな奴らばっかりなのに検証もせずスレに来てリコールリコール騒いでたからな いやスレでは検証してたやろ
それとは関係なく騒いでたのもいたけどあいつらLinux使うとも思えんし多分そもそも買ってすらいねえだろ 電源が不良だったり、オーバークロックしてCPUが壊れると
何故か通常の使用ではエラーが出ないのに、GCC回すとSEGVが発生するように
なるという摩訶不思議な壊れ方をするんですね。ｗ そもそも壊れたらSEGV以前に負荷テスト通らないのでは？ 多分最初に騒ぎ出した人たちの笑いどころは素人以下のクソ検証でエラッタエラッタリコールリコールと騒いでた事だよね
このスレにまでわざわざ来てたしなあ
ここでは黙々とメモリっぽいねぇ、個体差があるねぇってやってたのにね 信仰製品がセキュリティーホールだらけで頭がおかしくなってんじゃね？ >>636
こことか見れば分かるけど、ジャンプ先や戻り値がズレて本来の場所と違うアドレスに飛んで、
データが誤った値のまま動き続けて結果として出力ファイルサイズが違うとか起きてるからな
おかしな動作をした結果一定確率でSEGVしているだけで、SEGVしなくてもデータが正常とは限らない
初期BIOSはメモリ相性の問題があったからそれと混同してるのが多かった
http://www.e-hdk.com/diary/d201706c.html#20-2 当時のスレ状況の話なのに今になって当時の調査内容に突っ込んで何がしたいのか…
雉か？ >>635
通る
負荷テストは悪魔の証明であって無条件で信用できるモノじゃない
あとSIGSEGVランダムはメモリで起きる、コアエラーじゃ起きない
ここまでは実証した、Ryzen以外でな ちなみにSEGVが発生する石だと、memtest86+のマルチプロセスモードでエラーを吐く。
交換してもらった石だと正常になった。
実際にメモリ上のデータが壊れているようだ。 >>644
じゃあ一度は見てるはずだけど残念ながら覚えてないな
どれがそうかも分からんものを探すのはむりぽ
ってもしかして>>642の人とは別人か >>643
過去スレでどうぞ
初頭の検証やりまくってた時に混ざっていくつか上げた
報告された頻度を他環境で全て再現できたのはコレだけだと思う
UMC制御ファームのPROMあたりにちょっとした何かがあったと見てるけどね >>645
>交換してもらった石だと正常になった。
>実際にメモリ上のデータが壊れているようだ。
念のため質問
交換してもらった石ではメモリ上のデータは壊れてないんだよね？ >>646
IDかわってるけど>642は俺
色々やったけどXMP適用のみ調整なしってケースがランダムなポイントでのSEGVを再現出来た
調整次第で頻度はかなり変わった
この場合memtest3周は通ったのにSEGVは出るなんてのも平気であった、その後SEGVが低頻度なケースをmemtestをさらに追い込んで(放置)20周くらい通すもエラーなし
単なるCPUのOCでPrime5分しか持たないようなヤツでやっても落ちるか通るかの2択(中身がどうかは保証しない)
CPU-NB(L3+UMC)も同様、そもそも起動しないか起動して何も起きないかの2択
ちなみに普通に何のエラーも出ないような全ツルシからマージン+でも出てくるモノのサイズもハッシュも違って、こりゃ無意味だなと悟りやめた
最終テスト出来ないんじゃ意味がない
因みにそのツルシでビルドしたGCCとカーネルを使っていた
確かKernel4.14と7.0.0だったか8.0.0だったかキリのいいGCC(自動で3回ビルドして検証させられる、面倒)でやったわ
デスビは16.04のx64 >>649
手間をかけさせてしまってすみません、ありがとう
これを見て考えてはみたもののRyzenで起きてたものと同じかどうか単純な結論を導くのは難しいか…
個体によらず再現するものなのかは気になる
定格で適当に動かしてるIntel環境があるから試してみるか
当時Ryzenでメモリタイミング色々いじったけど起動しなくなることはあれどSEGV頻度は変わった印象なかったんだよね
もっとも統計的に頻度を語れる程の試行回数ではなかったけども
RMAで交換後はSEGVが出なくなったからもう追究するモチベーションはない… >>650
となると内部の制御系PROMかな
HWマスクは変更されてないから違う(大事になる)、BIOSに依存しないからMicrocodeではない
逆に言えば、この基礎PROMは100%セキュアって事か
修正に回収してるわけだし
まぁ追求はしなくても良いとは思う
命令がズレて化けるなんてアドレスがズレる以外にランダム要因無いし
と言うことは電源制御、パスセンサー系ファームないしMMUしか無いわけで >>649
そういえばSEGV出る個体だけMaxx MEM2を20回やってから再起動or電源を切る、
をやろうとするとリセット＆電源OFFの直前まで進むんだけどそこからブラックアウトのままで止まってたな
再起動せずにそのまま使った場合は普通に使えるという・・・(後に再起動しようとすると止まるが)
DDR4-1866 CL20とか緩めてもSEGV個体だとダメで後期ロットだと3466でも発生せず
opcache切れば発生しないけど何故なのかよく分からなかった >>652
発生条件が限定的過ぎるなぁ
ただまぁ中継点としてアドレス周りが絡んでるのは確かだな
もしかすると実際にSEGVが発生してた訳じゃ無いのかも
何らかの仕様上の差異を吸収しきれずに、結果としてSEGVを吐いてるとすればわからんでもない
ハードワイヤード部分でもmicrocodeでも無くてアドレスが怪しいとこ
L0や他キャッシュとの調停周りだけならもっと普遍的に出る筈だし
例の64バイトも考えてみりゃおかしいしな、可変長だったよなぁと、SEGV以外も出ないとおかしくないかな(他にも言えるが)
L0ミスからのtlb/ページウォークミスで引き摺り出したテーブルの末尾オフセットが特定の数値の場合、誤って8バイトほど加算されて適用されるとか(適当言ってる) SEGVプログラムもなにも、GCCでコンパイルするだけでしょ？ Intelでも起きるし、しかも非推奨の並列オプション付けてコンパイル。 だからかなんか知らんけど今になって恥を雪ぎに来てる人がいるよね
一応設計の不具合ではなく検査を通り抜けた不良品が多かったでカタがついた話なのに AMDはSEGVでなくなったから、今はインテルの石がSEGV欠陥品ということか。ｗ
インテルは放置が原則なんだな。
最近の脆弱性の問題でも。 本当にSEGVが毎回出るのであればコンパイル通らないからカーネルのビルドが出来ないので大問題だよな
初期ロットのRyzenはそれが出るから問題だった（しかも数分で）
現行品は何時間やってもSEGV出ないからな
Intelも不良品が0%なんてことは有り得ないからSEGV出る個体もあるだろう
まぁ不良はRMAしろで話は終わりなんだが 陰土人の嫌らしい言い回しも天才的だよな
未だにネチネチとアホかよ 雪だるまのスノーカイ（第二形態）が初めて輝いた＞最終面 >haya@homuh0mu 6月26日
>返信先: @homuh0muさん
>前回のからあまり変更はありませんが、スレッド数を1増やしたのと、メインスレッドのほうでsched_setaffinityを呼んでいるところが主な差分です。
>この状態でUbuntu17.04とその標準のgccでビルドして「./run.sh 8 2500000」をするとSEGV出ます。
コレ以外の設定じゃ出ないそうですね
この限定された方法で稀に出たとして、それが実使用でどれほどの脅威になるのだろうか
sat
homuh0mu
EIRAKU
カス三銃士 セグメンテーション・フォルト SIGSEGV や SIGBUS エラーの原因を特定する
https://www.isus.jp/products/fortran-compilers/sigsegv-or-sigbus-errors/
インテルR Fortran コンパイラーでコードをコンパイルすると、Linux* で ‘sigsegv’ (または Mac OS* X で ‘sigbus’) エラーが発生することがあります。
このコードは、以前のコンパイラー/プラットフォームでは問題なく動作していました。インテルR コンパイラーが問題なのではありませんか、という問い合わせを受けることがあります。この記事ではこれに関する回避方法を紹介します。 問題は、SEGVが解消してないロットのものを
未だに普通に売っているということだな。 >>671
代理店の在庫は交換済のはず、店舗の在庫は知らん
ちょっと考えれば分かることだが不良品を売った方が高コストになる
Fedexの送料計算してみればすぐ分かるよ
個人がRMA＝１件ごとにFedex送料+関税(片道１万3千円、送料はAMD負担)
代理店がRMA＝複数のCPUをまとめて送るので送料が安い アスクみたいに普通はSEGVに関しては代理店での交換は応じていないので
別にコスト高になるということはない。 Fedexってそんなに送料かかるの？
往復の送料で
儲けが吹き飛びそうだな ディスコンしてる製品でIntelだろうがスナドラだろうがお構いなしに出るような
おま環エラー相手に真面目に付き合うAMDが如何に神対応か思い知れるな ■ このスレッドは過去ログ倉庫に格納されています
