Linux PCMCIA HOWTO: インストールと設定における問題の解決

3. インストールと設定における問題の解決

この章では、PCMCIA サブシステムで起こしやすい問題をいくつか説明します。現われた症状を例と比べてみてください。この章では、特定のクライアントドライバやカードに固有でない一般的な問題だけを説明します。

問題を分析する前には、システムログが記録される場所を知っておいてください( 個別ディストリビューションに関する注意を参照)。また、dmesg や lsmod のような、基本的な診断ツールにも慣れておいてください。それから、ほとんどのドライバコンポーネント (カーネルモジュール全てを含みます)には専用のオンラインマニュアルが付いていることも忘れないでください。

問題をできるだけ絞り込みましょう。複数のカードを使っている場合は、それぞれを単独で使ってみたり、色々な組合せを試してみましょう。 Linux をコールドブートした結果と Windows からウォームブートした結果を比べてみましょう。カードを挿入したまま起動した結果と起動後にカードを挿入した結果を比べてみましょう。通常はラップトップ機をドックに接続しているのであれば、ドックから切り離してみましょう。また、2 つのソケットの動作が異なる場合もあります。

Linux を PCMCIA 経由でインストールしている時に遭遇したドライバの問題をデバッグするのはほとんど不可能です。症状に基づいて問題を特定しても、インストール用ディスクを修正するのは困難でしょう(特に、動作している Linux システムがない場合)。インストール用ディスクの修正方法は選んだディストリビューションによって全く違い、これは本文書で扱う範囲を超えています。一般的にはこういう場合の最善の策は、別の手段で Linux をインストールすること、最新のドライバを入手すること、それでどうしようもなければ問題をデバッグすることです。

3.1 ベースとなる PCMCIA カーネルモジュールがロードされません

症状:

PCMCIA の起動スクリプトの実行中に、カーネルバージョンの不整合に関するエラーが出る。
起動後に lsmod を実行しても PCMCIA モジュールが表示されない。
cardmgr がシステムログに ``no pcmcia driver in /proc/devices'' と報告を出す。

カーネルモジュールにはバージョン情報が書き込まれており、これはモジュールのロード時に現在動作中のカーネルのバージョンと比べられます。このチェックの種類は、カーネルのオプションである CONFIG_MODVERSIONS の設定によって変わります。これが No ならば、カーネルのバージョン番号はコンパイル時に各モジュールに書き込まれ、insmod はこの値が実行中のカーネルと一致するかをチェックします。CONFIG_MODVERSIONS が Yes ならば、カーネルがエクスポートしたそれぞれのシンボルには、ある種のチェックサムが与えられます。これらのコードは全て、モジュールに組み込まれている該当コードと比較されます。この目的は、モジュールをできるだけバージョンに依存しないようにすることです。というのも、チェックサムが変わるのはカーネルのインタフェースが変わる時だけであり、一般的にはカーネルのマイナーバージョンが上がっても変わらないからです。実際には、チェックサムの制限は厳しいことが分かっています。なぜなら、多くのカーネルインタフェースはコンパイル時のカーネルのオプション設定に依存するからです。また、チェックサムによる互換性の判定は非常に厳しいことが分かっています。

実際の結論としては、カーネルモジュールはカーネルのバージョンと多くのカーネル設定オプションの設定値の両方に密接に関係しています。一般的には、バージョン 2.0.31 のカーネル用に設定したモジュール群は、同じような設定になるように注意して構築していなければ、バージョン 2.0.31 の別のカーネルではロードできないことがあります。そのため、コンパイル済みのカーネルモジュールを配布するのは非常にやりにくい作業です。

選択肢はいくつかあります:

コンパイル済みのドライバを Linux ディストリビューションの一部として入手した場合には、そのディストリビューションに付属している、変更されていないカーネルを使っていることを確かめてください。コンパイル済みのモジュールを使うつもりであれば普通、これに対応するカーネルを使い続けなければなりません。
カーネルの再設定やバージョンアップを行っている場合には、PCMCIA パッケージのコンパイルとインストールを最初から行わなければならないでしょう。カーネルのソースがインストールしてあれば、この作業は簡単です。詳しい手順については、コンパイルとインストールの章を見てください。
場合によっては、他のシステムコンポーネントと互換性がないために、カーネルモジュールを正しくロードできないことがあります。カーネルのバージョンアップをしている場合には、カーネルのソースコードに入っている Documentation/Changes ファイルに書かれている、モジュールユーティリティと binutils の「最低条件」を確かめてください。

