はじめまして、と208.5日でリブートするカーネルのバグについて
ryo kawaguchi
民間企業でエンジニアをしております、川口と申します。
よろしくお願いします。
早速ですが、約208.5日連続稼動するとリプートが発生するというカーネルのバグが
あるようです。
「sched_clock() overflow after 208.5 days in Linux Kernel」
http://kenichiokuyama.blogspot.com/
対策のためのアップデート情報などを、お持ちのかたは、いらっしゃいますか？
以上です。
Akemi Yagi
少し調べてみたところ、kernel 3.1.5にはこのバグの修正がはいっている
ようです。
RHEL/SL 6 のコード (timer.h) は修正されていないので、バグの影響は
ありそうです。しかし bugzilla.redhat.com あたりを探してみましたが、
それらしい報告は見つかりませんでした。
一番てっとりばやい(?)対策は200+日がくる前に計画的なrebootを行うこと
ではないでしょうか。で、どうせrebootをするのなら、上記のパッチを
いれたkernelをビルドしてそれを使うのがとりあえずの回避策としては
よいのではと思いますが。
2012/1/5 ryo kawaguchi <rka...@gmail.com>:
Akemi Yagi
RHEL-6のメーリングリストに問い合わせてみたところ、RHから次のような返事が
ありました。
======================================
From: Robin Price II <rprice redhat com>
To: rhelv6-list redhat com
Date: Fri, 06 Jan 2012 11:55:08 -0500
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=765720
This is private due to private information from customer use cases. If
you need further details, I would highly encourage you to contact Red
Hat support or your TAM.
Here is the initial information opened in the BZ:
"The following patch is in urgent fix for Linus branch, which avoid the
unnecessary overflow in sched_clock otherwise kernel will crash after
209~250 days.
In hundreds of days, the __cycles_2_ns calculation in sched_clock
has an overflow. cyc * per_cpu(cyc2ns, cpu) exceeds 64 bits, causing
the final value to become zero. We can solve this without losing any
precision. We can decompose TSC into quotient and remainder of
division by the scale factor, and then use this to convert TSC into
nanoseconds."
~rp
=========================================
Bzの内容が読めないのではっきりしませんが、おそらく緊急扱いになっているのでは
と想像しています。しかし次のkernel updateが修正されるかは出てみないと
わかりません。
2012/1/6 Akemi Yagi <amy...@gmail.com>:
Akemi Yagi
kernel update (2.6.32-220.4.1.el6) が RH よりリリースされましたが、
このバグの修正はされていません。:-(
2012/1/6 Akemi Yagi <amy...@gmail.com>:
Kamae Norihiro
RHからの今回のアップデートで, 本件が修正されたようです.
https://rhn.redhat.com/errata/RHBA-2012-0124.html
SLからももうすぐリリースされるでしょう.
--
釡江 典裕