目次


Linuxハードウェア安定化ガイド: 第1回

CPUとメモリーのトラブルシューティング

Comments

Linux環境にいる多くのユーザーは、これまでたちの悪いハードウェアの問題に悩まされることがありました。Linuxコンピューターをセットアップし、お気に入りの配布ソフトウェアをインストールし、追加アプリケーションをコンパイルおよびインストールして、すべてが完ぺきに機能するにように設定したにもかかわらず、結局、新しいシステムに (何ということか !) 致命的なハードウェアのバグが見つかったという経験を、いったいどれだけのユーザーが体験していることでしょう。セグメンテーションの誤り、データ破損、ハード・ロック、損失データなど症状は何であっても、ハードウェアの欠陥が原因で、通常ならば信頼できるはずのLinuxオペレーティング・システムがうまく機能しなくなってしまいます。この記事では、異常のあるCPUとRAMを検出する方法を詳しく考察して、そのような欠陥から重大な損害が発生する前に、欠陥パーツを置き換えることができるようにします。

不安定性の問題を抱えており、それがハードウェアに関連しているのではないかという疑いがある場合、CPUとメモリーの両方をテストして、正常に機能していることを確認することをお勧めします。このような問題を抱えていない場合でも、CPUとメモリーのテストを実行することは大切です。これらをテストすると、タイミングの悪いときに直面していたかもしれないハードウェアの問題を、事前に検出できることがあります。その問題とは、データ損失を引き起こしていたかもしれないトラブルやその原因をいらいらしながら長時間必死に探すことになっていたかもしれないトラブルです。このような手法を正しくプロアクティブに適用することで、頭を抱えて悩む場面を少なくできるでしょう。また、自分のシステムがテストにパスすれば、システムが仕様通りであることがわかって安心することもできます。

CPUの問題

CPUに重大な欠陥がある場合、マシンはLinuxを起動できないか、または数分稼働しただけでロックしてしまうでしょう。このようなひどい状態にあるCPUは、症状が非常にわかりやすいため、欠陥として容易に診断できます。しかし、CPUには、見分けにくく診断するのが容易ではない欠陥も多くあります。一般に、不明確なエラーほど、理由のわからないロックを時々引き起こしたり、一定のプロセスが突然停止する原因となったりします。CPUのほとんどの不安定性は、CPUを「働かせる」ことによって引き起こされます。つまり、CPUに山ほど作業が与えられることにより、CPUがヒート・アップして異常を引き起こす可能性があります。CPUのストレス・テストの方法をいくつか見ていきましょう。

CPUの安定性を測る最善のテストの1つがLinuxにビルトインされていることを聞くと、驚くのではないでしょうか (それは、カーネル・コンパイルです)。gccコンパイラーは、一般のCPUの安定性をテストするのに優れたツールで、カーネル・ビルドには、たくさんgccが使用されています。ディレクトリー /usr/src/linuxから以下のスクリプトを作成および実行することによって、業界屈指のカーネル・コンパイル・ストレス・テストを実行できます。

cpubuildスクリプト
#!/bin/bash
make dep
while [ "foo" = "foo" ]
do
make clean
make -j2 bzImage
if [ $? -ne 0 ]
then
echo OUCH OUCH OUCH OUCH
exit 1
fi
done

このスクリプトは、カーネルを繰り返しコンパイルすることに気付くでしょう。その理由は簡単です。つまり、CPUには断続的に発生する不具合を持つものもあります。それがあってもカーネル・コンパイルを95%の時間完全に実行することができますが、一方でカーネル・コンパイルを時々失敗させる原因にもなります。通常その理由は、プロセッサーは、5つ以上のカーネル・コンパイルが実行されてから、ヒート・アップして不安定な状態に陥るためです。

上記のスクリプトでは、-jオプションを調整して、それに続く数字がシステムのCPUの数より1つ多くなるようにします。つまり、たとえば、単一プロセッサーには「2」を、デュアル・プロセッサーには「3」をそれぞれ使用します。-jオプションにより、カーネルをパラレルに構築して、各ソース・ファイルがコンパイルされた後、デッキに常に少なくとも1つのgccプロセスが存在するようにします。つまり、CPUにかかるストレスを最大にするようにします。Linuxコンピューターを午後中使用しない予定のときに、このスクリプトを実行して、マシンに数時間カーネルの再コンパイルを実行させてください。

