14+5 ：Socket774 (ﾜｯﾁｮｲ 6e74-uerO) [sage] ：2017/06/30(金) 21:20:22.91 ID:F92AV0K00 (1/2) [PC]
キャッシュ階層エラーとかAGESA1004a以降のBIOSでは見たこと無いけど、
うちの1700でもAGESA1004a以前はテスト用EXEで一発ブラックアウトだったけど今は問題無いな。
AGESA1006でも未だに発生してるなら初期不良で交換してもらった方が良いよ
OCとか、BIOS更新してないとかは問題外。
そういや、電源のコイルが容量抜けしてコンデンサ鳴きしてるやつだと何やっても安定しなかったな、今は交換したけど。
※電源分解して耳にシリコンチューブ当てて聴診器変わりにして鳴いてる部品を特定
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/KuthSwm.png)
>>10
まずECCメモリじゃない時点でお察し
相性きついのもXMPで動かないから手動でサブタイミング設定しないといけないのもRyzenメモリスレ見れば分かるわけだし
特にHynixモジュールは定格でBIOS起動すらしないからタイミング緩めるもクソも無いとか酷い相性出る場合があるわけで
価格COM辺り見てくれば何件もあるからね、Intel環境では動くのにってパターン
Hynix DDR4-3200は未だに8割方まともに動かなくて海外フォーラムでも2933止まりとか3066止まりとかやってるのが現状
SkylakeでもあったけどB0ガーバー基板だとIntel環境でも相性出るぐらいだから
8コアで入れ食い状態になるRyzen環境だとかなり厳しい
＞同じ「DDR4」で何が違う? - センチュリーマイクロのDDR4 DIMMで検証する「B1ガーバー」の効果
http://news.mynavi.jp/articles/2015/09/29/ddr4/001.html
http://news.mynavi.jp/articles/2015/09/29/ddr4/002.html 751+5 ：Socket774 (ﾜｯﾁｮｲ d7ec-TkOv) [sage] ：2017/07/12(水) 12:32:56.49 ID:QjaB+xjZ0 (13/22) [PC]
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) @ DDR4-2400 1.2V
tCL 16
tRCDRD 16
tRCDWR 16
tRP 16
tRAS 39
tRC 55
tRRD_S 4
tRRD_L 6
tFAW 28
tWTR_S 3
tWTR_L 9
tWR 19
Trcpage 383
TrdrdScL 3
TwrwrScL 3
tRFC 660
tRFC2 420
tRFC4 312
tCWL 12
tRTP 10
Trdwr 9
Twrrd 1
TwrwrSc 1
TwrwrSd 6
TwrwrDd 6
TrdrdSc 1
TrdrdSd 4
TrdrdDd 4
tCKE 6
CR 2T
700+2 ：Socket774 (ﾜｯﾁｮｲ d7ec-TkOv) [sage] ：2017/07/11(火) 21:38:16.38 ID:nnG1B4ZV0 (51/52) [PC]
なんだか自分だけ解決してしまって申し訳ないです
>>699
tRFCには仕様上の下限があるので、最近のDDR4-2400で16GBなモジュールなら、
tRFC1>550,tRFC2>350,tRFC3>260(単位はns)を守らないといけないので目安にしてください。
Row Hammer対策はtREFIなんじゃないかな…
私のはtRFC1 260.0ns指定(313clk)がSPDにあったのでそれを参考にしましたが、
最近の微細化が進んでいるモジュールでは上の値を採用したほうがよさそうですね。 950 ：Socket774 (ﾜｯﾁｮｲ 3a5f-hBgs) [sage] ：2017/07/15(土) 01:17:19.23 ID:lGWf+wRH0 (1/3) [PC]
新BIOSにしたから新しいsegvtestのwin版試したら1000台でエラーだったのがopcache controlをdisableにしたら10000超えてもエラー無しだわ
メモリのタイミングも各種電圧設定も総当たりで試してダメだったからこれでエラー出なくなったらスッキリすんだけどなぁ
916+4 ：Socket774 (ﾜｯﾁｮｲ 8eec-oLxb) [sage] ：2017/07/14(金) 14:06:16.58 ID:NhpYj5UA0 (6/17) [PC]
WindowsユーザーのためのUbuntu16.04でカーネルビルド無限ループさせたい人向け手順
1. 16GB以上の空きメモリのあるマシンと空のUSB Memory(4GB以上)を用意します
2. http://releases.ubuntu.com/16.04/ から ubuntu-16.04.2-desktop-amd64.iso を入手
3. ISOイメージをUSB Memoryに焼くために Rufus を https://rufus.akeo.ie/ から入手 (Rufus 2.15 Portableで構いません)
4. USB Memoryに2.でダウンロードしたイメージをインストール
5. 再起動、BIOSでF11を押してUSBから起動、Try Ubuntuを選択
6. 起動したら、左上のボタンを押してTerminalと入力、コンソールが開きます
7. 手順に従っって延々とビルドしてください… https://pastebin.com/bPEAVz5e
おまけ。Ubuntu16.04のgcc 5.4.0を再コンパイルしたい人へ
(コアダンプ解析したいとか。apt source 使うべきなのかもしれませんが、ここでは本家を採用)
https://pastebin.com/k9YpeqS3 13+2 ：Socket774 (ﾜｯﾁｮｲ 663e-cwwm) [sage] ：2017/07/16(日) 07:10:33.45 ID:S/CSAvjm0 (1/5) [PC]
1800X、C6H、M378A1K43BB2-CRCで
自動設定だとSPDより速い15-15-15-36、電圧も高めの1.35Vに設定されてカーネルビルド数回でSEGVが発生したけど
SPDどおりの17-17-17-39、1.2Vに手動設定したら250回を超えても発生してない
メモリ周りの安定性の確認にちょうどいい感じ
19+6 ：Socket774 (ﾜｯﾁｮｲ 663e-cwwm) [sage] ：2017/07/16(日) 09:34:16.39 ID:S/CSAvjm0 (2/5) [PC]
>>15
自動設定のとき
http://imgur.com/0v7UnXs
手動で17-17-17-39、1.20Vに設定したとき
(tRC、tRDWR、tRDDATAはAutoのままだがタイミングが変わってる)
http://imgur.com/prUDDQw
SPD
http://imgur.com/4sNh2hi
i┷i
∧＿∧ ⌒ ｒ"￣ヽ
（ ´∀｀） ⌒ |= イ .|
. （ ４亀,.つ ⌒ l.= ン |
.＿＿ ｜ ｜ | ⌒ l.= テ |
|――| （_＿）＿） ﾎﾟｲ |= ル |
￣￣￣￣￣￣￣￣￣￣￣￣| `､＿ノ
| ￣
|
|
|
DIMMの基板は横に240mmもある。3GHzの波長はわずか100mm。
これだけ厳しい事情が揃えばいろいろ小手先の技では超えられない壁が出来る。
ソフトの人にはわかりにくい話かも知れないが、
配線があればそれだけで当然抵抗もあるが、高周波ではインダクタもキャパシタも強く影響する。
少し前からマザーの配線すら注意してみると技術がいろいろ詰まっている。
130がまだ公にしてないことがありそうだし
時期が来たら公表しそうな雰囲気だから一応残しておいていいかと
組み込み系の技術者が何人か発言していて公にもなにも十分すぎるヒント出ている…
問題のある個体も恐らくマイクロコードで対策できる範囲なのでお蔵入り希望ー
後追いであっても報告することで今後に反映されていたらいいな、くらいの感覚
立場を理解していただきたいのだが、大騒ぎする意図はこちらにはないのよね。
もし評価されるとしたら、彼らと一緒に仕事がしたいか、なんじゃないかな？
どちらにせよ、大騒ぎの種が終わったというのだからこの問題は終わるだろう。
socket774の言う通り、彼は根本的な原因にかすりもせずに終わった、終了。
問題を速やかに解決したい人はRMAしてくださいどうぞとの公式アナウンス。世界平和
彼については茶化す以上にはどうこう言うつもりはあまりなかったのだが、
あまりにもひどすぎるパッチについては指摘しておきたい。
すでに指摘がなされているが、初期のK8における問題を知らないのに、
https://github.com/torvalds/linux/commit/637716a3825e186555361574aa1fa3c0ebf8018b
このようなパッチをコミュニティに投げたことについては
https://gist.github.com/satoru-takeuchi/687fb72c65c65e4896cc8836ae24d4c4
最近のエンジニアは経緯を調べることもしないのかと心底呆れている。 恥を知れ
問題を広げることが目的なのであればこのパッチの意図に一貫性はあるかもしれない。
そうでなければgitの使い方について誰か教えてあげたほうがよいのではないかと
すでに指摘されているようにCore micro-architecture優勢の時代が長すぎた。
これは様々な問題が現実にあることを無視できる別の意味でのフリーランチ
これを好機として10年以上のバグを一掃する方向に走るか、Core micro-architecture以外を非難するか。
Linuxに対する風評被害が生じてしまっているように見えるが、問題を改善していくのがOSS文化だ。
Linuxは文化としてユーザーを大切にしているので今後の展開については安心してよいかと IA-32切るのが早過ぎる
もうちょっと待ってよ、、、
>>14
> 立場を理解していただきたいのだが、大騒ぎする意図はこちらにはないのよね。
twitterやらAMDフォーラムの捨て垢消してこいよｗｗｗｗ 急いでスリッパ買うほどのことでもないんだけど
RMAって購入後何日までやってくれるの？
> twitterやらAMDフォーラムの捨て垢消してこいよｗｗｗｗ
それぞれにコンタクト取ってみれば？
さて、これは困った話なのだけれどもLinuxの電源制御に
CPUを破壊しかねないものがあるような…これもWindowsはまた影響を受けない。
ただし、Linux使用後にはWindowsでも問題が起きるようになる。
どうしたものかなこれ。これが本物の原因だとしたら笑えないぞ
公式にLinuxがサポートされるまで、仮想マシン以外でLinuxを使わないことを強く推奨案件
>>19
＞ただし、Linux使用後にはWindowsでも問題が起きるようになる。
これは「過去一度でもLinuxを使用した個体」ではWindowsでも問題が起きるようになる、という事？
Linux終了時は再起動だけして、UEFIセットアップに入り電源ボタン(ケース正面の物理スイッチ)を押してOFFにする、という手順を毎回行う事で回避出来ないか？ >>19
Linuxでスリープは使わない、という前提ね ある程度謎明かししてくれないとまた何言ってんだこいつみたいな空気になりそうだけど
>>24
そうなのか・・・
SEGV直ってるか確認するのに最近生産されたと思われるものを注文したんだけど、その問題があるのでは確認出来ないね orz
あと既にLinuxで使ってしまった手持ちは、仮に交換に出しても交換後LinuxでSEGV出ない事の確認をしてAMDに報告する事になるだろうから、結果SEGV直っても別の問題を抱えた個体になってしまう可能性がある
今交換に出すのはやめた方が良いかもしれない
この件は続報待ちの様子見だな
よろしく頼む
それにしても次から次と問題が出てくる
正直参った そこってリモート(SSH)で評価する事もできるそうだから、企業とか学校名目なら検討中という事にすれば試せるかもしれない
その後の営業からの売り込みは覚悟の上だが
BKDGが出ていないから完全に対応が遅れちゃっているね。
まさかの電力制御に問題ありって話になるとLinuxを生では使えないな…
一応レポートは飛ばしてあるけど、WindowsでSleep使えなくなったのはつらい。
これがBIOSの問題なのかLinuxの問題なのかはわからないが、
はっきりしているのはWindowsのSleepが正常に動作していたのが
Linuxを試行した後、完全に復帰不可能になったってこと。
Windows側が対応してくる可能性にも期待したいが、Linuxでの試験不足感ひどい
>>26 返事来たら共有するよ
参考までに、Sleep復帰失敗時のwrmsrのコンテキスト
MSR0000_041C[0..7]しか現状定義がないのに何て値を書き込もうとしているんだろう
CONTEXT: fffffc0785701870 -- (.cxr 0xfffffc0785701870)
rax=ffffffffffffffff rbx=0000000000000000 rcx=000000000000041c
rdx=00000000ffffffff rsi=fffffc07857022d0 rdi=0000000000000017
rip=fffff8021b61fadc rsp=fffffc0785702268 rbp=000000000000041c
r8=ffffffffffffffff r9=0000000000000007 r10=0000000000000000
r11=0000000000000000 r12=0000000000000010 r13=00000000c0000000
r14=0000000000037403 r15=fffffc07857023e8
iopl=0 nv up di pl nz ac po cy
cs=0010 ss=0000 ds=002b es=002b fs=0053 gs=002b efl=00010017
hal!HalpWheaNativeWriteMsr+0xc:
fffff802`1b61fadc 0f30 wrmsr >>25 "Performance Marginality Problem"というのはあまりにも広義すぎるが、
いわゆるSEGV問題とされていたものはこれに含まれているのと
私のレポートと矛盾ないのでこれでいいやって感じだなあ >>26 ちょっと考えてみたのだが、試しにHyper-V環境下でSEGV出るかの試験をして、
出るようならしばらくLinuxを生で走らせるのをやめて交換後Hyper-Vで試験というのはどうだろう？ しっかし、LinuxにおけるAMDサポートはどんだけ放置されていたんだよ…
こういった問題はOSSはおれの環境では報告に対するパッチワークになりがちだが、
ここまで放置されてしまっていたのはいくらなんでもひどすぎだろう。
あと、電力制御問題に関しては古いKernelではKaby Lakeもランダムにクラッシュすることが報告されている
Linux使った後でもWindowsでスリープ開始も復帰もエラー全く出ないけど
何か条件あるのかな
>>34
完全な条件はまだ完全にわかってはいない。解決に持ち込むためにはもう少し狭めないといけないが、
>>30 は問題が生じていることを説明するのに十分かとー。バージョンはいくつですか？ >>36 LinuxのunameとWindows のVersion x(OS Build y.z) を教えていただければと なお当方、Windows 10 Version 1703 (OS Build 16251.0)
試験したLinuxは4.8,4.10,4.12
Win10 Home 1703 OSBuild 15063.540
LinuxはXubuntu16.04.2でカーネルは4.10だったけどunameしたのは記録してないから詳細は不明ｗ
メモリタイミング調整して4時間以上SEGVしなくなったの確認してからは次のAGESAが出たらまたテストするつもりだったから
それ以来Linuxは起動していない
>>39
15063.540ということはCreator Updateなしってことか。インストールしてみるね
Xubuntu16.04.2だと、Kernel 4.10.56あたりかな。頑張って差分読んでみるか
っていうか、有償ベータテストにもほどがあるだろうっていう。苦笑 >>40
あ、そういえばXubuntuインストールした時は4.8だった
4.8でテストしてるうちにアップデートで4.10に変わった >>41
XubuntuであってもUbuntuと初期は変わらないので16.04だと初期が4.8.0-36、
apt updateで4.8.0-56あたりに、apt upgradeで4.10になるかとー
これで範囲が狭まった。ありがとう！ RyzenがLinuxを公式にサポートしていないっていう事実というか理由が見えてきた感じだなー
たぶんAMDは最初から分かってたかもだけど、Linux側がパッチなのか設計なのか？わからんが、どこまで対応するのか、AMDとしてはそれ以上のことはできないしな
仮にLinuxの電源管理（？）の問題だとして、そうだとすると
新しいCPU届いて直ったーとか言ってるやつらもしばらく使ってるとまたSEGVするようになるわけだよね？
なんかみんなスルーしてるから突っ込むけど、
＞Windows 10 Version 1703 (OS Build 16251.0)
ってそれInsiderPreviewじゃないですかー
問題の切り分けしようとしてるときに絶賛ベータテスト中のWindows使ってて
なんか挙動がおかしくなりましたって言われてもなーという感じ
仮になんかの目的があってIP使ってたとしても、少なくともこの文脈ではそれを断っておくべきでしょうに
15063.540っていうまさに正真正銘のCreator Update使ってる人に対して、
＞ということはCreator Updateなしってことか
とか言っちゃってるしこの人本当にWindowsのこと分かってるんだろうか
>>27
スリッパやEPYCはNUMA扱いだからカーネルの挙動が違うのでは？ レジスタに変な値書く事がある
って事か
FXでもBKDGに無い項目にチョイチョイ訳の分からん値が入ってたがアレかな
>>48
Linuxの対応が遅すぎってこと
新しいもの出た後はいつも遅くこれがオープンソースの弱点 >>50
近いけどちょっと違うね。
20年、30年も前の古い手法で記述されたコードが、
手直しされないままに現代のCPUでコケてる。
逆になんの手直しもせずに数時間くらい耐えるのはすごいことだよ。
それだけ後方互換性に気を遣ってるってことだから。 >>52
あぁなるほど、いつものやつか
そういう点においてはいつまで経ってもlinux系(UNIX系?)は進歩せんよね
窓も林檎は派手に切って前に進んでるし、泥だって切るの標準仕様だし
やっぱヘッドが居ないプロジェクトってアレだな 仮にLinux固有の問題として、RyzenってLinux使ってるようなサーバー用途こそ主なターゲットだと思うんだけど
Ryzenって、多コア=サーバー向けっていう従来の考え方を打ち破るコンシューマー向けの製品だと思う
>>54
何で?
そういうのはEPYCとかTRだろ
それにPCと変わんないようなWSだとしてもlinuxでその辺に転がってる有象無象じゃなく、RHELとかああいうのを使うわな
今回の問題が派手にならない理由と、原因がいつまで経ってもよく分からん理由はそこにある
高性能向けとは言えないけど小さくもないニッチなプラットフォームで、使用者がさらにその帯じゃニッチなlinux配布系デスビを使った時に顕在化する
ニッチということは同時にOSSとしては重視出来ないということ、人x質がリソースだけど人と質は同期して推移する
つまりまぁ待ってろって事だな >>51
オープンソース何だから不満なら自分で対応すれば
一円も払わない癖に他人を頼るな >>53
さらに面白いことに、Intel環境でも発生する報告が上がってもなお、Ryzenが悪いと言われてるという。
もはや、青い方の会社へのネガキャンじゃないかコレ。 >>52
タスク・スイッチングやページング・メモリー関連の話？見当付かないから適当に思いついたこと並べただけだけど
CPUの基本的仕組みは20年ほど変わらず、クロック・アップ、省電力化やマルチコア化してきたから20年前と同じコード(手法？)が使えそうだけど
明文化された仕様が変わったのか、暗黙のルール的なものが変化したのか、AMD64とIntel64の仕様の相違か
そう言えば、20年前はx86互換CPUを作るメーカーが10社くらいあったかな。各社の互換性が高かったのかOS側で泥臭い努力をしたのだろうか >>59
X86内部がCISC処理からRISC風処理への転換しだした頃から色々あるからね。 >>32
仮想ではSEGV出なかった(orもの凄く出にくい？)気がした
思い出したがWSLでは出る報告あるからWSLではどうだろうか？ >>29
Windowsでスリープ(ACPI S3)からの復帰は、すぐ試せる以下の環境では成功した
1500X+MSI Mate(SEGVテストで1ヶ月以上Linuxを動かしてたもの)
Windows8.1 Enterprise評価版(Build9600.17050)
(高速スタートアップ、ハイブリッドスリープはOFF)
スリープ→1分後電源スイッチ押す→復帰
3回試して3回とも成功
イベントログも正常系のみでエラーは無し
後で1700+Taichiの環境や他のVerのWindowsでも試して報告したいと思う
なお自分はスリープ使わない(設定も切ってる)ので、手持ちのRyzenは過去Linux、Windows共に一度もスリープしてない
(1500Xは今日初めてWindowsでスリープした) >>61
仮想で出ないとなればOSが変なもん投げてる説強いな >>64
アーキテクチャごとに最適化してきた結果、旧式の最適化されたコードが残って障害になる。 >>63
仮想では自分では試してない
出たという報告を見た覚えもなかった気がした
なので本当に出ないのかは分からない
曖昧な書き方でスマン あと先程Windows10のISOダウンロードが終わった
回線が20Mbps位なので時間かかった
今インストール用のUSBメモリ作ってる
遅いUSBメモリ使ってるからさらに時間かかる
まずは>>29と同じInsiderPreview 16251.0を入れてみる
次に>>39と同じ15063.540(但しEnterprise評価版)で試してみる 具体例が書けないってことは、単なる想像か？
基本的にCPUは、過去のCPUのアプリが動くように作る
いまだに16bitモードが使えたり、8bit時代の命令が使えたりする
>>45
うお。すまん、問題が解消しないから段階的に上げていったらこうなっていた
WinDbg使えるくらいにはWindowsには詳しいかも？指摘ありがとう。
>>62
ありがとう。BIOSの問題かもしれないので Windows7, 8.1, 10, 10 CU, 10 IP 試してみるか >>70
それはどのCPUにでも当てはまることじゃなくて、ｘ８６シリーズの売りのひとつだね。
後方互換性はCPUにとって、別に基本ではないよ。
あと、8bit時代ってのは8080かな？バイナリ互換はなかったはずでさ。 >>72
もちろんx86限定の話だよ
自作PC板のRyzenスレなんだから
8080とはバイナリ互換はないけど、
命令はいろいろと引き継いでる
確かに、ここで出す互換性の例としては不適切だったかも知れない 化石レジスタAHへのアクセスに関するエラッタがちょっと前に話題になったので
>>70
8は走らない
16までだけど当然16-32-64と拡張する時に足してるだけじゃなく引いてもある
にも拘らずその世代のコードを引きずるとどうなるか
それ自体既に誰が手を加えて何処がどうなってるかなんてわからないモノを使えるようにするには?
単純に足すしか無い、互換がなくなるから
当然そうやって肥大化した上にMT化やら何やらを場当たり的に足して解決する
要は何処がどう動くかよくわからんモノができる訳だ
盲目でやるジェンガみたいなもんだ うわーCPUが革新的すぎて過去のソフトがまともに動かないよーたすけてー
>>52 を批判するのはちょっと違うかなーと思う。Linux Kernelは誰でも読めるので読んでみたらいいですよ。
30年前はさすがに言いすぎかもだけど、大昔に採られていたトリックなんて普通に残っているし邪魔でしかないよあれ
移植性に関してもx86とは違いすぎるわーってところからarchに分離されていく流れなので設計思想の違いを感じる。
ユーザーランドをぶっ壊すなボケという思想はWindowsも見習ってよと思うことも多い。どっちもどっち
Intel IA-32 Architectures Manualsを神聖視してもいいんだけどさ、
実際それに完全準拠しているCPUがないからErrata表が重要視されているわけで
Simple PathなりDirect Pathデコードができる命令以外は今は何でもこい状態で、
覚えている人がどのくらいいるか知らないけど、NetBurstがあっさりAMD64に対応できた
が、REX Prefix対応が範囲外で弱かった…みたいな万能CPU化しすぎているんだよね。
そして、化石化したMicro architectureが、いきなり組み込み向けとして復活したりするので捨てられない
IntelはItaniumですっきりさせようとして懲りたのでTick-Tockで地雷を避けつつも、
ちょっとしたパフォーマンス向上のために電力食いの道へ、AMDはなぜか変化球投げてくるので初期ユーザーのおもちゃに。
RISC-Vあたりがすっきりさせてくれそうだが、20年蓄積されたIA-32の資産はあと半世紀は残るんじゃ… >>79
AVX-512サポートとそのレグレッションやりたくないから
Windows 10より前でのサポートが切られたSkylakeの話？ 雑談終わり。OS揃えるのは週末待たないとつらいな。
Windowsで問題が起きていたらこんな8月でなく初月で大騒ぎだよ
RHELへの言及があったが、この手の件は有償サポートが買えるOSでも買えばいいし、
整数演算重視なら、DDR3世代のXeon+ECCでいいだろ、
科学技術演算ガチでLinuxしか選択肢がないならQuad-Channel Broadwellでも買えばいいのになあ
>>73
アセンブラにしろ高級言語にしろ、ソースレベルの互換性はCPUの互換性とはいわないと思うけど。
実際、読み込ませても動きませんし。 それ言い出したらF00F Bugどうするのっていう…
コンパイラが回避している命令順序や特定のバイト列はもうしゃれにならない領域かと
>>84
エラッタはエラッタでしょ。
仕様にしちゃう？ >>71
1700+Taichi(約一ヶ月SEGVテストでLinux使ってたもの)
Win10 Pro IP 1703 Build 16251.1000
にてスリープ→復帰成功を確認した
(ハイブリッドスリープはON/OFF両方試してOKだった)
ネット繋がずISOから入れただけでBuildがそちらよりちょっと新しくなってしまったので参考データとして見てもらえれば
やはりそちらで別VerのWinも入れて試した方が良いと思う
7、8.1、10CE、10IP全てのVerでダメならそちらの個体が壊れたと言っていいかと
あと>>61のWSLで試す件、できれば意見をもらえると助かる
判断つかないならHyper-Vだけにしてみるが >>85
残念ながら一度Erratumとして扱われたものはコンパイラで回避されるために
それがいつ直ったのか、今後どうするべきなのかが定まらず回避され続ける = 仕様化する
>>86
そうなると、こちらのBIOSの問題かもしれない。PSUごと落としてBIOSリセットかけてみるか？
しかし、あのMSR0000_041Cに対する値は意味不明だ。地雷を発破していく感覚…本当に道楽だ
WSLだと他の問題が生じるのでHyper-Vでとりあえず試してみることをお勧めしたいな。
これで、Hyper-Vでは落ちなかった、性能あまり変わらなかったって話になったら苦笑するしかない >>88
ではなくて、8086が8080の後方互換製品か否かと、エラッタによる仕様不適合をごっちゃにしてどうするの。
あと、エラッタが仕様にならんでしょ。
互換性に関わる仕様ってのはそれ以降に出てくる製品にも反映されるもんだよ？
コンパイラの仕様の話なんてしてないし。 >>88
あともしBIOSが最新でなかったら(面倒でなければ)最新にしてみるのも良いと思う
WSLの件はありがとう
お勧め通り仮想だけにしておく
Hyper-Vと、ついでにVMware Workstation でも試してみようと思う
(個人的にはVMware使ってるので)
性能はどうだろうね
仮想は実機の8割位と聞くが、その通りになるだろうか
あと今までRAMディスク使ってなかったんだけど、SSDの書き込み量が7TBを超えてしまった(約1ヶ月で寿命の1/5以上書いた)
ちょっともったいないのと、仮想のディスクI/O性能を少しでも良くするために今回からはRAMディスク使ってログだけSSDに書くようにしてみる
なお新品CPUはまだ届いてないので始めるのはもう少し待ってほしい >>90
RAMディスク使っていなかってマジすか…tmpfs使うようにテンプレ書いたのは、
make loacalmodconfig だと1回の試行が 7GBに、make defconfigでも 1GBに達するからなので…
なんてこったい orz /root での試行スクリプトってどこが出自でしたっけ。
この試験はSSDでやると本当に一瞬で寿命縮めるので…先にそのスクリプトに指摘入れておくべきだった…
>>91
手順を書いてくれてたのは知ってたんだけど、メモリ周りに疑惑があったから、あまり負荷を上げない方が良いと思ったのが一つ
あとまさかそんなに書き込まれるとは思ってなかった自分がアホなだけ
smartctlも入れてなかったから確認も最近までやってなかった
笑い話の種にでもしてw
最初のスクリプトはスレ1の後半辺りから出てたけど、その時はRAMディスクは自己解決的に語られてた
(Linux使い的には常識なんでしょう)
だから全くRAMディスク使わない流れだった訳ではないです ちなみにsmartctlでのNAND書き込み実測値だと、defconfig時は1回につき約220MB書き込まれてた
(makeの出力のファイルリダイレクト含む)
だから例えば約111時間(4443回)だと約955GB書き込む計算になる
最初からsmartctl入れて計算しとけば良かったんだよね
ほんとバカw
>>93
気付かなかった。ちょっとそれ探して書き直しておきますね。
前スレ https://pastebin.com/ebp9VJHa で
# mount -t tmpfs -o size=10G none build
としたのはUSBブートであっても、RAMの半分がtmpfs上限既定を取っ払うためだったのです。
なお、WSLにはtmpfsがないのでこれもまたWSLでの試験がお勧めできない理由です。
あちゃー、本当に申し訳ない。皆どこのスクリプトを？？と
思ってはいたのですが、そんな流れがあったとは知らず… >>95
その時点のスレ的にはまずは再現してみようという思いが強かった事もあるので本当に気にしないでください
60GBで5000円位のSSDですし、まだ3.5/5位は残ってますので、この件が終わったら使用頻度の低いノートにでも入れますから
多分ノート本体が先に壊れますw
あとWSLでtmpfsが使えないのは初耳だったので勉強になりました
その勉強代と思えば安いものです >>96
60GB！今どき35TBW上限はと思ったらそういうことか
WSLでもtmpfsをmountできますが、実態は現状は普通のDiskです。
WSLで
$ mkdir tmp
$ sudo mount -t tmpfs none tmp
$ mount -a
...
none on /home/test/tmp type tmpfs (rw,relatime)
$ df -m
...
C: 204800 137037 67764 67% /mnt/c
none 204800 137037 67764 67% /home/test/tmp
と表示されてメモリ関係ない…となるのは現時点での仕様です。
本物のtmpfsは大雑把に言えばファイルがメモリアロケーションに対応しますが、
WSLはLinux Kernel Emulationであってもそれは出入口のEmulationなので現状こんなものです。 >>74
mov ah, 09hみたいなのはもうexceptionを出していい気がする
DISK I/OのBIOS call (INT 13h)じゃあるまいし
ソフトウェア的に古典x86 CPUをエミュレートするItanium方式は今思えば賢い >>57
それ逆な
オープンソースなんだからいつでも開発降りていいんだぞ
Linuxの１つや２つ無くなったところで誰も困らないし代替はいくらでもある
開発者がやってあげてる感覚じゃ進歩もないわ >>97
WSLの現状のtmpfsはこれだと単なるディレクトリと変わらないね
しかもtmpfsの仕組経由でアクセスするから若干性能落ちる？
互換性維持用と言ったところか
その割にSEGVは出る(手抜きしてない所はLinux Kernel同等？)んだから不思議な存在だ
Microsoftの新機能初回Verとしては頑張った方かな >>100
変わらないね。パフォーマンスも全く同程度になるかと。
WSLはあくまでもシステムコールのエミュレーションのみで中身はLinux Kernel関係ない。
FreeBSDにLinux Emulationがついているのと変わらないと考えてもらえればよいかと。
Windowsではまずボリュームありきで、それをボリュームマネージャが認識し、
ファイルシステムドライバに認識させるプロセスが取られているので、
仮想ディスクをRAM上に作らない限りにおいてはボリュームを作ることは難しい。
それに現状、NTFSとReFS, FATのみがメインでのサポートになる。
Windowsで新たにファイルシステムを作るのはそれはそれで相当な努力が必要なので
今のところそこまでする必要なしと判断されているんじゃないかな。
SEGVが出るというのは正直追試していないのでわからないところではあるが、
WSLには関係ないという結果が出てもあまり不思議ではないとも思っている >>101
詳しくありがとう
いつも勉強になる
ところで(VMwareWSは10年以上経験あるが)Hyper-Vは今回初だったのでWin10CU再インストール後色々いじってた
先程ようやくHyper-V上のUbuntu16.04.2LTS(アプデ無)で連続ビルド始めてSEGV出るのを確認した
たった7回で出てしまった
出るかどうかの確認には使えそうだ
17.04+MainlineKernel4.12.2も後で試してみる
スクショ
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/3RDqYg9.jpg)
性能面は今回はtmpfs使ったがビルド時間は約85秒
実機でSSDの時は約80秒だったから(ディスク速度差を無視して)大雑把には約6%遅い
仮想でこの程度なら良い方だと思う
環境(ホスト)は
1700+Taichi(BIOS P3.00)+マイクロン2400メモリ8GBx2
Win10 Enterprise評価版 Ver1703 Build 15063.540(Creators Update)
Hyper-V上のUbuntu(ゲスト)は
16コア、メモリ8GB割り当て
Ubuntu16.04.2LTS(アプデ無)
Kernel 4.8.0-36-generic
ASLRはON
uOpCacheもON
tmpfsは3GB割り当て
(2GBでも大丈夫そう)
メモリタイミングはRyzenTimingCheckerのスクショで
(130氏提示とほぼ同じ)
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://imgur.com/dNrcW2g.jpg)
あと連続ビルドはいつもと同じ
Kernel4.11.7をmake defconfig後make -j 16
>>101 で肝心なことを書き忘れていたのだが、RAM Diskを
Disk Manager->Volume Manager->FS Driver認識させる方法だと、
ファイル削除時に常にTrimが飛ぶわけではないので(明示的なのは defrag /L)
RAMを柔軟に開放することができない欠点が生じるという。 >>102
Hyper-VはLinux KernelにおけるXen IntegrationもKVMも関係ないので
最もバニラに近い結果が得られるかと思ったのだけれども予想以上の頻度ですね。
私のほうでも追試してみます。
それだとちょっと頻度が推定できないので1時間走らせて何回とかできますか？
こちらでも追試してみようかと。実は最初に疑ったのはこのケースだったのですが
違ったという。未だにこれがLinux Kernelの問題なのかどうなのか悩んでいる…
どちらにせよ、試験としてLinuxを直接起動しなくともHyper-Vでできるというのは朗報ですね。
壊すのは怖いのであまりLinuxを直接インストールしたくない。
VMware Workstationは元々Hypvervisorのない環境で特権命令を
置き換えていく特許により高いパフォーマンスを発揮するよう
設計されていたため、現在の挙動はわかりませんが、
あまりゲストに関心のないHyper-Vに比べると異なる挙動を示す可能性はあります。
また、Hypervisorの同居はセキュリティ上の問題…気が付いたら最強のRootKitとして
Hypervisor Malwareが乗っ取っている問題…の回避から拒否されることもあるかと思うので、
管理者権限で
bcdedit /copy {current} /d "Hypervisor Disabled"
などとしてコピーを作り、表示されたGUIDに対して
bcdedit /set {xxxx-xxxx-xxxx-xxxx-xxxx} hypervisorlaunchtype Off
とし、Hyper-Vが無効な起動選択肢を作ると同居させやすいかもしれません。
起動時のOS選択タイムアウトは30秒ならば
bcdedit /set {bootmgr} timeout 30
として設定できます。 >>105
取り急ぎ回し始めたので、1時間位したら報告したい >>104
Windows用のRAMディスクソフトは一般的に2GBなら2GB分メモリ確保してしまうので、そういうものと思って使えばあまり気にはならないと思う
むしろLinuxのtmpfsが実際のファイル容量分しかメモリ使わない動的制御してるのに驚いた
(恥ずかしながら今始めて知った) 確証がない以上は、古いLinuxをむやみに走らせるべきではないと言い切れないが微妙。
かといって、普段使いでもないLinuxのためにRyzen買いまくるのはどーかとって感じ。
Sleep問題が少なくともここで生じてしまってしまった以上は、Linux自己責任感が…
tmpfsの実装はファイルが削除されたら該当ファイル部分のRAMアロケーションの開放。
動的制御ではなく、ファイルが一つのRAMアロケーションなので消えたら解放される。
Windows NTのルールに則らなければ教科書通りの最も簡単な実装ですよ。
これは設計上の考えなのでもし、IFSがボリュームを必要としていなかったら、
tmpfs相当を実装するのは非常に簡単なのだけれども、Windowsはよくも悪くも、
Windows NT 時代の「引きずるくらいならその場でFSよりはHDDを落とせ」思想が強い。
それに加えてTransnational API(これはcygwinも依存している。ReFSで廃止予定なので文句がひどい)で、
制約がなかなかひどいのでNTFSの実装がどんどん肥大化しているというのはどうなんだろうねー
そんなサーバーのような発想ってどうなのよって思ったのだけれども、
これだけユーザーがー多い中で大した破損しか報告されていないのは、
実はユーザーのほうが復旧に対する意識がないので壊してはならない帰結なのかなと思ったり。
>>105
VMwareWSはVer5までは特許(バイナリ変換)だけだった
Ver6から仮想化機能付CPUが普及してきたのに合わせて仮想化機能(VT-x/AMD-V)にも対応し始めた
Ver7で追加の仮想化支援機能(EPT、RVI)にも対応した
(上位製品(vSphire/ESX/ESXi)との差別化のためVT-d/IOMMUには非対応)
ゲストOSがWinXPまでの場合はバイナリ変換の方がパフォーマンスが良いのでそれがデフォルト
WinVista/7の場合は仮想化機能を使った方がパフォーマンスが良いのでそれがデフォルトで使用される
(ユーザが後から明示的に変更も可能)
あと64bitOSの場合は仮想化機能しか使えない
とはいえいわゆるType2(アプリケーション型)なので、Hyper-VのようなType1(HyperVisor型)に比べると遅い
そんな場合でも出るのかどうか見ておこうかというのが目的
(&個人的にはそれでもVMwareWSの方が使い勝手が良いというのもある)
Hyper-Vを止めないと同居できないのは知っているのと、VMwareWSは1500Xの方に入れようと思っているので、そちらはそもそもHyper-Vは入れないかもしれない
ただ最近はマルウェア防止の意味合いもある、というのは知らなかった
(昔は仕様上/技術上の制限だけだった) >>109 Ver6. からについては追いかけていなかったので感服…
同居できないのはUEFIの導入とSVMあたりからかな。
全部仮想化されるとRootKitも何もなくなるわけで。
EPYCで導入されているはず？の仮想マシンのRAMごと暗号化はそれ対策なんだよね >>105
1時間位で
wait(cc1終了待ち)1回
(OS再起動はせずスクリプトだけ止めてやり直した)
SEGV2回
2-3回/時間といった所かな
SEGVの場合のスクショ
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/QAkjTZ2.jpg)
>>108
スリープの件がはっきりしないうちは止むなしかと
tmpfsの実装はなるほどと思った
容量指定はクォータみたいなものだね
WindowsだとそもそもRAMディスク機能がOS標準で用意されてないし、自作ファイルシステムをMicrosoftが解放してない？というのもあるから止むなしなのかな
壊してはならない、というのはあると思う
XP辺りからGUIでディスク整合性チェック(CHKDSK)をやると良いか悪いかしか表示しなくなった
(CLIでは色々出るけど)
その辺りからして、そもそもユーザにファイルシステムを意識させたくない方針に見える
>>110
最近は仮想でメモリ暗号化までやるんだ
RyzenでUEFIのメモリ周りの設定に暗号化っぽい設定がいくつかあるのが気にはなってたけど、UHD-BD対策なのかね位にしか思ってなかったw
そのうちPCもPS4とかゲーム機みたいに全部暗号化されるんだろうね >>110
余談だけどVMwareWSの8以降を書いてないのは、今使っているのが7の最終Verだから
8でVMware社はインド人スタッフにリファクタリングさせたのだがバグだらけで使い物にならなくなった
自分も今まで全く問題なかったからいつも通り8にあげたら色々おかしいので元に戻した
しまいには某社で8に上げたら社内システムが使い物にならなくなって情シスの課長さんがクビになった、という噂まで出る始末
VMware社も8のシリアルキーで7を使えるようにする程出来が悪かった
それから新Verはしばらく様子を見る事にしたのでそれ以降のVerは詳しくない
少し前に11を試しで使ってみたが問題なさそうだった
その後開発スタッフが全員クビになった事があるので現在の最新版12.5はどうなのか不明だが今回12.5を試してみるつもり
こんな感じで順風満帆とは言えない上クライアントHyper-Vの登場でVMwareWS/Playerは位置付けが難しくなってきたから残念だが先行きは明るくないと思う >>111
経過報告
20:34頃に発生
21:59頃に発生
コンスタントに2-3回/時間ではないようだ
でも頻度は高い方だと思う >>114
経過報告
21:59頃を最後に出なくなってしまった
とりあえず最初の数時間の傾向例ということで
一旦止める
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/HVxigdw.jpg)
>>112
自作ファイルシステムを作ることはやぶさかではないのだけれども、
ドライバの署名問題が…ハイブリッドカーネル(自称)と言っても空間一緒なので
ファイルシステムドライバ(IFS)が死ぬと本当に死んでしまうので厳しい。
chkdskで出てくるのもせいぜいインデックスの未参照報告くらいかと。
アクセスコントロールリストを個々のファイルで持つと効率悪いのでまとめたが、
回収が完全でなくなった場合にごみが残っていても容量も食わないために
chkdskではじめて報告されるケースが多いのはそれが事実上無害だからだね。
ユーザーにそれを意識させないためにかなりコンサバティブな動作をしているが、
結果的にベンチマーキングでひどい負け方をするんじゃないかな。特に細かいファイル
Zenのメモリ回り暗号化は、CPUやHypervisor実装に問題があってお隣が覗けたとしても
AES暗号化キーがないと回復できないので覗き見できないよ機能、
RAMが物理的に抜かれて液体窒素冷却からの分析対策、
結果的に高度なアクセスパターンのスクランブリングによるRAM安定化、と色々狙いすぎ。
UHD-BDはどうせ鍵が漏れたら…とか思いつつもそれを避けるために
CPUにまで暗号化されたパスを導入する、あまりにも強烈な策なので別件かな。
こういう変な仕様が取り込まれるたびに命令系統がややこしくなっていくのでいい加減にしろと…
>>115
おつおつ。最初の数時間があれなのは強調された報告でよく耳にしていたので、
やはりそんなものなのかなーと。 今日やっと注文していた1200新品が届いた
製造週(と思われる数字)は1725(17年25週)
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://imgur.com/orIfIdJ.jpg)
製造週については下記ページのコメントの後半(moreクリックで続きが出る)辺りにRMA2回目で1725のが来て直ったような事が書かれている
https://m.srad.jp/story/17/08/09/098243
図らずも同じ1725が来てしまった
本当かどうか分からないが近日中に試したい
(先に1700で仮想のUbuntu17.04+Kernel4.12.2を試さなくてはならないので)
参考まで手持ちの1700と1500Xも上げておく
(発売日購入なのでどちらも初期ロット)
1700は1706
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://imgur.com/SFNz1J6.jpg)
1500Xは1713
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://imgur.com/iOZEkBz.jpg)
なおThreadripperは米尼初回組の人で1729
(製造週の写りが悪いので見にくいが)
【AMD】Ryzen Threadripper 6足目
http://egg.2ch.net/test/read.cgi/jisaku/1502557119/
187 名前:Socket774 [sage] :2017/08/14(月) 10:34:42.03 ID:zbblBhKi
スリッパ着弾 糞でかい
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://jisaku.155cm.com/src/1502706794_b3244ce8624a9792d2428f9021a2b6365a06fd91.jpg)
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://jisaku.155cm.com/src/1502706794_194e91330fa3eb5d9b57fd221416b9d0aaffa846.jpg)
👀
Rock54: Caution(BBR-MD5:f68c41b6bce4f8b76d46a9fc61dd270c) Hyper-V上のUbuntu17.04(apt-get update/upgrade)+MainlineKernel4.12.2で連続ビルドを始めた
1時間程経過したがSEGVは出ていない
Kernel4.12.2だとやはり頻度は激減する
実環境同様しばらく回してみる
なお他の構成は>>102と同じ Ryzen_SEGV_Battleに参戦するには、
1. 定格外メモリのメモリ4枚刺しを行う
2. パラメータのおかしいSPDを食わせる
3. 古いBIOSを利用する
4. 古いKernelをわざと使う
が最低条件だとは思っていたのだが、Linux Kernel 4.8.0と4.12.2だと差分がでかすぎて
読むのにちょっと時間がかかるかもしれない。問題だと思っていた箇所以外に何かありそうだ。
RCU周りの変更が入っている4.12より4.11のほうが安定するのではないかと言われていたが、4.8.0よりはるかに安定するのは確か。
まだ気づいていないLinuxの問題がありそうなので調査が終わり次第、
報告の後、こちらでも共有したいと考えている。できれば電源回りの問題についても。
Sleep復帰時の問題はWindows側で対応可能である可能性が高いので何かしらの貢献ができれば。
初期ロットとおかしなBIOS、古いLinuxの組み合わせにおける救済措置だったとしたらひどいな。
もしそうならば、AMDもLinuxもどちらも非難されるべきではない可能性が。
改善で対応できればそれに越したことはない。
電源回りの問題は少なくともLinuxを直接インストール後では生じたことを否定できないので
今のところ、Linux専用機としないのであれば直接の起動はお勧めできないといったところ。
SEGV問題対象かどうかはHyper-Vで試験可能だとわかったわけだし、かなりの進歩なのでは。
土曜日はちょっと用事があったのであれだが、日曜にもう少し深堀してみようと思う。
Windowsを片っ端からインストールしてみるものも含めて。
追試にお付き合いいただき本当に感謝しております。
Linuxに関わらずにWindowsのみでの環境で問題が起きるとは思えない。
データ化けが生じないのは現在把握している範囲では理屈上そうなるし、
これだけ馬鹿売れしていてゲームなりエンコなりが落ちまくっていたら大騒ぎだ。
あえて参戦条件を満たしてLinux Kernel 4.8.0を試せばgccどころかインストールに失敗するほど落ちるのだが、
もしほとんどのユーザーが対象であるWindowsでそんなことになっていたら
4桁以上の騒ぎになっているはずなのだが、そういう話にはなっていないんだよな
むしろ公式フォーラムを見ていて、DDR4-3200がどうの、Linuxがどうのというのが理解できん
#Ryzen_SEGV_Battleとは一体何だったのだろう。
彼がLinuxをちっとも理解していないことはよくわかったが…
インストールで思い出したが、Ununtu16.04.2LTS/17.04をHyper-Vの仮想マシンにインストールする時の注意点
※仮想マシンVerは第一世代を使用した
(1)ISOからブートするとPIIX4云々という赤いエラーメッセージが出る
無視してしばらく(5分位)放っておくと起動する
※仮想ディスクにインストールした方から起動する時は起きない
(2)インストールが終わって再起動しようとしてもシャットダウン処理中のまま先に進まなくなる
やむを得ないので「停止」する
※仮想ディスクにインストールした方でも起きる場合があるが、5分位放っておくとシャットダウンする
(これは実環境でも起きる。acpidがなかなか落ちない時がある。スリープ問題に関係あるかな？)
(3)画面解像度が低い
以下のページを参考にgrubの設定を変更する
http://qiita.com/12yzero/items/2469a97ff9242d7e153b >>120
Linux Kernelの深い所の精査は完全にお任せするしかないので大変とは思いますがお願いしたいです
スリープ問題も現在再現する個体がそちらにしかないのでこれもお任せするしかないです
(ちなみにこちらは1700・1500X共Win10CUでも問題なかった)
お任せばかりでスマン
>>121
Windows専用なら問題起きない(だろう)という点は、技術面での視点でないのは恐縮だが、発売から5ヶ月以上経っても具体的な問題報告がないので、最近は個人的には大丈夫そうかなと考えるようになってきた
手持ちの1700と1500XはWindows専用にしてRMAしないかもしれない
初期ロットだから出来れば持っていたい
今後のAGESAでシレッと対策してくるかもしれないし
あとアレは個人的には売名行為で先走った結果だと思っている
あまり書くと親衛隊が荒らしに来るからこの位にしておく >>119
経過報告
4時間を超えたがSEGVは出ていない
このまま継続する
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/rF5mc1h.jpg)
※連続ビルド時間はuptime-8分 >>124
経過報告
約21時間でSEGV出てたので止めた
これでテスト環境の準備はできた
早々に入れ替えたい
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/GtmGahZ.jpg)
Hyper-Vテスト環境のCPUを1700から1200にした
CPU変えたら強制でメモリトレーニングが動いてデフォルトタイミングになってしまった
急いで元のタイミングに戻したが、CPU交換時は一度はデフォルトタイミングになるのは避けられないようだ
現在memtest10回(HammerTest有)中
10時間位かかるので続きは明日以降に
HammerTestだけ選択してテストすれば良くないか
あれが一番キツいし
>>127
経験上8-10回目の(HammerTest以外の)Test項目でエラーが出た事が何度もあるので、少なくとも10回パスしないと個人的には信用出来ない >>128
元々は>>4のDRAMだけの話だけと思っていたのだが、他のストレージも含めて脆弱性として攻撃にも使えるのか
微細化も考えものだね
memtest86 UEFI版の最新は7.4なのでHammerTestを搭載してからは結構経っている >>4のgoogle rowhammer-testは少し前に試したので書いておく
Ubuntuの場合
sudo apt install git (git入ってない場合)
git clone https://github.com/google/rowhammer-test (ソース取得)
cd rowhammer-test
./make.sh (ビルド)
./rowhammer-test (実行)
エラーが出ると止まる
エラーがないと永遠に繰り返すので止めたい時はCtrl+Cで止める
回数は Iteration 1 などと表示される
RowHammer問題を持つDIMMでは大体100回以内でエラーが出るとの事
なので最低200回位は回した方がいい
エラーが出た場合、Intel環境ならtREF(tREFI)というパラメータを小さくする事で回避できる場合がある
Ryzen環境ではtREFは現状7800ns固定(RyzenTimingCheckerで見れる)で変更できないので基本的にはそのDIMMの使用は諦めた方がいい
googleのrowhammer-testはカーネル・デーモン・他のプロセスが使用中のメモリ範囲はテストできないが、memtest86 UEFI V6.0以降(free版含む)のHammerTestはほとんどのメモリ範囲をテストできるのが最大の違い
しかしgoogleの方でも出る時は大体100回以内でエラーが出るという事からRowHammer問題自体に局所性はあまりないと考えられる
なので、Linux・Unix系がメイン環境の人はgoogleのを、Windowsがメイン環境の人はmemtestと使い分ければいいと思う
やってる事は以下の通り
メインメモリのフリーエリアからランダムに10ヶ所のメモリ範囲を確保し値の設定
↓
隣接行(Row)をデータ化けを誘発するアクセスパターンでアクセス(Hammering)
↓
データ化けが起きたかどうかを確認
memtestのHammerTestも基本的には同じ事をしている
一定の範囲(総メモリ容量で変動)内でランダムに25ヶ所のメモリ範囲を確保し値の設定
↓
隣接行(Row)をデータ化けを誘発するアクセスパターンでアクセス(Hammering)
↓
データ化けが起きたかどうかを確認
↓
これを3回繰り返す
↓
次の一定の範囲にテスト範囲を変更し最初に戻る
↓
全てのメモリ範囲をテストしたら終了 RowHammerはプロセスルールの細分化が関係してるから
一枚あたりの容量が大きいDRAMはよく吟味しないとな
>>126
経過報告
memtestは異常なし
Hyper-V上のUbuntu16.04.2LTS(アプデ無)で連続ビルドテスト(defconfig/make -j4)を始めた
1時間経過でSEGV発生せず
このまま継続する
16.04.2LTSで4コアの場合のデータが無いので何とも言えないが、単にコア数が少なくて遅いから出てない可能性もある
(17.04+Kernel4.12.2実環境の場合は約4時間でwait発生というデータはある)
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/sFal4BV.jpg)
>>133
経過報告
5時間を超えたがSEGV発生せず
このまま継続する
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/LfZcF8e.jpg)
あるタイミングでCPU載せてる基盤の実装を修正したという噂があるが
良くなってるのかな
前スレ130氏のメモリタイミングでDRAM電圧ちょっと盛って久しぶりにカーネルビルドを一晩回してみたら現在まで1100回連続でsegv発生なしまでようやくこれた
100回に1回は発生してた頃を思い出すと感慨深い...
すまん、ばたばたしていて試験が進んでいない orz
RowHammerについて個人的な見解を。Gigazineの話では
> もしも全てのブロックに破損を起こせるなら、権限を奪えるだろうということです。
> この結果は、ファイルシステムが動くSSD、HDD、などストレージの種類に依存しません
となっているが、HDDは非常に長い符号長を持つECCがなされており、
論理的破損ブロックとして検出される可能性のほうがはるかに高いはず。
有名なのはReed Solomon符号化だが、最近はLow-density parity-check(LDPC)が用いられているかも？
これはパフォーマンス向け、NAS向け、エンタープライズ向けでBERの保証値が変わる理由でもある。
SSDはNon-ECC DRAMほど影響を受けない可能性のほうが高いが、問題が生じる可能性は否定できない。
ゼロ埋めと1埋めで速度が変わるタイプはそういった影響を受けやすいと考えている。
最悪なのがDRAMで、ECC+Memory scrubbingが有効でない場合には問題が起きる可能性は非常に高くなる。
丸一日gccが問題起きない環境が欲しければ古いXeon+ECCでも使えば？指摘は正しいと思う。
現代のOSの多くはキャッシュラインのサイズを意識して多くの制御構造体を可能な限り小さくしている。
皮肉なことにこのことは攻撃目的外でもエラーレートを上昇させてしまっている。
海外出張の多い人ほどラップトップが壊れるという話は聞かないかな？それくらいDRAMは弱いのが現状。
本題なのだけれども、
>>123
Linuxに関係すると思われる問題は確実に存在していて4.8.0-4.12.xでは凄まじい量の変更がある。
やはりIntel時代が長すぎたのではないだろうかと思ったりする。4.14に向けて一掃されると嬉しいのだが、
必要がなかったり、待てないならばWindowsを普通に使っていればいいんじゃないのか？とは思う。
構造によりIntelのMESIF protocolとAMD64のMOESI protocolでは問題になる箇所が若干変わるので
確率的にIntelで問題なく動いていたものが十分ではなく、Zenの登場によって従来のMOESIでもなく、
若干の重複も許容されてしまったため再検証するべきものになった箇所がいくつかあるのではといった認識。
一通り終わったらRMAしてもよいのでは？とも思うが、検証用に使える可能性があるので希少価値が生じたら笑える。
Windows使いで続けてから、Linuxで問題が起きたと言ってRMAするほうがお得な感じがしなくもないような。
>>128
memtest86のDDR4試験や、ECC error injectionが有償なのが。
メーカー製品を使っていても検証用には買わざるを得ないのかも。
ECCならBugCheckが生じる？なんて変な話もあったけれども、AM4でECCサポートは全てではないし、
該当箇所に問題があれば復旧不可能な場合にはBugCheckではなく該当領域の無効化が走るだけ。
メーカーによっては予備領域をあらかじめ確保しておいて、
再マッピングでシステム全体の健全性をできるだけ保つ試みがなされる。
>>131
詳細解説乙です。tREF 7.8usは現状の定格なのであれだが、
問題が起きるならタイミング設定を無理させている可能性があるのでそんなDRAM大丈夫か？試験には有効だろうね。 これにかかりっきり、という訳にもいかないし、都合の良い時にやるでOKかと
自分も1700を手持ちの他のM/Bに載せて4コアでUbuntu16.04.2LTSで発生頻度見ないといけない事にさっき気がついたけど、まだ組んでない
>>134
経過報告
11時間を超えたがSEGV発生せず
継続する
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/K1wVWYG.jpg)
>>140 >>141
そちらばかり追試していただいていて申し訳ないです。
69万行の差分はさくっと読める量ではないので。苦笑
99%の問題はLinuxのバグとして修正、残りは一部の命令に対して
AGESA更新で互換性維持アップデートかかって終わりだと思っています。
ああいうユーザーもいる現実に対して、OSの設計に対する姿勢、
マーケティング上の課題、本当に色々と考えさせられますよ。 Linux 4.8.0での動作保証騒ぎでThreadripperの代理店価格が爆上げしている可能性あるんだよね。
日本の自作市場が世界規模で見たら小さすぎてリスク取れない事情は理解するが、なんだかな
あんなアスペガイジみたいなやつでもカーネルの開発者になれるんだってのが今回の騒動の一番の衝撃だったな
>>144
ぶっちゃけ一番の収穫かもな
これからは(カーネルだと回避しようが無いけど)一応気をつけようと思った
m$の商売を殿様だ何だと言っちゃいたが、安心安全が金で買えるという事の価値を再認識するわ >>141
経過報告
30時間を超えたがSEGV発生せず
自分が試した範囲内かつ細かい条件を無視しても、16.04.2LTS(uOpCache ON)でこんな長時間発生しないのは初めて
やはり少なくとも製造週1725以降は対策されていると見て良いのではないだろうか
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/RI7TNOx.jpg)
>>143
単に国内代理店がボッタクリで有名なA○Kだからじゃないかと思うのだが
ぼったくった分は自社扱い全製品の価格改定時の販売店在庫の補充金と、偉い人のスーパーカー購入・維持の原資にしてる
(後からCFD販売も扱う事が判明したが、力の差なのかほとんど流通していない)
怒ったThreadripper購入予定者はほとんど米尼で買ってる
なので国内代理店扱いは売れてなくて、どんどん価格が下がっている
今日14万を切ったそうだ 製造年月って箱に書いてあったっけ？
わざわざクーラー取り外して確認するのめんどくさいが
>>148
残念ながらヒートスプレッダのレーザーマーキングしかない
購入記念で写真撮っておくしかない 確かSMT無効にするとSEGVしないっていう報告もあったから
1400とかSMT付きでやらないとならないのでは
代理店ではSEGVの交換対応はやってるのかな
直接AMDとのやりとりなら米尼とか安い方で買った方がいいよね
>>150
手持ちの1700と1500Xは実環境でSMT OFFでもSEGV発生してる
国内代理店がSEGVのRMAを受付してるという話は今の所聞いた事は無い >>149
そうなのか･･･
組んだ記念に写真撮ってて良かったわ
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/tlT9mNw.jpg)
この場合1709でいいんか？購入日は4月末ぐらい >>151
自分の1700もSMT無効でもなるよ
ただ、そういう報告がコミュであったなと思ってたから
そういうCPUに当たった場合は出ないだろうなと思っただけだよ >>150
補足
近々1700を手持ちの他のM/Bに載せて1200相当(4コアSMT無し)にして試す予定
これで出れば間違いないと考えている
あとAMD直のRMAは送料も含めて無料だから金銭的には0で済む
使えない期間が発生するのでそれが困る人はもう一つ買うとかしないといけないかもしれないが >>152
自分の1700も同じ1709PGTだ
3月末購入でSEGVあり >>153
SMT切ると頻度は落ちる傾向があるから、長時間テストしないと「出ない」と判断してしまう可能性もあるとは思う 問題が出ているロットがどこまでなのかは気になるところ
検品の方法を変えたんだろうか？分からんが
1706が最初期生産ロットなんだろうか？
>>146 おつです。困ったな、もう1725以前は手に入らないのかもしれないのか。
しかし、Linux KernelのAMD放置っぷりは相当なものだな
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/arch/x86/kernel/cpu/amd.c?h=v4.13-rc5#n760
(v4.13-rc5は現状でHEADとほとんど変わらない)
case 0x17: Zen(FAM 17h)に対する記述がまだない。なぜにFAM 12hのErratum用である
MSRであるはずのMSRC001_1029[31]がBIOSで変更できるのか不思議に思っていたが、
スルーされているからBIOSで変更できてしまうのね。逆に言えば初期値がそのまま生きる
そのような範囲を絞った話でない場所だと764行目の判定で
FXSAVE Leak (CVE-2006-1056)がK10以降も問題扱いされているし、まじかー
LinuxだとAMDは本当に微妙でしかないが浮動小数点演算遅いんじゃないかな。
ここ最近だと某メーカーが某OSメーカーに大量に試験環境を供与した結果として、
その某メーカーでは問題の起きない問題が生じてしまった話やら、
ちょっと昔だとバグを直したバージョンのセカンドソースを
提供したらバグがないことが問題になって売れなかった話を思い出したり。
ステッピングを変更するにもマイクロコードを更新するにも時間が25週では
とても足りないと思われるのでMSRの規定値を変更してごまかしたのでは。苦笑 >>150
あと、確かにSMT有りの機種でもテストすればなお確証が得られると思う
しかし自分はもう購入資金が無いので他の1725以降購入/RMAした人に託すしかない
「手持ちの機材で確認できる限りは」という但し書きをしておいた方が良かったかな 今すぐ売れてなさそうなお店でRyzen7買えば前ロット手にはいるんじゃね？
>>147
それなりに言い訳は作らなければならなくって、
問い合わせ対応ですら時間は食うのでそれなりにマージンは取らなきゃなくなるよー
何しろ日本市場が小さすぎて在庫リスクがひどいのに検品対応となると元が取れないかと
>>148
外装から見える形でCPUは売っているので解読が済んだ後は装着前写真撮影推奨
>>150
Linux 4.8.0でなどの条件を足していくとSMT関係なくなる。 >>156 のいう通り頻度は落ちる可能性は高い。
今回のRMA対応はAMD本社側が行っているので、
RMAした時点で代理店保証は消えるが、代理店…何？となってしまった。 可能性はあまり多くないんだよな。
1. 攻めすぎな設定を回避する互換性フラグがそもそも存在した、のでそれを書き込んで出荷
2. 設定が厳しいものをRMAで送っている？これはRAM互換性の向上になっても回避にならない、が回避になっている
に対して、
1. マーケティング上の問題から鎮火のために互換性フラグ立てた
2. ひどい設定を無視するマイクロコードを同バージョンとして書き込んだ
くらいなものかと。
Linux 4.8.0と4.12.xでは議論にするべきでないくらいにはバグ修正あるし
(ずっとIntelな時代が続いていたというのにこれってのは本当にどうなのかと…)、
提案として、Linux 4.8.0をベースに4.12.xに対して"forward port"して
問題が生じる確率が上がるのかどうなのかを試験するというのはどうだろうか？
>>152
それってCPUを直に確認するしか確認の方法はない？ >>166
独占的なのは論外だが商売としては正しい判断だと思いますよ。
もしBIOS, Linuxの対応が遅れているのにその責を問われた際にかかる返品率が1割に達して
その責任をAMD側が取らなかった場合には1.5倍くらいの価格設定としないと死んでしまいます >>159
自分の方は仕込みが終われば時々確認するだけで基本放置だからいいのだけど
そちらはソース69万行等大変さの度合いが違いすぎるので都合の良いペースでどうぞ
技術的な話は勉強にはなるが理解が追いつかない事が多くレスできない事がほとんどで申し訳ない >>169 ギブアンドテイクだと思っているので気になることを
訊いていただければできるだけ真摯にお答えしたいです。 >>171
ｔｈｘ
CPUクーラー変えたいっちゃ変えたいんだけど
製造週の確認のためだけのためだけに外したくない >>174
刻印は5行なのだが(うち、4行目 DIFFUSED IN xxx, 5行目 MADE IN xxx)のうち、
1行目がモデル(YD1x00XXXXXXXX)、2行目が製造週(UA 1xXX PGT|US)、
3行目のSN#はパッケージと合致しているので、3行目からデータが揃えば特定できそうだが、
現状製造週までの逆算はパッケージからはできないのではないかと。 >>176
>ステッピング
発売日の深夜販売で購入した1800Xです(B2まだ出てないよね？) >>146
経過報告
1200+Taichi+マイクロン2400メモリの方
6日+9時間(153時間)を過ぎたがSEGVは発生せず
スクショ
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/hJuXB6t.jpg)
メモリタイミング
(130氏提示タイミングとtRFC・tRDWRだけ少し異なる(メモリの都合))
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/BYqShZi.jpg)
1500X+MSI Mate+Hynix2400メモリWin10Enterprise評価版(CU)
の環境に入れたVMwareWS Pro12.5上でもUbuntu16.04.2LTS(アプデ無)で連続ビルドテストを行った
結果はSMT ON(VM8コア割当)、SMT OFF(VM4コア割当)のどちらも1時間以内にSEGVが発生した
SMT ONのスクショ
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/u2gupcY.jpg)
SMT OFFのスクショ
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/sRZ0EGD.jpg)
メモリタイミング
(130氏提示タイミング)
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/AVghr3d.jpg)
1700+BIOSTAR X370GT5+スペックテック2400メモリ
Win10Enterprise試供版(CU)
の環境に入れたHyper-V上でもUbuntu16.04.2LTS(アプデ無)で連続ビルドテストを行った
1700はSMT OFF&4コア(2+2)に下げてある(1200相当)
結果は1時間以内にSEGVが発生した
スクショ
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/qKKSh0u.jpg)
メモリタイミング
(130氏提示タイミングとtRDRDSCL、tRDWRだけ少し異なる(メモリとM/Bの都合)
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/pGFfKXd.jpg)
まとめると、特に問題が出やすいUnuntu16.04.2LTS(アプデ無)で
・1200相当(4C4T)にした1700(製造週1706)、1500X(製造週1713)(共に発売日購入)は、1時間以内にSEGVが発生する
・1200(製造週1725)は153時間を超えてなおSEGVは発生していない
という事になる
以上から手持ちの個体で確認できる限りは、少なくとも製造週1725以降の市販品は対策されていると考えられる
自分ができるのはここまで
他の機種/個体でも本当に対策されているかはサンプル数が少なすぎるので断言はできない
少なくとも製造週1725以降の個体を購入して持っており試して結果を上げてくれる有志に期待したい
(自分はもう購入資金が無い)
あと「少なくとも製造週1725以降」と表現している点にも注意してほしい
1725より少し前の事例が全く無いので1725以降で確定とは断言できない
もしかするともう少し前の製造週でも対策されている可能性もゼロではない
これも該当する個体を購入して持っており試して結果を上げてくれる有志に期待したい
それからRMA品は市販品と異なる個別対策を施されている可能性もある
(例えば専用治具でのみ変更可能な非公開構成パラメータを変更している等)
なのでRMA品と市販品は区別して考えた方が良いかもしれない
オマケ
Xeon E3-1220 v2(4C4T 3.1GHz IvyBridge)、ECCメモリ6GB(DDR3 1600)搭載の富士通サーバ機TX100S3pでも連続ビルドテストしてみた
Ubuntu16.04.2LTS(アプデ無)を使用(仮想でなく実環境)
24時間回してみたがSEGVは発生せず
MCE、ECCエラーも発生せず
5年以上前に発売されたCPUなのでOS側のバグ出しやパッチ当てがあらかた済んでいるだろうから出る気配は全く無いように感じた
Intelでも出ると時々目にするがSkylakeやKabylakeなら出るのだろうか？
(持ってないし買うつもりも無いので試せないが)
スクショ
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/H28s4dB.jpg)
すげえ6日以上回したのかお疲れさんです
初期のロットになんかしらの問題があるんだろうということと
B1ステッピングだろうから特に手入れしたわけでは無いはずなので何の問題になるのかね
シリコン？
中期のtwitterでは製造段階で作りこみがあまい箇所ができ
そこがAVFSによる電圧削減（による電圧低下）に耐えられないんじゃないかって説があった
それでちょっと疑問だったんだけどSEVG自体はX付きのRyzenでも発生してるの？
1700無印の報告が多いみたいな傾向ってある？
>>177 ごめんなさい。製造週を聞きたかった。B2まだ出ていないです >>181 乙です。なお、Sleep復帰問題はfast startup無効化で解決
差分読みの結果をどうしたものか。
Linux Kernel 4.13.xに4.8.0のバグ修正を巻き戻したものと、
4.13.x + 思いつく限りのパッチ適用カーネルでも公開すればいいのかな。
4.8->4.11あたりのbug fixはIntelで問題を起こすから修正されたものとの認識
Linuxはこの数年、動く程度にしかAMD意識してないだろ
Intelで問題が起きると言ってもLinuxへのIntelの貢献は
AMDと違ってガチなので複数ソケットで起きるとかそういったミスが洗い出されているような
RyzenのつらいところはLast Level CacheがL3ではなくCCX*2なのに、
それを何とかInfinity Fabricで調停しきろうとしているのでOS側サポートがほしくなるところ
まるでYonah〜Kentsfieldの頃の地雷を踏みまくっている気分
Windowsで問題が起きないのは未だにx86(32bit)サポートをWindows7で続けていて
その関係で保守的に書かれたコードがこの問題を回避する最もわかりやすい策だからだろうな
>>184
C-Stateの影響仮説はあるのだけれども、それを言い出すと
電力削減速度に追いつかない電源問題が出てくるので問題がCPU単体でなくなる気が。
これを含めてRMAに応じるっていうのだからすごいなーとも思う こちらの環境も12週でSPD読みしたら問題起きなくなってしまった。なので、
今から問題を起こすためには基本的なRAMのパラメータから壊さなければという。
Threadripperで起きないのは何となく理解ができるのだけれども
おれのryzenもsegvしまくるのでRMAしたいんだが、どこでどうやるんだ？
>>188
前スレの事例
サポートのメールフォームは多分これ
Online Service Request
http://support.amd.com/en-us/contact/email-form
もちろん英語だが、機械翻訳(日本語→英語)でも良いと思う
「私はRyzenをLinuxで使用している。しかし並列ビルドを行うと時々SEGVが出る。どうすれば良いか？」みたいな英語に変換されやすそうな文章にしておけば多分通じるだろう。
(日本語も選べるようだが日本法人に行ってしまい話が通じない可能性がある？経験者の情報求む)
【エラッタ？】Ryzen SEGV検証Part.4【おま環】 [無断転載禁止]©2ch.net･
http://egg.2ch.net/test/read.cgi/jisaku/1500079362/
695 名前:Socket774 (ﾜｯﾁｮｲ 57ec-ZVm3) [sage] :2017/08/04(金) 12:36:46.53 ID:GEuJx9ft0
問い合わせたら、完全に同一の構成で24時間試験して送り返すとの申し出が。
非常にスムーズなやり取りと真摯な姿勢が感じられる。
1ヵ月前のレスポンスの悪さは一体何だったんだろう…
697 名前:Socket774 (ﾜｯﾁｮｲ 57ec-ZVm3) [sage] :2017/08/04(金) 12:59:04.84 ID:GEuJx9ft0
>>696
米AMDに対して詳細な情報を記載して送ったらさくっと返事来た。
結果的にRMAの形にはなる。FedEx着払いで試験は向こうが24時間回すとのこと
699 名前:Socket774 (ﾜｯﾁｮｲ 57ec-ZVm3) [sage] :2017/08/04(金) 13:09:31.22 ID:GEuJx9ft0
>>698サポートにメールした。
戻ってきてからこちらも試験して報告するよ。
1週間くらいかかるかもだが待っててくれ。 taichiにagesa1006bのBIOSきてるね
前スレ>>7のUSBメモリに焼いたISO起動してスクリプト実行、ってのをやってるんだけど、
これSEGV起きたらそれっぽいメッセージ吐いて停止するでおｋですか？ それともwarningの海を
眺めてないと駄目？ あと1回目に14ループ程度でフリーズ(30分以上進展なし)状態になって、
Ctrl+Cで停止させたんだけどしたんだけどこれもSEGV起こしたことが疑われますか？ >>195
その設定はどうやって変更するんでしょうか。
ryzen_segv_testを実行したら、OK:59867,NG:1という微妙な結果にorz >>196
具体的にどういったwarningが出ているのかコピペしていただければ
.configのCONFIG_FRAME_WARNが小さいのではないかと推測
なお、Linuxの正式サポートは表明されていないので16.04など自殺行為かと ryzen_segvなんちゃらはロックスピナーと呼ばれているあれ？2ch検索するだけでアレなのだが
>>196
このスレでは例のアレはやらない方がいいという事らしい
試すなら検証してくれた人達と同様カーネルビルドした方がいいと思うよ 例のアレは最低限FreeBSDの開発者たちのパッチを取り入れてから配布するべきなのでは
どう考えているのか知らないが、一部のウィルス検知ソフトで弾かれるらしいしどうなってるのやら
あいつマジもんの開発者だったの
ハードの知識疎いくせに恥ずかしくないのかな
なんの仕事にも繋がらない2ch知識でいきがって恥ずかしいやつだなお前
褒めるべきときは褒めろよ
>>197
あ、すいません。自分が書いたWarningは、これ
https://egg.2ch.net/test/read.cgi/jisaku/1500079362/7
の実行中に出続ける「snprintfで境界ハミんぞ」等の出力で
ありまして、SEGVが出た時のメッセージはそれに流されちゃう
のか、それとも停止してくれるのかをお聞きしたかったのです。
一度起きた変な事象の際は、特段のWarning無しにスクリプトが
無反応になりました。
>>199,201
先程BIOSを最新にして(Asus PRIME X370-PRO 0511からのBIOS
再挑戦したところ OK:32776,NG:1 でした。うーんこの…。
気にしなくていいんでしょうか。 × 0511からのBIOS
○ 0511から0810
>>209
cc1,asが生きている状態でfutexが刺さってデッドロックして止まっていたならUbuntu16.04のバグ踏んだとしか (´・ω・｀)おじちゃんたちおやしょくのじゅんびは？
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/zSsqpxYh.jpg)
>>192
AGESA 1.0.0.6bの修正内容が不明だったので様子見していたが、マザースレの下記書き込みのソース(phoronixの記事)のタイトルが
AGESA 1.0.0.6b Might Fix The Ryzen Linux Performance Marginality Problem
なのでSEGV対応されたようだ
Microcode Verは他で調べた限りでは8001129に上がっている模様(1.0.0.6と1.0.0.6aは8001126)
現状手持ちで1.0.0.6bが使えるのはTaichiだけなので、近々1700と1500Xに載せ換えて試してみたいと思う
【AMD】AM4マザーボード総合 Part38【Ryzen】 [無断転載禁止]©2ch.net
http://egg.2ch.net/test/read.cgi/jisaku/1504888332/
162 名前:Socket774 (ﾜｯﾁｮｲ 2bec-SGtB) [sage] :2017/09/14(木) 21:27:52.50 ID:A0NHn0920
>>154
https://www.phoronix.com/scan.php?page=news_item&px=AGESA-1.0.0.6b-Update
Linux関連のFixみたいね。関係ないけれど念のため上げといた。 >>186
スリープ復帰問題、解決して何より
ところでそれ絡みのLinuxを実環境で動かすのは危ない件はどうなんでしょう？ オマケ
BristolRidge(A10-9700E)を入手したので、>>179 の環境に入れてSEGV出るか試してみた
結果は5日(120時間)回しても発生せず
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/PihKp29.jpg)
(タスクマネージャの表示が変なのはモニタが1360x768で無理矢理収めたため)
メモリタイミングはデフォルト(一部Ryzenと異なるパラメータがあり、勉強不足でよく分からずデフォルトのままにした)
必要ならUEFIのスクショアップします
製造週(と思われるもの)は1721
売れ残りの在庫処分と思いきや、わざわざ最近になって製造し直しているのは気になる所
(Ryzen同様SEGV対策した可能性あり？)
![【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]©2ch.net ->画像>28枚](https://rz.anime-tube.win/pic.php?http://imgur.com/1LJOHeC.jpg)
>>193
遅レスだが日本AMDでRMA対応してもらえたという報告は見たことは無い
日本AMDにできるかどうか問い合わせてみるしかないと思う
(多分ダメと思うが。スレチなので詳しくは書かないがThreadripperスレを見ると理由が分かると思う) Bristol RidgeはもともとZenコアじゃなくてEscavatorコア（つまりはBulldozerの譜系）だから、それこそ問題となったuOPキャッシュとか無いのでSEGVしないと思う
したらしたで大問題だな
>>218
FXでも発生事例がある(過去スレ参照)のと、メモコン周りが怪しいのは分かっているので、
Ryzenのメモコンの習作であろうBristolRidgeのメモコンも同じ問題を抱えている可能性があるのでは？と考えてやってみたまで
RyzenのuOpCacheは自分の所ではOFFにしてもSEGV出るからuOpCacheの有無はあまり関係ない(ONの場合は結果的にuOpCacheの誤動作という形で見えやすかった)のでは？と考えている >>218
uOPキャッシュがエラー吐くからと言ってuOPキャッシュが悪いとは限らない >>223
休日に張り付いて荒らしとかミジメな奴
まさにねちねち重箱の隅野郎の本領発揮
エレクトロマイグレーションも知らないお前の素人「未満」の頭ではそれが原因に見えるんだろうな
そう思ってれば？ >>225
過去スレの書込
ID:UeRxpUXX はお前だ
「素人の解析ごっこ」なんて使うのはお前だけだからな
ID:jZaZEVKA が言ってる事はエレクトロマイグレーションなのは素人目に見ても明らかなのに「L2ってすり減って性能が落ちるのか」なんて素人でも言わないような事を言う有様
素人「未満」の事しか言えない奴が自分を棚に上げて「素人の解析ごっこ」などとよく言えたものだ
さらに一ヶ月程度前の自分の書込も覚えてない位、頭の中が中身のない重箱と同じで空っぽ
そもそもAMDから対策含めた公式発表があって1ヶ月以上経った現時点で原因追求してる人なんて一人も居ないのに「まだ原因がわからないのか」とか誰に向かって言ってるんだか
トンチンカンなのはお前の方だ
スレチは失せろやクソ荒らし
【エラッタ】Ryzen SEGV問題 Part.4【AMD】 [無断転載禁止]©2ch.net･
http://egg.2ch.net/test/read.cgi/jisaku/1503832805/
783 名前:Socket774 [sage] :2017/08/08(火) 12:28:51.14 ID:jZaZEVKA
Xeonだって2年経ったらL2すり減って性能だだ下がりしても
インテル呼びつけてタダで交換させているけど誰も問題にしないだろう
個別交換でいいんだよ直らないのと爆発や融解するのはヤバイけどさ
785 名前:Socket774 [sage] :2017/08/08(火) 12:36:36.15 ID:UeRxpUXX
L2ってすり減って性能が落ちるのか
795 名前:Socket774 [sage] :2017/08/08(火) 17:39:38.04 ID:UeRxpUXX
素人の解析ごっこ、お疲れさまでした >>228
>>229
複数回線まで使って人格攻撃とはよっぽど悔しいのか？素人未満のクズ野郎
技術的な内容で反論してみろや
スレに何の益ももたらさない荒らしは失せろ 166
168
【エラッタ】Ryzen SEGV問題 Part.4【AMD】 [無断転載禁止]©2ch.net･
http://egg.2ch.net/test/read.cgi/jisaku/1503832805/
165 名前:Socket774 [sage] :2017/09/16(土) 22:09:20.71 ID:jNrY/nwd
これが本当に問題になるようなやつは
無理して人と違うことやってる連中だけだって察した
166 名前:Socket774 [sage] :2017/09/16(土) 22:39:30.16 ID:7r/0wgOi
並行コンパイルはそこまで特殊じゃない
167 名前:Socket774 [sage] :2017/09/16(土) 22:50:25.68 ID:bsKYvKR+
>>166
わざわざ数あるOSからエラーを吐く物をつかうんだよね
168 名前:Socket774 [sage] :2017/09/16(土) 22:51:42.41 ID:vpwCDnk7
わざわざ数あるCPUからエラーを吐く物をつかうんだよね
169 名前:Socket774 [sage] :2017/09/17(日) 01:39:16.61 ID:Sn2ljbXk
そうだね。IntelのCPUもだね。 >>230
別人だよ
頭茹ですぎで妄想で怒りオナニーしてるよ >>232
並行コンパイルって書いたのは俺
結果論だけど、✕✕信者とか言うのでないのはわかるでしょ 何にせよ解決済の話。初期ロットが手元にあって特殊な使い方が
したい人は、発生を確認した上でRMAしたら良いんでない？
エンコしたら時々動画が化けるんだが、なんでだろ。
再度やると同じ設定でならない
Intelに刺してエラーでないメモリをRyzenにさしたらエラーがでた、memtest86
相性かな。
何時間もPC起動してるわけにいかなくて自分ではまだ試してないけど
AGESA1.0.0.6bだとSEGVしなくなったのかな
ASUS A320M-KがAGESA1.0.0.7のBIOSを公開したけど
SEGV試した人いる?
今からRMA申請しても年内に届かないよね
来年RMAするか
Ryzen 1800XでもSEGVした。
RMAしてほしいって連絡したけど返事が来ない。
年末だからかな
リテールクーラー以外使ってる場合はRMA対応してもらえないとかある？
