【エラッタ】Ryzen SEGV問題情報交換【フリーズ】 [無断転載禁止]©2ch.net

**Socket774** · 2017/06/21(水) 11:31:47.10

Ryzen SEGV問題についての情報交換スレです

B2ステッピング登場？
https://twitter.com/CPCHardware/status/876193860946468865

**Socket774** · 2017/06/21(水) 11:43:50.40

これってWindows上でgccでsegv出る条件でコンパイルしても出るの？

**Socket774** · 2017/06/21(水) 12:47:59.94

出る

**Socket774** · 2017/06/21(水) 14:33:42.83

それは初耳
スクショとかある？
自分でやってないなら出た人のtwitterのツイートとかでもいいけど

**Socket774** · 2017/06/21(水) 17:11:47.35

くこか
ペンギン村にもカキコしたけどここでも
http://hayabusa6.2ch.net/test/read.cgi/linux/1316419256/210

https://twitter.com/satoru_takeuchi/status/877324605706313728
交換品はB2かな？wktk

**Socket774** · 2017/06/21(水) 17:19:44.44

AMDから直接送られて来るのかこのツイートでは分からんから現状なんとも言えんな
続報を待つとしよう

**Socket774** · 2017/06/21(水) 17:33:26.32

ここでメモ
https://twitter.com/hashtag/Ryzen_SEGV_Battle?src=hash
https://search.yahoo.co.jp/realtime/search/Ryzen_SEGV_Battle/

>>6
https://twitter.com/satoru_takeuchi/status/876914187573710848
AMDサポートが個別対応とのことだけど、やっぱりどーなるんだろ？
ｗｋｔｋのAA省略

**Socket774** · 2017/06/21(水) 17:35:27.30

Ryzen General Protection Exception
http://www.e-hdk.com/diary/d201706c.html#20-2

**Socket774** · 2017/06/21(水) 17:44:04.34

>>7
AMDから個別対応扱いになってたのか
ならその前提で続報待ちだな

**Socket774** · 2017/06/21(水) 17:46:56.40

>>8
これはビルドしたカーネルが仮想マシン上で動かない件の詳細な調査事例
残念ながらエラッタがある模様
マイクロコードで直せるレベルなのか？

**Socket774** · 2017/06/21(水) 17:54:38.63

>>10
仮想鯖もするとこあるはず
んで、発表会のデモ↓
https://twitter.com/Hyper_beta/status/877408252937424896
> EPYCのデモでAMDがLinuxをビルドして見せたのは、メッセージなのかもしれない？
> #Ryzen_SEGV_Battle

直ったのかな？

**Socket774** · 2017/06/21(水) 17:58:20.26

スラドでトピが立った>>8
<title>Ryzen SEGV Battle、原因の一端が解明される | スラド Submission</title>
https://srad.jp/submission/71785/

**Socket774** · 2017/06/21(水) 17:59:01.60

EPYCはB2ステップなんでしょ
マイクロコードで直るのかはB1ステップを使ってる者として心配という意味

**Socket774** · 2017/06/21(水) 18:03:01.17

(｡･･｡)(｡. .｡)ｳﾝ

**Socket774** · 2017/06/21(水) 18:24:41.89

スラドのトピックの書き方だと>>8の現象が仮想マシンでのカーネル起動失敗とgcc segvの両方に関係するように読める
B2ステップでは直してるだろうけど、B1ステップをどうするかがまだ決まってなくてAMDとしては現時点では話を大きくしたくないのだろうなと感じる
続報待ちだな

**Socket774** · 2017/06/21(水) 18:47:34.88

まあIntelもTSXとかマイクロコードで修正むりなのやらかしてるしな

**Socket774** · 2017/06/21(水) 18:57:20.69

最悪コーディングレベルの回避方法が出るだけでもいいとは思う
リコールは今のAMDとしては避けたいだろう
下手すりゃ倒産するか買収される
折角インテルのケツをけっとばせたのにまたサボりボッタクリに戻ってしまう

**Socket774** · 2017/06/21(水) 19:20:18.30

https://twitter.com/Star_Craft/status/875594079534325766
> #Ryzen_SEGV_Battleの動画

こりか
Ryzen SEGV Battle
https://youtu.be/n4n84W0XUvM
ライブ配信だったのでチャットはない
4時間……

**Socket774** · 2017/06/21(水) 19:24:11.70

ほぼ5時間だたー

**Socket774** · 2017/06/21(水) 19:42:57.54

あっちのスレでEPYCがB1だってホント？
マザボで合わせてるのかな？
RyzenもBIOSとかのうｐだてで対応できる？

**Socket774** · 2017/06/21(水) 21:28:44.46

>>15
むしろcall命令で呼び出し先が-64バイトずれたら、もっと多様な問題が起きると思うが
発現頻度がかなり低いか、特定の条件があるのか

AMDが問題をどれだけ早く認識していたかによってはB2 steppingでも直ってないかもしれない。

**Socket774** · 2017/06/21(水) 21:44:48.27

これLinuxだけの問題じゃないよね
Windowsでも起きうるよね？

**Socket774** · 2017/06/21(水) 21:49:12.59

詫び石配布まだ？

**Socket774** · 2017/06/21(水) 22:05:15.48

スパッと例外で死んでくれたからまだマシだけど
64バイトずれたら何が起こってもおかしくないよね
データが漏洩するとか、間違った額を送金しちゃうとか、爆音がなるとか、データ消失とか、....

地雷を抱えたCPU

**Socket774** · 2017/06/21(水) 22:20:38.36

後から出てくるバグほど影響のデカいのが多いからな

**Socket774** · 2017/06/21(水) 23:59:35.67

命令デコーダの異常か…
デコード後のμOPsがキャッシュからあふれた時の処理がおかしいんだろうな

**Socket774** · 2017/06/22(木) 00:03:52.11

問題を修復した人発見

0384 Socket774 2017/06/21 21:53:06
>>375
Linuxで相性の悪いメモリ使っててカーネルコンパイルするとランダムで起きる
そしてコンパイル通った場合でも、そのカーネルに書き換えるとカーネルパニック起こして起動しなくなる
メモリを交換するとSEGVは起きなくなったんだよな
とにかくメモリ相性が厳しいからなあ

**Socket774** · 2017/06/22(木) 00:07:19.05

B2ステッピングはメモコンバグ修正だから直るかもね
B1はおつでしたわ

**Socket774** · 2017/06/22(木) 00:09:02.14

http://satoru-takeuchi.hatenablog.com/entry/2017/04/24/135914

