The SIG11 problem

Rogier Wolff, R.E.Wolff@BitWizard.nl

小林 雅典, zap03216@nifty.ne.jp

この 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.html で入手できます。

原文のスペルミスを見つけた、耳寄りな追加情報がある、 あるいは「わたしも同じ目にあった」なんて話があれば、R.E.Wolff@BitWizard.nl にメールをください。 (注――技術的にナンセンスと考えられるものは却下します) サブジェクトに ``sig11'' か、 そのような言葉を書き添えてもらえるとありがたいです。

The Sig11 FAQ

質問

(カーネルを) コンパイルしていると、

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

答え

おそらく、コンパイラにせよカーネルにせよ、 お使いのソフトウェア環境には何も悪いところはありません。 ハードウェアとの関係が大いにありそうです。 まずそうな部分はいろいろあり、直しかたも様々です。 ちょっと読み進めると、詳細が分るでしょう。 この「法則」には、2 つの例外があります。 仮想記憶が不足している場合と、Red Hat 5.x または 6.x のインストールの最中です。 この文章の最後のほうに詳しく書いてあります。

質問

オッケー。ソフトウェアが原因じゃないって、どうやって確かめたらいいの?

答え

最初に、トラブルの原因がハードウェアであることを確認してみよう。 ``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'' の実行後は別のところに移動するのなら、 ディスクからメモリへの転送に問題を抱えているのは確実だ。

質問

本当のところ、signal 11 ってどういう意味なの? ハードウェアの問題だってことは確かなの?

答え

いいかい、コンパイラが、 コンパイラの管理するメモリ区域の外側にアクセスしたんだ。 もし動作中のハードウェアでこいつが起こるなら、 コンパイラの内部にプログラミングの間違いがあるってこと。 それで ``internal compiler error'' っていうわけ。 でも、gcc はとてもたくさんのポインタを使うものだから、 ハードウェアがときたまビットを反転させてしまう場合、 しまいにはアドレッシングレンジの外側のどこかにアクセスしちゃいそうになる。 (めちゃくちゃなアドレスはたいていアドレッシングレンジの外側になっちゃう。 なぜって、 メインメモリに 4G ものお宝をもってるひとはめったにいないから... :-)

近頃 ``signal 11'' 問題に遭遇したひとはみんなこのページに直行するみたいだ。 でも、もしあなたが自作のソフトウェアを開発している、 もしくはまだ十分にデバッグされてないソフトウェアをもっているのなら、 ``signal 11'' (または、segmentation fault) は依然としてプログラムの不具合を知らせるとても強力なヒントになる。``gcc'' のようなほとんど誰のところでも動作してるプログラムで、 これまたよくテストされたデータセット (例えば、Linux カーネル) のクラッシュを引き起こした場合だけが、 ハードウェアに不具合があるヒントとなるんだ。

もし、システムの中で、 ハードウェアのドライバに類するソフトウェアがイカれていたら、 ハードウェアの故障に酷似した症状が起こることもありうる。 でも、ドライバがダメな場合は、 単にコンパイラのクラッシュを引き起こすことよりも、 カーネル内部の深刻なトラブルを引き起こすことのほうがありがちだ。

質問

オッケー。ハードウェアの何が問題なんだろう?

答え

もしハードウェアがそいつを引き起こすなら、原因は:

• メインメモリ。 メインメモリがときたまビットを間違うのかもしれない。 もし「書き込み」の際に起こるなら、 パリティーエラーが現われることはないだろう。 いろんな解決策がある:
  • メモリの速度が遅すぎるのかも。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)
• キャッシュメモリ。 キャッシュメモリがときたまビットを間違うのかも。 キャッシュには普通パリティーがついていない。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)
• ディスク転送。ディスクから送られてくるブロックが、 ときたまビットエラーにやられてるのかも。
  • もしこの問題があるなら、十中八九、 問題をある地点から次の地点へと「移動させる」ために ``dd'' コマンドを実行しなくてはならないようです....
  • IDE ハードディスクの中には ``irq_unmasking'' オプションを扱えないものがあります。 この問題は負荷がかかっている時だけ出現するかもしれません。 sig11 として顔を見せることがありえます。
  • kalok 31xx をもってる? ならゴミ箱にステステ。 (それか、DOS 野郎に売りつけてやろう。 更新――もう何年も kalok の噂を聞いたことがない。 たぶんつぶれちゃったのでしょう。 ついでに言うと、ドライバは Windows 95 でも動きません。)
  • SCSI? ターミネーター? 短かいケーブルならイカれたターミネーターでも (信頼できないけど) そのまま動くかも。 長いケーブルならやっぱりエラーが出るかも。 ホストとディスクのパリティーを有効にできる?
