新208.5日問題、LinuxカーネルのバグとXeonのバグの合わせで発生 42
ストーリー by hylom
前提条件が崩れちゃった 部門より
前提条件が崩れちゃった 部門より
かつてLinuxカーネルで発見され修正されていた「起動後208.5日経過すると勝手に再起動する」不具合が、完全には直っていなかったことが明らかになったようだ（新208.5日問題 - Systems with Intel® Xeon® Processor E5 hung after upgrade of Red Hat Enterprise Linux 6M）。
新たに発見された問題はXeon E5シリーズのCPUのみで発生するもので、「起動後208.5日経過すると勝手に再起動する」ではなく、「最後に電源停止を行ってから208.5日経過後に再起動を行うと再起動時にハングアップする」というもの。
そもそもの問題（Red Hatのサポートページ）は、駆動クロックに応じてカウントアップされるCPUの「Time Slice Stamp Counter（TSC）」というカウンタに対する処理と、この値を使ったスケジューラのコードにおける処理が不適切だったことで発生していた（この問題を解説したokky氏のブログ;）。
この問題は、スケジューラの処理を変更することで対処されたのだが、同様のコードがカーネルの起動時に使われており、かつXeon E5シリーズではwarm reset時にTSCのカウント値がリセットされない、という不具合が存在していたため、これらが重なってカーネルの起動時にハングアップするという問題が発症することとなったようだ。
サイドに (スコア:1)
サイドに電源停止、ってところで意味が分からず一分ほど黙考。
あきらめて最後まで読むとWarmresetの話が出てくるので、これは”最後に電源停止”の意味か。と気づく。
ここまで３分。
Re:サイドに (スコア:1, オフトピック)
すいません、typoです。修正しました。
Re:サイドに (スコア:2, おもしろおかしい)
何だって？ 修正しただと。
しっかりしろhylom、いつもの君じゃないぞ。
Re:サイドに (スコア:1)
ローマ字変換だとDとGでタイプミスするかなって思いますよね。
「もしかして：最後」みたいに予測結果出してくれるとうれしいかもしれないですね。
Re: (スコア:0)
いやいや「ここは『サイゴ』であって『サイド』じゃないよ～」とか考えながらタイプすると、何故かGがDになったりするよ。
このCPUのバグを発見した人を讃えたい (スコア:1)
というか、どうしてこれだと発見できたのか、そこを知りたい…
fjの教祖様
Re: (スコア:0)
CPUのBugはIntelが公開していますよ。
Re:このCPUのバグを発見した人を讃えたい (スコア:1)
うん、でも最初に何かしら症状があって、そこからCPUを疑って…で、Intel に報告。
Intelは調査して、「うわバグじゃん」となったわけですよ。
最初に「CPUを疑って」辺りに到達するまでのストーリーを知りたい、と言っているのさ。
最初に Intel の bug list があったわけではあるまい。
fjの教祖様
Re: (スコア:0)
再起動後にTSCを表示させれば、おかしいことには気付くのでは。案外偶々見つかったのかも
Re: (スコア:0)
何か修正しようとコードを読んでた人がたまたま以前fixされたバグと同じコードを見つけて、さらにその人がたまたまGEONのバグの話も知っていた、という方かも。
Re: (スコア:0)
勘違いかもしれないけど、最初にIntelのbug listあったんじゃないですかね
IntelのSpecification UpdateのRevision History見ると、April 2012で"Added Errata BT176-BT207"です
該当のBT81はそれより前なら、March 2012？
Re: (スコア:0)
たぶん元※の人は
「linux のバグの追及に最初にバグリストありき」を否定しているんじゃなくて、
「ｉｎｔｅｌのバグリストに最初にバグリストありきじゃないでしょ」って言ってるんでは？
つまり。「intelのバグリストに載せた時の追及した人をたたえたい」っていみかなぁと。
Re: (スコア:0)
いや、2012/3だと、発売時には既に公開されたたといいたかっただけです
つまり、intelのエラッタ表に最初からあった項目のはずで、発見/追及したのはintel自身の可能性が高いんじゃないかなと
Re: (スコア:0)
で、そのIndel自身はどうやって発見/追求したんだい？
Re: (スコア:0)
ハード側の問題なので、ソフト側から見つける以外の可能性もあるでしょう
当然、テストだって観点もやり方も違うでしょうし
大体、出荷時点でエラッタ表に載っているものの大半は、ソフトウェア側から見たらよく気づいたなレベルの話ですよ
Re: (スコア:0)
専門のテスト部隊を持っているところなら、その部隊が仕様に基づいて
論理設計部隊と独立して膨大なテストシナリオを作り、
シミュレーションなり実機評価なりで検証していきます。
驚くほどのことはありません。
Re:このCPUのバグを発見した人を讃えたい (スコア:2)
ひょっとして、検証が量産出荷に間に合わなかったから見切り発車で出したのかも。CPUだとたまによくあるような。
Re: (スコア:0)
Core-i7(Sandybridge-E)と比較すればわかるのですが、これ、Intelはかなり以前から検出済みの事象です。
http://www.intel.co.jp/content/dam/www/public/us/en/documents/specific... [intel.co.jp]
Sandybridge-Eの方はBS71.(TSC is Not Affected by Warm Reset)が該当し、これは2011/11の出荷時点でErattaに存在します。
ちなみにこっちはXeon E5の方では致命傷として扱われたBS90.(Xeonの方だとBT98.)が未修正で出荷され
つまり (スコア:0)
起動にしてから初期化プロセスが走るまでの時間が208.5日を超えると落ちるわけね。
普通はそんなことありえんから放っといたら、Xeon E5シリーズだとバグで再起動時にtscがリセットされなかったと。
Re: (スコア:0)
まあこれをLinuxカーネルのバグというのはちょっとかわいそうな気もする。
tscがリセットされるのが仕様ではなく、単に既存実装のふるまいだったとかなら別だけど。
Re: (スコア:0)
こんなに歴史と伝統があるintelのＣＰＵでも
こんなところのテスト漏れなんてあるんだねぇ。
Re: (スコア:0)
有名どころではPentiumのFDIVバグとかこれまでもいろいろやらかしてますがな
Re: (スコア:0)
リンク先の最後に
> kexec時も同様の問題が起きるはずですので、ご注意ください。
って書かれているのに気づいてる？
kexec であれば Xeon E5 シリーズでなくても発生する筈だし、 kernel panic 発生時の
kdump 取得のために cold reset を経由させるわけにもいかないし。
この問題は、例えば Ubuntu 12.04 リリース時点（ 2012-04-11 の 3.2.0-23.36
カーネル）にも存在していたけれど、 Ubuntu さんの対応が早かった（ 2012-05-01 の
3.2.0-24.38 カーネルで修正された）ので、未だにリリース時点のカーネルを
使い続けている人以外は引っかからないことでしょう。しかし
どこぞの会社風に言えば (スコア:0)
「横並びの漏れ」ですな。
再起動でwarm reset？ (スコア:0)
この手の問題が起こらないように再起動時はcold resetを行うもんだと思っていましたが・・・
linuxはイマイチですね
Re: (スコア:0)
cold resetを行うとBIOSの問題を引く可能性があります、intelとマザーボードベンダどっちが信用できますか
Re: (スコア:0)
この「208.5日問題」が問題になるような環境なら、動作検証済みのHWが使われているのでは？
Re: (スコア:0)
動作検証してればそもそも気づくだろ。
TSC (スコア:0)
> Time Slice Stamp Counter（TSC）
Time Stamp Counter じゃないの？
Re:TSC (スコア:1)
それな。
何度直しても Slice が復活するのよ。
<del>で囲ってやっても、しばらくすると del が消えて復活するんよ…
fjの教祖様
Windowsは危険(笑) (スコア:0)
OSSなら安全(爆笑)
Re:あほみたいにWindows2000の障害を叩いてたよね (スコア:1)
ええ。Linuxなんて捨ててRHELを使いましょう。そうしましょう。
Re:あほみたいにWindows2000の障害を叩いてたよね (スコア:1)
そりゃ毎月セキュリティ更新で再起動が必要なWindowsじゃ、
200日以上動かすなぞ論外だわな。
Re: (スコア:0)
Win vs Linuxのイデオロギーは別に無関係で述べるなら、メンテ作業で208.5日以内に再起動する必要があることと、208.5日で勝手に再起動したり、電源断から208.5日以降に再起動したらハングアップするのとでは問題が全く違うと思います。
サーバ管理者の立場で言うと、予定された保守作業で再起動するのはいいのですが、予定外に突然再起動が発生したり、リモートメンテナンスで再起動したら戻ってこなかったなどというのは痛いです。
個人サーバのLinuxならば、好きだから我慢できるのでしょうけど、顧客に提供しているサービスでそういう障害になったら、Linuxだからといってお客さんは許してくれることはありませんので。
Re: (スコア:0)
Linuxは再起動が必要なセキュリティ更新が200日以上提供されないんですね。
Re:あほみたいにWindows2000の障害を叩いてたよね (スコア:1)
ちょっとまじめに考えてみたけど、linux使ってて一年以上継続的に連続稼働は割とよくあるような気が。
windows serverもそれほど頻発するかって言われると、割とあるにはあるがそこまでではない気もする、けどどうだろう。
// 電源落とすと物理的な劣化が進むよ、って都市伝説っぽいのが一時期流行って連続稼働させてたのを思い出した
人の振り見て我が振り直せ (スコア:0)
じゃあ2000で直したはずのバグを再発させたWindowsも当然ステですね。
http://blog.livedoor.jp/blackwingcat/archives/1824244.html [livedoor.jp]
Re: (スコア:0)
リンク先だと「OS使いまわしているから同じバグが再発」系のコメントがついてますけど、これって違うんじゃ……。
32ビット幅のカウンタを10ミリ秒間隔でカウントアップしてたら、どのOSだろうが、誰が書こうが、どんな実装だろうが絶対に497日でオーバーフローしますよね。
むしろ、「この手のカウンタを32ビット幅にしてはいけない」という至極当たり前のことが周知されていないところに原因があるんじゃないかと。
（過去の失敗から学ぼうとしないという、より深刻な問題かも）
Re: (スコア:0)
32ビット幅だろうが、64ビット幅だろうが動かし続ければオーバーフローするわけで。。。
「32ビット幅にするな」ではなく
そもそも「オーバーフローを想定していない設計・コード・実装にするな」
では？
カウンタリセットしてもいいから、全体としてカウンタリセットに対応しとけと。
Re: (スコア:0)
64ビットだと4GHzで１クロックに１増やすとラップアラウンドするまで１３６年ちょっと。
電源等も含めたシステムの信頼性を考えればこの長さで今のところ十分では。
Re: (スコア:0)
捨てるはともかく
Linuxも人の事はいえないな