【エラッタ】Ryzen SEGV問題 Part.2【AMD】 [無断転載禁止]©2ch.net

**Socket774** · 2017/06/26(月) 20:25:11.45

前スレ
http://egg.2ch.net/test/read.cgi/jisaku/1498012307/

**Socket774** · 2017/06/29(木) 18:42:38.83

次からスレタイは自作板っぽく
こんな感じでいいんじゃないか？

【intel】NEW_耐久テスト【AMD】

こんな感じにした方が集客力あってデータ集まりそう

**Socket774** · 2017/06/29(木) 18:56:16.17

一般のソフト屋はそんな感じかな
エンジンやコンパイラ、暗号や圧縮アルゴリズム開発するようなエース級は高度すぎて理解できないおかしさだろうか

**Socket774** · 2017/06/29(木) 18:57:31.58

>>721
そこは「Ryzen SEGV Battle」でいいんじゃないかな

**Socket774** · 2017/06/29(木) 19:04:31.18

>>723
intelも混ぜた方がいいだろう
intelのハイエンドで試してる例が少なそうなんで
実験してみた方がいい

**Socket774** · 2017/06/29(木) 19:06:09.56

>>723
賛成

**Socket774** · 2017/06/29(木) 19:08:47.46

純粋に検証するためのスレじゃなくなるのは勘弁してもらいたいところ
BattleはTwitterでやればいいと思うんだ

**Socket774** · 2017/06/29(木) 19:12:37.32

ここエラー出ないようにしたい人のスレと違うの

**Socket774** · 2017/06/29(木) 19:13:25.55

【AMD】Ryzen SEGV検証 Part.3【battle】

まだ先だけど

**Socket774** · 2017/06/29(木) 19:13:28.54

>>70
Pentium4だと2桁クロックを落とした
486DX相当の性能に落ち込むから
超漢字ですら遅く感じるよ
それぐらいL1 L2の効果は大きい

**Socket774** · 2017/06/29(木) 19:18:22.61

battleは抜いて良いんじゃ？

**Socket774** · 2017/06/29(木) 19:32:42.77

>>729
仮にキャッシュが原因なら、キャッシュ切ったら挙動がどう変わるのかも見ておくべきだと思ったが、切れないので見られなくて残念、という意味
切ったら凄く遅くなるのは知ってる

**Socket774** · 2017/06/29(木) 19:48:41.40

最新CPUでも486に負けるのは、なんか感動したな

**Socket774** · 2017/06/29(木) 19:51:44.84

>>728
ryzenだけだともうある意味
結果が見えてるだけにどうなんだって感じだろ

**Socket774** · 2017/06/29(木) 19:51:54.07

>>732
流石にPen4だったからだと思う
486以下なんてコアレベルで比較してもそうそう無いぞ

**Socket774** · 2017/06/29(木) 19:55:29.00

>>728
Intel入れないの？
俺的に>>721を推したい…

**Socket774** · 2017/06/29(木) 20:01:21.71

真面目な話、メモリ負荷もコア負荷も高いし、カーネルビルドベースのストレステスト/ベンチマークは割と良いかもしれない
FP負荷を考えてSMTのT1にビルド、T2に重SIMDとか放り込んで

**Socket774** · 2017/06/29(木) 20:10:01.23

ちなみにSamsung環境でエラー出てる人って居ないんだっけ？

**Socket774** · 2017/06/29(木) 20:10:45.39

intelもやった方がいいぞ
きっちり調整するとwindows側ならNGは出ないと思うし

100万回連続OK 非常に快適
10万回連続OK　快適
1万回連続OK　普通

とか適当にランク分けて

**Socket774** · 2017/06/29(木) 20:16:36.42

>>724
いや、それだと収集つかなくなって分けわからなくなる
1つや2つくらいなら許容できるけど、それを超えると何やってるかわからなくなると思う

**Socket774** · 2017/06/29(木) 20:20:14.45

>>733
結果が出たら終了でいいだろう
スレ内の会話のし易さと、問題切り分けの観点からRyzenとIntelは分けたほうが良いと思う
後、見てるだけとか興味持ってる人もいるだろうし、AMDとIntelの話を交互にされると理解が追いつかなくなる

**Socket774** · 2017/06/29(木) 20:20:26.47

【AMD Ryzen】 SEGV検証 Part.3 【Intel】でいかがか。
Intelでやってる人も居るし。

**Socket774** · 2017/06/29(木) 20:25:30.12

>>727
ソフト屋の頭のエラッタを検証するスレだよ

**Socket774** · 2017/06/29(木) 20:28:51.03

>>741
別にかまわないけど、そもそもIntelじゃ問題になってないし発生する気がしないし、やってる人もそういう報告無さそうだから正直どうなんだろうと思う

**Socket774** · 2017/06/29(木) 20:31:46.94

誤解を招くかもね
Intelでも出るという確証ができるまでは控えるべきかと

**Socket774** · 2017/06/29(木) 20:39:16.37

久しぶりにヌルポ祭りになっててワロタw

**Socket774** · 2017/06/29(木) 20:41:26.28

タイミング緩めたらエラーでなくなって笑う

**Socket774** · 2017/06/29(木) 20:51:09.99

>>744
AMDでもAPUやFXではでないけど、Ryzenではでるではおいおいだが、
IntelやAPU/FXでも(それもRyzen以上に)出ているのに今回大騒ぎってなら
なんか俺らって大情弱って感じだよな

**Socket774** · 2017/06/29(木) 20:54:34.85

>>727
そうであってほしい、俺も自分の問題を解決したいだけなので
てか見えない敵と戦ったり個人叩きすること自体は別に好きにやってればいいと思うが
それに乗じて技術的に間違ってたり根拠がないことを吹聴するのは勘弁してほしいわ

**Socket774** · 2017/06/29(木) 21:01:05.34

testファイルセキュリティソフトで削除されるわ

**Socket774** · 2017/06/29(木) 21:01:19.04

>>747
主旨がぶれてるな
Ryzenで出ると騒がれてるからスレ作って検証してるんだが
他で出るのかとか検証したいなら別にスレ立ててやればいいだけ

**Socket774** · 2017/06/29(木) 21:01:35.31

今回騒がれるまでAMD、Intel含めてRyzen以前のCPU環境で、今回のテストと同じ様なことを繰り返してた人はそういないと思う
色んな環境での情報が集まるのは有意義ではあるでしょ

そもそも「Ryzenの問題」って発端が本当にそうなの？って所だし

**Socket774** · 2017/06/29(木) 21:04:01.39

>>743
えっ？

