【エラッタ？】Ryzen SEGV検証Part.4【おま環】 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
!extend:on:vvvvv:1000:512
↑を2行冒頭に書いて下さい。(1行分は消えて表示されません)
次スレは>>960を目処に。重複防止の為、宣言してからスレ立てをお願いします。
前スレ：
【エラッタ】Ryzen SEGV問題 Part.2【AMD】
http://egg.2ch.net/test/read.cgi/jisaku/1498476311/
参考リンク：
gcc segmentation faults on Ryzen / Linux
https://community.amd.com/thread/215773
Ryzenにまつわる2つの問題 - 覚書
http://satoru-takeuchi.hatenablog.com/entry/2017/04/24/135914
日記 (2017 年 6 月下旬) - hdk のページ
http://www.e-hdk.com/diary/d201706c.html
GitHub - hayamdk/ryzen_segv_test: RYZEN SEGV test code
https://github.com/hayamdk/ryzen_segv_test
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured 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更新してないとかは問題外。
そういや、電源のコイルが容量抜けしてコンデンサ鳴きしてるやつだと何やっても安定しなかったな、今は交換したけど。
※電源分解して耳にシリコンチューブ当てて聴診器変わりにして鳴いてる部品を特定
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 563+1 ：Socket774 (ﾜｯﾁｮｲ 17ea-u6mz) [sage] ：2017/07/11(火) 12:09:26.06 ID:O/1RDMq30 [PC]
メモリの信頼性云々はこれの事を言ってる模様
Row Hammer問題
プロセス微細化に伴い無視できなくなってきたデータ化け問題
(後藤の記事)
http://pc.watch.impress.co.jp/docs/column/kaigai/678795.html
Rowhammer問題私的まとめ
Google作成のRow Hammerテストツールの事が書いてある
http://blog.daionet.gr.jp/knok/2015/03/13/rowhammer/
テストツールは後でやってみよう
丁度この頃はPCパーツ殆ど買ってないから知らんかったわ 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 >>1
なんで6/30に終わって新しい情報が無いスレが前スレなんだよ
情報遮断か？
【エラッタ？】Ryzen SEGV検証Part.3【おま環？】 [無断転載禁止]©2ch.net
http://egg.2ch.net/test/read.cgi/jisaku/1498815128/
【エラッタ】Ryzen SEGV問題 Part.3【AMD】 [無断転載禁止]©2ch.net
http://egg.2ch.net/test/read.cgi/jisaku/1498824064/ >>8
【エラッタ？】Ryzen SEGV検証Part.3【おま環？】 [無断転載禁止]©2ch.net
http://egg.2ch.net/test/read.cgi/jisaku/1498815128/
は重複隔離スレだろ。@satoru_takeuchiに対するアムド信者の批判多すぎてゴミスレ ryzen_segv_testは486や初代Pentiumと戦ってるのか？
>>94
https://github.com/hayamdk/ryzen_segv_test/
これ、Intelも散々バグってたやつでしょ。Pentium III以降では動作してもモデル依存だぞ？
あまりにもPentium4で問題になったので非推奨ってはっきり書いてあるし、
自己書き換えですら実行中のページ (特に実行中の2KB内) に書くのは避けろってIntelも言っている。
要するに、この10年以上そんなコードを吐くケースなんてないんだよ。
今では裏で例外飛ばしてMicrocode対応するのが普通なんだが…
初代Pentiumと比較してどの程度落ちるのかの試験しているの？
今どきのIntelで落ちるのもモデル依存と言われている以上当たり前だろ。
Intel® 64 and IA-32 Architectures Software Developer’s Manual (Order Number: 325462-060US)
8.1.3 Handling Self- and Cross-Modifying Code
...
IA-32 processors exhibit model-specific behavior when executing cross-modifying code,
depending upon how far ahead of the executing processors current execution pointer the code has been modified.
訳)
IA-32 プロセッサは相互変更コードを実行するときにモデル固有の挙動を示す。
挙動は実行中のプロセッサの現在の実行ポインタからどれだけ離れたコードが変更されたかに依存する。 >>9
@satoru_takeuchiは土下座確定なのに往生際悪すぎだから叩かれるは仕方なし 1800X、C6H、M378A1K43BB2-CRCで
自動設定だとSPDより速い15-15-15-36、電圧も高めの1.35Vに設定されてカーネルビルド数回でSEGVが発生したけど
SPDどおりの17-17-17-39、1.2Vに手動設定したら250回を超えても発生してない
メモリ周りの安定性の確認にちょうどいい感じ Cross-Modifying Codeにおける問題と回避策を発見したので
再現コード書いてAMDに報告しておくわ。ただ、>>11 の通り通常は問題ない
本当に問題があるのであればChromeのJavaScriptのJITで落ちまくってるわｗ >>13
Ryzen Timing Checker のスクリーンショットもらえるとうれしい… この流れ楽しいな。ryzen_segv_test はしばらく眺めていようっと。笑
https://twitter.com/satoru_takeuchi/status/886119579075792896
> @homuh0mu AMDフォーラムでryzen_segv_testが話題になっています。AMDのエンジニアにも存在が知れてそうな雰囲気。ご参考まで。
私はこのプログラムの内容を理解できていないので静観してるだけです。すいません
https://twitter.com/homuh0mu/status/886149374450909184
> ありがとうございます。存じております。ひとまずこちらとしても聞かれたことはできるだけ答え、あとは見守ることしかできないですね。
話題になっています = 2 posts しかないユーザー
https://community.amd.com/people/cl0p3z/activity >>15
自動設定のとき
http://imgur.com/0v7UnXs
手動で17-17-17-39、1.20Vに設定したとき
(tRC、tRDWR、tRDDATAはAutoのままだがタイミングが変わってる)
http://imgur.com/prUDDQw
SPD
http://imgur.com/4sNh2hi >>11
意図的だな。続きの文章は
To write cross-modifying code and ensure that it is compliant with current and future versions of the IA-32 architecture,
the following processor synchronization algorithm must be implemented:
現行と将来の IA-32 アーキテクチャに準拠する cross-modifyin コードを書くには次の同期アルゴリズムを実装する必要がある: >>13
そういや大昔メモリテストにカーネルビルドが良いって話があったな
signal11が出なきゃokみたいな >>22
2001年の記録発見
ttp://archive.linux.or.jp/JF/JFdocs/GCC-SIG11-FAQ.txt >>21
わかってないなあ。
最初の Intel Architecture Software Developer's Manual に何も書いてなかったから
Intelは延々とErratumを記述する羽目になっていて、今は動いているからこれってだけなんだぜ？
こんな効率の悪い方法やーめたってなった瞬間に続きの前の文章が「仕様」になるわけだ。
直せないプロセッサがあったために、
> 自己書き換えですら実行中のページ (特に実行中の2KB内) に書くのは避けろってIntelも言っている。
と予防線張ってるし。笑
Google で Intel XMC Errata site:www.intel.com/content/dam と入れて検索してみな
gcc の SEGV と全く関係のない ryzen_segv_test に矛先が向けられてしまった
海外フォーラム勢がいつまで我慢できるか、矛先を変えた誰かさんがどう出るか見ものですよ 影響が大きいのはtRASかな
tRASだけ緩めたら3200にOCしても今のところエラーは出てない
(Autoで39に設定されたのを42に変更)
tRASを緩めなくてもmemtest86は通ってたからmemtest86はテストとして不十分な感じが
多分、memtest86はメモリセルのテストにはなってもアクセスタイミングのテストにはなってない >>25
memtest86 は各ダイの試験には十分だが、チャネルやバンクを切り替える試験には十分ではないんだろうね >>19
tRFC2とtRFC4の値いくらですか？ >>23
これ面白いね
同じ問題かはわからないけどはっきりとタイミングで起きると書いてるし
今回の事象と性質がよく似ている >>27
>>19 ではないが、tRFC 350(ns) ということは最近の DDR4 8Gb チップかと。
4Gb tRFC1 >= 260ns, tRFC2 >= 160ns, tRFC4 >= 110ns
8Gb tRFC1 >= 350ns, tRFC2 >= 260ns, tRFC4 >= 160ns
16Gb tRFC1 >= 550ns, tRFC2 >= 350ns, tRFC4 >= 260ns
CLK換算だと (DDR4-2400)
4Gb tRFC1 >= 312, tRFC2 >= 192, tRFC4 >= 132
8Gb tRFC1 >= 420, tRFC2 >= 312, tRFC4 >= 192
16Gb tRFC1 >= 660, tRFC2 >= 420, tRFC4 >= 312
参考) http://egg.2ch.net/test/read.cgi/jisaku/1498815128/978 ryze_segv_test 面白すぎだな。コンパイラ オプション次第でどうにでもなる
Concurrency 1, Loop -1 (無限) で 4時間近く走ってる。
http://www.gazo.cc/up/249035.png >>32
>>19を見ないで答えてるのかもしれないけど>>19ではtRFCが421だったから
2倍4倍も313、193になってるのかなって思って質問しただけだよ
RyzenTimingCheckerで350.833って表示されてるの紛らわしいだけだった
Samsungの仕様書に350nsで書いてたからtRFC決めるときにCLKを100以上で設定してるんだな
って事にして納得した UEFI上ではTrfcが312、192、132で表示されるのはどういうことだろう？
http://imgur.com/4ZgnfvN >>36 すまん、ID 見てなかった orz 情報ありがとう！
>>37
>>29 に書いたが tRFC はデータシートでは ns 表記なので、クロック数に換算するために
DDR4-2166 なら x1.033, DDR4-2400 なら x1.2, DDR4-2666 なら x1.333 して切り上げする
最低値を守らないと周波数を上げた際に動作が不安定になる
http://egg.2ch.net/test/read.cgi/jisaku/1498815128/978-979,989 まとめ
tCL, tRCDRD, tRCDWR, tRP, tRAS, tRC はいわゆるスピードグレード
tCL-tRCD-tRP-tRAS 表記で 16-16-16-39 ってのがそれ。
一般的には tRCDRD>=tRCDWR, tRC>=tRAS+tRPの関係式
tRRD_S, tRRD_L, tFAW, tWTR_S, tWTR_L, tWR, tRTP, tCWL (tWCL) がメモリチップ依存。一般的には
DDR4-2133 : tRRD_S >= 4, tRRD_L >=4, tFAW >= 23, tWTR_S >= 3, tWTR_L >= 8, tWR >= 16, tRTP >= 8, tCKE >= 6
DDR4-2400 : tRRD_S >= 5, tRRD_L >=5, tFAW >= 26, tWTR_S >= 3, tWTR_L >= 9, tWR >= 18, tRTP >= 9, tCKE >= 6
tCWL = 11 or 14 (DDR4-2133), 12 or 16 (DDR4-2400)
飛びとびなのは DRAMに設定できる値がフラグなため
安定させたければ増やすべき。
tRFC, tRFC2, tRFC4 もメモリ依存なのだがこいつは世代によって大きく変わる。最近の最小値は
DDR4-2133 : tRFC >= 587, tRFC2 >= 374, tRFC2 >= 278
DDR4-2400 : tRFC >= 660, tRFC2 >= 420, tRFC2 >= 312
Trdwr, Twrrd, TrdrdScL, TwrwrScL, TwrwrSc, TwrwrSd, TwrwrDd, TrdrdSc, TrdrdSd, TrdrdDd, CR が
メモリコントローラの性能とメモリの性能、周波数で変わってくる
Trcpage は APU 環境。AM4 には関係ない >>38
ナノ秒とクロック数の換算はわかるんだけど
Ryzen Timing Checkerでは>>19のように421と表示されるのが
UEFIでは>>37のように312と表示されるのがわからないんだ >>39
Ryzen Timing Checker は CPU が認識している値を表示しているはず…
となると、BIOS の設定が効いていないか BIOS の表示が間違っているってことになる その他の理由としては、起動時に何度かトレーニングかけるので間に合わねーとなると BIOS が自動的に値を上げる。 BIOS で 543 とか適当に大きな値を設定して、それでも反映されなかったらトレーニング結果だな お。メモリの設定きつくしていたら不安定になって MCE で再起動かかった！
これで詫び石ゲットできる権利付与？ >>44
個別対応頑張ればいけんじゃね？
まだ対応してるか知らんけど 教えてもらうか。
> 詫び石欲しい方、やり方教えます from sat@Ryzen SEGVエヴァンジェリスト
https://twitter.com/satoru_takeuchi/status/875502616347721728
でも、私はlinuxカーネル開発者じゃないのですが大丈夫でしょうか… >>46
これ詐欺の幇助とか教唆とかになる可能性ある？ >>47
この辺？
・偽計業務妨害罪・威力業務妨害罪
3年以下の懲役又は50万円以下の罰金
・詐欺利得罪
10年以下の懲役
・強要罪
3年以下の懲役 海外ユーザーのにryzen_segv_testが放った地獄
http://egg.2ch.net/test/read.cgi/jisaku/1498824064/248-255n
https://community.amd.com/thread/215773?start=203
> I used to think there were two issues. Now I'm thinking it's three.
> 私は問題は2つあると思っていたが、今はそれが3つになったと考えている。 結局今はどういう状態なんですかね？
スレをしばらく追っかけたんですが素人なんで良く分かりませんでした… Segmentation Faultが発生するのはメモリのアクセスタイミングの設定が適切でないとき
自動設定では適切に設定されないことがあるので、その場合は手動設定が必要 流れのまとめとしては
QVLにも載っていないRAMをBIOS更新もかけずに使用 -> 落ちる
->Errataだと決めつけて海外フォーラムに放火
->つたない英語でスルーされるもさらに日本人数名が放火に参戦
->自称分析できる人、自称再現コード書ける人が明後日なことをやりはじめる
->放火している界隈がTwitterで大騒ぎ
->対応していないメモリで確かにSEGV起きることを確認
->パラメータ見なおして再現しなくなった…えっ？
NEW!!
->ryzen_segv_test（）で問題が増えたよと海外フォーラムがうんざり
->Errataだと決めつけていたやつが逃げようとしている
->メモリパラメータ見直すとSEGVどころかMCEも再現可能なことが判明
->詫び石（）もらおうぜ！
> 詫び石欲しい方、やり方教えます from sat@Ryzen SEGVエヴァンジェリスト
https://twitter.com/satoru_takeuchi/status/875502616347721728 > - Ryzen SEGV Battleとお祭り騒ぎしながらAMDとやりとりしてる私
> - BitVisorなどて色々解析してるえいらくさん
> - ryzen_segv_testを作られたかた
>
> の間に統一した意思なんて無いよ。各々自分の目的のために試行錯誤してるだけ
https://twitter.com/satoru_takeuchi/status/886712554931724290
#Ryzen_SEGV_Battle だの、海外フォーラムに放火したのお前だろうが。あ…主犯宣言？ 火をつけたんだし、目的持ってやってたんじゃないんかよ >>52
あれ、今はBIOSアップデートと対応してるメモリなら問題起きないってこと？
ツイッターだとまだ起きてる人がいると思ったんだけど… AGESAで定義されていないメモリパラメータについてはM/Bによって変わるんだし
M/Bの種類によっては今でも起きる組み合わせはあると思うが
エラーテストプログラムとしては優秀だと思う たかが祭りくらいで犯罪になるわけねーだろ
https://twitter.com/search?f=tweets&;vertical=default&q=SEGV%20-rioriost&l=ja&src=typd
買い控えも起きていないし、ユーザーのクレームも飛んでいないだろ？匿名は黙ってろや 検証するやつがなぜか煽り気味だから余計に印象が悪い 原因の一端が判明64バイトズレると情報を捻じ曲げて拡散させたまとめブログとかのほうが捕まるだろうな それは別に間違ってはないのでは？
解析者PCのハード的な欠陥や相性が払しょくできてないから2chでは叩かれてるだけで >>62
64バイトズレるパターンがあるなぁ原因わかんないし他にもパターンあるしよくわからないからもっと調査だ
というブログ内容からどうしてあんなまとめ方されたんですかね まとめブログさんはCore-Xの高発熱についてのコメント残せば速攻消すのに
SEGVはRyzenに対して悪意ある纏め方するあたり、資金源からの指示出てるのがよくわかるね SuperCon2000優勝/ICPC2004,2005アジア大会優勝/ICFPC2010優勝/第一回京都大学総長賞程度で
「linuxカーネル開発者」であらせられる @satoru_takeuchi様に疑義を呈するとは何たる無礼
> それは知っているんですが、だとするとなおのことロジックあんま関係なくて、タイミングの問題の方が疑わしい気がしますけれども。
https://twitter.com/tanakh/status/886512967381958656 俺環のようにopcache無効でエラー出なくなる不良個体の可能性のある場合もあるから
一概にメモリのせいにするのはどうかと思うけど
まずはメモリの設定を疑うべきだな
Ryzenのメモコンがピーキー過ぎるのが原因なんだからAMDはここら辺しっかり説明してほしい >>66
エラー出るってLinuxカーネルビルドの話？ >>67
カーネルビルドも例のヤツも両方出るよ
Ubuntu16.04だとダメなのかと思ったけどopcache無効でエラー出なくなったから
俺環だとopcasheなんだと思った
けどRMA面倒くさいからこのまま使うかと思ってるｗ >>68 例のやつは…自称作者また出てこないかな
Trdwr 9, Twrrd 1, TrdrdScL 3, TwrwrScL 3, TwrwrSc 1, TwrwrSd 6, TwrwrDd 6, TrdrdSc 1, TrdrdSd 4, TrdrdDd 4, CR 2
でもカーネルビルドだめなら、コントローラー怪しいな。
この設定まで緩めなきゃならんのはコントローラーのチューニング甘すぎる感ひどいが…
やはり PRO版のために選別中なのかねえ？ 誤) Trdwr 9, Twrrd 1, TrdrdScL 3, TwrwrScL 3, TwrwrSc 1, TwrwrSd 6, TwrwrDd 6, TrdrdSc 1, TrdrdSd 4, TrdrdDd 4, CR 2
正) Trdwr 9, Twrrd 3, TrdrdScL 3, TwrwrScL 3, TwrwrSc 1, TwrwrSd 6, TwrwrDd 6, TrdrdSc 1, TrdrdSd 4, TrdrdDd 4, CR 2 OpCache設定と一緒に書き換わる設定箇所がおかしい説
MBのBIOS設計によるけど >>72
それな、MSR の内容が BIOSによって微妙に違うらしいことは64バイトのblog読んでいて思った。
BKDG 17hが出ないことには AGESA 1.0.0.6にもどんなワークアラウンドが設定できるのかわからん…
Ryzen Timing Checkerの作者はどうやって MSRの値と bit範囲を知れたのだろうか amdの調査が遅すぎ。てっきり内部では解決済みかと思っていたが、いまだにフォーラムで報告された電圧のワークアラウンド試せと言ってきてる。 >>69,70
メモリのタイミングも各種電圧も総当たりで試したけどダメだったんだよ
正直、タイミングで直るなら直ってもらいたかった・・・ >>74
フォーラムの報告内容、2chのクオリティよりひどくね？
サブパラメータの報告なんて見たことがない。OC扱い対応されてるんじゃないの？
こりゃエスパーでもない限りは電圧上げてみろとしか言いようがないな。
https://community.amd.com/people/sat/activity どう考えてもメモリタイミングいじって治るような問題じゃないだろ。 >>77
メモリタイミングいじって治したおれはどうすれば…。
さらに言うとメモリタイミングきつくしていってMCE吐かせることにすら成功しているわけで
メモリーコントローラーの実装きつすぎだろってのに異論はないが、
メモリーコントローラーの設定見直さないで騒ぐのはどうなのよって立場 >>77
と思うじゃん?
カーネルビルドでSEGV起こすケースを起こさない環境で再現しようとするとメモリのタイミングをヤバ目にセットするのが一番手っ取り早かったわ
コアとかキャッシュ怪しくしてもGPとか即落ちになって再現しない まだsat本人と周りの馬鹿が出てきてるのか？
言い訳苦しすぎなんだよ >>81
彼は逃げに入ってるだろ。 >>49 に押し付けて >>54 検証してる人の姿勢自体が疑惑に晒されてんだから検証にならん 面白そうだからウチのAtomちゃんでそのコンパイル動かしてもいいけど何にも知らないから教えてくれればやるけど･･･ @satoru_takeuchi
こいつもうダメだな
また意味わからん事言いだしてるわ
ただの構ってちゃんか？
https://twitter.com/satoru_takeuchi/status/886786078908104704
さっさと土下座しとけよ もうこれハードウェアの情報伏せてるのは故意だよ
誰か訴えてくれないかな >>86
@satoru_takeuchiは間違いなく完全に信用されなくなるだろうな
こんだけモラルと責任感欠如してると仕事無くすわ
自業自得だかな 64bitズレ検証君は単なるハードウェア側の知識不足なだけっぽいから
丁寧に伝えてあげれば改善しそうではあるけれども 何で不具合報告したユーザが叩かれてるの
そんなおかしな振る舞いしてないと思うんだけど、何か変だった？ >>89
初期BIOSで永遠とやってる馬鹿もいたよなｗ
BIOS更新しないわ環境変えないわのEIRAKUとかいうマゾ
こいつは一体何と戦ってるんだ？ 別にEIRAKU氏はAMDに凸ってるわけじゃないし
AMDが推奨してることやってない自覚はあって自分の興味のために調べてるだけでは なんにせよ、Ryzenは対応メモリ買ってきてポン刺ししただけでは安心出来ず、
細かいタイミング弄ったりしながらgcc回したりして検証しないとマトモに運用できないので、
その手のトラブル解決が好きな暇人以外はまだ買わないが吉ということでおｋ? >>94
おけー
強いて言うとIntel環境でも起きる人は起きるからメーカー製でも買いなよ >>94
対応メモリでゲームするくらいならいいけど、開発やインストール時に全てソースコードからコンパイルする Gentoo Linuxには向いてないだろうな。
そもそもOSの対応が終わってない。ポン刺しでの安定志向ならDDR3世代のIntel使うべき。 >>47
＞これ詐欺の幇助とか教唆とかになる可能性ある？
satとかEIRAKUとかはこれをわざと狙ってるか分かってないで喚いてる
アンチが好きそうなネタで寄って来ると思ってるんだろうな
@rioriost
こういうゴミが現れるわけ
今時こういう輩はモラル疑われる
satは信憑性のない事柄をあたかも事実のように語って言い訳たらたら流し始めてるし何とか問題にしたいようだがすでに無理やりすぎてなｗ
さっさと謝罪しといたほうがいいぞ >>95-96
ふむ、コンシューマ向けのRyzenは、
自作っつーてもトラブル解決楽しみたいわけじゃ無くて
ある程度好きなパーツ組み合わせてLinuxで使いたいみたいな人はお呼びじゃ無いという感じだね
EPYCと対応マザーと動作保障メモリとかで安定するならそれでも良いんだが、まだ入手可能になるまではかかりそうだね デフォルト設定で動作不安定な場合は
電圧とDRAMタイミングの調整を行ってください。
それでもダメたらRMA交換を要求してください。
こんなプラットフォーム、初心者や一般人に売ったらだめだろ。 環境の安定性テストするには凄くいいプログラムなんだと思うぞ
認識してないエラーを見つけ出してくれる >>101
一般人とか初心者がLinuxカーネルビルドとかしねーよ ＞それでもダメたらRMA交換を要求してください。
間違いさがしか？
違うものを混ぜんなよｗ いや、ryzen-segv-testとかいう実ワークロードに全く関係のない
自称テストプログラムは割とどうでも良いです
でもgccが不定期に落ちるほど不安定なのは困る人は、少なくともLinuxユーザーにはそれなりに多いハズ そもそもvolatile修飾に不備があってコンパイラによっては正しくspinlockが機能しない可能性あるプログラムが
本当にCPUのバグだけでエラー出してると思ってるのか、って問題はある 不定期で落ちるって言っても、数千数万に1回だと一般ユーザー的には別に困らんしな……
一発で通したかったらド安定なオプション付ければいいだけだろこの問題って？
鯖でも何でもエラー帰ればクリティカルでも無い限り基本的にリテイクする作り方してるし まあ、現状intel環境に比べてメモリに渋いのは、AMD好きとしても
認めざるをえないところなのかな？ 安定運用目指しておいて定格外にしたりECCメモリ使わないのって論外かと。
でも定格運用して高々1000回のコンパイルで1回コケるといったらそれゴミやん、とは思うけどね
まあ、Stepping上がれば解決してくる問題と思って
それまでは情報収集するしかなさそうかな 自動設定でメモリタイミングが定格外に設定にされてエラーが出たりもしてるので
そういう場合はBIOSの問題 >>98
現状、対応メモリの組み合わせが少ないのは認めざるを得ないでしょ。ポン刺しはDDR4世代ではIntelでも辛いっての。
Linuxがだめなんじゃなくて、古いLinuxにパッチを当てられない、あるいはソースコードから毎回ビルドかけるのが当たり前の Gentoo や Arch みたいな Linux をポン刺しはまだ無理って話。
もっとも、そんなDistributionを選ぶ人は、自分で構成からパッチまで当てることができるのが前提だったのだが、カーネル開発者様であれだからな。
Windowsはバイナリ配布が当たり前だから気にならないだろうね。
同様に、EPYCを動作保証のないメモリで動作させることなんてないでしょ？どういう用途よそれ。話が飛びすぎ。笑 AMDのコミュニティで昇圧推奨みたいな流れになったのも、
BIOSのバージョン上げずにRMAした日本人のせいだっていう…誰とは言わんが >>109
AMD好きってほど偏ってないが、Intel並にあと2nsくらい速く動作してくれると
パフォーマンスが0.1%は上がるので助かる >>113
あんたもここでコソコソ吠えてるんで無くてTwitterで本人たちにリプなり何なりで伝えてやったら？
既にやってたらゴメンよ >>115
@tanakh の声も届かないやつにどうしろと…
私はとあるプロジェクトにソースコードで貢献させていただくのでそれでご勘弁を。 >>117
そっか
何にせよ、この問題を実機使って検証してくれたり、
技術的考察してくれる人達には感謝しか無いんだよね、
自分みたいな結果だけ欲しがるハイエナにとっては。
色んな関係者の話がなんとか噛み合って問題が前進することを身勝手ながら願ってるよ 前スレでuOpcacheを切ったら安定したと書いた者です。データを集めたので共有します
＊まとめ
opcacheを切るだけではUbuntu17.04でNGが出ることがあったのでいろいろ試してみたら、CMOSクリア、インストール直後状態から
・bashパッケージ を upgrade（4.4-2ubuntu1: Tue, 15 Nov 2016 から 4.4-2ubuntu1.1: Tue, 16 May 2017）
（普通に update + dist-upgradeすれば入るやつです）
・Opcache Control を Auto->Disable
でメモリ2400（SPD）、3200（XMP2.0）共に安定しました
＊構成、テスト方法、BIOS設定やRyzenTimingChecker、結果、ログ
https://pastebin.com/FdVDAXeC
テスト結果後半に3200でのテストが目立ちますが、緩めた（つもりの）2400Mセットで失敗したので自環境ではopcache以外による影響は無視できると予想しました
17.04より前はRyzenで使う予定がないので試していません
＊BIOS設定
上記の2400Mセット http://imgur.com/a/Fs3PQ
opcache有効、DRAMタイミングを緩め、最近指示のあるらしいCPU、SoC、メモリ電圧を盛ったつもりの設定です。ダメでしたが・・・
opcache無効にしても許容範囲かなあとは思ってはいるのですが、設定に関してアドバイスありましたらお願いします
＊おまけ opcacheの効果
Cinebench : 1650 => 1562
FFベンチ : 12066 => 11886 Opcache無効でのパフォーマンスに本人が満足できるならそれでいいと思う
安定させることが主目的だろうし ECCメモリでもLockSpinnerで落ちちゃった件はどう説明する？ >>119
おつ。Micro-op cache切ると浮動小数点演算がつらくなるので、SMTも切ったベンチマークも上げてもらえると嬉しいです。 >>123>>124
double bit errorはecc付きでも修復出来ないんだよ >>119 >>125
時間がかかると思うのでCinebenchだけでもいいので、お願いします。 >>124
エラー出たのは旧BIOSで相性問題踏んでたときの物で、今回のテストではエラー出てない。
あと訂正不能エラー出たときはBSoDするから区別できる。 >>125
そういえばSMT無効化でも改善したケースがあったのを忘れていました
まあ気が向いたらやることにしますか・・・
平均値を取ったわけではないので参考程度に
SMT off
+ opcache on 1168
+ opcache off 1174 絶対に AGESA 1.0.0.6 以前の BIOS で起動しないこと
もしメモリ回りで問題が生じる場合には即座に Micro-op Cache を切ること
詳細はまた連絡します。1ヵ月はかかるかもしれない 下げ忘れた。前スレ >>891 です。
ryzen_segv_test の実行もやめたほうがいいです。
作者が意図した結果は得られていませんが、実際のワークロードとは関係はない一方、
現在のMicrocodeでは深刻な結果をもたらす可能性のあるものが含まれています。
まだ実証コードが完成していないのですが、
これは古いBIOSで意図的に壊したものですね。
https://twitter.com/satoru_takeuchi/status/886574525764075522 Microcode のバージョンは
AGESA 1.0.0.4 0x800111C
AGESA 1.0.0.6 0x8001126
です。BIOS なり /proc/cpuinfo で確認できます。
絶対に AGESA 1.0.0.6 より前の BIOS は使用しないでください。 また、謎なのですが (買うのもだるいな…)、
ASRock X370 Taichi での問題報告が非常に多いのが気になります。 連休中も無茶していた友人Yにこのスレを教えてあげた
もう良いんだよ、10日間良く頑張った。
メーカ指定ハードの一般アプリ使用では過負荷試験でも１度も起きないから…お前は本職に戻れ！ >>134
出先からなのでIDワッチョイ違うのはご容赦を
Taichiなのが気になるなら1800X+MSI_TOMAHAWKか1700+BIOSTAR_X370GTNでも試しましょうか？
1700は別件でRMA中なので明日以降になってしまいますが
Taichi含め上記3システムなら検証コードのプロトタイプを実行してお手伝いもできますよ >>135 本業がハードウェア関連でもあるっていう、な
>>136 ありがとう！お願いするかもしれん
とりあえず、MCE発生と futexが刺さる現象はそれぞれ別のメモリのタイミング設定で再現させられた。
これらは BIOS の更新待ちなのか、これらの問題を認識していないのかよくわからんのでまとめて報告しておくわ
昇圧対応と騒いでいるのは古い BIOS使って高速設定でぶっ壊した人はそりゃ一生 OC扱いせざるを得なくなるだろっていう
一応定格について、
Dual Channel/Dual Rank: 1866 (2133*)
Dual Channel/Single Rank: 2133 (2400*)
Single Channel/Dual Rank: 2400 (2667*)
Single Channel/Single Rank: 2667
*Depending on system & Module Design Twitterのハッシュタグを見てるとハングしてる奴今のところQVL未掲載メモリユーザーしか居ないな
QVL掲載メモリですら2DIMMまでって書かれてる奴があるから未掲載で4DIMM、メモリタイミング手動設定無しとかただの自殺行為だろう この人、いつになったら放火やめるの？
https://twitter.com/satoru_takeuchi/status/886943314649337857
一方で、海外フォーラムではryzen_segv一体何だったの？報告が。
> On all steps of trails I stressed the system with GitHub - hayamdk/ryzen_segv_test: RYZEN SEGV
> test code but never saw even single segfault (tried with gcc-5.4 and gcc-6.3).
> ... (snip) ... but never with the ryzen_segv.
https://community.amd.com/thread/215773?start=237 >>140
文章の一部だけ切り抜くのよくないよ
その直後に"I also tried kill-ryzen.sh but didn't observe any segfault."と書いてある
このスクリプト（https://github.com/suaefar/ryzen-test）はビルドループを回すもの
この報告者の環境では（特にアイドル時に）ランダムにエラーが発生していて、
・別バージョンのカーネル、SMT、ASLRの設定変更を試したが効果なし
・SOCとCPUの電圧を盛っても効果なし
・ビルドループやryzen_segv_testでエラーは確認できない
ので、別のスレッド（https://community.amd.com/message/2808979#comment-2808979）を参考に
・メモリのクロックを上げつつメモリ電圧を盛ったら解決した
という報告 >>141
で？解決したのはアイドル時の他のソフトの話でしょ
> So this configuration (RAM freq. = 2400MHz and DRAM voltage = 1.35V)
> seems to work so far. I haven't experience any problem, error or segfaults/reboots/freezes
> since then (2 days 9:00 hours uptime). I also tested it with the ryzen_segv for one hour
> (compiled with gcc-6.3, the segfault killer) - no any segfault.
アイドル時の問題を解決する前も、した後も、ryzen_segvは何だったの状態なわけだが。 >>141 >>142
他のソフトが安定したのもDDR4-2933をDDR4-2400@1.35Vに落とした落ちだしな。
電圧はさておき、定格に戻しただけじゃねーか。で、ryzen_segv_testは無意味でした ryzen_segv_testなんて再現性確認出来てないのにどんなプログラムなんだよ
自称作成者簡単に説明頼むわ >>142
この報告者は単にビルドループでもryzen_segv_testでも問題が発生しなかった、ということを述べている
ryzen_segv_testに疑問を呈しているような表現は少なくともこの報告者の文章には存在しない
あなたがryzen_segv_testに疑問を抱くのはわかるが、他人の文章の一部を切り出して、不適切なニュアンスで紹介するのはよくないよ
>>143
・テスト中のメモリ設定はオートモード（2133 MHz, 1.2V）
・その後、OCする際、当初2933MHz, 1.35Vにしていたが、ストック状態の一つ上の2400MHzにした
・その際電圧は1.2Vだとブートループになったので1.35V
と書いてある >>134
X370 Taichiでの問題報告が多いのはこれが関係してるのかも
AGESA 1.0.0.6のBIOS(P2.40)から1.0.0.6aのBIOS(P3.00)(7/14公開)に上げたら今までSMT ONでクラッシュしていたゲームベンチが正常に動くようになったそうだ
(ソースは後述)
公式発表がないから変更点は不明なのだがAGESA 1.0.0.6aでSMT周りが変更されている可能性がある
逆に言うと少なくともTaichiの場合P3.00より古いBIOSを使っている人はSMT周りに問題を抱えている状態で使っている可能性が高い事になる
ちなみに困った事に1.0.0.6aもMicrocodeVerが8001126のまま
http://i.imgur.com/pcdQ3sz.jpg
現状確認手段がBIOSの変更履歴しかない
あとASRockは現状X370の4機種用だけしか出ていない
ASUSは結構出ている
MSIはベータ版で出ている模様(確証はないが)
BIOSTARは出てない
Gigabyteは調べてない
https://www.reddit.com/r/Amd/comments/6jpe0o/whats_new_in_agesa_1006a/?utm_source=amp&;utm_medium=comment_list
下から4番目の書込
UDaManFunks• 3d
UEFI 3.0 (1.0.0.6a) for Asrock Taichi fixed the SMT issue I was having with UEFI 2.4 (1.0.0.6).
Basically, running the DX12 AOTS-Escalation benchmark always crashed to desktop when I ran it with SMT enabled. SMT disabled worked fine. On the new UEFI, SMT can be enabled now without it crashing to desktop. 👀
Rock54: Caution(BBR-MD5:1777ba470a0705a8ff6b3177e04ccfb6) >>143
その報告にあるメモリはメーカURLの通りで本来1.35Vの3000MHzなのよ
http://www.corsair.com/ja-jp/vengeance-lpx-32gb-2x16gb-ddr4-dram-3000mhz-c15-memory-kit-black-cmk32gx4m2b3000c15
Technical Specifications
Density: 32GB (2x16GB)
Speed: 3000MHz
Tested Latency: 15-17-17-35
Voltage: 1.35V オーバークロックメモリはあくまでオーバークロックであって、定格ではないかと >>147
Kingston KVR24N17S8/8 
コルセアはチップもその時々でかわるしね
現状2133が定格じゃないの ryzen_segv_testで落ちるCPU
Ryzen
K6-2
Core i3-3220T
Core i7-3770K
Core i7-4790K
Ryzenはgcc5.4.0,6.3で落ちない報告あり
http://egg.2ch.net/test/read.cgi/jisaku/1498824064/240-241n
http://egg.2ch.net/test/read.cgi/jisaku/1498824064/244
GitHubにあるzipは危険だと思う。 >>146
まじかよ…。Microcodeのバージョンが変わらないのはそれはそれで構わないかと
AGESA = Microcode + 起動時ワークアラウンド設定 + メモリ周り設定
海外フォーラムの連中も、BIOSが古くてメモリタイミングおかしい、
Intel用オーバークロック設定が書き込まれたXMPメモリが原因なのがほとんどってことか 今日も詫び石を推奨している。AMDが可哀想になってくる
> みなさん爆発するのは全然いいと思うんだけどサポートリクエストは出すだけだしても損はないと思うけどな。向こうは個別対応するって言ってるし、そっちなら反応もあるし。
> RMAしようって言われたら、今怒ってるみたいに「直ってないやついるぞ。くじ引きは嫌！」って言えばいい
https://twitter.com/satoru_takeuchi/status/887139454212751360 >>147
>>150
satが使ってるこのメモリ、QVL未掲載かつKingstonの同ValueRAMシリーズはQVLに載ってても2DIMMまでのサポートが多いんだよな。
で、satは見事に4DIMM動作って書いてある。
ASUSのIntelマザーに適当に買ったDDR3を4枚刺ししてハングしまくるPCが出来て4枚目抜いたら直った事があるからsatのハングアップはこれが原因じゃねーかな
KingstonのQVL掲載メモリを見るとヒートシンク付きHyper Xばかりで廉価版メモリは申し訳程度のサポートらしい >>154
今のところいいねの数が1だけで悲しいな >>152
Joule570X(Atom T5700) Ubuntu Server 16.04LTS, gcc5.4.0も加えてくれ またずいぶんと分析進んでるな。にちゃんねらー怖い
>>146 の AGESA 1.0.0.6a で私の着目しているものが修正されてたらウケる。
Microcode は変わってないから起こせそうな気はしているのだが。 >>154
誰も爆発なんかしてねーしこいつの指摘は外れてたわけだが
詫びsatまだか？ｗ 正直これ佐村河内とかSTAP細胞みたいな注目を浴びたいがために虚偽を押し通してる感じがするぞ 検品で弾かないといけない個体が出荷されてる時点で大問題 >>165
そーいや富士通ってまだEPYCサーバアナウンスしてねーよな
Xeon Phiは一番先だったのに ASrockのB350シリーズとA320MProに1.0.0.6a来た
A320M(と派生版)はまだ来てないが、近々来そうな気がする マロック先生に便乗して屋号云々と言ってたので独立考えてる可能性もなきにしもあらず >>170
この騒動の始まった後に不労所得が給与所得超えたって書いてたけど土地でも持ってんの？
この所属の給与超える額の不労所得とか単著の印税でも厳しいしかなり不自然なんだが >>165
一回も報告したことないが
最長で68回いったわ今 >>152
おまえネタと事実混同しているぞ>>K6-2 メモリタイミングを適当に上下してみたが再現率が変化しているような気がしない。これを上下させれば確実に再現率に影響するパラメータってどれ？ ひどい流れだな。ここまでくると、もう素直にこのスレにでも本人降臨してもらって
現在の設定値を確認してもらったほうが、相当馬鹿にはされるだろうが痛みは小さいのでは…
RMAしてまたぶっ壊すとか、M/B や DRAM, 設定を疑ったほうがいいだろっていう… >>172
失業保険の給付だけでも
実家とかに身を寄せたら手元に残る額は増えるかもよ あれいい加減にしろよっておれも思っているが、RMAおかわりでクレームはもう手詰まりすぎ。
>>176
今回問題になっているのは DDR4 固有パラメータ
Trdwr, Twrrd, TrdrdScL, TwrwrScL, TwrwrSc, TwrwrSd, TwrwrDd, TrdrdSc, TrdrdSd, TrdrdDd のうち、
Trdwr, Twrrd か、TwrwrSd, TwrwrDd, TrdrdSd, TrdrdDd を思い切り下げてみればいい。
下げすぎると起動しなくなるし、メモリーコントローラー痛める可能性があるから
ひどい設定で長時間動かすと彼みたいになるので試すのはほどほどに… >>181
我々はAMDではないので... >>48 200回ノーエラーいけるかと思ったら無理だった・・・
170: 2017年 7月 19日 水曜日 00:16:33 JST: OK
In file included from net/mac80211/trace.h:9:0,
from net/mac80211/driver-ops.h:11,
from net/mac80211/tx.c:34:
net/mac80211/trace.h: In function ‘trace_drv_add_chanctx’:
./include/linux/tracepoint.h:133:10: internal compiler error: Segmentation fault
struct tracepoint_func *it_func_ptr; \
^
./include/linux/tracepoint.h:186:4: note: in expansion of macro ‘__DO_TRACE’
__DO_TRACE(&__tracepoint_##name, \
^
./include/linux/tracepoint.h:348:2: note: in expansion of macro ‘__DECLARE_TRACE’
__DECLARE_TRACE(name, PARAMS(proto), PARAMS(args), \
^
./include/linux/tracepoint.h:473:2: note: in expansion of macro ‘DECLARE_TRACE’
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
net/mac80211/trace.h:1448:1: note: in expansion of macro ‘DEFINE_EVENT’
DEFINE_EVENT(local_chanctx, drv_add_chanctx,
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
make[2]: *** [net/mac80211/tx.o] エラー 1
make[2]: *** 未完了のジョブを待っています....
make[1]: *** [net/mac80211] エラー 2
make[1]: *** 未完了のジョブを待っています....
make: *** [net] エラー 2
make: *** 未完了のジョブを待っています....
171: 2017年 7月 19日 水曜日 00:17:41 JST: NG メモリ周りが弱いのは定格 >>137 な時点でお察しなのになぜに定格越えで文句言ってるんだろう？
帯域幅ほしかったらQuad-channel DDR4-2666対応のIntel Core i7-7820Xでも買えばいいのに
https://ark.intel.com/products/123767/Intel-Core-i7-7820X-X-series-Processor-11M-Cache-up-to-4_30-GHz >>180
マジで壊れるのでやめろ。一度MCE発生するほど追い詰めたら買い直すしかない uOP cache無効でSEGVしなくなるとかなんとか 俺環ではagesa 1.0.0.6aとopcache無効化でカーネルビルドのsegvが100回に1度くらいから500回に1度くらいまでには減ったわ
ちゃんとBIOSをアップデートしていってしっかり設定詰めれば出なくなる程度の現象だって改めて思ったわ opcache無効化しないと安定しないのそれ欠陥なのでは いままでごめんなさい
こんなゴミクズ人間で申し訳ないです。 俺はアウアウカーとアウアウウー以外の回線持ってないぞ？ OpCache無効化したら 500回程度ではエラー出ないはずなのだが… (defconfigと仮定) >>198
defconfigだが書いたとおりあくまで俺環()だぞ >>1にあるRyzen SEGV Test CodeをVS2017でビルド、例に倣ってパラメーターを8,2500000で実行してる
構成
CPU:Ryzen 7 1800X
M/B:X370GTN（BIOS:X37AK623（多分最新）（AGESA 1.0.0.6））
Mem:Crucial CT8G4DFS8213.C8FBD（シングルランク、8GB,DDR4-2133）
SSD:SM961 256GB
PSU:SS-660XP2S
BIOSの設定等:すべてデフォルト（メモリ設定もすべてAuto）
チラッと見た感じでは5400回中3回NGが出来てる つうか当たり前だけどリリースビルドしたら出来上がったexeファイルだけ別PCに持ってってもちゃんと動くのな
つーわけでXeon E5-2630v3でもちょっとやってみてる 俺もほむほむ本人様に指摘したんだけどね、いまどきの自己書き換えプログラムは未使用のページをアロケートしてコード書き込んでから実行属性に書き換えるぞって。 (ほぼ確定)
1. 1件のLinux Kernelにおけるパフォーマンス向上および信頼性向上 (恐らくBIOSで回避できるようになるはず)
2. 1件のLinux Kernelにおけるパフォーマンス向上 (これ書くの重いから後回しだな…)
3. 1件のBIOS設定における信頼性向上 (報告するだけ)
(未確定)
4. 1件の信頼性向上 (PoC書く難易度くそ高い)
を提出予定。3. については Customer Supportから Case開いたが時間かかりすぎるのだるい
Full disclosureを先にしたくないので
1. だけでも影響すさまじいのでさっさと報告してあげたいが…
法人でお付き合いあった営業さんの名刺探してみるか？
* 私はlinuxカーネル開発者ではありません 構成
CPU:Ryzen 7 1700 3.7Ghz 1.25V固定
M/B:B350GT3（AGESA 1.0.0.6）
Mem:Crucial BLS2K8G4D240FSB（8GB×2,DDR4-2400）@2933 1.35V
2週間ぶりにやったけど20000回してエラーでなくなってたし逆に自分がおま環な気がしてきたわ 1. だけで >>1 の上 3つが吹き飛ぶ。ryzen_segv_test? しらねーよあんなの ryzen_segv_testってIntel環境で起きる時点でSEGVのテストプログラムになってないよねぶっちゃけ
システムの安定度測定するための一環で自分はやったけど うちは1700+Taichi(P3.00 1.0.0.6a)+QVL掲載サムスン2133でも試してるがuOpCache切ってもタイミング変えても連続ビルド(defconfig)で1時間も経たずにSEGV出てしまう
>>204がAGESA/BIOSに反映される事で直るなら一旦封印して修正版BIOS待とうかという気にもなってくる・・・
(一ヶ月近く色々試して改善に至らずなので正直疲れたというのもあるが) >>130
AGESA 1.0.0.6aはいいが、1.0.0.6以前はダメなのか
起動するなということはDRAMかメモコンに直らないタイプのダメージがたまるってことかな 個人的には >>71 と BIOSデフォルトのうちより大きい値を設定することをお勧めします。。 >>211
TwrrdとCR以外はデフォルト値と同じだった
Twrrd3、CR2に変更してやってみたがダメ
さらにuOpCacheを切ってもダメ
しばらく格闘していたが、tCWLを14(>>38の情報より)、それ以外は当てずっぽうで大半を適当に+1してさらにuOpCacheを切ったら偶然当たり設定になったぽい
2時間超えてもSEGV出てない
引き続き回してみる >>3 を元にした報告用テンプレ。長くなるので環境と試験結果 (どう変わったか) だけ書いてパラメータ部分 pastebin 共有がおすすめかな
https://pastebin.com/67aEyCMv あと、もう見てられないので ryzen_segv_test 関連は隔離スレ立ててやってほしい… >>213
>あたり設定は共有していただければとー
メモリ型番とマザボ・BIOSをテンプレ化しないとだよね？ AMDから連絡こねー。どっかの誰かさんが詫び石などと騒いだせいでサポート混んでるのかしら…
>>212 はまだ走ってるのかな？ 1. くっそ簡単な回避策があった。ASLR有効でも OK なのに、4% 高速化とか… 詫びsatまだか？
言い逃れしてねーでさっさと土下座だろ？ 本当の原因もわからずにまだ 64バイトとか言ってるのか。よくやるよなあ… ここと、Twitterと、AMDのフォーラムで話が違いすぎて
それぞれ並行世界をみている気分になってくるなｗ
もはや、何信じたらいいのか未だRyzen買ってない第三者には
全く訳がわからない状況になっとる 要するにRyzenはまだ買ってはいけないということだな >>224
自分で買って確かめろ
安いR3出るから
R5下位でも良いけど
しかしまぁ性能比で言えばやっすいなぁ >>222
ツイッターはryzenのエラッタありきで語ってる
こっちはシステム全体で見てるからそりゃ噛み合いませんわ
SEGV発生して困る人は買わないほうがいいのは確か >>224
情報見て判断出来ないなら永遠に買わなくてもいいよ 残念なことに？ユーザーモードから exploit することは現状無理ぽ
その点、Intelは楽しいことになっているよな。あっちのほうやろうかしら ryzen testをHDD上で実行してエラー無し20000超えた設定でもtmpfs上で実行するとすぐ死ぬ > ぼちぼちサポートリクエストしたけど無反応という人が出てきたな。パンクしてるのか、それとも何かの意図があるのか
https://twitter.com/satoru_takeuchi/status/887906168923766788
誰のせいだよっていう。本当に勘弁してくれ… Linux が、1.x時代からの妙なトリックを引きずっていることは知っていたので対処できたが、
AMDは本当に古い Linux の対応を念頭に置いて Microcode 作ったのだろうかっていう
Linux 4.13 の merge window も閉じてしまったし、大丈夫なのかこれ？
Windows ユーザーには関係のない話だがなあ。この割り切りは Windows とはかえって相性がいい >>212だけど7時間過ぎた頃にSEGV出た
(出た頃に地震も来たんだけど関係ないよね)
最初は当たりぽいと思ったが、結果個人的にはイマイチ
なんでもうしばらく色々試そうと思っているが、この設定上げた方がいい？ >>234 おつおつ。
多分、その設定にたどり着くまでに AGESA 1.0.0.4 らでメモリーコントローラー？
(Infinity Fabric 含めなのでは疑惑が最近ある) 壊してしまっているので、それが限界かと
環境、パラメータの変更点、挙動の変化と、詳細パラメータを pastebin で上げてもらえると嬉しいです >>235
後で上げとく
3/3購入でコアOCはしてないがOCメモリは試してるから「壊してしまっている」は該当するんだろうな・・・ >>236
いや、本来ならば救済されるべき対象だったと思うのだが、
あの祭りでもう塩対応っぽいからなあ… なんだこの2chデザインは・・・
結局あの後mesaビルドを走らせてみたらNGが2/200程度出てしまいました。とりあえず根本解決はしなかった報告まで >>235
AGESA 1.0.0.4以前はメモリーのサブタイミングが糞でCPU側に無理させてたってこと？ >>239
否定はできない…表示すらなかったはずなので >>241
失礼
>>119の2400設定（opcache無効）です >>244
いや切ってないですね（opcache無効のみで解決できるのではと思っていたので）
カーネルのそのあたりに何かバグが？ それとも単純にメモリコントローラへの負荷を減らす策ですかね？ >>242
影響に個人差でかいのもそっちのほうが納得するが確証はないからな >>245
あ、Micro-op Cache 切っていたら関係ないです。 >>246
例えば >>119 は XMP のクロックできちんと tRDWR, tWRRD, tWRWRSD, ... が変わっているが、
そうじゃないマザーボードが大量に以下略
一応確認したんだよね。どうするんだこれ 結局、既存の市場無視して「ぼくがかんがえたさいきょうのしーぴーゆー」をAMDがまた出したってだけ
辻褄合わせが後付けで、ユーザーやデベロッパーの労力が求められる 古いAGESAとOCメモリで壊れたならAMDに瑕疵があるからAMDはテストプログラム配信して該当する場合は交換とか何か対応するべきだな >>247
あら・・・
とりあえずAMDから返答がないとなかなか全体をパブリックにできない様子
確証があるなら自分はのんびりしていようかなと思いますがどの程度でしょうか 9割以上はまともなマザーボードと Windows 10 の組み合わせだから問題ないはずだが。
あと、AGESA 1.0.0.6 で XMP を読む範囲が増えたといっても定格が向上したとは AMD は言っていない
>>251
この調子では Linux は相当対応が遅れると思う。さっき書いたように 4.13 の merge window も閉じちゃってるし、もう、ね… >>252
うーむでは時間が許す限りでパラメータとか調整してみますかね
見落としとかあるかもしれないですし。あったらいいなあ ソケAのころならまだしも今7時間もビルドし続ける事無いから合格レベルじゃないの 試験されている方々、お疲れ様です。
皆さんの数字をみて、安定を貰ってぬくぬくしようと思っている情けない自分です。
せめて、楽しんでやっていれば救いです。＞なんか昔にもそんな様なのありましたよね？新種のハードが出れば常なのかも？
熟れるってすごい事なのだと、久しぶりに痛感。ここしばらくこういうのなかったし。 そうだね
XMPなんてのがあるのも細かく調整しないと安定しないからというのがよくわかった M/B : ASRock X370 Taichi (BIOS P3.00)
CPU : AMD Ryzen 7 1700 定格,Microcode 0x8001126 (AGESA 1.0.0.6a)
FAN : Thermalright TRUE Spirit 1366+同TRUE BTK+Ainex CFZ-120LA
RAM : Samsung M378A5143DB0-CPB 4GB DDR4-2133 UDIMM x2 (15-15-15-36) @ DDR4-2133 1.2V
uOpCache : OFF
パラメータ
https://pastebin.com/crADU329
結果
1時間も経たずにSEGV発生→7時間超えた頃(328回目)にSEGV発生、まで延びた >>242
借り物だけどこれとかメモコン負荷かけまくりな設定ってことか？
http://i.imgur.com/RP4X2Sk.jpg
メモコンの該当すると思われるサブタイミングがやたら低いのだけど TaichiのP2.30の頃のデータ見たら3200のXMP読み込みでtRFCが2133のタイミングのままになってるわｗ 発売から5ヶ月近く経ってもメモリ手動調整しても結局エラー吐く糞環境って事？ >>260
Trdwr, Twrrd, TrdrdScL, TwrwrScL, TwrwrSc, TwrwrSd, TwrwrDd, TrdrdSc, TrdrdSd, TrdrdDd,とかのデータは流石に取ってないよね
そういえばどっかのメーカーはマニュアル設定だと起動してXMPだと起動しないとかあったなぁ >>262
残念ながら、その頃はそれらは記録してなかった ちなみにAMDのサポートリストに載ってるCMK16GX4M2B3200C16ver5.39は
Taichiでは未だに手動設定じゃないと起動できない >>257
自己レス
Trdwrを設定し忘れて自動で6(デフォルト-3)になってたので10(デフォルト+1)にして再度回してる
まだ40分位(30回目位)なので何とも言えんが結果は報告したいと思う 意味的には
tRDRDSC_S < tRDRDSC_L
tWRWRSC_S < tWRWRSC_L
tWRWRSC_S > tRDRDSC_S
tWRWRSC_L > tRDRDSC_L
tRDWR > tWRRD
tWRWRSC < tWRWRSD <= tWRWRDD
tRDRDSC < tRDRDSD <= tRDRDDD
tWRWRSC > tRDRDSC
tWRWRSD > tRDRDSD
の関係になりそうなものなのだが、気のせいか？ >>261
ようやくまともなメモリ設定をするマザーボードが現れ始めた、かな 略語だが、
SC = Same Chip
DC = Different Chip
DD = Different DIMM
RD = Read-burst
WR = Write-burst
ね。 MCE で強制再起動
-- 電源二度と入れるなの壁 --
MCE 吐く
-- 買い直しの壁 --
futex 刺さる
-- Infinity Fabric 壊れたんじゃないの？の壁 --
ASLR 切っても SEGV する
-- メモリーコントローラー壊れたんじゃ？の壁 --
SEGV する
-- ASLR切るか、パラメーターを見直したら？の壁 --
SEGV しない
-- 実際に設定できることが実証された --
論外)
memtest 通らない (memtest は DDR4 の機能フル活用しない) >>271
DDR4初期のIntelもこんなもんだった >>266
自己レス
2時間持たなかった
Trdwrを9→8→7→6→5と1ずつ下げながら試してみるか
ちな基本最低でもmemtest2回は回している >>273
検証おつ。memtest は真面目に回す必要はないかとー
DDR4 固有パラメータで壊れるのはメモリーコントローラー側なので… >>267
その条件に>>71の推奨値が当てはまらないように見えるのと、パラメータの名前合ってる？
>>270
手持ちの1500XはASLR切っても(頻度は激減したが)SEGV出たからメモコン壊れ？の壁を越えてるなぁ
1700はまだASLR切っては試してない
試すのが怖くなってくるw >>275
Clock換算で切り上げると不等式が等号になりうる… >>272
マザボベンダーのタイミング設定可能範囲にも問題大ありだったけどな
未だにASUSは緩い方に設定範囲が厳しいが あと少し前から気になっているんだけど、こんなページを見つけた
AMDの新CPU RyzenはUbuntuで利用できるのか？
https://kledgeb.blogspot.jp/2017/02/ubuntu-1604-137-amdcpu-ryzen-7ubuntu.html?m=1
このページではRyzenでLinuxを使うに当たり
・基本的にはRyzen対応が行われたKernel4.10以上を使った方が良い
・最低でもSMT Topologyの問題を修正したKernel4.9.10以上を推奨
という事が書いてある(ページ真ん中辺り)
そこでChangelogを見てみたのだが4.9.10では確かに修正が入っている
さらにKernel4.11.3でも
EDAC, amd64: Fix reporting of Chip Select sizes on Fam17h
(Fam17hはRyzen)
という修正が入っているのを見つけた
(関係する内容かは分からなかった)
以上の事から、少なくとも4.11.3より前のKernelでテストしている場合、SEGVの発生理由が
・Ryzen(ハード)だけによるものなのか
・Kernelが未対応(ソフト)な事も関係してくるのか
が判別しにくくなるのではないか？
4.9.10より前のKernelだとより一層判別しにくくなるのではないか？
と思っているのだが、詳しい方々はどう思う？
なお、4.11.3以上の環境でも出た事例が過去スレにあったはずなので、残念ながら4.11.3以上にしたからと言ってSEGVが直るわけではない 現状、全ての Linux Kernel で SEGV は起きる x86/x64互換なのに、後から出てきて動かない方が問題なんじゃ無いの？
x64なんかAMD出自なんだし 不効率性は新しい設計で済むけど（コードの最適化的な範疇
エラーや間違った結果吐いたり、指定と違うアドレスがコールするのはソフトの問題なのか？ >>250
QVLに掲載されてないメモリならAMDに瑕疵はないよ
それとOCという時点で自己責任だ
寧ろXMPという中途半端な欠陥仕様を提唱したIntelに瑕疵がある > 指定と違うアドレスがコールするのはソフトの問題なのか？
OS の問題 (Linux) futex が刺さる問題はこれっぽいな。疑って悪かった > Infinity Fabric
https://github.com/torvalds/linux/commit/76835b0ebf8
1. のワークアラウンドと合わせて半日走らせてみよう > x86/x64互換なのに、後から出てきて動かない方が問題なんじゃ無いの？
元々 SMP を想定していなかった x86 に、Core Micro-Architecture でばかり試験してきた環境がなあ
Zen の現在の Microcode の実装はその時点からに対して喧嘩売っちゃってるのでピーキー過ぎてお前には略
曖昧な x86 SMP 実装が見直されるいい機会なんじゃないのー >>270
そのうち修正するんだよな？出鱈目は止めろよ？ Win10のWSLでは問題ないという結論？
WSLでもSEGVするという話もあったが、あれは別の糞メモリ問題？ >>289
問題ないはずですね。現状、WSL 自体が実験的な実装ですが、
真面目に取り組んでいるようなので Linux Kernel より早く安定してしまうかも…
Twitter で騒いでいるのは壊れたメモリ、パラメーターで CPU 吹き飛ばしている人たちばかりですよ SEGVはLinuxの問題で必ず発生する
昔のBIOSはメモコンに負荷かけまくりでCPUふっ飛ばした個体多数で検証にならん
ということか >>291 私の認識は現状そうですね。
で、SEGV 起きる問題についてはすでにワークアラウンドを発見していて、回避可能と見ています。
問題の範囲もこれで恐ろしく狭まったので Microcode による対応も可能なはずです。
が、AMD と連絡つかねええ 両方に問題ありなのか
そうするとAMDのコミュニティで実験してたLowLatencyKernelで48時間SEGVが出なかったのもKernelの動作が微妙に変わって、それがたまたま問題が起きにくい動作だっただけぽいね
(ちなみに少し前に1500Xで実際やってみたが26時間位でSEGV出た)
現状ユーザーレベルで出来るのは「出にくくする」事まで
「出ないようにする」にはLinuxとBIOS修正待ち
但し少なくとも発売日に買って使ってる人はメモコン壊れている可能性がある、と
修正版でもダメなら代理店RMAできる事を期待するしかなさそう >>293
議論へのポインタと 1500X での構成、メモリのパラメーター希望。。 >>292
カスタマーサービスから連絡入れました？ AMDのフォーラムで返答がなくても、個別のサービスリクエストには応じてくれるようです >>295
はい。すでに SR に対して ticket 発行済です。 >>296
そうでしたか。普通の案件でもそれほどレスポンスはよくないので、内容が高度なものだともっと遅いのかもしれませんね >>294
前スレ
599 名前:Socket774 [sage] :2017/06/28(水) 21:07:13.12 ID:25mk0hwz
>>597
https://community.amd.com/thread/215773?start=120&;tstart=0
これか。
1500Xの構成は後でテンプレで上げるけど、ざっくり言うと1500X定格+MSI B350 PC Mate+Hynix 2400 1R 4GBx2
BIOSは1.0.0.6ベータ(3回出ているので正確なバージョンは記録してないと思う)
メモリタイミングはデフォルト(JEDECプロファイル)
Ubuntu Studio 16.04.2 LTS(デフォルトでLowLatencyKernelになっている)
apt-get update/upgradeした状態
Kernel4.8.36-lowlatencyでは2時間位でSEGV出た
GUIからアップデートしたら4.8.58-lowlatencyになって、そっちでは26時間位で出た
gccは入っていたのを使用 >>271
255のチキンだが、個人的にはVLバス相性問題を彷彿させられた
あれは完全なハードの問題だったが、現代はメモコンと設定とメモリとで協働するから問題が見えにくく複雑だ
Intelがすでにある程度のメモコンとDDR4との調整がつきマザボメーカも設定値に自身がついても
AMDのメモコンだとまだまだチューニングが生き切らなかった…
単語だけだと”相性問題”で片付くのかもしれない いや、今の CPU ってグレードがそのまんま型番行きで AC特性は型番ごとにわかっているのだから、
単純に計算して耐えうる設定値を示せばよいだけ。なのに、BIOS がそれやらないって何事なのこれ… 詫び石つまり交換対応は原因がはっきりしない場合に出さざるを得ないときに出す
ただ今は症状と対策がわかってるのだから、再現試験して、相応の結果が出なきゃ送り返すだけ
私なら足がおれてなにもできない、配送トラブルの可能性を否定しないがどーなの？って対応を考えるかもな
悪質なクレーマー対応なら >>300
初期BIOSはマザーベンダー側じゃ弄れなかったとかかね
そもそもAM4マザーボードが突貫工事だったのから地雷踏みそうとは思ってました >>298
ああ、これか。この人のは ASLR 切る対応なんだよね。
確かにその方法は緩和策としては PC-UNIX の構造上、かなり有効なのは理解はできる
私の 1. の方法は ASLR が有効でも落ちない。少なくとも最後の試行は今現在 4時間 SEGV を起こしていない
もちろん、gcc も含めて全て落ちないし、間接的な結果である 64バイト問題も当然生じないわけだ
AMD お返事ください…
>>302
いや、今でも対応しているもの、いないものが混在しているのは明らかにおかしいでしょ…
項目自体は表示されるようになった今、AMDに話を聞かずに設定いじるのは不可能なので、サボっているとしか
この場合、責任はどちら側になるんでしょうかねえ メモリースレ覗いた感じTaichiだけメモコンに関連すると思われるタイミングが異常に低いな
他メーカは多少は違えどだいたい同じような感じ >>303
すでにご存知ならメモリのパラメータ上げなくてもいいかな？
今別のメモリ差しているから差し替えしてBIOSダウングレードしないといけないので、必要性があまり無いなら申し訳無いが勘弁させて欲しい
(どうしても必要ならやるけど)
なお自分が試した時はASLRは入れた状態でやった(切ってやってたのは初めて知った)
参考まで >>305
あ、差し替えまでの手間がかかるのなら必要ないです。
できれば今の環境におけるパラメーターを上げていただければ
あまりにも M/B, BIOS における設定にばらつきがありすぎて収集中… >>304
AMD の Community で Taichi だけやたらと壊している印象あるのだけれども、
それと関係がないとはとても思えないんだよね。本当にどうするつもりなんだろう？
EPYC はがちがちにパラメーター指定してくるだろうから問題ないだろうけど、
このまま PRO が出るまででたらめなパラメーター配りまくる M/B だらけって落ちだったら怖い >>306
どうもすまん
お言葉に甘えさせていただく
あと今差してるメモリはTaichiに差してるのと同一
(4枚持ってるのを2枚ずつ差してる)
パラメータも全てTaichiのデフォルト値と同一だった
(>>257のpastebinの(+1)とかの分引いた値) >>308 いえいえ、ありがとうございます。
AMD Community 見ていると Taichi の他に 3つほどやばそうなのがあるのだが…
ゲーマー向けを謳っているやつは比較のためにわざときつくしていることは珍しくないのだが、
それを出たばかりの Ryzen でやるの？っていう… >>309
疑いあるマザーボードはここで言っていいんじゃね
ゲーマー向けマザーボードは持ってる人多いから検証進むし >>309
TaichiはP2.40(P3.00の一つ前)から同じメモリクロックでもリミッターがかかったように遅くなったらしい
(逆に言うとP2.40以降はきつい設定ができなくなったらしい)
だからP2.40とその一つ前のL2.36(ベータ版)で区切って考えないといけないかもしれない
P3.00(1.0.0.6a)(7/14リリース)(現時点最新)
P2.40(1.0.0.6)(6/9リリース)
---安全性の壁---
L2.36(1.0.0.6)(ベータ版)
L2.34(1.0.0.6)(ベータ版)
P2.30(1.0.0.4a)(5/10リリース)
・
・
ちなみに自分はTaichiは6月に購入
(それまで1700はBIOSTARのM/Bで使用)
2週間ほどで故障
7月上旬に修理に出したら新品交換で帰ってきた
なのであまりいじっていない
まだWindowsも動かしてない位
BIOSはP2.40以降しか使ってない >>311
リミッターかかったようだと言った一人だけど
原因はBankGroupSwapがP2.40からDisabledが初期値になったからだった
最新のP3.00も無効になっててP2.40の速度よりは伸びたけど書き込みは遅い
P2.00の時も書き込みにリミッターかかったようになってたけどその時は
BankGroupSwapが有効かどうかは気にしてなかったから定かじゃないな まず、壊しちゃったなーこれって人 (全部 AGESA 1.0.0.4A世代…)
mcl00 MSI x370 Gaming Pro Carbon (1.0.0.4a)
mcl00 ASRock Taichi x370 (AGESA 1.0.0.4a)
ichuev taichi x370 (1.0.0.4a)
deluxe Asus Crosshair VI Hero (1.0.0.4a)
tosilva Asus B350 Plus (1.0.0.4a)
sat ASUS PRIME X370-pro (1.0.0.4a)
mrwwhitney ASUS Prime B350-Plus (1.0.0.4a)
stoyany Asus Prime B350-Plus (1.0.0.4a)
raydude Asus Prime B350-Plus (1.0.0.4a) 圧倒的な安定感 (AGESA 1.0.0.6 or later)
ASUS PRIME X370-PRO (7件)
ASUS PRIME B350-A (2件)
ASRock AB350 Pro4 (2件) 初めから不良個体だった可能性もあるから断定するのはどうかと思うが すごく割れているが （人気あるんだろうな）、
ASRock X370 Taichi :
BIOS 2.60以降 -> OK
それ以前またはそれを使ったことのある人…だめぽ AMD Community の空気はこんな感じかなあ
1. を知っているので、ソフトウェアでなんとかなるものは OK カウントしてます >>315
別に断定はしていないが、 >>313 の中からどれか選んで古い BIOS 焼いて追試してみたら？ ちなみに自分のTaichiも起動不良で初期不良交換になったな >>311
初期にいたタイチ壊れた人か
戻ってきたんだねよかった CPU初期不良なのかどうかはともかく、MCE まで到達している人達がほぼ AGESA 1.0.0.4a 世代ってのは…
ASUS PRIME X370-PRO 使っている人、
BIOS デフォルトで、DDR4-2133, 2400, 2666 テンプレ報告してくれないかな (他力本願 キャッシュ階層エラー報告が増えているけどメモコンの件と関連性あるのかなぁ >>322
Micro-op Cache の Tag の一貫性の問題と同期の問題だな。(公開する気はない)
あとは現実的でないワークロードで起こしているのが ryzen_segv_test ね。
対処されるだろうとは思っているが、現在は意図的に異常な状態を作る一つの方法となっている
この、例外的なパスを走らせまくることで何が起きるのか、私には想像もつかんですわ >>320
もう一月近く前の話だから誰も覚えてないだろうと何も言わなかったがその通りです
ありがとう
なぜか販売店が初期不良期間過ぎてるのに新品交換(動作チェック・BIOSup込)までしてくれた 問題あるBIOSで追試させようとしているのは、また壊せと言っているようなもの >>325
>>318 についてだったら、皮肉だ。すまん
カウントについては AMD Community で確認できるから実際どうなのか見てくれればと
皮肉の裏返しの要点としては、
1. AGESA 1.0.0.4a 世代は Microcode がやばいのか BIOS がやばいのかわからないが、やばそう
2. AGESA 1.0.0.6a 世代は問題を起こしているように見えない
3. AGESA 1.0.0.6 以降であっても、CPU 本体の定格が上がったわけではない
4. CPU 定格はメモリの本数で変わる、パラメーターきつくても 1枚なら耐えられるケースも多いので
買ったら 1枚刺しですぐに BIOS 更新することをお勧めする
(CPU 定格)
Dual Channel/Dual Rank: 1866 (2133*)
Dual Channel/Single Rank: 2133 (2400*)
Single Channel/Dual Rank: 2400 (2667*)
Single Channel/Single Rank: 2667
*Depending on system & Module Design 4月にTaich使い始めたけど安定してる
こんなことになってるとは… 高負荷でぶん回さなければ多分問題にはならんと思うが
BIOSだけは最新にしとけ
怖いならメモリ設定手動で定格運用 高負荷でぶん回してもおそらく問題は無い
負荷ソフトとgcc同時に回すとgccにだけ問題が起きるから 3. の関係式も見えてきたなあ。これだと Linux でも全く問題はない…
本当にマザーボード メーカーは何やってんだか >>332
gccとSEGVとメモコン故障のSEGVの2つあるという130の考察なら昔のBIOSでメモリーぶん回しはやばいと思うが >>334
>>19 の http://imgur.com/0v7UnXs とか明らかにやばいだろ。tWRRD = 0 っておいー
これが動いていることからメモリーコントローラーの実装が見えてきたっていうのもあるが。
t(RD|WR).* は「仮想」レイテンシーだからね。設定とベンチマーク例を今晩あげられるかと メモリーについては、まず繰り返しになるが、
AMD は定格が AGESA 1.0.0.6 で上がったなどと言っていないことに注意
AGESA 1.0.0.6 より XMP で DDR4-4000 までのプロファイル読めるよって言われても、
JEDEC にそんな規格ないから…ガーバーデータの統一すら現状不可能だろそれ…
CPU の定格は定格、その先は自己責任。本当に帯域ほしいなら Quad-Channel な CPU 買えっていう
最悪なのは出回っている XMP で DDR-4 2666以上のメモリーが、
1. 本当の選別品 - 例えば Micron だったら -062E (定格で DDR4-3200) とか
2. 普通の対応品 - 最近だと -075 のスピードグレードが普通に手に入る
3. 自称「選別品」 - 実は -075 スピードグレードとか、それより悪いものに V_DD = 1.4V などと平気で書き込んでいるくそメモリ
で、メーカーブランドでない場合、3. が平気で出回っているから、もう、ね… しかも、さも当然の様にOCの値が定格の様に型番に入ってるから
自作素人には判断できない罠 言うまでもないがDRAMの供給不足で品質の悪い品物がハイグレードな価格で売られている現状
DDR4にはずれが多い理由がそれ >>335
tWRRD=0は少なくともASRock TaichiとMSI Mateの場合デフォルト値はそうなる
これは1.0.0.6/1.0.0.6aのBIOSでも同様
0以外が入っていたのを見た事がない
(0で大丈夫なんだろうかといつも気にはなっていた)
BIOSTAR X370GT5(1.0.0.6ベータ)はデフォルト値3が入っていた
(過去撮っていた画面写真で確認)
という事は少なくともデフォルトでtWRRD=0になるM/Bは全て危険
少なくともASRockとMSIは要注意という事なのかな？ >>339
設定値無視のフォールバック動作してるっぽい >>340
そうするとRyzenTimingCheckerで実使用値を確認しないとダメってことか >>341
いや、あれが BIOS 設定値。段階としては
1. BIOS 表示/設定値
2. 起動時 DRAM トレーニング反映値 (BIOS 表示値に返さない実装もある) = Ryzen Timing Cheker
3. メモリーコントローラーの実際の動作設定 (内部 - 現状確認する方法なし)
かと tWRRDは0スタートだし2133,2400なら問題ないだろ >>342
RyzenTimingCheckerでも実使用値は確認できないのか・・・
そうすると現状はデフォルト値が>>71の推奨値未満だったら推奨値を手動設定しておくのが一番安全そうだね
(特に0になっているパラメータ) Trdwr 8, Twrrd 1, TrdrdScL 3, TwrwrScL 3, TwrwrSc 1, TwrwrSd 5, TwrwrDd 5, TrdrdSc 1, TrdrdSd 3, TrdrdDd 3
より下げたければ下げてみればー？ >>345
新しい推奨値とベンチマークの結果を今晩上げるつもり
お泊りになったら明日晩になってしまうが… ちなみにおれは
Trdwr 12, Twrrd 2, TrdrdScL 5, TwrwrScL 5, TwrwrSc 2, TwrwrSd 8, TwrwrDd 8, TrdrdSc 2, TrdrdSd 5, TrdrdDd 5
ASLR Enabled, SMT Enabled, Micro-op Cache Enabled, Ubuntu 17.04 Kernel 4.12.2-041202-generic
で回してる。今日は Linux Kernel Build (defconfig) 3時間目。まだ問題なし 17-17-17-39-56 だと
Trdwr 12, Twrrd 2, TrdrdScL 5, TwrwrScL 5, TwrwrSc 2, TwrwrSd 8, TwrwrDd 8, TrdrdSc 2, TrdrdSd 5, TrdrdDd 5
で動いたが、16-16-16-39-55 だと無理だな。
DDR4 パラメーターは設定できる範囲がほとんどない。これユーザーに設定させるの酷だよな 察しのいい人は気づいているかも知らんが、
起動しない > 不安定 > SEGV しない > 動作下限 > 不安定 > 起動しない
の範囲があることに気づいたので、それを晒すって話だ その設定だとDDR4使う意味ないくらいの転送レベル >>342
といってもBIOS側で変更すればベンチ結果に差異はあるんでしょ？
現状安定を求めるならメモリーはXMP読み込ませず気になるならタイミング盛るしかないのかな >>356
だいぶ絞れてきた
16-１6-16-39-55 @ DDR4-2400 1.20V の話だが、
不安定上限
Trdwr 12, Twrrd 2, TrdrdScL 5, TwrwrScL 5, TwrwrSc 2, TwrwrSd 8, TwrwrDd 8, TrdrdSc 2, TrdrdSd 5, TrdrdDd 5
安定設定
？
SEGV しない下限
？
不安定下限
Trdwr 9, Twrrd 3, TrdrdScL 3, TwrwrScL 3, TwrwrSc 1, TwrwrSd 6, TwrwrDd 6, TrdrdSc 1, TrdrdSd 4, TrdrdDd 4
起動下限
Trdwr 8, Twrrd 1, TrdrdScL 3, TwrwrScL 3, TwrwrSc 1, TwrwrSd 5, TwrwrDd 5, TrdrdSc 1, TrdrdSd 3, TrdrdDd 3 >>357
ありがとう
不安定上限値でtWRRDだけ0だとエラー増えるかしら futex 刺さってた… 17-17-17-39-56 でないと耐えられなくなっている気が… 久しぶりにスレ見てみたけど、メモリの相性が原因とかですか？ メモリタイミングのセッティングじゃないかという
UEFIで設定した数値とRyzen Timing Checkerの数値が全く違うな・・・ メモリーコントローラーは壊れないなんて言う人もいるが、
現実には DQ が代表的だが、Bi-directional な Pin は多い
0.35um プロセスがーなんて言っていた時代の 3.3V と、
0.014um プロセスがーなんて言っている今の 1.2V ではかかる電界が １桁違う
周波数もスルーレートも段違い。100MHz と 1,200MHz で １桁違う
1nm が気になるってのは、シリコン原子 0.111nm が 9個あるかって話
CPU の内部などになると突然死するからわかりやすいが、性能が劣化していく
このことを知らずに安易にオーバークロックだの昇圧だのと昔みたいな感覚でやっているが、
寿命があっさり １桁削れちゃうよっていう。まあ自作ユーザーは覚悟の上でやっているのだろうけど よく分からないがとりあえずX370GTNのAuto設定の値貼っておくね
http://i.imgur.com/0ACsD1G.png じゃあ便乗して
BIOSTARでB350GT3
2933 14-16-16-16-34-57にOCした場合
http://imgur.com/oG9HJX5.jpg
OCするとメモコンに関連すると思われるサブタイミング値が変わるようだ >>369
BIOSTARってスイッチ式のDualBIOSじゃんということで2月8日の初期BIOS起動してみたら結構きつめの設定でした
メモリーは >>3 と同じはず
http://imgur.com/s4PuLDp.jpg SEGV しない下限 とベンチマークは今晩には出せると思う。眠い orz
gcc ぶん回すなんて確率的な手法はつらい
この問題を知っている知人に DDR4 試験プログラム書いてもらうか…
>>368 それ！
>>367 >>369 ありがとう。とても参考になります >>364
マザボの型番とずれる設定値わかります？ >>372
ASROCK Fatal1ty AB350 Gaming ITX/acで
tRC・tRCPage・tFAW・ｔRFC当たりが明らかに違いますね
X370の方はAGESA1006a来たけどこっちはまだなんでそれまちです >>371
要件にロックスピナー機能なしとお願いしてくれ 発生確率が０％でもなく１００％でもないそれは確率を下げても意味はない、
むしろ確率を上げて１００％未満の９９％に近づけ、
発生する部分のコードを特定するべきだ。 DDR4の問題ならコード特定出来ないよね
99%に近づける前にメモコンが死にそう バイディレクショナルつっても信号が逆方向に衝突するわけではなく、あくまで電圧を上げたことによってオーバーシュートが絶対定格を超えることの影響であって、ごく短時間ならそれほどの影響はないのではと思うけどね
俺はスペックしか見れないしこれ以上は何も言えないけど。
ただあの発熱具合からしてスルーレートはかなりキツキツなんだろうなと想像はするけど。 >>273
自己レス
環境(Taichi)とパラメータは>>257
Trdwrを9→8→7→6→5と1ずつ下げながら試してみた
なぜか6(つまり>>257通り)の時だけ成績が良い
今回は9時間近くSEGV出なかった
(前回は7時間強)
他の値は悪くて1分、良くても2時間強位だった
おま環とは思うがどういう事なんだろう？
後でMSIの方でも試す予定
(Ubuntu入れるSSDもう一台空けないといけない) このあたりM/Bの物理設計とも関係がありそうで面白げ 昨晩上げたかったのだが Windows 10 では数値が安定せず。Windows 7 入れるか orz
>>380
落ちる設定の時って、PSU ごと落として再起動するとコンパイル時間が変わったりしません？
遅い設定のほうがコンパイル時間が 4% ほど早いんだよなあ…
POST -> BIOS 設定画面 -> 再起動時にメモリーコントローラーはトレーニング結果を伝えているように見える
例えば Command Rate 2T で GearDownMode Disabled -> Enabled とすると
再起動後は 1T を Auto の値として推奨してくるなど
しかし、一度 SEGV するっていうか、フォールバック動作を疑う低速な状態に入ると
PSU ごと再起動しないと元の状態に戻らない。
疑っているのは、BIOS が、無理な設定を押し通しているんじゃないのっていう…
AMD が M/B メーカーに文句言って AGESA 1.0.0.6 まで出してもこれかっていう
https://www.pcgamesn.com/amd/amd-ryzen-memory-compatibility >>382
前に電源入れ直さないとメモリタイミング変更が正しく反映されない話があったので
SEGV発生
→再起動・パラメータ変更(UEFI)
→電源OFF
→memtest2回
→電源OFF(念のため)
→Ubuntu起動・連続ビルド開始
という手順でやってたのでSEGV発生後電源を切らないでの再テストはしてない
今テスト中なので、SEGV出たら再起動してもう一回回して時間の違い見てみるよ 2666MHz以上はギアダウンモードになって強制的に1Tにされる >>384
いや、2400 2T 定格なので Gear Down (なんでこんなヘンテコな名前…) だと、1T お勧めしてくる >>385
ギアダウンモードってメモリーの何かの内部クロック半分にして高速動作に対応させる技術らしいからタイミング合わせるために1Tしか動作させないんじゃないかな
調べても論文しか出てこないという問題点 >>386
DDR4-2666 からの機能。普通にデータシートな記述ありますよ。
倍速クロックでラッチを動かして 1T での動作時に余裕を作る >>382
SEGV出た(今回は10時間強持った)ので電源は切らずに
・再起動だけして連続ビルド
→変化なし(81秒)
・タイミングをデフォルトに戻して連続ビルド
→1秒速くなった(80秒)が数回やったら元(81秒)に戻った
・さらにギヤダウンモードをEnableにして連続ビルド
→1秒速くなった(80秒)が数回やったら元(81秒)に戻った
(2番目と同じ)
速い設定に変えてるのに少し経つと遅くなるという動作をしている
2133のメモリなので1秒(1.25%)位しか差が出ない模様
2400だと4%位の差になるのかな？？
そちらと同じ現象かは自信がない
あまり役にたたない実験結果の可能性が高いが参考まで >>388
10時間…乙です。そこまでやってだめなら、メモリーコントローラーだめかもなので RMA 要求飛ばしてみたらどうでしょ？
うちの環境だと、SEGV する設定では 121秒、しない設定では 116秒 もの開きが。
DDR4-2400 を 2133 に落としてもこの時間に差はほとんど見られないです。
L3 大きいので、通常用途だと差が出ないのは理解しているのですが。
コミュニティも DDR4 Timing Violation に気づいたみたい
https://community.amd.com/thread/215773?start=285&;tstart=0 >>389
今RMAしても塩対応との事だし、いずれ来るだろう修正版AGESA・LinuxKernelでも直らない事を確認してから出した方が良いかなと
もし直るなら出す必要はないし
あともしWindowsでは問題ないならWindows専用CPUにしても良いと思ってる
あと7/27頃にRyzen3(4C4T)が出るので一番安い1200(約1.5万円)を買って
メモリOCを含むOCは一切しないで1.0.0.6以上のM/Bでどうなるか試す事も考えている
まだ検討中だから本当に買うかは分からないが、同じメモリ・設定で1200はOK、1500X・1700がダメならRMAを考えるかもしれない
時間の方は、うちは出やすい設定(デフォルトタイミング)と出にくい設定の速度差があまりないので5秒も差が出ないのだと思う
参考にならなくてスマン >>390
一回のビルドで数千のプロセスが生成されるわけだけど、そんなの普通はやらないから数時間持つ～でも常用には耐えられるかと… amdはなんとかリコールしたくないようだが、いずれは確実な再現手順が発見されるだろうな。 >>392
いいんじゃない？
そのうちリビジョン上がってエラッタありました
で終わるから Zen+でるからRyzenにB2なんて降りてこないと思う >>394
今はZen2/Zen3な。
Intelと同じく年刊Ryzenって感じで更新されるからソケットは一緒でもコロコロ変わるだろうな RyzenPROもUSB.orgみるとB1だしな
amdはiommu周りのパッチを提出してもリジェクトされてるしなぁ >>395
Zen2の前に改良14nmで2xxx番台が出るって話らしいよ メモリーコントローラー壊れたんじゃね？に対しては、
昔動いていた設定が OS起動すらしなくなったっていう…
なんでも小さくすればいいと思っている人って
DDR 世代でも Additive Latency をきちんと理解できていたのかね？
「AMD Certified Mother board ほしい！」
>>378
Intel DDR3 で落ちるのは問題外だろ
>>379
> バイディレクショナルつっても信号が逆方向に衝突するわけではなく
DDR4以前でもそうだが、強制すれば CPU <-> Memory で双方が Output 状態は作れるわけだが
>>357
前回試したSEGV しない設定
Trdwr 12, Twrrd 3, TrdrdScL 5, TwrwrScL 5, TwrwrSc 3, TwrwrSd 8, TwrwrDd 8, TrdrdSc 3, TrdrdSd 5, TrdrdDd 5
>>380 の報告とは真逆だが、もう、Trdwr 9 以下では運用できないっていう。買い替えかね？ しっかし、AGESA に頼っていればよかった設定を無理に上書きした BIOS を載せたボードメーカーに責任ってにないのかね？ 1. についてはどうしたらいいんだろうなあ。AMD 連絡まだー？
* 私はlinuxカーネル開発者ではありません >>391
それが発生条件の一つだとして、Windows上で(Windowsネイティブに近い動作になる)CygWinやMinGWでgccでカーネル連続ビルドテストしてみたいと思っている
しかし実際入れてみたがエラーが出てビルドできなかった
(多分色々足りないのだろう)
クロスビルド環境の事例は比較的見つかるので、PPCとかのカーネル連続ビルドやっても意味あるかな？ >>399
前に動いた設定がOSすら起動しないというのはなんともはや・・・
逆にそういう状態になったらアウトとも言えそうなわけで、犠牲を伴った貴重な情報と思う
(RMAで良いのでは？)
新しい推奨値(なのかな)は後で試してみたい
あとうちの場合のTrdwr6はちょっと変で、手入力で6と入れるとダメっぽくて、Autoで6になるようにすると長時間持つようである事に気付いた
(現在追試中)
メモリもうちはサムスンでそちらのマイクロンとは異なるから、あくまでおま環と捉えてもらった方が良いと思う 396 Socket774 2017/07/24(月) 23:51:57.30 ID:Fn0M86ww
メモリタイミングもまともに設定出来ないやつが多すぎ
Intel用のXMP2.0でサブタイミングセットしてもRyzenでは奇数がダメだったり値が全然違ったりするからね
Intelで8が通ってもRyzenでは12以上じゃないとダメとか、WRはtRTPの2倍で尚且つ偶数じゃないとダメとか。
tRFCもソフトじゃ正常に読み取れないし >>400
AMDはM/Bメーカーのせいにしようとしてダンマリなのかもね
USB3.0問題もメーカー毎の回路設計の良し悪しだったのを分かってたみたいでダンマリを貫いているし
(アース取って改善とかまさにそれでしょう)
ASUS・ASRock→問題報告多数
MSI→問題報告少しあり
BIOSTAR→問題報告わずかにあり
GIgabyte→問題報告なし(うちのは問題出ない発言までしてる)
ただメモリ周りはUSBと違って逃げ道がないから何かしらアクションを起こしてくれないと困るが
>>401
ただでさえ反応が鈍いらしい所にRMAラッシュで「またか」位に思われてるだろうから、気長にやるしか無さそう 事実上、規格通りのDDR4はサムスンしかない。腹立たしい事に 去年某月
Asus,Asrock,MSI「鰤のAPUサンプル届いたからBIOS作って完成や！」
↓
去年8～9月？
Asus,Asrock,MSI「鰤用マザボ出来た。これベースにしてRyzen作ればええやろ」→鰤用マザボ出荷
↓
今年初め
MSI,Giga,Bio,Asus,Asrock「Ryzenのサンプル届いた」
MSI「さあ鰤用BIOS載っけて･･･上手く動かない？作り直すわ」
Asus,Asrock「鰤用BIOSあるし余裕やろ。それよりKaby対応で忙しいわ」
Giga,Bio「なんやこれ癖ありまくりやん。やったるでー！」
↓
2月前半
MSI「ギリギリ間に合いそうだわ、良かった」
Giga,Bio「出来たわ。まああとは細かい修正してけばいいな」
Asus,Asrock「やっと暇になったからとりあえずテストしよ。･･･全然ダメやないかい！急いで作り直すぞ」
↓
2月末
MSI「出来た。出荷」
Giga,Bio「こんなもんやろ。出荷」
Asus,Asrock「間に合わなかった！とりあえずBIOS修正して後から配布や！出荷」
結果はお察し
という妄想した CPUクーラーのリテンションすら定まってない状態だがAM4マザー自体去年の春から存在してる（主にOEM向け
Bristol RidgeのA12-9800とか有ったんだし
それでこの様なんだからRyzenの挙動が違いすぎてたんだろ 実際どうかと言われたら分からんけど、C6Hの反応見てC6E作るつもりだったんじゃないかと思わせるぐらいC6E遅いし、
一番こういうのに時間かけそうなBioが他メーカーより2ヶ月も早くmini-ITXのマザボを作って売ったあたりBio以外はRyzenを軽視してたのではないかというのはなんとなく伝わる気がする
軽視した理由は言わずもがな、前世代で痛い目にあったから？ BIOが力入れてたのは記事にあったしね
MSIはトマホークがリファレンスって当初言われてたけどほんとかな？
asus.asrockは遅れとってるのは間違いないと思う msiは普及帯がトマホークで使ってるPCB派生
gaming proはOEM向けPCBに化粧載せたもの（最廉価構成 ASUSとASRockは設計や調整が個別になるモデルバリエーション絞ってる方向じゃ無いかと 色々勘ぐるのはいいが、CPU に問題があったのか、M/B の設定がおかしいのか、発生頻度だけでいいので追試頼む
>>399 設定 DDR4-2400 で追試中。7時間問題なし
あと、この設定を流用して講演することを禁ずるｗ >>416
1500X+MSIの方はTrdwr6追試終わったので>>399の設定でmemtest2回始めた所
あと1時間以内で連続ビルド始められる予定
1700+Taichiの方はTrdwr6追試中で3時間経過でまだSEGV出てないので未定 >>417
自己レス
Taichiの方もSEGV出た(3時間強)
TaichiもMSIもTrdwrをAutoにした方が長時間持つようだ
理由は不明だがおま環の可能性が高いので参考程度で
これからTaichiも>>399の設定の追試に入る >>418
自己レス
1500X+MSI Mate(1.0.0.6a？ベータ)+サムスン2133 4GBx2の方は1時間強でSEGV出た
ASLRはON、uOpCacheはON(MSIはOFFにできない)
タイミング>>257(Trdwr Autoで6)の時と発生頻度は変わらない感じ
memtestのメモリ速度表示で比較すると20%程速度が落ちているが、ビルド時間は数秒遅くなる程度だった
ついでなのでTrdwrをAuto(6になった)にして再度回してみる
Tauchiの方はもう少しで1時間になる所 >>419
自己レス
1700+Taichi(1.0.0.6a)+サムスン2133 4GBx2の方も1時間40分程でSEGV出た
ASLRはON、uOpCacheはOFF
こちらはタイミング>>257(Trdwr Autoで6)の時より発生頻度は高くなってしまった
(7-10時間程→1時間40分程)
メモコンの壊れ具合？やメモリチップの型番毎に最適値が異なるのかもしれない
こちらもMSI同様ついでにTrdwrをAuto(6になった)にして再度回してみる >>420
これ立川の抜け番は当たりじゃなかったんだよな
要は抜け番でハズレも沢山あるけど
当たりだけピックアップするから怪しくみえるってだけ >>420
検証乙です。BIOS に設定書かせない設定がほしい。DDR4-2400 でも 12時間動いてました
Trdwr 9 未満で起動しないあたり、痛めてしまった感あるので、新しいのを買ってこない限り、おれ環ですな
原理的には
Trdwr, Twrrd はメモリ依存
TwrwrSc, TrdrdSc はほとんどメモリ依存
TrdrdScL, TwrwrScL, TwrwrSd, TrdrdSd はほとんどメモリーコントローラー依存
…メモリによっては +2 まであるか。なはずなんですけどね
TwrwrSc, TrdrdSc がデフォルト 2 以下というのが信じられないんだよな 話題的にズレるけどTrdrdScL, TwrwrScL共に2まで落とせばゲーム速くなるぜってAMD公式のブログか何かが記事にしてたな
このスレ見てると笑えないけど >>423
>>343 の記事でしょ？ OC だと明確に書いてあるからいいんじゃないかな
問題は初期値が OC状態の BIOS…何考えてるんだ… サポートがCPUの電圧上げろって言ってたが、それで再現しなくなったら不良品確定だろうが。早くリコールしろよ。 >>422
>>417-420の追試は全て手入力した
>>399のパラメータと、それ以外は>>257のパラメータ
＞TwrwrSc, TrdrdSc がデフォルト 2 以下というのが信じられないんだよな
これはASRock・MSI・BIOSTARともデフォルト値は1しか見た事がないと思う
メーカーに関わらずなのでAGESAが決めてる可能性があるのでは？
あとおま環のTrdwr Autoだが
>>399のパラメータと、それ以外は>>257のパラメータ、TrdwrだけAuto
・1500X+MSI Mateは約15分でアウト、かえって悪くなった
・1700+Taichiはもう少しで11時間位まで持った(自己新記録)
理由は不明だが少なくとも手持ちの1700はTrdwrはAutoの方が良いようだ
1500X+MSI MateはuOpCache切れないからこれ以上やっても無意味ぽい
近々BIOSTAR X370GT5(こっちは切れるはず)に移そうと思う >>427
なんでそちらはうまくいかないんだろう？
>>404 の
> WRはtRTPの2倍で尚且つ偶数じゃないとダメとか
考慮してます？ >>428
正直パラメータ個々については詳しくない
tWR=tRTP*2 かつ偶数というのもやってない
(>>404はNGになってたし)
大きくはメモコンの壊れ具合とメモリチップが違うから、と思っているのだが
・そちらはマイクロン 2400 8GB 2R(だっけ？)x2 QVL掲載なし(だっけ？)
・こちらはサムスン 2133 4GB 1R x2 QVL掲載あり
あと
・マイクロン 2400 8GB 1R x2 QVL掲載なし
・スペックテック 2400 4GB 1R x2 QVL掲載なし
(スペックテックはマイクロン子会社なのでマイクロン相当品)
があるから変えて追試した方が良いかな？
その場合>>399以外の全パラメータを教えてほしい >>428
あと、もしRyzen3を買う場合M/Bも買い直そうと思っている
(8月に入ったらほぼ買うつもり)
同じパラメータで同じように動くか確認しやすくできるように、M/Bはそちらと同じASRockのA320Mを買った方が良いかな？
(uOpCacheは切れるんだよね) まあ、最初から検証目的で流しているだけだからな。
大騒ぎがうざかったので反例として DDR4 のパラメータで回避できることを一例示せれば十分くらいな感覚
24時間 SEGV しなかった時点で設定公開しておけばよかったかもなあ
>>430
こちらでは tWR=tRTP*2 かつ偶数切り上げ、は BIOS デフォルト設定に対して何の意味もなかった
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
*0. CPU のメモリーコントローラーもうおかしいんじゃないか疑惑。Trdwr < 9 では BIOS すら起動しないし
環境は Ubuntu 17.04 (zesty) + Mainline Kernel 4.12.2-041202-generic
インストール後、apt update; apt upgrade したあと Mainline Kernel を手動でインストール
現在の試行における基礎は
tCL 16, tRCDRD 16, tRCDWR 16, tRP 16, tRAS 39, tRC 55
tRRD_S 5, tRRD_L 7, tFAW 28, tWTR_S 3, tWTR_L 9, tWR 19, tCWL 12, tRTP 10, tCKE 7, CR 2T
tRFC 313, tRFC2 193, tRFC4 133
*1. LGA2011v3 による読みも参照している。LGA2011v3 では tRRD_S 4, tRRD_L 6 だった
*2. DDR4-2400 ではもう 16-16-16-55 が 12時間以上でだと無理なので 17-17-17-56 に落とすこともある DDR4 に関しては
Trdwr 12, Twrrd 3, TrdrdScL 5, TwrwrScL 5, TwrwrSc 3, TwrwrSd 8, TwrwrDd 8, TrdrdSc 3, TrdrdSd 5, TrdrdDd 5
を現在の試行では
Trdwr 9, Twrrd 3, TrdrdScL 5, TwrwrScL 5, TwrwrSc 3, TwrwrSd 7, TwrwrDd 7, TrdrdSc 3, TrdrdSd 5, TrdrdDd 5
に変えている。問題なし 2時間目。
Trdwr 9, Twrrd 0, TrdrdScL 3, TwrwrScL 3, TwrwrSc 1, TwrwrSd 6, TwrwrDd 6, TrdrdSc 1, TrdrdSd 4, TrdrdDd 4
では futex が刺さってしまったので、現在の試行に変えている。
*3 Twrrd 0 = Auto と解釈されるべきだが実際に 0 設定されてしまう
>>428
ASRock A320M が Bristol Ridge向けが基礎なのは BIOS を見ていて疑わしいのであまりお勧めできないかも？
そもそも A320 は DRAM 以外の電圧がいじれないので昇圧しろと言われても対応できないし、
PCIe 2.0 を吐ける本数の制限もきつすぎる Entryモデルなのでどうなんだろう？Micro-op Cache は切れます。
Ryzen向けに開発された B350 Chipsetの板は今後普及してくると思われるので、様子を見たほうがよいのでは？
あと、この流れをまとめて AMD に報告すれば RMA対応してくれると思いますよ > Trdwr 9, Twrrd 0, TrdrdScL 3, TwrwrScL 3, TwrwrSc 1, TwrwrSd 6, TwrwrDd 6, TrdrdSc 1, TrdrdSd 4, TrdrdDd 4
は BIOS 既定 (CMOS クリア後） なのだが、原理的にメモリーコントローラーが追いつかなくなるよりは、
Infinity Fabric が高速に動作する状況のほうが明らかにメリットが高いので、ここ詰めた設定で出荷する必要あるのー？
って思う。 >>432-433
詳細な情報ありがとう
自分としても提示してくれた推奨値で直る(長時間出にくくなる)人続出、という展開だと良かったんだけどね
後で1700+Taichiの方をマイクロン8GBx2に変えて、できるだけ似せた設定で追試してみる
あとソフト環境がこっちはUbuntu16.04.2LTSで全部古いから、これも合わせてみる
Kernelまで合わせられるかは自信がないので最初は17.04で自動でアップデートできる範囲で一番新しいカーネルでやってみる
M/Bの買い替えはMSI MateがuOpCache切れないので今回の検証に向かない、元々色々イマイチで売り払う予定だったのもあっての事だった
話を見る限りA320Mは止めた方が良さそうなので申し訳ないが他のにさせてもらうよ
(といっても色々都合でASRockのB350のM/Bだけど)
Ryzen向け第二世代のM/Bはいつ出てくるか分からないから、それまで待てないというのもある
M/Bメーカーは一通り(RyzenAPUまで)出てからと考えているかもしれないし
RMAはRyzen3での追試結果を踏まえて検討してみる
そちらもRMAした方が良いと思う >>434
AMDって良くも悪くも技術屋だから、最初は規格に準拠する事にこだわる傾向があるように思う
だから細かい所は規格の範囲内で変にこだわってチューニングしてあったりするんだけど、トータルではあまり性能向上に寄与してなかったりする事がある
次の世代ではデファクトスタンダード準拠にしてくるんだけどね > Trdwr 9, Twrrd 3, TrdrdScL 5, TwrwrScL 5, TwrwrSc 3, TwrwrSd 7, TwrwrDd 7, TrdrdSc 3, TrdrdSd 5, TrdrdDd 5
これで 5時間問題ないので、TrdrdScL 4, TwrwrScL 4, TwrwrSc 2, TrdrdSc 2 で回してみようと思う。 >>435
もう 4.12.3 出てますね。
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.12.3/ >>438
マイクロン8GBx2(17-17-17-17-39-56)に差し替えてパラメータ設定しているが、許容範囲の狭いメモリぽい事が分かった
まず>>433-434のこの設定が通らない
(トレーニング失敗する)
＞tRRD_S 5, tRRD_L 7, tFAW 28, tWTR_S 3, tWTR_L 9, tWR 19, tCWL 12, tRTP 10, tCKE 7, CR 2T
＞tRFC 313, tRFC2 193, tRFC4 133
＞Trdwr 12, Twrrd 3, TrdrdScL 5, TwrwrScL 5, TwrwrSc 3, TwrwrSd 8, TwrwrDd 8, TrdrdSc 3, TrdrdSd 5, TrdrdDd 5
色々いじってみたが、ASRockのBIOSも癖があって、トレーニング失敗すると手入力した値は残るが実際は全てAuto扱いになってしまう
一旦値を削除して入力し直さないと反映されなくなる
また、トレーニング失敗まではいかないが手入力値が中途半端に反映される時もある
この場合CRがすぐ1Tになってしまう傾向がある
一旦他は自動にしてこれらだけ設定したら何とか設定できた
＞Trdwr 9, Twrrd 3, TrdrdScL 5, TwrwrScL 5, TwrwrSc 3, TwrwrSd 7, TwrwrDd 7, TrdrdSc 3, TrdrdSd 5, TrdrdDd 5
(TrdwrはSPDが10なので実際は10を設定)
他は1つずつ設定→保存してみてダメなら値を減らしてやり直さないとダメみたい
サムスンのメモリはこんな事がなかった
(許容範囲が広いぽい)
これで試行錯誤するのは大変だったと思う
本当に乙です
この後外出するので続きは後程
あと(どうでもいいけど)tRCPageはマイクロンだと383とかが自動的に設定される事が分かった
(サムスンとHynixは0) >>439
これを使えば自分でもカーネル4.12.3にできるのかな
後でちゃんと見てみる >>436
satなｗ
こいつはすでに構ってちゃんに成り下がってる
基本も試さず騒いだ挙句に完全的外れで信用失ってるしこれを回復するには土下座しか道が無いのに気付いてない アイツ
「交換品で試したらSEGVが出なくなってMCEが出た。謎」→LinuxカーネルとUEFIをアップデートした事は1文字もTwitterに書かず
「AMDのサポートが言う通り昇圧したら50%（本当は3割）遅くなった」
→※「サーマルスロットリングでは？エアフローが悪いのでは？」
→「中のケーブル配線弄ったけど遅いまま。謎」←クーラー名やケースは当然書かないし、ガチで言ってるならもう黙った方が良いレベルの初心者宣言
とか言ってる事ヤバイからな
悪意があってやってるならアウトだし無邪気でこれやってるなら救いようが無い 9時間回してみたが、rm と Firefox がそれぞれ 1度落ちてた。この石だともうこれすらマージン不足なのかも？
これで、安全圏
Trdwr 9, Twrrd 3, TrdrdScL 5, TwrwrScL 5, TwrwrSc 3, TwrwrSd 7, TwrwrDd 7, TrdrdSc 3, TrdrdSd 5, TrdrdDd 5
SEGV 起きないライン
Trdwr 9, Twrrd 3, TrdrdScL 4, TwrwrScL 4, TwrwrSc 2, TwrwrSd 7, TwrwrDd 7, TrdrdSc 2, TrdrdSd 5, TrdrdDd 5
futex 刺さるライン
Trdwr 9, Twrrd 0, TrdrdScL 3, TwrwrScL 3, TwrwrSc 1, TwrwrSd 6, TwrwrDd 6, TrdrdSc 1, TrdrdSd 4, TrdrdDd 4
が示せたかな。わざと古い BIOS など試してみたのでえらくゆるゆるでないといけない石になってしまったが… orz
きつくしていって SEGV 起こせる (64バイト問題も)、死ぬほどきつくしていって MCE 起こせる、
ゆるくしていって SEGV 起こせなくなる、古い BIOS 設定きつすぎ、今の BIOS も相性問題出やすそうなほどきつい
が示せたのでここクリアしないで騒ぐのあれだよなーってだけ。
>>440
基本パラメータは SPD読みなり XMP読みなりでよいかと。話混ざるとおかしくなると思う…
最初は起動するまで面倒だったが、あとは 1日に 2回か 3回試行回して放置しているだけだからなー >>448
昔はここまでじゃなかった。今の設定で 1日回っていたからね。
古い BIOS や MCE の壁に挑戦したらマージン稼げなくなった… 元々、LGA2011v3 で使っていた時も
tWRWRDR, DD, DS, DS_L 3
tRDWRSR 5
tRDWRDR, DD, DS 6
だったからな。Micron 前提で BIOS デフォルトでも作ったのか？冗談だろ 間違えた。Samsung 前提で BIOS デフォルトでも作ったのか？と言いたかった レイプが有ったか無かったかを簡単に察する方法は懲役の重さな
裁判中明らかにしなくてもレイプや暴力があれば刑は重くなる 全くレイプが無かった場合は軽くなる
報道されない事実を知れる立場の検察が殺人罪より重い１５年求刑してる時点で馬鹿じゃないなら分かると思うがｗ >>446
お疲れ様です
ただタイミング緩めると恐ろしいほど帯域落ちるな >>453
あくまでも古い DDR4 メモリで問題が起きた場合の切り分けに対する一つの手段なのと
昔は動いていたのに今は動かないので非常に緩い設定をしていることに留意していただければとー 帯域幅落ちると言っても、DDR4-2400 -> DDR4-2133 に落としてマージン稼ぐのとどっちがいいんだろうね？
あと、今の世代の M/B は本当に Ryzen向けにチューニングされているのか？っていう疑問が… >>451
Ryzenのメモコンはサムスンチップ、特にサムスンB-dieチップとの相性が一番いいそうだから、その可能性は十分にある
あとDDR4チップを世界で最初に出したのがサムスン(DDR4の規格がまだ確定してない時期に出したりしている)なので、デファクトスタンダードになっているのかもしれない
メーカー製PCは廉価品を除くとサムスン純正DIMMを使っているものがほとんどらしい
その割に自作界隈でサムスン純正DIMMをあまり見ないのは、最近はHynixやマイクロンより仕入単価が高いらしいのと、現在の主な国内代理店がアーキサイトというマイナー？な会社で取扱店が少ないための模様
あと3200以上のOCメモリはほとんどがサムスンB-dieの選別品で、OCメモリとして売った方が儲かるから、というのもあると思う
(販売店の利益率が50%位らしい) 可能性
かもしれない
らしい
模様
思う
(らしい)
まぁ、遠回しに言ってスレチ >>446
昨日はあの後結局作業できず今朝再開
これもおま環ぽいがtRFCをAuto以外にするとトレーニング失敗する事が分かった
(SPDの値312を手入力してもダメ)
tRFC2、tRFC4は大丈夫だった
メモコン・マイクロンメモリどちらのせいかは分からない
(サムスンメモリでは起きない現象)
とりあえず昨日のマイクロンメモリは許容範囲が狭いぽい発言は撤回しておく
結果以下の設定になった
(+n)はSPD値(デフォルト値)との差
tCL 17, tRCDRD 17, tRCDWR 17, tRP 17, tRAS 39, tRC 56(これらはSPDと同一)
tRRD_S 5(+1), tRRD_L 7(+1), tFAW 28(+2), tWTR_S 3, tWTR_L 9, tWR 19(+1), tCWL 12, tRTP 10(+1), tCKE 7(+1), CR 2T(+1)(これらは>>432と同一)
tRFC Auto(312), tRFC2 Auto(193), tRFC4 Auto(132)(これらはSPDと同一、>>432の-1)
Trdwr 12(+2), Twrrd 3,(+3) TrdrdScL 5(+2), TwrwrScL 5(+2), TwrwrSc 3(+2), TwrwrSd 8(+2), TwrwrDd 8(+2), TrdrdSc 3(+1), TrdrdSd 5(+1), TrdrdDd 5(+1)
(これらは>>433の最初と同一)
GearDownMode : Disable(デフォルトと同一)
BankGroupSwap : Disable(デフォルトと同一)
uOpCache : Disable
現在memtest10回(HammerTest有)を始めた所 >>457
見本にしますのでスレチでない情報の提供をお願いします >>456
自己レス
ソース
＞Ryzenのメモコンはサムスンチップ、特にサムスンB-dieチップとの相性が一番いいそうだから、その可能性は十分にある
http://www.legitreviews.com/ddr4-memory-scaling-amd-am4-platform-best-memory-kit-amd-ryzen-cpus_192259/6
ページ最後の辺り
Update 03-14-2017: AMD said that they have internally observed good results from 2933, 3200, and 3500 MT/s rates with 16GB kits based on Samsung “B-die” memory chips.
＞(販売店の利益率が50%位らしい)
【AMD】Ryzen メモリースレ 2枚目【AM4】
http://egg.2ch.net/test/read.cgi/jisaku/1493045393/
972 名前:Socket774 (ﾜｯﾁｮｲ 7eec-bwHs) [sage] :2017/05/18(木) 08:53:07.52 ID:WAZKXQUU0
>>965
ざっくり書くと売価28000円のOCメモリだと13000円お店の利益になるんですよ。
GALAXはアホみたいな価格で入って来るんで更に利益率が高い。
メモリばかり売って店やってられるのはそのおかげです。 >>456
自己レス
ソース(続き)
＞あとDDR4チップを世界で最初に出したのがサムスン(DDR4の規格がまだ確定してない時期に出したりしている)なので、デファクトスタンダードになっているのかもしれない
前田真一の最新実装技術あれこれ塾：
第1回 DDR4 (1/3)
http://monoist.atmarkit.co.jp/mn/spv/1211/09/news014.html
＞その割に自作界隈でサムスン純正DIMMをあまり見ないのは、最近はHynixやマイクロンより仕入単価が高いらしいのと、
価格.comで例えばDDR4 2400 8GBで価格の安い順でみると、アーキサイトのメモリ(型番の末尾-S)はヒートシンクなしの中では高い方な事が分かる
かつ他社はHynixかMicronのチップ使用品しかない
これらから推測した
＞現在の主な国内代理店がアーキサイトというマイナー？な会社で取扱店が少ないための模様
(例)
AS-2400D4-8G-S [DDR4 PC4-19200 8GB]
取扱店 2店
http://s.kakaku.com/item/K0000972845/
他にも価格.comでメモリでARCHISS(アーキサイトのブランド名)で検索してみるとほとんどの製品が2店だけの扱い
あとは尼と、楽天でアーキサイト自体が販売しているのと他の店舗数店が扱っているだけ
自作パーツ店での扱いは無い 「らしい」とかは間違いを指摘された時の保険だよな
セコいわ >>445
メンテナーかもしれんが、メンターではないな
ディスポーザブル部品でしかない Twitterですら本人に直接言えず
ここで匿名でsatの悪口言うだけなのも
相当セコいよねｗ Twitterの時点でブロックされたら終了な件について
まあ誰かは突撃しててもおかしくはないけどどうなんやろ 過去キングボックス、ゲイル、ウィンチップ、スーパータレント等変なメーカー使ってきたけど
流石にアーキサイトは使ったことない セコいのではなくて、関わったらあの水準だと思われるのが嫌なんだろ… >>466
本人にブロックされたら誰にも読まれない程度の器だってだけだろ、お前さんFF内2桁以下かい？ 使う気がない奴は巣から出てくんな
一般論を言っただけで罵倒とかどっかずれてないか？ 頭おかしい人なんだし可哀想な目で見てあげよう？
ただ巣から出てきてほしくないけど 寄付は歓迎するぞ（オリンピック選手村の木材的発想） 自分は広く情報提供を求めただけ
ソフトウェアのバグではない
FUD呼ばわりするなら実名出せ
って色々ひどいなｗ
炎上させるようなハッシュタグで盛り上げてCPUのエラッタだと決めつけたりしてたじゃないか。。 バトルと称して文句いい続けて個別対応を引き出したことが貢献か。ワイドショーでよく見かけるアレ？ なんかひでーことになってるな。自業自得と言ってしまえばそれまでだが。
> I believe it contributed to get the response from AMD that they started to handle us one by one by support request(message#95).
なんで彼の実績になってるの…この後の連投で amdmatt があのスレッドを見放しただけだろうが。大丈夫か？
https://community.amd.com/thread/215773?start=95
> It's OK for AMD to sue me if there is no problem in Ryzen platform and they regards me as a FUDer.
訴訟上等ってすごい覚悟。あの環境で問題がないことと FUD やっていいかどうかは別問題だろうが
っていうか、前スレだったかを見て訴訟起こされることに怖気づいたか…
ここに団子氏が出てきたのと、やたらと激しい言葉を使う人が出てきたのはフラグ？面倒くさいなもう… >>476
同意だわ。
>FUD呼ばわりするなら実名出せ
>炎上させるようなハッシュタグで盛り上げてCPUのエラッタだと決めつけた
逆に実名で根拠も無くよくこんなことできたよなｗ
こいつは炎上狙いだったのは過去ツイ見ればわかるし今じゃ往生際が悪く見苦しいだけ
さっさと土下座しとけ >>459
自己レス
memtest10回はOK
16GBだと11時間程かかった
昨日は作業時間が取れなかったのでUbuntu16.04.2LTSで連続ビルドして放っておいた
10時間程でSEGV出ていた
おま環の可能性もあるが、サムスンと似た時間で出ているので16.04.2LTSだと色々古いのもあってこの位が限度なのでは？と考えている
今日辺り17.04に入れ替えて連続ビルドしてみる予定 > Ryzenのフォーラムに入ってきて一人で暴れてる
> 2ちゃんねるの人、自分とAMDを同一視してる
> ような口ぶりなので、実は日本AMDの関係者では。
> 私にはAMDの人というより2ch世界しか
> 見えてないように見えました。
> AMDコミュニティの過去の流れとか一切無視して
> 自分のことばかり話してるので
お前ら言われてるぞｗ >>482
笑わせてもらったわｗ
>AMDコミュニティの過去の流れとか一切無視して自分のことばかり話してるので
これsatと数名はハードウェア構成など他の見方も一切無視、決めつけて掛かって完全自爆だよな
あとこれか？「宗教的狂信者」とか出してすでに逃げに入ってるがｗ
結局単純な批判しか出来ないｗ
https://twitter.com/n_soda/status/890733709938249728
コミュニティコピペ
sat on Twitter: "詫び石欲しい方、やり方教えます from sat@Ryzen SEGVエヴァンジェリスト"
sat on Twitter: "@mhiramat とりあえず向こうが同意してきて詫び石送ってきたらSEGV Battleまた執拗にやりますよ。このまま幕引きされてたまるものか"
sat on Twitter: "用語集 ガチャ→Ryzenを買う 当たり→SEGVを出す 確変→SW/HW構成、設定変更(定格内に限る)により当たり確率を上げる おかわり→当たり石を次の石と交換 詫び石→本競技のゴール。errataと認…
過去ツイ他にもあるがこれな
信者でなくてもFUDに見られるわ、その自覚が無いところが完全にゴミ
ジョークで逃げようとしてるが、社長直訴までしてジョークなのか？
土下座以外道はない 何ヶ月も暴れまわってるのに今更考え主張変えるのはプライド的に許さないでしょ
永遠に暴れまわるか逃げるかの2択だよ まあAMDが個別のチケットでお茶を濁し続けるのではなく
公式に何かを発表するなど具体的アクション起こすまで
こういうウルサイ人が何人かいることは悪いことじゃないんじゃないかと自分は思うけどね Intelでも発生した時点で「コードが悪い」「大衆向けCPUがそもそも悪い」で終わりの件だと思ってたがだいぶ燻ってんな
・メインストリームCPUに安定性求めるのがそもそも間違い
・安定性求めるならEPYC、XeonとECCメモリ使え
だとてっきり思ってたが違うんかこれ Intelすら定格メモリしか標準サポートしてないのにXMPでしか出てないDDR4-3200サポートとか気前よく書いてこのざまだから問題なんでしょ >>481
乙です。しかし、Micro-op Cache 切っても 10時間かー
この前の記録 12時間でしたっけ？かなり渋い結果ですな >>487
SEGVはメモコン限界からくる悲鳴疑惑が上のほうで検証されてるので読んでみてください >>490
11時間にわずかに届かず、が最高
とにかく今はできるだけそちらに近い環境にしてどうなるか確認したい
17.04はもう少しお待ちください uOP cacheの不具合とメモリタイミングの問題は別問題でいいわけね
いずれにしてもAMDとろいわ AMDのコミニュケーション不足が最大の問題だわ
こんなんでサーバー分野でIntelからシェア取ろうとか言っても
ユーザー企業でこの状況眺めてる技術者は不安で導入推奨できんやろ >>491
筋の悪さ見極められないんじゃ、どのみち先はない >>492
読んできた。なるほどメモコンか。
SEGVが発生する負荷環境は想定外ってことなんかねぇ
そうするとB2ステッピングでメモコン周りに修正が入ったEPYCでは発生しないかも…なわけだな 向こうのほうが解析進んでいるくさいのがな…出遅れた感
名指しされたついったー界隈が露骨に反応していてあれじゃあ思うつぼだろう
>>496
まさかの大騒ぎ陣営大逆転あるかもよ？笑 >>497
>>446 読んでー。ここでの流れは過負荷関係ない >>499
どうも勉強不足っぽいので教えてほしい
「負荷をかける→その状態で特定のメモコン設定だとSEGV」
で、「そもそもデフォルトの設定がキツキツ」
と読み取ったんだが違うか？ >>490
Ubuntu 17.04(apt-get update/upgrade)とMainline Kernel 4.12.2-041202-generic を入れられた
(Kernelは4.12.4まで出ていたがとりあえずそちらと同じにした)
gccは6.3.0 20170406(入っていたもの)
これでKernel4.11.7(make defconfig)の連続ビルド(make -j 16)を始めた
結果出たら報告する >>500
問題はメモコンがきつきつだからSEGV検証してなくても通常使ってるだけで劣化が速く進む可能性があるということでわ
検証した方はもうautoタイミングじゃ起動しないんだっけ >>505
イミフ。
459 Socket774 (ﾜｯﾁｮｲ 7e63-TFS8) sage 2017/07/27(木) 07:52:35.84 ID:vW611gt/0
>>(サムスンメモリでは起きない現象) >>506
それはtRFCをAuto以外にするとメモリトレーニングに失敗するという現象がサムスンメモリでは起きないという意味
ちなみに両方とも俺の書き込み >>507
ワッチョイ同じだからわかってる。
あー、そういうことか…トレーニングね
おk >>500 >>503
1度は丸一日問題がないほどには安定させられたのだがなー
最初の状態ではまともな安定性は得られなかったよ。わかったのは、
各社の M/B があまりにも異なる設定をデフォルトにしている、
XMP どころか SPD すらまともに読まないものが当たり前に存在する (ASRock A320M が実際そうだ)、
周波数を落とすとでたらめな値が設定されたこと (これが最初にまともに動かなかった理由)
あまりにもきつい設定を食わせると、どうもダメージを受けるようだということ
(CPU なのか DRAM のどちらかはわからないが、昔の緩さではもう動かない)
安定性は DDR4 固有のパラメーターに依存していて、設定だけで報告されている問題を再現できること
3行にまとまらなくてすまん。元々定格が
Dual Channel/Dual Rank: 1866
Dual Channel/Single Rank: 2133
Single Channel/Dual Rank: 2400
Single Channel/Single Rank: 2667
これなのだから期待などしていない。PRO版は余裕ができるらしいが、
現状、2枚刺しで DDR4-2400 を安定運用させられれば御の字かと。
元々 DDR4 は制約がきつすぎてよく動いているなーレベルの規格だし、
M/B の品質が悪いことに対して AMD が文句言っているあたりなんだかなーと思う。
https://www.pcgamesn.com/amd/amd-ryzen-memory-compatibility
メモリーコントローラーや AGESA に文句つける人がたまにいるが、
定格が Intel に劣っていたとしても定格は定格なのだから、その先は自己責任、
AGESA は…ただ Microcode と設定するエンドポイントを提供しているパッケージにすぎない。
M/B が好き勝手な値を設定していることについてはボードメーカーが責任を負うべきかと ThreadRipper や EPYC に対してはあまり悲観していない。何しろ後発だからなあ
いまいちわからんのは AMD が全く何もアナウンスしないことと、
Intel XMP が事実上の標準になってしまっていて、それに依存している DDR4 大丈夫？ってのと、
周辺の構成も見直す能力のない連中がこれを Errata 扱いしていることだな エラッタかBIOSのバグかリファレンスデザインのミスかなんてユーザーにはどうでもいい
安定して動く
これが重要 >>512
そういう考えならおとなしくお金を払ってintel選べばいいだけじゃん 最大メモリー速度 2667MHz と公式サイトにも書いてある >>513
AMDが返金保障してくれるならそれを望む人もいるだろうね エラッタ探しするなり、安定化の努力をするなりでない話題はどっかでやってくれっていう… 初もの買っといてその言い草はねえな
安定しか求めないなら枯れてるインテル選ぶのは当たり前 >>516
なぜそこまで頑なにエラッタではないという結論にこだわるのかがわからない
安定化の努力にエラッタ究明を含んでも何も矛盾はないのでは >>519
起きない現象に対してどーしろと。わざとまたきつくして、実証コード書けと？何のために？ 糞団子ちゃんガバりすぎｗｗｗ
ウソ
大げさ
紛らわしい
試験のためのコードは書けるだろうが、出遅れたっぽいからなー。惜しい…
そこまで労力かける意味あるのかわからんっていう >>520
問題がなければ無理に検証する必要はないのでは
SEGV及びフリーズ、リブートなどで運用に差し支えがあるから仕方なく検証してる人や、SEGVの仕組みに興味があって検証してる人などいろいろいると思います
モチベーションについては人それぞれなので、私からはなんとも言えません >>523
そうさせてもらうよ。先にスリープからの復旧時の BugCheck を解決したいので >>523
そんな奴は極々一部だよ
ユーザーの1%位じゃないかな 一部だから何だと？
多数はWindows使っててLinuxでコンパイルなんかしないから黙ってろとでも？ 頭悪そうなキレかただねｗｗｗ
ガバりすぎ糞団子ちゃんみたいｗｗｗｗ なお、この途中経過のために 3,000回 Linux Kernel を make したっていう。
過去の総計を一桁は上回ったぞ笑 >>526
そうだよ。当たり前じゃん
君には関係の無い話だからね >>530
じゃあ君はこのスレに関係ない人だから率先して黙るべきだねｗ >>502
自己レス
12時間越えたがSEGVはまだ出ていない(自己新記録)
引き続き回しておく
>>428の
＞なんでそちらはうまくいかないんだろう？
は、ディストリ・カーネルのVer違いが問題だった事が分かった
(カーネルだけでも伊達に70回以上VerUpしてる訳ではないという事か)
これで130氏が提示したサブタイミングでのSEGV回避を本人以外で再現できた事になる
(これが重要)
環境を再度書いておく
M/B : ASRock X370 Taichi (BIOS P3.00)
CPU : AMD Ryzen 7 1700 定格,Microcode 0x8001126 (AGESA 1.0.0.6a)
FAN : Thermalright TRUE Spirit 1366+同TRUE BTK+Ainex CFZ-120LA
RAM : Crucial CT8G4DFS824A.C8FBD1 8GB DDR4-2400 SR UDIMM x2 (17-17-17-39) @ DDR4-2400 1.2V
(CFD W4U2400CM-8G として売られているもの)
パラメータは>>459
ディストリ・カーネルは>>502(追試する人はこの環境を推奨)
ASLRはON、uOpCacheはOFF
Mainlineカーネルの入れ方は以下を参考に
http://ubuntuhandbook.org/index.php/2017/07/install-linux-kernel-4-12-in-ubuntu-linux-mint/
wgetする.debファイルのURLは以下で確認の事
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.12.2/ 新しいRyzenでピタリと現象が止まった時の反応が楽しみだ EPYCはどうなんだろうね
私はお金がなくて検証できませんが誰か試してるのだろうか >>532
自己レス
19時間以上経過したがまだSEGVは出てない
この環境はこのまま継続する
次は1500XをuOpCache切れるM/Bに載せ換えて追試第2弾
あとRyzen3を購入して新品でどう動くかの確認
M/Bも新品を用意しBIOSも1500X等であらかじめ1.0.0.6以上にUpしてサブタイミングも設定しておきメモコン壊さないようにする
Ryzen3でSEGV出ないならRMAを検討 サブタイミング設定で回避できたという事の証明ならopcache有効でやらないと意味無いような Op Cacheがバグってること（少なくとも個体レベルで不良があること）は誰も否定できてないな >>130
>>204
>>291-292
辺りを見ると分かると思うが、LinuxとRyzenの両方が問題を抱えている
現状ユーザーができる事は「出にくくする事」(自分はこれの事を回避と呼んでいる)まで
uOpCacheを切っているのも出にくくする事の一環
「出ないようにする」事は現状出来ずLinuxとRyzenのAGESA修正待ち
修正されればuOpCacheをONにしても問題なくなる AGESAの修正「キャッシュ無効にします」
の可能性も ここまでがユーザの限界ということだろうか
SEGV問題が気になるならサブタイミング緩くしてAMDの対応待つしかないわ >>543
俺は解析はしてないんだが？
お前にお疲れ様なんて言われる筋合いもない
130氏に言ってみろよ freebsdとdragonfly でスタックの位置をずらすだけで安定することを考えるとlinuxのバグは考えにくいだろ。 >>539
uop cache 無効で再現報告があるので十分では？ メモリータイミング緩めればメモコンによるSEGV発生確率大幅に減るからuOpCacheからくるSEGVも解析進みやすいのでわ
メモコンから来るSEGVはマザーボードメーカーのせいだとしてもuOpCacheはryzen側のエラッタと言えるし >>547
>>280
>>204
>>233
辺りを読んで
あとは130氏に直接どうぞ >>545
こいつはオウム返しのようにこれしかいってないから放置安定 uop cache切っても落ちるので提案された定格値で動かしたら安定したってだけでなんで責められているんだ？
その状態でuop cache ONにしてどのくらい動くのか教えてもらえると参考にはなるが。 >>553
130氏が常駐してる時はもう一つのスレでコソコソしてた根性無しのくせにな
ネチネチ重箱の隅をつつくしか出来ないカスが >>554
何がオウム返しなんだ？
お前に相手してもらう必要もないが >>554
もしかしてアンカ間違いか？
だったらスマン >>559
こいつ(>>553)はオウム返しのようにこれしかいってないから放置安定
という事だったのね
本当にスマン >>555
>>543 = >>553はこのスレ当初からいる荒らしのネチネチ重箱の隅野郎
130氏のようなホンモノがいる時だけ他のスレに逃げている根性無しのカス
ワッチョイあるのに自演バレバレのアホ
で、uOpCache ONはやる予定なんだけど、まだSEGV出てなくて(今28時間)、出なければ1週間位回したいのでしばらく後になるかも >>562 ああいうのは放置でいいんじゃね。
時間かけて試行錯誤しているのは130とあなたくらいのようだから乙としか。 >>563
放置についてはその通りなんだが、130氏がいなくなったと見るやこっちのスレに来やがったんでね
自分はスキル的に追試しか出来ないので130氏の手伝いの足しにでもなればと思ってやってる
役目が終われば消えるだけの名無しだし >>550
しね、嘘つき殺されろしね、殺されろ殺されろ何度も殺されろしね、嘘つき殺されろ >>564
追試が本当は大事なんだよ
STAPの時に皆学んだはずだ、追試しない科学的検証はありえないと
で、大本の問題を追試するに「科学的検証に足る試験条件」ってのはどこにあるのかな？
私は貴方方の見事なまでの試験と追試に感謝する。 科学的検証か。面白い視点ですね。追試本当に重要。本当に 564氏に感謝
私と、追試に参加してくださっている 564氏の目標が、安定した状態を得るところなのは大きいんじゃないかな。
皮肉な話だが、匿名なので売名目的にならないし、謝罪と賠償を望んでいるわけではない。
ここまでの経緯では特別なことは行われていないかと。
このスレッドのタイトルにも含まれている「おま環」がそれを端的に表している。
目の前で起きている事象を全ての環境で起きるはずと断定してかからずに、
もしかすると自分の環境がおかしいのではないだろうか、何を疑うべきなのだろうかとしているだけ。
他の環境での動作との差異を探しつつ、問題が起きる条件を狭めると同時に再現させる方法を探し、
パラメーター、試験手順まで含めて詳細な情報が共有している。このことが追試の容易さに繋がっていたら幸いだ。
そもそも巨視的には変化させられる条件として OS は何か、CPU 以外の構成は、設定は…程度しかなくって、
観測できる事象は恐ろしいほどの複雑さに対しては、例外が発生した、MCE が報告された程度のものしかない。
そのため、試行が意味を持つために必然的に外乱要因の排除が最優先となってしまった。
現在の状況は、まず BIOS はアップデートしておけ、定格で動作するか確認しろ、メモリー周りは影響が大きいようなので見直せ、
OS は Linux なら Kernel 4.8.0 ではなく新しいものを使え程度だが、当たり前の話だと思っているよ。
ようやく試験環境が整ったといったところか？ メモリーコントローラー決めつけってたまに言われるが、これを途中経過として他の問題は何もないとは断言していない。
あちらの socket774氏が先行っているようなのでモチベーションわかないのと、
もう十分安定してしまって関心が Windowsに行ってしまったのだが、そこのところはご勘弁を。
http://www.sci.kyoto-u.ac.jp/ja/academics/programs/scicom/2015/201602/07.html
> 科学を科学たらしめているのは導いた結果の正しさではなく、その導き方であると言えます。
長くなったが三行でまとめるならば
・誤った目標は誤った結果を引き起こす
・断定より先に検証と過程が重要である
・声の大きさではなく何をもたらしたか
といったところかねー。もう130を名乗るのも終わりにしようっと >>568
ありがとう
確かにその点は思い浮かんでて(STAPは縁起悪いからIPSの方だったけど)、せっかく130氏が色々提示してくれたのに第三者の再現事例がないと説得力が落ちてしまう懸念はあった
結果的に再現できたので良かったが、自分は見事とは言えないと思う
(130氏は見事です)
130氏の環境のAGESAが1.0.0.6で1.0.0.6aにVerUpしていない事には比較的早く気付いていながら、ディストリ・カーネルのVerには気付いていなかった
もっと早く気付いていればもう少し早く再現できたかもしれない
あとここまで来れたのは自分だけの力ではなく、スレ当初から色々な形で協力してくれた数多くの方々のおかげです
(初めはSEGVの出し方も分からなかった)
改めてお礼を申し上げたい >>570-571
130氏に再現できた事を見てもらえたようで安心した
(なお現在41時間越えた所)
こちらこそ感謝しきりです
現状ユーザーにできる事が「出にくくする事」、「出なくする」には修正待ちという指針と、出にくくする具体策を示してもらった事、AMDに修正のアクションを行っているという事で気分的には随分楽になった
第三者再現できた事で130氏が見当を付けた原因の確実性はより高くなったと思う
自分は追試を続行するけど、引き続き名無しで行きます
この問題の早期解決にわずかでも役に立つ事が出来たとしたら幸いです >>571
メモリのパラメータを適切に設定すればメモコンorMemoryを傷めずに済むのが分かって助かってる。
ありがとうございます＆お疲れさまでした。 >>537
経過報告
3日+12時間(84時間)(3060回)達成、さらに続行
スクショは今回からuptime入れた
uptimeは連続ビルド時間+約3分
http://i.imgur.com/XRnLNbN.jpg 適切なパラメーターで動作させると当たり前だと想定する動作が得られる
当たり前のことなんだけど、MBメーカーはそれができていなかった
今後、改善が広がるんだろうけどね マザーボードメーカは新製品かリビジョン上げて対応してくるのかな 既存M/BのBIOS設定変更でエラー出なくなるんだから
デフォルト設定値を変更したBIOS提供するだけで改善するだろ 新規購入を考えている身としては
BIOS update済みの方がありがたいんだけど >>582
購入時にBIOS最新化してくれるショップを使うという手もあるよ >>583
そういったサービスしているショップありますね
マザーボードメーカの更新情報をしばらく眺めておきます
情報ありがとう tWTR_SやらtWTR_LやらtWRやらtCWLやら
呪文か！！！！！11111111 ええと、現状を整理すると
・メモリタイミングに起因するものはMBメーカーのチョンボ、今後は改善して行くかも？
・それとは別に、RyzenにはLinuxカーネルが触ってしまう秘孔があって、カーネルへのWorkaroundのマージ待ち
で合ってる？ やっとAMDが調査を始めたか。RMAで解決すると思ってたら交換品で想像以上の不良率だったので焦り出したな。 やっと動いたというより130のAMDへの報告が実ったのかね >>589
お薬の飲み忘れでちゅか～？
だめでちゅよ～？ 見当違いの恥ずかしいsatと周辺
スレッドリッパー発売で急に騒ぎ出す
ほんと状況理解できず頭悪いよな、こいつらｗ
https://twitter.com/satoru_takeuchi
土下座以外道は無い >>576
経過報告
4日+15時間(111時間)(4043回)達成
一旦止めてuOpCache ONで再度開始した
(それ以外は変更なし)
スクショ
http://i.imgur.com/OVU79lM.jpg >>594
状態わかって原因わからないって頭悪すぎませんかね、、、 環境を明示した安定動作が例示された今、
騒ぐだけで冷笑の対象になると言うのに…
勘違いでした！あはははーとか言ってトンズラしちゃえば良いものを
uOPの話にするなら問題の切り分け位はしろよ 皆勘違いしてるけど、規格準拠品のメモリで定格動作しないなら不良品だよ
メーカー動作確認とはあくまで箔付けであって、公式に準拠が問題になるのは規格の方
定格の値が攻め過ぎてるなら誇大表示だし、定格が妥当なのに個体によって問題が出るなら不良品 >>600
メモコン関連のサブタイミングはマザーボードメーカーの調整でメモリー関係ないだろ？
SEGVの一因はメモコン周りのサブタイミングなのでそんな当たり前の話はメモリースレにでも書いとけよ メモコン痛むわけないだろと思っているやつは130が言ってた起動限界定格で試してみるといい
なお、メモリは無事だった。ここまで来ると道楽でしかないｗ
http://imgur.com/a/pLGCC >>595
経過報告
5時間強でSEGVが出た
手持ちの1700は残念ながら現状uOpCache ONでは使わない方が良いようだ
uOpCache OFFで再度回しておく
スクショ
http://i.imgur.com/IvbVVuY.jpg >>592
なら、お前は大概嘘を付いているようだが、死ななくていいのか？ >>603 お疲れ様！残念でしたね。
もう再起動かけてしまってそうだけど、syslog に MCE 報告などは残ってない？
>>605 いちいち煽るな… >>607
ありがとう
dmesgはチェックしていたがsyslogはチェックしてなかったので見てみた
発生時刻頃にx86_64-linux-gnu-as(アセンブラ？)が原因のgeneral protection error というのはあった
メモコンエラーっぽいのは見当たらない
今度からsyslogもチェックするようにしてみる
>>602はメモリ容量が大変な事になってるね
怖すぎる >>608
ちなみに今の試行に入る前の BIOS デフォルトだとどんな結果でしたっけ？ >>609
1700の方(経過報告してる方)はマイクロン2400メモリはBIOSデフォルトは試してないので分からない
実験中の1500Xの方(最近は報告してない方)でサムスン2133デフォルトでUbuntu17.04+MainlineKernel4.12.2で約24時間でSEGV発生という結果はある
uOpCache・ASLR共にON
syslogも見たがメモコンエラーもgeneral protection errorもなかった >>595 が平均 1:39
>>603 が平均 1:38 か メモリが全てではないが、影響は大きいなあ
> ようやく試験環境が整ったといったところか？
やはり、これだな… Twitter にもここ参照して頻度落ちた報告ちらほら出てる uop cache 無効で4日もやってたのか、椅子からずっこけた。 もう意地でもryzenが原因だと訴えないと死んでしまう奇病でも煩ってんのか？ uop cacheとかいう設定が付いてるのは回路設計が怪しいasrockだっけ？
比較的にましなのがMSIとbioか
うちは出ないで自信ありますなのがGIGAか 回路設計関係ないだろ。130はあの組み合わせをどう解いたのかわからないが、
uop cacheを無効化するのは、Linux Kernelを一日中ビルドするワークロードにおいて、
現時点では最も確実な回避策であることは確か。
数分で落ちるだの、uop cache切ってもどうこうは意味がわからないが。 >>616
Core i9に比べたら、はるかに良い。 >>616
死ね殺されろシッタカ糞団子死ね殺されろ早く死ね何度も殺されろ >>616
お前には関係ないんで巣に帰って、どうぞ 一番問題視することは、2ch を含む有志によって問題に対する「対応方法」が見いだされている点。
メモリのアクセスタイミングに問題があったのは事実だし、μ op cache を disable にしてコンパイルすると、
セグメンテーションフォルトが発生しないでコンパイルし続けることが出来るという事は、関連する箇所、
Ryzen 内に問題があったのも事実でしょう。
他、SMT 関連がストールするのと関連して %rip がずれたり、CPU #0 をよけてコンパイルすると問題が軽減したりと、
色々と「おま環」ではなく、Ryzen そのものに、AMD が公表していない問題があるのは、公然の事実でしょう。
AMD が自社の売り上げを大切にしたいのか、これらの問題を公表せず、沈黙を続けている事へ
怒りを向けた方がいいと思いますよ。
結果、全ての AMD ユーザーを大切にしていないわけですから。 初期BIOSなんてBIOとMSIの惨状を見ればメモリタイミングをAMDがコントロール出来るような状況じゃなかったのはわかるだろうし(実際現在のBIOSではかなり改善されている)μOpCacheについても確定的ではない。
まさか企業に不確定な情報を根拠に謝れと？ >>623
忘れてるようだが、別にAMD叩くためのスレじゃない。
対応方法が見出されたからって、なぜそれを叩く材料にしたがるのかわからん。
被害者意識があるなら直接AMDに連絡したらどう？
ちなみに、カーネルビルドやらとは無縁なうちのPCに対しては、とりたてて怒りも抱かない。
なぜなら、いまのところデフォルトのままで問題出てないから。 今のところ問題が起きてなくても、いつ起こるかわからないし、実は起こってて気付かないだけかも知れない
実は保存データが化けてましたとか とはいえ、実際問題としてアクションが無すぎて不安になるのは事実
もう報告され始めてから三ヶ月ぐらいたつだろ？
謝罪とかはどうでもいいが、今現在どういう状態なのかアナウンスするべきって話は分かる
調査が難航してるならそれはそれで仕方ないし、そうならば調査中だからもう少し待てって言ってくれるだけでだいぶ違う
ユーザーがあれこれテストしたって中身はブラックボックスだからAMDしか詳しいことは分からんのだよ 何が怒りだ。建設的な行動を取れよ。
お祭りのせいでしばらくエンジニアと連絡取れなくて困っていたのだが、何正義ぶってんの？ 確実に言えることは祭りのせいでかなり問題の原因をこちらの狭めた報告すら放置されたこと。
それで対応策がどうのこうの怒りをどうこうってふざけるな。この状況を作ったの誰だよ では建設的な行動とは具体的に？
いちユーザーにできることは色々テストして一時的な対症療法を探るぐらい
それはもうそろそろ煮詰まってきたじゃないか
じゃあそろそろ公式のアナウンスを、という頃合いだろう
お祭りのせいでエンジニアと連絡取れないってのもそもそも分からん
社員数人とかの中小企業じゃあるまいし、そんなもの社内で取捨選択して適切な部署で適切に処理すればいいだけじゃないか
こまめに公式からアナウンスあれば、じゃあそれに従って待つか、ってなるだけの話
アナウンスが無いからユーザーが各々バラバラに、遠回りな試行錯誤と議論に明け暮れることになってるんじゃないか >>628
認識することと怒りを向けることが同義だと？
認識してるから、ことの顛末をと思ってこのスレ読んでる。
だからといって、とりたてて怒りを覚えない。
思想運動みたいな言動で煽られても、プラカード持ちに加担するつもりはない。 おれはLinux Kernel開発者ではないが、見当つけて頻度を落とすパッチくらい提供できるわ
その程度もできずに祭りやるくらいなら黙っていてもらいたい。ワークアラウンドであっても公表が遅れて迷惑するのはユーザーなので このスレッドは本当に参考になった
ここ以外は意味不明な報告ばかりだったが、見当をつけるのに参考になった。本当に感謝 最初に本スレとかに出張したりTwitterで暴れたりで叩く素材として仕向けた時点で
建設的もクソもないからな
結果や対策だけ報告してる人以外 ていうか本物のlinuxkernel開発者様ならパッチの一つでも作ってやろうっていう建設的な方向に行くと思うんだよね
なんであんなFUD見たいな騒ぎ方したんだろう >>629
実態のない恐怖を語られても、それはこの問題に限ったことではなかろうとしか。
むしろ、なぜカーネルコンパイル以外の事例が未だに出てこないのか、のが不思議。
ホビー以外で使ってるユーザーだって、沢山いるだろに。
カーネル問題を知らないユーザーからでも、なんらかの不具合報告があってもおかしくないと思うが。 >>633
> お祭りのせいでエンジニアと連絡取れないってのもそもそも分からん
騒いでフォーラム潰してたじゃん AMDに怒りを向けましょうというよりコミュニティでいい加減な報告して暴れるだけ暴れた連中のほうがムカつくわ
結果AMDに見放されて半分放置気味じゃないか
対応策出た今こそAMDに報告する形を取るべきだった >>639
カーネルコンパイルに限らず、
gccを使った大規模なビルドではわりと何でも起こるようだが？
gcc以外でのビルドで起こる報告も無くはないが数も少なくて信ぴょう性に欠けるところがあるのでひとまず置いておくとして
なぜgccでのコンパイルで起きやすいのかまではなかなか AMDからの公式な声明は欲しいな
組んで数ヶ月経つけどSilent Data Corruptionが怖くてまだ実戦投入出来てないし
これさえ解決すれば完璧なまでの現行最強CPUなのにもったいない l|ヽ= 从;;l |l|;;ll;;;;;l|;;;;;l;;;ｲl;;;;;;;;;;;;;| l|;;;;;;-〈､|;;;;;;;;;;;;;;,,三∠ノ ﾌ な 地 イ
ヽﾐ三从;;从|;（;;;;|l;;;;l|;;;（（;;;;;(ヽ乂;;;;;;／ﾉ人､从;;;;;;;;ヽ ∠ | ま 獄 ン
ﾐ二ミﾐ从 ; ;;;;;;ﾞ;;;;ﾞ;;;;;L{{ミ|Y;;";;;;;rﾃ'';''iﾞ''ミﾞ ｲ;;;;{ミヽ∠ﾉ ぬ す テ
ﾞヽ乏ﾞﾞ从ﾞ ;;ヽ､､_;;;;;;;;;;;;;{≧Y;ﾉﾉ=-ﾞ'''"´彡 ';;;;;;ヽﾞ,,', ヽ る ら ル
＜彡l|;;;;;;;l､;}:/;r't;;;)＞| 彡￣""´ |;;;;;;〈 |.| } い に
ノノｲ;;;;;;之"ﾞ"''"´ |､ _,,､::::: |;;;;;ノﾉﾘ;∠ // . は
ｲ彡l|;;;;ヽ ﾞ:::::::: j _,､ -)ﾞヽ::... |;;/- /;;/ミヽ ・・
l|//l|;;;l~､'､ :::: ﾞ''::ヽ,／ |（,,ノ;;;ヽ〉ﾐ/
ﾘﾉｲ;ヽヽ'､ ｀ﾞ'､l__,,､､､,,_,, / l||;;;;;;;;|∠＿
"´ﾉ|;;;;｀'-;', (t -'''ﾍﾍ)}} ﾘ ﾘ;;;;;;;/从ミ | ／￣＼/＼／￣＼
|/l|;;;;;;;;ヽ ﾚ- '''""´ /:::" {;;;从;;;;;;;;）"
l|l||;;l|;;;;;;;;'､ ,,､;;''";;￣:: ,/:::::" ヽl|ﾘ;;;r''､ﾘ
ヽl |;;;;;;;;;＼ " ｀ﾞ ／::::::" ﾚ',､-ｰﾞ''""ﾞ''ｰ､ ,,､- ''
/／|;;;;;;;', ＼ 〈 ／ ::::::: ,､ '´ ﾞ'> ''"
（从l|;;', ヽ, ヽ:::ノ／ :::::: ,､ '´ ,､ '´
｀ﾞﾞﾞ''', ﾞ'' ｰ '''" ::::／ ／ >>642
コンパイラで起こり得る問題ならば、他のアプリケーションでも当然起こり得る。
他のアプリケーションで発生の報告がなく、GCCでしか起こらないとなれば、それはGCCの問題と考えられる。
しかし、他のCPUでは問題なく動いているとなれば、これはもうGCCの開発側とAMDの開発側で共同調査するしかないと思われるが。
個人的には、GCCを使わないうちの環境では、使用に際してもう無視してよい問題ではないのか、と思えてきている。 幾ら何でもAMDはダンマリが過ぎるよねぇ
一部ユーザーが頓珍漢な指摘をしたとかしないとか騒いだとかどうとか関係なく、
これをそもそもAMDは不具合と認識しているか、個別のPCのケース内過熱か品質の悪いメモリか何かでしょ程度に思ってるのか、
エンジニアが動いてるか否か、今どういう状況かくらいはオープンにしないと
公式フォーラムもブラストレーション溜まってる人がだんだん多くなってるのありありとわかるし
企業の対応として下手すぎる >>645
他のアプリケーションで発生の報告がなく、GCCでしか起こらない、とまでは言い切れない
単にコンパイラのシェアの問題で声が大きいか少ないかだけのような気がしないこともない GCC落ちるっても特定の場所でSegfaultする訳じゃないのが怪しすぎるんだよなぁ
マルチスレッドのソフトでもないのに あとはまあ、GCCで起こるんだ、じゃあ俺も試してみよって感じでGCCしかあまり試されてないか しかもさ、GCCでビルドしてたとしても、落ちるのがGCCじゃなくてbashだったりするじゃん
GCCそれ自体の問題でもなさそうなことは示唆されるわけで たまにsage忘れるのは申し訳ない
最近2chのUIが変わって使いにくくなった 130はWindowsでは関係ないメモコン壊れたら除くというスタンスの発言してるからWindowsユーザは関係ないと見ていいと思うけど Row Hammer問題みたいなもんだろ
通らないでも普段使いには問題ない
でも気持ち悪い
あの時のエラーの原因ではと疑心暗鬼になる
OCCTみたいなストレステストが24時間通らなくても問題ないと
考える人間とそうでない人間の違いで意見が違ってくる そら、キャッシュ切ったらメインメモリのデータをその都度参照するから、
間違った値を使い回す可能性は低くなるだろう。
狂ったメモリからの転写ミスで間違った値がキャッシュに残り続けるから、
一見すると固定数なズレが何度も起きるんだろ？ 急にsat,homu,eirakuによる自演がきたな >>647
言い切れないってのは実態がない。
逆にGCC以外でも問題が起こる、とも言い切れない。 >>656
意味が分からん
正しいデータがキャッシュに残り続けることもあるのだから確率的には変わらないのでは？
それにそもそもL1,L2,L3があるわけで、メモリ→OpCacheへダイレクトに転送なんてまずないと思うんだが >>656
uOPs cache有効でも無効でも参照順はL1I→L2→L3で最後にメモリです
uOPs cacheがバグってる以外の理由を考えにくい >>660
Opキャッシュだけを器用にoffしてるのか？ということで、
命令だけをキャッシュに乗せないように制御してるだけでは？ >>662
そんなことはあり得ない
命令を一切キャッシュに載せないなんて暴挙をやったら性能低下が数パーセントなんてレベルでは収まらない ぜんぜんなんのキャッシュかわかってねーじゃねーかｗ
CPUのアーキテクチャ勉強してこいｗ >>648
報告はマルチスレッドでコンパイルしてるときに起こるつーとろうが
一番基本的なことも知ろうとしないで何してんだお前！
この腐れ煽り屋が
>>646 >>648 >>665
gccの中が本当にシングルスレッドなのかまでは俺は知らんが、仮にそうだとして
少なくとも-jxのオプションで起こることは「マルチプロセス」
そんでもってプロセス間のは少なくともユーザープロセス的にはコンテキストが分離されてるからマルチスレッドのレースコンディションは起こらない あっ誤爆したw
>>667
煽り屋は否定しないんだな >>661
死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く死ね殺されろシッタカ糞団子 >>660
uOpがメインメモリ上にある状態ってのが理解できんのだが。
CPUアーキテクチャには疎いんだが、メインメモリ、L1～L3の内容がuOpキャッシュに入るなんてことがあるの？ >>663
じゃあ、そもそもキャッシュの参照の動作が我々が想定しているものと違うのでは？
排他的キャッシュだから、L1～L3の間で同じアドレスは常に1ヶ所にしかないわけで 、
それをタグ検索して探しているからレイテンシが大きめなわけだ。
けど、いくら16MB+4MBオーバーあるとはいえ
巨大なコンパイル作業で全てがキャッシュに乗るってのは無理がある。
おそらく、頻繁にメインメモリとデータの入れ換えが起こるだろう。
じゃあ、 OPキャッシュはというと、OSの最適化で同じループ同じスレッドに固定される傾向があるから、
キャッシュに収まる範囲なら内容の更新はほとんど起こらないことになるので、
間違った命令データがロードされたらほとんどの場合でプロセスが終わるまで変わらないだろう。 >>672
無いね
本来uOpキャッシュとはデコード済みのuOpをキャッシュしておくところ
ただ、RYZENのuOpキャッシュはx86命令キャッシュモードもあるとかで、
L0的に働くこともある模様 Inclusive構成が破綻するケースってつまりそれもバグなんだが キャッシュライン単位で紐付いてて、L1Iに存在しない命令列のμOPsがcacheに存在する事がまずありえない この件が不幸なのは、uop cacheを切っても問題が起きる設定を平気で食わせていたこと、
Linux Kernel 4.8.0なんぞ使って試験してしまったこと、
そもそもLinuxユーザーの比率が低すぎることだろう。
最初の二つの問題を抱えた状況では確かに1時間に何度も落ちて使い物にならない。
そのひどい条件を外すと確率が軽く二桁は落ちて負荷試験でも1日に数回segfaultするかまでになる上、
130のようにどういう計算したのかわからないが少なくとも丸一日落ちない設定まで発見されてしまった
make -j N はNプロセス(目安)での並列コンパイルであってマルチスレッドではない。
ただし、exec*, forkの挙動の違いによりmakeが生成するgcc, cc1, asのメモリマップがASLRによって変わる
ASLRが切られている場合においてはlibc含め多くのライブラリが同一のアドレスに配置される。
これが、ASLRを切るとまた一桁segfaultする確率が落ちる理由
…ここまで書けばパッチ1個書けるだろう。
先に公開するつもりはないので名誉回復したい方はどうぞ
make defconfigが90秒の世界では日に数千万プロセスが生成される。これは通常の負荷ではない。
また、Windowsは再配置可能なバイナリであり、当然ながら異なるスケジューラーで動いている。
自作ユーザーの多くが自分でBIOSをいじれる状況にいて、
大多数がゲームやエンコなど1プロセスの寿命が長い運用であるため問題に遭遇する確率が低すぎる。
それらの目的においては他の要因のほうが大きすぎて切り分けは不可能だろう。
本当に不幸なのはAMD Communityからamdmattが追い出されて
カスタマーサポート経由で粘らないとエンジニアに到達できなくなったこと。
これがFUDだったのかどうかはさておき、同じ結果をもたらすことには成功している ttp://pc.watch.impress.co.jp/docs/column/kaigai/1037983.html
> OPキャッシュはL1命令キャッシュにインクルードされていない。つまり、OPキャッシュでヒットしても、L1でヒットしないケースもありうる。
> ただし、エクスクルーシブ(exclusive)キャッシュとも言っておらず、分離されたキャッシュだと言っている。
> OPキャッシュの大部分はL1命令キャッシュにインクルードされるが、L1からキャッシュラインが排除されても、OPキャッシュに残る場合があるという。
> Intelアーキテクチャの場合は、uOPキャッシュはL1命令キャッシュにインクルードされると見られている。
> OPキャッシュはL1命令キャッシュにインクルードされていない。
> OPキャッシュはL1命令キャッシュにインクルードされていない。
> OPキャッシュはL1命令キャッシュにインクルードされていない。 うちのは1.0.0.6aに上げてμOpキャッシュ切ったら安定したのでとりあえずこれで使うわ
詳しい原因とかは興味はあるけどそれよりも早く運用開始したい まあ、uop cache切って運用するのが無難だろう。タイミングにも余裕が生まれる。
整数演算目的なら性能ほとんど変わらないし、
ECCサポートが有効になるEPYCはまだ先の話だ。 L2やL3は？
命令フェッチはL1I直結なのでキャッシュにない命令列を読もうとした段階でまずL1Iにロードする uOPキャッシュ切っても大幅にパフォーマンス落ちないし気になる奴は切る、でいいのではないかね？
uOPの切り分けで失敗してるならそれこそいずれなんとかなる気がする > 命令フェッチでは、OPキャッシュとL1命令キャッシュの両方をプルーブする必要があるが、それはマイクロタグ(Micro-tag)で行なう。
日本語読む能力あるの？ >>683
死ね殺されろ殺されろ殺されろ殺されろ殺されろ殺されろ殺されろ殺されろ殺されろ殺されろ殺されろ殺されろ殺されろ殺されろ殺されろ殺されろ殺されろ殺されろ殺されろ殺されろ殺されろ早く >>623
お前、こいつ本人だろw
596 Socket774 2017/08/02(水) 08:48:02.98 ID:SkqPVdSQ
私は情報収集していただけで、貶す意図などないことはコミュニティを見れば明らかだよ。切り貼りしないできちんと読んでもらいたい
確かに悪ふざけしていたことは認めるが2chでなくコミュニティに参加してもらえないだろうか？ 中身が公開されて半年経つというのに、まさかアーキテクチャの理解どころかチェックすらしていなかったとは…
ハードの仕様を読まない上に調べすらしないソフト屋…どうぞ〇んで。 >>688
正確にはvictimベースのちょっとややこしい方式の筈
AMDのキャッシュ周りの巧妙さは随一だと思う
それだけあってL0でエラーが起こるってのもよく分からん >>683
お前ホント邪魔
内容追ってすらない上に理解もできてないならレスすんなよ
ここはお前の自己愛の発露場所じゃねーんだよ >>683
とりあえず君はブログにでも書いててくれない？ 問い合わせたら、完全に同一の構成で24時間試験して送り返すとの申し出が。
非常にスムーズなやり取りと真摯な姿勢が感じられる。
1ヵ月前のレスポンスの悪さは一体何だったんだろう… >>696
米AMDに対して詳細な情報を記載して送ったらさくっと返事来た。
結果的にRMAの形にはなる。FedEx着払いで試験は向こうが24時間回すとのこと >>697
RMA申請のページじゃなくてサポートにメールしたという事かな
送ってる間PC使えなくなるのは辛いな
古い環境残しておけばよかった・・・ >>698 サポートにメールした。
戻ってきてからこちらも試験して報告するよ。
1週間くらいかかるかもだが待っててくれ。 つまりRyzenに問題があったのは事実でしょう。売り上げを大切にたいために個別対応では問題が公表されずに終わってしまいます。
2chで問題回避策を探るのではなく、沈黙を続けずに怒りを向けることが全ての AMD ユーザーのためになると思いますよ。
コミュニティに参加してさらなる圧力をかけませんか？ >>700
ついでに試験時のパラメータ群も聞いておくわ。これで問題がさらに狭まると嬉しい
>>701 …。 個別対応で大事にしないって感じか
北米は訴訟大国だからねぇ いや別ステッピングが来るならまだしも、こちらで問題起きたらおれ環になるだろ… >>701
だったら一人で勝手に怒って、２度とAMD製品を買わなければいい。
それでも納得行かないと言うならば、社会的に正規の手続きを踏んで、会社相手に訴訟でも起こせばいい。
こんなところで啓蒙活動してても、なんの解決にもならんよ。 MSI Mateに新しいベータBIOS(A.62)が来たんだけど、やっとuOpCacheが切れるようになった
とりあえずMSI以外のM/Bを買わなくても良くなった さすがに今度は直っているだろう。ステッピングはb1のままでこっそり直したかな。まあ直ればそれでいいが。 素朴な疑問なんだが問題がないはずなのに代理店通さずRMAするってツイカスで暴れてた人とやってること変わらんと思うのだが？
そういう意味でリコール確定なのかと聞いただけだがそんなに嫌な質問だったかね？ やってること変わらないとしてなんでリコールの話になるの？
リコールレベルの欠陥かは人それぞれだが 書いたやつの顔がいかにもイチャモンつけそうな顔だわｗ ただの中二病やろ
中年になって自分の可能性がもうなんもないと解ってくると
孤独に耐えられんくなるで(´・ω・｀) 今のところ
・少なくともCPUパッケージ内に個体による不良があること
・大抵のケースで問題が発生しなくなる条件（問題が発生する条件ではないこと、真の原因とは限らないことに注意）
がわかっていて、今後問題になるであろうことは
・AMDが対応をミスって消費者訴訟沙汰になる可能性（実用上問題にならなくても大炎上し得るのはFDIVで証明済）
・EPYCで発症する可能性（対企業の瑕疵担保責任）
・↑で経営が危うくなる可能性
くらいで、どれも技術的問題というより経営上の問題だな
元々の不良自体は原因箇所さえ分かればAMDのエンジニアがサクッと修正できるだろうし、それはこれ以降の設計にも反映されるだろうから大した問題ではない
完全新アーキテクチャが何のエラッタもないなんてことはほぼないから、エラッタがあること自体は経営上はそれほど問題ない（リスクは織り込み済み） エラッタがあることが問題ではない
問題があることが公開されてない
原因も不明
対策も不明
なのが問題 頻度減らす対策は130が示しただろ
納得できないですというなら知らん
というかもう後はAMDの対応待ちという状況でしかない 根治ではないけど対症療法は確立されてきてるじゃん
これでどうにもならないというなら、風邪も対症療法しかないから医学ではどうにもならないということになってしまう
公式発表がないのは、あちらだと沢山いるなんでもとにかく訴訟して金取ろうとする奴を刺激しないためで、どの企業も調査序盤では常用する手 この問題ゴールドマンが目をつけていて株価操作に使えると踏んでいるからちょっとヤバいんだよな
ゴールドマンはギャラクシー爆弾の時と同じ株価操作をするつもりだろう 1006以前のBIOS使用してメモコンすり減らしたryzen多すぎだから完全収束不可だろうな 機能無効にしたり、特異な設定を利用者側が施さなくちゃならないなら結局ダメ
OCメモリが～って言うけど、散々AMD自信がレビュー向けパッケージでOCメモリ同梱してバラ撒いて宣伝させてるからな
自らユーザーに刷り込んだイメージでの自爆でしか無い と言うかb2発売すれば殆どの人間は売り変えて忘れられるし
AMDがさっさと次のリビジョン出せばいいだけだが おま環エラッタの原因をここまで他人になするつけるキチガイ
そういや相性とか自作PC板じゃ死語になったんだなと思うと感慨深い ASRockさんのマザーボードはメモコンのタイミングキツキツだったけど流石に改善されたよな？ フォーラムに２度目のRMAで治った報告来た。これで終戦だな。後はAMDは戦後処理。 ECCメモリーじゃ対処できるわけないし残当な結果だ
B2ステッピングの意味なしやな えぇ…
Xeon SP買いたいとはあまり思わないが
EPYCがLinuxでガリガリ回すと怪しいというのではしょうがない EPYCも詫び石貰うしかねーな
これだけ出るんだからAMDは大人しくリコールしろと思うけど
株価めっちゃさがるぞこれ >>735
今更無理だからBIOSアップデート時にuOpCacheOFFとタイミング緩めるだけだぞ
Phenomで見たな 淫厨が必死なガバりすぎスレｗｗｗ
団子ちゃんｗｗｗ EYPCとスリッパでは問題起きるの？
金はあるんだけどそれが嫌で買えないｗ >>446
これのSEGV起きないラインまで強制的にタイミング緩めるしかないかな
TwrwrSc TrdrdSc の2つがネックでちょっと値を上げるだけで帯域ズタボロに落ちるのがねぇ >>740
金があるなら買って試してみれば
Windows使う分には何も問題ないよ Windowsでは問題出ないっての、単にWindowsがポンコツだからどっちが原因かわからないだけでは
まあ要するに問題ないんだけど Linuxがカリカリに攻めすぎなんじゃね
なんつうかＯＳちょっと緩めて解決する問題じゃないかと思ってる
"OS開発者" じゃないからわからんけどさ warとか煽るのを技術者とはちょっとなあ
団子の同類じゃんよ >>748
はっきり言いましょう
プログラム全くわかりません！ このスレって加計学園の顛末のマスコミの報道とまるで一緒だな windowsがポンコツでLinuxがカリカリ・・・
そんなレベルの人達は、なんにも心配しなくていいと思うよ。
たとえSEGVがいつ発生しようと、絶対に気づかないからさ。 寧ろlinuxっていっつもどっかエラー出てるイメージがある、ただ致命的な部分は分離してるから実害が少ないだけで
窓はエラー出たら巻き添えで色々落ちたり動きが変になるからわかるけど >>754
Linuxはモノリシックカーネルって認識だが、最近は変わってきているのかね？ >>755
さぁ?
ただ自分で入れて遊んでる限りは無茶こいても落ちにくいけど変わりにあれやこれや壊れる感じだったな
無茶しなくても動かなかったり固まったり壊れたりはよくあった
特に付属の火狐君とかターミナルとか
Ubuntu入れた時の話だけどね AWSやGCP, Bluemixの判断は正しかった
それだけのことだろ 検品体勢の杜撰さと実質的な歩留まりの悪さの問題でしょ >>757
死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く死ね殺されろ 団子ってすごいよな。こんなに人の恨みを買って。
死後は地獄行きだろうｗ >>752
やべー…
satと前川がオーバーラップした… 海外でも一旦騒ぎがでかくなったから
Segったら全部CPUバグ扱いで大問題にされているなぁ
まともな対応もうできないんじゃないかと思うよ
民進みたいなやり方で手口がやり慣れてる感じがする 定格内で使ってて、同じワークロードIntelのプロセッサに投げてちゃんと通るならAMDが責められるのはしょうがない B2ステッピングのEPYCもSEGVするならもはやエラッタの域ではないんじゃないの？ デスクトップに置いてたファイルの整理してたら
初期BIOSで調子が悪いときのAIDA64（trial）での計測結果が出てきた
これってなにかの解析の役に立ったりする？
http://imgur.com/a/pLLUQ
もう旬は過ぎてるような気がしないでもないけど -j無しの状態で変わりにスレッド分並列させて起きるかどうかよ
Intel64とAMD64じゃ差異あるし参考にならん >>767
B2で直るなんて誰が言ったの？
AMDが認めてないエラーですよ
Supermicroのマザーに、品質にうるさいRegistered DIMM
誰がCPU以外の問題を疑うの？
個体レベルでuOP Cacheが正しく動かないものがあるって話なら工場レベルで検品を厳しくすべき話ですなー >>731
Winでxmrマイニング廻してもエラーでねーんだけどな >>769
それをやってるのが>>747に見えるが >>772
130はLinux固有の問題と言ってたし
早い話開発段階ではAMDはLinuxでの検証してない そんでもMicrocodeがバグってるってのは暗黙の了解なんだよな >>774
百歩譲ってデスクトップ用RYZENでそうなのはいいとして（よくはないが）、
EPYCなんて鯖で使うためのものみたいなもんだからそれは通用しないんじゃ？
第一もうこの問題がデスクトップ用RYZENで発覚し始めてから何か月もたってるんだから、
検証が必要だと思えば十分できる期間だったでしょ
で、具体的に原因が特定されて公式に発表されて対策がなされつつあるんですか？
あ、130氏がもう特定されてAMDにコンタクト取られてるんでしたっけ？
あとひと月も待てば何らかのアクションさすがにありますよね
待ってればいいだけかな >>776
130は別スレで粘着する連中のせいで反応遅いと愚痴こぼしてるから上手くいってるのかどうか 個体の初期不良なんて、インテルでもごく稀に聞くけどもね そう？いままで不良品らしい不良品掴んだことないから、その点ではインテルもAMDも個人的には変わらんよ。 >>773
よし、じゃぁ取り敢えずFX機にぶち込んでやるぜ >>763
今でも十分地獄だろｗ
本人は自覚してるか分からんが 本家は団子喉につまらせて退場してほしいと心の底から願ってる メモリスレにも書いたがmemtest86の新Ver(7.4)が出てた
Ryzenに正式対応して温度等表示されるようになったので、テストに使ってる人はこのVer使った方が良いと思う
あとブラックリスト(ファイル)が用意されて、マルチコアでテストするとフリーズする可能性がある板はデフォルト1コアでテスト開始するそうだ
AM4はASUSの板が何枚か入ってる >>784
死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く死ね アホを相手すんなよ。
新アーキ初物だし、バグは覚悟のうえだろ。
むしろ、ここで膿出し切れば相当有利だ。 MCEってメモリコントローラエラーの事かと思っていたらMachine Check ExceptionというCPU内蔵のCPU自己診断機能の事だった orz
自分の所では1500Xの方でメモリタイミングを緩めすぎると連続ビルド中に強制リセットする事が過去何度かあった
昨日も出たので次の起動後にdmesgとsyslogを見たらMachine check events 云々というログが残っていた
少なくともこういう場合にはMCEが発生する事も分かった
1700の方はSMT OFF & 4コア(2+2)設定で擬似的に1200相当にしてSEGV出るか実験していたら、さらにuOpCache OFFにした時に強制リセットしてdmesgとsyslogに残っていた(1700の方は強制リセットは初)
8C16T用のメモリタイミングでは4C4Tでは緩すぎるという事か
1200ではもう少しきつくしてやらないといけないようだ
壊したくないから注意しないとね
なお mcelog --ascii というコマンドで詳細が見られるらしい
デフォルトでは入っておらずapt installで入れられるのだが、今両方回しているのでまだ試してない 完璧なIntel互換の動きにならないなら調整するのも一応曲がりなりにもLinux Foundationの会員に名を連ねる企業のつとめだろ
オープンソースはいつからハードウェア屋が無償の労働力を乞食する装置になった？
ハードウェアが売れて得するのはハードウェア屋だ
なら売れるための行動をしろってだけの話よ
ろくに情報開示もせず個人にデバッグさせようってほうがおかしいわな
（なおLinuxカーネルのみに原因があるという論も疑ってはいるんだがな >>791
なら尚の事Intelの成果物に依存せずAMD自社のアーキテクチャの情報とそれに長けたカーネルコミッタを差し出すべきだな 単に煽ってマウンティングしたいだけのコテハンはスルーでお願いします
レスが無駄に消費されるだけです >>789
補足
mcelog入れてみたがRyzenに対応していなかった
今の所dmesgとsyslogをgrep Machineとかで見るしかなさそう >>790
AMDから個人に無償の調査依頼でもあったんだろうか。
Skylakeのエラッタだって、どっかのコミュニティが見つけたもんだったろうに。
・・・そも、AMDユーザーすらバカにするやつに、なんか関係のある話だろうか。
↑調査してるのもAMDユーザー 結果的に買ってしまったユーザー有志が
後発製品のサーバ向けの調整という本来メーカーがやらないといけない作業をやらざるを得なくなってるという話 ・設計上の問題ではなく製造不良のせいで問題の出る石が出荷されている
・クレーム言ってきた人にだけストレステストをした石で交換対応する
・EPYCでも品質テストをすり抜けたダイが使われている
EPYCでは良品だけ使ってるんだろうと思ってたがSEGV出る物が出荷されてると聞いて笑いも出ないわ
CryptoNightマイニング専用CPUとして売り出すつもりなのかな >>799
今のLinuxじゃバージョンよっては何やってもSEGV発生すること無視の考察は辞めろや >>793
死ね殺されろ早く死ね殺されろ早く死ね殺されろ >>798
メーカーがなにもやってないと、何故いいきれるのか。
よっぽどの情報通なんだなぁ。 沈静化するか様子見してるだけじゃないの
FDIVみたいに誰でも簡単にチェックできるほど敷居が低くないから
それほど騒がれないと踏んでるのかね 52 ：Socket774 (ｻｻｸｯﾃﾛﾚ Sp29-PcvT)：2016/12/18(日) 12:32:05.25 ID:ErU0jIqNp
>>47
アム厨は懲りないねwww.
何度AMDのパフォーマンスに裏切られれば気付くのやら…
529 ：Socket774[]：2016/12/19(月) 09:01:39.39 ID:Qu8srf5u
>>508
>CPUシェアの変動
アム厨の妄想は程々にwww.
58 ：Socket774 (ｻｻｸｯﾃﾛﾛ Sp29-PcvT)[]：2016/12/19(月) 09:02:38.77 ID:Qu8srf5up
アム厨の妄想は尽きる事無しwww
232 ：Socket774[]：2016/12/25(日) 19:30:41.51 ID:/qIKlvkp
アム厨、必死だなwww.
805 ：Socket774 (ｻｻｸｯﾃﾛﾘ Spef-BP23)[sage]：2017/08/07(月) 13:37:46.35 ID:GvbIhxEvp
淫厨、必死だなwww. >>804
おいおい、SkylakeのHTエラッタだって、一般に広がったのは対策完了後だろうに。
それまでHT切って使えなんて、インテルは発表してた？ 3つも大学に進学させてもらって「どうして私なんて産んだの？」なんて言われたら親ブチギレるだろ 130の言っていたのって緩めりゃいいじゃなくて、
SPD読み確認しろ、DDR4関連は安定する範囲はほとんど狭くてBIOSが上書きする意味わかんね。じゃない？ Intelでも世代関係なく出るエラッタワロタ
ryzenに改善を求めてる当たり屋紛いのチンピラ
息してるー？ 煽るのは先週末の自作自演(どこの人だろう？苦笑)と変わらないのでやめとけ定期 マイケルの環境だけはな
別の人はSEGVマシンでもEPYC起きてたし個体差じゃねーの？ CPUに問題ありってAMDが認めてんじゃん
FUDだなんだと吹き上がってた連中息してるー？
解析済みｗｗｗｗｗ jekirl氏がEPYCでも発生すると言っていたのは他のCPUでも問題が起きるphoronixのbuild-phpであって
それ以外のストレステスト、kill-ryzenでは問題なかったそうで
EDIT 3: It looks like the conftest segfaults were due to the php build test. The other stress tests + kill-ryzen.sh have been running fine for hours now...
Fully stable for over a day so I stopped it to run benchmarks....I haven't been able to crash it without the build-php test running.
まあ少なくともEPYCで起きるという話は起きないという話より信憑性が落ちる形ですね kill-ryzenなんて名前つけて明らかに貶めようとしてるのがまるわかり
【インテルネットサポート】
ｳｨｰｯｽ ∧＿∧∩
（´∀｀*//
⊂二 ／おまいら
＿|￣￣||＿＿＿ | ) / 働けよ
／旦|――||/／ ／|［酒］/ ￣）
| in℡懇親会|￣| . | ( <⌒<.<
|＿＿＿＿＿|三|／ >/
ｶﾀｶﾀ ∧＿∧ ｶﾀｶﾀ ∧＿∧ ∧＿∧
（ ｀Д´ ） ｶﾀｶﾀ （ ｀Д´ ） ｶﾀｶﾀ （ ｀Д´ ） ｶﾀｶﾀ
＿|￣￣||＿）____ ＿|￣￣||＿）____ ___|￣￣||／_）__
／旦|――||/／ ／| ／旦|――|l/／ ／| ／旦|――||/／.／|
|￣￣挑発￣|￣| . | |￣￣煽り ￣l￣| . | |￣￣ うそ￣|￣| . |
|＿＿＿＿＿|三|／ |＿＿＿＿＿|三|／ l＿＿＿＿＿|三|／
ｶﾀｶﾀ ∧＿∧ ｶﾀｶﾀ ∧＿∧ ｶﾀｶﾀ∧＿∧
（ ｀Д´ ） ｶﾀｶﾀ （ ｀Д´ ） ｶﾀｶﾀ （ ｀Д´ ） ｶﾀｶﾀ
＿|￣￣||＿）____ ＿|￣￣||＿）____ ___|￣￣||＿）＿
／旦|――||/／ ／| ／旦|――|l/／ ／| ／旦|――|l/／ ／|
|￣￣工作￣|￣| . | |￣￣提灯￣|￣| . | |￣ﾏｯﾁﾎﾟﾝﾌﾟ|￣| . |
|＿＿＿＿＿|三|／ |＿＿＿＿＿|三|／ |＿＿＿＿＿|三|／
ｶﾀｶﾀ ∧＿∧ ｶﾀｶﾀ ∧＿∧
（ ｀Д´ ） ｶﾀｶﾀ （ ｀Д´ ） ｶﾀｶﾀ
＿|￣￣||＿）____ ＿|￣￣||＿）____ ___|￣￣||＿＿__
／旦|――||/／ ／| ／旦|――|l/／ ／| ／旦|――ll/／ ／|
|￣自作自演|￣| . | l~ネガキｬン~|￣| . | |￣￣逃亡￣|￣l . |
|＿＿＿＿＿|三|／ |＿＿＿＿＿|三|／ |＿＿＿＿＿|三l／ >>816
AMDはSEGVなんてCPU作ってないし、EPYCなんてトラブル聞いたことない。
記憶くらい整理しとけって。 お前二度と他人の誤字脱字の揚げ足取りするなよ？
口先八寸くん >>828
当たり屋紛いのチンピラヤクザの言い掛かりにすらちゃんと応えるAMDの神対応すげぇな
それに比べて爆熱の落第CPUの烙印を押されてもシレっとグリスバーガーを使い続けるintelの糞っぷりが際立つわ グリスバーガーでも問題ない（ｷﾘｯ
XモデルでもOCすんな（ｷﾘｯ
どこの糞メーカーだよ 逆に不思議なのは、B1ステッピングのはずのThreadripperでは問題確認出来ていない事だな
あくまで初期生産のRyzen固有の問題とか書いてある（本当だろうか？ >>828 Linuxサポート入って大勝利じゃん。
AMDの分析では、これらのRyzenにおけるsegfaultは特定のマザーボードベンダーの問題ではなくプロセッサー自体の問題です。
AMDは影響を受けていると考えているお客様に、AMD Customer Careに問い合わせていただきたいと申し出ています。
segfaultに関して連絡をされた人たちの中には、廃熱や電力などの問題を抱えている人もいるが、
AMDはLinuxにおけるこのようなマージンの問題に遭遇した人たちと協力することを確約している。AMDは今後、コンシューマ向け製品においてLinuxテスト/ QAも強化する予定です。 Linuxユーザーなら、古い電源や定格外メモリもサポートしてもらえる！大勝利じゃんこれ！ とりあえずFUDだのおま環だの言って報告者をボロクソに叩いてたファンボーイはごめんなさいしとけよ
このままじゃ団子と同レベルだぞ >>833
RMA交換品で他変えずに治った人もいるしRyzenはコンシューマ向けだからってことで品質テストを緩くしてたんじゃないの
あくまで製造不良が有意な量紛れ込んでるだけなんじゃない？（だとすればよりタチが悪いんだけど・・・） ツイッター垢にフォーラムの垢まで取って騒いでたんだからごめんなさいするのは当たり前だよね むしろ最初に騒いだ当たり屋のせいで遅れたんじゃ無いのコレ？ どう考えても妨害してるのはプロセッサー自体の問題をプロセッサー自体の問題じゃないということにしたい側の人なのに
コレガワカラナイ 初期個体というより初期BIOSでメモコンぶっ壊した連中に対して保証という感じに見える
初期のryzenで確認出来るってAMDの認め方なんか変だし 原因箇所 発生理由
[SEGV発生]┬[CPU]─┬─[個体不良] ※
│ . ├─[ロット不良] ※
│ . ├─[取付ミスによる動作不良]
│ . ├─[取付時の失敗による故障]
│ . ├─[OCによる異常動作]
│ . ├─[OCによる故障]
│ . ├─[放熱不足による異常動作]
│ . ├─[放熱不足による故障]
│ . └─[エラッタ/バグ] ※
├[メモリ]─┬─[個体不良]
│ ├─[ロット不良]
│ ├─[設定ミスによる動作不良]
│ ├─[設定ミスによる故障]
│ ├─[OCによる異常動作]
│ ├─[OCによる故障]
│ ├─[放熱不足による異常動作]
│ ├─[放熱不足による故障]
│ └─[SRDR枚数クロック制限の規格外搭載]
├[M/B]─┬─[個体不良]
│ . ├─[ロット不良]
│ . ├─[旧BIOSの異常設定値による不具合]
│ . ├─[旧BIOSの異常設定値による故障]
│ . ├─[特定バージョンBIOSの異常設定値による不具合]
│ . ├─[特定バージョンBIOSの異常設定値による故障]
│ . ├─[設定ミスによる動作不良]
│ . ├─[設定ミスによる故障]
│ . ├─[放熱不足による異常動作]
│ . ├─[放熱不足による故障]
│ . ├─[OCによる異常動作]
│ . ├─[OCによる故障]
│ . └─[バグ] └[電源]─┬─[個体不良]
. ├─[電圧変動幅増大]
. ├─[リプル電流過多]
. ├─[劣化による故障]
. └─[劣化による出力低下]
SEGV発生で騒いでる奴が全員CPU起因によるSEGVなら早々に特定されて終わってるが、
それ以外の要因の奴までCPUが原因だと騒いでるのが特定できない最大の理由だろ 130がこのスレで初期BIOS使ってたryzenはメモコン故障の疑惑ありと検証してたのに忘れてますね ぶっちゃけ最初はおま環かと思ってたけど、
uOPキャッシュ切ってメモリタイミングを正規化して走らせたら3日以上問題無く通ったっていう検証が出てきた辺りからやっぱりCPUもおかしいんじゃないかと思ってたわ
ただし、
・おま環も荷担している
・CPU依存の問題だからWindowsでも起こる時は起こる
・B1ステッピング固有の問題か、Zenコア全体の問題のどちらか
だと思ってたら半分違った
AMDによると
・CPUにも問題あるが、おま環も荷担している
・少なくともAMDの環境ではEPYC,B1ステッピングのはずのThreadripperでも起きていない
・RyzenでもWindowsでは発生していない
・あくまで初期生産のRyzen固有の問題
ということなのね 初期と今で何が変わってるかってM/BのBIOSくらいだと思うがな・・・ 初期よりも1.0.0.4aBIOSもやばいと思うけどな
6nsのDRAMのレイテンシ改善のシワ寄せがどこにいったでしょうかという話だし やはりRyzenに問題があったのは事実ではないですか。広く普及しているLinuxでしっかり試験していなかったのは問題でしょう。
前にも申し上げましたが、このままでは電源やRAMなどの環境のせいにされてしまい、問題が公表されずに終わってしまいます。
さらなる圧力こそが全てのAMDユーザーのためになると思います。正式にLinuxをサポートさせるために努力しませんか？ それよりもSEGVしないとAMDが主張しているWindowsとSEGVが出ているLinuxの差の解明をだな AMD Customer Careとやらに問い合わせてみるか（うちのもしっかりsegfaultするので） >>849
> 6nsのDRAMのレイテンシ改善
すっかり忘れてたが確かに・・ >>850
unixクローンだらけの特亜国の方ですか？ 問題の初期BIOSより6nsのDRAMレイテンシ改善なんて回路弄る以外だとメモコン側かメモリー側のタイミングきつめるしかないしなぁ
交換しますよって対応見てるとエラッタ扱いにしてあげたほうがまだAMD的にありがたそうだな AGESAをCPUの一部とみなすのかどうかなんじゃね 検証せずにsatや他の奴を個人攻撃するやつまでいたからな
AMDも認めたようだし土下座の用意をしとけよ 結果的にAMDがSEGVを認めたからといって、そもそも某Sの言い分がこの発表に繋がったのかも分からないのによく言うわ
(多分繋がってない。もっと的確な報告をした人がいるし)
そして某Sとその取り巻きが行った全ての迷惑行為が許される訳ではない
土下座とか言ってる取り巻き連中と本人はここじゃなくTwitterで都合悪いのをブロックしながらでもやってろ satが問題提示してこの問題が有名になったんだから勝利みたいなもんだろ
バトル始めた連中がいらないくらいだわ
メモコン破壊のほうがエラッタより深刻なのでAMDは早く正式な回答してくれ >アンチやどこぞの工作員はRyzen固有の問題にしようとしているようだが...
こんなことを平気で言ってた人が862みたいな負け惜しみを言っても説得力ないよ 話題になった発端はsatだけどね
勝ち負けの問題じゃないだろうけどその後の検証等でケチがついてるから勝利はないな
130と追試してくれてた人の方が張るかにAMDにとって有用な情報だろうと思うが
彼の報告レポート見てみたいよ >>864
都合の悪い所は削って引用してる方が説得力ないわな
そもそも勝ち負けとかの問題じゃないんだよ
とっととTwitterに帰れ
696 名前:Socket774 [sage] :2017/08/06(日) 11:19:59.15 ID:MvUZ1MC5
最近知ったのだが、Raspberry Pi3(Arm4コア)でも-j4でSEGV出るそうだ
RPi3カーネルビルド再び...
http://tuttitan.hatenablog.com/entry/2017/02/11/114130
エラーログ(クリックして展開)の所を展開するとSegmentation faultがある
130氏は現時点全Ver(4.13含む)のLinuxでSEGVは出ると言っている
また>>692の事例、前述のRasPiの事例もある
Linuxも問題を抱えているという事は忘れてはいけない
アンチやどこぞの工作員はRyzen固有の問題にしようとしているようだが... だからさ
Linux側が原因で起こる問題もあればRyzenが原因で起こる問題もあるのよ
後者を指摘する行為をアンチだの工作員だのFUDだの罵倒するのがおかしいという話 marginality performance problemってAMDが使った表現、すごいバカにされてるね Linuxが完璧なものだと思いこみエラッタだと決めつけてたのはどこの誰ですかねえ
ここで検証していた複数の人達はLinuxにもRyzenにも（主にメモコン）マザーにも問題あるんじゃないのってスタンスだっただろ >>867
最初からそういう論調で話をしていたか？
「Ryzenでしか起きない」としか読めなかったが？
初期の時点で他のプラットフォームで出るかどうかの実験すらしてないよな
あと俺は「FUD」とは一度も言っていない
「アンチとかどこぞの工作員」はお前らとはまた別の、便乗してRyzenやAMDを貶めようとしている連中(具体的に言えば元来のアンチAMDとインテル工作員)を差している
その辺の区別も出来ないくらい被害妄想が激しいのか？
そういう奴らにここは向いてないんだよ
とっとと失せろ クソ電源とクソメモリ使わなければほぼ出無さそうだなあ ワッチョイ変えながらインテルインテル言ってる人ってやっぱ高卒なん？ 海外でも検証してる人がいて、その人たちも電源メモリ言われ新しいの買う人もいてVictimとか言われてた
冷静な議論が必要だなとしか思えなかったな 誰が何処でどういう経緯で言われてたのかわからんとなんとも言えんね SEGV_Battleとか言ってた連中は、ソフト側ではなくハードウェア側が原因だと推測した後、
ハードウェアのうちどこで問題出るかの切り分け殆どやらずにCPU！CPU！って言ってるから馬鹿にされてんだよ
少なくとも中古動物電源でテスト繰り返す前に、まともな新品電源買うとかやることあるだろ SEGV_Battleとか言ってたやつの中で中古動物電源でテスト繰り返してたやつってどのぐらいいるの？ AMD、LinuxのSEGV問題の影響を一部確認、Epyc / TRに影響しない
http://www.phoronix.com/scan.php?page=news_item&;px=Ryzen-Segv-Response エラー出てもいいから安いだけのクソメモリとか使ってるんだよな
稀なエラーで騒ぐくらいシビアなことやってるならECC付きのXeonでも使ってろだな 何となくだけど、クロックと動作電圧の盛りすぎと
動作温度も限界近辺になると、内部回路が一部でショート
短絡っぽい状態になってるんじゃないの？
半導体の物理特性が原因だから
動作クロックを3G程度に制限して電圧と温度をキッチリ下げたら
エラーが再現しないとか >>812
>>814
>>850
> 煽るのは先週末の自作自演(どこの人だろう？苦笑)と変わらないのでやめとけ定期 勝ち負けとかそういうのじゃないと思う
130氏や追試氏に感謝すれど、ｓ氏にその心が動かないのは「騒げば良い」ではないからだろ？
また発端である事も重要ではない
むしろｓ氏が最初から130氏の様に指摘していたら大喝采では？
別にどのメーカが良い悪いでなくて、新しい技術が枯れていく過程では様々な障害がある
けど、それを越えて行かないと未来はないよって話
AMDが明日もAMDでありたいなら何らの行動があるでしょ
【インテルネット工作部】
ｳｨｰｯｽ ∧＿∧∩
（´∀｀*//
⊂二 ／おまいら
＿|￣￣||＿＿＿ | ) / 働けよ
／旦|――||/／ ／|［酒］/ ￣）
|￣￣部長￣|￣| . | ( <⌒<.<
|＿＿＿＿＿|三|／ >/
ｶﾀｶﾀ ∧＿∧ ｶﾀｶﾀ ∧＿∧ ∧＿∧
（ ｀Д´ ） ｶﾀｶﾀ （ ｀Д´ ） ｶﾀｶﾀ （ ｀Д´ ） ｶﾀｶﾀ
＿|￣￣||＿）____ ＿|￣￣||＿）____ ___|￣￣||／_）__
／旦|――||/／ ／| ／旦|――|l/／ ／| ／旦|――||/／.／|
|￣￣挑発￣|￣| . | |￣￣煽り ￣l￣| . | |￣￣ うそ￣|￣| . |
|＿＿＿＿＿|三|／ |＿＿＿＿＿|三|／ l＿＿＿＿＿|三|／
ｶﾀｶﾀ ∧＿∧ ｶﾀｶﾀ ∧＿∧ ｶﾀｶﾀ∧＿∧
（ ｀Д´ ） ｶﾀｶﾀ （ ｀Д´ ） ｶﾀｶﾀ （ ｀Д´ ） ｶﾀｶﾀ
＿|￣￣||＿）____ ＿|￣￣||＿）____ ___|￣￣||＿）＿
／旦|――||/／ ／| ／旦|――|l/／ ／| ／旦|――|l/／ ／|
|￣￣工作￣|￣| . | |￣￣提灯￣|￣| . | |￣ﾏｯﾁﾎﾟﾝﾌﾟ|￣| . |
|＿＿＿＿＿|三|／ |＿＿＿＿＿|三|／ |＿＿＿＿＿|三|／
ｶﾀｶﾀ ∧＿∧ ｶﾀｶﾀ ∧＿∧
（ ｀Д´ ） ｶﾀｶﾀ （ ｀Д´ ） ｶﾀｶﾀ
＿|￣￣||＿）____ ＿|￣￣||＿）_____ ___|￣￣||＿＿__
／旦|――||/／ ／| ／旦|――|l/ ／ ／| ／旦|――ll/／ ／|
|￣自作自演|￣| . l l￣ﾈｶﾞｷｬン￣|￣| . | |￣￣逃亡￣|￣l . |
|＿＿＿＿＿|三|／ |＿＿＿＿＿_|三|／ |＿＿＿＿＿|三l／ >>851
WindowsでLinux環境並みの検証をするには、特別なライセンス契約をしてカーネルのコードを読めるようにする必要がある
Windows内部がどうなっているかわからない以上、Windowsがエラーを隠蔽してしまうとどうしようもない >>886
エラーを隠蔽ってwww
それどんなMSの陰謀？ 英語記事読んでみた限り、「AMDがWindows環境でテストしてみた限りでは同様の問題は発見できなかった（not found）」としか書かれていないので、本当にWindowsで出ないのかは検証が不十分そうだ
（多分Linux側に検証リソースを割いてる）
一方で、ThreadripperとEPYCでは「同様の問題はないことを確認した（confirmed）」とあるので、こちらは自信がある模様 >>887 >>888
内部処理でエラーが出ても、それがOS内で解決できるならブログラム側に見せずに再処理することができるということ Linuxってオープン系なのにでかい顔しすぎじゃね？
ここまでデカい面してるOS世界中のどこにも存在しない
このままだと中から腐っていつか廃れるぜ >>890
エラーを解決しちゃう！！夢のような技術じゃないか！！
・・・適当言ってるだろ？
プログラムにエラーを見せる見せないもよくわからんけど、受け取る処理書かないとOSが何してくれてもわからんよ？ >>603
経過報告
(1700+Taichi+マイクロン2400メモリの方)
いくつかの実験後、再度uOpCache OFFで回しているが、先程dmesgとsyslogにHardware Errorというログが出た
この状況でもSEGVは発生していない
先日mcelogを入れた事によりmcelogデーモンが常駐して、MCE発生時はログに残す(強制リセット時以外も残す)ようになったようだ
(前の111時間回した時はmcelogは入れてなかったので出なかった)
これ何か参考になるだろうか？
(no action required.とか書いてあるから気にしなくて良いのか？)
なお手持ちの1700は不良or故障個体の可能性大なので、内容そのものを深追いする事はあまり意味ないであろう事には留意してほしい
mce: [Hardware Error]: Machine check events logged
[Hardware Error]: Corrected error, no action required.
[Hardware Error]: CPU:9 (17:1:1) MC1_STATUS[-|CE|MiscV|-|-|-|-|SyndV|-]; 0x98200000000b0151
[Hardware Error]: IPID: 0x000100b000000000, syndrome: 0x000000004a000000
[Hardware Error]: Instruction Fetch Unit Extended Error Code: 11
[Hardware Error]: Instruction Fetch Unit Error: L2 BTB multi-match error
[Hardware Error]: cache level:L1, tx: INSN, mem-tx: IRD
http://i.imgur.com/KZXsGnC.jpg
あとmcelogは以下でインストールできる(デーモンも自動で常駐する)
sudo apt install mcelog
以下でデーモンの状態を確認できる(q を押すと抜ける)
sudo service mcelog status
sudo mcelog <オプション> で色々できるはずだがCPUが対応してない旨出てコマンドラインでは何も出来ない >>828
当たり屋紛いのチンピラヤクザの言い掛かりにすらちゃんと応えるAMDの神対応すげぇな
それに比べて爆熱の落第CPUの烙印を押されてもシレっとグリスバーガーを使い続けるintelの糞っぷりが際立つわ まさかプレマーケット知らねえなんてことねえだろうな >>900
だから？ドヤ顔でそんな既知ネタかよ
本当に死ねよ糞団子早く死ね殺されろシッタカ >>901
まあ、どのみち今日の取引はもうじき始めるから現実がわかる 日本もヨーロッパも下げてて恐怖指数も20%以上上がってマインドネガティブ傾向なんだが
何が現実がわかるだ 本当にこのスレ違いなフンコロガシは何なんですかね？ 日本もヨーロッパもRMAしてて特損計上見込みだから下げてるんですよ知っとるわそんなこと amd nasdaqで検索すればグラフ出るけど
ホントに落ちてるんだな
NASDAQ閉めてから他の市場で持ち替えし始めてるけど
懸念売りにしては返しが早かないか？ これで下がってるだけだから
欲しいやつは買っておけばいい
1，2か月で簡単に30%上がり下がりするから
300万ぐらい突っ込んでおけば毎月好きなパーツ買えるぞｗ
http://www.investopedia.com/news/amd-fall-30-percent-barclays/?partner=YahooSA&;yptr=yahoo >>891
Linuxがというよりは、自称Linux開発者が
かな？ >>911
死ねよ早く死ね殺されろシッタカ糞団子早く死ね殺されろシッタカ糞団子早く死ね Windowsのソースコードって実はMSに申し込めば開示しくれるんだよね
お金払わなければいけないとかではなく、確か個人でもOKだったはず
この手の調査しようと思えばそういうのも必要だろうね >>884
satだろ？
対処の仕方とかそういう方向は一切考えてないからただのクレーマー
結局騒いだだけでこいつは何も貢献してない
製品保証期間があるからAMDが交換対応すると言ってきたのをいいことに何度も交換すると思うぞ
おそらく返品するんではなく使用済みは中古で売り払う気だろう
すでに構成自体怪しい状態で使い続けてるだろうしエラーは永遠と収まらない
モラルと良心のかけらもないクズ同然 >>915
個人に楽に開示してくれるものなら、この前みたいなWinソースコードリーク騒動で大騒ぎにはならなくね？ >>919
死ね殺されろ早く死ねシッタカ糞団子早く死ね >>921
死ねシッタカ糞団子早く死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く お前の悔し涙は最高のスパイスよ
ざまあwwwwww >>917
だから、大した騒動にならなかったんだよ
GPLだとかみたいに自由に配布は許可されてなくても、Windows向けのドライバーを作ってるところとかWindowsにはWindowsのソースコード開示されてる 皆が大学で遊んでるとき
俺は朝から晩までずっとパチンコのこと考えてた
どうやったら勝てるか
かてたとしてもっと稼ぐにはどうすりゃいいか
必死に考え行動し
毎日をパチンコ攻略のためにすごしてた
俺のゲーマー人生の土台はここにある
今の若い連中にいいたい
世間の評価なんてどうでもいい
自分が極めたい道を貫けと 結論から言えばWindowsは問題ないと考えているが、話が脱線しすぎだ
Linuxの該当部分がわかっていない人がWindowsのコード読んで…は無理がある
基本的にSource Licence Programは1万人分以上のWindows契約をしていて検証が必要な場合に限られる
どこもそうだが、Corporate NDAは恐ろしくきついものなので気軽に読めるものではない
Windowsの該当部分のコードは非常に読みやすいのでChecked Buildを
Public Symbolsでのんびり眺めているだけでも何が行われているかはわかる あんたに結論なんてものが本当に有るならLinuxカーネルにパッチ投げてみろよ
sat氏のやること否定するだけで何も行動してないよな スレ違いな株価ネタで荒らすしかできないザコがなに言ってやがる エビデンスが～とか言いながら自身は何一つ出さないな 俺は知らないからな
知ってるふりをする専門家気取りほど役に立たないものはないしな 自己資本比率を知らないおじさんにそんな難しいこと言っちゃダメ 筆頭債権者がどこのアラブの投資会社かも知らないバカが言ってろ >>930 ←ブーメラン
イキリオタクの骨頂ですな マウンティングしたいだけの無知な上に知性のないゴミだと言うことが改めて分かったので
以下ゴミコテはスルーでお願いします 株価がそんなに重要なら、2ドル以下だった頃と比べれば今は天国ですね
実際のところ、去年に市場で現金調達も成功してるし流動資産がショートするなんて心配は無い
去年株価が50%急騰したときにこんなこと言ってた団子は株に手を出さない方が良いのは確かｗ
977 名前：,,・´∀｀・,,）っ-○○○@KD106161194181.au-net.ne.jp (ｱｳｱｳ Sa19-laA8) 投稿日：2016/04/22(金) 07:59:05.78 ID:Kn0jnOPCa
所詮時間外取引だもの
自演取引で価格吊り上げなんてのもできる >>940 ←言ってる本人は自分に当てはまるところがないと思ってる良いサンプル >>943
多少は自覚あるから反応したんじゃないの？ いつも結論ありきで妄想による主張ばかりして
それが崩れるのが怖いから自分自身で検証はしない
まさに屑 あれも世界中にばらまかれてしまったのは何だかな。もちろん紹介はしない
明らかに違法な配布ばかりだ。読みたければ該当部分含め読めるのは確かだが。苦笑
WSLの記事にしつこいほど"clean room implementations"と書かれているのは
特許と著作権、ライセンスの問題が生じるから。
何であれ他人のコードを読む際には気を付けてくださいね >>946
これこれ、それは美化しすぎだよ。
彼は、sat氏、EIRAKU氏をよく引き合いに出すけど、
ホントのところ、「RAYZENなんて買うからだ、ざまぁｗｗｗ」くらいにしか思ってない。
つまり、AMDが叩きたいだけで、もしインテルに同様の問題が起きたとしても、有る事無い事並べて必死に擁護するだけさ。
もとより、エビデンスなんて必要ない次元なのさ。 Ubuntu16.04は試験に向いてなさそうだな
>>7 を Artful Current で置き換えるための追試しとくか
ちなみに株価は全体に対する過熱感と、どんぱちで^VIX上がっているだけですよ
ボラティリティ上がっている企業は^VIX上がると利確の影響を受けやすい
右肩上がりも下がりも同じですよ。これ常識だから。きちんと講義受けていたのかしら
https://finance.yahoo.com/quotes/%5EVIX,AMD,INTC,NVDA/view/v1 とりあえずLinuxにコミットできない言い訳の意味は理解した >>7
ここを見ていてかつ、試験している人は少ないので気にしなくてもよいのかも？
ただ、本家のこれは大量のトラフィックを受けるようにはできていないようなので
http://cdimage.ubuntu.com/daily-live/current/
JAISTのミラーサーバーを利用するべきなのだろうけれど、
日付を指定するとさくっと消えちゃうのがな
http://ftp.jaist.ac.jp/pub/Linux/ubuntu-cdimage/daily-live/current/ 空冷風見鶏おじさんまだいるの？
お前他人の事言う資格ないだろw笑えるわw 基本情報技術者資格持っとるわぼけ（スキルシートには書かないが） 応用以上の区分持ってるなら普通は基本なんて書かないよ WindowsユーザーのためのUbuntuでカーネルビルド無限ループさせたい人向け手順
1. 16GB以上の空きメモリのあるマシンと空のUSB Memory(4GB以上)を用意します
2. http://ftp.jaist.ac.jp/pub/Linux/ubuntu-cdimage/daily-live/current/ から artful-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/ebp9VJHa AMDがこの件で不具合認めたらしいけど
下らない批判やあまりにも意味がない検証をやっていた人はウレションできて良かったね
布団乾かせよ 詐称じゃないのか
なら病んだ技術者か
昔の
「ということにしたいのですね」
の人みたいなやつかな 論理的思考ができずに願望と妄想で判断するのが技術者ねぇ コミケ行くとちらほら韓国人いるよな
近くに居たら舌打ちするようにしてる >>961
あとMCE拾えるように連続ビルド始める前に
sudo apt install mcelog
でmcelogデーモン常駐させた方が良いと思う
>>895に書いたようにMCEが発生するとdmesgとsyslogにログが残るようになるので
dmesg | grep Machine
cat /var/log/syslog | grep Machine
等で時々チェックする
SEGV出た上でMCEも出たら交換対象の可能性大なので交換したい人はAMDカスタマーに連絡
交換はまだしない人はメモリタイミングを130氏提示にする(>>432 >>433 >>446)
場合によりさらにuOpCache切る、で対処するといった所か >>971
訂正
SEGV出れば基本的には交換対象だったか
MCEも出ていればなお話が進みやすいと思う 自分の所では、1700+Taichi+マイクロン2400メモリの方はMCEは計2回出た
SEGVは出ていない
現在前回の111時間をはるかに上回っているがMCE出ているので具体的な時間の公開は控える
代わりに1500X+MSI Mateの方がSEGVもMCEも発生せずにそろそろ72時間を迎える
2133メモリでは結局適正値を見つけられず2400メモリに交換した
メモリタイミングは1700よりは少しきつくした
uOpCacheは残念ながらOFF(ONではSEGV出る)
具体的には111時間を越えたら報告したいと思う
1200は諸般の事情で随分遅れたが、先程やっと注文した
届くのはお盆終わってからになると思う
EpycやThreadripperと同時期にテスト工程が行われた可能性があるので、それら同様出ないようになっていると良いのだが エラッタ吐くと判ってるなら対策されたBSD使うなりしないんかい？
リスク減らしたいならハードウェア換えるかOS換えるかだろうよ
わざわざエラッタ吐く組み合わせ選んで文句とか能なしにも程があるわ 何を言っとるんだコイツ
最初からリスク分散だから複数
その中でLinux「も」使ってるって話 Linuxでは、gccのコードやカーネルのパッチ対応に問題があり、高負荷でsegv発生することがある。ハード構成の見直しやメモリタイミング・CPUの周波数を一時的に緩めることで解決出来る。
これが本来の正解だったのでは？
一部の馬鹿がゴリ押しした事で本来だったら十分使える石も撥ねられるようになってしまった。スリッパはおま国価格になるしな。 Threadripperの価格は日本AMDがアスクに好き勝手やらせてるせいだと思う
卸価格が米アマで買った方が安いってOCWorksが嘆いてたぞ
CFDはアスクより少し安いみたい 日本AMDも窓口的なもんで、一次販売の商材扱いしてない本国のはずじゃ？
だから輸送量やら代理店税のっかった価格になってる 一応次スレ立てといた
【エラッタ？】Ryzen SEGV検証Part.5【おま環】 [無断転載禁止]?2ch.net
http://egg.2ch.net/test/read.cgi/jisaku/1502550752/ エラッタに対する認識がおかしいようだが、現時点ではエラッタは存在していない。
該当箇所の特定すらできていないようなので、そりゃ正誤が作れないわな。定義として。
公式に存在が認められているのは廃熱や電源の問題を含めての、マージンの問題とだけ。
問題が確認されているのもLinuxだけで、Windowsは対象外となっている。
考え方の違い、サポートするCPUの範囲による実装差なのでこういうこともあるだろう。
この問題がこれほど大きく騒がれているのは日本だけだというのもまた現実
謝罪と賠償文化が理解できないし、正直あまり理解したくないところではある。
私の環境ではSPD読みを直しただけで問題が起きなくなったことからして、
これをどこまで個体不良と呼ぶべきなのか正直わからない。
古いBIOSを用いて、SPD読みおかしくてもスルーした上、
Linux Kernel 4.8をわざと選択して、ようやく再現できたという。
該当箇所における疑いを確信するためには問題を起きやすくするのではなく、
正しい設定でも問題が起きることを確認する必要があった。もう十分な報告は飛ばしたつもり。
まあ、数分でだとか、BIOS更新後にRMAしても問題が起きるというのは未だに理解に苦しむ。
あとは、このメーカーごとに異なる設定がいつ統一されるのか、
次のマイクロコード更新がいつになるのか、かな。公式発表待ち
一番まともなのは各Distributionが公式にサポート宣言するまで他のCPU使っておく、だろうけど 語源はともかく、今ではLSIの細かい不具合のことをエラッタと言う >>978
機能や性能の劣化がなく、OSやBIOSで簡単に回避可能な問題であれば、そういう対応をするのが普通 Linuxを敵にまわすと、AMDに対応しなくなるぞ 交換で治ったという報告があるが
交換中にbios更新、再セットアップ、linux方面のバージョンアップなど変更点は多い
交換品のsteppingは変更無し
cpuロジックの問題でもなくエラッタでも何でも無かった >>994
それは悪魔の証明でしょう
AMDが具体的な原因言わないからいけないが 初期biosでコンパイルで負荷掛けまくってcpuのメモコン壊してるのが発端だろう
linuxは細かい部分で最適化が不十分だった
壊した物に対して交換しただけ
これが結論 satの頭の中のCPUに問題があるのは確信してますわ >>984
再現性のない不具合は相性問題に近いのでは？ 1台のマシンが組み上がりました。。。
新しい筐体を用意してくださいです。。。。
自作PC板＠2ch http://anago.2ch.net/jisaku/
life time: 29日 4時間 0分 29秒 ２ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ ２ちゃんねる専用ブラウザからの広告除去
★ ２ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.2ch.net/
▼ 浪人ログインはこちら ▼
https://login.2ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