3.2 ロードできないクライアントドライバモジュールがあります

症状:

基本モジュール (pcmcia_core, ds, i82365) は正しくロードされている。
カードを挿した時に高いビープ音 + 低いビープ音が鳴る。
cardmgr がシステムログにバージョン不整合のエラーを残す。

一部のドライバモジュールはカーネルのサービスを必要としますが、これはカーネルの設定によりあったりなかったりします。例えば、SCSI カードドライバはカーネルが SCSI をサポートする設定になっていることを必要とし、ネットワークドライバはネットワーク対応のカーネルを必要とします。もしカーネルが必要な機能を持っていなければ、insmod は「undefined symbols」というエラーを出し、そのモジュールのロードを拒否します。insmod のエラーでは、バージョン不整合のエラーとシンボル不足のエラーが区別できないことに注意してください。

もっと正確に書くと以下のようになります:

シリアル用のクライアントドライバである serial_cs を使うには、 CONFIG_SERIAL によってカーネルのシリアルドライバを有効する必要があります。このドライバはモジュールとして作られます。
マルチポートシリアルカードや、シリアルデバイスやモデムデバイスを含むマルチファンクションカードをサポートするには、 CONFIG_SERIAL_SHARE_IRQ を有効にする必要があります。
SCSI 用のクライアントドライバを使うには、CONFIG_SCSI を有効にする必要があります。また、適切なトップレベルドライバオプションを設定する必要があります(バージョン 2.1 のカーネルでは CONFIG_BLK_DEV_SD, CONFIG_BLK_DEV_SR 等)。これらはモジュールとして構築されます。
ネットワーク用のクライアントドライバを使うには、CONFIG_INET を有効にする必要があります。カーネルのネットワークサポートは、モジュールとして組み込むことはできません。
トークンリング用のクライアントドライバを使うには、CONFIG_TR を有効にする必要があります。

解決方法は 2 通りあります:

必要な機能を有効にしてカーネルを再構築します。
この機能がモジュールとしてコンパイルされていれば、 /etc/pcmcia/config を修正して、必要なモジュールを予めロードしておくようにします。

/etc/pcmcia/config では、特定のクライアント用にロードする必要がある追加のモジュールを指定することができます。例えばシリアルドライバを指定する時には以下のように設定します:


device "serial_cs"
  class "serial" module "misc/serial", "serial_cs"

複数のパスを、現在のカーネルのバージョンに対応するモジュールのトップレベルディレクトリからの相対パスで指定します。相対パスが全く与えられなければ、パスのデフォルト値は pcmcia サブディレクトリになります。

3.3 割り込みのスキャンに失敗します

症状:

PCMCIA ドライバがロードされると、カードが挿さっていなくてもシステムが固まってしまう。
システムログには、システムが固まる直前にちゃんとホストコントローラが検出したことが記録されているが、割り込みの検出の結果は記録されていない。

ホストコントローラの種類を識別した後、ソケットドライバは空いている割り込みを探査します。この探査では、空いているように見える割り込みそれぞれに対するコントローラのプログラミングが行われ、その後には「ソフト」な割り込みの生成が行われます。これは割り込みが正しく検出されたかどうかを調べるために行われます。場合によっては、特定の割り込みを探査すると他のシステムデバイスとの衝突が起こることがあります。

探査を行う理由は、空いている(つまり、Linux の他のデバイスドライバに予約されていない)と思われる割り込みで、まだホストコントローラに物理的に接続されていないか、またはドライバを持っていない他のデバイスに接続されているものを識別することです。

探査が成功すると、システムログには以下のような記録が残ります:


Intel PCIC probe:
  TI 1130 CardBus at mem 0x10211000, 2 sockets
  ...
  ISA irqs (scanned) = 5,7,9,10 status change on irq 10

先に進む方法は 2 つあります:

割り込みの探査は、ソケットドライバに対する irq_list パラメータを使った割り込みのリストによって制限されます。例えば ``irq_list=5,9,10'' を指定すると、探査は 3 つの割り込みに対してしか行われません。全ての PCMCIA デバイスは、これらの割り込みを使うように制限されます(探査はうまくいくものとします)。安全に検出できる割り込みを見つけるには、試行錯誤が必要かもしれません。
``do_scan=0'' オプションを付けてソケットドライバをロードすると、割り込みの探査は全く行われなくなります。この場合、デフォルトの割り込みリストが使われるので、既に他のデバイスに割り当てられた割り込みを避けることができます。

いずれの場合も、探査用のオプションの指定には PCMCIA 起動スクリプト内の PCIC_OPTS の定義を用います。設定例を以下に示します:


PCIC_OPTS="irq_list=5,9,10"

割り込み探査で問題が起こった時には、/proc/interrupts を調べても全く役に立たないことは肝に命じておいてください。この探査は、Linux の他のドライバが既に使っている割り込みを使わないようにする程度には賢いのです。ですから、PCMCIA のドライバは既に /proc/interrupts の全ての情報を使っています。システムの設計によっては、動作中でないデバイスでも割り込みを占有し、PCMCIA が探査を行った時に問題を起こすことがあります。

3.4 I/O ポートのスキャンに失敗します

症状:

カードが挿さっていなくても、cardmgr を最初に起動した時にシステムが固まってしまう。
システムログには、割り込み探査の結果も含めてホストコントローラの探査が成功したと記録されるが、I/O 探査の結果は記録されない。
I/O 探査は正常終了するが、でたらめなアドレスがたくさん除外されるという症状が出ることもある。

/etc/pcmcia/config.opts に挙げられている I/O ポート領域を cardmgr が処理する時、カーネルはこれらの範囲を探査し、I/O 空間を占有しているけれど Linux のドライバには割り当てられていない隠れたデバイスを検出します。探査では読み取りしか行われませんが、デバイスからの読み出しが重要なシステム関数と衝突し、その結果システムが固まることが稀に起こります。

お使いのシステムのユーザガイドを見れば、システムデバイスの割り当て表が載っており、I/O 領域とメモリ領域の範囲がわかるかもしれません。そうすると、config.opts でこれらの領域を明示的に除外することができます。

別の方法として、システムの探査が信頼できない場合には、CORE_OPTS の設定を``probe_io=0'' とすることで探査を無効にすることができます。この場合にはデフォルトの設定を使わないで、ちゃんと使えるポートの範囲だけを注意深く config.opts に設定しなければなりません。

3.5 メモリの検出に失敗します

症状:

カードが挿さっていない時にはコアドライバが正常にロードされ、システムログにもエラーが残らない。
カードを挿すと、ビープ音がすることなく、即座にシステムが固まったりリブートする。

以下のような症状が出る場合もあります:

どんなカードを挿しても必ず「高いビープ音 + 低いビープ音」が鳴る。
どんなカードも ``anonymous memory cards(未知のメモリカード)'' と認識される。
あちこちのメモリ領域が除外されていることがシステムログに記録される。

コアモジュールは、16 ビットカードが初めて挿入された時にメモリ走査を実行します。この操作はメモリにマップされている他のデバイスと衝突する可能性があります。またバージョン3.0.0 以前のパッケージでは、最近のドライバよりもきわどい走査を行っていました。メモリウィンドウは /etc/pcmcia/config.opts で定義されています。デフォルトのウィンドウは大きいので、走査をもっと狭い範囲に制限すればよいでしょう。試すのにちょうどよい範囲は 0xd0000-0xdffff, 0xc0000-0xcffff, 0xc8000-0xcffff, 0xd8000-0xdffff あたりです。

