<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">

<article id="index">

<artheader>
<title>The SIG11 problem</title>
<authorgroup>
 <author>
  <firstname>Rogier</firstname>
  <surname>Wolff</surname>
  <affiliation>
   <address><email>R.E.Wolff@BitWizard.nl</email></address>
  </affiliation>
 </author>
</authorgroup>
<pubdate>13 January 2001</pubdate>
<authorgroup>
 <othercredit role="translator" lang="ja">
  <firstname>雅典</firstname>
  <surname>小林</surname>
  <contrib>日本語訳</contrib>
  <affiliation>
   <address><email>zap03216@nifty.ne.jp</email></address>
  </affiliation>
 </othercredit>
</authorgroup>
<revhistory>
<revision>
  <revnumber></revnumber>
  <date>08 February 2001</date>
</revision>
</revhistory>

<!--
<html>
<head>
<title>The SIG11 problem</title>
</head>
<body>

-->

<abstract>
<!--
<h1>Signal 11 while compiling the kernel</h1> 
-->
<para>
カーネルをコンパイルする際の signal 11
</para>
</abstract>
</artheader>
<!--
This FAQ describes what the possible causes are for an effect that
bothers lots of people lately. Namely that a linux(*)-kernel (or any
other large package for that matter) compile crashes with a "signal
11". The cause can be software or (most likely) hardware. Read on to
find out more.
<br> 
-->
<sect1 id="introduction">
<title>はじめに</title>
<para>
この FAQ は、
近頃多くの人々を悩ませる現象は
いったいどういった原因で起こることがありうるのかを述べたものです。
すなわち、Linux(*) カーネル (または、その種の大きなパッケージ)
のコンパイルが ``signal 11'' でクラッシュするというものです。
原因はソフトウェアのこともありますが、ほとんどの場合はハードウェアにあります。
読み進めると、詳細が分るでしょう。
</para>
<!--
(*) Of course nothing is Linux specific. If your hardware is flaky,
Linux, Windows 3.1, FreeBSD, Windows NT and NextStep will all crash.

<br>
-->
<para>
(*)もちろん、Linux 固有の現象ではありません。
もしハードウェアがいかれているのなら、Linux,
Windows 3.1, FreeBSD, Windows NT, NextStep
はすべてクラッシュするでしょう。
</para>
<!--
If you are not reading this at 
<a href="http://www.BitWizard.nl/sig11/">
         http://www.BitWizard.nl/sig11/</a>, that's where
you can find the most recent version.
<br> 
-->
<para>
英文の最新版は
<ulink    
url="http://www.BitWizard.nl/sig11/">
http://www.BitWizard.nl/sig11/</ulink>
で入手できます。
</para>
<!--
For those of you who prefer reading this in French, the French
translation can be found at 
<a href="http://www.linux-france.org/article/sig11-fr/">
         http://www.linux-france.org/article/sig11-fr/</a>.
<br>
-->
<para>
フランス語で読みたい方のために、フランス語訳が
<ulink    
url="http://www.linux-france.org/article/sig11-fr/">
http://www.linux-france.org/article/sig11-fr/</ulink>
で入手できます。
</para>
<!--
For those of you who prefer reading japanese, the Japanese translation 
can be found at
<a href="http://www.linux.or.jp/JF/JFdocs/GCC-SIG11-FAQ.html">
         http://www.linux.or.jp/JF/JFdocs/GCC-SIG11-FAQ.html</a>.
<br>
-->
<para>
日本語訳 (この文書) の最新版は、
<ulink    
url="http://www.linux.or.jp/JF/JFdocs/GCC-SIG11-FAQ/">
http://www.linux.or.jp/JF/JFdocs/GCC-SIG11-FAQ/</ulink>
で入手できます。
</para>
<!--
<a href="mailto:r.e.wolff@BitWizard.nl">Email me at
R.E.Wolff@BitWizard.nl </a> if you find any spelling errors,
worthwhile additions or with an "it also happened to me" story. (Note
that I reject some suggested additions on my belief that it is
technical nonsense). I would appreciate it if you put "sig11" or
something like that in the subject.
-->
<para>
原文のスペルミスを見つけた、耳寄りな追加情報がある、
あるいは「わたしも同じ目にあった」なんて話があれば、R.E.Wolff@BitWizard.nl
にメールをください。
(注――技術的にナンセンスと考えられるものは却下します)
サブジェクトに ``sig11'' か、
そのような言葉を書き添えてもらえるとありがたいです。
</para>
</sect1>
<!--
<hr>
<h2>The Sig11 FAQ</h2><br>
-->
<sect1 id="sig11faq">
<title>The Sig11 FAQ</title>
<!--
<h3>QUESTION</h3> 
Signal 11, what does that mean?
<br>
-->
<sect2 id="mean">
<title>signal 11 ってどういう意味なの?</title>
<para>
<emphasis>質問</emphasis>
</para>
<para>
signal 11 ってどういう意味なの?
</para>
<!--
<h3>ANSWER</h3> 

Signal 11, or officially know as "segmentation fault", means that the
program accessed a memory location that was not assigned. That's
usually a bug in the program. So if you're writing your own program, 
that's the most likely cause. However, this FAQ will concentrate
on the possibilities besides that.
-->
<para>
<emphasis>答え</emphasis>
</para>
<para>
signal 11、正式には "segmentation fault" として知られている現象は、
プログラムが、割り当てられていないメモリ領域にアクセスしたという
意味なんだ。だから、もしあなたが自作のプログラムを製作中なら、
そのプログラムが原因で起こるというのが最もありがちなんだ。
でも、この FAQ ではそれ以外で起こる可能性に専念しようと思う。
</para>
</sect2>
<!--
<h3>QUESTION</h3> 
My (kernel) compile crashes with <br>
<pre>
      gcc: Internal compiler error: program cc1 got fatal signal 11
</pre>
What is wrong with the compiler? Which version of the compiler do I 
need? Is there something wrong with the kernel?
<br>
-->
<sect2 id="whatis">
<title>カーネルコンパイル中の signal 11 って何が原因なの?</title>
<para>
<emphasis>質問</emphasis>
</para>
<para>
(カーネルを) コンパイルしていると、
<screen>
      gcc: Internal compiler error: program cc1 got fatal signal 11
</screen>
と出てクラッシュします。
コンパイラの何がまずいのでしょうか?
コンパイラのどのバージョンが必要なのでしょうか?
カーネルにどこか不具合があるのでしょうか?
</para>
<!--
<h3>ANSWER</h3>
Most likely there is nothing wrong with your installation, your
compiler or kernel. It very likely has something to do with your
hardware.  There are a variety of subsystems that can be wrong, and
there is a variety of ways to fix it. Read on, and you'll find out
more.  There are two exceptions to this "rule". You could be running
low on virtual memory, or you could be installing Red Hat 5.x, 6.x or
7.x. There is more about this near the end.
-->
<para>
<emphasis>答え</emphasis>
</para>
<para>
おそらく、コンパイラにせよカーネルにせよ、
お使いのソフトウェア環境には何も悪いところはありません。
ハードウェアとの関係が大いにありそうです。
まずそうな部分はいろいろあり、直しかたも様々です。
読み進めると、詳細が分るでしょう。
この「法則」には、2 つの例外があります。
仮想記憶が不足している時と、Red Hat 5.x, 6.x, 7.x
のいずれかをインストールしている最中です。
この文章の最後のほうに詳しく書いてあります。
</para>
</sect2>
<!--
<hr><h3>QUESTION</h3>
Ok it may not be the software, How do I know for sure?
-->
<sect2 id="makesure">
<title>ソフトウェアが原因じゃないって、どうやって確かめたらいいの?</title>
<para>
<emphasis>質問</emphasis>
</para>
<para>
オッケー。ソフトウェアが原因じゃないって、どうやって確かめたらいいの?
</para>
<!--
<h3>ANSWER</h3>
First lets make sure it is the hardware that is causing your
trouble. When the "make" stops, simply type "make" again. If it
compiles a few more files before stopping, it must be hardware that is
causing you troubles. If it immediately stops again (i.e. scans a few 
directories with "nothing to be done for xxxx" before bombing at exactly
the same place), try
<br>
<pre>
        dd if=/dev/HARD_DISK of=/dev/null bs=1024k count=MEGS
</pre>
-->
<para>
<emphasis>答え</emphasis>
</para>
<para>
最初に、トラブルの原因がハードウェアであることを確認してみよう。
<command>make</command> が停止したら、もう一度
<command>make</command> とだけタイプする。
停止する前にもう少しだけファイルをコンパイルしたなら、
トラブルの原因はハードウェアに間違いない。
また即座に停止する (すなわち、``nothing to be done for xxxx''
を表示しながら少しばかりディレクトリをスキャンした後、
きっちり同じ場所で玉砕する) なら、
<programlisting>
        <command>dd <option>if=/dev/</option><replaceable>HARD_DISK</replaceable> <option>of=/dev/null</option> <option>bs=1024k</option> <option>count=</option><replaceable>MEGS</replaceable></command>
</programlisting>
を試してみよう。
</para>
<!--
Change HARD_DISK to "hda" to the name of your harddisk (e.g. hda or
sda. Or use "df .").  Change the MEGS to the number of megabytes of
main memory that you have.  This will cause the first several
megabytes of your harddisk to be read from disk, forcing the C source
files and the gcc binary to be reread from disk the next time you run
it.  Now type make again.  If it still stops in the same place I'm
starting to wonder if you're reading the right FAQ, as it is starting
to look like a software problem after all.... Take a peek at the "what
are the other possibilities" question..... If without this "dd"
command the compiler keeps on stopping at the same place, but moves to
another place after you use the "dd" you definitely have a disk->ram
transfer problem.
-->
<para>
<command><replaceable>HARD_DISK</replaceable></command>
を ``hda'' とかのハードディスクの名前 (例えば、hda
や sda など。<command>df</command> <option>.</option> すると出てくる) に、
<command><replaceable>MEGS</replaceable></command>
を搭載メインメモリのメガバイト数に置き換えて。
これを実行すると、
ハードディスクの最初の何メガバイトかがメモリに読み込まれるので、
次回 <command>make</command> する時には、C のソースファイルと
gcc バイナリは、
ディスクからメモリへ再度読み込まれることを強いられる。
ここでもう一度 <command>make</command> してみよう。
もし、依然として同じ場所で停止するのなら、
あなたが読むべきなのはこの FAQ なのかどうかあやしくなってくる。
なぜなら、結局のところソフトウェアの問題のように思われてくるから....
下にある「ほかの可能性はなんだろう」って質問をちょっと見てね.....
</para>
<para>
もし、この <command>dd</command>
コマンドを実行してないうちはコンパイラが同じところで止まり続けて、
<command>dd</command>
の実行後は別のところに移動するのなら、
ディスクからメモリへの転送に問題を抱えているのは確実だ。
</para>
</sect2>
<sect2 id="sure">
<title>ハードウェアの問題だってことは確かなの?</title>
<!--
<h3>QUESTION</h3>
What does it really mean? Are you sure it's a hardware problem?
<br> 
-->
<para>
<emphasis>質問</emphasis>
</para>
<para>
本当のところ、signal 11 ってどういう意味なの?
ハードウェアの問題だってことは確かなの?
</para>
<!--
<h3>ANSWER</h3>

Well, the compiler accessed memory outside its memory range. If this
happens on working hardware it's a programming error inside the
compiler. That's why it says "internal compiler error". However when
the hardware occasionally flips a bit, gcc uses so many pointers, 
that it is likely to end up accessing something outside of its addressing
range. (random addresses are mostly outside your addressing range, as
not very many people have a significant part of 4G as main memory... :-)
-->
<para>
<emphasis>答え</emphasis>
</para>
<para>
いいかい、コンパイラが、
コンパイラの管理するメモリ区域の外側にアクセスしたんだ。
もし動作中のハードウェアでこいつが起こるなら、
コンパイラの内部にプログラミングの間違いがあるってこと。
それで ``internal compiler error'' っていうわけ。
でも、gcc はとてもたくさんのポインタを使うものだから、
ハードウェアがときたまビットを反転させてしまう場合、
しまいにはアドレッシングレンジの外側のどこかにアクセスしちゃいそうになる。
(めちゃくちゃなアドレスはたいていアドレッシングレンジの外側になっちゃう。
なぜって、
メインメモリに 4G ものお宝をもってるひとはめったにいないから... :-)
</para>
<!--
It seems that nowadays, everybody with "signal 11" problems gets
directed to this page. If you're developing your own software or have
software that hasn't been debugged quite enough, "signal 11" (or
segmentation fault) is still a very strong hint that there is
something wrong with the program. Only when a program like "gcc" that
works for almost everybody else to crash on a dataset (e.g. the
Linux-kernel) that has also been well-tested, then it becomes a hint
that there is something wrong with your hardware.
-->
<para>
近頃 ``signal 11'' 問題に遭遇したひとはみんなこのページに直行するみたいだ。
でも、もしあなたが自作のソフトウェアを開発している、
もしくはまだ十分にデバッグされてないソフトウェアをもっているのなら、
``signal 11'' (または、segmentation fault)
は依然としてプログラムの不具合を知らせるとても強力なヒントになる。``gcc''
のようなほとんど誰のところでも動作してるプログラムで、
これまたよくテストされたデータセット (例えば、Linux カーネル)
のクラッシュを引き起こした場合だけが、
ハードウェアに不具合があるヒントとなるんだ。
</para>
<!--
If some software component like a hardware driver in your system is
broken, it could cause symptoms that are VERY close to those of a
hardware failure. However, when a driver is faulty it is more likely
to cause serious trouble inside the kernel, than just causing the
compiler to crash.
-->
<para>
もし、システムの中で、
ハードウェアのドライバに類するソフトウェアが壊れていたら、
ハードウェアの故障に酷似した症状が起こることもありうる。
でも、ドライバがダメな場合は、
単にコンパイラのクラッシュを引き起こすことよりも、
カーネル内部の深刻なトラブルを引き起こすことのほうがありがちだ。
</para>
</sect2>
<!--
<hr><h3>QUESTION</h3> 
Ok. I may have a hardware problem what is it?
-->
<sect2 id="hardware">
<title>ハードウェアの何が問題なんだろう?</title>
<para>
<emphasis>質問</emphasis>
</para>
<para>
オッケー。ハードウェアの何が問題なんだろう?
</para>
<!--
<h3>ANSWER</h3>
If it happens to be the hardware it can be:
-->
<para>
<emphasis>答え</emphasis>
</para>
<para>
もしハードウェアがそいつを引き起こすなら、原因は:
</para>
<!--
<ul>

