このセクションでは、よくある問題について説明します。 ここに質問の答えが見つからなかったら、お使いのホストアダプタや デバイスのセクションも調べて見てください。
再現性のないエラーが発生する場合、ケーブルや終端に問題がある ことが多いのです。
最近の NCR チップを採用した製品などには、ディジタルフィルタリングや アクティブシグナルネゲーションなどの機能を持っているものがあり、 これらはケーブルにはそれほど敏感ではありません。
例えば Adaptec の 154xC や 154xCF、それに 274x など、それ以外の 製品はケーブルに非常に敏感で、他のシステムでは問題なく動作する ケーブルでも動かないことがあります。
もう一度繰り返します。一部のホストアダプタはケーブルやターミネーターの 問題に非常に敏感なので、問題が起こった時にはまずケーブルや ターミネーターを調べてみてください。
問題を最小限にするため、以下のようなケーブルを使うべきです。
訳注: SCSI-2 規格では、同期転送を行なう場合のケーブルのインピーダンスは 90オームから132オームと規定されています。 SCSI-2 規格は ftp://ftp.symbios.com/pub/standards/io/x3t10/drafts/scsi2/ に あります。
ターミネータが接続されるケーブルの両端に十分な電力を供給するため、 ターミネータパワーは SCSI バス上のすべてのデバイスから 電流の逆流を防止するダイオードを通して供給されなくてはなりません。 バスが短絡された場合の損傷を防ぐため、TERMPWR はヒューズなどの 電流制限デバイスを通して供給されなければなりません。
訳注: SCSI-2 規格では、すべてのイニシエータデバイスは ターミネーターパワーを供給しなければならないと規定されていますが、 ターゲットデバイスは供給しなくてもよいことになっています。
複数のデバイスや外部ケーブル、あるいは FAST SCSI 2 を使用する場合には、 SCSI バスの両端にアクティブターミネータを使う必要があります。
アクティブターミネータについての詳しい情報は、 Comp.Periphs.Scsi の FAQ ( tsx-11 の pub/linux/ALPHA/scsi に あります) を参照してください。
この文書の中で「カーネルコマンドライン」について言及することがあります。
カーネルコマンドラインとは、LILO : プロンプトに対してイメージ名の後に、
あるいは LILO 設定ファイルの append フィールドに指定するオプション群の
ことです。
LILO 設定ファイルは LILO .14 以降では /etc/lilo.conf、
それ以前のバージョンでは /etc/lilo/config にあります。
プロンプトを表示させるには、LILO でブートし、起動中に Alt か Ctrl、または Shift キーのいずれかを押して下さい。 以下のプロンプトが表示されます。
:
ここで、ブートするカーネルイメージを選択します。また次のように ? を 入力すると、カーネルイメージのリストが表示されます。
:?
ramdisk floppy harddisk
選択したコマンドラインオプションでカーネルをブートするには、 カーネル名の後にオプションのリストをスペースで区切って入力し、 最後にリターンキーを押せば良いのです。
オプションは以下の形式で指定します。
variable=valuelist
valuelist は単一の値、あるいはスペースを含まない値のリストを
コンマで区切ったものです。ルートデバイスは例外ですが、それ以外の
値は10進または16進で指定する数値です。
例えば、ブート時に認識されない Adaptec 1520 のクローンを持った システムで Linux をブートするには次のようにします。
:floppy aha152x=0x340,11,7,1
ブート時にこれらの値を入力するのが面倒ならば、次の例のように、
LILO 設定ファイルの append オプションに指定することも
可能です (LILO .13 以降が必要です)。
append="aha152x=0x340,11,7,1"
この現象は、そのデバイスがコントローラと同じ ID を持っていることが 原因です。(コントローラの ID は普通は 7 ですが、ボードによっては 違う ID を使っている場合があります。 例えば Future Domain のボードには 6 を使っているものがあります。)
ジャンパーの設定を変更してください。
そのデバイスのファームウェアがバグっています。
暫定的な解決方法として、以下のカーネルコマンドラインオプションを 試してみてください。
max_scsi_luns=1
これでうまくいったら、カーネルソースの drivers/scsi/scsi.c の
blacklist 変数にある、バグありデバイスのリストに
そのデバイスを追加し、その情報を Linus Torvalds
<Linus.Torvalds@cs.Helsinki.FI> に
メールして下さい。
この問題は、質の悪いケーブルや不適当なターミネータによって引き起こされる ことがあります。
不安定なシステム を参照してください。
多くのネットワークドライバの自動検出ルーチンはレジスタへの書き込みを 行なうため、SCSI ドライバの動作と干渉することがあります。
カーネルによって SCSI デバイスは検出されるが、アクセスすることが
できない。
mkfs /dev/sdc とか tar xvf /dev/rst2 などの
コマンドが失敗する。
そのデバイスに対するスペシャルファイルが /dev にないのでしょう。
Unix のデバイスにはブロックデバイスとキャラクタデバイスの区別があり、
それぞれのデバイスはメジャーデバイス番号とマイナーデバイス番号で区別
されます。
ブロックデバイスはバッファキャッシュを通してアクセスされますが、
キャラクタデバイスはバッファキャッシュを通さずにアクセスされます。
メジャーデバイス番号は、使用されるドライバを表します。
例えばメジャー番号 8 のブロックデバイスは SCSI ディスクを表します。
マイナーデバイス番号は、そのドライバを通してどのユニットがアクセス
されるかを表します。例えばメジャー番号 4、マイナー番号 0 の
キャラクタデバイスは最初の仮想コンソールを表し、マイナー番号 1 は次の
仮想コンソールを表す、といった具合です。
しかし、この方法でデバイスをアクセスすることは、「すべてはファイルと
して表現される」という Unix/Linux のメタファにそぐわないため、
キャラクタデバイスとブロックデバイスのスペシャルファイル
が /dev の下に作成されており、例えば3番目の SCSI ディスク
は /dev/sdc、最初のシリアルポートは /dev/ttyS0 として
アクセスできるようになっています。
スペシャルファイルを作成するには、MAKEDEV スクリプトを使うのが
普通です。/dev に cd し、作成したいデバイスを指定して
次のように MAKEDEV を実行して下さい (root で)。
./MAKEDEV sdc
訳注: パッケージによっては MAKEDEV はスクリプトではなく、バイナリ
コードになっている場合もあります。
ワイルドカードも使える「はず」です。
./MAKEDEV sd\*
これによってすべての SCSI ディスクデバイスが作成される「はず」
(/dev/sda から /dev/sdp までと、それぞれに対して
15個のパーティションが作成されるはず) です。
./MAKEDEV sdc\*
これによって /dev/sdc 自身と /dev/sdc 上の15個の
パーティションすべてが作成される「はず」です。
カギカッコつきで「はず」といったのは、これが標準的な Unix の振舞い
だからです。インストールされている MAKEDEV スクリプトがこのように
振舞うとは限りませんし、作成するデバイスの数が制限されているかもしれません。
MAKEDEV では望む結果が得られない場合、mknod コマンドを使って
手動でデバイスファイルを作成する必要があります。
各種 SCSI デバイスのデバイス種別 (ブロックデバイスかキャラクタデバイスか)、 メジャーデバイス番号、マイナーデバイス番号は デバイスファイル に示してあります。
mknod コマンドの書式は次の通りです。
root で実行して下さい。
mknod /dev/device b|c major minor
以下は実行例です。
mknod /dev/sdc b 8 32
mknod /dev/rst0 c 9 0
ここに書かれている情報はごく限られたものです。 使用しているホストアダプタの項も参照してください。 ここに書かれている以外の解決法が書かれているかもしれません。
複数のデバイスが同時にアクセスされる時にロックアップすると思われる 場合には、デバイスのメーカーに連絡して、ファームウェアをバージョン アップすることで問題が解決できないか聞いてみるのがいいでしょう。 可能な場合には、SCSI ケーブルを換えてみたり、別のシステムで試して みてください。 また、ディスクのバッドブロックや、マザーボードの DMA 処理 (DMA を 行なうホストアダプタの場合) が原因となっていることも考えられます。 この種の問題には、他にも多くの原因が考えられます。
同一バス上の複数のデバイスが同時にアクセスされる時にロックアップする と思われる場合もあります。 同時に複数のコマンド処理を行なえるホストアダプタを使用している場合、 この値を 1 に減らして様子を見てください。バス上に低速のテープドライブ や CDROM がある場合、これは現実的な解決とはならないでしょう。
カーネルメモリはページングされないので、 使用しない SCSI ドライバは貴重なメモリを消費してしまい、 小さなシステムではメモリ不足の悪化にもつながります。
したがって、使用するシステム向けにチューンアップしたカーネルを 構築し、必要なドライバだけがインストールされるようにします。
cd /usr/src/linux
現在とは違うルートデバイス、あるいは 80x25 VGA 以外の
ディスプレイを使いたい場合で、ブートフロッピーに書き込みを
行なう場合には、makefile を編集して
ROOT_DEV =
および
SVGA_MODE =
以上の行にルートデバイスあるいはディスプレイの指定を行ないます。
パッチを当てた場合、すべてのファイルが再構築されるようにしたい場合が あります。そのためには以下のように入力します。
make mrproper
mrproper の結果がどうであれ、
make config
として、コンフィギュレーションに関する質問に答えて下さい。それから
make depend
を実行し、最後に
make
を実行します。終了したら、lilo を設定し直すか、以下のようにして
ブートフロッピーの作成を行ないます。
make zdisk
SCSI デバイスにはまともに LUN をサポートしていないものが多く、 0 以外の LUN にアクセスしようとしたとき SCSI バスを ロックさせるなどの悪さをします。
そのため、最近の Linux カーネルはデフォルトでは 0 以外の LUN を
見に行かないようになっています。0 以外の LUN を使うためには、
max_scsi_luns command コマンドラインオプションを使うか、
CONFIG_SCSI_MULTI_LUN オプションを指定してカーネルを再
コンパイルする必要があります。
普通は LILO コマンドラインに以下のように指定すればいいはずです。
max_scsi_luns=8
この変更を行なっても、マルチ LUN デバイスが正しく検出されないことが
あります (SCSI から MFM、RLL、ESDI、SMD などへのブリッジボードに多く
みられます)。
これは drivers/scsi/scsi.c 中の scan_scsis() にある、
以下のコードのせいです。
/* Some scsi-1 peripherals do not handle lun != 0.
I am assuming that scsi-2 peripherals do better */
if((scsi_result[2] & 0x07) == 1 &&
(scsi_result[3] & 0x0f) == 0) break;
このコードを削除すれば、うまく行くはずです。