**Socket774** · 2017/06/29(木) 21:05:01.98

そこで

【intel】NEW_耐久テスト【AMD】
ですよ

検証じゃないですから

**Socket774** · 2017/06/29(木) 21:07:07.49

https://software.intel.com/en-us/articles/determining-root-cause-of-sigsegv-or-sigbus-errors

**Socket774** · 2017/06/29(木) 21:15:36.85

Windowsでエラー出たって言ってた人、
もしWin10なら自動メンテナンスが走ってたんじゃないか？

**Socket774** · 2017/06/29(木) 21:22:24.58

>>754
せぐヴぃ

**Socket774** · 2017/06/29(木) 21:22:54.84

>>754
何かと思えばプログラムの書き方がまずいとコンパイルした後のコードを実行するとコケるっていう当たり前の話じゃないか
一応日本語訳があるようだ
https://www.isus.jp/products/fortran-compilers/sigsegv-or-sigbus-errors/

**Socket774** · 2017/06/29(木) 21:24:10.29

>>751
カーネルのコンパイルはRyzenより前のCPUではやっていないのか？
ある人が人生初めてのカーネルコンパイルをRyzenでやったらSEGV出て大騒ぎ始めたって感じじゃないのか
以前よりカーネルコンパイルやっている奴はカーネルコンパイルはそうい物(何回かやればSEGVでる)なのに、なんで今回騒ぐ？
って感じじゃないのか。

**Socket774** · 2017/06/29(木) 21:25:41.09

Ryzenだけの問題かの様に騒いだ奴は非常に罪深い

**Socket774** · 2017/06/29(木) 21:25:56.76

>>753
いやここ既に発生しているRyzenの検証、解決スレと化してるから
既に互いに情報交換しあってある程度の情報を共有している状況で、全く関係ないIntelの情報が混ざったらやってる方も見ている方も分けわからなくなる

**Socket774** · 2017/06/29(木) 21:33:38.38

>>758

これが発端だと思われる
ttp://satoru-takeuchi.hatenablog.com/entry/2017/04/24/135914

そして公式フォーラム
ttps://community.amd.com/thread/215773

**Socket774** · 2017/06/29(木) 21:33:56.70

Ryzenのエラッタが原因じゃないかというのが発端だしスレタイにintel入れる必要ないような

**Socket774** · 2017/06/29(木) 21:34:23.53

というか、Ryzen以外で発生するかは個人的にこのスレとは無関係にやればいい
それで発生したとか再現性あるんなら、改めて問題提起してどうするか考えればいい
発生しないなら報告も別にいらない

そもそもRyzenの時点で別に誰も特に困ってない上でのお遊び半分での再現検証だから
一部困っている人の為になってるといいな位は思ってはいるけど

誰も困ってない、騒いでもいない他のCPUまで手を出すのはどうかと思う
気になるなら個人的にやってほしい

**Socket774** · 2017/06/29(木) 21:35:35.83

>>757
RyzenのSEGVはきっとスタック領域不足が原因で起こっているんだよ
スタック領域を増やす設定で解決するんじゃないのか

**Socket774** · 2017/06/29(木) 21:41:18.86

>>761
>先代のCore i5を積んだマシンでは起きなかった現象です。
これじゃオイオイってなるか

**Socket774** · 2017/06/29(木) 21:42:09.39

うーんこの
http://hissi.org/read.php/jisaku/20170629/WGtIL1hRZzE.html

**Socket774** · 2017/06/29(木) 21:43:46.89

パーツ変えたり設定変えたりで治った報告がいくつかあるのを考えると
現状Intel環境で出たかどうかは切り分けのために欲しい情報ではないんだよね
まあ誰かがやってくれる分には歓迎だけど

**Socket774** · 2017/06/29(木) 21:44:15.25

>>760
OCCTやPrime95同様の耐久テストの一つに過ぎないというスレにすればいい
問題ある人があれこれ頑張ればいいだけ

**Socket774** · 2017/06/29(木) 21:46:49.44

Ryzenが本当に悪いのか？って前提から
並列処理はエラーでることがあるという話が出てきて
FXで試してくれた人がいたがSegment Faultでた
じゃあインテルは？でBroadwell-Eでは出ないって流れ
んでAMDコミュニティでLowLatencyKernelでエラーなしで長時間動いてるよと
かなりはしょったけど
他環境で試すのが必要ならやってくれる人は歓迎なんだよ

**Socket774** · 2017/06/29(木) 21:53:26.20

何回か検証して出ませんでしたで終わるなら良いけど、誰も彼もが色々やって出ませんでしたの報告だけ延々とされてもうんざりするだけ
欲しいのはどうやったら再現するのか、どうすれば改善するのかの2つ

**Socket774** · 2017/06/29(木) 21:53:26.34

追加でBroadwell-eの人はSkylake-Xでキャシュ構造変わったからもしかしたらそっちの方が可能性あるかもと>>385

**Socket774** · 2017/06/29(木) 21:54:39.80

>>770
Ryzenで出ないようにするにはLowLatencyKernelにすればいい
WindowsならMSにお願いしな

**Socket774** · 2017/06/29(木) 21:56:31.97

>>770
検証して出ませんでしたって結果も
大事なデータ

**Socket774** · 2017/06/29(木) 21:57:35.33

>>768
問題切り分けと見易さの観点から、Ryzenだけに限定したほうがいい
検証結果同士がリンクして新しい検証につながっていく現状で、全く関係ないCPUが加わると現状把握に手間がかかってスレの流れも悪くなる

**Socket774** · 2017/06/29(木) 22:00:01.19

>>769
このスレで検証してる人のBroadwell-Eで出てないのは今の所であって、確定ではない
>>385から続報がない
確定と勘違いするような表現はどうかと思うが

**Socket774** · 2017/06/29(木) 22:01:18.78

>>772
次の秋のWin10の大アップデートではLowLatencyKernelをサポートするんじゃないのか
そのうちLinux・WinもRyzen(Zen系)にOSインストールするときは、自動でLowLatencyKernelをインストール
するようになるだろ。

**Socket774** · 2017/06/29(木) 22:02:52.27

Intelでもやったほうがいいのは間違いない

Ryzenだと1/4000の確率でも出た扱いだが
このレベルだと他のパーツ起因のノイズと区別がつくのかどうか
Intelだと何をやっても1/10000でも出ないのかそのあたりは知りたい

**Socket774** · 2017/06/29(木) 22:03:27.81

>>774
ryzenだけって言ってもある意味答えが見えてるし
なぜintelを踏まえることをそこまで嫌がるのかが逆に分からない

