レンタルサーバ + Webシステム開発 = E-business
|
レンタルサーバ + Webシステム開発 = E-business
|
|
■レンタルサーバご利用参考資料 サーバご利用の参考にJF Project によるJF (Japanese FAQ)を掲載しています。
Linux JF(Japanese FAQ)Project. 一覧に戻る
The SIG11 problem
Rogier Wolff
R.E.Wolff@BitWizard.nl
小林雅典 - 日本語訳
zap03216@nifty.ne.jp
13 January 2001
Revision History
Revision 08 February 2001
カーネルをコンパイルする際の signal 11
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Table of Contents
1. はじめに
2. The Sig11 FAQ
2.1. カーネルコンパイル中の signal 11 って何が原因なの?
2.2. ソフトウェアが原因じゃないって、どうやって確かめたらいいの?
2.3. ハードウェアの問題だってことは確かなの?
2.4. ハードウェアの何が問題なんだろう?
2.5. RAM のタイミングに問題なんてありえない、よね?
2.6. ECC メモリを買ったほうがいい?
2.7. メモリテストは信頼できる?
2.8. カーネルをコンパイルする時だけ起こるのですか?
2.9. Linux だけで起こるのですか?
2.10. いつも signal 11 なの?
2.11. 何をすればいいの?
2.12. RAM テスターって信頼できる?
2.13. Red Hat のインストールがうまくいかないのはなぜ?
2.14. ほかにはどんな可能性があるだろう?
2.15. エラーをもっと速く検出できる方法があるんだけど?
2.16. 誰のところで起こったの?
3. おわりに
3.1. 著者より
3.2. 日本語版の謝辞
1. はじめに
この FAQ は、近頃多くの人々を悩ませる現象はいったいどういった原因で起こ
ることがありうるのかを述べたものです。すなわち、Linux(*) カーネル (また
は、その種の大きなパッケージ) のコンパイルが ``signal 11'' でクラッシュ
するというものです。原因はソフトウェアのこともありますが、ほとんどの場
合はハードウェアにあります。読み進めると、詳細が分るでしょう。
(*)もちろん、Linux 固有の現象ではありません。もしハードウェアがいかれて
いるのなら、Linux, Windows 3.1, FreeBSD, Windows NT, NextStep はすべて
クラッシュするでしょう。
英文の最新版は http://www.BitWizard.nl/sig11/ で入手できます。
フランス語で読みたい方のために、フランス語訳が http://
www.linux-france.org/article/sig11-fr/ で入手できます。
日本語訳 (この文書) の最新版は、 http://www.linux.or.jp/JF/JFdocs/
GCC-SIG11-FAQ/ で入手できます。
原文のスペルミスを見つけた、耳寄りな追加情報がある、あるいは「わたしも
同じ目にあった」なんて話があれば、R.E.Wolff@BitWizard.nl にメールをくだ
さい。 (注――技術的にナンセンスと考えられるものは却下します) サブジェ
クトに ``sig11'' か、そのような言葉を書き添えてもらえるとありがたいです
。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2. The Sig11 FAQ
2.1. カーネルコンパイル中の signal 11 って何が原因なの?
質問
(カーネルを) コンパイルしていると、
gcc: Internal compiler error: program cc1 got fatal signal 11
と出てクラッシュします。コンパイラの何がまずいのでしょうか? コンパイラ
のどのバージョンが必要なのでしょうか? カーネルにどこか不具合があるので
しょうか?
答え
おそらく、コンパイラにせよカーネルにせよ、お使いのソフトウェア環境には
何も悪いところはありません。ハードウェアとの関係が大いにありそうです。
まずそうな部分はいろいろあり、直しかたも様々です。読み進めると、詳細が
分るでしょう。この「法則」には、2 つの例外があります。仮想記憶が不足し
ている場合と、Red Hat 5.x または 6.x のインストールの最中です。この文章
の最後のほうに詳しく書いてあります。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2.2. ソフトウェアが原因じゃないって、どうやって確かめたらいいの?
質問
オッケー。ソフトウェアが原因じゃないって、どうやって確かめたらいいの?
答え
最初に、トラブルの原因がハードウェアであることを確認してみよう。 make
が停止したら、もう一度 make とだけタイプする。停止する前にもう少しだけ
ファイルをコンパイルしたなら、トラブルの原因はハードウェアに間違いない
。また即座に停止する (すなわち、``nothing to be done for xxxx'' を表示
しながら少しばかりディレクトリをスキャンした後、きっちり同じ場所で玉砕
する) なら、
dd if=/dev/HARD_DISK of=/dev/null bs=1024k count=MEGS
を試してみよう。
HARD_DISK を ``hda'' とかのハードディスクの名前 (例えば、hda や sda な
ど。df . すると出てくる) に、 MEGS を搭載メインメモリのメガバイト数に置
き換えて。これを実行すると、ハードディスクの最初の何メガバイトかがメモ
リに読み込まれるので、次回 make する時には、C のソースファイルと gcc バ
イナリは、ディスクからメモリへ再度読み込まれることを強いられる。ここで
もう一度 make してみよう。もし、依然として同じ場所で停止するのなら、あ
なたが読むべきなのはこの FAQ なのかどうかあやしくなってくる。なぜなら、
結局のところソフトウェアの問題のように思われてくるから.... 下にある「ほ
かの可能性はなんだろう」って質問をちょっと見てね.....
もし、この dd コマンドを実行してないうちはコンパイラが同じところで止ま
り続けて、 dd の実行後は別のところに移動するのなら、ディスクからメモリ
への転送に問題を抱えているのは確実だ。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2.3. ハードウェアの問題だってことは確かなの?
質問
本当のところ、signal 11 ってどういう意味なの? ハードウェアの問題だって
ことは確かなの?
答え
いいかい、コンパイラが、コンパイラの管理するメモリ区域の外側にアクセス
したんだ。もし動作中のハードウェアでこいつが起こるなら、コンパイラの内
部にプログラミングの間違いがあるってこと。それで ``internal compiler
error'' っていうわけ。でも、gcc はとてもたくさんのポインタを使うものだ
から、ハードウェアがときたまビットを反転させてしまう場合、しまいにはア
ドレッシングレンジの外側のどこかにアクセスしちゃいそうになる。 (めちゃ
くちゃなアドレスはたいていアドレッシングレンジの外側になっちゃう。なぜ
って、メインメモリに 4G ものお宝をもってるひとはめったにいないから... :
-)
近頃 ``signal 11'' 問題に遭遇したひとはみんなこのページに直行するみたい
だ。でも、もしあなたが自作のソフトウェアを開発している、もしくはまだ十
分にデバッグされてないソフトウェアをもっているのなら、 ``signal 11''
(または、segmentation fault) は依然としてプログラムの不具合を知らせると
ても強力なヒントになる。``gcc'' のようなほとんど誰のところでも動作して
るプログラムで、これまたよくテストされたデータセット (例えば、Linux カ
ーネル) のクラッシュを引き起こした場合だけが、ハードウェアに不具合があ
るヒントとなるんだ。
もし、システムの中で、ハードウェアのドライバに類するソフトウェアが壊れ
ていたら、ハードウェアの故障に酷似した症状が起こることもありうる。でも
、ドライバがダメな場合は、単にコンパイラのクラッシュを引き起こすことよ
りも、カーネル内部の深刻なトラブルを引き起こすことのほうがありがちだ。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2.4. ハードウェアの何が問題なんだろう?
質問
オッケー。ハードウェアの何が問題なんだろう?
答え
もしハードウェアがそいつを引き起こすなら、原因は:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2.4.1. メインメモリ
メインメモリ。メインメモリがときたまビットを間違うのかもしれない。もし
「書き込み」の際に起こるなら、パリティーエラーが現われることはないだろ
う。いろんな解決策がある:
・ メモリの速度が遅すぎるのかも。BIOS の wait states の数値を上げる
。
AMIBIOS の autoconfig option で起きることがある――今だと 100MHz の
486 が買えるけど、autoconfig option は 80MHz までの 486 しかちゃん
と認識しないかも。 -- Pat V
・ メモリの速度が遅すぎるのかも。もっと速い DRAM SIMM を入手する。例
えば、現行の ASUS のマザーボードは 100 または 133MHz のプロセッサな
ら 60ns DRAM を要求します (マザーボードのマニュアルを見てね)。70ns
でも動きますが、ランダムな sig11 が起こりうるような信頼性の問題があ
ると報告されています.... (リスクは負いたくありません) -- Andrew
Eskilsson (mpt95aes@pt.hk-r.se)
・ 100MHz SDRAM は 100MHz で動作可能に思えるかもしれないけど、それは
間違いだ! http://www.BitWizard.nl/sig11/sdram.html を読んでみて。こ
のことが事実だと思う理由が書いてあるから。少なくとも、妥当と思われ
るスピードよりも一段階速いグレードのものが必要だ。
・ SIMM のうちの 1 つにまずいチップがあります。もしバンク 1 つ以上の
メモリがあるなら、SIMM を引き抜いて、問題が解決するかどうか見てみま
しょう。静電気に注意して!!!
・ 先週強烈なメモリのマシンを取り扱った。16MB SIMM が 4 つとも壊れて
いて、どれも 1 時間に 1 回ぐらいビットを落とすことが判明した。こい
つはだいたい 1 日でマシンをクラッシュさせたり、1 時間くらいでカーネ
ルのコンパイルをクラッシュさせたりするのに十分だった。で、まとめて
新しい SIMM に交換したら完璧に動くようになった。こいつを診断するに
は長い時間がかかった、なぜなら SIMM が 4 つとも同じようにいかれてい
たからだ。そんな訳でメモリを半分交換しただけでは何の変化もなかった
。
Mark Kettner (kettner@cat.et.tudelft.nl) からの報告です。彼のシステ
ムは、筆者謹製のメモリテストを失敗せずに 2300 回走らせることができ
たが、それから 10 前後のエラーが検出された。その後はまた二、三百回
失敗が検出されずに動き続けた..... 彼のケースでは、カーネルコンパイ
ルは、システムの健康を診断するよりいっそうすぐれた手段だった (最も
安定した設定で、クラッシュする前に 14 前後のカーネルをコンパイルで
きた)。彼は、古いメモリを自称「メモリアップグレード」するために「返
品交換」して解決することにした。店員がメモリテスターでテストした結
果、メモリは「異常なし」とのこと。そんな訳で、彼は新品のメモリを割
引きしてもらった :-)。
・ 30-72 ピンコンバータの中には、メモリエラーを引き起こすものもある
ようだ。 (この項目はめちゃ古いんじゃないかって? 誰が 30pin SIMM な
んて過去の遺物を憶えてるのかって? でも、これらのことはすべて SIMM
←→ DIMM コンバータや socket370 ←→ slot 1 コンバータにも完璧にあ
てはまるよ) (コンバータ上の 4 つの SIMM が壊れたのか、あるいはコン
バータに欠陥があったのかは、いまだに分らない。SIMM は、コンバータに
移し替える前は長年完璧に動いていたものだった....) -- Naresh Sharma
(n.sharma@is.twi.tudelft.nl).
Paul Gortmaker (paul.gortmaker@anu.edu.au) は、SIMM にきれいな電力
を供給し続けるためには、SIMM コンバータは少なくとも 4 個のパスコン
を備えるべきだと補足してくれた。
・ もし DRAM のリフレッシュがきちんと機能していないなら、DRAM は保持
している情報をゆっくりと失なっていくだろう。``hidden refresh'' を有
効にした場合、(486) マザーボードの中には正確にリフレッシュするのを
やめるものもある。リフレッシュをめちゃくちゃにして sig11 問題を引き
起こしうる ``DRAM'' まわりのプログラムもあるようだ。 -- Hank Barta
(hank@pswin.chi.il.us), Ron Tapia (tapia@nmia.com)
・ wait states の数値が低すぎるのかもしれない。BIOS の wait states
の数値を上げると直る。インテルの Endeavour board は、メモリの wait
states を上げることができない。これは MR BIOS をマザーボードに書き
込めば可能になると思われる。 -- David Halls
(david.halls@cl.cam.ac.uk)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2.4.2. キャッシュメモリ
キャッシュメモリ。キャッシュメモリがときたまビットを間違うのかも。キャ
ッシュには普通パリティーがついていない。BIOS のキャッシュの項目をオフに
することで、このケースに当てはまるかどうかが診断できる。もし直ったら、
おそらくキャッシュが原因だ。いろんな解決策がある:
・ キャッシュメモリの速度が遅すぎるのかも。BIOS の wait states の数
値を上げる。
・ キャッシュメモリの速度が遅すぎるのかも。もっと速い SRAM のチップ
に交換する。
・ キャッシュに壊れたチップがある。SIMM みたいに簡単にチップの交換は
できそうもない。静電気に注意して!!! -- Joseph Barone
(barone@mntr02.psf.ge.com)
・ チップセットのライトバックの実装にバグがある一方で、キャッシュの
ライトバックが有効になっているのかもしれない。こいつが起こるマザー
ボードは ``MV020 486VL3H'' (with 20M RAM) だった。-- Scott
Brumbaugh (scottb@borris.beachnet.com) (メールアドレスに届かない。
スコット、きちんと送り返せるアドレスで返事をくれ)
・ マザーボードが、スロットタイプのキャッシュと、時代遅れの DIP チッ
プのキャッシュを切り替えるジャンパを要求しているのかも。 (Rev 2.4
ASUS P/I-P55TP4XE マザーボードの JP16)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2.4.3. ディスク転送
ディスク転送。ディスクから送られてくるブロックが、ときたまビットエラー
にやられてるのかも。
・ もしこの問題があるなら、十中八九、問題をある地点から次の地点へと
「移動させる」ために dd コマンドを実行しなくてはならないようで
す....
・ IDE ハードディスクの中には ``irq_unmasking'' オプションを扱えない
ものがあります。この問題は負荷がかかっている時だけ出現するかもしれ
ません。 sig11 として顔を見せることがありえます。
・ kalok 31xx をもってる? ならゴミ箱にステステ。 (それか、DOS 野郎に
売りつけてやろう。更新――もう何年も kalok の噂を聞いたことがない。
たぶんつぶれちゃったのでしょう。ついでに言うと、ドライバは Windows
95 でも動きません。)
・ SCSI? ターミネーター? 短かいケーブルなら壊れたターミネーターでも
(信頼できないけど) そのまま動くかも。長いケーブルならやっぱりエラー
が出るかも。ホストとディスクのパリティーを有効にできる?
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2.4.4. その他
・ CPU そのもの。プロセッサのロットの中には、「故障」する確率が非常
に高いものがあります。数年前だとオリジナルのインテルペンティアム
120。 2, 3 年前だと AMD K6/2-300 (1998 年の 34 週目から 39 週目に製
造されたもの!)。最近だと AMD K6/2-450 です。まあ、400MHz ならいける
と判断するひともいるかもしれません。でも、この問題であることが判明
したら、新品のプロセッサを得る権利があります。買ったお店に行って、
交換してもらいましょう。 (P120 のことは忘れましょう。わざわざ交換し
に行く価値すらありません... ;-) -- Guillaume Cottenceau
(gcottenc@ens.insa-rennes.fr).
・ CPU そのもの。K6 プロセッサのロットの中には、単なる設計上のバグが
あるものがあります。 http://www.multimania.com/poulot/k6bug.html を
読んで、お手もちの K6 が返品交換できるか確認してみましょう。 --
Rongen (rongen@istar.ca).
・ オーバークロック。Cyrix P166 プロセッサは 166MHz ではなくて
133MHz で動作します。これは、Cyrix の連中にとってはきっと理にかなっ
たことなのでしょうが、部外者には想像がつきません。もし 166MHz で
Cyrix P166 をお使いなら、オーバークロックしていることになりま
す.....
・ オーバークロック。ベンダー (や個人) の中には、いくつかの CPU でオ
ーバークロックができると考えている方がいます。動く可能性があるもの
もあれば、動かないのもあります。ターボスイッチ (注――ほとんどのペ
ンティアム対応マザーボードは、もはやノンターボモードをサポートして
いません) をオフにしてみると、問題が解決するかどうかが分ります。CPU
の速度 (表面に印刷されています。必要なら慎重にファンを取り外して)
を、マザーボードのジャンパや BIOS の設定と比較して、チェック....
インテルでさえ、CPU のクロック刻印が間違ってることがあるようです。
目下、正規のペンティアムが妥当なクロックで sig11 を起こす、もっと低
いクロックにすると起きなくなる、という複数の信頼できる報告がありま
す。クロックの中には、ゆっくりしたプロセッサのクロックよりも、激烈
にマザーボードを痛めつけるだけのものもあるので (120MHz →マザーボー
ドのクロック 60MHz, 100MHz →マザーボードのクロック 66MHz) マザーボ
ードとの関係はなさそうに思います。付け加えると、新品の 120MHz のプ
ロセッサは今ちゃんと動いています。 -- Samuel Ramac
(sramac@vnet.ibm.com). これは、インテルやその競合メーカーに特有のも
のではありません。
・ CPU の温度。高速のプロセッサは、まともなヒートシンクなしだとオー
バーヒートするでしょう。ダメなファンでも起こることがあります。 (愛
機 '486 には、スピードが上がるのに 2, 3 分かかるファンがついていま
す。たぶん、実際のところこいつは決して落ちることはないでしょう。な
ぜなら、もう使ってないから:-) CPU は、カーネルのコンパイルによって
「酷使」されると、おかしくなることがあります。この問題は、LILO のコ
マンドラインオプションで HALT を無効にすると、いっそう悪くなります
。Linux は、システムがヒマな時に halt 命令を実行することによって、
CPU の消費電力減少を試みます。電力が温存され、したがってシステムが
ヒマな時は CPU の温度が低くなります。それゆえに単純なエディット作業
の時には、この問題に気付かないかもしれません。気温が高い時に、何時
間も CPU を激しくこき使った後にだけ表面化するでしょう。
もし Fdiv バグのペンティアムをおもちなら、インテルに交換してもらう
のが賢明です。正規のインテルおすみつきのファンで、あらかじめ設定さ
れた新品を送ってくれるでしょう。補足――たいていの一般的な接着剤は
熱伝導率が非常に悪い。ファンを CPU に接着する必要のある時に使うのが
妥当な、特殊な熱伝導率のよい接着剤が入手できる。 -- Arno Griffioen
(arno@ixe.net), -- W. Paul Mills (wpmills@midusa.net) -- Alan Wind
(wind@imada.ou.dk)
インテルいわく、CPU 外部の許容温度の範囲は:
0 to +85 C: Intel486 SX, Intel486 DX, IntelDX2, IntelDX4 processor
0 to +95 C: IntelDX2, IntelDX4 OverDrive(R) processors
0 to +80 C: 60 MHz Pentium(R) processor
0 to +70 C: 66 to 166 MHz Pentium processor
計り方の情報および、ここに書かれたことを確認するには、 http://
pentium.intel.com/procs/support/faqs/iarcfaq.htm を見てね。 (特に質
問の Q5 と Q6 と Q12。その文書はちょっと時代遅れになってきてるけど
、今なおとても正確。質問をすこし今風にすればさらによくなるみたい。)
・ CPU の電圧。マザーボードのなかには、CPU の電圧が選べるものがある
し、CPU の電圧を扱うジャンパの設定がへたくそなマニュアルに書かれて
いるものもある。 5V のプロセッサはほとんどの場合、3.3V でも依然とし
て動くように思われる..... -- Karl Heyes (krheyes@comp.brad.ac.uk)
・ RAM の電圧。ベンダーは今、3.3V RAM を用意してるみたい。たいていの
メモリは目下 3.3V。 (でも RAM の電圧を設定できるマザーボードをもっ
てるなら注意して―― 3.3V RAM は 5V 流すと壊れちゃう.....) (ほとん
ど気にしなくていいよ、自動で切り替わるに違いないと思うから。)
・ ローカルバスの過負荷。25MHz だと 3 つの VesaLocalBus (VLB) カード
が使えます。33MHz だと 2 つだけ。40MHz だと 1 つだけだし、50MHz だ
とたぶんゼロ! (つまり、50MHz のローカルバスのシステムが使えても、
VLB カードは 1 つも使えない)。システムの中には、VL バスに負荷をかけ
過ぎた場合におかしくなりはじめるものもあります。過負荷 (上記の限界
以上) でない時さえ、システムは余計な VLB カードの追加によって、きわ
どいところの 2, 3 ナノセコンドを失なうことがあるかもしれません。よ
って、新しい VLB カードの増設後、キャッシュの wait states かなんか
を上げる必要がでてくるでしょう.... -- Richard Postgate
(postgate@cafe.net)
・ 電源管理。ラップトップ (いまどきの「グリーン」 PC も) のなかには
、電源管理の機能をもっているものもあります。これらは Linux のじゃま
をするかもしれません。ある機能は、メモリイメージを HD にセーブして
おいて、キーを押した時にメモリを元の状態に戻すもののようです。こい
つはよさげですが、Linux のデバイスドライバは、2 回のアクセスの間に
ハードウェアがお休みするのをあてにしていません。復帰するものもあれ
ば、しないのもあります。試しに電源管理を無効にするか、カーネルの
``APM support'' を有効にしてみてください。 -- Elizabeth Ayer
(eca23@cam.ac.uk)
・ 積もり積もったホコリ。ホコリの中には、ちょっと電気を通して微弱な
ショートを起こすものがあります。どこかでキャパシタンツを増加させ、
タイミングの特性を劣化させるかもしれませんし、熱の発散を妨げてどこ
かをオーバーヒートさせるかもしれません。愛機のケースを開けて内部を
掃除するのはいいアイデアなので、年に一度ぐらいやるのをお勧めします
。豆知識――綿棒は、手の届かないところのホコリを突っつくのに役立ち
ます... -- Craig Graham (c_graham@hinge.mistral.co.uk)
・ CPU そのもの。何人もの人々が、CPU 以外にやばいものが見つからなか
ったと報告してきています。CPU とマザーボードに互換性がなかったこと
もあるのでしょう。インテル CPU がらみのレポートの波は 97 年 2 月に
過ぎ去りました。Cyrix/IBM 6x86 CPU を非難する新たな波がおしよせてき
ています。本当に CPU のせいなのかもしれませんが、マザーボードと CPU
のあいだに互換性がないせいかもしれません。少なくともマザーボードの
マニュアルに、古い 6x86 とは互換性がないと言及してあるのを見たこと
があります。筆者自身の経験では、このデバイスは全然悪くないです。カ
ーネルコンパイルの際のベンチマークでは、P166+ が P155 と同じくらい
(P120 より 1.3 倍速い) でした。
・ メモリの穴。多くの現行マザーボードは、リニアフレームバッファに 1
ないし 2 メガバイトを割りあてて、古い ISA のビデオカードを使うこと
ができます。これをやるためには、ちょうど 16MB の真下にメモリをマッ
ピングしなくてはなりません。実際、いまだかつてこんな機能を使ったひ
とがいるとは思えないのですが、もしメモリに穴 (BIOS のなかには、LFB
support の項目になってるものもある) があいているなら、マシンは間違
いなくおかしくなっちゃうでしょう..... -- Paul Connolly
(pconnolly@macdux.com.au)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2.5. RAM のタイミングに問題なんてありえない、よね?
質問
RAM のタイミングの問題だって? 1 ヶ月以上前に BIOS の設定をいじくった。
その間やまほどカーネルをコンパイルしたけど何もマズくなかった。RAM のタ
イミングに問題なんてありえない、よね?
答え
ありえるよ。RAM 工場には 60ns の RAM を作る機械と 70ns の RAM を作る機
械が別々にあると思ってるの? そいつは違うね! いっしょくたに作って、それ
からテストするんだ。60ns の規格に適合するものもあれば、そうでないものも
ある。もし作り手がそいつにふさわしい数字を振らなくてはならないとしたら
、61ns が振られるものもあるかもしれない。この場合、例えば 40 度以下の気
温の時に、君の愛機で動作するのはいかにもありそうなことだ。 (気温が上が
ると、チップの動作はのろくなる。それがスーパーコンピュータをべらぼうに
冷さなくてはならない訳)
でも、「夏の到来」や長時間のコンパイル作業で、コンピュータ内部の温度が
「限界」を越えるまで上がることはありえるね。 -- Philippe Troin
(ptroin@compass-da.com)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2.6. ECC メモリを買ったほうがいい?
質問
ちょっと安かったから、値段につられて ECC メモリじゃないやつを買っちゃっ
た。馬鹿みたい。高くても ECC にしとけばよかった。そうだよね?
答え
より高価な ECC メモリやマザーボードを買うと、ある特定のタイプのエラーを
防ぐことができます――それはアルファ線の通過によってランダムに起こるエ
ラーです。
たいていのひとは gcc を使ってみると、半時間以内に ``signal 11'' 問題を
再現できますが、いざメモリをテストしてみると、何時間続けても再現できま
せん。よって ``signal 11'' は、単にアルファ線がいきあたりばったりにビッ
トを反転させて起こるのではないことは明らかです。アルファ線が原因なら、
メモリテストでも再現できるでしょうから。これは何か別のことが起きている
のを意味しています。
ほとんどの sig11 問題は、CPU ←→ cache ←→ memory の経路でのタイミン
グエラーによって引き起こされる印象があります。この場合、メインメモリの
ECC は役に立ちません。いつ ECC を買うべきか? a) 物欲がうずいた時。b) た
くさん RAM をもってる時。(なぜ最小限の数値を挙げないのかって? 最小限は
、時流によってまさに「たくさん」変化するものだから。) 誰もが ECC メモリ
を使ってると猛烈に思いこんでるひともいます。そういうひとは ``a)'' の理
由からです。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2.7. メモリテストは信頼できる?
質問
メモリの問題だって? BIOS のメモリテストは OK だ。素敵な DOS のプログラ
ムもメモリは OK だって言ってる。メモリに問題なんてありえない、よね?
答え
ありえるよ。BIOS のメモリテストは全くの役立たずだ。良いか悪いかテストす
るどころか、実際に得られる以上のメモリがときたま OK になることさえある
くらいだ。
640k PC をもってる友人がいた (そう、640k PC でお分りの通り、昔々のお話)
、そいつの 2 つ目のバンクには、256kbit チップの代りに 64kbit チップが 1
つささっていた。実際には 320k のワーキングメモリがあったことになる。時
々、BIOS の 384k のテストが ``OK'' になることがあった。にもかかわらず、
特定のアプリケーションだけは落ちる。実際の問題を診断するのは、ひどく骨
が折れた....
たいていのメモリの問題は、特殊な状況の下でしか起こりません。そのような
状況がどういうものであるのかは、まだほとんど分らないのです。gcc はどう
もそういった特殊な状況を作り出す「みたい」です。メモリテスト、特に BIOS
のメモリテストはそうではありません。筆者はもう、Linux カーネルと優秀な
メモリテスターを収録したフロッピーの作成サービスはやっていません。その
話は勘弁してください......
その理由として、メモリテストだと、CPU はほんのわずかな命令しか実行しな
いことと、メモリアクセスのパターンが非常に規則的になりがちなことが挙げ
られます。このような状況の下だと、メモリのうちのほんのわずかな部分しか
酷使されません。もしあなたが電子技術を学んでいて、メモリテストに興味が
おありなら、何が起きているのかを理解すれば修士論文が書けます。顧客には
信頼性がないと主張されているのに、製造段階のテストでは落ちてくれないハ
ードウェアに悩まされてる計算機メーカーが、喜んでそのようなプロジェクト
のスポンサーになってくれるでしょう......
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2.8. カーネルをコンパイルする時だけ起こるのですか?
質問
カーネルをコンパイルする時だけ起こるのですか?
答え
いいえ。ハードウェアには、カーネルをコンパイルしてる最中なのかを知る術
がありません。カーネルのコンパイルは、あいにくハードウェアにとってはと
ても骨が折れる仕事なのです。それで、カーネルをコンパイルしている時にだ
けたくさん起こるのです。 gcc や glibc のような大きなパッケージのコンパ
イルも、sig11 の引き金になることが多いです。
・ 例えば、slackware のインストールスクリプトを使ってインストールし
ている最中に、「ランダム」にクラッシュするのを見たことがあるって話
がある.... -- dhn@pluto.njcc.com
・ カーネルから、(クラッシュダンプといっしょに) ``general protection
errors'' を受け取ることもある。普通は /var/adm/messages に記録され
ているはず。 -- fox@graphics.cs.nyu.edu
・ bzip2 が ``signal 11'' や ``internal assertion failure (#1007)''
でクラッシュするのに出くわしたひともいる。 bzip2 はとてもよくテスト
されているので、クラッシュしたとしても bzip2 自身のバグではなさそう
だ。 -- Julian Seward (jseward@acm.org)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2.9. Linux だけで起こるのですか?
質問
NT, Windows 95, OS/2, DOS だと、何もクラッシュしません。 Linux 特有の何
かに違いありません。
答え
まず第一に、Linux は上記のどの OS よりもハードウェアを酷使します。上に
挙げたマイクロソフト製のような OS の中には、とにかくいつクラッシュする
かまったく予測がつかないものがあります。マイクロソフトに電話して、「お
い、今日ウインドウズが落ちたぞ」なんて言うひとはひとりもいないでしょう
。とにかくもしあなたがそういう行動に出たとしても、相手は、ユーザーであ
るあなたがエラーを起こしたんだ (ドイツの雑誌に掲載された http://
www.cantrip.org/nobugs.html を見てね....) 今はちゃんと動作しているのだ
から、口をつぐむべきだ、などとほざくでしょう。
これらの OS には、Linux より「予測可能な」ところもあります。エクセルは
、いつもきっちり同じメモリ領域にロードされるはず、という意味です。した
がってこの場合、ビットエラーが起こった時に影響を受けるのは常にエクセル
になります。エクセルはクラッシュするでしょう。もしくは、エクセルがほか
のアプリケーションをクラッシュさせるでしょう。とにかく、落ちるのは単な
るアプリケーションで、メモリとは関係ないように思われるでしょう。
きっちりインストールされた Linux システムなら、エラーを起こさずにカーネ
ルをコンパイルできるはずだと確信してます。間違いなく、sig11 は起こりま
せん。 (** 例外――Cyrix プロセッサでの Red Hat 5.0。別のところを見てね
。 **)
実際のところ、Linux と gcc はほかの OS 以上にハードウェアを酷使します。
もし Linux 以外で、クラッシュするところまでハードウェアを酷使するものが
必要なら、 winstone を試してみるのが吉。 -- Jonathan Bright
(bright@informix.com)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2.10. いつも signal 11 なの?
質問
いつも signal 11 なの?
答え
いいえ。4, 6, 7 のようなほかのシグナルも、ときたま発生します。でも、
signal 11 が最もありふれています。
メモリに記憶された情報がいかれてしまっている時なら、何が起こってもおか
しくありません。バイナリの異常がもっと頻発しても不思議はないくらいです
。にもかかわらず、いつも gcc が signal 11 を受け取るものだと決めつける
のはかなりの偏見のように思われます。以下の現象も見られます:
・
free_one_pmd: bad directory entry 00000008
・
EXT2-fs warning (device 08:14): ext_2_free_blocks bit already
cleared for block 127916
・
Internal error: bad swap device
・
Trying to free nonexistent swap-page
・
kfree of non-kmalloced memory ...
・
scsi0: REQ before WAIT DISCONNECT IID
・
Unable to handle kernel NULL pointer dereference at virtual
address c0000004
・
put_page: page already exists 00000046
invalid operand: 0000
・
Whee.. inode changed from under us. Tell Linus
・
crc error -- System halted (During the uncompress of the Linux kernel)
・
Segmentation fault
・
"unable to resolve symbol"
・
make [1]: *** [sub_dirs] Error 139
make: *** [linuxsubdirs] Error 1
・
The X Window system can terminate with a "caught signal xx"
最初のほうは、カーネルが、実際にはメモリの間違った記憶によって引き起こ
されたものを、「カーネルのプログラミングエラー」と「勘違いする」ケース
です。最後のほうは、アプリケーションプログラムがこのトラブルによって終
了してしまったところです。
-- S.G.de Marinis (trance@interseg.it) -- Dirk Nachtmann
(nachtman@kogs.informatik.uni-hamburg.de)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2.11. 何をすればいいの?
質問
何をすればいいの?
答え
何が悪いのかをつきとめたい場合は、以下のことを試してみましょう... 注―
―これらの中には、コンピュータを著しく遅くするおそれのあるものもありま
す。これらの狙いは、コンピュータをきちんと動作させ、どこが悪いのかを絞
りこんでいくことです。情報を得られれば、例えばベンダーに故障箇所を交換
してもらうことができます。
・ マザーボードのジャンパを、より低い CPU やバスの速度に切り変える。
・ BIOS の画面で、''Load BIOS defaults'' を選択する。かならず、前も
ってディスクドライブの設定を控えておいてください。
・ (BIOS で) キャッシュを無効にする (スロットタイプなら、引き抜く)。
・ linux mem=4M のオプションで、カーネルを起動する (4MB 以上を無効に
する)。
・ メモリの半分を取り外してみる。かわりばんこに試す。
・ リフレッシュの設定をいじくる (BIOS)。
・ ほかの誰かからメモリを借りてみる。なるべく、ほかのマシンで Linux
が完璧に動くメモリにすべきです... (シリコングラフィックスの Indy も
メモリを借用する恰好のターゲットです)
・ もし、本当に解決したかどうか確かめたいなら、次のことを試してみよ
う:
tcsh
cd /usr/src/linux
make zImage
foreach i (0 1 2 3 4 5 6 7 8 9)
foreach j (0 1 2 3 4 5 6 7 8 9)
make clean;make zImage > log."$i"$j
end
end
生成されたすべてのログファイルが同一であれば正常です。 (最初の make
zImage で、依存関係がすでに確立されたことを確認します.....) メモリ
16MB で 100MHz ペンティアムだと、24 時間前後かかります。 (4MB で
386 だと約 3 ヶ月 :-)
・ 現在のハードウェア環境が安定しているかどうかをテストするもう 1 つ
の方法があります――様々なサイズのファイルの md5sum を計算させるの
が有効かもしれません (ファイルの作りかたは dd if=/dev/random of=
testfile bs=1024k count=
一覧に戻る
グリーンネット・トップページへ戻る |