DOS または Windows の PCMCIA ドライバがあれば、これらのドライバが使っているメモリ領域を調べてもいいでしょう。DOS のメモリアドレスは多くの場合、「セグメント」の形で指定されており、最終的な 16 進アドレスとは離れている点に注意してください(絶対アドレス 0xd0000 が 0xd000 と与えられたりします)。config.opts を変更する時には、追加の桁を必ず足し戻してください。

普通でない場合として、メモリ探査の失敗が、ホストコントローラに関するタイミングレジスタの設定の問題である可能性があります。一般的なタイミングの問題の扱いについては、起動オプションの節をご覧ください。

cs: warning: no high memory space available!

CardBus ブリッジは、ISA バスのアーキテクチャにおける 640KB-1MB の「メモリの隙間」の外にメモリウィンドウを割り当てることができます。高位のメモリ領域を使うように CardBus ブリッジを設定するのは、一般的には良い考えです。なぜなら他のデバイスと衝突しにくいからです。また、 CardBus のカードは大きなメモリウィンドウを必要としますが、これを低位のメモリ領域に取るのは困難であったり不可能だったりします。カードサービスが CardBus ブリッジに対してはウィンドウを割り当てる際には、 config.opts に高位のメモリと低位のメモリが両方定義されていれば、カードサービスは優先的に高位のメモリを使います。現在のデフォルトの config.opts には高位アドレスのウィンドウ 0xa0000000-0xa0ffffff が含まれています。読者の皆さんが CardBus ブリッジを持っており、かつ古い PCMCIA ドライバからのバージョンアップを行った場合は、このアドレスがまだ定義されていないのであれば、これを追加しましょう。

場合によっては、デフォルトの高位メモリウィンドウが使えないことがあります。IBM ThinkPad の一部のモデルでは、デフォルトのウィンドウの代わりに 0x60000000-0x60ffffff のウィンドウが使えます。

3.6 カードの抜き挿しを検出できません

症状:

起動時にカードが挿してあれば、カードの検出と設定がうまく行われる。
カードの挿入と抜き取りを行ってもドライバが反応しない。すなわち、システムログにも記録が残らないし、ビープ音もしない。

大抵の場合、ソケットドライバ(i82365 または tcic)は適切な割り込みの探査と選択を行い、カードの状態変化を知らせます。割り込みの自動的探査は Intel 互換の一部のカードではうまく動作しません。このようなカードとしては Cirrus 製のチップがありますが、これが IBM の ThinkPad の一部で使われています。探査の時、あるデバイスが動作していなければ、その割り込みは使えるように見えるかもしれません。このような場合には、ソケットドライバは他のデバイスが使っている割り込みを選ぶかもしれません。

i82365 ドライバと tcic ドライバでは、irq_list オプションを使って調べる割り込みを制限することができます。このリストは PCMCIA カードが使える割り込みの組合せと、カードの状態変化を監視する割り込みの組合せを制限します。cs_irq オプションを使って、カードの状態変化の監視に使う割り込みを明示的に設定することもできます。

使える割り込みを見つからなければ、呼び出しモード(polled status mode)を使うこともできます。i82365 と tcic のどちらでも poll_interval=100 といったオプションを設定することができます。この設定を行うと、カードの状態は 1 秒間に 1 回行われる呼び出しで調べられます。このオプションは、PCMCIA カードで使える割り込みが足りない場合にも使うべきです。特に、複数のホストコントローラを持つシステムの場合には、カードの状態の監視に専用の割り込みを割り当ててもいいことはありません。

これらのオプションは全て、/etc/rc.d/rc.pcmcia または /etc/sysconfig/pcmcia ファイル内の PCIC_OPTS= 行で設定することになっているはずです。どちらのファイルを使うかはサイトの設定によって異なります。

3.7 システムリソースの不足

症状:

カードを挿入すると、正しく認識されるが設定ができない( 高いビープ音 + 低いビープ音が鳴ります)。

以下のメッセージのいずれかがシステムログに出力される:


RequestIO: Resource in use
RequestIRQ: Resource in use
RequestWindow: Resource in use
GetNextTuple: No more items
could not allocate nn IO ports for CardBus socket n
could not allocate nnK memory for CardBus socket n
could not allocate interrupt for CardBus socket n

