モデムおよび、モデムに対して用いる getty に関しては、Modem-HOWTO の トラブルシューティングの章をご覧ください。
端末が数個だけならばテスタ(電圧計として使います)があれば十分でしょ うが、シリアルポートの配線を調べるための簡単な特殊器具もあります。その 中には「中継コネクタ(breakout)」と呼ばれるものがあります。 「breakout」という言葉は、導線をケーブルから取り出すといった意味です。 このような小物には 2 つコネクタが付いており、シリアルケーブルを繋ぐよ うになっています。電圧計を繋ぐ端子がついているものもあります。特定の モデム制御線がオンになっていると点灯する LED ランプがついているものもあ ります。任意の線と線を接続できるようにジャンパがついているものもありま す。スイッチがついているものもあります。
Radio Shack 等の電器屋で「RS-232 Troubleshooter」つまり 「RS-232 結線テスタ」を売っています(1998 年)。これは TD, RD, CD, RTS, CTS, DTR, DSR をチェックします。緑のランプはオン(+12 V)を表し、赤のランプは オフ(-12 V)を表します。この店では「RS-232 シリアルジャンパボックス」と いう、接続ピンを自由に選べる装置も売っています。
どんな電圧計やテスタでも(10 ドルで売られているような安物でさえ)うま く使えるはずです。 電圧のチェックに他の方法を使うのは面倒です。 抵抗を直列に繋い で LED にかかる電圧を下げない限り、LED を使ってはいけません。 20 mA の LED では 470Ω の抵抗を使ってください(ただし全ての LED が 20 mA とは限りません)。LED は決まった極性でしか光らないので、+ と - の電 圧を調べることができます。自動的に回路を検査するこのような小物を誰か作 りませんか? 論理プローブは使おうとすると壊れてしまうかもしれません。 というのも、TTL が想定している電圧はたったの 5 V だからです。12 V の白熱電球を使うのはやめた方がいいでしょう。電球では極性はわかりませ んし、UART の出力電流は限られているため、たぶん光ることさえないでしょ う。
メスのコネクタの電圧を測定するには、曲げたペーパークリップを調べたい穴 に差し込むとよいでしょう。ペーパークリップの直径はピンよりも小さいはず なので、接触部を傷つけることはありません。接続するためには、ワニ口ク リップ(等)でペーパークリップを挟みましょう。
テストに使える器具が無く、かつ電気ショックを受ける(感電さえする)覚 悟があれば、最後の手段として電圧を味わうという方法もあります。調べる導 線をなめる前には、高圧電流が流れていないことを確かめましょう。両方の導 線に(同時に)片方の手で触れ、ショックを受けるかどうかを確認します。 ショックを受けなければ接触部の肌をなめて濡らし、再び導線に触れてみましょ う。これでショックを受ければ、なめてみる気はきっとなくなるでしょう。
12 V を調べるには、まず指をなめて、一方の導線をその指に押しつけます。 次に別の導線に舌で触れます。舌で触れた導線に正の電圧がかかっていれ ば、はっきりとした味がするでしょう。どんな味がするか前もって知っておき たければ、懐中電灯の電池をなめてみるといいでしょう。
モデム制御線を監視し、その電圧が正(1)であるか負(0)であるかを示す Linux 用のプログラムがいくつかあります。 シリアルポートの監視/診断用のプログラム の章をご覧ください。
デバイス(モデムなど)が確かに動作しているなら、そのデバイスが 繋がっているシリアルポートは検出されています。 まったく動作しないのであれば、 シリアルポートが検出できることを確かめる必要があります。
BIOS のメニューと出力メッセージを確認しましょう。 PCI バスならば lspci を使います。 ISA バス上の PnP シリアルポートの場合には、"pnpdump --dumpregs" を試したり、 Plug-and-Play-HOWTO をご覧になってください。 "scanport" を使うと、ISA 上の全てのポートをスキャンし、 シリアルポートかもしれない未知のポートを見つけることができます(ただし ポートの探査は行いません)。scanport は PC をハングさせるかもしれません。 setserial を使って探査を行ってもよいで しょう。 探査の節を参照してください。 シリアルポートにデータが何も流れていないようであれば、シリアルポートは あっても割り込みが間違っているかもしれません。 この上なく遅い: テキストがすごく遅れてゆっくり画面に表示されます の節をご覧ください。
2 つのポートが同じ I/O アドレスを持っている場合、探査では間違って ポートが一つしか示されません。プラグ&プレイによる検出では 両方のポートが見つかるので、これが問題になるのは、プラグ&プレイで ないポートが少なくとも一つある場合だけです。 「共有」されているポートに接続しているデバイスではほとんどどんなエラー でも報告/検出されることがありますが、同じポートに 2 つのデバイスが繋がっ ているという事実は検出されないようです(幸いにも自分で見つける場合は除 きます)。IRQ が違う場合には、setserial で各 IRQ を探査したときに IRQ の検出に失敗することにより、この状態を「検出」できると思います。 探査の節をご覧ください。
これは割り込みの設定が間違っているか、衝突しているためでしょう。 初めてモデムや端末、プリンタを使おうとしたときに出会うような現象をいく つか示します。場合によっては、入力した文字が何秒も経たないと表示されな いことがあります。入力した最後の文字しか表示されないこともあります。 また、その文字が単に目に見えない<改行>文字で、カーソルが 1 行下 に移動したことしかわからないこともあります。また別の場合としては、 画面にデータはたくさん表示されるのですが、16 文字ごとのかたまりでしか 表示されないこともあります。そして、あるかたまりの次のかたまりが表示さ れるまでには何秒もの長い待ち時間が続きます。 「input overrun(入力オーバーラン)」のエラーメッセージが表示される(ある いはログに残る)こともあります。
詳しい症状とそれが起こる理由については、
割り込みの問題に関する詳しい説明の 章や 割り込みの衝突の節、 割り込みの設定ミスの節を見てください。 プラグ&プレイデバイスがらみの問題なら、Plug-and-Play-HOWTO も 見てください。
本当に割り込みの問題かどうかを簡易的に調べるには、"setserial" で IRQ を 0 に設定してください。これにより、ドライバは割り込みではなくポーリ ングを使うようになります。 これで「遅い」問題が解決するようであれば、割り込みの問題が起きています。 ただし、その場合でも割り込みの問題を解決すべきです。なぜなら、 ポーリングはコンピュータの資源を大量に消費しますし、時には スループットを劇的に低下させるからです。
割り込みの衝突を見つけだすのは容易ではないかもしれません。というのも、 Linux は割り込みの衝突を全く許さず、ユーザが衝突を起こそうとしていると 判断すると /dev/ttyS?: Device or resource busy エラーを送ることになっているからです。 しかし、本当に衝突が起こる可能性があるのは "setserial" が間違った情報を指定していた場合です。 したがって、"setserial" を使っても衝突は明らかになりません(また、"setserial" の情報に基づいて 設定される /proc/interrupts を調べても衝突はわかりません)。 それでもハードウェアの実際の設定を調べる時に、間違っている部分を正確に 突き止めて直すには、"setserial" に設定されている情報を知らなければなり ません。
こういった場合に行うべき作業は、ジャンパや PnP 設定ソフトウェアを使っ て、ハードウェアに実際に設定されている情報を調べることです。PnP の場合 には、"pnpdump --dumpregs" (ISA バスの場合)または "lspci" (PCI バスの 場合)を実行しましょう。 そして、Linux ("setserial" 等)が考えているハードウェアの設定とこの結果 を比べてください。
考えられる理由の一つは、シリアルポートを使っているデバイス(モデム や端末、プリンタ)が、あなたが考えているほど速く動作しないことです。
考えられる別の理由は、あなたが使っているシリアルポートが古い (UART 8250, 16450 や初期の 16550)とシリアルドライバが認識していること です。 UART とは何ですか?を参照し、 "setserial -g /dev/ttyS*" を使ってください。その結果として 16550A より 性能がよくない UART が表示されたら、これは多分設定の問題です。 この場合は、"setserial" の設定に問題があれば、これを変更します。 詳しくは setserial とは何か?を見てください。 当然のことですが、実際は古いシリアルポートを使っているのに setserial をだまそうとしても、単に事態が悪化するだけです。
Linux カーネルはシステムの起動時に IRQ の検出は全く行いません。 serial モジュールがロードされた時に、シリアルデバイスの検出が行われる だけです。したがって、カーネルが IRQ に関して行う表示は無視してくださ い。なぜなら、この時点では標準の IRQ を決め打ちしているからです。この ようになっているのは、IRQ 検出は当てにならず、間違うことがあるからです。 しかし setserial が起動スクリプトから実行された場合には、setserial は IRQ を変更し、新しい(そして多分正しい)状態を起動画面に表示します。 間違った IRQ が後で訂正されて画面に表示されなければ、何か問題が起こっ ています。
よって、IRQ 5 に設定されている ttyS2 がある場合であっても、Linux
の起動時には
ttyS02 at 0x03e8 (irq = 4) is a 16550A
setserial を使わなければ
なりません。
"ls -l /dev/ttyS?" を実行してそのポートのファイルのパーミッション を調べてみましょう。ttyS? の所有者が自分であれば、読み書きのパーミッショ ンとして crw が必要です。最初の桁は c (キャラクタデバイス)です。ポート の所有者でなければ、8 桁目と 9 桁目が rw- でなければなりません。つまり 誰でもそのポートを読み書きできなければなりません。 パーミッションを変更するには "chmod" を使います。 アクセス権限を得る方法としては、グループパーミッションを持っている 「グループ」に所属するといったもっと複雑なものもあります。
このエラーは、カーネルがサポートしていないために、setserial や stty 等が要求した操作が行えないという意味です。以前は "serial" モジュー ルがロードされてないことが原因の場合が多かったのですが、PnP の登場によ り、このエラーはドライバ(および setserial)が考えているアドレスにモデム (あるいは他のシリアルデバイス)がないことを示すことが多くなりました。こ ういったアドレスにモデムがなければ、そのアドレスに送られた(操作のため の)コマンドは当然ながら処理されません。 シリアルポートのハードウェアの設定は? の節をご覧ください。
"serial" モジュールがロードされていなかったが今ロードしたと "lsmod" が表示する場合は、モジュールは今ロードされたけれど、 エラーが出た時にはロードされていなかったのかもしれません。 多くの場合、モジュールは必要な時に自動的にロードされます(もし見つけること ができれば)。"serial" モジュールを強制的にロードさせるには、 /etc/modules.conf または /etc/modules に記述しておきます。モジュールそ のものは /lib/modules/.../misc/serial.o にあるはずです。
何らかのプログラムがポートを「オープン」する時、ロックファイル が /var/lock/ に作られます。lock ディレクトリのパーミッションが間違っ ていると、ここにロックファイルを作れません。パーミッションが正しいかど うかを確認するには "ls -ld /var/lock" を使います。普通は全員に対して rwx です(rwx が 3 度繰り返されます)。パーミッションが間違っている場合 には、"chmod" コマンドを使って修正します。もちろん、"lock" ディレクト リがなければ、そこにロックファイルを作ることはできません。ロックファイ ルに関する、より詳しい情報については ロックファイルとは何ですか?の節をご覧くだ さい。
このメッセージが出た場合にはおそらく、誰か他の人(あるいは他のプロセ ス)がシリアルポートを使っています。このポートを「使用中」のプロセスを 見つける方法はいくつもあります。一つの方法は、ロックファイル (/var/lock/LCK...)の中身を見ることです。これは、ポートを使っている プロセスの ID のはずです。プロセス ID が 例えば 261 ならば、"ps 261" を実行し、それが何かを調べましょう。そして、そのプロセスがもはや不要であれば、 "kill 261" で優しく kill してもいいでしょう。これで終了しないなら、 "kill -9 261" を実行して強制的に kill してください。ただし、この場合に はロックファイルが消されずに残るので、手で消す必要があるでしょう。 もちろん、261 のようなプロセスが存在しなければ単にロックファイルを消 してかまいません。しかし、ロックファイルが示すプロセス ID (261 等)が 無効であれば、多くの場合そのロックファイルは自動的に削除されるはずです。
これはアクセス(つまり使用)しようとしているデバイスがビジー状態 (使用中)と考えられるか、デバイスが必要としているリソース(IRQ 等)が 他のデバイスに使われていると考えられることを示します。本当に 「ビジー状態」のこともありますが、そうでなければ間違って 「ビジー状態」のように見えているだけです。
``resource busy'' の部分はよく、(例えば ttyS2 で)「他のデバイスが ttyS2
の割り込みを使用中なので、ttyS2 は使えません」という意味になります。
"setserial" の設定による割り込みの衝突の可能性が考えられます。このエラー
メッセージをもっと正確に言うと、「ttyS2 を使えません。setserial の
データ(とカーネルのデータ)が、他のデバイスが ttyS2 の割り込みを使っ
ていると示しています」となるでしょう。2 つのデバイスが同じ IRQ を使っ
ていても、そのうちの片方しか起動していなければ何も問題は起きません。
まだ衝突は起きていないからです。しかし、次に(最初のデバイスを終了させ
ないままで) 2 番目のデバイスを起動しようとすると、"... resource busy"
のエラーメッセージが出ます。こうなるのは、カーネルが追跡するのはどの
IRQ が実際に使われているかだけなので、デバイスが使用(オープン)されなけ
れば衝突は起きないからです。
2 通りの場合が考えられます。
まず、本当に割り込みが衝突しそうなので、それを避けようとしているという
場合もあるでしょう。
しかし、setserial が勘違いをしているという場合もありますし、
そうだとすると(setserial が間違った衝突を予測したという以外には)
ttyS2 が使えない理由はどこにもないはずです。
ここですべきことは、ttyS2 が使っていると
setserial が考えている割り込み番号を調べることです。これは言うのは簡単
ですが、ttyS2 に対して "setserial" を使えないため、実際にやるのは
面倒です。"setserial" が使えないのは、ttyS2 の IRQ は「ビジー状態」と
いうことになっており、同じく "device busy" のエラーメッセージを出すからです。
これを解決するには、再起動するか、衝突していそうなプロセスを優しく
kill してください。再起動する際には次のことを行ってください。
ttyS2 が使っている IRQ を知っているつもりであれば、
/proc/interrupts を見て、現在その IRQ を使っている他のデバイスを見つけ
るとよいでしょう。/proc/interrupts (や "setserial")が示す疑わしい IRQ
が正しい(ハードウェアの設定と同じ)かどうかを全てチェックし直すのもよい
でしょう。割り込みが衝突している可能性があるかどうかを調べる方法は、
"setserial" を使って IRQ に 0 (ポーリング)を設定することです。
IRQ にずっと 0 を設定したままにするのはよくありません。というのも、CPU
の資源を余計に使うからです。
トラブルに対処する時に使うとよいプログラムがいくつかあります: