
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=<megs>)。RAM の 2 倍のサイズのファイルを用
    いれば、ディスクが酷使されるでしょう。また、RAM より 4MB から 10MB
    小さいファイルを用いれば、RAM と CPU が酷使されるでしょう。
   
    しかしながらこの方法で、ありうる限りの問題が発見されるかどうかはは
    っきりしません。gcc はたくさんの異なった命令を様々な順序で実行する
    ものなので、単に md5sum が実行する命令の順序が、gcc が実行する命令
    の順序とはきっちり一致しないかもしれないからです。でも、md5sum がエ
    ラーをもたらせば、カーネルコンパイルよりも問題が検出されるのがずっ
    と速いかもしれません。 -- Rob Ludwick (rob@no-spam)
   

上に挙げた手段のうち、メモリの借用だけは試せないというひとがほとんどで
しょうが、やれるだけのことをやっても変化が見られないとなると、きわめて
やっかいです。この場合は、本当に RAM そのものが原因だと言えそうなのです
。目下、RAM は PC の最も高価なパーツなので、こんな結論であって欲しくは
ないでしょう。でも残念ながら、結局 RAM のせいだと判明したとの返事をたく
さんもらってます。でもまだまだあきらめないで――RAM は全くのゴミではな
いかもしれない――いつでも下取りに出して別の、もしくはより多くの RAM を
買うことができます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2.12. RAM テスターって信頼できる?

質問

RAM テスターの機械でうちの RAM をテストしたことがある。結果は OK だった
。RAM に問題なんてありえない、よね?

答え

ありえます。RAM の中で今まさに起こっているエラーは、RAM テスターでは検
出できないように思われます。「あなたの」コンピュータでは、マザーボード
があやしいやりかたで RAM をアクセスしているか、さもなくば RAM を混乱さ
せているかもしれないからです。この場合の利点は、いまだに RAM テスターを
信頼してる誰かさんに RAM を売りつけてやれることです......
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2.13. Red Hat のインストールがうまくいかないのはなぜ?

質問

うちで Red Hat のインストールが玉砕するのはなぜ?

答え

マシンによっては、Red Hat 5.x や 6.x のインストールには問題がいくつかあ
ります。

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.14. ほかにはどんな可能性があるだろう?

質問

ほかにはどんな可能性があるだろう?

答え

ほかには、以下に挙げた可能性が記録されています:

 ・ 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.15. エラーをもっと速く検出できる方法があるんだけど?

質問

あるソフトウェアを走らせると、カーネルをコンパイルするだけよりもずっと
速くエラーが検出されることを発見しました。あなたのサイトでこのことにつ
いて触れていただけないでしょうか。

答え

多くのひとが、このようなことが書かれたメールを筆者の許に送ってきます。
でも、彼らは「問題のあるハードウェアのうちのあるひとつのケースに遭遇し
たにすぎない」ことに気付いていないのです。``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.16. 誰のところで起こったの?

質問

こんなことは信じられないな。誰のところで起こったの?

答え

まあ、少なくとも筆者個人のところで起こったことです。でも、こんなわたし
の言うことを信じる必要はありません。以下の人達のところでも起こりました:

 ・ 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)