何かしら負荷がかかるとマズイらしい

ちなみにSEGV起きない人は起きないらしいので

**Socket774** · 2017/06/22(木) 00:16:09.57

VRMが貧弱・フェーズ数少ない安マザーでコアOCしている
メモリVRMが1フェーズで出来のよくない安マザーでメモリOCしている
とかいうオチだったら笑うわ

**Socket774** · 2017/06/22(木) 00:59:28.12

＞0x40バイトずれた命令を実行
CPUとして販売できないレベルだろこれ

**Socket774** · 2017/06/22(木) 01:17:57.86

>>31
元はともかく、そういうことをわかってないレベルのやつが今騒いでんだろ

**Socket774** · 2017/06/22(木) 01:35:12.07

>>32
逆汗して解説してくれてる人いるから見てこいよ
騒ぐ騒がないというレベルの問題じゃないから

**Socket774** · 2017/06/22(木) 01:41:45.60

これ何でWindowsだと報告が無いんだ？

**Socket774** · 2017/06/22(木) 01:44:39.12

全然良くわかってないんだがこれ科学とか数学の厳密な計算とか大丈夫なのか？

**Socket774** · 2017/06/22(木) 01:52:41.81

>>35
ただのビルドなんで
gccを並列ビルドしないだけでも大方問題は解決するんじゃないか

というより現象が人によって様々なんだろう
多分上の人が言ってるようにメモリーが不安定なのかもしれんな

**Socket774** · 2017/06/22(木) 01:53:16.54

オワータ

**Socket774** · 2017/06/22(木) 01:59:46.44

メモリー入れ替えてなおった人が居るんで
なおらないことはない

Linuxによくある相性の問題かと

**Socket774** · 2017/06/22(木) 02:40:41.51

この人ソフト屋さんだからソフト面で頑張って調査してるけど発生の有無とかランダム性を考えるとハード不良もしくは相性な気がする
上でメモリ交換で直ったって話もあるけどとりあえず
コア電圧とメモリ電圧盛ってみてほしいわ
場合によってはsoc電圧もか

あとlinuxにあるのか知らないけどモニタリングソフトでクロックとか電圧をモニタリングしながらコンパイルしてその変動がトリガーなのかどうか調べてみてほしいところ

**Socket774** · 2017/06/22(木) 02:43:01.53

こういうのがあるからAMDは仕事用に採用しにくいんだよなぁ
良い製品が出来たのにほんともったいない

**Socket774** · 2017/06/22(木) 02:50:58.36

まーいいじゃん主張した人はCPU交換してもらえたみたいだし
7700Kの温度スパイク問題みたいに
ユーザー「ファンが唸ってるんですけど」
intel「そんな現象は発生しません。」
でフォロー無しで終わった
あっちの方が被害大きいだろ

**Socket774** · 2017/06/22(木) 02:51:46.24

>>34
64バイト前方にずれるので同じ命令を二度実行しても、データや結果が不正に化けるだけでエラーにならない場合もある。
WindowsはLinuxみたいなシステムと違って、エラーメッセージが貧弱だから問題が起きてもブルースクリーンが出たで済まして
原因究明する利用者が少ない

>>40
本当にウキウキな気分だったのに泣きたい
I wanna cry.

**Socket774** · 2017/06/22(木) 02:52:44.49

これCPU原因なら近年まれに見るバグだな
いきなり新アーキだからしょうがないのかもしれんが

**Socket774** · 2017/06/22(木) 02:57:57.46

どっちもどっちだって
Intelもここ10年内に登場したCPUに潜むリモート操作される脆弱性とかって修正だしとったでしょ
リモート管理機能のバグで
コンピューターを遠隔でフルコントロールされる危険性があることが判明し、
2017年5月1日にIntelは脆弱性を修復する緊急パッチをリリースとか

**Socket774** · 2017/06/22(木) 03:09:04.19

あれってAMTだけと言ってるが、実はME搭載機全部(Core iシリーズほとんど)じゃないかと思ってる
また10年後に実は・・・とか言いそう

あとatom C2000の突然死問題の方がよっぽど致命的だな
あれは運用開始後に発覚してるから、ネットワーク機器の会社が頭抱える羽目になったとか

**Socket774** · 2017/06/22(木) 03:12:27.02

Intelの話はスレチ

**Socket774** · 2017/06/22(木) 03:18:25.87

スレチだが、近年まれに見るという話だったから、他の近年まれに見る事例の話になったと思う
まあ止めとくわ

**Socket774** · 2017/06/22(木) 03:40:12.51

Pentium 66Mhz並のバグか？
全数リコールｗ

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

メモリ交換で命令デコーダのバグが直るってどういう仕組みだよ

**Socket774** · 2017/06/22(木) 06:52:47.37

>>39
ハード不良の原因をソフトで絞るのはよくあることだと思うけど

**Socket774** · 2017/06/22(木) 06:54:25.81

>>49
たまたまタイミングがずれてその場所では発生しなくなるとか

**Socket774** · 2017/06/22(木) 06:55:34.74

>>48
演算結果不定よりは動作不定の方が一般的には重い

**Socket774** · 2017/06/22(木) 07:09:22.76

AMDにとっては幸いなことにgcc以外でバグが発生してないからな
リコールはない

**Socket774** · 2017/06/22(木) 07:13:55.63

発生してないなんてわからんでしょ

**Socket774** · 2017/06/22(木) 07:26:54.14

デコーダー異常なんて発生したらフリーズするから誰でもすぐわかるがな
誰しもバグが発生しPCの使用に支障が出てる訳ではない

**Socket774** · 2017/06/22(木) 07:36:21.00

出ない人もいる
メモリ相性電圧冷却クロックで出方が変わる
Ｂ２でアンコアに修正入る

相性厳しかったんだなという印象

**Socket774** · 2017/06/22(木) 07:48:44.07

ECCメモリも使えないような環境でデータ化けの心配をするとか、一体どういう神経してるんだろう
EPYCなら致命的だがRyzenはホビーユースで出してる製品だろうに…

**Socket774** · 2017/06/22(木) 08:05:36.93

ホビーじゃないだろ
ビジネスにも使われるぜ
正直今回のエラッタは深刻だと思うけどな
とっとと糞石処分してB2買いたいわ

**Socket774** · 2017/06/22(木) 08:11:01.40

ECCは宇宙線なんんかの特殊なエラーから守るためのものであって、
普段からエラーでっぱなしとかたとえデスクトップ用でも欠陥品だろ

