先日、リプレースが完了した、当サーバーの /var/log/messages を目視で確認していたたところ、見慣れぬエラーメッセージが目に入りました。
Feb 2 03:47:57 tokyo kernel: MCA: Bank 2, Status 0x940040000000017a Feb 2 03:47:57 tokyo kernel: MCA: Global Cap 0x0000000000000104, Status 0x0000000000000000 Feb 2 03:47:57 tokyo kernel: MCA: Vendor "AuthenticAMD", ID 0x662, APIC ID 0 Feb 2 03:47:57 tokyo kernel: MCA: CPU 0 COR GCACHE L2 EVICT error Feb 2 03:47:57 tokyo kernel: MCA: Address 0x6d2bdd40
kernel がエラーを吐いています。（tokyoはホスト名）
/var/log/messages の中でのMCA 文字列を検索してみると、CPU の機能のようで今使っている AthlonXP の機能の一つのようです。
kernel: Origin="AuthenticAMD" Id=0x662 Family=0x6 Model=0x6 Stepping=2
kernel: Features=0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,P AT,PSE36,MMX,FXSR,SSE>
AMD 専用の機能ではなく、Intel CPU にも含まれていました。以下は、Celeron 1.2GHz のもの。
kernel: CPU: Intel(R) Celeron(TM) CPU 1200MHz (1202.76-MHz 686-class CPU)
kernel: Origin = "GenuineIntel" Id = 0x6b1 Family = 0x6 Model = 0xb Stepping = 1
kernel: Features=0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,P AT,PSE36,MMX,FXSR,SSE>
検索してみると、Machine Check Architecture でCPU自身が正常動作していることを把握できるようにする機能のようです。
こんなメッセージが記録されるということは、相当やばいんじゃない？つまりハードウェアの故障の可能性があるのではないか！と慌てました。
さらに検索を続けると、
http://gihyo.jp/admin/clip/01/fdt/201205/28
に情報がありました。（ありがたや。）これでほぼ状況がつかめました。
messages に記録されているメッセージを正確に把握するには、AMD Athlon XP のハードウェアマニュアルを読んでみないとわからないので、私としては推測するしかないのですが、メッセージをぱっと見た感じ、L2 キャッシュの整合性（チェックサム）に異常が見つかり、それをEVICT (eviction)しようとしてエラーが発生した。常識的に考えれば、オンチップキャッシュにエラーが見つかったらそのデータは使えないわけですから、キャッシュをフラッシュするとか、リロードするとか、再計算する必要があります。GCACHE がどのキャッシュかわかりませんけどコードキャッシュを指すなら同じ命令がメインメモリにあるのでロードし直しで済みます。データキャッシュだと同じデータが別の何処かにあるとは限らないのですから、キャッシュ異常が見つかったプロセスはダウンさせるしか無くなります。core dump。それがカーネル部分なら Panic ですね。
上記URLの情報によると、今回のエラーは、「CPU 0 COR」になっているので CORrection （訂正）できた模様です。つまり、計算を継続できるという意味でしょう。messages には記録されていましたが、console.log には記録されていないので、FreeBSD から見るとレベルの低いエラーなのかもしれません。
今回のケースは、不気味なエラーが記録されていましたが、幸いなことに問題ではないと判断できます。
しかし、なぜこんな事が・・・・・
シングルコアCPUでキャッシュが異常を起こすってどういう原因？チェックサムエラーなんてユーザープログラムのエラーなんかじゃ起きないはずですから、電圧低下とかCPU温度上昇を推測します。しかし発生時刻が 3:47AM ですので、外部からのアクセスによるサーバー負荷が上昇する時間じゃありません。
考えられることは、BOINC。同じエラーが出るようであれば、CPU負荷を押さえる設定にするか、参加するプロジェクトを変更してみないといけませんねぇ。
それにしても、ここ20年以上 CPUのマニュアルを真面目に読んだことはないのですが、（プログラムバグではない状況で）CPUがエラーを起こすことを前提として設計されていたとは知りませんでした。