<li>Main memory. Your main memory might be getting an occasional bit wrong.
If this happens on the "writes", you won't see any parity errors. There are
several ways to fix it: 
-->
<sect3 id="mainmemory">
<title>メインメモリ</title>
<para>
メインメモリ。
メインメモリがときたまビットを間違うのかもしれない。
もし「書き込み」の際に起こるなら、
パリティーエラーが現われることはないだろう。
いろんな解決策がある:
</para>
<!--
  <ul>
  
  <li>The memory speed might be too slow. Increase the number of
      wait states in the BIOS. <br> This could be caused by the
      AMIBIOSs autoconfig option: it may only know about 486s running
      upto 80 MHz, whereas you currently buy 100 MHz versions. &#045;&#045; Pat
      V.
-->
<itemizedlist>
<listitem><para>
メモリの速度が遅すぎるのかも。BIOS の wait states の数値を上げる。
</para><para>
AMIBIOS の autoconfig option で起きることがある――
今だと 100MHz の 486 が買えるけど、autoconfig option
は 80MHz までの 486 しかちゃんと認識しないかも。
-- Pat V
</para></listitem>
<!--
  <li>The memory speed might be too slow. Get faster DRAM SIMMs. For
      example current ASUS motherboards require 60 ns DRAM if you have
      a 100, or 133 MHz processor (Take a look in your motherboard's
      manual). I've heard reports that 70 ns also works, reliability
      problems like random sig11's belong to the possibilities.... (I
      wouldn't take the risk) &#045;&#045; Andrew Eskilsson
      (mpt95aes@pt.hk-r.se)
-->
<listitem><para>
メモリの速度が遅すぎるのかも。
もっと速い DRAM SIMM を入手する。
例えば、現行の ASUS のマザーボードは
100 または 133MHz のプロセッサなら 60ns DRAM
を要求します (マザーボードのマニュアルを見てね)。70ns
でも動きますが、
ランダムな sig11 が起こりうるような信頼性の問題があると報告されています....
(リスクは負いたくありません) -- Andrew Eskilsson
(mpt95aes@pt.hk-r.se)
</para></listitem>
<!--
  <li>You might think that you can run your 100MHz SDRAMs at
  100MHz. Wrong! read <a
  href="http://www.bitwizard.nl/sig11/sdram.html">
  http://www.bitwizard.nl/sig11/sdram.html</a> why I think this is the
  case. You need at least one speed grade faster than the speed they
  are rated for.
-->
<listitem><para>
100MHz SDRAM は 100MHz で動作可能に思えるかもしれないけど、
それは間違いだ!
<ulink    
url="http://www.BitWizard.nl/sig11/sdram.html">
http://www.BitWizard.nl/sig11/sdram.html</ulink>
を読んでみて。このことが事実だと思う理由が書いてあるから。
少なくとも、
妥当と思われるスピードよりも一段階速いグレードのものが必要だ。
</para></listitem>
<!--
  <li>There is a bad chip on one of the SIMMs. If you own more than 1
  bank of memory you might be able to pull SIMMs and see if the
  problem goes away. Be careful for STATIC!!!
-->
<listitem><para>
SIMM のうちの 1 つにまずいチップがあります。
もしバンク 1 つ以上のメモリがあるなら、SIMM を引き抜いて、
問題が解決するかどうか見てみましょう。静電気に注意して!!!
</para></listitem>
<!--
  <li>We handled a hard one here the last week. It turned out that ALL
  4 16Mb SIMMs were broken in that they dropped a bit around once per
  hour. This was sufficient to crash the machine in about a day, or
  crash a kernel compile in about an hour. A new set of SIMMs works
  perfectly. It took a long while to diagnose this one, because all 4
  of the SIMMs were affected equally, so leaving half of the memory
  out didn't change things.
-->
<listitem><para>
先週強烈なメモリのマシンを取り扱った。16MB SIMM
が 4 つとも壊れていて、どれも 1 時間に
1 回ぐらいビットを落とすことが判明した。
こいつはだいたい 1 日でマシンをクラッシュさせたり、1
時間くらいでカーネルのコンパイルをクラッシュさせたりするのに十分だった。
で、まとめて新しい SIMM に交換したら完璧に動くようになった。
こいつを診断するには長い時間がかかった、
なぜなら SIMM が 4 つとも同じようにいかれていたからだ。
そんな訳でメモリを半分交換しただけでは何の変化もなかった。
</para>
<!--
  <br> Mark Kettner (kettner@cat.et.tudelft.nl) reports that his 
  system was capable of running my memory test for 2300 times
  faultlessly, but then detected around 10 errors. It then continued 
  detecting no faults for a few hundred runs again..... In his case
  running kernel compiles was a much more efficient way of detecting
  the health of the system (in the most stable configuration the
  system could compile around 14 kernels before going bzurk). His
  solution was to "trade in" the old memory for a so called "memory
  upgrade". The shopkeeper then "tests" in their memory tester, which
  OKs the memory. He then got a good discount on the new memory :-).
-->
<!-- ?? going bzurk -->
<para>
Mark Kettner (kettner@cat.et.tudelft.nl) からの報告です。
彼のシステムは、
筆者謹製のメモリテストを失敗せずに 2300 回走らせることができたが、
それから 10 前後のエラーが検出された。
その後はまた二、三百回失敗が検出されずに動き続けた.....
彼のケースでは、カーネルコンパイルは、
システムの健康を診断するよりいっそうすぐれた手段だった
(最も安定した設定で、
クラッシュする前に 14 前後のカーネルをコンパイルできた)。
彼は、
古いメモリを自称「メモリアップグレード」するために「返品交換」して解決することにした。
店員がメモリテスターでテストした結果、メモリは「異常なし」とのこと。
そんな訳で、彼は新品のメモリを割引きしてもらった :-)。
</para></listitem>
<!--  
  <li>It seems that some 30-72 pin converters can cause memory errors.
  (See how old this entry is? Who remembers 30pin SIMMs? However all
  these things hold perfectly for SIMM <-> DIMM converters, or socket370
  <-> slot 1 converters) (It hasn't been proven whether the 4 SIMMS in
  the converter had gone bad, or if the SIMM converter was at
  fault. The SIMMS had been functioning perfectly for years before
  they were moved into the converter....) &#045;&#045; Naresh Sharma
  (n.sharma@is.twi.tudelft.nl).  Paul Gortmaker
  (paul.gortmaker@anu.edu.au) adds that the SIMM converters should
  have at least 4 bypass capacitors to keep the power supply of the
  SIMMs clean.
-->
<listitem><para>
30-72 ピンコンバータの中には、
メモリエラーを引き起こすものもあるようだ。
(この項目はめちゃ古いんじゃないかって?
誰が 30pin SIMM なんて過去の遺物を憶えてるのかって?
でも、これらのことはすべて SIMM ←→ DIMM コンバータや
socket370 ←→ slot 1 コンバータにも完璧にあてはまるよ)
(コンバータ上の 4 つの SIMM が壊れたのか、
あるいはコンバータに欠陥があったのかは、いまだに分らない。SIMM
は、コンバータに移し替える前は長年完璧に動いていたものだった....)
-- Naresh Sharma (n.sharma@is.twi.tudelft.nl).
</para><para>
Paul Gortmaker (paul.gortmaker@anu.edu.au) は、SIMM
にきれいな電力を供給し続けるためには、SIMM
コンバータは少なくとも 4 個のパスコンを備えるべきだと補足してくれた。
</para></listitem>
<!--
  <li>If the refresh of the DRAM isn't functioning properly, the DRAMs
      will slowly lose their information. Some (486) motherboards stop
      refreshing correctly when you turn on "hidden refresh". There
      seems to be a program called "dram" around that can also mess up
      your refresh to cause sig11 problems. &#045;&#045; Hank Barta
      (hank@pswin.chi.il.us), Ron Tapia (tapia@nmia.com)
-->
<listitem><para>
もし DRAM のリフレッシュがきちんと機能していないなら、DRAM
は保持している情報をゆっくりと失なっていくだろう。``hidden refresh''
を有効にした場合、(486)
マザーボードの中には正確にリフレッシュするのをやめるものもある。
リフレッシュをめちゃくちゃにして sig11 問題を引き起こしうる
``DRAM'' まわりのプログラムもあるようだ。
-- Hank Barta (hank@pswin.chi.il.us), Ron Tapia (tapia@nmia.com)
</para></listitem>
<!--
  <li>The number of wait states could be too low. Increase the number of
      waist states in the BIOS for a fix. The Intel Endeavour board 
      doesn't allow you to increase the memory wait states. This can
      supposedly be fixed by flashing a MR BIOS into the motherboard.
      &#045;&#045; David Halls (david.halls@cl.cam.ac.uk)
  </ul>
-->
<listitem><para>
wait states の数値が低すぎるのかもしれない。BIOS
の wait states の数値を上げると直る。インテルの Endeavour board は、
メモリの wait states を上げることができない。
これは MR BIOS をマザーボードに書き込めば可能になると思われる。
-- David Halls (david.halls@cl.cam.ac.uk)
</para></listitem></itemizedlist>
</sect3>
<!--
<li>Cache memory. Your cache memory might be getting an occasional
     bit wrong.  Caches are usually not equipped with parity. You can
     diagnose that this is the case by turning off the cache in the
     BIOS. If the problem goes away it is probably the cache. There
     are several ways to fix it:

  <ul>
-->
<sect3 id="cachememory">
<title>キャッシュメモリ</title>
<para>
キャッシュメモリ。
キャッシュメモリがときたまビットを間違うのかも。
キャッシュには普通パリティーがついていない。BIOS
のキャッシュの項目をオフにすることで、
このケースに当てはまるかどうかが診断できる。
もし直ったら、おそらくキャッシュが原因だ。
いろんな解決策がある:
</para>
<itemizedlist>
<!--
 <li>The cache memory speed might be too slow. Increase the number
       of wait states in the BIOS.
-->
<listitem><para>
キャッシュメモリの速度が遅すぎるのかも。BIOS
の wait states の数値を上げる。
</para></listitem>
<!--
 <li>The cache memory speed might be too slow. Get faster SRAM
      chips.
-->
<listitem><para>
キャッシュメモリの速度が遅すぎるのかも。
もっと速い SRAM のチップに交換する。
</para></listitem>
<!--
 <li>There is a bad chip in your cache. It is unlikely that you can
     swap chips as easily as with SIMMs. Be careful for STATIC!!!
     &#045;&#045; Joseph Barone (barone@mntr02.psf.ge.com)
-->
<listitem><para>
キャッシュに壊れたチップがある。SIMM
みたいに簡単にチップの交換はできそうもない。
静電気に注意して!!!
-- Joseph Barone (barone@mntr02.psf.ge.com)
</para></listitem>
<!--
 <li>The cache might be set to "write back" while there is a bug in the
     write back implementation of your chipset. The motherboard where 
     this happened was a "MV020 486VL3H" (with 20M RAM)
      &#045;&#045; Scott Brumbaugh (scottb@borris.beachnet.com) (Mail address
        doesn't work. Scott: Get back at me with a valid return address)
-->
<listitem><para>
チップセットのライトバックの実装にバグがある一方で、
キャッシュのライトバックが有効になっているのかもしれない。
こいつが起こるマザーボードは ``MV020 486VL3H'' (with 20M RAM)
だった。-- Scott Brumbaugh (scottb@borris.beachnet.com)
(メールアドレスに届かない。スコット、
きちんと送り返せるアドレスで返事をくれ)
</para></listitem>
<!--
 <li>The motherboard may require a jumper to switch between Cache On A
     Stick and the old-fashioned dip chip cache. (JP16 on Rev 2.4 ASUS
     P/I-P55TP4XE motherboards) 
</ul>
-->
<listitem><para>
マザーボードが、スロットタイプのキャッシュと、
時代遅れの DIP チップのキャッシュを切り替えるジャンパを要求しているのかも。
(Rev 2.4 ASUS P/I-P55TP4XE マザーボード の JP16)
</para></listitem></itemizedlist>
</sect3>
<!--
<li>Disk transfers. A block coming from disk might incur an occasional
    bit error.

   <ul>
-->
<sect3 id="disktransfers">
<title>ディスク転送</title>
<para>
ディスク転送。ディスクから送られてくるブロックが、
ときたまビットエラーにやられてるのかも。
</para>
<itemizedlist>
<!--
   <li>If you have this problem, you are most likely to have to do the
   "dd" command to "move" the problem from one place to the next....
-->
<listitem><para>
もしこの問題があるなら、十中八九、
問題をある地点から次の地点へと「移動させる」ために <command>dd</command>
コマンドを実行しなくてはならないようです....
</para></listitem>
<!--
   <li>Some IDE harddisks cannot handle the "irq_unmasking" option.
   This may only show under load. And it could show as a sig11.
