【エラッタ】Ryzen SEGV問題 情報交換【フリーズ】 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
これってWindows上でgccでsegv出る条件でコンパイルしても出るの? それは初耳
スクショとかある?
自分でやってないなら出た人のtwitterのツイートとかでもいいけど AMDから直接送られて来るのかこのツイートでは分からんから現状なんとも言えんな
続報を待つとしよう >>7
AMDから個別対応扱いになってたのか
ならその前提で続報待ちだな >>8
これはビルドしたカーネルが仮想マシン上で動かない件の詳細な調査事例
残念ながらエラッタがある模様
マイクロコードで直せるレベルなのか? >>10
仮想鯖もするとこあるはず
んで、発表会のデモ↓
https://twitter.com/Hyper_beta/status/877408252937424896
> EPYCのデモでAMDがLinuxをビルドして見せたのは、メッセージなのかもしれない?
> #Ryzen_SEGV_Battle
直ったのかな? スラドでトピが立った>>8
<title>Ryzen SEGV Battle、原因の一端が解明される | スラド Submission</title>
https://srad.jp/submission/71785/ EPYCはB2ステップなんでしょ
マイクロコードで直るのかはB1ステップを使ってる者として心配という意味 スラドのトピックの書き方だと>>8の現象が仮想マシンでのカーネル起動失敗とgcc segvの両方に関係するように読める
B2ステップでは直してるだろうけど、B1ステップをどうするかがまだ決まってなくてAMDとしては現時点では話を大きくしたくないのだろうなと感じる
続報待ちだな まあIntelもTSXとかマイクロコードで修正むりなのやらかしてるしな 最悪コーディングレベルの回避方法が出るだけでもいいとは思う
リコールは今のAMDとしては避けたいだろう
下手すりゃ倒産するか買収される
折角インテルのケツをけっとばせたのにまたサボりボッタクリに戻ってしまう あっちのスレでEPYCがB1だってホント?
マザボで合わせてるのかな?
RyzenもBIOSとかのうpだてで対応できる? >>15
むしろcall命令で呼び出し先が-64バイトずれたら、もっと多様な問題が起きると思うが
発現頻度がかなり低いか、特定の条件があるのか
AMDが問題をどれだけ早く認識していたかによってはB2 steppingでも直ってないかもしれない。 これLinuxだけの問題じゃないよね
Windowsでも起きうるよね? スパッと例外で死んでくれたからまだマシだけど
64バイトずれたら何が起こってもおかしくないよね
データが漏洩するとか、間違った額を送金しちゃうとか、爆音がなるとか、データ消失とか、....
地雷を抱えたCPU 命令デコーダの異常か…
デコード後のμOPsがキャッシュからあふれた時の処理がおかしいんだろうな 問題を修復した人発見
0384 Socket774 2017/06/21 21:53:06
>>375
Linuxで相性の悪いメモリ使っててカーネルコンパイルするとランダムで起きる
そしてコンパイル通った場合でも、そのカーネルに書き換えるとカーネルパニック起こして起動しなくなる
メモリを交換するとSEGVは起きなくなったんだよな
とにかくメモリ相性が厳しいからなあ B2ステッピングはメモコンバグ修正だから直るかもね
B1はおつでしたわ VRMが貧弱・フェーズ数少ない安マザーでコアOCしている
メモリVRMが1フェーズで出来のよくない安マザーでメモリOCしている
とかいうオチだったら笑うわ >0x40バイトずれた命令を実行
CPUとして販売できないレベルだろこれ >>31
元はともかく、そういうことをわかってないレベルのやつが今騒いでんだろ >>32
逆汗して解説してくれてる人いるから見てこいよ
騒ぐ騒がないというレベルの問題じゃないから 全然良くわかってないんだがこれ科学とか数学の厳密な計算とか大丈夫なのか? >>35
ただのビルドなんで
gccを並列ビルドしないだけでも大方問題は解決するんじゃないか
というより現象が人によって様々なんだろう
多分上の人が言ってるようにメモリーが不安定なのかもしれんな メモリー入れ替えてなおった人が居るんで
なおらないことはない
Linuxによくある相性の問題かと この人ソフト屋さんだからソフト面で頑張って調査してるけど発生の有無とかランダム性を考えるとハード不良もしくは相性な気がする
上でメモリ交換で直ったって話もあるけどとりあえず
コア電圧とメモリ電圧盛ってみてほしいわ
場合によってはsoc電圧もか
あとlinuxにあるのか知らないけどモニタリングソフトでクロックとか電圧をモニタリングしながらコンパイルしてその変動がトリガーなのかどうか調べてみてほしいところ こういうのがあるからAMDは仕事用に採用しにくいんだよなぁ
良い製品が出来たのにほんともったいない まーいいじゃん主張した人はCPU交換してもらえたみたいだし
7700Kの温度スパイク問題みたいに
ユーザー「ファンが唸ってるんですけど」
intel「そんな現象は発生しません。」
でフォロー無しで終わった
あっちの方が被害大きいだろ >>34
64バイト前方にずれるので同じ命令を二度実行しても、データや結果が不正に化けるだけでエラーにならない場合もある。
WindowsはLinuxみたいなシステムと違って、エラーメッセージが貧弱だから問題が起きてもブルースクリーンが出たで済まして
原因究明する利用者が少ない
>>40
本当にウキウキな気分だったのに泣きたい
I wanna cry. これCPU原因なら近年まれに見るバグだな
いきなり新アーキだからしょうがないのかもしれんが どっちもどっちだって
Intelもここ10年内に登場したCPUに潜むリモート操作される脆弱性とかって修正だしとったでしょ
リモート管理機能のバグで
コンピューターを遠隔でフルコントロールされる危険性があることが判明し、
2017年5月1日にIntelは脆弱性を修復する緊急パッチをリリースとか あれってAMTだけと言ってるが、実はME搭載機全部(Core iシリーズほとんど)じゃないかと思ってる
また10年後に実は・・・とか言いそう
あとatom C2000の突然死問題の方がよっぽど致命的だな
あれは運用開始後に発覚してるから、ネットワーク機器の会社が頭抱える羽目になったとか スレチだが、近年まれに見るという話だったから、他の近年まれに見る事例の話になったと思う
まあ止めとくわ Pentium 66Mhz並のバグか?
全数リコールw メモリ交換で命令デコーダのバグが直るってどういう仕組みだよ >>39
ハード不良の原因をソフトで絞るのはよくあることだと思うけど >>49
たまたまタイミングがずれてその場所では発生しなくなるとか >>48
演算結果不定よりは動作不定の方が一般的には重い AMDにとっては幸いなことにgcc以外でバグが発生してないからな
リコールはない デコーダー異常なんて発生したらフリーズするから誰でもすぐわかるがな
誰しもバグが発生しPCの使用に支障が出てる訳ではない 出ない人もいる
メモリ相性電圧冷却クロックで出方が変わる
B2でアンコアに修正入る
相性厳しかったんだなという印象 ECCメモリも使えないような環境でデータ化けの心配をするとか、一体どういう神経してるんだろう
EPYCなら致命的だがRyzenはホビーユースで出してる製品だろうに… ホビーじゃないだろ
ビジネスにも使われるぜ
正直今回のエラッタは深刻だと思うけどな
とっとと糞石処分してB2買いたいわ ECCは宇宙線なんんかの特殊なエラーから守るためのものであって、
普段からエラーでっぱなしとかたとえデスクトップ用でも欠陥品だろ 何が深刻かって現象の程度ではなくAMDが対応策発表しない点だな
100%発生するパターンがないから発表のしようがないのかもしれんが
解決策発表しないとソフト側も対応出来ないから放置のままだし AMDも理由があって現時点で何も言わないor言えないんだろ
公式発表を待つしかあるまい
幸い発生条件が限定されてるようだし
メモリ交換で直った事例があるならCPUエラッタなのかマザーの設計が悪いのか個体差なのか単なる故障なのかも判断できない
ここで騒いだところで何も解決はしない
文句あるやつはAMDに直接問い合わせた方がいい
問い合わせ件数が多くなれば早々に何らかのアクションを起こすだろ PhenomやSkylakeはエラッタ解決のために性能落とされたからな
どうなることやら OCやらメモリの相性やらBIOSだとかLinuxメンテナフォーラムでさんざん議論われて今更感
あまり関係ない雰囲気がボランティアの対策チームの認識になりつつある
幸いなことに対応している人たちはAMDのフロント対応が杜撰な事に不平はいっているが
FUD/プロパガンダ等の押し並べて煽って騒ぎたててる訳ではないし
エラッタの振る舞いが判った今、あとは発生条件を調べて
あとはAMDにハードウェア的に対策してもらうだけだろ
PhenomのTLBみたいな事にならなきゃいいが Phenomみたいに性能落とされなければ
PhenomのTLBみたいに
これ自体がFUDにしか見えない 対策が入っても性能が維持できるかどうか、というのは皆が気になる所 そんなの対策されるまで分からんだろう
初物買ったんだから最悪の事態は覚悟の上だろ
待てないならAMDに問い合わせろ >>42
64ずれるってのがわからない
プログラムカウンタズレてそれだけってことあるのかな
それともスタックフレームを意味してる? Linuxだと出やすい条件の命令なのかもしれない
カーネルパニックしろブルースクリーンにしろ、何かしらシスログなりイベントログは残る >>58
X.M.Pプロファイルでメモリ設定しているビジネスユースなんて一体何処の世界に存在してるんだよ
そんなのAMDの責任範疇の外だろう全く呆れるわ
メモリがSPD設定しか読まないガッチガチのビジネスモデルで検証したのなら理解出来るが… >>70
プログラムカウンタがずれたんじゃなくて、データがずれたんでしょ コピペ
ただし、一点希望が持てることが明らかになりました。
CPUコアを1つにして、かつマルチスレッド無効化しても問題は発生することがわかりました。
これによって、別コア(スレッド)との相互作用が無くても単一CPUだけでも問題は
発生しうると言えます。これまでは、あるCPUにおいてSEGVが発生した際に、それ以外の
CPUの挙動が謎だったために、再現プログラムの作成難易度が相当高いと思っていました。
ただ、SEGV発生時のCPUの挙動だけを真似れば理屈上再現プログラムが作れることがわかったので、作成の敷居は下がりました。 コピペ2
起きるパターンは負荷テストを止めてほんの 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 出てしまったよ! コピペ3
BitVisor から覗いて見てわかったのは、ミスって #VMEXIT の状況を
うまく確認できるようにしていなかったことだw Local APIC の書き込みアクセスで
#VMEXIT したところだけ見えていて、果たして NMI が出ているのかはっきりしなかった。 (ω)しょぼーん。
これはさすがにやっぱり CPU 内部関係かなという感じがとてもする。
キャッシュがどうのこうのという感じではない。
レジスターの内容はこうして追ってみると一理ある感じなので、命令の実行が何かおかしいの?である。
(↓おそらく64bit先のに飛ぶことのかと)
LastExceptionToIP がなぜかユーザー空間のアドレスになっていることが多々ある。
例外の遷移先だから、カーネル空間でないとおかしい。VMM が絡んで変なことになるにしても、
それなら VMM の使っているアドレス空間でなければおかしいだろう。LastExceptionFromIP も
ユーザー空間にあるのは別にそれでもいいとも言えるのだが、そこに明らかに LastExceptionToIP にジャンプする命令が入っているというのはこれまたおかしな話である。
内容に矛盾はなく、本当に、ページフォールトだけがおかしいのである。
まるで 0x40 ズレた、手前の位置の命令を実行しようとしていたかのように。ハードだとしてもそうなる原因わかんね。。 この問題は放置だな
Ubuntu 16.04で問題出たと言っても
ryzen対応のUbuntu 17.04が出てる訳で
問題があるならそこで問題になっている 起こってるやつはメモリと各電圧の値含めて全環境を提示してみてくれ
そういう情報が一切無いからどうにもだ
ちなみに、定格とかじゃ無くて具体的な数字を上げてくれ この話、4月から言ってるのにいまだに反応には似たようなもんだな 重大な問題ならば、各MB、PCメーカーが黙っているはずもなく、販売中止もしくは延期を発表するはず。
だから重大ではないとは言えないが、そんな動きがまったく無いのが不思議だよ。
EPYCもmicronあたりが盛大にラインナップ発表したらしいし?
EPYCで解決してるなら、その故と販売済みRyzenへの対策が発表されるだろし。
誰か、この問題がユーザーサイドではなくメーカーサイドで取り扱われたソース知ってる?
予定していた購入は、そこらへんの情報が揃うまで待つよ。 >>72
SEGVエラーはメモリ関係ないCPUのエラッタなんだが >>83
断定されてないんだが
あくまでだろう止まりなんだが
それにメモリーというよりメモコンの話でしょ 必ず発症する状況、環境というのが存在しないのと
発症した人が大半「どういうハードウェア的な検証したのか」を公開しないから問題の切り分けがいつまでもできない
自作PC板的にチェックするようなところが殆どスルーされて非公開だからCPUの問題だと確定できないんだよな
http://damelog.com/
例えばこの人とか、M/B交換とメモリ交換を行ったことはわかるけど、
BIOSバージョン不明、メモリ設定詳細不明、電源型番及び使用期間不明、使用CPUクーラー不明、
関係なさそうだとしても使用GPU不明、使用USBポート不明、ARC-1214-4i使用スロット不明
言い出した人の環境に関してはCPU以外一切不明だし進歩ないのは仕方ないと思う >>84
メモコンはCPUの機能だろうが。オンダイだぞ。 >>87
メモコンとメモリー間の相性悪いからって意味ね
当然メモリーが規格に適したものであるならryzen側が修正しないといけないが 朝はグダグダだったのに今見たらスレタイに即した内容になってて草
検証できる有志は検証環境のハード・ソフト構成と結果を挙げて行ったらいいのでは?
集計すれば何か傾向など分かるかもしれない
(例えばこのマザーだと出ないとか、等)
CPU・マザー・メモリはできれば製造週と製造国も
CPU・メモリは定格かOCか
AGESAによる変化はあるか、もあればなお良し(Ver.Up毎にメモコンいじってるし)
テンプレも作った方がいい
あと検証したいが何をしたら良いかわからない有志候補のために、検証の仕方の手順を作ってくれる有志もいるといいと思う
(そういうサイトがあればその案内でも可)
俺は残念ながら有志候補レベルだが、テンプレ草案位は作れると思う ttp://news.mynavi.jp/articles/2015/09/29/ddr4/
腐ってたのはCPU側Skylakeのメモコンが原因でメモリの品質には全く問題は無かった訳だが、何故かモジュール側で対応させてるよね Intelお得意の、他に経費をなすりつけるためだろ
これならすでに製造した欠陥メモコン入ダイを全て捨てる必要がなくなる AMDとかGentooとか各フォーラムに事例が連日報告されてる
再現方法が完全に分かってるわけじゃなくて、全ての個体に起きてるわけじゃないようだけど >>92
AMDはメモリモジュールメーカーに圧力かける必要ないからな
そもそもなんでお前このスレにいんの?
ネガキャンのネタ探しか? 連投すまんが
>>93
その各フォーラムのリンク貼ってもらえないか? >>89
そんなの本来AMDがやることだろ
なんで購入者がそこまでやらないといけないんだよ
不具合報告を上げたら、AMDが詳細条件とか調査してバグ修正すればいい Ryzen Segv Battleとかやってる人たちはハッカーとして面白いからやってるんであって消費者としての立場でやってるわけじゃないと思うな 放っとけばいい
メモリ交換して問題が起きなくなった人がいるんだし
同じ現象起きたくない人はその人と同じメモリ付けときゃいい訳だ
そうやっていろいろ議論するのがLinuxユーザーの楽しみ方の一つで
昔もLinuxでは使えないとかあって
ペンギンシールが貼ってあるものはLinux動作確認済みですとかやってたんだけどな >>97
今回のエラッタは全環境で発生してないからな
AMDへの情報提供量が少ないだけ発見修正の時間がかかる Linuxユーザーが絶対エラッタ起きるコードを楽しく作ってるからAMDに提供するまで待ちだろうね linuxユーザーなんてこの手のトラブル慣れてるだろ
騒いでるのは関係の無い外野ばかりだな >>96
ありがとう、後で見てみる
>>97
そう思うなら賛同・参加しなければいい
AMDのアクションが鈍い(公式な情報公開が全くない)事もあって、不安に思うユーザーは日々少しずつ増えている
ならユーザーレベル範囲で不安の軽減策として何かやれないかと思って一手段として書いてみたまで
(賛同は得られないだろう事は承知の上)
AMDに不具合報告を上げるのも手段としては有効だろう
現状おそらく報告件数が少なすぎるのがアクションが鈍い要因と思われる
件数が増えれば増える程AMDに重大かつ緊急の問題と認識させられるだろうから なんでマスコミの記事もPCメーカーの見解も出てこない?
ユーザーの見解しか見つけられないので、誰かください。 一度CoreInfoの誤表示信じてヤラカシだから慎重なんでしょ
AMDが公式でなんか言うまで動かないよ 連投すまんが
>>102
LinuxとBSDでは起きていると聞くが、Windowsで起きているという話は聞かない(少なくとも俺は聞いた事がない)
だから関係のない外野であるWindowsメインのユーザーとしては
何故Windowsでは起きてない?
本当は起きているのに気がついてないだけ?
という疑問が、だんだん不安に変わってきていて騒いでると思う >>99
あのシールそういう意味もあったのかw
ドライバが用意されてるとかその程度かと思ってた >>105
業界全体が歩調揃えてるって?それはないでしょ。
ましてや、PCメーカーは販売している以上、クレームを受け付ける立場だよ?
問題発覚から2ヶ月もたってるってことだし、EPYCは持ち上げてる記事しか目につかない。
重要事項なら、販売延期するだろし、これまでもしてきてたと思うけども。 分岐予測切ったりL2TLBの動作を調節したりメモリーインターリーブをブロックサイズごと変更して動作確認可能なBIOSTARのマザーボードで誰か試しておいてくれ 報告テンプレこんな感じか?
【CPU】 電圧設定、クロック設定 (特に設定していないなら"デフォルト")
【CPUクーラー】 型番、設定あるなら、(CPU付属品の場合は"リテール")
【メモリ】 型番、使用中のクロック・電圧・タイミング設定も
【M/B】 型番とBIOSバージョン("最新"はNG)
【VRM冷却】 CPUクーラーが水冷やサイドフローの場合には必要
【グラフィック】 総使用電力の参考にするため
【ストレージ】 使用IFの種類、できれば取付コネクタの位置も
【HBA】 使用している場合のみ(使用スロットも)
【使用USBデバイス】 できれば使用コネクタの位置も(CPU内蔵のUSBコントローラも存在している為)
【ケース】 ケースファン等の冷却機器の有無も
【電源】 W数だけでなくメーカー型番、使用年数が重要
【アース端子接続】 電源のアースをコンセントのアース端子に接続しているか否か
【動作テスト】memtest一晩放置、Prime95 1時間パス、OCCT Linpack 1時間パス等が基準
CPU以外に何らかの問題を抱えていたなら動作テストでエラーが出てくるはずだから、
ビルド以外の動作テストでエラーが出ていないことを確認してほしいところ
memtest4周程度ではメモリエラー見落とすことはある(一晩放置で朝方にエラー発生ということもある) まともなPCメーカーが「安OCメモリをX.M.Pで回してコケました」なんてレポする訳がないだろう
EPYCでは発生しないようだし、Ryzenでもクソ高い純正メモリだと安定動作するんだろうな
寧ろPCメーカーにとってみれば「自作BTOだと不安定だからうちの製品買って下さいよ」と絶好の売り文句になる >>110
現象はIPがキャッシュライン一枚ぶん飛ぶようだから
CPU
メモリ
MB-BIOSVer-uCodeバージョン
電源
冷却
温度(無ければ無くても可)
Vcore
VSoC
VPLL
マルチプライヤ-Turbo-XFR
クロックダウン関連
あとメモリのわかる限りのパラメータ(定格表記不可)
こんくらいかな いままでの重大バグの対応
○Pentium FDIVバグ
石交換
○Pentium F00Fバグ
OSで対策することで対処可能
○Phenom TLBバグ
BIOSアップデートでTLBキャッシュ無効化で修正、ただしパフォーマンス低下
○Sandy intel 6チップセット SATAバグ
マザーボード交換
○Haswell TSXバグ
修正不可能、BIOSアップデートでTSXまるごと無効化される
○Atom C2000シリーズ
どんどん壊れる重大バグ発覚、ただし一般ユーザー向けに直接販売はしてないために対応は不明
○Skylakeフリーズ
BIOSアップデートで修正
○Ryzen SEGV
いまのところAMDからアナウンスなし >>93
この再現性のなさがこの問題の一番厄介なところ
おそらくハードの問題かと予想されるが、どのように処すべきかわからない
またメインであるwindowsで類似の不具合か聞かれないから、対策も下手げに打てない
現実はダーク Atom C2000のバグはC0ステッピングで対策済み
だけどブラジルの企業に訴えられたりしたぐらいには広い範囲に及んでるみたい >>110
おお、素晴らしい
あとはソフト関係
[OS] Linux FreeBSD等
[ディストリ] Gentoo バージョン等
[カーネルVer] uname の値
[gccVer]バージョン見るオプションの表示内容
[gccコマンドライン]
[ビルドに使用したカーネルソースVer]
みたいな感じ
(すまんが詳しい方補って)
(あと全角のかっこ使ったら書き込めなくて[]使ってる)
memtestはメモリOCの場合8-10周目辺りでエラー出る事があるので個人的には10周推奨
>>112 の内容も合体させればいいかな
Windowsも使える環境ならHWiNFO等のスクショでもいいかも >>109
ASRockのX370taichiもP2.40(L2.34、L2.36も?)はそれ関係の設定できる模様 放っておけばいいのに
LinuxのOSシェアのうち
UbuntuとDebianという70%のシェアを占めるディストリビューションは
普通に配布されてるISOなりCDなりから普通にインストールして使えるんだから
全体の0.5%にも満たない人達の中で更に外れを引いた人達が頑張ってる訳で
VISTA人口より遥かに少ないだろ >>118
それはUbuntuとDebianで他の環境でビルド済みのカーネルを使っている限りはsegvは発生しないという意味? >>111
ちょいまち、それ発生原因の確定内容?初耳なんだが 何か勘違いしてる奴がいるようだが
この件がUbuntu17.04で改善されてるなどという話は全く無いぞ Linuxのディストリビューションって、基本的にパッケージ構成とGUIのインターフェイスの違いくらいしかない
カーネルとかGCCとかのコアパッケージは同じだし >>119
カーネルコンパイルをする必要がないだろ
それに負荷がかかった時以外は発生しないケースが多いんで
ubuntuやDebianユーザー的にもそんなんあるだー程度じゃないか 淫注キチガイが騒いでるだけって
誰かが言ってたよ、無視しよう そもそも俺の環境で発生しないんで
検証しようがないんだけど 会社の会議でも
使えない奴に限って重箱の隅のどうでもいい問題に
必要以上にこだわって会議を紛糾させる
ゴミクズみたいな奴はどこにでもいるんだな
さらっと流しとけよ >>126
むしろ発生しない環境の情報はあまり出てこなくて貴重なので知りたいわ >>123
当たり前の事とは思ったが念のため聞いた
7年位前まで4年程CentOS4と5は使っていたがそれ以降触ってないから大きく変わっていたりしたら知る術がないので
>>127
俺の事言ってるんだろうけど別に使えないゴミクズ扱いで構わんから
お前こそさらっと流して一々書き込まなければ? >>117
ゲームベンチ結果もいろいろ変わるから暇なら試してみてね Ubuntu17.04でもSEGV出るし、kernel4.12rc6でもでる。
ちなみにメモリはFLARE Xな。
カーネルオプションにiommu = softつけたりすると若干頻度が下がってる感あるけど
当てにならん。 スレチですまんが
>>132
特に日本の会社の少し古いゲームに効果あるらしいね
あとBIOSTARのマザーも持ってるよ 連投すまん
>>133
念のための質問だけど、その環境でsegv出るのはカーネルビルド(16並列オプション有)の時だけなんだよね?
iommu = soft はハードのiommu使わないオプションかな
アンコアの負荷(消費電力)が下がると頻度が減ったりするんだろうか?
UEFIセットアップでIOMMUを無効にした場合の差も気になる所 ネチネチ粗探しするなよ
なんでも批判したがるクズだな
嫌われるぞ LiinuxでしかエラーでないからWindowsでは関係ないとかいってるやつは
根本的にサーバを理解してないな
AMDもしくはMSが、Windowsではこのバグは影響ないって公式にアナウンスしない限り、
Windowsでもこのバグの影響を受けると想定するのは当然 Gigabyte マザーで出るVector 07は同じ原因なんかな コンパイラはファイル読み書きと計算をするごく普通のプログラムに過ぎないので
問題発生のトリガが特定できない現状あらゆるプログラムでデータ破壊の可能性があるとしか言いようがない >>139
この場合VS2017のバグなのかRyzen segvなのか切り分けできてないように読める 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 >>144 に書いてある153の人は、他のスレでKaliLinux 64bitで起動時にsegv出ると言っていた人
環境詳しく晒せと言われていた所までは読んでた 連投すまん
再度幾つかのページ見てきたけど、やはり自分で環境作って実際にsegv出してみないと現象に対する理解が深まらない事が分かった
またハード的に幾つか試したい事も思いついたので出直してくる
あと変なのに絡まれてるからこれ以上スレに迷惑かけるのも嫌だし
ちなみに石交換になった人のページ見てたら、石交換は単に故障かどうかを切り分けるためで、同じ機種の別の個体と交換という事らしい
(B2ステップとの交換ではない模様) >>144
これ投稿したやつだけどryzen購入時期は発売直後
分岐予測とかSMT切っても発生した
あとメモリのプロファイルはDDR-2134, cas-latencyが16.0, ras-toCASが15, ras-prechargeが15, tRASが36,tRCが50という値になっていた
cpu-zから確認した あと同じusb使ってpentiumG3258の機体で起動したところ、普通にいけた USBにOS突っ込んで起動しようとしたらフリーズと
SEGVと判断した理由とかはあるん?特定の場所でフリーズとか >kalilinuxブートするusb挿す位置も全部のポートで試したけどだめだった
何気にこういう情報重要だからありがたいよ >>152
いやGTX750Ti
>>153
起動時にlinux特有のログみたいなのが流れるんだけどそこで延々SEGV〜ってのが流れ続けるループしてるっぽい >>155
再現率100%の事例なら初じゃね
今まではどの環境でも再現率100%じゃないから困ってたわけだし
明日試してみよ DRの4枚刺しは公式では1866までしかサポートしてないんですが・・・
2166で動かしてない? >>157
(アカン)
それかもしれない明日BIOSアプデと一緒にやってみる
>>156
おけ 2枚刺しで試してみたらどうかな?2枚刺しDRなら2133までサポートだし
(上2166を2133に訂正)
BIOSアップしても公式サポートは1866までだしね kali linux の最新版は2017年1月リリースだがそもそもRyzenに対応してるのか? Ryzenでビルドしたのじゃないなら別の問題じゃないかと ググったら出てくるが平気で動くらしい
変なエラーもなしで Ryzenの場合、windows10でもcreators updateじゃないと不具合あるケースあるもんな
うちで1700普通ににつかってるけど、実害がないにしてもエラッタがあるってのは
なんか気分が悪いわ。
とりあえずこのスレを転載して煽り記事書いてアクセス数を稼ぐジサクテックは死ね エラッタの発信主さんはメモリクロックいくつで動かしてたんだろうね
2400のSR4枚みたいだけど ブートでコケるやつはryzenを認識できない事による対応命令の誤認識ってやつでしょ
ブログに情報が出てたよ
SEGVはuopcache切っても発生して、
ipは正しいんだからL1i-cacheに病気持ってるってことに見える >>162
>>165
リンク貼ってくれんか
探し方悪いのか見つからない >>167
そっちの事言ってたのか
それは仮想マシンで起動する場合の話ね
論より証拠で今DL中
WeelkyBuildもあったからこっちも試してみる >>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は試さず 連投失礼
>>158
>>169の通り問題なく動いてしまった
フォーラムにグラボ絡みで起動しないような情報がある
1080Tiを使っていて起動しないらしい
https://forums.kali.org/showthread.php?35773-Kali-Linux-works-on-AMD-Ryzen
グラボ変えるかWeeklyBuildで試してみて ubuntuでもXMP読むとbios立ち上がるのにブートでコケるからメモリは弱いな ねちねち粗探し、そんな人生楽しいか?
前向きに生きろよ
と言うと馬鹿なお前らは
改善しようと前向きにやってるんだと
アホなことで自慰する糞 この問題て仮想マシンでもおきるんかな?
試したいんだが、ryzen機はesxiいれてしまったので、仮想マシンでしか試せない >>172
お前こそこんな所でねちねち粗探ししてないでとっととどっか行って前向きに生きたら?
それとも他に行く所もなくこんな所でねちねち粗探ししかできない馬鹿なのか? >>173
あとメモリは定格でやってみてほしい
まあ最初は2枚刺し2133が安定だと思う 22日のブログで64バイトズレ以外にも違ったエラーもあるって書いてあるな ちなみにAMDサポートコミュニティSEGVスレッドのメインキャラの一人は
某フォーラムで「環境を全部網羅してないと話にならない」とかネチネチ難癖つけられて
脱出してきた人です。難癖つけた人は私の書き込み記録を消した人でもあります。
まあなんつうか、アレな人が一部いると大変ですねと
https://twitter.com/satoru_takeuchi/status/877828616846888961
このスレにも環境ガーとか必死でねちねち文句つけてる奴が1匹いるよね 127
136
172
178
ネチネチ(ねちねち)
粗探し
重箱の隅
環境を聞かれる事に対する不満・文句
共通項が多いのは気のせいか?
http://i.imgur.com/na66loK.png
http://i.imgur.com/4RF6SPP.png ここまで執拗だと仕事でネガキャンやってるのかと疑うわ 仕事やろなぁ
別に環境設定晒して何の損にもならんだろ?そこに問題が無い証明にもなるのに
必死に隠そうとしてるのは何か裏を疑ってしまうわ エラーの再現性を検証する為なら細かい環境まで晒すのは普通だと感じる
そうしないとあんまり意味が無いから
それを嫌がる奴はエラー検証なんて面倒な事を普通はしないだろ 最初からけんか腰なら何を言っても無駄だなって思うことはあるよね intelの情報操作が凄すぎる
どんだけ金ばらまいとんのか
7700Kの温度スパイク問題とか
日本はどこも記事にしてない
ジサクテックも取り上げない
AMD側は不具合は目立つよなー けど基本的な構成データは欲しいとは思う
>>144みたいなメモリのサポート外ということもあるし >>183
いや思わんねぇ
喧嘩腰でやってくる奴なんか環境晒して問題無い事証明して黙らせればいいじゃない
なんでしないのかがわからん >>187
アホ相手に情報与えたくないって感じじゃね?w >>188
一人で大量の機材用意して検証できるならまだしも情報共有しないと検証が進まないだろ 自分の検証環境に問題が無い事を証明出来ない無能なんだから仕方ないよね 問題の人はまずWindowsインストールしてOCCTとかで確認したほうがいいんじゃないか。 本人の検証環境に問題があるとは思わないけど
他者の検証環境に問題あるかどうか確認せずに報告だけ取り上げるのは片手落ちだからな
取り上げた他者のエラー報告の中に別要因によるエラーが混じってたら特定できない要因になる
それが目的なら目論見通りなんだろうけども そもそもgcc以外でのコンパイルは問題起きたの?
数ヶ月前の海外記事はgccだけだって話から何にも進展してないよねこれ >>188
それは検証をする人間としてはアホ以下の反応なんだよなぁ・・・ >>194
わかるわー
こういうトラブルが発生したんですがどうしたらいいですか→情報が拾えて無くて全くわからない→一々出向く羽目に
俺の仕事でよくあるパターン
情報がなきゃ全くわからんからな、情報が多すぎるぶんは取捨選択すりゃ良いだけだが少ないのはどうしようもない >情報が拾えて無くて全くわからない
聞いたらいいじゃん?ここどうなってますかとか >>196
聞くよ、まぁ初期情報が足らなさ過ぎるケースが殆どだけど
そうするとちょっと調べて来ますつって時間掛けて何か調べて来た挙句よくわかりませんと返ってくる
最初の情報の時点でその対応者のスキルというか中身わかってんのよ、わかってるなら情報不足と言っても聞けば済む範囲に収まる
専門外の事を人間は答えられないし出来ない、これは当たり前の事で仕方ない
だけどこういうケースはそうはいかない
ネット経由という特性上こういうトラブルシュートで情報不足ってのはやり手が答えない時点で止まる
専門分野の違う大多数による観点から確度を高めるという特徴を、一辺倒の分野知識だけで済ませようとするからそうなる
要はさ、自分の中の結論通りに行って欲しいだけで解決する気無いんだよ
尤もこの正常化バイアスはわかってないと防げないしそこを責めるつもりはない
まだ条件も確定してないしよくわからんからな プログラマーとしての興味で粗さがしが楽しいのはわかるが
株価だの持ち出した時点で、やっぱ最初からそういう目的だったのね、って感じ 元の人はブログでパーツ構成だけ書いてたような
違う人だったかな?キングストンのハイパーなんちゃらってメモリだったな エラッタ見つけたやつ=すごい
エラッタに便乗して騒ぐやつ=氏ね キャッシュ1ライン読み違えるならストレステストでもエラー吐くぞ
負荷テスト通してるのかコイツ? >>205
次の日のブログで64バイト以外にエラーあるわって言ってるのに悪質な記事だなこれ 辿ったがコメントにあった
>MSR C0011029h 14:14 は 1 になっていますか?
てのは気になるな >>203
日本人はお祭り好き(笑)だから仕方ないね
Win10の時もそうだったろ その割にはインテルCPUのエラーはこんな騒ぎ方しないよな
ユーザー数からすればあちらの方が遥かに多いはずなのに インテルのエラッタは綺麗なエラッタ!
とかじゃね? 被害妄想はgcc以外で発生事例確定してないのに騒いでる連中なんじゃないですかね windowsでOCCT24時間耐えた(24時間で止めた)ryzen1700機で、gcc試してみるわ
結果でたら、HW構成含めてここにかくよ 日本でAMDしかもryzenユーザーでlinuxユーザーな奴の比率考えたら騒ぎの大きさが不自然だと思わない方がおかしい >>216
はしゃいでるのが居るのは目障りだが、原因究明のプロセス自体を論難みたく扱うのは間違い >>217
検証は大いに結構だと思うよ
関係無い外野が何で鬼の首取った様に騒いでるのかが不思議で仕方ない
まだAMDに勢いがあった頃のphenomのエラッタよりもネガキャン酷いだろこれ twitterをSEGVで検索しても日本人ばかりなんだよな
ryzen segv battleとかいっておちゃらけてるのが気に食わない 気にすんなよ
どうせスリッパで手のひら返すか黙る奴らなんだし 仮想でも出るとかって話しなんでVitualBox使って
ubuntu17.04環境で4.12-rc6コンパイルしてるけど
Segmentation fault出ないわ
元々ubutu最新は仮想で必ず入れてるんで、、、ついでだが
今もやってるけど、、、
仮想内でメモリ1.5G使用、
ハード25G増加程度になり時間もそこそこかかるんで
フルパワーで臨む場合は
ある程度耐久ソフトを通した方がいいだろうな バグの内容詳しく語らず不安だけ広めてる糞まとめブログのほうがむかつくわ >>220
マジメな技術をおちゃらけてやるのがOS周りの人たちなんでそういう文化だと思うしかない Ubuntu16.04はよく出るらしい
OSによってもバグ発生頻度がまったく違うからCPUがおかしいと言っても外的要因がデカ過ぎて言いがかりと言われても仕方ない >>226
Linuxのバージョンによっては発生しないの伝えないアフィテックさんですか? 一般人はどんな問題なのか理解できないからただ「Ryzenには問題がある」としか認識できず不安ばかり煽られる
単なるネガキャンに使われてるのは不快だわ >>226
理由がある
恐らく、やってみる→再現せず→発生事象をforumで調べる→図面見る→リファレンス内では発生しない事を確認→?
って事だろう 現実に発生しないケースが存在する以上
本当にCPU由来なのか他の要因で起こってるのかが分からないのにryzenに問題があると言い切る方がおかしい
だからネガキャンにしかみえないし不快だわ 根拠なく問題がないと主張するのはOKなのか?
ひどいダブルスタンダード >>231
検証してる人誰しもがCPUが悪いと思うんだけどなぁしか言ってない
つまり確定してない問題をCPUのエラッタと言い切る神経がわからない >>234
切り分けができていない状況で断言するのは悪意しか感じないけどな 検証出来る人間の間だけで騒げば良いものを一般人にも無理に広めようとするからネガキャンと言われるんだよ 検証している人間以外が不確かで不正確な情報を拡散するのが正しいと考える訳か 細かい環境出せと言えばこれだからな>>179
ネガキャンと取られてもしょうがない まとめ方の問題なんだがそこはスルーか
個人の確証出来ないブログをソースにしてよ >>242
つまりCPUに問題があるかどうかは問題が無く営業妨害が目的なんだな >>234
>>237
ハードウェア環境をただの一人も出していないってのは本当?
これはこれで由々しき問題だと思うんだが >>245
おれが拡散してるわけじゃないから
ボランティアの誰か 団子の場合は不確かな情報じゃなくて嘘の情報だから
あれはたちが悪い Ryzen 7に換えてからXMedia Recode 3.3.5.8で異常終了することが増えたんだよ。
http://www.xmedia-recode.de/en/download.html
SMTを無効にして8スレッドにすると異常終了しなくなる。
memtest86は2周したからメモリが問題じゃないと思う。
Opteron 6300ではこんなことは無かったよ。 CPUのエラッタ見つけるのはユーザー視点から見ても有難いことだが
問題なのは構成による不具合かどうか不明確な他者環境でのエラーまでCPUの問題だと決めつけて同じ扱いすることだよ
別原因の問題をごちゃ混ぜにしたら原因特定から離れていくばかりなんだから
実際に自分で検証できない自環境以外での問題を取り上げる際は慎重になるべきなんだよ
例えばAMDフォーラムで報告してた人のように、冷却や電源含めた全てのパーツ構成とBIOSバージョンや設定書き出したうえで
「Prime95を1時間以上パスして問題ない環境」でエラーが出たとする報告は、他者の環境でのエラー報告として示す価値はあるけど
マザーとBIOSバージョンしか分からない環境で発生したとされるエラー報告は、まだ参考例に留めておき一例として取り上げちゃダメなパターン
発生したエラーが問題としているエラーなのか、CPU以外のパーツの初期不良系エラーなのかの切り分けが出来てない段階だから、
まずPrime95等で負荷テストを行ってもらい、負荷によるエラーが発生しないことを確認してから、今回のエラー発生例に加えるべき事例
他要因の切り分け出来ていないこの段階のエラー発生報告を一例に取り上げるのは単に騒ぎたいだけと取られる >>250
10週
それからOCCTとPrime95も
全負荷でエラーが出るならこいつらでも出る筈 Linuxでしか発生しない
Wimdowsでは発生しない
こういう嘘の書き込みは文句を言わないの? 発生しているなら報告すれば良いと思うが窓でカーネルビルドする事あるのか? win機で起こるというのは初耳だがソースあるの?
テストするから教えてくれ カーネルビルドで発生するってことは、他でも発生するってことなんだけど >>255
日本語が不自由ですか?
意図的にアホなフリですか? >>258
windowsで発生したソースをよろしく >>253
だから発生してるなら報告があるはずだろ
でCPU以外に問題が無い環境を晒した上での報告が何処かにあがってるの?
無いなら風説の流布だよねそれ いやwin機ならもっと騒ぎになってるしソースぐらい普通あるでしょ
無いというならお前の単なる妄想なんだけど
まあ言い張るなら好きにすればいいんじゃない 海外じゃ数ヶ月前から記事になって大きな騒ぎになってないからなぁ
USBのアース線の件みたいに流れる電気的なものかも知れんし
>>253
SEGVのバグと違う可能性のがデカイんだが?
SMTを切ったら直ったというのはソフトがきちんと対応していない可能性のほうがでかい WSL上でビルドミスって話はどっかで聞いたな
俺が調べた限りじゃ無かったと思うが何処かにあるかもわからん >>257
先に主張をはじめた「Windowsでは発生しない」
これのソースを先に示すのが筋かと思うけど やっぱりハードの構成が甘いとかOSを再インストールしてないとかじゃないのか
XMedia Recode 3.3.5.8
これも入れてるけど落ちたことはないな >>266
発生しないソースなど存在しえない、発生するから報告も上がるし問題にもなる
さっさとソース提示しろや >>268
つまり証明できないわけだよな
「Windowsでは発生しない」も単なる想像 >>270
発生したと言うソースが無いなら必然的に発生しないと言う事になる
詭弁は結構ですよ >>270
そういうDD論は通用しないよ
windowsで発生したソースよろしく >>266
逆だろw
お前の言ってる事おかしいし屁理屈だね 「現状ではWimdowsで発生したという確かな情報は無い」
これが正しい主張 >>270
つまりお前も起こった事を証明できないわけだよな
「Windowsで起こる」も単なる想像 phoronixとかでもエラーが出たって言ってる人はいるみたいだけどな Winはエラー吐きながら動いてるからな
エラーに埋もれて見つからない可能性も否定できない >>252
そいや思い出したけど田村がムキになって1700OCしてprime95を1日回してたの思い出したわ >>276
つまり不安を煽って買い控えを起こしたいんだろ アフィテックはゲハと同じように更なる対立煽りで金稼ぎ始めたからこれから先おかしい人が次々自作板に来るぞ >>279
それでもwinだと大問題になってそうだけどねぇ・・・ Windowsで発生するかどうかは、エラッタが解明すればわかる
わかってない現状で「Windowsでは発生しない」
こんな主張は嘘だと
悪魔の証明でも何でもない エラーログ残るから各自覗いてみればいいのでわ
フリーズしたぞだからSEGVだって安直に決めるのが問題であって発生した証拠検証があれば認めざる得ないのよ
証拠と検証があればな 実際にエラッタだとすれば、Windowsでも発生させることが出来ると考えるのは極めて自然
CPUがLinuxのカーネルビルドをわざわざ選んでエラッタを仕込んだとかじゃない限りは >>284
発生しているなら既に問題になっているだろ >>279
ありえん
キャッシュライン一枚ズレるような場合、OSは関係なくアプリケーションが落ちる
もう一つOSで差異があるとすればMSRくらいか >>286
linuxでも起こらない場合があるのに?
エラーを狙って起こせるならエラーログ残るんだから既に見つかってないとおかしいよな
linuxユーザーなんて1%程度しかいない少数でも見つかってるんだからな >>287
今騒いでる人がいないと言うだけ
他のエラーに埋もれているとか、今後出てくるソフトで発生するとか、可能性はいくらでもある >>289
あり得ないかていを書いたつもりだったんだが 関係の無い人間巻き込めば巻き込むほど解決から遠退く
このスレだって4分の1埋まってるけどまともな情報いくつあるのかって話 >>290
だから全体の1%しかいないlinuxユーザーに起こっているものが遥かに多い筈の窓ユーザーで起こっていれば既に見つかっていないとおかしいだろ >>292
それが目的なんだろ
原因がはっきりしない方がネガキャンやってる奴には随分と都合が良さそうだからな >>294
ただ騒ぐだけじゃお客様呼び込むだけでまともな情報交換出来なくなるから害でしかない 機械語に直す時に問題が発生してるんじゃないの?
アプリケーションの機械語を読み取るのは正しく動作出来るから一般人は認識できない的な
コンパイル成功してもファイルサイズ違う場合があるって64バイトの発見者のブログに書いてあるし Windowsでは発生しないという非対称性は何の疑問も持たないのに、発生率が異なるという非対称性は考えもしないと 4.10以降のRyzen対応カーネルが実はアカンという可能性はないの? >>301
なるほど
素人の俺じゃ調べてもこの程度しかわからんし一般人はもっとわかってないんじゃないかなと感じるわ >>300
つまり問題にならない程低確率で発生するかめしれないししないかもしれないと?
不安を煽ってるだけで話にもならないな >>302
16.04のデフォルトは4.10より前のカーネルだから16.04で発生するならあまり関係ないんじゃないの? >>304
あくまで可能性
今後率が増えるかもしれないし減るかもしれないし、全く発生しないかもしれない
現時点では不明
常識的には、特定のOSの特定のアプリの特定の使い方だけで発生するというのは非常に考えづらいけど そもそもCPUに問題があると確定した訳ではないのに何言ってんだ? 今まで出てる情報から、CPUのエラッタである可能性は極めて高いと思うが
まああくまで可能性 >>307
現時点で発生の報告も無く不具合も出ていないのにまるで発生したかの様に情報を拡散するのはおかしいけどな 解明されて無いのに根拠なく「発生しない」はおかしいと思うけどな 落ちた時のスタックトレースと周辺の命令と各レジスタの値くらい貼れよ 証明されてないのに根拠なく「発生する」はおかしいと思うけどな
ブーメラン乙 CPUのエラッタで確定したらWindowsも影響あるかもってのが自然な流れでしょ 「Windowsでも発生させられると考えるのが自然である」 「今のところWimdowsで発生したという確かな情報は無い」 >>315
だからさっさと発生させてエラーログ出せば良いだろ うーん、さっきからエラッタが多いな
nがmにずれる 原因不明のフリーズや再起動ってのは自作で一番困る。
「負荷かけた時だからこれは電源か」とか予想せんといかん訳だが
親方日の丸のIntelだから安心だろう、でもAMDも安くていいぞ、とか思ってAMDをチョイスする。
けど、こんな事があるなら金輪際買わん。イコールスペック、イコールプライス、は妥協できても
設計でこんな事故られたらもう駄目だ。 >>317
エラッタを解明してWindowsで発生しないという証拠を出せば? >>319
CPUエラッタで確定してないのにそんな結論言われてもアンチかガキにしか見えないけど >>320
エラッタを解明してWindowsで発生するという証拠を出せば?
ブーメランブーメラン・・・ 誰も技術の話してなくてふわふわしたイメージだけで語ってて草
どうやってCPUが動いてるか基本的な部分だけでも実際理解してないでしょ 17.04でコンパイルしつつ
16.04LTSなるものを仮想でインストールしてみたわ
これでコンパイルして見るか
取り合えずupgradeしてみたが時間かかるかもしれんけど >>322
>>317に対してブーメランしたつもりだったんだけど
アホな発言に対して同レベルに合わせてみた 条件確定するまで進展なさそうだから
プリプリしても仕方ないと思うで >>323
検証してる奴は日本に一桁人数しかいないと言われても驚かないわ 悔しいのは分かるけどどっちがアホだと思われてるかはこのスレの反応で理解しろよ >>309
極めて低いと見るね
エラッタならここまで再現に手間取ることは無い
またエラッタなら再現しない環境も絶対に存在しない
影響あるかもじゃ無い
例の0x40であれば何であれ必ずエラーが目に見える形で起きる
データ破壊は確実と言って良いからな
であれば何故起きないか
答えは単純だ
「機能が不安定になる要因がある」か「渡すパラメータがおかしい」か
このどっちかしか有り得ない 普通エラッタならもう解析+SEGV再現されてるよなぁ 発覚?してからそこそこ経過してるんだし
今でも再現性なしとかどうなってるんやら そういえば昔ブリスベンAthlonx2 5000+で組んだ時XP SP2で謎のフリーズ頻発して使い物にならなかったなあ
すぐにSP3がリリースされて解消されたからよかったものの それこそk10やK15の時にエラッタ修正でOSからMSR書くように指定されてて、誤ってそれが適用されエラーを誘発する
てのも有り得なくはない
kernelをmakeするconfig見てるとわかるが、超古いサポートまで残ってるからな
アレの解析だけでも相当な手間だろう >>330
君はCPUの何を知ってるの?
発生確率の低いエラッタなんていくらでもあるんだが
数ヶ月負荷テストして見つかるエラッタ
たまたまピッタリ複数事象のタイミングが合った場合に発生するエラッタ
今のCPUは非常に複雑なので、検証も極めて時間がかかる
当然発見出来ないで出荷されることもある ソフトウェアの脆弱性報告も粗探しって言われそう
そして脆弱性が一切公表されない優しい世界へ 粗探しというか屁理屈だし可能性の話ならINTELでもあるんだけどね だからいつCPUのエラッタだと確定したんだよ
妄想も大概にしとよ >>1
これ結構前から指摘してる人いたからある程度在庫吐けてから報告なんて
不具合を発見した人のAMD愛を感じるね
粗悪品つかまされたと怒ってる人は
結構前から必死に不具合発見して報告してた人をネガキャン目的だと
馬頭し続けて黙らせてたネット工作員を恨むんだな >>334
何も起こらないからわからないのであって、今回は何かが起こるのかわかっている
つまりこの時点で前者から外れる
その上で特定出来ないというケースは通常考えられるものではない
ぴったりタイミングが合えば発生するというパターンも
頻発してる奴も居れば全く起こらない奴も居る
この場合、頻発するケースはとんでもない天文学的な確率を引き続けていることになる
これは確率的に有り得ない
コイツを合理的にエラッタと説明するのは非常に困難だ
ハズレ個体って方がまだ説明が付く >>340
愛って何を言ってるんだ
gccコンパイルで原因不明な案件をCPUのせいって印象操作したまとめブログに愛があるといいたいのか 前Kalilinuxが起動しないって言ってたものだけど、GTX1080からGTX750Tiに替えたら治った。
あとGTX1080の状態だとメモリの周波数変えてもuefiアップデートしても起動しかった
これから念のため耐久回してみる グラフィックドライバ周りかな
ttps://forums.kali.org/showthread.php?35773-Kali-Linux-works-on-AMD-Ryzen 動作条件が特定されないかぎり、正常なお前のそれもいつ発生するかわからない地雷
こわい この問題は発生するか、発生しないかの2拓で
発生しないという話なら、報告はすべて捏造だって話になる。
アンチAMD工作員の仕業だっていう話になる 特にこのスレと関係は無いんだけど癌発生のメカニズ厶の話しても良い? ID:2g+dXCnh=ID:OB3x918x=ID:kXT/cQmn
完全に逃げたな
結局論破されて終了
>>344
tasだっけか?
こいつ本人だと思うよw
>>347
コテ付けて頑張れよ
情けないやつめ ID:2g+dXCnh=ID:OB3x918x=ID:kXT/cQmn=ID:FMAv0JSr
ほらもっと頑張れよ >>351
お前も買ったよな?w
ブーメラン、ブーメランwww
こいつ知能低いわw 威力業務妨害でぶち込まれるまで頑張れ
その方が世の為になるから
豚は豚箱へ >>356
えぇ、、、
この調子だとBIOSの設定からヤバそうですね 日常的にPC扱ってても自作しない人ならこんなもんだろう
電源品質やCPUクーラーの種類の重要性は理解してほしいとは思うくらい 自作しない人がlinuxを日常的に使う場面が想像出来ないです >>361
いや、この場合怖いのはメモリだよ
キッツキツだから
SPDが2400とかでDRx4でやろうものなら当然IMC仕様から逸脱したOC状態になる うえっぇぇぇl・・・
ソフト屋つってもこんなもんなのんか むしろLinuxユーザーって出来合いの低スペPCに入れて悦に入るイメージあるわ
あとはラズパイとか変わり種系 >>364
DR4枚で2400とかその時点でOCじゃん
DR4枚って1866までだろ公式サポート >>368
そうだよ
この人の構成がどんなもんか知らないけど、十分可能性はあると思う >>361
本人のページに簡単な構成書かれてるけど、いちおうSRx4ぽいよ
>Kingston KVR24N17S8/8 * 4 (8 * 4 = 32GB)、
動作クロックはわからないけど、
震源地のAMDフォーラムのスレッドで、他のエラー報告していた人がメモリ4枚動作時の定格クロックについて軽く触れてたから
流石に2133以下で動作させてると思うよ リテールクーラーは小さい方だろ
CPUも普通のサイズだし何言ってるのか理解できない まず2枚差しかシングルで試すものじゃね?
4枚差しって相性もきっついし 色々試したが改善しなくて
ちゃんとエビデンス取ってAMDサポに投げようと思った矢先に電源が焦げた
明日新しいの買ってくるつもりだが糞電源が原因だったとかいうオチであって欲しい / ヽ 'ーミ彡'"´///;;;;//シ;;;;;;ミミ、リ彡;;;;;ミ/
/ | ,,、-''"ィィ ""///'"/- 、;;;;;;;l;;;;}r''";;;;ヽ/ ああ・・・
| AMDなんて買うやつは | (////ノッッll||l|;| 淫 厨 ''ll彡;;;;;;;イ
| |,,,、-彡 ノノリ//从;;;;;;リリ u::::::::::::::゙'' 、;| AMDがダイッキライ
| ただのばかども L// ッッ ///;;ノ;;// u ー;
| ///彡ノノ/":::ミー、,ッu ノ ィ'"/::://;;;;| なだけや
L |/ッッイノ;;;/ィ'" <っ゙ヽ;ゝ" {Y'∠,, |||;;;;;/ヽ
〈 ノ彡彡ノ;;;/)-、""'''ミミ'''=.ィ'"彡;=,-、-、;;l|ll|ヽ
| /,、彡彡ィ' '/ ノ ,,-、ミ゙゙ ヽj::::::::`゙゙゙'ーヽ:ヽl|;;;;ll`'ー、
 ̄\ (/'""";ィ/ /'" イ:/ ゙/:〈、〈" ),<" `ヽ::::/;;;;;トlll |ノノヽ、__
