内蔵モデムを既に取り付けた、あるいは外付けモデムがつながっているシ リアルポートがわからない場合は、次の課題はシリアルポートを検出すること です。 シリアルポートが物理的には存在す るのに検出できません をご覧ください。この節では、モデムが接続してい るシリアルポートを検出することに関して述べます。
``wvdialconf'' という使用中のシリアルポートからモデムを探し出すプログ
ラムがあります。``wvdialconf <a-new-file-name>'' とだけタイ
プしてください。新しいファイルを設定ファイルとしてつくります。しかし、
``wvdial'' を電話をかけるために使わない限り、このファイルを使う必要は
ありません。
wvdialconf とは? をご覧ください。
Linux では使えないソフトウェアモデムなどが原因の問題かもしれません。 ソフトウェアモデムの大部分は避ける をご覧 ください。``setserial'' はシリアルポートを検出するために使いますが、ポー トにつながっているモデムの検出はしません。従って、まず ``wvdialconf'' を試すのが最も良い方法です。
ポート上にモデムがあるかどうか確かめるもうひとつの方法は、``minicom''
を起動することです (C-A O で設定メニューへ行きます)。``AT''
とタイプすると、OK と返ってくるはずです(リザルトコードを数字で表
示しているなら 0 です)。(カーソルを移動するだけの場合を含み) 応答が返っ
てくるまでに時間がかかりすぎるようなら、
この上な く遅い: テキストがすごく遅れてゆっくり画面に表示されます をご覧くだ
さい。
56k 近い速度で通信するには、回線のノイズが非常に低いことが必要です。 電話回線の品質が非常に悪く、56k よりもずっと遅い (28.8k あるいは更に遅 い) 速度しか得られないことがあります。同一の回線に接続した内線電話は、 問題を引き起こすこともあります。これを確かめるため、(他の人が許してく れるなら)回線に何もつながっていない状態で、回線がビルの中へ引き込まれ ている場所に直接モデムを接続してみるのも良いでしょう。
(PC あるいはモデムで)フロー制御が有効になっていないかもしれません。 (115.2k などの)速い DTE 速度を設定したなら、モデムから PC への流れは正 常に動作するでしょう。しかし、逆方向では電話回線がボトルネックになるの で、多くのデータが正常に送れないかもしれません。従って、多くのエラーと パケット再送が発生します。ファイルを送るのに非常に長い時間がかかる、あ るいは送れないかもしれません。また、ファイルを全く作れない場合もあるで しょう。(モデムのデータ圧縮を使いながら) 大きな無圧縮ファイルやウェブ ページをダウンロードしているとき、フロー制御がないためにダウンロードも うまくいかないこともあります。
init のバージョンに合った正しい記述法を使っていることを、確か
めてください。init により /etc/inittab の記述法は異なり
ます。また、getty のバージョンにあった記述法を用いているか、確認
してください。
Id ``S3'' はただの例です。この場合には、/etc/inittab の
``S3'' で始まる行を見てください。この行が問題を引き起こしています。こ
の行の記述方法が正しいか、デバイス (ttyS3) が存在し見つけられるか
どうか、確認してください。
モデムが正しく設定してあることを確認してください。E レジスタと
Q レジスタを見てください。表題に示す現象はモデムが getty と
通信する際に起こります。
uugetty を使っているのなら、/etc/gettydefs の記述を、以下に示
すような方法で確かめてください。
linux# getty -c /etc/gettydefs
uugetty の初期化に失敗するときにも、表題の現象は起こり得ます。
uugetty がいまだに動作しない の節をご覧くださ
い。
DTR 信号が切れたときにモデムがリセットされないと、この現象が起きま
す。Greg Hankins さんはこの現象が起きたとき、RD と SD の LED がおかし
くなるのに気付きました。モデムをリセットする必要があります。多くの
Hayes 互換モデムは &D3 でリセットを行います。しかし、彼の USR
Courier 社製のモデムは &D2 と S13=1 を使わなければ行けま
せんでした。(もしあるなら)モデムのマニュアルを確認してください。
getty_ps には DEBUG オプションがあります。設定ファイル
/etc/conf.{uu}getty.ttySN を編集し、DEBUG=NNN
を追加してください。何をデバッグするのかによって、NNN は以下に挙
げる数字の組合わせになります :
D_OPT 001 オプションの設定
D_DEF 002 デフォルトのファイル処理
D_UTMP 004 utmp/wtmp の処理
D_INIT 010 回線の初期化 (INIT)
D_GTAB 020 gettytab ファイルの処理
D_RUN 040 他の実行時診断
D_RB 100 リングバック-デバッグ
D_LOCK 200 uugetty ロックファイル処理
D_SCH 400 スケジュール処理
D_ALL 777 すべて
まずは DEBUG=010 の設定が良いでしょう。
syslogd を動かしているなら、デバッグ情報はログファイルへ出力
されます。syslogd を動かしていないなら、
/tmp/getty:ttySN にgetty デバッグ時の情報を出力しま
す。そして、 uugetty は /tmp/uugetty:ttySN と
/var/adm/getty.log に載ります。デバッグ情報を見て何が起きてい
るのか調べてください。恐らく、設定ファイルでいくつかのパラメータを調整
し、モデムを再設定する必要があります。
mgetty も試せます。これでうまくいった人もいます。
(モデムなどの)装置がシリアルポート上で動作しているなら、明らかにポー トを検出できています。全く動作しないなら、シリアルポートを検出できるよ うに、手当てする必要があります。
BIOS のメニューと出力メッセージを確認しましょう。ISA バス上の PnP シリ
アルポートの場合には、``pnpdump --dumpregs'' を試したり、
Plug-and-Play-HOWTO をご覧になってください。PCI バスの場合には
lspci を使用してください。setserial を使って検出を行ってもよ
いでしょう。
検出 の項目を参照してくださ
い。シリアルポー トにデータが何も流れていないようであれば、シリアルポー
トはあっても割込みが間違っているかもしれません。
この上なく遅い: テキストがすごく遅れてゆっくり画面に表示されます の節をご覧ください。
[訳注 : JF プロジェクトによる日本語訳 Plug-and-Play-HOWTO ]
これは割込みの設定が間違っているか、衝突しているためでしょう。 初めてモデムや端末、プリンタを使おうとしたときに出会うような現象をいく つか示します。場合によっては、入力した文字が何秒も経たないと表示されな いことがあります。入力した最後の文字しか表示されないこともあります。 また、その文字が単に目に見えない<改行>文字で、カーソルが 1 行下 に移動したことしかわからないこともあります。また別の場合としては、 画面にデータはたくさん表示されるのですが、16 文字ごとのかたまりでしか 表示されないこともあります。そして、あるかたまりの次のかたまりが表示さ れるまでには何秒もの長い待ち時間が続きます。 「input overrun (入力オーバーラン)」のエラーメッセージが表示される(ある いはログに残る)こともあります。
詳しい症状とそれが起こる理由については、Serial-HOWTO の「割込みの問 題に関する詳しい説明」の節を見てください。
プラグ&プレイデバイスがある場合には、Plug-and-Play-HOWTO も見てく ださい。
[訳注 : JF プロジェクトによる日本語訳 Serial-HOWTO および Plug-and-Play-HOWTO ]
本当に割込みの問題かどうかを簡単に調べるには、``setserial'' で IRQ を 0 に設定してください。これにより、ドライバは割込みではなくポーリングを 使うようになります。これで「遅い」問題が解決するようであれば、割込みの 問題が起きています。しかし、ポーリングはコンピュータの資源を大量に消費 して処理速度を低下させることもあります。ポーリングに頼らず、きちんと割 込みの問題を解決すべきです。
割込みの衝突を見つけだすのは容易ではないかもしれません。というのも、
Linux は割込みの衝突を全く許さず、衝突を起こそうとすると
/dev/ttyS?: Device or resource busy エラーを送っ
てくるようです。しかし、``setserial'' が誤った情報を持っていると、本当
の衝突が発生します。このように、``setserial'' を使っただけでは衝突は発
生しないでしょう (``setserial'' の情報に基づく
/proc/interrupts を見ることもないでしょう)。どこが悪いのか指
摘するためには、やはり ``setserial'' の設定を知る必要があります。ハー
ドウェア中の本当の設定がわかったら、設定を変更してください。
こういった場合に行うべき作業は、ジャンパや PnP 設定ソフトウェアを使っ
て、ハードウェアに実際に設定されている情報を調べることです。PnP の場合
は、``pnpdump --dumpregs'' または ``lspci'' を実行しま
しょう。そして、この結果を Linux 側の (``setserial'' などの)設定と比べ
るのです。
考えられる理由の一つは、シリアルポートを使っているデバイス(モデム や端末、プリンタ)が、あなたが考えているほど速く動作していないことです。 56k モデムはほとんど 56k で動作することはなく、そしてインターネットは ときには輻輳を起し、速度を低下させるボトルネックが発生します。
考えられる別の理由は、あなたが使っているシリアルポートが古い(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
ttyS02'' のところが ``tty02''
となります)。実際に使う IRQ を Linux に知らせるには、setserial を
使わなければなりません。
``ls -l dev/ttyS?/'' を実行してそのポートのファイルのパーミッ
ションを調べてみましょう。ttyS? の所有者が自分であれば、読み書き
のパーミッションとして crw が必要です。最初の桁は c (キャラ
クタデバイス)です。ポートの所有者でなければ、8 桁目と 9 桁目が
rw- でなければなりません。つまり誰でもそのポートを読み書きできな
ければなりません。アクセス権限を得る方法としては、グループパーミッショ
ンを持っている「グループ」に所属するといったもっと複雑なものもあります。
このエラーは、カーネルがサポートしていないために、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'' ディレクトリがなければ、そこにロックファ
イルを作ることはできません。ロックファイルに関する、より詳しい情報につ
いては Serial-HOWTO の「ロックファイルとは何ですか?」の節をご覧くださ
い。
[訳注 : パーミッションを設定するには chmod 1777
/var/lock を実行してください。詳細は chmod(1) をご覧ください。
JF プロジェクトによる日本語訳 Serial-HOWTO ]
このメッセージが出た場合にはおそらく、誰か他の人(あるいは他のプロセ
ス)がシリアルポートを使っています。このポートを「使用中」のプロセスを
見つける方法はいくつもあります。一つの方法は、ロックファイル
(/var/lock/LCK...)の中身を見ることです。これは、ポートを使っ
ているプロセスの ID のはずです。プロセス ID が 例えば 261 ならば、
``ps 261'' を実行し、それが何かを調べましょう。そして、そのプロセ
スが不要であれば、``kill 261'' で優しく kill してもいいでしょう。
これで終了しないなら、``kill -9 261'' を実行して強制的に kill し
てください。ただし、この場合にはロックファイルが消されずに残るので、手
で消す必要があるでしょう。もちろん、261 のようなプロセスが存在しなけれ
ば単にロックファイルを消してかまいません。しかし、ロックファイルが示す
プロセス ID (261 等)が無効であれば、多くの場合そのロックファイルは自動
的に削除されるはずです。
モデムで電話をかけようとしたときにDCD あるいは DTR が正常に動作し
ないと、この問題が起こります。DCD は getty がポートを監視している
ときではなく、実際に回線がつながったとき(例えば誰かがダイヤルインした
とき)だけ ON になるべきです。接続時にだけ DCD を ON にするようモデムを
設定しているか、確かめてください。getty や kermit などの通信
プログラムが回線を監視しているなど、使用中はいつでも DTR は ON になっ
ているべきです。
``resource busy'' は多くの場合、(ttyS2 の場合)「他のデバイスが ttyS2 の割込みを使用中なので、ttyS2 を使うことはできません」という意味です。 ``setserial'' の設定による割込みの衝突の可能性があります。このエラーメッ セージをもっと正確に言うと、「ttyS2 を使えません。setserial のデータが、 他のデバイスが ttyS2 の割込みを使っていると示しています」となるでしょ う。
これには 2 つの可能性があります。ひとつは割込みが実際に衝突している場
合で、これは修正しなければなりません。しかし、setserial が誤った割込み
を設定しているのなら、ttyS2 を使えない理由はないでしょう。ただし、
衝突を間違って伝えるような setserial は除きます。起動メッセージを見て、
ttyS2 が使用していると setserial が考えている割込みを知る必要があ
ります (setserial はエラーメッセージ ``device busy'' を出すので、正常
には動作しないでしょう)。そして、この割込みを他のデバイスが使っていな
いか、あるいはハードウェアで設定している割込みと等しいかどうか、確かめ
てください。
トラブルに対処する時に使うとよいプログラムがいくつかあります:
lsof /dev/ttyS*'' は開いているシリアルポートを表示し
ます。/proc にある (ioports, interrupts などの)
「ファイル」。