**Socket774** · 2017/06/29(木) 22:06:55.95

>>776

えっとなに言ってるのかちょっとわからないです。
Winのカーネルが変わるってこと？は、ちょっと考えにくいんだけども。

**Socket774** · 2017/06/29(木) 22:07:21.07

>>775
すまん
恐らくもう検証してないだろうという前提で書いてしまったね

>>776
redstone3どうなるのか全く知らなかった

**Socket774** · 2017/06/29(木) 22:09:17.48

>>772
> Ryzenで出ないようにするにはLowLatencyKernelにすればいい
> WindowsならMSにお願いしな
それが結論ならこのスレは終了なんだが、それで検証中の人が納得するかな

>>773
いくつかそういう報告がある分には別に問題ないよ
似たような環境ばかりでそういうのが大量に発生してスレが流れたり混乱するのを懸念してるだけ
それに、kabylake、Skylake、broadwell(-E)、haswell、Ivybridge、Sandybridge毎に、更にi7/i5/i3/セレロン単位おまけにメモリや電源別に延々と発生しなかった報告されてもね
そこまでやるつもりなら、個別にIntelスレ作ったほうが良い

**Socket774** · 2017/06/29(木) 22:11:03.31

>>777
多くのAMDファンが検証目的のためだけにskyをボーナスで買って、両方で検証してくれると思う
CPU・マザー以外は同じハードでの結果が今週末には出るんじゃないのか

**Socket774** · 2017/06/29(木) 22:11:15.15

俺もlowlatencyやってみよう
apt install linux-lowlatencyで4.10.0-24が入ったからとりあえずこれでいいかな

**Socket774** · 2017/06/29(木) 22:13:24.05

>>783
常識的には若干パフォーマンス落ちると書いてあるから
ノーマルとのビルド速度の差とかも興味がある

**Socket774** · 2017/06/29(木) 22:13:31.00

LowLatencyKernel
が出てもryzenならOKかもしれない

でも7700Kで5GHz近くまでOCしたCPUだとLowLatencyKernelで
ちゃんと動くんだろうか？
っていう疑問も出て来る

**Socket774** · 2017/06/29(木) 22:16:49.49

>>663
少し亀レスだが
Law Latency KernelはRTカーネルと通常カーネルの中間位のリアルタイム性を持たせたカーネルでSoft-RTなどとも呼ばれているらしい
(自分も初めて知ったが)

Ubuntu Studioというディストリには標準で準備されていて、起動時のメニューから選択するとLaw Latency Kernelで起動して使えるそうだ

もしそれで本当に大丈夫だとすると、標準カーネルのスレッドコンテキストスイッチ処理がRyzenとうまくマッチしてないのか、という気がする

**Socket774** · 2017/06/29(木) 22:17:16.89

>>780
分かってもらえればおk

**Socket774** · 2017/06/29(木) 22:17:18.55

>>778
答えが見えそうなだけで見えてるわけじゃないです
それは色んな検証結果の末にスレの総意として決めることだろう
1つの問題が解決してないのに他の問題を加えるのは一般的には愚策と呼ばれる行為です
他の問題が発生したり気になるならそれは別件として処理する案件
特にIntelみたいに大量のCPUと環境が存在するものを検証するなら、専用でスレを立てるのが筋でしょう

何度も言うけど、いくつか試しにやってみる程度ならここでもいいと思います
本格的にやるなら相当な数になるから、ここでやるべきじゃないと思う

**Socket774** · 2017/06/29(木) 22:18:40.66

素人の解析ごっこ
お疲れさまです！

**Socket774** · 2017/06/29(木) 22:19:21.00

>>738
ECC無しのデスクトップ用CPU/メモリなら、ごくわずかの偶発的なエラーは避けられない

ECCありのサーバ用なら、100万回連続OKとかできて当たり前だな

**Socket774** · 2017/06/29(木) 22:21:02.61

>>785
いやいや、OCした時点で動作保証対象外だからエラー発生しても自業自得でしか無いよ
あくまで定格でエラーが出るのを何とかするのが主旨で、OCはそれを顕著にする手段でしか無い
定格で出ないならそれで終了でしょう

**Socket774** · 2017/06/29(木) 22:21:38.64

>>788
本格的も何もryzenの件も
大半の人は関係ないんだから
心配な人が勝手に耐久試験として試せばいいだけだろ
それこそOCCTやprime95と同じで
己のパソコンの為にやるんだから
その結果が誰かの訳に立てばいいだけの話しで
２ｃｈってそもそもそんなところだろ

**Socket774** · 2017/06/29(木) 22:24:02.75

>>788
大丈夫、収拾つかなくなるとかレスがどんどん流れてくとか、そんな速度で大量の情報は集まってこないよ
寧ろこういう言い合いのレスの方が割合が多いだろ

現に、情報提供でもない貴方のレスだけでも既に20以上進んでる

**Socket774** · 2017/06/29(木) 22:24:43.36

>>786

亀レスでもありがとう。
あれからちょっと調べたんだけども、多分、同じの見たかな？

ttps://wiki.ubuntulinux.jp/UbuntuStudioTips/Setup/Kernels

ちなみにWinは非リアルタイムのNTカーネルであってlow latencyなんて名前のものは存在しないと思われる。

**Socket774** · 2017/06/29(木) 22:27:12.69

なぜそこまでかたくなに拒否するのか不思議だね
Intelで何か起きたら困る人にしか見えないし
Intelで起きるのは別の現象と意味不明の予防線貼ってるのがますます謎

**Socket774** · 2017/06/29(木) 22:28:55.08

-j16 を 1実行だと1/50だった同じ環境で
-j1 で16実行開始した　make 16発www
環境とか結果はまた明日まとめて

56のスクリプトもいじってぶっつけ本番
競合しないで無事にログ取れてるといいな

**Socket774** · 2017/06/29(木) 22:30:52.69

>>794
そうそうこれ
受け売りでスマソ
NT Kernelのスレッドコンテキストスイッチ処理は無論Linuxと異なると思うが、たまたま問題が出ないのか、VAX/VMSの子孫だから実は優秀なのか、そこまでは分からない

**Socket774** · 2017/06/29(木) 22:31:23.65

>>785
言ってることの意義は分かる
多分理想はこうだ
(1) 負荷テスト総合スレ(仮)で何人かが特定の環境で問題が起きていることを報告する
(2) スレ内で簡単に解決すれば終了、解決しなければどうやら厄介な問題だということで別にスレを立てる
(3) 新たに立った専用スレで情報交換が行われる