゙'ー―-ァ- 、,,、-'" ̄`゙//////__/ ,'::ノ ィ´、」゙゙'::゙"ア U :::::::/;;;;;;ノll| \l
_ ,、-'彡 l | (;;;;;/イww/;;;;/ |''','"" ,'ィ´',/::(゙_'ー≦=ミ_ ..::::/;;;;//イ }} l| ヽ
`゙゙'''ー- 、,,"ー=ノシノノ从从l|l|」;;;;;;;;;;;j j. j :イノ j:::ィ''ヾ゙゙'''ー-ノ:::〉 ..:::/;;;;/" |、 lリ)
`゙゙''- 、,彡ノノ;;;;;;;レ ;;;;;;;;;;;;;j. ",イ, Y" 〈{イ}、_ `´⌒):::/ :::/;;;;;;;リ、l||| lヽ|
`'' 、;;ニニニl;;;;;;;;;イ( ( } j''ー- 、''ー--'::::,'u: /;;;;;;;;;/ノ/|"| >>371
いや危ないと思うぞ?
このメモリMicron製っぽいし、ほぼ最悪の選択と言って差し支えないだろう
よくまぁ動くもんだ
マイナー過ぎてSPDが見つからない ソフト屋でマシンメンテまで出来る人は稀、大抵はどちらかに偏るそうだ
あまりにもハードウェアに無頓着だったのでもしかしたらと思ったが案の定か… >>250
俺も1700XでXmedia recode3.3.5.8使ってるけど、
エラーする場合はOS再起動すると正常になるし、
エラーが発生する動画ソースはいつも同じなので、
DLLの初期化にミスってる可能性が高いよ。
もしくは、OSのプリフェッチやスーパーフェッチで読まれた
メインメモリ上のファイルキャッシュが壊れてる。 BTOかな?
Kingston KVR24N17S8/8 って基盤むき出しの1枚売りのものだね
キット物だとS8K2とかS8K4と表記するはず
Hyper Xじゃないのかあ Xmedia recodeって元から不安定やん
ソフトウェア板でもしょっちゅう動かなくなったとかエラー出るようになったとか書かれてる これか
ハードウェア
CPU: Ryzen 1800X
Motherboard: ASUS PRIME X370-PRO
BIOS: 1.0.0.4a(設定はデフォルト)
DIMM: Kingston KVR24N17S8/8 * 4 (8 * 4 = 32GB)
GPU: GeForce GTX 1060
ソフトウェア
OS: Ubuntu 16.04
kernel: 4.8.0-54-generic
gcc: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 WraithMaxならVRM冷却はたぶん問題なさそうだけども、BTOの電源は品質がちょっと心配だな
>>373
自作板ならまずそのあたりの検証についての反応が出てくるよなぁ >>383
とくにRyzenってメモリ相性がキツイというのは発売当初から言われてたことだし
まず2枚か1枚で再構成するのが基本なんだけどな 電源は使いまわしだけど紫蘇だから大丈夫って言ってたな >>384
何かあったっけ
調べてきたらAGESA1004aはBIOS0604
betaだけど1006あるねこの板 紫蘇だし200W以下だし大丈夫だよね?の人は別人だったと思う
そっちの人はM/Bやメモリも別のものに交換してたけど Ryzenとクーラーがでかく見えるということは
最後に中を見たのはAthlonXPの頃ではないか
今見るとPALは小さい >>387
発売直後からキャッシュやメモリ周りに不具合があると海外で報告あったからね
それのことと混同してるんじゃないかな?
初期に語られてた問題と今回の問題は根本的に違う >>387
BIOS機能Numa nodeのOS通知がBUGるとプロセスが同じメモリを操作するとき
別のキャッシュ跨ぐと同じメモリへのキャッシュ(L2とL3両方=排他なため)が2つ存在してしまう。
本来ならNuma状態のプロセス間のキャッシュ重複はOSが調停して問題はでない。
サーバー向けBIOSの移植ならいいが非サーバーマザーボードのBIOSをベースで
アップグレードした場合は考えられる。 434 : ,,・´∀`・,,)っ-○○○
2017/06/21(水) 15:38:32.47 ID:QDG///Vq
負荷がかかると命令ポインタのジャンプ先を間違えるバグ入りなんて半額でもいらない
857 : ,,・´∀`・,,)っ-○○○
2017/06/23(金) 00:10:38.59 ID:S/XEM49i
まあ、実際に4月からAMDが認知してないバグ報告で大炎上の火種が燻ってる事実は事実だしなあ
交換対応でなおった報告もないし、大規模リコールの可能性は否定できない
あくまで可能性だがなwwww
メシウマ案件だな
団G
恐ろしい子… 気付いたらubuntu17.04での4回目のビルドが終わってました
http://i.imgur.com/aPgZqmo.png
4戦4勝
ubuntu16.04はまだ動いてる 要はあれか
あまりにもハードの情報が無いのは隠してるんじゃなく・・・
解らないからなのか >>394
あいつって色々やらかしすぎて居場所がIntel次世代スレしかないらしいが・・・? 他のスレに現れると本人発言のコピペ張られる人の話はその辺で >>356
こんなレベルじゃたぶん自分の使ってるPCの構成を分かってないよな
細かいパーツの構成を尋ねられても本人自身がよく分かっていないから
自分の不甲斐なさにイライラして「揚げ足とりばかりならもういいです」ってキレてそう
PC好きならパーツの構成なんて自分から喜んで語り出すもんなwww
問題の切り分けするのも自作PCの醍醐味だし
下手したら自作PCですらない、BTOなんじゃないか?
ハードに関して門外漢なら身近なハードに詳しい人を頼って
ちょっとずつでも調査してほしいのにね AMD信者が必死過ぎ
欠陥があるのにダンマリで放置して公式に声明・回避策を発表しないAMDがいちばん悪い segfault出てる人で電源が怪しい環境だと、
AM4板スレの人が作ってくれた電源負荷変動テストでバッチ使用でOCCT等のテストしたらエラー出るんじゃないかなとは思う
http://egg.2ch.net/test/read.cgi/jisaku/1497012283/672 AMDもしくはMSが、Windowsではこのバグが発生しないと公式に発表するまでは、
Windowsでもバグが発表するという前提で考えるのは当たり前
このバグに関して公式発表あるまでは、
試験導入や人柱以外でRyzenや同じコアつかったCPUの導入を控えるのは当然である 特定の個人にしか問題が起こらないとか電源やメモリ不良とかいってるやつは、
特定の数人だけじゃなく、海外フォーラム見てもたくさんの人で同様の問題が起こってるのを無視してるな
これだけ多くの人で同様の問題が起こってるんだから、
Ryzenに問題があると推定するのが当然である Ryzen発売当時もWin10に致命的なバグがあるから
Ryzenのベンチマークがふるわないんだと2chやTwitter大騒ぎ
Microsoftバッシングはじめてた人がちょっとり多めにいて
賛同意見のおおさと当時はRyzenの情報集めてなくて無知で
Win10なら不具合あるかもなと自分も…
結局AMDが調査することになってWin10のバグではないと記事が書かれて
久しぶりに盛大に釣られたなと恥ずかしくなったからな
全て疑ってかからないとな 議論の一般的なルールと悪魔の証明
"「起きないこと」や「存在しないこと」を証明することは困難です。なぜなら、「ある(存在する、起きる)」ことを
証明するためには一例を挙げれば良いだけなのですが、「ない(存在しない、起きない)」ことを証明するためには、
世の中の森羅万象を調べ尽くさなければならず、それは不可能に近いからです。
ゆえに、議論の一般的ルールとして、「ある」と主張した者が、それを先に証明しなければならないという暗黙の了解があります。
「あなたが先に『ない』ことを証明せよ、さもなくば『ある』のだ」と主張する詭弁を「悪魔の証明」と呼びます。"
出典詭弁-△△でないという証拠がないから△△である(未知論証・悪魔の証明・立証責任の転嫁) >>404
それに対するAMDの回答が全定格に戻せとかメモリ変えてみろとか、要は安定性改善方向の提言だったらしい
変だなとは思ったけど、恐らくAMD社内の検証環境で全く起こらなかったんだと思う
内部の環境がどうかはわからないけど、前世代までがあのFXとか(言っちゃ悪いが)低性能のAPUだった事を鑑みれば業務用に相当数導入してる筈
そりゃそういう事しか言えんわ
BIOSにしても未だImproved Stabilityとかやってるくらいだしな
CPU側で有り得そうなのはSoCとかPLLの電圧不足とかか
こいつらはコアみたいに食わないから、ある程度余裕を持った電圧をLDOで下げるとかあの機構はついてないんじゃないだろうか
必然的に電源品質に対しシビアになるし、USB不具合に対するコンセント逆差しやアースみたいにちょっとした事でコロコロする
まぁEPYCのデモでもやってたように、本来はカーネルビルドくらいは通るんだろうぜ パフォーマンス問題とエラー問題は違うだろ
パフォーマンス問題なら、多少速度が出なくても計算結果は正しいが、
今回のは計算結果が変わってしまったり計算に失敗したりする EPYCの場合は、安定性重視でマージンを十分にとってある可能性もある
デスクトップ用Ryzenは、マージンを少なめにしてあるので、まれに足りなくなるとか >>411
有り得るな
結構XFRとかで回してるし、その原因の奴も居るかも
というか症状がバラバラなのってもしかしてそういう事か まあ個体差がありそうな気はする
もし品質管理に問題があって不良品ばらまいたというのが真相ならちゃんと交換対応して欲しいが >>414
それもあって詫び石の件が出て来たんだろう
とは言え適当に盛ってやればすぐ直りそう >>415
なんかいくつかレス見ててふと1700定格でlinpack回したらフリったわ 詫び石も難しいもので
・また出た→うちでは全く出ない石なんですがおたくの環境大丈夫ですかね
・今度は出ない→はい個体差でしたね おれもkernelコンパイルし始めた。
普通にmakeすればいいだけかね?
何かオプションつけるんかな?
環境はryzen1700+carbon+CMK32GX4M2B3000C15
メモリタイミングは16-16-16-36 2400で動作
CPUのOCは無し intelは
「そんな現象は発生しません」
で終わらせてたけど >>418
make -j 8にしてみた
おおー、早い早い このスレにAMDガーRyzenガーとか必死でねちねち文句つけてる奴が1匹いるよね >>418
特にオプションは必要ない
発現確率は環境によって違うかもだが俺の場合5%程度だったので
10回や20回の試行では見逃す可能性がある みんな電圧どれくらいにしてるんだろ
よく見たら1700でも電圧AUTOにしてると瞬間的に1.35vくらいまで上がる時がある >>422
そうなのね
http://jisakutech.com/archives/2017/06/35675
に
「Ryzen SEGV Battleにエントリーするときには、 make -j 16 ぐらいは指定しましょうね。」
と書いてあったので並列度16にしてみた。
早いし、とりあえずこれでやっておくわ。
ファンがフル回転しとるw すげーな
10分経たずにコンパイルおわた。
Kernelコンパイル10年ぶりくらいにやったけど、前は半日以上かかってた記憶がある・・・
1回目は異常なし。
とりあえず30回くらいはやってみるわ。 気付いたらubuntu16.04での1回目のビルドが終わってました
http://i.imgur.com/aa6ohJG.png
ubuntu16.04
1戦1勝
ubuntu17.04
4戦4勝
ubuntu16.04はまだ動いてる >>424
それはスピードを上げて試行回数を増やす程度の意味だと思われる
Twitterを引用するのに1次ソースと関係ないものを貼るゴミはさっさと死ね
1コアだけでも起こるという話もある >>427
貼ったあと気づいた
すまんな
もうこないわ、じゃーな
あとはおまえにまかせた このスレ荒れた原因の記事持ち出せばな
ある意味爆心地その2だし >>429
さっきこのスレ見たばかりだったんでな
知らんかった、すまんかった
一気にモチベーションなくなったのでやめるわ >>428
俺が悪かった
今更謝ってどうなるものでもないがごめんなさい >>430
しょうがないよryzenエラッタで検索引っかかるし
原因はっきりしてないのにああ書かれちゃAMDは怒っていいと思うわ 今はカーネルビルドに10分で済むのかよw
それなら失敗してもすぐ終わるじゃん
まぁエラッタあるなら直るほうがいいけど ソフト屋と自作erのトラブルへの対処(原因究明)の仕方が違って面白いわ
自作er的にはまずは最小構成試したり電圧盛ってみるところからだからなー 確かにソフト屋さんは自分のハードウェア構成には問題ないだろうという方向からのアプローチするけど
自作板住人はまずハードウェア構成に何らかの問題が含まれてるのであろうという前提でのアプローチするからな・・・ スレチかどうか判断つかないけど
同様の問題IntelCPU環境下では発生しないというのは、間違いないんかね
いままでなかったとはよく聞くが、本件を受けて同様に再現するか確認したって報告見えなくてさ 再現をしないって時点で
直観的にハードの方に目が行く >>437
わからんが、向こうでも意図的にどっかの値をカツカツにセットしたりすりゃ似たような現象は再現出来ると思う
割合から言えばやっぱPLLあたりかな? ubuntu16.04
2戦2勝
ubuntu17.04
4戦4勝
速度並列の数増やさんと無理か?これ >>420
-j オプションはスレッド数 +1 が良いとか >>439
まあここまで祭りになるとストレステストよろしくかなり試されるだろうから不具合も発生するはずだ
一方従来品で同等の試験してもやっぱり再現しないってなったらそれこそryzen固有のエラッタであると、確信をもてるよなあ >>443
ま、おいおい結論も出るさね
俺も自分のでやってみたくはあるけど、仮想環境しか用意できない上にあのSEGV_battleの動画みたいな実行はどうやってやるのやらわからん
使ってるVMの都合上フルスレッドは使えん故にかなり限定的且つやっぱFXは遅い(重要)
早く買わなきゃな、Ryzen
あと他で気掛りなのはLinux側のMSR周りかなぁ
何処かで温度読めないっての見た気がするんだけど、だとするとキチンとプロセッサ状態読めてるのかが不安だ 電圧見てハード的に調べるっていうけど内部のロジック回路それぞれの入出力線の電圧か少なくともパッケージの入出力ピンごとの電圧見れないと解析できないんじゃないの
もちろん参考情報にはなるけど外から見える電源電圧だけ見てても内部はブラックボックスだし
あと分岐予測なんかはCPU内部でソフトウェア的に処理してるから(今回の件とは関係ないかもしれないが)もうその辺りはお手上げ ubuntu16.04(最新)
4戦4勝
ubuntu17.04(最新)
4戦4勝
問題が起きそうな気がしないけど
誰か起きた人居る? つか、ファイルアクセスやんない処理の方が再現するんでないの?
なんか複雑なベンチとか回してみれば 50回やって出たところで何か問題があるのか?
って感じが否めないけど 自作erの場合
ソフトの分野はともかくとして
ハード的には問題ない状態で動かしていると思うので
そこで異常を発見できた人がいるのかっていう ubuntuで耐久テストばりに負荷かけて暗号通貨掘ってるがCPUでエラーとか出ないな AMDの評価をすり抜けたエラッタだから、単純に負荷をかけただけで発生するとは思えないけど AMDが事前に知ってて隠してるって可能性も当然あるだろうけど いつもエラーを吐いて落ちてくれるなら良いけど、例えば足し算を実行したつもりが
その64バイト手前の引き算を実行していた、みたいに間違った計算をしてもそれが
分からない方が怖いよ
発生トリガーが明確じゃないからどんな可能性もあり得る >>424だが昨日はすまんかった
>>431は別に謝ることはないよ
次から気をつけるよ
一晩ねたらやる気でてきたので、またコンパイル始めた
とりあえず10回やったが再現なし
kernelは4.11.6をコンパイルしてる
環境はosがubuntu16.04LTS
ハードは、ryzen1700+carbon+CMK32GX4M2B3000C15
メモリタイミングは16-16-16-36 2400で動作
CPUのOCは無し >>457
なんか昔のインテルのCPUにそんなのあったな ubuntu16.04(最新)
5戦5勝
ubuntu17.04(最新)
4戦4勝
こりゃおま環レベルだろ 1回ずつ報告しなくていいから
50回やったらでいい 同じ処理をしても再現しないということから、メモリとの相性だろうなぁ。
プログラムが走っていて次の処理をしようとしてメモリにデータ取りに行くんだけど
何かのタイミングでメモリからデータが取れなかったときに、
本来使うべきではないキャッシュにある64Byteを間違えて使っちゃうんじゃないの?
キャッシュにあるのは直前に実行していた64Byteという感じで。 並列処理も
結果表示の順番が毎回違うんで
各々のコアが勝手にコンパイルしてるような感じだが
そこもランダムと言えばランダムのような気がするわ
何かその組み合わせ的な問題で発生してるんだろうか >>462
それをメモリとの相性というのか?
おれの感覚だとキャッシュ関連のエラッタと言った方が適切と思うが あと、インストラクションキャッシュの中身を「データ」と呼んだら団子に絡まれるから注意
インストラクションとデータの区別も出来ない
とか言い出すから >>464
感覚というか記事読んだ感想の間違いでわ
キャッシュミスなら再現度もっと高そうだしOS環境で発生率バラバラなのおかしいわ >>462についてだけど
メモリの相性と言っておきながらその説明がキャッシュのエラッタ >>467
64バイト以外にもエラーは発生してるからね64バイトズレのパターンかあるというだけ 64バイトずれたら何が起こるかわからないから、現象として異なるように見えるってのは当然あるだろう
本当に複数の問題を抱えてる可能性もあるけど >>461
そんなにやらんわ
ハードが安定してれば問題が発生しそうにない気がする
発生するとすれば
コンパイルの順番が毎回違うので
一定ではないパターンがそこに存在してるんで
その組み合わせで起きてるかとそんなんじゃないのか
後はハードの構成とか、、、この構成だとダメとか >>366
これ64バイトのブログだから全部読んでから考察しろよ
揚げ足を取るような糞考察に価値はない これ読んだらキャッシュのエラッタと思うでしょ普通は
メモリの相性とかジャンプ先のアドレス計算を間違うとかには見えない キャッシュのエラッタならもっと簡単に再現できそうだけどな 簡単に再現出来るならとっくにAMDがハッケンシテ修正してるよ 希な状況で発生するから検証をすり抜けて出荷されたわけで AMDは数ヶ月間再現できない事象と考えたほうがいいわ
何故再現出来ないのかから答え導いた方が速い
そうするとCPU単体というよりは外的要因のほうが可能性高い B2ステッピングでこっそり修正かもしれんがリーク記事だとコア部分の修正しないみたいだし
キャッシュが原因なら鯖分野で大参事になるかもな あ、ちなみに私今まで3個エラッタを発見してます
PCではないですが
1個はそのせいでバグを入れたまま製品出荷してしまって、メーカーと代理店が謝りに来ましたよ
損害賠償請求まではしませんでしたが
そういう報告をするときには、きっちり問題点を絞って、問題が発生する最小形にして報告します その問題に特化した負荷テストを数週間続けてやっと1回発生するくらいの頻度の問題でした >>481
いつも使ってるchromeやEdgeが動作停止する回数より相当少ないな PCじゃないんで
もうちょっと規模の小さな組み込み用CPU >>483
クロームが落ちたこと無いんだけど。
少なくともここ2ヶ月はずっと起動しっぱ。
RYZEN 1700Xにメモリ64GBだけどね。 >>485
intel、AMD関係なくブラウザは落ちるね
ノートはintelだがバコバコ落ちてる ブラウザはコンテンツや通信の問題があるんで
悪意のあるコンテンツとか >>485
落ちるというより
動作が停止して信頼性履歴の表示に
「動作が停止しました」って出るんだよね そもそもLinuxのカーネルコンパイルとか
そんなやらないからな
普通はwindowsみたいにアップグレードして終わりだろ >>424
アフィテックのところも随分伸びてるねえ
騒げば騒ぐ程カネになるんだねえ ゲハと同じ構造なら企業がスポンサーについてるかつく見込みがある もうすぐカレシと出かけるから
寂しいとは思うけど
バイバイ 高負荷なときに、CPUの回路の一部が電圧もしくは電流が不足して動作不良、
それが原因でバグが起こるとかだったりして
たまたまマージンが少ないRyzen CPUがそうなるとか
マージンは個体ごとにばらばらなので、あたり石と外れ石があるとかね
LinuxでALSRをオンにしてると、電源不足が起こる確率が上がるとか
本来のロジックそののもじゃなく、低消費電力制御の失敗みたいな >>497
コイツのいうことに関しては信用出来そうにないな
まともに取り合わないほうがよさそう
ほかの検証してる人に望みを託そう そもそもLinux開発陣がこの問題スルーするわけないんだけど何かコメントでもしてるの? >>497
CPU交換したあとCMOSクリアしてないパターンじゃね 最初に問題提起したのはsatだけど実行されてる場所が0x40ズレてるって言い出したのはeirakuなんだからそっちもヲチしたら?
http://www.e-hdk.com/diary/d201706c.html
http://twitter.com/hdk_2 gcc 自体はryzen環境でリビルドしたものを使ってるのかしら? >>508
6/8と6/10の記事に構成が書いてあるな
う〜ん 取り合えず
ある程度ハード構成に詳しくて自信のある
自作erが異常出してくれないと話しにならない
ubuntu16.04 6回
ubuntu17.04 4回
計10回コンパイルしたけど出なかった
誰か異常出してくれ
自分は出かける 中古の動物電源とかありえんわー
地雷の自乗じゃないですか >>511
あっ…
真面目に取り合って無駄骨だった様だな ソフト屋って糞だな
糞な環境でも安定するIntelが素晴らしいのか? Ryzenがいろいろとマージン狭いのは確かだ
B2で多少良くなるだろうか memtest86で通ればメモリ相性も問題ないと思ってる節があるんだよな
紫蘇電源使いまわしてる人のmemtestバージョン古すぎるしなんだかなあ C6/C7ステートで糞電源は駆逐されたものとばかり思っていたのに 電源やメモリのせいで64バイトずれるとか
頭おかしい人の集まりか?ここは (´・ω・`)ただでさえVRMあっちっち仕様なのに
糞原電使ってたらそりゃ安定しませんわ >>520
64バイト以外も発生するぞ
ソース元のブログ見たか? 恵安古いお遊びPCでそれなり長く使ってるけど
「は?」って言いたくなる意味分かんないとこで死んだりするし
いろいろ把握しないとメインで使うのは怖いな >>519
ホワイトボックスサーバ導入してるところは、慶安のをつかってるところもあるのでは? SEGVハグ発生したら必ず64バイトズレると勘違いしてるやつ結構いるんだな
ソース元のブログ読まないとかねぇ 色々エラーが起きてるうちの64バイトズレの奴が再現性が高そうだって話じゃないのこれって 取り敢えずまともな環境でやってる人のじゃないと参考になりませんわ 糞原電が問題だとすると、winで起こらないのがわからないですね satってやつCPU刺し直したみたいだがグリス塗りなおしてんだろうな・・・ >>527
ryzenはエラッタ自体いくつもあるから間違ってないね
修正のためにB2ステッピングだし メモリSR4枚2400MHzで動かしてたけど、一応仕様通り2133MHzに変えといたわ
ほとんど大丈夫だと思うけどサイレントエラーはさすがに困るからな〜 B2はあのキッツキツIMCとかの修正でコア部に手は入らんぞ
まぁ普通の自作erだったらこんなエラーが乱発したらストレステスト掛けまくるな
Primeで調整すれば各階層毎に切り分けてテスト出来るし >>531
もしも塗り直してなくて熱で再起動多発だったら俺のち○げうpするぜ! Windowsで問題が出ない理由は、そもそも今Ryzen使ってる人は自作erだから
使い始める前にOCCTやPrime回してハードの問題解決してから使い始めるから
問題出てないのだと思う訳で。 Intelと違ってRyzenはグラボ必須だからなぁ
12V系統が貧弱な電源でグラボ載せればどうなるかは予想がつく Windowsでハードに問題あるとブルスクなったり再起動かかったりするじゃん。
それがLinuxだと現象としてセグメントフォルトだったり、その他の形で出てるのでは
ないの?と思う。 電源が安定してないと変なことが起きる、って感じか?
本来はハングするべきなんだろうけど、変に動いちゃってるのが問題なんじゃね? 電源のせいで64バイトずれるとかまだ言ってるのか
知能レベルがよく分かるスレだな 電源が糞=システム全体の電力供給が不安定=システムが不安定
メモリ4枚刺しは相性の関係があるから1枚か2枚で再試行
だから環境を晒すのは原因の切り分けをするという意味で重要ですなぁ 64バイトずれる
で意味はわかるだろ
HOTな問題なんだから 結論としてはキチンと組みましょうとしか言えんわな
AMDの対応にしてみてもヤケに淡白なのは不自然だが、こういう事なら納得は行く
そういうのが居るからB2ステップでIMCとかもうちょっと余裕持たせていわゆる「noob向け」にしましょうと
エラッタエラッタ言われるからこのデリケート仕様をアンコアのエラッタって事にしてあげようって皮肉含めた提案かもな >>552
今回の問題とは関係ないと言い切れる根拠は? 糞電源はありとあらゆる怪現象起こすから検証の場で持ち出してはいけない
常用に耐えなくなったら中古に流すという流れがあるから更に怖い
店側もそんなジャンクまがいのものに長期の安定性テストとかするわけがない 多少知識や技術がある人に
「電源の問題じゃね?」
なんて言ったら間違いなくバカにされるから 常識的には中古部品とかブルーピーコックだろう
先ずは信頼できる新品で組んでみるべし
確かパーツ選びのテンプレというかコピペ有ったよな、あんな感じ SEGV問題がありとあらゆる怪現象に結び付く
の方は正しいと思うけど 仮に電源の能力不足でおかしくなるなら、
中途半端におかしくなったまま処理を続行するのではなく、
フリーズもしくはカーネルパニック・BSODを出さないといけない
中途半端におかしくなったまま処理を続行っていう、いちばんやってはいけないことをやってしまってる 信頼性の無い環境下で行った検証には価値が無い
原因の切り分けが出来ずに混乱するだけだから >>561が何を言おうが切り分けは時間の問題だろうから >>557
有るよ
というかその辺の専門
何故かおかしな動きをする古いFAとか、テスターで片端から当たっても正常、外観も問題無く一見わからない
でもオシロで見ると、スパイクやノイズがダバダバ漏れてたり 電源は関係ない( ー`дー´)キリッ
とか言ってて恥ずかしくないの?
自分はにわかですって自己紹介してるようなもんだぞ ネガキャンが仕事なんだろ
ゲハにも良くいる結論ありきで他人の話聞く気がない奴はモノホンのキチガイかお仕事 根拠は感覚で真面目にレスする気が失せたわ
まさかここまで話にならないとは 30回コンパイルしたが、今のところ異常なし
並列度も8 〜17までやってみたが問題なし
50回目にまた報告する 最近の電源はLinuxのカーネルビルドだけ攻撃出来るリップルを吐くと?
なかなか面白いね
学会で発表できるよ >>571
鸚鵡返しは敗北宣言だぞ
そもそもお前が電源が関係無いと言い切ったから根拠を聞いたんだ 中古の動物電源が原因の可能性高いなと言ってる訳だけど?
新品の電源使ってもう一度やり直せとしか言えない 先に電源の責任にしようとしたのは誰でしたっけ?
根拠なく 発見者がCPU差し直したらバグの頻度変わったと発言しだしたのがだいたい悪い 電源の可能性が高い
は根拠なく信じて
キャッシュのエラッタの可能性が高い
は信じない
変な人たち 発生率は環境要因が大きいが発生した際の挙動は良くないといったところか >>577
じゃあもうこなくていいよ はなすだけ無駄だし >>569
・linux以外でも発生してる
・64Bだけじゃ無い
・環境は不明
・再現性が十分じゃない
そうなったら電源疑うのは普通の感覚だと思うけど、まあ一般から外れた感覚の持ち主なんだね レス古事記かソースロンダリングの為のお仕事やってる奴の相手真面目にする必要ないよ 海外の人の報告のほうは電源は書いてあるね。SeasonicとかCorsairとか 電源はPCの心臓部で血液だしな
あそこ劣化したら真面目にヤバい >>581
ちょっと前にLinuxでしか発生しないとか主張してなかった?
そんな何が起こるかわからない地雷CPUなんか使えないね >>581
あいつじゃないけどlinux以外で発生してるソースよろ せっかくだからビルド結果のmd5も統計取ってみよう(自分ではやらない) とりあえず切り分けの一つとして電源変えて試してみてよって感じなんだけどな
可能性一個一個つぶしていかないと答えでないよこんなの >>588
多分結構ミスってると思う
普通に考えりゃHWエラッタやSW要因で確率がここまで離散するワケはないんだがな >>589
キャッシュエラッタにしては頻度バラバラなのがなぁ
じゃあなんだよって話であるが CPUの電圧制御が厳しいから電源で左右されやすいとかかなぁ >>593
コア及び付随キャッシュ以外はLDO付いてないからなぁ
GND揺れたりしたら一発だろ
いっそ発生する環境が有ればなぁ >>587
>>589
おれもスクリプトで回すようにした
とりあえず100回ずつ回す
一回のコンパイルは9分30秒くらい >>595
HDDやSSDに書くとアレだからRAMDISKおっ立ててやるらしい AMDがお詫び石条件にメモリと電源教えろって支持出してるんだから
無駄な公論する前に素直にそっちも疑わないと会話が前進しない 巷で出回ってるRyzen SEGV battleのスクリプト、bzImageのサイズとMD5ハッシュも同時に出力したほうがいいとおもう
gccがSEGVはしてないが、bzImageがおかしくなるっていう条件でも抽出できるように linux on ryzen がこなれて来るのはいつ頃になるんだろうなぁ
仮装鯖組んで見たいと思ってギガのマザー狙ってるんだが
intelの爆熱CPUなんてもう買いたくないし まあ動物電源てなった時点で、それが容疑者になるのは仕方がないね >>599
おけ!
ハッシュもチェックして、初期登録のものと異なってたらNGなるようにする >>511
ちょっと違うみたいだが、Bullと大差ないなこれ
>現在の構成:
>電源装置: 玄人志向 KRPW-L4-400W [¥2,008]
>HDD: Seagate Barracuda 7200.8 ST3250823AS [¥0]
>マザーボード: ASUS PRIME B350M-A [今回購入: 9,913円(税込)]
>CPU: AMD Ryzen 7 1700 BOX (AM4/3.0/20M/C8/T16/65W) [今回購入: 37,740円(税込)]
>メモリー: G.SKILL F4-2400C16D-16GFX (DDR4 PC4-19200 8GB 2枚組) [今回購入: 14,480円(税込)] (CPU とのセット購入で 500 円引き価格)
>ビデオカード: 玄人志向 GF-GT710-E1GB/LP (GeForce GT710 1GB LP) [今回購入: 3,218円(税込)]
まって・・・ちょっとまって・・・こんな環境でエラー再現テストって言ってたの・・・ >>603
6/10にハードオフでBULL買ったって書いてある どんな構成でも
耐久ソフト安定して通れば問題ないわけだが 電源って80+プラチナ以上なら検証になる?
やっぱり鯖用の新品使った方がいいかな? >>606
鯖運用ならそのほうが良いと思う
普通運用なら電源スレで少し調べて良いの買えばいいよ 中古電源はどこまで酷使してるかわからんからなぁ
特に動物電源とか怖すぎる >>608
SEGV検証するのに今手持ちこのしょぼいのしかないんだよねw
これで起きたとか言ったらCDNの専門家のA氏みたいに大恥かきそうじゃん?
http://www.super-flower.com.tw/products_detail.php?class=2&sn=16&ID=94&lang= >>610
OCCTとPrime95と負荷変動テスト通れば問題はないよ >>610
いや、検証自体のみなら何かあったら電圧上げたりタイミング緩めたりマージン取れば大丈夫だろう
要はSWと機能を触らずに起きない条件まで引き摺り上げることができるかだ、まぁ多分最新BIOSでキチンとデフォルトロードさせたら電源周りはクソ電源でない限り大丈夫だと思うけど
あとメモリも現在値で決め打ちしておいた方が良いかもしれない、IMCカツカツ過ぎだから予防策に
あとアース取っておいた方がいいぞ
運用するときは流石に鯖用に何か拵えた方がいいとは思うけど 再現性ないんだし
ハード構成に問題ありだとした場合
耐久テスト終わらせている人なら
それより負荷の少ないコンパイル
を何度やっても安定しているわけで
何度繰り返してもその構成では問題
はでてこないはず 買った時期で起きるかな?
そもそも問題起きている人このスレにいるの? 大丈夫
ハード構成に自信がないなら
クロック落とせばいいんだから
クロック半分まで下げれば
どんなにシバイテも
痛くも痒くもない 問題が起きてる人たちって、同じマシンにWin入れてOCCTとかPrime95とか動かしてるの? >>613
俺もそうは思うけど念の為だ
ストレステストの多くはストレス目的に特定の処理に特化してる
多種多様な命令を放り込むコンパイルはエラッタの洗い出しに主眼を置けば適しているとは思う
まぁ設定ミスとか変なコードでエラー吐く可能性が無いかといえばそうでも無いってのが難しいところだが hdk氏にまともな電源を送ることで、発生事象が変化したりして。 まるごと落ちるとか
ブラックアウトするとか
クソ電源が原因ならそこら変だろ
64バイトズレるってのは電源が原因ではないような >>619
絶対64バイトならその通り
勘違いしてるのは64バイトの再現率が高そうなだけでエラー内容はバラバラ >>619
糞電源は電圧が不安定になるから全てに悪影響及ぼすで k10stat使ってる頃低電圧化やりすぎるとデータ壊れるぞって言われたな >>619
RyzenはCPU側で15,000通り以上のステップで電圧調整(しかもリアルタイムで)してるから
電源が原因の可能性は微粒子よりは大きい >>622
実際壊れる
ので安定確認した値から2-3段階くらいマージン見て常用するよろし >>599
カーネルコンパイル後のソースツリーのrootにできるvmlinuxの
ハッシュ値チェックしてるんだけど、ハッシュ値が毎回異なる・・・
こーゆーもんなのか?
これじゃハッシュ値のチェックできないな
もしくはハッシュをとるファイル間違ってる? VSだと製作日時のデータの違いで同じハッシュにはならなかった気がする >>625
twの方でビルドした日付が入ってるからハッシュ値は一致しない、って話が出てたね。 たとえばuname-a とかで出てくる情報にカーネルビルド日付が入ってるから、その辺から追えば
適当に固定値いれたりする場所わかるんじゃないかしら。 詳しく無いからよくわからんがmake終わった後のCRCもダメ(当たり前)
こりゃもう容量くらいかな >>627
なるほどね
ハッシュ値のチェックは意味ないしやめるわ
とりあえず、スクリプトで延々回してみる テストするならkernelよりmesaの方が良いよ
https://pkg-xorg.alioth.debian.org/howto/build-mesa.html
./configureは./configure --with-gallium-drivers=r600 とかで >>624
なもんで電圧が十分でなければRyzenでもおかしな挙動が起きてもおかしくないのかなと
加えてメモリ相性がきつくキャッシュが直接の原因だとは断定できないのでは
B2はメモコンも手入れるらしいのでその辺りの解消を狙ったものだと思われる
AMDコミュニティでも電圧上げろ言われたらしいし
とりあえずLinpackでも回してもらいたいね
Wineで動くかな? linpackはネイティブなものがいろいろあるだろうからWineのテストをしたいのでなければあえてWin用のものを使わなくても、とかね。 Linux 及び NetBSD に
出てるから ryzen が犯人だよね Ryzenが正常動作してるかどうかという意味では犯人だろうが
ただそういう動作になった原因はまだまだ不明なわけだ Windowsでは問題出てないようだしlinuxが悪いでしょ
ryzenに最適化してないlinuxが悪い そもそもRYZEN(システム)の対応OSにLinuxは?みたいな。
なのでSEGV Battleの本番はマザボメーカーの対応OSリストにLinuxが入ってるEPYCが本番
なんてナ。 >>632
# apt-get build-dep mesa
パッケージリストを読み込んでいます... 完了
E: sources.list に 'ソース' URI を指定する必要があります
で断念。
調べるのめんどいのでとりあえずkernelでやっとく >>641
16パラレルでやってるけどダメなんか?
なんで?
50回はやったけど、今んとこ問題なし 自作のスクリプト使って、kernelビルドしてるけど、どこかにみんな使ってるスクリプトある?
探したけど見つからんかった… >>515
それはそうだろうw
ハードいじりに金と時間とられたくないだろうし >>640
sudo add-apt-repository universe
するか/etc/aptのsource.listでsrcの行コメ外して
sudo apt-get updateする
それからやってみるといい twitterで#Ryzen_SEGV_Battle +
vcore
コア電圧
vsoc
soc電圧
LLC
load line calibration
で検索したら全くヒットせず
(socは1人だけいたがそういう噂を聞いて試したというレベル、ちなみにどの位上げたか不明でダメだったそうだ)
Ryzenの電源周りの設計をある程度でも理解している人はまずいない模様
大原の記事だけど、せめてここに書いてある電源周りの話位は知ってればvcoreやllcの話位出てきそうなものだが...
http://s.news.mynavi.jp/articles/2017/03/02/ryzen/001.html 各個人のマシンで起きた問題を混ぜて扱うのはよくない
本当にエラッタか何かの人と、単にハード構成が悪い人が居て混ざったら混乱するだけだ そりゃまあその辺の設定をを変えて改善したケースがなければ情報もあまり出てこないだろ
俺も色々やったけどエラー頻度が変わった感じはしないわ >>650
twitter民ならvcore上げ・LLCレベル1等試してダメならダメとツイートしそうだなと
実際試して変わった感じがないという情報がここに出てきたのでいいけど >>650
電圧固定したりブースト切っても同じ感じ? 64バイト発見者の6月分のブログ読んでたけど6月8日の記事見てヒェーってなったよ
これすでに環境壊れてるだろ >>652
そだね、あとはCPUとメモリのクロックを落としたりしたけど変わらず
パーツ系は電源3種類とメモリ2種類試したがダメ
マザーボードかCPUのどっちかだとは思うんだがちょっとお手上げ
石交換勢の様子を見て対応決めようかと思っている >>655
環境教えて貰えせんか?
試したメモリと電源も >>655
電圧電源メモリー変えてみて結果同じならryzenの中身エラッタかなぁ
キャッシュエラッタなら石交換でも頻度変わらなそうだけど
Linuxバージョンと何コンパイルしてるか教えてくれると嬉しいな
OS側の設定揃えて発生頻度が同じなら結論に近づくだろう >>653
sat氏の接触不良云々が、微かに頭をよぎるね >>653
http://www.e-hdk.com/diary/d201706a.html#08
・組立中にスッポン
・マザー電源コネクタ半差しで起動→起動せず→電源ユニットに通電したまま?コネクタ差し込み起動させる
・さらにメモリも半差し(さすがに電源は切って差し直したが)
・ATX12V 8ピン専用なのに4ピンだけ接続して起動
どこからつっこめばいいんだ? なんて検証してる個人を攻撃してんだよ
不満があるなら自分で検証しろよ >>659
Mini-ITX ケース電源流用してしかも負荷テストしてるところも糞
案の定PC止まってるし まともな環境じゃないからに決まってんだろ
USB3.0のおま環と同じレベル 不満どうこうじゃなくて馬鹿にされてるだけなんだよなあ メーカーサイドが問題無いって言ってるのは構成がちゃんとしてるから? >>660
攻撃のつもりは無いけど、>>508と併せて読んだり
AMDの侘び石対応のみってのも考慮すると、もしかして?と思ってしまう。
AM4はピン数増えてるみたいだけど、デリケートな感じなんだろか。 ブログのryzen検証内容自体は素晴らしいが前提が崩壊してるもん
壊れていてもおかしくない環境の検証が拡散されたなら不満は出るわ ここまで酷いと既に不良品に陥ってるだろうからエラー出ても何も不思議ではない 検証結果に不満があるんじゃなくて
前提環境に不具合があるだけ Ryzen 7 1700 + AB350M pro4 (BIOS v2.50)
Ubuntu 17.04(4.12.0-041200rc5)
メモリ
・CMK32GX4M2A2666C16
・CMU32GX4M2C3200C16
電源
・Corsair SF450
・DELTA 400AB-8
・5000円のケースに付いてたSFX電源(捨てたので型番不明)
正直機材は微妙なのだが手持ちの範囲内の限界ということで
替えても症状が悪化も改善もしないので多分関係無いだろう、とは思うのだけど >>659
組み立て中にスッポンと4ピンだけってのがな あ、自分でも検証してるのね
文句言うだけのクズかと思ってました
大変失礼しました >>677
ありがとうございます
やっぱりエラー自体は起こるんですね やっと土俵が揃ったか
こっからだね
ストレステストは通るの? まともな前提条件出たらから発生率5%目指してやるしかないでしょ
白黒さっさとつけたいし さんざんバカにしてるヤツより解析能力が無いなんてことはないよなまさか >>659
これイチャモンつけるためにわざと無茶組みしてるだろ 順序的にはこんな感じ?
電圧上げ(vcore/vmem/soc/llc)
メモリクロック下げ(SR/DRそれぞれの定格へ/タイミングも併せて?)
CPUクロック固定(cステート/ブースト等無効化)
メモリ枚数減らす
BIOSバージョン変えてみる
電源変えてみる
最終手段でマザーやCPU交換
あとはmicronチップのメモリは相性良くないから注意ってとこかね >>688
同じOSと同じコンパイラ環境でバグ発生頻度がどのマシンでも同じだけ発生するならAMD環境でも同じ頻度で起きる
ダンマリならつまりそういうことなのでAMD叩けばいい >>690
BIOSまでは一連の作業だな
うちのブルスク出まくってたi5は電圧盛ってクロック落としたら安定した segvの検証しようと1500X+taichiにubuntu入れてたらアップデート後の再起動中に突然電源が切れてPOSTすらしなくなってしまったw
CMOSクリアもダメ
電源を交換してもダメ
グラボ、メモリ1枚、CPUクーラーだけにしてもダメ
多分taichiが死んだ
segvどころじゃなくなったわw
コイン電池外して一晩置いて、ダメなら修理だな
ものすごくガッカリ
酒飲んで寝るわ 凄惨な状況だな
Fam17hのPPR眺めてても詳しく無いのでよくわからん
MSRにIPとか臭い項目あったけど関係は無いだろう多分 64バイト発見人の解析は凄いなぁと思ってたのにブログ読み進めてたらこりゃダメだと
ある意味ショックだよ落胆のほうが大きい >>695
以前持ってた特定のネジ絞めると調子が悪くなるマザボを思い出した バラックでダンボール箱の上で動かしてるからそれはない 今までRyzenだけでもtaichi以外に2枚、他のCPUのマザーも6枚位テストベッドとして使ってきた箱だから考えにくい 1600で再現実験して20回とも発生せず
SEGVとはなんだったのか まず何で飛んだかだなぁ
しかしこうなってくると入れた途端ってのが変に引っかかるなw 尼の薄いダンボール箱だけどな
丁度ATXサイズなんだわ
今までここで数ヶ月テストしつつ環境作ってからケースに入れて使ってた
ファンはCPUクーラー以外に4-5個は使ってVRMやらサウスブリッジやら冷やすようにしてた
今回はさらにメモリも冷やしてた位だった
taichiは今月上旬に買って順調に動いてたんだが、突然死した感じ
テストベッドだからテストNGってことになるが、何も初期不良交換期間が過ぎたこのタイミングで起きなくてもと思う
Ubuntu入れた後に死んだのはたまたまだろう >>704
6コア4コアモデルの事例は見ない気がするから結構貴重かもな
俺はそう思ったのと丁度4コアモデル持ってたからこれでやろうと思ってたんだが
その矢先にこれだよw 電圧がダメな人はUPSとかどうだろ?
俺は使ったことないけど、サージとか瞬断とかもオッケーらしい ちなみにうちの話だけど、室内ファンが止まる瞬間にPCの画面が一瞬暗くなる(ラデrx460)
ゲフォの1060に変えたら発生しなくなった。
こんなこともあるので、電圧は常に一定ではないんだよね あちゃー、SEGV発生してもうた。
http://i.imgur.com/qHMH3e1.png
確率は4/37
使ったスクリプトはこんなん(適当に自作)
並列度16でlinux-4.11.6を延々ビルド。
#!/bin/sh
COUNT=0
while :
do
COUNT=$(( COUNT + 1 ))
make -j 16 2>>/root/log.txt
if [ "$?" -eq 0 ]
then
echo "${COUNT}: $(date): OK" >>/root/log.txt
else
echo "${COUNT}: $(date): NG" >>/root/log.txt
fi
make clean
done
環境はこれ
マザー:MSI X370 Carbon
CPU:Ryzen1700
メモリ:Corsair CMK32GX4M2B3000C15(DR16Gx2)
※1.35V 16-16-16-36 2400MHz
SSD:960EVO
Video:MSI 1060(6G)
電源;Corsair RM550x 80PLUS GOLD
OS:ubuntu16.04
ちょいとメモリの周波数落として再チャレンジしてみるわ。 エラー出す環境で
メモリ32Gが多いな
ほぼ全員そうじゃないか ごめん
今確認したがファンじゃなくて冷蔵庫の始動だったわ
そして1060でも発生した >>713
そういえばそういうの海外のフォールム多分reddit辺りで見たな
探してるけど見つからんが >>714
それはディスプレイのバックライトではなくて? >>717
これは単なるMakefileの書き方の不具合で100%再現するやつでしょ
Ryzenのは時々しか再現しないので厄介
メモリクロック1833にして再テスト始めてみた make -j〇〇
付けて失敗するパターンは昔からあるな
ただ16って大きい数値を入れてるから目立ってるだけじゃないか -j4を付けないで実行してくださいって返答してるってことは
多分-j〇付けて失敗して消去して成功した経験がありそうだな >>714
電圧安定しないとこは、インバータ方式のUPSいれるといいよ。
前住んでたとこがそうだった。
東京電力に文句いったら、電柱についてる変圧器?みたいなのが古いので、どうしようもないと。
交換するには、周囲の家も一時停電させないといけないって。
面倒なので、インバータ方式のups買って凌いだ >>722
念のため最低ラインまで落とした
メモリタイミングの調整は結構苦労したので、少しトラウマ、、 make -j〇〇
については昔からトラブってるな >>709
安い常時商用給電方式はダメだよ
電圧不安定なとこであんま意味ない。
少し高価だけどインバータ方式にしとけ >>712
メモリに関しては下記gentooフォーラムのc1pherx氏が8x4から8x2にしたらsegv無くなったよって書いてるわ
多分715で俺が見たのこれだわすまそ
https://forums.gentoo.org/viewtopic-t-1061546.html make -j〇〇
Linuxユーザー的に推奨されてない臭いんで
時間がかかるけどmakeだけでやってみれば?
これintelでも出るんじゃないか? >>725
パラレルmakeは、Makefileの作りがパラレルに対応してないと、オブジェクト間の依存関係が前後してしまうんじゃないかな
kernelのビルドはパラレルに対応してないと時間かかるし開発者が不便だと思うので、当然対応していると思いたい。
1833で動かしてだめなら、パラレルなしでやってみるわ GNU makeで並列コンパイル
http://www.toyoshima-house.net/classic/beos/tips_make.html
ファイル間の依存関係がきちんと記述されていないと並列makeは失敗することもあるそうです。 ASLRでランダムに割ると速度の違いで順番おかしくなる事があるとか?
ならmakeのみをスレッド分並列させてみるとかどうかな 書き忘れ
今Ubuntu17.04をインスコ中
対照としてFX機でぶん回そう 日本のLinuxなんて鳥入れて五分位UIいじって終わりってやつが大半だからな メモリがHynixだと1.43V盛ってサブタイミング緩めてProcODT設定して、PLL2.0ぐらいにしないとVSでLLVMコンパイルしただけでエラー吐くことあったな
サムスンBダイならそこまで面倒なことにはならないんだけど
8C16T負荷かかった時にメモリ回りに問題あるとコンパイラ内部エラーになる
OCCTとか負荷テスト通ってても余裕でエラーになるから困る、Linpackもテストにならんし
どうしてもダメならメモリ1枚差しかCCX2無効にしてメモリへの負荷を減らすしかない やっぱメモリキッツキツやな
ProcODTとPLLが必要って事はIMCが原因?、メモリそのものというよりIMC内部の触れないパラメータが何かやってそう
BKDGが有ると多少マシだけど、17h用は転がって無いんだよね わしFX-8150上にXubuntu走らせて週一くらいでカーネルコンパイルしているけど
昔からこんなエラーしょっちゅう出てたぞ
でも再度コンパイルさせれば何もなかったように通るので「FXの気まぐれなんだろう」
くらいの気持ちでスルーしていた笑
まあ確かに言われてみればカーネルの並列ビルドの時くらいにしかお目にかかったことがない
エラーであることは確かだわな まぁ確かにwinで同じ現象が起こったら即落ちものだもんなぁ、、、
WSLは結局中身Ubuntuだからアレとして
もう全然わからんな
RAMDISKが足りなくて止まった
俺noob過ぎだわ Linuxだから騒いでるけど
WindowsだったらOCCTとPrime95で即座におま環判定事案じゃないの、これ。 鯖で使うのに適さない言うなら、
ECCメモリ差して検証してどうぞ。 >>730
1833でもエラーになった
次はパラレルなしでやってみる
>>744
OCCT24時間たえたマシンにubuntu入れて試してる。
結構な確率でSEGVになるな
パラレルコンパイルが悪いのかもしれんけど。
今パラレルなしで再開させた。
結果でたらまた書き込むわ Fatal1ty X370 Gaming K4にECCメモリを差して使ってるけど,
BIOSを2.50(AGESA 1.0.0.6)にアップデートするまでは負荷を
掛けるとすぐにECCエラーが発生してリブートしちゃって使い物
にならなかった.
アップデートしてからは問題は起きてない.
このエラーと今回のSEGV問題って何か関係があるんだろうか. >>748
メモリーにECCが無かったら気付かないままデータ化けしていたってことか SEGV出てる人でコンセント逆差しかアース取って直った人いる? 自作音痴は本人の欠陥
電源換えようがメモリ変えようがどうにかなる物ではない
もうメーカー製PCで試せよとしか そういやID:7JWOpl1/はファームのバージョン書いてないな これubuntuカーネルが腐ってるだけじゃね?
素のdebianじゃ全く起こらない
ProcOCTガチガチに詰めるとエラー出るけどね KP41と一緒で原因は一つに限らないって話なのかね? >>754
そうだね。
SEGV自体、真の原因はさらに掘ってね、というものだし。 gentoo界隈見てきたけど面白いな
メモリ/CPUの電圧盛って改善
CPUクロック落として改善
ASLR OFFで改善
BIOS UPDATEで改善
BIOS UPDATE + クリーンインストールで改善
binutilsが古かった / ぶっ壊れていた のを直して改善
(少なくともあるユーザーの)PWMの設定が逆( 熱くなるほどファンが遅くなる )
俺は不平屋じゃないよとかCPU単独の問題じゃなくてシステム全体でとらえなさいとか
言われてて苦笑 3000回mesaビルドして2回だけハードウェアエラー出て
uopのタグミス出たけどこいつだけはエラッタかもしれないがそれ以外はディストリと設定じゃねーかな >>756
>>677の人は電圧盛ったりクロック落としてもダメだったそうだが、改善する場合もあるという事か バグ発見の為にA10-9700とかA12-9800を買う猛者はおらんか?
海外通販13000円から買えるけど >>758
>>667はUPS使えば改善しそうだがね。 >>759
AM4だからといって鰤では起きないんじゃないか?
それを確認して欲しいのだろうけど
ただ13000円位ならバグ発見関係なしに興味はある
どこで買える?
>>760
UPSも確かに手だな
既に常時インバータにしろという話も出てる
高いけど
ラインインタラクティブならバッテリーダメになったやつ持ってるからバッテリー買い直せば使えるな AMDフォーラムにもこんな人がいる
・テスト環境はPC環境新しくしてからクリーンインストール、Windows10、Ubuntu 16.04、Gentoo
・Ryzen7 1700+H110i AIO+MSI X370 Gaming Pro Carbon(7A32v15)+CMK16GX4M2B3200C16R(2x8GB、1866〜2133設定、CL16)
+Samsung 950pro 250GB and Sandisk Ultra 480GB+Fractal Design R5 case, 2x140mm case fans+Geforce GTX670+Corsair RM650x
memtest2pass、Prime95 2時間以上pass、OCCTpassだけどエラー出る
・温度はCPU47℃とMB36℃(Windows10から確認)
・Gentoo, gcc6.3 (-O2 -pipe -march=znver1), make -j16 and emerging (compiling and installing) the mesa-17.0 package in a loop.
CPUクーラーのファン最大に→2周でエラー、make -j8→4周でエラー、メモリ2133/CL15→1周でエラー、メモリ1866/1.2V/CL18→2周でエラー、
メモリ2133+CnQoff→3周でエラー、+LLCmode2→2周でエラー、+CPU1.25v→3周でエラー、+NB1.15v→1周でエラー、+
CPUターボoff+C6off+3.2GHz+CPU1.35v+NB1.15v+LLCmode4→2周でエラー
デフォ設定メモリ2933+ASLRoff→5周でエラー
SMT disabled (RAM 2933MHz) and make -j9で172周以上(一晩)エラー出なかった
・SMT enableにして再テスト
make -j16, ASLR disabled→5周でエラー、Disable 2 cores (3+3)→4周でエラー、Disable 4 cores (4+0)→6周でエラー
↓
・Ryzen 5 1600X と ASRock Taichi x370(P1.60)を入手したので入れ替えてテストしてみた
・前のシステムからCPUを1600Xに変えた→segfaultが簡単に再現した
・ASRock x370 Taichi(P1.60)+1600X→安定していたが65周でlockup
・TaichiのBIOSをP2.30に更新+1700を載せてみる→一晩放置でlockupせずにエラー0だった
・再現するのがMSI X370 Gaming Pro CarbonだけになったのでRMAしようと思う
板不良だったのか単にVRM冷却忘れてたのかまでは分からなかったが >>712氏がエラー出したPC環境(板、メモリ、電源)とかなり似てたので気になった >>758
ファイルが古いとか設定の問題があるのでそこが間違っていると何やっても駄目らしい
特にbinutilsの選択が間違っていると(古いと)駄目
RAMの電圧とタイミング、BIOSの選択(MBによっては最新のほうが駄目だったりする) >>763
taichiはVRMがかなり贅沢でCPU12+4、メモリ2フェーズ、コントローラ・FETはIR製
X370carbonはCPU8+2、メモリ1フェーズ、コントローラはIR製、FETは中華企業製
carbonはVRM安定性の個体差がtaichiより出やすい可能性がある
(経験的にはMSIのAM4板は最上位のチタン以外その傾向がある感じ)
なおtaichiのBIOS P1.60はAGESA1.0.0.3、P2.30は1.0.0.4a
現在は1.0.0.6のP2.40(ベータでなく正式版)も出ている 結局、おま環か。
ソフト専門屋は、環境を総合的に解析出来なくてダメだなあ。 初期不良に当たらなければ
当たると>>695みたいになる MBからみればマージンが狭く御しにくいCPUではあるかな
B2stepping + 比較的高価なM/Bのスリッパでどうなるか見ものである >>699
特定のネジ閉めたら、電源切ったらCMOS勝手にクリアされるマザーならあったわ ソフト専門屋≠ハードも詳しいが普通
まあ、しゃーないわな まあハードにステータスを振らずにソフトに振っておくみたいなの。 >>729
linuxってこんなんばっかやな
理由のよくわからん上手くいくおまじない多すぎ >>759
売ってる所分かった
A10-9700(TDP65W)とA12-9800E(TDP35W)
3000円も違わない
悩ましいな
少し前にTurion64x2とノート用Core2Duoを買ってみたが無事届いたよ
PayPal支払だからいい加減な商売やるとストップさせられるから大丈夫と思われ
スレチっぽいのは勘弁 >BIOSの選択(MBによっては最新のほうが駄目だったりする)
AGESA 1.0.0.6はメモリアクセス遅くなった、メモリクロック下げないと起動しなくなった等一部マザーにおいて不評な模様
安定性を上げるために安全側に振ったのかもしれんが… >>779
確かにその二つだと悩むというかどちらを選択するかの決定打ないな。 >>778
まあ並列コンパイルは、並列コンパイルが出来るように個別対応して手をかけてやってるわけで。 今頃気づいたがtaichiはC6H同様映像出力ポート無かった
APU使えない
使える板も持ってるからまあいいけど >>784
APUの内蔵GPUが使えないだけで、グラボ挿せばつかえるんじゃね。 まあ使いもしないオンボ映像出力ポートが邪魔なんじゃないか説は
詰まったら検討してみようみたいな。 多分それで使えると思うが
サポートリストに載ってないのがね
現物で試すしかないのがまた悩む linux使ったことないから蚊帳の外だわ
何か簡単にテスト出来る方法ない? >>778
ただのオプション記法じゃん
まじないいうやつが呪術世界に住んでる >>763
おれの環境に似てるなあ
carbonでSMTなしだとSEGVはでないのか
とりあえずSMTきって-j9で試す
並列コンパイルなしは、遅々として進まずやってられん >>788
鰤はある意味新CPU(APU)みたいなもんだからついw
もし買ったら>>759の要望に応えてSEGVテストはしてみるわ
出たらびっくりだけどな
という事でスレチ勘弁 4.11.6を7.0.1で-j16で6時間回したけどSegvみたいなのは出ないな
configはUbuntu17.04のlocalmodconfig使用
取り敢えず並列オプはある程度は信用できそうだ
ただ数値おかしいとか構文おかしいとかめっちゃ注意されまくってる
このカーネル自体は使わない方が良さそうだ 今時CPUの購入週とか関係ないよな
リビジョン一緒だし >>794
環境によるんかねー
おれ環だと結構すぐでるんだけど
ubuntuのバージョン(make,gccのバージョン)の違いだったりして
おれは16.04 CPU単独のエラッタ
M/Bのリファレンスデザインが糞
Ryzenはペリフェラルに非常にシビア
Ryzenユーザーの環境は糞が多い
どれがいい? >>796
いや申し訳ない
書き忘れたがコレはFX機だ
カーネルそのものとgccのバージョン、其れから-jがそもそもイケるかどうかの対照実験
ちなみに17.04でツルシのままなので環境自体は4.10.0-24上 >>798
おお、そっか
対照実験ありがとう
進展あったらまた教えて >>797
大丈夫、大丈夫
公認会計士も一時期増えすぎで就職できない人がいっぱい出たけど
みんなどっかで元気に生きてるから エラッタはあるのかもしれないと、休みの日を潰して地道に検証してる人はえらいと思う。
でもゴミみたいな動作環境で、逐一twitterで無知を晒しながら
検証というなのお遊びをしてる奴とその取り巻きはほんとクソだな
AMDはエライ迷惑してるだろうなと >>712だが、SMT無効でSEGV今んとこでてない。まだ20回程度だけど。
SMT有効のときは一割くらいの確率ででてた。
マザボcarbonだし環境も症状も>>763と同じ。 >>803
書いた矢先だが、SEGVでてたわ
SMT関係なかった
もうわからんな、これ
公式見解まつわ >>713
>>728
>>753
ここらは怪しいかなあと思える
昨晩taichi逝った人復旧できなかったのかな気になる >>804
BIOSのバージョン1.5だったらベータ版1.63(AGESA1.0.0.6)出てるから試してみては?
taichiでBIOSアップデートで挙動変わってる事例あるし
>>805
心配してくれてありがとう
俺がそうだけど、朝起動してもダメでやる気なくしてた
さっき気を取り直して他の板に一式移して無事起動を確認
他のパーツが死んでなくて良かった
今memtest中
taichiは後で1700を載っけて新品の電源でもう一度試してダメなら修理に出す debianは未だ3番台じゃなかったか
Ubuntuは4.10まで行ってるし >>806
マザー突然死することなんてあるもんなんだなあ
恐ろしい >>806
デバッグコードがいくつか気になるとこではあるけど
ファン回ってるのならBIOS飛んだかもな >>807
4.0.9
unstable 4.10.6 カーネル4.10.xxがダメならRyzen SMT対応したものがダメだという話になるのでは・・・? ハードが安定してるのに
上手く行ったり行かなかったりか
ソフトの異常も混じってる感じか? >>808
昔EPoXのSocket754マザーで似たような事があった
ある日昨日まで動いてたのに起動したらピクリともしない
切り分けた結果マザー突然死と判明した覚えがある
代理店が同じマスタードシードというのがなんともはや
>>809
ファンは一瞬回るがすぐ止まる
デバッグLEDは点かない
HDD等も起動しない
電源制御が死んでいる感じ >>810
メジャーは一緒か
大元のdebianで未だ4.10がunstableなのにUbuntuは平気で使うんだな
16.04LTSでも4.3だし 追加購入していった結果最終的にもう1セット揃ったけどやっぱり石の問題じゃないのという気持ちで徒労感
確認してみた方が良い項目他にないかな
OS: Ubuntu 17.04
kernel: 4.10.0-24
gcc: 6.3.0 20170406 (Ubuntu 6.3.0-12ubuntu2)
SSD: WD Green 240GB M.2
GPU: Radeon R9 Nano
PSU: Seasonic SS-860XP2S(1800X機と1700機では別の個体)
UI: PS/2キーボード USBマウス
memtestは全メモリ問題なし
電圧設定変更後はOCCTで30分だけ
頻度は特に気にしてないんであしからず
電源をタップ経由 -> マンションの3pinコンセント直結 => 効果なし
1800X
Cooler: Noctua NH-D15 (max 55度)
MB: TOMAHAWK B350 v1.64
Mem: Corsair CMK16GX4M2B3200C16 (2133MHz動作)
3.2GHz, 3.65GHz/ CPU 1.25V/ SoC 1.1V => 効果なし
C6 State/ CnQ/ Core Performance Boost: disable => 効果なし
LLC: Auto -> Mode1, Mode8 => 効果なし
ASLR: disable => 効果なし
1700
Cooler: AMD Wraith Spire (max 60度)
MB: BIOSTAR X370GTN (M-ITX) X37AK413.BSS
Mem: Century Micro CK8GX2-D4U2133/HYN
デフォルトからCnQとC6、Boostっぽい設定を切って効果なかったのを確認した程度で深追いはしていない
1700
Cooler: Cryiorig R5 Universal (max 45度)
MB: ASRock X370 Taichi 2.40
Mem: G.Skill FLARE-X F4-2400C16D-16GFX
P0のみ3.0GHz残りはdisable/ CPU 1.2V/ SoC 1.05V => 効果なし
C6/CnQ/Core Performance Boost/ Global C-state Control: disable => 効果なし
LLC(CPU/SoC): Level1 => 効果なし
SMT/OpCache: disable => テスト中(これで動いてもね...)
1800XにWraithSpireを試してみたときにしか動作停止起こらなかったんでそういうのは熱暴走の類なんじゃないのかなあ...?
1800X機上のWin10 1703 15063.413、VS2015 Communityを使ってChromiumビルドしたら4/5で失敗した
同根の問題かは不明だけどおま環かどうか知りたいので誰か試してみてくれない?
https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md >>816
ハードウェアにも詳しいソフト屋に参考までに見解聞いてきたが
「VRM周りの作りがへちょいマザーだと8コア支えるの無理なんじゃね?」と言われた
試しにBIOSでコア数削って試してみてもらえんね? >>820
ソレはあの単体メモリの人?
ならあのメモリ調べた時に1sしかヒットしなかったと記憶してるから1sじゃ無いかな
調子に乗ってdebian入れるんじゃなかった
インスコ時間掛かるー すまんTaichiの設定慣れてなかったもんで正しく電圧固定されてなかった
下の画像でもわかる通り動作周波数も2.7GHzぐらいまで落ちてる瞬間があるしで
>>816のTaichiの結果は忘れてくれ
>>817
PLLがBIOSから探せなかったんでとりあえずHWinfoの画像を
http://i.imgur.com/L55O3Zk.png
BIOS設定のどこにあたるか教えてくれたら結果貼るときに併記するよ
>>819
電圧固定で再テストしてまだ問題があるようだったら次にやってみる >>820
Ryzen
ASUSマザー
Geforceビデオカード なので↓あたりでしょうか
パソコン工房 "LEVEL-R0X3-R7-RNJ"
https://www.pc-koubou.jp/products/detail.php?product_id=589202
標準が550Wのシルバーで余裕があると書いてあるのでおすすめの700Wのブロンズかもしれませんね
https://www.pc-koubou.jp/products/custom.php
電源メーカーはすぐにはわかりませんでした >>823 に追加
"パソコン工房 VIVE 電源 メーカー" でググると FSP みたいな感じです
FSPなら悪くないところですね >>823
CPU: Ryzen 1800X
Motherboard: ASUS PRIME X370-PRO
BIOS: 1.0.0.4a(設定はデフォルト)
DIMM: Kingston KVR24N17S8/8 * 4 (8 * 4 = 32GB)
GPU: GeForce GTX 1060
これで工房のBTOだとメモリ8GBx4が選べないね >>825
メモリ 32GBなんですね。失礼しました >>822
taichiもダメな場合ありかーと思っていたらどんでん返し
taichi持ちとして期待している
(昨日壊れたので多分1ヶ月程使えないがw) >>822
taichiのマニュアル見た
PLLは1.8vの所の筈
ちなみにPROMってなってるところはC6HのOCマニュアルじゃSB扱いになってる、あと1.8vスタンバイって謎の項目も
PLLは許容2.1らしいし、場所もよくわからんし
あんまり派手に動かせないなこれは
VPPMって何だろうか、、、 >>806
BIOS1.63にあげた
BIOS設定はメモリ以外はデフォ
メモリは以前から安定してる設定に変更してある。
結果でたら報告する >>822
PLLは固定するなら1.95〜2vくらいまでがいいかな >>829
taichi持ちだが俺もその辺は分からない
すまぬ BIOSあげたら、ほんの少しおそくなった
今まで一回のkernelビルドが580sぐらいだったのに、BIOSあげてから590s程度になった。
五回終わってエラーなし 誰かまとめお願い!
Linux以外で発生するか
1コアで発生するか
1スレッドで発生するか
カーネルのビルド以外で発生するか >>836
SEGV出てないけど15回目でmakeが停止状態になってた。
straceかけたけどmakeはwait4()状態。
gcc終了を待ってる模様。
# ps ax | grep ccかけるといくつかのgcc,cc1が停止状態
これ、今回の件と関係あんのかな・・ TaichiのPLL(+1.8V)、2.15からレッドゾーンで俺環だと2.15VではBusクロックが逆に安定しなくなった
Hynixチップを3333で安定動作させるのにSOCが1.175V必要だったのが
PLLを2.1V以上盛ることでAutoの1.1Vでも動くようになったな俺環では
VPPMはそれの半分の電圧がメモコンに流れているらしいが詳細は不明
これを2.70Vまで盛ってOCCTが通らなかった設定で安定動作したりした事もある
けど、どの設定も他の電圧に左右されてるし個々に違うだろうから
完全な設定を見つけるためには総当たりするしかないと思う >>840
今気がついたけどメモリ設定はデフォじゃないんだ
1.0.0.6にするとメモコンの動作特性が変わるので、1.0.0.4aの時の設定では通らない場合がある
とりあえず何かでメモリテストしてみた方が良いと思われ 昔からパラレルmakeは苦戦してるみたいだからね
http://d.hatena.ne.jp/yamidori98/20130627/1372353889
オブジェクトの生成(makeの実行)
「-j*」を付けない場合、シリアルコンパイルになるため、基本的にコンパイル問題は発生しなくなります。ただし、コンパイル時間が長くなります。Core i5クラスで4時間程度掛かります。
「-j*」を付けた場合、パラレルコンパイルになるため、希にコンパイルの途中でハングすることがあります。ただし、「-j*」を付けることによって、コンパイル時間を減らすことが可能です。
昔からLinux使ってる人はパラレルmakeは速いが失敗するってのが知れ渡ってるみたいだけど >>841
参考になる
手持ちのtaichi壊れたから試せるのはしばらく後だけど・・・ http://d.hatena.ne.jp/tmatsuu/20071122/1195746717
Gentooには初期段階からparallel makeの仕組みが存在する(emakeコマンド)のだが、これは良い面も悪い面もある。
というのも、Makefileが腐ってるためにparallel makeができないソフトウェアが実は結構あるのだ。
タチが悪いのは、タイミング等の問題でうまく再現できない場合があること。
そのために、makeに失敗して無駄な時間を浪費してしまうかもしれない。 今回の騒動の大前提が崩れるということ?
(実は起きて当たり前のことをおかしいと)
でも人によってはエラーが多すぎるような ryzen持ってないから試せないけど10年以上前からGentooをメインで使ってる
その俺が言える事は
*kernelやgccの様なクリティカルなパッケージは-j**付けても-O3の
様な最適化付けても強制的に-j1や-Oに戻される。直接全てのmakefike
書き直ししないとこれが適用される
*コンパイルがコケるのなんて日常茶飯事。アップデートが1度で通る事
なんて数える程しか経験ない。その度にソースファイル書き直したり依存関係
解決したり自力でやるしかない
*セグメンテーション違反出る時は大抵ANSIを無視した超最適化した時か
スタック偽装プロテクションをガッチガチにした時 ここで言うのもアレだがメーカーPCでの検証はないのかな どうしてもみんなCPU以外の問題にしたいみたいだけど、冷静に考えてCPUのエラッタの可能性が一番高いと思うよ >>846
そんなの当たり前的になってるような気がするし
>>847
ryzenとか -j16にすると恐ろしいスピードで終わるよ
-j1に戻されてないんじゃないだろうか? >ryzenとか -j16にすると恐ろしいスピードで終わるよ
基本的にkernelはドライバの集合体みたいなモンだから依存関係の無い部分は
多重プロセス化けるされるのと部分的には多重スレッド化もされる
ただクリティカルな部分はシングルスレッドでしかコンパイル出来ない
説明がうまく出来ないから伝わるか判らんが >>852
どうなの?
Linuxユーザー感覚として
make -j16にして
カーネルコンパイルを10分程度という
かつてないスピードで走らせてるけど
確実に終わるもんなの? >>854
例えばラズパイ2でコンパイルして熱暴走した時なんかは
コンパイルが止まるというよりOS自体が落ちる感じだった
クソメモリの時もOS自体道連れにする事が多い
仮にエラッタがあったとするとやっぱりOS自体落ちると思う
コンパイルだけコケる、または出てきたファイルが壊れてるって場合は
ソフトウェアの問題の可能性が高いと思う あらゆる環境で発生した時の症状が同じなんだから電源とかメモリ絡みを疑うのは違う気がする
ソフトのバグか、CPUのエラッタ >>763のところで
make -j8→4周でエラー
って-j8で落ちるからな
ハード的には確実に安定している
ソフトのバクなんじゃないか パラレルだと全然話が違うってのは、Llinux詳しくないけど感覚として分かるわ〜
要はシングルでやらなきゃいけない部分を厳密に記述できてるの?ってことだよな
そこをOFFにしてるってことは外的な不確定要素をなるべく排除しようっていう設計思想なんだろう
j 16が出来るのは単にユーザーに禁止してないだけでおま環で勝手にやれでバイナリの完全性を保証してるわけではない(と思う。多分な)
これってカーネルに限った話じゃないと思うんだが? IntelのCPUで検証して「Core i7 SEGV」や「Xeon SEGV」みたいなことが起これば
問題は単に「gcc SEGV」と言っていい。 アーキテクチャが違うからそう言い切れるものではないかと 何度かカーネルの並列ビルド中に割り込み?を掛けて止めた(Breakが効かなかったので)が、動きとしてマスターのスレッドみたいなのが有って、周りはそれにくっ付いて動いてるように見受けられる
一応は大丈夫そうだが、、、
それよりLinuxだと認識しているトポロジが違うんだっけか
あれの方も気になる
またパッケージ段階で適切にビルドされているかどうか
configに気になる項目は山程あるしな
それに出現率が余りにも離散的に過ぎるってのもある
対照試験として、数回に一回の失敗条件を満たすエラーを故意に別環境で誘発してみようと思う 騒いでるのは日本だけじゃないか
カーネルのコンパイル自体
かなり特殊な行為になる
Linuxでもmakeなんてコマンドを使わなくなっている マジかよGentooって日本人しか使ってなかったんだな >>863
お前が来るところじゃねーよ
隔離場所にすっこんでろ ・特定のバイナリをLLVMでリコンパイルするとオプションにsandybridgeを指定していないと動作しない(genericやznver1等はダメ)
・Y-Cruncher Benchの特定のバージョン(0.5.3.9132〜v0.5.5.9178)でクラッシュ
・ここのx64-13-Haswell.exeのベンチで100%ハードブリック(リセットボタン反応なしで電源長押ししないとダメ)
http://forum.hwbot.org/showthread.php?t=167605
どれも共通していたのはSMTを無効にすると起きない、Agesa1004a以降は発生しないという点。
何故かコンパイルオプションを本来のCPUとは違う指定をすると動いたりする辺り、何かあるんだろうけど。 標準設定でのマージンが不足して、標準設定でまれに動作不良になるんだろ?
OCしたり自分で電圧やクロック、メモリのクロック・タイミングいじったりしてマージン不足でクラッシュするならおま環だけど、
標準状態でまれにマージン不足でクラッシュする >>816
gccはRyzen環境でビルドしたものでしょうか?ディストリビューション標準のものでしょうか? ubuntu→debianで検証としてbuildしてたんだけど
ubuntuでは山程出てたエラー?(色付き文字で出る、でも止まらない)みたいなのがdebianで出なくなってる事に気付いた
FXだから大丈夫だろうと思ってたが何でこんな事が?
gccバージョンがubuntuの時7でやってて、debianはツルシだから7に後で上げてみる
詳しくないとこういうのあるから困るな、手戻りだ
あとメモリそのものを故意に不安定にして3回走らせたらmakeの最後に出て来るSystem isの容量が同じ設定で毎度ズレた(エラーはない)
参考にどうぞ >>870
ディストロ標準だね aptで入るやつ
>>871
Warningのことならgccのバージョンによって出る出ないあると思うよ >>860
例のRyzenをバグがある事にしたい人のtwitter 6/16の書き込みで他の環境でも発生と報告した人がいるな >>840
またsegvでずにmakeがwait状態でとまってたわ
メモリ周り調整して再トライするよ… 普通のパーツで組んでる人の構成を小馬鹿にして、電源ガー、VRMガー、メモリガーって突つくのは相当見苦しいけれどね
CPUのエラッタじゃなければ、電源やメモリよりもソフトのバグの可能性の方が余程大きいだろうに。
まあ非常に発生率が低いCPUのエラッタなのだろうなと思うけど >>877
小馬鹿は悪いとは言え疑うことは仕方ないでしょ
何故発生するのかきちんと原因わかってないのに CPUが原因と思い込んでる人にとっては否定気味で考察しているこっちが異常に見えるのかもしれんが 厳選されたボッタクリパーツで固めないと動かないんだったらそもそもコンシューマ向けに売るなと 64バイトずれの再現性が高いって時点で、電源やメインメモリは関係なさそうだと思うでしょ
ソフトのバグかCPU固有の問題を真っ先に疑うけど ソフトは実績があるので、CPUのエラッタの可能性が高い >>816
windows10だとここ最近にchromium取ってくるとgclient syncで止まるからビルドすらできんはずだけど?
Windowsで動作させている人でWHEA-Loggerでメモリかキャッシュのエラー出る人いる? ところでFXで対照実験してた人どうだったんだろ?
パラレルコンパイルでSEGVでなかった? >>883
再現率バラバラでCPUの問題か?ってところでソフト屋がCPU付け替えたらバグ頻度変わったなんてツイッターで言うから外的要因なのかって話が現状なんだが 素人の解析能力の低さがよく分かるスレだよな
何度も発生してるのに何の情報も得られていないという
さんざんバカにしてるソフト屋の情報を結局あてにしてたり >>885
DEPOT_TOOLS_WIN_TOOLCHAIN=0指定し忘れたときとVS2017使おうとしたときは確かそこで止まったけど
指定してVS2015だったら通ってビルドできたよ satって例のソフト屋か?
残念ながらおれはAMDのCPUは買わない主義なんで >>891
環境変数設定してもgn.exe作る時点でこけるw >>855
いまやkernel本体より、静的に組み込まれているドライバのコード量の方が圧倒的に多いと思うけど ソフトウェアにバグはつきものだし
CPUもこれだけいろいろなもん積んでるとバグがないほうが奇跡のようなもの >>872
ソースコードがあるものは、自環境でビルドしないと気持ち悪いのですが、時代が違うのかな。
余裕あれば上にも出てたbinutils含め、カーネルビルドで利用するソフト一式を同じ環境でリビルドすることで改善しないか、お試しいただけないでしょうか。 linux詳しくないけどカーネル古いのに戻すことはできるの?
ryzen対応直前の物に変えるとどうなんだろう
twitterで購入当初は起こってなかった気がすると少し前に見たんだが >>895
買ってもないのに妄想でデマばら撒いてんのか >>893
流石にPATHは通してるだろうし
VS2015コマンドラインから実行してるか?
VSインストール時にWindowsSDKも選択(デフォルトだったような気もするけど)してるか?
http://cygx.mydns.jp/blog/?arti=477 これにあるtoolchain.pyはどう?
あたりかなあ 解決するつもりがあるならエラー貼ってくれたらもうちょっと詳しく見られるけど >>895
じゃあ君はソフトウェアのバグの線で解析をお願いします [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
https://lists.debian.org/debian-devel/2017/06/msg00308.html
Skylake(第6世代)とKabylake(第7世代)のCPUでハイパースレッディングを使うと
システムが予測不能な挙動を示し、アプリやシステムにデータの破損や損失を含む
エラーが起こる可能性がある。
これは、デスクトップ、モバイル、組み込み、HEDT、Xeonサーバー全てに共通する。
マイクロコードが修正されるまで、回避策としてハイパースレッディングをBIOSか
らOFFにすること。
この欠陥はLinuxに限らず、全てのOSに影響を与える可能性がある。
潜在的に影響を受けるソフトウェアの検出は困難であり、全ての上記CPUユーザーは
HT OFFを推奨する。 >>902
既知のエラッタとしてドキュメント化されており、修正マイクロコードは既に各ベンダーに配布済み
各社新EFIのテスト中で、製品によっては公開済みかもしれない
という内容は意図的に無視 それはそうとsatさんのtwitterで1コア利用でも発生したって書かれてたよ 原因切り分けが出来なさそうな人間だしな…過去の発言みるとだけど
正直信用できん ryzenエラッタエラッタ言ってた団子にブーメラン刺さったってマジ? なんだ真夜中に病人わいて出たか
>>908
病人の通常営業だよ 最近のBIOSアップデートの更新履歴に"RC Code 1.8 Updated"って書いてあったがこのエラッタの修正とは無関係なのかな >>906
ごめん、そしてありがとう
RyzenのSEGVバグの話と勘違いしてた @64命令以内のショートループ
A部分レジスタAH/BH/CH/DHを使用
BHyperThreadingで同じ論理CPUの部分レジスタを参照
で、条件フラグがおかしくなって発動するのな
発生条件がもはや天文学的なんだけど具体的に実用的なコードで発生すんの?
クッソ古い文字列関数の一部実装くらい?
64ビットモードではほぼ使わねーだろこの部分レジスタ
しかも4月の時点でエラッタリスト書いてあるし
お前らは気にする必要ない >>912
原因が分かってるだけマシって開き直ると予想 団子はこんなところじゃなくて他の板で真実を広めろよ
悪い噂はryzenみたいにパーっと広まるから アムド信者が待ち望んだ雷禅に致命的欠陥発見ワロタwwwwwwww
一気に絶望へと突き落とされた信者の阿鼻叫喚はほんと面白いわ いまどきコンパイラがこんなコード吐かないでしょ
AH/BH/CH/DHの操作なんてクソ遅いし 今時のコンパイラだと問題ないけど、昔のコードはまだたくさん残ってるからな >>907
原因がわかってて対応しないといけないエラッタが
残り149個あるってことか?
intelも大変だな
150個中の1個が公になっただけ? 再現条件もはっきりしててすなわち防止方法も明らかだな
鬼の首とるには不十分だ、がんばれ
ちなみに俺個人のことを言えばKabylakeのCore m3と迷ってApolloLakeのタブ買った俺には直接は関係ない話だな。デスクトップ機は4C4Tのi5だし >>927
命令キャッシュ=データキャッシュの知恵遅れおじいちゃんこんばんは 2chからいなくなるのがベスト
間違った事しか書き込まないからどこに現れても迷惑なんだよね >>905
Satだろ?
そいつは炎上狙いでHW不具合出させて交換しろとかおかしな発言多すぎる
都合のいいツイッターだけ引っ張ってきて問題ない人は一切見ないか認めないとか頭おかしいから放置でいい
Linuxのコミュニティでもこの問題は無視されてるのが現状
Phenom IIの時にも同じ問題あったけどドキュメント公開されて終了
ソフト側の対応ができてないのが原因
SatはLinux側の人間だから素直に認めないわ 結局電源の質とかメモリのタイミング周り?
RyzenがIntel CPUに比べて結構シビアなのか、
AMD機を買うのは貧乏人が多いから
相対的にこの手の問題に遭遇する事がおおいのか? >>938
>>938
Ryzen発売当初 購入者の外人「詳細な情報レポート付き」でRyzenのキャッシュかメモリに不具合あると警告
↓海外ユーザ・2ch反応
「おれは不具合でない」「ベンチーマーク完走したぞ10分」「おま環」「メモリまわりがシビアなんだよ」
↓
サイトR●●●で匿名がRyzenの不具合に言及
↓2ch反応
「インテルのネガキャンはjまったよ」「以前不具合ないと確定した(と思う)」「この前のコード修正で治った(はず)」
↓
自作板匿名「やっぱりRyzen不具合あるんじゃない?あんなことやこんなことやってみた」
↓2ch反応
「黙れ工作員」 ※報告者フルボッコ
↓
4chan,サイトR●●●「やはりキャッシュかメモリ周りに問題あり」
↓2ch反応
スルー
↓
今回 ←New!! >>942
原因確定したの?
結局何が原因で起こる不具合なんだ? >>938
漏れたので追加
Ryzen発売当初 購入者の外人「詳細な情報レポート付き」でRyzenのキャッシュかメモリに不具合あると警告
↓海外ユーザ・2ch反応
「おれは不具合でない」「ベンチーマーク完走したぞ10分」「おま環」「メモリまわりがシビアなんだよ」
↓
海外Blog「Windows10にバグがあるためRyzenはベンチマークが振るわない
↓2ch反応
「やっぱりMicorosoftかどうりでIntelより性能低いはずだ」「Win10修正されたら実行速度でRyzenが最強になるな」「これだからWin10は…」
↓さっそくAMDの中の人が調査
AMDの中の人「Windows10にバグはない。AMDは近々修正コードをリリース予定それで改善します」
↓
AMD修正コードリリース
↓2ch反応
「Ryzenのベンチマークすげー落ちたんだけど…」「Microsoftにいくら金つまれたんだよAMDやっぱりWin10のバグだろ」「スパイOS Win10氏ね」
↓
サイトR●●●で匿名がRyzenの不具合に言及
↓2ch反応
「インテルのネガキャンはjまったよ」「以前不具合ないと確定した(と思う)」「この前のコード修正で治った(はず)」
↓
自作板匿名「やっぱりRyzen不具合あるんじゃない?あんなことやこんなことやってみた」
↓2ch反応
「黙れ工作員」 ※報告者フルボッコ
↓
4chan,サイトR●●●「やはりキャッシュかメモリ周りに問題あり」
↓2ch反応
スルー
↓
今回 ←New!! いや俺情報そこまで追いかけてられていないが
Ryzen検討したいから現状知りたいのよ
64バイトずれってのが本当に複数の人で起こるなら
それは外付けメモリや電源じゃなくて、
プロセッサかプロセッサの内蔵キャッシュじゃないの?やはり
電源がギリギリだったりメモリのタイミングきつくて
クリティカルなとこでそういうアナログ的原因で狂うなら
そんな規則的な単一現象じゃなくてもっと色々起きそうだし >>946
原因が解明されたなら解決は早いな!
ところで原因が確定したソースは何処にあるんだい? >>945
じゃあなんでそんな民度であるここにいるんですかね…?
同じになりたいの? 148 名前:,,・´∀`・,,)っ-○○○[] 投稿日:2016/11/14(月) 20:21:39.52 ID:0Q4rwlJ0 [5/9]
まあ、本当にBroadwellの性能超えたら32コアOpteronデュアル機組んでAMDを応援してやるよ
351 名前:,,・´∀`・,,)っ-○○○[sage] 投稿日:2017/01/10(火) 21:24:59.71 ID:deU+9WJv [4/7]
リアル春にはAMD冬の時代になるから今のうちに春を楽しんで置きたまえ
540 名前:,,・´∀`・,,)っ-○○○[sage] 投稿日:2016/10/12(水) 21:45:48.40 ID:ijYX/87D [5/21]
Zenが高くないと買えない自分を正当化できないもんな
大丈夫だよ、8コア最上位でも3万円切るから
お前みたいな無職大貧民には大金だけどな
545 名前:,,・´∀`・,,)っ-○○○[sage] 投稿日:2016/10/12(水) 22:03:09.78 ID:ijYX/87D [8/21]
最上位で3万円切るって宣言した俺の発言ログとっとけよ 電源か、または正しい電圧を供給できないマザボが原因。 IntelだろうがAMDだろうがバグ見つかったらマイクロコードパッチででもそれなりに素早く対応してくれりゃいいのよ
定格の部品使って定格内で安定しないとか、
コンパイルでも数値計算でも、少人数だろうがどうだろうが、特定の人達が現実に使うワークロードでおかしくなるものを放置されるとか、
もしそうならそんなもん安心して買えないというだけ 定格で使ってないから不具合出てるんじゃないかと思うがとりあえず原因確定したの? >>947
必ず64バイトずれるかと聞かれると確定してない
64バイトずれると言い出した人が中古の動物電源使ってる人だけなので何とも言えない
このスレに居るような、まともなパーツで構成したシステム所有しててエラー出る人が検証してくれたなら真実に近づくんだけども intelは今回の件解決したとして
後100個以上残ってる
結構前に見つかったものが
やっと1個現実的被害としてヤバイ
と認識され修正されるかどうか
という感じじゃないか >>956
暇だった
●Intel/AMD新型CPU発売直後の質問スレ
読解力無し君
「5GHzにできると言われたオーバークロックモデルを購入したのですがブルースクリーンします」
「5GHzにできると言われたオーバークロックモデルを購入したのですがOSが起動しません」
↓
親切な人「オーバークロックしてるんやろ?」
↓
読解力無し君「はい、調べて5GHzにしてあります エッヘン」
親切な人「オーバークロックが原因だよ」
↓
読解力無し君「どうして?どうやるの?おしえて?」
親切な人「オーバークロックやめてとりあえず起動するかテストしてSS貼って」
↓
読解力無し君「嫌だめんどくさい。けちけちしないで教えて」
親切な人「もしかすると他に原因あるかもしれないから問題の切り分けが必要なんだよ」
↓
読解力無し君「情報サイトと同じパーツ買ったから5GHzで絶対動くはずだ!!!!!!」
親切な人「…(駄目だコイツ)」
↓
読解力無し君「ウゼー煽るだけで教えてくれねーのかよ」
★親切な人「…(もう自分から調べようとしない人には教えないようにしよう)」 豊洲(intel)は丹念に調査した結果ヤバイことがわかりました
築地(amd)はさほど調べてないけど多分大丈夫です >>947
64バイトズレの人はスッポンしたり色々やらかしてるからあまり参考にならん
解析スキルはあるのにまともにPC組めない人 bitvisorとかいうソフトの宣伝の為にやってみました感あるな 今日は急に変なのが大量に湧いてるな
業者なら昨日は休みだったからか
ネガキャン業者か
火消し業者を雇ったか
さらに混乱させたいだけのアフィブログ工作員か あんなので自称Linuxカーネル開発者なんだからLinuxってレベル低いんだな そもそも、エラッタって致命的なの以外は直す必要はないんだよな
文章で発生条件・回避方法を書いて発表しておくだけでいい
で、致命的な奴だけ修正
ちょっと前発見されたintelのHT有効時のバグに関しては、レガシーバイナリ・レガシーコード動かさない場合当てはまらないでしょう
ただし、レガシーコード動かす場合は結構致命的
HTをオフにするっていうワークアラウンドがあるが、パフォーマンスが大きく落ちる
ところがryzenのバグは、いまだに発生条件・回避方法がわからずamdもダンマリ >>966
発生条件わからないのに
CPUが原因と決めつけてるわけ? ryzenのエラッタ
発生条件:GCC
回避方法:GCCを動かさない
文章で発生条件・回避方法を書いておけばエラッタ修正の必要は無いんだよな? >>971
AMDがGCC以外のソフトで例のバグが発生しないと明言できるならやってもいいのでは?
まあ多くの人がそれで納得しないだろうが そもそもパラレルmakeなんぞ昔から成功しない例が多々あって
パラレルmakeはしない方がいいという意見が多く見られるのに
なぜ16個も並列に動かして失敗して
問題にしてしまったのか?っていう Linuxカーネルのコードはパラレルmakeしても問題ないようにmakefile等が作られてる
パラレルmake非対応のソフトをパラレルmakeして問題が起こってるのとはわけが違う
ハードウェアが正常動作してれば問題が起こらないはずのところで、ハードが原因で問題が起こってる 自作板でやるからパーツ構成情報を併用した検証になるんであって
Linux板やソフトウェア板でやると中古動物電源使った構成でエラー出たーっていう人が幅を利かせるんだろう そもそもlinux板では話題にすらなってないから連中目線では良くある事なんだろ マザーボードが原因なのは間違いないだろ、NUMA nodeが怪しいという話は
どこに消えた? 中古動物電源w よっぽど電源にお金払いたくなかったんだろうな
新品でも動物電源なんて買う人いるのかって個人的には思うレベルなんだが >>972
HT切ればって方も誰も納得しないと思うが・・ 電源がなんたら言うやついるが、マザーボード側ださらに降圧して二次電源
で安定化計っている原理すらしらない池沼なの?
電源言うならマザーボード上の電源だろ、もしかしてケース電源の電圧のまま
メモリやらCPUに供給されているとか思った? >EPYC買うために今年の欧州の鯖の入れ替え予想シェアの10%を
>占める某社がインテルの猛烈なskylake-epプッシュかわして静観しているんだよな
IntelのXeonサーバーを含め全てに波及するHTバグ
AMDのB2ステップで解消されるSEGV問題
勝負あったな 若気の至りで自作初心者が値段だけ見て買う事はあるんじゃないかな
相当年数の間一貫して最悪な評価が変わってないのに未だに販売されてる方が凄いと思う >>982
全部まとめて回路描いてみろ
それでわからなきゃ電気語るな 今頃気づいたが6/9からDELLがRyzen PC販売開始している
大手PCメーカーが販売始めたなら現時点CPUには問題なしと判断している、という見方もできそうだが
http://www.itmedia.co.jp/pcuser/spv/1706/09/news094.html >>982
そうだけど今回は高負荷で常に引っ張られてるからPSUも重要
有名メーカーでも古ければ2時コンがヘタるし1時側の降圧と2時側のロードがタイミングぶつかれば容易に起こりうる
CPU内部のレギュレータや制御も可能性あるけど外部を潰してからじゃないと検証はできない >>989
PCメーカーなんて「売れればなんでもいい」としか思ってないよ
それこそ動物電源並みか、それ以下の電源積みやがるし >>989
デルはそんなの構わず売るよ
HPが使えば問題ないかもだけどね 今回の場合に限るが、この状況であえて疑惑の品を出してきてるならそうとも言えないと思うが
問題抱えているものを分かってて出して、後で交換やらで経費を損するのは他ならぬDELL自身だ
AMDは正常なCPUの無償提供はするだろうが経費までは支払ってくれんだろ 電源が問題だとおもうなら、最低でもリップルと過渡特性くらいは測れよ >>988
いまのエンジニアでは1人でできる規模じゃねーよ、
そんな単純なものと思ったの?
おれはイータ電気に1年派遣いっていたことあるぞ、 >>994
そんなことしなくても電源が問題なのは分かりきってるだろ PCメーカーが売ってるから問題ない、とするなら
動物電源クラスの電源も問題ない、と言う事になるが >>996
おまえの脳内回路がすごそうだな、どうやって分かりきる結論になったかの
根拠が民進党 1台のマシンが組み上がりました。。。
新しい筐体を用意してくださいです。。。。
自作PC板@2ch http://anago.2ch.net/jisaku/
life time: 5日 8時間 42分 9秒 2ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 2ちゃんねる専用ブラウザからの広告除去
★ 2ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.2ch.net/
▼ 浪人ログインはこちら ▼
https://login.2ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。