起こりうるCPUの問題

スクリプトが数時間問題なく実行されたら、成功です! CPUは最初のテストにパスしました。ただし、上記のスクリプトが突然停止する可能性もあります。ほかの問題ではなく、CPUに問題があることはどのようにすればわかるでしょうか。そうです。gccによって以下のようなエラーが出された場合、CPUに欠陥がある可能性が高いといえます。

gcc: Internal compiler error: program cc1 got fatal signal 11

この時点で、CPUの状態には以下の3つの可能性があります。

  • "make bzImage" と入力してカーネル・コンパイルを再開すると、コンパイラーがまったく同じファイルで停止する場合、"make bzImage" と繰り返し入力します。10回ほど繰り返しても、ビルド・プロセスがこの特定のファイルで停止し続ける場合、CPUの異常が原因ではなく、この特定のソース・ファイルが原因で引き起こされている (珍しい) gccコンパイラー・バグが問題の原因となっている可能性が高いでしょう。ただし、最近のgccは非常に安定性が高いため、このようなことはめったにありません。
  • "make bzImage" と入力してカーネル・コンパイルを再開すると、少し後に別のシグナル11を取得する場合、CPUに寿命がきている可能性が最も高いでしょう。
  • "make bzImage" と入力してカーネル・コンパイルを再開すると、カーネル・コンパイルが正常に実行される場合でも、CPUが正常であるということを意味しているわけではありません。通常、これは、CPUの不具合が時々現れる、つまり通常はCPUがある一定の温度以上になったときだけ現れる (CPUは長時間使用していると温度が上がり、いくつかのカーネル・コンパイルを実行してから危険ポイントに達することがある) ということを示しています。

CPUの救済

高い負荷がかかったときにCPUにランダムな断続的エラーが発生する場合、CPUに欠陥はないといえるでしょう。つまり、それは単に適切に冷却されていないのが理由だからです。以下にチェック項目を挙げます。

  • CPUのファンはプラグインされていますか ?
  • ほこりが付いていませんか ?
  • 電源がオンのときファンは実際に回っていますか (また、適切な速度で回っていますか) ?
  • ヒート・シンクはCPUに正しく配置されていますか ?
  • CPUとヒート・シンクの間にサーマル・グリースが塗られていますか ?
  • ケースは適切に換気されていますか ?

すべての項目にパスしていたら、オープン・ケースでカーネル・コンパイル・テストを再実行します。カーネル・コンパイルを5分ほど続けてから、稼働しているマシンの中に手を入れ、電源のメタル・ケーシングの外側に触れてアースします。それから、注意しながら指でヒート・シンクを触って温度を調べます。異常に熱い場合、ヒート・シンクとファンの組み合わせがそのCPUにとって不適切である可能性が高いといえます。そのような場合、システムの冷却装置をアップグレードします。おそらくは、CPUは永久的な損傷を受けておらず、正常に機能すると思います。

究極のCPUテスト

カーネル・コンパイル・テストは、CPUの安定性をテストするには優れた方法ですが、さらに優れたCPUテストも使用できます。この方法を最後まで紹介しなかったのは、CPUの冷却が極端に不十分な場合、CPUはこのテストによって実際にオーバーヒートされ、 理論上 CPUに永久的な損傷をもたらす可能性があるためです。このテストは、問題なくカーネル・コンパイル・テストにパスするシステムを対象にしています。つまり、非常に大きなCPUの負荷を確実に容易に処理することができるシステムです。CPUが適切に冷却されると、このテストにはパスします。パスしない場合は、さらに冷却する必要があります。

