問題に出くわしたら、まず以下を試してみてください。
以下の FAQ の章を読む。
/var/log/messages と /var/log/kern の出力を見る。
dmesg を実行する。
/proc/irda の各ファイルを見る。
私は強力なハッカーというわけではありませんが、ここには Linux/IrDA ソフトウェアのエラーやバグを追跡するための技を集めてあります。
/proc/sys/net/irda/debug のデバッグレベルを 1, 2, 3, 4 と変更してみる。
/proc/sys/net/irda にあるファイルを用いて 違うパラメータを試してみる。 例えば、echo 0 > /proc/sys/net/irda/discovery などのようにしてみる。/proc/*/irda ファイルとは
root@duckman:~# ls /proc/sys/net/irda/* /proc/net/irda/* /proc/net/irda/discovery /proc/net/irda/irlmp /proc/net/irda/irda_device /proc/net/irda/irttp /proc/net/irda/irias /proc/net/irda/irlap /proc/sys/net/irda/devname /proc/sys/net/irda/discovery /proc/sys/net/irda/compression /proc/sys/net/irda/debug |
コードをデバッグすることも可能ではありますが、私はやり方を知りません。 SKB デバッグコードを用いたい場合、irda.h を編集し、/include/linux/skbuff.h を変更してください (snapshot 10-2-98 の編集履歴参照のこと)。
irda モジュールに関する問題については、modules パッケージ収録の kdstat ユーティリティが役に立つでしょう。但し、私はまだこれを使えていません。
「使用するディスカバリパケットの数 (1、6、8 または 16) と、それを送る時間間隔 (2-8 * 10mS) を /proc/sys/net/irda で変更できるようになりました。 デバイスの検出で問題が発生していると言うことなら、これを試してください。私の Palm III では 16 ディスカバリスロットと、8 (*10mS) のスロットタイムアウトが好ましいようです」…… 「IR-610 で安定した検出が行える最小のスロット数は 9 のようです」 その他にも「Palm III では 8 ディスカバリフレームを連続して送るのはまずく、6 なら OK です。8 にすると 6-10 回に一回しか返答しませんが、6 だと毎回返答が返ります。これが Linux/IrDA の問題なのか、Palm III が悪いのかは分かっていません。この問題を解決する方法の一つとして、 異なったディスカバリ手法を以下のように順に繰り返して見ることが考えられます。
Discovery 1: send 8 xid frames with 80 ms separation
ここで返答があれば、この設定を引き続き使います。
返答がなければ次の設定を試します。
Discovery 2: send 6 xid frames with 80 ms separation
Discovery 3: send 8 xid frames with 90 ms separation
Discovery 4: send 6 xid frames with 90 ms separation
Discovery 5. 1 に戻る
カーネル Oops となる場合には、それを ../linux/scripts/ksymoops/ksymoops プログラムに食わせれば、どこでおかしくなったかがわかります。 単に Oops を起こした行を syslog から切り抜いて、ファイルに保存し、 ksymoops <file> を実行してください。
Dag Brattli さんによると「cs4232 サウンドカードが毎秒数百回 ! の割り込みを発生させていることを突き止めました。 そこでカーネルからサウンド関係を取り去ったところ、マシンがだいたい 4 倍 ! も速くなりました。Linux/IrDA は esound サーバ (esd) を同じマシンで実行している場合、問題を起こすかもしれません。 私の二台のマシン、166MHz の Pentium と 200MHz の Pentium Pro の両方とも esd を動かしていると Linux/IrDA を実行できません。これは、esd によりサウンドカードが毎秒 300 回の割り込みを発生するため、シリアルドライバが受信オーバフローを起こすからです。 これは Linux-2.2 がシリアルドライバで遅い割り込みを用いている (2.2 ではすべて遅い割り込みで処理されるため) ため、割り込みドライバが抜ける際に割り込み処理がスケジュールされるためです [1]。 遅い割り込みの良い点は、次のタイマの刻みを待つ必要がないためパケットがずっと速く配送されることです。 上記の例外は pc87108 ドライバで、これは esd との組み合わせでも問題なく動作します。これは、このドライバが DMA を用いてパケット当たり数回の割り込みしか起こさないためです」
Linux/IrDA の接続をチェックするには、ユーザ空間ツールの irdaping と irdadump も使えます。
私の知る限り、IrCOMM は赤外線デバイス経由でもシリアルケーブル経由でも使えます。 これはデバッグに役に立つかもしれません。
以下を試してください。
/etc/conf.modules を編集し、次の行を付け加えてください。
option irda irda_debug=3
irda 関係モジュールがすべて削除されていることを確認してください。
/etc/syslog.conf を編集し、次の行を付け加えてください。
*/* -/var/log/all
"killall -1 syslogd" を実行してください。
印刷、またはその他の irlpt で問題を起こしている動作を実行してください。
/var/log/ 以下の全ファイルをチェックしてください。
一部の ThinkPad モデルでは、プリインストールされている M$ OS で再起動して、 ThinkPad ツールを使って IrDA ポートを有効にしなければなりません。これを行う Linux 向けのツールは現在ありません。これは同時に内蔵シリアルポート (ttyS0) を無効化します。DOS 用のツールは PS2.EXE で、私の知る限り tpctl はこの機能を持ちません。 この DOS プログラム (ps2.exe) で赤外線ポートを有効にすることがきわめて重要です。Microsoft windows の ツールを用いてこれを行うことはできません。 これを行わなければ、ドライバは正しくロードされて何もかも OK のように見えますが、LED が十分に明るく発光しません。
Daniel R. Risacher さんによると 「Palm III と私の Tecra 8100 (2.2.17 使用) で同期をとるため、 /usr/src/linux/include/net/irda/toshoboe.h で "#define PCI_DEVICE_ID_FIR701 0x0701" を "#define PCI_DEVICE_ID_FIR701 0x0D01" と書き換える必要がありました」
チップの正しいデバイス ID を得るには、scanport コマンドが使えます。これは hwtools パッケージの一部です (Debian では。他のディストリビューションでも多分同じでしょう)。 単にコマンドを入力すれば、コマンドで 0x100 から 0x400 までの I/O ポート (標準的 ISA のアドレス範囲) をスキャンします。0x400 以上は 0x400 以下のデバイスのシャドウがあり、更に上は PCI デバイスが使っていますので、 標準では 0x400 以上はスキャンしません。「結局 inb を使って私のチップの I/O アドレスを手で探すことになりました。 運良くそんなに先まで見る必要はありませんでした (最近のサウンドカードは 0x530 付近に居座っており、0x220 を従来モード互換のために押さえています)。 普通は、デバイスがアドレス空間内でどこにいるか分かっていれば、 ドライバでそれを指してみて、それがドライバが期待しているデバイスかどうかドライバに検出させることになります。 これは完全に安全とは言えませんが、全ドライバに全 I/O ポートをそのドライバが扱えるものを求めて総当たりさせるよりはずっと安全です scanport はポートの読み込みを行うだけで、これは通常安全です [2]。
| [1] | 訳注: 割り込み処理を引き続いて行うこと |
| [2] | 訳注: PC-AT の仕様上は 16bit フルデコードしろということになっているが、守っているデバイスは少ないため、結果として上のようなことになる。 |