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