「究極の」CPUテストを実行するには、まず、Lm_sensorsページ (参考文献 参照) に行き、lm_sensorsパッケージをダウンロードします。このソースのtarballには、状態モニター機能とのインターフェースを持つさまざまなカーネル・モジュールがあります。状態モニター機能は現在のほぼすべてのマザーボードに内蔵されています。このパッケージが正しくインストールされ、正しいモジュールがロードされると (prog/detect/sensors-detectスクリプトを使用してモジュールを特定する)、新しいファイルとディレクトリーが /proc/sys/dev/sensorsに表示されます。これらのファイルには、CPUのファンの速度、CPUとメインボードの温度表示値、マザーボードの電圧の表示値などの情報がすぐに利用できるように格納されており、すべてリアルタイムで更新されます。このパッケージを、モジュールとしてコンパイルする対象として構成定義し、sensors-detectスクリプトを使用して、起動時にロードするモジュールを特定することをお勧めします。お勧めする理由は、この構成にすることでよりよい結果が得られたという実績があるからです。

lm_sensorsモジュールをロードし終えたら、グラフィカルCPU/センサー・モニターをインストールすることをお勧めします。このモニターは、/proc/sys/dev/sensorsの "cat" ファイルを何度も参照せずに、CPUの負荷と温度をリアルタイムで監視できるようにします。この目的のために、gkrellm (参考文献参照) と呼ばれる優れた小さなプログラムを使用します。CPU使用、マザーボードの温度設定値など、多くの状態をモニターする、gkrellmアプリケーションのスナップショットを示します。

gkrellmの実行中
スクリーン・ショット

lm_sensorsと互換性のあるそのほかのグラフィカル・モニタリング・パッケージも利用できます。「リンク」セクション下のlm_sensorsホーム・ページにその一覧が表示されています。

準備段階の最後は、cpuburnプログラム (参考文献参照) のダウンロードです。この使いやすい小さなプログラムは、手動で作成したマシン命令の組み合わせを使用して、特定のCPUに最大ストレスをかけます。このストレスは、繰り返されるカーネル・コンパイルよりも少し強いものです。アーカイブ内には、P5- およびP6-クラスのプロセッサーを設定するためにカスタマイズされたさまざまな小さなプログラムをはじめ、AMD K6用の特別バージョンもあります。cpuburnタールボールのパッケージを開いたら、READMEファイルをお読みください。添付されているアセンブリー・ソース・ファイルのコンパイル方法が説明されています。これを実行すると、自分自身のcpuburnプログラムとなります。

さあ、テストを実行しましょう。通常、グラフィカル・センサー・モニターを始動させてから、ルートとしてcpuburnプログラムを起動します。次に、CPUの温度表示が上がって安定するのを監視して、cpuburnを1時間ほど実行したままにします。このようなステップを繰り返すうちにCPUの温度が異常な高さ (華氏160度ほどになると、「異常に高い」と見なす) に上がり続ける場合、CPUの冷却システムに大きな処置が必要です。また、マシンがクラッシュまたはロックしたり、あるいはcpuburnプロセスが停止してしまう場合、CPUの冷却機能に改善が必要です。そうでなければ、単に特定のCPUが仕様通りでないということになるでしょう。CPUの温度表示を使用して、この判断を行うことができます。一方、すべてが正常に動作する場合、システムは、直面するどんな問題にも対処することができるはずです。1時間ほどたったら、cpuburnプログラムを強制終了して、通常のオペレーションを再開します。

メモリー・テスト

CPUが完全に信頼できるということは本当に重要です。また、信頼性の高いRAMチップがあるということも同じくらい重要です。SIMMSやDIMMSは故障しないからテストなど必要ないと考える人もいます。残念ながら、これは間違いです。欠陥のあるメモリーは珍しくないため、必ず監視しなければなりません。また、欠陥のあるRAMは確かにあるけれども、どんなRAMのエラーも起動時のBIOSメモリー・チェックで検出できると信じている人もいます。これも間違っています。BIOSのメモリー・チェックでは、欠陥のあるRAMはほとんど検出されません。したがって、セキュリティーの欠陥検知をBIOSチェックに頼ってはいけません。

メモリーの欠陥の兆候

