Linux をイーサネット接続で使うことに関連した質問のうち、 よく聞くものを集めました。 カードに固有な質問については、「メーカー別に」分けました。 あなたの知りたい問題は、きっと他の誰かによって質問されている (そして答えられている!) ことが多いでしょうから、 もしここに知りたい答えがなくても、 Dejanews. のようなニュースアーカイブなら見付かるかもしれません。
わたしのカード用の最新版ドライバや、試験的なアルファ版ドライバが 入手できると聞きました。どこにありますか？
「新しい」ドライバの最新版は、Donaldの ftp サイト
cesdis.gsfc.nasa.gov の /pub/linux
にあります。
ここにあるものは頻繁に変化していますから、探し回ってみてください。
あるいは WWW ブラウザで以下を訪ねるほうが、
お探しのドライバを見つけるには楽かもしれません。
WWW ブラウザはソースを勝手に変更して (例えばタブをスペースにしちゃったりとか) ダメにしちゃうことがあるので注意しましょう。 ftp を使うか、あるいはよくわからなければ、 少なくともダウンロードには FTP URL を使ってください。
さて、そのドライバが本当にアルファ版 (あるいはプレアルファ版) なら、 それなりの取扱いをしてください。つまり、解決できないことやわからない ことがあっても、文句を言わないこと。 インストールのやり方がわからないのなら、 プレアルファドライバのテストをすべきではありません。 またこのドライバのせいでマシンがダウンしても、文句を言わないでください。 文句の代わりに詳細なバグリポートをお送りください。 もっといいのはパッチですけど！
「使える」実験的なドライバ、アルファドライバのうちのいくつかは、
標準のカーネルソースツリーにも含まれるようになっています。
make config を実行すると、最初のほうで
``Prompt for development and/or incomplete code/drivers''
という質問をされるはずです。アルファ/実験的ドライバに関する
選択肢を出したいときには、ここで `Y' と答えてください。
Linuxで2つのイーサネットカードを動かすにはどうすればいいの？
この質問に対する答えは、ドライバをローダブルモジュールとして
使っているか、あるいはカーネルに直接組み込んでいるかによって
異なります。ほとんどの Linux ディストリビューションは、現在では
モジュール化ドライバを使っています。ドライバの組み合わせだけが
異なるたくさんのカーネルを配布しないですむからです。
一つのベースとなるカーネルを使い、
それぞれのユーザのシステムで必要とされる個別のドライバは、
システムがブートしてドライバモジュールファイル
(通常 /lib/modules/ におかれます)
がアクセス可能になってからロードされるようになっているのです。
ドライバがモジュールのとき:
PCI ドライバの場合は、
モジュールはインストールされているカードを全て自動的に
検知するはずです (もちろん対応するカードを、ですが)。
しかし ISA のカードでは、カードの探索 (probe) は危険な作業なので、
カードの I/O ベースアドレスを与えて、モジュールにどこを探せばよいかを
教えてあげる必要があるでしょう。この情報は
/etc/conf.modules ファイルに保存されます。
例として、二枚の ISA NE2000 カードがある場合を考えましょう。
一つは 0x300 に、もう一つは 0x240 とします。
この場合は /etc/conf.modules ファイルには以下のような
行を指定することになるでしょう。
alias eth0 ne
alias eth1 ne
options ne io=0x240,0x300
説明: ここで指定されていることは以下の通りです: 管理者
(あるいはカーネル) が modprobe eth0 あるいは modprobe eth1
を実行すると、 ne.o ドライバが eth0, eth1 それぞれに
対してロードされます。さらに ne.o モジュールがロードされるとき、
io=0x240,0x300 というオプションが与えられるので、
ドライバはカードを探す場所がわかるようになります。
0x が重要です。 DOS の世界でよく使われる 300h というような
表記は動作しません。 0x240 と 0x300 の順序をかえれば、
物理的なカード二枚に対する eth0, eth1 の関係を
逆にすることができます。
ほとんどの ISA モジュールドライバでは、複数のカードを扱えるよう、
この例のように複数の I/O の値をコンマで区切って与えることができます。
しかし 3c501.o モジュールのように (古い?) ドライバでは、
モジュールのロードあたり一つのカードしか使えないこともあります。
このような場合に両方のカードを検知するためには、モジュールを二回
ロードする必要があります。 /etc/conf.modules は以下のように
なるでしょう。
alias eth0 3c501
alias eth1 3c501
options eth0 -o 3c501-0 io=0x280 irq=5
options eth1 -o 3c501-1 io=0x300 irq=7
この例では -o オプションを用いて、それぞれロードされたモジュール
インスタンスに一意な名前をつけています。二つのモジュールを同じ名前で
同時にロードすることはできないからです。
irq= オプションも、カードのハードウェア IRQ 設定を指定するために
用いられています。
(この方法を、複数 I/O 値のコンマ区切り指定を許すカードに用いることもで
きますが、効率が悪いです。なぜなら必要のない場合でもモジュールが二回
ロードされることになるからです。)
最後の例として、 0x350 にある 3c503 カードと
0x280 にある SMC Elite16 カード (wd8013) を同時に使う
場合を示します。以下のようになります:
alias eth0 wd
alias eth1 3c503
options wd io=0x280
options 3c503 io=0x350
PCI のカードに対しては、通常は alias 行で
ethN インタフェースと対応するドライバを指定するだけでいいはずです。
PCI カードの I/O ベースアドレスは安全に検知されるからです。
利用できるモジュールは /lib/modules/`uname -r`/net
に保存されているはずです。ここで uname -r コマンドは
カーネルのバージョン (例えば 2.0.34) を与えます。
ここを探して、お使いのカードにあったドライバを探してください。
conf.modules が正しく設定されれば、
以下のようにしてテストできます。
modprobe ethN
dmesg | tail
ここで `N' にはテストしたいイーサネットインタフェースの番号を 入れてください。
ドライバをカーネルに組み込んでいる場合: ドライバをカーネルに組み込んでいる場合は、複数のイーサカードに 対するフックも全てカーネルに組み込まれていることになります。 しかしここで、デフォルトではひとつのカードしか自動探索 されないことに注意してください。 これは、神経質なカードを探索することによって起こりうる ブート時のハングアップを避けるためなのです。
(注意: 2.1.x の最後の方のカーネルでは、ブート時の探索は 安全なものから危険なものの順に行われるようになりました。 これは、安全な (つまり PCI と EISA) 探索が、対応するカードを 自動的に見つけることができるようにです。 二枚以上のイーサネットカードを備えたシステムで、その内の 少なくとも一枚が ISA のカードの場合には、 依然として以下のいずれかを行う必要があります。)
2番目 (および3番目、および...) のカードの自動認識を可能にするには、
2つの方法があります。もっとも簡単なのは起動時にカーネルへ引数を与
えることです。通常は LILO でこれを行ないます。
ether=0,0,eth1 のような簡単な引数をブート時引数に与えれば、
2番目のカードを探索することができます。
この場合、起動時にカードが見つかった順番に eth0, eth1
が割り当てられます。 0x300 のカードを eth0 に、
0x280 のカードを eth1 にしたいなら、
LILO: linux ether=5,0x300,eth0 ether=15,0x280,eth1
とします。 ether= コマンドは上記のIRQ + I/O + 名前以外の
ものも受け付けます。
構文の全て、カード固有のパラメータ、LILO の裏技等を知りたい場合は
カーネルにイーサネット関連引数を渡す方法
を見てください。
これらの起動時の引数を、毎度毎度入力しなくてすむようにもできます。
LILO のマニュアルから設定オプション
`append' の項を参照してください。
2つめの方法 (お勧めできません) は、 Space.c を編集し、
I/O アドレスの 0xffe0 エントリを 0 に書き換えてしまうことです。
0xffe0 エントリは、カーネルにそのデバイスを検出しないようにさせます。
これを 0 にすれば、デバイスを自動検出するようになります。
Linuxを2つのネットワーク間のゲートウェイとして使用するつもりなら、 IP forwardingを有効にしてカーネルを再コンパイルしなければなりません。 通常は `kbridge'のようなソフトウェアを利用して、古いAT/286マシン をゲートウェイにしたほうがよいでしょう。
この文書をネットサーフィンの途中で見ている人は、 Donald の WWW サイトにある mini-HOWTO を見てみるといいでしょう。 以下の URL です。 Multiple Ethercards.
訳注: 上記の日本語訳は http://www.linux.or.jp/JF/JFdocs/Multiple-Ethernet.html にあります。
ether= ってやっても何もおきません。なんで？
上記のように、 ether= コマンドはカーネルに組み込まれた
ドライバでしか動作しません。今日のほとんどのディストリビューションは
モジュール化されたかたちでドライバを利用しているので、
ether= コマンドはもはやほとんどの場合使えません。
(古い文書では、まだこのあたりの変更に応じた更新がされていないかも
しれません。)
モジュール化されたイーサネットドライバにオプションを与えたい場合は、
/etc/conf.modules ファイルの方を変更しなければなりません。
ドライバをカーネルに組み込んでいて、 ether= を
LILO の設定ファイルに追加した場合は、
ファイルの変更後に lilo を再実行しなければ
更新情報が反映されないことに注意してください。
問題: PCI NE2000 クローンカードが v2.0.x のブート時に検知されない。
理由:
v2.0.30 までの ne.c ドライバが知っている PCI ID 番号は、
RealTek 8029 ベースのクローンカードのものだけだったのです。
これ以降、 PCI NE2000 クローンカードが他からもいくつか
リリースされ、それらは別の PCI ID 番号を使っていたため、
ドライバはこれを検知できないのです。
解決法: 一番簡単な解決法は v2.0.31 以降のカーネルにアップグレードすることです。 これらのカーネルは NE2000-PCI チップの 5 種類の ID 番号を知っており、 ブート時やモジュールとしてロードされたときにカードを自動的に検知します。 2.0.34 以降にアップグレードすれば、 PCI 専用の NE2000 ドライバを 使うことができ、これは従来の ISA/PCI ドライバよりも多少小さく、 より効率的です。
問題: ブート時や ne.0 モジュールをロードしたとき、 PCI NE2000 クローンカードが ne1000 (8 ビットカード!) として 報告されます。したがって動作しません。
理由: PCI クローンの中には、byte wide アクセスを実装していない ものがあります (つまりこれらは本当の 100% NE2000 互換では ありません)。これによって検知ルーチンは、 NE1000 カードだと 思ってしまうのです。
解決法: 上述のように、 v2.0.31 以降にアップグレードする必要があります。 現在のドライバはこのハードウェアのバグをチェックするようになりました。
問題: PCI NE2000 カードの性能がとても悪いです。 性能を上げるためのヒント にあるように、 ウィンドウサイズを減らしてもだめです。
理由: オリジナルの 8390 チップの spec シート (設計・販売は 10 年前) では、 信頼性を最大限にするためには write 操作の前にダミーのリードが必要 であると記述されています。ドライバはこれを行う機能を持っていますが、 v1.2 カーネルの頃以降、デフォルトでは無効にされています。 あるユーザによると、この「ミス回避機能」を有効にすることによって、 安物の PCI NE2000 クローンカードの性能向上に効果があったそうです。
解決法:
これは一人の人から報告されただけですから、あまり期待しないように。
"read before write" を有効にするには、 linux/drivers/net/
のドライバファイルを編集して、 NE_RW_BUGFIX の行を
アンコメントするだけです。その後お使いの環境にあわせて
カーネルかモジュールをビルドし直してください。
これがうまくいったら、性能の違いとお使いのカード/チップのタイプを
書いて、私に電子メールを送ってください。
(同様の手法は ne2k-pci.c ドライバにも適用可能です。)
問題:
ne2k-pci.c ドライバが timeout waiting for Tx RDC
というようなエラーメッセージを出し、 PCI NE2000 カードがうまく動きません。
理由: お使いのカードや、カードと PCI バスのリンクが、 このドライバで用いられている long word の I/O 最適化を 扱うことができないからです。
解決法:
まず BIOS/CMOS セットアップで変更可能な設定項目をチェックして、
関係する PCI バスのタイミングが安定動作に害を及ぼすような過激な
値になっていないか確かめてください。
これがだめなら、 ISA/PCI 用の ne.c ドライバを
使えば (あるいは ne2k-pci.c から
#define USE_LONGIO の行を削除すれば)
現在のカードを利用できるはずです。
問題: ISA Plug and Play の NE2000 カード (RealTek 8019 など) が検知されません。
理由: オリジナルの NE2000 の仕様では (すなわち Linux NE2000 ドライバでも) Plug and Play をサポートしていないからです。
解決法:
カードについてきた DOS の設定ディスクを使って PnP を無効にし、
カードの I/O アドレスと IRQ を適切な値に指定してください。
そして /etc/conf.modules に、 options ne io=0xNNN
のような行を追加してください。ここで 0xNNN はカードに指定した
16 進の I/O アドレスです。 (なお、これはモジュール化ドライバを
使っている場合です。そうでない場合はブート時に ether=0,0xNNN,eth0
のような引数を指定してください。)
もしかしたら BIOS/CMOS 設定で、指定した IRQ を PnP ではなく
Legacy-ISA にマークする必要があるかもしれません。
あるいは、他の OS との互換性を保つために PnP を残しておきたいことも
あるかもしれません。この場合は isapnptools パッケージを
覗いてみてください。 man isapnp すれば、システムに既に
インストールされているかどうかわかります。
インストールされていない場合は以下の URL を訪ねてみましょう。
問題: NE*000ドライバが起動検出時に `not found (no reset ack)' (見つかりません、リセットに対して応答がありません) というメッセージを出します。
理由: これは上述の変更に関係しています。 8390 が探索された I/O アドレスに存在することが確認されると、 リセットが行われます。カードのリセットが終了したとき、 カードから「リセットが完了した」という通知がされることになっています。 カードが応答しない場合、ドライバは NE カードが存在しないものとします。
解決法:
ドライバに、使っているカードが悪い (bad な) カードであることを
伝えることができます。
ブート時に、 mem_end の部分に
0xbad という 16 進の値を指定すれば良いのです
(mem_end はこれ以外の用途には使われません)。
この 0xbad を用いる際には、カードの I/O ベースアドレスに
0 でない値を指定しなければなりません。例えば
0x340 にあるカードがリセットを ack しない場合は、
以下のような指定になります:
LILO: linux ether=0,0x340,0,0xbad,eth0
これによって、カードがリセットに ACK しない場合でも
カード検知は継続されます。ドライバをモジュールとして
用いている場合は、 I/O アドレスを指定する場合と同じような形式で、
bad=0xbad というオプションを与えてください。
問題: NE*000カードが最初のネットワークアクセスの際にマシンをハングさせます。
理由: この問題は昔の1.1.57のカーネルのころから現在に至るまで報告されています。 これはソフトウェアから設定できるクローンカードに限られた問題のようです。 このようなカードは、特定の方法で初期化する必要があるようです。
解決法: 何人かの人たちから、以下のような報告があります。 カードについてきた DOS の設定プログラムや、 DOS のドライバを 走らせておいてからウォームブート (つまり loadlin するか 「三つ指ついてごあいさつ (訳注: Ctrl-Alt-Del :-)」するか) して Linux に入れば、これらのカードを動作させることができるそうです。 おそらくこれらのカードは、現在の Linux ドライバでなされているのとは若 干異なる、特別な方法で初期化しなければならないのでしょう。
問題:
アドレス 0x360 にあるカードが検出できない。
理由:
お使いの NE2000カードが 0x20 分の I/O 空間を使用します。
その結果、 0x378 に存在するパラレルポートと
ぶつかることになります。あるいは 2 つめのフロッピーコントローラを
使っている場合はそれが 0x370 に、また 0x376-0x377
に 2 つめの IDE コントローラがあるかもしれません。
これらのポートが先に他のドライバによって登録されてしまうと、
カーネルは検出を実行しません。
解決法:
カードのアドレスを 0x280, 0x340, 0x320 などに移動するか、
パラレルプリンタのサポートを外してカーネルをコンパイルしなおしましょう。
問題: 何か印刷するとネットワークが「どこかに行って」しまいます (NE2000)
原因: 上記と同じ問題です。ただ使っているカーネルが古くて、 I/O 領域の多重使用をチェックしていないのでしょう。 上と同じ方法で直ります。その時にはカーネルも新しくしたほうがいいでしょう。
問題: NE*000 ethercard probe at 0xNNN: 00 00 C5 ... not found. (invalid signature yy zz) と表示される。
理由:
まず、アドレス 0xNNN に NE1000 あるいは NE2000が存在しますか？
もしそうなら、表示されるハードウェアアドレスは正しいもののようでしょうか？
これも OK なら、使ってるのはダサい NE*000 クローンなんでしょう。
全ての NE*000 クローンは、カード上の SA PROM のバイト 14 と 15
に 0x57 という値を持っていなければなりません。
このように表示されるカードはこの値になっておらず、
`yy zz'が書き込まれているんです。
解決法:
この問題を回避する方法は二つあります。簡単なほうは
上記の `no reset ack' 問題のところで述べたように、
mem_end の値に 0xbad を使うやり方です。
こうすると、 0 でない I/O ベースアドレスが与えられていれば
指紋チェックをスキップします。
この方法はカーネルを再コンパイルしなくてもすみます。
二つめの方法はハッカー向きで、ドライバを書き換えてカーネル
(あるいはモジュール) を再コンパイルします。
ドライバ (/usr/src/linux/drivers/net/ne.c) には、
42 行目あたりに ``Hall of Shame (恥さらしの殿堂)''
と呼ばれるリストがあります。
このリストはダサいクローンの検出に用いられます。
例えば DFI のカードでは、
通常想定されているバイト 14、15 の 0x57 の代わりに、
PROM の先頭 3 バイトにある `DFI' を使うようになっています。
問題: ブート時に `8390...'や`WD....'というメッセージが出て、 その直後にマシンがハングする。NE2000 を取り外すとハングしない。
解決法:
NE2000 のベースアドレスを 0x340 へ変更してください。
あるいはブート引数 ``reserve='' を ``ether='' 引数と一緒に用いて、
他のデバイスドライバによる探索からこの領域を保護するやり方でも OK です。
理由: お使いのカードの互換性が足りないのです。 動作している NE2000 は、その I/O 空間を自動探索しようとする 他のドライバに対して、底無しの落し穴となります。 NE2000 をあまり人気のないアドレスに変更して、 他の自動検出から外してあげれば、マシンを起動することができます。
問題: マシンが起動時のSCSI検出中にハングする。
理由: 上記と同じ問題です。 イーサカードのアドレスを変更するか、 ブート引数 reserve/ether を使用してください。
問題: ブート時のサウンドカード検出中にマシンがハングする。
理由: いえ、実際には無言のうちに SCSI の探索が行われているんです。 ですので上記と同じ問題です。
問題: NE2000 が起動時に検出されない - ブートメッセージが何も出ない。
解決法: 検出されない理由にはさまざまなものがあり得るので、 「魔法の解決法」は存在しません。以下のリストが、 問題解決までの道のりの手助けとなるでしょう。
1) 新しいカーネルを、必要なデバイスドライバだけでビルドしてみましょう。
新しいカーネルでブートしていることを確認しましょう。
lilo の実行を忘れたりすると、古いカーネルでブートされちゃうかもしれま
せん (ブート時に表示される時刻/日付をよく見ましょう)。
当たり前のように思えるかもしれませんが、皆がはまってきた道なのです。
新しいカーネルにドライバがちゃんと含まれているか確認しましょう。
System.map ファイルに ne_probe のような名前がありますか？
2) ブートメッセージをよく見ましょう。
`NE*000 probe at 0xNNN: not found (blah blah)' のような NE2000
の探索メッセージが出ていますか？それともだまって失敗していますか？
両者には大きな違いがあります。
ログインしてから dmesg | more とすれば、ブートメッセージを
再確認できます。
あるいはブートが完了してログインプロンプトが出た後に
Shift-PgUp すれば、スクリーンをスクロールアップさせることができます。
3) ブートした後、 cat /proc/ioports して、
カードが必要とする I/O 領域が全部空いているかを確認しましょう。
0x300 を使うなら、 ne2k ドライバは 0x300-0x31f を
必要とします。他のドライバがこの範囲の一部でも予約していると、
このアドレスへの探索は行われず、黙って次のアドレスへの探索と
進みます。よくあるケースとしては、 lp ドライバが 0x378
を、second IDE チャネルが 0x376 を予約していて、
0x360-0x380 へのドライバのプローブが行われない場合があげられます。
4) 同じように cat /proc/interrupts もやってみましょう。
他のデバイスがイーサカードにセットした割り込みを使っていないか
確認してください。この場合には探索は行われ、
イーサードライバはブート時に「必要な IRQ ラインが使えない」
と大声で文句を言います。
5) これでもまだドライバが沈黙したまま動作しない場合は、
原因を調べるために printk() をいくつか追加してみましょう。
例えば ne2k の場合なら、
linux/drivers/net/ne.c に以下のような行を
追加(+行)したり削除(-行) したりしてみましょう。
int reg0 = inb_p(ioaddr);
+ printk("NE2k probe - now checking %x\n",ioaddr);
- if (reg0 == 0xFF)
+ if (reg0 == 0xFF) {
+ printk("NE2k probe - got 0xFF (vacant I/O port)\n");
return ENODEV;
+ }
こうするとポートアドレスをチェックするたびにメッセージを出力します。 カードのアドレスが探索されているかどうかがわかります。
6) Don の ftp サイト (既に紹介してあります)
から ne2k 診断ツールを入手して、 Linux のブート後に、
このツールがカードを検出できるかどうか試してみることもできます。
`-p 0xNNN' オプションを使って調べる場所を指定してください。
(デフォルトは 0x300 で、ブート時とは異なり、他の場所は
見に行きません。)
カードが検出された場合の出力は以下のようになります。
Checking the ethercard at 0x300.
Register 0x0d (0x30d) is 00
Passed initial NE2000 probe, value 00.
8390 registers: 0a 00 00 00 63 00 00 00 01 00 30 01 00 00 00 00
SA PROM 0: 00 00 00 00 c0 c0 b0 b0 05 05 65 65 05 05 20 20
SA PROM 0x10: 00 00 07 07 0d 0d 01 01 14 14 02 02 57 57 57 57
NE2000 found at 0x300, using start page 0x40 and end page 0x80.
レジスタの値と PROM の値はこれと異なるかもしれません。
PROM の値が 16ビットカードでは倍になること、
最初の行にはイーサネットアドレス (00:00:c0:b0:05:65) が表示されること、
PROM の最後に 2 つの 0x57 が指紋として登録されていること
などに注目してください。
カードが 0x300 にインストールされていない場合の出力は
以下のようになります。
Checking the ethercard at 0x300. Register 0x0d (0x30d) is ff Failed initial NE2000 probe, value ff. 8390 registers: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff SA PROM 0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff SA PROM 0x10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Invalid signature found, wordlength 2.
0xff の値は、空の I/O ポートを読み込んだ時に返ってきた値です。
もしたまたま他のハードウェアがこの領域にあれば、
0xff 以外の値が現れる可能性もあります。
7) DOS のブートフロッピーから、 (loadlin を使って) Linux をウォームブートさせてみてください。 ブートの前に、カードについてきた DOS のドライバか設定プログラムを 走らせておいてください。これらがカードの初期化に 余分な (つまり非標準の) 手妻を使っているかもしれません。
8) Russ Nelson の n2000.com パケットドライバを使って、 カードが見えるか確認してください。見えない場合は、 多分状況は良くないでしょう。例を示します:
A:> ne2000 0x60 10 0x300
引数はソフトウェア割り込みベクタ、ハードウェア IRQ、 I/O ベースアドレスです。このコマンドは pktdrv11.zip にあります。有名な msdos アーカイブならきっと あるでしょう。現在のバージョンは 11 より新しいかもしれません。
問題: 以下のようなメッセージが表示される:
eth0: bogus packet size: 65531, status=0xff, nxpg=0xff
理由: 共有メモリに問題があります。
解決法:
最もよくある原因は、PCI マシンが ISA メモリデバイスに
マップするように設定されていない場合です。したがって、
受信パケットのデータが含まれている、本来見にいくべきカードの RAM ではなく、
PC の RAM の一番最後 (値が全部 0xff) を
見にいってしまっているのです。
他にありがち (で修正が簡単) なものとしては、ボードの競合、 キャッシュかその領域の `shadow ROM' が有効になっている、 ISA バスが 8MHz 以上で動作している、などがあります。 イーサネットカードでのメモリ不良も、じつは驚くほどたくさん起きています。 こんな問題が起きた場合には、診断プログラムを走らせておくといいですね。
問題: SMC EtherEZ がメモリ非共有モード (PIO モード) で動作しません。
原因: Ultra ドライバの古い版はメモリ共有モードの動作しか サポートしていなかったからです。
解決法: カーネル 2.0 以降のドライバは PIO モードの動作もサポートしています。 2.0 より新しいバージョンにアップグレードしましょう。
問題: 古い wd8003 や、ジャンパ設定式の wd8013 で、 正しくない IRQ が取得されてしまいます。
原因: 古い wd8003 カードやジャンパ設定式の wd8013 クローンには、 ドライバが IRQ 設定を読み込む対象とする EEPROM がついていません。 IRQ を読めないと、ドライバは auto-IRQ を使って IRQ を見つけようとします。そして auto-IRQ が 0 を返すと、 ドライバは単純に 8 ビットのカードには 5 を、 16 ビットのカードには 8 を割り当てようとします。
解決法: auto-IRQ コードを使わないようにして、カードにジャンパ設定した IRQ をカーネルに教えてあげましょう。モジュールの設定ファイル (あるいはカーネル組み込みドライバの場合はブート時引数) を使います。
問題: SMC Ultra カードが wd8013 と検知されますが、 IRQ と共有メモリのベースアドレスが間違っています。
原因: Ultra カードは wd8013 と非常によく似ており、 Ultra のドライバがカーネルにないと、 wd ドライバが Ultra を wd8013 と間違えてしまうことがあるかもしれません。 Ultra の探索は wd よりも先に行われるので、 普通の場合にはこのようなことは起こりません。 Ultra は IRQ とメモリベースを wd8013 とは異なったフォーマットで EEPROM に保存しています。このため妙な値が報告されてしまうのです。
解決法: 必要なドライバだけが組み込まれるようにカーネルを再構築しましょう。 wd と Ultra カードが 1 台のマシンに共存していて、 モジュールを使っているときは、 ultra モジュールを先にロードしてください。
問題: 3c503 が IRQ Nを選択しますが、これは IRQ N を使用する別のデバイス (例えばCD ROMドライバやモデムなど) のために必要なんです。 カーネルをコンパイルしなおさずにこの問題は解決可能ですか?
解決法:
3c503 ドライバは空いている IRQ 線を {5、9/2、3、4} の順に検出してい
きます。そして使われていない IRQ を選択することになっています。
ドライバは ifconfig が行われ、動作に入る段階でこの選択を行います。
モジュール化されたドライバを使っている場合は、 モジュールのパラメータで色々な設定ができます。 もちろん IRQ の値もです。
以下では IRQ9、ベースアドレス 0x300, <ignored value>,
if_port #1 (外部トランシーバ) を選択しています。
io=0x300 irq=9 xcvr=1
あるいはドライバがカーネルに組み込まれている場合は、 以下のようなパラメータを LILO を使ってブート時に渡せば 同じ値が設定できます。
LILO: linux ether=9,0x300,0,1,eth0
以下では IRQ3, ベースアドレスの自動検出、<ignored value>, デフォルトの if_port #0 (内蔵トランシーバ) を指定しています。
LILO: linux ether=3,0,0,0,eth0
問題: 3c503: configured interrupt X invalid, will use autoIRQ. と表示される。
理由: 3c503カードはIRQ{5、2/9、3、4} のどれかしか使えません (カードに接続されている IRQ 線はこれらだけなのです)。 もしこれ以外の IRQ を設定してしまうと、 上述のようなメッセージが表示されてしまいます。 通常は 3c503 の IRQ を指定する必要はありません。 ifconfig を行なった際に IRQ が自動検出され IRQ{5、2/9、3、4} のうち 1 つが選択されます。
解決法: 上述の有効な IRQ のどれかを使用するか、 IRQ の指定をやめて自動検出を使ってください。
問題: 3c503 ドライバで AUI (thicknet) ポートを使用できない。 デフォルトの thinnet ポートではなく、 こちらを使うにはどうするのか？
解決法: 3c503 AUI ポートはカーネル組み込みドライバなら起動時に、 モジュールドライバならロード時に選択が可能です。 この選択は、現在は用いられていない dev->rmem_start 変数の下位ビットを立てることで可能です。 つまり、起動時パラメータ
LILO: linux ether=0,0,0,1,eth0
を用いればカーネル組み込みドライバなら機能するはずです。
モジュールのロードの際に AUI ポートを指定するには、
xcvr=1 を I/O および IRQ の値と一緒に
モジュールのオプション行に追加するだけで OK です。
最高の結果 (と最低の不快感) のためには、カードに付属のプログラム
(通常は DOS のものでしょう) を用いて PnP メカニズムを無効にし、
I/O アドレスと IRQ には固定値を用いることです。ここで指定した
I/O アドレスをブート時の探索に用いるようしてください。
モジュールを使っているなら io= オプションを
/etc/conf.modules に記述してください。
場合によっては BIOS/CMOS setup に入り、指定した IRQ を
PnP ではなく Legacy-ISA にマークする必要があるかもしれません
(コンピュータにこのオプションがある場合)。
なお、 DOS ベースの設定プログラムを動かすために DOS をインストール する必要は、通常はありません。 DOS のフロッピーディスクから ブートして、カードについてきたフロッピーに差し替えて実行すれば いいはずです。 OpenDOS や FreeDOS なら無料でダウンロードできます。
他の OS との互換性を保つために PnP を有効にしておきたい場合は、
isapnptools パッケージを用いてカードをブートの度に設定する
必要があります。この場合もカードにあてがわれた I/O アドレスが
ドライバによって探索されるようにする
(あるいは io= オプションを与える) 必要があります。
大抵の場合は、 使用したいカードのサポートが組み込まれていないカーネルを 使っているのが原因でしょう。 モジュール化されたカーネルなら、 必要なモジュールがロード要求されていないか、 I/O アドレスをモジュールのオプションに 指定しなければならない、などが考えられます。
モジュールベースのカーネル
(大抵の Linux ディストリビューションがインストールするのはこれ)
を使っているなら、
そのディストリビューションの設定ユーティリティを使って
お使いのカードのモジュールを選んでください。
ISA のカードでは I/O アドレスを決めておいて、
設定ユーティリティがオプション入力を求めたときに、
その値をオプションに指定する (例: io=0x340) のが良いでしょう。
設定ユーティリティがない場合は /etc/conf.modules に
正しいモジュールの名前 (とオプション) を追加する必要があるでしょう。
詳細は man modprobe を見てください。
ディストリビューションの一部として配布されている コンパイル済みカーネルを使っている場合は、 文書を読んでどのカーネルをインストールしたのか、 自分のカードのサポートが一緒に組み込まれているかをチェックしましょう。 組み込まれていない場合には、カードをサポートしている別のカーネルを 取得するか、自分でカーネルをビルドする必要があります。
通常、自分の必要なドライバだけを組み込んだカーネルを構築するのが賢い 方法です。カーネルのサイズを小さくできますし (アプリケーションのため に貴重なRAMを節約できます！)、過敏なハードウェアに問題を生じさせるデ バイスの自動検出の回数を減らすことができます。カーネルのコンパイルは思 ったほど複雑なことではありません。どのドライバが必要か、という一連の 質問に答えていくだけで、あとは全部勝手にやってくれます。
(訳注: Kernel-HOWTO 等をご覧ください。)
次なる大きな原因は、カードが必要とする I/O 空間の一部を他のデバイスが使
用している、というものです。ほとんどのカードは I/O 空間を 16 あるいは
32 バイト幅で使用します。カードが 0x300 以降の
32バイトを使用するように設定されていると、
ドライバは 0x300-0x31f を要求します。他のデバイスドライバがそ
の範囲内で 1 ポートでも登録してしまっていると、そのアドレスにおいて検出
は行なわれずドライバは黙って次のアドレスへ検出に行きます。ですから
ブートした後に cat /proc/ioports を行ない、
カードの要求する I/O 空間が完全に空いているか確認してみてください。
別の原因としては、デフォルトでは検出されない I/O アドレスにジャンパ設
定してしまっている、というものがあります。
それぞれのドライバで探索されるアドレスは、ドライバソースの
コメントテキストのあとに書いてありますので、簡単に見付かります。
カードの I/O 設定が探索アドレスのリストになくても、
カーネルにイーサネット関連引数を渡す方法
で説明するように、起動時に (カーネル組み込みドライバなら)
ether= コマンドを使って I/O アドレスを指定することができます。
モジュールドライバなら /etc/conf.modules に
io= オプションを使って、デフォルトでは探索されない
アドレスを指定することができます。
ifconfig が、間違ったカード I/O アドレスを報告する
いいえ、間違ってません。あなたが誤解しているのです。これはバグで
はありませんし、報告されている数値は正確です。
特定の 8390 ベースのカード (wd80x3, smc-iltra など) では、
割り当てられた I/O ポートの先頭からずれたところに
実際の 8390 チップが存在しているのです。
dev->base_addr に記録されているのはこの値で、
これが ifconfig の報告する値なのです。
カードが使用するポートの全範囲を知りたいなら、
cat /proc/ioports すれば望みの値が得られます。
PCI BIOS のなかには、電源 ON の時に全ての PCI カードを有効に しないものがあるようです (特に BIOS オプションの `PNP OS' が 有効になっている場合には)。この「欠陥」は、 いまだにリアルモードのドライバが残っている 現在の Windows をサポートするためのものなんです。 このオプションを無効にするか、無効なカードを有効にするコードが 入っている新しいドライバにアップグレードしてください。
0xffff)
このときには大抵、たくさんの 0xffff が表示されることになるでしょう。
いかなる共有メモリタイプのカードも、 PCI ROM BIOS/CMOS SETUP
を適切に設定しなければ、 PCI マシンで使用することはできないでしょう。
カードが使用するメモリ領域に対して、
ISA バスからの共有メモリアクセスが可能となるように
設定しなければいけません。
どの設定が正しいのかわからない場合は、メーカーに問い合わ
せるか、お近くのコンピュータの導師様にお聞きください。
AMI BIOS では、これは通常 "Plug and Play" セクションにある
``ISA Shared Memory Size'' と ``ISA Shared Memory Base'' 設定です。
wd8013 や SMC Ultra では、これをデフォルトの `Disabled' から 16KB
に変更し、ベースをお使いのカードの共有メモリアドレスに変更します。
cat /proc/interruptsしてみましょう。
表示の中に、カードが生成した割り込みイベントの
起動時からの総回数があるはずです。
もしこれが 0 か、あるいはカードを利用しても増加しない場合は、
おそらくそのコンピュータにインストールされている他のデバイスと
割り込みが物理的に衝突しているのでしょう
(その「他のデバイス」用のドライバがインストールされているか、
起動されているかどうかはこの際関係ありません)。
二つのデバイスのどちらかの IRQ を空いている IRQ に変更しましょう。
Werner Almesberger が Linux の ATM サポートに取り組んでいます。 彼は Efficient Networks の ENI155p ボード ( Efficient Networks) と Zeitnet の ZN1221 ボード ( Zeitnet). に対して作業を行なってきました。
Werner によれば、 ENI155p のドライバはかなり安定ですが、 ZN1221のドライバはまだ完成していない、ということです。
最新の状態については以下の URL をチェックしてください:
Linux に gigabyte イーサネットのサポートはあるのでしょうか？
はい、少なくとも二つあります。 Packet Engines G-NIC PCI Gigabit Ethernet adapter 用のドライバが v2.0 と v2.2 カーネルに入っています。 より詳しい情報やサポート状況、ドライバの更新状況については、 以下をどうぞ:
http://cesdis.gsfc.nasa.gov/linux/drivers/yellowfin.html
v2.2 カーネルにある acenic.c ドライバが
Alteon AceNIC Gigabit Ethernet card と、
他にも 3Com 3c985 等の Tigon ベースのカードに使えます。
このドライバは NetGear GA620 にも使えるはずですが、
これはまだ確認されていません。
Linux に FDDI のサポートはあるのでしょうか？
はい。 Larry Stefani が Digital の DEFEA (FDDI EISA) と DEFPA (FDDI PCI) カードに対する v2.0 用のドライバを書いています。 これは v2.0.24 カーネルで取り込まれました。 ただし今のところは、他にはサポートされたカードはありません。
全二重を使えば 20Mbps 出せますか？ Linux ではサポートされてます？
Cameron Spitzer は全二重の 10Base-T カードについて 以下のように書いています。 「もしこれを全二重のスイッチングハブに繋ぎ、 あなたのシステムが充分高速で他にすることがあまりなければ、 双方向のリンクを busy 状態に維持することができるでしょう。 なお全二重の 10BASE-2 (細い同軸ケーブル) とか 10BASE-5 (太い同軸ケーブル) とかいうものはありません。 全二重はアダプタでのパケット衝突検知を無効にすることによっ て動作します。これが同軸ケーブルを使えない理由です (同軸ケーブルの LAN はこのような状況では動作しませんから)。 10BASE-T (RJ45 インタフェース) は送信と受信に別々の 信号線を用いているので、両方を同時に使うことが可能です。 パケット衝突の問題はスイッチングハブが面倒を見てくれます。 信号転送速度は 10Mbps になります」
ですからおわかりのように、送信または受信を 10Mbps で行えるのであって、 性能が 2 倍になるわけではありません。サポートされているかどうかは カードとドライバに依存します。自動ネゴシエーションをするカードもあれば、 ドライバのサポートを必要とするものもあれば、カードの EEPROM 設定で ユーザがオプションを選ばなければならないカードもあります。 いずれにせよ、この二つのモードの違いがわかるのは カードを真剣、かつヘビーに使っているユーザだけでしょう。
マルチプロセッサ (Multi Processor: MP) コンピュータに
余分のお金を使うのでしたら、
イーサネットカードも良いものを買いましょう。 v2.0 カーネルでは
あまり問題にはなりませんが、 v2.2 ではこのことは非常に重要です。
古いノンインテリジェントなカード (例えば ISA バスの PIO や
共有メモリを用いたカードなど) では、 MP マシンで用いることは
全然考慮されていません。なすべきことを先にまとめておきますと、
インテリジェントな新しい設計のカードを購入すること、その際には
ドライバが MP 動作を扱えるように記述されている (あるいは更新されている)
ことを確認すること、です。
(ここでのキーワードは「新しい設計」です。
PCI-NE2000 は 10 年以上前の設計を新しいバスにつないだものにすぎません。)
ドライバのソースに spin_lock という単語があるかどうかで、
そのドライバが MP 動作を扱えるように書かれているかどうかは
だいたい判断できます。以下に、 MP で用いる時にはなぜ良いカードを
買わなければならないのか (そしてそうしなければどうなるのか)
を述べます。
v2.0 カーネルでは、ある瞬間に「カーネルに入っている」ことができる (つまりカーネルのデータを変更したりデバイスドライバを動作させる ことができる) プロセッサは一つだけでした。ですからカードの方からは (そしてそのドライバの方からは)、単一プロセッサ (Uni Processor: UP) の動作と何ら変わることはなく、物事はそのままで問題なく動作していました。 (これが MP 版の Linux をつくるには最も楽な方法だったのです。 カーネル全体に及ぶ巨大なロックで、一時に一つのプロセッサしか 許さない方法です。このようにすると、二つのプロセッサがある対象を 同時に変更しようすることがなくなります。)
一度に一つのプロセッサしかカーネルに置かない、という手法の欠点は、 MP の性能を得られるのが特殊な場合 (例えば自分の内部にしかデータを持たない、 計算処理に特化したプログラムを動作させる場合) に限られる、ということです。 プログラムがたくさんの入出力 (I/O) をこなす場合には (例えばディスクやネットワークへのデータの読み書き)、 一つを除いた残りのプロセッサは、 I/O 要求がすむまで待たされる ことになります。その一方でカーネルにいるプロセッサは、 馬鹿馬鹿しくも自分の I/O 要求だけのために全部のデバイスドライバを 独占してしまうのです。このようにして、 カーネルで動作するプロセッサが一つしか許されないので、 カーネルがボトルネックになってしまうわけです。 I/O 負荷が大きく、単一ロックの MP マシンの性能は、すぐに シングルプロセッサのマシンと同じくらいにまで下がってしまいます。
これが理想的でないのは明らかですから (特にファイルサーバ、 WWW サーバ、 ルータ等では)、 v2.2 カーネルはロックの粒度をより細かくしました。 つまり複数のプロセッサが同時にカーネルに入れるようにしたのです。 カーネル全体に及ぶ一つの巨大なロックの代わりに、 たくさんのより小さなロックが導入され、これらが クリティカルなデータに対する複数のプロセッサからの同時操作を 防ぐようになりました。つまり、ネットワークカードドライバを 動作させることができるプロセッサは一つですが、その間他の プロセッサはディスクドライブのドライバを動作させることが できるようになったわけです。
OK、以上を頭に入れていただくと、ここにちょっとした問題が生じることが
わかります。より細かなロックによって、以下のようなことが可能になります。
一つのプロセッサがあるイーサネットドライバを通してデータを送信しようと
試みる一方で、他のプロセッサが同じドライバ/カードに他のことを
しようとする (例えば cat /proc/net/dev 用のカードの統計を
取得しようとする) ような状況が考えられるわけです。
あらら、カードの情報がネットを通して送られ、カード情報の代わりに
送信データを取得しちゃいました...
そう、カードは同時に二つの (あるいはもっと多くの!) ことを
要求されると、混乱してしまい、そのプロセスがマシンをクラッシュ
させてしまうことだってありえます。
ですから、ドライバはもはや UP で動作するだけでは充分ではないのです。 ドライバはロックを扱えるように更新されなければいけません。 ロックによる、カードに対するアクセスの制御が必要です。 受信・送信・設定データの操作といった 3 つのタスクを、 カードが安定動作できるような順序に 並べ替えることができなければいけません。 ここで恐いのは、アップデートされておらず、 ロックを扱えないようなドライバでも、 ネットワーク負荷の軽い状況下なら MP マシンで動作してしまうのです。 ところが二つの (あるいはもっと多くの!) プロセッサが これらの 3 つのタスクのうちの 1 つ以上を同時に行おうとすると、 マシンはクラッシュするか、少なくとも妙な振る舞いをするようになるのです。
アップデートされた MP を意識するドライバは、
(最低でも) ドライバの周りにロックを要求し、それによって
エントリポイントへのアクセスを制限し、
カーネルからのドライバへのアクセスを「お一人様づつどうぞ」にします。
こうすると複数アクセスは整列し、ドライバの背後にあるハードウェアは
UP マシンの場合と全く同じように扱われ、
すなわち安定動作するようになります。
この欠点は、イーサネットドライバ全体に対するロックは、
カーネル全体に対するロックと同じように
性能の低下を招いてしまう (しかしより小さなスケールで)、
ということです。つまり、同時にカードを扱えるプロセッサが
一つに制限されるわけです。
[テクニカルノート:
追加しなければならないロックが irqsave タイプのもので、
かつ長期間続くようなものである場合、
割り込みイベントの増加による性能低下も生じることになります。]
この状況の改善手法としては 2 つが考えられます。 ロックの取得から解放までの時間を最小にすること、そして ドライバ内部でのより細かなロックを実装することです (例えば、一つの、あるいは二つのロックによって、 カードのレジスタや設定の敏感な部分への同時アクセスを防ぐことが できさえすれば良いのなら、ドライバ全体に及ぶロックは やりすぎということになります)。
しかし古いノンインテリジェントなカードは、最初から MP 動作を 想定せずに設計されていますので、このような向上は見込めません。 さらに悪いことに、ノンインテリジェントなカードでは、 カード−コンピュータメモリ間のデータ転送がプロセッサに対して 要求されることがあり、最悪のシナリオでは 1.5kB のデータパケットを ISA バスを通して移動する間、 ずっとロックが継続されてしまうことも考えられます。
より新しいインテリジェントなカードでは、通常プロセッサの助力なしに ネットワークデータを直接コンピュータメモリとやりとりできます。 これは非常に性能を向上させます。なぜならこの場合、ロックに必要な 時間は、プロセッサがカードに送信ネットワークデータパケットが 保存されているメモリアドレス (受信パケットを保存するアドレス) を伝える間だけですむからです。さらにより新しい設計のカードでは、 同じようにドライバ全体への大きなロックを必要としないように なってきています。
v2.0 の段階では、 3c509, depca, de4x5, pcnet32, 8390 ドライバ全部 (wd, smc-ultra, ne, 3c503 など) が 「アーキテクチャ非依存」で作られており、したがって DEC Alpha CPU ベースのシステムでも動作します。 Donald の WWW ページにある最新の PCI ドライバも、 おそらく動作するでしょう。これらもアーキテクチャ非依存の 精神に則って書かれていますから。
ドライバをアーキテクチャ非依存にするために必要な変更手順は そんなに複雑ではありません。以下の項目を行なうだけです。
jiffies 関連の値全てに HZ/100 を掛ける。
Alpha が使用する HZ は 100 ではない値を使っているからです
(すなわち timeout=2; を timeout=2*HZ/100; にします)
- int *mem_base = (int *)dev->mem_start; - mem_base[0] = 0xba5eba5e; + unsigned long mem_base = dev->mem_start; + writel(0xba5eba5e, mem_base);
memcpy_fromio() あるいは memcpy_toio()
の適切な方に置き換える。
アーキテクチャ非依存な形でメモリアクセスを扱うことに関しては、
最近のカーネルに付属している
linux/Documentation/IO-mapping.txt
に詳しく記述されています。
Sparc に関する最新情報は以下の URL から取得してください。
Sparc のイーサネットハードウェアの一部には、 MAC アドレスを
ホストコンピュータから取得するものがあります。
ですから複数のインタフェースが同じ MAC アドレスになってしまいます。
2 つ以上のインタフェースが同じネットに必要な場合は、
ifconfig の hw オプションを用いて
ユニークな MAC アドレスを割り当ててください。
PCI ドライバを Sparc プラットフォームに移植する場合の注意点は 上に紹介した AXP プラットフォームの場合とだいたい同じです。 あとエンディアンの問題にも要注意です。 Sparc は big エンディアン を用いますが、 AXP と ix86 では little エンディアンを 用いていますから。
他にも Atari/Amiga (m68k) など、 Linux が動作するハードウェアはいくつかあります。 Sparc の場合と同様に、現在のサポート状況に関しては それぞれのプラットフォームに対する Linux 移植プロジェクトの ホームサイトをチェックしてください (そのようなサイトへのリンクがあったらここに載せます - お知らせください!)
ハブ無しで 10/100BaseT (RJ45) ベースのシステムを接続できますか？
2 台なら簡単に接続できますが、 それ以上だと特別なデバイスや仕掛けなしではできないでしょう。 ケーブル、同軸、ツイストペア の項を参照してください。やり方が書いてあります。 いくつかの線を交差させてつないだりするだけでは、 ハブの代替をさせることはできません。 ハブを使用せずに信号の衝突を正しく処理することには、 かなり無理があります。
起動時に `SIOCSIFxxx: No such device' というメッセージがたくさん出て、 次に `SIOCADDRT: Network is unreachable' というメッセージが出ます。 何が悪いんですか？
起動時/モジュール登録時にイーサネットデバイスが検出されておらず、
その結果 ifconfig と route の実行時に
処理すべきデバイスが存在しないのです。
dmesg | more を実行して起動時のメッセージを確認し、
イーサネットカードの検出に関して何かメッセージが出ていないか確認してください。
ifconfig 実行時に `SIOCSFFLAGS: Try again' と出ます -- 何？
イーサカードが使用する IRQ を別のカードが横取りしてしまったため、
カードがその IRQ を使用できないのです。これを解決するには、
必ずしも再起動する必要はありません。
なぜならデバイスによっては必要な時だけ IRQ を使用し、
用が済んだら解放するものもあるからです。
例としてはサウンドカード、シリアルポート、
フロッピーディスクドライブなどがあります。
cat /proc/interrupts とすれば、
どの割り込みが現在使用されているか確認できます。
Linux のイーサカードドライバのほとんどは、
`ifconfig'から起動されてはじめてIRQを使用します。
ですからほかのデバイスが必要な IRQ 線を解放すれば、
ifconfig で `Try again' することができるでしょう。
ifconfig を引数なしで実行すると、 (10Mbps Ethernet ではなく) LINK が UNSPEC であると表示され、 さらにハードウェアアドレスが全て 0 と表示される。
これはカーネルより新しい `ifconfig' を実行しているからでしょう。 この新しいバージョンの ifconfig は、古いカーネルと一緒に使用すると、 これらの情報を表示することができないのです。 カーネルをアップグレードするか、 ifconfig を「ダウングレード」 してください。 あるいはこのメッセージを無視しても構いません。 カーネルはカードのハードウェアアドレスを取得していますから、 ifconfig がアドレスを読み出せないことはなんら問題ではありません。
逆に ifconfig プログラムがカーネルよりもずっと古い場合も、
おかしな情報が表示されることがあるかもしれません。
ifconfig を引数なしで実行すると、 受信および送信パケットの両方のエラーカウントが非常に多く表示される。 動作はうまく行っているように見えるけど -- 何がおかしいんでしょう？
もう一度よく見てください。
RX packets 大きな数 [空白] errors:0
[空白] dropped:0 [空白] overrun:0
と表示されているはずです。 TX の行も同様です。
あなたが見ている大きな数というのは、
マシンが送受信したパケットの総数ということになんです。
それでも混乱してしまうなら、
代わりに cat /proc/net/dev
としてみてください。
/dev/ のエントリ/dev/eth0 が dev/xxx へのリンクとして存在します。 これで正しいのですか？
以前お聞きになったことと矛盾しているかもしれませんが、
/dev/* のファイルは使用されません。
/dev/wd0 や /dev/ne0
などのエントリは削除しても構いません。
イーサカードを `ifconfig' するときに、 trailers を無効にすべきでしょうか？
trailers を無効にすることはできませんし、そうすべきではありません。 `trailers' はネットワーク層におけるデータのコピーを避けるための仕組みです。 この考え方は、サイズ `H' のあらかじめ決められたサイズのヘッダを使用し、 可変サイズのヘッダ情報をパケットの最後に置き、 そしてページの先頭から `H' バイト前に 全てのパケットを割り当てるというものでした。 いいアイディアではありましたが、 実際には正常に動作しないことがわかりました。 だれかが `-trailers' の使用を提案したとしても、いいですか、 それは山羊の血を生贄にすべきだ、っていってるのと同じ程度のことなんです。 こいつが問題を解決してくれることはありませんが、 問題が勝手に解決してしまったら、 その人は深く神秘的な知識を持っているとみなされちゃうわけです。
TCP/IP などの層を経由せず、 Linux で raw イーサネットデバイスへ アクセスするにはどうしたらいいですか？
int s=socket(AF_INET,SOCK_PACKET,htons(ETH_P_ALL));
これでどのようなプロトコルでも受信できるソケットが得られます。
ソケットへの recvfrom() コールをすると、
ソケットは sa_family のデバイスタイプを sockaddr に、
デバイス名を sa_data 配列にそれぞれ書き込みます。
Linux用の SOCK_PACKET をだれが最初に発明したのかは知りませんが
(もうずいぶん前です)、こいつは非常に「いい仕事」ですねえ。
raw デバイスに sendto() コールを使って送信することもできます。
どちらの場合でも、もちろん root のアクセス権限が必要になります。