-->
<listitem><para>
IDE ハードディスクの中には
``irq_unmasking'' オプションを扱えないものがあります。
この問題は負荷がかかっている時だけ出現するかもしれません。
sig11 として顔を見せることがありえます。
</para></listitem>
<!--
    <li>Do you have a kalok 31xx? Throw it in the garbage. (or sell it
    to a DOS user. Update: Haven't heard about kalok for years. They're
    probably bust. The drives also don't work with W95 by the way.)
-->
<listitem><para>
kalok 31xx をもってる? ならゴミ箱にステステ。
(それか、DOS 野郎に売りつけてやろう。
更新――もう何年も kalok の噂を聞いたことがない。
たぶんつぶれちゃったのでしょう。
ついでに言うと、ドライバは Windows 95 でも動きません。)
</para></listitem>
<!--
   <li>SCSI? Termination? A short bus might still work (unreliably
       that is) with bad termination. A long bus might get errors
       anyway. Can you turn on parity on the host and the DISK?

   </ul>
-->
<listitem><para>
SCSI? ターミネーター?
短かいケーブルなら壊れたターミネーターでも
(信頼できないけど) そのまま動くかも。
長いケーブルならやっぱりエラーが出るかも。
ホストとディスクのパリティーを有効にできる?
</para></listitem></itemizedlist>
</sect3>
<!--
<li>The CPU itself. Some batches of processors have a much higher 
    percentage of them that happen to be "bad". Some years ago:
    original Intel-Pentium-120's. A few years ago AMD K6/2-300's 
    (1998, produced in weeks 34 through 39!). And recently AMD K6/2-450's.
    Some people may decide that say 400MHz is acceptable to them, however
    if this turns out to be the problem, you're entitled
    to a new processor. Go and exchange it where you bought it.
    (Forget about those P120's, it's not worth the trouble... ;-)
    &#045;&#045; Guillaume Cottenceau (gcottenc@ens.insa-rennes.fr). 
-->
<sect3 id="etc">
<title>その他</title>
<itemizedlist>
<listitem><para>
CPU そのもの。プロセッサのロットの中には、
「故障」する確率が非常に高いものがあります。 
数年前だとオリジナルのインテルペンティアム 120。
2, 3 年前だと AMD K6/2-300
(1998 年の 34 週目から 39 週目に製造されたもの!)。
最近だと AMD K6/2-450 です。まあ、400MHz
ならいけると判断するひともいるかもしれません。
でも、この問題であることが判明したら、
新品のプロセッサを得る権利があります。
買ったお店に行って、交換してもらいましょう。
(P120 のことは忘れましょう。わざわざ交換しに行く価値すらありません... ;-)
-- Guillaume Cottenceau (gcottenc@ens.insa-rennes.fr).
</para></listitem>
<!--
<li>The CPU itself. Some batches of K6 processors simply have a
    design bug. Read <a href="http://www.multimania.com/poulot/k6bug.html">
    http://www.multimania.com/poulot/k6bug.html</a> and then make sure
    you get your K6 exchanged. &#045;&#045; Rongen (rongen@istar.ca).
-->
<listitem><para>
CPU そのもの。K6 プロセッサのロットの中には、
単なる設計上のバグがあるものがあります。
<ulink    
url="http://www.multimania.com/poulot/k6bug.html">
http://www.multimania.com/poulot/k6bug.html</ulink>
を読んで、お手もちの K6 が返品交換できるか確認してみましょう。
-- Rongen (rongen@istar.ca).
</para></listitem>
<!--
<li>Overclocking. Cyrix P-166 processors run at 133MHz, not at
    166. This must be logical to the guys at Cyrix, but nobody else.
    You're overclocking them if you run them at 166Mhz.....
-->
<listitem><para>
オーバークロック。Cyrix P166 プロセッサは 166MHz ではなくて
133MHz で動作します。これは、Cyrix
の連中にとってはきっと理にかなったことなのでしょうが、
部外者には想像がつきません。
もし 166MHz で Cyrix P166 をお使いなら、
オーバークロックしていることになります.....
</para></listitem>
<!--
<li>Overclocking. Some vendors (or private people) think it is
    possible to overclock some CPUs. Some of them may work others
    don't. You might want to try turning off turbo (note that most
    pentium motherboards no longer support a non-turbo mode) and see
    if the problem goes away. Check the speed of your CPU compared
    (printed on it, carefully remove the fan if necessary) with what
    the motherboard jumpers or BIOS settings say....  It seems that
    even Intel may make mistakes in this area. I now have several
    reliable reports that official pentium would sig11 at their rated
    speed, but not at a lower speed. As for some speeds the
    motherboard is only stressed HARDER for a slower processor speed,
    (120 MHz-> motherboard runs at 60MHz, 100MHz-> motherboard runs at
    66MHz), I think it is unlikely that this has anything to do with
    the motherboard. Moreover a new 120MHz processor is now
    functioning correctly. &#045;&#045; Samuel Ramac (sramac@vnet.ibm.com).
    This is not unique to Intel or any of its competitors.
-->
<listitem><para>
オーバークロック。ベンダー (や個人) の中には、
いくつかの CPU
でオーバークロックができると考えている方がいます。
動く可能性があるものもあれば、動かないのもあります。
ターボスイッチ (注――ほとんどのペンティアム対応マザーボードは、
もはやノンターボモードをサポートしていません) をオフにしてみると、
問題が解決するかどうかが分ります。CPU の速度
(表面に印刷されています。必要なら慎重にファンを取り外して) を、
マザーボードのジャンパや BIOS の設定と比較して、チェック....
</para>
<para>
インテルでさえ、CPU のクロック刻印が間違ってることがあるようです。
目下、正規のペンティアムが妥当なクロックで sig11 を起こす、
もっと低いクロックにすると起きなくなる、
という複数の信頼できる報告があります。
クロックの中には、ゆっくりしたプロセッサのクロックよりも、
激烈にマザーボードを痛めつけるだけのものもあるので
(120MHz → マザーボードのクロック 60MHz,
100MHz → マザーボードのクロック 66MHz)
マザーボードとの関係はなさそうに思います。
付け加えると、新品の 120MHz のプロセッサは今ちゃんと動いています。
-- Samuel Ramac (sramac@vnet.ibm.com).
これは、インテルやその競合メーカーに特有のものではありません。
</para></listitem>
<!--
<li>CPU temperature. A high speed processor might overheat without the
    correct heat sink. This can also be caused by a failing fan. (My
    personal '486 has a fan that takes a few minutes to get up to
    speed. It probably will never really FAIL because it's now
    decommissioned :-). The CPU can become erratic if "pushed" by
    compiling a kernel. This problem becomes worse if you disable
    "HALT" on the LILO command line. Linux tries to power-down the CPU
    by executing the "halt" instruction when the system is idle. This
    preserves power, and therefore the CPU temperature drops when the
    system is idle. You therefore might not notice this problem when
    simply editing, and it might only surface after hours of CPU
    intensive jobs when the ambient temp is high.
-->
<listitem><para>
CPU の温度。高速のプロセッサは、
まともなヒートシンクを付けないとオーバーヒートするでしょう。
ダメなファンで起こることもあります。
(愛機 '486 には、
スピードが上がるのに 2, 3 分かかるファンがついています。
たぶん、実際のところこいつは決して落ちることはないでしょう。
なぜなら、もう使ってないから:-)
CPU は、カーネルのコンパイルによって「酷使」されると、
おかしくなることがあります。この問題は、LILO
のコマンドラインオプションで 
<command><option>HALT</option></command>
を無効にすると、いっそう悪くなります。Linux は、
システムがヒマな時に halt 命令を実行することによって、CPU
の消費電力減少を試みます。電力が温存されるので、
システムがヒマな時は CPU の温度が低くなります。
それゆえに単純なエディット作業の時には、
この問題に気付かないかもしれません。気温が高い時に、
何時間も CPU を激しくこき使った後にだけ表面化するでしょう。
</para>
<!--
    If you have a
    Pentium with Fdiv bug, it is advisable to trade it in at Intel.
    They will send you a new one that pre-configured with an official
    Intel-approved FAN. Also note that most normal glues are very bad
    thermal conductors. There is special thermal glue available that
    should be used when a fan needs to be glued to a CPU. &#045;&#045; Arno
    Griffioen (arno@ixe.net), &#045;&#045; W. Paul Mills (wpmills@midusa.net)
    &#045;&#045; Alan Wind (wind@imada.ou.dk) <p>
-->
<para>
もし Fdiv バグのペンティアムをおもちなら、
インテルに交換してもらうのが賢明です。
正規のインテルおすみつきのファンで、
あらかじめ設定された新品を送ってくれるでしょう。
補足――
たいていの一般的な接着剤は熱伝導率が非常に悪い。
ファンを CPU に接着する必要のある時に使うのが妥当な、
特殊な熱伝導率のよい接着剤が入手できる。
-- Arno Griffioen (arno@ixe.net), -- W. Paul Mills (wpmills@midusa.net)
-- Alan Wind (wind@imada.ou.dk)
</para>
<!--
    Intel says that the allowable temperature ranges for the
outside of your CPU is:<br>
0 to +85 C: Intel486 SX, Intel486 DX, IntelDX2, IntelDX4 processor<br>
0 to +95 C: IntelDX2, IntelDX4 OverDrive(R) processors<br>
0 to +80 C: 60 MHz Pentium(R) processor<br>
0 to +70 C: 66 to 166 MHz Pentium processor<br>
    For information on how to measure this and some confirmation of what
    I say here, see: 
<a href="http://pentium.intel.com/procs/support/faqs/iarcfaq.htm">
         http://pentium.intel.com/procs/support/faqs/iarcfaq.htm</a>
     (Especially questions Q5, Q6 and Q12. The document is getting
slightly outdated, but it is still very accurate. It seems the
questions move around a bit every now and then as well.)
-->
<para>
インテルいわく、CPU 外部の許容温度の範囲は:
</para><para>
0 to +85 C: Intel486 SX, Intel486 DX, IntelDX2, IntelDX4 processor</para><para>
0 to +95 C: IntelDX2, IntelDX4 OverDrive(R) processors</para><para>
0 to +80 C: 60 MHz Pentium(R) processor</para><para>
0 to +70 C: 66 to 166 MHz Pentium processor</para><para>
計り方の情報および、ここに書かれたことを確認するには、
<ulink    
url="http://pentium.intel.com/procs/support/faqs/iarcfaq.htm">
http://pentium.intel.com/procs/support/faqs/iarcfaq.htm</ulink>
を見てね。
(特に質問の Q5 と Q6 と Q12。
その文書はちょっと時代遅れになってきてるけど、
今なおとても正確。質問をすこし今風にすればさらによくなるみたい。)
</para></listitem>
<!--
<li>CPU voltage. Some motherboards allow you to select the CPU
    voltage. Some motherboards badly document the jumper settings that
    manage this. It seems that a 5V processor might still work most of
    the time at 3.3 volts.....  &#045;&#045; Karl Heyes
    (krheyes@comp.brad.ac.uk)
-->
<listitem><para>
CPU の電圧。マザーボードのなかには、CPU の電圧が選べるものがあるし、CPU
の電圧を扱うジャンパの設定がへたくそなマニュアルに書かれているものもある。
5V のプロセッサはほとんどの場合、3.3V
でも依然として動くように思われる.....
-- Karl Heyes (krheyes@comp.brad.ac.uk)
</para></listitem>
<!--
<li>RAM voltage. It seems that vendors are preparing for 3.3V RAM
    now. Most memory is now 3.3V. (but be careful if you have a board
    capable of setting the RAM voltage: 3.3v RAM will break at 5V.....)
    (Having heard little about this, I think the switch must be automatic.)
-->
<listitem><para>
RAM の電圧。ベンダーは今、3.3V RAM を用意してるみたい。
たいていのメモリは目下 3.3V。
(でも RAM の電圧を設定できるマザーボードをもってるなら注意して――
3.3V RAM は 5V 流すと壊れちゃう.....)
(ほとんど気にしなくていいよ、自動で切り替わるに違いないと思うから。)
</para></listitem>
<!--
<li>Local bus overloading. At 25 MHz you're allowed to have 3
    VesaLocalBus (VLB) cards, At 33MHz only two, at 40MHz only one and
    guess what at 50MHz NONE! (i.e. you are allowed to run your system
    with a 50MHz local bus, but then you're not allowed to use any VLB
    cards). Some systems start acting flaky when you overload the
    VLB. Even when your VLB isn't overloaded (over the limits stated
    above), the system may lose a few nanoseconds of margin by adding
    an extra VLB card, so you might need to add a cache wait state or
    something after you've added a new VLB card....  &#045;&#045; Richard
    Postgate (postgate@cafe.net)
