注意: この文書はかなり以前に書かれたものなので、 いまどきの Linux 環境にはあてはまらない箇所があります。 (JF Project)
この文書はフリーです。再配布、変更は Free Software Foundation 発行の GNU General Public License (バージョン2またはそれ以降)に したがって行うことができます。
この文書は有用であることを目指して配布されていますが、何の保証もありません。 商用性、あるいは特定の目的への適合性は暗黙にも保証されていません。 詳細については、GNU General Public Licence を参照してください。
GNU General Public Licence は、この文書に付随して配布されているはずです。 もし付随していなかった場合には、 Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. まで連絡してください。
もしこの文書を出版する場合には、最新のバージョンに関して筆者 <drew@PoohSticks.ORG> に問い合わせてくださるよう お願いします。 もし古いバージョンが出版されてしまうと、私は新しいバージョンに答えが 載っている質問をユーザーから受けることになりますし、それは出版する側 にもうれしくないことだろうと思うのです。 また、フリー配布を行っているサイトや、競合するパッケージや製品に関する 記述を改変しないようにお願いします。
バグレポート セクションに記述された手順に 従わないバグレポートや問い合わせは無視されます。
この文書は、Linux カーネル 1.2.10 およびそれ以降のアルファコードに 実装された Linux の SCSI サブシステムについて説明しています。 これ以前のリビジョンの SCSI コードはサポートされていませんし、 実装されているドライバや性能、利用できるオプションなどに関して大きく 異なっていることがあります。
linux-scsi メーリングリストに参加すれば、より詳しい情報を得ることが できます。 参加するには、本文に以下のように書いて、 majordomo@vger.rutgers.edu に メールを送ってください。
subscribe linux-scsi
メーリングリストから脱退するには、本文に以下のように書いて、同じアドレスへ メールを送ってください。
unsubscribe linux-scsi
メーリングリストに参加すると、以下のアドレスにメールが送れるようになります。
linux-scsi@vger.rutgers.edu
この文書はあまりユーザーフレンドリーではありませんし、不正確な 記述や、書き落としていることもあるでしょう。 これらの問題を解決するために何か建設的なコメントがあれば、 私にメールしてください。
このセクションでは、よくある問題について説明します。 ここに質問の答えが見つからなかったら、お使いのホストアダプタや デバイスのセクションも調べて見てください。
再現性のないエラーが発生する場合、ケーブルや終端に問題がある ことが多いのです。
最近の 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;
このコードを削除すれば、うまく行くはずです。
Linux の SCSI 開発者たちは、古いコードを取っておいているとは限りません。 したがって、リリースされた最新の Linux カーネル以外では (MCC、SLS、 Yggdrasil などのパッケージは最新カーネルから1つから12個も古い場合が あります) 問題解決が不可能な場合があります。 ですから、バグレポートを送る前に、リリースされた最新のカーネルでも その問題が起こるかどうか確かめて下さい。
カーネルをバージョンアップした後でも、またこの文書をよく読んだ後でも、 まだバグが存在すると信じられる場合には、Linux メーリング リストの SCSI チャネルにバグレポートを送ってください。 ここには Linux SCSI ドライバの作成に協力している多くの人々が参加しています。
バグレポートには、 ハードウェア構成、ブート時に Linux が表示する正確なメッセージ、 エラーが発生する場合、それにエラーが存在するソースコードの位置 など、なるべく多くの情報を書いてください。 メッセージの取得 や <tt>panic()</tt> の位置を特定する に記述されている手続きに従ってください。
最大限の情報が提供されないと、開発者が問題を誤って診断したり、 他の問題を修正することがより重要だと判断することになってしまうかも しれません。
要するに、我々がバグを再現させることができない場合、 どこがおかしいのかを具体的に指摘してくれなければ、 バグを修正することはできないということです。
カーネルメッセージロギングシステムを実行していない場合:
/proc ファイルシステムがマウントされていることを確かめて
ください。
grep proc /etc/mtab
/proc ファイルシステムがマウントされていなければ、マウント
してください。
mkdir /proc
chmod 755 /proc
mount -t proc /proc /proc
カーネルのバージョンとメッセージをログファイルにコピーします。
cat /proc/version > /tmp/log
cat /proc/kmsg >> /tmp/log
1秒から2秒後に CNTRL-C を打ってください。
ロギングシステムを実行している場合、適当なログファイル (ログファイルの
情報は /etc/syslog.conf にあります) を覗くか、
dmesg コマンドを使用してください。
Linux が起動していない場合、DOS 上でフロッピーディスクをフォーマット
してください。RAM ドライブではなく、ルートディスケットを直接マウント
するパッケージを使っている場合には、ルートとしてマウントされるドライブ
以外で読み書き可能なディスケットを用意するか、
ramdisk ブートオプションの使用が必要であることに
注意して下さい。
Linux をパッケージのブートフロッピーからブートします。できればシングル ユーザモードで RAM ドライブをルートとしてマウントしてください。そして、
mkdir /tmp/dos
とし、さっきフォーマットしたディスケットを挿入し、マウントしてください。
mount -t msdos /dev/fd0 /tmp/dos
あるいは
mount -t msdos /dev/fd1 /tmp/dos
とします。
ログファイルをフロッピーにコピーします。
cp /tmp/log /tmp/dos/log
DOS フロッピーをアンマウントします。
umount /tmp/dos
そして Linux をシャットダウンします。
shutdown now
リブートして DOS を起動し、好みの通信ソフトを使ってログファイルを メールしてください。
panic() の位置を特定する
他の Unix と同じように、Linux は致命的なエラーが生じるとカーネルの
panic() 関数を呼び出します。他の Unix とは違って、Linux は
コアをスワップあるいはダンプデバイスにダンプして自動的にリブート
することはありません。その代わり、ユーザが手で書き写すことができる
ように有用なステート情報のサマリが表示されます。
Unable to handle kernel NULL pointer dereference at virtual address c0000004
current->tss,cr3 = 00101000, %cr3 = 00101000
*pde = 00102027
*pte = 00000027
Oops: 0000
EIP: 0010:0019c905
EFLAGS: 00010002
eax: 0000000a ebx: 001cd0e8 ecx: 00000006 edx: 000003d5
esi: 001cd0a8 edi: 00000000 ebp: 00000000 esp: 001a18c0
ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
Process swapper (pid: 0, process nr: 0, stackpage=001a09c8)
Stack: 0019c5c6 00000000 0019c5b2 00000000 0019c5a5 001cd0a8 00000002 00000000
001cd0e8 001cd0a8 00000000 001cdb38 001cdb00 00000000 001ce284 0019d001
001cd004 0000e800 fbfff000 0019d051 001cd0a8 00000000 001a29f4 00800000
Call Trace: 0019c5c6 0019c5b2 0018c5a5 0019d001 0019d051 00111508 00111502
0011e800 0011154d 00110f63 0010e2b3 0010ef55 0010ddb7
Code: 8b 57 04 52 68 d2 c5 19 00 e8 cd a0 f7 ff 83 c4 20 8b 4f 04
Aiee, killing interrupt handler
kfree of non-kmalloced memory: 001a29c0, next= 00000000, order=0
task[0] (swapper) killed: unable to recover
Kernel panic: Trying to free up swapper memory space
In swapper task - not syncing
EIP: 行の16進数 (この場合 19c905) を書き留め、
/usr/src/linux/zSystem.map を探してこのアドレス以下で最も大きな
数字を見つけてください。
0019a000 T _fix_pointers
0019c700 t _intr_scsi
0019d000 t _NCR53c7x0_intr
これによってどの関数を実行中に panic() が呼ばれたかが分かります。
この関数を含むソースファイルをデバッグオプションつきでコンパイルし直すか、
/usr/src/linux/Makefile を編集して -g オプションを
CFLAGS の定義に追加してカーネル全体をコンパイルし直してください。
#
# standard CFLAGS
#
つまり、次の行を
CFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe
このように変更します。
CFLAGS = -g -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe
カーネルを再構築します。
make clean
make
/etc/lilo.conf にエントリを作成してカーネルをブートできるように
します。
image = /usr/src/linux/zImage
label = experimental
そして root で LILO を再実行するか、ブートフロッピーを作成します。
make zImage
リブートし、エラー発生時の EIP を記録します。
script がインストールされている場合、これを起動して
以下のデバッグの記録をタイプスクリプトファイルに記録して
おくのが良いでしょう。
次のように gdb を実行します。
gdb /usr/src/linux/tools/zSystem
そして次のように入力します。
info line *<your EIP>
例えば以下のように。
info line *0x19c905
これに対して gdb は次のような情報を出力します。
(gdb) info line *0x19c905
Line 2855 of "53c7,8xx.c" starts at address 0x19c905 <intr_scsi+641&>
and ends at 0x19c913 <intr_scsi+655>.
この情報を記録して下さい。それから以下のように入力します。
list <line number>
次のような出力が得られるでしょう。
(gdb) list 2855
2850 /* printk("scsi%d : target %d lun %d unexpected disconnect\n",
2851 host->host_no, cmd->cmd->target, cmd->cmd->lun); */
2852 printk("host : 0x%x\n", (unsigned) host);
2853 printk("host->host_no : %d\n", host->host_no);
2854 printk("cmd : 0x%x\n", (unsigned) cmd);
2855 printk("cmd->cmd : 0x%x\n", (unsigned) cmd->cmd);
2856 printk("cmd->cmd->target : %d\n", cmd->cmd->target);
2857 if (cmd) {;
2858 abnormal_finished(cmd, DID_ERROR << 16);
2859 }
2860 hostdata->dsp = hostdata->script + hostdata->E_schedule /
2861 sizeof(long);
2862 hostdata->dsp_changed = 1;
2863 /* SCSI PARITY error */
2864 }
2865
2866 if (sstat0_sist0 & SSTAT0_PAR) {
2867 fatal = 1;
2868 if (cmd && cmd->cmd) {
2869 printk("scsi%d : target %d lun %d parity error.\n",
quit と入力して gdb から抜けます。
上の情報も記録してください。開発者のカーネルがあなたのカーネルと違って いる場合に役立つコンテキスト情報が得られます。
ここでは、ローダブルカーネルモジュールのサポート状況と SCSI との関係に ついて説明します。
ローダブルモジュールは、ユーザーやシステム管理者がカーネルのメモリーに ファイルをロードして、カーネルの能力を拡張することを可能にするものです。 ローダブルモジュールはハードウェアをサポートするドライバや、ファイル システムをロードするためによく使われます。
SCSI にとってモジュールはいくつかの利点があります。 ひとつは、多数のマシンを管理するシステム管理者が、すべてのマシンに 対して唯一のカーネルイメージを使用し、マシン特有のハードウェアを サポートするためにはカーネルモジュールをロードするといった使い方が できることです。
配布パッケージの作成者が、どのモジュールをロードするか問い合わせる スクリプトをブートフロッピー上に用意することもできます。 こうすれば、使われないドライバのためにメモリを浪費することはなくな りますし、存在しないハードウェアを検出しに行って他のハードウェアを おかしくしてしまう可能性も減らすことができます。
モジュールはラップトップコンピュータにも適しています。ラップトップ コンピュータはデスクトップマシンよりもメモリが少ないことが多く、 なるべくカーネルイメージを小さくして、必要に応じてモジュールをロード することができるからです。 また、モジュールによって PCMCIA SCSI カードのサポートも簡単になります。 カードが挿入/抜出される時にドライバをロード/アンロードできるからです。 [ 注意: 現在のところ、PCMCIA をサポートしているのは qlogic と 152x の ドライバです。]
最後に、カーネル開発者にとってドライバのデバッグやテストが簡単になるという 利点もあります。新しいドライバのテストのために、マシンをリブートする必要が ないからです (もちろん、ドライバのバグによってマシンがクラッシュしてしまう ことがなければ、の話ですが)。
モジュールには数々の利点がありますが、大きな制限もあります。 ルートディスクパーティションが SCSI デバイス上にある場合、ディスク アクセスに必要な SCSI ドライバをモジュールとしてロードすることは できません。 これは、システムがディスクからモジュールをロードする前に、ルート パーティションをマウントしなければならないからです。 ローダとカーネルを変更して、カーネルがルートファイルシステムをマウント する前にモジュールをロードできるようにしようと考えている人々がいます から、将来はこの制限もなくなることでしょう。
1.2.N シリーズのカーネルでは、SCSI カーネルモジュールは部分的に サポートされています。ハイレベル (ディスク、テープなど) のドライバは モジュールとして使用することはできませんが、ローレベル (1542、1522 など) のドライバは必要に応じてロード/アンロードすることができます。 ローレベルのドライバはロードされるたびに、まずそのドライバがサポート しているカードを探しに行きます。次に、見つかったカードそれぞれに対して、 SCSI バスがスキャンされ、内部データ構造がセットアップされて、デバイスが 使用できるようになります。
使わなくなったローレベルドライバは、アンロードすることができます。
マウント中のファイルシステムやオープン中のファイルなどについて使用中
カウンタが保持されているため、ドライバが管理しているデバイスを使って
いる間は rmmod ユーティリティがデバイスが使用中であるという警告
を発し、ドライバはアンロードできないことに注意してください。
ドライバがアンロードされると、関連するデータ構造はすべて開放され、
システムはモジュールがロードされる前の状態に戻ります。
これは、ドライバはその後必要に応じて再びロードできるということを意味します。
1.3 シリーズのカーネルでは、SCSI ドライバは完全にモジュール化されています。 つまり、まったく SCSI をサポートしていないカーネルでブートした後に モジュールをロードすることによって SCSI をフルサポートすることもできる ということです。
お望みならば、SCSI ドライバの一部分をカーネルに組み込んでコンパイルし、 その他の部分を後でロードすることもできます。どの部分を実行時にロードするか、 どの部分をカーネルに直接リンクするかは、自由に選択することができます。
まったく SCSI をサポートしていないカーネルでブートした場合、まず
SCSI コアをカーネルにロードする必要があります。
これは scsi_mod という名前のモジュールになっています。
このモジュールをカーネルメモリにロードするまでは、これ以外の SCSI
モジュールをロードすることはできません。
このモジュールにはローレベルドライバは含まれていませんから、
このモジュールをロードしても SCSI バスはスキャンされませんし、
SCSI ディスクやテープが使えるようにもなりません。
カーネルを構築する際 CONFIG_SCSI に「y」と答えたのであれば、
このモジュールをロードする必要はありません。
この後は、あまり順番を気にせずに必要な機能を実現するモジュールを
ロードすることができます。使用中のモジュールがアンロードされて
しまうことを防ぐために、使用中カウンタによるインターロックがかかって
いるので、モジュールがビジーの場合には rmmod からメッセージが
出力されます。
ディスク、CDROM、テープ、それに SCSI 汎用のハイレベルドライバは、 それぞれ「sd_mod」、「sr_mod」、「st」、「sg」という名前になっています。 ハイレベルドライバがロードされると、接続されたすべてのホストアダプタの デバイスリストが調べられ、サポートされているデバイスは自動的に有効に なります。
ローレベルドライバのモジュールとしての使い方は、 カーネル 1.2 でのモジュールのサポート を参照してください。 ローレベルドライバがロードされると、バスがスキャンされ、見つかった デバイスはハイレベルドライバによってサポートされているデバイスとして 認識できるかどうか調べられます。認識されたドライバは自動的にアタッチ され、活性化されます。
この章では Linux でサポートされている各種のホストアダプタに対して、 それぞれのホストアダプタに固有の情報を示します。
Adaptec 152x、Adaptec 154x (DTC 329x のボードも動くようですが、サポー トの対象にはなっていません)、 Adaptec 174x、Adaptec 274x/284x (294x を利用するには新しいバージョンの ドライバが必要です)、 BusLogic MultiMaster ホストアダプタ、EATA-DMA および EATA-PIO プロトコルを 使うボード (DPT PM2001、PM2011、PM2012A、PM2012B、PM2021、PM2022、PM2024、 PM2122、PM2124、PM2322、PM2041、PM2042、PM2044、PM2142、PM2144、PM2322、 PM3021、PM3122、PM3222、PM3224、PM3334、 それに加えて NEC、AT&T、SNI、AST、Olivetti、および Alphatronix などの メーカーのボードのいくつか)、 Future Domain 850、885、950、および同社の他のシリーズ (ただし 840、841、880、881 のボードは適当なパッチを当てないと動作しま せん)、 Future Domain 16x0 (チップが TMC-1800、TMC-18C30、または TMC-18C50 のもの)、 NCR53c8xx、PAS16 の SCSI ポート、Seagate ST0x、 Trantor の T128/T130/T228 ボード、 Ultrastor 14F、24F および 34F、Western Digital 7000。
MCA のカードのうち、上にあるサポートされているカードと互換性のあるもの (つまり Adaptec 1640 と BusLogic 640) は動作します。
アルファ版のドライバの多くが以下のサイトに置かれています。
ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsiNCR53c8xx のドライバは開発されていますが、このドライバは NCR53c700、 NCR53c710、NCR53c720 のチップに対してそのままでは適用できません。 これらのチップを動作させるには以下のような修正が必要です。 修正の難易度についても示しています。
訳注: カーネル 2.0.27 では、すでにこれらのチップはサポートされて いるようです。
カードの検出部分の変更、初期化の変更、'810 のレジスタアドレスを '7xx 用にマッピングするためのコードの変更。
カードの検出部分の変更、初期化の変更 (以上はアセンブラソースの変更)、'810 のレジスタアドレスを '7xx にマッピングするためのコードの変更、IID 割り 込みを扱うための割り込みハンドラを INTFLY 命令からそのエミュレーション に変更。
検出部分の変更、初期化の変更、 NCR のコードを DSA を使わないように変更、 Linux 本体のコードを変更し、コンテキストスイッチを扱えるようにする。
パラレル->SCSI アダプタ全部、 Rancho の SCSI ボード、ジャンク品の SCSI カード。 Buslogic の FlashPoint ボード (BT-930/932/950 など) もま だサポートされていません。
Adaptec と非互換で NCR53c8xx を使用していない DTC のボード (3270、 3280 など)。CMD の SCSI ボード。
DTC/CMD からプログラムに必要な情報をもらうには、秘密保持契約を結ぶ 必要があります。これはつまり Linux のドライバを書いても、そのドライバ を公開できない、ということになります。秘密保持契約に従えばソースは 公開できませんから、これは GPL に反します。また GPL に従う場合は ソースを公開しなければなりませんから、これは秘密保持契約に反する ことになります。
もしこれら以外のサポートされていないハードウェアを動かしたければ、選択 肢は二つあります。一つはあなた自身がドライバを書くことです (Eric Youngdale と私は Linux の SCSI ドライバに関する技術的な質問には通常喜んでお答え します)。もう一つはドライバの作成を依頼することです (個人での利用の場 合には契約料金が高く付きすぎるでしょうが)。
ホストアダプタの中には、一台のシステムで同じ形式のアダプタを 複数使うことができるものがあります ( 購入の手引き: ドライバ機能の比較 を見てください)。 同じ形式のアダプタを一つのホストで複数使う場合は、通常最も低いアドレス のものが scsi0 になり、その次が scsi1... のようになります。
種類の違うホストアダプタなら、どんな場合でも複数のアダプタを同時に使う
ことが可能です。ただしアドレスが競合していないことが条件です。 SCSI コ
ントローラは drivers/scsi/hosts.c の
中の builtin_scsi_hosts[]
配列の順番で検索されます。現在の順番は以下の通りです。
BusLogic, Ultrastor 14/34F, Ultrastor 14F,, Adaptec 151x/152x,
Adaptec 154x, Adaptec 174x, AIC7XXX, AM53C974, Future Domain 16x0,
Always IN2000, Generic NCR5380, QLOGIC, PAS16, Seagate,
Trantor T128/T130, NCR53c8xx, EATA-DMA, WD7000, debugging driver.
ほとんどの場合 (Buslogic と Adaptec のドライバの両方を使っていない場合) には、このエントリを入れ替えることで、検索の順番を都合の良いように変え ることができます。例えば新しい SCSI ホストをシステムに追加したときに、 元からのデバイス名を変更したくない場合などがあるでしょう。
割り込みがちゃんと有効になっているか、他のボードとの IRQ、DMA、 IO アドレスなどの競合が起こっていないかを確認してください。
もしお使いの SCSI アダプタが以下のどれかの場合:
Adaptec 152x, Adaptec 151x, Adaptec AIC-6260,
Adaptec AIC-6360, Future Domain 1680, Future Domain TMC-950,
Future Domain TMC-8xx, Trantor T128, Trantor T128F,
Trantor T228F, Seagate ST01, Seagate ST02, Western Digital 7000
そしてアダプタがブートアップの時に検出されない場合、すなわち
scsi : 0 hosts
や
scsi%d : type
といったようなメッセージがシステムにインストールされている (サポート対象の) SCSI アダプタそれぞれに対して表示されない場合は、 自動検出のルーチンがそのボードを知らないために問題が起こっている ものと考えられます。
BIOS を使って自動検出を行うドライバでは、BIOS が有効になっている必要が あります。よく調べてください。 またほかの機器の BIOS と競合していないかもチェックしてください。
ボードのシグネチャや BIOS のアドレスがドライバに登録されているものと 違う場合も自動検出は失敗します。
訳注: シグネチャとは、BIOS の先頭部分に書き込まれている情報の ことです。
BIOS がインストールされている場合は、DOS と DEBUG を使ってボードの シグネチャを調べてください。
例えば 0xc8000 にあるボードに対しては、DOS から
debug
d c800:0
q
として、結果を ASCII で Linux メーリングリストの SCSI チャネルに送っ てください。メッセージの長さとベースアドレス (この場合 0xc8000) からの オフセットも同時に送ってください。メッセージは完全に正確でなければなり ません。またテキストには 16 進と ASCII の両方が含まれる必要があるでしょ う。
BIOS がインストールされていない場合、そしてお使いのドライバが Adaptec 152x、 Trantor T128、 Seagate のどれかである場合は、コマンドラインやコ ンパイル時に検出を強制するように設定を変更することができます。
お持ちの SCSI カードに対応した節をご覧になってください。 不安定なシステム も見てください。
(Trantor T128 と Seagate のボードが該当します。 Adaptec、 NCR5380 汎用、PAS16、Ultrastor のボードには該当しません。)
この問題は、メモリマップされた I/O ポートが誤ってキャッシュされて いるときによく起こります。 BIOS 設定で、ボードの占有するアドレス空間をキャッシュ不可に設定して ください。
これができない場合は、キャッシュを全てオフにしてください。
ボードのアドレスをマニュアルで設定する場合は、Linux に必要なのは 16バイトセ グメントの値 (マニュアルにはたいていこちらが書いてあります) ではなく、 実際のアドレスであることに注意してください。
つまり 0xc8000 が正しい値であり、 0xc800 では正しく動作しません。後者 では恐らくメモリの内容が破壊されてしまうでしょう。
カーネルのバイナリイメージを (フロッピーにコピーする前／した後に) 編集 する必要があります。 2 バイトのフィールド (リトルエンディアンに注意) をいくつか修正すれば、お使いのシステムで動くようになります。
バイト表現では以下のようになります。
3.5" : 0xA0 0x05
5.25" : 0xB0 0x04
dd か rawrite を用いてファイルをディスクに書き込んでください。
そのディ
スクを A: のフロッピードライブに入れ、「ルートディスクを入れるように」
というプロンプトが出るのを待って、お使いの配布パッケージのルートフロッ
ピーを入れてください。
まずドライバの作者が使っているバージョンのカーネルを手に入れる必要があ ります。バージョンの情報は恐らくドライバと同時に配布されているドキュメ ントに記述があるでしょう。
最新のものを含め、様々なバージョンのカーネルは
ftp://nic.funet.fi/pub/OS/Linux/PEOPLE/Linusにあります。名前は linux-version.tar.gz となっているは
ずです。
これらは tsx-11 などの 多くのサイトにもミラーされています。
ソースを手に入れたら /usr/src へ移動し、古い Linux のソースを
削除しましょう。バックアップとして残したい場合は以下のようにします。
mv linux linux-old
アーカイブを展開します。
gunzip < linux-0.99.12.tar.gz | tar xvfp -
パッチを当てます。パッチファイルで記述されているファイル名は、ファイル
システムの適当なディレクトリを基準として、そこからの相対パスで記述され
ています。パッチファイル中の出力ファイルの行を
調べる (^--- を grep すれば表示されます) ことで、
この基準ディレクトリがどこかわかります。例えば
--- ./kernel/blk_drv/scsi/Makefile
--- ./config.in Wed Sep 1 16:19:33 1993
のような行がパッチファイルにあったら、基準ディレクトリは
/usr/src/linux です。
ドライバのソースを適当な場所に展開します。アーカイブの中身を見るには以 下のようにします。
tar tfv patches.tar
展開したファイルは必要な場所に移動します。 SCSI のドライバファイル
は /usr/src/linux/kernel/drivers/scsi に置く必要があります。
パッチファイル中の基準ディレクトリに移動して以下のようにタイプすること でパッチが当たります。
patch -p0 < patch_file
パッチファイル中のファイル指定における、最初の方のディレクトリを無視する ように指定することもできます。例えば
--- linux-new/kernel/blk_drv/scsi/Makefile
のような指定がパッチファイル中にあり、これを /usr/src/linux
以下のファイルにパッチ当てしたい場合は、まず /usr/src/linux に
cd してから
patch -p1 < patches
と打ち込みます。これで linux-new は無視されます。
パッチ当てが終わったら、失敗したパッチがないか調べてください。パッチが
失敗すると # という拡張子がついたファイルができているはずです。
訳注: 普通この拡張子は.rejですが、patchのコンパイル時 のオプションによって、#になることもあります。
find /usr/src/linux/ -name "*#" -print
このようなファイルが存在したら、その中身を見てください。もしかしたら単
に RCS の識別子が違っているだけかもしれません。この場合は無害ですから
無視してかまいません。それ以外の場合は、手でパッチ当てをする必要がある
かもしれません。diff ファイルの形式とパッチ当てに関してはこの文書の範
囲外です。
カーネルの設定と再構築 もご覧になってください。
ときにはドライバの作者が自分の書いたドライバの .c や .h
ファイルへのパッチを提供していない場合もあります。またパッチ元の
カーネルのバージョンが古すぎて、うまくパッチが当たらない場合も
ありえます。
.c や .h などのファイルを
/usr/src/linux/drivers/scsi へコピーします。
/usr/src/linux/config.in を編集して
*
* SCSI low-level drivers
*
bool 'Always IN2000 SCSI support' CONFIG_SCSI_IN2000 y
Makefile にエントリを追加します。
/usr/src/linux/drivers/scsi/Makefile を編集して、以下のような
行を追加します。
ifdef CONFIG_SCSI_IN2000
SCSI_OBS := $(SCSI_OBJS) in2000.o
SCSI_SRCS := $(SCSI_SRCS) in2000.c
endif
Makefile 中の
scsi.a: $(SCSI_OBJS)
.c のファイルには先ほどコピーし
た .c のファイルを、.o のファイルには .c のファイルの
拡張子を .o に置き換えたものを書きます。
/usr/src/linux/drivers/scsi/hosts.c を編集して、
ヘッダファイルのための #include 行を追加します。
設定ファイルに加えた CONFIG_SCSI の値によって
プリプロセッサの処理を変更できるようにしておくと良いでしょう。
例えば、
#ifdef CONFIG_SCSI_GENERIC_NCR5380
#include "g_NCR5380.h"
#endif
#ifdef CONFIG_SCSI_IN2000
#include "in2000.h"
#endif
Scsi_Host_Template のエントリを
scsi_host[] 配列に追加する必要があります。
.h ファイルを見てみると例えば以下のような #define
行があるはずです。
#define IN2000 {"Always IN2000", in2000_detect, \
in2000_info, in2000_command, \
in2000_queuecommand, \
in2000_abort, \
in2000_reset, \
NULL, \
in2000_biosparam, \
1, 7, IN2000_SG, 1, 0, 0}
scsi_hosts[] 配列に追加します。
設定ファイルで定義したシンボルによってプリプロセッサの動作を
制御できるようにしておきましょう。
つまり
#ifdef CONFIG_SCSI_GENERIC_NCR5380
GENERIC_NCR5380,
#endif
#ifdef CONFIG_SCSI_IN2000
IN2000,
#endif
Compaq のシステムの多くでは PCI デバイスを検出するための 32 ビット拡張 BIOS がメモリにマップされています。メモリレイアウトが特殊なために、 Linux では この BIOS をアクセスすることができません。 Linux は (サポー トされているはずの) PCI SCSI ボードの検出に失敗すると、以下のようなメッ セージが出力されます。
pcibios_init: entry in high memory, unable to access
以下のファイルを手に入れてください。
ftp://ftp.compaq.com/pub/softpaq/sp0921.zipこれは自己解凍型のアーカイブで、BIOS32 のコードを再配置するためのプロ グラムが入っています。
訳注: このzipファイルをunzipすると、exeサフィックス を持った自己解凍型のアーカイブができます。
%d Hosts というメッセージを出した後にハングアップします。PCI のシステムの中には、BIOS 中で割り込みを禁止し、再び割り込みを 可能にせずに呼び出し元に制御を返してしまうものがあります。 以下のパッチでなおるはずです。
--- bios32.c.orig Mon Nov 13 22:35:31 1995
+++ bios32.c Thu Jan 18 00:15:09 1996
@@ -56,6 +56,7 @@
#include <linux/pci.h>
#include <asm/segment.h>
+#include <asm/system.h>
#define PCIBIOS_PCI_FUNCTION_ID 0xb1XX
#define PCIBIOS_PCI_BIOS_PRESENT 0xb101
@@ -125,7 +126,9 @@
unsigned long address; /* %ebx */
unsigned long length; /* %ecx */
unsigned long entry; /* %edx */
+ unsigned long flags;
+ save_flags(flags);
__asm__("lcall (%%edi)"
: "=a" (return_code),
"=b" (address),
@@ -134,6 +137,7 @@
: "0" (service),
"1" (0),
"D" (&bios32_indirect));
+ restore_flags(flags);
switch (return_code) {
case 0:
@@ -161,11 +165,13 @@
unsigned char present_status;
unsigned char major_revision;
unsigned char minor_revision;
+ unsigned long flags;
int pack;
if ((pcibios_entry = bios32_service(PCI_SERVICE))) {
pci_indirect.address = pcibios_entry;
+ save_flags(flags);
__asm__("lcall (%%edi)\n\t"
"jc 1f\n\t"
"xor %%ah, %%ah\n"
@@ -176,6 +182,7 @@
: "1" (PCIBIOS_PCI_BIOS_PRESENT),
"D" (&pci_indirect)
: "bx", "cx");
+ restore_flags(flags);
present_status = (pack >> 16) & 0xff;
major_revision = (pack >> 8) & 0xff;
@@ -210,7 +217,9 @@
{
unsigned long bx;
unsigned long ret;
+ unsigned long flags;
+ save_flags(flags);
__asm__ ("lcall (%%edi)\n\t"
"jc 1f\n\t"
"xor %%ah, %%ah\n"
@@ -221,6 +230,7 @@
"c" (class_code),
"S" ((int) index),
"D" (&pci_indirect));
+ restore_flags(flags);
*bus = (bx >> 8) & 0xff;
*device_fn = bx & 0xff;
return (int) (ret & 0xff00) >> 8;
@@ -232,7 +242,9 @@
{
unsigned short bx;
unsigned short ret;
+ unsigned long flags;
+ save_flags(flags);
__asm__("lcall (%%edi)\n\t"
"jc 1f\n\t"
"xor %%ah, %%ah\n"
@@ -244,6 +256,7 @@
"d" (vendor),
"S" ((int) index),
"D" (&pci_indirect));
+ restore_flags(flags);
*bus = (bx >> 8) & 0xff;
*device_fn = bx & 0xff;
return (int) (ret & 0xff00) >> 8;
@@ -254,7 +267,9 @@
{
unsigned long ret;
unsigned long bx = (bus << 8) | device_fn;
+ unsigned long flags;
+ save_flags (flags);
__asm__("lcall (%%esi)\n\t"
"jc 1f\n\t"
"xor %%ah, %%ah\n"
@@ -273,7 +288,9 @@
{
unsigned long ret;
unsigned long bx = (bus << 8) | device_fn;
+ unsigned long flags;
+ save_flags(flags);
__asm__("lcall (%%esi)\n\t"
"jc 1f\n\t"
"xor %%ah, %%ah\n"
@@ -292,7 +309,9 @@
{
unsigned long ret;
unsigned long bx = (bus << 8) | device_fn;
+ unsigned long flags;
+ save_flags(flags);
__asm__("lcall (%%esi)\n\t"
"jc 1f\n\t"
"xor %%ah, %%ah\n"
@@ -303,6 +322,7 @@
"b" (bx),
"D" ((long) where),
"S" (&pci_indirect));
+ restore_flags(flags);
return (int) (ret & 0xff00) >> 8;
}
@@ -311,7 +331,9 @@
{
unsigned long ret;
unsigned long bx = (bus << 8) | device_fn;
+ unsigned long flags;
+ save_flags(flags);
__asm__("lcall (%%esi)\n\t"
"jc 1f\n\t"
"xor %%ah, %%ah\n"
@@ -322,6 +344,7 @@
"b" (bx),
"D" ((long) where),
"S" (&pci_indirect));
+ restore_flags(flags);
return (int) (ret & 0xff00) >> 8;
}
@@ -330,7 +353,9 @@
{
unsigned long ret;
unsigned long bx = (bus << 8) | device_fn;
+ unsigned long flags;
+ save_flags(flags);
__asm__("lcall (%%esi)\n\t"
"jc 1f\n\t"
"xor %%ah, %%ah\n"
@@ -341,6 +366,7 @@
"b" (bx),
"D" ((long) where),
"S" (&pci_indirect));
+ restore_flags(flags);
return (int) (ret & 0xff00) >> 8;
}
@@ -349,7 +375,9 @@
{
unsigned long ret;
unsigned long bx = (bus << 8) | device_fn;
+ unsigned long flags;
+ save_flags(flags);
__asm__("lcall (%%esi)\n\t"
"jc 1f\n\t"
"xor %%ah, %%ah\n"
@@ -360,6 +388,7 @@
"b" (bx),
"D" ((long) where),
"S" (&pci_indirect));
+ restore_flags(flags);
return (int) (ret & 0xff00) >> 8;
}
BIOS アドレス : 0xd8000, 0xdc000, 0xd0000, 0xd4000,
0xc8000, 0xcc000, 0xe0000, 0xe4000
IO ポート : 0x140, 0x340
IRQ : 9, 10, 11, 12
DMA : 使用していません
IO : ポートマップ方式
BIOS が入っているボードではだいたいうまく動作するようです。入っていな いボード (Adaptec 1510、Sound Blaster16 SCSI など) では、カーネルのコ マンドラインオプションかコンパイル時の設定変更が必要になります。
PORTBASE、IRQ、SCSI_ID、RECONNECT、PARITY を
適当な値に定義してください。
「定義可能なパラメータ」のところを参考にしてください。
aha152x=<PORTBASE>[,<IRQ>[,<SCSI-ID>[,<RECONNECT>[,<PARITY>]]]]
SCSI-ID はホストアダプタの SCSI ID です。特に ID 7 が必要な他のデバイ スをつないでいない限り 7 にしておきましょう。
I/O アドレスを 0x340 に固定し、IRQ 11、SCSI-ID 7、 ディスコネクト/リコネクトを許可するようにするには、 以下のようなコマンドラインオプションを使うことになります。
aha152x=0x340,11,7,1
AUTOCONFコントローラが報告してきた設定を使う (152x のみ)
IRQ割り込みチャネルの設定変更 (9,10,11 or 12) (デフォルト 11)
SCSI_IDAIC-6260 の SCSI ID の設定変更 (0-7) (デフォルト 7)
RECONNECTターゲットからのディスコネクト/リコネクトの設定を 変更する (0 以外で許可、0 で禁止)
DONT_SNARFポートを登録しない (pl12 以下)
SKIP_BIOSTESTBIOS シグネチャのテストを 行わない (AHA-1510 または BIOS のない機器)
PORTBASEポートのベースアドレスを指定し、検出を行わない。
訳注: カーネル 2.0.27 に付属のドライバでは、DONT_SNARF はなくなっています。 また、PORTBASE は IOPORT に変更されています。
IO ポート : 0x330 and 0x334
IRQ : 9, 10, 11, 12, 14, 15
DMA チャネル : 5, 6, 7
IO : ポートマップ方式、バスマスタ方式
自動検出されるのは I/O アドレス 0x330 と 0x334 だけです。
aha1542=<PORTBASE>[,<BUSON>,<BUSOFF>[,<DMASPEED>]]
drivers/scsi/aha1542.h 中の AHA1542_SCATTER を 0 に
すると、(動作する、という言葉の定義によりますが) 無理矢理動作させる
こともできます。
訳注: スキャッタ/ギャザについて補足説明。
Linux は仮想記憶を採用していることはご存知ですね。 CPU から指定された仮想アドレスは、MMU によって物理アドレスに変換され ます。しかしこの変換が行われるのは CPU からのアドレスだけであって、 DMA やバスマスタ転送を行う場合のアドレスは、物理アドレスを使用しな ければなりません (PC/AT アーキテクチャの場合。ちなみに Sun の SPARCstation などは DMA も仮想アドレスを使います)。 仮想アドレスから物理アドレスへの対応づけは、ページと呼ばれる単位ごとに 行われますから、プログラムから見て仮想アドレスが連続していても、物理 アドレスは飛び飛びになっているということがあり得ます。 このような場合にも、コントローラを一度設定するだけで、 飛び飛びの物理アドレスにデータを転送してくれるような機能の ことを、スキャッタ/ギャザといいます。 コントローラがスキャッタ/ギャザをサポートしていない場合には、飛び飛びに なっている物理アドレスの個数分だけ、DMA を複数回行なう必要があります。
154xC の初期のカードでは SCSI 信号の立ち上がりが速すぎるため、 インピーダンスの正しくないケーブルを使うと信号の反射が起こって しまうことがありました。
新しいボードでは幾分改善されているようですが、それでもケーブルや ターミネーションに対しては非常に敏感です。
おそらくターミネーションの問題でしょう。ソフトウェアでホストアダプタの ターミネーションを無効にするには、スイッチ 1 をオフにする必要があります。 この章の「よくある問題」の その1 や その3、それに よくある問題や 不安定なシステムの章も参考にしてください。
複数のデバイスが同時に使用されると、システムがフリーズしたように見える
ことがあります。この場合はデバイスのメーカに連絡して見るとよいでしょう。
ファームウェアのアップグレードによってこの問題は解決されているかもしれ
ません。最後の手段としては aha1542.h 中の AHA1542_MAILBOX を
1 に変更する方法があります。これは SCSI バスに同時に出力されるコマンド
を実効的に一つだけにするので、この状況を解決できるかもしれません。しかし
遅いテープドライブや CD-ROM デバイスを用いている場合は、実用的な解決法に
はならないでしょう。
この章の「よくある問題」の その1 や その2、それに よくある問題、 よくある問題: SCSI システムがロックアップする などの項も 参考にしてください。
BIOS の拡張機能のうち、 1G 以上のディスクに対する拡張マッピング、3 台 以上のディスクのサポート機能、およびバスの自動スキャンを無効にします。 あるいはカーネルを 0.99.14k 以上にアップグレードしましょう。
Unable to determine Adaptec DMA priority. Disabling board.
これは古い BusLogic のドライバとの間で衝突が起こってしまうためです。カー ネルを再構築して BusLogic のドライバを含まないカーネルを作るか、カーネ ルのコマンドラインオプションを用いて BusLogic のドライバに別のアドレス を検出するようにさせます。もし使っている Adaptec のボードがポートアド レス 0x334 を使っており、0x330 を使っているボードが何もないようでした ら、以下のようなコマンドラインオプションになります。
buslogic=0x330
Adaptec のファームウェアのあるバージョンにはバグがあります。 BIOS を v2.11 以上にするとこの問題は解決されているそうです。
スロット : 1-8
IO ポート : EISA ボードなので関係無し
IRQ : 9, 10, 11, 12, 14, 15
DMA チャネル : EISA ボードなので関係無し
IO : ポートマップ方式、バスマスタ方式
全ての設定で動作します。
ありません。
aha1740: Board detected, but EBCNTRL = %x, so disabled it.
使用中のボードがエンハンストモードではないのでボードを有効にできないためです。 1542 モードでボードを動作させることはできません。
訳注: カーネル 2.0.27 では、294x もサポートされています。
Adaptec 294x もサポートする新しいバージョンは以下から入手できます。
ftp://ftp.ims.com/pub/Linux/aic7xxx
274x 284x 294x
EISA スロット : 1-12 N/A N/A
IO ポート : N/A ALL ALL
IRQ : ALL ALL ALL
DMA チャネル : N/A ALL N/A
IO : ポートマップ方式、バスマスタ方式
拡張マッピングを強制するには以下のようにします。
aha274x=extended
CONFIG_PCI を指定しておく必要があります。
IO ポート : 0x100, 0x110, 0x200, 0x220
IRQ : 10, 11, 14, 15
DMA チャネル : 使用していない
IO : ポートマップ方式
BIOS は不必要。
ありません。
(この節は Leonard N. Zubkoff
<lnz@dandelion.com> に著作権があります。)
(Buslogic のドライバの文書としてより詳細なものを望む方は
README.BusLogic を見てください。)
BusLogic MultiMaster SCSI Driver for Linux
Version 1.2.2 for Linux 1.2.13
Version 1.3.2 for Linux 1.3.88
ftp://ftp.dandelion.com/BusLogic-1.2.2.tar.gz
ftp://ftp.dandelion.com/BusLogic-1.3.2.tar.gz
16 April 1996
Leonard N. Zubkoff
Dandelion Digital
lnz@dandelion.com
BusLogic Inc. は高性能な SCSI ホストアダプタを何種類も設計、生産しています。
MultiMaster ASIC 技術を用いることで、これらのホストアダプタでは使用する
バスが異なってもプログラミングのインターフェースは共通化されています。
このドライバは現存する全ての BusLogic MultiMaster ホストアダプタをサポート
しており、恐らく将来リリースされるシリーズ製品に対してもそのまま (あるいは
わずかな修正で) 対応できるでしょう。 FlashPoint アーキテクチャに基づいた
ホストアダプタはこのドライバではサポートしていません。
こちらに関しては README.FlashPoint ファイルを参考にしてください。
Linux ではサポート外の FlashPoint LT から、サポート対象である BT-948 へ
アップグレードできる Linux ユーザ向けのキャンペーンに関する情報があります。
私がこの完全に新しい BusLogic のドライバを Linux 向けに書くに当たっては、 以下のような事を目標にしました。まず BusLogic のホストアダプタおよび SCSI 機器の性能を最大限に発揮させること、そして高い信頼性を持ち、高性能が 要求される重要な用途でも安心して使えるようにすることです。 主要な SCSI 拡張機能やエラー回復機能は Linux カーネルのコマンドライン オプションで設定できるようになっており、必要に応じてドライバの性能や エラー回復機能の微調整が可能です。
BusLogic は私の仕事に非常に好意的でした。私は同社の製品を Linux コミュニ ティに強く推薦します。 1995 年の 11 月に、私は彼らの最新の MultiMaster 製品である BT-948 PCI Ultra SCSI ホストアダプタをβテストすることができました。 また 1996 年の 9 月には BT-958 PCI Wide Ultra SCSI を同じく提供して もらいました。これによって BusLogic 社は、社内のテストグループでは 行えなかったようなテストを質量ともに行なうことができましたし、 Linux コミュニティは Linux 向けによくテストされた高性能なホストアダプタを 販売前に手に入れることができました。 この際に私は同社の技術スタッフと直接話し合うことができ、彼らの製品の 内部動作に関してより深く知ることができました。 また逆に彼らには Linux コミュニティが必要としているものとその潜在的な 需要について伝えることができました。彼らの Linux に対する関心と協力とに 深く感謝します。
Linux で起こった問題についてメーカの技術サポートに問い合わせると 「あなたの使い方はサポート対象外です」などと言われがちなものですが、 BusLogic ではそんなことはありません。 彼らの最新製品の宣伝では「BusLogic のホストアダプタは以下のような全ての 主要な OS で用いることができます:... Linux ...」とさえ記述されているのです。
BusLogic の所在地は 4151 Burton Drive, Santa Clara, California, 95054, USA で、電話番号は 408/492-9090、 FAX は 408/492-1542 です。 anonymous FTP サイトが ftp://ftp.buslogic.com に、BBS が 408/492-1984 にあります。 BusLogic の技術サポートには電子メール techsup@buslogic.com 、電話 408/654-0760、 FAX 408/492-1542 で 連絡をとることができます。 ヨーロッパおよび日本における連絡先は Web サイトから得ることができます。
以下のリストは BusLogic 社のホストアダプタのうち、現在までにサポート されているものの一覧です。以下の表にない BusLogic 製品を購入しようと 考えている方には、その製品のサポートがされているか、あるいはされる 予定があるかどうかを筆者まで尋ねてからにすることをお勧めします。
"W" Series Host Adapters: BT-948 PCI Ultra Fast Single-ended SCSI-2 BT-958 PCI Ultra Wide Single-ended SCSI-2 BT-958D PCI Ultra Wide Differential SCSI-2 "C" Series Host Adapters: BT-946C PCI Fast Single-ended SCSI-2 BT-956C PCI Fast Wide Single-ended SCSI-2 BT-956CD PCI Fast Wide Differential SCSI-2 BT-445C VLB Fast Single-ended SCSI-2 BT-747C EISA Fast Single-ended SCSI-2 BT-757C EISA Fast Wide Single-ended SCSI-2 BT-757CD EISA Fast Wide Differential SCSI-2 BT-545C ISA Fast Single-ended SCSI-2 BT-540CF ISA Fast Single-ended SCSI-2 "S" Series Host Adapters: BT-445S VLB Fast Single-ended SCSI-2 BT-747S EISA Fast Single-ended SCSI-2 BT-747D EISA Fast Differential SCSI-2 BT-757S EISA Fast Wide Single-ended SCSI-2 BT-757D EISA Fast Wide Differential SCSI-2 BT-545S ISA Fast Single-ended SCSI-2 BT-542D ISA Fast Differential SCSI-2 BT-742A EISA Single-ended SCSI-2 (742A revision H) BT-542B ISA Single-ended SCSI-2 (542B revision H) "A" Series Host Adapters: BT-742A EISA Single-ended SCSI-2 (742A revisions A - G) BT-542B ISA Single-ended SCSI-2 (542B revisions A - G)
AMI の FastDisk ホストアダプタは BusLogic の完全なクローンなので、 このドライバで動作させることができます。
BT-948/958/958D PCI Ultra SCSI ホストアダプタの機能には、Linux をイン ストールする際に (場合によっては) 注意しなければならない点があります。
工場出荷時の設定では、BT-948/958/958D のボードはマザーボードの PCI BIOS が 割り当てた I/O ポートのみを認識するようになっていて、以前の BusLogic の SCSI ホストアダプタが応答した ISA 互換の I/O ポートには応答しません。 このドライバは PCI の I/O ポート割り当て機能をサポートしていますので、 こちらの設定が望ましいでしょう。しかし何らかの理由 (パッケージの ブートカーネルがこのドライバを使っていない場合など) で、 古い BusLogic のドライバを使わなければならない場合には、 AutoSCSI の設定で古い ISA 互換の I/O ポートを用いるようにすることもできます。
この古い機能との互換性を持たせるオプションを有効にするには、システムの ブート時に Ctrl-B を押して AutoSCSI を立ち上げ、「Adapter Configration」、 「View/Modify Configration」と選んで、その中の「ISA Compatible Port」を 「Disable」から「Primary」か「Alternate」に変えてください。このドライバが インストールされた後には、I/O ポートの衝突を防ぐため、 この「ISA Compatible Port」は「Disable」に戻しておく必要があります。 少々古い製品である BT-946C/956C/956CD にもこの設定オプションがありますが、 工場出荷時の設定は「Primary」になっています。
BusLogic の PCI ホストアダプタを複数枚備えたシステムでは、PCI スロットの 検索の順番が BT-948/958/958D の場合と BT-946C/956C/956CD の場合とで逆に なることがあります。 SCSI のディスクから正しくブートさせるには、ホストアダプタの BIOS とカー ネルの間で、ブートデバイスと認識しているドライブが一致している必要があり ます。 つまり PCI ホストアダプタの認識の順序が同じでなければならないのです。 マザーボードの PCI BIOS は通常 PCI ホストアダプタを番号付けする標準的な 機能を持っており、 Linux のカーネルではこれを用いています。 PCI BIOS のインプリメントによって、PCI スロットをバス番号とデバイス番号の 昇順にカウントするか降順にするかは異なっています。
不幸なことに Microsoft は Windows 95 で PCI スロットの番号付けをバス番号と デバイス番号の昇順に固定することにしてしまい、 Windows 95 対応の証明をもら うにはホストアダプタの BIOS はこの順序を守らなければならなくなりました。 したがって BT-948/958/958D の工場出荷値ではバス番号とデバイス番号の昇順に ホストアダプタの番号付けをすることになっています。この機能を無効にするには、 システムブートの際に Ctrl-B で AutoSCSI を起動し、「Adapter Configuration」 「View/Modify Configreation」を選んで Ctrl-F10 を押してください。 そして「Use Bus And Device # For PCI Scanning Seq」オプションを OFF に してください。
このドライバは PCI の検索手順のオプション設定を問い合わせて、ホストアダプタ をアダプタの BIOS と同じ順序で認識するようにしています。
BusLogic の広報用メーリングリストは Linux ユーザに新しいドライバの リリースを知らせたり、 BusLogic SCSI ホストアダプタの Linux サポート関連の アナウンスを伝えるのに用いられています。 このメーリングリストに参加するには、本文に「subscribe」と書いたメールを BusLogic-announce-request@dandelion.com まで送ってください。
(この節は Leonard N.Zubkoff <lnz@dandelion.com> に 著作権があります)
現在のところ FlashPoint LT/DT/LW (BT-930/932/950) の Linux ドライバは ありませんし、将来にわたってリリースされるかどうかもはっきりしていません。 FlashPoint のボードは MultiMaster のボードとはアーキテクチャが異なっていて、 オンボードの CPU は無く SCSI シーケンサのみが搭載されています。 FlashPoint はデスクトップパソコン用の製品であり、 Linux のような高機能な マルチタスク OS に特に向いているというわけではありません。
MultiMaster BT-948/958 にはオンボードの CPU とメールボックスプログラム インターフェース機能があり、ホストの OS とアダプタの間で並列化とパイプ ライン化が可能になっています。 一方 FlashPoint のボードではホストの CPU への割り込みが頻繁に起こります。 システムの負荷が高くなるとこの割り込みが重荷になってしまい、 BT-948/958 が良い性能を維持するのに対して、FlashPoint の性能は急速に低下 します。 さらに BT-948/958 のファームウェアには SCSI バスとの信号のやり取りに関する 低レベルの命令がすでに含まれています。 FlushPoint では Linux のドライバが これらの命令を全て持つ必要があるので、SCSI シーケンサとの間で命令をやり取り して仕事をするのに多くの時間がかかってしまいます。実売価格ではそれほど差が ありませんが、 Linux で用いるには BT-948 と BT-958 の方がはっきりと優れて いるのです。
< 引用はじめ >
ANNOUNCEMENT
BusLogic FlashPoint/BT-948 Upgrade Program
1 February 1996
十月終わりにリリースされて以来、BusLogic FlashPoint LT は Linux コミュニ ティのメンバーにとって問題の種になってきました。この Ultra SCSI 対応の 新製品には Linux ドライバがないためです。 FlashPoint はデスクトップパソコン用の製品という位置づけにあり、Linux の ような高性能のマルチタスク OS に特に向いているというわけではありません。 しかし PC のベンダは FlashPoint を最新製品と言って売り込み、ハイエンドの システムにも MaltiMaster 製品ではなくこちらを付けてきました。その結果、 BusLogic の SCSI ホストアダプタは全て Linux でサポートされていると思って うっかりこのようなシステムを買ってしまった多くの人々が残念な思いをする ことになってしまいました。 FlashPoint はまだサポートされておらず、将来 されるにしても相当先の事になるでしょう。
この問題が認識されて以来、BusLogic は主要な OEM 先と連絡を取り、 BT-946C/956C MultiMaster のカードを選択可能にすること、そして 間違って FlashPoint を購入してしまった Linux ユーザに BT-946C への アップグレードを可能とすることを申し合わせました。 これで新規システムを購入する多くの人が救われるでしょうが、 しかし Linux ユーザへの FlashPoint サポートの問題の一部を解決したに すぎません。 FlashPoint に対応している OS のために製品を買って、 後に Linux への移行を決めた人や、対応していると思って FlashPoint LT を 購入し、返品出来なくなってしまった人には何の助けにもならないのです．
12 月の半ばに私は BusLogic の上位管理職に会談を求め、FlushPoint への Linux やフリーソフトの対応に関して話し合いました。 Linux コミュニティに対する BusLogic の態度について様々な噂が流れていた ので、これらについて直接聞くのがベストだと思ったのです。 私は夜の 11 時に電子メールを送り、翌日の午後に会合がもたれました。 残念ながら会社における歯車と言うのは (特に会社が買収されようとしている ときは) 回転が遅いもので、詳細までがはっきり決定されて公式な声明が 行われるのは現在となってしまいました。
BusLogic は現在のところ FlushPoint のドライバを書くために必要な情報を サードパーティに公開していません。現存している FlushPoint のドライバは 全て BusLogic のエンジニアによって直接書かれたものです。 外部の開発者が助力なしにドライバを書くために必要な、FlushPoint の詳細な 情報を記した文書はないのです。 BusLogic の社内には FlushPoint のアーキテクチャを公開すべきでないという 意見の人もおり、この議論はまだ決着していません。いずれにしろ、 もしドキュメントが今日入手できたとしても、まっとうに動作するドライバを 書くには長いことかかるでしょう。このドライバを書くのに必要な努力がその 価値に見合うとは私は納得していません。
しかし BusLogic は Linux コミュニティに高性能な SCSI を提供し続けることを 確約しており、FlashPoint LT を購入してしまったために Linux を動作できない ユーザを座視することは望んでいません。そこで BusLogic はアップグレード キャンペーンを行ない、世界中の Linux ユーザに FlushPoint LT と 新製品 BT-948 MultiMaster PCI Ultra SCSI ホストアダプタとを交換できる ようにしました。 BT-948 は BT-946C の後継の Ultra SCSI アダプタであり、BT-946C と FlashPoint LT の両方の利点を受け継いでいます。終端処理の自動化や ファームウェアのアップグレードが容易な flash PROM の採用、そしてもちろん 現在の Linux ドライバへの互換性もあります。 このアップグレードに必要な価格は 45US$ で、 BusLogic のテクニカルサポートが実行しています。 連絡先は電子メールが techsup@BusLogic.com、 電話が +1 408 654-0760、 FAX が +1 408 492-1542 です。
私は BT-948 のβテスタであり、私が書いた BusLogic ドライバの 1.2.1 と 1.3.1 にはこの BT-948 へのサポートが含まれています。 Ultra SCSI MultiMaster カードへの additional cosmetic サポートは続く リリースで追加される予定です。 BusLogic との共同テストの結果、ファームウェアにあったいくつかのバグが発見・ 修正されました (ファームウェアのバージョンが 5.05R 以降であることを確認 して下さい)。 私が高負荷をかけて使用している Linux システムはエラー回復プロセスを テストするに理想的な環境です。エラー回復は製品のシステムではめったに 用いられませんが、しかしシステム全体の安定性には必要不可欠の機能です。 ファームウェアのエンジニア達と直接一緒に仕事ができ、ファームウェアの デバッグ環境下で障害を再現できたことは特に便利でした。 私が組込みのファームウェアで仕事していた頃とは大違いでした。 私は現在性能のテストを行なっており、そう遠くない将来にまとまった データを報告できる予定です。
BusLogic は私にこのアナウンスをするように言ってきました。 FlashPoint のサポートに関する質問の多くが私宛の電子メールや私の参加 している Linux のニュースグループに寄せられているからです。 まとめますと、BusLogic は Linux ユーザ向けに、 サポート外の FlashPoint LT (BT-930) をサポートされている BT-948 へ $45 で アップグレードする道を提供しています。 アップグレードを受けるには、BusLogic のテクニカルサポート techsup@BusLogic.com か +1 408 654-0760 へ連絡してください。
Leonard N. Zubkoff
lnz@dandelion.com
<引用終わり>
EATA-DMA プロトコルを使っているもの全て。 以下のようなものがあります。
DPT Smartcache (Plus) family: PM2011 ISA Fast Single-ended SCSI-2 PM2012B EISA Fast Single-ended SCSI-2 DPT Smartcache III family: PM2021 ISA Fast Single-ended SCSI-2 PM2021W ISA Wide Single-ended SCSI-2 PM2022 EISA Fast Single-ended SCSI-2 PM2022W EISA Wide Single-ended SCSI-2 PM2024 PCI Fast Single-ended SCSI-2 PM2024W PCI Wide Single-ended SCSI-2 PM2122 EISA Fast Single-ended SCSI-2 PM2122W EISA Wide Single-ended SCSI-2 PM2124 PCI Fast Single-ended SCSI-2 PM2124W PCI Wide Single-ended SCSI-2 PM2322 EISA Fast Single-ended SCSI-2 PM2322W EISA Wide Single-ended SCSI-2 DPT Smartcache VI family: PM2041W ISA Wide Single-ended SCSI-2 PM2041UW ISA Ultra Wide Single-ended SCSI-2 PM2042W EISA Wide Single-ended SCSI-2 PM2042UW EISA Ultra Wide Single-ended SCSI-2 PM2044W PCI Wide Single-ended SCSI-2 PM2044UW PCI Ultra Wide Single-ended SCSI-2 PM2142W EISA Wide Single-ended SCSI-2 PM2142UW EISA Ultra Wide Single-ended SCSI-2 PM2144W PCI Wide Single-ended SCSI-2 PM2144UW PCI Ultra Wide Single-ended SCSI-2 PM2322W EISA Wide Single-ended SCSI-2 PM2322UW EISA Ultra Wide Single-ended SCSI-2 DPT SmartRAID family: PM3021 ISA Fast Single-ended SCSI-2 PM3021W ISA Wide Single-ended SCSI-2 PM3122 EISA Fast Single-ended SCSI-2 PM3122W EISA Wide Single-ended SCSI-2 PM3222 EISA Fast Single-ended SCSI-2 PM3222W EISA Wide Single-ended SCSI-2 PM3224 PCI Fast Single-ended SCSI-2 PM3224W PCI Wide Single-ended SCSI-2 PM3334W PCI Wide Single-ended SCSI-2 PM3334UW PCI Ultra Wide Single-ended SCSI-2
この他、上記のボードに対応するディファレンシャル SCSI の ボードもサポートされています。
また以下のメーカのコントローラにもサポートされているものが あります。
NEC、AT&T、SNI、AST、Olivetti、Alphatronix
スロット : ALL
IO ポート : ALL
IRQ : 全レベル、エッジトリガ
DMA チャネル : ISA のものは全て、EISA/PCI は関係無し
IO : ポートマップ方式、バスマスタ方式
SCSI Channels : ALL
全ての設定で動作します。
EATA-DMA ドライバの最新バージョンは以下から入手できます。
ftp://ftp.i-Connect.Net:/pub/Local/EATA/EATA メーリングリストは EATA-DMA および EATA-PIO ドライバを使用してい る Linux ユーザに議論の場と新バージョンその他のアナウンスの場を提供し ています。メーリングリストに参加するには、 メッセージ本文に「subscribe」と書いたメールを linux-eata-request@i-connect.net 宛に 送ってください。
/proc/scsi サポート
より詳細なコマンドの統計をとるには以下を実行してください。
echo "eata_dma latency" > /proc/scsi/eata_dma<driver_no>
これを再び off にするには以下のようにします。
echo "eata_dma nolatency" > /proc/scsi/eata_dma<driver_no>
解決法は、ascsi* のブートディスクを使うことです。
hd.c: ST-506 interface disk with more than 16 heads detected,
probably due to non-standard sector translation. Giving up.
(disk %d: cyl=%d, sect=63, head=64)
hdc: probing with STATUS instead of ALTSTATUS
hdc: MP0242 A, 0MB w/128KB Cache, CHS=0/0/0
hdc: cannot handle disk with 0 physical heads
hdd: probing with STATUS instead of ALTSTATUS
hdd: MP0242 A, 0MB w/128KB Cache, CHS=0/0/0
hdd: cannot handle disk with 0 physical heads
<BIOS : 2.0, 3.0, 3.2, 3.4, 3.5
<BIOS アドレス : 0xc8000, 0xca000, 0xce000, 0xde000
<IO ポート : 0x140, 0x150, 0x160, 0x170
<IRQ : 3, 5, 10, 11, 12, 14, 15
<DMA チャネル : 使用しません
<IO : ポートマップ方式
全ての設定で動作します。 BIOS がインストールされていることが必要です。
ありません。
disktab を使用する必要があります。
IO ポート : all
IRQ : all
DMA チャネル : DMA は使用しません
IO : ポートマップ方式
できません。
GENERIC_NCR5380_OVERRIDE を IO ポート、IRQ、DMA、およびボード形式
からなる配列データとして定義します。
ポート 0x330、IRQ 5 の NCR5380 の場合は以下のようになります。
#define GENERIC_NCR5380_OVERRIDE {{0x330, 5, DMA_NONE, BOARD_NCR5380}}
ポート 0x350 の T130B の場合なら以下のようになります。
#define GENERIC_NCR5380_OVERRIDE {{0x350, 5, DMA_NONE, BOARD_NCR53C400}}
古いバージョンのコードでは BOARD_* のエントリが無視されるかもしれません。
IRQ の部分に IRQ_NONE と IRQ_AUTO が使えます。
ncr5380=port,irq
ncr5380=port,irq,dma
ncr53c400=port,irq
irq を使わない場合は 255、自動選択する場合は 254 にします。
NCR5380 互換レジスタのベースアドレスからのオフセットは 8 です。 従って、ベースアドレスが 0x350 ならば、カーネルのコマンドラインから 以下のように入力してください。
ncr5380=0x358,254
パブリックリリース 6 以前の NCR5380 汎用ドライバは これらのボードの割り込みに対応していません。 バージョンアップして下さい。
ベースアドレス : ALL
IRQ : ALL
DMA チャネル : PCI なので関係なし
IO : ポートマップ方式、バスマスタ方式
PCI BIOS が必要です。デバイスのスキャンやコンフィギュレーション空間の 読み出しには PCI BIOS のルーチンを使っています。
ドライバは初期化の際、いくつかのレジスタにプログラムされている値を用います。 従って BIOS がインストールされている必要があるのです。
訳注: 最新のカーネル (2.0.27) では、ディスコネクト/リコネクトは サポートされています。
ドライバの最新リリース版は以下のところから手に入ります。
ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/ncr53c810現在のところここには 1.2.10 以降へのパッチが置いてありますが、 次のリリースでは 1.3.x だけになります。これらのパッチはすべて 完璧に当たるとは限りません。ELF 対応パッチや他のパッチが開発 者である私のベースシステムには既に当たっているからです。 もしパッチの際の障害 (４つあります) を手動で訂正できない場合は、 これらのパッチは使わないで下さい。パッチは最新のものだけが必要です。 インクリメンタルなパッチではありません。
次のリリースが待てず、NCR のドライバを 1.3.x カーネルで使いたいという方の ために、 Harald Evensen <Harald.Evensen@pvv.unit.no> が 1.3.x 用の パッチを公開しています。
ftp://ftp.pvv.unit.no/pub/Linux/ALPHA/ncrこれらのパッチは問題なく当たるはずです。
まずこれらのディレクトリの README ファイルをすべて読んで下さい。 またアルファ版のコードを用いたい場合は NCR メーリングリストにも 入って下さい。ここでは暫定的なバグフィックスや次バージョンの リリース情報などがポストされます。
参加するには以下のような内容をメール本文に書いて、 majordomo@colorado.edu に 送って下さい。
subscribe ncr53c810
参加をやめる場合にはメール本文に以下のような内容を書いて同じアドレスに 送って下さい。
unsubscribe ncr53c810
訳注: 特に neptune や mercury チップセットは危ないようです。
"scsi%d: IRQ0 not free, detaching"
"scsi%d: IRQ255 not free, detaching"
drivers/scsi/ncr53c7,8xx.c の pci_init() 関数を変更すると
この問題を回避することができます。
irq = my_irq;
return normal_init (tpnt, board, chip, (int) base,
(int) io_port, (int) irq, DMA_NONE, 1, bus, device_fn,
options);
ncr53c810=xxx などが機能しない
現在のカーネルでは init/main.c にこれらのオプションへの
エントリポイントが無いためです。これは実は根拠があってのことです。
コマンドラインオプションが与えられていると、ドライバは必ずそのパラメー
タでボードの自動検出を行ないます。もしコマンドラインの設定が PCI の設
定ルーチンで得られるものと異なると、問題が生じることになります。
実際にコマンドラインによる指定が必要となるのは、PCI のハードウェアと
BIOS が壊れている場合でしょうが、この場合はエラー復帰ルーチンも
機能しないので、コマンドラインオプションにはほとんど価値がないのです。
最後に。利用者がコマンドラインオプションを必要だと考えるのは、ドライバ
が設定などのエラーメッセージを出したときだけです。が、ドライバが設定に
問題があると言ってきたときは、システムの設定に問題があるか、あるいはシ
ステムが壊れているかなのです。このような場合コマンドラインオプションを
使っても問題は解決しません。
init/main.c に適当なエントリポイントを追加すればコマンドライン
オプションを有効にすることはできるかもしれませんが、これは完全にサポート
の範囲外であるだけでなく、おそらく動作もしないでしょう。
訳注: 2.0.27 のドライバは、同期転送をサポートしています。
ベースアドレス : 0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000, 0xde000
IRQ : 3, 5
DMA チャネル : 使用されません
IO : メモリーマップ方式
アドレスに関してのみスキャンを行ないます。 IRQ は 5 とみなされます。BIOS がインストールされている必要があります。
OVERRIDE をベースアドレスに、CONTROLLER を FD もし
くは SEAGATE のどちらかに、IRQ をシステムの IRQ にそれぞれ
定義します。
st0x=address, irq または tmc8xx=address,irq
(0.99.13b 以降のカーネルで動作します)
ハンドシェイクは以下のような手順で行われます。
コマンドを読み込んで処理するのが遅いデバイスでは、 REQ/ACK ハンドシェ イクに 12us 以上の時間がかかってしまいます。するとドライバで指定されて いる経過時間が過ぎても REQ がデアサートされないので、 一つの REQ パルスに対して複数バイトのデータを送ってしまいます。
カーネル 0.99.12 にはバグがあって、アービトレーションのコードを 書き換えた結果セレクションが失敗するようになっていました。 0.99.13 で修正されています。
出荷時のボードのデフォルト設定は MSDOS 向けになっています。 つまり割り込みが無効になっているのです。割り込みを有効にする ジャンパスイッチは、 Seagate のボードではジャンパ W3 (ST01) または JP3 (ST02) で、IRQ 5 を選択するには F と G のピンを ショートします。
scsi_devices 配列の
broken フィールドの値を用いて、デバイスごとに選択する
ようにしています。
もし問題が生じたら、該当するデバイスを broken が 0 にリセット
されないデバイスのリストに登録してください。
現在リストには TENEX CDROM ドライブのみが登録されています。
seagate.h を編集して、STAT_MSG と STAT_CD の定義を交換し、
カーネルを再コンパイルして下さい。
その際 CONTGROLLER を SEAGATE に定義し、
IRQ と OVERRIDE を適当な値に設定して下さい。
fdisk しようとすると、HDIO_REQ か
HDIO_GETGEO ioctl が失敗したというエラーメッセージや、
以下のようなエラーメッセージが表示される。
You must set heads sectors and cylinders. You can do this from the extra functions menu.パーティションの作成 を 見て下さい。
seagate.c には以下のようなコードがあるはずです。
cli();
DATA = (unsigned char) ((1 << target) | (controller_type == SEAGATE ? 0x80 : 0x40));
CONTROL = BASE_CMD | CMD_DRVR_ENABLE | CMD_SEL |
(reselect ? CMD_ATTN : 0);
sti();
cli();
CONTROL = BASE_CMD | CMD_DRVR_ENABLE | CMD_SEL |
(reselect ? CMD_ATTN : 0);
DATA = (unsigned char) ((1 << target) | (controller_type == SEAGATE ? 0x80 : 0x40));
sti();
FAST または FAST32これらを定義すると 可能な場合にはブラインド転送を行ないます。
ARBITRATEホストアダプタが SCSI-II 互換の アービトレーションを行なうようにします (バスフリーフェーズを待って いきなりセレクションをはじめるのではなく)。 配布版のソースを再構成する時には、LUN 当たりひとつのコマンドを 実行するように変更する予定です (訳注: つまり今はそうなっていないと いうことか？)。
SLOW_HANDSHAKESeagate のソースコードのハンドシェイクの スピードについていけないイカレたデバイス (ある種の CD ROM など) を使う 時に定義してください。
SLOW_RATE=xハンドシェイクが正しく動作しないときに デフォルトの転送レートにする値を x に指定します。
IO ポート : 0x388, 0x384, 0x38x, 0x288
IRQ : 10, 12, 14, 15
(重要) : IRQ はこのボードのサウンド機能が用いる IRQ とは
別にする必要があります。
DMA : このボードの SCSI 機能では用いません。
IO : ポートマップ方式
BIOS は必要ありません。
PAS16_OVERRIDE を IO ポートと IRQ の配列として定義して下さい。
ポート 0x388、IRQ10 の場合ならば以下のようになります。
#define PAS16_OVERRIDE ((0x388, 10))
pas16=port,irq
AUTOSENSE定義されていると CHECK CONDITION ステータスを 返してくるコマンドに対して自動的に REQUEST SENSE が実行されます。
PSEUDE_DMA擬似 DMA のハードウェアを使用できるようにします。 性能は I/O ポーリングを使ったものの 3-4 倍になります。
PARITYパリティチェック機能を有効にします。 まだサポートされていません。
SCSI2SCSI-II タグ付きコマンドキューイングをサポートします。 テストされていません。
UNSAFE割り込みを許可したまま擬似 DMA 転送を行います。 高速シリアル通信でデータ落ちが生じる場合にだけ使って下さい。 その場合でも、転送サイズを変更する方が良い結果が得られるでしょう。
USLEEPディスコネクトを行なわないデバイスをサポートします。 テストされていません。
PSEUDO_DMA の定義を無効にして下さい。
drivers/scsi/pas16.c の中の #define PSEUDO_DMA を
#undef PSEUDO_DMA に修正します。
後者の方法は最後の手段と思って下さい。この方法を選ぶと著しく性能が落ち
てしまいます。
ベースアドレス : 0xcc000, 0xc8000, 0xdc000, 0xd8000
IRQ : なし, 3, 5, 7 (全てのボード)
10, 12, 14, 15 (T128F のみ)
DMA : 使用していません
IO : メモリーマップ方式
全ての設定において動作します。BIOS がインストールされている必要があります。
T128_OVERRIDE をベースアドレスと IRQ からなる配列として定義します。
例えばアドレス 0xcc000、IRQ 5 のボードの場合には以下のようになります。
IRQ の指定には IRQ_NONE と IRQ_AUTO も使えます。
#define T128_OVERRIDE ((0xcc000, 5))
t128=address,irq
AUTOSENSE定義されていると CHECK CONDITION ステータスを 返してくるコマンドに対して自動的に REQUEST SENSE が実行されます。
PSEUDE_DMA擬似 DMA のハードウェアを使用できるようにします。 性能は I/O ポーリングを使ったものの 3-4 倍になります。
PARITYパリティチェック機能を有効にします。 まだサポートされていません。
SCSI2SCSI-II タグ付きコマンドキューイングをサポートします。 テストされていません。
UNSAFE割り込みを許可したまま擬似 DMA 転送を行います。 高速シリアル通信でデータ落ちが生じる場合にだけ使って下さい。 その場合でも、転送サイズを変更する方が良い結果が得られるでしょう。
USLEEPディスコネクトを行なわないデバイスをサポートします。 テストされていません。
PSEUDO_DMA の定義を無効にして下さい。
drivers/scsi/pas16.c の中の #define PSEUDO_DMA を
#undef PSEUDO_DMA に修正します。
後者の方法は最後の手段と思って下さい。
この方法を選ぶと著しく性能が落ちてしまいます。
IO ポート : 0x130, 0x140, 0x210, 0x230, 0x240, 0x310, 0x330, 0x340
IRQ : 10, 11, 14, 15
DMA チャネル : 5, 6, 7
IO : ポートマップ方式、バスマスタ方式
ポートが 0x310 の場合は機能しません。BIOS は必要ありません。
コンパイル時のみです。PORT_OVERRIDE を定義します。
hd.c: ST-506 interface disk with more than 16 heads detected, probably due to non-standard sector translation. Giving up. (disk %d: cyl=%d, sect=63, head=64)これは Ultrastor のボードを WD1003 のエミュレーションモードで 動作させているときに起こります。解決法は二つあります。
hd=cylinders,heads,sectors
include/linux/config.h の
HD_TYPE マクロを適当な値に定義して再コンパイルすることで、
手動ブートしなくてもすむようになります。
BIOS アドレス : 0xce000
IO ポート : 0x350
IRQ : 15
DMA チャネル : 6
IO : ポートマップ方式、バスマスタ方式
BIOS がインストールされている必要があります。
ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/AM53C974-0.3.tar.gzにあります。
訳注: カーネル 2.0.27 には含まれています。
IO ポート : all
IRQ : all
DMA チャネル : 6
IO : ポートマップ方式、バスマスタ方式 (unintelligent)
ねえ Drew、この章はどこにあるの？ 目次にしかないよ ;-) - by D.F.
ここでは、ディスクドライブに固有の情報を示します。
すべてのダイレクトアクセス SCSI デバイス (訳注: これは「ハードディスク」を 意味する SCSI 用語です) で、ブロックサイズが 256バイトか 512バイト、または 1024バイトのものは使えるはずです。 これ以外のブロックサイズは使えませんが、多くの場合ブロックサイズまたは セクタサイズは SCSI の MODE SELECT コマンドを使って変更できます。
セクタサイズとは、デバイスのセクタに割り当てられたデータバイト数のことです。 例えば、CDROM のセクタサイズは 2048 です。
ブロックサイズとは、デバイスとのインターフェースに使用される論理ブロックの 大きさのことです。これは通常セクタサイズと等しいのですが、複数の小さな 物理セクタ (55M サイクエストドライブの場合には 256バイト) を大きな論理 ブロックにマップしたり、逆にひとつの物理セクタを複数の論理ブロックに 分割する (例えば、SUN コンパチブルの CDROM ドライブのブロックサイズは 512 バイトです) こともあります。
リムーバブルメディアデバイスには、Bernouli、フロプティカル、MO ドライブ、 Syquest などの種類があります。
理論的には、1テラバイトまでのドライブは使えるはずです。 9ギガバイトまでの小さなドライブに関しては、まったく問題はありません。
パーティションを切るときに、「シリンダが 1024 よりも多い」という 警告メッセージが表示される。 あるいは、1024 以降の論理シリンダを含んだパーティションからブート できない。
これは、BIOS の制限によるものです。
詳しい説明は、 ディスクのジオメトリ および パーティションの作成 を参照してください。
/dev/hd* にパーティションが切れない/dev/hd* は SCSI デバイスではありません。
SCSI デバイスは /dev/sd* です。
正しいデバイス名とパーティションの切り方については、 デバイスファイルや ディスクのジオメトリ、それに パーティションの作成 を参照してください。
Linux は、メディアがマウントされている時にはドライブのドアを ロックします。予期せぬメディアの入れ替えによって ファイルシステムが壊れるのを防ぐためです。
まずディスクをアンマウントしてください。
SCSI ドライバと BIOS との間で、使用すべき BIOS マッピングに関して 情報が食い違っていることがあります。 この場合、ブート時に LILO が「LI」まで表示してハングする などの問題を引き起こすことがあります。
この問題を回避するためには、DOS で使われる BIOS ジオメトリ
マッピングを調べて、これを /etc/lilo/disktab に書き込む
必要があります。
あるいは、「linear」jfile 設定オプションを使うという方法も あります。
fdisk が以下のようなメッセージを出力する
You must set heads sectors and cylinders.
You can do this from the extra functions menu.
そして fdisk を再起動すると、変更したはずのディスクジオメトリが 変更されていない。
パーティションの作成 を参照して ください。
Linux は ANSI SCSI リビジョン 1 以前の SCSI デバイスに対しては、
0 以外の LUN を探しに行きません。
0以外の LUN を認識させたければ、drivers/scsi/scsi.c の
scan_scsis() 関数を変更する必要があります。
この問題はすでに解決されています。 カーネルを 1.1.38 にバージョンアップしてください。
訳注: 現在 Conner は Seagate に買収されています。
これは、先読みとキャッシュに関するマイクロコードのバグのためです。
Soenke Behrens (Conner テクニカルサポート) からのメールより :
過去数週間の間に、Linux オペレーティングシステムを使用していて Conner CFP1060x 1GB SCSI ドライブに深刻な問題が生じたという電話を 何人かのお客様から頂きました。 症状は、ファイルシステムの破壊 (inode の損傷) がシステムブート時にe2fsckによって報告されるというものです。
CFP1060x (マイクロコードリビジョン 9WA1.62/1.66/1.68) と Linux を 使用されているお客様には、マイクロコードの修正が御利用頂けます。 マイクロコードをバージョンアップするためには、DOS ブートディスクと ハードディスクドライブにアクセスできる ASPI ドライバが必要です。 バージョンアップによって、新しいキューイングと先読みのコードが ドライブの不揮発性 SCSI RAM にダウンロードされます。
マイクロコードリビジョンが 9WA1.60 のディスクで問題が生じた 場合には、最寄りの Conner サービスセンターに連絡して、ディスクを バージョンアップしてもらう必要があります。 マイクロコードのリビジョンは、ドライブ上のラベルと、ドライブの下側の IC のひとつに貼られたラベルに書いてあります。
自分でバージョンアップできる自信のある方は、Conner テクニカルサポートに 連絡して、最新のマイクロコードを入手してください。 ヨーロッパの Conner テクニカルサポートの電話番号は +44-1294-315333 です。 アメリカの Conner テクニカルサポートの電話番号は 1-800-4CONNER です。
敬具
Soenke Behrens
ヨーロッパテクニカルサポート
SCSI ディスクのブロックデバイスメジャー番号は 8 で、BSD のような「ロー」 デバイスは存在しません。
ひとつの SCSI ディスクには、16個のマイナー番号が割り当てられています。 minor % 16 == 0 はディスク全体を表し、1 <= (minor % 16) <= 4 は4つのプライマリパーティションを、5 <= (minor % 16) <= 15 は拡張パーティション (訳注: 正確には「拡張パーティション中の 論理ドライブ」でしょう) を表します。
たとえば、以下のような構成では次のようにデバイス名が割り当てられます。 (ひとつのホストアダプタの場合)
Device Target, Lun SCSI disk 84M Seagate 0 0 /dev/sda SCSI->SMD bridge disk 0 3 0 /dev/sdb SCSI->SMD bridge disk 1 3 1 /dev/sdc Wangtek tape 4 0 none 213M Maxtor 6 0 /dev/sdd
標準的なデバイス名の付け方は、次のようになります。
/dev/sd{letter} ディスクデバイス全体 ((minor % 16) == 0)
/dev/sd{letter}{partition} そのデバイス上のパーティション
(1 <= (minor % 16) <= 15)
たとえば次のように。
/dev/sda block device major 8 minor 0 /dev/sda1 block device major 8 minor 1 /dev/sda2 block device major 8 minor 2 /dev/sdb block device major 8 minor 16
SCSI ディスクにパーティションを切るには、DOS、OS/2、Linux やその他の 標準的なパーティションの作成方法をサポートしている OS 上のパーティション 作成プログラムを使用することができます。
Linux の fdisk プログラムを起動する場合は、必ずデバイスをコマンド
ラインで指定してください。例えば最初の SCSI ディスクにパーティションを
作成する場合には、以下のように入力します。
fdisk /dev/sda
デバイスを指定しなかった場合には、デフォルトの /dev/hda が
使われてしまうことがあります。これは SCSI ディスクではありません。
fdisk が次のようなメッセージを出力することがあります。
You must set heads sectors and cylinders.
You can do this from the extra functions menu.
Command (m for help):
あるいは HDIO_REQ または HDIO_GETGEO ioctl が失敗したという
メッセージが出力されることもあります。
こういう場合には、
ディスクのジオメトリ
での説明にしたがって、ディスクのジオメトリを入力しなければなりません。
また LILO を使ってそのディスクからカーネルをブートするには、
/etc/disktab にもディスクジオメトリを設定する必要があります。
ディスクジオメトリを入力した場合には、その後 fdisk を起動しよう
とすると同様のメッセージが表示されます。これは PC がディスクジオメトリ
情報をパーティションテーブルに保存しないためで、異常ではありません。
それ自体は問題とはなりませんし、そのドライブに作成したパーティション
を Linux でアクセスすることにも問題はありません。
しかし、いくつかのメーカーの出来の悪いインストールプログラムの中には、
これをうまく処理できないものもあります。
その場合にはメーカーに連絡し、プログラムを修正するよう要求してください。
場合によっては、シリンダ 1024 以降に食い込んだパーティションに
関する警告メッセージが出力されることがあります。そのような
パーティションを作成した場合、そのパーティションから LILO を
使って Linux カーネルをブートすることはできません。
しかし、一部または全部がシリンダ 1024 以降にあるルートパーティションを
作成できないわけではありません。
シリンダ 1024 以下に小さな /boot パーティションを
作成するか、既存のパーティションからカーネルをブートすれば
よいからです。
Linux では、ディスクは SCSI ホストアダプタから見える通りに、エラーの ない 0 から N-1 まで番号づけされた N 個のブロックとして認識されます。 一方 DOS や BIOS では賢いディスクにも過去の慣習が適用されてしまい、 このようなリニアなアドレッシングが恣意的にヘッド/シリンダ/セクタに マッピングされてしまいます。
このことは、Linux でドライブにパーティションを切る場合に問題となる
おそれがあります。DOS や BIOS がどのようにジオメトリをマップするかを
知る汎用的な方法がないからです。多くの場合 HDIO_GETGEO ioctl() が
このマッピングを知るために使えます。
残念ながら、一部のメーカー (Seagate) のように、ひねくれた、標準から
外れた、しかも文書化されていない方法でマッピングを行っている場合、
この方法は使えず、ジオメトリをマニュアルで指定する必要があります。
マニュアル指定には、いくつかの方法があります。
1 <= heads <= 256 1 <= cylinders <= 1024 1 <= sectors <= 63
NU (訳注: Norton Utilities のことでしょう) のようなプログラムを使うこと もできますし、次のプログラムも使えます。
begin 664 dparam.com
MBAZ``##_B+^!`+N!`(H'0SP@=/D\,'5:@#]X=`6`/UAU4(!_`3AU2H!_`P!U
M1(I7`H#J,(#Z`7<Y@,*`M`C-$PCD=3-14HC()#\PY.@R`.@J`%J(\/[`,.3H
M)0#H'0!8AL2Q!M+L0.@7`+K"`;0)S2'#NIP!ZR"ZQ0'K&[K5`>L6N]T!,=*Y
M"@#W\8#",$N(%PG`=>^)VK0)S2'#=7-A9V4Z(&1P87)A;2`P>#@P#0H@("!O
L<B`@9'!A<F%M(#!X.#$-"B1);G9A;&ED(&1R:79E#0HD("`D```````D``!O
`
end
このプログラムを実行すると、コマンドラインで指定した BIOS アドレス (0x80 が最初のディスク、0x81 が 2番目のディスク) のドライブについて、 セクタ数、ヘッダ数、シリンダ数をプリントします。
つまり、dparam 0x80 を実行して以下のように表示された場合、
60 17 1007
C: ドライブのセクタ数が 60、ヘッド数が 17、シリンダ数が 1007 で あることを示しています。
ここでは、CDROM 特有の情報を示します。
ブロックサイズが 512 または 2048 バイトの SCSI CDROM は使えます。 これ以外のブロックサイズはサポートされていません。
ISO-9660 CDROM をマウントするための正しいコマンドは以下の通りです。
mount -t iso9660 /dev/sr0 /mount_point -o ro
このコマンドが正しく動作するためには、SCSI のサポートと使用している ホストアダプタや SCSI CDROM のドライバ、それに iso9660 ファイル システムがカーネルに組み込まれている必要があります。
カーネル 1.1.32 では、CDROM のようなリードオンリーのデバイスは デフォルトの読み書き可能オプションではマウントできないことに 注意してください。
Linux は、メディアがマウントされている時にはドライブのドアをロック します。予期せぬメディアの入れ替えによってファイルシステムが壊れる のを防ぐためです。
まずディスクをアンマウントしてください。
workman あるいは xcdplayer などのプログラムを使ってください。
workman や xcdplayer がうまく動かないオーディオ機能の制御は SCSI-II のコマンドセットに含まれているので、
SCSI-II に準拠していないドライブでは動作しないでしょう。
また、多くの SCSI-I CDROM ドライブと SCSI-II CDROM ドライブの一部には、
SCSI-II コマンドセットではなく、独自のコマンドセットを使ってオーディオ
機能にアクセスするものがあります。
NEC のドライブについては、この種のコマンドセットを使うようにパッチが
あたった xcdplayer があります。
ftp://tsx-11.mit.edu/pub/linux/BETA/cdrom を探してみて
ください。
これらのプログラムは、SCSI 以外の CDROM にも使える可能性があります。
ドライバが SCSI ドライバと同様の ioctl を実装していることが
条件です。
たいていの CD チェンジャはディスクごとに一つの論理ユニットを割り当てます。 論理ユニットに対応するスペシャルファイルを作成してあるかどうか確かめて ください ( デバイスファイルを参照のこと)。 また、 0 以外の LUN が使えないも読んで ください。
SCSI CD ROM のメジャーデバイス番号は 11 です。
マイナー番号は動的に割り当てられます ( ディスク や デバイスファイル を見てください)。 最初に見つかった CDROM のマイナー番号が 0、2番目に見つかった CDROM のマイナー番号が 1、という具合になります。
標準的なデバイス名は /dev/sr{数字} ですが、
パッケージによっては以下の例のように /dev/scd{数字} を
使っているものもあります。
/dev/sr0 /dev/scd0 /dev/sr1 /dev/scd1
この章では SCSI のテープドライブに特有の情報を記述しています。
固定長ブロックのドライブにも可変長ブロックにも対応しています。ただしド ライバで定義しているバッファよりもブロックは小さくなければなりません。 配布版カーネルのソースではドライバのバッファは 32K に設定されています。
ブロックサイズやバッファリング、記録密度などのパラメータは ioctl を
使って (通常は mt プログラムで) 設定されます。この設定はデバイスが
close/reopen した後も保持されます。
ほとんど全てのドライブが動作します。以下に一部を示します。
テープをドライブに入れてからブートしてみてください。
複数のファイルをテープから読み出すとき、最初の tar は成功し、その
次の tar はなにも出力せずに終わります。さらに次の tar を
行なうと二つめのファイルが読めます。
tar のようなユーザレベルのプログラムはファイルマークを認識しません。
最初の tar は先頭のファイルの最後まで読み込みます。
2 度目の tar はファイルマークの位置で読み込みを始めるのでなにも出力
しません。しかしこれによりテープは次のファイルの先頭に移動するので 3 度目
の tar は 2 番めのファイルを読み込みます。
次のファイルにスキップするためには、巻戻しをしないデバイス
(/dev/nst?) に mt コマンドを用いて下さい。
圧縮プログラムはファイルの最終ブロックに追加される 0 のデータを正しく 扱うことができません。
警告やエラーを防ぐには、圧縮ファイルを .tar ファイルの中にまとめて
下さい。つまり
tar cfvz /dev/nrst0 file.1 file.2 ...
とするのではなく、以下のようにして下さい。
tar cfvz tmp.tar.z file.1 file.2 ...
tar cf /dev/nrst0 tmp.tar.z
他の OS で書き込んだテープを Linux で読み込むことができない。 または、Linux で書き込んだテープを他の OS で読み込むことができない。
システムが異なるとブロックサイズも異なることがあります。ブロックサイズが 固定のデバイスに、異なったサイズのブロックを読み込ませることはできません。
このようなテープを読むには、テープドライブのブロックサイズを書き込まれ たときのサイズに合わせてやるか、あるいは可変長にしてやる必要があります。
注意 : これはハードウェアのブロックサイズのことであって、tar や
dump 等のコマンドのブロッキングファクターのことではありません。
ブロックサイズを変えるには mt コマンドを使います。
mt setblk <size>
可変長にするときには以下のようにします。
mt setblk 0
mt の setblk フラグは、 Linux の配布パッケージに入っている
GNU 版の mt ではサポートされていません。代わりに BSD から移植
された mt コマンドを使う必要があります。ソースコードは以下の
ところから入手できます。
ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsiまたデフォルトでは、バッファサイズの最大値が 32K バイトに指定されてい
ることに注意して下さい。これは
/usr/src/linux/drivers/scsi/st_options.h (古いカーネルでは
st.c) の ST_BUFFER_BLOCKS で定義されています。 32K 以上の
ブロックを使う場合はこれを変更してカーネルを再構築する必要があります。
テープにアクセスするたびに「No such device」といったような エラーメッセージが出てしまう場合です。
テープデバイスのタイプをチェックして下さい。テープデバイスはキャラクタ デバイスでなければならず、またデバイスのメジャー番号とマイナー番号が デバイスファイル に記述してあるような値に なっていなければなりません。
多くのテープドライブでは古いハードウェアとの互換性を保つために、低密度 での読み込みをサポートしていますが、普通書き込みはできません。
特に QIC のドライブでこの問題が生じることが多いでしょう。例えば古い形 式の 60M テープが読めても、書き込みは 120, 150, 250, 525M のフォーマット でしかできない場合などです。
これは一度にひとつのコマンドしか処理できない SCSI ドライバで特に良く生 じる問題です。(内容については 複数のデバイス を 見て下さい。またどのドライバがそうかについては 購入の手引: ドライバ機能の比較 を見て下さい。) しかし切断を拒否するテープドライブもいくつか存在しています。
訳注: SCSI ホストアダプタから見て、複数のコマンドを同時に実行するには、 ターゲットデバイスがディスコネクトをサポートしていることが必要です。 (つまりコマンドを受けとったら SCSI バスを解放し、データが準備できたら ターゲット側からバスを要求してデータ転送を行なう。それまでの間に別の デバイスに対するコマンドの送出やデータ転送などが可能となる。) ディスコネクトをサポートしていないターゲットデバイスは、コマンドの 実行を終るまで SCSI バスを放さないので、テープドライブの巻き戻し コマンドなどを送ると悲惨なことになります。
drivers/scsi/st.c の先頭に以下の行を追加してカーネルを再構築
することで、この問題を回避できる場合もあります。
#define ST_NOWAIT
この変更を行なった場合、エラー状態のレポートは次の SCSI コマンドが実行 されるまでされません。従って、mt などを使った頭出しがちゃんとできてい るかどうかを確認するには以下のようなコマンドを実行してみる必要がありま す。
mt status
この確認をしておかないと、頭出しに失敗した場合にテープを上書きしてしま うことになります。
しかし複数ファイルをテープに書き込んでいて、この解決法を使わなければな らない場合は、よりサポートの良い SCSI ボードか、新しいドライブにする方 が良いかもしれません。
SCSI テープはキャラクタデバイスのメジャー番号 9 を使います。
Linux では 16 ビットの dev_t を使っているので、マイナー番号には 8 ビッ
トしか割り当てられていません。このため SCSI テープのマイナー番号は
SCSI のホスト/ID/LUN の低い方から動的に割り付けされます。
巻戻しデバイスは 0 からはじまります。一台目の SCSI テープ
/dev/rst0 は c 9 0 となり、二台目は c 9 1 となります。
巻戻しをしないデバイスではマイナー番号の最上位ビットがセットされます。
つまり /dev/nrst0 は c 9 128 となります。
通常は以下のような名前が使われます。
/dev/nst{数字} 巻戻さないデバイス
/dev/st{数字} 巻戻すデバイス
この章では汎用 SCSI デバイスのドライバに特有の情報について示します。
汎用 SCSI ドライバは全ての SCSI デバイス (ディスク、テープ、 CDROM、 メディアチェンジャーロボットなどなど) へ SCSI コマンドを送るインター フェースです。
お使いの SCSI ボードと電気的に :-) 互換性のあるものは全て動作するはず です。
ありません :-)
SCSI の汎用デバイスはキャラクタデバイスのメジャー番号 21 を使います。
Linux では dev_t が 16ビットであるという制限から、マイナー番号
は 0 から順番にデバイス毎に動的に割り当てられます。
/dev/sg0
は一枚目の SCSI ボードにおける最小の SCSI/LUN 番号のデバイスになります。
「Linux に対応しているたくさんのボードの中で、どの SCSI ホスト アダプタを買えばいいんでしょう？」という質問をよく聞きます。
答えは、どの程度の性能を期待するか (あるいは必要とするか) によって 異なりますし、使用するマザーボードや接続を予定している SCSI 周辺機器 によっても違ってきます。
性能 (ここではスループットと SCSI I/O の応答時間を指しています) に もっとも大きく影響するのは、転送のタイプです。 以下、各種の転送タイプに対して、性能に与える影響とどのような場合に お勧めかを示します。
純粋なポーリングを行う I/O ボードは、 REQ/ACK ハンドシェークを含むすべての SCSI 信号処理を CPU で行います。
高速な CPU であっても、単純なシーケンサよりも REQ/ACK ハンドシェークは 遅いので、ピーク転送レートは高速のマシンで 150K/秒、低速のマシンでは おそらく 60K/秒程度になってしまうでしょう (ファイルシステムを介した 転送レート)。
またドライバは SCSI バスがビジーである間ループしていなければならない ので、SCSI I/O 中にはほぼ 100% CPU が使用され、応答が極端に 悪くなります。 低速でディスコネクト/リコネクトに対応していない CDROM をこの種の ボードに接続すると、使い物にならないほど応答性が低下します。
この種のボードは、お勧めできません。
インターロックポーリングを使用した ボードは、SCSI REQ/ACK ハンドシェーク信号が PC バスのハンドシェーク 信号と連動していることを除けば、純粋なポーリングのボードと 本質的に変わりません。 ハンドシェーク以外の SCSI 信号処理は、CPU によって行われます。
この種のボードのファイルシステムを介したピーク転送レートは、 最大で 500〜600K/秒程度です。
純粋なポーリング I/O ボードと同様に、ドライバは SCSI バスがビジーで ある間ループしていなければならないので、CPU の利用率はデバイスの転送 レートとディスコネクト/リコネクトを行う頻度によって変化します。 CPU の利用率は 25% (ディスコネクト/リコネクトを適切に行う等速 CDROM の場合) から 100% (高速のドライブ、またはディスコネクト/ リコネクトを行わないイカレた CDROM の場合) まで変化します。
筆者の 486-66 の場合、ヘッドレート 1080K/秒のドライブと T128 ボードで 547K/秒のスループットを得た時の CPU 使用率は 90% でした。
コストを安く抑えることが最優先ならば、 場合によって低速のテープや CDROM ドライブには使用可能でしょう。
FIFO ポーリングを行うボードは、小さな (8K 程度の) バッファを CPU と SCSI バスの間に持っており、多少は インテリジェントな処理を行うことができます。 その結果 CPU は FIFO との間でフルスピードでデータを転送することが でき、データ転送と割り込み処理 (FIFO エンプティ、ディスコネクト/ リコネクト処理など) 以外には CPU を占有しません。
ピーク転送レートは、ほとんどの SCSI デバイスに十分な値が得られます。 FAST SCSI に対応した Seagate Barracuda と Adaptec 1520 の 組み合わせで、低レベルの SCSI コマンドを使って 64K ブロックの 読み出しを行った場合、転送レートは 4M/秒に達しました。
CPU の使用率は、デバイスの転送レートによって異なります。 デバイスが高速になるほど、単位時間当たりに発生する割り込みが多くなり、 より多くの CPU 処理時間を必要とします。 高速なデバイスでは CPU 使用率は高くなる (75% 程度) ものの、 システムが使い物にならなくなることは普通ありません。 この種のボードは、ディスコネクト/リコネクトを行わないイカレた デバイス (安物の CDROM ドライブに多い) に対しても、優れた 応答性を示します。
予算が厳しい人にはお勧めです。
スレーブ DMA ボードのドライバは、 PC の DMA コントローラの 1チャネルを使ってデータ転送を行い、 CPU に制御を返します。
ピーク転送レートは、PC の DMA コントローラが低速なため、あまり 高くなりません。 この種の 8bit ボードとあるマザーボードの組み合わせでは、 140〜150K/秒以上の転送レートでは問題が生じました。
CPU 使用率はかなり優秀で、FIFO ポーリング I/O ボードよりも わずかに低い程度です。 この種のボードは、ディスコネクト/リコネクトを行わないイカレた デバイス (安物の CDROM ドライブに多い) にも十分耐えられます。
低速の CDROM やテープドライブには使用可能でしょう。
インテリジェントなボードです。 この種のボードのドライバは、SCSI コマンド、ターゲットと LUN、 それにデータへのポインタを構造体にセットして、ボードに処理を 任せます。 ドライバは他のプログラムに制御を戻し、SCSI ボードは割り込みを あげて処理が終わったことを知らせます。
インテリジェンスがドライバではなくファームウェアにあるため、 この種のボードのドライバは、同期転送、タグ付きコマンドキュー イングなど、より高度な機能をサポートすることができます。
単位のリード/ライトを行うパッチを当てると、ファイルシステムを 介したピーク転送レートは、ライトの場合でヘッドレートの 100%、 リードの場合で 70% に達します。
CPU 使用率は I/O 負荷に関わらず最小で、Adaptec 1540 で倍速 CDROM を アクセス中に 5%、SCSI ディスクに 1.2M/秒で継続的にデータ 転送している場合で 20% でした。
予算が非常に厳しい場合、マザーボードにバグがある場合 (バグのある マザーボードには、バスマスタが動作しないものもあります)、スルー プットよりもデータアクセス時間の方が重要なアプリケーションを 使っている場合 (バスマスタのオーバヘッドは 1コマンドあたり 3〜4ms あります) を除き、常にお勧めできます。
性能に大きな影響を与える 2番目に重要なドライバやハードウェアの機能は スキャッタ/ギャザ I/O です。 SCSI コマンドの実行に必要なオーバヘッドはかなり大きく、ミリ秒のオーダ です。Adaptec 1540 のようなインテリジェントバスマスタは、ターゲットに SCSI コマンドを送る前の処理に 3〜4ms かかる場合があります。 バッファなしのデバイスの場合、このオーバヘッドは次のセクタにアクセスする のに常にもう1回転待たなければならないほど大きいため、一度に1ブロックの 転送を行なう場合には、転送レートは 60K/秒 (3600rpm のドライブの場合) に まで低下してしまいます。 したがって、性能を上げるためには、与えられた大きさのデータを転送するのに 必要な SCSI コマンドの数を少なくすることが必要となってきます。これは、 ひとつのコマンドあたりに転送されるデータ量を大きくすることを意味します。 Linux のバッファキャッシュの設計により、ディスクブロックとして連続している データであっても、メモリ上で連続しているとは限りません。クラスタごとの リード/ライトパッチがあたっている場合には、4K のバッファは連続しています。 したがって、SCSI コマンドあたり転送されるデータ量は最大で 1K * スキャッタ/ ギャザ領域の数 (クラスタごとのリード/ライトパッチがあたっていない場合)、 あるいは4K * スキャッタ/ギャザ領域の数 (クラスタごとのリード/ライトパッチ があたっている場合) となります。 実験の結果、私たちはひとつの SCSI コマンドあたりに転送するデータの大きさは 64K が適当だろうという結論に達しました。これは、クラスタごとのリード/ライト パッチが当たっている場合でバッファサイズの 16倍、そうでない場合には 64倍です。 16K から 64K に転送サイズを増やした結果、Adaptec 1540 シリーズのボードを 使った場合でファイルシステムを介した読み書きがヘッドレートの 50% か ら 75% (リードの場合) および 100% (ライトの場合) にまで向上し ました。
Ultrastor や WD7000 や Adaptec 1540 や 1740、それに BusLogic の ボードなど、インテリジェントなホストアダプタの多くはメイルボックス インターフェースを持っています。これは、SCSI コマンドを実行する際、 特定のメモリアドレス (メイルボックス) に SCSI コマンド構造体を 書き込み、ボードに信号を送り (つまり、出すべきメールがあることを 示すフラグを上げ)、結果 (返信) を待つものです。 このような高レベルのプログラミングインターフェースを使用した場合、 ソフトウェアの変更なしに FAST + WIDE SCSI のような新しい機能を持った ボードにバージョンアップできることが多くなります。 一般的な傾向としてドライバはシンプルな実装で機能が多く、安定したものに なります。
それに対して NCR53c7/8xx ファミリや Adaptec AIC-7770/7870 チップ (274x、284x、それに 2940 ボードに使われています) などのボードは、 より低レベルのプログラミングインターフェースを使います。 この利点としては、処理の多くがボード上のプロセッサからより高速な ホスト CPU に移るため高速化しやすいという点、柔軟性に富みある種の 機能 (任意のデバイスに対するターゲットモードなど) が実装しやすいという点、 それに製造コストが低い (NCR のボードのように、消費者にとっても 安く買えることにつながります) という点などがあげられます。 一方欠点としては、ドライバが複雑になりがち (これはバグの入り込む 余地も多くなることを意味します) だという点、それに新しいチップの 機能を生かすためにはドライバの変更が必要だという点があげられます。
バスのタイプは次に考慮すべき点で、ISA、EISA、VL、それに PCI などの 選択肢があります。マーケティングの連中は、バースト転送レートと空想に 基づいたばかばかしい数値を宣伝していますが、こんなものは実際の役には 立ちはしません。 そのかわりに私は各種の周辺機器について測定した結果をもとにした、より 実用的な数値を示すことにします。
バンド幅は、バスマスタデバイスの場合、5M/秒よりも少し 良い程度です。ISA バスの調停は、いにしえの 8237 DMA コントローラに よって行われるので、バスの獲得にかかる時間は比較的長くなります。 割り込みの検出はエッジトリガ方式なので、割り込みの共有はできません。 通常、ISA はバッファされていないため、転送中はホストバスとメモリバスが 占有されてしまいます。バスの占有を防ぐメカニズムは提供されません。
バンド幅はおよそ 30M/秒です。システムによっては 規格から外れたタイミングでバスを駆動しているものもあり、この ようなシステムでは動かないボードもありますから、返品保証のない ハードウェアを購入する場合にはこの点を考慮する必要があります。 通常、VL バスはバッファされていないため、転送中にはホストバスと メモリバスが占有されてしまいます。
バンド幅はおよそ 30M/秒ですが、バスマスタ転送は 通常 VL よりも高速です。 バスがバッファされているシステムでは、高速なホスト/メモリバスへの バースト転送が可能で、CPU 性能への影響も最小限となります。 EISA の割り込み検出はエッジトリガにもレベルセンスにも設定できるため、 ドライバが対応していれば割り込みの共有が可能です。 EISA バスはボードごとに独立したアドレス空間を割り当てるため、ISA や VL に比べて資源の衝突が起こるおそれは少なくなります。
バンド幅はおよそ 60M/秒です。PCI システムはたいてい ホストブリッジ上に遅延書き込みバッファを持っており、バス間のスピードの 違いがバスや CPU の性能に与える影響を最小限に抑えることができます。 PCI の割り込みはレベルセンスなので、ドライバが対応していれば割り込みを 共有することが可能です。 バスの占有を防ぐメカニズムが提供されており、マスタとスレーブのどちら からでもバスサイクルを中断することが可能です。
PCI は、書き込み可能な設定レジスタをボードごとに独立したアドレス空間に 持っており、プラグアンドプレイメカニズムを提供します。 正しく実装された PCI システムはプラグアンドプレイ機能を持っています。
PCI はトレース長、負荷、機械的寸法などについて大変厳密に規定して いるので、VL や ISA よりも信頼性は高いはずです。
結論を言うと、PCI が最良の PC バスですが、弱点もあります。PCI はまだ 製品が世に出てから日が浅く、大部分のメーカーはすでに問題を解決している とはいえ、まだ古いバグありの PCI ハードウェアやイカレた BIOS が存在 します。このため、筆者は返品保証付きのハードウェアを購入することを 強くお勧めします。最近の PCI マザーボードは真のプラグアンドプレイを 実現していますが、古いボードではジャンパとソフトウェアによる設定が必要な 場合もあります (例えば割り込みレベルの割当)。 PCI の問題を解決するには時間がかかることが多く、このため システムを動作させるまでの時間が非常に重要な場合にはおすすめできません。
低速の SCSI デバイス、例えばヘッドレートが 2M/秒程度かそれ以下の ディスクや CDROM、テープドライブに関しては、PC 側のバスインター フェースが違ってもスループットはほとんど変化しません。 最近のギガバイトクラスのハイエンド SCSI ドライブのヘッドレートは 4-5M/秒に達し、あるメーカーは 14M/秒のヘッドレートを実現する並列 ヘッドユニットのアルファテストを行っています。このようなドライブ では高速なバス上のコントローラが性能を発揮します。 あるユーザーは Adaptec 1542 ISA ボードから NCR53c810 PCI ボードに 変えて、2.5倍性能が向上したそうです。
PCI の遅延書き込みや、同様のライトバッファ機構が使用される場合を除いて、 システム中のひとつのバスがビジーのときは、すべてのバスがアクセス不可能と なります。したがって、バスのスピードが頭打ちになることは SCSI の性能に 影響しないとしても、システムの応答性には悪影響を与えるおそれがあります。 つまり、ISA バス上で 4M/秒の SCSI ディスクを使用している場合、バンド幅の 80% を失っていることになります。 ISA/VL システムでは画面描画に使えるのは 6M/秒しかありません。 たいていの場合、バックグラウンドで実行中のジョブには同様の影響があります。
16M 以上のメモリーがあっても ISA バスマスタ SCSI ボードが使えないわけ ではないことに注意してください。 他のイカレた OS と違って、Linux は ISA コントローラで 16M 以上の領域に DMA 転送する時にはダブルバッファリングを行います。 これによる性能の低下はわずか 1.5% 程度で、まったく気になりません。
最後に、バスインターフェースが違っても、バスマスタ方式のボードの値段は それほど変わらないことが多い、ということは覚えておいてください。
以上の議論を踏まえて、目的によってバスに順序をつけると次のようになるで しょう。
安定性を求める。インストールに必要な時間が EISA ISA VL PCI
重要。ボードが返品できない場合。
性能を求める。インストールには多少時間が PCI EISA VL ISA
かかってもよい。
訳注: 現在の PCI は、少なくとも VL よりは安定していると思います。
すでに述べたように、バスマスタ方式が総合的なシステムの性能に与える影響は 非常に大きくなってきているので、SCSI コントローラを購入する際にはバスの タイプよりもバスマスタであるかどうかの方を重視すべきです。
SCSI バス上に複数のデバイスが存在する場合、ホストアダプタやドライバが 同時に複数のコマンドを並列に処理できるかどうかが重要になってきます。 この機能は、テープドライブを使用する場合にはほぼ必須となりますし、 例えば CDROM とディスクドライブといった、スピードの異なるデバイスが 存在する場合には非常に望ましい機能と言えます。 Linux ドライバが1つのコマンドしか同時には処理できない場合、テープ ドライブがテープを巻き戻したりメディアの最後を探している間 (おそらく 30分ほど)、ディスクドライブにアクセスできなくなってしまいます。 ディスクドライブが 2台ある場合、この問題は顕著ではありませんが、 スループットが 2台の転送レートの和ではなく、2台の転送レートの平均に なってしまいます。
SCSI は年々進歩しています。 新しいバージョンの規格には、より高い転送レートやスループットを向上させる ための方法、新しいデバイスに対するコマンドの標準化、すでにサポートされて いるデバイスに対する新しいコマンドの追加などが規定されています。
SCSI のリビジョンレベルそれ自体には、実際には意味はありません。 SCSI-II が SCSI-I の単一イニシエータオプションを許さない、といった些細な 点を除けば SCSI は下位互換性を保っており、新しい機能は必須機能としてでは なく、オプション機能として導入されます。 したがって、SCSI アダプタを SCSI、SCSI-II、あるいは SCSI-III と呼ぶのは マーケティング的な意味しかないと言っても過言ではないでしょう。
ドライバ機能の比較を以下の表に示します (そのドライバでサポートされている チップはカッコ内に示してあります)。
ドライバ名 同時発行可能な スキャッタ/ 複数
転送モード コマンド数 ギャザの制限 ボード
全体/LUN
AM53C974 バスマスタリング DMA 12s/1s 255s Y
aha152x FIFO(8k) ポーリング 7s/1s 255s N
(AIC6260,
AIC6360)
aha1542 バスマスタリング DMA 8s/1s 16 Y
aha1740 バスマスタリング DMA 32s 16 N
aha274x バスマスタリング DMA 4s/1s 255s Y
BusLogic バスマスタリング DMA 192/31 128s, 8192h Y
(この値は BT-948/958/958D のもので、古いボードのサポートするコマンド数は
もっと少ない)
eata_dma バスマスタリング DMA 64s-8192h/2-64 512s, 8192h Y
fdomain FIFO(8k) ポーリング 1s 64s N
(TMC1800, TMC18c30 は 2k FIFO
TMC18c30,
TMC18c50,
TMC36c70)
in2000* FIFO(2k) ポーリング 1s 255s N
g_NCR5380 純粋なポーリング 16s/2s 255s Y
(NCR5380,
NCR53c80,
NCR5381,
NCR53c400)
gsi8* スレーブ DMA 16s/2s 255s
(NCR5380)
PAS16 純粋なポーリング 16s/2s 255s Y
(NCR5380) またはインターロックポーリング
(システムによっては動作しません！)
seagate インターロックポーリング1s/1s 255s N
wd7000 バスマスタリング DMA 16s/1s 16 Y
t128 インターロックポーリング16s 255s Y
(NCR5380)
qlogic インターロックポーリング1s/1s 255s N
ultrastor バスマスタリング DMA 16s/2s 32 Y
53c7,8xx バスマスタリング DMA
(NCR53c810,
NCR53c815,
NCR53c820,
NCR53c825)
rel5 1s/1s 127s N
rel10 8s/1s 127s Y
注:
define し直すことによって変更することができます。
ボード名 ドライバ バス 価格 備考
Adaptec AIC-6260 aha152x ISA ボードではなくチップ
Adaptec AIC-6360 aha152x VLB ボードではなくチップ
(VL/ISA の SCSI つきマルチ I/O ボードの多くと Zenon の
マザーボードに使われています)
Adaptec 1520 aha152x ISA
Adaptec 1522 aha152x ISA $80 1520 + FDC
Adaptec 1510 aha152x ISA ブート ROM なしの 1520
自動認識不可
Adaptec 1540C aha1542 ISA
Adaptec 1542C aha1542 ISA 1540C + FDC
Adaptec 1540CF aha1542 ISA FAST SCSI-II
Adaptec 1542CF aha1542 ISA $200 1540CF + FDC
Adaptec 1640 aha1542 MCA
Adaptec 1740 aha1740 EISA 生産中止
Adaptec 1742 aha1740 EISA 生産中止、1740 + FDC
Adaptec 2740 aha274x EISA
Adaptec 2742 aha274x EISA FDC つき
Adaptec 2840 aha274x VLB
Adaptec 2842 aha274x VLB FDC つき
Adaptec 2940 aha274x PCI
Always IN2000 in2000 ISA
BusLogic BT-948 BusLogic PCI $180 Ultra SCSI
BusLogic BT-958 BusLogic PCI $230 Wide Ultra SCSI
(BusLogic のボードの詳細については、
BusLogic MultiMaster ホストアダプタ
を参照してください。)
DPT PM2011 eata_dma ISA FAST SCSI-II
PM2012A eata_dma EISA FAST SCSI-II
PM2012B eata_dma EISA FAST SCSI-II
PM2021 eata_dma ISA FAST SCSI-II
PM2022 eata_dma EISA FAST SCSI-II
PM2024 eata_dma PCI FAST SCSI-II
PM2122 eata_dma EISA FAST SCSI-II
PM2322 eata_dma EISA FAST SCSI-II
PM2124 eata_dma PCI FAST SCSI-II
PM2124 eata_dma PCI FAST SCSI-II
PM2124 eata_dma PCI FAST SCSI-II
PM2124 eata_dma PCI FAST SCSI-II
PM2124 eata_dma PCI FAST SCSI-II
PM2124 eata_dma PCI FAST SCSI-II
PM2041W eata_dma ISA Wide Single-ended
SCSI-II
PM2041UW eata_dma ISA Ultra Wide Single-ended
PM2042W eata_dma EISA Wide Single-ended
PM2042UW eata_dma EISA Ultra Wide Single-ended
PM2044W eata_dma PCI Wide Single-ended
PM2044UW eata_dma PCI Ultra Wide Single-ended
PM2142W eata_dma EISA Wide Single-ended
PM2142UW eata_dma EISA Ultra Wide Single-ended
PM2144W eata_dma PCI Wide Single-ended
PM2144UW eata_dma PCI Ultra Wide Single-ended
PM3021 eata_dma ISA multichannel
raid/simm sockets
PM3122 eata_dma EISA multichannel/raid
PM3222 eata_dma EISA multichannel
raid/simm sockets
PM3224 eata_dma PCI multichannel
raid/simm sockets
PM3334 eata_dma PCI Wide Ultra SCSI
multichannel
raid/simm sockets
DTC 3290 aha1542 EISA 動作するはずですが、
ドキュメントリリース
ポリシーのため、DTC の
ハードウェアはサポート
されません
DTC 3130 53c7,8xx PCI '810
DTC 3130B 53c7,8xx PCI '815
DTC 3292 aha1542 EISA 3290 + FDC
DTC 3292 aha1542 EISA 3290 + FDC
Future Domain 1680 fdomain ISA FDC
Future Domain 3260 fdomain PCI
NCR53c810 53c7,8xx PCI $60 ボードではなくチップ。
(FIC、Chaintech、Nextor、Gigabyte (ボード) ボードには BIOS は
などの SCSI ボードや AMI、ASUS、 含まれていませんが、
J-Bond などのマザーボードに使われ たいていのマザーボード
ています。DEC PCI システムに には SDMS BIOS が
使われているのも普通これです。) ついています。
NCR53c815 53c7,8xx PCI $100 NCR53c810 + BIOS
(Intel PCISCSIKIT
NCR8150S など)
NCR53c825 53c7,8xx PCI $120 NCR53c815 の WIDE 版。
現在の Linux ドライバは
Wide 転送のネゴシエー
ションを行なわないこと
に注意。
Pro Audio Spectrum 16 pas16 ISA サウンドボード + SCSI
Seagate ST01 seagate ISA $20 ドライブによっては
BIOS は動作しません
Seagate ST02 seagate ISA $40 ST01 + FDC
Sound Blaster 16 SCSI aha152x ISA サウンドボード + SCSI
Western Digital 7000 wd7000 ISA FDC つき
Trantor T128 t128 ISA
Trantor T128F t128 ISA T128 + FDC
IRQ 10 以上をサポート
Trantor T130B g_NCR5380 ISA
Ultrastor 14F ultrastor ISA FDC つき
Ultrastor 24F ultrastor EISA FDC つき
Ultrastor 34F ultrastor VLB
注:
SW (swt@netcom.com) (214) 907-0871 fax (214) 907-9339
性能、機能 (アクティブターミネーションなど)、Adaptec 1540 シリーズ との互換性などの点から、BusLogic のMultiMaster ボードは ISA、EISA、 VL、PCI のいずれにもお勧めできます。 EISA、ISA、PCI、VL のバスインターフェースと シングルエンドやディファレンシャル、8/16 ビットの SCSI バスに対応した たくさんのモデルが用意されています。 最新の Ultra SCSI PCI モデル BT-948/958/958D はフラッシュ ROM により 容易にファームウェアをバージョンアップでき、スマートターミネーション 機能も持っています。
最高の I/O 性能を求める人には、DPT のボードがいいでしょう。 RAID とキャッシュ、複数の SCSI チャネルに対応したボードは他に ありません。
PCI システムを使っている場合、NCR53c8xx チップを使ったボードは検討に 値します。バスマスタ SCSI コントローラが、53ドル (何と Adaptec 1520 よりも安い！) という値段で手に入るのです。 C't マガジンによる DOS のベンチマークでは Adaptec 2940 や BusLogic BT-946C を凌ぐ性能が出ていますし、Linux でもかなりの性能 (ファイル システムを介して 6M/sec) が得られています。 これらのボードの BusLogic に対する弱点は、Adaptec 1540 互換でない ことと、アクティブターミネータがついているかどうかわからないこと、 ハードウェアの性能を発揮させるためには最新のドライバ (1.3.5x の カーネルには標準でついてきます。1.2.x のカーネル用のドライバは 匿名 ftp で取ってくることができます) が必要だということ、それに BusLogic や DPT などのメールボックスインターフェースのボードに比べて ドライバに問題が起こりやすいという点です。
確実に動作させることが必要な場合には、BusLogic MultiMaster か DPT の ボードがおそらくベストでしょう。 NCR53c8xx や Adaptec AIC7xxx のようなメールボックスインターフェースで ないボードはドライバが複雑で問題が生じやすいので、このような目的には 適していません。
予算が限られていて、PCI 以外の SCSI カードが必要ならば、在庫処分品や 中古の Adaptec 154x B バージョンや 174x A バージョンのボードを見つけ るか、Adaptec 1520 互換のボード (新品で 80ドルくらいからあります) を 探すのがいいでしょう。 これらのボードのスループットと応答性はかなりのもので、値段もまあまあ です。
Linux では、dev_t に 16ビットを使用しており、マイナー番号には 8ビット
しか割り当てられていないため、SCSI ディスクやテープ、CDROM、それに
汎用デバイスのマイナー番号は、以下にしたがって動的に割り当てられます。
For すべての SCSI ホストアダプタ (scsi0 から scsiN まで) について
For ホストアダプタ自身の ID を除く、すべての SCSI ID (0 から 7 まで) について
For すべての LUN (0 から max_scsi_luns まで) について
- TEST UNIT READY コマンドを発行して、バス、ターゲット、
LUN の組み合わせを探索する。あるバス上の SCSI ID に
デバイスが存在しないと判断したら、そのバスと SCSI ID の
対しては LUN の探索を行わない。
- INQUIRY コマンドを発行して、見つかったデバイスに関する
情報を集める。デバイスタイプ、メーカー、モデル名、
ファームウェアのバージョンなど。
- この結果を特別な認識関数を通して、存在するハイレベル
ドライバ (ディスク、テープなど) に通知する。
このデバイスを扱えるドライバのユニットとしてアタッチする。
汎用ドライバはすべてのデバイスをアタッチする。
- SCSI-I デバイスの場合、あるいは複数の LUN を扱えない
デバイスのリストに載っているデバイスの場合は、
このバスのこの SCSI ID に対して LUN の探索を行わない。
- 複数の LUN を持っていることがわかっているデバイスの
場合は、max_scsi_luns を無視してすべての LUN を
スキャンする。
この方法では、しばしば問題が生じる場合があるということが分かっています。
ある時点でしか存在しないデバイスがあった場合、そのデバイスのマイナー
デバイス番号は、ブート時に見付かったデバイスに依存して決まります。
この場合、rc スクリプトや /etc/fstab ファイルによって
マウントされるパーティションのマイナー番号が異なってしまう可能性が
あるからです。
この問題は、まだ完全には解決されていません。
/dev/scsi 以下のデバイス階層をホスト番号と SCSI ID および
LUN から作成するプログラムがあり、
ftp://tsx-11.mit.edu から
取ってくることができます。
ちょっと扱いづらい点もありますが、これによって問題の一部が軽減される
ことは確かでしょう。
多分もっと良い解決法は、/proc/scsi 擬似ディレクトリを使うこと
でしょう。現在作業が進行中なので、どのような方法になるかはまだ正確には
言えませんが、この問題を解決するためには有望だと思えます。