欠陥のあるRAMがあるとします。マシンに何か問題があるかもしれません。以下にコンピューターのRAMに欠陥があることを示す可能性のある警告サインを挙げます。

  • 多くのプログラムを一度にロードすると、特定のプログラムが理由もわからず停止してしまうことがある。
  • ファイルを開くと、破損していることがよくある。後で開くと、正常である。
  • タールボール ("tar xzvf") を展開すると、tarにより、タールボールが破損していると報告されることがよくある。後日再びタールボールを抽出しようとすると、今度はエラーが報告されない。同様の問題がgzipとbzip2でも発生することがある。

このような問題がある場合、システムのRAMに欠陥がある可能性があります。以下の方法を使って、ぜひRAMをテストしてください。また、このような問題がない場合でも、システムのRAMを適切にテストして、今後もRAMの予期しない不具合に悩まされることがないようにした方がよいでしょう。その方法を示します。

memtest86
幸い、ブート可能なフロッピー・ディスクにインストールされた優れたLinuxベースのメモリー・テスト・プログラムがあります。これは、memtest86 (取得するには参考文献 を参照) と呼ばれます。memtestフロッピーの作成は簡単です。まず、タールボールをダウンロードします。次に、アーカイブをアンパックして、バイナリー・ディスク・イメージを作成します。

# tar xzvf memtest86-2.5.tar.gz
# cd memtest86-2.5# make

次に、空の3.5" ディスクをフロッピー・ドライブに挿入して、次のように入力します。

# make install

数秒後、3.5" ディスクには、優れた小さなメモリー・テスターが格納され、いつでも起動できるようになっています。このテストを実行する最善の方法は、マシンが少なくとも6時間使用しないときを見つけることです。つまり、夜寝る (または仕事を終える) 直前にテストを開始するとよいでしょう。テストを開始するには、3.5" ディスクをドライブに入れてマシンを再起動します。システムが起動すると、memtest86プログラムがすぐに開始されます。

memtest86による開発マシンのRAMテスト
スクリーン・ショット

スクリーン・ショット

主なメモリーの不具合 (「使用できない」ビットなど) が数秒で検出されます。特定のビット・パターンによって引き起こされる障害 (残念ながらよくある) は、数時間では検出されないこともありますが、最終的には検出されます。memtest86が欠陥のあるビットを検出するとすぐに、画面の下にメッセージが表示され、テストは続行されます。朝になってモニターの電源を入れるとテストは完了しており、画面には何の警告も表示されていないならば、RAMの機能は完全に正常であることになります。ただし、「メモリーの欠陥の兆候」セクションにリストした問題が続く場合、RAMには、まれに発生する不具合があり、それを取り替える必要がある場合があります。

RAMの問題の解決

お使いのRAMがすべて正常に機能してくれればと期待しています。しかし、運が悪くても、すべてを失うわけではありません。欠陥のあるRAMを「修正」できる方法はあります。まず提案するのは、BIOSセットアップ・プログラムに行って、メモリーの設定値を見ることです。BIOSセットアップ・プログラムには、"Turbo Mode" と呼ばれるメモリー・オプションを持つものがあります。もちろん、このようなオプションをオンにしている場合は、オフにします。また、BIOSとメモリーのタイミング設定値が正しくない可能性もあります。これを調整 (リフレッシュ・レートを高める、CAS設定を低くするなど) して、memtest86を再実行し、問題が除去されているかどうか確認します。

それでも、memtestでエラーが発見される場合は、欠陥のあるSIMMまたはDIMMを特定して、マシンから除去します。複数のメモリー・モジュールをインストールしている場合、モジュールを1つだけ (SIMMSの場合は2つ) インストールして、memtest86を実行します。すべてのモジュールを順々に実行していくと、どのモジュールに欠陥があるか特定できます。つまり、正常なメモリー・モジュールをゴミ箱に捨てなくて済みます。

今回は以上です。このシリーズの2番目と最後の回では、ハードウェア構成に関連する問題の解決方法を見ていきます。たとえば、IRQとPCIの待ち時間の問題などがあります。また、以下の参考文献を参照するとよいでしょう。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=228552
ArticleTitle=Linuxハードウェア安定化ガイド: 第1回
publish-date=03012001