The SIG11 problem Rogier Wolff 小林雅典 - 日本語訳 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. カーネルコンパイル中の signal 11 って何が原因なの? 2.3. ソフトウェアが原因じゃないって、どうやって確かめたらいいの? 2.4. ハードウェアの問題だってことは確かなの? 2.5. ハードウェアの何が問題なんだろう? 2.6. RAM のタイミングに問題なんてありえない、よね? 2.7. ECC メモリを買ったほうがいい? 2.8. メモリテストは信頼できる? 2.9. カーネルをコンパイルする時だけ起こるのですか? 2.10. Linux だけで起こるのですか? 2.11. いつも signal 11 なの? 2.12. 何をすればいいの? 2.13. RAM テスターって信頼できる? 2.14. Red Hat のインストールがうまくいかないのはなぜ? 2.15. ほかにはどんな可能性があるだろう? 2.16. エラーをもっと速く検出できる方法があるんだけど? 2.17. 誰のところで起こったの? 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 ってどういう意味なの? 質問 signal 11 ってどういう意味なの? 答え signal 11、正式には "segmentation fault" として知られている現象は、プロ グラムが、割り当てられていないメモリ領域にアクセスしたという意味なんだ 。だから、もしあなたが自作のプログラムを製作中なら、そのプログラムが原 因で起こるというのが最もありがちなんだ。でも、この FAQ ではそれ以外で起 こる可能性に専念しようと思う。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.2. カーネルコンパイル中の signal 11 って何が原因なの? 質問 (カーネルを) コンパイルしていると、 ┌──────────────────────────────────┐ │ gcc: Internal compiler error: program cc1 got fatal signal 11 │ └──────────────────────────────────┘ と出てクラッシュします。コンパイラの何がまずいのでしょうか? コンパイラ のどのバージョンが必要なのでしょうか? カーネルにどこか不具合があるので しょうか? 答え おそらく、コンパイラにせよカーネルにせよ、お使いのソフトウェア環境には 何も悪いところはありません。ハードウェアとの関係が大いにありそうです。 まずそうな部分はいろいろあり、直しかたも様々です。読み進めると、詳細が 分るでしょう。この「法則」には、2 つの例外があります。仮想記憶が不足し ている時と、Red Hat 5.x, 6.x, 7.x のいずれかをインストールしている最中 です。この文章の最後のほうに詳しく書いてあります。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.3. ソフトウェアが原因じゃないって、どうやって確かめたらいいの? 質問 オッケー。ソフトウェアが原因じゃないって、どうやって確かめたらいいの? 答え 最初に、トラブルの原因がハードウェアであることを確認してみよう。 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.4. ハードウェアの問題だってことは確かなの? 質問 本当のところ、signal 11 ってどういう意味なの? ハードウェアの問題だって ことは確かなの? 答え いいかい、コンパイラが、コンパイラの管理するメモリ区域の外側にアクセス したんだ。もし動作中のハードウェアでこいつが起こるなら、コンパイラの内 部にプログラミングの間違いがあるってこと。それで ``internal compiler error'' っていうわけ。でも、gcc はとてもたくさんのポインタを使うものだ から、ハードウェアがときたまビットを反転させてしまう場合、しまいにはア ドレッシングレンジの外側のどこかにアクセスしちゃいそうになる。 (めちゃ くちゃなアドレスはたいていアドレッシングレンジの外側になっちゃう。なぜ って、メインメモリに 4G ものお宝をもってるひとはめったにいないから... :-) 近頃 ``signal 11'' 問題に遭遇したひとはみんなこのページに直行するみたい だ。でも、もしあなたが自作のソフトウェアを開発している、もしくはまだ十 分にデバッグされてないソフトウェアをもっているのなら、 ``signal 11'' (または、segmentation fault) は依然としてプログラムの不具合を知らせると ても強力なヒントになる。``gcc'' のようなほとんど誰のところでも動作して るプログラムで、これまたよくテストされたデータセット (例えば、Linux カ ーネル) のクラッシュを引き起こした場合だけが、ハードウェアに不具合があ るヒントとなるんだ。 もし、システムの中で、ハードウェアのドライバに類するソフトウェアが壊れ ていたら、ハードウェアの故障に酷似した症状が起こることもありうる。でも 、ドライバがダメな場合は、単にコンパイラのクラッシュを引き起こすことよ りも、カーネル内部の深刻なトラブルを引き起こすことのほうがありがちだ。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.5. ハードウェアの何が問題なんだろう? 質問 オッケー。ハードウェアの何が問題なんだろう? 答え もしハードウェアがそいつを引き起こすなら、原因は: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.5.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.5.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.5.3. ディスク転送 ディスク転送。ディスクから送られてくるブロックが、ときたまビットエラー にやられてるのかも。 ・ もしこの問題があるなら、十中八九、問題をある地点から次の地点へと「 移動させる」ために dd コマンドを実行しなくてはならないようです.... ・ IDE ハードディスクの中には ``irq_unmasking'' オプションを扱えないも のがあります。この問題は負荷がかかっている時だけ出現するかもしれま せん。 sig11 として顔を見せることがありえます。 ・ kalok 31xx をもってる? ならゴミ箱にステステ。 (それか、DOS 野郎に売 りつけてやろう。更新――もう何年も kalok の噂を聞いたことがない。た ぶんつぶれちゃったのでしょう。ついでに言うと、ドライバは Windows 95 でも動きません。) ・ SCSI? ターミネーター? 短かいケーブルなら壊れたターミネーターでも (信頼できないけど) そのまま動くかも。長いケーブルならやっぱりエラー が出るかも。ホストとディスクのパリティーを有効にできる? ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.5.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) ・ マイクロコード。とりわけ SMP システムでは、CPU がマイクロコードのア ップグレードを必要としているのかもしれません。Pentium に割り算のバ グがあったせいで大惨事が起こったので、インテルは CPU のある領域をア ップグレード可能にしています。CPU は BIOS からの特殊な命令によって 少しバージョンを上げることができるのです。普通は使用しているマシン の BIOS によってこのアップグレードがなされるので、特に SMP システム をお使いなら、最新の BIOS になっているかどうかを確認してください。 -- Jeffrey Friedl (メールアドレスは非公開). ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.6. RAM のタイミングに問題なんてありえない、よね? 質問 RAM のタイミングの問題だって? 1 ヶ月以上前に BIOS の設定をいじくった。 その間やまほどカーネルをコンパイルしたけど何もマズくなかった。RAM のタ イミングに問題なんてありえない、よね? 答え ありえるよ。RAM 工場には 60ns の RAM を作る機械と 70ns の RAM を作る機 械が別々にあると思ってるの? そいつは違うね! いっしょくたに作って、それ からテストするんだ。60ns の規格に適合するものもあれば、そうでないものも ある。もし作り手がそいつにふさわしい数字を振らなくてはならないとしたら 、61ns が振られるものもあるかもしれない。この場合、例えば 40 度以下の気 温の時に、君の愛機で動作するのはいかにもありそうなことだ。 (気温が上が ると、チップの動作はのろくなる。それがスーパーコンピュータをべらぼうに 冷さなくてはならない訳) でも、「夏の到来」や長時間のコンパイル作業で、コンピュータ内部の温度が 「限界」を越えるまで上がることはありえるね。 -- Philippe Troin (ptroin@compass-da.com) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.7. ECC メモリを買ったほうがいい? 質問 ちょっと安かったから、値段につられて ECC メモリじゃないやつを買っちゃっ た。馬鹿みたい。高くても ECC にしとけばよかった。そうだよね? 答え より高価な ECC メモリやマザーボードを買うと、ある特定のタイプのエラーを 防ぐことができます――それはアルファ線の通過によってランダムに起こるエ ラーです。 たいていのひとは gcc を使ってみると、半時間以内に ``signal 11'' 問題を 再現できますが、いざメモリをテストしてみると、何時間続けても再現できま せん。よって ``signal 11'' は、単にアルファ線がいきあたりばったりにビッ トを反転させて起こるのではないことは明らかです。アルファ線が原因なら、 メモリテストでも再現できるでしょうから。これは何か別のことが起きている のを意味しています。 ほとんどの sig11 問題は、CPU ←→ cache ←→ memory の経路でのタイミン グエラーによって引き起こされる印象があります。この場合、メインメモリの ECC は役に立ちません。いつ ECC を買うべきか? a) 物欲がうずいた時。b) た くさん RAM をもってる時。(なぜ最小限の数値を挙げないのかって? 最小限は 、時流によってまさに「たくさん」変化するものだから。) 誰もが ECC メモリ を使ってると猛烈に思いこんでるひともいます。そういうひとは ``a)'' の理 由からです。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.8. メモリテストは信頼できる? 質問 メモリの問題だって? BIOS のメモリテストは OK だ。素敵な DOS のプログラ ムもメモリは OK だって言ってる。メモリに問題なんてありえない、よね? 答え ありえるよ。BIOS のメモリテストは全くの役立たずだ。良いか悪いかテストす るどころか、実際に得られる以上のメモリがときたま OK になることさえある くらいだ。 640k PC をもってる友人がいた (そう、640k PC でお分りの通り、昔々のお話) 、そいつの 2 つ目のバンクには、256kbit チップの代りに 64kbit チップが 1 つささっていた。実際には 320k のワーキングメモリがあったことになる。時 々、BIOS の 384k のテストが ``OK'' になることがあった。にもかかわらず、 特定のアプリケーションだけは落ちる。実際の問題を診断するのは、ひどく骨 が折れた.... たいていのメモリの問題は、特殊な状況の下でしか起こりません。そのような 状況がどういうものであるのかは、まだほとんど分らないのです。gcc はどう もそういった特殊な状況を作り出す「みたい」です。メモリテスト、特に BIOS のメモリテストはそうではありません。筆者はもう、Linux カーネルと優秀な メモリテスターを収録したフロッピーの作成サービスはやっていません。その 話は勘弁してください...... その理由として、メモリテストだと、CPU はほんのわずかな命令しか実行しな いことと、メモリアクセスのパターンが非常に規則的になりがちなことが挙げ られます。このような状況の下だと、メモリのうちのほんのわずかな部分しか 酷使されません。もしあなたが電子技術を学んでいて、メモリテストに興味が おありなら、何が起きているのかを理解すれば修士論文が書けます。顧客には 信頼性がないと主張されているのに、製造段階のテストでは落ちてくれないハ ードウェアに悩まされてる計算機メーカーが、喜んでそのようなプロジェクト のスポンサーになってくれるでしょう...... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.9. カーネルをコンパイルする時だけ起こるのですか? 質問 カーネルをコンパイルする時だけ起こるのですか? 答え いいえ。ハードウェアには、カーネルをコンパイルしてる最中なのかを知る術 がありません。カーネルのコンパイルは、あいにくハードウェアにとってはと ても骨が折れる仕事なのです。それで、カーネルをコンパイルしている時にだ けたくさん起こるのです。 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.10. Linux だけで起こるのですか? 質問 NT, Windows 95, OS/2, DOS だと、何もクラッシュしません。 Linux 特有の何 かに違いありません。 答え まず第一に、Linux は上記のどの OS よりもハードウェアを酷使します。上に 挙げたマイクロソフト製のような OS の中には、とにかくいつクラッシュする かまったく予測がつかないものがあります。マイクロソフトに電話して、「お い、今日ウインドウズが落ちたぞ」なんて言うひとはひとりもいないでしょう 。とにかくもしあなたがそういう行動に出たとしても、相手は、ユーザーであ るあなたがエラーを起こしたんだ (ドイツの雑誌に掲載された http:// www.cantrip.org/nobugs.html を見てね....) (訳注: 日本語訳は http:// www.unixuser.org/~euske/doc/nobugs-ja/ にあります) 今はちゃんと動作して いるのだから、口をつぐむべきだ、などとほざくでしょう。 これらの OS には、Linux より「予測可能な」ところもあります。エクセルは 、いつもきっちり同じメモリ領域にロードされるはず、という意味です。した がってこの場合、ビットエラーが起こった時に影響を受けるのは常にエクセル になります。エクセルはクラッシュするでしょう。もしくは、エクセルがほか のアプリケーションをクラッシュさせるでしょう。とにかく、落ちるのは単な るアプリケーションで、メモリとは関係ないように思われるでしょう。 きっちりインストールされた Linux システムなら、エラーを起こさずにカーネ ルをコンパイルできるはずだと確信してます。間違いなく、sig11 は起こりま せん。 (** 例外――Cyrix プロセッサでの Red Hat 5.0。別のところを見てね 。 **) 実際のところ、Linux と gcc はほかの OS 以上にハードウェアを酷使します。 もし Linux 以外で、クラッシュするところまでハードウェアを酷使するものが 必要なら、 winstone を試してみるのが吉。 -- Jonathan Bright (bright@informix.com) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.11. いつも 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.12. 何をすればいいの? 質問 何をすればいいの? 答え 何が悪いのかをつきとめたい場合は、以下のことを試してみましょう... 注― ―これらの中には、コンピュータを著しく遅くするおそれのあるものもありま す。これらの狙いは、コンピュータをきちんと動作させ、どこが悪いのかを絞 りこんでいくことです。情報を得られれば、例えばベンダーに故障箇所を交換 してもらうことができます。 ・ マザーボードのジャンパを、より低い CPU やバスの速度に切り変える。 ・ BIOS の画面で、''Load BIOS defaults'' を選択する。かならず、前もっ てディスクドライブの設定を控えておいてください。 ・ (BIOS で) キャッシュを無効にする (スロットタイプなら、引き抜く)。 ・ linux mem=4M のオプションで、カーネルを起動する (4MB 以上を無効にす る)。 ・ メモリの半分を取り外してみる。かわりばんこに試す。 ・ リフレッシュの設定をいじくる (BIOS)。 ・ ほかの誰かからメモリを借りてみる。なるべく、ほかのマシンで Linux が 完璧に動くメモリにすべきです... (シリコングラフィックスの Indy もメ モリを借用する恰好のターゲットです) ・ もし、本当に解決したかどうか確かめたいなら、次のスクリプトを試して みよう: #!/bin/sh #set -x t=1 while [ -f log.$t ] do t=`expr $t + 1` done while true do make clean make -k bzImage > log.$t t=`expr $t + 1` done 生成されたすべてのログファイルが同一(同じサイズで同じ内容) であれば 正常です。ひとつひとつのカーネルをビルドするのに、メモリ 512MB で 1GHz Athlon だと 4 分前後かかります。 (4MB で 386 だと約 3 ヶ月 :-) ・ 現在のハードウェア環境が安定しているかどうかをテストするもう 1 つの 方法があります――様々なサイズのファイルの md5sum を計算させるのが 有効かもしれません (ファイルの作りかたは dd if=/dev/random of= testfile bs=1024k count=)。RAM の 2 倍のサイズのファイルを用 いれば、ディスクが酷使されるでしょう。また、RAM より 4MB から 10MB 小さいファイルを用いれば、RAM と CPU が酷使されるでしょう。 しかしながらこの方法で、ありうる限りの問題が発見されるかどうかはは っきりしません。gcc はたくさんの異なった命令を様々な順序で実行する ものなので、単に md5sum が実行する命令の順序が、gcc が実行する命令 の順序とはきっちり一致しないかもしれないからです。でも、md5sum がエ ラーをもたらせば、カーネルコンパイルよりも問題が検出されるのがずっ と速いかもしれません。 -- Rob Ludwick (rob@no-spam) 上に挙げた手段のうち、メモリの借用だけは試せないというひとがほとんどで しょうが、やれるだけのことをやっても変化が見られないとなると、きわめて やっかいです。この場合は、本当に RAM そのものが原因だと言えそうなのです 。目下、RAM は PC の最も高価なパーツなので、こんな結論であって欲しくは ないでしょう。でも残念ながら、結局 RAM のせいだと判明したとの返事をたく さんもらってます。でもまだまだあきらめないで――RAM は全くのゴミではな いかもしれない――いつでも下取りに出して別の、もしくはより多くの RAM を 買うことができます。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.13. RAM テスターって信頼できる? 質問 RAM テスターの機械でうちの RAM をテストしたことがある。結果は OK だった 。RAM に問題なんてありえない、よね? 答え ありえます。RAM の中で今まさに起こっているエラーは、RAM テスターでは検 出できないように思われます。「あなたの」コンピュータでは、マザーボード があやしいやりかたで RAM をアクセスしているか、さもなくば RAM を混乱さ せているかもしれないからです。この場合の利点は、いまだに RAM テスターを 信頼してる誰かさんに RAM を売りつけてやれることです...... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.14. Red Hat のインストールがうまくいかないのはなぜ? 質問 うちで Red Hat のインストールが玉砕するのはなぜ? 答え マシンによっては、Red Hat 5.x, 6.x, 7.x のインストールには問題がいくつ かあります。 32M しかメモリを認識していない状態でのインストールを試して みましょう。普通、ブートパラメーターに mem=32m を指定すれば可能です。 Red Hat のインストールが、完璧な状態のマシンでうまくいかない (signal 7 もしくは signal 11 でクラッシュする) ことがあるとの報告をもらいましたし 、筆者もこの目でしかと見たことがあります。使っているマシンは昔も今も 100% 信頼がおけるものです。 (実際、テストに用いたそのマシンは、今でも完 全に信頼できます)。みんな、旧式の「ちゃんと動く」ディストリビューション を捨てて、トラブルに巻き込まれていきます。そのうえに、もっと新しいバー ジョンの Red Hat をインストールしたがるのです。さらにまた古いバージョン に戻すことは、もはや選択できません。なぜなら、5.x に戻したところで、結 果として同じ「インストール中のクラッシュ」に見舞われるからです。 Patrick Haley (haleyp@austin.rr.com) は、96MB (32 & 64) を上限として、 あらゆるパターンでメモリを装着してみたところ、96MB 載せた時だけはきちん とインストールできるのが分ったと報告してくれました。これは、筆者自身の (Red Hat のインストールに失敗した) 経験とも一致します――筆者の場合は、 32MB のマシンにインストールしようとして失敗したのです。 最新情報――カーネルに問題があるせいかもしれないみたいです。カーネルが 、(一時的に) メモリ不足におちいって、カレントプロセスを kill するのかも しれません。 Hubert Mantel (mantel@suse.de) によるパッチが http:// juanjox.linuxhq.com/patch/20-p0459.html で入手できます。 実際、このケースにあてはまるのなら、2 つ目の仮想コンソールに切り替えて (ctrl-alt-F2 を押す)、そこで 2, 3 秒ごとに sync と打つのを試してみてく ださい。これをやると、ハードディスクバッファとして割り当てられたメモリ の量が切り詰められます... Red Hat のインストールが 2 度 3 度と続けてク ラッシュした際に、このトリックを用いることでインストールを完了できたと いう方は、ぜひご一報ください!!! CD に読み取りエラーがあるのかもしれません。この場合、インストーラーの処 理は完璧にはほど遠いです..... この問題から逃れるには何をしたらいいのかって?... ・ SuSE を使う。こいつはベターだ――インストールの間クラッシュしない。 (おまけに、ディストリビューションとしてのできもベター。;-) ・ ひょっとして、お使いの CD に不良ブロックがあるなんて事態に遭遇して るのかも。ドライブによってはありえる話です。このケースにあてはまる なら、試しに別のドライブでその CD のコピーを作成してみましょう。そ れか、誰かの Red Hat を借りてきて試してみましょう。 ・ 1 ギガバイトものスワップを設定してみる。 1 ギガバイトのスワップを作 ったらうまくいったと、ふたりの方が報告してくれました。このやりかた が役に立ったら著者までご一報ください! ・ ハードディスクの「設定」を変更する。BIOS での設定を ``LBA'' から ``NORMAL'' に変えたことによって、少なくともひとりの方が救われていま す。もしこれを試したなら、R.E.Wolff@BitWizard.nl にメールをいただけ ると本当にありがたいです――このやりかたが有効なのかどうか、あなた から聞きたいのです。 (正確に、何をやったらきちんと動くようになった のか、も) ・ まず最低限の基本システムをインストールして、それからそこにパッケー ジを追加インストールするやりかたで、「筆者の」マシンにはインストー ルできました。 ・ この現象が起きる時、マシンがメモリを使いきっているのかもしれない、 と言ってくれた方がいました。スワップパーティションの設定がすでにな された状態で試してみましょう。また、たぶん少ないメモリの環境でもイ ンストールできるような機能が「用意」されているのにもかかわらず、イ ンストーラーが状況の判断を誤っているのかもしれません。例えば、ちょ うど 1M しか空きの RAM が残ってない状態で、さらに 2M のアプリケーシ ョンを RAMDISK にロードしようとしたのかもしれません。よって、もし RAM が 16M なら、mem=14M のオプションでブートすると、実際に効果があ るかもしれません、というのは、それから「RAMDISK にロードする」段階 で失敗して、それ以降は RAMDISK の代りに CD からインストールするよう になるであろうからです。 (昔はメモリが 8M のマシンにもインストール できたけど、今でもいけるかな?) ・ 一度、 Linux で使う予定があるすべてのパーティションをディスクから消 去して、リブートして、それからインストールしてみる、というのを試し てみましょう。手動でパーティションを切るか、インストールプログラム に計算させるか、どちらかの手段で。 (Red Hat にもこういった選択肢は あると思います。SuSE にはありますから...) もしこれで動作するように なったら、報告してもらえるとありがたいです。 ・ ダウンロードの過程で壊れちゃった場合でも起きる。はあ。 ・ もはや 8MB のマシンにはインストールできない、しかも sig7 でぶざまに 終了する、との報告がありました。 -- Chris Rocco (crocco@earthlink.net) ・ ``BIOS shadow'' (system と VIDEO の両方) を無効にすることが助けにな ったと、ひとりの方が報告してくれました。Linux は BIOS を使わないの で、shadow を有効にしても役に立ちません。コンピュータの中には、 shadow を無効にすると、おまけに 384k も RAM が増えるかもしれないも のもあります。無効にして、何が起こるか見てみましょう。 -- Philippe d'Offay (pdoffay@pmdsoft.com). ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.15. ほかにはどんな可能性があるだろう? 質問 ほかにはどんな可能性があるだろう? 答え ほかには、以下に挙げた可能性が記録されています: ・ Red Hat 5.0 に含まれているコンパイラと libc は、Cyrix のプロセッサ とは妙に相性が悪いです。コンパイラがクラッシュするし、こいつは「非 常に」奇妙です。仮にこれが事実だとしたら、Cyrix には現時点で未検出 のバグがあり、「その」 gcc が Linux カーネルをコンパイルする時にき っちり引き金を引く、としか考えられません。とにかくカーネルをコンパ イルしたいだけなら、Red Hat のウェブサイトから、新しいコンパイラと libc のいずれか、もしくは両方をゲットすべきです。 (トップページで errata をクリック) ・ 2.0.x のカーネルを、2.8.x の gcc もしくは任意のバージョンの egcs で コンパイルすると、きちんと動作しません。2.0.x カーネルには、gcc 2.7.x のジョブの最適化がゆるいせいで露見しないバグがすこしあります 。gcc 2.8.x や egcs だと、最適化しないように指定しなかったせいで、 そんなコードのいくつかがきっちりダンプされます。とにかく普段お使い の、一見ちゃんと動いているように見えるカーネルにも、奇妙なバグが潜 んでいるのです。例えばこの場合だと、X が signal 11 でクラッシュする かもしれません。おっと、訊かれる前に先まわりして答えておこう。いい え。この問題は修復される予定はありません。この話で Alan や Linus を わずらわさないで。いいかい? -- Hans Peter Verne (h.p.verne@kjemi.uio.no) ・ ペンティアムに最適化された gcc (バージョン番号のおわりが ``p'' のも の) は、デフォルトのオプションだと floppy.c のような特定のソースフ ァイルのコンパイルに失敗します。「引き金」は、カーネル、libc、gcc 自身にあります。この場合は、単純に「ハードウェアの問題ではない」と 診断できます。なぜなら、いつも同じ箇所で起こるからです。いくつかの 最適化を無効にする (最初に -fno-unroll-loops を試してみて) か、ほか の gcc を使うか、のいずれかをやってみるとよいです。 -- Evan Cheng (evan@top.cis.syr.edu) (言い換えると――gcc 2.7.2p は、floppy.c の コンパイルの際に sig11 でクラッシュします。回避策その 1――素の gcc を使う。回避策その 2――floppy.c を -O2 の代りに -O のオプションで 手動コンパイルする。) ・ ディスクとシステムの間の接続が不良。例えば、IDE ケーブルは 40cm (16 インチ) の長さまでしか許されていないのに、もっと長いケーブルを付け て出荷されるシステムが多いです。取り外し可能な IDE ラックも、システ ムをクラッシュさせるのに十分なトラブルの要因になるかもしれません。 ・ めちゃくちゃに設定された gcc -- あるバージョンの部分があり、別のバ ージョンの部分もあるもの。2, 3 週間後、すべてまともになるようにいち からインストールし直して、けりをつけた。 -- Richard H. Derr III (rhd@Mars.mcs.com). ・ プログラムが SCO のライブラリ (iBCS についてくる) にリンクされてい る場合、gcc や、gcc でコンパイルされたアプリケーションは sig11 で終 了するかもしれません。 LDFLAGS に -L/lib を指定したアプリケーション の中には、この現象が起きるものがあります.... ・ ELF 形式のバイナリを生成するコンパイラでカーネルをコンパイルしてい るのに、a.out に設定しちゃった場合 (逆だったかな) ld を最初に呼ぶと ころで signal 11 に出くわすでしょう。この場合はソフトウェアの問題だ と容易に見きわめられます。なぜなら、ビルドの間「最初に」 ld を呼ぶ ところでいつも起きるからです。 -- REW ・ 間違って設定された PCI BIOS とイーサネットカードとの組み合わせ。も しお使いのイーサネットカードが ISA バスのスロット用なら、BIOS のセ ットアップ画面のどこかを設定する必要があるかもしれません。さもなく ば、ハードウェアは PCI バスにシェアードメモリの領域を探しに行くでし ょう。ISA のカードは PCI バスのリクエストに反応できないので、からっ ぽの「空気」を読んでしまっていることになります。その結果、 segmentation fault したりカーネルがクラッシュしたりすることがありま す。 -- REW ・ 壊れちゃったスワップパーティション。 Tony Nugent (T.Nugent@sct.gu.edu.au) は、かつてこの問題を、スワップパーティショ ンを mkswap し直すことで解決したことがあると報告してくれました。 ( mkswap した後、なにかやる前に sync するのを忘れないで。 -- Louis J. LaBash Jr.(lou@minuet.siue.edu)) ・ NE2000 互換のカード。安物の NE2000 互換カードの中には、システムを混 乱させる可能性のあるものがあります。 -- Danny ter Haar (dth@cistron.nl) 筆者はかつて個人的によく似た問題を抱えていたことがあるかもしれませ ん、というのは、メールサーバーが時々 (1 日に 1 回程度) ひどくクラッ シュした経験があるのです。今思えば、1.2.13 や、1.3.x カーネルの多く にはこのバグがあったみたいです。1.3.48 では見られませんでした。たぶ ん、その間のどこかで修復されたのでしょう.... -- REW ・ 電源? いいや、それが原因だとは思えないな。SCSI と IDE の両方に 2 つ か 3 つのハードディスクがあるいまどきの重装備システムでも、120 ワッ トかそこらを超えることはないでしょう。もし旧式のハードディスクや旧 式の拡張カードをどっさりおもちなら、さらにたくさんの電力が必要にな るでしょうが、電力供給の限界に達するにはまだまだです。もちろん、首 尾よく古いフルサイズのハードディスクをやまほど見つけて、でかいタワ ーケースに組み込む方もいらっしゃいます。実際、それだと電源の過負荷 になることがありえます。 -- Greg Nicholson (greg@job.cba.ua.edu) いかれた電源は、もちろんぎりぎりの電力を送る「可能性」があります。 その場合、この文書に書いてあるすべての障害を引き起こします。 -- Thorsten Kuehnemann (thorsten@actis.de) ・ つじつまの合わない ext2fs。状況によっては ext2 ファイルシステムのカ ーネルコードが、結果的に gcc の signal 11 を引き起こすことがありま す。 -- Morten Welinder (terra@diku.dk) ・ CMOS RAM の電池。BIOS を好みに設定しても、CMOS RAM の電池が切れてい たら、いけしゃあしゃあと「マズい」もとの設定に戻されてしまうでしょ う。 -- Heonmin Lim (coco@me.umn.edu) ・ スワップスペースが、まったくないか少なすぎ。gcc は、「メモリを使い きった」状態ではうまく動きません。 -- Paul Brannan (brannanp@musc.edu) ・ 互換性のないライブラリ。シンボリックリンクが ``libc.so.5'' から ``libc.so.6'' に向けて張ってあった場合、アプリケーションの中には sig11 で沈没するものもあるでしょう。 -- Piete Brooks (piete.brooks@cl.cam.ac.uk). ・ 壊れたマウス。どういうわけか、マウスはいくつかの (マウスに関係した) プログラムを sig11 でクラッシュさせて中断させることがあるようです。 壊れたマウスをすばやく動かした時、X サーバがクラッシュするのを見た ことがあります。 Matthew のところでは、マウスを動かさなかった場合さ え、起きたかもしれないとのことです。 -- REW & Matthew Duggan (stauff@guarana.org). ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.16. エラーをもっと速く検出できる方法があるんだけど? 質問 あるソフトウェアを走らせると、カーネルをコンパイルするだけよりもずっと 速くエラーが検出されることを発見しました。あなたのサイトでこのことにつ いて触れていただけないでしょうか。 答え 多くのひとが、このようなことが書かれたメールを筆者の許に送ってきます。 でも、彼らは「問題のあるハードウェアのうちのあるひとつのケースに遭遇し たにすぎない」ことに気付いていないのです。``unzip -t'' を薦めるひとは偶 然ある壊れた DRAM を使っていたにすぎません。そして、たまたま unzip のほ うが、カーネルコンパイルよりもエラーを検出するのがずっと速かったにすぎ ないのです。 しかしながらその他数多くの問題では、カーネルコンパイルだとエラーが検出 されるでしょうが、他のテスト方法だと検出されないことは確かです。筆者は 、コンピュータの多種多様な部分にストレスをかけるという理由で、カーネル コンパイルは優れたテスト方法だと考えます。他多くのテストは、あるひとつ の箇所だけを酷使するにすぎないのです。その箇所がたまたま壊れていたなん て場合だと、カーネルコンパイルよりもずっと速く問題があらわになるでしょ う。しかし、お使いのコンピュータではその箇所は正常で、別の箇所が壊れて いたのであれば、その「よりすばやく結果が判明する」テストだと「異常なし 」という結果しか出ないかもしれませんが、カーネルコンパイルによるテスト だと、どこかに悪いところがあると判明するでしょう。 それはともかくとして、優秀なテスト手段と考えられているものを載せたほう がよさそうなので以下に挙げますが、これらは「何かいじくってみてからカー ネルをコンパイルする」テストほど総合的なテスト手段ではありません.... ・ カーネルのコンパイル中に unzip を実行する。だいたい RAM と同じくら いのサイズの「zip で圧縮されたファイル」を用いること。 ・ memtest86 を使う。 (訳注――memtest86 のありかは http:// reality.sgi.com/cbrady_denver/memtest86/ ) ・ カーネルのコンパイル中に dd if=/dev/hda of=/dev/null を実行する。 ・ 複数の大きなディレクトリツリーに対して md5sum を実行する。 注――「うちのコンピュータが壊れている」と判明するどのような高速な手段 を発見できたとしても、そんなテストでもう突然落ちなくなったからといって 、お使いのコンピュータが快調であるという保証はどこにもないでしょう。き ちんと動作させるためにどこかをいじくった後には、24 時間のカーネルコンパ イルテストをするよう常におすすめします。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.17. 誰のところで起こったの? 質問 こんなことは信じられないな。誰のところで起こったの? 答え まあ、少なくとも筆者個人のところで起こったことです。でも、こんなわたし の言うことを信じる必要はありません。以下の人達のところでも起こりました: ・ Johnny Stephens (icjps@asuvm.inre.asu.edu) ・ Dejan Ilic (d92dejil@und.ida.liu.se) ・ Rick Tessner (rick@myra.com ・ David Fox (fox@graphics.cs.nyu.edu) ・ Darren White (dwhite@baker.cnw.com) (L2 cache) ・ Patrick J. Volkerding (volkerdi@mhd1.moorhead.msus.edu) ・ Jeff Coy Jr. (jcoy@gray.cscwc.pima.edu) (Temp problems) ・ Michael Blandford (mikey@azalea.lanl.gov) (Temp problems: CPU fan failed) ・ Alex Butcher (Alex.Butcher@bristol.ac.uk) (Memory waitstates) ・ Richard Postgate (postgate@cafe.net) (VLB loading) ・ Bert Meijs (L.Meijs@et.tudelft.nl) (bad SIMMs) ・ J. Van Stonecypher (scypher@cs.fsu.edu) ・ Mark Kettner (kettner@cat.et.tudelft.nl) (bad SIMMs) ・ Naresh Sharma (n.sharma@is.twi.tudelft.nl) (30->72 converter) ・ Rick Lim (ricklim@freenet.vancouver.bc.ca) (Bad cache) ・ Scott Brumbaugh (scottb@borris.beachnet.com) ・ Paul Gortmaker (paul.gortmaker@anu.edu.au) ・ Mike Tayter (tayter@ncats.newaygo.mi.us) (Something with the cache) ・ Benni ??? (benni@informatik.uni-frankfurt.de) (VLB Overloading) ・ Oliver Schoett (os@sdm.de) (Cache jumper) ・ Morten Welinder (terra@diku.dk) ・ Warwick Harvey (warwick@cs.mu.oz.au) (bit error in cache) ・ Hank Barta (hank@pswin.chi.il.us) ・ Jeffrey J. Radice (jjr@zilker.net) (Ram voltage) ・ Samuel Ramac (sramac@vnet.ibm.com) (CPU tops out) ・ Andrew Eskilsson (mpt95aes@pt.hk-r.se) (DRAM speed) ・ W. Paul Mills (wpmills@midusa.net) (CPU fan disconnected from CPU) ・ Joseph Barone (barone@mntr02.psf.ge.com) (Bad cache) ・ Philippe Troin (ptroin@compass-da.com) (delayed RAM timing trouble) ・ Koen D'Hondt (koen@dutlhs1.lr.tudelft.nl) (more kernel error messages) ・ Bill Faust (faust@pobox.com) (cache problem) ・ Tim Middlekoop (mtim@lab.housing.fsu.edu) (CPU temp: fan installed) ・ Andrew R. Cook (andy@anchtk.chm.anl.gov) (bad cache) ・ Allan Wind (wind@imada.ou.dk) (P66 overheating) ・ Michael Tuschik (mt2@irz.inf.tu-dresden.de) (gcc2.7.2p victim) ・ R.C.H. Li (chli@en.polyu.edu.hk) (Overclocking: ok for months...) ・ Florin (florin@monet.telebyte.nl) (Overclocked CPU by vendor) ・ Dale J March (dmarch@pcocd2.intel.com) (CPU overheating on laptop) ・ Markus Schulte (markus@dom.de) (Bad RAM) ・ Mark Davis (mark_d_davis@usa.pipeline.com) (Bad P120?) ・ Josep Lladonosa i Capell (jllado@arrakis.es) (PCI options overoptimization) ・ Emilio Federici (mc9995@mclink.it) (P120 overheating) ・ Conor McCarthy (conormc@cclana.ucd.ie) (Bad SIMM) ・ Matthias Petofalvi (mpetofal@ulb.ac.be) ("Simmverter" problem) ・ Jonathan Christopher Mckinney (jono@tamu.edu) (gcc2.7.2p victim) ・ Greg Nicholson (greg@job.cba.ua.edu) (many old disks) ・ Ismo Peltonen (iap@bigbang.hut.fi) (irq_unmasking) ・ Daniel Pancamo (pancamo@infocom.net) (70ns instead of 60ns RAM) ・ David Halls (david.halls@cl.cam.ac.uk) ・ Mark Zusman (marklz@pointer.israel.net) (Bad motherboard) ・ Elizabeth Ayer (eca23@cam.ac.uk) (Power management features) ・ Thorsten Kuehnemann (thorsten@actis.de) ・ ・ (あなたの話をメールしてくれたら、ここに載るかも... :-) ---- 更新― ―あなたのところで何が起きたのか聞きたいと思います。それによって、 何が最もたくさん起こっているのかが推測できるだろうし、この文書をで きるだけ正確に保つこともできるだろうから。でも、目下筆者のところに は、sig11 問題に遭遇したことのある人々のさまざまなメールアドレスが 500 前後あります。このリストに「手当たり次第に」名前を追加し続ける のが有益だとは思いません。「あなたは」どう思う? ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3. おわりに 3.1. 著者より 新たな話に興味があります。もし問題を抱えていてそれが何であるか確信がも てないなら、R.E.Wolff@BitWizard.nl にメールをいただけると、助けになれる かもしれません。普通なら好奇心がわたしに、その問題が何であるかをあなた がつきとめるまで、質問に答えるように駆りたてるでしょう..... (一方、問題 が明らかに上に挙げてあるものなら、うんざり :-) この文書のオリジナル英文は http://www.BitWizard.nl で管理されています。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.2. 日本語版の謝辞 この文書の翻訳にあたって、JF ML のみなさんにたいへんお世話になりました 。なかでも、山下義之さん、武井伸光さんにはたくさんの有益なアドバイスを いただきました。感謝します。 -- Masanori Kobayasi (zap03216@nifty.ne.jp)