これを踏まえると今の状況は(3)に相当するはずで、ここを総合スレにスライドするのは無理があると思った
このスレとは別に総合スレを立てるならよいのでは

**Socket774** · 2017/06/29(木) 22:37:46.43

>>794
ちょっと答えがズレてた
NT KernelのLaw latencyとかRTとかはなかったと思う
ただRTは昔どっかの会社がRT-Windowsっぽくする仕組みを出してたような気もする
(Interface誌の広告辺りで見たような)

その上でスレッドコンテキストスイッチ云々は自分の勝手な推測

**Socket774** · 2017/06/29(木) 22:38:20.63

ただ単純にあれだけ熱を発してクロックも高くしてて
温度スパイクも出てたりする訳だろ
組み立て後にチェックしてこれ以上にするとヤバイとか
おかしくなるとか速い段階でわかってた方が
ユーザーとしては後々いいんじゃないかと思っただけだけど

それだと困るような人が居るみたいだ

**Socket774** · 2017/06/29(木) 22:39:50.13

>>796
検証乙

**Socket774** · 2017/06/29(木) 22:42:46.22

>>801
ありがとう　がんばるぉ

**Socket774** · 2017/06/29(木) 22:44:49.02

>>799

見つけたよ、こんなんあった（ある？）だねぇ。
でも、スレチな気がするから、個人的に読んで楽しむことにしよう。
ありがと

**Socket774** · 2017/06/29(木) 22:46:55.85

>>792
OCCTやPrimeみたいに、という点は現状では同意する
極論を言えば自分の環境でいくらやっても出ないなら自己責任ではあるが無視してもいいわけだし
使い終わったらシャットダウンする人なら多く見積もって24-48時間位大丈夫なら無視してもいいんじゃないか、と
あくまで自己責任だけどね

**Socket774** · 2017/06/29(木) 23:01:23.10