**Socket774** · 2017/06/22(木) 08:12:04.08

何が深刻かって現象の程度ではなくAMDが対応策発表しない点だな
100%発生するパターンがないから発表のしようがないのかもしれんが
解決策発表しないとソフト側も対応出来ないから放置のままだし

**Socket774** · 2017/06/22(木) 08:16:21.70

>>55
発生してないなんてわからん

**Socket774** · 2017/06/22(木) 08:18:31.56

今のところ表だって騒いでる人がいない
というだけ

**Socket774** · 2017/06/22(木) 08:28:34.06

AMDも理由があって現時点で何も言わないor言えないんだろ
公式発表を待つしかあるまい
幸い発生条件が限定されてるようだし
メモリ交換で直った事例があるならCPUエラッタなのかマザーの設計が悪いのか個体差なのか単なる故障なのかも判断できない

ここで騒いだところで何も解決はしない
文句あるやつはAMDに直接問い合わせた方がいい
問い合わせ件数が多くなれば早々に何らかのアクションを起こすだろ

**Socket774** · 2017/06/22(木) 08:34:59.70

PhenomやSkylakeはエラッタ解決のために性能落とされたからな
どうなることやら

**Socket774** · 2017/06/22(木) 09:00:28.60

OCやらメモリの相性やらBIOSだとかLinuxメンテナフォーラムでさんざん議論われて今更感
あまり関係ない雰囲気がボランティアの対策チームの認識になりつつある

幸いなことに対応している人たちはAMDのフロント対応が杜撰な事に不平はいっているが
FUD/プロパガンダ等の押し並べて煽って騒ぎたててる訳ではないし

エラッタの振る舞いが判った今、あとは発生条件を調べて
あとはAMDにハードウェア的に対策してもらうだけだろ
PhenomのTLBみたいな事にならなきゃいいが

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

http://twitter.com/satoru_takeuchi/status/877346684853866496
この理論が正しければWindowsでも
RAMディスク使ってスワップ起こるまで使えばエラーになるんじゃね

**Socket774** · 2017/06/22(木) 09:17:30.50

Phenomみたいに性能落とされなければ
PhenomのTLBみたいに

これ自体がFUDにしか見えない

**Socket774** · 2017/06/22(木) 09:43:46.94

対策が入っても性能が維持できるかどうか、というのは皆が気になる所

**Socket774** · 2017/06/22(木) 09:54:23.74

そんなの対策されるまで分からんだろう
初物買ったんだから最悪の事態は覚悟の上だろ
待てないならAMDに問い合わせろ

32 · 2017/06/22(木) 12:01:22.32

>>42
64ずれるってのがわからない

プログラムカウンタズレてそれだけってことあるのかな
それともスタックフレームを意味してる？

**Socket774** · 2017/06/22(木) 12:06:59.91

Linuxだと出やすい条件の命令なのかもしれない
カーネルパニックしろブルースクリーンにしろ、何かしらシスログなりイベントログは残る

**Socket774** · 2017/06/22(木) 12:40:38.25

>>58
X.M.Pプロファイルでメモリ設定しているビジネスユースなんて一体何処の世界に存在してるんだよ
そんなのAMDの責任範疇の外だろう全く呆れるわ
メモリがSPD設定しか読まないガッチガチのビジネスモデルで検証したのなら理解出来るが…

**Socket774** · 2017/06/22(木) 13:23:02.39

>>70
プログラムカウンタがずれたんじゃなくて、データがずれたんでしょ

**Socket774** · 2017/06/22(木) 13:24:32.70

コピペ　

ただし、一点希望が持てることが明らかになりました。
CPUコアを1つにして、かつマルチスレッド無効化しても問題は発生することがわかりました。
これによって、別コア(スレッド)との相互作用が無くても単一CPUだけでも問題は
発生しうると言えます。これまでは、あるCPUにおいてSEGVが発生した際に、それ以外の
CPUの挙動が謎だったために、再現プログラムの作成難易度が相当高いと思っていました。
ただ、SEGV発生時のCPUの挙動だけを真似れば理屈上再現プログラムが作れることがわかったので、作成の敷居は下がりました。

**Socket774** · 2017/06/22(木) 13:31:07.29

希望か

**Socket774** · 2017/06/22(木) 13:54:55.42

コピペ２

起きるパターンは負荷テストを止めてほんの 2, 3 分程度の頃が多い。
何時間も負荷テストをする必要もない。
電源管理まわりの設定を変えると改善するとの噂があるが、設定の仕方がまだわかってない。

rcu_sched detected stalls on CPUs/tasks はたぶんスケジューラー的にコイツ動いてないよ
というたぐいのメッセージ。これを放置して触っていると、TLB shootdown か何かの処理が
終わらなくなるようで (CPU0 が応答しないのだとすれば当然)、他の CPU も巻き添えを
食って止まり始めるが、他の CPU では NMI watchdog が出る。CPU0 も /proc/interrupts
を見る限りは NMI が出続けているのだが、なぜか watchdog は出てこないんだよな。

さて、idle が怪しいと見ていろいろ試したが、idle=poll も効果無し。（SEGV出ず）

Linux を BitVisor 上で動かし続けて 24 時間超えた。マジで
rcu_sched detected stalls on CPUs/tasks のほうは ”BitVisor ”上では再現しないたぐいの問題なのか?
Ubuntu 16.04 でやって報告しまくっている第一人者の話があるので、
試しに debootstrap で chroot の” Ubuntu 16.04 ”環境をこしらえた。
schroot というのが便利だというので使ってみている。それでいざカーネルビルドさせてみたらほんの 5 回ほどで segfault 出てしまったよ!

**Socket774** · 2017/06/22(木) 13:57:27.46

コピペ３

BitVisor から覗いて見てわかったのは、ミスって #VMEXIT の状況を
うまく確認できるようにしていなかったことだw Local APIC の書き込みアクセスで
#VMEXIT したところだけ見えていて、果たして NMI が出ているのかはっきりしなかった。（ω）しょぼーん。

これはさすがにやっぱり CPU 内部関係かなという感じがとてもする。
キャッシュがどうのこうのという感じではない。
レジスターの内容はこうして追ってみると一理ある感じなので、命令の実行が何かおかしいの？である。

（↓おそらく64bit先のに飛ぶことのかと）
LastExceptionToIP がなぜかユーザー空間のアドレスになっていることが多々ある。
例外の遷移先だから、カーネル空間でないとおかしい。VMM が絡んで変なことになるにしても、
それなら VMM の使っているアドレス空間でなければおかしいだろう。LastExceptionFromIP も
ユーザー空間にあるのは別にそれでもいいとも言えるのだが、そこに明らかに LastExceptionToIP にジャンプする命令が入っているというのはこれまたおかしな話である。

