アカウント名:
パスワード:
それ、Linuxのバグじゃないの?
FreeBSDでは発生するらしい。Linux subsystem for windowsで発生するという報告もある。発生する条件はかなりシビアらしくて誰の言ってることが正しいのかもはっきり言ってよく分からない。
Linuxだけではなく、少なくともDragonflyBSD、NetBSD、FreeBSDで症状が報告されてます。さらに、AMDが公式にCPUの問題だったと認めている上、AMDから送られてきたCPUに交換するだけで直った報告もありますから、もはやLinuxやgcc側の問題であるという可能性は残っていません。
発生する条件は確かにシビアなんですが、今は数時間程度で症状を再現できるテストプログラムが公開されていますから、問題のあるチップか否かの判別は確実にできます。
でもほんの数日前までそのテストプログラムも怪しかったわけでしょ
http://www.phoronix.com/scan.php?page=article&item=ryzen-segv-cont... [phoronix.com]
> でもほんの数日前までそのテストプログラムも怪しかったわけでしょ
おいおい、ちゃんと記事読もうよ。
phoronixの人がずっと Ryzen を常用してて、ベンチマークの負荷とかもかけてたりしたのに全く問題なかった。でもその同じハードウェアで、1ヶ月くらい前から公開されていたhttps://github.com/suaefar/ryzen-test/commits/master [github.com]を実行してみたら、たったの88秒でくだんの問題が再現したって記事だよ。
つまりテストプログラムは1ヶ月くらい前にはもうあったわけ。数日前までわかってなかったのは phoronixの人だけ。前から AMD に相談していた人は、このプログラムのことは既にみんな知ってたんだよ。
>おいおい、ちゃんと記事読もうよ
??phoronixの人は他の負荷試験では一切問題が起きないことを確認してるんだが。通常のアプリケーションでは発生せずkii-ryzenとか意図的な過負荷プログラムのみで顕著に発生すると書いているつまり特定という言い方をしてる誤解を招かないためにアップデートで言及してるよ
> phoronixの人は他の負荷試験では一切問題が起きないことを確認してるんだが。
ちゃんと読みましょう。https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Test-Stress-Run [phoronix.com]では、くだんの ryzen-test とは別のプログラム、エンタープライズ・カスタマーが負荷試験・安定性テストのために以前から使っている「Phoronix Test Suite」のstress-runを使うと、SMTをオフにしていても 229秒で問題が再現すると書いてあります。さきほどの ryzen-test では SMT をオフにしていると 30分程度の時間をかけないと再現しないとも書いてますから、ryzen-test よりも Phoronix Test Suite の方が8倍くらい頻度が上がるわけです。
これのどこが「他の負荷試験では一切問題が起きないことを確認してる」んですか。
> 通常のアプリケーションでは発生せずkii-ryzenとか意図的な過負荷プログラムのみで顕著に発生すると書いている
それはこの人のふだん使ってるプログラムが軽いものだってだけですね。
ソフトウェア開発している人だと、CPUコア数分の並列度でLinuxカーネルのような巨大プログラムコンパイルする作業を日常的にやっている人が結構いて、そういう人は特に負荷試験とかしているつもりはなくても、この問題に気づいてました。というか、それが今回の騒ぎのきっかけです。少なくとも日本では。
もちろん、そういう高負荷な作業をしてない人も沢山いて、そういう人は問題に出会わないでしょう。Windows で再現してないってのも、たぶんそういう話なんだと思います。そういう人は交換せずに Ryzen を幸せに使ってればいいんです。
でも、Ryzen は高負荷なビルド作業をしている人にとって、Intel の CPU よりもはるかに魅力的な CPU であり、そういう人にとって、今回の件は現実の問題なんです。「意図的な過負荷プログラムのみ」なんて寝言を言うのはやめていただきたい。もしも問題なく動くのであれば、Ryzen は Intel の CPU よりはるかに開発マシン向けなんですよ。AMDがちゃんと認めて対応すると言ってるのに、何を考えて Ryzen のそういう可能性を貶めてるんでしょうか。
某twitterの人か、張り付いてるのよくわかる
phoronixの最初の記事はこれなんだよhttp://www.phoronix.com/scan.php?page=article&item=ryzen-segv-cont... [phoronix.com]
実際検証で何ページかあったが君なら確認してるだろう誤解を招くためupdate5が入った時点で消されている
AMD Confirms Linux Performance Marginality Problem Affecting Some, Doesn't Affect Epyc / TRhttps://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response [phoronix.com]
日付7日のアップデートで言及してるよこれの冒頭をしっかり読んでるの?
横から失礼あなたが指摘したい点がよくわからないんですが、特定の再現プログラムでなければ問題は起こらないってことですか?
http://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response [phoronix.com] > they are found to occur with many, parallel compilation workloads in particular上によれば、多数の並列コンパイルを走らせると起こる(事がある)って言ってるだけで再現プログラムでしか発生しないって事ではないでしょ?っていうか問題が起こったからその条件が発生しやすいようなプログラムを書いたわけで。
> Linux boxes have been wor
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
Linuxで発生するもWindowsでは再現しないこと (スコア:0)
それ、Linuxのバグじゃないの?
Re: (スコア:0)
FreeBSDでは発生するらしい。
Linux subsystem for windowsで発生するという報告もある。
発生する条件はかなりシビアらしくて誰の言ってることが正しいのかもはっきり言ってよく分からない。
Re: (スコア:2, 参考になる)
Linuxだけではなく、少なくともDragonflyBSD、NetBSD、FreeBSDで症状が報告されてます。
さらに、AMDが公式にCPUの問題だったと認めている上、AMDから送られてきたCPUに交換するだけで直った報告もありますから、もはやLinuxやgcc側の問題であるという可能性は残っていません。
発生する条件は確かにシビアなんですが、今は数時間程度で症状を再現できるテストプログラムが公開されていますから、問題のあるチップか否かの判別は確実にできます。
Re: (スコア:0)
でもほんの数日前までそのテストプログラムも怪しかったわけでしょ
http://www.phoronix.com/scan.php?page=article&item=ryzen-segv-cont... [phoronix.com]
Re: (スコア:1)
> でもほんの数日前までそのテストプログラムも怪しかったわけでしょ
おいおい、ちゃんと記事読もうよ。
phoronixの人がずっと Ryzen を常用してて、ベンチマークの負荷とかもかけてたりしたのに
全く問題なかった。でもその同じハードウェアで、1ヶ月くらい前から公開されていた
https://github.com/suaefar/ryzen-test/commits/master [github.com]
を実行してみたら、たったの88秒でくだんの問題が再現したって記事だよ。
つまりテストプログラムは1ヶ月くらい前にはもうあったわけ。
数日前までわかってなかったのは phoronixの人だけ。
前から AMD に相談していた人は、このプログラムのことは既にみんな知ってたんだよ。
Re: (スコア:-1)
>おいおい、ちゃんと記事読もうよ
??
phoronixの人は他の負荷試験では一切問題が起きないことを確認してるんだが。
通常のアプリケーションでは発生せずkii-ryzenとか意図的な過負荷プログラムのみで顕著に発生すると書いている
つまり特定という言い方をしてる
誤解を招かないためにアップデートで言及してるよ
Re:Linuxで発生するもWindowsでは再現しないこと (スコア:0)
> phoronixの人は他の負荷試験では一切問題が起きないことを確認してるんだが。
ちゃんと読みましょう。
https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Test-Stress-Run [phoronix.com]
では、くだんの ryzen-test とは別のプログラム、エンタープライズ・カスタマーが
負荷試験・安定性テストのために以前から使っている「Phoronix Test Suite」の
stress-runを使うと、SMTをオフにしていても 229秒で問題が再現すると書いてあります。
さきほどの ryzen-test では SMT をオフにしていると 30分程度の時間をかけないと
再現しないとも書いてますから、ryzen-test よりも Phoronix Test Suite の方が
8倍くらい頻度が上がるわけです。
これのどこが「他の負荷試験では一切問題が起きないことを確認してる」んですか。
> 通常のアプリケーションでは発生せずkii-ryzenとか意図的な過負荷プログラムのみで顕著に発生すると書いている
それはこの人のふだん使ってるプログラムが軽いものだってだけですね。
ソフトウェア開発している人だと、CPUコア数分の並列度でLinuxカーネルのような巨大プログラムコンパイルする作業を日常的にやっている人が結構いて、そういう人は特に負荷試験とかしているつもりはなくても、この問題に気づいてました。というか、それが今回の騒ぎのきっかけです。少なくとも日本では。
もちろん、そういう高負荷な作業をしてない人も沢山いて、そういう人は問題に出会わないでしょう。
Windows で再現してないってのも、たぶんそういう話なんだと思います。
そういう人は交換せずに Ryzen を幸せに使ってればいいんです。
でも、Ryzen は高負荷なビルド作業をしている人にとって、Intel の CPU よりもはるかに魅力的な CPU であり、そういう人にとって、今回の件は現実の問題なんです。
「意図的な過負荷プログラムのみ」なんて寝言を言うのはやめていただきたい。
もしも問題なく動くのであれば、Ryzen は Intel の CPU よりはるかに開発マシン向けなんですよ。
AMDがちゃんと認めて対応すると言ってるのに、何を考えて Ryzen のそういう可能性を貶めてるんでしょうか。
Re: (スコア:0)
某twitterの人か、張り付いてるのよくわかる
phoronixの最初の記事はこれなんだよ
http://www.phoronix.com/scan.php?page=article&item=ryzen-segv-cont... [phoronix.com]
実際検証で何ページかあったが君なら確認してるだろう
誤解を招くためupdate5が入った時点で消されている
Re: (スコア:0)
AMD Confirms Linux Performance Marginality Problem Affecting Some, Doesn't Affect Epyc / TR
https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response [phoronix.com]
日付7日のアップデートで言及してるよ
これの冒頭をしっかり読んでるの?
Re: (スコア:0)
横から失礼
あなたが指摘したい点がよくわからないんですが、特定の再現プログラムでなければ問題は起こらないってことですか?
http://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response [phoronix.com]
> they are found to occur with many, parallel compilation workloads in particular
上によれば、多数の並列コンパイルを走らせると起こる(事がある)って言ってるだけで再現プログラムでしか発生しないって事ではないでしょ?っていうか問題が起こったからその条件が発生しやすいようなプログラムを書いたわけで。
> Linux boxes have been wor