The SIG11 problem Rogier Wolff, R.E.Wolff@BitWizard.nl 9 August 2000 小林 雅典, zap03216@nifty.ne.jp 25 August 2000 カーネルをコンパイルする際の signal 11 この FAQ は、近頃多くの人々を悩ませる現象はいったいどういった原因で起 こることがありうるのかを述べたものです。すなわち、Linux(*) カーネル (または、その種の大きなパッケージ) のコンパイルが ``signal 11'' でク ラッシュするというものです。原因はソフトウェアのこともありますが、ほと んどの場合はハードウェアにあります。読み進めると、詳細が分るでしょう。 (*)もちろん、Linux 固有の現象ではありません。もしハードウェアがイカれ ているのなら、Linux, Windows 3.1, FreeBSD, Windows NT, NextStep はすべ てクラッシュするでしょう。 英文の最新版は で入手できます。 フランス語で読みたい方のために、フランス語訳が で入手できます。 日本語訳 (この文書) の最新版は、 で入手できます。 原文のスペルミスを見つけた、耳寄りな追加情報がある、あるいは「わたしも 同じ目にあった」なんて話があれば、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 カーネル) のクラッシュを引き起こした場合だけが、ハードウェアに不具合が あるヒントとなるんだ。 もし、システムの中で、ハードウェアのドライバに類するソフトウェアがイカ れていたら、ハードウェアの故障に酷似した症状が起こることもありうる。で も、ドライバがダメな場合は、単にコンパイラのクラッシュを引き起こすこと よりも、カーネル内部の深刻なトラブルを引き起こすことのほうがありがち だ。 ______________________________________________________________________ ______________________________________________________________________ 質問 オッケー。ハードウェアの何が問題なんだろう? 答え もしハードウェアがそいつを引き起こすなら、原因は: o メインメモリ。メインメモリがときたまビットを間違うのかもしれない。 もし「書き込み」の際に起こるなら、パリティーエラーが現われることは ないだろう。いろんな解決策がある: o メモリの速度が遅すぎるのかも。BIOS の wait states の数値を上げる。 AMIBIOS の autoconfig option で起きることがある――今だと 100MHz の 486 が買えるけど、autoconfig option は 80MHz までの 486 しかちゃん と認識しないかも。 -- Pat V o メモリの速度が遅すぎるのかも。もっと速い DRAM SIMM を入手する。例え ば、現行の ASUS のマザーボードは 100 または 133MHz のプロセッサなら 60ns DRAM を要求します (マザーボードのマニュアルを見てね)。70ns で も動きますが、ランダムな sig11 が起こりうるような信頼性の問題がある と報告されています.... (リスクは負いたくありません) -- Andrew Eskilsson (mpt95aes@pt.hk-r.se) o 100MHz SDRAM は 100MHz で動作可能に思えるかもしれないけど、それは間 違いだ! を読んでみて。 このことが事実だと思う理由が書いてあるから。少なくとも、妥当と思わ れるスピードよりも一段階速いグレードのものが必要だ。 o SIMM のうちの 1 つにまずいチップがあります。もしバンク 1 つ以上のメ モリがあるなら、SIMM を引き抜いて、問題が解決するかどうか見てみま しょう。静電気に注意して!!! o 先週強烈なメモリのマシンを取り扱った。16MB SIMM が 4 つとも壊れてい て、どれも 1 時間に 1 回ぐらいビットを落とすことが判明した。こいつ はだいたい 1 日でマシンをクラッシュさせたり、1 時間くらいでカーネル のコンパイルをクラッシュさせたりするのに十分だった。で、まとめて新 しい SIMM に交換したら完璧に動くようになった。こいつを診断するには 長い時間がかかった、なぜなら SIMM が 4 つとも同じようにイカれていた からだ。そんな訳でメモリを半分交換しただけでは何の変化もなかった。 Mark Kettner (kettner@cat.et.tudelft.nl) からの報告です。彼のシステ ムは、筆者謹製のメモリテストを失敗せずに 2300 回走らせることができ たが、それから 10 前後のエラーが検出された。その後はまた二、三百回 失敗が検出されずに動き続けた..... 彼のケースでは、カーネルコンパイ ルは、システムの健康を診断するよりいっそうすぐれた手段だった (最も 安定した設定で、クラッシュする前に 14 前後のカーネルをコンパイルで きた)。彼は、古いメモリを自称「メモリアップグレード」するために「返 品交換」して解決することにした。店員がメモリテスターでテストした結 果、メモリは「異常なし」とのこと。そんな訳で、彼は新品のメモリを割 引きしてもらった :-)。 o 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 個のパスコンを備えるべきだと 補足してくれた。 o もし DRAM のリフレッシュがきちんと機能していないなら、DRAM は保持し ている情報をゆっくりと失なっていくだろう。``hidden refresh'' を有効 にした場合、(486) マザーボードの中には正確にリフレッシュするのをや めるものもある。リフレッシュをめちゃくちゃにして sig11 問題を引き起 こしうる ``DRAM'' まわりのプログラムもあるようだ。 -- Hank Barta (hank@pswin.chi.il.us), Ron Tapia (tapia@nmia.com) o wait states の数値が低すぎるのかもしれない。BIOS の wait states の 数値を上げると直る。インテルの Endeavour board は、メモリの wait states を上げることができない。これは MR BIOS をマザーボードに書き 込めば可能になると思われる。 -- David Halls (david.halls@cl.cam.ac.uk) o キャッシュメモリ。キャッシュメモリがときたまビットを間違うのかも。 キャッシュには普通パリティーがついていない。BIOS のキャッシュの項目 をオフにすることで、このケースに当てはまるかどうかが診断できる。も し直ったら、おそらくキャッシュが原因だ。いろんな解決策がある: o キャッシュメモリの速度が遅すぎるのかも。BIOS の wait states の数値 を上げる。 o キャッシュメモリの速度が遅すぎるのかも。もっと速い SRAM のチップに 交換する。 o キャッシュにイカれたチップがある。SIMM みたいに簡単にチップの交換は できそうもない。静電気に注意して!!! -- Joseph Barone (barone@mntr02.psf.ge.com) o チップセットのライトバックの実装にバグがある一方で、キャッシュのラ イトバックが有効になっているのかもしれない。こいつが起こるマザーボ ードは ``MV020 486VL3H'' (with 20M RAM) だった。-- Scott Brumbaugh (scottb@borris.beachnet.com) (メールアドレスに届かない。スコット、 きちんと送り返せるアドレスで返事をくれ) o マザーボードが、スロットタイプのキャッシュと、時代遅れの DIP チップ のキャッシュを切り替えるジャンパを要求しているのかも。 (Rev 2.4 ASUS P/I-P55TP4XE マザーボード の JP16) o ディスク転送。ディスクから送られてくるブロックが、ときたまビットエ ラーにやられてるのかも。 o もしこの問題があるなら、十中八九、問題をある地点から次の地点へと 「移動させる」ために ``dd'' コマンドを実行しなくてはならないようで す.... o IDE ハードディスクの中には ``irq_unmasking'' オプションを扱えないも のがあります。この問題は負荷がかかっている時だけ出現するかもしれま せん。 sig11 として顔を見せることがありえます。 o kalok 31xx をもってる? ならゴミ箱にステステ。 (それか、DOS 野郎に売 りつけてやろう。更新――もう何年も kalok の噂を聞いたことがない。た ぶんつぶれちゃったのでしょう。ついでに言うと、ドライバは Windows 95 でも動きません。) o SCSI? ターミネーター? 短かいケーブルならイカれたターミネーターでも (信頼できないけど) そのまま動くかも。長いケーブルならやっぱりエラー が出るかも。ホストとディスクのパリティーを有効にできる? o CPU そのもの。プロセッサのロットの中には、「故障」する確率が非常に 高いものがあります。数年前だとオリジナルのインテルペンティアム 120。 2, 3 年前だと AMD K6/2-300 (1998 年の 34 週目から 39 週目に製 造されたもの!)。最近だと AMD K6/2-450 です。まあ、400MHz ならいける と判断するひともいるかもしれません。でも、この問題であることが判明 したら、新品のプロセッサを得る権利があります。買ったお店に行って、 交換してもらいましょう。 (P120 のことは忘れましょう。わざわざ交換し に行く価値すらありません... ;-) -- Guillaume Cottenceau (gcottenc@ens.insa-rennes.fr). o CPU そのもの。K6 プロセッサのロットの中には、単なる設計上のバグがあ るものがあります。 を 読んで、お手もちの K6 が返品交換できるか確認してみましょう。 -- Rongen (rongen@istar.ca). o オーバークロック。Cyrix P166 プロセッサは 166MHz ではなくて 133MHz で動作します。これは、Cyrix の連中にとってはきっと理にかなったこと なのでしょうが、部外者には想像がつきません。もし 166MHz で Cyrix P166 をお使いなら、オーバークロックしていることになります..... o オーバークロック。ベンダー (や個人) の中には、いくつかの CPU でオー バークロックができると考えている方がいます。動く可能性があるものも あれば、動かないのもあります。ターボスイッチ (注――ほとんどのペン ティアム対応マザーボードは、もはやノンターボモードをサポートしてい ません) をオフにしてみると、問題が解決するかどうかが分ります。CPU の速度 (表面に印刷されています。必要なら慎重にファンを取り外して) を、マザーボードのジャンパや BIOS の設定と比較して、チェック.... インテルでさえ、CPU のクロック刻印が間違ってることがあるようです。 目下、正規のペンティアムが妥当なクロックで sig11 を起こす、もっと低 いクロックにすると起きなくなる、という複数の信頼できる報告がありま す。クロックの中には、ゆっくりしたプロセッサのクロックよりも、激烈 にマザーボードを痛めつけるだけのものもあるので (120MHz -> マザーボ ードのクロック 60MHz, 100MHz -> マザーボードのクロック 66MHz) マザ ーボードとの関係はなさそうに思います。付け加えると、新品の 120MHz のプロセッサは今ちゃんと動いています。 -- Samuel Ramac (sramac@vnet.ibm.com). これは、インテルやその競合メーカーに特有の ものではありません。 o 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 計り方の情報および、ここに書かれたことを確認するには、 を見て ね。 (特に質問の Q5 と Q6 と Q12。その文書はちょっと時代遅れになっ てきてるけど、今なおとても正確。質問をすこし今風にすればさらによく なるみたい。) o CPU の電圧。マザーボードのなかには、CPU の電圧が選べるものがある し、CPU の電圧を扱うジャンパの設定がへたくそなマニュアルに書かれて いるものもある。 5V のプロセッサはほとんどの場合、3.3V でも依然とし て動くように思われる..... -- Karl Heyes (krheyes@comp.brad.ac.uk) o RAM の電圧。ベンダーは今、3.3V RAM を用意してるみたい。たいていのメ モリは目下 3.3V。 (でも RAM の電圧を設定できるマザーボードをもって るなら注意して―― 3.3V RAM は 5V 流すと壊れちゃう.....) (ほとんど 気にしなくていいよ、自動で切り替わるに違いないと思うから。) o ローカルバスの過負荷。25MHz だと 3 つの VesaLocalBus (VLB) カードが 使えます。33MHz だと 2 つだけ。40MHz だと 1 つだけだし、50MHz だと たぶんゼロ! (つまり、50MHz の ローカルバスのシステムが使えて も、VLB カードは 1 つも使えない)。システムの中には、VL バスに負荷を かけ過ぎた場合におかしくなりはじめるものもあります。過負荷 (上記の 限界以上) でない時さえ、システムは余計な VLB カードの追加によって、 きわどいところの 2, 3 ナノセコンドを失なうことがあるかもしれませ ん。よって、新しい VLB カードの増設後、キャッシュの wait states か なんかを上げる必要がでてくるでしょう.... -- Richard Postgate (postgate@cafe.net) o 電源管理。ラップトップ (いまどきの「グリーン」 PC も) のなかには、 電源管理の機能をもっているものもあります。これらは Linux のじゃまを するかもしれません。ある機能は、メモリイメージを HD にセーブしてお いて、キーを押した時にメモリを元の状態に戻すもののようです。こいつ はよさげですが、Linux のデバイスドライバは、2 回のアクセスの間にハ ードウェアがお休みするのをあてにしていません。復帰するものもあれ ば、しないのもあります。試しに電源管理を無効にするか、カーネルの ``APM support'' を有効にしてみてください。 -- Elizabeth Ayer (eca23@cam.ac.uk) o 積もり積もったホコリ。ホコリの中には、ちょっと電気を通して微弱な ショートを起こすものがあります。どこかでキャパシタンツを増加させ、 タイミングの特性を劣化させるかもしれませんし、熱の発散を妨げてどこ かをオーバーヒートさせるかもしれません。愛機のケースを開けて内部を 掃除するのはいいアイデアなので、年に一度ぐらいやるのをお勧めしま す。豆知識――綿棒は、手の届かないところのホコリを突っつくのに役立 ちます... -- Craig Graham (c_graham@hinge.mistral.co.uk) o CPU そのもの。何人もの人々が、CPU 以外にやばいものが見つからなかっ たと報告してきています。CPU とマザーボードに互換性がなかったことも あるのでしょう。インテル CPU がらみのレポートの波は (Feb '97) に過 ぎ去りました。Cyrix/IBM 6x86 CPU を非難する新たな波がおしよせてきて います。本当に CPU のせいなのかもしれませんが、マザーボードと CPU のあいだに互換性がないせいかもしれません。少なくともマザーボードの マニュアルに、古い 6x86 とは互換性がないと言及してあるのを見たこと があります。筆者自身の経験では、このデバイスは全然悪くないです。カ ーネルコンパイルの際のベンチマークでは、P166+ が P155 と同じくらい (P120 より 1.3 倍速い) でした。 o メモリの穴。多くの現行マザーボードは、リニアフレームバッファに 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 の引き金になることが多いです。 o 例えば、slackware のインストールスクリプトを使ってインストールして いる最中に、「ランダム」にクラッシュするのを見たことがあるって話が ある.... -- dhn@pluto.njcc.com o カーネルから、(クラッシュダンプといっしょに) ``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 を受け取るものだと決めつけ るのはかなりの偏見のように思われます。以下の現象も見られます: o free_one_pmd: bad directory entry 00000008 o EXT2-fs warning (device 08:14): ext_2_free_blocks bit already cleared for block 127916 o Internal error: bad swap device o Trying to free nonexistent swap-page o kfree of non-kmalloced memory ... o scsi0: REQ before WAIT DISCONNECT IID o Unable to handle kernel NULL pointer dereference at virtual address c0000004 o put_page: page already exists 00000046 invalid operand: 0000 o Whee.. inode changed from under us. Tell Linus o crc error -- System halted (During the uncompress of the Linux kernel) o Segmentation fault o "unable to resolve symbol" o make [1]: *** [sub_dirs] Error 139 make: *** [linuxsubdirs] Error 1 o 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) ______________________________________________________________________ ______________________________________________________________________ 質問 何をすればいいの? 答え 何が悪いのかをつきとめたい場合は、以下のことを試してみましょう... 注 ――これらの中には、コンピュータを著しく遅くするおそれのあるものもあり ます。これらの狙いは、コンピュータをきちんと動作させ、どこが悪いのかを 絞りこんでいくことです。情報を得られれば、例えばベンダーに故障箇所を交 換してもらうことができます。 o マザーボードのジャンパを、より低い CPU やバスの速度に切り変える。 o BIOS の画面で、``Load BIOS defaults'' を選択する。かならず、前もっ てディスクドライブの設定を控えておいてください。 o (BIOS で) キャッシュを無効にする (スロットタイプなら、引き抜く)。 o ``linux mem=4M'' のオプションで、カーネルを起動する (4MB 以上を無効 にする)。 o メモリの半分を取り外してみる。かわりばんこに試す。 o リフレッシュの設定をいじくる (BIOS)。 o ほかの誰かからメモリを借りてみる。なるべく、ほかのマシンで Linux が 完璧に動くメモリにすべきです... (シリコングラフィックスの Indy も メモリを借用する恰好のターゲットです) o もし、本当に解決したかどうか確かめたいなら、次のことを試してみよう: 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 ヶ月 :-) o 現在のハードウェア環境が安定しているかどうかをテストするもう 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 を買うことができます。 ___________________________________________________________________ ___________________________________________________________________ 質問 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) によるパッチが で入手できます。 実際、このケースにあてはまるのなら、2 つ目の仮想コンソールに切り替えて (ctrl-alt-F2 を押す)、そこで 2, 3 秒ごとに ``sync'' と打つのを試してみ てください。これをやると、ハードディスクバッファとして割り当てられたメ モリの量が切り詰められます... Red Hat のインストールが 2 度 3 度と続 けてクラッシュした際に、このトリックを用いることでインストールを完了で きたという方は、ぜひご一報ください!!! この問題から逃れるには何をしたらいいのかって?... o SuSE を使う。こいつはベターだ――インストールの間クラッシュしない。 (おまけに、ディストリビューションとしてのできもベター。;-) o ハードディスクの「設定」を変更する。BIOS での設定を ``LBA'' から ``NORMAL'' に変えたことによって、少なくともひとりの方が救われていま す。もしこれを試したなら、R.E.Wolff@BitWizard.nl にメールをいただけ ると本当にありがたいです――このやりかたが有効なのかどうか、あなた から聞きたいのです。 (正確に、何をやったらきちんと動くようになった のか、も) o まず最低限の基本システムをインストールして、それからそこにパッケー ジを追加インストールするやりかたで、「筆者の」マシンにはインストー ルできました。 o この現象が起きる時、マシンがメモリを使いきっているのかもしれない、 と言ってくれた方がいました。スワップパーティションの設定がすでにな された状態で試してみましょう。また、たぶん少ないメモリの環境でもイ ンストールできるような機能が「用意」されているのにもかかわらず、イ ンストーラーが状況の判断を誤っているのかもしれません。例えば、ちょ うど 1M しか空きの RAM が残ってない状態で、さらに 2M のアプリケー ションを RAMDISK にロードしようとしたのかもしれません。よって、もし RAM が 16M なら、mem=14M のオプションでブートすると、実際に効果があ るかもしれません、というのは、それから「RAMDISK にロードする」段階 で失敗して、それ以降は RAMDISK の代りに CD からインストールするよう になるであろうからです。 (昔はメモリが 8M のマシンにもインストール できたけど、今でもいけるかな?) o 一度、 Linux で使う予定があるすべてのパーティションをディスクから消 去して、リブートして、それからインストールしてみる、というのを試し てみましょう。手動でパーティションを切るか、インストールプログラム に計算させるか、どちらかの手段で。 (Red Hat にもこういった選択肢は あると思います。SuSE にはありますから...) もしこれで動作するように なったら、報告してもらえるとありがたいです。 o ダウンロードの過程で壊れちゃった場合でも起きる。はあ。 o もはや 8MB のマシンにはインストールできない、しかも sig7 でぶざまに 終了する、との報告がありました。 -- Chris Rocco (crocco@earthlink.net) o ``BIOS shadow'' (system と VIDEO の両方) を無効にすることが助けに なったと、ひとりの方が報告してくれました。Linux は BIOS を使わない ので、shadow を有効にしても役に立ちません。コンピュータの中に は、shadow を無効にすると、おまけに 384k も RAM が増えるかもしれな いものもあります。無効にして、何が起こるか見てみましょう。 -- Philippe d'Offay (pdoffay@pmdsoft.com). ___________________________________________________________________ ___________________________________________________________________ 質問 ほかの可能性はなんだろう? 答え ほかには、以下に挙げた可能性が記録されています: o Red Hat 5.0 に含まれているコンパイラと libc は、Cyrix のプロセッサ とは妙に相性が悪いです。コンパイラがクラッシュするし、こいつは「非 常に」奇妙です。仮にこれが事実だとしたら、Cyrix には現時点で未検出 のバグがあり、「その」 gcc が Linux カーネルをコンパイルする時に きっちり引き金を引く、としか考えられません。とにかくカーネルをコン パイルしたいだけなら、Red Hat のウェブサイトから、新しいコンパイラ と libc のいずれか、もしくは両方をゲットすべきです。 (トップページ で errata をクリック) o 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) o ペンティアムに最適化された 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'' のオプ ションで手動コンパイルする。) o ディスクとシステムの間の接続が不良。例えば、IDE ケーブルは 40cm (16 インチ) の長さまでしか許されていないのに、もっと長いケーブルを付け て出荷されるシステムが多いです。取り外し可能な IDE ラックも、システ ムをクラッシュさせるのに十分なトラブルの要因になるかもしれません。 o めちゃくちゃに設定された gcc -- あるバージョンの部分があり、別のバ ージョンの部分もあるもの。2, 3 週間後、すべてまともになるようにスク ラッチからインストールし直して、けりをつけた。 -- Richard H. Derr III (rhd@Mars.mcs.com). o プログラムが SCO のライブラリ (iBCS についてくる) にリンクされてい る場合、gcc や、gcc でコンパイルされたアプリケーションは sig11 で終 了するかもしれません。LDFLAGS に -L/lib を指定したアプリケーション の中には、この現象が起こるものがあります.... o ELF 形式のバイナリを生成するコンパイラでカーネルをコンパイルしてい るのに、a.out に設定しちゃった場合 (逆だったかな) ``ld'' を最初に呼 ぶところで signal 11 に出くわすでしょう。この場合はソフトウェアの問 題だと容易に見きわめられます。なぜなら、ビルドの間「最初に」 ``ld'' を呼ぶところでいつも起きるからです。 -- REW o 間違って設定された PCI BIOS とイーサネットカードとの組み合わせ。も しお使いの (ISA) イーサネットカードが ISA バスのスロット用な ら、BIOS のセットアップ画面のどこかを設定する必要があるかもしれませ ん。さもなくば、ハードウェアは PCI バスにシェアードメモリの領域を探 しに行くでしょう。ISA のカードは PCI バスのリクエストに反応できない ので、からっぽの「空気」を読んでしまっていることになります。その結 果、segmentation fault したりカーネルがクラッシュしたりすることがあ ります。 -- REW o 壊れちゃったスワップパーティション。 Tony Nugent (T.Nugent@sct.gu.edu.au) は、かつてこの問題を、スワップパーティショ ンを mkswap し直すことで解決したことがあると報告してくれました。 (mkswap した後、なにかやる前に ``sync'' するのを忘れないで。 -- Louis J. LaBash Jr.(lou@minuet.siue.edu)) o NE2000 互換のカード。安物の NE2000 互換カードの中には、システムを混 乱させる可能性のあるものがあります。 -- Danny ter Haar (dth@cistron.nl) 筆者はかつて個人的によく似た問題を抱えていたことが あるかもしれません、というのは、メールサーバーが時々 (1 日に 1 回程 度) ひどくクラッシュした経験があるのです。今思えば、1.2.13 や、1.3.x カーネルの多くにはこのバグがあったみたいです。1.3.48 では 見られませんでした。たぶん、その間のどこかで修復されたのでしょ う.... -- REW o 電源? いいや、それが原因だとは思えないな。SCSI と IDE の両方に 2 つ か 3 つのハードディスクがあるいまどきの重装備システムでも、120 ワッ トかそこらを超えることはないでしょう。もし旧式のハードディスクや旧 式の拡張カードをどっさりおもちなら、さらにたくさんの電力が必要にな るでしょうが、電力供給の限界に達するにはまだまだです。もちろん、首 尾よく古いフルサイズのハードディスクをやまほど見つけて、でかいタワ ーケースに組み込む方もいらっしゃいます。実際、それだと電源の過負荷 になることがありえます。 -- Greg Nicholson (greg@job.cba.ua.edu) イ カれた電源は、もちろんぎりぎりの電力を送る可能性があります。その場 合、この文書に書いてあるすべての障害を引き起こします。 -- Thorsten Kuehnemann (thorsten@actis.de) o つじつまの合わない ext2fs。状況によっては ext2 ファイルシステムのカ ーネルコードが、結果的に gcc の signal 11 を引き起こすことがありま す。 -- Morten Welinder (terra@diku.dk) o CMOS バッテリー。BIOS を好みに設定しても、CMOS バッテリーがイカれて いたら、いけしゃあしゃあと「マズい」もとの設定に戻されちゃうでしょ う。 -- Heonmin Lim (coco@me.umn.edu) o スワップスペースが、まったくないか少なすぎ。gcc は、「メモリを使い きった」状態ではうまく動きません。 -- Paul Brannan (brannanp@musc.edu) o 互換性のないライブラリ。シンボリックリンクが ``libc.so.5'' から ``libc.so.6'' に向けて張ってあった場合、アプリケーションの中には sig11 で沈没するものもあるでしょう。 -- Piete Brooks (piete.brooks@cl.cam.ac.uk). o 壊れたマウス。どういうわけか、マウスはいくつかの (マウスに関係した) プログラムを sig11 でクラッシュさせて中断させることがあるようです。 壊れたマウスをすばやく動かした時、X サーバがクラッシュするのを見た ことがあります。 Matthew のところでは、マウスを動かさなかった場合さ え、起きたかもしれないとのことです。 -- REW & Matthew Duggan (stauff@guarana.org). ___________________________________________________________________ ___________________________________________________________________ 質問 こんなことは信じられないな。誰のところで起こったの? 答え まあ、少なくとも筆者個人のところで起こったことです。でも、こんなわたし の言うことを信じる必要はありません。以下の人達のところでも起こりまし た: o Johnny Stephens (icjps@asuvm.inre.asu.edu) o Dejan Ilic (d92dejil@und.ida.liu.se) o Rick Tessner (rick@myra.com) o David Fox (fox@graphics.cs.nyu.edu) o Darren White (dwhite@baker.cnw.com) (L2 cache) o Patrick J. Volkerding (volkerdi@mhd1.moorhead.msus.edu) o Jeff Coy Jr. (jcoy@gray.cscwc.pima.edu) (Temp problems) o Michael Blandford (mikey@azalea.lanl.gov) (Temp problems: CPU fan failed) o Alex Butcher (Alex.Butcher@bristol.ac.uk) (Memory waitstates) o Richard Postgate (postgate@cafe.net) (VLB loading) o Bert Meijs (L.Meijs@et.tudelft.nl) (bad SIMMs) o J. Van Stonecypher (scypher@cs.fsu.edu) o Mark Kettner (kettner@cat.et.tudelft.nl) (bad SIMMs) o Naresh Sharma (n.sharma@is.twi.tudelft.nl) (30->72 converter) o Rick Lim (ricklim@freenet.vancouver.bc.ca) (Bad cache) o Scott Brumbaugh (scottb@borris.beachnet.com) o Paul Gortmaker (paul.gortmaker@anu.edu.au) o Mike Tayter (tayter@ncats.newaygo.mi.us) (Something with the cache) o Benni ??? (benni@informatik.uni-frankfurt.de) (VLB Overloading) o Oliver Schoett (os@sdm.de) (Cache jumper) o Morten Welinder (terra@diku.dk) o Warwick Harvey (warwick@cs.mu.oz.au) (bit error in cache) o Hank Barta (hank@pswin.chi.il.us) o Jeffrey J. Radice (jjr@zilker.net) (Ram voltage) o Samuel Ramac (sramac@vnet.ibm.com) (CPU tops out) o Andrew Eskilsson (mpt95aes@pt.hk-r.se) (DRAM speed) o W. Paul Mills (wpmills@midusa.net) (CPU fan disconnected from CPU) o Joseph Barone (barone@mntr02.psf.ge.com) (Bad cache) o Philippe Troin (ptroin@compass-da.com) (delayed RAM timing trouble) o Koen D'Hondt (koen@dutlhs1.lr.tudelft.nl) (more kernel error messages) o Bill Faust (faust@pobox.com) (cache problem) o Tim Middlekoop (mtim@lab.housing.fsu.edu) (CPU temp: fan installed) o Andrew R. Cook (andy@anchtk.chm.anl.gov) (bad cache) o Allan Wind (wind@imada.ou.dk) (P66 overheating) o Michael Tuschik (mt2@irz.inf.tu-dresden.de) (gcc2.7.2p victim) o R.C.H. Li (chli@en.polyu.edu.hk) (Overclocking: ok for months...) o Florin (florin@monet.telebyte.nl) (Overclocked CPU by vendor) o Dale J March (dmarch@pcocd2.intel.com) (CPU overheating on laptop) o Markus Schulte (markus@dom.de) (Bad RAM) o Mark Davis (mark_d_davis@usa.pipeline.com) (Bad P120?) o Josep Lladonosa i Capell (jllado@arrakis.es) (PCI options overoptimization) o Emilio Federici (mc9995@mclink.it) (P120 overheating) o Conor McCarthy (conormc@cclana.ucd.ie) (Bad SIMM) o Matthias Petofalvi (mpetofal@ulb.ac.be) ("Simmverter" problem) o Jonathan Christopher Mckinney (jono@tamu.edu) (gcc2.7.2p victim) o Greg Nicholson (greg@job.cba.ua.edu) (many old disks) o Ismo Peltonen (iap@bigbang.hut.fi) (irq_unmasking) o Daniel Pancamo (pancamo@infocom.net) (70ns instead of 60ns RAM) o David Halls (david.halls@cl.cam.ac.uk) o Mark Zusman (marklz@pointer.israel.net) (Bad motherboard) o Elizabeth Ayer (eca23@cam.ac.uk) (Power management features) o Thorsten Kuehnemann (thorsten@actis.de) o o (あなたの話をメールしてくれたら、ここに載るかも... :-) ---- 更新― ―あなたのところで何が起きたのか聞きたいと思います。それによって、 何が最もたくさん起こっているのかが推測できるだろうし、この文書をで きるだけ正確に保つこともできるだろうから。でも、目下筆者のところに は、sig11 問題に遭遇したことのある人々のさまざまなメールアドレスが 500 前後あります。このリストに「手当たり次第に」名前を追加し続ける のが有益だとは思いません。「あなたは」どう思う? ___________________________________________________________________ ___________________________________________________________________ 新たな話に興味があります。もし問題を抱えていて、それが何であるか確信が もてないなら、R.E.Wolff@BitWizard.nl にメールをいただけると、助けにな れるかもしれません。普通なら好奇心がわたしに、その問題が何であるかをあ なたがつきとめるまで、質問に答えるように駆りたてるでしょう..... (一 方、問題が明らかに上に挙げてあるものなら、うんざり :-) ______________________________________________________________________ ______________________________________________________________________ 日本語版の謝辞 この文書の翻訳にあたって、JF ML のみなさんにたいへんお世話になりまし た。なかでも、山下 義之さん、武井 伸光さんにはたくさんの有益なアドバイ スをいただきました。感謝します。 -- Masanori Kobayasi (zap03216@nifty.ne.jp) ______________________________________________________________________ ______________________________________________________________________ この文書のオリジナル英文は で管理されていま す。