内容に矛盾はなく、本当に、ページフォールトだけがおかしいのである。
まるで 0x40 ズレた、手前の位置の命令を実行しようとしていたかのように。ハードだとしてもそうなる原因わかんね。。

**Socket774** · 2017/06/22(木) 14:01:07.50

この問題は放置だな

Ubuntu 16.04で問題出たと言っても
ryzen対応のUbuntu 17.04が出てる訳で
問題があるならそこで問題になっている

**Socket774** · 2017/06/22(木) 14:15:21.65

intel使えば問題ない

**Socket774** · 2017/06/22(木) 14:33:36.34

起こってるやつはメモリと各電圧の値含めて全環境を提示してみてくれ
そういう情報が一切無いからどうにもだ

ちなみに、定格とかじゃ無くて具体的な数字を上げてくれ

**Socket774** · 2017/06/22(木) 14:47:37.81

この話、4月から言ってるのにいまだに反応には似たようなもんだな

**Socket774** · 2017/06/22(木) 14:56:54.53

重大な問題ならば、各MB、PCメーカーが黙っているはずもなく、販売中止もしくは延期を発表するはず。
だから重大ではないとは言えないが、そんな動きがまったく無いのが不思議だよ。

EPYCもmicronあたりが盛大にラインナップ発表したらしいし？
EPYCで解決してるなら、その故と販売済みRyzenへの対策が発表されるだろし。

誰か、この問題がユーザーサイドではなくメーカーサイドで取り扱われたソース知ってる？
予定していた購入は、そこらへんの情報が揃うまで待つよ。

**Socket774** · 2017/06/22(木) 15:30:20.65

>>72
SEGVエラーはメモリ関係ないCPUのエラッタなんだが

**Socket774** · 2017/06/22(木) 15:50:18.65

>>83
断定されてないんだが
あくまでだろう止まりなんだが

それにメモリーというよりメモコンの話でしょ

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

必ず発症する状況、環境というのが存在しないのと
発症した人が大半「どういうハードウェア的な検証したのか」を公開しないから問題の切り分けがいつまでもできない
自作PC板的にチェックするようなところが殆どスルーされて非公開だからCPUの問題だと確定できないんだよな

http://damelog.com/

例えばこの人とか、M/B交換とメモリ交換を行ったことはわかるけど、
BIOSバージョン不明、メモリ設定詳細不明、電源型番及び使用期間不明、使用CPUクーラー不明、
関係なさそうだとしても使用GPU不明、使用USBポート不明、ARC-1214-4i使用スロット不明

言い出した人の環境に関してはCPU以外一切不明だし進歩ないのは仕方ないと思う

32 · 2017/06/22(木) 16:46:47.40

>>73
だからスタックフレーム言うとるのよ

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

>>84
メモコンはCPUの機能だろうが。オンダイだぞ。

**Socket774** · 2017/06/22(木) 17:23:14.80

>>87
メモコンとメモリー間の相性悪いからって意味ね
当然メモリーが規格に適したものであるならryzen側が修正しないといけないが

**Socket774** · 2017/06/22(木) 17:41:27.92

朝はグダグダだったのに今見たらスレタイに即した内容になってて草

検証できる有志は検証環境のハード・ソフト構成と結果を挙げて行ったらいいのでは？
集計すれば何か傾向など分かるかもしれない
(例えばこのマザーだと出ないとか、等)

CPU・マザー・メモリはできれば製造週と製造国も
CPU・メモリは定格かOCか
AGESAによる変化はあるか、もあればなお良し(Ver.Up毎にメモコンいじってるし)
テンプレも作った方がいい

あと検証したいが何をしたら良いかわからない有志候補のために、検証の仕方の手順を作ってくれる有志もいるといいと思う
(そういうサイトがあればその案内でも可)

俺は残念ながら有志候補レベルだが、テンプレ草案位は作れると思う

**Socket774** · 2017/06/22(木) 17:44:30.71

ttp://news.mynavi.jp/articles/2015/09/29/ddr4/
腐ってたのはCPU側Skylakeのメモコンが原因でメモリの品質には全く問題は無かった訳だが、何故かモジュール側で対応させてるよね

**Socket774** · 2017/06/22(木) 17:51:57.38

Intelお得意の、他に経費をなすりつけるためだろ
これならすでに製造した欠陥メモコン入ダイを全て捨てる必要がなくなる

**Socket774** · 2017/06/22(木) 18:17:24.89

AMDもやれば良いべ？

**Socket774** · 2017/06/22(木) 18:27:46.36

AMDとかGentooとか各フォーラムに事例が連日報告されてる
再現方法が完全に分かってるわけじゃなくて、全ての個体に起きてるわけじゃないようだけど

**Socket774** · 2017/06/22(木) 18:40:48.66

>>92
AMDはメモリモジュールメーカーに圧力かける必要ないからな
そもそもなんでお前このスレにいんの？
ネガキャンのネタ探しか？

**Socket774** · 2017/06/22(木) 18:51:22.82

連投すまんが
>>93
その各フォーラムのリンク貼ってもらえないか？

**Socket774** · 2017/06/22(木) 18:56:13.09

>>95
https://community.amd.com/message/2800014
https://forums.gentoo.org/viewtopic-t-1061546.html

**Socket774** · 2017/06/22(木) 18:56:49.89

>>89
そんなの本来AMDがやることだろ
なんで購入者がそこまでやらないといけないんだよ

不具合報告を上げたら、AMDが詳細条件とか調査してバグ修正すればいい

**Socket774** · 2017/06/22(木) 19:05:31.86

Ryzen Segv Battleとかやってる人たちはハッカーとして面白いからやってるんであって消費者としての立場でやってるわけじゃないと思うな

**Socket774** · 2017/06/22(木) 19:07:57.15

放っとけばいい

メモリ交換して問題が起きなくなった人がいるんだし
同じ現象起きたくない人はその人と同じメモリ付けときゃいい訳だ

そうやっていろいろ議論するのがLinuxユーザーの楽しみ方の一つで
昔もLinuxでは使えないとかあって
ペンギンシールが貼ってあるものはLinux動作確認済みですとかやってたんだけどな

**Socket774** · 2017/06/22(木) 19:08:35.25

>>97
今回のエラッタは全環境で発生してないからな
AMDへの情報提供量が少ないだけ発見修正の時間がかかる