• 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 がらみのレポートの波は (Feb '97) に過ぎ去りました。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)

質問

RAM のタイミングの問題だって? 1 ヶ月以上前に BIOS の設定をいじくった。 その間やまほどカーネルをコンパイルしたけど何もマズくなかった。RAM のタイミングに問題なんてありえない、よね?

答え

ありえるよ。RAM 工場には 60ns の RAM を作る機械と 70ns の RAM を作る機械が別々にあると思ってるの? そいつは違うね! いっしょくたに作って、それからテストするんだ。60ns の規格に適合するものもあれば、そうでないものもある。 もし作り手がそいつにふさわしい数字を振らなくてはならないとしたら、61ns が振られるものもあるかもしれない。 この場合、例えば 40 度以下の気温の時に、 君の愛機で動作するのはいかにもありそうなことだ。 (気温が上がると、チップの動作はのろくなる。 それがスーパーコンピュータをべらぼうに冷さなくてはならない訳)

でも、「夏の到来」や長時間のコンパイル作業で、 コンピュータ内部の温度が「限界」を越えるまで上がることはありえるね。 -- Philippe Troin (ptroin@compass-da.com)

質問

ちょっと安かったから、値段につられて ECC メモリじゃないやつを買っちゃった。 馬鹿みたい。高くても ECC にしとけばよかった。そうだよね?

答え

より高価な ECC メモリやマザーボードを買うと、 ある特定のタイプのエラーを防ぐことができます―― それはアルファ線の通過によってランダムに起こるエラーです。

たいていのひとは ``gcc'' を使ってみると、 半時間以内に ``signal 11'' 問題を再現できますが、 いざメモリをテストしてみると、何時間続けても再現できません。 よって ``signal 11'' は、 単にアルファ線がいきあたりばったりにビットを反転させて起こるのではないことは明らかです。 アルファ線が原因なら、メモリテストでも再現できるでしょうから。 これは何か別のことが起きているのを意味しています。

ほとんどの sig11 問題は、CPU <-> cache <-> memory の経路でのタイミングエラーによって引き起こされる印象があります。 この場合、メインメモリの ECC は役に立ちません。 いつ ECC を買うべきか? a) 物欲がうずいた時。b) たくさん RAM をもってる時。(なぜ最小限の数値を挙げないのかって? 最小限は、時流によってまさに「たくさん」変化するものだから。) 誰もが ECC メモリを使ってると猛烈に思いこんでるひともいます。 そういうひとは ``a)'' の理由からです。

質問

メモリの問題だって? BIOS のメモリテストは OK だ。 素敵な DOS のプログラムもメモリは OK だって言ってる。 メモリに問題なんてありえない、よね?

答え

ありえるよ。BIOS のメモリテストは全くの役立たずだ。 良いか悪いかテストするどころか、 実際に得られる以上のメモリがときたま OK になることさえあるくらいだ。

640k PC をもってる友人がいた (そう、640k PC でお分りの通り、昔々のお話)、 そいつの 2 つ目のバンクには、256kbit チップの代りに 64kbit チップが 1 つささっていた。 実際には 320k のワーキングメモリがあったことになる。 時々、BIOS の 384k のテストが ``OK'' になることがあった。 にもかかわらず、特定のアプリケーションだけは落ちる。 実際の問題を診断するのは、ひどく骨が折れた....

たいていのメモリの問題は、特殊な状況の下でしか起こりません。 そのような状況がどういうものであるのかは、 まだほとんど分らないのです。gcc はどうもそういった特殊な状況を作り出す「みたい」です。 メモリテスト、特に BIOS のメモリテストはそうではありません。 筆者はもう、Linux カーネルと優秀なメモリテスターを収録したフロッピーの作成サービスはやっていません。 その話は勘弁してください......

その理由として、メモリテストだと、CPU はほんのわずかな命令しか実行しないことと、 メモリアクセスのパターンが非常に規則的になりがちなことが挙げられます。 このような状況の下だと、 メモリのうちのほんのわずかな部分しか酷使されません。 もしあなたが電子技術を学んでいて、 メモリテストに興味がおありなら、 何が起きているのかを理解すれば修士論文が書けます。 顧客には信頼性がないと主張されているのに、 製造段階のテストでは落ちてくれないハードウェアに悩まされてる計算機メーカーが、 喜んでそのようなプロジェクトのスポンサーになってくれるでしょう......