-->
<listitem><para>
ローカルバスの過負荷。25MHz だと
3 つの VesaLocalBus (VLB) カードが使えます。33MHz
だと 2 つだけ。40MHz だと 1 つだけだし、50MHz だとたぶんゼロ!
(つまり、50MHz の ローカルバスのシステムが使えても、VLB
カードは 1 つも使えない)。
システムの中には、VL
バスに負荷をかけ過ぎた場合におかしくなりはじめるものもあります。
過負荷 (上記の限界以上) でない時さえ、
システムは余計な VLB カードの追加によって、
きわどいところの 2, 3 ナノセコンドを失なうことがあるかもしれません。
よって、新しい VLB カードの増設後、
キャッシュの wait states かなんかを上げる必要がでてくるでしょう....
-- Richard Postgate (postgate@cafe.net)
</para></listitem>
<!--
<li>Power management. Some laptops (and nowadays also "green" pc's)
    have power management features. These might interfere with
    Linux. One feature might save a memory image to HD and restore the
    RAM when you press a key.  This sounds like fun, but Linux device
    drivers don't expect that the hardware has been turned off between
    two accesses. Some may recover, but others not. Try turning it off,
    or enabling "APM support" in your kernel.  &#045;&#045; Elizabeth Ayer
    (eca23@cam.ac.uk)
-->
<listitem><para>
電源管理。ラップトップ (いまどきの「グリーン」 PC も)
のなかには、電源管理の機能をもっているものもあります。
これらは Linux のじゃまをするかもしれません。
ある機能は、メモリイメージを HD にセーブしておいて、
キーを押した時にメモリを元の状態に戻すもののようです。
こいつはよさげですが、Linux のデバイスドライバは、2
回のアクセスの間にハードウェアがお休みするのをあてにしていません。
復帰するものもあれば、しないのもあります。
試しに電源管理を無効にするか、
カーネルの ``APM support'' を有効にしてみてください。
-- Elizabeth Ayer (eca23@cam.ac.uk)
</para></listitem>
<!--
<li>Dust buildup. Some dust might conduct a bit and create a weak
    short. It might increase capacitances somewhere, and degrade
    timing characteristics. It might impede thermal flow, and lead to
    overheating components. It might even short a jumper connection! I
    recommend that every year or so, it is a good idea to open up your
    computer, and vacuum the inside. Tip: Those cotton-on-a-stick
    thingies help prodding the dust out of inaccessible spots... &#045;&#045;
    Craig Graham (c_graham@hinge.mistral.co.uk). Someone else told me: 
    if you can, use pressureized air to blow things out instead of the
    vacuum cleaner. Preferably do this outside. 
-->
<listitem><para>
積もり積もったホコリ。ホコリの中には、
ちょっと電気を通して微弱なショートを起こすものがあります。
どこかでキャパシタンツを増加させ、
タイミングの特性を劣化させるかもしれませんし、
熱の発散を妨げてどこかをオーバーヒートさせるかもしれません。
ジャンパをショートさせることさえあるかもしれないのです!
お使いのコンピュータのケースを開けて内部を掃除するのはいいアイデアなので、
年に一度ぐらいやるのをお勧めします。
豆知識――綿棒は、
手の届かないところのホコリを突っつくのに役立ちます...
-- Craig Graham (c_graham@hinge.mistral.co.uk)
誰かが教えてくれたことによると――
できればホコリを吹き飛ばすには、掃除機のかわりに圧縮エアーを
使いましょう。なるべく屋外で。
</para></listitem>
<!-- 最後の </ul> はたぶん不要。-->
<!--
<li>The CPU itself. Several people are reporting that they have found
    nothing to blame except the CPU. This could also have been an
    incompatibility between the CPU and the motherboard. A wave of
    reports concerning Intel CPUs has passed (Feb '97). A new wave of
    reports is coming in that are blaming Cyrix/IBM 6x86
    CPUs. Although it could indeed be the CPU, it could also be that
    your motherboard is incompatible with your CPU. At least I've seen
    a motherboard manual mention that it isn't compatible with older
    6x86's. My own experience is that these devices aren't bad at all,
    and on a kernel compile I benchmarked a P166+ to be equivalent
    with a P155 (1.3 times faster than a P120).  </ul>
-->
<listitem><para>
CPU そのもの。何人もの人々が、CPU
以外にやばいものが見つからなかったと報告してきています。CPU
とマザーボードに互換性がなかったこともあるのでしょう。
インテル CPU がらみのレポートの波は
97 年 2 月に過ぎ去りました。Cyrix/IBM 6x86 CPU
を非難する新たな波がおしよせてきています。
本当に CPU のせいなのかもしれませんが、
マザーボードと CPU のあいだに互換性がないせいかもしれません。
少なくともマザーボードのマニュアルに、
古い 6x86 とは互換性がないと言及してあるのを見たことがあります。
筆者自身の経験では、このデバイスは全然悪くないです。
カーネルコンパイルの際のベンチマークでは、P166+
が P155 と同じくらい (P120 より 1.3 倍速い) でした。
</para></listitem>
<!--
<li>The Memory hole. Many modern motherboards allow you to use old
    ISA video cards with one or two megabytes of linear frame buffer.
    To achieve this, they have to map out the memory just below
    16Mb. Nobody actually ever used this feature, but if you turn
    the memory  hole (or LFB support in some BIOSes) on, your
    machine will certainly be flaky..... &#045;&#045; Paul Connolly
    (pconnolly@macdux.com.au) </ul>
-->
<listitem><para>
メモリの穴。現行マザーボードの多くは、
リニアフレームバッファに 1 ないし 2 メガバイトを割りあてて、
古い ISA のビデオカードを使うことができます。
これをやるためには、ちょうど 16MB
の真下にメモリをマッピングしなくてはなりません。
実際、いまだかつてこんな機能を使ったひとがいるとは思えないのですが、
もしメモリに穴
(BIOS のなかには、LFB support の項目になってるものもある) があいているなら、
マシンは間違いなくおかしくなってしまうでしょう.....
-- Paul Connolly (pconnolly@macdux.com.au)
</para></listitem>
<!--
<li>
    The Microcode. Especially on SMP systems, the CPUS may need an
    upgrade. Since the Pentium division disaster, Intel have their
    CPUs field upgradable! The CPU can be bumped a few versions by a
    special instruction from the BIOS.  These upgrades usually come
    with your BIOS, so make sure you're running the latest BIOS,
    especially if you have an SMP system. &#045;&#045; Jeffrey Friedl (Email withheld).
-->
<listitem><para>
マイクロコード。とりわけ SMP システムでは、CPU がマイクロコードの
アップグレードを必要としているのかもしれません。Pentium に割り算のバグ
があったせいで大惨事が起こったので、インテルは CPU のある領域を
アップグレード可能にしています。CPU は BIOS からの特殊な命令によって
少しバージョンを上げることができるのです。普通は使用しているマシンの
BIOS によってこのアップグレードがなされるので、特に SMP システムをお使いなら、
最新の BIOS になっているかどうかを確認してください。
-- Jeffrey Friedl (メールアドレスは非公開).
</para></listitem></itemizedlist>
</sect3>
</sect2>
<!--
<hr><h3>QUESTION</h3> 
RAM timing problems? I fiddled with the bios settings more than a 
month ago. I've compiled numerous kernels in the mean time and nothing
went wrong. It can't be the RAM timing. Right?
-->
<sect2 id="ramtiming">
<title>RAM のタイミングに問題なんてありえない、よね?</title>
<para>
<emphasis>質問</emphasis>
</para>
<para>
RAM のタイミングの問題だって?
1 ヶ月以上前に BIOS の設定をいじくった。
その間やまほどカーネルをコンパイルしたけど何もマズくなかった。RAM
のタイミングに問題なんてありえない、よね?
</para>
<!--
<h3>ANSWER</h3>
Wrong. Do you think that the RAM manufacturers have a machine that 
makes 60ns RAMs and another one that makes 70ns RAMs? Of course not!
They make a bunch, and then test them. Some meet the specs for 60 ns,
others don't. Those might be 61 ns if the manufacturer would have to
put a number to it. In that case it is quite likely that it works
in your computer when for example the temperature is below 40 degrees
centigrade (chips become slower when the temp rises. That's why some 
supercomputers need so much cooling).
-->
<para>
<emphasis>答え</emphasis>
</para>
<para>
ありえるよ。RAM 工場には 60ns の RAM を作る機械と 70ns の RAM
を作る機械が別々にあると思ってるの? そいつは違うね! 
いっしょくたに作って、それからテストするんだ。60ns
の規格に適合するものもあれば、そうでないものもある。
もし作り手がそいつにふさわしい数字を振らなくてはならないとしたら、61ns
が振られるものもあるかもしれない。
この場合、例えば 40 度以下の気温の時に、
君の愛機で動作するのはいかにもありそうなことだ。
(気温が上がると、チップの動作はのろくなる。
それがスーパーコンピュータをべらぼうに冷さなくてはならない訳)
</para>
<!--
However "the coming of summer" or a long compile job may push the 
temperature inside your computer over the "limit".
&#045;&#045; Philippe Troin (ptroin@compass-da.com)
-->
<para>
でも、「夏の到来」や長時間のコンパイル作業で、
コンピュータ内部の温度が「限界」を越えるまで上がることはありえるね。
-- Philippe Troin (ptroin@compass-da.com)
</para>
</sect2>
<!--
<hr><h3>QUESTION</h3> 
I got suckered into not buying ECC memory because it was slightly
cheaper. I feel like a fool. I should have bought the more expensive
ECC memory. Right?
-->
<sect2 id="ecc">
<title>ECC メモリを買ったほうがいい?</title>
<para>
<emphasis>質問</emphasis>
</para>
<para>
ちょっと安かったから、値段につられて ECC メモリじゃないやつを買っちゃった。
馬鹿みたい。高くても ECC にしとけばよかった。そうだよね?
</para>
<!--
<h3>ANSWER</h3>

Buying the more expensive ECC memory and motherboards protects you
against a certain type of errors: Those that occur randomly by passing
alpha particles.<br>

-->
<para>
<emphasis>答え</emphasis>
</para>
<para>
より高価な ECC メモリやマザーボードを買うと、
ある特定のタイプのエラーを防ぐことができます――
それはアルファ線の通過によってランダムに起こるエラーです。
</para>
<!--
Because most people can reproduce "signal 11" problems within half an
hour using "gcc" but cannot reproduce them by memory testing for hours
in a row, that proves to me that it is not simply a random alpha
particle flipping a bit. That would get noticed by the memory test
too. This means that something else is going on. 

-->
<para>
たいていのひとは gcc を使ってみると、
半時間以内に ``signal 11'' 問題を再現できますが、
いざメモリをテストしてみると、何時間続けても再現できません。
よって ``signal 11'' は、
単にアルファ線がいきあたりばったりにビットを反転させて起こるのではないことは明らかです。
アルファ線が原因なら、メモリテストでも再現できるでしょうから。
これは何か別のことが起きているのを意味しています。
</para>
<!--
 I have the impression that most sig11 problems are caused by
timing errors on the CPU <-> cache <-> memory path. ECC on your
main memory doesn't help you in that case.

-->
<para>
ほとんどの sig11 問題は、CPU ←→ cache ←→ memory
の経路でのタイミングエラーによって引き起こされる印象があります。
この場合、メインメモリの ECC は役に立ちません。
<!--
When should you buy ECC? a) When you feel you need it. b) When you
have LOTS of RAM. (Why not a cut-off number? Because the cut-off
changes with time, just like "LOTS".) Some people feel very strong
about everybody using ECC memory. I refer them to reason "a)".

-->
いつ ECC を買うべきか? a) 物欲がうずいた時。b)
たくさん RAM をもってる時。(なぜ最小限の数値を挙げないのかって? 
最小限は、時流によってまさに「たくさん」変化するものだから。)
誰もが ECC メモリを使ってると猛烈に思いこんでるひともいます。
そういうひとは ``a)'' の理由からです。
</para>
</sect2>
<!--
<hr><h3>QUESTION</h3> 
Memory problems? My BIOS tests my memory and tells me its ok. I have
this fancy DOS program that tells me my memory is OK. Can't be memory
right?
-->
<sect2 id="memorytest">
<title>メモリテストは信頼できる?</title>
<para>
<emphasis>質問</emphasis>
</para>
<para>
メモリの問題だって? BIOS のメモリテストは OK だ。
素敵な DOS のプログラムもメモリは OK だって言ってる。
メモリに問題なんてありえない、よね?
</para>
<!--
<h3>ANSWER</h3>
Wrong. The memory test in the BIOS is utterly useless. It may even
occasionally OK more memory than really is available, let alone test
whether it is good or not.<br>
-->
<para>
<emphasis>答え</emphasis>
</para>
<para>
ありえるよ。BIOS のメモリテストは全くの役立たずだ。
良いか悪いかテストするどころか、
実際に得られる以上のメモリがときたま
OK になることさえあるくらいだ。
</para>
<!--
A friend of mine used to have a 640k PC (yeah, this was a long time
ago) which had a single 64kbit chip instead of a 256kbit chip in the
second 256k bank. This means that he effectively had 320k working
memory. Sometimes the BIOS would test 384k as "OK". Anyway, only
certain applications would fail. It was very hardto diagnose the
actual problem....<br>
-->
<para>
640k PC をもってる友人がいた
(そう、640k PC でお分りの通り、昔々のお話)、
そいつの 2 つ目のバンクには、256kbit
チップの代りに 64kbit チップが 1 つささっていた。
実際には 320k のワーキングメモリがあったことになる。
時々、BIOS の 384k のテストが ``OK'' になることがあった。
にもかかわらず、特定のアプリケーションだけは落ちる。
実際の問題を診断するのは、ひどく骨が折れた....
</para>
<!--
Most memory problems only occur under special circumstances. Those
circumstances are hardly ever known. gcc Seems to exercise them.  Some
memory tests, especially BIOS memory tests, don't. I'm no longer
working on creating a floppy with a linux kernel and a good memory
tester on it. Forget about bugging me about it......<br>
-->
<para>
たいていのメモリの問題は、特殊な状況の下でしか起こりません。
そのような状況がどういうものであるのかは、
まだほとんど分らないのです。gcc
はどうもそういった特殊な状況を作り出す「みたい」です。
メモリテスト、特に BIOS のメモリテストはそうではありません。
筆者はもう、Linux
カーネルと優秀なメモリテスターを収録したフロッピーの作成サービスはやっていません。
その話は勘弁してください......
</para>
<!--
The reason is that a memory test causes the CPU to execute just a few
instructions, and the memory access patterns tend to be very
regular. Under these circumstances only a very small subset of the
memories breaks down. If you're studying Electrical Engineering and
are interested in memory testing, a masters thesis could be to figure
out what's going on. There are computer manufacturers that would want
to sponsor such a project with some hardware that clients claim to be
unreliable, but doesn't fail the production tests......
-->
<para>
その理由として、メモリテストだと、CPU
はほんのわずかな命令しか実行しないことと、
メモリアクセスのパターンが非常に規則的になりがちなことが挙げられます。
このような状況の下だと、
メモリのうちのほんのわずかな部分しか酷使されません。
もしあなたが電子技術を学んでいて、
メモリテストに興味がおありなら、
何が起きているのかを理解すれば修士論文が書けます。
顧客には信頼性がないと主張されているのに、
製造段階のテストでは落ちてくれないハードウェアに悩まされてる計算機メーカーが、
喜んでそのようなプロジェクトのスポンサーになってくれるでしょう......
</para>
</sect2>
<!--
<hr><h3>QUESTION</h3> 
Does it only happen when I compile a kernel?
-->
<sect2 id="compile">
<title>カーネルをコンパイルする時だけ起こるのですか?</title>
<para>
<emphasis>質問</emphasis>
</para>
<para>
カーネルをコンパイルする時だけ起こるのですか?
</para>
<!--
<h3>ANSWER</h3>

Nope. There is no way your hardware can know that you are compiling a
kernel.  It just so happens that a kernel compile is very tough on
your hardware, so it just happens a lot when you are compiling a
kernel. Compiling other large packages like gcc or glibc also often
trigger the sig11. 
<ul>
-->
<para>
<emphasis>答え</emphasis>
</para>
<para>
いいえ。ハードウェアには、
カーネルをコンパイルしてる最中なのかを知る術がありません。
カーネルのコンパイルは、
あいにくハードウェアにとってはとても骨が折れる仕事なのです。
それで、
カーネルをコンパイルしている時にだけたくさん起こるのです。
gcc や glibc のような大きなパッケージのコンパイルも、sig11
の引き金になることが多いです。
</para>
<itemizedlist>
<!--
<li> People have seen "random" crashes for example while installing
     using the slackware installation script.... &#045;&#045;
     dhn@pluto.njcc.com
-->
<listitem><para>
例えば、slackware
のインストールスクリプトを使ってインストールしている最中に、
「ランダム」にクラッシュするのを見たことがあるって話がある....
-- dhn@pluto.njcc.com
</para></listitem>
<!--
<li> Others get "general protection errors" from the kernel (with 
     the crashdump). These are usually in /var/adm/messages.
     &#045;&#045; fox@graphics.cs.nyu.edu
