【エラッタ】Ryzen SEGV問題 Part.3【AMD】 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
今回の問題についてはAMDは回答保留続けてるな
パフォーマンスアップデートの時は素早い対応だったのにな B2steppingのRyzenで理想に近い形にすることを優先し新AGESAや新BIOSでの対応後回しとか https://twitter.com/CPCHardware/status/877623934736252928
I only said that a new B2 stepping will come soon, with many hardware bugs fixed. I don't understand which "claim" can be refuted さっさと移動しろカス
【エラッタ？】Ryzen SEGV検証Part.3【おま環？】 [無断転載禁止]©2ch.net
http://egg.2ch.net/test/read.cgi/jisaku/1498815128/ ／￣￣￣￣＼
／￣￣ /;;:: ／￣￣￣￣＼
／￣/;;:: |;;:: ｨ●/;;:: ／￣￣￣￣＼
/;;::: |;;:: ｨ●ｧ |;;:: |;;:: ｨ●/;;:: ::;ヽ
|;;:: ｨ●|;;:: |;;:: |;;:: |;;:: ｨ●ｧ ｨ●ｧ::;;|
|;;::: |;;:: c{ |;;::: |;;:: |;;:: ::;;|
|;;:: c|;;:: ＿__ヽ;;:: |;;::: |;;:: c{ っ ::;;|
|;;:: __ヽ;;:: ー /￣＼;;ヽ;;:: |;;:: ＿＿ ::;;;|
ヽ;;::: |￣＼;; / /￣＼;;ヽ;;:: ー ::;;／
|￣＼;;: | | | | / ／￣＼;;:: ::;;／￣|
| | | ＼ | ﾚ ／ |
| ＼ ＼ ＼..| / ／ ／ ／ |
.＼ ＼ ＼ | ./.／ ／ ／ ／
＼ ＼ ＼ .| ／ ／ ／ ／
＼ ＼ヽ|/ ／ ／ ／
(＿＿(__(＿＿) (＿＿_)
/￣/￣/￣／ ￣￣ヽ
/ / / ／ '、
. / / /／ ／￣￣￣￣￣￣| |
;' / ／ ／ ヽヽ| |
| / .／ ／ ヽ| |
|;／ ／ | | >>9
スレタイ見るに完全に荒しの立てたスレじゃねーか
こっちでいいわ なぜIntelを持ち出すのか
Ryzen SEGV問題なのに関係ないでしょ >>20
問題の切り分け
GCCエラーならIntel機でも発生するから 組み合わせると発生する、というアレなパターンもあるかもね？ 祭りの後のまったりモードになってるんだが、もう皆んな飽きたのかな >>25
業者・工作員・アフィブログ関係者など仕事で書き込んでるのが休みだとこうなるっぽい
よほど都合が悪いらしい
荒らしや狂信者は曜日関係なく来るが
先週の土日もこんな感じだった >>22
インテルに頼らないと問題の切り分けも出来ないAMD >>28
糖質の妄想かよ
単に社内ニートやら窓際族がむしゃくしゃして暇つぶしに荒らしてるだけだぞ 必死にlinuxのせいにしたりコンパイラのせいにしたがる人があっちのスレには多いな わざわざこんなCPUのエラッタスレで書き込まなくても
Intel使えば解決じゃないか ｀''ﾌ, ii ;;;Y/;;､;;;;;;(;;;;; ;; ;;;;;i|;;;i;;;;;;;;､t;;;;;;ii;;从､;;;;､､ 死 す イ
ﾉノij､､;;;; ;;;t ;;;;t;t;;ノﾉ;;;;ノtt;;;､升込ﾍ､从｀;;;;;ii
,,､､､ iyi)从;;;;i r'"iiii||||iiiヽ;;t'''"iiiiiii||||i體逡;; <;;;;;｀ ん で ン
r" '' ､ /ﾌ-i;;;;;i:ﾝ､zﾓﾃﾃ､;;t≦;;ｰ;rﾓﾃﾁゝz'" 〉;;;;;;
't ｀ ' ､ 从;;;;;;t:::｀:::"";;;;;ﾘΞ :::::::"",,,",ノ" i;;;;;ﾘ, で に テ
ヽ, ､ 刈ii､t::::::::::::::;;; i:: :::::::::::::::'" i;;;;/ﾉ
' ､ ,,､､::''' ヽ, i;;ヽ, ;､::::::::::::;; i､__,,,_ :::: ::::: i;r"／;; い ル
~' ､""" :::;;; ヽ, t; ;;;｀it ::::::::ヽ､;;;~'' ::: /~r;;;;;;;;;;
,,､--､,,,,､'ヽ, '' ､, ノi; ;;;| t :: ,,ii,,,,, / |;;i;;;;;;;;;;;;; る は
ｰ'";; ;;''''';;;; ''"ヽ;;;;;;'''"",, ヽ, ヽ;;;i ;t ''";;",｀' - /;;:::ヽﾘ;;;;;;;;;;;;,,,
;; ;; ;;" ;;; ｀t''''"" ~'' ,, ヽ,,rr"iiitt､r"t;;;i ヽ '' ;;~;; ''ｰ ,, ';;:::: "i|;;;;;;;;;;ヽ"" ！
,,r" / :::ヽ;;tヽ､,,,,,､､-'",, ヽ,ｰ-;;､iiii"ヽii;;ヽ;;ヽ r';;;; ,,r";;::::::: i|ﾚ"|;;;;ﾉ
" / ::::: i;｀''-､;;;;;;;;;;;;'":::､, t ~'' ､;;;;ii"ii:::ヽヽ,ヽ-ｰ ,､ ';;; :::: ::: |'"ヽ''';;-､､,,,,,,,,,,,,,,
/ ::: ﾉ''ｰ､;;;;;;､,,,,,,,:::::: t ''"""'ヽ;;;; ""ii::;;;~~~~~~";;;;; ::::::::''" ::: |;;;;""''ヽ;;;~'- ､＝=~､''''' ｰ ､ エラッタスレと認識しながらintelCPUで代用する話をする意味はあるのだろうか >>32
HWにしては合理的な説明がつかないから仕方ないね そうはいってもLinuxやコンパイラに起因するというほうがよっぽど合理的な説明がつかないからな
まだメモリや電源の相性ってほうがあり得ると思う >>37
どうもgcc7.1.1なら通るとか言ってるからそれで良いんじゃね(適当
まぁそもそも確か2NUMAとか正しく無い認識してるから、何処まで正しいかは神のみぞ知るだ
dmesgをMSRとか設定レジスタでgrepしてみたい
変な値書き込んで無いだろうな IntelだってHTエラッタは問題が取り沙汰されるまで放置
残り149のエラッタも具体的な症状が出るまで放置だからな
実際にそれで問題無いし
AMDもGCC以外で不具合発生した時に迅速な対応さえしてくれれば問題無いよ 問題が出ている人のうちある人は
カーネル4.8.0
gcc-5.4.0
ubuntu 16.4
ryzen に対応していないころの
Linux だよね
これで騒いでいる Ryzenの場合は、ユーザーが問題を指摘しAMDが隠蔽しているのが問題
intelの場合はintel自身が発見し、原因も明確になっており、対策もintel主導で行う
この差 >>42
隠蔽じゃなく何言ってんだこいつらってヤツだろうな
というかAMDの公式資料が今年3月付で軒並み更新されてるの、織り込んで有るんだろうな?
無きゃバグって当たり前だぞ pentiumの誤差問題は、ユーザーが発見、
原因追求で、インテルは、ホッカブリ Linux4.12 がリリースされたが
この問題の対策はされていない感じ
カーネルのバグでないのか？ >>44
つまり、AMDはintelの20年前レベルだと （ / )
〉 口 禁 開 う {_ 〈 | 作 じ
低 プ / .に 句 発 わ/ } | れ ゃ
| ラ | し .あ 者 i < ん お
| イ | た. っ の | } の 前
い .ド 〉 | さ 〉 ﾉ か ら
,-〈） り / ´ﾆ よ
￣ヽ（￣jﾊN_冫 ＿_,.‐＜ ／:::::｀⌒i ＿_
i! i! i! ,.ｨ/ｰｲ７::::'⌒V:::::r‐く (_ !从ﾄ､ﾄ､､ﾊﾄ､ﾊ⌒Ｙ´
i! i!／ /＂ Ｌ1:::::::::::::,.乂辷| ( {●} {● }=}
i! iﾊ { | {:::::::::::::〈 {￣ｰう´ r' r=＝ﾍ u r'
i!/ｰ' ∵! ヾ:::::::::::/｀ur=┘ 八u jr､＿__} /-､
U / _从ﾊ/ ､ /_ r-ヱ三三≦-'⌒ヽ
/／:::ヾー--へく ７ｧ‐/j i ,__））:.:.:.:ﾉ
//::::::::::::::::￣￣::::::ヽ /:.:}:ゝ⊃´`ー‐1
ＡＭＤ インテル >>46
うん だからこんな会社のCPU買って文句つけるよりIntel買えば？ コンパイラのターゲットCPUモデルがRyzenに未対応だったってことだろ 結局IntelもskylakeとkabylakeにHTTエラッタとかあるんだから好きな方選べよ >>46
> >>44
> つまり、AMDはintelの20年前レベルだと
確かに、インテルatom c2000みたいに突然死する
エラッタなら検証も糞もなく簡単だわな。進歩的。 >>50
そんな理由では命令ポイントがおかしくはならない ビルド中に発生するんだからターゲットなんて関係ないじゃん >>56
どんなおかしな命令が来ようとも、命令ポイントなどのレジスタやスタックの状態と、そこに至るまでの命令とが矛盾してる状態にはならない
そこが明らかにおかしくなってる（としか思えない現象に直面してる）からこそ、CPUの内部で何か変なことになってないかが疑われてるわけで
単なるセグフォ自体はプログラムのバグなどでも起こるが、そんな問題だったらとっくに決着してる 例えばARMの機械語突っ込んだって一発目でイリーガルオペレーションだのなんだのの例外で落ちるだろうけど、CPUはそのときになるべくしてなる状態になってるわけよ
非対応なターゲットだからといってレジスタやスタックのが矛盾してる状態にはならない その通り！
解析してるつもりの人たちは、直接的な解析が出来ないからトンチンカンなテストをしてる
素人の解析ごっこ >>52
全OSに影響出るし修正されていないからHTはヤバイだろ… ヤバくない
発生原理がわかっていて、非常にマレだと言うことがわかっている
普通のコードでは発生しない 実用的なコードでもわりと出る
発生要因は明らかではない
そもそも現状AMDが認めてないから修正されるのかも定かではない
全くHTのエラッタとは違うだろう >>58
本当にそうか?
例えば24594に今年更新されたC3のモデファイとか、24593-7.6.1とか7.4.1とか >>67
文書のセクションだけ挙げられても何が言いたいか分からない
具体的な指摘を >>68
つーことはアレを読んでないんだな
折角公開されてるんだから自分で調べなさいな
其々がデカ過ぎて書ききれない上に結構多い上に俺もよくわからない
臭いと思ったのは24593の7.6.1、Cache Organization and Operationのとことかかな
それっぽいこと書いてある、ように見える >>61
直接的な解析ができるのはAMDしかないじゃん
>>62
発生条件はインテルがエラッタで公開してる
めったにつかわれないレガシー命令でしか発現しない
またBIOS/マイクロコードアップデートがすでに出始めてる >>71
操作Aでエラッタにひっかかる、これが検証されたとしても
他の検証されていない操作でエラッタに引っかかる可能性は無いとは言えない
今回のHTT問題もそうだけど、この前のSkylakeでPrime95でFFT size=768Kで止まるエラッタも、他が引っかからないという証明にはならない
エラーが起きるという証明は検証コードがあれば簡単に出来るけど、エラーが起きないという証明は簡単には出来ない(悪魔の証明)
最近のCPUは複雑すぎるんだよ
>>69
キャッシュをオフに出来れば判断出来るけど、オフれないからな・・・ >>73
それはどういうこと？
>>74
＞他の検証されていない操作でエラッタに引っかかる可能性は無いとは言えない
とかを言い出すとそれはもう究極的には未知の不具合が存在するかもしれないでしょ？ってところに行きつくわけで
もはやそれはどんなプロセッサでも同じ
SEGVは将来見つかるかもしれない危険性ではなく、今実際に不可解な現象が起こっていて
それがまだどういう要因なのかAMDによる公式な見解が示されていないってのが一番問題なんだよ AMDの文書読んでみても、
スレッド間で命令領域を書き換える場合は同期を取って、
そのうえでserializing instructionを実行せよっていうずっと昔からのx86の仕様が書かれているだけにしか読み取れない。
もちろんOSはそんなことは百も承知だし、今までのプロセッサでは問題なく動いていた。
命令キャッシュ等のserializingに関して、今までの仕様から変更になったという情報はどこかにあるのか？ そう思うならこんな所に居ずにIntelのCPU使えば…
なんでこんな所でくだ巻いてるのか理解ができん CUDA蒔こうぜ！
まったく税金さまは最高だぜヒャッハー >>78
なぜってRYZEN買って使ってるからだよ
問題あるのかないのか、あるなら直るのか、AMDにはっきりしてほしいと思うことはいかんのか？ なんだよ結局問題なかったのか
CPUに問題があって欲しかった人は騒いでいるようだが >>80
持ってるなら確認すりゃ良いぞ、問題有ったらRMAすりゃ良いべ？
無ければそのまま使っとけ 関係あるのか知らないがなんか来てる
Scheduler Improvements Set For Linux 4.13
http://www.phoronix.com/scan.php?page=news_item&;px=Linux-4.13-Scheduler-Work
scheduler changes for v4.13
http://lkml.iu.edu/hypermail/linux/kernel/1707.0/00517.html >>82
普通に問題出てるからここに来てるんだよ
AMDに交換しても変わらないらしいじゃん、めんどいよ >>86
めんどいなら売っぱらってIntel買えば解決 よし、じゃあ俺がintelでマザボとCPUの構成考えるから、
その購入金額で俺のRYZENとマザーをお前が買い取れ >>75
命令ポイントなんて言葉は初めて目にしたってこと >>89
あ、それは単なる予測変換か何かのミス
言われるまで気づかんかった 問題出てるんだろ？愚痴る位ならAMDに言って交換してもらうなりしろよ・・・
現時点で発生原因がバラバラだから公式発表が出来ないのが現状だぞ
（メモリクロック下げたら治った？新しいコンパイラで治った？とかいう状態） あと交換でステッピング変わらないということはAMDでは問題なしの可能性もあるし
違う石で試してね という意思表示の可能性もあるし
まず何が問題出てるのかをAMDへ報告しないと始まらない AMDに報告してるやつは俺以外に何人かいて、
芳しい結果が得られていない現状ではわざわざ不慣れな英語でサポートに連絡する気は起きない
芳しい結果とは、現象の再現を確認したと明言されたり問題が起こらない交換品が届くなど。
まあそれはいいとして、一番愚痴りたくなるのは、AMDがどうこうという以前に、
・結局〇〇だっただけだろ的にまとめようとするやつ（例：コンパイラのターゲットの不一致）
・AMDのドキュメント読めばそれっぽいヒントあると匂わせるだけのやつ（でも具体的な提示は無し）
・ならうっぱらってintel買え（じゃあお前がきっちり新パーツと同額で買い取るのか）
とかいうできもしない／知りもしないくせにAMDのサポートの代弁者になったかのような奴に対してだわ 自動翻訳を使うんだ 案外通るらしいぞ（始めに自動翻訳ですとか書くと効果大）
あと>>93の考えだと原因確定して当に公式発表されてると思われ いくらなんでも無言はない
そしてここにいると愚痴りたくなるからスレから離れた方がいい そもそもエラッタ関係ないハード面の不具合かもしれんしな
ここに常駐してストレス貯めるとかドMかよって話 >>93
fedoraじゃ問題ない報告上がってるが一切触れないとかどういうことですかね？
sat一味さん UbuntuやGentooでエラーが出た環境でFedoraに変えたら問題が出なかったという意味かい？
そうでないなら説得力ないな gentooでのエラーはgccをubuntuのモノ
でやった結果
ゆえにフォーラムではgcc が犯人に
された
なぜgentooのgccでないのか不明 >>97
sat一味とかいうのもよく分からんし、なんで俺が触れなきゃいかんのよ
触れたい人がいたら勝手に触れろよ
fedoraじゃ問題ないっぽい（ついでにいうとUbuntuのlow latency kernelとかもね）、
ってだけじゃ何の解決にもならんでしょ
そこから掘り下げて要因が解明されてLinux全般で安全にRYZENが使えるようになる、
とかまで行って初めて解決でしょ（さらにWindowsは大丈夫なのかって話もあるし）
現時点ではメモリクロック変えたら直ったとかCPU挿し直したら直ったとかそのレベルの話でしかない
>>98
一応そういうことみたいよ あーほんと、
＞fedoraじゃ問題ない報告上がってるが一切触れないとかどういうことですかね？
こいつもAMDのサポート気取りの何の役にも立たないやつ
じゃあお前がUbuntu系のKernelとfedoraで何が違うか調べて検証して
さっさとLKMLにでもパッチ投げて解決してこい
できもしないくせに解決者を気取るな それももちろん検討の余地はあると思うが、
RYZENって固有名詞に触れていないことがちょっと試してみたい気力がいまいちわかない要因になっている
そのうちだれかやるだろうし、俺もやるかもしれん ID:YcxpY/oHはマゾなんですかね…
わざわざイラつく板を見るとか sat周辺は火傷してるなぁ
無理矢理すぎてここまで来ると痛いわ Ryzen用カーネルビルド
Linux4.12 用の .config をfedora から
持ってきたけど、Ryzen 用には他に
設定するオプションはありますか 最も影響しそうなEPYC周りで噂にすら登ってないからサーバーサイドじゃ問題なしということなんだろう 但しEPYCに正式対応したバージョンのOS・ディストリビューションを使うのが前提っぽい
なんだけどRHEL・CentOS・Fedora辺りを見てもEPYCに何も触れてない
探し方が下手なのかもしれんが
対応バージョン出てるなら欲しいんだよね EPYC向けに最適化したカスタムバージョンとか使うんじゃない 仮にそうだとしてもEPYCシステム買った人にしか配布しないとかは止めてほしい
OSSでそれはないと思いたいが
とりあえず7/11にFedora26が正式版になるようだからそれを様子見かな EPYCクラスになると性能命だから
汎用なんか使わんだろう
4coreの仮想立てるなら全部1CCXに押し込むとか
そういう処理が前提のEPYCだし ASLRを有効にするとSEGV率が増える
PIEなコードを実行するとSEGV率が減る
FedoraやDebianがSEGV起きにくいのは、主要プログラムはPIEが有効になってるからでしょ？ Ryzen買おうか迷ってこのスレ覗いたら何が何だかわからなくてワロタ >>115
一般用途なら出会わないし、この問題はLinuxユーザーの中のごく一部の人が騒いでる話
話そのものも信憑性が怪しい(騒いでいる人の頭がバグっていると言う批判もあり)
因みにLinuxのユーザーはこの程度なので気にする必要なし。
ttp://gs.statcounter.com/os-market-share/desktop/worldwide/
Windows 83.92%
OS X 11.76%
Linux 1.66% いや、そんなこと言われても俺は困ってるんで
お前がこの問題と無縁なのは分かったから下らん嫌がらせしてないで他所へ行ってくれよ >>118
Intelスレに出張する暇あったらしっかり火消し頑張れよ >>117
具体的に何でお困り？
あと何故か2chでは大きい面しているけどAMDに問い合わせしていないよね ランダムSEGV出るって時点でサーバ用途では使い物にならないんだよ Linux４.11.9 でKASLR のバグフィックス
でこの問題は解決しないですか？ Fedora -Rawhide の最新版を見ると
Linux-4.13 とカーネルが新しすぎる
4.12の間違い？ メモリにしろUSBにしろ一段耐性が低い時点で正直なあ
おま環の頻度が高い時点で十分問題だわ このエラッタでおらの大事なエロデータが破損するってマジですか？ >>140
エロデータだけは全く無傷に済みます。
君の童貞と同じです。 検証と言いつつ自分が何をやってるのか全く理解して無い感じ >>133の人再現したってコアダンプとログ出してる
誰か解析はよ Linux4.10 なカーネルはSMTに不具合
あったり、電圧や温度などのセンサ情報が
取得できないなど今ひとつでは？ 素人の検証ごっこに拘泥して本筋見失ってるな
自作板でこういう検証は向かないと言えばそれまでの話だが AMDのBIOS/AGESA/XMPあたりの実装がタコで、正常動作しないことがある条件の周波数・電圧・タイミングを設定してしまう
よってそういった状態になったときにまれにエラーが起こる
の可能性かな >>150
(DDR4自体結構アレだから多少はね?) Ivyで発生した件はメモリ廻りの環境情報が一切無いのかね？ >>154
そもそもハードの問題の有無はさておき
Cの規格定義外のコードを
枯れてないコンパイラでビルドして
動作の安定してないカーネルで動かして
正常動作を保証する方が無理がある ソフトのバグだと思うならそういう切り分けをすればいいのに
誰もしない
さすが素人の解析ごっこ ハードウェアの問題かもしれないけどあまりにも検証環境が杜撰すぎて参考にならない。
せめてQVLリストのメモリと最新の安定版BIOSくらいは準備して。
再現性のためにBIOSバージョンそろえるのは良いけど新しいBIOSで、設定で、出ないなら改善された、つまりソフトの成熟でカバーできる程度の問題かおま環ってことじゃないのか？ ハードを疑うなら
全て同じ構成でパーツも全て同一ロットに揃えた端末を複数台用意して検証しないとね >>158
ハードウェア知識の全くない自称プログラマーが発生したって騒いでいるくらいの認識で良い >>159
そんな大がかりじゃなくてもソフトかハードかは切り分け可能と思うが >>160
ハードの知識が無くても、ソフトの知識があれば、ソフトかハードかの切り分けは可能
ソフトの知識があれば >>162
可能じゃない問題を除外しちゃダメでしょ。
騒いでいる方々は現状で切り分けできていないから、ある程度はハードウェア知識は必要だと思うし、多分ソフト側の知識も微妙で一方的な見方しかしないと思う実際 とりあえず中古動物電源使用でエラー出てますはそうですねとしか言いようがない ハードの知識も、あれば当然役立つ
このスレ中にハードの知識を解析に役立ててる感じは一切無いけど >>165
深い意味はない
可能と言い切るのはだめってだけ いずれにしろ、ハードとソフト両方の素人が集まっても解決しない
実際今まで何の切り分けも出来てない 何だかんだで再現性ない→おま環
が一番しっくりくるでしょ 基本的に物理ベースがあってこそだかんな
切り分けはまずHW、次にSWだよ >>169
再現が難しいバグ、エラッタなんていくらでもある
おま環や相性ってことにするのは簡単だろうが、原因は必ずある >>171
能力の無い者の言い訳
普通、製品の開発の初期段階ってのはどっちも完成されてない
そんな中で原因を突き止めて対策をしていかなきゃならん >>174
どんなケースでもソースから手繰るのは基礎中の基礎だろう
ソースってのは何らかの供給からって事な
問題ないと目される場合はスキップするけど、こういう難航する場合は当然根っこに近い方から当たる
開発だ何だは知ったことではない、決まった仕様に向かって積み上げてるワケでもあるまい
トラブルシュートと無関係なものを混同するな >>161
ハードを疑うなら
現状おま環でなんだからちゃんとした検証するなら必要
最初の言い出しっぺがryzenでのみ起きる！って言ってたんだから
まずそこでしょ >>161
ivyでも起こってるのにエラッタ言うのは貴方ですよね ホント素人の検証ごっこだよね
プログラム出してる人間がイマイチ解ってない感じだし
言い出しっぺもアレな感じだし
さらにはクソコテが荒らしてるしねぇ おま環トラブルに便乗した土人のネガキャンやろこんなもん
未だにエラーの再現すらまともに報告出てきてねーじゃねーかよ 恐らくAMDからアナウンスが無いのもAMD自身も追試してて「？？？」ってなってんじゃないのかね？ ろくに原因の切り分けが出来ないソフト屋が騒いでいるだけだ >>183
というか間違い無いだろ
普通に考えればこれだけ多種多様な現象が頻度バラバラで起こるとなれば疑うべきは共通じゃ無い点
つまり石でもSWでもなく組み合わせでエラーの出る可能性があるもの
そんなもんメモリしか無い >>186
VRMの品質とか、電源の品質とかもあるぞ。 >>188
そういえば中古のクソ電源って話もあったな
VRMは多分大丈夫、報告者の傾向漁ろうと集めた時にあまり傾向に違いは無かった
メモリの含めても多種多様な出方したりとか出なかったりとか >>189
CPUのバグかわからない＆＆おま環の可能性があるくらい再現性がない＆＆キャッシュ絡み？
となると、電源電圧が一瞬だけ下がってバグるのが一番可能性高いぞ。
で、それは、突発的な消費電流の増加か、消費電流の変動幅がマザーかVRMの想定外である事が可能性が高く、
要は、CPUの消費電流変動に（ナノ秒単位で）電源系がついて行けないような、微妙な品質の電源系だという感じに。
マイクロコードやEFI側でなんとかできるかもしれないし、できないかもしれない。 電源だと思うなら、エラーの瞬間をオシロで見てみるのが普通の発想 トリガーさえちゃんとかけられれば100MHzくらいの安物でも十分
トリガーはソフトの力が必要 >>195
200MHzのオシロでも、今ですらバカ高いから、普通にハードウェア開発のお仕事してても、予想通りとしても、簡単には現象追えないと思うよ。
まあ、マザボ屋さんやAMDにはもっと高速なのがあるだろうけど。
そもそも、トリガー条件設定自体が大変かも。 >>193
最近だとHaswellのC6/7ステートで不具合を起こす電源とかもありましたしそういうものかもしれないですね ビルド中にC6/C7ステートですか
変わった省電力仕様ですね >>193
今回のはその辺LDOが入ってるから、先ずこいつらを固定化するところから
でも出てない環境がある以上こいつらは正しく機能していると考えるのが無難
つまり自動制御でヘッドルームはある程度担保してる
LDO無しの電源系もあり得るけど、そっちもセンサーついてる筈だし
しかも今回はMiMCapで対策してある
まぁ出まくる人は流石にメモリだけに限らずこの辺全部の複合要因だろうけど
バリエーションから言って主要因とは考えにくい Skylakeバグは複雑だったけど、再現は容易だった。
いかなる環境でも必ずPrime95を特定の設定で回せば再現したからね。 >>195
GHzで動いてるようなCPUだし、ダイの中の電圧計測とか素人じゃ無理 そこらのオシロじゃ数十Mhzオーダーぐらいだもんな GHz帯の観測はほぼ無理よ
それにダイの中だしな
だからこそ昨今の石には色々付いてるんだが 結局satって人が成り上がりたい一心で鬼の首を取ったように騒いだけど
一部の取り巻きにしか相手にされてないって状態なのかな？ >>208 >>210
ダイの内部の電圧を測る？
発想がぶっ飛んでて笑える Ryenのキャッシュ周りに設計上の不具合が？ →AMD「間違い。些細な不具合は逐次更新」
↓次
Windows10に欠陥があるからRyzen真の潜在能力が発揮されない！ →AMD「間違い。Win10に問題はない。早期に修正BIOS提供」
↓次
ベンチマークが落ちたアプリに問題があるんだ！ →AMD「間違い。CPUの特殊構造がもたらす現象でありAMD当社自信も驚いてる。開発者と密接に協力している最中だ」
↓次
SEGV問題！ →AMD「… … …。」
↓
AMDが暫定的にエラーが出ないものを様々準備してきたぞ… →Coming Soon.... 【悲報】AMD Ryzenにエラッタ発覚。ランダムにプログラムが壊れる。BIOSでは直せないので交換対応も開始 [無断転載禁止]©2ch.net [303515234]
https://leia.2ch.net/test/read.cgi/poverty/1499999953/ ほんと、チンピラの言いがかりレベルのはなしだらけで草 おい淫厨
skylake-xスレ早く建てろよいじって遊べないだろうが ソース https://zigsow.jp/item/331838/review/333142
>ryzen-problem-repro3
>https://gist.github.com/satoru-takeuchi/23afbf565c2d97c3ef16e5d46d11f5bf
>を用いて、Linuxカーネル4.11を688回ビルドしてみたもののSEGVは1回も発生せず。
>たぶん、接触不良辺りや、電源やメモリの相性じゃないの？と思いつつもしばらく安穏としていたが……
>ある日突然、某氏から報せが届く
>SEGVが出るコードが出来上がってしまいました haya @homuh0mu
>https://twitter.com/homuh0mu/status/879330494789308416
>を実行。約18分経過後、ctrl+cで強制終了して出力されたlog.txtを確認……
>311,699 OK / 29 NG
>どうやら、うちのRyzenでSEGVが発生する確率は約0.0093%の様です。
>BOINC的にはあまり無視できないですね。約1万回処理して約1個SEGVが発生するという確率です。
１万回に１回おきるなら、確認するのは困難だ、そんなの無視しておけ。気が付かないなら問題ない。 >>219
遊びで使うなら問題ない。安心して使ってヨシ 対応されたばかりのLinuxでエラーが
出て、Ryzen のバグだと騒がれて
AMD可哀想
誰もRyzen対応が完璧だと思わないはず
AMDはLinuxには関係ないはずで
CPUを交換してくれるのは
AMDのせめても誠意ある対応だと思う ソース https://twitter.com/satoru_takeuchi/status/885635422419693569
>おかわりのテスト結果サマリ。全然現象が変わった - SEGV出ない
>- uop cache tag parity errorが頻繁に出る(corrected) - ランダムにハングアップ
またインテル信者のデマかよ しつこすぎるぞ >>219
>haya@homuh0mu 6月26日
>返信先: @homuh0muさん
>前回のからあまり変更はありませんが、スレッド数を1増やしたのと、メインスレッドのほうでsched_setaffinityを呼んでいるところが主な差分です。
>この状態でUbuntu17.04とその標準のgccでビルドして「./run.sh 8 2500000」をするとSEGV出ます。
コレ以外の設定じゃ出ないそうですね
この限定された方法で稀に出たとして、それが実使用でどれほどの脅威になるのだろうか う～ん。頻度云々はともかくも、
再現性試験が出来て、明確な回避策さえあれば良いだけなんだよねー
理由が説明出来る、対策も説明できるなら別に困らない
理由が解らないってのが一番困る
因みにこちらでやっているテストでは１度も起きていない
ただ高負荷って言ってもコンパイルなんてやらないしな…
実機ではApache2とか特定のserviceだとかしか動かさない
そこに負荷をいくら書けてもでないのよね…とほほ 許さんぞ…
sat
homuh0mu
EIRAKU AMD Ryzen Master でキチンとノーマルな
設定し直してLinuxに挑戦だよね 困るのは普段の使用で出るエラーで、出ないなら困ることもないのでは
サーバー企業ですら、止まること前提で多重化して組んでるから、個人レベルで止まらないことを要求しても仕方ないと思う
本当に困るなら、AMDとそれなりのサポート契約した方がいいでしょう >>228
>困るのは普段の使用で出るエラーで、出ないなら困ることもないのでは
ぜったに出ないよ、問題ない、数万分の１の確率だから隕石にあたるようなものだ
俺が保証してあげたい そもそもクソ高い業務用ソフトでさえ再現性のないバグは取り合ってもらえないからなあ
言うまでも無いがここで言う再現性ってのは
同じ事をやって必ず同じバグが出るって事な CPU以外全取っかえでも発生率が変わらないならともかく、メモリや電源交換で割りと減ったり出なくなったりしてたから、メーカーも本気で対策する気はないだろうね dellとかhpのPCで再現性のある不具合が出るならまた違ってくるだろうね
現状ではFUDを疑われても仕方がないよ >>212
それより、CPUに供給される電流を、系統ごとに、なおかつ一桁ナノ秒単位で計測した方がまだいいよ。 検証は、進めてほしい。
結構タメになる。
気に食わない奴は、見なきゃいいだけ。 ソフトの信頼性の無さとか安定したハード環境の構築という点では役に立つかもね
検証という意味ではまさにごっこ遊びの域を出ない うちのK6-2でやったらSEGVでた、すごいなこれ Ryzen
K6-2
i7 3770k
最近のi7 (3770kのテストの動機になったやつ）
本当にCPUは欠陥だらけだなけしからん！ 兎に角欲しいのは再現性試験手順！これだけ！
これが無いならFUDとして見られて当然。
今出来ないなら、出来るようになってから言うのが筋ではないか？ >>240
3220Tも落ちたようだ
cpu_segv_testに改名しよう あっぽーれーくもおちたぞ
LockSpinnerにしろよ https://egg.2ch.net/test/read.cgi/jisaku/1500079362/16
16 : Socket774 (ﾜｯﾁｮｲ dfec-Xm5V)2017/07/16(日) 09:02:43.48 ID:sWuKSMyk0
この流れ楽しいな。ryzen_segv_test はしばらく眺めていようっと。笑
https://twitter.com/satoru_takeuchi/status/886119579075792896
> @homuh0mu AMDフォーラムでryzen_segv_testが話題になっています。AMDのエンジニアにも存在が知れてそうな雰囲気。ご参考まで。
私はこのプログラムの内容を理解できていないので静観してるだけです。すいません
https://twitter.com/homuh0mu/status/886149374450909184
> ありがとうございます。存じております。ひとまずこちらとしても聞かれたことはできるだけ答え、あとは見守ることしかできないですね。
話題になっています = 2 posts しかないユーザー
https://community.amd.com/people/cl0p3z/activity ryzen_segv_testが海外に放った悲劇
186. 他のプロジェクトをGitHubで見つけたぞ - hayamdk/ryzen_segv_test: RYZEN SEGV test code (英語の説明が最後にある).
これが何なのか確かではないが、見る限り非常に特定の、分離されたryzenのsegfaultバグの再現コードなのか？？
クラッシュする問題を抱えている誰か、こいつがryzenでクラッシュする問題なのか確認できないか？
190. ryzen_segv_test不可試験でsegfaultの再現が可能だぞ。
Ubuntu 16.04 with kernel 4.11.10
Ryzen 7 1700
Gigabyte GA-AX370-Gaming K7
Kingston DDR4 2x16GB 2133MHz (ECC)
latest BIOS with AGESA 1006
あのコードでの負荷試験に使ったコマンドは ./run.sh 16 1000000000
とんでもない失望だ。AMDは早く修正するか、非常に多くの顧客を失うことになるだろう。 >>248
192. ryzen_segv_testでの試験でsegfaultの再現にどのくらいの時間がかかるのか？
githubでちょうどこれを見つけられて幸運だった。(ryzenとついている名前のプロジェクトをスター数で並び替えた)
なぜ我々はこれに気付かなかったのだろうか？言葉の壁なのだろうか？
これは本当に分離された、かつ、直接的なこのバグに対する試験のように見える。AMDのエンジニアはすでにこれを認識しているだろうと思う。
193. > これは本当に分離された、かつ、直接的なこのバグに対する試験のように見える。AMDのエンジニアはすでにこれを認識しているだろうと思う。
彼らは認識していると確信しているが、100%確実にしなければ… >>249
196. こいつはsegfaultさせるために using ./run.sh 16 1000000000 でだいたい 10-20分かかる。
スレッドの数は16でなければならない。さもなければsegfaultを起こすのに非常に長い時間がかかる。反復回数もまた十分に長くしなければならない。実行中のCPU使用率はほとんど100%になるが、CPUは熱くはならなかった。AMDのクーラーは熱くならなかった。
私はAMDがこの失敗の根本原因を認識してないことが信じられません。サーバープラットフォームのEPYCは同じコアを使う。私はThreadripperをワークステーションとして、EPYCをサーバーとして買いたい。だが、この問題が解決されるまで買うつもりはない。
197. Ubuntu 17.04に最新のカーネル4.12他全てで、私は最初の"NG"を見るのに6分かかったよ
198. > (ryzen_segv_testの結果を受けて)
我々は速いコンピューターがほしかったから、いくつかのRyzenを買って目的に合っているか試しているのに。
現時点ではそうじゃない！
我々はこの問題が解決されるまで今後一切Ryzenベースのマシンを買わない。 >>250
200. > (ryzen_segv_testの結果を受けて)
こりゃクラッシュ祭りだよ！
(以下、Ryzen関係ないryzen_segv_testのsegfaultのログが大量投下)
202. 数日前に日本語の部分が更新されたが、Q&Aの部分は英語にまだ訳されていないね。
IntelのCPUでも試験をしているが、明らかに誰かが3770Kでsegfaultsを起こしていると報告しているが、作者はそのチップを持っていないためIntelベースのマシンで問題を再現できていないらしい
203. 24時間も走らせているが、私のRyzen 1600では何の問題も再現できていない。オプション6も12も試してみたが、失敗しない。
私は問題は2つあると思っていたが、今はそれが3つになったと考えている。 >>251
206. >>203
どのコンパイラを使っているのだ？うちではgcc 7はクラッシュしないが、gcc 6.3はする
207. >>200
1つ情報を追加しよう: あのツール(gcc-7.1.1)を使ってもsegfaultsは一度も起きなかった。書かれているパラメータで3時間走らせたよ。うちのシステムは R7 1800X, Asus X370 Pro, BIOS 0805, 32GB 2400MHz RAM, オーバークロックはなし、ファンレスの冷却だ
208. 私は gcc 4.9.4 を使っている。これが違いなのだろう
209. どうやらこの試験は gcc 6.3でビルドした際に効果的らしいぞ
これを見てくれ https://github.com/hayamdk/ryzen_segv_test/issues/2#issuecomment-315509679 >>252
211. ryzen_segv_testを1時間も走らせているが何のエラーも見られない。私はどれだけ待てばエラーを見られるのか？私の環境:
Ryzen 1700X
Asus Prime X370-Pro, BIOS 0805, Agesa 1.0.0.6a
RAM: 2*8GB Corsair CMK16GX4M2B3200C16 at 2933 MHz, RAM voltage 1.35V, SOC voltage 0.9V
No CPU overclock, auto voltage
Debian 9, default kernel (inux ryzenpc 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x86_64 GNU/Linux)
212. ryzen_segv_testでの再現に成功した
932251: Fr 14. Jul 23:28:58 CEST 2017: NG
1369764: Sa 15. Jul 04:16:48 CEST 2017: NG
14日の金曜日、13:20に開始した。パラメータは 16 20000だ
Linux ryzen 4.11.9-1-ARCH #1 SMP PREEMPT Wed Jul 5 18:23:08 CEST 2017 x86_64 GNU/Linux
Ryzenを持ってから、安定性の問題を多数抱えてきた。うちのシステムは[1]に書かれてる。そして、CPUを含むほとんど全ての環境を切り替えたよ。
[1] Ryzen Instability MCE bea0000000000108? What do do next?
https://community.amd.com/thread/216084
これらの問題が修正されるとは信じられない。あまりにも多くの時間をすでに浪費した… この発言最高だよな
https://community.amd.com/thread/215773?start=203
> I used to think there were two issues. Now I'm thinking it's three.
> 私は問題は2つあると思っていたが、今はそれが3つになったと考えている。 @homuh0muの放ったコードによる地獄
お気に入りの発言
> とんでもない失望だ。AMDは早く修正するか、非常に多くの顧客を失うことになるだろう。
> これは本当に分離された、かつ、直接的なこのバグに対する試験のように見える。AMDのエンジニアはすでにこれを認識しているだろうと思う。
> 私はAMDがこの失敗の根本原因を認識してないことが信じられません。
> 私はThreadripperをワークステーションとして、EPYCをサーバーとして買いたい。だが、この問題が解決されるまで買うつもりはない。
> 我々はこの問題が解決されるまで今後一切Ryzenベースのマシンを買わない。
> こりゃクラッシュ祭りだよ！ B2ステッピングで修正済み→EPYCはB2ステッピングで問題なし、Ryzenは文句言ってきた奴だけ交換
B2ステッピングでも未修正→EPYC発売延期、バグ修正したB3ステッピング製造、EPYCはB3ステッピングに
さてどれだ？ BIOS/マイクロコードでOp Cache無効化アップデート、パフォーマンスがbulldozerクラスに落ちる
これやってほしいな 結局どっちが悪いのAMDが悪で全品リコールで決着ついたの？ ダンゴムシが来て一気にクソスレ化
というかあいつが来たからこの問題は収束に向かうな 電圧上げると解決する事案が多いから
どちらかというとμops cache部の電圧を削りすぎ or 電力供給不足が原因っぽいよ >>266
安易に何処がってのにはまだ早いな
そうだとするともっと解決は早かった筈だ
それに、普通に考えればそんな状態ならMCAにバカスカエラーが出るだろう 結論、SEGV問題は事実として存在する、AMDはエラッタにしないが交換に応じる
原因は2chユーザーによって曖昧のまま解決には至らない >>269
Intelも起きるのでIntelCPUもエラッタしてますね 【インテル広報室】
ｶﾀｶﾀ ∧＿∧ ｶﾀｶﾀ ∧＿∧ ｶﾀｶﾀ∧＿∧
（ ｀Д´ ） ｶﾀｶﾀ （ ｀Д´ ） ｶﾀｶﾀ （ ｀Д´ ） ｶﾀｶﾀ
＿|￣￣||＿）____ ＿|￣￣||＿）____ ___|￣￣||／_）__
／旦|――||/／ ／| ／旦|――|l/／ ／| ／旦|――||/／.／|
|￣￣擁護￣|￣| . | |￣￣煽り ￣l￣| . | |￣￣ うそ￣|￣| . |
|＿＿＿＿＿|三|／ |＿＿＿＿＿|三|／ l＿＿＿＿＿|三|／
ｶﾀｶﾀ ∧＿∧ ｶﾀｶﾀ ∧＿∧ ｶﾀｶﾀ∧＿∧
（ ｀Д´ ） ｶﾀｶﾀ （ ｀Д´ ） ｶﾀｶﾀ （ ｀Д´ ） ｶﾀｶﾀ
＿|￣￣||＿）____ ＿|￣￣||＿）____ ___|￣￣||＿）___
／旦|――||/／ ／| ／旦|――|l/／ ／| ／旦|――|l/／ ／|
|￣￣工作￣|￣| . | |￣￣提灯￣|￣| . | |￣ﾏｯﾁﾎﾟﾝﾌﾟ|￣| . |
|＿＿＿＿＿|三|／ |＿＿＿＿＿|三|／ |＿＿＿＿＿|三|／
ｶﾀｶﾀ ∧＿∧ ｶﾀｶﾀ ∧＿∧
（ ｀Д´ ） ｶﾀｶﾀ （ ｀Д´ ） ｶﾀｶﾀ
＿|￣￣||＿）____ ＿|￣￣||＿）____ ___|￣￣||＿＿__
／旦|――||/／ ／| ／旦|――|l/／ ／| ／旦|――ll/／ ／|
|￣自作自演|￣| . | |￣￣.デマ￣|￣| . | |￣￣逃走￣|￣l . |
|＿＿＿＿＿|三|／ |＿＿＿＿＿|三|／ |＿＿＿＿＿|三l／ SEGVの原因は、ryzenチップ内のどこかのマージンが少なすぎて、高確率でマージン不足のチップが出るとか
そんなのでは？
メモリタイミング手動調整だけで治るチップもあるし、電圧あげるだけで治るチップもあるが、
それでもなおらないチップもあるって感じで
マージン不足が数パーセントとかならともかく、５０％とかそれ以上の確率でまざってるのでは？ >>273
チップというよりマザーボードのじゃないかなぁ
BIOSアップデートで改善方向だけど >>271
ハードの問題と発覚した事例はRyzenだけでは？ >>278
ハードの問題とryzenが確定したソースは？
64バイトのブログのこと？ Ryzen最上位3万円君の妄想に付き合う必要あるのか なんで団子はryzen買って検証しないのかね？
好きなだけ貶すチャンスじゃん
まあそんな事できるスキルはないからしょうがないね
ウソがバレるし、バレてるし >>281
RyzenじゃなくEPYCを買うつもりなんだよきっと >>278
同じソフトでエラー出して、Ryzenだけハードのエラーで
その他はソフトのエラーなんてことはあるわけないだろ。
クソ団子 >>284
他で出たからってソフトの問題になるわけじゃないぞ
μOPscache無効で改善する問題がソフトの問題か？ ジャンプ命令後のRIPずれたのもRyzenだけだし
ryzen_segv_test（という名のスピンロックテスト）のことならハードの問題のない動作環境で絶対にエラーにならないことが保証されてない >>282
所詮2chで吠えてるだけのゴミクズだよね ログは貼らないけどJouleに引き続きSurface Pro 4 i5 256GBモデル上のLXSS(Ubuntu 16.04)でもロックスピナー回したらエラー1回出たよ
このプログラムの信頼性をまず保証しないとハードのエラーの物差しには使えん
それとgccは別問題 >>285
RyzenのSEGVがμopscache無効化で改善するとして、
団子先生のありがたい言葉を借りれば原因が分かっていないことが問題だそうですが、インテルCPUでも出る原因は分かったの？ 団子のロックスピナー検証のおかげでRyzen_SEGV_testが半分くらいの報告が役に立たないことが判明してほっこり >>294
半分じゃなく全部だろ
結局振り出しじゃないか >>295
一応gcc回してる人もいたし(震え声) 許さんぞ…
sat
homuh0mu
EIRAKU 結局satとか言う人が勘違いで騒いでいいががりつけてたって事でいいの？ 定格運用でも高負荷で動作異常になるような不良石・不良BIOSをそのまま出荷するAMDが悪い
定格運用時の不良率は最低でも0.1%以下にしないと
IntelでもかなりOCすればこれくらいの確率でトラブル起こるだろうが、
定格じゃまずおこらない >>300
Intelで起きた人は定格だからそれはない 勘違いなのか何かを企図してかは(内心は)わからん
>心裡留保だったのに引っ込みつかない事態になったのかもしれんし、本気かもしれんし、ただの遊びかもしれん
でも現状OCでもピーキーだと言う認識が薄かった
DDR4の規格の危うさは新しもの好きの性
RYZEN事態新物→ままんも当然新物
と言うジェットストリームアタックだったから頻発？したようだね 定格で問題が出たと言ってる人が本当にメモリの定格通りで動かしているのかが怪しいんだよな
うちの環境ではデフォルトの自動設定だと定格よりきついタイミングに設定されて問題が出てしまうから 、.、_ ]) ゜ヽ
＾t、 \、 _,ノ" __ノfﾟ
＾ヽ-ﾟ ,.-_~arr'"゛ t_.1、
｜~゛ tヽx、 ~k_ ＾r、 _,,,,........---ｰ ､
ヾ＾^^?r v゜【 )、｜ ~t、G 'ｌﾞﾞﾞンｰ'''"￣´ﾞ¨二″
゛ヽ。『 」 【 ＾'∥＾'h、 ~~ ! .,{i;;;;;;二ゝ ｌ . !
,。 "~ _vr"゜__。- ! .iﾝ- 二｀'ｯ,,..ﾉ .ﾞ‐'''‐､
yﾟ』゜ rf^＾-q ~[ _u.。_ ｌ ! ヽ.二_/ '''''| .厂￣
メ∥ ____,a『 ﾟ3'"~~ ﾟ〉 ｌ ! ,､ )｀>iヽ | .|
メ ∥-p''"~~s- t ｜ ＾ ゜ /./ !､.ｌ/ノ_ ヽ_) ! .!
,eメ gﾟ ｜ ｜ ____、 l／ 'l'" _,,,.- ´t- ..ﾉ .|
∥ _____uv[ .ﾟ""゜ ＾^! ｀゛ `-､,_ !
ヾ 『~_av-t''^"~＾ﾟ'''''^ ._,,,,,,｡,,、 广'x、 ,,､.＿ ｣'ﾞ''i､
,,,,,_.,,,,、广ﾟ┐ .,,,ｖ―冖"~゛ ﾞ'i､ .ﾄ ,|,_ rｉゃ .｝ .,i´ '冖i､
.］ ｀ ｆﾞ,l° ,i´ .ﾞl＿ .ｙ-┐ 'や'ﾞ"ﾞ’ _,,,ｖr" .ﾞト.ﾞ'x,,,,广 ｨ・'''ﾞ~ .._,,ｖ･ﾟﾋ''''･x、
入､rУ ,iﾚ-ｖ,,,、 .,r°."'''lﾞ ,|√ﾞﾟ'i､ 匸 ._ .y・'ﾞﾟ,,,ｖ―-, .:ﾟｰａ .√ ._,rll＿ :｝
.,r''y|゛ﾞﾞl..,i´ ,i"ﾞl, .ﾞト ,r°,,, .., .＿,,ｖぐ .｀√ .,i´l广.＿,,,,,,,,i´ ,,i´ ,i´ ,｢ .:| .~''''″
.r″ .|ﾞl、 “ .,i″.yi入-ｲ il∠i、.｀ .,ﾒ| | ｣'ト .,,i´ .,i´ ,,￣ .[ .,i´.,,,,,,! .]_
.ﾞl＿,i´,ﾚ .'㍉,,,,ﾚ ~''┐ .,r°.,i´.| .| ,lﾞ :ﾞl、 ,,i´ ,i´ l゜.ﾟＬ＿＿ .:―ﾔﾟ″_ :~''=、
.,r″.,x=,, .,i´ ,x'".,,x'″ .ﾞl、 ﾞ冖''″ .］ | .,i´ .ﾞl, .~1 .ﾟＬ 'ﾞ〃 ,n, .,,}
.,l彡'''″ .ﾞ~"''''''''''"゜ .テ''~゛ .:ﾟ'―---―･° ―″ .~''￢―'″ .:ﾟ=＿,r 不安定言っている人はまず、BIOSの設定の値か以下の値のより大きいほうを試してみてください。。
Trdwr 9, Twrrd 3, TrdrdScL 3, TwrwrScL 3, TwrwrSc 1, TwrwrSd 6, TwrwrDd 6, TrdrdSc 1, TrdrdSd 4, TrdrdDd 4 RYZENがDDR4で略されてしまってR4になっているのが面白い ECCメモリにしてカーネルビルドしたけどSEGV出たわ
このスレでECCメモリなら大丈夫とか言ってた奴はi9土下座しろや ECCはデータのビット化けにしか対応できないからな 向こうのスレである程度問題点を絞り込んだ人がいるね
口だけで荒らすだけのクソコテとはえらい違いだな
>>316
ざっくりとしか読んで無いけど
segvの報告があるね
この問題がアレならサーバー厳しいかもね
って話じゃ無くて？
というかこの記事はVEGAがクソだからなんとかならんかって話がメインだよね >>317
そうだと思う
「discrete GPU segment」あたりをSEGVと思い違いしているんだろうか >>318
A side noteに書いてはあるけどね。
linux上で高負荷のコンパイルを行うとすると発生するという報告が多数上がってる、と 古いAGESAではタイミング厳しくてメモコン死亡なんて言ってたようだけど
本当なら大問題だよ メモコン死亡問題はSEGVと別問題な気はするが
というかメモコン死亡問題が事実なら別スレ建てたほうがいいレベル >>322
初期のころからメモリーOCしまくってた人はryzen瀕死かもしれんな
中古に流れるryzenやばそう 一番素直に考えると、高負荷時にuOPキャッシュ関係の回路が誤動作しますってことかな uOPキャッシュ切ると一緒にメモリーのパラメータも変わるのではと考察してるな いや違った
SEGVが起きる原因は2つある
ひとつはLinuxOS
もうひとつはCPUのメモコンの故障
初期BIOSはメモコンに負荷かかる設定だから使うのやめろ
ということね sat
homuh0mu
EIRAKU
確かに(頭の)不良率高い メモコン壊れると簡単に書いてるけど
それだけでも大問題だと思うんだが 本当にメモコンがおかしいのか
メモリ設定がおかしい状態でOS入れる→OSがおかしくなる→何やってもどうやってもシステム根幹が壊れてるので意味が無い
んじゃねぇかな 株主対策大変なのは解るけど
結局作り込み甘くて、ユーザーがとばっちり食ってるだけ
Intel追い込む効果はあったろうけど、半年や1年作り込んでからリリースするべきだったと思うけど >>333
俺もそう思ってた
経営厳しかったのは分かるが
もう少し熟成させてから出すべきだった お前らの言うこと聞いてたらいつまでも出せそうに無いけどな >>330
定格で壊れるなら大問題だが、壊してる連中はXMP読ませてるんだっけ？
それで、XMPとかいうOCプロファイルは絶対安全なのか？という話になるが…
そもそも絶対安全問題ナシなら、わざわざXMPなんて裏ページを設たりせずにSPDで直接読ませるわな常識的に考えて もうXMPという名称にOCの一言を入れなかったIntelが悪いってことで手落ちにしよう AMD公表のRyzen対応メモリに3200まで載せていますが2400を越えるOCメモリを使用すると壊れるます！
ということだな やり方次第
アホが適当にやると痛めるなんて当たり前の話 ゲーミングなんたらのBIOSって、そういうもんだろ
だから交換も迅速 そもそもASRockの初期BIOSなんてDOSでしかBIOSアップデート出来ないし、ASUSの英雄は自動BIOSアップデートで立ち上がりで無を書き込んで自爆とかいう状態だったんだし古いBIOSが危険なのは明らかでしょ初物だし。 向こうのスレで問題になってるのは今だに最新BIOSでメモコンに関わるタイミングキツめなメーカーがあることじゃ マージン不足のままCPUを出荷、
負荷が重くなるとマージン不足によってエラーが起こってクラッシュ
これだな
CPUの設計が悪いのか、検査が悪いのｊか、そのあたりでしょう 昔のAMDCPU定格で普通に使っていただけだけど
ブラックエディジョンの高クロックモデル突然死したからね
無理してる様な気がしてたけどやっぱりダメかって思った
今回の1800X辺りも製造プロセスの特性とか耐性ギリギリじゃないかと
製造は、サムスンの14LPPだよね、サムスンは昔からスペック詐称とか
高クロックメモリーチップの品質が寿命面で極端に劣っていたりしてた
使い始めは取りあえず動作するけど比較的短時間で劣化して壊れる
今回も高クロック高負荷で半導体回路が電気特性的トラブル起こしてるんじゃないの
低負荷だと起きないので検出が難かしいとか
Xモデルは使用禁止かな とりあえずメモコン設定値おかしな人はここまで落としたほうがいい気がする
メモリースレ見るとメーカーによってはもっとゆるゆる
Trdwr 9, Twrrd 3, TrdrdScL 3, TwrwrScL 3, TwrwrSc 1, TwrwrSd 6, TwrwrDd 6, TrdrdSc 1, TrdrdSd 4, TrdrdDd 4 >>347
AMDのCPUの製造はサムスンじゃなくグローバルファウンドリーズ >>350
共同開発にはIBMも加わってるけどな
サムスンの半導体で問題が出るなら
iPhone 6や6S、Snapdragon 835を使ったAndroidに問題が出ないとおかしいな
これらの半導体がどれだけ出荷されてると思ってるの？ ちなみにGFは10nmはスキップするようだが
GFはIBMの半導体部門を買収したしたしな
GFが7nm FinFETの生産計画を発表 - IBMの技術協力で2018年に生産開始へ
http://news.mynavi.jp/news/2016/09/23/149/
>GFのCEOであるSanjay Jha氏は、「7nmは、次世代の長く使い続けられる技術ノードであり、
>ここで他社に差異を付けられるのは、IBMからGFに移籍した優秀な人材とノウハウ、
>それに、IBMとの研究アライアンスによる世界トップクラスの研究開発体制によるところが大きい」と述べており、
>IBMもまた、7nmおよびそれ以降のプロセス技術の共同研究を加速するのに役立つ新しいアイデアやスキル、
>新技術の開発を今後も協力していくとしている。
IBM、半導体事業をGFに譲渡 － 15億ドルの現金対価をIBMがGFに支払う予定
http://news.mynavi.jp/news/2014/10/21/319/ >>351
マージン取ってるからだろ
14nmLPPだからzenは3GHzが定格かなとか予想建てられたくらいこいつは高クロック向かない AMDをディスるのに必死な人がいるようですね
それだけRyzenの出来がいいということかな？
今までのAMD叩きで半導体製造の話なんて出てこなかったし >>354
出来は素晴らしいよ
ただIntelに対抗していろいろと無茶な設定してる気はするが >>339
品質に問題無いメモリチップで適切な設定値を返してくれれば3200まで回してあげるよ。と言ってるだけ
ちな現在は2666で定格駆動する製品がある
粗悪メモリチップに適切な設定値を返さない怪しいプロファイルでOC駆動する、さも定格品のように売られてる詐欺モジュールを使うのは勝手だけど
それで壊れてもAMDの責任にはならないよね >>353
実際に3.2GHz以下で電力効率が相当良くなるからな ストリーミングがあるから。
そしてsat氏病気でキャンセルだと。 sat←病気ざまぁ
homuh0mu←FUD
EIRAKU←何と戦っているの？ やっぱり、売名行為だったか…
アフィカス含め、売上アップに利用される自作板 実は訴状が届いてたら笑う
悪名はその界隈に轟いたんじゃ無いの？
自分からクソぶっかけておいていざ批判の矢面に立たされそうになると逃げるってサイテー また集まって適当なこと話すのかぁ
しょうもねぇなぁ >>353
というか14LPPでコレだけ回るって完全にスピードデーモンを手懐けたと言えるかもな
Bull比でもちょこっとしかミスプレディクトコスト下がってないし、相当深いでしょ 講演会の参加者一覧みたけどhayaはtwitter情報載せてなくね？
こいつの方がよっぽど悪質な気がするんだが
【インテル工作員ただいま活動中】
ｶﾀｶﾀ ∧＿∧ ｶﾀｶﾀ ∧＿∧ ｶﾀｶﾀ∧＿∧
（ ｀Д´ ） ｶﾀｶﾀ （ ｀Д´ ） ｶﾀｶﾀ （ ｀Д´ ） ｶﾀｶﾀ
＿|￣￣||＿）____ ＿|￣￣||＿）____ ___|￣￣||／_）__
／旦|――||/／ ／| ／旦|――|l/／ ／| ／旦|――||/／.／|
|￣￣挑発￣|￣| . | |￣￣煽り ￣l￣| . | |￣￣ うそ￣|￣| . |
|＿＿＿＿＿|三|／ |＿＿＿＿＿|三|／ l＿＿＿＿＿|三|／
ｶﾀｶﾀ ∧＿∧ ｶﾀｶﾀ ∧＿∧ ｶﾀｶﾀ∧＿∧
（ ｀Д´ ） ｶﾀｶﾀ （ ｀Д´ ） ｶﾀｶﾀ （ ｀Д´ ） ｶﾀｶﾀ
＿|￣￣||＿）____ ＿|￣￣||＿）____ ___|￣￣||＿）___
／旦|――||/／ ／| ／旦|――|l/／ ／| ／旦|――|l/／ ／|
|￣￣擁護￣|￣| . | |￣￣提灯￣|￣| . | |￣ﾏｯﾁﾎﾟﾝﾌﾟ|￣| . |
|＿＿＿＿＿|三|／ |＿＿＿＿＿|三|／ |＿＿＿＿＿|三|／
ｶﾀｶﾀ ∧＿∧ ｶﾀｶﾀ ∧＿∧
（ ｀Д´ ） ｶﾀｶﾀ （ ｀Д´ ） ｶﾀｶﾀ
＿|￣￣||＿）____ ＿|￣￣||＿）____ ___|￣￣||＿＿__
／旦|――||/／ ／| ／旦|――|l/／ ／| ／旦|――ll/／ ／|
|￣自作自演|￣| . | |￣￣工作￣|￣| . | |￣￣自殺￣|￣l . |
|＿＿＿＿＿|三|／ |＿＿＿＿＿|三|／ |＿＿＿＿＿|三l／ 本スレはメモリーのサブタイミングでかたがつきそうだけどsat先生達は何やるんでしょうか SEGVプログラム動かして出ましたーとか言うんでしょ…
死ねばいいのに
こう言うの売名してデタラメ言い続けて講演して金儲けするって犯罪じゃないの？ sat『SEGV(等の欠陥を装った発見を流布)して儲かるビジネス。自分が気になったことなので他人には関係ない。』 全部自動設定の定格運用でトラブル多発するとか完全にAMDの不具合だろうが
結局、AMDがAGESAあたりをアップデートしてメモリタイミングを適切に修正すれば
大抵の問題は片付くだろうが Ryzenの出来は良いよね、感動的ですらある
けど電圧とクロックを盛りすぎた可能性はある
モバイル用の低電圧低クロックでは起きない問題が
デスクトップーハイエンド製品で起きてるんじゃないかな Ryzenに期待してなかったメーカーがマザー開発遅れてんだよ
Bioだけ評価して早々に開発してた Bristol Ridge向けBIOSを流用したマザーボードメーカーの責任では？
Trcpageが設定できるあたりがもう終わっている感 IntelもAMDも互いに無茶してる状況だからなぁ >>374
1.0.0.6からマザーボードメーカーに設定投げた臭いからメーカー格差激しくなりそうだぞ >>378
今無茶してるのはIntelだけだと思う ryzenメモリースレ見るとやたらサブタイミング低いマザーボードが確かにありますね
他マザーボードより異様に低いのは気になる >>383
メモリ側がSPD情報でサブタイミングまできっちり提供をしてるのに無視した動作をするものがあるとしたら、それは紛れもないクソマザボだね
サブタイミング等の設定情報を正しく提供してこない粗悪なOCメモリだったら… マザボ側で適当な値を決め打ちしないと起動すらしないし、メーカー毎にそれぞれ異なる値が代入される事になる
これってオートで値を埋めたマザボがクソだと言えるの？ 問題のサブタイミングはマザーボードが固有で決めてる
しかもBIOSのバージョンによって値が変わる SPD、サプパラメーター、DDR4固有の3分類でやってるだろ？
SPDのtRFCもでたらめなのがちらほらいて笑う >>384
そこまで言い始めたらDDR4がまだ熟れて切っていない事になる >>388
実際USBと一緒で初期のガバガバからIntelのHWに合わせたところまでそっくり
=成熟度以前の問題で厳密な仕様がガバなのでそりゃ問題も出るわ
現にPCI-SIGとかVESAとかIEEEが手綱握ってる規格はこういうの少なくなったろうが >>384
Corsairなんて同じ型番でチップが3種類～あるのにSPD同じだからな
そのせいでVer4.xはOKなのにVer5.xはダメとかいう話になるわけで
本来チップが違うならSPDに書き込む値もチップごとに合わせないとダメ >>391
だからそのJE何とかとかRamBなんとかとかがガバガバなんだろ
FAAみたいなもんだ あっちのスレカオスだなぁ
良くわかってないのに奨励値だのメモコン壊れただのやってるんだな >>394
特定のメモリータイミング遅らせればSEGVの発生は抑えられる
初期BIOSは特定のメモリータイミングがきつめ
2つわかっただけでも前進でしょ
壊れたは言いすぎな気はする メモリタイミングもまともに設定出来ないやつが多すぎ
Intel用のXMP2.0でサブタイミングセットしてもRyzenでは奇数がダメだったり値が全然違ったりするからね
Intelで8が通ってもRyzenでは12以上じゃないとダメとか、WRはtRTPの2倍で尚且つ偶数じゃないとダメとか。
tRFCもソフトじゃ正常に読み取れないし 要は年単位で後出ししてんにメモコンの性能低くて、記載のタイミングじゃ動かせないという 原因はメモコンじゃなくてDDR4と適当に鰤用 BIOS流用したマザボメーカー このスレでも数か月かかってるように、外部の一般ユーザーには分からないことだからな
M/BメーカーとかでなくRyzenに原因があるとしたのがまずかった 向こうは落ち着いたようだが、大騒ぎしていた連中どうするの 公演予定だったスライドなり資料なりをどっかに上げれば逃げたと思われなかったのにね >>402
これだと同じプロセスのままでテストになってないようだけど ロックスピナーを世界にばらまいているの誰よ
#108
ryzen_segv_test はぶっ壊れていると思う。最初のループにおいて t2 スレッドはロックされておらず、thread1 がそれらを使う前に初期化されている保証はない satよりryzen_segv_test なんてもんバラまいてた連中のほうが悪質 ロックスピナーをコミュニティに放ったのも、64バイト氏をTwitterで大騒ぎしてスラドに上げたのも…あっ… https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399#c119
#119
メモリフェンス/シリアライゼーションのことはよくわからんが、ryzen_segv_testが間違っている疑念をいくつか持っている。
（中略）
次に新しく移動されたデータ列 ret2 = pf(func_set); の呼び出しの前の lock_enter() の後に mfence(); serialize(); を移動してみた。
これにより、mfense() に読み込み待ちにメモリの多少の負荷を与え、データがキャッシュから移行されるようになる。
この変更により、セグメンテーションフォールトを得ることができなくなった。
Ryzenのバグ？ただの積極的なプリフェッチ？知るかそんなもん… >>405
volatile指定が抜けてるバグに気づいた人が俺以外にもでてきたね あっちはあっちで楽しそうだね
自称作者さん絶対の自信だったから乗り込んでほしい やめりゃいいのに懲りてないよね。マッチポンプ？
https://community.amd.com/message/2813386#comment-2813386#2813386
> Unfortunately linux kernel bugzilla is not actively used. Many developers don't check it.
> It' better to send a main to linux kernel mailing list (LKML) to report this problem to the
> linux kernel community.
https://twitter.com/satoru_takeuchi/status/889968129333354496
> というわけでLKMLに問題提起してみました。さくっと無視されるだけかもしれんけど、あそこの人達の膨大な知見によって何等かの進展があれば儲けもの #Ryzen_SEGV_Battle 儲かるのかねえ？一技術者としては絶対に関わってはいけない人間だなとは思っているが。 Ryzenが標準設定で正常動作不可なメモリタイミングを設定するってのが原因ってのはほぼ確定じゃん
だから、AMDがBIOS/AGESAの関連個所を修正してそれをマザーボードベンダに渡して、
マザーボードベンダーがそれをもとにBIOSアップデートすればいい話
Ryzenの問題だけど、RyzenのASICそのものの問題では無く、
BIOSアップデートで対応できる問題
ryzen_segv_testのほうは、プログラムが悪い、でおわる話 >>406
ryzen搭載BTO購入をこの問題のせいで１ヶ月躊躇った視点で言わせてもらうと
もし訴えれるならsatよりもhaya(@homuh0mu)訴えたい。 向こうはRyzenの問題よりはBristol Ridge流用ママンが悪いって落ちで収束しそうな流れだが
64バイト氏は誰かさんに利用されているだけだからマッチポンプ氏はタチ悪いな
自称作者さんはFIFO保証されていないスレッドの立て方でIntelでも問題が起きる、
通常行われている追加のmfence()かmprotect(...)で問題がIntel, AMD共に回避されることについてどうお考えなのだろうか？
https://lkml.org/lkml/2017/7/25/1295
> - at least part of this problem is caused by running instructions at
"RIP - 0x40" BIOSのメモリタイミングの設定ミスが、一般人どころかそれなりのプログラマーの想定の範囲を
大きく超える64バイトずれて実行っていう、まったく想像できない動作をすることによって、
RyzenのASICの問題だって決めつけてしまったのが騒ぎが大きくなった原因だね
メモリタイミングの設定ミスの根本原因が、メモリ側の問題なのか、Ryzen/BIOS側の問題なのかは知らないが、
ここまで多くの環境でエラーが起こるってことは、たとえメモリ側の問題であったとしても
BIOSでの対応が求められる 騒ぎが大きくなったじゃなくて、大騒ぎしているのが日本人約一名な件について… メモリータイミングはBIOSアップデートごとに変わってますからなぁ
メーカーも大苦戦してる感じ btrfs関連で数件の本当に問題のあるパッチを送りつけるだけで「私はlinuxカーネル開発者です」自称できるなら世の中に「linuxカーネル開発者」は何万人いるんだろうね？ >>419
安全な範囲ではなくAGESA1.0.04世代の危ないレンジを配っていることには言い訳できんだろ。。 >>421
かと言って1.0.0.6も安全とは言い切れないしなぁ
向こうの論だと1.0.0.4以前のBIOS使用したryzenはメモコン故障の可能性があるため完全な検証にならんって感じだし 逃げずに放火し続けているだろ。最後に傍観者気取って講演じゃね？ そんな古いあげさを使ったユーザーを犯罪者みたいにこき下ろすなよ
問題の出るファームウェアのまま製品出したのはどこの会社だ？ 1.0.x.xって普通安定板に付けるバージョン表記だけど不安定なまま各社にリリースしたのはどこの会社？ haya(@homuh0mu)が、sat1人の責任になすり付けて逃げようとしてるのばれてるｗ
今回の件がどちらに転んでも得をするのはhayaだけだからな 各社に差があり過ぎるのだからDDR4の設定おかしいのはマザーボードメーカーだろ
今回の騒動で儲けたのはアフィサイトと愉快な仲間たちか。本当にしょーもないな 次スレあるか知らんが【頭にエラッタ？】【かつらがずれた？】あたりで頼む 彼は自分でカーネル開発者って名乗ってる割にbugzillaにポストされました云々とか
LKMLに投げるほうが云々って言ってて、カーネル開発者ってよりメーカーの組み込み向け程度しか
やってないんじゃねーか？
おかしいの判ってたらメモリ周りに手を入れるとおもうんだが、答えがなきゃ出来ない最近の
自称開発者？ カーネルコミッターレベルの開発者を連れてこいよ
って、実は富士通グループにはsatじゃないけどそのレベルの人はいる
http://news.mynavi.jp/articles/2011/11/29/elf6/
この人とか がちゃぴん先生なら独立して屋号持つって先日ツイートしてただろいい加減にしろ #Ryzen_SEGV_Battleは馬鹿発見器になってしまったか。414の"apology silicon"ウケたｗ
https://community.amd.com/message/2813867
https://twitter.com/satoru_takeuchi/status/890736947320070145
> ryzen_segv_testも今disられてます。非常に口汚いので色々たしなめられたり怒られたりしてます。この人のお陰でいろんな人が時間を浪費してる(うんこの投げ合いに巻き込まれている)ので、早くいなくなってほしいです
399がdisられか。自称作者は反応してやれよｗ
https://community.amd.com/message/2813704 またしょーもないことを…
AMDスレの人ドン引きしてるじゃん… 20連投してamdmattを追い出した成果は認められるべき ちょっと待て、130はLinux4.8に問題があることに気付いて4.12推奨したわけだが同じことをやっているやつがいなかったか？
> 冒頭に記載した環境からの差分は次の通り。
>
> kernelは4.8.0-58-genericとv4.12
> BIOSは1.0.0.6a
>
> 現在のところの試験結果は次の通りです。
>
> a. ランダムなSEGVは発生しなくなった
SEGVしなくなったのに#Ryzen_SEGV_Battle？？？ 誰か時系列で説明してくんないかな？
twitterと此処とamdのコミュニティで話がばらけて何がどうなってんのかイマイチ分かりづらい 4/24 古いBIOSと古いLinuxをQVLでもない安物RAM4枚刺しで定格外動作させるとgccがSEGVするとの報告
ttp://satoru-takeuchi.hatenablog.com/entry/2017/04/24/135914
5/9 AMD CommunityでgccがSEGVするとの報告
ttps://community.amd.com/thread/215773?start=0&tstart=0
なお、本人は自身がオーバークロッカーであることを自覚していない様子
> My RAM is on the QVL and running at 3200 MHz but that shouldn't matter.
5/23 日本人が AMD Community に参戦。20近い連投を行う
#Ryzen_SEGV_Battleの火ぶたが切られる
6/9 日本人によってAMDに対する勝利宣言が出される
> AMD サポートコミュニティ、「AMDｸﾗｧｯ!居るのはわかってんだぞ、出てこいやぁっ!(ﾄﾞｶｯﾄﾞｶｯ)」ってレスがつきはじめてて非常に治安が悪化してる
ttps://twitter.com/satoru_takeuchi/status/872906584602451969
6/20 AMDの中の人が個別対応するとしてコミュニティから撤退(#95) 6/23 謎の試験プログラムが投下される。IntelのCPUにバグがあることを追試することには成功した
ttps://github.com/hayamdk/ryzen_segv_test
同時にSEGVが生じた際に報告される命令ポインタがずれていると報告される
ttp://www.e-hdk.com/diary/d201706c.html
このことが#Ryzen_SEGV_Battleの総帥によって広く広められスラドに紹介される
後にexciteニュースにも載り、アフィリエイトサイトで広められる
ttps://srad.jp/story/17/06/23/0550221/
ttp://www.excite.co.jp/News/it_g/20170623/Slashdot_17_06_23_0550221.html
6月末 2chでの検証が活発化
7月頭 少なくともメモリー周りが不安定だと安定しないと2chで報告
同時期のTwitterの流れはハッシュタグ追ったほうが早い
ttps://twitter.com/hashtag/ryzen_segv_battle?f=tweets&vertical=default&src=hash 7/22 「Ryzen SEGV Battle(仮)」の発表者がSEGVしたためその発表が延期される
7/25 2chでメモリー周りの設定の追試が始まる
7/27 AMDコミュニティに匿名が乱入。ryzen_segv_testを貶す
> 1. インテル製のプロセッサでも問題が起きる
> 2. 現実的なワークロードでない
> 3. 確率的な動作でしかない
> 4. gccはシングルスレッドであり自己書き換えをしない
> このことは信頼性や不適切さについて考えるのに不十分か？
日本人が反論
> RyzenのコアダンプはIntelのそれとは違い通常のコードでクラッシュしており、命令ポインタがずれている
匿名が反論
> はいはい、あなたもIntelで問題が起きることを確認したのね。なんて信頼性の高い試験なのだろう
> @satoru_takeuchiが#Ryzen_SEGV_Battleと称して始めたFUDキャンペーンの参加者であることとryzen_segv_testの信頼性はわかった
> ここには情報交換に来ただけだ。あなたがたのキャンペーンに参加する気はないのでryzen_segv_testについて今後触れないことを約束する ツイッターの悪ノリをコミュニティに持ち出したsat軍団が悪いとしか思えない
手順さえしっかりしてれば展開なんていくらでも変わっただろうに
そもそもSEGVの問題なのにryzen_segv_testなんて持ち出したら説得力薄くなるでしょ バクチに負けて後に引けなくなった感じだね
下衆な功名心でおま環の問題をなぜかCPUだけの問題と早合点しちゃったのか
しかしもうちょっと慎重にやってればこんな事にはならなかったと思うけどな
妙な色気出して目が曇ったんだろうね、釈明なしに逃げちゃったし…… satは更にこれのネタで講演して金儲けしようとしているよ > RyzenのコアダンプはIntelのそれとは違い通常のコードでクラッシュしており、命令ポインタがずれている
→こっちの方がヤバい問題な気がする 俺が「ロックスピナー」って名前つけた理由思い出してね
あれがIntel CPUでもセグメンテーション違反で落ちるのはスピンロックに失敗してるから
mfenceかませた修正パッチ後のプログラムではAtom系,Core系とも発生を確認できてない ネット上に Ryzen コンパイラの
ベンチマークが発表されているが
segv が出るなら
gcc 6/7/8 の比較が出来ないはずだが
どういうこと？ >>456
コミュニティの内容を読んでみるといいよ。
文句言い続けている連中で環境を明らかにしている人はオーバークロックメモリ使ってるから… いつからRyzenはDDR4-3200対応していることになったんだ？っていう… >>456
ubuntu 17.04
カーネルは4.12
でテストして問題出ない感じだよね >>457
こんな場合定格通りにセットしないと
いかんがな >>459
マザボがまさかのトマホーク
トマホーク大勝利だよね 続き
7月に入るとLinux Kernel Developerを名乗る日本人(ただしLinux Kernel 4.8.0に固執)により議論の方向性が
ぜか"gcc segmentation faults on Ryzen / Linux"の話題ではなく、
オーバークロックメモリで起動しない問題議論、
オーバークロックメモリでgccが1日動かないのはおかしい。状態に陥る
別の日本人が登場
> #Ryzen_SEGV_BattleハッシュタグはFUDではない。情報を広く集めるためだけのものだ
> 私は多くの価値ある情報をTwitterから得た。私はソフトウェアエンジニアの視点からこれがハードウェアの問題であることを共有した
> 私はこれらの行為によってAMDから個別のサポートを引き出すことに成功したと信じている(#95を読め)
> これらの活動がFUDだと？一連の投稿は誰にでも読める。このスレッドに書いてあることとほぼ同じだ
> 私はメールアドレスも含めたプロファイルを公開している。AMDは訴えられるものなら訴えてみろ。私は逃げも隠れもしない
> socket774、実名で私をFUDerと呼べるものなら呼んでみろ
同時に反論したことをTwitterで公表
> 2chから来たっぽい人にRyzenを貶めるFUDer扱いされたので反論しました。個人宛なら無視するんですが、公衆の面前で、とくにAMDコミュニティという大事な場所で言われたので
ttps://twitter.com/satoru_takeuchi/status/890551320603639809 匿名の反論
> やあ、Ryzen SEGV エバンジェリスト様
(過去のTwitterでの投稿が英訳されて晒される)
> sat on Twitter: "詫び石欲しい方、やり方教えます from sat@Ryzen SEGVエヴァンジェリスト"
> sat on Twitter: "@mhiramat とりあえず向こうが同意してきて詫び石送ってきたらSEGV Battleまた執拗にやりますよ。このまま幕引きされてたまるものか"
> sat on Twitter: "用語集 ガチャ→Ryzenを買う 当たり→SEGVを出す 確変→SW/HW構成、設定変更(定格内に限る)により当たり確率を上げる おかわり→当たり石を次の石と交換 詫び石→本競技のゴール。errataと認めさせて修正版と交換。"
> 宣言通り、執拗にAMDを非難して、サポートを困らせているようじゃないか。しかし根本的な原因にはまだかすりもしていないようだね
> 我々の邪魔をしないでもらえないだろうか。あなたは文句が個別のサポートを引き出したことを誇りに思っているようだが、それは邪魔でしかないことにまだ気づかないの？
> > 私は多くの価値ある情報をTwitterから得た。
> 価値がある？どこに？
> 我々はあなたとあなたの愉快な仲間たちとは関わりたくないので忠告はこれで終わりにするよ
日本人による勝利宣言
> ２ちゃんねらーが出てきてうんこの投げ合いが始まった AMD フォーラム。笑いすぎてお腹痛い。
ttps://twitter.com/fujii0/status/890713061312479232
> むしろRyzenが致命的な問題を起こす前に問題提起してるという意味では、Ryzen Segv battleはAMD派に与するものだと思ってたんだけど。intel派なら無視してればいいし。
ttps://twitter.com/mhiramat/status/890736400139567104 非建設的な発言も出始める
> Ryzen SEGVのアレ、ついに「FUDer呼ばわりするなら実名出せ、一生口利けないようにしてやる」って言い出してどひゃ～となってる。いやいや貴方Intel CPUでSEGV出たら真っ先に「ソースがおかしいに決まってる」って決めつけましたやん。それで狂信者呼ばわりか。酷え。
> いや、まあSEGVで祭りやってんだからそう捉えられても仕方がない気もしますが…
なお、ryzen_segv_testの作者は謎の勝利宣言を行った後、なぜか沈黙を保っている
> RYZEのSEGV問題の核心がかなり分かってきた感じ。でもこれ、何かの拍子に64バイトずれたアドレスを実行してしまうことがあるって、突こうと思えば悪用できそうだし、うやむやにしないで対策しないといけない性質の問題なのが明らかになった気がする。
ttps://twitter.com/homuh0mu/status/877354483608461313
> ryzen_segv_testも今disられてます。非常に口汚いので色々たしなめられたり怒られたりしてます。この人のお陰でいろんな人が時間を浪費してる(うんこの投げ合いに巻き込まれている)ので、早くいなくなってほしいです
ttps://twitter.com/satoru_takeuchi/status/890736947320070145 AMDコミュニティから公式を追い出して議論を逸らす
-> AMDコミュニティではこうなっている！ #Ryzen_SEGV_Battle
-> AMDコミュニティに変なツールを紹介する
-> "Ryzenひどい"の声に便乗する人が増える
(繰り返し) その後、こっそりblogが更新される
> 冒頭に記載した環境からの差分は次の通り。
> kernelは4.8.0-58-genericとv4.12
> BIOSは1.0.0.6a
> 現在のところの試験結果は次の通りです。
> a. ランダムなSEGVは発生しなくなった
”SEGVしないKernel”
さて、今後の展開は？ >>455
そう、Intelのは完全に問題でパッチ対処、Ryzenのはタイミング問題で現在追試中。
結局RyzenhaOC野郎の火遊びだったと。
その辺が不明確な間は鳴りを潜めていた団子小僧は今一度引っ込めよ 丸一日並列ビルドして失敗してはならない、は現実的な用途なのかねえ？
おれはIntel使っているがクリアできる自信ない。
DDR4の規格は、BER 1e-16 なので1日で数ビット化けても文句は言えんだろ。
素直に枯れたXeonでECCメモリ使えばいいんじゃないのか… AMDも気前がいいよね。DDR4-2400は4枚挿しでは定格外なのにRMAに応じるとは…それともクレームが相当だったのかね？ >>470
構造上OCメモリはInfinity FabricがOC状態になるから公式が喝入れ推奨と言っているのはそういうこと。
タイミングをデータシート読みして設定したら動く、SPD読みでBIOSがおかしな読みになるは
ボードメーカーの責任だし、ごみを食わせてごみが出てくるのは何の検証でもないのでは？
すでに指摘されているが、一貫性のない状態まで追い込んだ際に問題が起きたとして
その際にL1 Cacheに載っていたものが、ダンプ生成時に強い整合性形成後に吐き出された内容と同一である保証はない。
これをエラッタとするならば、
「不適切な構成またはオーバークロック時に不定動作になる - 修正予定なし」
とでも書かせればいいのかねえ
>>471
また変なパッチが配布されてる…この人、ガードページとしてTASK_SIZE_MAXからPAGE_SIZE引く基本すら理解できないようね
https://gist.github.com/satoru-takeuchi/687fb72c65c65e4896cc8836ae24d4c4
こんなのがLinux Kernel Developerだのと権威ぶっているのだからLinuxごと嫌われてもしょうがないだろ いろんな人が時間を浪費してる(うんこパッチの投げ込みに巻き込まれている)状況の正しい解釈
> みんな私の(効果が無さげな)パッチをテストしてくれて励ましてくれるので非常に嬉しい
https://twitter.com/satoru_takeuchi/status/891663081784225792 結局あの騒ぎはなんだったのだろうか。64バイト氏も落ちる頻度が下がったと言い出しているし…
RMAで新しい石もらって問題が起きたとして、疑うべきは自分の環境か？それでもまだエラッタなのか？
http://www.e-hdk.com/diary/d201707c.html#21
> 21 (金) %1 Ryzen new BIOS での状況
> 結局きのうの夜回していたやつは 6 時間以上数百回回ってもクラッシュは最初の 2 回のみ。 うーん...? 64バイト君はまともな電源買ってから話に加わってくれとしか
中古Bullmax 500Wでエラー出たと言ってるのを見ると滑稽でしかない いやいや64バイト君には一式新品で買い直して欲しいね
もうあれ組み立てからやばい感じだし ずっと爆熱でないから古い電源だと壊れる→AMDが悪い！！ 公式が去った後のコミュニティはマジでOCスレだな。
raydudeが環境明かしたが、DDR4-3433で動かないことが問題なのか。どひゃー
#495.
> GigabyteのBIOSには失望した。最悪だ、大災厄だ、避けるべき。なんかわからんが私のアプリケーションはASRockのボードでは動かない。こいつは素晴らしいBIOSを積んでいてDDR4-3433で動くのに！しかし私のアプリケーションはそれでは動作しない。説明しろ。
> 新しいシステムには本当に苛立たされた。二度と同じ間違いを繰り返したくない。重要な時には1年前の本物の石とシステムを使うべき。 公式は低遅延カーネルの人以外はマジうんこしか居なかったな ここまで横暴なOCerが跋扈すると、次世代からintelみたいにOCに制限が入りそう #512
satがraydudeに返信
> 私もmcl00と非常によく似た状況に置かれている。最初のCPUにはsegfaultの問題が、2番目はMCEの問題がありました。
> キャッシュタグのパリティエラーとリブートの問題について私は3個目を待っているし、AMDのエンジニアによって私と同じM/B、メモリ試験中です。
> 彼らの試験がよく知られたgccの負荷によるもので、3個目が良好であることを願います。
「3個目」 AMDがブチ切れてメモリにまでロックかける落ちがつきそうで嫌なんだが、あれを止めるよい方法はないのか？ えー？
あの人ら、自分がオーバークロックしてる自覚無いの？
いくらハードウェアに疎いっても限度があるだろ
おかしいでしょ？ ここに"linuxカーネル開発者"により日本版は「お前ら時間に正確だろ」とロック版のみ販売
OCしたいのであれば北米版を個人輸入する未来が作られた
彼を記念して自作板にはシリコンで彫られた石像が建てられるだろう
～完～ Intelマザーのノリで、OC動作メモリのクロック表記して売ってるメーカー各社の功罪もあるけどな 残念ながら言い訳は通用しない
エラッタが有るのは奴らの脳みそだった DDR4-3600で動くRyzenほしい！
#513.
mrsがsatに返信
> RMAにかかるプロセスはとーーーっても遅い…CPUを送って4個目…が…戻って…きて…また違う問題を起こす…他に…誰かこれを楽しんでいる？あたかも誰も1000ドル/ユーロのマシンで仕事をしていないようだ。
> そこに光はあるのか？私は我々が暗闇に置き去りにされている様を悲しく思う。
「4個目」
※なお、環境
#135.
1) Ryzen 1700 / ASUS PRIME B350M-A / 2x 8GB DDR4-3600 Corsair Vengeance LPX (CMK16GX4M2B3600C18R)
2) Ryzen 1800X / ASUS PRIME PRIME X370-PRO / 2x 16GB DDR4-3000 G.Skill Ripjaws (F4-3000C15-16GVR) >>494
HPE Integrity Superdome 現象
メモリタイミングの設定が悪いと、低確率でランダムSEGVが起きる、
なぜか64バイトずれた場所を実行する、フリーズする場合も
対処法
AMD・マザーボードメーカーが、BIOS/AGESAで、正常に動作するメモリタイミングを設定する
糞OCメモリに対するワークアラウンドもできるだけBIOS/AGESAに入れる
ユーザーは新BIOSにアップデート
正常に動かない設定を提示する一部の糞OCメモリの使用を止める
結局、メモリタイミングがずれたら64バイトずれた場所を実行するってう、
だれも想像しないような斜め上の現象が起きることからして、
多くの人がRyzenのコア部分のバグだと思い込んでしまった
ところがふたを開ければただのメモリタイミングの設定ミスだった アドレスバスのタイミングがずれたら読み込むアドレスがずれてもなんの不思議もないよ >>496
マザーボードメーカーによってタイミング違うから余計話はややこしくなるのがね 鬼の首でも取ったようにryzenのエラッタだryzenのエラッタだと騒いでた陰土人息してんのかな、初期からIntel環境でも発生してた言われてたのにな。 メーカーによって個性というかチューニングが異なるとかなら良かったんだが
単に検証不足の疑いが濃厚という DDR4-2400*4は定格外で門前払い
相手にする方がおかしい 445,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｳｰ Sa5b-L5XL)2017/07/09(日) 22:44:51.87ID:gJGagwd6a
もしメモリに問題があるならマルチスレッド化したN-QueenとかPiでも問題が出る可能性は高いと思ってますがね
483,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｶｰ Sa2b-L5XL)2017/07/10(月) 09:03:42.74ID:C8+wZvtra
>>479
このプログラムが自己書き換え時のキャッシュ同期ミスってるだけなのでメモリ買い換える必要もない
そしてgccの現象は全く別原因
612,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｶｰ Sa2b-L5XL)2017/07/11(火) 15:40:14.44ID:TxsAv5NDa
特定のアドレス関係なしにどこのアドレスでも必ず-64バイトのオフセットがかかるのはメモリの不具合ではありえないよ
652,,・´∀｀・,,）っ-○○○ (ｱｳｱｳｶｰ Sa2b-L5XL)2017/07/11(火) 18:42:23.11ID:BvfqsKTWa
とりあえずjmp時にポインタズレるのはメモリの問題じゃない
流石団子逆神予言サービスは迅速で正確だ コアA : もう走ったことある命令列だからuop cacheで走らせますね
コアB : 書き換えたわー。フラッシュ！
メモリーコントローラー : おい設定厳しすぎてパイプライン詰まった！メモリが追い付いてこない
コアA : えー、もうここまで走らせたんだけど？クラッシュ！
OS : じゃあダンプ吐いておきますね → 64バイト前に見えるんだが、コアAさんきちんとfixup書けた？
…こんな落ちじゃないの >>496
Linux Kernel 4.8にmfence漏れのバグあるので4.11以降使えってのも入れといて AMDは、Ryzen Master のLinux版を
出すべき
またRyzen 電源プラン設定ユーティリティ
のLinux版を出すべき そもそもLinuxはRYZENの対応OSリストに入っていないような。 AMDは古い電源用に消費電力を最高速度向けで一定にするべき >>506
ありゃ逆
linux"が"サポートするもの Linuxがクソなんだよ
あんなｷﾁｶﾞｲｸﾚｰﾏｰ居るんだし
普及しないわけですわ kernel4.8 は SMT に不具合があるから
4.10以降使えとどこかで言ってた気がする >>506
発売前からRyzenのcpu id が追加
されていたと思う 前スレですら40時間走らせて落ちないって報告出てて、130氏も少なくとも1日は落ちない、
564氏も41時間以上落ちない(彼はuop cache無効か)…まだ続けているのかな？と報告出てるのに、
なんでDDR4-2400x4にこだわって詫び石言ってんの？
Linuxやってるやつってマジでこんなやつしかいないのか？ 数日ぶっ通しでやらなくても4時間を数回ノーエラーでこなせたら問題無いような ECC無しでは4時間回れば十分だろ？何この要求水準。かなり引くんだが… Kernel4.8.0でSEGV？？当たり前だろ。Skylakeでも問題起こすぞ？意味がわからないんだがどういうことこれ？？ アドレスバスのタイミング不良起こしてもエラーとしてトラップされずに、
そのまま動作しちまうのが問題なんじゃ無いの？ ああ、ずれるのが問題だって話になっているのか
これ？http://www.e-hdk.com/diary/d201706b.html
なんでわざわざUbuntu16.04なんて使ってるの？ >>517
有名ディストリビューションでつかわれてるカーネルは、新カーネルで修正された重大バグは
バックポートされて問題修正されてるのが多いので、
それを使ってれば、4.8でも大丈夫だよ
自分でコンパイルしたカーネルは駄目だね すでに実行されている命令でRIPが報告されていないということね。そのまま動作している、ではない様子
でもこの人、SOCの電圧上げておいてヒートシンクが65度くらいと、とんでもないことを言っている気がするのだが… >>520
追試している人を見ると全員かなりバージョンあげて解決しているのは気のせい？ Kernel更新が要件になっているのであれば本当にUbuntu16.04が試験に適しているのか疑問なのだが。何もかもめちゃくちゃだなこれ は？マイクロコード上げないでエラー出ていると言っているの？ そもそもUbuntuはArtfulでなければ十分なバージョンにならないだろ
この二人は環境がよくわからないのだが、初期不良対応でまた壊れる確率…？ make defconfigが16並列で2分切るのか…
それだと、4時間回すと数十万のプロセス生成になるはずだが
普通のWindowsユーザーなら数年分、gentooでもemerge @worldが終わるだろ
自作でその負荷を一日担保させるためにAMDに文句言っているのか理解できないのだが…
会社単位でのサポート契約でも結んでいるのか？ 自作で会社単位のサポートはないか。UDIMMで動作保証させろと？？
法人契約なら時間あたり5万円は必要な調査を無償でやってもらえるのか
それを考えたら破格の値段だな。その構成で買うか まぁ勝手も問題はないよ
メモリだけ少し注意で。
騒いでるsatという奴はFUD扱いでいい 要するにバグがメシより好きな人が
その原因を調べるのが
趣味だったという話
segv が出ないと不機嫌 メモリ周りは厳しめというのは発売日からわかってたことだしなぁ・・・
DDR4-2400x4でするのは論外だけど >>532
いやまぁやるのは良いが
ダメで即エラッタ扱い←コレガワカラナイ >>533
確かにね ていうか定格に気づいてない可能性もあるなこれ またよくわからないスクリプトか。今度はgccを1日中ビルドしろと？結局負荷試験だろ。
とりあえずmake defconfigで1日SEGVしない環境作ってから参戦すりゃいいのに
最近の開発者は自作板より技術力ないのか。
そんな連中にプログラム書かせるほうが怖いのは気のせいか？
https://twitter.com/homuh0mu/status/892229052882276354
> ビルドのループにkill-ryzen.sh https://github.com/suaefar/ryzen-test … を使ってみたところ、
> カーネルビルドだと日に数回かぐらいしか出ない自分のマシンでも一時間と経たずSEGV出るのでテストツールとして良さそう。 #Ryzen_SEGV_Battle 消費者グレードに何を求めてるんだ？ASK税高くなっているのはこいつらのせいか… 564氏はuop cache無効化で84時間以上にまで到達したのか！すごすぎるだろ
Intelで全員あれを超えてみろよ。JEDEC規格より2桁の余裕があるってこと？
gcc用途ならuop cache無効化で5%しか性能が下がらないことはすでに報告されている
大量のgccを走らせる整数演算中心のものはuop cache無効で、
エンコなどプロセス生成しないものはuop cache有効で走らせればいい
は現実的な回避策となり得ないのか。それともCIサーバーとエンコサーバーの両立がほしいと？ なんで巣から出てくるんだこいつ
使う事など絶対ないんだし、叩く材料を見てるだけだと思うが は？ネガキャンやっている自覚ないのあいつら？まず定格で試せよ
何個壊したらRMA止むの？これが本当にRMA必要な場面に影響しなきゃいいが
https://trends.google.com/trends/explore?geo=JP&;q=segv,ryzen%20segv マイクロコードのキャッシュ殺さないと安定出来ないなら設計ミスじゃん >>544 キャッシュ殺さずに40時間、1日の例では足りんのか？ >>544
いい加減OC止めたら？
自分の環境を見直してよ >>545
あなたの努力や功績は認めるけど
>>540みたいなのが定期的に湧いてるのが
AMDの公式な判断が無いうちは、問題が無い物とせずに思慮事項としていけば良いのに、
変に幕引きしたがってる手合いも居るのがね >>542
仕事でもi7やXeonだけど、経費節約にうるさい株主納得させるだけの理由は必要かな メモリの設定とか見直せないやつが手っ取り早く出来る応急処置がuop cache無効化って印象 最新BIOSにアップデート
一部のおかしなOCメモリの使用をやめる
この２つを実行するだけで、問題は解決する
おかしなOCメモリで正常動作しないのはメモリの問題であり、規格外品をつかってるユーザーの問題でもあるが、
BIOSアップデートでワークアラウンドが入るかもしれないし、
ユーザーが手動でメモリクロックやメモリタイミング調整することによって回避可能 >>550
おかしなマザーボードの間違いだわ
定格だろうとマザーボードの設定次第で発生するのは別スレ130が散々言ってただろ たぶんintelの場合は、intelが市場に出回ってる規格外メモリをたくさん購入して検証し、
規格外メモリでもなるべく正常動作するようにBIOS等で対策してあるのでは？
だから、規格外メモリでも自動で正常動作 >>551
通常、マザーボードはメモリ関連の設定は標準設定のままでユーザーが関与しない
ただし多くの自作マザーでは手動設定も可能
マザーボードベンダーとしては、規格内メモリ使って、標準設定でちゃんと動けば、
手動設定でうまく動かないとか完全にユーザー責任だろ >>553
OCどころかメモリーが定格設定でもマザーボードごとにサブタイミングが違うんだよ
向こうで騒いでた1番原因はこれ
初期BIOSはサブタイミングがさらにきつかったから使うなって警告してたんだよ >>553
規格内メモリに標準設定でもエラー出るから問題になってるんだろ
JEDEC準拠メモリ挿してAutoでエラー出ないマザーは無いんじゃないかと思える
メモリAutoでエラー出ないマザーがあるなら教えてくれ むこうで安全と言われてるタイミング設定にするとレイテンシよりメモリー帯域がとにかく落ちるしAMDどうするのかなぁ 当たり前の動作が期待できないボードがあってそれを何とか設定したら40時間動いたって話でしょ
ボードでばらつきありすぎるのはメモリスレ見りゃわかるし、
文句あるならsocket774や130のように買って追試して報告すりゃいいだろ。おれも報告は送って返信来てる
564のようにMicronで合わせて130のデータシート読みして追試して動いた報告も有用だろ
買わないで文句言う、試しもしないで負荷試験かけてエラッタ決めつけできる神経がおかしい
エラッタ決めつけで環境公表してるの誰かいるの？ 新設計のCPUとか全部有料βだけどな
自作民の常識も知らんのか？ BIOS画面開けないやつは自作せずにDell待てばいいだろ。環境も晒さずになに騒いでたんだあいつら そんな常識は知らんなー
Intelならリコールにしてるレベルの不具合だろこれ Intelでも初期はいつもこんなもんだったんだが？ >>562
Sandy Brigdeは即リコールしたろ P5Q以上の地雷ってあったっけ？
こいつ実際それ以上な気がするんだけど 物理的に破壊されるというあのリコールは、ちょっと別格すぎると思うが……
ちょっと前のC2000といい、検証の「け」の字もやっていなさそうなインテルのチップセット部隊以上の地雷はなかろう。
というかAMDの考えるリコールレベルってPhenomのTLBバグあたりだけど、あれを再現できたというお話を聞いたことがない時点で
今回の現象がエラッタになるとは正直思い難いが。 あいつら2chから出てきてコミュニティでやれと文句言っているが、ロックスピナーがスレ違だと指摘しただけで実名晒せと恫喝したの誰だよ 実のところ1700でj8で回したらどれくらいの速度低下で
確率はどれくらいとかそういう話があるといいんよね sat取り巻き連中は2ちゃんねる見てるの？戯言なんて気にしない勢だと思ってたのに >>567
C2000の問題は使用による経年劣化だからなあ
Ryzenには経年劣化問題がないと言うには期間が経ってなさすぎる >>569
整数演算のみならuop cache切っても性能5%も下がらん、が前スレ i9とｘ299マザーの酷さに比べたらP5Qはまだ笑って許せるレベルだろう 経年劣化(当初発表したスペックシートを満たすことは多分無理です)ね。
というかメモリを調整するだけで起きなくなるような不具合って、原因が何であるかを明確に吐露しとるようなもんだと思うが……
あと騒動前半にsat以下を散々ヨイショしといてからの沈黙と手の平の回し様、中々に見物でしたよ団子さん。
>>467から逃げないようにね。まあ逃げるんでしょうけど。 どちらにせよ、Twitterで支持を得ているエンジニアが全てでない現実が突きつけられたのは皮肉だ。あいつら結局炎上しか能がないのね >>575
Intelのパッチ対処ってなんのことだ？
排他ロックが正常に行われてないソフトのバグをハードの不具合にすり替えるなよ
8ビットの部分レジスタ書き換えの問題に至ってはそんな20年以上も前のコード資産なんて運用してるやつ知るかレベル（Pentium Pro時代からRAWペナルティ大きいから禁止が徹底されてきたコードだし） はいはい、スレ汚すだけ汚して
Ryzenは不具合
Intelなら糞コードな
お前らしいわw >>552
それはどっちかな？と迷う所
逆の考えで、Intelが動くようにメモリメーカが作るというのもある
多分両方あって、双方から支え合っているから効率的に製品が安定する
後から来たAMDにそれは… >>578
ryzen_segv_testならAMDのフォーラムでもバグってるって指摘されてたと思ったが
いつからあの作った本人すらよくわかってないプログラムがハードのバグを検証するプログラムになったんだ？
「ロックスピナー」って呼んだ意味理解してよ >>558
簡単に言えばそういうことだよ
解ってるなら変なスクリプトとか持ってこないでお前も有料テスター位してみろ
皆の目が変わるぞ？ｗ
しっかし…海千山千とは言うがこうも市場が厳しいと後発程やりにくそうだ intelが金にモノを言わせてJEDECに介入して策定させたのがddr4 revisionB1
そりゃアホな不具合は一つも出せんよ
skylakeはJEDECに救われた
は、言い過ぎかなw
https://s.news.mynavi.jp/articles/2015/09/29/ddr4/ 原因がわかってない状態で「おれの環境では問題が起きた→CPUが犯人」ってのは短絡すぎるよ。まして、定格外動作を含めて全員に効くワークアラウンドはまだないんだよ。落ち着け
#Ryzen_SEGV_Battle 原因がわかってない状態で「Xをどうこうしたら直った→Xが犯人」ってのは短絡的すぎるよ。まして、メモリタイミングを含めて全員に効くワークアラウンドはまだないんだよ。落ち着け 130はメモリが全てだとは言ってなかったような？「メモリくらい見直せ」をどう解釈したらああなるんだ？日本語苦手なのかな メモリー緩めてuop cache切ったら症状出てない追試した人はいるし
130の個体は試験しすぎて参考にならん状態とは言ってるけど
130はメモコンが正常な個体はuop cache切らなくてもSEGV出ないはずとも言ってたな
後は各々検証するしかない 130は切らずに1日動かして打ち切ったし、前スレのも切らずに40時間で打ち切ってたわけでしょ？
おれも通常使用で問題起きないのだが、なにが足りないの？わざと壊すの嫌なんだが 検証してくれている人ですら、エラー出てないままでも長くやって壊れたら嫌ってんなら
一般人は手を出さない方が良いんだろうな >>591
いや130の安全圏は空白だらけになるから…
あれはいくらなんでも余裕持たせすぎ >>581
死ね殺されろ早く死ね殺されろ何度も殺されろ :::::: ＿ヽ.＿ _＼ ／,. ' ／ ,/ }
.ヽ／, ／＿ ヽ/＼ ＿＿＿＿＿＿＿＿＿＿＿＿ .／／ ∠ ､＿__/ | ち
..// ／< ＿＿） l-＼ ｜___＿＿＿＿＿＿＿＿＿___｜ ／ V-─- 、 , ',_ヽ / ,' ょ
..|| ｜ < ＿＿）_ゝJ_)＼|｜ﾀｲ━Φ|(|´|Д|`|)|Φ━ﾎ!| |／ヾ､ ',ﾆ､ ヽ_/ ｒｭ､ ﾞ､ / っ
..||.｜ < ＿__）_(＿)_ >＼ﾀｲ━|Φ|(|ﾟ|∀|ﾟ|)|Φ━ﾎ!!／＼ l ﾄこ,! {`-'} Y と
| | <_＿__ノ_(＿)＿ )... ＼━|Φ|(|ﾟ|∀|ﾟ|)|Φ|━／ 来 ヽj 'ー'' ⊆) '⌒｀ !
ヾヽニニ/ー--'/. ＼Φ|(|´|ⅴ|`|)|Φ／, ､ い l ﾍ‐--‐ｹ } 署
|_|＿t＿|_♀__|. ＼∧∧∧∧／ ヽ ヽ. _ .ヽ. ﾞ<‐y′ / ま
９ ∂ ＜ タ ＞ } >'´.-!、 ゝ､＿ ~ ___,ノ で
６ ∂ タイーホ！！ ＜ 予 イ ＞ | －! ＼` ｰ一'´丿 ＼
(9_∂ ＜ l ＞ ﾉ ,二!＼ ＼___／ /｀
.─────────────＜ 感 ホ ＞───────────────
タイーホ！！ 「￣￣了 ＜ の ＞ また、タイーホか！
l h「￢丨 ＜ !!! ＞ _ ＿＿＿＿＿
.／￣￣＼＿_,ト、Д/＿＿..／∨∨∨∨＼ ∧＿∧ |｜＼ ＼
／ /￣Yi. / jﾃ、 .／ ＼ （ ´∀｀） |｜ ｜￣￣
/ ／∧ / / /.i l ／ ／￣￣￣￣＼「（ つ／￣||｜／ ￣￣
/ ／ Д｀ / / / / ／∧＿∧＜通報しますた!＼ヽ |二二二」二二二二二
／ ｌ ヽ../ ﾚ ..／ （ ´Д｀ ） ＼＿＿＿＿＿＿＼］＿） | |
/ ＼ !、 lヽ＿＿／ ／, / (ﾟдﾟ) ｼﾏｽﾀ! ＼ ／ |
＼. ＼ ＼l ／ (ぃ９ | ゜( )ｰ ＼［＿＿」
＿＼/ﾄ、/ﾄ、 ／ / /、 ./ > (･∀･)ｼﾏｽﾀ!＼
( ）y ）／ / ∧_二つ ＼ 私は情報収集していただけで、貶す意図などないことはコミュニティを見れば明らかだよ。切り貼りしないできちんと読んでもらいたい
確かに悪ふざけしていたことは認めるが2chでなくコミュニティに参加してもらえないだろうか？ >>596
そっちも切り貼りコミュニティじゃんwww Intelがキツすぎる設定を無視するワークアラウンド入れてる可能性ってないの？ 基本的にメモリocした時点で、自己責任じゃないの？
なんでそれが不具合になるのか。 >>600
定格で起きるから
OCで起きるとかどこから言ってるのか不明だがコミュニティの連中は論外だぞ コミュニティの連中意味不明なんだよなー。数分で起きるとかどうやって？
なんで自作板は MCE だの、ランダムなんちゃらに遭遇できないんだろ リプ乞食だからなんだろ、ここで言うところの団子みたいなアホの吹き溜まりなんだよ 声のデカい職業ITエンジニアって団子みたいな奴ばっかりなのかね？ 定格メモリで問題起きると、SPDの記載情報から推測値で設定されてる値が悪いから（マザボメーカー毎で値にバラツキがあるから）マザボメーカーのせい
…という話になってる
要はIntel環境で動いたメモリのタイミングだろうが、AM4環境のBristol Ridgeでは動いたタイミングだろうが
Ryzenに合わせた糞緩い設定に自動にならないマザボメーカーが悪いという論調ね
OCメモリも、シングル2枚なら2666MHz動く事をRyzenの製品情報となっていようが
2666MHzのメモリ自体OCメモリだから、動かなくちゃならない義理も無ければ、動作保証なんて有るわけ無いじゃん
動かないのはメモリのせい、マザボメーカーのせいって事らしいよ
でもマイクロコード用キャッシュを無効にすると、既存環境のタイミング等でエラー無しで動くらしい
個人的には、本来機能としてあるキャッシュが有効になると、緩いタイミングじゃ無いとエラーが出るメモコンがどうかと思うし
キャッシュがヒットせずに、通常のキャッシュやメモリに読みに行った際、過渡にタイミング緩くしてないと追従できなくなるキャッシュシステムにエラーやバグじゃ無く
設計的な考え方の問題がありそうだし
5ヶ月経っても未だにこんな状態な製品売りに出してるのが問題な気がするんだが いやいや、XMP読みどころかSPD読みすらしないのは問題外でしょ…
メモリーコントローラーの設定もDDR4-1833に落とすと空とかあほかと
これはボードメーカーが確実に悪い。
遅延でかいわりには頭の悪いメモリーコントローラーだとは思うが、
祭りにしてしまったのは悪手。ようやくAMDと文通できるようになった UMCの遅延がデカい何て誰も言ってないがな
間にもう一個噛んでるでしょうが C6Hにサムスン純正モジュールでもSPDよりキツいタイミングに自動設定されて問題が出るんだよな uOPキャッシュが本当に悪いのであれば、それこそマイクロコードの修正でなんとかなるんじゃないのかね？ >>613
ほとんど確信しているが、これは修正できる類 linuxカーネル開発者が関わっていたbtrfsはRHEL7.4で廃止か。ほんと関わるとろくなことがねーな
https://lwn.net/Articles/729488/ >>615
RedHatが後退していってるだけでしょ >>617
後退っていうかIBM化しているだけだよ つかマジで糞団子は買う気も、持ってもないのにここにも本スレにも現れるなよ
みんな迷惑してるじゃないか ところでRadeon MemoryってやつはDDR4ではやってないの？
マザーボードも含めてOEMでいいからAMD名義で販売してくれればRMA窓口が一本化できていいのにな >>620
死ね早く死ね早く死ね早く死ね早く死ね早く死ね早く死ね殺されろ早く死ね殺されろ殺されろ >>607
表示上空でも実際の値不明だからなんとも
UI的な設定範囲外な可能性が外せないんじゃ、一概に設定値が無いと判断出来ん
表示が得られないのは頂けないけど
表示が出てないのと設定がされてないのはイコールじゃ無いでしょ
実際BIOS動いてるならメモリ稼働してるんだし >>622
それな。表示されていないがtwrrdがすとんと0に落ちる。RTCで確認した 固定回線を用いた3名による自作自演かな？
よくタイミング合わせられたな
642 (ﾜｯﾁｮｲ 6f63-AGS5) ID:Wm3bkM8Y0
ここまで"gcc"
647 (ﾜｯﾁｮｲ 6f63-AGS5) ID:Wm3bkM8Y0
649 (ﾜｯﾁｮｲ 6f63-AGS5) ID:Wm3bkM8Y0
650 (ﾜｯﾁｮｲ 6f63-AGS5) ID:Wm3bkM8Y0
651 (ﾜｯﾁｮｲ 6f63-AGS5) ID:Wm3bkM8Y0
660 (ﾜｯﾁｮｲ 6f63-AGS5) ID:Wm3bkM8Y0
663 (ﾜｯﾁｮｲ 6f63-AGS5) ID:Wm3bkM8Y0
666 (ﾜｯﾁｮｲ 6f63-AGS5) ID:Wm3bkM8Y0
674 (ﾜｯﾁｮｲ 6f63-AGS5) ID:Wm3bkM8Y0
"GCC"
643 (ﾜｯﾁｮｲ 77be-AGS5) ID:nVyebhRf0
645 (ﾜｯﾁｮｲ 2b87-AGS5) ID:IGk5x2o/0
658 (ﾜｯﾁｮｲ 2b87-AGS5) ID:IGk5x2o/0
672 (ﾜｯﾁｮｲ 2b87-AGS5) ID:IGk5x2o/0
AGS5
646 (ｻｻｸｯﾃﾛﾚ Spef-p6Kn) ID:lICSPWeIp
648 (ｻｻｸｯﾃﾛﾚ Spef-p6Kn) ID:lICSPWeIp
667 (ｻｻｸｯﾃﾛﾚ Spef-p6Kn) ID:lICSPWeIp
654 (ﾜｯﾁｮｲ 0b5b-2lvr) D:/3Wvza180
655 (ﾜｯﾁｮｲ 0b5b-2lvr) D:/3Wvza180 >>625
ID:nVyebhRf0 だけど少なくとも俺は違うよw 疑ってすまんかったｗ
すごいなーとしか思わないがな ほんと、代わりにパッチ書いてくれりゃいいのにな…
socket774の後追いくらいならまだ間に合うはず 取り巻きはさておき、引けなくなってるやつがいるからな CPUのエラッタだと断定してあとに引けない人が多いんでしょう
現行のBIOSで、標準設定でたまにメモリタイミング間違えるってのは、広義のエラッタではあるでしょう
AMD/マザーボードベンダー/メモリベンダーどっちの責任かは知らんが
将来はAMD/マザーボードベンダーの対応が進んで、
BIOSアップデートされていけば徐々にこの問題の影響を受けるMB/メモリの組み合わせは少なくなるのでは？ 上のツイートの流れ、48時間要求されてるから…
なぜ問題の一時回避パッチを発表するなり、問題の明確な再現コードを書くなりできないのかよくわからん
もう、ここと向こうのスレにヒント出まくりなのに…能力不足なのかなー いつデータ化けするかわからないCPU
そんなもんこわくて使えない >>637
じゃあ使わなくてええんやで
どうせ持ってないだろうけど 130とsocket774がそれぞれ誰だか何となくわかっちゃってるのでここでだべって様子見ー で、現状で謎のカーネルビルド連発以外に実害受けるユーザーっていてるん？
実害が発生してるならそれこそ騒ぎになってそうなのに、そうなってないってことはおま環だったりFUDって感じなんかって印象しか受けないわほんと >>642
一億プロセス起動して問題が起きたら困る人のみが実害を受ける… 全社メモリタイミングAUTOの設定値を修正したBIOSを出して更新させれば終わる気がするが >>644
1CPUで大量なプロセスが正常に動き続けるということを期待する噴飯レベルなユーザーは確かに困りそうやな... >>645
それで99.99%のユーザーは影響受けなくなるだろうな。
ここでの40時間の例はWindowsで数年分、Linuxで開発メインでも1年分の余裕があるはず socket774は勝利宣言出しているが、1週間以内にパッチを後追いであっても公表できればお祭りの勝利、
そうでなければメモリタイミングの余裕を持たせたとしてBIOSが配布されて何事もなかったことになる。
さて、どうなることやら？ AMDが各環境に合わせたCPUで交換対応するようだしRyzen自体の問題じゃないの 特定のメモリタイミングでは確かに問題が起きない。
向こうの695の狙いはそれを明らかにすることだろうな。AMDの狙いは実態調査と、
問題のない個体を返送しているのに壊している人をマークするといったところだろうか。
結果的には問題は解決されるだろうが、どう決着させられるかはお祭り参加者の力量次第かと 要はエラッタ無いのにAMDの仕切りと練り込み甘くて、エラッタ有るのと同じ様なな状態が起きてるの？
別な意味で不味いんじゃ？ 元の意味の正誤表の意味ではこれはエラッタに該当するだろう
ただ、お祭り連中の言っているようなまずい状況(攻撃とか)はないだろうな 実際にアクセス違反例外が発生してるんだから
マズい状況が発生しないなんてことは無い 例外飛んだ、レジスタは変更されているように見えるだけでは弱すぎるよ… exploitableであるかのような主張には弱いとの意 >>637
intelも落ちるから君はARMかSPARCでも使っとき uop cacheとメモリータイミングの問題とほぼ断定したのにまだ言い争いするのか >>660
uOPのキャッシュならRyzenの問題だってことだが 原因がどこであれ、簡単にデータ化けするようなCPUなんか使えない phronixが取り上げたからredditでも大きく話題になってるな
どうなるやら >>642
新モノだけに時間は等しく利益であり、価値なのだが、
それをFUDで潰されたら実害のある行為だと思うのだけどねー
企業には責任があって個人にはないと思うならそれはそれで良いんじゃない？
私はそうは思わないけどね
ただ個人の責任のとりようなんてそれこそ「十分に」謝れば済む程度だろうに
既に冷静な人らは問題が何処じゃなく誰になっている訳だし
生暖かく観察をするしかない uop cacheが安定性のアキレス腱状態なのは向こうの調査でもわかっているから、
何かしらの問題ありなのだろうとは思うが、それですらタイミング設定で確率が変わると設定なのか何なのかはっきりしないのが気持ち悪い。
これは695がうまく情報引き出してくれることに期待。
一方でお祭り連中は試験時間をgccで48時間だの、これはまずい問題(攻撃可能)だの、怒りとなんちゃら…
もはや何を言っているのかわからない。意味がないどころか問題を増やす変なパッチは騒ぎをまた盛り上がるし、あほかと
問題を特定して解決させるよう働きかけている派と、
大騒ぎと圧力によってのみ問題が解決されるとする派に分かれたのかなー
そのうちgcc一年動いた個体寄こせと言い出しそう あぁ～確かに130は時間的に社会人ではなさそうだったな
ガチ勢がわからんが東大院生かなんかかすげーな GPU複数ぶん回すために安上がりで電力食わないCPUがほしくてやっているだけ
別にAMDに拘りはないのだが競争でIntelのCPUが安くなる結果でも全然構わない
頼むから祭りやめてもらえないかな。
祭りのたびに向こうのレスポンスが遅くなる
パッチ作るのに十分なヒントは出ているんだから書くか、Intel買うか何でもいいけど何粘着してんのあれ ryzenのエラッタを発見した技術者って言うのを飯の種にしようとしたんじゃない？ これでThreadripperに間に合わなくなったな。恨むならあいつら恨んでくれー 問題は指摘してあるからさすがにEPYCは間に合うでしょ。うちには手の届かん代物だが
PCIe 60LaneはGPU 3台積んで10GbEで集約するのに魅力的なんだよ。ほんと邪魔しないでくれー >>677 おつｗ
散々邪魔してThreadripperに更新が間に合わなかったことを逆手に
「もっとSEGVする石！！」とか言い出すんだろうね。やれやれだ >>679
間に合いませんでした
731 Socket774 (ﾜｯﾁｮｲ 5176-3aaz) 2017/08/05(土) 16:31:21.72 ID:4qGhsG+k0
あらあら、EPYC でも segfault するらしい。
https://www.reddit.com/r/Amd/comments/6rmq6q/epyc_7551_mining_performance/ >>687
ま、こうなった以上しょうがない。本業がんばってくれ デスクトップ用CPUで期待されるエラー率 半年に1回以下のエラー率(宇宙線等でメモリのデータが化ける場合を除く)
サーバ用CPUで期待されるエラー率 10年に1回以下のエラー率
こんな感じでしょう >>690
連続稼働条件で？
それだとPCが50万円超えるぞ 私FX-8150ユーザだけどgccでmake -j8とかすると
たまに segment fault 出るよ
普通はもう一回実行すれば出てこなくなる
個人的にRyzenシリーズ固有の問題ではないと思っている まあ常に起こるのではなく、たまに起こる事だからね
失敗したらもう一度やれば問題ないし、どうしても嫌ならuOPキャッシュ切ってやれば大幅改善するし どこ製の何であろうとアンチが買って騒げば自動的にそうなるわな 最近知ったのだが、Raspberry Pi3(Arm4コア)でも-j4でSEGV出るそうだ
RPi3カーネルビルド再び...
http://tuttitan.hatenablog.com/entry/2017/02/11/114130
エラーログ(クリックして展開)の所を展開するとSegmentation faultがある
130氏は現時点全Ver(4.13含む)のLinuxでSEGVは出ると言っている
また>>692の事例、前述のRasPiの事例もある
Linuxも問題を抱えているという事は忘れてはいけない
アンチやどこぞの工作員はRyzen固有の問題にしようとしているようだが... 海外の記事だとLinuxに何かパッチ当てて終いでしょみたいな〆だった gccでSEGV出るのは原因は一つじゃない
ripが化ける問題までカーネルの問題だと思ってるのならすっこんでろとしか 買ってもない、検証する気もないのならすっこんでろとしか 検証してるよEPYCのリモート環境借りて
まだめぼしい収穫はなし
当たり前だけどビッグデータ寄りなのでAVX-512つかえるXeonのほうが数字でる とりあえず8ビット整数の畳み込み多用する機械学習用途だとGoldの18コアのほうがEPYCの32コアよりも速いという数字は得た
正式サービス開始まで借りていいことにはなってるがどうしたもんかねー Ryzenのuopsキャッシュの構造すら知らなかった阿呆は巣に帰れば？ CPUで畳み込みとかようやるわ
それこそCUDA回せよ つかxeonのavx512性能とかスレ違いだから
結局煽りたいだけのクズだな >>706
1-2UのラックサーバにP40なんか刺さるわけねーだろボケ
クラウドサービスの範疇超えてるし
まあ、ここまで差がついたら母艦としてもXeonのほうがコスパはるかにいいことはわかったわ 全く同じデータ投入して落ちたり学習結果がおかしくなったらgcc以外でも問題起こるエビにはなるだろ >>709
死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く
死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く
死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く
死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く 普通にGPU付きプラン出てるしそういう用途にはGPUプランになると思うよ
GPUの1/10の速度で勝ち誇るごく一部の無能以外はね ※ただし母艦はXeon
PCIe経由でホストのメモリネックになるからそこまで万能じゃない
ホストメモリのアクセス頻度の少ないタスクをGPUに振って残りをCPUでやるのが得策 GPUの話はスレ違だろ。他でやってくれ…
Linuxってのは元々、おれ環では動く。に対して問題が起きたらパッチ送って修正していくのが文化
IntelのCache構成から、昔はまともにmfenceなど置かなくても動いていたものが、
Pentium4でSMT導入されてから結構大規模に見直されたり、RCU導入してみたり、
それでも新しいマイクロアーキテクチャで問題が起きたら抜け漏れ特定してパッチ当てる。
ユーザーランドを壊さずに様々な問題をカーネル側の修正の積み上げで安定させる。
これが今まで普通に行われていた健全な文化だったのだが、今回はなんだかなあ
いつからカーネル開発者の貢献が、でたらめなパッチで炎上騒ぎを起こすことになったのやら…
コミッタークラスがこんなことやったら怒鳴り散らされて終わるんだが、全く意図が読めない。 あと、RIPがずれて報告される問題はuop cacheの問題じゃないよ。
パイプライン破棄時にRIP修正しないのは問題だが、
中途半端な状態でパイプライン破棄しなければならなくなるのは別の問題
もうヒント出てるっていう… 以下団子に関してはスルーでお願いします
マウンティングする為だけにレスをしてるので 自作スレにいる連中に難しい話して察しろと言われてもわかるわけないだろ Bulldozer以降の停滞でx86 Linux = Intel っつー図式がしみ込んで、おまけにずっとアーキテクチャが固定されていた結果、
ハードウェアの問題とはどんなものか、を開発者連中が忘れてしまったんじゃないの？
ハードウェアと常時格闘しているコミッターとかデバドラ開発者とかは別だが、
今回の連中のハードウェアに対する理解度の無さは、ちょっとねえ…ぬるま湯に浸かっていたと言われても仕方なし。
まあAMDにしてもさっさとBKDG出せよとは思うが、今回の件で更に遅れそうなのがあれだな。 >>715
シリアライズしてない場所がある、という事だろうか?(素人) XeonやEPYC扱うような信頼性や安定性重視な所はとっくにSEGV問題の解決やら対策ぐらいしてるでしょ 必ずフリーズするSkylakeバグは棚に上げてるよね。 4コア8スレッド8MB L3のi7発売からそろそろ8年
開発に携わって数年レベルだと
設計から何からCore iアーキの拡張版しか知らない連中も増えてるのは間違いない >>721
信頼性・安定性重視なところは、EPYCはせいぜい検証用に少数導入するくらいで様子見でしょ？
１年くらいたって問題なさそうなら本格導入が増えるかもね 察しろと言われてもについてはすまん
どのように公表するかは祭りになった以上、慎重に進めたいので待ってくれとしか コンテクスト切り替え時にmfenceしろみたいな話を言いたいんだろうけど
カーネルモード移行時にシリアライズされないみたいな話ならそれx86の仕様外の挙動で結局は「バグ」だよ SkylakeでサポートされたMPX/SGXもEPYCのMAPもUbuntuやRHELで正式サポートされるには来年春まで待たないといけない
そういう意味では双方猶予期間はあるかな IvyもHaswellもSEGVで落ちるものがあるので問題だね ryzen_segv_testとかいうデタラメソフトで落ちるのはソフトがデタラメだからでハードの問題ではない まあ少なくともRyzen側の問題と思われるのはページウォーク絡みで変なことが起きてる感じ reddit
EPYCでSEGV出たぞ！
Edit: 2600Kでも出ました
res: KAVERIでも出ました
いいねこの展開 >>736
起きてたら各レビューサイトが大荒れになりますよ >>737
それな。今までこの規模の試験など行われてきていなかったっていう
向こうで130が示したSPD読みすらいい加減な環境多いってのは大問題かも これがLinuxのバグなのかどうか確信が持てない…
Windowsユーザーはほとんど気にしなくていいんじゃないの？
エンコ化けてたり、突然ゲームが落ちるなんて話ならもっと大騒ぎになっている >>742 解析はしている。ただ、これマイクロコードで回避可能だろ…ってのと、
これ実はSkylakeでも問題起こすのではないのか？というところで悩みが。
地道に文通続けるよ…
>>714 >>719 >>724 が指摘しているように、
おれ環での「最速のこーど」が見直されるよいきっかけと捉えるかどうかかな
お祭り連中と同じにはなりたくないよ、正直。
あんなのと同列だと思われるのは研究者倫理にすら反する恥ずかしい行為なので… 確かにかっちり定めた環境では問題が起きないのと、564氏(あれは130氏のパラメータより緩めた)
2chですら頻度を激減させられているのに数分に一度と言われると
下手するとエラッタ扱いではなくて「マージン広げました」マイクロコード配布になる可能性が。
RedditもDRAM周波数落としたら問題なくなったーとかわけのわからんことを言いだしているあたりが何とも。
構造上Infinity Fabricが肝なのはわかっているのでコア部分のエラッタを認めさせるのは厳しいかも
そもそもLinuxはおれ環最適化を商用企業がパッチで修正する場になってもう何年って話で…
細かい問題はCoverityの検査で一掃されたが、同期関連までは読まないからな。-O0 でコンパイルできないのいい加減何とかしてくれ
Microsoftが証明に基づく設計を取り入れたHyper-Vの脆弱性のなさを見る限りではどれが正しいのかよくわからん
来週末こちらでも追試するからちょっと待ってくれー ASLRをオフにすると発生しなくなることがある、という点に留意しような。
正直これを見るとIntelでSEGV出ないのが不気味ではある。
有象無象のDDR4モジュールと同じく玉石混交のマザーを組み合わせて、何のエラーもなく動いている方がちょっと怖い。
>>736
WindowsではOSが強制的に処理する(致命的ならシステムごと落とす)か、放置状態なら他の要因が問題を起こすかのどっちかと上にあるぞ。
まあOSがタコ(いい意味でも悪い意味でも)なわけだが。 >>746
Windowsの基本思想として「誤ったデータが永続化されるくらいならばBugCheckで落とす」というのがあってな。
大きなところだと大学にMicrosoft本社のPh.Dがたまに講義開設してくれるので聞きに行くとよいかと ゴミポインタにデータ流しこんでリブートかかってた時代が懐かしい >>747
サンクス。実務作業ばっかりだと聞きに行く気力が湧かないが、そういうことなら興味出るな。
>>748
気持ちはわかるが…もうハードウェアはね…ソフト(デバッグ)も同じようなものだからアキラメロンとしか。 問題なのはIntel環境でのSPD読みを設定するだけで問題が1桁下がる報告に対して反論がなされていない点
結果的に一貫性のなさがRIPのずれだなんだのって話も問題なのだが、それ以前だろ…
数分に一回のレベルは、Kernel 4.11より前かつ、SPD読みおかしい。が130の検証だろ？
混乱の原因はいくつかあって、さすがにAMDにもわけがわからん状況だろう。2chが一番まともな皮肉
1. Kernel 4.8.0 - SMT bugで最近のIntelでも落ちる
2. Kernel 4.12.x - RCU関連の更新で実験場状態
3. SPD読みすらしないBIOS - そりゃ落ちるわ
4. DDR4設定おかしい - 公式がアナウンスしないから話がややこしいが改善はする
5. 古い電源だとRyzenのC6 Stateからの復帰に追いつかない - 知るかボケ
6. 刺し直したら状況変わった？？ - BTO買えば？
7. Windows？むしろWindowsでしか試験していないんじゃ？PTE CoalescingはWindows向きだし…
>>749
本郷の某大学の某研究室関係だとほぼ完全なWindows Kernel Source Codeが読める
その他の学生も、一部自分で復元しなきゃならんが8割のコードが手に入る…のは内緒だよ？ Redditも定格に落としたら問題なくなったとかわけわからんじゃん
コミュニティは以下略 >>752 どの世代？最近駒場がやばいので柏とかその他に分散されてきているよ。
空冷だのを先進DC(そっちの意味ではない)並に徹底しているのは電力つらいから。
本郷も研究室単位での消費電力管理が徹底されてきているのでつらい…。 メーカーに対する踏み絵みたいなもんだな
Windowsの特性的に誤魔化せていた部分が露わになってる 駒場は電力使用量問題で図書館の冷房すら落としてるぞ…。これが空冷になった理由の一つ
>>758
Windowsの特性なのかな？Windows NTはポータビリティのために64KiBページ粒度での管理
これはPTE Coalescing 32KiBと非常に相性がいいんだろうな。
Linuxはx86(32bit)からポーティングしていったが未だに当時のコードを引きずっていてな
元々x86から始まって、移植の際にそれぞれおれ環での最適化に進んでしまったLinuxと、
コンサバティブに設計され、検証走らせているWindowsを比べるのは筋違い。
どちらがよいとかそういう話ではなくて、建設的に話を進めるならばパッチ送るのが筋かと まあ大学に対しての予算の締め付けとか、8月も授業するとかそういうので大学の電力事情が逼迫するとかなんとか。 太陽光発電所でも併設すればよろし
バッテリは気の利いた奴がLi系電池寄せ集めて作るべ 論じゃ勝てないから特定して脅迫行為か？団子最低だな むしろ書き込みを公表されて地に落ちるような名誉なら最初から虚像ともいえるね どっかなら名前引っ張ってきたのか知らんが名前違ったら笑われもんだぞ団子 団子の名誉はこれ以上落ちようが無いからな
やりたい放題 AMD Confirms Linux Performance Marginality Problem Affecting Some, Doesn't Affect Epyc / TR
http://www.phoronix.com/scan.php?page=news_item&;px=Ryzen-Segv-Response
とりあえずRyzenについては問題を認めたと報じられてるけどカーネルの問題だけに仕立て上げようとしたやつ息してます？ Linuxカーネルだけの問題になってるのも意味不明だし（DragonfryBSDは無視？） http://egg.2ch.net/test/read.cgi/jisaku/1500079362/818
818 Socket774 (ﾜｯﾁｮｲ 5fe6-ElC9) sage 2017/08/08(火) 08:18:26.74 ID:IDWMZhns0
jekirl氏がEPYCでも発生すると言っていたのは他のCPUでも問題が起きるphoronixのbuild-phpであって
それ以外のストレステスト、kill-ryzenでは問題なかったそうで
EDIT 3: It looks like the conftest segfaults were due to the php build test. The other stress tests + kill-ryzen.sh have been running fine for hours now...
Fully stable for over a day so I stopped it to run benchmarks....I haven't been able to crash it without the build-php test running.
まあ少なくともEPYCで起きるという話は起きないという話より信憑性が落ちる形ですね 個体差で問題が起こることをAMDが認めた、とあれば全てのEPYCで起きないとも言えないね
（バリデーションの信頼性の問題だから） Windowsで起きないってのもそもそもWindowsではコンパイル環境作ってないから試してないだけの話じゃねーのかな
（Cygwinでクロスコンパイル環境作れるけど） 丸いの３つ、もう良いから少し黙ってろ
SH-3でゴリゴリしてた頃を懐かしんで見ているが
これを好機と見て変革すれば良いのだがね Xeonだって2年経ったらL2すり減って性能だだ下がりしても
インテル呼びつけてタダで交換させているけど誰も問題にしないだろう
個別交換でいいんだよ直らないのと爆発や融解するのはヤバイけどさ 選抜品を送ってみても壊れる謎の環境もあるらしいが。まだ見ぬエラッタ探しをやめてRMAバトルが勃発？ 選抜品で解決するなら、マイクロコード更新より手っ取り早いとの判断だったりして。
大騒ぎしているのが数十人だからそのほうが安上がりなのかもなー >>781
死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く >>783
初耳だな
L2の設計or製造ミスで定格使用でもエレクトロマイグレーションが起きてるって事か
型番 or 世代を教えてくれ すり減って性能落ちるの発想が理解できんかったがたぶんフラッシュメモリと勘違いしている お前らの分析やレポートなぞ役に立たなかったんだよｗ大勝利じゃんｗ >>790
死ね殺されろ早く死ね殺されろ早く死ね殺されろ早く uOpCacheの問題はB2だと発生しないのか？
あとメモリータイミング問題はB1ステッピングは下手したら捨てられかもしれんね なんとなく意図は読めた。AMD株買っておこうかな… 5/2の下げみたいな下げがほしいな。もう一度祭りやってもらえないかなー(ゲス 認めるがリコールはしないってふざけてるな。誰かリコールに追い込めよ。 当たり屋紛いのチンピラヤクザの言い掛かりにすらちゃんと応えるAMDの神対応すげぇな
それに比べて爆熱の落第CPUの烙印を押されてもシレっとグリスバーガーを使い続けるintelの糞っぷりが際立つわ リコールにしないのではなく、リコールに踏み込めないんじゃないか？
恐らくAMD内部でも「（初期生産Ryzenと後期生産Ryzenと）何が違うのかが分からない、どれぐらいの規模になるのかも不明」
でまだ特定に至らずで調査中なのかと
中にはPCの環境（スペックやBIOS設定等）のせいで起きている事例も集まっているから余計にややっこしいことになってるとかな
EPYCはともかく、B1ステッピングのはずのThreadripperでは起きてないらしいからさ マイクロコード更新前にクレイマーにPRO用の選別品返してるんじゃ… 問題の初出がDragonFlyだったことも忘れて、なーーーーにがカーネルの問題だあたまでっかちが DragonFlyのトランポリン問題は元々Intelで問題が起きたからLinuxでは対処されていた事実について… 世の中には自分の発言を忘れる人もいるんだし仕方ないよ
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万円切るって宣言した俺の発言ログとっとけよ
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冬の時代になるから今のうちに春を楽しんで置きたまえ どちらにしろ祭りはうざかったなー。あれがなければ2ヶ月半は早く何とかなっていたんじゃっていう… 詫び石詫び石って子供みたいにやらないでここおかしいですよができてればね… satとその周りの連中が騒いだから動いたわけじゃないだろ
あいつらは石交換しろ交換しろしかしていない
検証も不十分で何が大勝利なのだろうか エンジニアと繋がって初期レポート投げてからここまでの流れは本当に早かったなー 関連スレとか、いっとき自分はあいつら（sat一味)とは違う
みたいなのが前置きになってたからな AMDは問題を認めたがエラッタと認めてないからね
B1であるスリッパで確認出来ないなら本郷の言ってた初期BIOSによるメモコン破壊のほうが正しく見えるけど このスレにも相変わらず書き込んでるじゃん変な子
三点リーダーはコテハンのつもりなのかな あんな連中と一緒にはされたくないわ…
落ちが >>745 だったのでどうなの感あるが、マイクロコード更新でもこれ解消されると思うよ >>823
売名行為で先走って無駄に騒いだ様なのとは全然違うから大丈夫
核心をまだ非公開にしてるのは現在の状況では正解
引き続き頑張ってほしい 「賢いふりをしたノイズ」くそわろす
2chの専門板の大多数そうだよな 賢いふりをしてるつもりだったのか
頭が悪いようにしか見えないけど EPYCとThreadRipperで出ないと言われてもそんなん買うやつそうおらへんし 時間外取引で一時13ドル割れてるしそろそろ影響起きてるなあ intelでも世代を越えて発生してる当たり屋紛いのチンピラヤクザの言い掛かりエラッタにすらちゃんと応えるAMDの神対応すげぇな
それに比べて爆熱の落第CPUの烙印を押されてもシレっとグリスバーガーを使い続けるintelの糞っぷりが際立つわ sの字が欠陥欠陥詫び石詫び石って騒がずにこれこれこう言う環境で起きるんですけどって
冷静にやっとけばもっと対応早かったんじゃ無いの？
公演でなにを話すつもりだったのか気になるよね
逃げたから余計に スレチな話題引き合いに出してまでIntel論ってんの必死すぎだろ 空冷風見鶏おじさん
いい加減ちゃんとコテつけるか黙っててくんない？ Ryzen357はメモリアクセス？が非同期で
スリッパEPYCはチャンネル数が多いから十分な帯域が確保できるので
同期みたいな英文を読んだ気がする
だからスリッパEPYCでは起きないという主張はわからんではない 責任転嫁じゃ無くて余計な事しやがってと言う話でしょうが
頭悪いのかね？ 「AMDも」だろうな
Intelや業界も叩かれるべき >>851
ハイエンドにグリスバーガーという、誰得仕様。 賢いふりをしたノイズ君IDコロコロ変えて出没するのが笑える 2ヶ月半失われたくらい気にしなくてもいいんじゃない？自覚なさそうなのがあれだが。
ただ被害がひどかっただけにマーケティング教材になりそう gccって自己書き換えなんかやってたのね
自己書き換えとかループ展開ジャンプインなんてキャッシュがないマシンでやるものだと思ってたよ 結局ryzenのバグじゃん。
決めつけ力凄い人って恐ろしい。
断言ってホント信用ならない。 ある週以後の製造分では直っているという話も出てますが じゃぁ障害のあるロット回収して交換しなきゃな
実質のリコールか？ これ製造不良だよなぁ
販売店で交換対応とかにしてもらいたいわ intelでも世代を越えて発生してる当たり屋紛いのチンピラヤクザの言い掛かりエラッタにすらちゃんと応えるAMDの神対応すげぇな
それに比べて爆熱の落第CPUの烙印を押されてもシレっとグリスバーガーを使い続けるintelの糞っぷりが際立つわ じゃあIntelも過去製品から遡ってリコール対象やんか
Intelはんも罪やねぇ 初期BIOSのryzenメモコン破損疑惑は無くなったの？ Intelが8C16T 3.8GHzで動作するCore i7を$340で売り出せば何も気にせずにいられる オフィシャルなアナウンスはまだか？
blogとか検索してて俺も俺もとクレームつけた奴だけ対応して後は知らんぷりのつもりか？ 同じチップなのに製造分で違うのはなぜなんだ
パッチ配布できない場所なのか >>882
単純に製造の最適化によるものじゃない。
生産が安定できるまでは、試作品レベルの製品になってたって事じゃない？ 設計自体が全く変わってないとすればマージンの問題かテストのカバレッジの問題か でたらめな設定を無視するようにしただけだよ
何度もRMAしてなぜ突然動いたかのカラクリはこれ 24時間と要求されたので、試験後にロックかけて変更できなくなっているはず
BIOSいじれないなら専用機送るしかないでしょ
専用機、かっこいいなー RMA繰り返しても動かないと言われるんだから、そーゆーのもありなのかもな
マージンにばらつきがあったとして、何個も連続して外れると信じる人はここにはいないでしょ？
歩留まり1%かよ、あの界隈 >>803
多分、それじゃないかと思うよ。
再現出来る条件すら絞り込めない現象なら、そりゃ、リコール出しようないよね。と言う。 >>719
ほんとこれだよね(´･ω･`)
みんな、ヌルい、ヌルすぎるよ(´･ω･`) >>715
やっぱり、分岐予測周りかなー(´･ω･`) >>859
そこはびっくりしたよ。
自己書き換えなんて、圧縮したコードを展開する訳でもないのに、この規模のCPUで今時やるのかと。
自己書き換えが確実に反映されない可能性になる要素てんこ盛りだと言うのに…ハードウェア側やマイクロコードが対処仕切れるとは限らない、危ないまねするなよというか。 下位互換的にそういう環境でも都合の良い基本構成維持してるのでは？ ＜自己書き換え
既存OSに追いつけってんで、実装優先で古く泥臭い技法が残ってるしな Linuxカーネルは386は動作対象外になったけどいまだに486で動くように作られてるので、
古臭いコードはまだ残ってるはず
最低でもpentium pro以降、できればcore 2 duo以降専用にしないと
ただし、red hat等の商用Linuxは最新版ではレガシー切り捨てしてある x86の場合、レガシー切り捨てする一番いい方法は、
64bitLinuxで、64bitアプリ動かすことだね >>898
しかも一からあの辺りの基幹を精査してからな
思うにGCCは一度作り直した方が良いと思う
それが出来ないならゴチャってる証左でもあるけどさ
で、AOCCはどうなった くそなのは
出来損ないのcpuだろ
責任転嫁すんなや >>900
単独要因じゃ無いから厄介になる
両方潰せば後が楽
大体ワイのFXさんでもサブのCore君でもディストリ放り込んだだけなのにたまに狐とかターミナル落ちるってどういうこっちゃ
狐はまぁ落ちて当たり前みたいな風潮あるけど なんでBSDつかわないの？病気なの？それとも無能なの？ 結局原因は言えないけど直しておきました、というオチですか DragonFly BSDでworkaround patchが出ていた
ttp://lists.dragonflybsd.org/pipermail/commits/2017-August/626190.html >>905
クレーマー対策にはそれが一番。
暴れて騒ぎだすからな Linuxって元々サポートされてないのになんであんな大騒ぎするのか謎だった
しかもインテルでも起きてるのにね そのIntelでも起きてるって自分は馬鹿ですって言ってるようなもんだからやめたほうがいいよ >>910
なんでなのか説明(解析)できなのも馬鹿だってことか Linuxに問題が有ろうと無かろうと関係なく
Ryzenに問題が有ることは確か Linuxアンチが発生するのはさすがに知能が低すぎる >>913
同じryzenでも
winは発生しない
Linuxで発生する
悪いのはOS なるほど今まではsat氏やその他を叩いてたけど次はLinuxを叩くんだね
なんにも出来ないなら黙ってればよいのに RyzenはWindows向け
EPYCはLinux向け
それぞれの市場で問題ないんだからいいだろ
Linuxでカーネルビルドを大量にしたいならIntel買えばいいだけ
普通に使う分には問題ないから気にすんな、ハゲども 製造上の欠陥なんだから
時間経つにつれ劣化して増えそうだな
問題ないというなら証拠を出して説明しないと >>925
>>926
死ね殺されろシッタカ糞団子早く死ね 逆神団子が暴れてる = 問題ないの法則発動で皆んな安心して去っていった AMDが問題のある個体を出荷してたこと認めた以上、あとは個体差の問題だしな
全てが解決したわけではないにせよ このフンコロガシみたいなコテハンによると
Intelは不良品を一切出さない神企業らしい 交換に応じてるのは、問題が出る個体集めて原因究明のサンプルにする気なんじゃ？ >>937
ちゃんといつものようにエビデンスっていえよ団子 >>939
原因も何もIntelだろうが新旧だろうが見境なく出てるやん。
悪いのは糞OS使い続けてるおま環 コードのバグならエラー出る場所定まるだろ
石交換したら出なくなるとか、AMDの管理下に出来ていない個体差が不良出してるって事でしょ？ >>943
とは限らない
そんなもんコンパイラで検出できる
問題は出来ないバグ 精神を病んでることは確かだろうな
AMDへの拘りが異常だもん >>945
質問に対して質問で返す
しかも疑問に対して証明出来るかと
この辺が証明になってたりして まあ、ガチもんからは逃げ続ける負け犬クソ団子ですし 生え際とか後ろの下の方の髪に何かヅラのようなものが乗ってる感じ
髪質や色がかぶってると思われる上の部分と違う 結局2017年25週より前製造の個体(の一部?)に存在する問題みたいね
OSマザボBIOSメモリが全て同一の環境でCPUだけ交換すると起きなくなる、と
具体的に何が悪かったのかは全く公表されてないけど 25週って時期が絞れて今は問題が解消されてるって事なら
意図してかしないでかは解らないけど、何かしらの改修してるって事で
25週以前に改修計画もされていたけど、ユーザーには今まで何も伝えらてない訳だ 25週以降も問題がないわけではないのがカーネル開発者の主張では？
https://community.amd.com/message/2817335#comment-2817335 の803
3個目でUA 1725SUSもらったけどMCE起きるので
4個目の同じUA 1725SUSで問題起きなくなったとか何とか。
他に何か変えているかはこの文面だけではわからないが。
手元のは16週で問題起きなかったんだけど、まぐれなのかね？ RMAで送り返されてくるのが17週以降、特にLinux負荷試験要求に応えたのが25週以降だったのは
問題がある可能性がある個体が25週までの範囲になるとは思えない。
1週目を持っているという話も聞かないし、もっと細かい話になるような >>956 打ち間違え。問題が起きていない個体が12週だった(16週ではない) まとめると糞OS上のみで極めて限定的に発生するおま環問題。
Intelでも発生。製品の世代問わず発生。
Intelは問題そのものをまったく無視仕切ってる糞対応
AMDではその真逆の神対応 このキモチワルイコテハンに成りすましたというところは評価ポイントかとｗ >>960
お前も団子になれよ、やっててばかばかしいくらいばかになれるぞ >>960
まとめると糞OS上のみで極めて限定的に発生するおま環問題。
Intelでも発生。製品の世代問わず発生。
Intelは問題そのものをまったく無視仕切ってる糞対応
AMDではその真逆の神対応 >>964
ダウト。
初期のBIOSでメモコン酷使してぶっ壊している奴が暴れていただけだから >>962
まだそこまで割り切って落ちられないというか
色々未練があるというかｗ >>962
あ、ホントだ。
って、おい！(笑)
しかし>>959は的を射ている気がするよ >>965
今新品購入して組んだ状態でもSEGV発生してるようだし
初期BIOSでメモコン壊したという状況ではないだろ
AMDもわかってて個別対応してるような感じだよな
25週以降は直ってるというわけじゃないようだし >>970
初期BIOS（1.0.0.6未満）では既定のDDR設定がおかしく
それゆえのエラーもあったらしい >>972
普通に定格でなる
買いなおした新品で定格動作で即SEGVするから
SEGVする確率かなり高いんじゃないかと思ってるよ俺は
25週以降でそれが下がってることを願うけど
これ以上PC生やしてもしょうがないから様子見 定格で動かしてるつもりでもタイミングが定格どおりに設定されてないことがあるよ
C6Hとサムスン純正Bダイ2400モジュールの組み合わせで
BIOSが最新の1501でも自動設定だと定格よりきつい設定になってSEGVが起きる
手動でモジュールの定格どおりに設定したら発生してない >>971
マシとは言え今でも厳しいよ
メモコンに余裕ない個体はSEGV吐くし ESレベルだけどとりあえず出しちゃった的な
RMAﾏﾝﾄﾞｸｾｰ agesaが原因なら、結局amdのせいじゃないの？ >>977
おっと、Intel製品の悪口はそこまでだ >>979
IntelプロセッサのSEGVは無かったことにするの？ >>981
それはそれでIntelの責任じゃ無いの？
片方に文句言う奴は、もう片方の味方だとか、そういう傾いだ見方してる時点でもうダメだよ
それとも「Intel相手に騒がれてないんだからAMD相手にも騒がないで」って事？
両方騒いで、両方のメーカーに対応させりゃ良いんだよ
金取って買わせた物の不良なんだから >>985
自作スレいるくらいだからわかると思うけど
自作続けてるとパーツあまってくるからさ
最近はインストール簡単だしLinux自分もインスコするから
みんなもそうなんじゃない？
常用となるとゲームユーザーとかは無理だろうけど >>985
余ったパーツ動かしたり動作検証したりするにはWindowsって面倒臭すぎるもの >>985
いや全然少ない。このスレだけ多いように見える錯覚 一般人がLinux使うメリットってまるでないからな
中古パソコンですら大概はwin付いてくるし 電気代と自宅までの回線代考えればレン鯖のほうが手軽でいいよ >>991
BSD系でええやん、こんなスレ立つほどの問題のあるOSに拘る理由がわからんわ こんなスレがたつ問題を抱えたcpuにこだわる理由はないな >>994
intelCPUでもSEGVになるしな… 1台のマシンが組み上がりました。。。
新しい筐体を用意してくださいです。。。。
自作PC板＠2ch http://anago.2ch.net/jisaku/
life time: 58日 16時間 34分 1秒 ２ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ ２ちゃんねる専用ブラウザからの広告除去
★ ２ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.2ch.net/
▼ 浪人ログインはこちら ▼
https://login.2ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