質問

カーネルをコンパイルする時だけ起こるのですか?

答え

いいえ。ハードウェアには、 カーネルをコンパイルしてる最中なのかを知る術がありません。 カーネルのコンパイルは、 あいにくハードウェアにとってはとても骨が折れる仕事なのです。 それで、 カーネルをコンパイルしている時にだけたくさん起こるのです。gcc や glibc のような大きなパッケージのコンパイルも、sig11 の引き金になることが多いです。

• 例えば、slackware のインストールスクリプトを使ってインストールしている最中に、 「ランダム」にクラッシュするのを見たことがあるって話がある.... -- dhn@pluto.njcc.com
• カーネルから、(クラッシュダンプといっしょに) ``general protection errors'' を受け取ったひともいる。 普通は /var/adm/messages に記録されているはず。 -- fox@graphics.cs.nyu.edu

質問

NT, Windows 95, OS/2, DOS だと、何もクラッシュしません。 Linux 特有の何かに違いありません。

答え

まず第一に、Linux は上記のどの OS よりもハードウェアを酷使します。 上に挙げたマイクロソフト製のような OS の中には、 とにかくいつクラッシュするかまったく予測がつかないものがあります。 マイクロソフトに電話して、 「おい、今日ウインドウズが落ちたぞ」 なんて言うひとはひとりもいないでしょう。 とにかくもしあなたがそういう行動に出たとしても、 相手は、ユーザーであるあなたがエラーを起こしたんだ (ドイツの雑誌に掲載された the interview with Bill Gates を見てね....) 今はちゃんと動作しているのだから、口をつぐむべきだ、 などとほざくでしょう。

これらの OS には、Linux より「予測可能な」ところもあります。 エクセルは、いつもきっちり同じメモリ領域にロードされるはず、 という意味です。 したがってこの場合、 ビットエラーが起こった時に影響を受けるのは常にエクセルになります。 エクセルはクラッシュするでしょう。もしくは、 エクセルがほかのアプリケーションをクラッシュさせるでしょう。 とにかく、落ちるのは単なるアプリケーションで、 メモリとは関係ないように思われるでしょう。

きっちりインストールされた Linux システムなら、 エラーを起こさずにカーネルをコンパイルできるはずだと確信してます。 間違いなく、sig11 は起こりません。 (** 例外――Cyrix プロセッサでの Red Hat 5.0。別のところを見てね。 **)

実際のところ、Linux と gcc はほかの OS 以上にハードウェアを酷使します。 もし Linux 以外で、 クラッシュするところまでハードウェアを酷使するものが必要なら、winstone を試してみるのが吉。 -- Jonathan Bright (bright@informix.com)

質問

いつも 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)

質問

何をすればいいの?

答え

何が悪いのかをつきとめたい場合は、以下のことを試してみましょう... 注――これらの中には、 コンピュータを著しく遅くするおそれのあるものもあります。 これらの狙いは、コンピュータをきちんと動作させ、 どこが悪いのかを絞りこんでいくことです。 情報を得られれば、 例えばベンダーに故障箇所を交換してもらうことができます。

• マザーボードのジャンパを、 より低い 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 をテストしたことがある。 結果は OK だった。RAM に問題なんてありえない、よね?

答え

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

質問

うちで 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 度と続けてクラッシュした際に、 このトリックを用いることでインストールを完了できたという方は、 ぜひご一報ください!!!

この問題から逃れるには何をしたらいいのかって?...

• SuSE を使う。こいつはベターだ―― インストールの間クラッシュしない。 (おまけに、ディストリビューションとしてのできもベター。;-)
• ハードディスクの「設定」を変更する。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).

質問

ほかの可能性はなんだろう?

答え

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

• 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) イーサネットカードが 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 バッテリー。BIOS を好みに設定しても、CMOS バッテリーがイカれていたら、 いけしゃあしゃあと「マズい」もとの設定に戻されちゃうでしょう。 -- 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).

質問

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

答え

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

• 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 前後あります。 このリストに「手当たり次第に」名前を追加し続けるのが有益だとは思いません。 「あなたは」どう思う?

この文書の翻訳にあたって、JF ML のみなさんにたいへんお世話になりました。なかでも、 山下 義之さん、武井 伸光さんにはたくさんの有益なアドバイスをいただきました。 感謝します。 -- Masanori Kobayasi (zap03216@nifty.ne.jp)