</ul>
-->
<listitem><para>
カーネルから、(クラッシュダンプといっしょに)
``general protection errors'' を受け取ることもある。
普通は
<filename class="directory">/var/adm/messages</filename>
に記録されているはず。
-- fox@graphics.cs.nyu.edu
</para></listitem>
<!--
<li> Some see <b>bzip2</b>crash with "signal 11" or with "internal
     assertion failure (#1007)." Bzip2 is pretty well-tested, so if it
     crashes, it's likely not a bug in bzip2. &#045;&#045; Julian Seward
     (jseward@acm.org)
-->
<listitem><para>
<command>bzip2</command> が ``signal 11'' や
``internal assertion failure (#1007)''
でクラッシュするのに出くわしたひともいる。
bzip2 はとてもよくテストされているので、
クラッシュしたとしても bzip2
自身のバグではなさそうだ。
-- Julian Seward (jseward@acm.org)
</para></listitem>
</itemizedlist>
</sect2>
<!--
<hr><h3>QUESTION</h3> 
Nothing crashes on NT, Windows 95, OS/2 or DOS. It must be something
Linux specific.
-->
<sect2 id="specific">
<title>Linux だけで起こるのですか?</title>
<para>
<emphasis>質問</emphasis>
</para>
<para>
NT, Windows 95, OS/2, DOS だと、何もクラッシュしません。
Linux 特有の何かに違いありません。
</para>
<!--
<h3>ANSWER</h3>
First of all, Linux stresses your hardware more than all of the above.
-->
<para>
<emphasis>答え</emphasis>
</para>
<para>
まず第一に、Linux は上記のどの OS よりもハードウェアを酷使します。
<!--
Some OSes like the Microsoft ones named above crash in unpredictable
ways anyway. Nobody is going to call Microsoft and say "hey, my
windows box crashed today". If you do anyway, they will tell you that
you, the user, made an error (see 
<a href="http://www.cantrip.org/nobugs.html">the interview with Bill
Gates</a> in a German magazine....) and that since it works now, you
should shut up.<br>
-->
上に挙げたマイクロソフト製のような OS の中には、
とにかくいつクラッシュするかまったく予測がつかないものがあります。
マイクロソフトに電話して、
「おい、今日ウインドウズが落ちたぞ」
なんて言うひとはひとりもいないでしょう。
とにかくもしあなたがそういう行動に出たとしても、
相手は、ユーザーであるあなたがエラーを起こしたんだ
(ドイツの雑誌に掲載された
<ulink    
url="http://www.cantrip.org/nobugs.html">
http://www.cantrip.org/nobugs.html</ulink>
を見てね....)
(訳注: 日本語訳は
<ulink    
url="http://www.unixuser.org/~euske/doc/nobugs-ja/">
http://www.unixuser.org/~euske/doc/nobugs-ja/</ulink>
にあります)
今はちゃんと動作しているのだから、口をつぐむべきだ、
などとほざくでしょう。
</para>
<!--
Those OSes are also somewhat more "predictable" than Linux. This means
that Excel might always be loaded in the exact same memory area.
Therefore when the bit-error occurs, it is always excel that gets
it. Excel will crash.  Or excel will crash another application. Anyway,
it will seem to be a single application that fails, and not related to
memory.<br>
-->
<para>
これらの OS には、Linux より「予測可能な」ところもあります。
エクセルは、いつもきっちり同じメモリ領域にロードされるはず、
という意味です。
したがってこの場合、
ビットエラーが起こった時に影響を受けるのは常にエクセルになります。
エクセルはクラッシュするでしょう。もしくは、
エクセルがほかのアプリケーションをクラッシュさせるでしょう。
とにかく、落ちるのは単なるアプリケーションで、
メモリとは関係ないように思われるでしょう。
</para>
<!--
What I am sure of is that a cleanly installed Linux system should be
able to compile the kernel without any errors. Certainly no sig-11
ones. (** Exception: Red Hat 5.0 with a Cyrix processor. See
elsewhere. **) <br>
-->
<para>
きっちりインストールされた Linux システムなら、
エラーを起こさずにカーネルをコンパイルできるはずだと確信してます。
間違いなく、sig11 は起こりません。
(** 例外――Cyrix プロセッサでの Red Hat 5.0。別のところを見てね。
**)
</para>
<!--
Really Linux and gcc stress your hardware more than other OSes. If you
need a non-linux thingy that stresses your hardware to the point
of crashing, you can try winstone. &#045;&#045; Jonathan Bright (bright@informix.com)
-->
<!-- <p> 追加 -->
<para>
実際のところ、Linux と gcc はほかの OS 以上にハードウェアを酷使します。
もし Linux 以外で、
クラッシュするところまでハードウェアを酷使するものが必要なら、
<application>winstone</application>
を試してみるのが吉。
-- Jonathan Bright (bright@informix.com)
</para>
</sect2>
<!--
<hr><h3>QUESTION</h3> 
Is it always signal 11?
-->
<sect2 id="always">
<title>いつも signal 11 なの?</title>
<para>
<emphasis>質問</emphasis>
</para>
<para>
いつも signal 11 なの?
</para>
<!--
<h3>ANSWER</h3>

Nope. Other signals like four, six and seven also occur occasionally.
Signal 11 is most common though.
<p>
-->
<para>
<emphasis>答え</emphasis>
</para>
<para>
いいえ。4, 6, 7 のようなほかのシグナルも、ときたま発生します。
でも、signal 11 が最もありふれています。
</para>
<!--
As long as memory is getting corrupted, anything can happen. I'd
expect bad binaries to occur much more often than they really
do. Anyway, it seems that the odds are heavily biased towards gcc
getting a signal 11. Also seen:
-->
<para>
メモリに記憶された情報がいかれてしまっている時なら、
何が起こってもおかしくありません。
バイナリの異常がもっと頻発しても不思議はないくらいです。
にもかかわらず、いつも gcc が signal 11
を受け取るものだと決めつけるのはかなりの偏見のように思われます。
以下の現象も見られます:
</para>
<!--
<ul>
<li> free_one_pmd: bad directory entry 00000008
<li> EXT2-fs warning (device 08:14): ext_2_free_blocks bit already
     cleared for block 127916
<li> Internal error: bad swap device
<li> Trying to free nonexistent swap-page
<li> kfree of non-kmalloced memory ...
<li> scsi0: REQ before WAIT DISCONNECT IID
<li> Unable to handle kernel NULL pointer dereference at virtual
     address c0000004 
<li> put_page: page already exists 00000046 <br>
     invalid operand: 0000
<li> Whee.. inode changed from under us. Tell Linus
<li> crc error  &#045;&#045;  System halted  (During the uncompress of the Linux kernel)
<li> Segmentation fault
<li> "unable to resolve symbol" 
<li> make [1]: *** [sub_dirs] Error 139 <br>
     make: *** [linuxsubdirs] Error 1  <br>
<li> The X Window system can terminate with a "caught signal xx"
</ul>
-->
<itemizedlist>
<listitem><screen>
free_one_pmd: bad directory entry 00000008
</screen></listitem>
<listitem><screen>
EXT2-fs warning (device 08:14): ext_2_free_blocks bit already
cleared for block 127916
</screen></listitem>
<listitem><screen>
Internal error: bad swap device
</screen></listitem>
<listitem><screen>
Trying to free nonexistent swap-page
</screen></listitem>
<listitem><screen>
kfree of non-kmalloced memory ...
</screen></listitem>
<listitem><screen>
scsi0: REQ before WAIT DISCONNECT IID
</screen></listitem>
<listitem><screen>
Unable to handle kernel NULL pointer dereference at virtual
address c0000004 
</screen></listitem>
<listitem><screen>
put_page: page already exists 00000046 
invalid operand: 0000
</screen></listitem>
<listitem><screen>
Whee.. inode changed from under us. Tell Linus
</screen></listitem>
<listitem><screen>
crc error -- System halted  (During the uncompress of the Linux kernel)
</screen></listitem>
<listitem><screen>
Segmentation fault
</screen></listitem>
<listitem><screen>
"unable to resolve symbol" 
</screen></listitem>
<listitem><screen>
make [1]: *** [sub_dirs] Error 139
make: *** [linuxsubdirs] Error 1
</screen></listitem>
<listitem><screen>
The X Window system can terminate with a "caught signal xx"
</screen></listitem>
</itemizedlist>
<!--
The first few ones are cases where the kernel "suspects" a
kernel-programming-error that is actually caused by the bad memory.
The last few point to application programs that end up with the
trouble. <p>

&#045;&#045; S.G.de Marinis (trance@interseg.it) <br>
&#045;&#045; Dirk Nachtmann (nachtman@kogs.informatik.uni-hamburg.de)
<br> 
-->
<para>
最初のほうは、カーネルが、
実際にはメモリの間違った記憶によって引き起こされたものを、
「カーネルのプログラミングエラー」と「勘違いする」ケースです。
最後のほうは、
アプリケーションプログラムがこのトラブルによって終了してしまったところです。
</para>
<para>
-- S.G.de Marinis (trance@interseg.it)
-- Dirk Nachtmann (nachtman@kogs.informatik.uni-hamburg.de)
</para>
</sect2>
<!--
<hr><h3>QUESTION</h3>
What do I do?
-->
<sect2 id="whatdoido">
<title>何をすればいいの?</title>
<para>
<emphasis>質問</emphasis>
</para>
<para>
何をすればいいの?
</para>
<!--
<h3>ANSWER</h3>
Here are some things to try when you want to find out what is wrong...
note: Some of these will significantly slow your computer down. These
things are intended to get your computer to function properly and allow
you to narrow down what's wrong with it. With this information you
can for example try to get the faulty component replaced by your vendor. 
-->
<para>
<emphasis>答え</emphasis>
</para>
<para>
何が悪いのかをつきとめたい場合は、以下のことを試してみましょう...
注――これらの中には、
コンピュータを著しく遅くするおそれのあるものもあります。
これらの狙いは、コンピュータをきちんと動作させ、
どこが悪いのかを絞りこんでいくことです。
情報を得られれば、
例えばベンダーに故障箇所を交換してもらうことができます。
</para>
<!--
<ul>

<li> Jumper the motherboard for lower CPU and bus speed.
-->
<itemizedlist>
<listitem><para>
マザーボードのジャンパを、
より低い CPU やバスの速度に切り変える。
</para></listitem>
<!--
<li> Go into the BIOS and tell it "Load BIOS defaults". Make sure you
     write the disk drive settings down beforehand. 
-->
<listitem><para>
BIOS の画面で、''Load BIOS defaults'' を選択する。
かならず、前もってディスクドライブの設定を控えておいてください。
</para></listitem>
<!--
<li> Disable the cache (BIOS) (or pull it out if it's on a "stick").
-->
<listitem><para>
(BIOS で) キャッシュを無効にする (スロットタイプなら、引き抜く)。
</para></listitem>
<!--
<li> boot kernel with "linux mem=4M" (disables memory above 4Mb).
-->
<listitem><para>
<command><option>linux mem=4M</option></command>
のオプションで、カーネルを起動する
(4MB 以上を無効にする)。
</para></listitem>
<!--
<li> Try taking out half the memory. Try both halves in turn.
-->
<listitem><para>
メモリの半分を取り外してみる。かわりばんこに試す。
</para></listitem>
<!--
<li> Fiddle with settings of the refresh (BIOS)
-->
<listitem><para>
リフレッシュの設定をいじくる (BIOS)。
</para></listitem>
<!--
<li> Try borrowing memory from someone else. Preferably this should be 
memory that runs Linux flawlessly in the other machine... (Silicon
graphics Indy machines are also nice targets to borrow memory from)
-->
<listitem><para>
ほかの誰かからメモリを借りてみる。なるべく、
ほかのマシンで Linux が完璧に動くメモリにすべきです...
(シリコングラフィックスの Indy もメモリを借用する恰好のターゲットです)
</para></listitem>
<!--
<li>If you want to verify if a solution really works try the following
script:
<pre>
   #!/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
</pre>
-->
<listitem><para>
もし、本当に解決したかどうか確かめたいなら、
次のスクリプトを試してみよう:
</para>
<programlisting>
<![CDATA[
   #!/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
]]>
</programlisting>
<!--
All the resulting logfiles should be the same (i.e. the same size, and
the same contents). Every kernel build takes around 4 minutes on a
1GHz Athlon with 512Mb of memory.  (and about 3 months on a 386 with
4Mb :-).
</ul>
-->
<para>
生成されたすべてのログファイルが同一(同じサイズで同じ内容)
であれば正常です。
ひとつひとつのカーネルをビルドするのに、メモリ 512MB で 1GHz Athlon だと
4 分前後かかります。
(4MB で 386 だと約 3 ヶ月 :-)
</para></listitem>
<!--
<li> Another way to test if your current setup is stable might be to
run "md5sum" on files of different sizes (dd if=/dev/random
of=testfile bs=1024k count=<megs>). If you use a file twice the size
of your RAM, you'll be exercising your disk. If you use a file 4 to
10 Mb smaller than your RAM, you'll excercise your RAM/CPU. <br>
-->
<listitem><para>
現在のハードウェア環境が安定しているかどうかをテストするもう
1 つの方法があります――
様々なサイズのファイルの <command>md5sum</command>
を計算させるのが有効かもしれません
(ファイルの作りかたは
<command>dd <option>if=/dev/random</option> <option>of=</option>
<replaceable>testfile</replaceable> <option>bs=1024k</option> <option>count=</option><replaceable>&lt;megs&gt;</replaceable></command>)。RAM
の 2 倍のサイズのファイルを用いれば、ディスクが酷使されるでしょう。
また、RAM より 4MB から 10MB 小さいファイルを用いれば、RAM と CPU
が酷使されるでしょう。
</para>
<!--
Whether
this method catches all possible problems, however, is uncertain.  Gcc
executes lots of different instructions in different orders, and
md5sum might simply not hit the right sequence of instructions that
gcc does. But if md5sum leads to errors, it might do so quicker than a
kernel compile. &#045;&#045; Rob Ludwick (rob@no-spam)


</ul>
-->
<para>
しかしながらこの方法で、
ありうる限りの問題が発見されるかどうかははっきりしません。gcc
はたくさんの異なった命令を様々な順序で実行するものなので、
単に md5sum が実行する命令の順序が、gcc
が実行する命令の順序とはきっちり一致しないかもしれないからです。
でも、md5sum がエラーをもたらせば、
カーネルコンパイルよりも問題が検出されるのがずっと速いかもしれません。
-- Rob Ludwick (rob@no-spam)
</para></listitem></itemizedlist>
<!--
The hardest part is that most people will be able to do all of the
above except borrowing memory from someone else, and it doesn't make a
difference. This makes it likely that it really is the RAM. Currently
RAM is the most pricy part of a PC, so you rather not have this
conclusion, but I'm sorry, I get lots of reactions that in the end
turn out to be the RAM. However don't despair just yet: your RAM may
not be completely wasted: you can always try to trade it in for different
or more RAM.
-->
<para>
上に挙げた手段のうち、
メモリの借用だけは試せないというひとがほとんどでしょうが、
やれるだけのことをやっても変化が見られないとなると、
きわめてやっかいです。
この場合は、本当に RAM そのものが原因だと言えそうなのです。
目下、RAM は PC の最も高価なパーツなので、
こんな結論であって欲しくはないでしょう。
でも残念ながら、
結局 RAM のせいだと判明したとの返事をたくさんもらってます。
でもまだまだあきらめないで――RAM
は全くのゴミではないかもしれない――
いつでも下取りに出して別の、
もしくはより多くの RAM を買うことができます。
</para>
</sect2>
<!--
<hr><h3>QUESTION</h3> 
I had my RAMs tested in a RAM-tester device, and they are OK. Can't be the 
RAM right?
-->
<sect2 id="ramtester">
<title>RAM テスターって信頼できる?</title>
<para>
<emphasis>質問</emphasis>
</para>
<para>
RAM テスターの機械でうちの RAM をテストしたことがある。
結果は OK だった。RAM に問題なんてありえない、よね?
</para>
<!--
<h3>ANSWER</h3>
Wrong. It seems that the errors that are currently occurring in RAMS are
not detectable by RAM-testers. It might be that your motherboard is 
accessing the RAMs in dubious ways or otherwise messing up the RAM 
while it is in YOUR computer. The advantage is that you can sell your
RAM to someone who still has confidence in his RAM-tester......
-->
<para>
<emphasis>答え</emphasis>
</para>
<para>
ありえます。RAM の中で今まさに起こっているエラーは、RAM
テスターでは検出できないように思われます。
「あなたの」コンピュータでは、
マザーボードがあやしいやりかたで RAM をアクセスしているか、
さもなくば RAM を混乱させているかもしれないからです。
この場合の利点は、
いまだに RAM テスターを信頼してる誰かさんに
RAM を売りつけてやれることです......
</para>
</sect2>
<!--
<hr><h3>QUESTION</h3> 
Why is the Red Hat install bombing on me?
-->
<sect2 id="redhat">
<title>Red Hat のインストールがうまくいかないのはなぜ?</title>
<para>
<emphasis>質問</emphasis>
</para>
<para>
うちで Red Hat のインストールが玉砕するのはなぜ?
</para>
<!--
<h3>ANSWER</h3>
The Red Hat 5.x, 6.x and 7.x install has problems on some machines.
Try running the install wiht only 32M. This can usually be done with
mem=32m as a boot parameter.<p>
-->
<para>
<emphasis>答え</emphasis>
</para>
<para>
マシンによっては、Red Hat 5.x, 6.x, 7.x
のインストールには問題がいくつかあります。
32M しかメモリを認識していない状態でのインストールを試してみましょう。
普通、ブートパラメーターに mem=32m を指定すれば可能です。
</para>
<!--
People report, and I've seen with my own eyes, that Red Hat installs
can go wrong (crash with signal 7 or signal 11) on machines that are
perfectly in order. My machine was and still is 100%  reliable
(actually the machine I tested this on, is now reliably dead).
People are getting into trouble by wiping the old "working just fine"
distribution, and then wanting to install a more recent Red Hat
distribution. Going back is then no longer an option, because going
back to 5.x also results in the same "crashes while installing". 
-->
<para>
Red Hat のインストールが、完璧な状態のマシンでうまくいかない
(signal 7 もしくは signal 11 でクラッシュする)
ことがあるとの報告をもらいましたし、
筆者もこの目でしかと見たことがあります。
使っているマシンは昔も今も 100% 信頼がおけるものです。
(実際、テストに用いたそのマシンは、今でも完全に信頼できます)。
みんな、旧式の「ちゃんと動く」ディストリビューションを捨てて、
トラブルに巻き込まれていきます。そのうえに、
もっと新しいバージョンの Red Hat をインストールしたがるのです。
さらにまた古いバージョンに戻すことは、もはや選択できません。
なぜなら、5.x に戻したところで、
結果として同じ「インストール中のクラッシュ」に見舞われるからです。
</para>
<!--
<p>
Patrick Haley (haleyp@austin.rr.com) reports that he tried all memory
configurations up to 96Mb (32 & 64) and found that only when he had
96Mb installed, the install would work. This is also consistent with
my own experience (of Red Hat installs failing): I tried the install
on a 32M machine.
-->
<para>
Patrick Haley (haleyp@austin.rr.com) は、96MB (32 &amp; 64)
を上限として、あらゆるパターンでメモリを装着してみたところ、96MB
載せた時だけはきちんとインストールできるのが分ったと報告してくれました。
これは、筆者自身の (Red Hat のインストールに失敗した) 経験とも一致します――
筆者の場合は、32MB のマシンにインストールしようとして失敗したのです。
</para>
<!--
<p>
NEW: It seems that this may be due to a kernel problem. The kernel may
(temporarliy) run low on memory and kill the current process. The fix by
Hubert Mantel (mantel@suse.de) is at: 
<a href="http://juanjox.linuxhq.com/patch/20-p0459.html">
         http://juanjox.linuxhq.com/patch/20-p0459.html</a>.
-->
<para>
最新情報――カーネルに問題があるせいかもしれないみたいです。
カーネルが、(一時的に) メモリ不足におちいって、
カレントプロセスを kill するのかもしれません。
Hubert Mantel (mantel@suse.de) によるパッチが
<ulink    
url="http://juanjox.linuxhq.com/patch/20-p0459.html">
http://juanjox.linuxhq.com/patch/20-p0459.html</ulink>
で入手できます。
</para>
<!--
<p>
If this is actually the case, try switching to the second virtual
console (ctrl-alt-F2) and type "sync" there every few seconds. This
reduces the amount of memory taken by harddisk-buffers...  I would
really appreciate hearing from you if you've seen the Red Hat install
crash two or more times in a row, and then were able to finish the
install using this trick!!!
-->
<para>
実際、このケースにあてはまるのなら、2 つ目の仮想コンソールに切り替えて
(<command>ctrl-alt-F2</command> を押す)、そこで
2, 3 秒ごとに <command>sync</command> と打つのを試してみてください。
これをやると、
ハードディスクバッファとして割り当てられたメモリの量が切り詰められます...
Red Hat のインストールが 2 度 3 度と続けてクラッシュした際に、
このトリックを用いることでインストールを完了できたという方は、
ぜひご一報ください!!!
</para>
<!--
<p>
It could be that there is a read-error on the CD. The installer handles
this less-than-perfect.....
-->
<para>
CD に読み取りエラーがあるのかもしれません。
この場合、インストーラーの処理は完璧にはほど遠いです.....
</para>
<!--
<p>
What do you do to get around this problem?...
-->
<para>
この問題から逃れるには何をしたらいいのかって?...
</para>
<!--
<ul>
<li> Use SuSE. It's better: It doesn't crash during the
installation. (Moreover, it actually <b>is</b> better. ;-)
-->
<itemizedlist>
<listitem><para>SuSE を使う。こいつはベターだ――
インストールの間クラッシュしない。
(おまけに、ディストリビューションとしてのできもベター。;-)
</para></listitem>
<!--
<li> Maybe you're running into a bad-block on your CD. This can be
drive-dependent. If that's the case, try making a copy of the CD in
another drive. Try borrowing someone elses copy of Red Hat.
-->
<listitem><para>
ひょっとして、
お使いの CD に不良ブロックがあるなんて事態に遭遇してるのかも。
ドライブによってはありえる話です。
このケースにあてはまるなら、
試しに別のドライブでその CD のコピーを作成してみましょう。
それか、誰かの Red Hat を借りてきて試してみましょう。
</para></listitem>
<!--
<li> Try configuring a GIGABYTE of swap. I have two independent reports
that report that they got through with a gig of swap. Please report to me
if it helps!
-->
<listitem><para>1 ギガバイトものスワップを設定してみる。
1 ギガバイトのスワップを作ったらうまくいったと、
ふたりの方が報告してくれました。
このやりかたが役に立ったら著者までご一報ください!
</para></listitem>
<!--
<li> Modify the "settings" for the harddisk. Changing the setting from
"LBA" to "NORMAL" in the bios has helped for at least one person. If
you try this, I'd really appreciate it if you'd <a
href="mailto:r.e.wolff@BitWizard.nl">EMail me</a>: I would like to hear
from you if it helps or not. (and what you exactly changed to get it
to work)
-->
<listitem><para>ハードディスクの「設定」を変更する。BIOS での設定を
``LBA'' から ``NORMAL'' に変えたことによって、
少なくともひとりの方が救われています。
もしこれを試したなら、R.E.Wolff@BitWizard.nl
にメールをいただけると本当にありがたいです――
このやりかたが有効なのかどうか、あなたから聞きたいのです。
(正確に、何をやったらきちんと動くようになったのか、も)
</para></listitem>
<!--
<li> I got <b>my</b> machine to install by installing a minimal base
system, and then adding packages to the installed system. 
-->
<listitem><para>まず最低限の基本システムをインストールして、
それからそこにパッケージを追加インストールするやりかたで、
「筆者の」マシンにはインストールできました。
</para></listitem>
<!--
<li> Someone suggested that the machine might be out-of-memory when
this happens. Try having a swap partition ready. Also, the install may
be "prepared" to handle low mem situations, but misjudging the
situation.  For example, it may load a RAMDISK, leaving just 1M of
free RAM, and then trying to load a 2M application. So if you have 16M
of RAM, booting with mem=14M may actually help, as the "load RAMDISK"
stage would then fail and the install would then know to run off the
CD instead of off the RAMDISK. (installs used to work for >8M
machines. Is that still true?)
-->
<listitem><para>この現象が起きる時、
マシンがメモリを使いきっているのかもしれない、と言ってくれた方がいました。
スワップパーティションの設定がすでになされた状態で試してみましょう。
また、たぶん少ないメモリの環境でもインストールできるような機能が
「用意」されているのにもかかわらず、
インストーラーが状況の判断を誤っているのかもしれません。
例えば、ちょうど 1M しか空きの RAM が残ってない状態で、
さらに 2M のアプリケーションを RAMDISK にロードしようとしたのかもしれません。
よって、もし RAM が 16M なら、<command><option>mem=14M</option></command>
のオプションでブートすると、実際に効果があるかもしれません、
というのは、それから「RAMDISK にロードする」段階で失敗して、
それ以降は RAMDISK の代りに CD
からインストールするようになるであろうからです。
(昔はメモリが 8M のマシンにもインストールできたけど、
今でもいけるかな?)
</para></listitem>
<!--
<li> Try, in one session to clear the disk of all the partitions that
are going to be used by Linux. Reboot. Then try the install. Either by
partitioning manually, or by letting the install program figure it out. 
(I take it that Red Hat has that possibility too, SuSE has it...)
If this works for you, I'd appreciate it if you'd tell me. 
-->
<listitem><para>一度、
Linux で使う予定があるすべてのパーティションをディスクから消去して、
リブートして、それからインストールしてみる、
というのを試してみましょう。手動でパーティションを切るか、
インストールプログラムに計算させるか、どちらかの手段で。
(Red Hat にもこういった選択肢はあると思います。SuSE
にはありますから...)
もしこれで動作するようになったら、報告してもらえるとありがたいです。
</para></listitem>
<!--
<li> A corrupted download can also cause this. Duh.
-->
<listitem><para>ダウンロードの過程で壊れちゃった場合でも起きる。はあ。
</para></listitem>
<!--
<li> Someone reports that installs on 8Mb machines no longer work, and
that the install ungracefully exits with a sig7. &#045;&#045; Chris Rocco
(crocco@earthlink.net)
-->
<listitem><para>もはや 8MB のマシンにはインストールできない、
しかも sig7 でぶざまに終了する、との報告がありました。
-- Chris Rocco (crocco@earthlink.net)
</para></listitem>
<!--
<li> One person reports that disabling "BIOS shadow" (system & VIDEO),
helped for him. As Linux doesn't use the BIOS, shadowing it doesn't
help.  Some computers may even give you 384k of extra RAM if you
disable the shadowing. Just disable it, and see what happens. &#045;&#045;
Philippe d'Offay (pdoffay@pmdsoft.com).
</ul>
-->
<listitem><para>``BIOS shadow'' (system と VIDEO の両方)
を無効にすることが助けになったと、
ひとりの方が報告してくれました。Linux
は BIOS を使わないので、shadow を有効にしても役に立ちません。
コンピュータの中には、shadow を無効にすると、
おまけに 384k も RAM が増えるかもしれないものもあります。
無効にして、何が起こるか見てみましょう。
-- Philippe d'Offay (pdoffay@pmdsoft.com).
</para></listitem>
</itemizedlist>
</sect2>
<!--
<hr><h3>QUESTION</h3> 
What are other possibilities?
-->
<sect2 id="other">
<title>ほかにはどんな可能性があるだろう?</title>
<para>
<emphasis>質問</emphasis>
</para>
<para>
ほかにはどんな可能性があるだろう?
</para>
<!--
<h3>ANSWER</h3>
Others have noted the following possibilities:
-->
<para>
<emphasis>答え</emphasis>
</para>
<para>
ほかには、以下に挙げた可能性が記録されています:
</para>
<!--
<ul>
<li>The compiler and libc included in Red Hat 5.0 have an odd
    interaction with the Cyrix processor. It crashes the compiler,
    This is VERY odd. I would think that the only way
    that this can be the case is when the Cyrix has a bug that has
    gone undetected all this time, and reliably gets triggered 
    when THAT gcc compiles the Linux kernel. Anyway, if you just want
    compile a kernel, you should get a new compiler and/or libc from 
    the Red Hat website. (start at the homepage, and click errata). 
-->
<itemizedlist>
<listitem><para>Red Hat 5.0 に含まれているコンパイラと libc は、Cyrix
のプロセッサとは妙に相性が悪いです。
コンパイラがクラッシュするし、こいつは「非常に」奇妙です。
仮にこれが事実だとしたら、Cyrix には現時点で未検出のバグがあり、
「その」 gcc が Linux
カーネルをコンパイルする時にきっちり引き金を引く、
としか考えられません。
とにかくカーネルをコンパイルしたいだけなら、Red Hat
のウェブサイトから、新しいコンパイラと
libc のいずれか、もしくは両方をゲットすべきです。
(トップページで errata をクリック)
</para></listitem>
<!--
<li>Compiling a 2.0.x kernel with a 2.8.x gcc or any egcs doesn't work. 
    There are a few bugs in the kernel that don't show up because 
    gcc 2.7.x does a lousy job optimizing it. gcc 2.8.x and egcs just
    dump some of the code because we didn't tell it not to. Anyway,
    you usually get a kernel that seems to work but has funny bugs.
    For example X may crash with a signal 11. Oh, and before you
    ask, no it's not going to be fixed. Don't bother Alan or Linus
    about this OK? &#045;&#045; Hans Peter Verne (h.p.verne@kjemi.uio.no)
-->
<listitem><para>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)
</para></listitem>
<!--
<li>The pentium-optimizing-gcc (the one with the version number ending
    in "p") fails with the default options on certain source files 
    like floppy.c in the kernel. The "triggers" are in the kernel, libc and
    in gcc itself. This is easily diagnosed as "not a hardware
    problem" because it always happens in the same place. You can
    either disable some optimizations (try -fno-unroll-loops first) or
    use another gcc.  &#045;&#045; Evan Cheng (evan@top.cis.syr.edu)
    (In other words: gcc 2.7.2p crashes with sig11 on floppy.c .  
    Workaround-1: Use plain gcc. Workaround-2: Manually compile
    floppy.c with "-O" instead of "-O2". )
-->
<listitem><para>ペンティアムに最適化された gcc (バージョン番号のおわりが
``p'' のもの) は、デフォルトのオプションだと
<filename>floppy.c</filename>
のような特定のソースファイルのコンパイルに失敗します。
「引き金」は、カーネル、libc、gcc 自身にあります。
この場合は、単純に「ハードウェアの問題ではない」と診断できます。
なぜなら、いつも同じ箇所で起こるからです。
いくつかの最適化を無効にする
(最初に <command><option>-fno-unroll-loops</option></command> を試してみて) か、
ほかの gcc を使うか、のいずれかをやってみるとよいです。
-- Evan Cheng (evan@top.cis.syr.edu)
(言い換えると――gcc 2.7.2p は、<filename>floppy.c</filename>
のコンパイルの際に sig11 でクラッシュします。
回避策その 1――素の gcc を使う。
回避策その 2――<filename>floppy.c</filename> を 
<command><option>-O2</option></command> の代りに
<command><option>-O</option></command>
のオプションで手動コンパイルする。)
</para></listitem>
<!--
<li>A bad connection between a disk and the system. For example IDE
    cables are only allowed to be 40cm (16") long. Many systems come
    with longer cables. Also a removable IDE rack may add enough
    trouble to crash a system. 
-->
<!-- " ← for global-font-lock -->
<listitem><para>ディスクとシステムの間の接続が不良。
例えば、IDE ケーブルは 40cm (16 インチ)
の長さまでしか許されていないのに、
もっと長いケーブルを付けて出荷されるシステムが多いです。
取り外し可能な IDE ラックも、
システムをクラッシュさせるのに十分なトラブルの要因になるかもしれません。
</para></listitem>
<!--
<li>A badly misconfigured gcc &#045;&#045; some parts from one version, some
    from another.  After a few weeks I ended up re-installing from
    scratch to get everything right.  &#045;&#045; Richard H. Derr III
    (rhd@Mars.mcs.com).
-->
<listitem><para>めちゃくちゃに設定された gcc -- あるバージョンの部分があり、
別のバージョンの部分もあるもの。2, 3 週間後、
すべてまともになるようにいちからインストールし直して、
けりをつけた。
-- Richard H. Derr III (rhd@Mars.mcs.com).
</para></listitem>
<!--
<li>Gcc or the resulting application may terminate with sig11 when a
    program is linked against the SCO libraries (which come with
    iBCS). This occurs on some applications that have -L/lib in their
    LDFLAGS....
-->
<listitem><para>プログラムが SCO のライブラリ (iBCS についてくる)
にリンクされている場合、gcc や、gcc
でコンパイルされたアプリケーションは
sig11 で終了するかもしれません。
<command><option>LDFLAGS</option></command>
に <command><option>-L/lib</option></command>
を指定したアプリケーションの中には、
この現象が起きるものがあります....
</para></listitem>
<!--
<li>When compiling a kernel with an ELF compiler, but configured for
    a.out (or the other way around, I forgot) you will get a signal 11
    on the first call to "ld". This is easily identified as a software
    problem, as it always occurs on the FIRST call to "ld" during the
    build. &#045;&#045; REW
-->
<listitem><para>ELF
形式のバイナリを生成するコンパイラでカーネルをコンパイルしているのに、a.out
に設定しちゃった場合 (逆だったかな) ld
を最初に呼ぶところで signal 11 に出くわすでしょう。
この場合はソフトウェアの問題だと容易に見きわめられます。
なぜなら、ビルドの間「最初に」 ld
を呼ぶところでいつも起きるからです。
-- REW
</para></listitem>
<!--
<li>An Ethernet card together with a badly configured PCI BIOS.  If
    your (ISA) Ethernet card has an aperture on the ISA bus, you might
    need to configure it somewhere in the BIOS setup screens.
    Otherwise the hardware would look on the PCI bus for the shared
    memory area. As the ISA card can't react to the requests on the
    PCI bus, you are reading empty "air". This can result in
    segmentation faults and kernel crashes. &#045;&#045; REW
-->
<listitem><para>間違って設定された PCI BIOS
とイーサネットカードとの組み合わせ。もしお使いの
イーサネットカードが ISA バスのスロット用なら、BIOS
のセットアップ画面のどこかを設定する必要があるかもしれません。
さもなくば、ハードウェアは PCI
バスにシェアードメモリの領域を探しに行くでしょう。ISA
のカードは PCI バスのリクエストに反応できないので、
からっぽの「空気」を読んでしまっていることになります。
その結果、segmentation fault
したりカーネルがクラッシュしたりすることがあります。
-- REW
</para></listitem>
<!--
<li>Corrupted swap partition. Tony Nugent (T.Nugent@sct.gu.edu.au)
    reports he used to have this problem and solved it by an mkswap on
    his swap partition. (Don't forget to type "sync" before doing
    anything else after an mkswap. &#045;&#045; Louis J. LaBash Jr.  
    (lou@minuet.siue.edu))
-->
<listitem><para>壊れちゃったスワップパーティション。
Tony Nugent (T.Nugent@sct.gu.edu.au)
は、かつてこの問題を、スワップパーティションを
<command>mkswap</command>
し直すことで解決したことがあると報告してくれました。
(<command>mkswap</command> した後、なにかやる前に <command>sync</command>
するのを忘れないで。
-- Louis J. LaBash Jr.(lou@minuet.siue.edu))
</para></listitem>
<!--
<li>NE2000 card. Some cheap Ne2000 cards might mess up the system. &#045;&#045;
    Danny ter Haar (dth@cistron.nl) I personally might have had
    similar problems, as my mail server crashed hard every now and
    then (once a day). It now seems that 1.2.13 and lots of the 1.3.x
    kernels have this bug. I haven't seen it in 1.3.48. Probably got
    fixed somewhere in the meantime.... &#045;&#045; REW
-->
<listitem><para>NE2000 互換のカード。安物の NE2000 互換カードの中には、
システムを混乱させる可能性のあるものがあります。
-- Danny ter Haar (dth@cistron.nl)
</para><para>
筆者はかつて個人的によく似た問題を抱えていたことがあるかもしれません、
というのは、メールサーバーが時々 (1 日に 1 回程度)
ひどくクラッシュした経験があるのです。
今思えば、1.2.13 や、1.3.x
カーネルの多くにはこのバグがあったみたいです。1.3.48
では見られませんでした。
たぶん、その間のどこかで修復されたのでしょう....
-- REW
</para></listitem>
<!--
<li>Power supply? No I don't think so. A modern heavy system with two
    or three harddisk, both SCSI and IDE will not exceed 120 Watts or
    so.  If you have loads of old harddisks and old expansion cards
    the power requirements will be higher, but still it is very hard
    to reach the limits of the power supply. Of course some people
    manage to find loads of old full-size harddisks and install them
    into their big-tower. You can indeed overload a powersupply that 
    way. &#045;&#045; Greg Nicholson (greg@job.cba.ua.edu)
    A faulty power supply CAN of course deliver marginal power, which
    causes all of the malfunctioning that you read about in this file....
    &#045;&#045; Thorsten Kuehnemann (thorsten@actis.de)
-->
<listitem><para>電源? いいや、それが原因だとは思えないな。SCSI
と IDE
の両方に 2 つか 3 つのハードディスクがあるいまどきの重装備システムでも、120
ワットかそこらを超えることはないでしょう。
もし旧式のハードディスクや旧式の拡張カードをどっさりおもちなら、
さらにたくさんの電力が必要になるでしょうが、
電力供給の限界に達するにはまだまだです。
もちろん、首尾よく古いフルサイズのハードディスクをやまほど見つけて、
でかいタワーケースに組み込む方もいらっしゃいます。
実際、それだと電源の過負荷になることがありえます。
-- Greg Nicholson (greg@job.cba.ua.edu)
</para><para>
いかれた電源は、もちろんぎりぎりの電力を送る「可能性」があります。
その場合、この文書に書いてあるすべての障害を引き起こします。
-- Thorsten Kuehnemann (thorsten@actis.de)
</para></listitem>
<!--
<li>An inconsistent ext2fs. Some circumstances can cause the kernel
    code of the ext2 file system to result in Signal 11 for Gcc. 
    &#045;&#045; Morten Welinder (terra@diku.dk)
-->
<listitem><para>つじつまの合わない ext2fs。
状況によっては ext2 ファイルシステムのカーネルコードが、
結果的に gcc の signal 11 を引き起こすことがあります。 
-- Morten Welinder (terra@diku.dk)
</para></listitem>
<!--
<li>CMOS battery. Even if you set the BIOS as you want it, it could be
    changing back to "bad" settings under your nose if the CMOS battery is
    bad. &#045;&#045; Heonmin Lim (coco@me.umn.edu)
-->
<listitem><para>CMOS RAM の電池。BIOS を好みに設定しても、CMOS
RAM の電池が切れていたら、
いけしゃあしゃあと「マズい」もとの設定に戻されてしまうでしょう。
-- Heonmin Lim (coco@me.umn.edu)
</para></listitem>
<!--
<li>No or too little swap space. Gcc doesn't gracefully handle the 
    "out of memory" condition. &#045;&#045; Paul Brannan (brannanp@musc.edu)
-->
<listitem><para>スワップスペースが、まったくないか少なすぎ。gcc
は、「メモリを使いきった」状態ではうまく動きません。
-- Paul Brannan (brannanp@musc.edu)
</para></listitem>
<!--
<li>Incompatible libraries. When you have a symlink from "libc.so.5"
    pointing to "libc.so.6", some applications will bomb with sig11. 
    &#045;&#045; Piete Brooks (piete.brooks@cl.cam.ac.uk).
-->
<listitem><para>互換性のないライブラリ。シンボリックリンクが
``libc.so.5'' から ``libc.so.6'' に向けて張ってあった場合、
アプリケーションの中には sig11 で沈没するものもあるでしょう。
-- Piete Brooks (piete.brooks@cl.cam.ac.uk).
</para></listitem>
<!--
<li>Broken mouse. Somehow, a mouse seems to be able to break in a way
    that it causes some (mouse related) programs to crash with Sig11.
    I've seen it happen on an X server that would crash if you moved
    the mouse quickly. Matthew might not even have been moving his mouse.
    &#045;&#045; REW & Matthew Duggan (stauff@guarana.org).

</ul>
-->
<listitem><para>壊れたマウス。どういうわけか、マウスはいくつかの
(マウスに関係した) プログラムを sig11
でクラッシュさせて中断させることがあるようです。
壊れたマウスをすばやく動かした時、X
サーバがクラッシュするのを見たことがあります。
Matthew
のところでは、マウスを動かさなかった場合さえ、
起きたかもしれないとのことです。
-- REW &amp; Matthew Duggan (stauff@guarana.org).
</para></listitem>
</itemizedlist>
</sect2>
<!--
<hr><h3>QUESTION</h3> 
I found that running ..... detects errors much quicker than just 
compiling kernels. Please mention this on your site.
-->
<sect2 id="quicker">
<title>エラーをもっと速く検出できる方法があるんだけど?</title>
<para>
<emphasis>質問</emphasis>
</para>
<para>
あるソフトウェアを走らせると、カーネルをコンパイルするだけよりも
ずっと速くエラーが検出されることを発見しました。
あなたのサイトでこのことについて触れていただけないでしょうか。
</para>
<!--
<h3>ANSWER</h3>
-->
<para>
<emphasis>答え</emphasis>
</para>
<!--
Many people email me with notes like this. However, what many don't
realize is that they encountered ONE case of problematic hardware. 
The person recommending "unzip -t" happened to have a certain broken
DRAM stick. And unzip happened to "find" that much quicker than a 
kernel compile. 
-->
<para>
多くのひとが、このようなことが書かれたメールを筆者の許に送ってきます。
でも、彼らは
「問題のあるハードウェアのうちのあるひとつのケースに遭遇したにすぎない」
ことに気付いていないのです。``unzip -t''
を薦めるひとは偶然ある壊れた DRAM を使っていたにすぎません。
そして、たまたま unzip のほうが、
カーネルコンパイルよりもエラーを検出するのがずっと速かったにすぎないのです。
</para>
<!--
<p>
However, I'm sure that for many other problems, the kernel compile
WOULD find it, while other tests don't. I think that the kernel
compile is good because it stresses lots of different parts of the
computer. Many other tests just excercize just one area. If that area
happens to be broken in your case, it will show a problem much quicker
than "kernel compile" will. But if your computer is OK on that area
and broken in another, the "faster" test may just tell you your
computer is OK, while the kernel compile test would have told you
something was wrong.
-->
<para>
しかしながらその他数多くの問題では、
カーネルコンパイルだとエラーが検出されるでしょうが、
他のテスト方法だと検出されないことは確かです。
筆者は、コンピュータの多種多様な部分にストレスをかけるという理由で、
カーネルコンパイルは優れたテスト方法だと考えます。
他多くのテストは、あるひとつの箇所だけを酷使するにすぎないのです。
その箇所がたまたま壊れていたなんて場合だと、
カーネルコンパイルよりもずっと速く問題があらわになるでしょう。
しかし、お使いのコンピュータではその箇所は正常で、
別の箇所が壊れていたのであれば、
その「よりすばやく結果が判明する」テストだと
「異常なし」という結果しか出ないかもしれませんが、
カーネルコンパイルによるテストだと、
どこかに悪いところがあると判明するでしょう。
</para>
<!--
<p>
In any case, I might just as well list what people think are good
tests, which they are, but not as general as the "try and compile a
kernel" test.... 
-->
<para>
それはともかくとして、
優秀なテスト手段と考えられているものを
載せたほうがよさそうなので以下に挙げますが、
これらは「何かいじくってみてからカーネルをコンパイルする」
テストほど総合的なテスト手段ではありません....
</para>
<!--
<ul>
<li>Run unzip while compiling kernels. Use a zipfile about as large as RAM. 
-->
<itemizedlist>
<listitem><para>
カーネルのコンパイル中に <command>unzip</command>
を実行する。だいたい RAM
と同じくらいのサイズの「zip で圧縮されたファイル」を用いること。
</para></listitem>
<!--
<li>use "memetest86". 
-->
<listitem><para>
<application>memtest86</application> を使う。
(訳注――<application>memtest86</application> のありかは
<ulink    
url="http://reality.sgi.com/cbrady_denver/memtest86/">
http://reality.sgi.com/cbrady_denver/memtest86/</ulink>
)
</para></listitem>
<!--
<li>do dd if=/dev/hda of=/dev/null while compiling kernels. 
-->
<listitem><para>
カーネルのコンパイル中に
<command>dd <option>if=/dev/hda</option> <option>of=/dev/null</option></command>
を実行する。
</para></listitem>
<!--
<li>run md5sum on large trees. 
</ul> 
-->
<listitem><para>
複数の大きなディレクトリツリーに対して <command>md5sum</command> を実行する。
</para></listitem>
</itemizedlist>
<!--
Note that whatever fast method you may find to tell you that your
computer is broken, it won't guarantee your computer is fine if such a
test suddenly doesn't fail anymore. I always recommend that after
fiddling with things to make it work, you should run a 24-hour
kernel-compile test.
-->
<para>
注――「うちのコンピュータが壊れている」と判明する
どのような高速な手段を発見できたとしても、
そんなテストでもう突然落ちなくなったからといって、
お使いのコンピュータが快調であるという保証はどこにもないでしょう。
きちんと動作させるためにどこかをいじくった後には、24
時間のカーネルコンパイルテストをするよう常におすすめします。
</para>
</sect2>
<!--
<hr><h3>QUESTION</h3> 
I don't believe this. To whom has this happened?
-->
<sect2 id="whom">
<title>誰のところで起こったの?</title>
<para>
<emphasis>質問</emphasis>
</para>
<para>
こんなことは信じられないな。誰のところで起こったの?
</para>
<!--
<h3>ANSWER</h3>
Well for one it happened to me personally. But you don't have to 
believe me. It also happened to:
-->
<para>
<emphasis>答え</emphasis>
</para>
<para>
まあ、少なくとも筆者個人のところで起こったことです。
でも、こんなわたしの言うことを信じる必要はありません。
以下の人達のところでも起こりました:
</para>
<!--
<ul>
<li> Johnny Stephens (icjps@asuvm.inre.asu.edu)
<li> Dejan Ilic (d92dejil@und.ida.liu.se)
<li> Rick Tessner (rick@myra.com)
<li> David Fox (fox@graphics.cs.nyu.edu)
<li> Darren White (dwhite@baker.cnw.com) (L2 cache)
<li> Patrick J. Volkerding (volkerdi@mhd1.moorhead.msus.edu)
<li> Jeff Coy Jr. (jcoy@gray.cscwc.pima.edu) (Temp problems)
<li> Michael Blandford (mikey@azalea.lanl.gov) (Temp problems: CPU fan failed)
<li> Alex Butcher (Alex.Butcher@bristol.ac.uk) (Memory waitstates)
<li> Richard Postgate (postgate@cafe.net) (VLB loading)
<li> Bert Meijs (L.Meijs@et.tudelft.nl) (bad SIMMs)
<li> J. Van Stonecypher (scypher@cs.fsu.edu)
<li> Mark Kettner (kettner@cat.et.tudelft.nl) (bad SIMMs)
<li> Naresh Sharma (n.sharma@is.twi.tudelft.nl) (30->72 converter)
<li> Rick Lim (ricklim@freenet.vancouver.bc.ca) (Bad cache)
<li> Scott Brumbaugh (scottb@borris.beachnet.com)
<li> Paul Gortmaker (paul.gortmaker@anu.edu.au)
<li> Mike Tayter (tayter@ncats.newaygo.mi.us) (Something with the cache)
<li> Benni ???  (benni@informatik.uni-frankfurt.de) (VLB Overloading)
<li> Oliver Schoett (os@sdm.de) (Cache jumper)
<li> Morten Welinder (terra@diku.dk)
<li> Warwick Harvey (warwick@cs.mu.oz.au) (bit error in cache)
<li> Hank Barta (hank@pswin.chi.il.us)
<li> Jeffrey J. Radice (jjr@zilker.net) (Ram voltage)
<li> Samuel Ramac (sramac@vnet.ibm.com) (CPU tops out)
<li> Andrew Eskilsson (mpt95aes@pt.hk-r.se) (DRAM speed)
<li> W. Paul Mills (wpmills@midusa.net) (CPU fan disconnected from CPU)
<li> Joseph Barone (barone@mntr02.psf.ge.com) (Bad cache)
<li> Philippe Troin (ptroin@compass-da.com) (delayed RAM timing trouble)
<li> Koen D'Hondt (koen@dutlhs1.lr.tudelft.nl) (more kernel error messages)
<li> Bill Faust (faust@pobox.com) (cache problem)
<li> Tim Middlekoop (mtim@lab.housing.fsu.edu) (CPU temp: fan installed)
<li> Andrew R. Cook (andy@anchtk.chm.anl.gov) (bad cache)
<li> Allan Wind (wind@imada.ou.dk) (P66 overheating)
<li> Michael Tuschik (mt2@irz.inf.tu-dresden.de) (gcc2.7.2p victim)
<li> R.C.H. Li (chli@en.polyu.edu.hk) (Overclocking: ok for months...)
<li> Florin (florin@monet.telebyte.nl) (Overclocked CPU by vendor)
<li> Dale J March (dmarch@pcocd2.intel.com) (CPU overheating on laptop)
<li> Markus Schulte (markus@dom.de) (Bad RAM)
<li> Mark Davis (mark_d_davis@usa.pipeline.com) (Bad P120?)
<li> Josep Lladonosa i Capell (jllado@arrakis.es) (PCI options overoptimization)
<li> Emilio Federici (mc9995@mclink.it) (P120 overheating)
<li> Conor McCarthy (conormc@cclana.ucd.ie) (Bad SIMM)
<li> Matthias Petofalvi (mpetofal@ulb.ac.be) ("Simmverter" problem)
<li> Jonathan Christopher Mckinney (jono@tamu.edu) (gcc2.7.2p victim)
<li> Greg Nicholson (greg@job.cba.ua.edu) (many old disks)
<li> Ismo Peltonen (iap@bigbang.hut.fi) (irq_unmasking)
<li> Daniel Pancamo (pancamo@infocom.net) (70ns instead of 60 ns RAM)
<li> David Halls (david.halls@cl.cam.ac.uk)
<li> Mark Zusman (marklz@pointer.israel.net) (Bad motherboard)
<li> Elizabeth Ayer (eca23@cam.ac.uk) (Power management features)
<li> Thorsten Kuehnemann (thorsten@actis.de)
<li>
-->
<!-- 以下、カッコ内はあえて訳しません -->
<itemizedlist>
<listitem><para>
 Johnny Stephens (icjps@asuvm.inre.asu.edu)
</para></listitem>
<listitem><para>
 Dejan Ilic (d92dejil@und.ida.liu.se)
</para></listitem>
<listitem><para>
 Rick Tessner (rick@myra.com
</para></listitem>
<listitem><para>
 David Fox (fox@graphics.cs.nyu.edu)
</para></listitem>
<listitem><para>
 Darren White (dwhite@baker.cnw.com) (L2 cache)
</para></listitem>
<listitem><para>
 Patrick J. Volkerding (volkerdi@mhd1.moorhead.msus.edu)
</para></listitem>
<listitem><para>
 Jeff Coy Jr. (jcoy@gray.cscwc.pima.edu) (Temp problems)
</para></listitem>
<listitem><para>
 Michael Blandford (mikey@azalea.lanl.gov) (Temp problems: CPU fan failed)
</para></listitem>
<listitem><para>
 Alex Butcher (Alex.Butcher@bristol.ac.uk) (Memory waitstates)
</para></listitem>
<listitem><para>
 Richard Postgate (postgate@cafe.net) (VLB loading)
</para></listitem>
<listitem><para>
 Bert Meijs (L.Meijs@et.tudelft.nl) (bad SIMMs)
</para></listitem>
<listitem><para>
 J. Van Stonecypher (scypher@cs.fsu.edu)
</para></listitem>
<listitem><para>
 Mark Kettner (kettner@cat.et.tudelft.nl) (bad SIMMs)
</para></listitem>
<listitem><para>
 Naresh Sharma (n.sharma@is.twi.tudelft.nl) (30-&gt;72 converter)
</para></listitem>
<listitem><para>
 Rick Lim (ricklim@freenet.vancouver.bc.ca) (Bad cache)
</para></listitem>
<listitem><para>
 Scott Brumbaugh (scottb@borris.beachnet.com)
</para></listitem>
<listitem><para>
 Paul Gortmaker (paul.gortmaker@anu.edu.au)
</para></listitem>
<listitem><para>
 Mike Tayter (tayter@ncats.newaygo.mi.us) (Something with the cache)
</para></listitem>
<listitem><para>
 Benni ???  (benni@informatik.uni-frankfurt.de) (VLB Overloading)
</para></listitem>
<listitem><para>
 Oliver Schoett (os@sdm.de) (Cache jumper)
</para></listitem>
<listitem><para>
 Morten Welinder (terra@diku.dk)
</para></listitem>
<listitem><para>
 Warwick Harvey (warwick@cs.mu.oz.au) (bit error in cache)
</para></listitem>
<listitem><para>
 Hank Barta (hank@pswin.chi.il.us)
</para></listitem>
<listitem><para>
 Jeffrey J. Radice (jjr@zilker.net) (Ram voltage)
</para></listitem>
<listitem><para>
 Samuel Ramac (sramac@vnet.ibm.com) (CPU tops out)
</para></listitem>
<listitem><para>
 Andrew Eskilsson (mpt95aes@pt.hk-r.se) (DRAM speed)
</para></listitem>
<listitem><para>
 W. Paul Mills (wpmills@midusa.net) (CPU fan disconnected from CPU)
</para></listitem>
<listitem><para>
 Joseph Barone (barone@mntr02.psf.ge.com) (Bad cache)
</para></listitem>
<listitem><para>
 Philippe Troin (ptroin@compass-da.com) (delayed RAM timing trouble)
</para></listitem>
<listitem><para>
 Koen D'Hondt (koen@dutlhs1.lr.tudelft.nl) (more kernel error messages)
</para></listitem>
<listitem><para>
 Bill Faust (faust@pobox.com) (cache problem)
</para></listitem>
<listitem><para>
 Tim Middlekoop (mtim@lab.housing.fsu.edu) (CPU temp: fan installed)
</para></listitem>
<listitem><para>
 Andrew R. Cook (andy@anchtk.chm.anl.gov) (bad cache)
</para></listitem>
<listitem><para>
 Allan Wind (wind@imada.ou.dk) (P66 overheating)
</para></listitem>
<listitem><para>
 Michael Tuschik (mt2@irz.inf.tu-dresden.de) (gcc2.7.2p victim)
</para></listitem>
<listitem><para>
 R.C.H. Li (chli@en.polyu.edu.hk) (Overclocking: ok for months...)
</para></listitem>
<listitem><para>
 Florin (florin@monet.telebyte.nl) (Overclocked CPU by vendor)
</para></listitem>
<listitem><para>
 Dale J March (dmarch@pcocd2.intel.com) (CPU overheating on laptop)
</para></listitem>
<listitem><para>
 Markus Schulte (markus@dom.de) (Bad RAM)
</para></listitem>
<listitem><para>
 Mark Davis (mark_d_davis@usa.pipeline.com) (Bad P120?)
</para></listitem>
<listitem><para>
 Josep Lladonosa i Capell (jllado@arrakis.es) (PCI options overoptimization)
</para></listitem>
<listitem><para>
 Emilio Federici (mc9995@mclink.it) (P120 overheating)
</para></listitem>
<listitem><para>
 Conor McCarthy (conormc@cclana.ucd.ie) (Bad SIMM)
</para></listitem>
<listitem><para>
 Matthias Petofalvi (mpetofal@ulb.ac.be) ("Simmverter" problem)
</para></listitem>
<listitem><para>
 Jonathan Christopher Mckinney (jono@tamu.edu) (gcc2.7.2p victim)
</para></listitem>
<listitem><para>
 Greg Nicholson (greg@job.cba.ua.edu) (many old disks)
</para></listitem>
<listitem><para>
 Ismo Peltonen (iap@bigbang.hut.fi) (irq_unmasking)
</para></listitem>
<listitem><para>
 Daniel Pancamo (pancamo@infocom.net) (70ns instead of 60ns RAM)
</para></listitem>
<listitem><para>
 David Halls (david.halls@cl.cam.ac.uk)
</para></listitem>
<listitem><para>
 Mark Zusman (marklz@pointer.israel.net) (Bad motherboard)
</para></listitem>
<listitem><para>
 Elizabeth Ayer (eca23@cam.ac.uk) (Power management features)
</para></listitem>
<listitem><para>
 Thorsten Kuehnemann (thorsten@actis.de)
</para></listitem>
<listitem><para>
</para></listitem>
<!--
<li> (Email me with your story, you might get to be mentioned here...  :-)
-->
<listitem><para>
 (あなたの話をメールしてくれたら、ここに載るかも...  :-)
<!--
&#045;&#045;&#045;&#045;
Update: I like to hear what happened to you. This will allow me to 
guess what happens most, and keep this file as accurate as possible. 
However I now have around 500 different Email addresses of people who've
had sig-11 problems. I don't think that it is useful to keep on adding
"random" people's names on this list. What do YOU think?
</ul>
-->
---- 更新――あなたのところで何が起きたのか聞きたいと思います。
それによって、何が最もたくさん起こっているのかが推測できるだろうし、
この文書をできるだけ正確に保つこともできるだろうから。
でも、目下筆者のところには、sig11
問題に遭遇したことのある人々のさまざまなメールアドレスが
500 前後あります。
このリストに「手当たり次第に」名前を追加し続けるのが有益だとは思いません。
「あなたは」どう思う?
</para></listitem>
</itemizedlist>
</sect2>
</sect1>
<!--
<hr>
I'm interested in new stories. If you have a problem and are unsure 
about what it is, it may help to
<a href="mailto:R.E.Wolff@BitWizard.nl">Email me at R.E.Wolff@BitWizard.nl
</a>. My curiosity will usually drive me to answering your questions until
you find what the problem is..... (on the other hand, I do get pissed when
your problem is clearly described above :-)
-->
<sect1 id="end">
<title>おわりに</title>
<sect2 id="author">
<title>著者より</title>
<para>
新たな話に興味があります。
もし問題を抱えていてそれが何であるか確信がもてないなら、R.E.Wolff@BitWizard.nl
にメールをいただけると、助けになれるかもしれません。
普通なら好奇心がわたしに、
その問題が何であるかをあなたがつきとめるまで、
質問に答えるように駆りたてるでしょう.....
(一方、問題が明らかに上に挙げてあるものなら、うんざり :-)
</para>
<!--
<hr>
This page is hosted by <a href="http://www.BitWizard.nl/">www.BitWizard.nl</a>
<hr>
</body>
</html>
-->
<para>
この文書のオリジナル英文は
<ulink    
url="http://www.BitWizard.nl">
http://www.BitWizard.nl</ulink>
で管理されています。
</para>
</sect2>
<sect2 id="translator">
<title>日本語版の謝辞</title>
<para>
この文書の翻訳にあたって、JF ML
のみなさんにたいへんお世話になりました。なかでも、
山下 義之さん、武井 伸光さんにはたくさんの有益なアドバイスをいただきました。
感謝します。
-- Masanori Kobayasi (zap03216@nifty.ne.jp)
</para>
</sect2>
</sect1>
</article>