**Socket774** · 2017/06/22(木) 19:14:47.01

Linuxユーザーが絶対エラッタ起きるコードを楽しく作ってるからAMDに提供するまで待ちだろうね

**Socket774** · 2017/06/22(木) 19:18:43.25

linuxユーザーなんてこの手のトラブル慣れてるだろ
騒いでるのは関係の無い外野ばかりだな

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

>>96
ありがとう、後で見てみる

>>97
そう思うなら賛同・参加しなければいい
AMDのアクションが鈍い(公式な情報公開が全くない)事もあって、不安に思うユーザーは日々少しずつ増えている
ならユーザーレベル範囲で不安の軽減策として何かやれないかと思って一手段として書いてみたまで
(賛同は得られないだろう事は承知の上)

AMDに不具合報告を上げるのも手段としては有効だろう
現状おそらく報告件数が少なすぎるのがアクションが鈍い要因と思われる
件数が増えれば増える程AMDに重大かつ緊急の問題と認識させられるだろうから

**Socket774** · 2017/06/22(木) 19:28:44.12

なんでマスコミの記事もPCメーカーの見解も出てこない？
ユーザーの見解しか見つけられないので、誰かください。

**Socket774** · 2017/06/22(木) 19:30:41.79

一度CoreInfoの誤表示信じてヤラカシだから慎重なんでしょ
AMDが公式でなんか言うまで動かないよ

**Socket774** · 2017/06/22(木) 19:30:43.72

連投すまんが
>>102
LinuxとBSDでは起きていると聞くが、Windowsで起きているという話は聞かない(少なくとも俺は聞いた事がない)

だから関係のない外野であるWindowsメインのユーザーとしては
何故Windowsでは起きてない？
本当は起きているのに気がついてないだけ？
という疑問が、だんだん不安に変わってきていて騒いでると思う

**Socket774** · 2017/06/22(木) 19:39:53.33

>>99
あのシールそういう意味もあったのかｗ
ドライバが用意されてるとかその程度かと思ってた

**Socket774** · 2017/06/22(木) 19:44:09.89

>>105

業界全体が歩調揃えてるって？それはないでしょ。
ましてや、PCメーカーは販売している以上、クレームを受け付ける立場だよ？
問題発覚から２ヶ月もたってるってことだし、EPYCは持ち上げてる記事しか目につかない。

重要事項なら、販売延期するだろし、これまでもしてきてたと思うけども。

**Socket774** · 2017/06/22(木) 19:59:06.18

分岐予測切ったりL2TLBの動作を調節したりメモリーインターリーブをブロックサイズごと変更して動作確認可能なBIOSTARのマザーボードで誰か試しておいてくれ

**Socket774** · 2017/06/22(木) 19:59:53.37

報告テンプレこんな感じか？

【CPU】電圧設定、クロック設定 (特に設定していないなら"デフォルト")
【CPUクーラー】型番、設定あるなら、(CPU付属品の場合は"リテール")
【メモリ】型番、使用中のクロック・電圧・タイミング設定も
【M/B】型番とBIOSバージョン("最新"はNG)
【VRM冷却】 CPUクーラーが水冷やサイドフローの場合には必要
【グラフィック】総使用電力の参考にするため
【ストレージ】使用IFの種類、できれば取付コネクタの位置も
【HBA】使用している場合のみ(使用スロットも)
【使用USBデバイス】できれば使用コネクタの位置も(CPU内蔵のUSBコントローラも存在している為)
【ケース】ケースファン等の冷却機器の有無も
【電源】 W数だけでなくメーカー型番、使用年数が重要
【アース端子接続】電源のアースをコンセントのアース端子に接続しているか否か
【動作テスト】memtest一晩放置、Prime95　1時間パス、OCCT Linpack 1時間パス等が基準

CPU以外に何らかの問題を抱えていたなら動作テストでエラーが出てくるはずだから、
ビルド以外の動作テストでエラーが出ていないことを確認してほしいところ

memtest4周程度ではメモリエラー見落とすことはある(一晩放置で朝方にエラー発生ということもある)

**Socket774** · 2017/06/22(木) 20:00:41.76

まともなPCメーカーが「安OCメモリをX.M.Pで回してコケました」なんてレポする訳がないだろう
EPYCでは発生しないようだし、Ryzenでもクソ高い純正メモリだと安定動作するんだろうな
寧ろPCメーカーにとってみれば「自作BTOだと不安定だからうちの製品買って下さいよ」と絶好の売り文句になる

**Socket774** · 2017/06/22(木) 20:14:53.42

>>110
現象はIPがキャッシュライン一枚ぶん飛ぶようだから

CPU
メモリ
MB-BIOSVer-uCodeバージョン
電源
冷却
温度(無ければ無くても可)
Vcore
VSoC
VPLL
マルチプライヤ-Turbo-XFR
クロックダウン関連
あとメモリのわかる限りのパラメータ(定格表記不可)

こんくらいかな

**Socket774** · 2017/06/22(木) 20:16:47.52

いままでの重大バグの対応

○Pentium FDIVバグ
　　石交換
○Pentium F00Fバグ
　　OSで対策することで対処可能
○Phenom TLBバグ
　　BIOSアップデートでTLBキャッシュ無効化で修正、ただしパフォーマンス低下
○Sandy intel 6チップセット SATAバグ
　　マザーボード交換
○Haswell TSXバグ
　　修正不可能、BIOSアップデートでTSXまるごと無効化される
○Atom C2000シリーズ
　　どんどん壊れる重大バグ発覚、ただし一般ユーザー向けに直接販売はしてないために対応は不明
○Skylakeフリーズ
　　BIOSアップデートで修正
○Ryzen SEGV
　　いまのところAMDからアナウンスなし

**Socket774** · 2017/06/22(木) 20:17:41.41

>>93
この再現性のなさがこの問題の一番厄介なところ
おそらくハードの問題かと予想されるが、どのように処すべきかわからない

またメインであるwindowsで類似の不具合か聞かれないから、対策も下手げに打てない

現実はダーク

**Socket774** · 2017/06/22(木) 20:23:37.01

Atom C2000のバグはC0ステッピングで対策済み

だけどブラジルの企業に訴えられたりしたぐらいには広い範囲に及んでるみたい

**Socket774** · 2017/06/22(木) 20:33:16.05