発生頻度に影響するとみられる要素（効果のある人には効果がある）
・CPU差しなおし
・メモリ設定をゆるめる
・SOCの電圧をやや盛る(1.18Vだそうです)
・binutilsを一新(複数報告）/OS再インスコ
・BIOSアップデート
・M/Bを交換する
・ASLRを切る
・SMTを切る
・LowLatencyカーネルを使用

たいていどれかヒットするか飽きるかしてamdもgentooも該当フォーラムは
過疎ってる

バイナリが腐ってると何やってもダメというのが怖いところ

**Socket774** · 2017/06/29(木) 23:13:19.01

>>805
CPUのエラッタ、の可能性はなくなったのか？

**Socket774** · 2017/06/29(木) 23:15:41.95

>>806
ryzen環境がいろいろと相性が厳しいという意味ならある意味エラッタみたいなもんだがな

**Socket774** · 2017/06/29(木) 23:19:59.63

>>806

いや、いまとここのスレで証明らしい作業は行われていないと思うよ。
現象としては参考になるかもと思って読んでる。

**Socket774** · 2017/06/29(木) 23:20:31.37

>>806
いや、個人的にはエラッタだと思ってるよ
修正出るまではCPU側で発生率変えられないから影響リストに入ってないだけ

**Socket774** · 2017/06/29(木) 23:23:07.80

>>809

え？バイナリが腐ってるって買いたるから、てっきりソフトウェア側に原因があると考えてるんだとおもった。

**Socket774** · 2017/06/29(木) 23:24:02.70

買わない、書いてあるの間違い。

**Socket774** · 2017/06/29(木) 23:24:25.55

>>810
一般使用でまず問題ない
じゃーintelの方へってなったとして
それもまたまともに動くかどうかわからない

**Socket774** · 2017/06/29(木) 23:25:26.27

intelは今のところデータなし

**Socket774** · 2017/06/29(木) 23:32:30.09

バイナリが腐ってる云々は主にgentooの話だろう
gentooでは原則全てを自分でビルドして使うからそもそもカーネルや基本的なツールのビルド時にデータ破損が起きてると
そのせいで変なエラーが発生してもおかしくない

**Socket774** · 2017/06/29(木) 23:34:47.17

>>810
うまく伝わらなくて申し訳ない

ハードや設定をこれだけ変えても治らない！というケースでも
実は環境構築がうまくいってない、つまりバイナリ起因のケースもある
と言いたかったんだ

たとえばgentooのforumで紹介されているようなクリーンなルートを
踏んだのか、wikiで推奨されているようなツールセットを選択しているのか
そのあたりも気を付けないとあかんなあという話

**Socket774** · 2017/06/29(木) 23:36:33.00

>>806
雑誌記者
「いやいやいやRyzenに深刻な不具合は無い」
「B2ステッピングは簡単なバグ修正」
「B2ステッピング使用で性能アップもない」
「B2ステッピング登場までRyzen購入見送りなんてナンセンス」
名無し1「今日Ryzen注文する」
名無し2「雑誌記者さんあなたの意見がAMDの見解だと誤解されてるけど大丈夫？」
名無し3「雑誌記者さんあなたの発言がRyzenに不具合あることの証拠になってる」

雑誌記者「多くのハードウェア上のバグを修正したB2ステッピングがリリースされると説明してるだけ。反論とか知るかボケ」
名無し4「ちょｗ」　雑誌記者「…」
名無し5「記者さん戻ってこーい」　雑誌記者「…」
名無し6「適当言ってるん？」　雑誌記者「…」

**Socket774** · 2017/06/29(木) 23:39:23.18

>>805
>>816別発言

馬鹿「Ryzenに不具合はないネガキャンするとか最低」
↓
reddit、4han、Bloger、2ch「Ryzenは問題を抱えている（あれこれテストソース付）」

馬鹿「印象操作ウゼー。最近のBIOSアップデートで改善した（はず）」
↓
reddit、4han、Bloger、2ch「パフォーマンスアプデ前からの問題とパフォーマンスアプデ後の不具合は別物で新たな問題」

馬鹿「はいはい、ソースお願いね。何時何分何秒にエラーでたの？捏造乙」
↓
ヨーロッパメディア、業界関係者、有識者「AMDは急ピッチでRyzenの新ステッピング準備中」

馬鹿「へぇー、そうなんだ？だから何？」
↓
ヨーロッパメディア、業界関係者、有識者「AMDから突如としてCPU新ステッピングがリリースされるだろう」
↓
煽り好きのごく少数の馬鹿2chネラー「ざまーゲラゲラゲラｗ」

馬鹿「ぐぬぬ、インテルだってインテルだってインテル最低だな」
↓
ヨーロッパメディア、業界関係者、有識者「AMDはB2ステッピングという形はとるが修正と呼ぶには思いのほか問題が深刻で多岐にわたるためかなりの手直しが行われ新仕様も」

馬鹿「え・・・　ねぇねぇねぇ・・・　初期型Ryzenどうなっちゃうの？・・・」
↓
reddit、4han「B2リリースは元々予定されていたもので現行のAGESAで吸収しきれないRyzenの問題に対する抜本的な対応がとられる」

馬鹿「つまり・・・どういうこと？」
↓
reddit、4han、Twitter「AMDはただのバグフィック版Ryzenのリリースと言われるのを嫌ってる節がある。それらが何を指すか？どうやらB2steppingに新仕様が盛り込まれる。
デバイスやメモリの追加サポートなど要望のおおい事項もその可能性の一つである。改修内容についての詳細はAMDから回答をもらえていないため現時点確定事項ではない」
↓
もっと馬鹿「常にRyzenのバグフィックリリースされてるからB2出てもアップデートすれば一緒」

↑
自動翻訳混じり文章あやしい

**Socket774** · 2017/06/29(木) 23:40:04.72

>>815

わざわざ解説させてこちらこそ申し訳ない。
えと、揚げ足とりするつもりは無いんだけど、バイナリ＝２進数って意味なので・・・ちょっと用法が気になったかな。

**Socket774** · 2017/06/29(木) 23:43:14.59

>>818
すまぬ
いつもビルド結果の実行ファイルのことをバイナリと呼んでるのでその癖で
バイナリ交換やなとかそんな感じで

**Socket774** · 2017/06/29(木) 23:45:43.97

>>819

その用法はあってるんだけど・・・いや、まぁ、ハードウェア起因を疑ってるのはわかったから、了解ってことで
ひっぱってごめんね。

**Socket774** · 2017/06/29(木) 23:47:08.04

Intelではどこも騒がれてない
ここでも幾つか検証したけど出てない
定格で出ないからOCしてみようとかいう始末→定格で出ないなら問題ないでしょう
何でIntelでやろうとしてるのか分からないんだが
というか、何でIntelに拘るのかわからない

CPUをRyzenに限定してるから、メモリやBios、クロックや各種ツールと幅広く検証を行えてるんだが
それをIntelという曖昧なくくりだとCPUだけでも膨大で、マザーやメモリや他の条件考えたら収集つかなくなるのは分かると思うけど

**Socket774** · 2017/06/29(木) 23:47:57.31

Ryzen B1買った人達が不憫でならないなぁ
AMDは工作員雇う暇があったらB1買った人に保証してやれよｗ

**Socket774** · 2017/06/29(木) 23:56:07.04

>>822
別に不憫に思ってないだろう
Linuxで問題あるって返品したら新品くれるぞ？
みんな道徳心高いから難癖つけるのが嫌だから境界を調査しているだけで
長くても1、2ヶ月待てばb2ステッピング貰えるからどうでもいいんだよ

**Socket774** · 2017/06/29(木) 23:57:37.53

>>822
初物はこういうことまで覚悟してるから別に・・・

**Socket774** · 2017/06/30(金) 00:11:39.24

AMDが工作員雇えるほどの余裕があると？
工作員雇える余裕がある会社なんて資金たっぷりなあの会社しかありませんわ

**Socket774** · 2017/06/30(金) 00:13:01.46

>>823
交換して貰えるってフォーラムで騒がないと応じないでしょ

**Socket774** · 2017/06/30(金) 00:14:08.03

青い会社はEUでいつ制裁金の最終判決出されてもおかしくないのに余裕だなー
skylake-ep出た後に制裁金確定という欧州委員会が教科書的な制裁加えるとかなり売り上げに響くけどねぇ
成長痛とか言ってられんけど

**Socket774** · 2017/06/30(金) 00:14:14.11

intelは騒がれてないというより
intelのハイエンドで検証が行われていない
ネットにもデータがない

**Socket774** · 2017/06/30(金) 00:15:09.54

>>826
指定された表題で支持された情報英語で送ればRMA受け付けてくれるよ
個別対応だが

**Socket774** · 2017/06/30(金) 00:16:54.17

>>829
なるほど
B2ステッピングなったら試してみるか

**Socket774** · 2017/06/30(金) 00:19:18.90

>>651
ちなみにこれでok20000のうちして1回NGでたわ
無視していいレベルかはしらん

**Socket774** · 2017/06/30(金) 00:20:05.68

Linuxのカーネルコンパイル自体
Linuxユーザーであっても特別な人以外はほとんどしない
だとしても7700Kを買ってるユーザーはたくさん居るはずなんで
ここはデータがあってもいいはずだが
データがない

**Socket774** · 2017/06/30(金) 00:25:23.66

>>828
購入者が少ないから相対的にて

**Socket774** · 2017/06/30(金) 00:25:53.59

>>831
メモリクロック2933なの・・・？
それでそのレベルなら無視していいレベルじゃないのかね
詳しく検証してくれた人はメモリ設定ゆるゆるにして徐々にSEGV減ってたし

**Socket774** · 2017/06/30(金) 00:26:20.32

http://news.mynavi.jp/news/2017/06/29/282/
このクラスのマザーを今更出してるってことは
ここまでやらないと安定しないのかもしれないが

検証してみないことにはわからない

**Socket774** · 2017/06/30(金) 00:28:25.67

自分の環境ではSEGVはまだ出てないがSSDに替えてから>>56のこの現象が出るようになった

5.SEGVは発生しなくなったが、makeがwait()でハングアップするようになる(子プロセスのgccがハングアップしていて、それを待っている状態)。

SSDに替えて自動で回し始めて6回目で発生
dmesgには開始後から何も追加されていない
化石HDDのようなストレージ周りのトラブルではなさそう
念のため psの出力をファイルに保存しシャットダウン
(makeの出力結果はteeでファイルに残している)
コールドスタートしてもう一度走らせたら3回目でまた出た

環境は>>292の化石HDDを次のSATA 60GB SSDに変え、SecureErase後ubuntuを再インストールしたもの

SSD:Patriot Blaze SSD 60GB PB60GS25SSDR

1500Xの場合make -j8は化石HDDで約25分だったがSSDで約18分まで速くなった
そしてSSDに変えた途端現象の一部が出始めた
PC全体である程度の速さ、特にストレージの速さがないと出にくいのかもしれない
(遅めのHDDでも出てる人がいるなら話は別だが)

まずは現象の出る機械が目の前にないと何もできないが一歩近づいた
ハードは出来るだけ交換せず、メモリスピードや電圧の設定変更などでSEGVに持っていこうと考えている

**Socket774** · 2017/06/30(金) 00:37:11.54

流れ的に見ると
7700Kあんだけ売れてるけどあのハイスペックで
連続コンパイル大丈夫なのか？って疑問だけが残るけど

**Socket774** · 2017/06/30(金) 00:38:02.42

OCもメモリやら電圧やらの手動設定もおこなわずに、標準設定で高確率で起こるなら
ryzenのバグに決まってるでしょう

**Socket774** · 2017/06/30(金) 00:40:44.75

おそらくAMDはリコール対応はしないとおもうよ
リコールしたら多額の費用がかかるから

一部不良品が混ざってる、不良品だった人は症状を添えて申し出てくれば交換対応をする

この程度でしょう

**Socket774** · 2017/06/30(金) 00:42:03.96

高確率ってほど出ないんだよなぁ

**Socket774** · 2017/06/30(金) 00:42:05.51

リコールはないだろ
パワー落とせばNG出ないんだから

**Socket774** · 2017/06/30(金) 00:43:47.36

しかも
パワー落とせばNG出ないっていうのは
もう過去のデータからわかっていることで
だからLinuxユーザーは並列コンパイルで失敗するかもしれないから
シングルでやっていた

**Socket774** · 2017/06/30(金) 00:45:26.51

>>836
HDDの場合、HDDの読み書き待ちでCPU負荷が上がらずに遊んでるからでしょう
SSDの場合、読み書きがはるかに高速なので、CPU負荷が上がる

**Socket774** · 2017/06/30(金) 00:45:36.94

当然i5を所有しているLinuxユーザーもパラレルコンパイルでハングすることを知っている

http://d.hatena.ne.jp/yamidori98/20130627/1372353889

オブジェクトの生成(makeの実行)

「-j*」を付けない場合、シリアルコンパイルになるため、基本的にコンパイル問題は発生しなくなります。ただし、コンパイル時間が長くなります。Core i5クラスで4時間程度掛かります。

「-j*」を付けた場合、パラレルコンパイルになるため、希にコンパイルの途中でハングすることがあります。ただし、「-j*」を付けることによって、コンパイル時間を減らすことが可能です。

**Socket774** · 2017/06/30(金) 00:50:23.68

>>839
俺もだが実はB2が出たら交換してもらおう(交換にトライ)って思っている奴がいっぱい
年末までにはB2でるような感じなんだろ

**Socket774** · 2017/06/30(金) 00:51:31.09

はっきり言おう

intel信者なのか営業なのかが頑張ってるだけ

**Socket774** · 2017/06/30(金) 00:54:41.02

>>844
make -jX やら　ninja　や　/MPでマルチコアコンパイルは普通
マルチコア時代にわざわざシングルコアでするってアホだろ

**Socket774** · 2017/06/30(金) 00:56:21.61

>>847
重要なのはそこじゃない

パラレルmakeが失敗することを認識している＝おそらくそれをやって失敗している

という事実

**Socket774** · 2017/06/30(金) 00:58:24.58

2133JDEC仕様でもエラー出るし不良品だろRyzen

**Socket774** · 2017/06/30(金) 00:59:55.29

普通に考えたら不良だな
不安を抱えたまま使い続けることに

**Socket774** · 2017/06/30(金) 01:00:13.57

B2ステッピングはSEGVの修正がなくてもメモコン周り修正くるみたいだし普通にほしいわ

**Socket774** · 2017/06/30(金) 01:00:23.89

intel信者か営業だわ
必死に煽ってるのは

**Socket774** · 2017/06/30(金) 01:01:57.41

サーバ機なら、並列コンパイル１００万回実行して１回でもハードウェアが原因のエラーが出れば不良品だといっていい

デスクトップPCなら、どのレベルの信頼性が求められるのかはいまいちわからんが、
１００回に１回なら不良品といっていいでしょう
１万回に１回とかなら知らん

**Socket774** · 2017/06/30(金) 01:02:05.88

Intel側でSEGV発生したら煽ってる連中ショックで倒れちゃうから誰もやりませんわ

**Socket774** · 2017/06/30(金) 01:04:12.02

>>844
6850Kの人も来ないし、手持ちのインテル機で一番速いのはXeonE3-1220v2(Ivy 3.1GHz 4C4T)なんだけど一応走らせてみるか
富士通のサーバ機なのでおま環要素減るしメモリもECCだからECCメモリガーの反論にもなる

>>836
自己レスだけど、設定変更だけだと元に戻せばSEGV出なくなるという事だから意味無いよね
1700も持ってるけどできれば1500Xで出したいので今後のやり方は改めて良く考えてみる

**Socket774** · 2017/06/30(金) 01:06:02.70

>>850
だろ。交換してもらえそうなネタ(SEGV)があるから個別で良いから交換しろってクレーム

**Socket774** · 2017/06/30(金) 01:08:15.29

>>856は>>851

>>855
XeonE3-1220v2でも良いんじゃないのか

**Socket774** · 2017/06/30(金) 01:12:00.55

>>852
工作員
業者
アンチ
アフィブログ関係者

と思われるので相手にしなくておk
スルーで

**Socket774** · 2017/06/30(金) 01:18:07.01

>>858
そんな奴が現れてどこのサイトも
閑散として問題になってないんだろ

**Socket774** · 2017/06/30(金) 01:21:48.13

努力は認めるが
どんなに頑張ってもあの爆熱は厳しいぞ

MBとCPUの売り場
近所ショップでは
intelとAMDで4：6の割合になってるが
次はi9とryzen3だろ？

厳しいぞ

**Socket774** · 2017/06/30(金) 01:28:24.05

すまんbro-e6850Kの者だけど忙しくて昨日おとといと回せてなかった
今日休みだから一日中回してみるよ
また夜に報告しに来る

**Socket774** · 2017/06/30(金) 01:39:10.73

>>861
待ってたよ!
催促したみたいになってすまん
報告待ってる

**Socket774** · 2017/06/30(金) 01:53:52.94

>>861
追伸
>>836に書いたが、ストレージが遅いと出にくい模様
できればSSD(消耗するから気が進まんかもしれんが)か、高速HDDで試してもらえるとありがたい
(判断はお任せします)

**Socket774** · 2017/06/30(金) 01:58:53.82

>>844が現状の見解でそもそも不安定な設定状況が前提で検証してるのを忘れないようにな
INTEL,AMD関係なくパラレルコンパイルで稀にSEGVが発生するのは今始まった話ではないし過去にも度々発生してる

**Socket774** · 2017/06/30(金) 01:59:08.54

OK10000でもカーネルのファイル数50000以上だからコンパイル完了を想定するなら全然足りないな

**Socket774** · 2017/06/30(金) 04:58:05.38

コンセント逆差し、人に言っときながら自分でやってなかったのでやってみた
驚く事に止まる現象が出なくなった

しばらくして確認したら1回だけ途中で終了していたが、スクリプト間違いでエラー出力がファイルに残らず、何が起きたか分からない(SEGVの可能性はある)
さらに、teeを使うとこの後のif文でteeの処理結果を判定してしまい、全てOKが出力されてしまう事も分かった

>>510のmakeの出力をteeで残すのは忘れてください
勉強不足でどうもスマン

makeの出力をファイルに残したい場合は画面表示は諦めて
make -j 16 >/root/make_$(date +%y%m%d%H%M%S).log 2>&1
という感じにするのしか思いつかない

**Socket774** · 2017/06/30(金) 06:25:57.79

>>866
bashなら
$? の代わりに ${PIPESTATUS[0]} でパイプの1つ目のコマンドの終了ステータスが取れる

**Socket774** · 2017/06/30(金) 06:51:44.11

>>865
ryzen_segv_testは8ビット加算2～3回やって終わりとかじゃないっぽいから、とりあえず20000ぐらいOKなら良いんじゃないかな
http://i.imgur.com/zQGlLHC.png

**Socket774** · 2017/06/30(金) 07:05:15.33

コンセント逆刺しってなんだろう
コンセントって交流で向きなんかあるかと思ってたがあるみたいだね
http://pabasic.com/denkinokiso/dengennokyokusei/

**Socket774** · 2017/06/30(金) 07:19:59.34

>>844
元々のLinuxカーネルが腐ってるだけじゃね？
何かのタイミングで違うデータを引っ張ってきた場合でも、それを検出しないのかと
>>797で言ってるカーネルはその部分にワンクッション入れてあるんだと思う
これだけ現象が出ててWindowsで何も出ないとなると、それ位しか考えられん
仮想マシン上だと安定するっていうのは、そこの部分の監視を仮想マシン側がやるからなのかね？
商用で立ててる仮想上で「違うデータ引っ張った」は致命的だし、AGESA 1006で新たにサポートしたACSはまさに仮想上での監視強化だよね

**Socket774** · 2017/06/30(金) 07:24:52.61

これでリコールならインテルはリコール大発生だな

**Socket774** · 2017/06/30(金) 07:51:20.02

>>869
3線式100/200の100側ならね
本当はアースを取った方が良い
どの道D種接地じゃ気休め程度だし、DC特性は良くてもAC特性は帯域不足だから
デカップ盛るしか有効な手法は無いけど

一瞬で3桁Aオーダーの負荷が立ち上がるような機械だし、アナログ特性ももっと洗練出来る電源規格が欲しいよ
エラー如何は別にしても、今後よりこう言った条件はキツくなりこそすれ緩くなる事は無いからね

**Socket774** · 2017/06/30(金) 08:11:17.70

>>710
646だか、メモリタイミングを手動にしてもう一度やったが61まで耐えた
確率的にはプラグ逆差ししようがしまいが、1/50くらい
BIOSアップ前は1/7くらいなので、大きな改善ではある。

ESXiは普段使いしているよ。
特に不安定とか落ちたりなどということは一度もない。

**Socket774** · 2017/06/30(金) 08:22:04.21

>>836
56だが、おれはramdisk上でのmake。
ストレージが早過ぎると問題あるのかな？
メモリクロック落としたら、makeがwaitでとまる現象はなくなった。

**Socket774** · 2017/06/30(金) 09:29:08.69

make のオプションは
コア数+1 が最適らしい
make -j9
gentoo のインストールマニュアルより

**Socket774** · 2017/06/30(金) 09:43:12.36

でかい声のアンチが騒いだだけの
おま環ネタに真面目に取り組むとか皆優しい脳

**Socket774** · 2017/06/30(金) 09:53:34.35

検証もせず20以上レスしてスレを仕切ろうとしてたやつとかなんなの？

**Socket774** · 2017/06/30(金) 09:59:19.88

あげく「IntelCPUで検証する理由がわからない」とかワケわからないこと言い出してたな
言えるのはただひとつ
陰厨乙

**Socket774** · 2017/06/30(金) 10:17:17.34

>>866

それ、たぶん差込み方向関係ないよ。てか、電源コードからアース線でてなかった？
それが宙に浮いてる時点でどっち向きとか関係なくなってるから。

でも、もし逆に刺してて正しい向きになおしたから改善されたと考えるならば、
電源単体での検証に切り替えたほうがいい。

個人的には一次電源が原因だとしたら、むしろ問題はSEGVにとどまらず発生していると思う。
極端な話、ケースに触ったら感電したとかね？

**Socket774** · 2017/06/30(金) 11:04:08.14

ID:XkH/XQg1 ←こいつか

**Socket774** · 2017/06/30(金) 11:23:20.07

IntelとAMDスレタイ入りで

**Socket774** · 2017/06/30(金) 12:09:02.95

intelのCPUで検証するのはいいけど一番必要なのはB2との比較だろうし
B2で検証されるまでは今のスレタイのままでいいと思うぞ

**Socket774** · 2017/06/30(金) 12:17:04.93

まー一緒でいんでない？
マルチのオプションの是非にも話は及んでる訳だし。
報告大杉なら分ければ。

**Socket774** · 2017/06/30(金) 12:22:22.14

>>672
この環境でメモリ、電圧、各設定を総当たりで試したけどエラー消える設定見つけれなかった
とりあえずもうすぐ出るらしい次のBIOSまで休憩する
OCCTとかと違ってOSごとハングとか危険な状態にならないのが救いか

**Socket774** · 2017/06/30(金) 12:39:34.69

ID:XkH/XQg1 みたいな淫厨が湧くようなスレタイだけは絶対に許さないよ

**Socket774** · 2017/06/30(金) 12:42:19.41

intelのcpuを検証するのは有益
ただし全てはryzenのためにする行為であるべき
それがこのスレの趣旨

タイトルにintelは要らん

**Socket774** · 2017/06/30(金) 12:50:47.46

おっ、本人か

**Socket774** · 2017/06/30(金) 12:51:11.38

スレタイってのはスレの内容を示すものだ。
スレでIntelチップも扱うのなら含めろよ。

**Socket774** · 2017/06/30(金) 13:01:28.26

ソフトのバグかどうかの検証用にintelを使うってだけならタイトルには書かない方が良い

**Socket774** · 2017/06/30(金) 13:05:16.41

・このスレはエラッタを仮定してる
・Ryzenのハードウェア的問題に、（仮に発生するとして）IntelのCPUの問題は関係ない

IntelのCPUに同様の問題があるなら別のスレでやるべき

**Socket774** · 2017/06/30(金) 13:06:38.69

866だがSEGV出た
要は現状うちの場合
・コンセント方向A wait発生
・コンセント方向B SEGV発生
という状況
わざと糞電源使ってたからアース取ったり最近買った新品電源ユニットに変えたりしてみる
あと極性も調べておく
(方向AとかBではおま環情報でしかない)
出先なので続きは帰ってから

>>872
単相200Vも1系統あるから該当する

>>879
バラックなのでケースはないが、マザーのGND部分や電源ユニットの金属部分に触ってもビリビリはしない
ケースに入れてるPCもビリビリはしない

**Socket774** · 2017/06/30(金) 13:06:53.95

開発用途で、make中にSEGVが発生したら、普通はコンポーネント順番に取り替えて原因を特定する
Ryzen以前に特定の環境でそんな問題が頻発してたら、gentooあたりが認知してないわけがない
Ryzen環境で、コンポーネント全部取り替えても問題が解消しないからgentooフォーラム（https://forums.gentoo.org/viewtopic-t-1061546.html?sid=109711a1cef306f68e5199d00681eac0）でも騒いでるわけで…

**Socket774** · 2017/06/30(金) 13:12:28.24

>>890
エラッタとして仮定っていつからそうなったよ
エラッタかどうか確かめてみようから始まったスレだぞ

**Socket774** · 2017/06/30(金) 13:14:57.72

スレタイにIntel入れなるならIntelCPUでSEGV確認してからでいいと思うがな

**Socket774** · 2017/06/30(金) 13:17:09.90

しいていうとryzenはまだ確定でバグ持ちと決まったわけじゃないし問題を検証に変えるべきかと

**Socket774** · 2017/06/30(金) 13:19:20.58

これだけ出ておま環か？
そんな馬鹿な

**Socket774** · 2017/06/30(金) 13:21:30.18

>>896
これだけ発生頻度もバラバラなのにCPUエラッタで済ませられるか？
8割方CPUが原因だろうけど絶対とは現状言い切れないわ

**Socket774** · 2017/06/30(金) 13:22:14.25

エラッタかどうかは知らんけどメモコンがクソなのは確か

**Socket774** · 2017/06/30(金) 13:24:08.26

メモコンが微妙てのはマイニング界隈の様子見てて何となく感じてる

**Socket774** · 2017/06/30(金) 13:25:57.97

メモコンもRyzenの一部だろうが
「問題」で問題なし

**Socket774** · 2017/06/30(金) 13:31:05.53

>>900
問題あるクソなんだしIntel買えばいいじゃん

**Socket774** · 2017/06/30(金) 13:41:26.86

>>891

>要は現状うちの場合
>・コンセント方向A wait発生
>・コンセント方向B SEGV発生
>という状況

ますます、いったん電源の件は忘れたほうがいいと思うんだけど・・・
なんてか、コンセントの向きでCPUの動きが制御できるってことでしょ？
・・・まぁ、絶対にないとは断言しないけど、判断は詳しい人に譲るよ・・・

あと、ビリビリはごめん、そのためみたいなもんだからね、アースってのは。

ATX電源はスイッチング電源だよ。
AC100Vにのってるノイズ（落雷？）ではなく、疑うならMOSFET以降のコンデンサだと思うけどなぁ。
あくまで、疑うならばだけども。

**Socket774** · 2017/06/30(金) 13:43:44.81

gentoo のryzen未対応のgcc
古いbinutils でビルドしたのが
原因では？
gcc7 + linux4.12 でやってみたら

**Socket774** · 2017/06/30(金) 13:49:38.65

>>890
エラッタであるという仮定が大前提なら、もう2chのスレじゃなくてツイッター上であの人達と連携した方が良いんじゃない？

スレ分けると情報の連携もしにくくなるし

**Socket774** · 2017/06/30(金) 13:57:47.29

複合的な要因なんかな
ますますKP41めいてきたな

**Socket774** · 2017/06/30(金) 13:59:33.43

intel勢の煮詰まり方が半端ないな

**Socket774** · 2017/06/30(金) 14:00:09.58

>>900
>>901みたいに対立うむだけで良いこと無し。検証でいいとおもう

**Socket774** · 2017/06/30(金) 14:04:37.44

intelが煮詰まってるからなー
煽りは止まらんぞ

**Socket774** · 2017/06/30(金) 14:12:32.35

爆熱でお湯沸かして煮詰まってんの？

**Socket774** · 2017/06/30(金) 14:14:58.72

煮詰まる
の意味しってる？

**Socket774** · 2017/06/30(金) 14:19:40.51

特定の原因じゃないのはほぼ確定でしょ
色んな方法で出たり出なかったりだし
コンセントの抜き差しも含めるなら、おま環の相性問題の可能性が一番高い
まあ、一番の問題はRyzen自体が相性にシビアということだろうけど
昔から環境に関係なく似たようなエラーが出るらしいことも分かったし

**Socket774** · 2017/06/30(金) 14:41:50.51

とりあえずﾋに転がってたソフト回したら5000ループ回った時点ででng6回出た

**Socket774** · 2017/06/30(金) 14:42:46.68

来月B2が出たらB1使ってるのがおま環になるわけだな

**Socket774** · 2017/06/30(金) 15:00:52.11

そりゃないだろ
ryzen3が出るんだし
intel勢が適当なスペック表示して
「B2でもNGでるよ！」
そう報告して煽るだけ

**Socket774** · 2017/06/30(金) 15:05:41.56

>>911
そこ改善のB2ステッピングだろうしね

**Socket774** · 2017/06/30(金) 15:08:13.92

B1の時点で一般的には無視できるレベルだからB2でそんな煽りされても無視するだけでしょ
2chですらここ以外じゃ誰も話題にしないくらい興味も影響もない

**,,・´∀｀・,,）っ-○○○** · 2017/06/30(金) 15:08:48.39

エラッタリストにも上がってない症状がなぜステッピング変わったら対策されると思うの

**Socket774** · 2017/06/30(金) 15:09:11.11

必死に買い抑えを狙うB2ステップ煽り

intelいよいよ来てるわ

**,,・´∀｀・,,）っ-○○○** · 2017/06/30(金) 15:10:59.49

>>916
そもそも消費者がRyzenに興味持ってないだけだろ
Twitterですらあのざまだよ
みんなスマホの新機種や新しいSurface,MBPの話をしている