割り込みが不足する場合、割り込み探査に問題があることが多くあります( 割り込みのスキャンに失敗しますの項を参照してください)。場合によっては、探査はうまく行われているように見えるけれど、利用できる割り込みが 1 つあるいは 2 つしか報告されないこともあります。システムログを調べて、探査の結果がそれらしいかどうかを見てください。探査を行わず、割り込みを手動で選んでも問題が解決することがあります。

割り込みの検出がうまく動作していない場合は、割り込みが全く足りなくてカード挿入の監視用に割り込みを割り当てることが好ましくないのに、ソケットドライバがカード挿入の監視用の割り込みを割り当てているのかもしれません。このような場合には、PCIC_OPTS に ``poll_interval=100' を設定してコントローラの設定を呼び出しモードに切り替えるといいでしょう。あるいは、CardBus コントローラの場合には、 ``pci_csc=1'' を試してください。これはカードの状態変化の監視に (利用可能ならば) PCI 割り込みを使うための設定です。

I/O ポートが不足することは普通はありませんが、必要とする I/O ポート空間が巨大かつ連続で、整列されてなければならないカードを使う場合や、特定小数の位置の I/O ポートしか認識しないカードを使う場合には、不足することもあります。普通は /etc/pcmcia/config.opts に設定されているデフォルトの I/O ポート範囲で十分ですが、これを広げることもできます。稀にしか起きませんが、I/O ポートの不足が I/O ポートの探査の失敗によって起こることがあります( I/O ポートのスキャンに失敗しますを参照)。

メモリの不足も、config.opts で設定されているデフォルトのメモリウィンドウ設定を使っていれば普通は起こりません。CardBus カードは、典型的な 16 ビットカードよりも大きなメモリ領域を必要とすることがあります。CardBus のメモリウィンドウは(PC システムが持つ 640KB-1MB の領域の単なる「隙間」でなく)ホストの PCI アドレス空間のどこにでもマップすることができるので、高位メモリ領域(0xa0000000-0xa0ffffff など)に大きなメモリウィンドウを取ると問題が解決することがあります。

3.8 2 枚のカードを挿入した時だけリソースが衝突します

症状:

2 枚のカードを別々に使うとうまく動作する。
両方のカードを同時に挿入すると、片方しか動作しない。

これは普通、Linux が認識していないシステムデバイスとリソースが衝突している時の症状です。PCMCIA デバイスは動的に設定されるので、例えば、割り込みは特定のカードやソケットに明確に割り当てられるのではなく、必要に応じた割り当てが行われます。利用可能と思われるリソースのリストを与えると、カードには設定された順にリソースが割り当てられます。この場合、最後に設定されたカードには、実際には空いていないリソースが割り当てられています。

システムログを調べて、動作していないカードが使っているリソースを探しましょう。/etc/pcmcia/config.opts を編集してこのようなリソースを除外する設定にし、cardmgr デーモンを再起動してリソースデータベースを再読み込みさせてください。

3.9 デバイスの設定が終わりません

症状:

カードを挿入すると、高いビープ音が 1 回だけ鳴る。
それ以降はカードの抜き挿しを行っても無視される。

この症状が示すのは、カードはうまく認識されているものの、何らかの理由で cardmgr が設定処理を終えられないということです。もっともありがちな原因は、カード設定スクリプトのどこかの処理がブロックされていることです。わかりやすい例としては、物理的にネットワークに繋がっていないのにネットワークカードを挿し込むとネットワーク設定スクリプトがブロックされることが挙げられます。

原因を特定するためには、手動で設定スクリプトを実行し、どこでブロックされるかを調べるとよいでしょう。スクリプトは /etc/pcmcia ディレクトリにあります。スクリプトに与える引き数は、デバイス名と動作の 2 つです。cardmgr デーモンは設定コマンドをシステムログに記録します。例えば、``./network start eth0'' というコマンドが cardmgr が実行した最後のプログラムであるという記録がシステムログに残っていれば、以下のコマンドを実行するとスクリプトの動作をトレースすることができます:


sh -x /etc/pcmcia/network start eth0

次のページ前のページ目次へ