>>110
おお、素晴らしい
あとはソフト関係
[OS] Linux FreeBSD等
[ディストリ] Gentoo バージョン等
[カーネルVer] uname の値
[gccVer]バージョン見るオプションの表示内容
[gccコマンドライン]
[ビルドに使用したカーネルソースVer]
みたいな感じ
(すまんが詳しい方補って)
(あと全角のかっこ使ったら書き込めなくて[]使ってる)

memtestはメモリOCの場合8-10周目辺りでエラー出る事があるので個人的には10周推奨

>>112 の内容も合体させればいいかな
Windowsも使える環境ならHWiNFO等のスクショでもいいかも

**Socket774** · 2017/06/22(木) 20:40:05.78

>>109
ASRockのX370taichiもP2.40(L2.34、L2.36も？)はそれ関係の設定できる模様

**Socket774** · 2017/06/22(木) 20:45:54.04

放っておけばいいのに

LinuxのOSシェアのうち
UbuntuとDebianという70％のシェアを占めるディストリビューションは
普通に配布されてるISOなりCDなりから普通にインストールして使えるんだから
全体の0.5%にも満たない人達の中で更に外れを引いた人達が頑張ってる訳で

VISTA人口より遥かに少ないだろ

**Socket774** · 2017/06/22(木) 20:56:53.61

>>118
それはUbuntuとDebianで他の環境でビルド済みのカーネルを使っている限りはsegvは発生しないという意味？

**Socket774** · 2017/06/22(木) 21:05:16.73

>>111

ちょいまち、それ発生原因の確定内容？初耳なんだが

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

何か勘違いしてる奴がいるようだが
この件がUbuntu17.04で改善されてるなどという話は全く無いぞ

**Socket774** · 2017/06/22(木) 21:16:27.96

Linuxのディストリビューションって、基本的にパッケージ構成とGUIのインターフェイスの違いくらいしかない
カーネルとかGCCとかのコアパッケージは同じだし

**Socket774** · 2017/06/22(木) 21:18:45.50

>>119
カーネルコンパイルをする必要がないだろ
それに負荷がかかった時以外は発生しないケースが多いんで
ubuntuやDebianユーザー的にもそんなんあるだー程度じゃないか

**Socket774** · 2017/06/22(木) 21:19:35.90

淫注キチガイが騒いでるだけって
誰かが言ってたよ、無視しよう

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

ダメだこりゃ

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

そもそも俺の環境で発生しないんで
検証しようがないんだけど

**Socket774** · 2017/06/22(木) 21:27:15.83

会社の会議でも
使えない奴に限って重箱の隅のどうでもいい問題に
必要以上にこだわって会議を紛糾させる
ゴミクズみたいな奴はどこにでもいるんだな
さらっと流しとけよ

**Socket774** · 2017/06/22(木) 21:41:50.70

>>126
むしろ発生しない環境の情報はあまり出てこなくて貴重なので知りたいわ

**Socket774** · 2017/06/22(木) 21:44:21.53

発生しないやつはそもそも書き込まない

**Socket774** · 2017/06/22(木) 22:05:01.94

>>129
これ
>>128は頭悪そう

**Socket774** · 2017/06/22(木) 22:06:53.48

>>123
当たり前の事とは思ったが念のため聞いた
7年位前まで4年程CentOS4と5は使っていたがそれ以降触ってないから大きく変わっていたりしたら知る術がないので

>>127
俺の事言ってるんだろうけど別に使えないゴミクズ扱いで構わんから
お前こそさらっと流して一々書き込まなければ？

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

>>117
ゲームベンチ結果もいろいろ変わるから暇なら試してみてね

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

Ubuntu17.04でもSEGV出るし、kernel4.12rc6でもでる。
ちなみにメモリはFLARE Xな。
カーネルオプションにiommu = softつけたりすると若干頻度が下がってる感あるけど
当てにならん。

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

スレチですまんが
>>132
特に日本の会社の少し古いゲームに効果あるらしいね
あとBIOSTARのマザーも持ってるよ

**Socket774** · 2017/06/22(木) 22:40:30.38

連投すまん
>>133
念のための質問だけど、その環境でsegv出るのはカーネルビルド(16並列オプション有)の時だけなんだよね？

iommu = soft はハードのiommu使わないオプションかな
アンコアの負荷(消費電力)が下がると頻度が減ったりするんだろうか？
UEFIセットアップでIOMMUを無効にした場合の差も気になる所

**Socket774** · 2017/06/22(木) 22:45:23.24

ネチネチ粗探しするなよ
なんでも批判したがるクズだな
嫌われるぞ

**Socket774** · 2017/06/22(木) 22:48:58.13

>>136
お前に用は無い

**Socket774** · 2017/06/22(木) 23:08:38.40

LiinuxでしかエラーでないからWindowsでは関係ないとかいってるやつは
根本的にサーバを理解してないな

AMDもしくはMSが、Windowsではこのバグは影響ないって公式にアナウンスしない限り、
Windowsでもこのバグの影響を受けると想定するのは当然

**Socket774** · 2017/06/22(木) 23:31:26.19

>>138
Windowsだと思ふ
https://twitter.com/homuh0mu/status/877795361108090882

**Socket774** · 2017/06/22(木) 23:38:41.97

Gigabyte マザーで出るVector 07は同じ原因なんかな

**Socket774** · 2017/06/22(木) 23:46:52.11

コンパイラはファイル読み書きと計算をするごく普通のプログラムに過ぎないので
問題発生のトリガが特定できない現状あらゆるプログラムでデータ破壊の可能性があるとしか言いようがない

**Socket774** · 2017/06/22(木) 23:53:22.59

心配なら対策されるまで待つかインテル使え

**Socket774** · 2017/06/22(木) 23:55:37.81

>>139
この場合VS2017のバグなのかRyzen segvなのか切り分けできてないように読める

**Socket774** · 2017/06/23(金) 00:00:05.66

KaliLinux 64bit
http://egg.2ch.net/test/read.cgi/jisaku/1498034171/153
153 名前：Socket774 (ｵｯﾍﾟｹ Sr0b-1uIF)：2017/06/22(木) 23:56:34.57 ID:OeveasXtr
>>80
よし以下スペック

CPU Ryzen 1700X
GPU 玄人志向　GF-GTX1080-E8GB/OC/DF　2枚HBSLI
SSD Crucial CT275MX300SSD1
HDD WD WD30EZRZ-00Z5HB0 2台
マザボ　Asrock X370Taich uefiバージョンはP2.20
メモリ　crucial CT8G4DF8213 を4枚計32GB

**Socket774** · 2017/06/23(金) 00:07:18.53

なんか、ちょくちょくスレタイ読めない人が出没する

**Socket774** · 2017/06/23(金) 00:09:50.84

バグフリーズは全部SEGVになりそうだなこりゃ

**Socket774** · 2017/06/23(金) 00:20:08.49

>>144 に書いてある153の人は、他のスレでKaliLinux 64bitで起動時にsegv出ると言っていた人
環境詳しく晒せと言われていた所までは読んでた

**135** · 2017/06/23(金) 00:22:46.42

連投すまん
再度幾つかのページ見てきたけど、やはり自分で環境作って実際にsegv出してみないと現象に対する理解が深まらない事が分かった
またハード的に幾つか試したい事も思いついたので出直してくる

あと変なのに絡まれてるからこれ以上スレに迷惑かけるのも嫌だし

ちなみに石交換になった人のページ見てたら、石交換は単に故障かどうかを切り分けるためで、同じ機種の別の個体と交換という事らしい
(B2ステップとの交換ではない模様)

**Socket774** · 2017/06/23(金) 00:25:12.14

amdでも苦労してそうだなあ

**Socket774** · 2017/06/23(金) 00:46:38.37

>>144
これ投稿したやつだけどryzen購入時期は発売直後

分岐予測とかSMT切っても発生した
あとメモリのプロファイルはDDR-2134, cas-latencyが16.0, ras-toCASが15, ras-prechargeが15, tRASが36,tRCが50という値になっていた
cpu-zから確認した

**Socket774** · 2017/06/23(金) 00:47:46.40

あと同じusb使ってpentiumG3258の機体で起動したところ、普通にいけた

**Socket774** · 2017/06/23(金) 00:50:51.21

>>151
G3258もSLIなん？

**Socket774** · 2017/06/23(金) 00:51:30.71

USBにOS突っ込んで起動しようとしたらフリーズと
SEGVと判断した理由とかはあるん？特定の場所でフリーズとか

**Socket774** · 2017/06/23(金) 00:52:05.41

＞kalilinuxブートするusb挿す位置も全部のポートで試したけどだめだった

何気にこういう情報重要だからありがたいよ

**Socket774** · 2017/06/23(金) 00:53:12.55

>>152
いやGTX750Ti
>>153
起動時にlinux特有のログみたいなのが流れるんだけどそこで延々SEGV～ってのが流れ続けるループしてるっぽい

**Socket774** · 2017/06/23(金) 00:55:11.42

>>155
再現率100%の事例なら初じゃね
今まではどの環境でも再現率100%じゃないから困ってたわけだし
明日試してみよ

**Socket774** · 2017/06/23(金) 00:55:26.93

DRの４枚刺しは公式では１８６６までしかサポートしてないんですが・・・
２１６６で動かしてない？

**Socket774** · 2017/06/23(金) 00:56:42.47

>>157
(アカン)
それかもしれない明日BIOSアプデと一緒にやってみる
>>156
おけ

**Socket774** · 2017/06/23(金) 01:02:16.29

２枚刺しで試してみたらどうかな？２枚刺しDRなら２１３３までサポートだし
(上２１６６を２１３３に訂正)
BIOSアップしても公式サポートは１８６６までだしね

**Socket774** · 2017/06/23(金) 01:33:48.12

kali linux の最新版は2017年1月リリースだがそもそもRyzenに対応してるのか？

**Socket774** · 2017/06/23(金) 01:46:45.41

Ryzenでビルドしたのじゃないなら別の問題じゃないかと

**Socket774** · 2017/06/23(金) 01:48:05.09

ググったら出てくるが平気で動くらしい
変なエラーもなしで

**Socket774** · 2017/06/23(金) 01:49:53.32

Ryzenの場合、windows10でもcreators updateじゃないと不具合あるケースあるもんな
うちで1700普通ににつかってるけど、実害がないにしてもエラッタがあるってのは
なんか気分が悪いわ。

とりあえずこのスレを転載して煽り記事書いてアクセス数を稼ぐジサクテックは死ね

**Socket774** · 2017/06/23(金) 01:50:35.97

エラッタの発信主さんはメモリクロックいくつで動かしてたんだろうね
2400のSR4枚みたいだけど

**Socket774** · 2017/06/23(金) 01:52:04.97

ブートでコケるやつはryzenを認識できない事による対応命令の誤認識ってやつでしょ
ブログに情報が出てたよ

SEGVはuopcache切っても発生して、
ipは正しいんだからL1i-cacheに病気持ってるってことに見える

**Socket774** · 2017/06/23(金) 02:17:29.18

>>162
>>165
リンク貼ってくれんか
探し方悪いのか見つからない

**Socket774** · 2017/06/23(金) 02:28:55.73

>>29
>>166

**Socket774** · 2017/06/23(金) 02:54:21.49

>>167
そっちの事言ってたのか
それは仮想マシンで起動する場合の話ね

論より証拠で今DL中
WeelkyBuildもあったからこっちも試してみる

**Socket774** · 2017/06/23(金) 03:48:51.03

>>162 の言う通り問題なく起動した
Kali linux 64bit 2017.1 ISOをUSBメモリにWinDDで書き込んだものを使用

http://i.imgur.com/ZLmqjdR.jpg

Ryzen 5 1500X(定格)
ASRock X370 Taichi (BIOS 2.40)
AData AD4U2400W4G17-S(2400 4GB)x2
MSI RADEON HD5450 1GB DDR3

2017.1で起動したのでWeeklyBuildは試さず

**Socket774** · 2017/06/23(金) 04:01:12.58

連投失礼
>>158
>>169の通り問題なく動いてしまった

フォーラムにグラボ絡みで起動しないような情報がある
1080Tiを使っていて起動しないらしい

https://forums.kali.org/showthread.php?35773-Kali-Linux-works-on-AMD-Ryzen

グラボ変えるかWeeklyBuildで試してみて

**Socket774** · 2017/06/23(金) 06:06:14.05

ubuntuでもXMP読むとbios立ち上がるのにブートでコケるからメモリは弱いな

**Socket774** · 2017/06/23(金) 07:41:06.78

ねちねち粗探し、そんな人生楽しいか？
前向きに生きろよ

と言うと馬鹿なお前らは
改善しようと前向きにやってるんだと
アホなことで自慰する糞

**Socket774** · 2017/06/23(金) 07:41:50.32

>>170
おけ

**Socket774** · 2017/06/23(金) 08:05:33.13

この問題て仮想マシンでもおきるんかな？
試したいんだが、ryzen機はesxiいれてしまったので、仮想マシンでしか試せない

**Socket774** · 2017/06/23(金) 08:41:21.97

>>172
お前こそこんな所でねちねち粗探ししてないでとっととどっか行って前向きに生きたら？

それとも他に行く所もなくこんな所でねちねち粗探ししかできない馬鹿なのか？

**Socket774** · 2017/06/23(金) 09:24:03.89

>>173
あとメモリは定格でやってみてほしい
まあ最初は２枚刺し２１３３が安定だと思う

**Socket774** · 2017/06/23(金) 09:34:59.59

22日のブログで64バイトズレ以外にも違ったエラーもあるって書いてあるな

**Socket774** · 2017/06/23(金) 10:28:59.93

ちなみにAMDサポートコミュニティSEGVスレッドのメインキャラの一人は
某フォーラムで「環境を全部網羅してないと話にならない」とかネチネチ難癖つけられて
脱出してきた人です。難癖つけた人は私の書き込み記録を消した人でもあります。
まあなんつうか、アレな人が一部いると大変ですねと
https://twitter.com/satoru_takeuchi/status/877828616846888961

このスレにも環境ガーとか必死でねちねち文句つけてる奴が１匹いるよね

**Socket774** · 2017/06/23(金) 11:02:01.23

127
136
172
178

ネチネチ(ねちねち)
粗探し
重箱の隅
環境を聞かれる事に対する不満・文句

共通項が多いのは気のせいか？

http://i.imgur.com/na66loK.png
http://i.imgur.com/4RF6SPP.png

**Socket774** · 2017/06/23(金) 11:04:59.89

ここまで執拗だと仕事でネガキャンやってるのかと疑うわ

**Socket774** · 2017/06/23(金) 11:39:01.31

仕事やろなぁ
別に環境設定晒して何の損にもならんだろ？そこに問題が無い証明にもなるのに
必死に隠そうとしてるのは何か裏を疑ってしまうわ

**Socket774** · 2017/06/23(金) 11:53:36.32

エラーの再現性を検証する為なら細かい環境まで晒すのは普通だと感じる
そうしないとあんまり意味が無いから
それを嫌がる奴はエラー検証なんて面倒な事を普通はしないだろ

**Socket774** · 2017/06/23(金) 11:57:54.13

最初からけんか腰なら何を言っても無駄だなって思うことはあるよね

**Socket774** · 2017/06/23(金) 12:10:39.68

intelの情報操作が凄すぎる
どんだけ金ばらまいとんのか
7700Kの温度スパイク問題とか
日本はどこも記事にしてない
ジサクテックも取り上げない

AMD側は不具合は目立つよなー

**Socket774** · 2017/06/23(金) 12:15:15.29

けど基本的な構成データは欲しいとは思う
>>144みたいなメモリのサポート外ということもあるし

**Socket774** · 2017/06/23(金) 12:29:31.57

>>179
堂々と漫画割ったコメントしてたな

**Socket774** · 2017/06/23(金) 12:41:20.87

>>183
いや思わんねぇ
喧嘩腰でやってくる奴なんか環境晒して問題無い事証明して黙らせればいいじゃない
なんでしないのかがわからん

**Socket774** · 2017/06/23(金) 12:44:56.83

>>187
アホ相手に情報与えたくないって感じじゃね？ｗ

**Socket774** · 2017/06/23(金) 12:46:48.15

>>188
一人で大量の機材用意して検証できるならまだしも情報共有しないと検証が進まないだろ

**Socket774** · 2017/06/23(金) 12:48:29.69

自分の検証環境に問題が無い事を証明出来ない無能なんだから仕方ないよね

**Socket774** · 2017/06/23(金) 12:53:18.98

問題の人はまずWindowsインストールしてOCCTとかで確認したほうがいいんじゃないか。

**Socket774** · 2017/06/23(金) 12:53:26.87

本人の検証環境に問題があるとは思わないけど
他者の検証環境に問題あるかどうか確認せずに報告だけ取り上げるのは片手落ちだからな

取り上げた他者のエラー報告の中に別要因によるエラーが混じってたら特定できない要因になる
それが目的なら目論見通りなんだろうけども

**Socket774** · 2017/06/23(金) 12:54:29.49

そもそもgcc以外でのコンパイルは問題起きたの？
数ヶ月前の海外記事はgccだけだって話から何にも進展してないよねこれ

**Socket774** · 2017/06/23(金) 13:05:25.25

>>188
それは検証をする人間としてはアホ以下の反応なんだよなぁ・・・

**Socket774** · 2017/06/23(金) 13:19:24.84

>>194
わかるわー
こういうトラブルが発生したんですがどうしたらいいですか→情報が拾えて無くて全くわからない→一々出向く羽目に
俺の仕事でよくあるパターン
情報がなきゃ全くわからんからな、情報が多すぎるぶんは取捨選択すりゃ良いだけだが少ないのはどうしようもない

**Socket774** · 2017/06/23(金) 13:26:19.27

>情報が拾えて無くて全くわからない
聞いたらいいじゃん？ここどうなってますかとか

**Socket774** · 2017/06/23(金) 13:59:14.32

>>196
聞くよ、まぁ初期情報が足らなさ過ぎるケースが殆どだけど
そうするとちょっと調べて来ますつって時間掛けて何か調べて来た挙句よくわかりませんと返ってくる

最初の情報の時点でその対応者のスキルというか中身わかってんのよ、わかってるなら情報不足と言っても聞けば済む範囲に収まる
専門外の事を人間は答えられないし出来ない、これは当たり前の事で仕方ない

だけどこういうケースはそうはいかない
ネット経由という特性上こういうトラブルシュートで情報不足ってのはやり手が答えない時点で止まる
専門分野の違う大多数による観点から確度を高めるという特徴を、一辺倒の分野知識だけで済ませようとするからそうなる
要はさ、自分の中の結論通りに行って欲しいだけで解決する気無いんだよ
尤もこの正常化バイアスはわかってないと防げないしそこを責めるつもりはない
まだ条件も確定してないしよくわからんからな

**Socket774** · 2017/06/23(金) 15:02:07.81

プログラマーとしての興味で粗さがしが楽しいのはわかるが
株価だの持ち出した時点で、やっぱ最初からそういう目的だったのね、って感じ

**Socket774** · 2017/06/23(金) 15:09:17.75

元の人はブログでパーツ構成だけ書いてたような
違う人だったかな？キングストンのハイパーなんちゃらってメモリだったな

**Socket774** · 2017/06/23(金) 15:17:58.83

>>198
じゃなきゃこんなスレ立てないでしょ