<!doctype linuxdoctr system>

<article>
<title>The Linux Serial HOWTO
<author>David S.Lawyer  
  <tt><htmlurl url="mailto:dave@lafn.org" name="dave@lafn.org"></tt>
  original by Greg Hankins 

<date> v2.07 May 2000 
<trans>The Linux Japanese FAQ Project
<tdate>v2.07j, May 2000

<!--
fujiwara:
原文の「ボルト」「V」の揺れは、訳では「V」に統一しています。
-->

<!--  Change log:
v2.07 Apr. locking methods, clarity re uart protocol, sticky parity
v2.06 2 March 2000 more on multiport, not 3-3 for null modem, 
 butter -> buffer,
v2.05 Vern's & my url, ref to multiport modem cards
v2.04 duplicate info removed from setserial
v2.03 ttyS minor is 4, not 5
v2.02 Oct. 1999. National Instruments card, removed m4_define TorS, lockfile
 error mesg
v2.01 Aug. 1999. more on HSSI, irq=0, serial module, clarity, 
 Computone update, New copyright, interrupts mis-set symptoms,
 m4-include files (PnP stuff, stty, etc.)
v2.00 May 1999 holding reg. to shift reg.
 Added tech info.  Removed modem and terminal info and put into Modem-HOWTO
 and Text-Terminal-HOWTO.  Added info from Modem-HOWTO which is
 only about the serial port.
v1.12 July 1998: reissue of old doc (v1.11).  Added more info on Winmodems. 
-->
<!--
<abstract>
  This document describes serial port features other than those which
  should be covered by Modem-HOWTO, PPP-HOWTO,
  Serial-Programming-HOWTO, or Text-Terminal-HOWTO.  It lists info on
  multiport serial cards.  It contains technical info about the serial
  port itself in more detail than found in the above HOWTOs and should
  be best for troubleshooting when the problem is the serial port
  itself.  If you are dealing with a Modem, PPP (used for Internet
  access on a phone line), or a Text-Terminal, those HOWTOs should be
  consulted first.  </abstract>
-->
<abstract>
この文書は、シリアルポートの機能のうち、Modem-HOWTO, PPP-HOWTO,
Serial-Programming-HOWTO, Text-Terminal-HOWTO で扱われていない範囲を
説明します。マルチポートシリアルカードに関する情報も紹介します。
シリアルポートに関して他の文書より詳しく書いてあるので、
問題がシリアルポートそのものにある場合は、これを読むのが一番でしょう。
モデム、PPP (電話回線でインターネットにアクセスするために使います)、
テキスト端末を扱っている場合には、それぞれに対応
する HOWTO 文書を先にご覧ください。</abstract>

<toc>
<!--
<sect>Introduction
-->
<sect>はじめに

<!--
<p> This HOWTO covers basic info on the Serial Port and multiport
serial cards.  Information specific to modems and text-terminals has
been moved to Modem-HOWTO and Text-Terminal-HOWTO.  Info on getty (the
program that runs the login process or the like) has been also moved
to these HOWTOs since mgetty and uugetty are best for modems while
agetty is best for text-terminals.  If you are dealing with a modem,
text terminal, or printer, then you may not need to consult this
HOWTO.  But if you are using the serial port for some other device,
using a multiport serial card, trouble-shooting the serial port
itself, or want to understand more technical details of the serial
port, then you may want to use this HOWTO as well as some of the other
HOWTOs.  (See <ref id="related_howtos" name="Related HOWTO's">)  This
HOWTO lists info on various multiport serial cards since they may be
used for either modems or text-terminals.  This HOWTO addresses Linux
running on Intel x86 hardware, although it might be valid for other
architectures.
-->
<p>この文書は、シリアルポートとマルチポートシリアルカードについての
基本的な情報を扱っています。モデムやテキスト端末に固有の情報は、
Modem-HOWTO と Text-Terminal-HOWTO に移動させました。getty (ログイン
処理等を実行するプログラム)に関する
情報もこれらの HOWTO に移動させました。というのも、mgetty と uugetty 
はモデムと組み合わせて使うことが多く、agetty はテキスト端末と組み合わ
せて使われることが多いからです。
モデムやテキスト端末、プリンタを扱う場合には、この HOWTO を調べる
必要はないでしょう。
しかし、シリアルポートを別のデバイスと組み合わせて使う場合、
マルチポートシリアルカードを使う場合、シリアルポートそのものに関する
問題を解決する場合、シリアルポート
に関する技術的な情報を詳しく知りたい場合には、他の HOWTO と共にこの
HOWTO を参照する必要があるかもしれません
(<ref id="related_howtos"
name="関連する HOWTO 文書"> をご覧ください)。
この HOWTO には各種マルチポートシリアルカードに関する情報を載せています。
というのも、これはモデムでもテキスト端末でも使われることがあるからです。
この HOWTO は Intel x86 アーキテクチャで動作する Linux を対象にし
ていますが、他のアーキテクチャでも使えるかもしれません。

<!--
<sect1> Copyright, Disclaimer, &amp; Credits
-->
<sect1> 著作権、免責事項、クレジット

<!--
<sect2>Copyright
-->
<sect2>著作権
<p>
Copyright (c) 1993-1997 by Greg Hankins, 1998-2000 by David S. Lawyer
<url url="mailto:dave@lafn.org">
<!-- license.H begin -->

Please freely copy and distribute (sell or give away) this document
in any format.  Forward any corrections and comments to the document
maintainer.  You may create a derivative work and distribute it
provided that you:

<enum>
<item> Send your derivative work (in the most suitable format such as
  sgml) to the LDP (Linux Documentation Project) or the like for
  posting on the Internet.  If not the LDP, then let the LDP know
  where it is available.  Except for a translation, send a copy to the
  previous maintainer's url as shown in the latest version.
<item>License the derivative work in the spirit of this license or use
  GPL.  Include a copyright notice and at least a pointer to the 
  license used.
<item>Give due credit to previous authors and major contributors.
</enum>

If you're considering making a derived work other than a
translation, it's requested that you discuss your plans with the
current maintainer. 

<!--
<sect2>Disclaimer
-->
<sect2>免責事項
<p> While I haven't intentionally tried to mislead you, there are
likely a number of errors in this document.  Please let me know about
them.  Since this is free documentation, it should be obvious that I
cannot be held legally responsible for any errors.

<!--O
<sect2>Trademarks.
-->
<sect2>商標
<p> Any brand names (starts with a capital letter) should be assumed to
be a trademark).  Such trademarks belong to their respective owners.
<!-- copyright.H end -->


<!--
<sect2>Credits
-->
<sect2>クレジット
<!--
<p> Most of the original Serial-HOWTO was written by  Greg Hankins. 
<tt><htmlurl url="mailto:gregh@cc.gatech.edu"
name="gregh@cc.gatech.edu"></tt>
He also rewrote many contributions by others in order to maintain
continuity in the writing style and flow.  He wrote: "Thanks to
everyone who has contributed or commented, the list of people has
gotten too long to list (somewhere over one hundred).  Special thanks
to Ted Ts'o for answering questions about the serial drivers.
Approximately half of v2.00 was from Greg Hankins HOWTO and the other
half is by David Lawyer.  Ted Ts'o has continued to be helpful.
-->
<p> オリジナルの Serial-HOWTO の大部分は Greg Hankins さん
<tt><htmlurl url="mailto:gregh@cc.gatech.edu"
name="gregh@cc.gatech.edu"></tt> が書きました。
Greg さんはまた、他の方が提供した文章の書き直しを文体や文章の流れの繋
がりを保つために行っています。彼曰く「貢献してくれた方々、意見をくださっ
た方々の全てに感謝します。それぞれの名前を挙げると長くなりすぎるので省
略します(100 人を超えています)。シリアルドライバについての質問に答えて
くださった Ted Ts'o には特に感謝します」ということです。
<!--
fujiwara: 原文のバージョンアップで閉じ quote が消えてるんですけど…
-->
バージョン 2.00 のうち約半分は Greg Hankins さんの HOWTO の内容を引き
継ぎ、残りの部分は David Lawyer が新たに書きました。Ted Ts'o も協力を続けて
くれています。

<!--
<sect1> Release Notes
-->
<sect1> リリースノート
<!--
<p> 2.00 was a major revision which has removed info on Terminals and
Modems from the old Serial-HOWTO and put such info into:
-->
<p> 2.00 は大幅な改訂であり、古い Serial-HOWTO にあった端末とモデム
に関する情報はなくなりました。これらの情報は以下の文書に移動しています:
<itemize>
<item> Text-Terminal-HOWTO
<item> Modem-HOWTO
</itemize>

<!--
2.01: Added info on Plug-and-Play from Modem-HOWTO and more.  Info on
setserial and stty has been updated.  I still haven't checked out all
the info on multiport cards to see if it's up-to-date.  The fact that
this HOWTO was pieced together from various sources has resulted in a
certain lack of integration.  This may be improved on in future
versions.
-->
2.01: Modem-HOWTO などからプラグ&amp;プレイに関する情報を追加しました。
setserial と stty の情報を更新しました。筆者はマルチポートカードに関す
る全ての情報が最新かどうかをまだチェックしていません。この HOWTO 文書
は色々な情報源からの情報を集めて作ったという性質上、統一性に欠けている
部分があります。この点は将来出すバージョンで改善するかもしれません。

<!--
<sect1> New Versions of this Serial-HOWTO
-->
<sect1> この HOWTO の最新版について
<!--
<p> New versions of the Serial-HOWTO will be available to
browse and/or download at LDP mirror sites.  For a list of mirror
sites see: <url url="http://metalab.unc.edu/LDP/mirrors.html">.
Various formats are available.  If you only want to quickly check the
date of the latest version look at <url
url="http://metalab.unc.edu/LDP/HOWTO/Serial-HOWTO.html"> and compare
it to this version: v2.07 May 2000 .  New in this version is: locking methods, clarity re uart protocol,
 sticky parity. 
-->
<p> Serial-HOWTO の最新版は LDP とそのミラーサイトで閲覧・入手できます。
ミラーサイトのリストは <url
url="http://metalab.unc.edu/LDP/mirrors.html"> にあります。文書は色々
な形式で入手できます。最新版の日付を確認したいだけなら <url
url="http://metalab.unc.edu/LDP/HOWTO/Serial-HOWTO.html"> を見て、
現在のバージョン(v2.07, May 2000)と比べてください。このバージョンの
新しい点は、ロッキングの方法、UART プロトコルに関する情報の整理、
スティッキーパリティについてです。

<!--
<sect1> Related HOWTO's re the Serial Port <label id="related_howtos">
-->
<sect1> シリアルポート関連の他の HOWTO 文書 <label id="related_howtos">
<!--
<p> Modems, Text-Terminals, some printers, and other peripherals often
use the serial port.  Get these HOWTOs from the nearest mirror site as
explained above.
-->
<p> モデム、テキスト端末、一部のプリンタや他の周辺機器はしばしば
シリアルポートを使います。先に説明したミラーサイトのうち、最も近い
サイトから以下の HOWTO を入手してください。

<itemize>
<!--
<item><tt>Modem-HOWTO</tt> is about installing and configuring modems
-->
<item><tt>Modem-HOWTO</tt> モデムのインストールと設定について
<!--
<item><tt>Printing-HOWTO</tt> has info on using a serial printer
-->
<item><tt>Printing-HOWTO</tt> シリアルプリンタの使用に関する情報
<!--
<item><tt>Serial-Programming-HOWTO</tt> helps you write
 C programs (or parts of them) that read and write to the serial port
 and/or check/set its state.  A new version is expected soon.
-->
<item><tt>Serial-Programming-HOWTO</tt> シリアルポートの読み書きや状態
の確認/設定を行う C 言語のプログラム(またはその一部)を書くための参考情
報です。もうすぐ新しいバージョンが出ます。
<!--
<item><tt>Text-Terminal-HOWTO</tt> is about how they work, how to install 
configure, and repair them.
-->
<item><tt>Text-Terminal-HOWTO</tt> テキスト端末の動作、インストール・
設定・修復の方法について
</itemize>

<!--
<sect1>Feedback
-->
<sect1>フィードバック
<p>
<!--
Please send me any questions, comments, suggestions, or additional 
material.  I'm always eager to hear about what you think about this
HOWTO.  I'm also always on the lookout for improvements!  Tell me 
exactly what you don't understand, or what could be clearer.  You can
reach me via email at <tt><htmlurl url="mailto:dave@lafn.org"> (David
Lawyer)</tt>.
-->
質問、意見、提案、追加の情報は筆者に送ってください。筆者は、読者の皆さ
んがこの HOWTO についてどう思っているかを大変知りたいと思っています。
筆者は改善点を常に探しています! 理解できなかったところや、はっきりしな
い部分はちゃんと筆者に教えてください。筆者に連絡するには
<tt><htmlurl url="mailto:dave@lafn.org"> (David Lawyer)</tt>
までメールを送ってください。

<!--
<sect1> What is a Serial Port?
-->
<sect1> シリアルポートとは何か?
<!--
<p> The conventional serial port (not the newer USB port, or HSSI
port) is a very old I/O port.  Almost all PC's have them.  But Macs
(Apple Computer) after mid 1998 (with colored cases) only have the USB
port.  The common specification is RS-232 (or EIA-232).  The connector
for the serial port is often seen as one or two 9-pin connectors (in
some cases 25-pin) on the back of a PC.  But the serial port is is
more than just that.  It includes the associated electronics which
must produce signals conforming to the EIA-232 specification.  See
<ref id="volt_shape" name="Voltage Waveshapes">.  One pin is used to
send out data bytes and another to receive data bytes.  Another pin is
a common signal ground.  The other "useful" pins are used mainly for
signalling purposes with a steady negative voltage meaning "off" and a
steady positive voltage meaning "on".
-->
<p>(新しい USB ポートや HSSI ポートでない)従来のシリアルポートは、非常
に古い I/O ポートです。
シリアルポートはほとんど全ての PC に付いています。ですが 
1998 年半ば以降の Macintosh (色付きのケースのもの)には USB ポートしか
ついていません。最も一般的な規格は RS-232 (EIA-232 とも呼ばれます)で
す。シリアルポートのコネクタは、PC の裏に9 ピンのコネクタ(25 ピンの場
合もあります)が 1 つまたは 2 つ付いている形でよく見られます。
しかし、シリアルポートはそれ
だけのものではありません。シリアルポートには、EIA-232 規格に準拠する信
号を生成しなければならない関連電子技術も含まれます。<ref
id="volt_shape" name="電圧の波形"> の章を見てください。あるピンは
データのバイト列を送るために使い、別のピンはバイト列を受け取るために使
います。信号が共通に使う接地電圧のピンもあります。他の「便利な」ピンは
主に、「オフ」を表す負の定常電圧と「オン」を表す正の定常電圧を使って信
号を表すために使います。

<!--
The UART (Universal Asynchronous Receiver-Transmitter) chip does most
of the work.  Today, the functionality of this chip is usually built
into another chip.  See <ref id="uart_" name="What Are UARTs?"> These
have improved over time and old models (several years old) are now
obsolete.
-->
UART (Universal Asynchronous Receiver-Transmitter) チップがほとんどの
処理を行います。最近は普通、このチップの機能は別のチップに組み込まれて
います。「<ref id="uart_" name="UART とは何ですか?">」を参照してくださ
い。UART は時間が経つにつれ改良されており、現在は古いモデル(数年前のモ
デル)は時代遅れになっています。

<!--
The serial port was originally designed for connecting modems but it's
used to connect many other devices also such as mice, text-terminals, some
printers, etc. to a computer.  You just plug these devices into the
serial port using the correct cable.  Many internal modem cards have a
built-in serial port so when you install one inside your PC it's as if
you just installed another serial port in your PC.
-->
シリアルポートは元々はモデムを接続するために設計されたのですが、マウス
やテキスト端末、ある種のプリンタ等の色々なデバイスをコンピュータに接続
するためにも使われています。これらのデバイスは、適切なケーブルを使って
シリアルポートに繋ぐだけです。内蔵モデムの多くは組み込みのシリアルポー
トを持っているので、内蔵モデムを PC に追加すると、別のシリアルポートが 
PC に加わったように見えます。

<!--
<sect> How the Hardware Transfers Bytes <label id="how_hdw_xfers">
-->
<sect> ハードウェアによるバイトデータの転送の仕方 <label id="how_hdw_xfers">

<!--O
<p> Below is an introduction to the topic, but for a more advance
treatment of it see <ref id="fifo_" name="FIFOs">.
-->
<p> 以下はこの話題についての入門的な解説ですが、もっと進んだ内容につい
ては <ref id="fifo_" name="FIFO"> を見てください。

<!--
<sect1> Transmitting
-->
<sect1> 送信
<!--
<p> Transmitting is sending bytes out of the serial port away from the
computer.  Once you understand transmitting, receiving is easy to
understand since it's similar.  The first explanation given here will
be grossly oversimplified.  Then more detail will be added in later
explanations.  When the computer wants to send a byte out the serial
port (to the external cable) the CPU sends the byte on the bus inside
the computer to the I/O address of the serial port.  The serial port
takes the byte, and sends it out one bit at a time (a serial
bit-stream) on the transmit pin of the serial cable connector.  For what a
bit (and byte) look like electrically see <ref id="volt_shape"
name="Voltage Waveshapes">.
-->
<p>送信(transmitting)とは、シリアルポートを通じてコンピュータからバイ
ト列を送ることです。一旦、送信を理解できれば、受信は同じようなものなの
で理解するのは容易です。
ここで最初に示す例は極端に簡略化したものです。
もっと詳しい説明を後で追加します。
コンピュータが(外部ケーブルに繋がっている)シリアルポートから 1 バイト
のデータを送ろうとする時、CPU
はコンピュータ内部のバス上にあるそのデータをシリアルポートの I/O アド
レスに送ります。シリアルポートはそのデータを受け取り、シリアルケーブルの端子の 
送信ピンを使ってこれを 1 ビットずつ送ります(シリアルビットストリーム)。
あるビット(とバイト)が電気的にはどう見えるのかについては、<ref
id="volt_shape" name="電圧の波形">の章をご覧ください。

<!--
Here's a replay of the above in a little more detail (but still very
incomplete).  Most of the work at the serial port is done by the UART
chip (or the like).  To transmit a byte, the serial device driver
program (running on the CPU) sends a byte to the serial port"s I/O
address.  This byte gets into a 1-byte "transmit shift register" in
the serial port.  From this shift register bits are taken from the
byte one-by-one and sent out bit-by-bit on the serial line.  Then when
the last bit has been sent and the shift register needs another byte
to send it could just ask the CPU to send it another byte.  Thus would
be simple but it would likely introduce delays since the CPU might not
be able to get the byte immediately.  After all, the CPU is usually
doing other things besides just handling the serial port.  
-->
上記の説明をもう少し詳しくして(まだ完全には程遠いものですが)繰り返
します。シリアルポートで行われる処理のほとんどは UART (または同等のも
の)が行います。1 バイトのデータを転送するために、シリアルデバイスドラ
イバプログラム(CPU 上で動作)はシリアルポートの I/O アドレスに 1 バイト
を送ります。このデータはシリアルポートの「送信シフトレジスタ」(大きさ
が 1 バイト)に入ります。このシフトレジスタでは、このバイトデータから 1 
ビットずつ取り出され、1 ビットずつシリアル線に送られます。そして最後の
ビットが送信され、シフトレジスタが送るための別のバイトを必要とするよう
になると、UART は別のバイトデータを送るよう CPU に求めるだけで済みます。
これなら単純な話ですが、CPU がバイトデータを即座に取得することができな
いために遅延が生じるかもしれません。なにしろ CPU はシリアルポートの
処理以外にも作業をこなしているのが普通です。

<!--
A way to eliminate such delays is to arrange things so that the CPU
gets the byte before the shift register needs it and stores it in a
serial port buffer (in hardware).  Then when the shift register has
sent out its byte and needs a new byte immediately, the serial port
hardware just transfers the next byte from its own buffer to the shift
register.  No need to call the CPU to fetch a new byte.
-->
このような遅延をなくす方法は、シフトレジスタがバイトデータを必要とする
前に CPU がバイトデータを取得して、これをシリアルポートの(ハードウェア)
バッファに格納することです。
こうしておけば、シフトレジスタがバイトデータを送り出してしまって次に送る
バイトデータが即座に必要になった時には、シリアルポートのハードウェアは
自分のバッファに入っている次の
バイトデータをシフトレジスタに転送するだけです。
新しいバイトデータを取得するために CPU を呼ぶ必要はありません。

<!--
The size of this serial port buffer was originally only one byte, but
today it is usually 16 bytes (more in higher priced serial ports).
Now there is still the problem of keeping this buffer sufficiently
supplied with bytes so that when the shift register needs a byte to
transmit it will always find one there (unless there are no more bytes
to send).  This is done by contacting the CPU using an interrupt.  
-->
シリアルポートのバッファのサイズは元々 1 バイトしかありませんでしたが、
現在は普通 16 バイトです(高価なシリアルポートにはもっとあります)。しか
しそれでも、シフトレジスタが転送するデータを必要とした時に必ずバッファ
にデータがあるように、このバッファに十分なバイトデータを与え続けるとい
う問題が残っています(送るデータがもう残っていない場合は除きます)。これ
は割り込みを使って CPU と連絡することで行います。

<!--
First we'll explain the case of the old fashioned one-byte buffer,
since 16-byte buffers work similarly (but are more complex).  When the
shift register grabs the byte out of the buffer and the buffer needs
another byte, it sends an interrupt to the CPU by putting a voltage on
a dedicated wire on the computer bus.  Unless the CPU is doing
something very important, the interrupt forces it to stop what it was
doing and start running a program which will supply another byte to
the port's buffer.  The purpose of this buffer is to keep an extra
byte (waiting to be sent) queued in hardware so that there will be no
gaps in the transmission of bytes out the serial port cable.
-->
まずはバッファが 1 バイトの古い方式のシリアルポートについて説明します。
というのも、バッファが 16 バイトのものも同じように動作するからです(
ただし動作はより複雑です)。
シフトレジスタがバイトデータをバッファから取り出し、バッファが他のバイ
トデータを必要とすると、コンピュータのバス上にある専用の配線の電圧を上
げることにより、CPU に割り込みが送られます。CPU が非常に重要な処理をし
ていなければ、CPU が実行中の処理は割り込みにより強制的に中断され、シリ
アルポートのバッファに別のバイトデータを与えるためのプログラムが実行さ
れます。このバッファの目的は、シリアルポートのケーブルから送り出される
バイトデータが途切れないように、追加のバイトデータが(送られるのを待っ
て)ハードウェア内のキューに入った状態を保つことです。

<!--
Once the CPU gets the interrupt, it will know who sent the interrupt
since there is a dedicated interrupt wire for each serial port (unless
interrupts are shared).  Then the CPU will start running the serial
device driver which checks registers at I/0 addresses to find out what
has happened.  It finds out that the serial's transmit buffer is empty
and waiting for another byte.  So if there are more bytes to send, it
sends the next byte to the serial port's I/0 address.  This next byte
should arrive when the previous byte is still in the transmit shift
register and is still being transmitted bit-by-bit.  
-->
いったん CPU に割り込みがかかると、CPU は誰が割り込みをかけたかを知ります。
なぜなら、各シリアルポートについて専用の割り込み線があるから
です(ただし割り込みの共有をしていない場合)。それから CPU はシリアルデ
バイスドライバを動作させます。ドライバは I/O アドレスにあるレジスタを
チェックし、何が起きたのかを調べます。そして、シリアルポートの送信バッ
ファが空になり、追加のバイトデータを待っていることを知ります。したがっ
て、送るべきバイトデータがもっとあれば、CPU は次のバイトデータをシリア
ルポートの I/O アドレスに送ります。このバイトは、前のバイトがまだ送信
シフトレジスタ内にあり、1 ビットずつ送られている間に届かなくてはなりま
せん。

<!--
In review, when a byte has been fully transmitted out the transmit
wire of the serial port and the shift register is now empty the
following 3 things happen almost simultaneously:
-->
復習すると、1 バイトがシリアルポートの送信線へ完全に送り出されると、
シフトレジスタは空になり、以下の 3 つの動作がほとんど同時に起こります:

<enum>
<!--
<item> The next byte is moved from the transmit buffer into
the transmit shift register 
-->
<item> 次のバイトが送信バッファから送信シフトレジスタに入れられ
ます。
<!--
<item> The transmission of this new byte (bit-by-bit) begins 
-->
<item> この新しいバイトの(1 ビットずつの)送信が始まります。
<!--
<item> Another interrupt is issued to tell the device driver to send 
yet another byte to the now empty transmit buffer
-->
<item> 次の割り込みが発行され、たった今、空になった送信バッファへ次の
バイトを送るよう、デバイスドライバに指示します。
</enum>

<!--
Thus we say that the serial port is interrupt driven.  Each time the
serial port issues an interrupt, the CPU sends it another byte.  Once
a byte has been sent to the transmit buffer by the CPU, then the CPU
is free to pursue some other activity until it gets the next
interrupt.  The serial port transmits bits at a fixed rate which is
selected by the user (or an application program).  It's sometimes
called the baud rate.  The serial port also adds extra bits to each
byte (start, stop and perhaps parity bits) so there are often 10 bits
sent per byte.  At a rate (also called speed) of 19,200 bits per
second (bps), there are thus 1,920 bytes/sec (and also 1,920
interrupts/sec).
-->
このように、シリアルポートは割り込み駆動(interrupt driven)であると言えます。
シリアルポートが割り込みを発行する度に、CPU は次のバイトを送ります。
CPU が 1 バイトを送信バッファに送ると、次の割り込みを受け取るまで、CPU 
は他の処理を自由に行うことができます。シリアルポートはユーザ(あるいは
アプリケーションプログラム)が選択した
固定の速度でビット列を送信します。この速度はボーレートと呼ばれることも
あります。シリアルポートはバイトごとに追加のビット(スタートビット、ス
トップビット、場合によってはパリティビットも)も付け加えるので、多
くの場合、1 バイトごとに 10 ビットのデータが送られます。したがって、通
信レート(速度とも言われます) 19,200 ビット/秒(bps, bit per second)は 
1,920 バイト/秒(1,920 割り込み/秒)ということになります。

<!--
Doing all this is a lot of work for the CPU.  This is true for many
reasons.  First, just sending one 8-bit byte at a time over a 32-bit
data bus (or even 64-bit) is not a very efficient use of bus width.
Also, there is a lot of overhead in handing each interrupt.  When the
interrupt is received, the device driver only knows that something
caused an interrupt at the serial port but doesn't know that it's
because a character has been sent.  The device driver has to make
various checks to find out what happened.  The same interrupt could
mean that a character was received, one of the control lines changed
state, etc.
-->
この処理を全て行うことは CPU にとっても重い負担です。これは色々な理由
から言えます。まずは、32 ビット(64 ビットのことだってあります)のバス上
で一回に 1 バイト(8 ビット)のデータしか送らないので、バス幅をあまり有
効に使っているとは言えません。また、割り込みを送る度に大きなオーバーヘッ
ドが生じます。割り込みを受け取った場合でも、デバイスドライバに分かるこ
とは何かがシリアルポートで割り込みを起こしたことだけであり、文字が送ら
れたことが理由であることまでは分かりません。何が起こったかを調べるには、
デバイスドライバは色々なチェックを行わなければなりません。同じ割り込み
が起こっても、文字を受け取ったのかもしれませんし、制御線の状態が変化し
たのかもしれません。

<!--
A major improvement has been the enlargement of the buffer size of the
serial port from 1-byte to 16-bytes.  This means that when the CPU
gets an interrupt it gives the serial port up to 16 new bytes to
transmit.  This is fewer interrupts to service but data must still be
transferred one byte at a time over a wide bus.  The 16-byte buffer is
actually a FIFO (First In First Out) queue and is often called a FIFO.
See <ref id="fifo_" name="FIFOs"> for details about the FIFO along
with a repeat of some of the above info.
-->
重要な解決方法の一つは、シリアルポートのバッファの大きさを 1 バイトか
ら 16 バイトに増やすことでした。
つまり、CPU は割り込みを受け取ると、シリアルポート
に 16 バイトまでのデータを新たに送ることができます。これにより割り込み
の発行は減りますが、太いバスにもかかわらず 1 バイトずつしかデータを送
れない問題はそのままです。16 バイトのバッファは実際には FIFO
(First In First Out, 先入れ先出し)のキューであり、よく FIFO と呼ばれます。
FIFO の詳細については <ref id="fifo_" name="FIFO"> をご覧ください。
これまでの説明も一部繰り返してあります。

<!--
<sect1> Receiving
-->
<sect1> 受信
<!--
<p> Receiving bytes by a serial port is similar to sending them only
it's in the opposite direction.  It's also interrupt driven.  For the
obsolete type of serial port with 1-byte buffers, when a byte is fully
received from the external cable it goes into the 1-byte receive
buffer.  Then the port gives the CPU an interrupt to tell it to pick
up that byte so that the serial port will have room for storing the
next byte which is currently being received.  For newer serial ports
with 16-byte buffers, this interrupt (to fetch the bytes) may be sent
after 14 bytes are in the receive buffer.  The CPU then stops what it
was doing, runs the interrupt service routine, and picks up 14 to 16
bytes from the port.  For an interrupt sent when the 14th byte has
been received, there could be 16 bytes to get if 2 more bytes have
arrived since the interrupt.  But if 3 more bytes should arrive
(instead of 2), then the 16-byte buffer will overrun.  It also may
pick up less than 14 bytes by setting it that way or due to timeouts.
See <ref id="fifo_" name="FIFOs"> for more details. 
-->
<p>シリアルポートによるバイト列の受信は送信とほぼ同じで、方向が逆になっ
ているだけです。受信も割り込み駆動です。受信バッファを 1 バイトしか持
たない古い型のシリアルポートでは、外部ケーブルから 1 バイトのデータ全体を受け取ると、こ
のデータは(大きさが 1 バイトである)受信バッファに入ります。するとシリ
アルポートは CPU に割り込みをかけてそのデータを取り込ませ、現在受信中
の次のデータを格納できる場所が空くようにします。16 バイトのバッファを持っ
ている新しいシリアルポートの場合は、この(バイトデータを取得するための)
割り込みはバッファに 14 バイトのデータが蓄積した時点で発行されます。す
ると CPU は現在の処理を一旦止め、14 から 16 バイトのデータをシリアルポー
トから取り出します。14 番目のバイトが受け取られた時に送られた割り込み
に対し、これが起きてからさらに 2 つのバイトデータが届くと、受け取るべ
きバイトの個数は 16 バイトになるかもしれません。しかし(2 バイトではな
く) 3 バイト届いてしまうと、16 バイトのバッファは溢れてしまいます。
14 バイト未満のデータを取り込むことも、そのように設定することや
タイムアウトによりできます。詳しくは <ref id="fifo_" name="FIFO"> を見
てください。

<!--
<sect1> The Large Serial Buffers
-->
<sect1> シリアルポートの大きなバッファ
<!--
<p> We've talked about small 16-byte serial port hardware
buffers but there are also much larger buffers in main memory.  When
the CPU takes some bytes out of the receive buffer of the hardware, it
puts them into a much larger (say 8k-byte) receive buffer in main
memory.  Then a program that is getting bytes from the serial port
takes the bytes it's receiving out of that large buffer (using a
"read" statement in the program).  A similar situation exists for
bytes that are to be transmitted.  When the CPU needs to fetch some
bytes to be transmitted it takes them out of a large (8k-byte)
transmit buffer in main memory and puts them into the small 16-byte
transmit buffer in the hardware.
-->
<p>今まではシリアルポートが持っている 16 バイトの小さいハード
ウェアバッファについて説明しましたが、メインメモリにはもっと大きな
バッファもあります。CPU はいくつかのバイトデータを
ハードウェアの受信バッファから取り込むと、これらのデータをメイン
メモリ中のずっと大きな(例えば 8K バイトの)バッファに入れます。したがって、
シリアルポートからデータを受け取るプログラムは、この大きなバッファから
(プログラム中で "read" 文を用いて)データを取り出します。送信するデータ
についても同じことが言えます。CPU がデータをいくらか送る必要がある場合、
CPU はメインメモリにある大きい(8K バイトの)送信バッファからデータを取
り出し、ハードウェアが持つ 16 バイトの小さな送信バッファに入れます。

<!--
<sect> Serial Port Basics <label id="basics_">
-->
<sect> シリアルポートの基礎 <label id="basics_">
<!-- basics.H  begin   <sect> Serial Port & Modem Basics -->
<!-- Change log: Nov. '99: 2 serial drivers concurrently NG
-->


<!-- ifdef SERIAL_ -->
<!--
<p> You don't have to understand the basics to use the serial port But
understanding it may help to determine what is wrong if you run into
problems.  This section not only presents new topics but also repeats
some of what was said in the previous section <ref id="how_hdw_xfers"
name="How the Hardware Transfers Bytes"> but in greater detail.
-->
<p>シリアルポートを使うだけなら基礎を理解する必要はありませんが、基礎
を理解しておけば、問題が起きた際に原因を特定する役に立つかもしれません。
この章は新しい話題について述べるだけでなく、前の章(<ref
id="how_hdw_xfers" name="ハードウェアによるバイトデータの転送の仕方">
の内容の一部も繰り返します。ただし、こちらの章ではずっと詳しい説明を行
います。

<!--
<sect1> What is a Serial Port ?
-->
<sect1> シリアルポートとは何か?
<!--
<sect2> Intro to Serial
-->
<sect2> シリアル入門
<!--
<p> The serial port is an I/O (Input/Output) device.  
-->
<p>シリアルポートは I/O (入出力)デバイスです。

<!-- ifdef SERIAL_ -->
<!--
An I/O device is just a way to get data into and out of a computer.
There are many types of I/O devices such as serial ports, parallel
ports, disk drive controllers, ethernet boards, universal serial
buses, etc.
-->
I/O デバイスはコンピュータにデータを出し入れするための方法です。I/O デ
バイスにはシリアルポートやパラレルポート、ディスクドライブコントローラ、
イーサネットボード、汎用シリアルバス等のたくさんの種類があります。
<!-- ifdef SERIAL_ end -->
<!--
Most PC's have one or two serial ports.  Each has a 9-pin connector
(sometimes 25-pin) on the back of the computer.  Computer programs can
send data (bytes) to the transmit pin (output) and receive bytes from
the receive pin (input).  The other pins are for control purposes and
ground.
-->
ほとんどの PC にはシリアルポートが 1 つか 2 つあります。
各ポートはコンピュータの裏側に 9 ピン(25 ピンのこともあります)の
コネクタを持っ
ています。コンピュータのプログラムは送信ピン(出力)にデータ(バイト列)を
送ることができますし、受信ピン(入力)からデータを受け取ることもできます。
他のピンはフロー制御と接地のために使います。

<!--
The serial port is much more than just a connector.  It converts the
data from parallel to serial and changes the electrical representation
of the data.  Inside the computer, data bits flow in parallel (using
many wires at the same time).  Serial flow is a stream of bits over a
single wire (such as on the transmit or receive pin of the serial
connector).  For the serial port to create such a flow, it must
convert data from parallel (inside the computer) to serial on the
transmit pin (and conversely).
-->
シリアルポートは単なるコネクタではありません。シリアルポートは
並列(パラレル)のデータを直列(シリアル)に変換し、
データの電気的な表現を変えます。コンピュータ内部では、
データを表すビット群は並列に流れます(同時に多数の配線を用います)。
データを直列に流すとは、1 本の配線(シリアルコネクタの送信ピンや
受信ピン等)にビットのストリームを流すことです。
シリアルポートではこのようにデータを流すため、シリアルポートは送信ピン
上でデータを並列(コンピュータ内部の
形式)から直列に変換できなければなりません(その逆の変換も必要です)。

<!--
Most of the electronics of the serial port is found in a computer chip
(or a section of a chip) known as a UART.  For more details on UARTs
see the section <ref id="uart_" name="What Are UARTs?  How Do They
Affect Performance?">.  But you may want to finish this section first
so that you will hopefully understand how the UART fits into the
overall scheme of things.
-->
シリアルポートの電子回路のほとんどは、UART と呼ばれるチップ(あるいはチッ
プの一部)です。UART の詳細については、<ref id="uart_" name="UART って
何ですか? 性能にどんな影響を与えますか?">の章を見てください。しかし、
まずはこの章から読むとよいでしょう。全体における UART の位置づけが分か
るからです。

<!--
<sect2> Pins and Wires
-->
<sect2> ピンと配線
<!--
<p> Old PC's used 25 pin connectors but only about 9 pins were
actually used so today most connectors are only 9-pin.  Each of the 9
pins usually connects to a wire.  Besides the two wires used for
transmitting and receiving data, another pin (wire) is signal ground.
The voltage on any wire is measured with respect to this ground.  Thus
the minimum number of wires to use for 2-way transmission of data is
3.  Except that it has been known to work with no signal ground wire
but with degraded performance and sometimes with errors.
-->
<p>古い PC では 25 ピンのコネクタが使われていましたが、このうち実際に
使われていたのは 9 本のピンだけです。したがって、現在ではほとんどのコ
ネクタは 9 ピンです。9 本のピンは普通、それぞれ配線に繋がっています。
データの送信と受信用に使われる 2 本の線の他に、信号の接地用に 1 本のピ
ン(配線)が使われます。各配線の電圧は、この接地電圧に対して計測されます。
このように、双方向のデータの送信のために使う配線の最小数は 3 本です。
ただし、信号接地線がなくても動作することが知られてはいますが、この
場合には性能が落ちたり、エラーが起きたりします。

<!--
There are still more wires which are for control purposes (signalling)
only and not for sending bytes.  All of these signals could have been
shared on a single wire, but instead, there is a separate dedicated
wire for every type of signal.  Some (or all) of these control wires
are called "modem control lines".  Modem control wires are either in
the asserted state (on) of +12 volts or in the negated state (off) of
-12 volts.  One of these wires is to signal the computer to stop
sending bytes out the serial port cable.  Conversely, another wire
signals the device attached to the serial port to stop sending bytes
to the computer.  If the attached device is a modem, other wires may
tell the modem to hang up the telephone line or tell the computer that
a connection has been made or that the telephone line is ringing
(someone is attempting to call in).  See section
<ref id="pinout_" name="Pinout and Signals"> for more details.
-->
他にももっと配線がありますが、これらは制御のため(信号処理)に使われるだ
けであり、データの送信には使われません。
全ての信号を 1 本の線で共有することも
できますが、シリアルポートはそうなっておらず、信号の種類ごとに別々の専
用線が用意されています。これらの制御用配線の一部(あるいは全部)は
「モデム制御線(modem control line)」と呼ばれます。モデム制御線の状態は、
+12 V の有効(on)状態か、-12 V の無効(off)状態のどちらかです。
これらのモデム制御線の 1 つは、コンピュータに信号を送って
シリアルポートへのデータ送信を止めさせるためのものです。
これとは逆で、シリアルポートに接続されたデバイスへ信号を送り、
コンピュータへのデータ送信を止めさせるための接続線もあります。
また、接続されているデバイスがモデムの場合には、モデムに電話を切るよう
に指示したり、接続が確立していることや電話が鳴っている(誰かが電話をか
けてきている)ことをコンピュータに教えたりするための線もあります。
詳しくは <ref id="pinout_" name="ピン配置と信号"> の章をご覧ください。

<!-- ifdef SERIAL_ -->
<!--
<sect2> RS-232 or EIA-232, etc.
-->
<sect2> RS-232 や EIA-232 等
<!--
<p> The serial port (not the USB) is usually a RS-232-C, EIA-232-D, or
EIA-232-E.  These three are almost the same thing.  The original RS
(Recommended Standard) prefix became EIA (Electronics Industries
Association) and later EIA/TIA after EIA merged with TIA
(Telecommunications Industries Association).  The EIA-232 spec
provides also for synchronous (sync) communication but the hardware to
support sync is almost always missing on PC's.  The RS designation is
obsolete but is still widely used.  EIA will be used in this howto.
Some documents use the full EIA/TIA designation.  For info on other
(non-EIA-232) serial ports see the section <ref id="non_rs232"
name="Other Serial Devices (not async EIA-232)">
-->
<p>(USB ではない)シリアルポートの規格は普通 RS-232-C, EIA-232-D,
EIA-232-E のいずれかです。この 3 つはほとんど同じものです。
もともと頭に付いていた RS(Recommended Standard)が EIA
(Electronics Industries Association)となり、EIA と TIA
(Telecommunications Industries Association) が合併した後に EIA/TIA と
なりました。EIA-232 の仕様には同期通信も書かれていましたが、同期に対応
するためのハードウェアは PC にはほとんどついていません。
RS という呼称自体は過去のものとなりましたが、今でも広く使われています。
本 HOWTO 文書では EIA という表記を使いますが、文書によっては完全な表記
である EIA/TIAを使っているものもあります。
これ以外の(EIA-232 以外の)シリアルポートについては、
<ref id="non_rs232" name="他のシリアルデバイス (非同期 EIA-232 でないもの)">
の章をご覧ください。
<!-- ifdef SERIAL_ end -->

<!--
<sect1> IO Address &amp; IRQ
-->
<sect1> I/O アドレスと IRQ

<!--
<p> Since the computer needs to communicate with each serial port, the
operating system must know that each serial port exists and where it
is (its I/O address).  It also needs to know which wire (IRQ number)
the serial port must use to request service from the computer's CPU.
It requests service by sending an interrupt on this wire.  Thus every
serial port device must store in its non-volatile memory both its I/O
address and its Interrupt ReQuest number: IRQ.  See <ref
id="interrupt_" name="Interrupts">.  For the PCI bus it doesn't work
exactly this way since the PCI bus has its own system of interrupts.
But since the PCI-aware BIOS sets up chips to map these PCI interrupts
to IRQs, it seemingly behaves just as described above except that
sharing of interrupts is allowed (2 or more devices may use the same
IRQ number).
-->
<p>コンピュータはそれぞれのシリアルポートと通信する必要があるので、
OS はそれぞれのシリアルポートが存在することとそれらがある場所
(I/O アドレス)を知っていなければなりません。また、シリアルポートが 
CPU にサービスを要求する時にどの線(IRQ 番号)を使わなければならないかも
OS は知っている必要があります。
シリアルポートはこの線に割り込みを送ることに
よってサービスを要求します。したがって、それぞれのシリアルポートデバイ
スは I/O アドレスと IRQ (Interrupt ReQuest number)の両方を不揮発性メモリ
に保存していなければなりません。
詳しくは<ref id="interrupt_" name="割り込み">の節を参照してください。
PCI バスの場合は、必ずしもこのように動作するわけではありません。
というのも、PCI に
は独自の割り込みシステムがあるからです。しかし、PCI 対応の BIOS は
PCI の割り込みを IRQ にマッピングするようにチップを設定するため、
見かけ上は先の説明の通りに動作します。ただし、割り込みの共有が許されて
いる点は除きます(複数のデバイスが同じ IRQ 番号を使えるわけです)。

<!--
I/O addresses are not the same as memory addresses.  When an I/O
addresses is put onto the computer's address bus, another wire is
energized.  This both tells main memory to ignore the address and
tells all devices which have I/O addresses (such as the serial port)
to listen to the address to see if it matches the device's.  If the
address matches, then the I/O device reads the data on the data bus.
-->
I/O アドレスはメモリのアドレスとは別物です。
I/O アドレスがコンピュータのアドレスバスに設定されると、別の配線に信号
が流れるのです。この信号が流れているとメインメモリはアドレスを無視
しますが、固有の I/O アドレスを持っている全てのデバイス(シリアルポート
等)は設定されたアドレスに注目し、それがデバイスのアドレスにマッチする
かどうかをチェックします。
もしアドレスがマッチすれば、その I/O デバイスはデータバス上のデータを
読み込みます。

<!--
<sect1> Names: ttyS0, ttyS1, etc.
-->
<sect1> 名前: ttyS0, ttyS1 等
<!--
<p> The serial ports are named ttyS0, ttyS1, etc. (and usually
correspond respectively to COM1, COM2, etc. in DOS/Windows).  The /dev
directory has a special file for each port.  Type "ls /dev/ttyS*" to
see them.  Just because there may be (for example) a ttyS3 file,
doesn't necessarily mean that there exists a physical serial port
there.
-->
<p>シリアルポートには ttyS0, ttyS1 等の名前が付けられます(これらは
普通、DOS や Windows における COM1, COM2 等にそれぞれ対応します)。
/dev ディレクトリには、それぞれのポートに関する特殊ファイルがあります。
"ls /dev/ttyS*" を実行してこれらのファイルを見てみましょう。ただし、
(例えば)ttyS3 ファイルがあるからといって、必ずしもそこに物理的な
シリアルポートが存在するわけではありません。

<!--
Which one of these names (ttyS0, ttyS1, etc.) refers to which
physical serial port is determined as follows.  The serial driver
(software) maintains a table showing which I/O address corresponds to
which ttyS.  This mapping of names (such as ttyS1) to I/O addresses
(and IRQ's) may be both set and viewed by the "setserial" command.
See <ref id="set_serial" name="What is Setserial">.  This does
<tt/not/ set the I/O address and IRQ in the hardware itself (which is
set by jumpers or by plug-and-play software).  Thus what physical port
corresponds to say ttyS1 depends both on what the serial driver thinks
(per setserial) and what is set in the hardware.  If a mistake has
been made, the physical port may not correspond to any name (such as
ttyS2) and thus it can't be used.  See <ref id="ttySN_" name="Serial
Port Devices /dev/ttyS2, etc."> for more details>
-->
(ttyS0, ttyS1 等の)どの名前がどの物理シリアルポートを指すのかは、以下
のようにして決まります。シリアルドライバ(ソフトウェア)は、どの I/O ア
ドレスがどの ttyS に対応するのかを示す表を管理しています。このような名
前(ttyS1 等)から I/O アドレス(と IRQ)への対応は、設定も表示も "setserial"
コマンドで行えます。
<ref id="set_serial" name="setserial とは何か?">の節をご覧ください。こ
のプログラムは、ハードウェアそのものの I/O アドレスや IRQ の設定は
<tt/行いません/(ハードウェアの設定はジャンパやプラグ&amp;プレイの設定
プログラムで行います)。このように、どの物理ポートが ttyS1 などに対応す
るのかは、(setserial での)シリアルドライバの設定とハードウェアの設定
の両方に依存します。設定が間違っていると、物理ポートは(ttyS2 などの)
名前に対応させられず、したがって使えなくなります。
詳しくは
<ref id="ttySN_" name="/dev/ttyS2 等のシリアルポートデバイス">
の章をご覧ください。

<!--
<sect1> Interrupts <label id="interrupt_">
-->
<sect1> 割り込み <label id="interrupt_">
<p> 
<!--O
When the serial port receives a number of bytes (may be set to 1, 4,
8, or 14) into its FIFO buffer, it signals the CPU to fetch them by
sending an electrical signal known as an interrupt on a certain wire
normally used only by that port.  Thus the FIFO waits for a number of
bytes and then issues an interrupt.
-->
シリアルポートは、ある数のバイトデータ(1, 4, 8, 14 のいずれかに設定さ
れていると思います)のデータを FIFO バッファに受け取ると、通常はそのポー
トだけが使う特定の配線上に割り込みとして知られる電気信号を流すことによ
り、そのデータを取り込むように CPU に伝えます。このように FIFO は、あ
る数のバイトデータを待って、それから割り込みを発行します。

<!--O
However, this interrupt will also be sent if there is an unexpected
delay while waiting for the next byte to arrive (known as a timeout).
Thus if the bytes are being received slowly (such as someone typing on
a terminal keyboard) there may be an interrupt issued for every byte
received.  For some UART chips the rule is like this: If 4 bytes in a
row could have been received, but none of these 4 show up, then the
port gives up waiting for more bytes and issues an interrupt to fetch
the bytes currently in the FIFO.  Of course, if the FIFO is empty,
no interrupt will be issued.
-->
しかし、この割り込みは、次のバイトデータが届くのを待っている間に、予期
しない遅延が生じた時にも送られます(タイムアウトといいます)。このように、
バイトデータがゆっくり受信されていると(端末のキーボードで入力している
ように)、1 バイトを受け取るごとに割り込みが発行されるかもしれません。
一部の UART チップでは、以下のような規則になります:  4 バイトを連続し
て受け取れるかもしれなかったのに、これらの 4 バイトのデータがいずれも
出てこなければ、シリアルポートは次のバイトデータを待つのをあきらめ、現
在 FIFO に入っているバイトデータを取得させるために割り込みを発行します。
もちろん、FIFO が空であれば割り込みは発行されません。

<!--
Each interrupt conductor (inside the computer) has a number (IRQ) and
the serial port must know which conductor to use to signal on.  For
example, ttyS0 normally uses IRQ number 4 known as IRQ4 (or IRQ 4).  A
list of them and more will be found in "man setserial" (search for
"Configuring Serial Ports").  Interrupts are issued whenever the
serial port needs to get the CPU's attention.  It's important to do
this in a timely manner since the buffer inside the serial port can
hold only 16 (1 in old serial ports) incoming bytes.  If the CPU fails
to remove such received bytes promptly, then there will not be any
space left for any more incoming bytes and the small buffer may
overflow (overrun) resulting in a loss of data bytes.
There is no <ref id="flow_control" name="Flow Control"> to prevent
this.   
-->
(コンピュータ内部にある)それぞれの割り込み線には番号(IRQ)が付いており、シリ
アルポートは信号を送るためにどの線を使うのかを知っていなければなりませ
ん。例えば ttyS0 は通常、IRQ 番号 4 を使います。これは IRQ4(または IRQ
4)と書かれます。IRQ 番号のリスト等は "man setserial" に書かれています(
「シリアルポートのコンフィギュレーション上の注意事項
(Configuring Serial Ports)」の章を見てください)。シリアルポートが CPU 
の注意を引く必要がある時には必ず割り込みが発行されます。
割り込みの発行を適切なタイミングで行うことは重要です。というのも、シリ
アルポートのバッファは入ってくるデータを 16 バイト(古いシリアルポートでは 1 バ
イト)しか保持できないからです。このような受信データをバッファからうま
く取り出すことに CPU が失敗すると、これ以上のデータが入る場所がなくな
り、小さなバッファがあふれて(オーバーラン)データが無くなってしまうかも
しれません。
これを <ref id="flow_control" name="フロー制御">で防ぐことはできません。

<!--
Interrupts are also issued when the serial port has just sent out all
16 of its bytes from its small transmit buffer out the external cable.
It then has space for 16 more outgoing bytes.  The interrupt is to
notify the CPU of that fact so that it may put more bytes in the small
transmit buffer to be transmitted.  Also, when a modem control line
changes state an interrupt is issued.
-->
割り込みは、シリアルポートが 16 バイトのデータを小さい送信バッファから
外部ケーブルに全て送り出した直後にも発行されます。この送信バッファには、
送り出すデータ用の 16 バイトの空きができます。
この事実を CPU に伝え、小さい送信バッファに送信すべき新しいデータを入
れさせるために割り込みを用います。
また、モデム制御線の状態が変化した時にも割り込みが発行されます。

<!--
The buffers mentioned above are all hardware buffers.  The serial port
also has large buffers in main memory.  This will be explained later
-->
上の説明のバッファは全てハードウェアバッファのことです。シリアルポート
はメインメモリ上にも大きいバッファを持っています。これは後ほど説明します。

<!--
Interrupts convey a lot of information but only indirectly.  The
interrupt itself just tells a chip called the interrupt controller
that a certain serial port needs attention.  The interrupt controller
then signals the CPU.  The CPU runs a special program to service the
serial port.  That program is called an interrupt service routine
(part of the serial driver software).  It tries to find out what has
happened at the serial port and then deals with the problem such a
transferring bytes from (or to) the serial port's hardware buffer.
This program can easily find out what has happened since the serial
port has registers at IO addresses known to the the serial driver
software.  These registers contain status information about the serial
port.  The software reads these registers and by inspecting the
contents, finds out what has happened and takes appropriate action.
-->
割り込みは多くの情報を伝えますが、これは間接的にしか行いません。
割り込みそのものは、特定のポートが注意を求めていることを割り込みコント
ローラと呼ばれるチップに知らせるだけです。割り込みコントローラはこれを
受けて CPU に信号を送ります。CPU はシリアルポートにサービスを提供する
特殊なプログラムを実行します。このプログラムは割り込みサービスルーチン
と呼ばれます(シリアルドライバのソフトウェアの一部です)。
割り込みサービスルーチンはシリアルポートで起きた出来事を調べ、その問題
(シリアルポートのハードウェアバッファのデータ入出力など)を処理します。
このルーチンはシリアルポートで起きたことを簡単に知ることができます。と
いうのも、シリアルポートのレジスタはシリアルデバイスドライバが知ってい
る I/O アドレスにあるからです。このレジスタは、シリアルポートの状態に
関する情報を保持しています。デバイスドライバはこのレジスタを読んでその
内容を調べることにより、シリアルポートで起きたことを知り、適切な動作を
行うことができます。





<!-- ifdef SERIAL_ -->
<!--
<sect1> Data Flow (Speeds)
-->
<sect1> データフロー (速度)
<!--
<p> Data (bytes representing letters, pictures, etc.) flows into and
out of your serial port.  Flow rates (such as 56k (56000) bits/sec)
are (incorrectly) called "speed".  But almost everyone says "speed"
instead of "flow rate".  
-->
<p>シリアルポートではデータ(文字、画像などを表すバイト列)の入出力が行
われます。データが流れる速度であるフローレート(56k (56000) ビット/秒な
ど)は(不正確ですが)「速度」と呼ばれます。ですが大抵の人は
「フローレート」ではなく「速度」の方を使います。

<!--
It's important to understand that the average speed is often less than
the specified speed.  Waits (or idle time) result in a lower average
speed.  These waits may include long waits of perhaps a second due to
<ref id="flow_control" name="Flow Control">.  At the other extreme
there may be very short waits (idle time) of several micro-seconds
between bytes.  If the device on the serial port (such as a modem)
can't accept the full serial port speed, then the average speed must
be reduced.
-->
平均速度は仕様で決められている速度よりも遅い場合が多いことを理解してお
くことが大切です。待ち時間(あるいはアイドル時間)があると、平均速度は低
くなります。このような待ち時間には、<ref id="flow_control"
name="フロー制御">による 1 秒程度もある長い待ち時間も含まれます。別の
極端な例としては、バイトデータを送る間の数ミリ秒という非常に短い待ち時
間があります。シリアルポートに接続したデバイス(モデムなど)がシリアルポー
トの最高速度に付いていけない場合には、平均速度を低くしなければなりませ
ん。
<!-- ifdef SERIAL_ end -->

<!--
<sect1> Flow Control <label id="flow_control">
-->
<sect1> フロー制御 <label id="flow_control">
<!--
<p> Flow control means the ability to stop the flow of bytes in a
wire.  It also includes provisions to restart the flow without any
loss of bytes.  Flow control is needed for modems to allow a jump in
instantaneous flow rates.  
-->
<p>フロー制御とは、配線を流れるバイトデータを止める機能のことです。
これには、バイトデータを失うことなくデータを再び流し始める機能も含まれ
ます。フロー制御は、モデムが瞬間のフローレートを非連続的に変えられるよ
うにするために必要です。

<!--
<sect2> Example of Flow Control 
-->
<sect2> フロー制御の例
<!--
<p> For example, consider the case where you connect a 36.6k external
modem via a short cable to your serial port.  The modem sends and
receives bytes over the phone line at  36.6k bits per second (bps).
It's not doing any data compression or error correction.  You have set
the serial port speed to 115,200 bits/sec (bps), and you are sending
data from your computer to the phone line.  Then the flow from the
your computer to your modem over the short cable is at 115.2k bps.
However the flow from your modem out the phone line is only 33.6k bps.
Since a faster flow (115.2k) is going into your modem than is coming
out of it, the modem is storing the excess flow (115.2k -33.6k = 81.6k
bps) in one of its buffers.  This buffer would eventually overrun (run
out of free storage space) unless the 115.2k flow is stopped.  
-->
<p>例として、33.6k の外部モデムを短いケーブルを使ってシリアルポートに
接続する場合を考えましょう。このモデムは電話回線上で 33.6k bps
(ビット毎秒)でデータを送受信します。データ圧縮やエラー訂正は全く行わな
いものとします。シリアルポートの速度は 115.2k bps に設定してあり、デー
タをコンピュータから電話回線に送ります。すると、コンピュータからモデム
へは短いケーブルを通って 115.2k bps でデータが流れます。しかし、モデム
から電話回線へは 33.6k bps でしかデータが流れません。データが出て行く
よりも速くデータが入ってくるので、モデムは超過分のデータ
(115.2k -33.6k = 81.6k bps)をバッファに保持しなければなりません。
115.2k bps のデータの流れが止まらない限り、結局はこのバッファは溢れて
(空き容量がなくなって)しまいます。

<!--
But now flow control comes to the rescue.  When the modem's buffer is
almost full, the modem sends a stop signal to the serial port.  The
serial port passes on the stop signal on to the device driver and the
115.2k bps flow is halted.  Then the modem continues to send out data
at 33.6k bps drawing on the data it previous accumulated in its
buffer.  Since nothing is coming into the buffer, the level of bytes
in it starts to drop.  When almost no bytes are left in the buffer,
the modem sends a start signal to the serial port and the 115.2k flow
from the computer to the modem resumes.  In effect, flow control
creates an average flow rate in the short cable (in this case 33.6k)
which is significantly less than the "on" flow rate of 115.2k bps.
This is "start-stop" flow control.
-->
ですが、ここでフロー制御が役立ちます。モデムのバッファが溢れそうになる
と、モデムはシリアルポートに停止信号を送ります。シリアルポートはこの停
止信号をデバイスドライバに渡し、115.2k bps のデータの流れは停止します。
モデムは、今までバッファに蓄えたデータを取り出しながら、その
まま 33.6k bps でデータを送り続けます。するとバッファには何も入ってこ
ないため、バッファ内のデータ量は減り始めます。バッファ内のデータがほと
んどなくなると、モデムは開始信号をシリアルポートに送り、コンピュータから
モデムへ再び 115.2k bps でデータが流れ始めます。フロー制御により事実上、
短いケーブル上での平均的なフロー速度(この場合は 33.6k bps)は、データを
「流し続けた」場合の速度である 115.2k bps よりもずっと遅くなります。
これが「開始-停止」フロー制御です。

<!--
The above is a simple example of flow control for flow from the
computer to a modem , but there is also flow control which is used for
the opposite direction of flow: from a modem (or other device) to a
computer.  Each direction of flow involve 3 buffers: 1. in the modem
2. in the UART chip (called FIFOs) 3. in main memory managed by the serial
driver.  Flow control protects certain buffers from overflowing.  The
small UART FIFO buffers are not protected in this way but rely
instead on a fast response to the interrupts they issue.  FIFO stand
for "First In, First Out" which is the way it handles bytes.  All the
3 buffers use the FIFO rule but only one of them also uses it as a
name.  This is the essence of flow control but there are still some
more details.
-->
上記の簡単な例はコンピュータからモデムへの流れのフロー制御でしたが、反
対向きの流れに対して用いるフロー制御も
あります。すなわちモデム(または他のデバイス)からコンピュータの向きです。
どちらの向きの流れにも 3 つのバッファ(1. モデム内のバッファ、
2. UART チップ(いわゆる FIFO)の内部、3. シリアルドライバが管理するメイ
ンメモリ中のバッファ)があります。フロー制御は、特定のバッファが溢れない
ように保護します。小さい UART FIFO バッファはこのような保護を受けてい
ませんが、その代わりに、このバッファが発行する割り込みへの応答が高速で
あることを期待して動作します。FIFO は「First In, First Out(先に入った
データが先に出る)」という、バイトデータの扱い方を表しています。
3 つのバッファ全てが FIFO の規則で動作しますが、これを名前として持って
いるのは 1 つだけです。これがフロー制御の本質ですが、説明することはもっ
とたくさんあります。

<!-- ifdef SERIAL_ -->
<!--
<sect2> Symptoms of No Flow Control
-->
<sect2> フロー制御がない時の症状
<!--
<p> Understanding flow-control theory can be of practical use.  The
symptom of no flow control is chunks of data missing from files sent
without the benefit of flow control.  This is because when overflow
happens, it's usually more than just a few bytes that overflow and are
lost.  Often hundreds or even thousands of bytes get lost, and all in
contiguous chunks.
-->
<p>フロー制御の理屈を知っていると実際に役立てることができます。
フロー制御がない時に出る症状は、フロー制御の恩恵を受けずに送られた
ファイルからデータがごそっと消えてしまうことです。
これはオーバーフローが起こった時には、たいてい数バイトどころではない量
のデータがあふれて失われるからです。
何百、何千バイトものデータが消え、その全てが一続きであることもよくあり
ます。
<!-- ifdef SERIAL_ end -->

<!--
<sect2> Hardware vs. Software Flow Control
-->
<sect2> ハードウェアフロー制御対ソフトウェアフロー制御
<!--
<p> If feasible it's best to use "hardware" flow control that uses two
dedicated "modem control" wires to send the "stop" and "start"
signals.  
-->
<p>可能であれば、できるだけ「ハードウェア」のフロー制御を使いましょう。
これは専用の「モデム制御線」を 2 本使い、「停止(stop)」と「開始(start)」
の信号を送るものです。


<!--
Software flow control uses the main receive and transmit wires to send
the start and stop signals.  It uses the ASCII control characters DC1
(start) and DC3 (stop) for this purpose.  They are just inserted into
the regular stream of data.  Software flow control is not only slower
in reacting but also does not allow the sending of binary data unless
special precautions are taken.  Since binary data will likely contain
DC1 and DC3, special means must be taken to distinguish between a DC3
that means a flow control stop and a DC3 that is part of the binary
code.  Likewise for DC1.  
-->
ソフトウェアによるフロー制御は、開始信号と停止信号
を送るためにメインの送信線と受信線を使います。ソフトウェアのフロー制御
は、この信号を送るために ASCII 制御文字の DC1(開始)と DC3(停止)を使い
ます。この制御文字は単に、通常のデータストリーム内に挿入されます。ソフ
トウェアのフロー制御は反応が遅いだけでなく、特別な対策を講じなければモ
デムを使ってバイナリデータを送ることもできません。バイナリデータには大
抵、フロー制御用の制御文字である DC1, DC3 が入っているので、特殊な対策を立て
て、フロー制御の停止信号である DC3 とバイナリコードの一部である DC3 
を区別しなければなりません。DC1 についても同様です。


<!--
<sect1> Data Flow Path, Buffers
-->
<sect1> データフローのパスとバッファ
<!--
<p> Although much has been explained about this including flow
control, a pair of 16-byte FIFO buffers (in the hardware), and
a pair of larger buffers inside a 
device connected to the serial port
there is still another pair of buffers.  These are large buffers
(perhaps 8k) in main memory also known as serial port buffers.  When
an application program sends bytes to the serial port
 they first get stashed in the the
transmit serial port buffer in main memory.  The pair consists of both
this transmit buffer and a receive buffer for the opposite direction
of byte-flow.
-->
<p>この話題については、フロー制御・(ハードウェアが持つ)16 バイトの
FIFO バッファのペア・シリアルポートに接続されている大きいバッファの
ペアを含めた大部分を既に説明しましたが、これ以外にもまだバッファの対があ
ります。すなわちメインメモリ上に大きな(多分 8KB)バッファが存在し、
これもシリアルポートのバッファと呼ばれます。アプリケーションプログラム
がデータをシリアルポートに送ると、このデータはまずメインメモリの方の
送信シリアルポートバッファに格納されます。バッファの対は、データの流れ
の向きが反対である送信バッファと受信バッファの組み合せです。

<!--
The serial device driver takes out say 16 bytes from this transmit buffer,
one byte at a time and puts them into the 16-byte transmit buffer in the
serial hardware for transmission.  Once in that transmit buffer, there
is no way to stop them from being transmitted.  They are then
transmitted to the device connected to the serial port
which also has a fair sized (say 1k) buffer.  When the device driver
(on orders from flow control) stops the flow of outgoing bytes from
the computer, what it actually stops is the flow of outgoing bytes
from the large transmit buffer in main memory.  Even after this has
happened and the flow to the device
connected to the serial port has stopped, an application program
may keep sending bytes to the 8k transmit buffer until it becomes
fill.  
-->
シリアルポートのデバイスドライバは、例えば 16 バイトのデータを 1 バイ
トずつ送信バッファから取り出し、これをシリアルポートのハードウェアが送
信用に持っている 16 バイトの送信バッファに入れます。一度データが送信バッファに入る
と、その送信を止める方法はありません。そしてこのデータは、シリアルポー
トに接続されているデバイスに送られます。シリアルポートも適切な大きさ
(例えば 1K バイト)のバッファを持っています。デバイスドライバが(フロー
制御による指示で)コンピュータから出ていくバイトデータの流れを止めた時
には、実際に止まるのはメインメモリ上にある大きな送信バッファから出てい
くバイトデータの流れです。これが起こり、シリアルポー
トに接続されているデバイスへのデータの流れが止まった後であっても、アプ
リケーションプログラムは、8K バイトの送信バッファがいっぱいになるまでは、
ここにデータを送り続けることができます。

<!--
When it gets fill, the application program can't send any more bytes
to it (a "write" statement in a C_program blocks) and the application
program temporarily stops running and waits until some buffer space
becomes available.  Thus a flow control "stop" is ultimately able to
stop the program that is sending the bytes.  Even though this program
stops, the computer does not necessarily stop computing.  It may
switch to running other processes while it's waiting at a flow control
stop.  The above was a little oversimplified since there is another
alternative of having the application program itself do something else
while it is waiting to "write".
-->
このバッファがいっぱいになると、アプリケーションプログラムはそれ以上の
データを送る(C 言語では "write" 文を使います)ことができなくなり、
アプリケーションの実行を一時的に停止してバッファに空きができるのを待ち
ます。
このように、フロー制御の "stop" 信号は最終的には、データを送る
プログラムを止めることができます。このプログラムが止まっても、
コンピュータは必ずしも計算を止めるわけではありません。フロー
制御の stop 信号を受けて待っている間は、別のプロセスに切替えればよいの
です。
以上の説明は多少簡略化しすぎです。というのも、"write" 文を待っている間
にアプリケーションプログラム自体に別処理をさせる方法も他にあるからです。

<!-- ifdef SERIAL_ -->
<!--
<sect1> Complex Flow Control Example
-->
<sect1> 複雑なフロー制御の例
<!--
<p> For many situations, there is a transmit path involving several
links, each with its own flow control.  For example, I type at a
text-terminal connected to a PC with a modem to access a BBS.  For
this I use the application program "minicom" which deals with 2 serial
ports: one connected to a modem and another connected to the
text-terminal.  What I type at the text terminal goes into the first
serial port to minicom, then from minicom out the second serial port
to the modem, and then onto the telephone line to the BBS.  The
text-terminal has a limit to the speed at which bytes can be displayed
on its screen and issues a flow control "stop" from time to time to
slow down the flow.  What happens when such a "stop" is issued?  Let's
consider a case where the "stop" is long enough to get thru to the BBS
and stop the program at the BBS which is sending out the bytes.  
-->
<p>多くの場合、伝送経路が複数のリンクを持ち、そのそれぞれが独自のフロー
制御を行うことがあります。例えば、モデム経由で BBS にアクセスしている 
PC に接続しているテキスト端末上で文字をタイプしたとします。この場合、
使っているアプリケーションプログラム "minicom" はシリアルポートを 2 つ
扱うことになります。テキスト端末上で入力された文字は、まずシリアルポー
トから minicom に送られ、次に minicom から次のシリアルポートを経由でモ
デムに送り出されます。そして最後に、この文字は電話回線を通じて BBS に
送られます。テキスト端末が画面に文字を表示できる速度には限界があるので、
速度を落すためにフロー制御の "stop" 信号が時々発行されます。"stop" 信
号が発行されると一体何が起こるのでしょうか? "stop" 信号が BBS まで届き、
BBS ホスト上でデータを送り出しているプログラムを止めるまでに長い時間が
かかる場合を考えてみましょう。

<!--
Let's trace out the flow of this "stop" (which may be "hardware" on
some links and "software" on others).  First, suppose I'm "capturing"
a long file from the BBS which is being sent simultaneously to both my
text-terminal and a to file on my hard-disk.  The bytes are coming in
faster than the terminal can handle them so it sends a "stop" out its
serial port to the first serial port on my PC.  The device driver
detects it and stops sending bytes from the 8k serial buffer (in main
memory) to the terminal.  Now minicom still keeps sending out bytes for
the terminal into this 8k buffer.
-->
この "stop" 信号の流れを追跡してみましょう(リンクによって
ソフトウェアで処理されたり、ハードウェアで処理されたりします)。まずは
BBS から大きなファイルを「取得する」場合を考えます。この際には、テキス
ト端末とハードディスク上のファイルの両方に同時にデータが送られます。
テキスト端末の表示速度よりも速くデータが送られてくるので、テキスト端末
は PC の 1 つめのシリアルポートに "stop" 信号を送ります。デバイスドラ
イバはこれを検出し、(メインメモリ上にある)8KB のシリアルバッファから端
末へのデータ送信を停止させます。この時点ではまだ、minicom は端末へ送る
ためのデータを 8KB のバッファに送り続けています。

<!--
When this 8k transmit buffer (on the first serial port) is full,
minicom must stop writing to it.  Minicom stops and waits.  But this
also causes minicom to stop reading from the 8k receive buffer on the
2nd serial port connected to the modem.  Flow from the modem continues
until this 8k buffer too fills up and sends a different "stop" to the
modem.  Now the modem's buffer ceases to send to the serial port and
also fills up.  The modem (assuming error correction is enabled) sends
a "stop signal" to the other modem at the BBS.  This modem stops
sending bytes out of its buffer and when its buffer gets fill, another
stop signal is sent to the serial port of the BBS.  At the BBS, the
8-k (or whatever) buffer fills up and the program at the BBS can't
write to it anymore and thus temporarily halts.  
-->
(1 つめのシリアルポートの)この 8KB の送信バッファがいっぱいになると、
minicom はここへの書き込みを止めなければなりません。minocom はデータを
送るのを止めて待ち状態に入ります。ですがこれによって同時に、モデムに接
続されている 2 番目のシリアルポートの 8KB の受信バッファからの読み込み
も止まってしまいます。モデムからのデータは、8 KB のバッファがいっぱい
になり、モデムに対する "stop" 信号が新しく送られるまで流れ続けます。
モデム(エラー訂正は有効であるものとします)は "stop 信号" を BBS 側の
モデムに送ります。このモデムはバッファからデータを送り出すのを止め、
このバッファがいっぱいになると、BBS ホストのシリアルポートに stop 信号
を送ります。BBS ホストでは、8KB(など)のバッファがいっぱいになり、BBS 
ホスト側のプログラムから書き込みできなくなると、このプログラムが一時的
に停止します。

<!--
Thus a stop signal from a text terminal has halted a programs on a BBS
computer.  What a complex sequence of events!  Note that the stop
signal passed thru 4 serial ports, 2 modems, and one application
program (minicom).  Each serial port has 2 buffers (in one direction
of flow): the 8k one and the hardware 16-byte one.  The application
program may have a buffer in its C_code.  This adds up to 11 different
buffers the data is passing thru.  Note that the small serial hardware
buffers do not participate directly in flow control.
-->
このようにして、テキスト端末から送られた stop 信号が BBS ホスト上のプ
ログラムを止めます。とっても面倒な仕組みですね! stop 信号はシリアルポー
トを 4 つ通り、モデムを 2 つ通り、アプリケーションプログラムを 1 つ
(minicom)を通過するのです。各シリアルポートは(一方向につき)バッファを 
2 つ(8KB のバッファと、ハードウェアが持つ 16 バイトのバッファ)持ちます。
アプリケーションプログラムは C 言語のコード内部でもバッファを持ってい
るでしょう。これも含めると、データは 11 個もの別々のバッファを通ります。
シリアルハードウェアの小さいバッファはフロー制御を直接は識別しない点に
は注意してください。

<!--
If the terminal speed limitation is the bottleneck in the flow from
the BBS to the terminal, then its flow control "stop" is actually
stopping the program that is sending from the BBS as explained above.
But you may ask: How can a "stop" last so long that 11 buffers (some
of them large) all get filled up?   It can actually happen this way if
all the buffers were near their upper limits when the terminal sent
out the "stop".  
-->
BBS から端末へデータが流れる際に端末の速さの限界がボトルネックになって
いる場合、フロー制御の "stop" 信号は実際には BBS からデータを送るプロ
グラムを止めることになります。これは先程説明した通りです。
ですが「"stop" 信号がそんなに時間を食って、11 個のバッファ(もっと
大きいバッファもある)が全部あふれることなんて本当にあるの?」と思われる
かもしれません。
テキスト端末が "stop" 信号を送った時に全てのバッファが容量いっぱいに近
かった場合には、そうなることは実際にあります。

<!--
But if you were to run a simulation on it you would discover that it's
usually more complicated than this.  At an instant of time some links
are flowing and others are stopped (due to flow control).  A "stop"
from the terminal seldom propagates back to the BBS neatly as
described above.  It may take a few "stops" from the terminal to
result in one "stop" at the BBS.  To understand what is going on you
really need to observe a simulation which can be done for a simple
case with coins on a table.  Use only a few buffers and set the upper
level for each buffer at only a few coins.
-->
ですが実験を行ってみれば、これよりももっと説明が複雑になる
ことがお分かりになると思います。ある瞬間にデータを流しているリンクもあ
りますし、(フロー制御によって)止まっているリンクもあります。
端末からの "stop" 信号が、先に説明したようにうまく BBS ホストに伝わる
ことは滅多にありません。BBS 側に "stop" 信号を 1 つ届けるには、端末か
らは "stop" 信号をいくつか送らなければならないことがあります。実際の動
作を理解するには、机にコインを置いて行う簡単な実験をやってみるといいで
しょう。バッファの数は 2, 3 個で、各バッファの容量もコイン 2, 3 個だけ
にしてください。

<!--
Does one really need to understand all this?  Well, understanding this
explained to me why capturing text from a BBS was loosing text.  The
situation was exactly the above example but modem-to-modem flow
control was disabled.  Chunks of captured text that were supposed to
also get to my hard-disk never got there because of an overflow at my
modem buffer due to flow control "stops" from the terminal.  Even
though the BBS had a flow path to the hard-disk without bottlenecks,
the overflow due to the terminal happened on this path and chunks of
text were lost and never even made it to the hard-disk.  Note that the
flow to the hard-disk passed thru my modem and since the overflow
happened there, bytes intended for the hard-disk were lost.
-->
読者の皆さんは、なぜこんなことをいちいち説明するのかと思われるかもしれ
ません。ですが筆者は、BBS から取得したテキストがなくなる原因をこれで理
解したことがあるのです。その時の状況はちょうど前の例と同じですが、モデ
ム対モデムのフロー制御が無効になっていました。ハードディスクにも保存さ
れるはずの、取得したテキストデータが実際には保存されなかったのですが、
その原因は端末からのフロー制御の "stop" 信号のためにモデムのバッファが
オーバーフローしていたことでした。ボトルネックがないデータの経路が BBS 
からハードディスクまであっても、端末が原因となるオーバーフローがこの経
路上で起きたため、テキストデータが無くなってハードディスクに保存できま
せんでした。モデム経由でハードディスクにデータを渡すはずが、モデムでオー
バーフローが起こっていたために、ハードディスクに送るべきデータが消えて
いたのでした。
<!-- ifdef SERIAL_ end -->

<!--
<sect1> Serial Software: Device Driver Module
-->
<sect1> シリアル操作ソフトウェア: デバイスドライバモジュール
<!--
<p> The device driver for the serial port is the software that
operates the serial port.  It is now provided as a serial module.
This module will normally get loaded automatically if it's needed.
The kernel 2.2 + will do this.  In earlier kernels, you had to have
<tt/kerneld/ running in order to do auto-load modules on demand.
Otherwise the serial module needed to be explicitly listed in
/etc/modules.  Before modules became popular with Linux, the serial
driver was usually built into the kernel.  If it's still built into
the kernel (you might have selected this when you compiled the kernel)
don't let the serial module load.  If you do and wind up with two
serial drivers, it's reported that you can't use the serial ports and
get an "I/O error" if an attempt is made to open them.
-->
<p> シリアルポート用のデバイスドライバは、シリアルポートを操作するソフ
トウェアです。現在はこれはシリアルモジュールとして用意されています。
このモジュールは普通、必要な時に自動的にロードされます。バージョン 2.2 
以降のカーネルはこれを行います。これより古いカーネルでは、必要な時にモ
ジュールを自動ロードするためには <tt/kerneld/ を実行する必要がありまし
た。これを行わない場合には、/etc/modules に明示的に列挙する必要があり
ました。モジュールが Linux で一般的になる前は、シリアルドライバはカー
ネルに組み込むのが普通でした。もし、シリアルドライバがまだカーネルに組
み込んであるのなら(カーネルのコンパイル時にそう選択したのかもしれませ
ん)、シリアルモジュールをロードしてはいけません。もしこれをロードして
シリアルドライバが 2 つになってしまうと、シリアルポートは使えなくなり
ます。この場合にシリアルポートをオープンしようとすると "I/O error" と
なります。

<!--
When the serial module is loaded it displays a message on the screen
about the existing serial ports (often showing a wrong IRQ).  But once
the module is used by <tt/setserial/ to tell the device driver the
(hopefully) correct IRQ then you should see a second display similar
to the first but with the correct IRQ, etc. See <ref id="set_serial"
name="What is Setserial"> for more info on <tt/setserial/. ) 
-->
シリアルモジュールがロードされると、存在するシリアルポートに関するメッ
セージが画面に表示されます(よく間違った IRQ を表示します)。
しかし、一度 <tt/setserial/ を使ってデバイスドライバに(たぶん)正しい 
IRQ を教えれば、次の表示は最初の表示に似ていますが、IRQ 等が正しくなっ
ているはずです。<tt/setserial/ の詳細については
<ref id="set_serial" name="setserial とは何か?">をご覧ください。

<!--
One may modify the driver by editing the kernel source code.  Much of
the serial driver is found in the file serial.c.  For details
regarding writing of programs for the serial port see
Serial-Programming-HOWTO (currently being revised by Vern Hoxie).
-->
カーネルのソースコードを編集してドライバを修正することができます。シリ
アルドライバの大部分は serial.c ファイルにあります。シリアルポートを使
うプログラムの詳しい書き方については、Serial-Programming-HOWTO
をご覧ください(現在 Vern Hoxie さんが改訂中です)。
<!-- basics.H end  -->

<!--
<sect> Is the Serial Port Obsolete?
-->
<sect> シリアルポートは時代遅れなのか?
<!--
<sect1> Introduction
-->
<sect1> はじめに
<!--
<p> The answer is yes, but ... The serial port is somewhat obsolete
but it's still needed, especially for Linux.  The serial port has many
shortcomings but almost all new PC's seem to come with them them.
Linux supports ordinary telephone modems only if they work thru a
serial port.
-->
<p>「はい」というのが答えですが…。シリアルポートはいくらか時代遅れで
すが現在でも必要ですし、特に Linux では必要です。シリアルポートには欠
点がたくさんありますが、新しい PC のほとんどにシリアルポートが付いてい
るようです。Linux がサポートしている通常電話回線用のモデムは、シリアルポート
経由で動くものだけです。

<!--
The serial port must pass data between the computer and the external
cable.  Thus it has two interfaces and both of these interfaces are
slow.  First we'll consider the interface via external cable to the
outside world.
-->
シリアルポートは、コンピュータと外部ケーブルの間でデータを運ばなければ
なりません。
よって、シリアルポートは 2 つのインタフェースを
持ち、どちらのインタフェースも低速です。まずは外部ケーブルを通じた外界
とのインタフェースを考えてみましょう。

<!--
<sect1> EIA-232 Cable Is Low Speed &amp; Short Distance
-->
<sect1> 低速で距離も短い EIA-232 ケーブル
<!--
<p> The conventional EIA-232 serial port is inherently low speed and
is severely limited in distance.  Ads often read "high speed" but it
can only work at "high speed" over very short distances such as to a
modem located right next to the computer.  Compared to a network card,
even this "high speed" is low speed.  All of the serial cable wires
use a common ground return wire so that twisted-pair technology
(needed for high speeds) can't be used without additional hardware.
More modern interfaces for serial ports exist but they are not
standard on PC's like the EIA-232 is.  See <ref id="non_232"
name="Successors to EIA-232">.  Some multiport serial cards support
them.
-->
<p>従来の EIA-232 シリアルポートは、どうしても低速で、距離にも厳しい
限界があります。広告ではよく「高速」と謳われますが、実際に「高速」に動
作するのは、PC のすぐ隣にモデムがあるような非常に距離が短い場合だけで
す。またネットワークカードと比べると、この「高速」というのも低速に過ぎ
ません。シリアルケーブルは全て共通の接地線を使う配線を用いているので、
ハードウェアを追加しない限り(高速な伝送で必要となる)ツイストペア技術を
使えません。シリアルポート用の最新技術も存在しますが、これら
は EIA-232 と違って PC の標準ではありません。
<ref id="non_232" name="EIA-232 の後継">をご覧ください。
一部のマルチポートシリアルカードはこれらをサポートしています。

<!--
It is somewhat tragic that the RS-232 standard from 1969 did not use
twisted pair technology which could operate about a hundred times
faster.  Twisted pairs have been used in telephone cables since the
late 1800's.  In 1888 (over 110 years ago) the "Cable Conference"
reported its support of twisted-pair (for telephone systems) and
pointed out its advantages.  But over 80 years after this approval by
the "Cable Conference", RS-232 failed to utilize it.   Since RS-232
was originally designed for connecting a terminal to a low speed modem
located nearby, the need for high speed and longer distance
transmission was apparently not recognized.
-->
1962 年に作られた RS-232 規格がツイストペア技術を使っていないことはあ
る意味悲劇です。これを使っていれば 100 倍高速に動作できたはずなのです
から。ツイストペアは電話線には 19 世紀末から使われてきました。
1888 年(110 年以上も前)の「ケーブル会議(Cable Conference)」は、ツイス
トペアの(電話システムへの)支持とその利点を報告しています。ですが、
「ケーブル会議」での合意は、80 年以上も後の RS-232 では生かされません
でした。RS-232 は元々、端末をその隣に置いた低速モデムと接続するために
設計されたので、高速・長距離の伝送に関する必要性は理解されなかったよう
です。

<!--
<sect1> Inefficient Interface to the Computer
-->
<sect1> コンピュータへのインタフェースの非効率さ

<!--
<p> To communicate with the computer, any I/O device needs to have
an address so that the computer can write to it and read from it.  For
this purpose many I/O devices (such as serial ports) use a special
type of address known as an I/O addresses (sometimes called an I/O
port).   It's actually a range of addresses and the lower address in
this range is the base address.  If someone only says (or writes)
"address" it likely really means "base address" 
-->
<p>コンピュータと情報をやりとりするには、どんな I/O デバイスであっても
コンピュータが読み書きできるアドレスが必要です。
この目的のために多くの I/O 
デバイス(シリアルポート等)は I/O アドレスと呼ばれる特殊なアドレスを持っ
ています(I/O ポートと呼ばれることもあります)。これは実際には、あるアド
レスの範囲であり、一番低位のアドレスがベースアドレスになります。単に
「アドレス」と言われた(書かれた)場合は、実際は大抵「ベースアドレス」を
指しています。

<!--
Instead of using I/O, addresses some I/O devices read and write
directly from/to main memory.  This provides more bandwidth since the
conventional serial I/O system only moves a byte at a time.  There are
various ways to read/write directly to main memory.  One way is called
shared memory I/O (where the shared memory is usually on the same card
as the I/O device).  Other methods are DMA (direct memory access) on
the ISA bus and  what is about the same as DMA (only much faster):
"bus mastering" on the PCI bus.  These methods are a lot faster than
those used for the serial port.  Thus the conventional serial port
with its interrupt driven (every 14 bytes) interface and single bytes
transfers on a bus which could accommodate 4 (or 8) bytes at a time is
not suited for very high speed I/O.
-->
一部の I/O デバイスは I/O アドレスを使わないで、直接メインメモリの読
み書きを行います。この方法だと大きな帯域を利用できます。というのも、
昔ながらのシリアル I/O システムでは同時に 1 バイトしか転送できないから
です。
メインメモリを直接読み書きする方法は色々あります。
その一つが共有メモリ I/O と呼ばれるもの
です(共有メモリは普通、I/O デバイスと同じカード上にあります)。他の方法
としては ISA バスの DMA(direct memory access, 直接メモリアクセス)や、
PCI バスでの DMA と同様の仕組み(速度はずっと速い)である
「バスマスタリング」があります。これらの方法は、シリアルポートの方式よ
りもずっと高速です。したがって、(14 バイトごとの)割り込み駆動インタフェー
スを持ち、バス自体が 4(または 8)バイトをまとめて処理できるのに 1 バイ
トずつしか送信できない昔ながらのシリアルポートは、超高速の I/O には向
いていません。

<!--
<sect> Multiport Serial Boards/Cards/Adapters
-->
<sect> マルチポートシリアルボード/カード/アダプタ
<!--
<sect1> Intro to Multiport Serial 
-->
<sect1> マルチポートシリアル入門

<!--
<p> Multiport serial cards install in a slot in a PC on the ISA or PCI
bus.  Instead of being called "... cards" they are also called "...
adapters" or "... boards".  Each such card provides you with many
serial ports.  Today they are commonly used for the control of
external devices (including automation for both industry and the
home).  They can connect to computer servers for the purpose of
monitoring/controlling the server from a remote location.  They were
once mainly used for connecting up many terminals and/or modems to
serial ports.  They are still used this way but a modem used with it
has the same limitation of ordinary modems: It can't send at over
33.6k even if it is a 56k modem.
-->
<p>マルチポートシリアルカードは PC の ISA バスまたは PCI バスのスロッ
トに設置します。「…カード」と呼ぶ代わりに、「…アダプタ」や「…ボード」
と呼ばれることもあります。このようなカードを使うと、シリアルポートをた
くさん使うことができます。今日では、マルチポートシリアルカードは(企業
や家庭における自動化を含めて)外部デバイスの制御に一般的に使われていま
す。マルチポートシリアルカードは、遠隔地からコンピュータサーバを監視/
制御するためにコンピュータサーバに接続できます。
これはかつては主としてたくさんの端末やモデムを
シリアルポートに接続するために使われていました。
こういった使い方もまだされていますが、マルチポートシリアルカードを
モデムと組み合わせて使うと、普通のモデムの場合と同じ制限を受けます。
つまり、モデムが 56K モデムであっても、接続速度は 33.6K を超えることが
できません。

<!--O
Thus if someone dials in to you (reaches your multiport serial card
from a modem plugged into the card) they will not be able to go above
33.6k in either direction, even if they use a 56k modem.  To go above
33.6k for dial-in requires that you have a digital connection to the
telephone line.  The serial port is no longer used for this case.
Thus serial multiport cards are now obsolete for use by ISPs or anyone
that needs to allow others to dial-in to them at 56k (over 33.6k).
See Modem-HOWTO: Modem Pools, Digital Modems.
-->
したがって、誰かがあなたに電話をかけ(そして、カードに挿さったモデムか
らあなたのマルチポートシリアルカードに接続し)た場合、たとえ 56K モデム
を使っていたとしても、どちらの向きの通信速度も 33.6K を超えることはで
きません。ダイアルイン接続で 33.6K を超えるためには、電話線がデジタル
接続になっている必要があります。この場合、シリアルポートはもう関係なく
なります。したがって、マルチポートシリアルカードは今では ISP や
外部から 56K(33.6K 以上で)ダイアルイン接続をさせる必要がある人が使うに
は時代遅れのものになりました。詳しくは Modem-HOWTO の「Modem Pools」と
「Digital Modem」の節を見てください。

<!--O
Each multiport card has a number of external connecters (DB-25 or RJ45
(telephone-like)) so that one may connect up a number of devices
(modems, terminals, etc.).  Each such physical device would then be
connected to its own serial port.  Since the space on the
external-facing part of the card is limited there is often not enough
room for all the serial port connectors.  To solve this problem, the
connectors may be on the ends of cables which come out (externally)
from the card (octopus cable).  These connectors may also be on a
little box which is connected by a cable to the multiport card.
-->
各種マルチポートカードにはたくさんの外部コネクタ(DB-25 または 
(電話線のような)RJ-45)がついており、たくさんのデバイス(モデム、端末
など)を接続できます。それから、こういった物理デバイスはそれぞれ
各自のシリアルポートに接続されます。カードの外に面している部分の面積は
限られているため、全てのシリアルポートコネクタに対して十分な空間が取れ
ないこともよくあります。この問題を解決するために、コネクタはカードから
(外部に)延びているケーブル(タコ足ケーブル)の端に繋がれることがあります。
こういったコネクタはマルチポートカードとケーブルで繋がっている小さな箱
に接続されることもあります。

<!--
Dumb ones are not too much different than ordinary serial ports.  They
are interrupt driven and the CPU of the computer does most all the
work servicing them.  They usually have a system of sharing a single
interrupt for all the ports.  This doesn't decrease the load on the
CPU since the single interrupt will be sent to the CPU each time any
of the ports needs servicing.  Such devices usually require special
drivers that you must put into the kernel or activate by modifying
source code.  
-->
ダムシリアルポートも通常のシリアルポートとあまり変わりません。ダムシリ
アルポートも割り込み駆動であり、このポートにサービスする動作のほとんど
全てはコンピュータの CPU が行います。これには普通、1 つの割り込みを全
てのポートで共有するためのシステムが付いています。だからといって CPU に
かかる負荷が減るわけではありません。なぜなら、いずれかのポートがサービスを
必要とするたびに CPU に割り込みがひとつ送られるからです。こういった
デバイスは通常は特殊なドライバを必要とします。ドライバはカーネルに組
み込むか、ソースコードの修正によって有効にしなければなりません。

<!--
Smart boards may use ordinary UARTs but handle most interrupts from
the UARTs internally within the board.  This frees the CPU from the
burden of handling  all these interrupts.  The board may save up bytes
in its large internal FIFOs and transfer perhaps 1k bytes at a time to
the serial buffer in main memory.  It may use the full bus width of 32
bits for making data transfers to main memory (instead of transferring
only 8-bit bytes like dumb serial cards do).  Not all "smart" boards
are equally efficient.  Many boards today are Plug-and-Play.  
-->
賢いボードは通常の UART を使えますが、UART からの割り込みのほとん
どをボード内で内部的に処理します。これにより、CPU はこういった割り込み
の全てを扱うという負荷を逃れることができます。このボードはバイトデータ
を大きな内部 FIFO に蓄え、一度に 1K バイトくらいのデータをメインメモリ
上のシリアルバッファに転送します。メインメモリへのデータ転送を行う際に
は、(ダムシリアルカードのように 8 ビットのバイトだけを転送するのではな
く)32 ビットのバス幅を全て使うことができます。必ずしも全ての「賢い」
ボードが同じように効率的なわけではありません。現在の多くのボードはプラ
グ&amp;プレイ対応です。

<!--O
For a smart board to work, a special driver for it must be used.
Sometimes this driver is built into the kernel source code or supplied
as a module.  Even in such cases, you must still do something to
activate it.  This includes selecting it when you compile the kernel
(or making sure that a pre-compiled kernel has done this).  The "make
config" or "make menuconf" commands may display an option for this.
In some cases there is a special module to load or certain parameters
to pass to the kernel (via lilo's append command).  The board's
manufacturer should have info on this on their website.
Unfortunately, info for old boards is sometimes not there but might be
found somewhere else on the Internet (including discussion groups).
-->
賢いボードを動かすためには、専用のドライバを使わなければなりません。
このドライバはカーネルのソースコードに組み込まれていたり、モジュールと
して提供されることもあります。こういった場合でも、ドライバを有効にする
には何かしなければなりません。その作業には、カーネルのコンパイル時に
選ぶこと(または、予めコンパイルされているカーネルがそうなっているかど
うかを確かめること)が含まれます。"make config" コマンドか
"make menuconfig" コマンドを使うと、このオプションがどのように設定され
ているかを確かめることができます。場合によっては、特殊なドライバを
ロードしたり、特定のパラメータを(LILO の append コマンドを使って)
カーネルに渡すこともあります。ボードのメーカーは、このような情報を自社
のウェブサイトに載せているはずです。残念ながら、古いボードの情報がない
ことも時々ありますが、その情報はインターネット上の他の場所で見つけられ
るかもしれません(議論用のニュースグループを含みます)。

<!--
<sect1>Making "devices" in the /dev directory
-->
<sect1>/dev ディレクトリでの「デバイス」の作成
<p>
<!--
The serial ports your multiport board uses depends on what kind of board
you have.  Some of these may be listed in detail in <tt>rc.serial</tt>
or in <tt>0setserial</tt>.  These files may be included in a
>setserial or serial package.  I highly recommend getting the latest
version of <tt/setserial/ if you are trying to use multiport boards.
You will probably need to create these devices.  Either use the
<tt/mknod/ command, or the <tt/MAKEDEV/ script.  Devices (in the /dev
directory) for serial ports are made by adding ``64 + port number''.
So, if you wanted to create devices for <tt>ttyS17</tt>, you would
type:
-->
マルチポートボードが使うシリアルポートは、お使いのボードの種類によって
異なります。一部のポートは <tt>rc.serial</tt> や <tt>0setserial</tt> 
に詳しく列挙されているかもしれません。これらのファイルは
setserial パッケージまたは serial パッケージに入っているかもしれません。
筆者としては、読者の皆さ
んがマルチポートボードを使おうとしているのなら、最新バージョンの 
<tt/setserial/ を入手することを強くお勧めします。また多分、これらのデ
バイスを作成する必要があるでしょう。作成には <tt/mknod/ コマンドか
<tt/MAKEDEV/ スクリプトを入手してください。シリアルポート用のデバイス
(/dev ディレクトリにある)は、「64 + ポート番号」の足し算で作れます。
したがって、<tt>ttyS17</tt> 用のデバイスを作成したければ、以下のコマン
ドを実行します:

<tscreen><verb>
linux# mknod -m 666 /dev/ttyS17 c 4 81
</verb></tscreen>
<!--
Note the "major" number is always 4 for ttyS devices (and 5 for the
obsolete cua devices).  Also ``64 + 17 = 81''.  Using the <tt/MAKEDEV/
script, you would type:
-->
ttyS デバイスの「メジャー」番号は必ず 4 である点(そして、5 は時代遅れ
の cua デバイスの番号である点)に注意してください。
また「64 + 17 = 81」にも注意してください。
<tt/MAKEDEV/ スクリプトを使う場合には以下のコマンドを実行します:
<tscreen><verb>
linux# cd /dev
linux# ./MAKEDEV ttyS17
</verb></tscreen>

<!--
Besides the listing of various brands of multiports found in this
HOWTO there is <url
url="http://members.aa.net/~swear/serialcards.html" name="Gary's
Encyclopedia - Serial Cards">.  It's not as complete, but may have
some different links.
-->
本 HOWTO に書かれているマルチポート製品の一覧以外にも、
<url url="http://members.aa.net/~swear/serialcards.html" name="Gary's
Encyclopedia - Serial Cards"> という WWW ページがあります。これは完全
ではありませんが、他へのリンクもいくつかあります。

<!--
<sect1>Standard PC Serial Cards
-->
<sect1>PC 標準のシリアルカード
<!--O
<p> In olden days PCs used to come with a serial card installed.
Later on the serial function was put on the hard-drive interface card.
Today one or two serial ports are usually built into the motherboard.
But one may still buy the old PC serial cards if they need 1-4 more
serial ports.  These are for ttyS0-ttyS3 (COM1 - COM4).  They can be
used to connect external serial devices (modems, serial mice, etc...).
Only a tiny percentage of retail computer stores carry such cards.
But one can purchase them on the Internet.  Before getting a PCI one,
make sure Linux supports it.
-->
<p> 昔は PC にはシリアルカードが独立して挿さっていました。少し前は
シリアル機能はハードディスクのインタフェースカードに組み込まれていまし
た。現在は、普通は一つまたは二つのシリアルポートがマザーボードに組み込
まれています。しかし、追加のシリアルポートが 1 つから 4 つ必要な場合は
今でも PC 用の旧式のシリアルカードを買えるでしょう。これらは
ttyS0-ttyS3 (COM1 - COM4)として使います。これらを使って外付けシリアル
デバイス(モデム、シリアルマウス等)を接続できます。
小売のコンピュータショップでこういったカードを扱っているのはごく一部だ
けです。しかし、インターネットを通じて購入することもできます。PCI の
シリアルカードを買う前には、Linux が対応していることを確かめましょう。

<!--O
Here's a list of a few popular brands:
-->
有名なブランドをいくつか紹介します:
<itemize>
<!--O
<item>Byte Runner (may order directly, shows prices) <url
 url="http://www.byterunner.com">
-->
<item>Byte Runner (直接注文できます。価格も表示されています) <url
 url="http://www.byterunner.com">
<item> SIIG <url url="http://www.siig.com/io"> 
<item> Dolphin <url url="http://www.dolphinfast.com/sersol/">
</itemize>
<p>
<!--
Note: due to address conflicts, you may not be able to use COM4 and
IBM8514 video card (or some others) simultaneously.  See <ref
id="8514_" name="Avoiding IO Address Conflicts with Certain Video
Boards">
-->
注意: アドレスが衝突するため、COM4 と IBM8514 ビデオカード(など)は同時
に使えないかもしれません。
<ref id="8514_" name="特定のビデオボードでの I/O アドレスの衝突を避ける方法">
をご覧ください。

<!--
<sect1>Dumb Multiport Serial Boards (with standard UART chips) 
-->
<sect1>ダムマルチポートシリアルボード (標準の UART チップが載っているもの)
<!--
<p> They are also called "serial adapters".  They often have a
special method of sharing interrupts which requires that you compile
support for them into the kernel.<newline>

* =>  The file that ran setserial in Debian shows some details of configuring
# => See note below for this board
-->
<p>以下のボードは「シリアルアダプタ」とも呼ばれます。これらのカードは、
対応機能をカーネルにコンパイルして組み込む必要がある特殊な方法を使って
割り込みを共有していることがよくあります。<newline>

* =>  Debian では setserial を実行するファイルが、詳細な設定を表示します。
# => このボードについては後述の注を見ること
<itemize>
<!--
<item>AST FourPort and clones (4 ports) * #
-->
<item>AST FourPort およびその互換カード (4 ポート) * #
<!--
<item>Accent Async-4 (4 ports) *
-->
<item>Accent Async-4 (4 ポート) *
<!--
<item>Arnet Multiport-8 (8 ports)
-->
<item>Arnet Multiport-8 (8 ポート)
<!--
<item>Bell Technologies HUB6 (6 ports)
-->
<item>Bell Technologies HUB6 (6 ポート)
<!--
<item>Boca BB-1004 (4 ports), BB-1008 (8 ports), BB-2016 (16 ports;
 See the mini-howto) * #
-->
<item>Boca BB-1004 (4 ポート), BB-1008 (8 ポート), BB-2016 (16 ポート;
 mini-howto 文書があります) * #
<!--
<item>Boca IOAT66 or? ATIO66 (6 ports, Linux doesn't support its IRQ
 sharing ??  Uses odd-ball 10-cond RJ45-like connectors)
-->
<item>Boca IOAT66 あるいは? ATIO66 (6 ポート、確かめていませんが Linux 
では IRQ 共有に対応していません。RJ45 に似た、特殊な 10-ピンコネクタを
使います)
<!--
<item>Boca 2by4 (4 serial ports, 2 parallel ports)
-->
<item>Boca 2by4 (4 シリアルポート、2 パラレルポート)
<!--
<item>Byte Runner <url url="http://www.byterunner.com">
-->
<item>Byte Runner <url url="http://www.byterunner.com">
<!--
<item>Computone ValuePort V4-ISA (AST FourPort compatible) *
-->
<item>Computone ValuePort V4-ISA (AST FourPort 互換) *
<!--
<item>Digi PC/8 (8 ports) #
-->
<item>Digi PC/8 (8 ポート) #
<item>Dolphin <url url="http://www.dolphinfast.com/sersol/">
<item>Globetek <url url="http://www.globetek.com/">
<!--
<item>GTEK BBS-550 (8 ports; See the mini-howto)
-->
<item>GTEK BBS-550 (8 ポート; mini-howto 文書があります)
<!--
<item>Hayes ESP (after kernel 2.1.15)
-->
<item>Hayes ESP (カーネル 2.1.15 以降)
<!--
<item>HUB-6 See Bell Technologies.
-->
<item>HUB-6 (Bell Technologies に問い合わせてください)
<!--
<item>Longshine LCS-8880, Longshine LCS-8880+ (AST FourPort compatible) *
-->
<item>Longshine LCS-8880, Longshine LCS-8880+ (AST FourPort 互換) *
<!--
<item>Moxa C104, Moxa C104+ (AST FourPort compatible) *
-->
<item>Moxa C104, Moxa C104+ (AST FourPort 互換) *
<!--
<item><url
url="http://digital.natinst.com/manuals.nsf/web%2Fbyproductcurrent?OpenView&amp;Start=1&amp;Count=500&amp;Expand=15.1#15.1" name="NI-SERIAL"> by National Instruments
-->
<item><url
url="http://digital.natinst.com/manuals.nsf/web%2Fbyproductcurrent?OpenView&amp;Start=1&amp;Count=500&amp;Expand=15.1#15.1" name="NI-SERIAL">, National Instruments 製
<!--
<item>PC-COMM (4 ports) <item><url url="http://www.sealevel.com" 
  name="Sealevel Systems">
 COMM-2 (2 ports), COMM-4 (4 ports) and COMM-8 (8 ports)
-->
<item>PC-COMM (4 ポート)
<item><url url="http://www.sealevel.com" name="Sealevel Systems">
 COMM-2 (2 ポート), COMM-4 (4 ポート), COMM-8 (8 ポート)
<!--
<item>SIIG I/O Expander 2S IO1812 (4 ports) #
-->
<item>SIIG I/O Expander 2S IO1812 (4 ポート) #
<!--
<item>STB-4COM (4 ports)
-->
<item>STB-4COM (4 ポート)
<!--
<item>Twincom ACI/550
-->
<item>Twincom ACI/550
<!--
<item>Usenet Serial Board II (4 ports) *
-->
<item>Usenet Serial Board II (4 ポート) *
</itemize>
<p>
<!--
In general, Linux will support any serial board which uses a 8250, 
16450, 16550, 16550A, 16650, etc. UART.  See the latest man page for
"setserial" for a more complete list.
-->
一般的には、Linux は 8250, 16450, 16550, 16550A, 16650 などの UART を
使っている全てのボードに対応しています。もっと詳しいリストについては、
"setserial" の最新のマニュアルページを参照してください。

<!--
Notes:
-->
注:

<!--
AST Fourport: You might need to specify <tt/skip_test/ in <tt/rc.serial/.
-->
AST Fourport: <tt/rc.serial/ で <tt/skip_test/ を指定する必要があるか
もしれません。

<!--
BB-1004 and BB-1008 do not support DCD and RI lines, and thus are not
usable for dialin modems.  They will work fine for all other purposes.
-->
BB-1004 と BB-1008 は DCD, RI ラインをサポートしておらず、そのためダイ
アルイン用のモデムには使えません。他の目的では問題なく動作します。

<!--
Digi PC/8 Interrupt Status Register is at 0x140.
-->
Digi PC/8 の割り込み状態レジスタの位置は 0x140 です。

<!--
SIIG IO1812 manual for the listing for COM5-COM8 is
wrong.  They should be COM5=0x250, COM6=0x258, COM7=0x260, and
COM8=0x268.
-->
SIIG IO1812 のマニュアルに書かれている COM5 から COM8 のリストは誤って
います。正しくは COM5=0x250, COM6=0x258, COM7=0x260, COM8=0x268 のはず
です。

<!--
<sect1>Intelligent Multiport Serial Boards
-->
<sect1>インテリジェントマルチポートシリアルボード
<p>
<!--
Make sure that a Linux-compatible driver is available and read the
information that comes with it.  These boards use special devices (in
the /dev directory), and not the standard ones.  This information
varies depending on your hardware.  If you have updated info which
should be shown here please email it to me.
-->
Linux 互換のドライバが使えることを確かめ、ドライバ付属の情報を読んで
ください。これらのカードは、標準のデバイスでなく特殊なデバイス(/dev ディ
レクトリにある)を使います。この情報はハードウェアごとに異なります。こ
の文書に載せるべき新しい情報があれば、ぜひ筆者にメールを送ってください。

<!--O
Names of Linux driver modules are *.o but these may not work for all
models shown.  Also, parameters (such as the io and irq often need to
be given to the module so you need to find instructions on this
(possibly in the source code tree).  
-->
Linux のドライバモジュールの名前は *.o ですが、これらは全てのモデルで
正しく動作するとは限りません。また、(I/O アドレスや IRQ 等の)パラメータ
をモジュールに与える必要があることも多いので、それに関する説明を見つけ
る必要もあります(ソースコードツリーの中にあるかもしれません)。

<!--O
There are many different brands, each of which often offers many
different cards.  No attempt is currently being made to list the cards
here (and many listed may be obsolete).  So this list is a hodgepodge
of both obsolete and the latest multiport brands/cards.   Contact
information has been removed if it's available from the webpage.
Driver information should also be available from the same webpage.
Where there is no webpage, the cards are likely obsolete.  If you
would like to put together a more complete list, let me know.
-->
マルチポートカードのブランドはたくさんあり、それぞれから色々な種類のカー
ドがよく出されます。
今のところ、これらのカードをここで網羅しようとはしていません(また挙げ
ているものの多くは時代遅れになっているかもしれません)。
したがって、このリストはマルチポートカードやそ
のブランドについて古いものと新しいものがごっちゃになっています。
ウェブページから分かる場合には連絡先は削除しました。
ドライバに関する情報も同じウェブページで見つかるはずです。
ウェブページを紹介していない場合、そのカードはたぶん古いと思います。
リストをよりよくするために情報を追加したいと思う方は、筆者にお知らせく
ださい。

<itemize>
<!--O
<item>Chase Research (UK based, ISA/PCI cards)<newline>
webpage: <tt><url url="www.chaser.com"></tt><newline>
driver status: for 2.2 kernel.  Supported by Chase.
-->
<item>Chase Research (UK ベース、ISA/PCI カード)<newline>
ウェブページ: <tt><url url="http://www.chaser.com"></tt><newline>
ドライバのステータス: 2.2 カーネル用。Chase がサポートしています。

<!--O
<item>Comtrol RocketPort (36MHz ASIC; 4, 8, 16, 32, up to 128 ports)<newline>
 webpage: <tt><htmlurl url="http://www.comtrol.com" 
 name="http://www.comtrol.com"></tt><newline> 
 driver status: supported by Comtrol.  rocket.o<newline>
        driver location: <tt><htmlurl 
 url="ftp://tsx-11.mit.edu/pub/linux/packages/comtrol"
 name="ftp://tsx-11.mit.edu/pub/linux/packages/comtrol"></tt>
-->

<item>Comtrol RocketPort (36MHz ASIC; 4, 8, 16, 32 ポート、128 ポートまで)<newline>
 ウェブページ: <tt><htmlurl url="http://www.comtrol.com" 
 name="http://www.comtrol.com"></tt><newline> 
 ドライバのステータス: Comtrol 社がサポートしています(rocket.o)。<newline>
        ドライバの入手先: <tt><htmlurl 
 url="ftp://tsx-11.mit.edu/pub/linux/packages/comtrol"
 name="ftp://tsx-11.mit.edu/pub/linux/packages/comtrol"></tt>

<!--
<item>Computone IntelliPort II (ISA, PCI and EISA busses up to 64 
 ports)<newline>
 webpage: <url url="http://www.computone.com"><newline>
 driver location:
  <url url="ftp://ftp.computone.com/PUB/Products/IntelliPortII/Linux/">,
 patch at <url 
  url="http://www.wittsend.com/computone/linux-2.2.10-ctone.patch.gz"><newline>
 mailing list: <url url="mailto:majordomo@lazuli.wittsend.com"> with 
  "subscribe linux-computone" in body<newline>
 note: Old ATvantage and Intelliport cards are not supported by Computone
-->
<item>Computone IntelliPort II (ISA, PCI, EISA バス用。64 ポートまで)<newline>
 ウェブページ: <url url="http://www.computone.com"><newline>
 ドライバの入手先: <url url="ftp://ftp.computone.com/PUB/Products/IntelliPortII/Linux/">,
 パッチは <url 
  url="http://www.wittsend.com/computone/linux-2.2.10-ctone.patch.gz">
 にあります。<newline>
  メーリングリスト: 本文に "subscribe linux-computone" と書いたメール
を <url url="mailto:majordomo@lazuli.wittsend.com"> に送ります。
 注意: Computone は、古い ATvantage カードや IntelliPort カードをサポー
トしていません。

<!--O
<item> Connecttech<newline>
 website: <tt><url url="http://www.connecttech.com/porducts/products.html"></tt><newline>
 driver location: <url url="ftp://ftp.connecttech.com/pub/linux/">
--> 
<item> Connecttech<newline>
 ウェブサイト: <tt><url url="http://www.connecttech.com/porducts/products.html"></tt><newline>
 ドライバの入手先: <url url="ftp://ftp.connecttech.com/pub/linux/">

<!--
<item>Cyclades<newline> 
 Cyclom-Y (Cirrus Logic CD1400 UARTs; 8 - 32 ports),<newline>
 Cyclom-Z (MIPS R3000; 8 - 64 ports)<newline>
 website: <tt><url url="http://www.cyclades.com/products.html"></tt><newline>
 driver status: supported by Cyclades<newline>
 driver location: <tt><htmlurl url="ftp://ftp.cyclades.com/pub/cyclades"
 name="ftp://ftp.cyclades.com/pub/cyclades"></tt> and included in Linux 
 kernel since version 1.1.75: cyclades.o
-->
<item>Cyclades<newline> 
 Cyclom-Y (Cirrus Logic CD1400 UART; 8 - 32 ポート),<newline>
 Cyclom-Z (MIPS R3000; 8 - 64 ポート)<newline>
 ウェブサイト: <tt><url url="http://www.cyclades.com/products.html"></tt><newline>
 ドライバのステータス: Cyclades がサポートしています。<newline>
 ドライバの入手先: <tt><htmlurl url="ftp://ftp.cyclades.com/pub/cyclades"
 name="ftp://ftp.cyclades.com/pub/cyclades"></tt>。また、バージョン 
 1.1.75 以降の Linux カーネルに含まれています: cyclades.o

<!--
<item>Decision PCCOM8 (8 ports)<newline>
 contact: <tt><url url="mailto:info@cendio.se"></tt><newline>
 website: none (defunct)
 driver location: <tt><htmlurl url="ftp://ftp.signum.se/pub/pccom8"
 name="ftp://ftp.signum.se/pub/pccom8"></tt>
-->
<item>Decision PCCOM8 (8 ポート)<newline>
 連絡先: <tt><url url="mailto:info@cendio.se"></tt><newline>
 ウェブサイト: なし(消滅)
 ドライバの入手先: <tt><htmlurl url="ftp://ftp.signum.se/pub/pccom8"
 name="ftp://ftp.signum.se/pub/pccom8"></tt>

<!--
<item>Digi PC/Xi (12.5MHz 80186; 4, 8, or 16 ports),<newline>
 PC/Xe (12.5/16MHz 80186; 2, 4, or 8 ports),<newline>
 PC/Xr (16MHz IDT3041; 4 or 8 ports),<newline>
 PC/Xem (20MHz IDT3051; 8 - 64 ports)<newline>
 website: <tt><url url="http://www.dgii.com"></tt><newline>
 driver status: supported by Digi<newline>
 driver location: <tt><htmlurl 
 url="ftp://ftp.dgii.com/drivers/linux"
 name="ftp://ftp.dgii.com/drivers/linux"></tt> and 
 included in Linux kernel since version 2.0. epca.o
-->
<item>Digi PC/Xi (12.5MHz 80186; 4, 8, 16 ポート),<newline>
 PC/Xe (12.5/16MHz 80186; 2, 4, 8 ポート),<newline>
 PC/Xr (16MHz IDT3041; 4, 8 ポート),<newline>
 PC/Xem (20MHz IDT3051; 8 - 64 ポート)<newline>
 ウェブサイト: <tt><url url="http://www.dgii.com"></tt><newline>
 ドライバのステータス: Digi 社がサポートしています。<newline>
 ドライバの入手先: <tt><htmlurl 
 url="ftp://ftp.dgii.com/drivers/linux"
 name="ftp://ftp.dgii.com/drivers/linux"></tt> でも入手できますし、バー
ジョン 2.0 以降のカーネルにはドライバが含まれています(epca.o)。

<!--
<item>Digi COM/Xi (10MHz 80188; 4 or 8 ports)<newline>
 contact: Simon Park, <tt><htmlurl url="mailto:si@wimpol.demon.co.uk"
 name="si@wimpol.demon.co.uk"></tt><newline>
 driver status: ?<newline>
 note: Simon is often away from email for months at a time due to
 his job.  Mark Hatle, <url url="mailto:fray@krypton.mankato.msus.edu">
 has graciously volunteered to make the driver available if you need
 it.  Mark is not maintaining or supporting the driver.
-->
<item>Digi COM/Xi (10MHz 80188; 4, 8 ポート)<newline>
 連絡先: Simon Park さん, <tt><htmlurl url="mailto:si@wimpol.demon.co.uk"
 name="si@wimpol.demon.co.uk"></tt><newline>
 ドライバのステータス: 不明。<newline>
 注意: Simon さんは仕事のため、何ヵ月も続けて電子メールが使えなくなることが
よくあります。 Mark Hatle さん(
<url url="mailto:fray@krypton.mankato.msus.edu">
)のご厚意により、ドライバが必要ならば入手できるようになっています。
Mark さんはドライバのメンテナンスやサポートは行いません。

<!--
<item>Equinox SuperSerial Technology (30MHz ASIC; 2 - 128 ports)<newline>
 website: <tt><htmlurl url="http://www.equinox.com"
 name="http://www.equinox.com"></tt><newline>
 driver status: supported by Equinox<newline>
 driver location: <tt><htmlurl 
 url="ftp://ftp.equinox.com/library/sst" 
 name="ftp://ftp.equinox.com/library/sst"></tt>
-->
<item>Equinox SuperSerial Technology (30MHz ASIC; 2 - 128 ポート)<newline>
 ウェブサイト: <tt><htmlurl url="http://www.equinox.com"
 name="http://www.equinox.com"></tt><newline>
 ドライバのステータス: Equinox 社がサポートしています。<newline>
 ドライバの入手先: <tt><htmlurl 
 url="ftp://ftp.equinox.com/library/sst" 
 name="ftp://ftp.equinox.com/library/sst"></tt>

<!--O
<item>Globetek<newline>
 website: <url url="http://www.globetek.com/products.shtml"><newline>
 driver location: <url url="http://www.globetek.com/media/files/linux.tar.gz">
-->
<item>Globetek<newline>
 ウェブサイト: <url url="http://www.globetek.com/products.shtml"><newline>
 ドライバの入手先: <url url="http://www.globetek.com/media/files/linux.tar.gz">

<!--
<item>GTEK Cyclone (16C654 UARTs; 6, 16 and 32 ports),<newline>
 SmartCard (24MHz Dallas DS80C320; 8 ports),<newline>
 BlackBoard-8A (16C654 UARTs; 8 ports),<newline>
 PCSS (15/24MHz 8032; 8 ports)<newline>
 website: <tt><htmlurl url="http://www.gtek.com" name="http://www.gtek.com">
 </tt><newline>
 driver status: supported by GTEK<newline>
 driver location: <tt><htmlurl url="ftp://ftp.gtek.com/pub" 
 name="ftp://ftp.gtek.com/pub"></tt>
-->
<item>GTEK Cyclone (16C654 UART; 6, 16, 32 ポート),<newline>
 SmartCard (24MHz Dallas DS80C320; 8 ポート),<newline>
 BlackBoard-8A (16C654 UART; 8 ポート),<newline>
 PCSS (15/24MHz 8032; 8 ポート)<newline>
 ウェブサイト: <tt><htmlurl url="http://www.gtek.com" name="http://www.gtek.com">
 </tt><newline>
 ドライバのステータス: GTEK 社がサポートしています。<newline>
 ドライバの入手先: <tt><htmlurl url="ftp://ftp.gtek.com/pub" 
 name="ftp://ftp.gtek.com/pub"></tt>

<!--
<item>Hayes ESP (COM-bic; 1 - 8 ports)<newline> 
 website: <tt><htmlurl url="http://www.nyx.net/&tilde;arobinso"
 name="http://www.nyx.net/&tilde;arobinso"></tt><newline>
 driver status: Supported by Linux kernel (1998) since v. 2.1.15.
 esp.o.  Setserial 2.15+ supports. Also supported by author<newline> 
 driver location: <tt><htmlurl url="http://www.nyx.net/&tilde;arobinso"
 name="http://www.nyx.net/&tilde;arobinso"></tt> 
-->
<item>Hayes ESP (COM-bic; 1 - 8 ポート)<newline> 
 ウェブサイト: <tt><htmlurl url="http://www.nyx.net/&tilde;arobinso"
 name="http://www.nyx.net/&tilde;arobinso"></tt><newline>
 ドライバのステータス: バージョン 2.1.15 (1998年)以降の Linux カーネル
 は対応しています(esp.o)。setserial 2.15 以降も対応しています。
 作者もサポートしています。<newline> 
 ドライバの入手先: <tt><htmlurl url="http://www.nyx.net/&tilde;arobinso"
 name="http://www.nyx.net/&tilde;arobinso"></tt> 

<!--O
<item>Intelligent Serial Interface by Multi-Tech Systems<newline>
 PCI: 4 or 8 port.  ISA 8 port. DTE speed 460.8k<newline>
 webpage: <url url="http://www.multitech.com/products/">
-->
<item>Multi-Tech Systems 製のインテリジェントシリアルインタフェース<newline>
 PCI 版は 4 または 8 ポート。 ISA 版は 8 ポート。DTE 速度は 460.8K。<newline>
 ウェブページ: <url url="http://www.multitech.com/products/">

<!--
<item>Maxpeed SS (Toshiba; 4, 8 and 16 ports)<newline>
 website: <tt><htmlurl url="http://www.maxpeed.com" 
 name="http://www.maxpeed.com"></tt><newline>
 driver status: supported by Maxpeed<newline>
 driver location: <tt><htmlurl url="ftp://maxpeed.com/pub/ss" 
 name="ftp://maxpeed.com/pub/ss"></tt>
-->
<item>Maxpeed SS (Toshiba; 4, 8, 16 ポート)<newline>
 ウェブサイト: <tt><htmlurl url="http://www.maxpeed.com" 
 name="http://www.maxpeed.com"></tt><newline>
 ドライバのステータス: Maxpeed 社がサポートしています。<newline>
 ドライバの入手先: <tt><htmlurl url="ftp://maxpeed.com/pub/ss" 
 name="ftp://maxpeed.com/pub/ss"></tt>

<!--O
<item> Microgate SyncLink ISA and PCI high speed multiprotocol
 serial.  Intended for synchronous HDLC.<newline>
 website: <url
 url="http://www.microgate.com/products/sllinux/hdlcapi.htm"><newline>
 driver status: supported by Microgate: synclink.o
-->
<item> Microgate SyncLink ISA/PCI 高速マルチプロトコルシリアルカード。
 同期 HDLC 用です。<newline>
 ウェブサイト: <url
 url="http://www.microgate.com/products/sllinux/hdlcapi.htm"><newline>
 ドライバのステータス: Microgate 社がサポートしています(synclink.o)。

<!--
<item>Moxa C218 (12MHz 80286; 8 ports),<newline> 
 Moxa C320 (40MHz TMS320; 8 - 32 ports)<newline>
 website: <tt><htmlurl url="http://www.moxa.com"
 name="http://www.moxa.com"></tt><newline>
 driver status: supported by Moxa<newline>
 driver locations: <tt><url 
 url="http://www.moxa.com/support/download/download.php3>"></tt>
 <tt><url url="ftp://ftp.moxa.com/drivers/linux" ></tt>
 (also from Taiwan at www.moxa.com.tw/...) where ... is the same as
 above)
-->
<item>Moxa C218 (12MHz 80286; 8 ポート),<newline> 
 Moxa C320 (40MHz TMS320; 8 - 32 ポート)<newline>
 ウェブサイト: <tt><htmlurl url="http://www.moxa.com"
 name="http://www.moxa.com"></tt><newline>
 ドライバのステータス: Moxa 社がサポートしています。<newline>
 ドライバの入手先: <tt><url 
 url="http://www.moxa.com/support/download/download.php3>"></tt>
 <tt><url url="ftp://ftp.moxa.com/drivers/linux" ></tt>
 (台湾からは www.moxa.com.tw/... も使えます。「...」の部分は上記と同じです。)

<!--
<item>SDL RISCom/8 (Cirrus Logic CD180; 8 ports)<newline>
 website: <tt><htmlurl url="http://www.sdlcomm.com" 
 name="http://www.sdlcomm.com"></tt><newline>
 driver status: supported by SDL<newline>
 driver location: <tt><htmlurl url="ftp://ftp.sdlcomm.com/pub/drivers"
 name="ftp://ftp.sdlcomm.com/pub/drivers"</tt>
-->
<item>SDL RISCom/8 (Cirrus Logic CD180; 8 ポート)<newline>
 ウェブサイト: <tt><htmlurl url="http://www.sdlcomm.com" 
 name="http://www.sdlcomm.com"></tt><newline>
 ドライバのステータス: SDL 社がサポートしています。<newline>
 ドライバの入手先: <tt><htmlurl url="ftp://ftp.sdlcomm.com/pub/drivers"
 name="ftp://ftp.sdlcomm.com/pub/drivers"</tt>

<!--
<item> Specialix SX (25MHz T225; 8? - 32 ports),<newline>
 SIO/XIO (20 MHz Zilog Z280; 4 - 32 ports)<newline>
 webpage: <url url="www.specialix.com/products/io/serialio.htm"><newline>
 driver status: Supported by Specialix<newline>
 driver location: <url url="http://www.BitWizard.nl/specialix/"><newline>
 old driver location: <url 
 url="ftp://metalab.unc.edu/pub/Linux/kernel/patches/serial">
-->
<item> Specialix SX (25MHz T225; 8? - 32 ポート),<newline>
 SIO/XIO (20 MHz Zilog Z280; 4 - 32 ポート)<newline>
 ウェブページ: <url url="http://www.specialix.com/products/io/serialio.htm"><newline>
 ドライバのステータス: Specialix 社がサポートしています。<newline>
 ドライバの入手先: <url url="http://www.BitWizard.nl/specialix/"><newline>
 古いドライバの入手先: <url 
 url="ftp://metalab.unc.edu/pub/Linux/kernel/patches/serial">

<!--
<item>Stallion EasyIO-4 (4 ports), EasyIO-8 (8 ports), and<newline>
 EasyConnection (8 - 32 ports) - each with 
 Cirrus Logic CD1400 UARTs,<newline>
 Stallion (8MHz 80186 CPU; 8 or 16 ports),<newline>
 Brumby (10/12 MHz 80186 CPU; 4, 8 or 16 ports),<newline>
 ONboard (16MHz 80186 CPU; 4, 8, 12, 16 or 32 ports),<newline>
 EasyConnection 8/64 (25MHz 80186 CPU; 8 - 64 ports)<newline>
 contact: <tt><htmlurl url="mailto:sales@stallion.com"
 name="sales@stallion.com"></tt> or
 <tt><htmlurl url="http://www.stallion.com" 
 name="http://www.stallion.com"></tt><newline>
 driver status: supported by Stallion<newline>
 driver location: <tt><htmlurl
 url="ftp://ftp.stallion.com/drivers/ata5/Linux"
 name="ftp://ftp.stallion.com/drivers/ata5/Linux"></tt> and
 included in linux kernel since 1.3.27
-->
<item>Stallion EasyIO-4 (4 ポート), EasyIO-8 (8 ポート),<newline>
 EasyConnection (8 - 32 ポート) - これらには
 Cirrus Logic CD1400 UART が載っています。<newline>
 Stallion (8MHz 80186 CPU; 8, 16 ポート),<newline>
 Brumby (10/12 MHz 80186 CPU; 4, 8, 16 ポート),<newline>
 ONboard (16MHz 80186 CPU; 4, 8, 12, 16, 32 ポート),<newline>
 EasyConnection 8/64 (25MHz 80186 CPU; 8 - 64 ポート)<newline>
 連絡先: <tt><htmlurl url="mailto:sales@stallion.com"
 name="sales@stallion.com"></tt> または
 <tt><htmlurl url="http://www.stallion.com" 
 name="http://www.stallion.com"></tt><newline>
 ドライバのステータス: Stallion 社がサポートしています。<newline>
 ドライバの入手先: <tt><htmlurl
 url="ftp://ftp.stallion.com/drivers/ata5/Linux"
 name="ftp://ftp.stallion.com/drivers/ata5/Linux"></tt> から入手できま
す。また、バージョン 1.3.27 以降の Linux カーネルに含まれています。

<!--O
 <item>System Base
 website: <url url="http://www.sysbas.com/">
-->
 <item>System Base
 ウェブサイト: <url url="http://www.sysbas.com/">
</itemize>		 

<p>
<!--
A review of Comtrol, Cyclades, Digi, and Stallion products was printed 
in the June 1995 issue of the <EM/Linux Journal/.  The article is 
available at <tt><htmlurl url="http://www.ssc.com/lj/issue14" 
name="http://www.ssc.com/lj/issue14"></tt>. 
-->
Comtrol 社, Cyclades 社, Digi 社, Stallion 社の製品のレビューが
<EM/Linux Journal/ 誌の 1995 年 6 月号に掲載されています。この記事は
<tt><htmlurl url="http://www.ssc.com/lj/issue14" 
name="http://www.ssc.com/lj/issue14"></tt> で読むことができます。

<!--O
<sect1> Unsupported Multiport Boards
-->
<sect1> 未対応のマルチポートボード
<!--O
<p> The following boards don't mention any Linux support as of 1 Jan.
2000.  Let me know if this changes.
-->
<p>2000 年 1 月 1 日現在、以下のボードは Linux でのサポートが
全く謳われていません。状況が変化していたらお知らせください。
<itemize>
<!--O
<item> Aurora (PCI only) <url url="www.auroratech.com">
-->
<item> Aurora (PCI 版のみ) <url url="http://www.auroratech.com">
</itemize>

<!--
<sect>Configuring the Serial Port
-->
<sect>シリアルポートの設定
<!-- configure.H begin
<sect>Configuring the Serial Port  -->

<!--
<sect1> PCI Bus Support Underway <label id="PCI_">
-->
<sect1> PCI バスへの対応は進行中です <label id="PCI_">
<!--
<p> The kernel 2.2 serial driver contains no special support for the
PCI bus.  But kernels 2.3 and 2.4 will eventually support some PCI
serial cards (and modem cards).  Many PCI cards need special support
in the driver.  The driver will read the id number digitally stored on
the card to determine how (or if) to support the card.  If you have a
PCI card which you are convinced is not a winmodem but it will not
work, you can help in attempting to create a driver for it.  To do
this you'll need to contact the maintainer of the serial driver,
Theodore (Ted) Y. Ts'o.  But first check out the modem list site <url
url="http://www.o2.net/~gromitkc/winmodem.html"> for the latest info
on PCI modems and related topic.
-->
<p>カーネル 2.2 のシリアルドライバは PCI バスへの特別な対応は入ってい
ません。
しかし、カーネル 2.3 と 2.4 では、ついに一部の PCI シリアルカード(およ
びモデムカード)に対応します。多くの PCI
カードは、ドライバによる特殊なサポートが必要です。ドライバはカードに
デジタル的に格納されている ID を読み込み、そのカードにどうやって対応す
るか(あるいはサポートするかどうか)を決めます。確実に Windows モデムで
はないにもかかわらず動作しない PCI カードをお持ちであれば、そのカード
用のドライバを作る手助けができます。これを行うには、シリアルドライバの
メンテナである Theodore (Ted) Y. Ts'o さんに連絡する必要があります。
しかし、まずは Windows モデムの一覧のサイト
<url url="http://www.o2.net/~gromitkc/winmodem.html"> 
を見て、PCI モデムとそれに関連する話題の最新情報を調べてください。

<!--O
You will need to email Ted Ts'o a copy of the output of "lspci -vv"
with full information about the model and manufacturer of the PCI
modem (or serial port).  Then he will try to point you to a test
driver which might work for it.  You will then need to get it, compile
it and possibly recompile your kernel.  Then you will test the driver
to see if it works OK for you and report the results to Ted Ts'o.  If
you are willing to do all the above (and this is the latest version of
this HOWTO) then email the needed info to him at: <url
url="mailto:tytso@mit.edu">.
-->
また、Ted Ts'o には "lspci -vv" の出力のコピーと PCI モデム(または
シリアルポート)のモデルとメーカーに関する詳しい情報を電子メールで送る
必要があります。
そうすれば、彼は動作するかもしれないテスト用ドライバの場所をできる
だけ教えてくれるでしょう。次に、このドライバを入手してコンパイルします。
カーネルも多分再コンパイルすることになるでしょう。そして、このドライバ
をテストしてうまく動作するかどうかを調べ、その結果を Ted Ts'o に報告し
ます。上記の手順全てをちゃんと行うつもりがあるなら(そしてこの文書が最
新版なら)、彼に必要な情報を送ってください。
メールアドレスは <url url="mailto:tytso@mit.edu"> です。

<!--
PCI modems are not well standardized.  Some use main memory for
communication with the PC.  It you see 8-digit hexadecimal addresses
it's not likely to work with Linux.  Some require special enabling of
the IRQ.  The output of "lspci" can help determine if one can be
supported.  If you see a 4-digit IO port and no long memory address,
the modem might work by just telling "setserial" the IO port and the
IRQ.  Some people have gotten a 3COM 3CP5610 PCI Modem to work that
way.  

PCI modems are not well standardized.  Some use main memory for I/O
with the PC (ISA ones use the I/O address space for this).  Some
require special enabling of
the IRQ.  The output of "lspci" can help determine if one can be
supported.  If the details are not too complex I may find them and put them here in a future revision.
-->
PCI モデムはあまり標準化されていません。一部のカードは PC との通信に
メインメモリを使います。8 桁の 16 進アドレスが表示されたら、そのカード
はおそらく Linux では使えないでしょう。
一部のカードは、特殊な方法を使わないと IRQ が有効になりません。"lspci" 
の出力を見れば、カードがサポートされているかどうかを調べる役に立つでしょ
う。4 桁の I/O ポートが表示され、長いメモリアドレスが表示されなければ、
そのモデムは "setserial" で I/O ポートと IRQ を設定するだけで動作する
と思います。この方法で 3COM 3CP5610 PCI モデムを動かすのに成功した人も
います。

<!--
<sect1> Configuring Overview <label id="irq_io_conf">
-->
<sect1>設定の概要 <label id="irq_io_conf">
<!--
<p> In many cases, configuring will happen automatically and you have
nothing to do.  But sometimes you need to configure (or just want to
check out the configuration).  If so, first you need to know about the
two parts to configuring the serial port under Linux:
-->
<p> 多くの場合、設定は自動的に行われるので、ユーザがすることは何もあり
ません。しかし場合によっては設定を行う必要があります(あるいは単に設定
を確かめるだけのこともあるでしょう)。こういった場合に最初にすべきこと
は、Linux におけるシリアルポートの設定の 2 つの部分を知ることです。

<!--
The first part (low-level configuring) is assigning it an IO address,
IRQ, and name (such as ttyS2).  This IO-IRQ pair must be set in both
the hardware and told to the serial driver.  We might just call this
"io-irq" configuring for short.  The <tt/setserial/ is used to tell
the driver.  PnP methods, jumpers, etc, are used to set the hardware.
Details will be supplied later.  If you need to configure but don't
understand certain details it's easy to get into trouble.
-->
最初の部分(低レベル設定)は、I/O アドレス、IRQ、名前(ttyS2 など)を割り
当てることです。この I/O と IRQ の組は、ハードウェアとシリアルドライバ
の両方に設定しなければなりません。これを簡単に「I/O と IRQ の設定」と呼
ぶことにしましょう。<tt/setserial/ はドライバを設定するために使います。
PnP の機構やジャンパなどはハードウェアの設定に用います。詳しくは後述し
ます。設定をする必要があるにも関わらず詳しいことが分かっていなければ、
すぐに問題に出会ってしまうでしょう。

<!--
The second part (high-level configuring) is assigning it a speed (such
as 38.4k bits/sec), selecting flow control, etc.  This is often done
by communication programs such as PPP, minicom, or by getty (which you
may run on the port so that others may log into your computer).
However you will need to tell these programs what speed you want, etc.
by using a menu or a configuration file.  This high-level configuring
may also be done with the <tt/stty/ program.  <tt/stty/ is also useful
to view the current status if you're having problems.
See also the section <ref id="stty_" name="Stty">
When Linux starts, some effort is made to detect and configure
(low-level) a few serial ports.  Exactly what happens depends on your
BIOS, hardware, Linux distribution, etc.  If the serial ports work OK,
there may be no need for you to do any configuring.  Application
programs often do the high-level configuring but you may need to
supply them with the required information.  With Plug-and-Play serial
ports (often built into an internal modem), the situation has become
more complex.  Here are cases when you need to do low-level
configuring (set IRQ and IO addresses):
-->
2 番目の部分(高レベルの設定)は速度(38.4K ビット/秒など)の設定やフロー
制御の選択などです。これはしばしば PPP や minicom といった通信プログラ
ムや、getty (他の人があなたのマシンにログインできるようにポート上で動
作します)が行います。
しかし、こういったプログラムに対しては、希望する速度等の設定をメニュー
や設定ファイルを使って行う必要があります。この高レベルの設定は、
<tt/stty/ プログラムによっても行えます。<tt/stty/ は、問題がある時に現
在の状態を表示する際にも役立ちます。
詳しくは <ref id="stty_"name="stty"> の章をご覧ください。
Linux が起動する時には、いくつかのシリアルポートの検出と(低レベル)設定
が試みられます。正確にどうなるのかは、お使いの BIOS, ハードウェア、
Linux ディストリビューション等によって違います。シリアルポートがうまく
動作しているならば、何もする必要はありません。アプリケーションプログラム
はたいてい高レベルの設定を行ってくれますが、必要な情報を与えてやる必要
があるかもしれません。プラグ&amp;プレイのシリアルポート(内蔵モデムに組
み込まれることが多いです)では、事情はずっと複雑になります。低レベルの
設定(IRQ と I/O アドレスの設定)が必要となる場合を以下に示します:

<itemize>
<!--
<item> Plan to use more than 2 serial ports
-->
<item> 3 つ以上のシリアルポートを使う予定の場合
<!--
<item> Installing a new serial port (such as an internal modem)
-->
<item>新しいシリアルポート(内蔵モデムなど)をインストールする場合
<!--
<item>  Having problems with serial port(s)
-->
<item>シリアルポートで問題が起きた場合
</itemize>

<!--
For kernel 2.2+ you may be able to use more that 2 serial ports
without low-level configuring by sharing interrupts.  This only works
if the serial hardware supports it and may be no easier than low-level
configuring.  See <ref id="int_share-2.2" name="Interrupt sharing and
Kernels 2.2+">
-->
バージョン 2.2 以降のカーネルでは、割り込みの共有を使えば低レベルの設
定を行わなくても 3 つ以上のシリアルポートを使うことができます。ただし、
これが動作するのはシリアルポートのハードウェアが割り込みの共有に対応し
ている場合だけですし、その設定もシリアルポートの低レベルの設定より簡単
とは言えません。
<ref id="int_share-2.2" name="2.2 以降のカーネルと割り込みの共有">
をご覧ください。

<!--
The low-level configuring (setting the IRQ and IO address) seems to
cause people more trouble (than high-level), although for many it's
fully automatic and there is no configuring to be done.  Thus most all
of this section is on that topic.  Until the serial driver knows the
correct IRQ and IO address the port will not work at all.  It may not
even be found by Linux.  Even if it can be found, it may work
extremely slow if the IRQ is wrong.  See <ref id="slow_"
name="Extremely Slow: Text appears on the screen slowly after long
delays">.
-->
低レベルの設定(IRQ と I/O アドレスの設定)は、(高レベルの設定と比べると)
比較的問題を起こしやすいようです。多くの場合は完全に自動で、何も設定す
ることがないのにです。そこで、この章の大部分はその話題を扱います。
シリアルドライバが正しい IRQ と I/O アドレスを知るまでは、ポートは全く
動作しません。Linux では検出さえされないでしょう。検出されたとしても、
IRQ が間違っていれば、動作は極めて遅いかもしれません。
<ref id="slow_" name="この上なく遅い: テキストがすごく遅れてゆっくり画面に表示されます">
を見てください。

<!--
In the Wintel world, the IO address and IRQ are called "resources" and
we are thus configuring certain resources.  But there are many other
types of "resources" so the term has many other meanings.  In review,
the low-level configuring consists of putting two values (an IRQ
number and IO address) into two places: 
-->
Wintel の世界では、I/O アドレスと IRQ は「リソース」と呼ばれます。した
がって、我々は特定のリソースを設定していることになります。
しかし、他の種類の「リソース」がたくさんあるので、この言葉は他に色々な
意味を持つことになります。復習になりますが、低レベルの設定は 2 つの値
(IRQ 番号と I/O アドレス)を 2 つの場所に設定することです:

<enum>
<!--
<item> the device driver (often by running "<tt/setserial/" at 
 boot-time)
-->
<item> デバイスドライバ(多くの場合、起動時に "<tt/setserial/" を実行し
て設定します)
<!--
<item> memory registers of the serial port hardware itself 
-->
<item> シリアルポートのハードウェアそのもののメモリレジスタ
</enum>

<!--
You may watch the start-up (= boot-time) messages.  They are usually
correct.  But if you're having problems, there's a good chance that
some of these messages don't show the true configuration of the
hardware (and they are not supposed to).  See <ref id="boot_mesgs"
name="I/O Address & IRQ: Boot-time messages">.  
-->
起動(= ブート時)メッセージを見てください。これは通常は正しいです。しか
し問題が起きている場合には、これらのメッセージの一部がハードウェアの正
しい設定を示していない(そして正しくないと思われる)可能性が高いです。
<ref id="boot_mesgs" name="I/O アドレスと IRQ: 起動時のメッセージ"> を
ご覧ください。

<!--
<sect1> Common mistakes made re low-level configuring
-->
<sect1> 低レベル設定に関するありふれた間違い
<!--
<p> Here are some common mistakes people make:
-->
<p>多くの人がやってしまう一般的な間違いを示します:
<itemize>
<!--
<item>setserial command: They run it (without the "autoconfig" option)
 and think it has checked out the hardware (it hasn't).  
-->
<item>setserial コマンド: (autoconfig オプションを付けずに) setserial 
を実行し、ハードウェアも調べられたと思い込む(実際には調べられません)
<!--
<item>setserial messages:  They see them displayed on the screen at
 boot-time, and erroneously think that the result shows how their
 hardware is actually configured.
-->
<item>setserial のメッセージ: 起動時に画面に表示されるメッセージを見て、
ハードウェアが実際に設定された結果だと間違って信じてしまう
<!--
<item>/proc/interrupts: When their serial device isn't in use they don't
 see its interrupt there, and erroneously conclude that their
 serial port can't be found (or doesn't have an interrupt set).
-->
<item>/proc/interrupts: シリアルポートが使われていない時は、その割り込
みは /proc/interrupts に現われないが、それを見てシリアルポートが見つか
らない(あるいは割り込みが設定されていない)と誤って信じてしまう
<!--
<item>/proc/ioports: People think this shows the hardware
 configuration when it only shows about the same data (possibly
 erroneous) as setserial.
-->
<item>/proc/ioports:
このファイルが表示するのは setserial とほぼ同じ(つまり間違っている
可能性のある)データでしかないのに、それが実際のハードウェア設定だと思
い込んでしまう
</itemize>

<!--
<sect1>  I/O Address & IRQ: Boot-time messages <label id="boot_mesgs">
-->
<sect1>  I/O アドレスと IRQ: 起動時のメッセージ <label id="boot_mesgs">
<!--
<p> In many cases your ports will automatically get low-level
configured at boot-time (but not always correctly).  To see what is
happening, look at the start-up messages on the screen.  Don't neglect
to check the messages from the BIOS before Linux is loaded (no
examples shown here).  These BIOS messages may be frozen by pressing
the Pause key.  Use Shift-PageUp to go back to all the messages after
they have flash by.  Shift-PageDown will scroll in the opposite
direction.  The <tt/dmesg/ command may be used at any time to view
some of the messages but it often misses important ones.  Here's an
example of the start-up messages (as of mid 1999).  Note that ttyS00
is the same as /dev/ttyS0.  
-->
<p> 多くの場合、ポートの低レベルの設定は起動時に自動的に行われます(し
かし常に正しいとは限りません)。何が起きているか調べるには、画面上の起
動メッセージを見ましょう。Linux がロードされる前に BIOS が出すメッセー
ジ(例は挙げません)の確認も怠らないでください。このような BIOS の
メッセージの出力は Pause キーを押すと一時的に止めることができます。
スクロールして流れてしまったメッセージを戻して見るには、Shift-PageUp 
キーを使います。Shift-PageDown キーを押すと反対向きにスクロールします。
<tt/dmesg/ コマンドを
使えばいつでも起動メッセージの一部を見ることができますが、大事な部分が
抜け落ちていることもよくあります。起動メッセージの例(1999 年半ばの時点)
を以下に示します: ttyS00 は /dev/ttyS0 と同じである点に注意してくださ
い。

<!--
<tscreen><verb>
At first you see what was detected (but the irq is only a wild guess):

Serial driver version 4.27 with no serial options enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
ttyS02 at 0x03e8 (irq = 4) is a 16550A

Later you see what was saved, but it's not necessarily correct either:

Loading the saved-state of the serial devices...
/dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A
/dev/ttyS1 at 0x02f8 (irq = 3) is a 16550A
/dev/ttyS2 at 0x03e8 (irq = 5) is a 16550A
</verb></tscreen>
-->
<tscreen><verb>
検出されたものが最初に表示されます(ただし IRQ は大雑把に推定したものに
過ぎません):

Serial driver version 4.27 with no serial options enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
ttyS02 at 0x03e8 (irq = 4) is a 16550A

保存された値が後で表示されますが、これも正しいとは限りません:

Loading the saved-state of the serial devices...
/dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A
/dev/ttyS1 at 0x02f8 (irq = 3) is a 16550A
/dev/ttyS2 at 0x03e8 (irq = 5) is a 16550A
</verb></tscreen>

<!--
Note that there is a slight disagreement: The first message shows
ttyS2 at irq=4 while the second shows it at irq=5.  Your may only have
the first message.  In most cases the last message is the correct one.
But if your having trouble it may be misleading.  Before reading the
explanation of all of this complexity in the rest of this section, you
might just try using your serial port and see if it works OK.  If so
it may not be essential to read further.
-->
ちょっとした不一致がある点に注意してください。最初のメッセージでは 
IRQ=4 に ttyS2 があるように表示されていますが、二番目のメッセージでは 
IRQ=5 になっています。最初のメッセージしか表示されないかもしれません。
ほとんどの場合は最後に表示されるものが正しいメッセージです。しかし問題
がある場合には紛らわしいかもしれません。この章の残りに書かれているこの
難しいことの説明を読む前には、とりあえずシリアルポートを使ってみて、正
しく動作するかどうかを調べるとよいでしょう。ちゃんと動作しているならば、
この先は特に読まなくてもかまいません。

<!--
The second message is from the <tt/setserial/ program being run at
boot-time.  It shows what the device driver thinks is the correct
configuration.  But this too could be wrong.  For example, the irq
could actually be set to irq=8 in the hardware (both messages wrong).
The irq=5 could be there because someone incorrectly put this into a
configuration file (or the like).  The fact that Linux sometimes gets
IRQs wrong is because it doesn't probe for IRQs.  It just assumes the
"standard" ones (first message) or accepts what you told it when you
configured it (second message).  Neither of these is necessarily
correct.  If the serial driver has the wrong IRQ the serial port is
very slow or doesn't seem to work at all.
-->
2 番目のメッセージは、起動時に実行される <tt/setserial/ プログラムが出
力します。このメッセージは、デバイスドライバが正しいと思っている設定を
示します。しかし、これも間違っていることがあります。例えば、ハードウェ
アの IRQ が実際には IRQ=8 に設定されていることもあります(どちらのメッ
セージも間違っている)。IRQ=5 が表示されるのは、誰かが間違ってその情報
を設定ファイルに入れたため(あるいはこれと同様の理由)かもしれません。
Linux が時々
間違った IRQ を取得するのは、Linux が IRQ の探査を行わないからです。
Linux は単に「標準」の IRQ を仮定するか(最初のメッセージ)、ユーザが行っ
た設定をそのまま使います(2番目のメッセージ)。この両者はいずれも、正し
いとは限りません。シリアルドライバの IRQ が間違っていると、シリアルポー
トの動作が非常に遅くなったり、まったく動作していないように見えたりしま
す。

<!--
The first message is a result of Linux probing the serial ports but it
doesn't probe for IRQs.  If a port shows up here it exists but the
IRQ may be wrong.  Linux doesn't check IRQs because doing so is not
foolproof.  It just assumes the IRQs are as shown because they are the
"standard" values.  Your may check them manually with <tt/setserial/
using the <tt/autoconfig/ and <tt/auto_irq/ options but this isn't
guaranteed to be correct.
-->
最初のメッセージは、Linux がシリアルポートの探査を行った結果ですが、
IRQ の探査は行われていません。ポートがここに現われた場合、そのポートは
存在しますが、IRQ は間違っていることがあります。
Linux が IRQ のチェックを行わないのは、どのみち完璧にはチェックできな
いためです。
Linux は IRQ が先に示した値であることを仮定します。なぜなら、これらが
「標準的」な値だからです。<tt/setserial/ に <tt/autoconfig/ オプション
や <tt/auto_irq/ オプションを付けて実行すると手動で確認を行えますが、
これも正しいという保証はありません。

<!--
The data shown by the BIOS messages (which you see at first) is what
is set in the hardware.  If your serial port is Plug-and-Play PnP then
it's possible that the <tt/isapnp/ will run and change these settings.
Look for messages about this after Linux starts.  The last serial port
message shown in the example above should agree with the BIOS messages
(as possibly modified by isapnp).  If they don't agree then you either
need to change the setting in the port hardware or use setserial to
tell the driver what is actually set in the hardware.
-->
BIOS のメッセージに表示されるデータ(最初に表示される)はハードウェアに
設定されている値です。シリアルポートがプラグ&amp;プレイならば、
<tt/isapnp/ を実行してこれらの設定を変えることができます。Linux が起動
した後に、これに関するメッセージを探しましょう。先の例に挙げられている、
最後のシリアルポートのメッセージは、BIOS のメッセージと一致していなけ
ればなりません(これは isapnp が変えているかもしれません)。
一致しない場合には、ポートのハードウェアの設定を変更す
るか、ハードウェアに実際に設定されている内容を setserial を使って
ドライバに教えなくてはなりません。

<!--
Also, if you have Plug-and-Play (PnP) serial ports, Linux will not
find them unless the IRQ and IO has been set inside the hardware by
Plug-and-Play software.  This is a common reason why the start-up
messages do not show a serial port that physically exists.  The PC
hardware (a PnP BIOS) may automatically low-level configure this.  PnP
configuring will be explained later.
-->
また、プラグ&amp;プレイのシリアルポートをお使いの場合には、プラグ&amp;
プレイのソフトウェアがハードウェア内部の IRQ と I/O を設定しなければ、
Linux はこれらを検出しません。これは、物理的に存在するシリアルポートが
起動メッセージで表示されない一般的な理由です。PC のハードウェア(PnP BIOS)
はこのようなシリアルポートの低レベルな設定を自動的に行います。PnP の設
定は後で説明します。

<!--
<sect1> What is the current IO address and IRQ of my Serial Port ? 
-->
<sect1> シリアルポートの現在の I/O アドレスと IRQ の設定は?
<label id="what_is_io_irq">
<!--
<p> The previous section indicated how to attempt to do this by
looking at the start-up messages.  If they give you sufficient info
then you may not need to read this section.  If they don't then there
are some other ways to look into this.
-->
<p>前の節では、起動メッセージをみることにより設定を調べる方法を説明し
ました。起動メッセージで十分な情報が得られれば、この節を読む必要はあり
ません。情報が十分でなければ、これを調べる方法がいくつかあります。

<!--
There are really two answers to the question "What is my IO and
IRQ?" 1. What the device driver thinks has been set (This is what
setserial usually sets and shows).  2. What is actually set in the
hardware.  They both should be the same.  If they're not it spells
trouble since the driver has incorrect info on the physical serial
port.  If the driver has the wrong IO address it will try to send data
to a non-existing serial port -/-or even worse, to an actual device
that is not a serial port.  If it has the wrong IRQ the driver will
not get interrupt service requests from the serial port, resulting in
a very slow or no response.  See <ref id="slow_" name="Extremely Slow:
Text appears on the screen slowly after long delays">.  If it has the
wrong model of UART there is also apt to be trouble.  To determine if
both I0-IRQ pairs are identical you must find out how they are set in
both the driver and the hardware.
-->
「I/O と IRQ の設定はどうなっているの?」という問いへの答えは実際には 2 
通りあります。1. デバイスドライバに設定されている値(これは普通は setserial 
コマンドで設定と表示を行います)。 2. 実際にハードウェアに設定されてい
る値。両者は同じ値でなければなりません。同じ値でなければ問題が起こりま
す。なぜなら、ドライバが物理的なシリアルポートに関して間違った情報を持
つことになるからです。間違った I/O アドレスがドライバに設定されている
と、ドライバは存在しないポートにデータを送ろうとします。あるいはもっと
悪いケースとしては、シリアルポートでない実在のポートにデータを送ろうと
します。間違った IRQ がドライバに設定されていると、
ドライバがシリアルポートからの割り込みサービス要求を受け取れずに、非常
に遅かったり全く応答しなかったりします。この場合は、
<ref id="slow_" name="この上なく遅い: テキストがすごく遅れてゆっくり画面に表示されます">
の節をご覧ください。ドライバに設定されている UART のモデルが間違ってい
る場合にも問題が起こりがちです。I/O-IRQ の組がドライバとハードウェアで同じ
かどうかを確かめるには、これらの値がどのように設定されているのかを
ドライバとハードウェアの両方について調べなければなりません。

<!--
<sect2> What does the device driver think?
-->
<sect2> デバイスドライバの設定は?
<!--
<p> This is easy to find out.  Just look at the start-up messages or
type "setserial -g /dev/ttyS*".   If everything works OK then what
it tells you is likely also set in the hardware.  There are some other
ways to find this info by looking at "files" in the /proc directory.
An important reason for understanding these other ways is to warn you
that they only show what the device driver thinks.  Some people view
certain "files" in the /proc directory and erroneously think that what
they see is set in the hardware but "it ain't necessarily so". 
-->
<p>これを調べるのは簡単です。単に起動メッセージを見るか、
"setserial -g /dev/ttyS*" を実行するだけです。シリアルポートがうまく動
作していれば、この表示内容がハードウェアにも設定されているでしょう。こ
の情報を調べる別の方法としては、/proc ディレクトリにある「ファイル」を
見る方法があります。このような別の方法を説明する重要な理由は、
これらはデバイスドライバに設定されている情報しか表示しないことに注意し
てもらうためです。一部の人は、/proc ディレクトリにある特定のファイルを
見て、これがハードウェアに設定されていると勘違いしてしまいますが、
「必ずしもそうではありません」。

<!--
/proc/ioports will show the IO addresses that the drivers are using.
/proc/interrupts shows the IRQs that are used by drivers of 
currently running processes (that have devices open).  Note that
in both cases above you are only seeing what the driver thinks and not
necessarily what is actually set in the hardware.  /proc/interrupts also
shows how many interrupts have been issued (often thousands) for each
device.  You can get a clue from this because if you see a large
number of interrupts that have been issued it means that there is a
piece of hardware somewhere that is using that interrupt.  Sometimes a
showing of just a few interrupts doesn't mean that that interrupt is
actually being physically generated by any serial port.  Thus if you
see almost no interrupts for a port that you're trying to use, that
interrupt might not be set in the hardware and it implies that the
driver is using the wrong interrupt.  To view /proc/interrupts to
check on a program that you're currently running (such as "minicom")
you need to keep the program running while you view it.  To do this,
try to jump to a shell without exiting the program.
-->
/proc/ioports は、ドライバが使っている I/O アドレスを表示します。
/proc/interrupts は、現在動作している(デバイスをオープンした)プロセスの
ドライバが使っている IRQ を表示します。上記のいずれの場合も、表示され
るのはドライバの設定内容であり、ハードウェアの実際の設定内容では必ずし
もありません。/proc/interrupts は、それぞれのデバイスに対して割り込みが
いくつ発行されたのかも表示します(数千個のこともよくあります)。この情報
から問題解決の手がかりをつかむことができます。なぜなら、大量の割り込み
が発行されていれば、その割り込みを使っているハードウェアがどこかにある
ということだからです。割り込みが少ししか表示されないことは時に、その割
り込みが実際にはどのシリアルポートによっても物理的に生成されていないこ
とを意味します。したがって、使おうとしているシリアルポートに対してほと
んど割り込みが発行されていなければ、ハードウェアには割り込みが設定され
ていないかもしれず、つまりドライバが間違った割り込みを使っているという
ことかもしれません。現在実行中の("minicom" のような)プログラムをチェッ
クするために /proc/interrupts を見るには、このファイルを見ている間は
ずっとプログラムを実行し続ける必要があります。これを行うには、プログラ
ムを終了せずにシェルに行ってみましょう。

<!--
<sect2> What is set in my serial port hardware ? <label
 id="io-irq_in_hdw"
-->
<sect2> シリアルポートのハードウェアの設定は? <label
 id="io-irq_in_hdw">
<!--
<p> How do you find out what IO address and IRQ are actually set in
the device hardware?  Perhaps the BIOS messages will tell you
some info before Linux starts booting.  Use the shift-PageUp key to
step back thru the boot-time messages and look at the very first ones
which are from the BIOS.  This is how it was before Linux started.
Setserial can't change it but isapnp or pciutils can.  
-->
<p> デバイスのハードウェアに実際にどの I/O アドレスと IRQ が設定されて
いるのかを調べるにはどうすればいいのでしょうか? Linux が起動を始める前
に、もしかすると BIOS のメッセージがある程度の情報を教えてくれるかもし
れません。
Shift-PageUp キーを使って起動メッセージの表示を戻し、BIOS が出した一番
最初のメッセージを見ましょう。これは Linux が起動する前の設定です。
setserial はこの設定を変えることはできませんが、isapnp や pciutils は
設定を変えられます。

<!--
One crude method is try probing with setserial using the "autoconfig"
option.  You'll need to guess the addresses to probe at.  See <ref
id="set_serial" name="What is Setserial">.  For a PCI serial port, use
the "lspci" command (for kernels &lt;2.2 look at /proc/pci).  If your
serial port is is Plug-and-Play see the next two subsections.
-->
大雑把な方法の一つとして、"autoconfig" オプションを付けて setserial に
検出を行わせてみる方法があります。この方法では、検出を行うアドレスを推定
する必要があります。<ref id="set_serial" name="setserial とは何か?"> 
を見てください。PCI シリアルポートの場合には、"lspci" コマンドを使って
ください(2.2 より前のカーネルの場合は /proc/pci を見てください)。
お使いのシリアルポートがプラグ&amp;プレイならば、以下の 2 つの節を見て
ください。

<!--
For a port set with jumpers, its how the jumpers were set.  If the
port is not Plug-and-Play (PnP) but has been setup by using a DOS
program then it's set at whatever the person who ran that program set
it to.
-->
ジャンパで設定したポートの場合は、これはジャンパで設定した内容です。ポー
トがプラグ&amp;プレイ(PnP)ではないけれど DOS プログラムを使って設定さ
れている場合には、そのプログラムを実行した人が設定したように設定されて
います。

<!--
<sect2> What is set in my PnP serial port hardware ?
-->
<sect2> PnP シリアルポートのハードウェアの設定は?
<!--
<p> PnP ports don't store their configuration in the hardware when the
power is turned off.  This is in contrast to Jumpers (non-PnP) which
remain the same with the power off.  If you have an ISA PnP port, it
can reach a state where it doesn't have any IO address or IRQ and is
in effect disabled.  It should still be possible to find the port
using the <tt/pnpdump/ program.
-->
<p> PnP シリアルポートは、電源が切られた時に設定をハードウェアに保存し
ません。これは、電源を切っても設定が変わらないジャンパ(非 PnP)と対照的
です。ISA PnP シリアルポートをお使いであれば、シリアルポートが全く I/O 
アドレスや IRQ を持たず、事実上使えない状態になる可能性があります。こ
の場合でもまだ、<tt/pnpdump/ を使ってそのシリアルポートを見つけること
が可能なはずです。

<!--
For Plug-and-Play (PnP) on the ISA bus one may try the <tt/pnpdump/
program (part of <tt/isapnptools/).  If you use the &#045;&#045;dumpregs option
then it should tell you the actual IO address and IRQ set in the port.
The address it "trys" is not the device's IO address, but a special
-->
ISA バスでのプラグ&amp;プレイの場合、<tt/pnpdump/ (<tt/isapnptools/ に
含まれています)を試すとよいでしょう。--dumpregs オプションを使うと、ポー
トに設定されている実際の I/O アドレスと IRQ が表示されるはずです。
<tt/pnpdump/ が「試した」アドレスはデバイスの I/O アドレスではなく、特
殊なものです。

<!--
For PnP ports checking on how it's configured under DOS/Windows may not
be of much help.  Windows stores its configuration info in its
Registry which is not used by Linux.  It may supply the BIOS's
non-volatile memory with some info but it may not be kept in sync with
the current Window configuration in the Registry ??  If you let a PnP
BIOS automatically do the configuring when you start Linux (and have
told the BIOS that you don't have a PnP operating system when running
Linux) then Linux should use whatever configuration is in the BIOS's
non-volatile memory.
-->
PnP ポートの場合は、DOS/Windows での設定内容を調べてもあまり役に立
ちません。Windows は設定情報をレジストリに保存しますが、これは Linux 
では使われません。BIOS の不揮発性メモリにも Windows の情報が記憶されて
いることもありますが、レジストリ内にある Windows の現在の設定とは同
期が取れていないことがあります(??)。Linux の起動時に PnP BIOS に自動設
定をさせているのならば(そして Linux を起動する際には、PnP オペレーティ
ングシステムでないと BIOS を設定しているならば)、Linux は BIOS の不揮
発性メモリ内の設定を使うはずです。

<!--
<sect1>Choosing Serial IRQs
-->
<sect1>シリアルの IRQ の選択

<!--
<p> If you have a true Plug-and-Play set up where either the OS or a
PnP BIOS configures all your devices, then you don't choose your IRQs.
PnP determines what it thinks is best and assigns them.  But if you
use the tools in Linux for Plug-and-Play (isapnp and pcitools) then
you have to choose.  If you already know what IRQ you want to use you
could skip this section except that you may want to know that IRQ 0
has a special use (see the following paragraph).
-->
<p> OS か PnP BIOS が全てのデバイスを設定するという本物のプラグ&amp;プ
レイ設定を行っているならば、IRQ を選ぶことはありません。PnP は最も良い
と思われる割り当てを選んでこれを設定します。しかし、Linux でプラグ
&amp;プレイ用のツール(isapnp と pcitools)を使っている場合には、IRQ の
選択を行う必要があります。使いたい IRQ を既に知っている場合には、この
節を飛ばしてもかまいませんが、IRQ 0 の使い方が特殊であることだけは知っ
ておいてください(次の段落を読んでください)。

<!--
<sect2> IRQ 0 is not an IRQ
-->
<sect2> IRQ 0 は IRQ ではない
<!--
<p> While IRQ 0 is actually the timer (in hardware) it has a special
meaning for setting a serial port with setserial.  It tells the driver
that there is no interrupt for the port and the driver then will use
polling methods.  This is quite inefficient but can be tried if there
is an interrupt conflict or mis-set interrupt.  The advantage of
assigning this is that you don't need to know what interrupt is set in
the hardware.  It should be used only as a temporary expedient until
you are able to find a real interrupt to use.
-->
<p> IRQ 0 は実際には(ハードウェアでは)タイマですが、setserial を使った
シリアルポートの設定においては特殊な意味を持っています。この指定は、
そのポートには割り込みがないことをドライバに伝え、ドライバはポーリング
を使った動作を行います。ポーリングは非常に効率が悪いのですが、割り込み
が衝突した場合や、割り込みの設定ミスがあった場合には試すとよいでしょう。
IRQ 0 を設定する利点は、ハードウェアに設定されている割り込み番号を知る
必要がない点です。IRQ 0 は、実際に使える割り込みが見つかるまでの急場を
しのぐためだけに使うべきです。

<!--
<sect2> Interrupt sharing and Kernels 2.2+ <label id="int_share-2.2">
-->
<sect2> 割り込みの共有とバージョン 2.2 以降のカーネル <label id="int_share-2.2">
<!--
<p> The general rule is that every device should use a unique IRQ and
not share them.  But there are situations where sharing is permitted
such as with most multi-port boards.  Even when it is permitted, it
may not be as efficient since every time a shared interrupt is given a
check must be made to determine where it came from.  Thus if it's
feasible, it's nice to allocate every device its own interrupt.
-->
<p> 一般的な規則では、全てのデバイスが固有の IRQ を持ち、IRQ の共有を
行わないことになっています。しかし大抵のマルチポートを使う場合のように、
IRQ の共有が許されている場合もあります。ただし、共有が許されているとし
ても、効率は良くないかもしれません。というのも、共有されている割り込み
が与えられる度に、どこで割り込みが発行されたのかを調べなければならない
からです。したがって、可能であれば、全てのデバイスに固有の割り込みを与
えるといいでしょう。

<!--
Prior to kernel 2.2, serial IRQs could be shared with each other only
for most multiport boards.  Starting with kernel 2.2 serial IRQs may
be sometimes shared between all serial ports.  In order for sharing to
work in 2.2 the kernel must have been compiled with
CONFIG_SERIAL_SHARE_IRQ, and the serial port hardware must support
sharing (so that if two serial cards put different voltages on the
same interrupt wire, only the voltage that means "this is an
interrupt" will prevail).  Thus even if you have 2.2, it may be best
to avoid sharing.
-->
バージョン 2.2 より前のカーネルでは、IRQ はほとんどのマルチポートボー
ド同士だけでしか共有できませんでした。バージョン 2.2 以降のカーネルは、
場合によっては全てのシリアルポートで IRQ を共有できます。バージョン 
2.2 のカーネルで共有を動作させるには、CONFIG_SERIAL_SHARE_IRQ を設定し
てカーネルをコンパイルしなければなりません。また、シリアルポートのハー
ドウェアも共有に対応していなければなりません(対応していれば、2 つの
シリアルカードが 1 つの割り込み線に異なる電圧を流しても、「これが
割り込みです」という意味の電圧しか受け取られません)。
よってバージョン 2.2 のカーネルであっても、割り込みの共有はしない方が
良いかもしれません。

<!--
<sect2> What IRQs to choose?
-->
<sect2> どの IRQ を選ぶか?

<!--
<p> The serial hardware often has only a limited number of IRQs it can
be set at.  Also you don't want IRQ conflicts.  So there may not be
much of a choice.  Your PC may normally come with <tt/ttyS0/ and
<tt/ttyS2/ at IRQ 4, and <tt/ttyS1/ and <tt/ttyS3/ at IRQ 3.  Looking
at <tt>/proc/interrupts</tt> will show which IRQs are being used by
programs currently running.  You likely don't want to use one of
these.  Before IRQ 5 was used for sound cards, it was often used for a
serial port.
-->
<p> シリアルポートのハードウェアには、限られた IRQ しか設定できないこ
とがよくあります。しかし IRQ が衝突するのも嫌でしょう。したがって、選択
の余地はあまりありません。PC では普通、<tt/ttyS0/ と <tt/ttyS2/ が 
IRQ4 に、<tt/ttyS1/ と <tt/ttyS3/ が IRQ 3 にあります。
<tt>/proc/interrupts</tt> を見れば、現在動作中のプログラムが使っている 
IRQ がどれかわかります。このような IRQ は使わない方がいいでしょ
う。IRQ 5 がサウンドカードに使われるようになる前には、シリアルポート
でもよく使われていました。

<!--
Here is how Greg (original author of Serial-HOWTO) set his up in
/etc/rc.d/rc.serial.  rc.serial is a file (shell script) which runs at
start-up (it may have a different name of location).  For versions of
"setserial" after 2.15 it's not always done this way anymore but this
example does show the choice of IRQs.
-->
以下に、Greg (Serial-HOWTO の元々の著者)がどのように 
/etc/rc.d/rc.serial を設定しているかを示します。rc.serial は起動時に実
行されるファイル(シェルスクリプト)です(場所や名前は違うことがあります)。
バージョン 2.15 より後の "setserial" では、必ずしもこのように設定が行
われるわけではありませんが、これは IRQ の選択の例にもなります。

<!--
<tscreen><verb>
/sbin/setserial /dev/ttyS0 irq 3	# my serial mouse
/sbin/setserial /dev/ttyS1 irq 4	# my Wyse dumb terminal
/sbin/setserial /dev/ttyS2 irq 5	# my Zoom modem 
/sbin/setserial /dev/ttyS3 irq 9	# my USR modem
</verb></tscreen>
-->
<tscreen><verb>
/sbin/setserial /dev/ttyS0 irq 3	# シリアルマウス
/sbin/setserial /dev/ttyS1 irq 4	# Wyse 製のダム端末
/sbin/setserial /dev/ttyS2 irq 5	# Zoom 製のモデム
/sbin/setserial /dev/ttyS3 irq 9	# US Robotics 製のモデム
</verb></tscreen>
<p>
<!--
Standard IRQ assignments:
-->
標準の IRQ 割り当てを示します:
<!--
<verb>
	IRQ  0    Timer channel 0 (May mean "no interrupt".  See below.)
	IRQ  1    Keyboard
	IRQ  2    Cascade for controller 2
	IRQ  3    Serial port 2
	IRQ  4    Serial port 1
	IRQ  5    Parallel port 2, Sound card
	IRQ  6    Floppy diskette
	IRQ  7    Parallel port 1
	IRQ  8    Real-time clock
	IRQ  9    Redirected to IRQ2
	IRQ 10    not assigned 
	IRQ 11    not assigned
	IRQ 12    not assigned
	IRQ 13    Math coprocessor
	IRQ 14    Hard disk controller 1
	IRQ 15    Hard disk controller 2
</verb>
-->
<verb>
	IRQ  0    タイマチャネル 0 (「割り込み無し」を意味することもあります。詳しくは後述します)
	IRQ  1    キーボード
	IRQ  2    コントローラ 2 へのカスケード
	IRQ  3    シリアルポート 2
	IRQ  4    シリアルポート 1
	IRQ  5    パラレルポート 2, サウンドカード
	IRQ  6    フロッピーディスク
	IRQ  7    パラレルポート 1
	IRQ  8    リアルタイムクロック
	IRQ  9    IRQ2 にリダイレクト
	IRQ 10    割り当て無し
	IRQ 11    割り当て無し
	IRQ 12    割り当て無し
	IRQ 13    数値コプロセッサ
	IRQ 14    ハードディスクコントローラ 1
	IRQ 15    ハードディスクコントローラ 2
</verb>
<p>

<!--
There is really no Right Thing to do when choosing interrupts.  Just
make sure it isn't being used by the motherboard, or any other boards.
2, 3, 4, 5, 7, 10, 11, 12 or 15 are possible choices.  Note that IRQ 2
is the same as IRQ 9.  You can call it either 2 or 9, the serial
driver is very understanding.  If you have a very old serial board it
may not be able to use IRQs 8 and above. 
-->
割り込みを選ぶための決定的な方法はありません。割り込みをマザーボードや、
他のボードが使っていないことを確かめるしかありません。2, 3, 4, 5, 7,
10, 11, 12, 15 を選ぶことができます。IRQ 2 と 9 は同じであることに注意
してください。IRQ 2 と 9 のどちらを使っても、シリアルドライバはこれを
うまく認識します。非常に古いシリアルボードをお使いの場合には、8 以上の 
IRQ は使えないかもしれません。

<!--
Make sure you don't use IRQs 1, 6, 8, 13 or 14!  These are used by
your motherboard.  You will make her very unhappy by taking her IRQs.
When you are done, double-check <tt>/proc/interrupts</tt> when
programs that use interrupts are being run and make sure there are no
conflicts.
-->
IRQ 1, 6, 8, 13, 14 は使わないでください! これらの IRQ はマザーボー
ドが使うからです。マザーボードが使っている IRQ を取り上げると、とても
悲しいことになります。設定が終わったら、割り込みを使うプログラムを実行
する時に <tt>/proc/interrupts</tt> を再確認し、IRQ の衝突が起こってい
ないことを確かめてください。

<!--
<sect1> Choosing Addresses &#045;&#045;Video card conflict with ttyS3
-->
<sect1> アドレスの選択 --ttyS3 と衝突するビデオカード

<!--
<p> The IO address of the IBM 8514 video board (and others like it) is
allegedly 0x?2e8 where ? is 2, 4, 8, or 9.  This may conflict (but
shouldn't if the serial port is well designed) with the IO address of
<tt/ttyS3/ at 0x02e8 if the serial port ignores the leading 0 hex
digit (many do).  That is bad news if you try to use <tt/ttyS3/ at
this IO address.
-->
<p>IBM 8514 ビデオカード(とその類似品)の I/O アドレスは、聞くところで
は 0x?2e8 です(? は 2, 4, 8, 9 のいずれか)。16 進値の先頭の 0 である桁
をシリアルポートが無視する場合には(多くの場合はそうです)、これは
0x02e8 にある <tt/ttyS3/ と衝突するかもしれません(しかし、シリアルポー
トがうまく設計されていれば衝突しないはずです)。このアドレスで 
<tt/ttyS3/ を使おうとしている場合には、これは悪い知らせです。

<!--
In most cases you should use the default addresses if feasible.
Addresses shown represent the first address of an 8-byte range.  For
example 3f8 is really the range 3f8-3ff.  Each serial device (as well
as other types of devices that use IO addresses) needs its own unique
address range.  There should be no overlaps (conflicts).  Here are the
default addresses for the serial ports: 
-->
ほとんどの場合は、可能であればデフォルトのアドレスを使うべきです。ここ
で言うアドレスは、8 バイトの範囲の最初のアドレスを表しています。例えば、
3f8 は実際には 3f8-3ff の範囲です。それぞれのシリアルデバイスは(I/O ア
ドレスを必要とする他のタイプのデバイスと同じく)固有のアドレス範囲を必
要とします。これは重なっては(衝突しては)いけません。シリアルポートのデ
フォルトのアドレスを以下に示します:

<!--
<tscreen><verb>
ttyS0 address 0x3f8
ttyS1 address 0x2f8
ttyS2 address 0x3e8
ttyS3 address 0x2e8
</verb></tscreen>
-->
<tscreen><verb>
ttyS0 のアドレス 0x3f8
ttyS1 のアドレス 0x2f8
ttyS2 のアドレス 0x3e8
ttyS3 のアドレス 0x2e8
</verb></tscreen>

<!--
<sect1> Set IO Address &amp; IRQ in the hardware (mostly for PnP)
 <label id="io-irq_methods">
-->
<sect1> I/O アドレスと IRQ のハードウェアへの設定 (主に PnP 向け)
 <label id="io-irq_methods">

<!--
<p> After it's set in the hardware don't forget to insure that it also
gets set in the driver by using <tt/setserial/.  For non-PnP serial
ports they are either set in hardware by jumpers or by running a DOS
program ("jumperless") to set them (it may disable PnP).  The rest of
this subsection is only for PnP serial ports.  Here's a list of the
possible methods of configuring PnP serial ports:
-->
<p>I/O アドレスと IRQ をハードウェアに設定した後には、<tt/setserial/ 
を使ってドライバを設定することも忘れないでください。
非 PnP のシリアルポートの場合には、
ポートのハードウェアの設定はジャンパか、("ジャンパレス"の場合には)設定
を行うための DOS プログラムの実行によって行います(このプログラムで PnP 
が無効になるかもしれません)。PnP シリアルポートを設定する際に考えられ
る方法のリストを以下に示します:

<itemize>
<!--
<item> Using a PnP BIOS CMOS setup menu
 (usually only for external 
  devices
 on ttyS0 (Com1) and ttyS1 (Com2))
-->
<item> PnP BIOS の CMOS 設定メニューを使う(普通は ttyS0 (Com1) と 
ttyS1 (Com2) にある外付けデバイスだけに使います)
<!--
<item> Letting a PnP BIOS automatically configure a PnP serial port
 See <ref id="bios_conf" name="Using a PnP BIOS to I0-IRQ Configure">
-->
<item> PnP BIOS に PnP シリアルポートを自動的に設定させる。
<ref id="bios_conf" name="PnP BIOS を使った I/O アドレスと IRQ の設定">
を参照してください
<!--
<item> Doing nothing if you have both a PnP serial port and a PnP
 Linux operating system (see Plug-and-Play-HOWTO).
-->
<item> PnP シリアルポートと PnP 対応の Linux を使っているならば何もし
なくてかまいません(Plug-and-Play-HOWTO を参照)
<!--
<item> Using <tt/isapnp/ for a PnP serial port non-PCI)
-->
<item> PCI でない PnP シリアルポートの場合には <tt/isapnp/ を用いる
<!--
<item> Using pciutils (pcitools) for the PCI bus
-->
<item> PCI バスの場合には pciutils (pcitools) を用いる
</itemize>

<!--
The IO address and IRQ must be set (by PnP) in their registers each
time the system is powered on since PnP hardware doesn't remember how
it was set when the power is shut off.  A simple way to do this is to
let a PnP BIOS know that you don't have a PnP OS and the BIOS will
automatically do this each time you start.  This might cause problems
in Windows (which is a PnP OS) if you start Windows with the BIOS
thinking that Windows is not a PnP OS.  See Plug-and-Play-HOWTO.
-->
I/O アドレスと IRQ は電源を入れる度に(PnP を使って)シリアルポートのレ
ジスタに設定しなければなりません。というのも、PnP ハードウェアは電源が
切られた時の設定内容を覚えていないからです。これを行う簡単な方法は
PnP OS を使っていないと PnP BIOS に教えてやることで、そうすると起動の
度に BIOS が自動的に設定を行います。
ただし、(PnP OS である)Windows を「PnP OS ではない」と BIOS に認識させ
たまま Windows を起動すると、Windows 側で問題が発生するかもしれません。
詳しくは Plug-and-Play-HOWTO をご覧ください。

<!--
Plug-and-Play was designed to automate this io-irq configuring,
but for Linux at present, it has made life more complicated.  The
standard kernels for Linux don't support plug-and-play very well.  If
you use a patch to the Linux kernel to covert it to a plug-and-play
operating system, then all of the above should be handled
automatically by the OS.  But when you want to use this to automate
configuring devices other that the serial port, you may find that
you'll still have to configure the drivers manually since many Linux
drivers are not written to support a Linux PnP OS.  If you use
<tt/isapnptools/ or the BIOS for configuring plug-and-play this will
only put the two values into the registers of the serial port section
of the modem card and you will likely still need to set up setserial.
None of this is easy or very well documented as of early 1999.  See
Plug-and-Play-HOWTO and the isapnptools FAQ.
-->
プラグ&amp;プレイは I/O と IRQ の設定を自動化するために設計されました。
しかし現時点の Linux では、話をややこしくしているだけです。標準の 
Linux カーネルはプラグ&amp;プレイをあまりうまくサポートしていません。
Linux カーネルをプラグ&amp;プレイ OS にするパッチを使っているならば、
上記のことは全て OS が自動的に処理できるはずです。しかし、
シリアルポート以外のデバイスの設定を自動化するためにこのパッチを使った
としても、手動でドライバの設定をしなければならないかもしれません。
というのも、Linux のドライバの多くは PnP 対
応の Linux 向けに書かれていないからです。<tt/isapnptools/ や BIOS を使っ
てプラグ&amp;プレイの設定を行っているならば、これは 2 つの値をモデムカー
ドのシリアルポート部分のレジスタに設定するだけなので、setserial の設定
はユーザが行う必要があるでしょう。1999 年初めの時点では、これらの設定
は簡単でもありませんし、詳しい文書もありません。
Plug-and-Play-HOWTO と isapnptools FAQ をご覧ください。

<!--
<sect2> Using a PnP BIOS to I0-IRQ Configure <label id="bios_conf">
-->
<sect2> PnP BIOS を使った I/O アドレスと IRQ の設定 <label id="bios_conf">
<!--
<p> While the explanation of how to use a PnP OS or isapnp for io-irq
configuring should come with such software, this is not the case if
you want to let a PnP BIOS do such configuring.  Not all PnP BIOS can
do this.  The BIOS usually has a CMOS menu for setting up the first
two serial ports.  This menu may be hard to find and for an "Award"
BIOS it was found under "chipset features setup"  There is often
little to choose from.  Unless otherwise indicated in a menu, these
first two ports normally get set at the standard IO addresses and
IRQs.  See <ref id="dev_nos" name="Serial Port Device Names &
Numbers">
-->
<p> PnP OS や isapnp を使って I/O と IRQ の設定を行う方法の説明はそれら
のソフトウェアに付いてくるはずですが、PnP BIOS にそういった設定を
させようと思っている場合にはそうはいきません。全ての PnP BIOS がこれを行える
わけではありません。BIOS には普通、最初の 2 つのシリアルポートを設定す
るための CMOS メニューがあります。このメニューは見つけにくいかもしれま
せんが、Award 製の BIOS ならば "chipset features setup" の下にあります。
多くの場合、ここではほとんど何も選べません。他のものがメニューになけれ
ば、最初の 2 つのシリアルポートには標準の I/O アドレスと IRQ が設定さ
れます。<ref id="dev_nos" name="シリアルポートデバイスの名前と番号">を
ご覧ください。

<!--
Whether you like it or not, when you start up a PC a PnP BIOS starts
to do PnP (io-irq) configuring of hardware devices.  It may do the job
partially and turn the rest over to a PnP OS (which you probably don't
have) or if thinks you don't have a PnP OS it may fully configure all
the PnP devices but not configure the device drivers.  This is what
you want but it's not always easy to figure out exactly what the PnP
BIOS has done.
-->
好むと好まざるとに関わらず、PC を起動すると PnP BIOS が PnP によるハー
ドウェアデバイスの(I/O と IRQ の)設定を始めます。PnP BIOS が行う処理
が不十分で、残りの設定が(読者の皆さんがおそらく持っていない) PnP OS に
残されるかもしれません。あるいは PnP OS を持っていないと設定されている
場合には、全ての PnP デバイスを完全に設定するかもしれませんが、デバイ
スドライバの設定は行いません。これは読者の皆さんが望む動作ですが、PnP
BIOS が行った設定を正確に調べることは必ずしも容易ではありません。

<!--
If you tell the BIOS that you don't have a PnP OS, then the PnP BIOS
should do the configuring of all PnP serial ports -/-not just the first
two.  An indirect way to control what the BIOS does (if you have
Windows 9x on the same PC) is to "force" a configuration under
Windows.  See Plug-and-Play-HOWTO and search for "forced".  It's
easier to use the CMOS BIOS menu which may override what you 
"forced" under Windows.  There could be a BIOS option that can set or
disable this "override" capability.
-->
PnP OS を持っていないことを BIOS に設定してあれば、PnP BIOS は最初の 2 
つだけでなく全ての PnP シリアルポートの設定を行うはずです。
BIOS の動作を間接的に制御する方法は(もし MS Windows9x を同じ PC で使っ
ていれば)、Windows における設定を「強制」することです。
Plug-and-Play-HOWTO を「forced」で検索してください。Windows 上で「強制」
した設定を CMOS BIOS メニューを使って上書きするのは簡単です。
この「上書き」機能の設定・解除が行える BIOS オプションがあると思います。

<!--
If you add a new PnP device, the BIOS should change its PnP
configuration to accommodate it.  It could even change the io-irq of
existing devices if required to avoid any conflicts.  For this
purpose, it keeps a list of non-PnP devices provided that you have
told the BIOS how these non-PnP devices are io-irq configured.  One
way to tell the BIOS this is by running a program called ICU under
DOS/Windows.
-->
新しい PnP デバイスが追加されると、BIOS は PnP 設定を変更して調整を行
わなければなりません。衝突を避ける必要が生じれば、既存のデバイスの I/O 
と IRQ の設定が変わることもあります。この目的のため、非 PnP デバイスの 
I/O と IRQ をどのように設定しているのかを BIOS に教えてあれば、BIOS は
非 PnP デバイスのリストを保存しています。これを BIOS に教える方法の一
つは、DOS/Windows 上で ICU と呼ばれるプログラムを実行することです。

<!--
But how do you find out what the BIOS has done so that you set up the
device drivers with this info?  The BIOS itself may provide some info,
either in its setup menus of via messages on the screen when you turn
on your computer.  See <ref id="io-irq_in_hdw" name="What is set in my
serial port hardware?"
-->
しかし、この情報でデバイスドライバを設定するために、BIOS が行った設定
を調べるにはどうすればよいでしょうか? BIOS 自身もある程度の情報を出し
ます。これは設定メニューや、コンピュータの起動時に画面に現われるメッ
セージを通じて得られます。
<ref id="io-irq_in_hdw" name="シリアルポートのハードウェアの設定は?">
をご覧ください。

<!--
<sect1> Giving the IRQ and IO Address to Setserial
-->
<sect1> IRQ と I/O アドレスを setserial に与える
<!--
<p> Once you've set the IRQ and IO address in the hardware (or arranged
for it to be done by PnP) you also need to insure that the "setserial"
command is run each time you start Linux.  See the subsection <ref
id="sets_boot_time" name="Boot-time Configuration"> 
-->
<p> いったんハードウェアの IRQ と I/O アドレスを設定したら(あるい
は PnP で割り当てられるようにしたら)、今度は Linux が起動される度に 
"setserial" コマンドが実行されるようにする必要があります。
<ref id="sets_boot_time" name="起動時の設定">の節をご覧ください。
<!-- 原文のコメント -->
<!-- configure.H end-->

<!--
<sect1> High-level Configuring: stty, etc.  
-->
<sect1> 高レベルの設定: stty など
<!--
<p> As a rule, your application program will do most (or all) of this.
The command which does it is <tt/stty/.  See <ref id="stty_"
name="Stty">
-->
<p> 原則としては、アプリケーションプログラムが設定の大部分(あるいは全
て)を行います。これを行うコマンドは <tt/stty/ です。
<ref id="stty_" name="stty"> をご覧ください。

<!--
<sect2> Configuring Flow Control: Hardware Flow Control is Best
-->
<sect2> フロー制御の設定: ハードウェアフロー制御がベストです
<!--
<p> See <ref id="flow_control" name="Flow Control"> for an explanation of
it.  It's usually better to use hardware flow control rather than
software flow control using Xon/Xoff.  To use full hardware flow
control you must normally have two wires for it in the cable between
the serial port and the device.  If the device is on a card, then it
should always be possible to use hardware flow control.  
-->
<p> 解説が<ref id="flow_control" name="フロー制御">にあるので、そちら
もご覧ください。普通は Xon/Xoff を使ったソフトウェアフロー制御よりもハー
ドウェアフロー制御を使う方がいいでしょう。完全なハードウェアフロー制御
を用いるには普通、シリアルポートとデバイスを接続するケーブル内にフロー
制御用の線が 2 本必要です。デバイスがカード上にあるならば、確実にハー
ドウェアフロー制御が使えるはずです。

<!--
Many applications (and the getty program) give you an option
regarding flow control and will set it for you.  It might even set
hardware flow control by default.  Like the IRQ and IO address, it
must be set both in the serial driver and the hardware connected to
the serial port.  How it's set into the hardware is hardware
dependent.  Often there is a certain "init string" you send to the
hardware device via the serial port from your PC.  For a modem, the
communication program should set it in both places.
-->
多くのアプリケーション(と getty プログラム)には、フロー制御に関するオ
プションがあり、必要に応じて設定できます。デフォルトでハードウェアフロー
制御を設定することもできます。IRQ と I/O アドレスのように、フロー制御
もシリアルドライバとシリアルポートに接続されているハードウェアの両方に
設定しなければなりません。
ハードウェアの設定方法は、ハードウェアによって異なります。
多くの場合は、PC からシリアルポート経由でハードウェ
アデバイスに送る特定の「初期化文字列」があります。モデムの場合は、通信
プログラムは両方の設定を行うはずです。

<!--
If a program you use doesn't set flow control in the serial driver,
then you may do it yourself using the <tt/stty/ command.  Since the
driver doesn't remember the setting after you stop Linux, you could
put the stty command in a file that runs at start-up or when you
login (such as /etc/profile for the bash shell).  Heres what you would
add for hardware flow control for port ttyS2:
-->
お使いのプログラムがシリアルドライバのフロー制御を設定しない場合には、
<tt/stty/ コマンドを使って自分で設定できます。ドライバは 
Linux が停止した時の設定を覚えていないので、起動時やログイン時に実行さ
れるファイル(シェルが bash の場合には /etc/profile など)に stty コマンドを入れ
ておくとよいでしょう。以下にポート ttyS2 でハードウェアフロー制御を行
うために追加する内容を示します:

<!--
<tscreen><verb> 
stty crtscts < /dev/ttyS2 
or for stty version >= 1.17:
stty -F /dev/ttyS2 crtscts
</verb></tscreen> 
-->
<tscreen><verb> 
stty crtscts < /dev/ttyS2 
stty のバージョンが 1.17 以上の場合は:
stty -F /dev/ttyS2 crtscts
</verb></tscreen> 

<!--
<tt/crtscts/ stands for a Control setting to use the RTS and CTS pins of
the serial port for hardware flow control.  The upper case
letters of the last sentence spell: <tt/crtscts/.
-->
<tt/crtscts/ は、シリアルポートの RTS と CTS ピンを使ってハードウェア
フロー制御を行う設定の指定を表します。前の文の大文字を
<tt/crtscts/ と綴ります。

<!--
<sect> Serial Port Devices /dev/ttyS2, etc. <label id="ttySN_">
-->
<sect> シリアルポートデバイス: /dev/ttyS2 等 <label id="ttySN_">
<!-- 原文のコメント -->
<!-- device_dir.H begin
<sect> Serial Port Devices /dev/ttyS2, etc. -->

<!--
<p> For creating devices in the device directory see 

<ref id="create_dev" name="Creating Devices In the /dev directory">
-->
<p>デバイスディレクトリにデバイスを作成する方法については
<ref id="create_dev" name="/dev ディレクトリにおけるデバイスの作成方法">
をご覧ください。

<!--
<sect1>Serial Port Device Names &amp; Numbers <label id="dev_nos">
-->
<sect1>シリアルポートデバイスの名前と番号 <label id="dev_nos">
<!--
<p> Devices in Linux have major and minor numbers.  Each serial port
may have 2 possible names in the /dev directory: ttyS and cua.   Their
drivers behave slightly differently.  The cua device is deprecated and
will not be used in the future. 
See the Modem-HOWTO section: "The cua Device".
-->
<p>Linux のデバイスはメジャー番号とマイナー番号を持っています。シリア
ルポートはそれぞれ、/dev ディレクトリで 2 つの名前を持つ可能性がありま
す。すなわち ttyS と cua です。これらのドライバは少し異なった動作をし
ます。cua デバイスは使わないことが勧められており、将来は使われなくなり
ます。Modem-HOWTO の「cua デバイス」の章をご覧ください。

<!--
Dos/Windows use the COM name while the <tt/setserial/ program uses
tty00, tty01, etc.  Don't confuse these with dev/tty0, dev/tty1, etc.
which are used for the console (your PC monitor) but are not serial
ports.  The table below is for the "standard" case (but yours could be
different).
-->
DOS/Windows は COM という名前を使いますが、<tt/setserial/ プログラムで
は tty00, tty01 といった名前を使います。これらを dev/tty0, dev/tty1 等
と混同しないでください。dev/tty0 等はコンソールデバイス(PC のモニタ)の
名前であり、シリアルポートではありません。
以下の表はアドレスの「標準的な」対応を示します(読者の皆さんの場合は異なる
かもしれません)。

<!--
<tscreen><verb>
       				 		  IO
 dos		major minor	  major minor  address
COM1  /dev/ttyS0  4,  64;  /dev/cua0  5,  64      3F8
COM2  /dev/ttyS1  4,  65;  /dev/cua1  5,  65      2F8
COM3  /dev/ttyS2  4,  66;  /dev/cua2  5,  66      3E8
COM4  /dev/ttyS3  4,  67;  /dev/cua3  5,  67      2E8
</verb></tscreen>
-->
<tscreen><verb>
       				 		           I/O
 DOS		メジャー マイナー        メジャー マイナー アドレス
COM1  /dev/ttyS0   4,      64;  /dev/cua0   5,      64      3F8
COM2  /dev/ttyS1   4,      65;  /dev/cua1   5,      65      2F8
COM3  /dev/ttyS2   4,      66;  /dev/cua2   5,      66      3E8
COM4  /dev/ttyS3   4,      67;  /dev/cua3   5,      67      2E8
</verb></tscreen>
<!--O
Note that all distributions should come with ttyS devices (and many
distributions have the obsolete cua device).  You can verify this by
typing (don't feel bad if you don't find any obsolete cua devices): 

Note that all distributions should come with ttyS devices (and cua
devices until cua is finally abolished).  You can
verify this by typing: 
-->
全てのディストリビューションに ttyS デバイスが付いているはず(多くの
ディストリビューションには古い cua デバイスもあるはず)である点に注意し
てください。これは以下のコマンドを実行すれば確かめられます(古い cua
デバイスがなくても心配する必要はありません):

<tscreen><verb>
linux% ls -l /dev/cua*
linux% ls -l /dev/ttyS*
</verb></tscreen>

<!--O
<sect1> Link ttySN to /dev/modem ?
-->
<sect1> ttySN から /dev/modem にリンクを張るべきかどうか
<!--
<p> On some installations, two extra devices will be created, 
<tt>/dev/modem</tt> for your modem and <tt>/dev/mouse</tt> for your 
mouse.  Both of these are symbolic links to the appropriate 
device in <tt>/dev</tt> which you specified during the 
installation (unless you have a bus mouse, then <tt>/dev/mouse</tt> 
will point to the bus mouse device).
-->
<p>一部のインストーラは 2 つの追加デバイスを作ります。すなわち
モデム用の <tt>/dev/modem</tt> とマウス用の <tt>/dev/mouse</tt> です。
どちらも <tt>/dev</tt> ディレクトリにある適切なデバイスへのシンボリッ
クリンクです。このリンク先のデバイスはインストール時に選択されています
(ただしバスマウスの場合はこの限りではなく、<tt>/dev/mouse</tt> はバス
マウスのデバイスへのリンクとなります)。

<!--
There has been some discussion on the merits of <tt>/dev/mouse</tt>
and <tt>/dev/modem</tt>.  The use of these links is discouraged.  In
particular, if you are planning on using your modem for dialin you may
run into problems because the lock files may not work correctly if you
use <tt>/dev/modem</tt>.  However, if you change or remove this
link, some applications might need reconfiguration.
-->
<tt>/dev/mouse</tt> と <tt>/dev/modem</tt> の利点については、過去に
何度も議論がありました。これらのリンクの使用はお勧めできません。特に、
モデムをダイアルイン用に使おうと考えている場合には、
<tt>/dev/modem</tt> を用いるとロックファイルが正しく動作しないことがあ
り、問題が起きるかもしれません。しかし、リン
クを張り直したり削除した場合には、一部のアプリケーションは再設定が必要
になるかもしれません。
<!-- device_dir.H end -->

<!--
<sect1>Notes For Multiport Boards
-->
<sect1>マルチポートボードに関する注意
<p>
<!--
For board addresses, and IRQs, look at the <tt/rc.serial/
or <tt>/etc/rc.boot/0setserial</tt> that comes with the <tt/setserial/
program.  It has a lot of detail on multiport boards, including I/O
addresses and device names. 
-->
ボードの アドレスと IRQ については、<tt/setserial/ プログラムに付属し
ている <tt/rc.serial/ や <tt>/etc/rc.boot/0setserial</tt> を見てくださ
い。マルチポートボードについては I/O アドレスやデバイス名を含む細かい
話がたくさんあります。

<!--
<sect1>Creating Devices In the /dev directory <label id="create_dev">
-->
<sect1>/dev ディレクトリにおけるデバイスの作成方法 <label id="create_dev">
<p>
<!--
If you don't have a device, you will have to create it with the 
<tt/mknod/ command.  Example, suppose you needed to create devices 
for <tt/ttyS0/:
-->
デバイスが存在しなければ、<tt/mknod/ コマンドを使ってこれを作成しなけ
ればならないでしょう。例えば <tt/ttyS0/ に対するデバイスを作成する必要
があるとします:
<!--O
<tscreen><verb>
linux# mknod -m 666 /dev/cua0 c 5 64 (cua devices are now obsolete)
linux# mknod -m 666 /dev/ttyS0 c 4 64
</verb></tscreen>
-->
<tscreen><verb>
linux# mknod -m 666 /dev/cua0 c 5 64 (cua デバイスは既に過去のものです)
linux# mknod -m 666 /dev/ttyS0 c 4 64
</verb></tscreen>
<!--
You can use the <tt/MAKEDEV/ script, which lives in <tt>/dev</tt>.
See the man page for it.  This simplifies the making of devices.  For
example, if you needed to make the devices for <tt>ttyS0</tt> you
would type:
-->
<tt/MAKEDEV/ スクリプトを使うこともできます。このスクリプトは
<tt>/dev</tt> ディレクトリにあります。
マニュアルページを見てください。
このスクリプトを使うと、デバイスを簡単に作成できます。
例えば <tt>ttyS0</tt> に対応するデバイスを作る必要がある場合には、
以下のコマンドを実行します:
<tscreen><verb>
linux# cd /dev
linux# ./MAKEDEV ttyS0
</verb></tscreen>
<!--
This handles the devices creation and should set the correct permissions.
-->
このスクリプトはデバイスの作成処理と正しいパーミッションの設定を行いま
す。

<!--
<sect>Interesting Programs You Should Know About
-->
<sect>知っておくとよい便利なプログラム
<!--
<p> Most info on getty has been moved to Modem-HOWTO with a little info on
the use of getty with directly connected terminals now found in
Text-Terminal-HOWTO.
-->
<p>getty に関する情報のほとんどは Modem-HOWTO に移動しました。
端末に直接接続する getty の使用法に関する情報が Text-Terminal-HOWTO に
少し書かれています。

<!--
<sect1> Serial Monitoring/Diagnostics Programs <label id="serial_mon">
-->
<sect1> シリアルポートの監視/診断用のプログラム <label id="serial_mon">
<!--
<p> A few Linux programs will monitor various modem control lines and
indicate if they are positive (1 or green) or negative (0 or red).
-->
<p>各種モデム制御線を監視し、これが正(1 または緑)であるか負(0 または赤)
であるかを示すプログラムがいくつかあります。
<itemize>
<!--
<item> modemstat (Only works correctly on Linux PC consoles.  Status
 monitored in a tiny window.  Color-coded and compact.  Must kill
 process to quit.)
-->
<item> modemstat (Linux の PC コンソール上でしか正しく動作しません。小
さいウィンドウで状態を表示します。色付きですし、コンパクトです。終了す
るには kill しなければなりません)
<!--O
<item> statserial (Info displayed on entire screen)
-->
<item> statserial (画面全体を使って情報を表示します)
<!--
<item> serialmon (Doesn't monitor RTS, CTS, DSR but logs other
  functions)
-->
<item> serialmon (RTS, CTS, DSR の監視は行いませんが、他の機能のログを
残します)
</itemize>
<!--
You may already have them.  If not, download them from <url url=
"http://metalab.unc.edu/pub/Linux/system/serial/" name="Serial
Software">.  As of June 1998, I know of no diagnostic program in Linux
for the serial port.  
-->
これらのプログラムのいくつかは既に使えるようになっているかもしれません。
そうでない場合には、<url url=
"http://metalab.unc.edu/pub/Linux/system/serial/" name="シリアル用ソフトウェア">
から入手してください。1998 年 6 月の時点では、筆者は Linux 用のシリア
ルポート監視プログラムを知りません。

<!--
<sect1> Changing Interrupt Priority
-->
<sect1> 割り込みの優先度の変更
<p> 
<itemize>
<!--
<item> <tt/irqtune/ will give serial port interrupts higher
 priority to improve performance.
-->
<item> <tt/irqtune/ はシリアルポートの割り込みの優先度を高くし、
効率を向上させます。
<!--
<item> <tt/hdparm/ for hard-disk tuning may help some more.
-->
<item> ハードディスクのチューニングを行う <tt/hdparm/ があればさらに
便利でしょう。
</itemize>

<!--
<sect1>What is Setserial ? <label id="set_serial">
-->
<sect1>setserial とは何か? <label id="set_serial">
<!-- 原文のコメント -->
<!-- setserial.H  begin  (in MM TT SS)
<sect1>What is Setserial ? <label id="set_serial"> -->
<!--O
<p> This part is in 3 HOWTOs: Modem, Serial, and Text-Terminal.  There
are some minor differences, depending on which HOWTO it appears in.
-->
<p>この節は 3 つの HOWTO(Modem, Serial, Text-Terminal)に入っています。
HOWTO によって内容が多少異なります。

<!--
<sect2> Introduction
-->
<sect2> はじめに
<!--
<p> Don't ever use <tt/setserial/ with Laptops (PCMCIA).
-->
<p> ラップトップ機(PCMCIA)では絶対に <tt/setserial/ を使わないでください。
<!--
<tt/setserial/ is a program which allows you to tell the device driver
software the I/O address of the serial port, which interrupt (IRQ) is
set in the port's hardware, what type of UART you have, etc.  It can
also show how the driver is currently set.  In addition, it can be
made to probe the hardware and try to determine the UART type and IRQ,
but this has severe limitations.  See <ref id="probing_ss"
name="Probing">.  Note that it can't set the IRQ, etc in the hardware
of PnP serial ports.
-->
<tt/setserial/ は、シリアルポートの I/O アドレスやポートの
ハードウェアに設定されている割り込み(IRQ)、使用している UART の種類等
をデバイスドライバのソフトウェアに伝えられるようにするプログラムです。
このプログラムは、現在ドライバに設定されている内容の表示も行います。
加えて、
ハードウェアを探査して UART の種類や IRQ を調べさせることもできますが、
これには厳しい制限があります。
<ref id="probing_ss" name="探査">の節を見てください。
<tt/setserial/ は PnP シリアルポートのハードウェアの IRQ 等を設定でき
ない点に注意してください。

<!--
If you only have one or two built-in serial ports, they will usually
get set up correctly without using setserial.  Otherwise (or if there
are problems with the serial port) you will likely need to deal with
setserial.  Besides the man page for <tt/setserial/, check out info in
<tt>/usr/doc/setserial.../</tt> or <tt>/usr/share/doc/setserial</tt>.
It should tell you how setserial is handled in your distribution of
Linux.  
-->
組み込みのシリアルポートが 1 つか 2 つしかなければ、普通は setserial 
を使わなくても正しく設定されます。シリアルポートがこれ以上ある場合(ま
たはシリアルポートに問題がある場合)には、setserial を使う必要があるで
しょう。
<tt/setserial/ のマニュアルページ以外にも、
<tt>/usr/doc/setserial.../</tt> や <tt>/usr/share/doc/setserial</tt> 
の情報を調べてください。お使いの Linux
ディストリビューションでの setserial の扱いが書かれているはずです。

<!--
<tt/Setserial/ is often run automatically at boot-time by a start-up
shell-script for the purpose of assigning IRQs, etc. to the driver.
Setserial will only work if the serial module is loaded (or if the
equivalent was compiled into your kernel).  If you should (for some
reason) unload the serial module later on, the changes previously made
by <tt/setserial/ will be forgotten by the kernel.  So <tt/setserial/
must be run again to reestablish them.  In addition to running via a
start-up script, something akin to <tt/setserial/ also runs when the
serial module is loaded (or the like).  Thus when you watch the
start-up messages on the screen it may look like it ran twice, and in
fact it has.
-->
<tt/setserial/ はドライバに IRQ 等を割り当てるために、多くの場合は起動
時に起動スクリプトが自動的に実行します。
<tt/setserial/ は serial モジュールがロードされている場合(または同等の
機能がカーネル構築時に組み込まれている場合)にしか動作しません。
(何らかの理由で)serial モジュールを後からアンロードする
と、カーネルは以前に <tt/setserial/ で行った設定を忘れます。
したがって、設定を元に戻すためには <tt/setserial/ を再び実行しなければ
なりません。起動
スクリプト経由での実行に加え、serial モジュール(など)がロードされた時
には <tt/setserial/ に似た何らかのプログラムも実行されます。
したがって、画面上で
起動メッセージを見る時に <tt/setserial/ が 2 度実行されたように見える
かもしれませんが、実際に 2 度実行されているのです。

<!--
Setserial can set the time that the port will keep operating after
it's closed (in order to output any characters still in its buffer in
main RAM).  This is needed at slow baud rates of 1200 or lower.  It's
also needed at higher speeds if there are a lot of "flow control"
waits.  See "closing_wait" in the man pg.
-->
setserial を使って、ポートがクローズされた後に動作し続ける時間を設定す
ることができます(これは、メイン RAM 上のバッファにまだ残っている文字を
全て出力させるためです)。この設定はボーレートが遅い(1200 以下)場合には
必要です。また「フロー制御」によるウェイトが多くかかる場合には、速度が
速くても必要となります。
マニュアルページの "closing_wait" を見てください。


<!--
Setserial does not set either IRQ's nor I/O addresses in the serial
port hardware itself.  That is done either by jumpers or by
plug-and-play.  You must tell setserial the identical values that have
been set in the hardware.  Do not just invent some values that you
think would be nice to use and then tell them to setserial.  However,
if you know the I/O address but don't know the IRQ you may command
setserial to attempt to determine the IRQ.  
-->
<tt/setserial/ は、シリアルポートのハードウェアそのものの IRQ や I/O 
アドレスの設定は行いません。ハードウェアの設定は、ジャンパまたはプラグ
&amp;プレイで行います。<tt/setserial/ には、ハードウェアに既に設定され
ているのと同じ値を指定しなければなりません。使えると思うアドレスを勝手
にでっちあげて、それを setserial に教えてはいけません。しかし、I/O ア
ドレスが分かっているけれど IRQ が分からない場合には、<tt/setserial/ に 
IRQ を調べるように指示することもできます。

<!--O
You can see a list of possible commands by just typing <tt/setserial/
with no arguments.  This fails to show you the one-letter options such
as -v for verbose which you should normally use when troubleshooting.
Note that setserial calls an IO address a "port".  If you type:
-->
使用可能なコマンドの一覧は、単に引き数無しで <tt/setserial/ を実行すれ
ば表示されます。このコマンドは、トラブル処理の際に普通使う詳細表示
オプションである -v のような 1 文字オプションは表示できません。
<tt/setserial/ では I/O アドレスのことを「ポート」と呼ぶ点に注意してく
ださい。
<tscreen><verb>
setserial -g /dev/ttyS*
</verb></tscreen> 
<!--O
you'll see some info about how that device driver is configured for

your ports.  Add a -a to the option -g to see more info although few
people need to deal with (or understand) this additional info since
the default settings you see usually work fine.  In normal cases the
hardware is set up the same way as "setserial" reports, but if you are
having problems there is a good chance that "setserial" has it wrong.
In fact, you can run "setserial" and assign a purely fictitious I/O
port address, any IRQ, and whatever uart type you would like to have.
Then the next time you type "setserial ..." it will display these
bogus values without complaint.  Of course the serial port driver will
not work correctly (if at all) with such bogus values.  
-->
を実行すると、そのポートに関するデバイスドライバの設定状況が表示されま
す。詳しい情報を表示させるには "-g" オプションに "-a" を追加します。
ただし、ほとんどの人はこの追加の情報を扱う(あるいは理解する)必要はありま
せん。なぜなら普通はデフォルトの設定で十分だからです。普通の場合は、
ハードウェアは "setserial" が報告するのと同じ設定になっていますが、
問題がある場合には、"setserial" が間違っている可能性が高いでしょう。
実際、<tt/setserial/ を実行して全く嘘の I/O ポートアドレスや IRQ, UART 
を設定することができます。それ以降に "setserial ..." を実行すると、この嘘
の値がエラーメッセージもなしに表示されます。もちろん、このような間違っ
た値ではシリアルポートドライバは(動くとしても)正しく動作しません。

<!--O
While assignments made by setserial are lost when the PC is powered
off, a configuration file may restore them (or a previous
configuration) when the PC is started up again.  In newer versions,
what you change by setserial gets automatically saved to a
configuration file.  In older versions, the configuration file only
changes if you edit it manually so the configuration remains the same
from boot to boot.  See <ref id="ss_conf_script" name="Configuration
Scripts/Files">
-->
<tt/setserial/ による設定は PC の電源を切ると消えますが、PC の電源を再
び入れた時には設定ファイルの情報(または前の設定)が残っているかもしれま
せん。最近のバージョンでは <tt/setserial/ を使って変更した設定は自動的
に設定ファイルに保存されます。古いバージョンでは、設定ファイルはユーザ
が手で編集した時しか内容が変わらないので、何度起動しても同じ設定が使わ
れます。<ref id="ss_conf_script" name="設定スクリプト/ファイル">の節を
見てください。

<!--
<sect2> Probing <label id="probing_ss">
-->
<sect2> 探査 <label id="probing_ss">
<!--O
<p> With appropriate options, <tt/setserial/ can probe (at a given I/O
address) for a serial port but you must guess the I/O address.  If you
ask it to probe for /dev/ttyS2 for example, it will only probe at the
address it thinks ttyS2 is at (2F8).  If you tell setserial that ttyS2
is at a different address, then it will probe at that address, etc.
See <ref id="probing_ss" name="Probing">
-->
<p>適切なオプションを使えば、<tt/setserial/ は(指定された I/O アドレス
について)シリアルポートを探査できますが、そのためには I/O アドレスを推
定しなければなりません。例えば <tt/setserial/ に /dev/ttyS2 を探査させ
ると、<tt/setserial/ は ttyS2 があるとコマンド自身が思っているアドレス
(2F8)しか探査しません。ttyS2 が別のアドレスにあることを <tt/setserial/ 
に指示した場合は、<tt/setserial/ はそのアドレスを探査します。
<ref id="probing_ss" name="探査">の節を見てください。

<!--O
The purpose of this is to see if there is a uart there, and if so,
what its IRQ is.  Use "setserial" mainly as a last resort as there are
faster ways to attempt it such as wvdialconf to detect modems, looking
at very early boot-time messages, or using <tt>pnpdump
-/-dumpregs</tt>.  To try to detect the physical hardware use the -v
(verbose) and <tt/autoconfig/ command to <tt/setserial/.  If the
resulting message shows a uart type such as 16550A, then you're OK.
If instead it shows "<tt/unknown/" for the uart type, then there is
supposedly no serial port at all at that I/O address.  Some cheap
serial ports don't identify themselves correctly so if you see
"<tt/unknown/" you still might have a serial port there.  
-->
<p><tt/setserial/ の目的は UART がそこにあるかどうか調べ、もし UART が
あればその IRQ を調べることです。"setserial" は最後の手段として使って
ください。というのも、こういったことを行うにはもっと早い方法
(モデムの検出に wvdialconf を使ったり、起動メッセージのごく最初の部分
を見たり、<tt>pnpdump --dumpregs</tt> を使う等)があるからです。
物理的なハードウェアの検出を試す場合に
は、<tt/setserial/ の -v オプション(詳細表示)と <tt/autoconfig/ コマン
ドを使ってください。得られる出力が 16550A といった UART の種類であれば
成功です。逆に UART の種類について "<tt/unknown/" と表示された場合には、
その I/O アドレスにはシリアルポートは全くないと思われます。一部の安物
のシリアルポートはうまく認識されないので、"<tt/unknown/" と表示されて
もそこにシリアルポートが存在することもあります。

<!--
Besides auto-probing for a uart type, setserial can auto-probe for
IRQ's but this doesn't always work right either.  In versions of
setserial >= 2.15, the results of your last probe test may be saved
and put into the configuration file <tt>/etc/serial.conf</tt> which
will be used next time you start Linux.  At boot-time when the serial
module loads (or the like), a probe for UARTs is made automatically
and reported on the screen.  But the IRQs shown may be wrong.  The
second report of the same is the result of a script which usually does
no probing and thus provides no reliable information as to how the
hardware is actually set.  It only shows configuration date someone
wrote into the script or data that got saved in /etc/serial.conf.
-->
setserial は UART の種類の自動検出以外にも IRQ の自動検出ができますが、
これも必ずしも正しく動作するとは限りません。バージョン 2.15 以上の 
setserial では最後の探査の結果は保存され、設定ファイル 
<tt>/etc/serial.conf</tt> に格納されるかもしれません。
このファイルは、次に Linux を起動する時に使われます。
起動時に serial モジュールがロードされる等した時は、UART の探査は
自動的に行われ、その結果が画面に出力されます。
しかし、表示される IRQ は間違っているかもしれません。
同じものをもう一度出力させた時に得られるのは、普通は探査を行わず、
したがってハードウェアの実際の設定について信頼できる情報を出力しない
スクリプトの実行結果です。
単に誰かがスクリプトに書き込んだ設定データか /etc/serial.conf に保存さ
れた設定データが表示されているだけです。

<!--O
It may be that two serial ports both have the same IO address set in
the hardware.  Of course this is not permitted but it sometimes
happens anyway.  Probing detects one serial port when actually there
are two.  However if they have different IRQs, then the probe for IRQs
may show IRQ = 0.  For me it only did this if I first used
<tt/setserial/ to give the IRQ a ficticious value.
-->
2 つのシリアルポートのハードウェアに同じ  I/O アドレスが設定されている
ことがあります。もちろんこれは認められていないのですが、実際にそういう
ことは起こります。一つのアドレスに実際にシリアルポートが 2 つある時も、
探査では一つのシリアルポートしか検出されません。しかし、違う IRQ が設
定してあれば、IRQ の探査で IRQ = 0 が表示されるかもしれません。筆者の
場合は、こうなったのは最初に <tt/setserial/ を使って嘘の値を設定した時
だけです。

<!--O
<sect2> Boot-time Configuration <label id="sets_boot_time">
-->
<sect2> 起動時の設定 <label id="sets_boot_time">
<!--O
<p> When the kernel loads the serial module (or if the "module
equivalent" is built into the kernel) then only <tt/ttyS{0-3}/ are
auto-detected and the driver is set to use only IRQs 4 and 3
(regardless of what IRQs are actually set in the hardware).  You see
this as a boot-time message just like as if <tt/setserial/ had been
run.  If you use 3 or more ports, this may result in IRQ conflicts. 
-->
<p> カーネルが serial モジュールをロードする時(または「モジュール相当
のもの」がカーネルに組み込まれている場合)には、<tt/ttyS{0-3}/ だけが
自動検出され、ドライバは IRQ 4 と 3 しか使わないように設定されます(
ハードウェアに実際に設定されている IRQ に関わらず)。これは 
<tt/setserial/ を実行したときのように、起動メッセージとして表示されま
す。3 つ以上のシリアルポートを使っていると、IRQ の衝突が起きてしまうか
もしれません。

<!--O
To fix such conflicts by telling setserial the true IRQs (or for other
reasons) there may be a file somewhere that runs <tt/setserial/ again.
This happens early at boot-time before any process uses the serial
port.  In fact, your distribution may have set things up so that the
setserial program runs automatically from a start-up script at
boot-time.  More info about how to handle this situation for your
particular distribution might be found in file named "setserial..."
or the like located in directory /usr/doc/ or /usr/share/doc/.
-->
正しい IRQ を setserial に教えてこういった衝突を回避するために(あるい
は別の理由のために)、<tt/setserial/ を再び実行するファイルがどこかにあ
るかもしれません。これはシリアルポートを使う他のどのプロセスよりも前に、
起動の最初の方のステップで実行されます。実際、読者の皆さんが使っている
ディストリビューションでも、起動時に setserial プログラムが起動スクリ
プトから自動的に実行されるように設定されているかもしれません。
お使いのディストリビューションでの扱い方についての詳しい説明は、
/usr/doc/ や /usr/share/doc/ というディレクトリにある
"setserial..." のような名前のファイルに書かれているかもしれません。

<!--O
<sect2> Configuration Scripts/Files <label id="ss_conf_script">
-->
<sect2>設定スクリプト/ファイル<label id="ss_conf_script">
<!--O
<p> Your objective is to modify (or create) a script file in the /etc
tree that runs setserial at boot-time.  Most distributions provide
such a file (but it may not initially reside in the /etc tree).  In
addition, setserial 2.15 and higher often have an /etc/serial.conf
file that is used by the above script so that you don't need to
directly edit the script that runs setserial.  In addition just using
setserial on the command line (2.15+) may ultimately alter this
configuration file.
-->
<p>ここでの目的は /etc ツリーにあって起動時に setserial を実行する
スクリプトを修正(または作成)することです。ほとんどの
ディストリビューションにはそのためのファイルが付属しています(しかし最
初は /etc ツリーに置かれていないかもしれません)。さらに、バージョン
2.15 以降の setserial は大抵 /etc/serial.conf ファイルを持っています。
これは setserial を実行するスクリプトが使うファイルで、ユーザが
スクリプトを直接編集する必要をなくすためのものです。さらに、
(バージョン 2.15 以降では)コマンドラインから setserial を使うだけで
最終的に設定ファイルを変更できます。

<!--O
So prior to version 2.15 all you do is edit a script.  After 2.15 you
may need to either do one of three things: 1. edit a script.  2. edit
<tt>/etc/serial.conf</tt> or 3. run "setserial" on the command line
which will result in <tt>/etc/serial.conf</tt> automatically being
edited.  Which one of these you need to do depends on both your
particular distribution, and how you have set it up.
-->
したがって、バージョン 2.15 より前ならばすべきことはスクリプトを編集す
ることだけです。バージョン 2.15 以降では、次の 3 つの作業のどれかを行えば
大丈夫です: 1. スクリプトを編集する。 2. <tt>/etc/serial.conf</tt>
を編集する。 3. コマンドラインから "setserial" を実行し、自動的に 
<tt>/etc/serial.conf</tt> を編集させる。このうちのどれを使う必要がある
かは、お使いのディストリビューションや設定の方法によります。

<!--O
<sect2> Edit a script (after version 2.15: perhaps not)
 <label id="old_sets_script">
-->
<sect2> スクリプトの編集 (バージョン 2.15 以降ではたぶん使いません)
 <label id="old_sets_script">
<!--O
<p> Prior to setserial 2.15 (1999) there was no /etc/serial.conf file
to configure setserial.   Thus you need to find the file that runs
"setserial" at boot time and edit it.  If it doesn't exist, you need
to create one (or place the commands in a file that runs early at
boot-time).  If such a file is currently being used it's likely
somewhere in the /etc directory-tree.  But Redhat <6.0 has supplied it
in /usr/doc/setserial/ but you need to move it to the /etc tree before
using it.   You might use "locate" to try to find such a file.  For
example, you could type: locate "*serial*".   
-->
<p> setserial のバージョンが 2.15 (1999年)より前の場合、setserial の
設定には /etc/serial.conf は使われません。したがって、起動時に
"setserial" を実行しているファイルを探し、これを編集する必要があります。
このようなファイルが存在しなければ、新しく作る(または起動の初期段階に
実行されるファイルにコマンドを追加する)必要があります。このようなファイルが現在
使われているなら、/etc ディレクトリツリー内のどこかにあるでしょう。し
かし、バージョン 6.0 より前の RedHat ではこのファイルは
/usr/doc/setserial/ に置かれているので、使う前には /etc ツリーに移動さ
せる必要があります。このようなファイルを見つけるには "locate" コマンド
を使うとよいでしょう。例えば、'locate "*serial*" ' のように入力します。

<!--O
The script <tt>/etc/rc.d/rc.serial</tt> was commonly used in the past.
The Debian distribution used <tt>/etc/rc.boot/0setserial</tt>.
Another file once used was <tt>/etc/rc.d/rc.local</tt> but it's
not a good idea to use this since it may not be run early enough.
It's been reported that other processes may try to open the serial
port before rc.local runs resulting in serial communication failure.
-->
以前は <tt>/etc/rc.d/rc.serial</tt> というスクリプトが一般的に使われて
いました。Debian は <tt>/etc/rc.boot/0setserial</tt> を使っていました。
かつては <tt>/etc/rc.d/rc.local</tt> というファイルも使われていま
したが、このファイルはあまり早くは実行されないので、適切とは言えませ
んでした。rc.local が実行されるよりも前に他のプロセスがシリアルポート
をオープンしようとして、シリアル通信が失敗するという問題が報告されまし
た。

<!--O
If such a file is supplied, it should contain a number of
commented-out examples.  By uncommenting some of these and/or
modifying them, you should be able to set things up correctly.  Make
sure that you are using a valid path for <tt/setserial/, and a valid
device name.  You could do a test by executing this file manually
(just type its name as the super-user) to see if it works right.
Testing like this is a lot faster than doing repeated reboots to get
it right.  Of course you can also test a single <tt/setserial/ command
by just typing it on the command line.
-->
このようなファイルが用意されていれば、その中にはコメントアウトさ
れた指定例がたくさん入っているはずです。これらの一部をアンコメントした
り修正することにより、正しい設定を行えるはずです。
<tt/setserial/ へのパスが正しいことと、デバイス名が正しいことを確かめ
てください。このファイルを手で実行して(単にスーパーユーザとしてファイ
ル名を入力します)正しく動作するかどうか調べることにより、テストを行う
ことができます。こういったテストは何度も再起動して正しい設定にするより
もずっと早く行えます。もちろん、コマンドラインから <tt/setserial/ を実
行することによりコマンド単独のテストも行えます。

<!--O
If you want setserial to automatically determine the uart and the IRQ
for ttyS3 you would add something like:
-->
ttyS3 について UART や IRQ を自動的に setserial に調べさせたければ、
以下のような指定を追加します。

<tscreen><verb>
/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig
</verb></tscreen>
<!--O
Do this for every serial port you want to auto configure.  Be sure to
give a device name that really does exist on your machine.  In some
cases this will not work right due to the hardware so if you know what
the uart and irq actually are, may want to assign them explicitly with
"setserial".  For example:
-->
自動的に設定したい全てのシリアルポートに対してこれを行ってください。実
際にマシン上に存在するデバイス名を必ず使ってください。場合によっては、
これはハードウェアのせいで正しく動作しないので、IRQ や UART の実際の
設定がわかっているのなら、"setserial" を使って明示的にこれらの値を割り
当てるとよいでしょう。例えば、

<tscreen><verb>
/sbin/setserial /dev/ttyS3 irq 5 uart 16550A  skip_test 
</verb></tscreen> 
のようにします。

<!--O
For versions >= 2.15 (provided your distribution implemented the
change, Redhat didn't) it may be more tricky to do since the file that
runs setserial on startup, /etc/init.d/setserial or the like was not
intended to be edited by the user.  See <ref id="new_config"
name="New configuration method using /etc/serial.conf">. 
-->
バージョンが 2.15 以降の場合(お使いのディストリビューションが変更を行っ
ている場合。RedHat は行っていません)には、これを行うのは比較的面倒
かもしれません。というのも、起動時に setserial を実行するファイル
である /etc/init.d/setserial 等はユーザが編集するためのファイルではな
いからです。
<ref id="new_config" name="/etc/serial.conf を用いる新しい設定方法">
の節を見てください。

<!--
<sect2> New configuration method using /etc/serial.conf 
<label id="new_config">
-->
<sect2> /etc/serial.conf を用いる新しい設定方法
<label id="new_config">
<!--
<p> Prior to setserial version 2.15, the way to configure setserial
was to manually edit the shell-script that ran setserial at boot-time.
See <ref id="old_sets_script" name="Edit a script (after version 2.15:
perhaps not)">.  Starting with version 2.15 (1999) of <tt/setserial/
this shell-script is not edited but instead gets its data from a
configuration file: <tt>/etc/serial.conf</tt>.  Furthermore you may
not even need to edit serial.conf because using the "setserial"
command on the command line may automatically cause serial.conf to be
edited appropriately.
-->
<p>バージョン 2.15 より前の setserial では、setserial の設定方法は、
起動時に setserial を実行するシェルスクリプトを手で編集することでした。
<ref id="old_sets_script" name="スクリプトの編集 (バージョン 2.15 以降ではたぶん使いません)">
の節を見てください。
バージョン 2.15 (1999 年) 以降の <tt/setserial/ では、この
シェルスクリプトは編集されないことになり、設定ファイルである 
<tt>/etc/serial.conf</tt> からデータを読み込むようになりました。
さらには <tt>serial.conf</tt> を編集する必要さえないこともあります。
なぜなら、"setserial" コマンドをコマンドラインで使うと、
<tt>serial.conf</tt> は自動的にきちんと編集されるからです。

<!--O
This was intended to make it so that you don't need to edit any file
in order to set up (or change) setserial so it will do the right thing
each time that Linux is booted.  But there are serious pitfalls
because it's not really "setserial" that edits serial.conf.  Confusion
is compounded because different distributions handle this differently.
In addition, you may modify it so it works differently.
-->
この方式なら、わざわざ設定(あるいは設定変更)のためにファイルを編集しな
くても、Linux を起動する度に setserial を正しく動作させられます。
ただし大きな落とし穴があります。というのも、serial.conf を編集する
のは実際には "setserial" ではないということです。ディストリビューション
ごとに扱いが違うため話はなおさらややこしくなっています。
さらに、動作を変えるためにユーザが serial.conf を編集することもできます。

<!--O
What often happens is this:  When you shut down your PC the script
that runs "setserial" at boot-time is run again, but this time it only
does what the part for the "stop" case says to do:  It uses
"setserial" to find out what the current state of "setserial" is and
puts that info into the <tt>serial.conf</tt> file.  Thus when you run
"setserial" to change the serial.conf file, it doesn't get changed
immediately but only when and if you shut down normally.
-->
よく起こるのはこういうことです: ユーザが PC をシャットダウンした時、
起動時に "setserial" を実行するスクリプトは再び実行されますが、今回は
"stop" の分岐に書かれている部分しか実行しません。この部分は 
"setserial" を使って "setserial" の現在の状態を調べ、この情報を
<tt>serial.conf</tt> ファイルに書き込みます。したがって、"setserial" 
を実行して serial.conf ファイルを変更しようとしても、変更は即座に行わ
れるのではなく、マシンを正常にシャットダウンした時にしか行われません。

<!--O
Now you can perhaps guess what problems might occur.  Suppose you
don't shut down normally (someone turns the power off, etc.) and the
changes don't get saved.  Suppose you experiment with "setserial" and
forget to run it a final time to restore the original state (or make a
mistake in restoring the original state).  Then your "experimental"
settings are saved.  
-->
ここまでくればどういう問題が起こる可能性があるのか想像がつくかもしれま
せん。
シャットダウンが正常にできず(誰かが電源スイッチを切る等)、変更が保存さ
れなかった場合を考えてください。また、"setserial" で試行錯誤をしていて、
最後に元の状態に戻すのを忘れていた場合(または元の状態に戻す時にミスを
した場合)を考えてください。すると「試行錯誤中」の設定が保存されてしま
います。

<!--O
If you manually edit serial.conf, then your editing is destroyed when
you shut down because it gets changed back to the state of setserial
at shutdown.  There is a way to disable the changing of serial.conf at
shutdown and that is to remove "###AUTOSAVE###" or the like from first
line of serial.conf.  In at least one distribution, the removal of 
"###AUTOSAVE###" from the first line is automatically done after the
first time you shutdown just after installation.  The serial.conf file
will hopefully contain some comments to help you out.
-->
手動で serial.conf を編集すれば、編集した部分はシャットダウンの時に
破棄されます。なぜなら、シャットダウンの時にその時点の setserial の
状態に戻されるからです。シャットダウンの時に serial.conf を変更させな
いための方法もあります。serial.conf の最初の行に書かれている
"###AUTOSAVE###" といった部分を削除するのです。すくなくともある
ディストリビューションでは、インストール直後の初めてのシャットダウンの
時に最初の行から "###AUTOSAVE###" を削除することは自動的に行われます。
serial.conf にはたぶん、参考になる情報がコメントの形で書かれているでしょ
う。

<!--O
The file most commonly used to run setserial at boot-time (in
conformance with the configuration file) is now /etc/init.d/setserial
(Debian) or /etc/init.d/serial (Redhat), or etc.,  but it should not
normally be edited.  For 2.15 Redhat 6.0 just had a file
/usr/doc/setserial-2.15/rc.serial which you have to move to
/etc/init.d/ if you want setserial to run at boot-time.
-->
起動時に(設定ファイルに従って) setserial を実行す
るために通常使われるファイルは、/etc/init.d/setserial (Debian) や
/etc/init.d/serial (Redhat) 等ですが、普通はこのファイルを編集すべきで
はありません。バージョン 2.15 を使っている RedHat 6.0 では、
起動時に setserial を実行させたい場合に /etc/init.d/ に移動させる
/usr/doc/setserial-2.15/rc.serial ファイルが付いています。

<!--
To disable a port, use <tt/setserial/ to set it to
"uart none".  The format of /etc/serial.conf appears to be just like
that of the parameters placed after "setserial" on the command line
with one line for each port.  If you don't use autosave, you may edit
/etc/serial.conf manually.  
-->
ポートを無効にするには <tt/setserial/ を使って "uart none" を設定しま
す。/etc/serial.conf のフォーマットは、コマンドラインで "setserial" の
後に置くパラメータとほぼ同じものを各ポートについて 1 行ずつ書く形式で
す。自動保存を行っていなければ、/etc/serial.conf を手で編集してくださ
い。

<!--
BUG: As of July 1999 there is a bug/problem since with ###AUTOSAVE###
only the setserial parameters displayed by "setserial -Gg /dev/ttyS*"
get saved but the other parameters don't get saved.  Use the -a flag
to "setserial" to see all parameters.  This will only affect a small
minority of users since the defaults for the parameters not saved are
usually OK for most situations.  It's been reported as a bug and may
be fixed by now. 
-->
BUG: 1999 年 7 月の時点では、###AUTOSAVE### に由来するバグ/問題があり
ます。これは "setserial -Gg /dev/ttyS*" で表示される 
setserial のパラメータしか保存されず、他のパラメータが保存されないとい
うものです。"setserial" の全てのパラメータを表示させるには -a フラグを
使います。
これはごく一部のユーザにしか影響を与えないでしょう。というのも普通、
保存されないパラメータはほとんどの場合はデフォルト値で大丈夫だからです。
これはバグとして報告されているので、現在は修正されているかもしれません。

<!--
In order to force the current settings set by setserial to be saved to
the configuration file (serial.conf) without shutting down, do what
normally happens when you shutdown: Run the shell-script
<tt>/etc/init.d/{set}serial stop</tt>.  The "stop" command will save
the current configuration but the serial ports still keep working OK.
-->
setserial で設定した現在の設定をシャットダウンすることなく設定ファイル
(serial.conf)に保存するには、シャットダウンの時に通常行われる処理をさ
せます。
つまり、シェルスクリプト <tt>/etc/init.d/{set}serial stop</tt> を実行
します。
"stop" コマンドにより現在の設定が保存されますが、シリアルポート自体は
動作したままです。

<!--
In some cases you may wind up with both the old and new configuration
methods installed but hopefully only one of them runs at boot-time.
Debian labeled obsolete files with "...pre-2.15".
-->
場合によっては新旧両方の設定方法がインストールされているかもしれません
が、起動時に実行されるのはたぶんそのうちの片方だけでしょう。Debian で
は、古くて使わないファイルに "...pre-2.15" というラベルが付いています。

<!--
<sect2> IRQs
-->
<sect2> IRQ

<!--
<p> By default, both ttyS0 and ttyS2 share IRQ 4, while ttyS0 and
ttyS3 share IRQ 3.  But sharing serial interrupts is not permitted
unless you: 1. have kernel 2.2 or better, and 2. you've complied in
support for this, and 3. your serial hardware supports it.  See 
 
<ref id="int_share-2.2" name="Interrupt sharing and Kernels 2.2+">

If you only have two serial ports, ttyS0 and ttyS1, you're still OK
since IRQ sharing conflicts don't exist for non-existent devices.  
-->
<p>デフォルトでは、ttyS0 と ttyS2 が IRQ 4 を共有し、ttyS0 と ttyS3 が 
IRQ 3 を共有しています。しかし、次の条件が成り立たなければシリアルの割
り込みの共有はできません: すなわち (1) カーネルが 2.2 以降である、
(2) 割り込みの共有をサポートするようにカーネルをコンパイルしている、
(3) シリアルポートが割り込みの共有をサポートしているという条件です。

<ref id="int_share-2.2" name="割り込みの共有とバージョン 2.2 以降のカーネル">
をご覧ください。

ttyS0 と ttyS1 の 2 つのシリアルポートしか使っていない場合にも問題はあ
りません。というのも、存在しないデバイスについては共有する IRQ の衝突
が起きないからです。

<!--
If you add an internal modem and retain ttyS0 and ttyS1,
then you should attempt to find an unused IRQ and set it both on your
serial port (or modem card) and then use setserial to assign it to
your device driver.  If IRQ 5 is not being used for a sound card, this
may be one you can use for a modem.  To set the IRQ in hardware you
may need to use isapnp, a PnP BIOS, or patch Linux to make it PnP.  To
help you determine which spare IRQ's you might have, type "man
setserial" and search for say: "IRQ 11".  
-->
内蔵モデムを追加した状態でも ttyS0 と ttyS1 をそのままにするならば、未
使用の IRQ を見つけ、これをシリアルポートの両側(またはモデムカード)に
設定し、setserial を使ってデバイスドライバに割り当てなければな
りません。IRQ 5 がサウンドカードに使われて
いなければ、これをモデム用に使ってもよいでしょう。ハードウェアの IRQ 
を設定するには、isapnp や PnP BIOS, あるいは Linux を PnP にするための
パッチを使う必要があるかもしれません。余っている IRQ を調べる参考とし
て、"man setserial" を実行して "IRQ 11" などを検索してみてください。

<!-- setserial.H  end -->



<!--
<sect1> Stty <label id="stty_">
-->
<sect1> stty <label id="stty_">
<!-- stty.H begin <sect1> Stty <label id="stty_"> --> 
<!--
<sect2> Introduction
-->
<sect2> はじめに
<!--
<p> <tt/stty/ does much of the configuration of the serial port but
since application programs (and the getty program) often handle it,
you may not need to use it much.  It's handy if your having problems
or want to see how the port is set up.  Try typing ``stty -a'' at your
terminal/console to see how it's now set.  Also try typing it without
the -a (all) for a short listing which shows how it's set different
than normal.  Don't try to learn all the setting unless you want to
become a serial guru.  Most of the defaults should work OK and some of
the settings are needed only for certain obsolete dumb terminals made
in the 1970's.
-->
<p> <tt/stty/ はシリアルポートの設定を色々やりますが、
アプリケーションプログラム(および getty プログラム)が設定を扱うことも
よくあるので、ユーザが使う必要はあまりありません。
このプログラムは、問題が起こった時
やポートの設定を見たい時には便利です。端末やコンソールで ``stty -a'' 
を実行すればポートの設定を見ることができます。また、-a (all) オプショ
ンを付けずに stty を実行すれば、通常と異なる設定になっている部分が短く
リスト表示されます。シリアルポートの達人になろうというのでなければ、全
ての設定を覚える必要はありません。ほとんどはデフォルトのままで大丈夫な
はずで、1970 年代に作られた特定の古いダム端末に対してだけ設定がいくつか
必要となります。

<!--
Whereas <tt/setserial/ only deals with actual serial ports, stty is
used both for serial ports and for virtual terminals such as the standard
Linux text interface at a PC monitor.  For the PC monitor, many of the
stty settings are meaningless.  Changing the baud rate, etc. doesn't
appear to actually do anything.
-->
<tt/setserial/ は実際のシリアルポートだけを扱うのに対して、stty は
シリアルポートと仮想端末(PC モニタで使う Linux 標準のテキストインタフェー
ス等)の両方に対して使われます。PC モニタに対しては、stty の設定の多く
は無意味です。ボーレート等を変えても実際には何も変わらないように見える
でしょう。

<!--
Here are some of the items stty configures: speed (bits/sec), parity,
bits/byte, # of stop bits, strip 8th bit?, modem control signals, flow
control, break signal, end-of-line markers, change case, padding, beep
if buffer overrun?, echo what you type to the screen, allow background
tasks to write to terminal?, define special (control) characters (such
as what key to press for interrupt).  See the <tt/stty/ man or info
page for more details.  Also see the man page: <tt/termios/ which
covers the same options set by stty but (as of mid 1999) covers
features which the stty man page fails to mention.  
-->
stty の設定をいくつか示すと、速度(ビット/秒)、パリティ、ビット/バイト、
ストップビットの数、8 番目のビットを落とすかどうか、モデム制御シグナル、
フロー制御、ブレーク信号、行末マーカー、文字ケースの変更、パディング、
バッファ溢れの際にビープ音をならすかどうか、入力した文字をエコー表示するか、
バックグラウンドタスクの端末への書き込みを許すかどうか、特殊(制御)文字
の定義(どのキーを押すと割り込みがかかるか等)があります。
詳しくは <tt/stty/ の
マニュアルページか info ファイルを見てください。<tt/termios/ のマニュアル
ページも見てください。これは stty で設定できるのと同じオプションを
含んでいますが、(1999 年半ばの時点では) stty のマニュアルページが
説明できていない機能も含んでいます。

<!--
With some implementations of getty (getty_ps package), the commands
that one would normally give to stty are typed into a getty
configuration file: /etc/gettydefs.  Even without this configuration
file, the getty command line may be sufficient to set things up so
that you don't need stty."')
-->
一部の getty の実装(getty_ps パッケージ)では、stty に通常与えるコマン
ドは getty の設定ファイル(/etc/gettydefs)に書かれます。この設定ファイ
ルがなくても、getty のコマンドラインはユーザが stty を必要としないよう
に十分な設定ができます。

<!--
One may write C programs which change the stty configuration, etc.
Looking at some of the documentation for this may help one better
understand the use of the stty command (and its many possible
arguments).  Serial-Programming-HOWTO is useful.  The manual page:
termios contains a description of the C-language structure (of type
termios) which stores the stty configuration in computer memory.  Many
of the flag names in this C-structure are almost the same (and do the
same thing) as the arguments to the stty command.
-->
stty の設定などを変更する C プログラムを書くことができます。これに関す
る文書をいくつか見れば、stty コマンドの使い方(およびたくさんある使用可
能な引き数)もよく理解できるでしょう。Serial-Programming-HOWTO も役に立
ちます。マニュアルページ termios には C 言語の構造体(termios 型)の
説明があります。この構造体は stty の設定をコンピュータのメモリに格納し
ます。C 言語の構造体のフラグ名の多くは、stty コマンドの引き数とほぼ同
じです(そして同じ動作をします)。

<!--
<sect2> Using stty for a "foreign" terminal
-->
<sect2> 「別の」端末に対しての stty の使用
<!--
<p> Using <tt/stty/ to inspect or configure the terminal that you are
currently using is easy.  Doing it for a different (foreign) terminal
or serial port may be tricky.  For example, let's say you are at the
PC monitor (tty1) and want to use <tt/stty/ to deal with the serial
port ttyS2.  Prior to about 2000 you needed to use the redirection
operator "<".  After 2000 (provided your version of setserial is >=
1.17 and stty >= 2.0) there is an alternate method using the -F
option.  This will work when the old redirection method fails.  Even
with the latest versions be warned that if there is a terminal on
ttyS2 and a shell is running on that terminal, then what you see will
likely be deceptive and trying to set it will not work.  See <ref
id="2_term_interfaces" name="Two Interfaces at a Terminal"> to
understand it.
-->
<p> <tt/stty/ を使って、自分が現在使っている端末の調査や設定を行うの
は簡単です。これを別の(よその)端末やシリアルポートに対して行うのは面
倒かもしれません。
例えば、読者の皆さんが PC のモニタ (tty1) にいて、そして <tt/stty/ を
使ってシリアルポート ttyS2 を扱いたいと考えているとします。
2000 年より前の頃は、リダイレクト演算子 &lt; を使う必要がありました。
2000 年以降では(お使いの setserial のバージョンが 1.17 以上で、stty の
バージョンが 2.0 以上ならば)、-F オプションを使うという別の方法があり
ます。これはリダイレクションを使う古い方法が失敗する場合でも動作します。
しかし、たとえ最新版であっても、ttyS2 上に端末があり、そこでシェルが動
作しているならば、表示されるものは確かではなく、設定しようとしてもうま
くいかないだろうということを注意しておきます。
その理由を理解したければ
<ref id="2_term_interfaces" name="端末の 2 つのインタフェース">
をご覧ください。

<!--O
The new method is ``stty -F /dev/ttyS2 ...'' (or -/-file instead of F).
If  ... is -a it displays all the stty settings.  The old redirection
method (which still works in later versions) is to type ``stty ... &lt
/dev/ttyS2''.   If the new method works but the old one hangs, it
implies that the port is hung due to lack of a modem control line from
being asserted.  Thus the old method is still useful for
troubleshooting.  See the following subsection.
-->
新しい方法は ``stty -F /dev/ttyS2 ...'' です(あるいは -F の代わりに 
--fileを使います)。... が -a であれば、このコマンドで stty  の全ての設
定が表示されます。リダイレクションを使う古い方法(最近のバージョンでも
まだ使えます)では ``stty ... &lt; /dev/ttyS2'' を使います。
新しい方法では動作するのに古い方法だとハングする場合は、オンにしてくれ
るモデム制御線がないためにポートがハングしていると思われます。このよう
に、古い方法もまだトラブル解決に役立ちます。
詳しくはこの後の節を読んでください。

<!--O
<sect3> Old redirection method
-->
<sect3>リダイレクションを使う古い方法
<!--O
<p> Here's a problem with the old redirection operator (which doesn't
happen if you use the newer -F option instead).  Sometimes when trying
to use stty, the command hangs and nothing happens (you don't get a
prompt for a next command even after hitting &lt;return&gt;).  This is
likely due to the port being stuck because it's waiting for one of the
modem control lines to be asserted.  For example, unless you've set
"clocal" to ignore modem control lines, then if no CD signal is
asserted the port will not open and stty will not work for it (unless
you use the newer -F option).  A similar situation seems to exist for
hardware flow control.  If the cable for the port doesn't even have a
conductor for the pin that needs to be asserted then there is no easy
way to stop the hang.
-->
<p>リダイレクション演算子には問題があります(この演算子ではなく、新しい 
-F オプションを使えば問題は起きません)。stty を使おうとすると時々、
コマンドがハングし、何も起こらないことがあります(リターンキーを押して
も、次のコマンドのプロンプトが出ない)。これは大抵ポートがハングしてしまっ
たためであり、これはモデム制御線のいずれかがオンになるのをポートが待っ
ているために起こります。例えば、モデム制御線を無視するように "clocal" 
を設定していない場合、CD 信号がオンにならなければポートはオープンでき
ませんし、stty はポートに対して動作しません(新しい -F オプションを使っ
ていない場合)。同様の状況は、
ハードウェアフロー制御でも起こるようです。オンになる必要がある導線がポー
トに繋いだケーブルになければ、ハングするのを防ぐ簡単な方法はありません。

<!--O
One way to try to get out of the above hang is to use the newer -F
option and set "clocal" and/or "crtscts".  If you don't have the -F
option then you may try to run program on the port that will force it
to operate even if the control lines say not to.  Then hopefully this
program might set the port so it doesn't need the control signal in
the future in order to open: clocal or -crtscts.  To use "minicom" to
do this you have to reconfigure minicom for another ttyS, etc, and
then exit it and restart it.  Since you then have to reconfigure
minicom again, it may be simpler to just reboot the PC.
-->
このようなハングを防ぐ方法の一つは、新しい -F オプションを使い、
"clocal" や "crtscts" を設定することです。-F オプションが使えない場合
は、たとえ制御線がオフであってもポートを強制的に動作させるプログラムを、
そのポートに対して使ってみてもよいでしょう。
すると多分このプログラムは、この先ポートをオープンするために制御線が必
要なくなるようにポートを設定できます: すなわち clocal または -crtscts 
を設定します。"minicom" を使ってこれを行うには、別の ttyS 等に合わせて 
minicom を再設定し、それから minicom の終了と再実行を行わなければなり
ません。その後再び minicom を再設定しなければならないので、単に PC を
再起動するだけの方が簡単かもしれません。

<!--O
The old redirection method makes ttyS2 the standard input to stty.
This gives the stty program a link to the "file" ttyS2 so that it may
"read" it.  But instead of reading the bytes sent to ttyS2 as one
might expect, it uses the link to find the configuration settings of
the port so that it may read or change them.  Some people tried to use
``stty ... &gt /dev/ttyS2'' to set the terminal.  This will not do it.
Instead, it takes the message normal displayed by the stty command for
the terminal you are on (say tty1) and sends this message to ttyS2.
But it doesn't change any settings for ttyS2.
-->
リダイレクションを使う古い方法は、ttyS2 を stty への標準入力とします。
すると、stty  プログラムは「ファイル」である ttyS2 にリンクして
これを「読み取る」ことができるようになります。しかし、ttyS2 に送られた
バイトデータは普通に期待される通りに読み取るのではなく、ポートの読み取
りや変更ができるように、このリンクを使ってポートの設定を調べます。
``stty ... &gt; /dev/ttyS2'' を使って端末を設定しようとする人もいますが、
このコマンドで設定することはできません。この場合は設定は行われずに、使っ
ている端末(例えば tty1)に対する stty コマンドで普通に表示されるメッセージ
が得られ、これが ttyS2 に送られます。しかし、ttyS2 の設定は全く変わり
ません。

<!--
<sect2> Two interfaces at a terminal <label id="2_term_interfaces">
-->
<sect2> 端末の 2 つのインタフェース <label id="2_term_interfaces">
<!--
<p> When using a shell (such as bash) with command-line-editing
enabled there are two different terminal interfaces (what you see when
you type stty -a).  When you type at the command line you have a
temporary "raw" interface (or raw mode) where each character is read
by the command-line-editor as you type it.  Once you hit the
&lt;return&gt; key, the command-line-editor is exited and the terminal
interface is changed to the nominal "cooked" interface (cooked mode)
for the terminal.  This cooked mode lasts until the next prompt is
sent to the terminal.  Note that one never types anything to this
cooked mode but what was typed in raw mode becomes cooked mode as soon
as one hits the &lt;return&gt; key.
-->
<p> コマンドライン編集機能を有効にしてシェル(bash など)を使っている時
は、2 つの異なる端末インタフェース(stty -a を実行した時に表示されるも
の)があります。コマンドラインで入力を行う時には一時的な "raw" インタフェー
ス(つまり "raw" モード)を持っており、それぞれの文字は入力するごとにコ
マンドラインエディタが読み込みます。&lt;リターン&gt;キーを叩くと、コマ
ンドラインエディタは終了し、端末インタフェースはその端末の通常の 
"cooked" インタフェース(cooked モード)に切り替わります。この cooked
モードは、次のプロンプトが端末に送られるまで続きます。この cooked モー
ドでは何も入力しませんが、raw モードで入力された文字は &lt;リターン&gt;
キーが押されると cooked モードになります。

<!--
When a prompt is sent to the terminal the terminal goes from "cooked"
to "raw" mode (just like it does when you start an editor since you
are starting the command-line editor).  The settings for the "raw"
mode are based only on the basic settings taken from the "cooked"
mode.  Raw mode keeps these setting but changes several other settings
in order to change the mode to "raw".  It is not at all based on the
settings used in the previous "raw" mode.  Thus if one uses stty to
change settings for the raw mode, such settings will be lost as soon
as one hits the &lt;return&gt; key at the terminal that has supposedly
been "set".
-->
プロンプトが端末に送られると、端末は "cooked" モードから "raw" モード
に変わります(これはエディタを起動する時とちょうど同じように行われます。
というのも、コマンドラインエディタを起動しようとしているからです)。
"raw" モードの設定は、"cooked" モードから得た基本設定のみに基づいて行
われます。raw モードはこれらの設定を保持しますが、他のいくつかの設定は
モードを "raw" に変えるために変更します。前の "raw" モードで使われた設
定には全く依存しません。したがって、stty を使って raw モードの設定を変
えると、「設定された」と思われる端末上で&lt;リターン&gt;キーを叩いた途
端にこのような設定は無くなってしまいます。

<!--
Now when one types stty to look at the terminal interface, one may
either get a view of the cooked mode or the raw mode.  You need to
figure out which one you're looking at.  It you use stty from another
terminal to deal with a terminal that is displaying a command line,
then the view is that of the raw mode.  Any changes made will only be
made to the raw mode and will be lost when someone presses
&lt;return&gt; at the terminal you tried to "set".  But if you type a
stty command at your terminal (without using &lt for redirection) and
then hit &lt;return&gt; it's a different story.  The &lt;return&gt;
puts the terminal in cooked mode.  Your changes are saved and will
still be there when the terminal goes back into raw mode (unless of
course it's a setting not allowed in raw mode).
-->
ここで、stty を入力して端末インタフェースを見る時には、cooked モードか 
raw モードの設定を表示することができます。その時にはどちらを見るのかを
はっきりさせる必要があります。コマンドラインを表示している端末を扱うた
めに別の端末から stty を使う場合には、表示は raw モードのものになりま
す。行われた変更は raw モードにしか適用されず、「設定」しようとした端
末上で誰かが&lt;リターン&gt;を押すと消えてしまいます。しかし、自分のい
る端末で(リダイレクトの &lt; を使わずに) stty コマンドを入力し、それか
ら&lt;リターン&gt;を押した場合は話が違ってきます。&lt;リターン&gt;キー
により端末は cooked モードになります。行われた変更は保存され、端末が 
raw モードに戻った時にも残っています(もちろん raw モードで変更できない
設定の場合は除きます)。

<!--
This situation can create problems.  For example, suppose you corrupt
your terminal interface and to restore it you go to another terminal
and "stty -F dev/ttyS1 sane" (or the like) to restore it.  It will not
work!  Of course you can try to type "stty sane ..." at the terminal
that is corrupted but you can't see what you typed.  All the above not
only applies to dumb terminals but to virtual terminals used on a PC
Monitor as well as to the terminal windows in X.  In other words, it
applies to almost everyone who uses Linux.  Luckily, a file that runs
stty at boot-time will likely deal with a terminal (or serial port
with no terminal) that has no shell running on it so there's no
problem.
-->
この状況により問題が起こることがあります。例えば、端末インタフェースを
ぐちゃぐちゃにしてしまい、これを戻すために別の端末に行って
"stty -F dev/ttyS1 sane" (等)を実行したとしましょう。ところが、この方法は
使えません! もちろんぐちゃぐちゃになってしまった端末から "stty sane ..." の入力を試
みることはできますが、入力した文字を見ることはできません。上記の現象は
ダム端末だけではなく、PC モニタ上で使う仮想端末や、X 上の端末ウィンド
ウにも当てはまります。言い換えれば、これは Linux を使うほとんど全ての
人に当てはまります。幸運なことに、stty を起動時に実行するファイルはシェ
ルが動作していない端末(あるいは端末が繋がっていないシリアルポート)を扱
えるので問題はありません。

<!--
<sect2> Where to put the stty command ? <label id="stty_where">
-->
<sect2> どこに stty コマンドを置くか? <label id="stty_where">
<!--
<p> Should you need to have <tt/stty/ set up the serial interface each
time the computer starts up then you need to put the <tt/stty/ command
in a file that will be executed each time the computer is started up
(Linux boots).  It should be run before the serial port is used
(including running getty on the port).  There are many possible places
to put it.  If it gets put in more than one place and you only know
about (or remember) one of those places, then a conflict is likely.
So make sure to document what you do.
-->
<p>コンピュータが起動する度に <tt/stty/ にシリアルインタフェースを設定
させる必要があるのなら、コンピュータが起動する(Linux が起動する)度
に実行されるファイルに <tt/stty/ コマンドを入れておく必要があります。このファイ
ルはシリアルポートが使われる(ポートにおける getty の実行も含みます)前
に実行されなければなりません。これを置くことができる場所はたくさんあり
ます。複数の場所にこれを置いたのに、その場所のうちの一つしか知らなけれ
ば(覚えていなければ)衝突が起きてしまうでしょう。したがって、設定したこ
とは記録しておきましょう。

<!--
One place to put it would be in the same file that runs setserial when
the system is booted.  The location is distribution and version
dependent.  It would seem best to put it after the setserial command
so that the low level stuff is done first.  If you have directories in
the /etc tree where every file in them is executed at boot-time 
(System V Init) then you could create a file named "stty" for this
purpose.
-->
stty コマンドを置く場所の一つは、システムが起動する時に setserial 
を実行するファイルの内部です。この場所はディストリビューションや
バージョンごとに異なります。低レベルの処理が先に行われるようにするため、
これは setserial の後に置くのが良いでしょう。
置かれているファイルが起動時に全て実行されるディレクトリ(System V Init)
が /etc ディレクトリツリーの下にあれば、"stty" という名前のファイルを
作って stty コマンドを実行させても良いでしょう。
<!-- stty.H end --> 


<!--
<sect1> What is isapnp ?
-->
<sect1> isapnp とは何か?
<!--
<p> <tt/isapnp/ is a program to configure Plug-and-Play (PnP) devices
on the ISA bus including internal modems.  It comes in a package
called "isapnptools" and includes another program, "pnpdump" which
finds all your ISA PnP devices and shows you options for configuring
them in a format which may be added to the PnP configuration file:
/etc/isapnp.conf.  The isapnp command may be put into a startup file
so that it runs each time you start the computer and thus will
configure ISA PnP devices.  It is able to do this even if your BIOS
doesn't support PnP.  See Plug-and-Play-HOWTO.
-->
<p><tt/isapnp/ は、内部モデムを含めた ISA バス用のプラグ&amp;プレイ
(PnP)デバイスを設定するためのプログラムです。このプログラムは 
"isapnptools" と呼ばれるパッケージに他のプログラム("pnpdump")と一緒に
入っています。"pnpdump" は全ての ISA PnP デバイスを見つけ、これら
のデバイスを設定するオプションを出力します。この出力は、PnP の設定ファ
イルである /etc/isapnp.conf に追加できる形式です。コンピュータの起動時
に毎回実行され、ISA PnP デバイスを設定できるように、isapnp コマンドは
システムの起動ファイルに書かれます。BIOS が PnP をサポートしていなくて
も、これを行うことは可能です。詳しくは Plug-and-Play-HOWTO を見てくだ
さい。

<!--
<sect> Speed (Flow Rate) <label id="speed_">
-->
<sect> 速度 (フローレート) <label id="speed_">

<!--
<p> By "speed" we really mean the "data flow rate" but almost everybody
incorrectly calls it speed.  The speed is measured in bits/sec (or
baud).  Speed is set using the "stty" command or by a program which
uses the serial port.  See <ref id="stty_" name="Stty">
-->
<p>ここで言う "速度" は本当は「データフローレート(data flow rate)」と
いう意味なのですが、大抵の人はこれを速度と誤用しています。速度の単位は
ビット/秒(あるいはボー)です。速度は "stty" コマンドまたはシリアルポー
トを使うプログラムで設定します。
<ref id="stty_" name="stty"> をご覧ください。

<!--
<sect1> Can't Set a High Enough Speed
-->
<sect1> 十分に速い速度が設定できません
<!-- high_speed.H begin  -->
<!--
<p> You need to find out the highest speed supported by your hardware.
As of late 1998 most hardware only supported speeds up to 115.2k bps.
A few 56k internal modems support 230.4k bps.  Recent Linux kernels
support high speeds (over 115.2k) but you might have difficulty using
it because of one or both of the following reasons:
-->
<p>ハードウェアが対応している最大速度を知る必要があります。1998 年末の時
点では、ほとんどのハードウェアが 115.2k bps までの速度にしか対応してい
ませんでした。
いくつかの 56k 内蔵モデムは 230.4k bps に対応しています。
最近の Linux カーネルは高速(115.2k 以上)対応していますが、以下の理由の
いずれかあるいは両方のために、対応が難しい場合があります:

<enum>
<!--
<item> The application program (or stty) will not accept the high speed.
-->
<item> アプリケーションプログラム(または stty)が高速対応していない
<!--
<item> Setserial has a default speed of 115,200 (but this default is
easy to change)
-->
<item> setserial の設定がデフォルトの速度の 115,200 である(しかし、こ
のデフォルト値を変えるのは簡単です)
</enum>

<!--
<sect2> How speed is set in hardware: the divisor and baud_base <label
 id="divisor_">
-->
<sect2> ハードウェアに速度を設定する方法: 除数と baud_base 値 <label
 id="divisor_">
<!--
<p> Here's a list of commonly used divisors and their corresponding
speeds (assuming a maximum speed of 115,200): 1 (115.2k), 2 (57.6k), 3
(38.4k), 6 (19.2k), 12 (9.6k), 24 (4.8k), 48 (2.4k), 96 (1.2k), etc.
The serial driver sets the speed in the hardware by sending the
hardware only a "divisor" (a positive integer).  This "divisor"
divides the maximum speed of the hardware resulting in a slower speed
(except a divisor of 1 obviously tells the hardware to run at maximum
speed).  
-->
<p>普通使われる除数とそれに対応する速度(最大速度は 115,200 とします)の
リストを示すと 1 (115.2k), 2 (57.6k), 3 (38.4k), 6 (19.2k), 12 (9.6k),
24 (4.8k), 48 (2.4k), 96 (1.2k) などとなります。シリアルドライバは、
ハードウェアに「除数」(正の整数)のみを送ることによってハードウェアの速
度を設定します。この「除数」でハードウェアの最大速度が割り算され、遅い
速度となります(ただし除数が 1 の場合は言うまでもなく、ハードウェアに
最大速度で動作するよう命令します)。

<!--
Normally, if you specify a speed of 115.2k (in your communication
program or by stty) then the serial driver sets the port hardware to
divisor 1 which obviously sets the highest speed.  If you happen to
have hardware with a maximum speed of say 230.4k, then specifying
115.2k will result in divisor 1 and will actually give you 230.4k.
This is double the speed that you set.  In fact, for any speed you
set, the actual speed will be double.  If you had hardware that could
run at 460.8k then the actual speed would be quadruple what you set.
-->
普通は(通信プログラムや stty で)速度を 115.2k に指定すると、シリアルド
ライバはポートのハードウェアに除数 1 を設定します。これは言うまでもな
く最高速度の設定です。
お使いのハードウェアの最高速度が例えばたまたま 230.4k 
ならば、115.2k を指定した時の除数が 1 であるため、実際の速度は 230.4k 
になります。これにより設定した速度の倍の速度になります。実際、どんな速
度を指定しても実際の速度は倍になってしまいます。460.8k で動作できるハー
ドウェアがあったとすると、実際の速度は設定値の 4 倍となるでしょう。

<!--
<sect2> Work-arounds for setting speed
-->
<sect2> 速度設定に関する問題の回避
<!--
<p> To correct this accounting (but not always fix the problem) you
may use "setserial" to change the baud_base to the actual maximal
speed of your port such as 230.4k.  Then if you set the speed (by your
application or by stty) to 230.4k, a divisor of 1 will be used and
you'll get the same speed as you set.  PROBLEM: stty and many
communication programs (as of mid 1999) still have 115.2k as their
maximum speed setting and will not let you set 230.4k, etc.  So in
these cases one solution is not to change anything with <tt/setserial/
but mentally keep in mind that the actual speed is always double what
you set.
-->
<p>こういった計算を正しくさせるには(しかし必ずしも問題が解決するとは限
りません)、"setserial" を使って baud_base 値を実際のポートの最大速度
(例えば 230.4k)に変更します。そうすると(アプリケーションや stty を使っ
て)速度を 230.4k にした場合に除数として 1 が使われ、設定したのと同じ速
度が得られます。しかし問題があります: (1999 年半ばの時点では)stty や多
くの通信プログラムは最大速度の設定値が 115.2k であり、230.4k 等を設定
することができないのです。したがって、このような場合の一つの解決方法は、
<tt/setserial/ では何も変更せず、実際の速度は設定した速度の 2 倍である
ことを自分で覚えておくことです。

<!--
There's another work-around which is not much better.  To use it you
set the baud_base (with setserial) to the maximal speed of your
hardware.  This corrects the accounting so that if you set say 115.2k
you actually get 115.2k.  Now you still have to figure out how to set
the highest speed if your communication program (or the like) will not
let you do it.  Fortunately, setserial has a way to do this: use the
"spd_cust" parameter with "divisor 1".  Then when you set the speed to
38400 in a communication program, the divisor will be set to 1 in the
port and it will operate at maximum speed.  For example:<newline>
setserial /dev/ttyS2 spd_cust baud_base 230400 divisor 1<newline>
Don't try using "divisor" for any other purpose other than the special
use illustrated above (with spd_cust).
-->
あまりマシとは言えませんが、別の回避策もあります。この方法を使うには、
(setserial を使って) baud_base 値をハードウェアの最大速度にしてくださ
い。これにより計算方法が正しくなり、115.2k を指定すれば実際に 115.2k 
の速度が得られるようになります。ここでもまだ、通信プログラムなどが最高
速度を設定させてくれない場合に、最高速度を設定する方法を見つける必要が
あります。幸運なことに、setserial にはこれを行う方法があります:
"divisor 1" として "spd_cust" パラメータを使うのです。すると、通信プロ
グラムで速度を 38400 とした時にポート内の除数は 1 に設定され、最高速度
で動作します。例: <newline>
setserial /dev/ttyS2 spd_cust baud_base 230400 divisor 1<newline>
"divisor" を先に説明した(spd_cust と組み合わせる)特殊な用途以外の目的
で使ってはいけません。

<!--
If there are two or more high speeds that you want to use that your
communication program can't set, then it's not quite as easy as above.
But the same principles apply.   You could just keep the default
baud_base and understand that when you set a speed you are really only
setting a divisor.  So your actual speed will always be your maximum
speed divided by whatever divisor is set by the serial driver.  See
<ref id="divisor_" name="How speed is set in hardware: the divisor and
baud_base">
-->
通信プログラムで設定できない速い速度を 2 つ以上使いたい場合には、先の
説明ほど簡単には行きません。しかし同じ原則が当てはまります。baud_base 
値は単にデフォルトのままにしておき、速度を設定する時には実際は除数しか
設定していないと考えるのです。したがって実際の速度は常に、シリアルドラ
イバが設定した除数で最大速度を割った値となります。
<ref id="divisor_" name="ハードウェアに速度を設定する方法: 除数と baud_base 値">
をご覧ください。

<!--
<sect2> Crystal frequency is not baud_base
-->
<sect2> 水晶発振器の周波数はボーレートではありません
<!--
<p> Note that the baud_base setting is usually much lower than the
frequency of the crystal oscillator in the hardware since the crystal
frequency is often divided by 16 in the hardware to get the actual top
speed.  The reason the crystal frequency needs to be higher is so that
this high crystal speed can be used to take a number of samples of
each  bit to determine if it's a 1 or a 0.
-->
<p> baud_base 値の設定は普通、ハードウェア内の水晶発振器の周波数よりずっ
と低い点に注意してください。というのも、水晶発振器の周波数はハードウェ
ア内で 16 で割られ、実際の最高速度となることが多いからです。水晶発振器
の周波数の方が高くなければならない理由は、このように周波数が高速ならば、
各ビットが 1 か 0 であるかを決めるためのサンプルをたくさん取ることがで
きるからです。
<!-- high_speed.H end  -->


<!--
<sect1>Higher Serial Throughput
-->
<sect1>シリアルのスループットの向上
<p>
<!--
If you are seeing slow throughput and serial port overruns on a 
system with (E)IDE disk drives, you can get <tt>hdparm</tt>.  This
is a utility that can modify (E)IDE parameters, including unmasking
other IRQs during a disk IRQ.  This will improve responsiveness
and will help eliminate overruns.  Be sure to read the man page very
carefully, since some drive/controller combinations don't like this
and may corrupt the filesystem.
-->
(E)IDE のハードディスクを使っているシステムであり、かつスループットが
悪くてシリアルポートがオーバーランする場合は <tt>hdparm</tt> を試して
ください。これは (E)IDE のパラメータ(ディスクの IRQ が発行されている間
は他の IRQ をアンマスクする等)を変更可能にするユーティリティです。この
ユーティリティを使うと応答が良くなってオーバーランを無くすのに役立つでしょ
う。ただし、マニュアルページは必ずよく読んでください。というのも、
一部のドライブとコントローラの組合せではこのユーティリティがうまく動作
せず、ファイルシステムを壊してしまうかもしれないからです。
<p>
<!--
Also have a look at a utility called <tt>irqtune</tt> that will change 
the IRQ priority of a device, for example the serial port that your 
modem is on.  This may improve the serial throughput on your system.
The <tt/irqtune/ FAQ is at <url url="http://www.best.com/~cae/irqtune"
name="http://www.best.com/~cae/irqtune">
-->
<tt>irqtune</tt> と呼ばれるユーティリティも試してください。これはデバ
イス(例えばモデムが繋がっているシリアルポート)の IRQ の優先度を変更す
るユーティリティです。これにより、お使いのシステムのシリアルポートのス
ループットが向上するかもしれません。<tt/irqtune/ の FAQ は
<url url="http://www.best.com/~cae/irqtune"
name="http://www.best.com/~cae/irqtune">
にあります。

<!--O
<sect> Locking Out Others
-->
<sect>ロックして他で使えないようにする
<!--O
<sect1> Introduction
-->
<sect1> はじめに
<!--O
<p> When you are using a serial port, you may want to prevent others
from using it at the same time.  However there may be cases where you
do want others to use it, such as sending you an important message if
you are using a text-terminal.
-->
<p>自分がシリアルポートを使う時には、他の人は同時に使えないようにした
いと思うでしょう。しかし、他の人にも使わせたいこともあるかもしれません。
例えば自分がテキスト端末を使っている時に、他の人が重要なメッセージを
送れるようにしたい場合です。

<!--O
There are various ways of preventing others (or other processes) from
using your serial port when you are using it (locking).  This should
all happen automatically but it's important to know about this if it
gives you trouble.  If a program is abnormally exited or the PC
is abruptly turned off (by pulling the plug, etc.) your serial port
might wind up locked.  Even if the lock remains, it's usually
automatically removed when you want to use the serial port again.
But in rare cases it isn't.  That's when you need to understand what
happened.
-->
自分が現在使用中のシリアルポートを他の人(や他のプロセス)が使えないよう
にする方法(ロッキング)は色々あります。この処理は自動的に行われるはずで
すが、問題が起きた時のためにロッキングを知っておくことは重要です。
プログラムが異常終了したり、(コンセントを引き抜くなどで)PC が突然落ち
たりした場合には、シリアルポートがロックしたままになってしまうかもしれ
ません。ロックが残ったままであっても、普通は次にシリアルポートを使おう
とした時に自動的にロックは消されます。しかしまれにそうでないこともあり
ます。そんな時には何が起こったのかを理解する必要があります。

<!--O
One way to implement locking is to design the kernel to handle it but
Linux thus far has shunned this solution (with an exception involving
the cua device which is now obsolete).  Two solutions used by Linux
is to: 
-->
ロッキングを実装する方法の一つは、ロックを処理できるようにカーネルを設
計することですが、Linux はこれまではこの方法を避けてきました(今では使
われなくなった cua デバイスは例外です)。Linux で使われる方法は 2 つあ
ります。
<enum>
<!--O
<item> create lock-files
-->
<item> ロックファイルを作る方法
<!--O
<item> modify the permissions and/or owners of devices such as /dev/ttyS2
-->
<item> /dev/ttyS2 等のデバイスのパーミッションや所有者を変える方法
</enum>

<!--O
<sect1>Lock-Files <label id="lockfiles_">
-->
<sect1>ロックファイル <label id="lockfiles_">
<p>
<!--O
A lock-file is simply a file created to mean that a particular device is
in use.  They are kept in <tt>/var/lock</tt>.  Formerly they were in
<tt>/usr/spool/uucp</tt>.  Linux lock-files are sometimes named
<tt/LCK../<EM/name/, where <EM/name/ is either a device name, or a
UUCP site name.  Most processes (an exception is getty) create these locks so that they can
have exclusive access to devices.  For instance if you dial out on
your modem, a lock-file (or even more that one lockfile) will appear
telling other processes that someone else is using the modem.  Lock
files contain the PID of the process that has locked the device.  Note
that if a process insists on using a device that is locked, it may
ignore the lockfile and use the device anyway.  This is useful in
sending a message to a text-terminal, etc.
-->
ロックファイルは特定のデバイスが使用中であることを示すために作られるた
だのファイルです。
このファイルは <tt>/var/lock</tt> に置かれます。以前は
<tt>/usr/spool/uucp</tt> に置かれていました。Linux では、ロックファイ
ルの名前は <tt/LCK../<EM/name/ となることがあります。ここで <EM/name/ 
はデバイス名か、UUCP のサイト名です。
ほとんどのプロセス(getty は除きます)は、そのデバイスに排他的にアクセス
できるようになるためにロックファイルを作ります。
例えば、モデムを使ってダイアルアウトを行うと、誰かがモデムを使って
いることをロックファイル(ひとつだけでないこともあります)が他のプロセス
に伝えます。ロックファイルの内容は主に、デバイ
スをロックしているプロセスの ID です。
ロックされているデバイスをどうしても使いたければ、プロセスは
ロックファイルを無視して、とにかくデバイスを使ってしまってもよい点に
注意してください。これはテキスト端末にメッセージを送りたい時などに便利
です。

<!--O
When a program wants to use a serial port but finds it locked with a
lock-file it should check to see if the lock-file's PID is still in
use.  If it's not it means that the lock is stale and it's OK to go
ahead and use the port anyway (after removing the stale lock-file).
Unfortunately, there may be some programs that don't do this and give
up by telling you that a device is already in use when it really isn't.
-->
プログラムがシリアルポートを使おうとしたけれど、そのポートが
ロックファイルでロックされている時は、このプログラムはロックファイルが
示す PID がまだ使われているかどうかを確認するはずです。
その PID が使われていなければロックは無効ということなので、(無効になっ
たロックファイルを消してから)そのままポートを使っても大丈夫です。
残念ながらプログラムによってはこのような処理を行わず、実際には
デバイスが使用中でなくてもデバイスが使用中だというメッセージを表示して
あきらめてしまうものもあります。

<!--O
Problems can arise with lockfiles if the same device has two different
names, resulting in lockfiles with different names that actually are
the same device.  Formerly each physical serial port was known by
two different device names: ttyS0 and cua0.  The lock checking
software is aware of ttyS vs. cua but it's simpler now since cua has
been eliminated.  Older versions may still use cua.  Using alternate
names (such as /dev/modem for /dev/ttyS2) is asking for trouble.
-->
ロックファイルがらみの問題は、同じデバイスが 2 つの別名を持っており、
その結果として別の名前を持つが実際には同じデバイスを示す
ロックファイルが 2 つできる場合に起こる可能性があります。かつては
各々の物理シリアルポートは 2 つの異なるデバイス名(ttyS0 と cua0)を
持つことが有名でした。ロックをチェックするプログラムは ttyS と cua の
両方に対応していましたが、現在は cua がなくなったので処理は簡単になり
ました。バージョンの古いプログラムはまだ cua を使っていることがありま
す。別名を使うこと(/dev/modem で /dev/ttyS2 を示す等)はトラブルを自ら
招くようなものです。

<!--O
<sect1> Change Owners, Groups, and/or Permissions of Device Files
-->
<sect1> デバイスファイルの所有者、グループ、パーミッションの変更
<!--O
<p> In order to use a device, you (or the program you run if you have
"set user id") needs to have permission to read and write the device
"file" in the /dev directory.  So a logical way to prevent others from
using a device is to make yourself the temporary owner of the device
and set permissions so that no one else can use it.  A program may do
this for you.  A similar method can be used with the group of the
device file.
-->
<p>デバイスを使うには、ユーザ(setuid されている場合は、実行するプログラム)
は /dev ディレクトリにあるデバイス「ファイル」を読み書きするための
パーミッションを持っている必要があります。したがって、他の人がデバイス
を使えないようにする筋の通った方法は、自分自身をそのデバイスの一時的な
所有者にし、他には誰も使えないようなパーミッションを設定することです。
このような処理をするプログラムもあります。
同じような方法として、デバイスファイルのグループも使えます。

<!--O
While lock files prevent other process from using the device, changing
device file owners/permissions restricts other users (or the group) from using
it.  One case is where the group is permitted to write to the port,
but not to read from it.  Writing to the port might just mean a
message sent to a text-terminal while reading means destructive
reading.  The original process that needs to read the data may find
data missing if another process has already read that data.  Thus a
read can do more harm that a write since a read causes loss of data
while a write only adds extra data.  That's a reason to allow writes
but not reads.  This is exactly the opposite of the case for ordinary
files where you allow others to read the file but not write (modify)
it.  Use of a port normally requires both read and write permissions.
-->
ロックファイルは他のプロセスがデバイスを使えないようにしますが、
デバイスファイルの所有者/パーミッションの変更は他のユーザ(やグループ)
がデバイスを使えないようにします。ひとつの状況として、グループに対して
シリアルポートへの書き込みのパーミッションは与えられているけれど、
読み取りのパーミッションは出ていない場合があります。この場合、
ポートへの書き込みは単にテキスト端末へのメッセージ送信になるだけですが、
読み取りは悲惨なことになります。別のプログラムが先にデータを読み出して
しまうと、データの読み取りの必要があった元々のプログラムの
データがなくなってしまいます。このように、読み取りは書き込みよりも大き
な害を及ぼすことがあります。
読み取りではデータがなくなりますが、書き込みでは
余計なデータが追加されるだけだからです。これが、書き込みは許しても
読み取りは許さない理由です。これは通常ファイルの場合とちょうど反対にな
ります。通常ファイルでは他人に読み取りを許可しますが、書き込み(修正)は
許しません。シリアルポートを使う場合は普通、読み取りと書き込みの両方が
必要です。

<!--O
A program that changes the device file attributes should undo these
changes when it exits.  But if the exit is abnormal, then a device
file may be left in such a condition that it gives the error
"permission denied" when one attempts to use it again.
-->
デバイスファイルの属性を変更するプログラムは、終了時には変更した部分を
元に戻すはずです。しかし、異常終了した場合には、次に誰かが使おうとした
時に "permission denied" エラーが出るような状態のままの
デバイスファイルが残ることがあります。

<!--
<sect>Communications Programs And Utilities<label id="comms">
-->
<sect>通信プログラムとユーティリティ<label id="comms">
<!--
<sect1> List of Software
-->
<sect1> ソフトウェアの一覧
<p>
<!--
Here is a list of some communication software you can choose from,
available via FTP, if they didn't come with your distribution.
-->
以下に通信プログラムをいくつか紹介します。お使いのディストリビューショ
ンに付属していなければ、FTP で入手することもできます。

<itemize>
<!--
<item><tt/ecu/ - a communications program
-->
<item><tt/ecu/ - 通信プログラム
<!--
<item><url url="http://www.columbia.edu/kermit/" name="C-Kermit"> - 
 portable, scriptable, serial and TCP/IP communications including file 
 transfer, character-set translation, and zmodem support
-->
<item><url url="http://www.columbia.edu/kermit/" name="C-Kermit"> - 
 移植性が高く、スクリプト記述ができ、ファイル転送・文字集合変換・
zmodem に対応しているシリアル・TCP/IP 共用の通信プログラム。
<!--
<item><tt/minicom/ - <tt/telix/-like communications program 
-->
<item><tt/minicom/ - <tt/telix/ に似た通信プログラム
<!--
<item><tt/procomm/ - <tt/procomm/-like communications program with zmodem
<item><tt/procomm/ - <tt/procomm/ に似た zmodem 対応通信プログラム
fujiwara: 山下さんの指摘を受けて著者に確認したところ，

  This was in the HOWTO when I took it over and is in error.  Thanks for
  finding it.  It should be pcomm is like procomm, etc.  But since pcomm
  is considered to be obsolete (and it's mentioned in Modem-HOWTO) I
  have deleted this line from Serial-HOWTO.  So I suggest to just delete
  this line.

とのことでした．これを受けて原文も含めてコメントアウトします．
次の版では原文からもこの行が消えるはずです．
-->
<!--
<item><tt/seyon/ - X based communication program
-->
<item><tt/seyon/ - X ベースの通信プログラム
<!--
<item><tt/xc/ - xcomm communication package
-->
<item><tt/xc/ - xcomm 通信パッケージ

<!--
<item><tt/term/ and <tt/SLiRP/ offer TCP/IP functionality using a
 shell account.
-->
<item><tt/term/ と <tt/SLiRP/ は、シェルアカウントを使って TCP/IP 機能
を提供します。

<!--
<item><tt/screen/ is another multi-session program.  This one behaves 
 like the virtual consoles.
-->
<item><tt/screen/ はマルチセッションプログラムです。これは仮想コンソー
ルのように動作します。

<!--
<item><tt/callback/ is where you dial out to a remote modem and then
 that modem hangs up and calls you back (to save on phone bills).
-->
<item><tt/callback/ を使うと、リモートモデムに電話をかけた時に、その
モデムはいったん電話を切ってからコールバックしてくれます(電話代を節約
できます)。

<!--
<item><tt/mgetty+fax/ handles FAX stuff, and provides an alternate 
 <tt/ps_getty/. 
-->
<item><tt/mgetty+fax/ はファックスを扱います。<tt/ps_getty/ の代わりに
使うことができます。

<!--
<item><tt/ZyXEL/ is a control program for ZyXEL U-1496 modems.  It 
 handles dialin, dialout, dial back security, FAXing, and voice
 mailbox functions.
-->
<item><tt/ZyXEL/ は ZyXEL U-1496 モデムを制御するプログラムです。この
プログラムはダイアルイン、ダイアルアウト、コールバックによるセキュリティ
機能、ファックス、音声メールボックスを扱います。

<!--
<item>SLIP and PPP software can be found at
 <tt> <htmlurl url="ftp://metalab.unc.edu/pub/Linux/system/network/serial"
 name="ftp://metalab.unc.edu/pub/Linux/system/network/serial"></tt>.
-->
<item>SLIP と PPP に関連するソフトウェアは
<tt> <htmlurl url="ftp://metalab.unc.edu/pub/Linux/system/network/serial"
 name="ftp://metalab.unc.edu/pub/Linux/system/network/serial"></tt>
で入手できます。
</itemize>

<!--
<sect1>kermit and zmodem
-->
<sect1>kermit と zmodem
<p>
<!--
To use zmodem with <tt/kermit/ (for ttyS3), add the following to your
<tt/.kermrc/:
-->
(ttyS3 で)<tt/kermit/ で zmodem を使うには、<tt/.kermrc/ に以下の記述を追加しま
す:
<tscreen><verb>
define rz !rz < /dev/ttyS3 > /dev/ttyS3
define sz !sz \%0 > /dev/ttyS3 < /dev/ttyS3
</verb></tscreen>
<!--
Be sure to put in the correct port your modem is on.  Then, to use it,
just type <tt/rz/ or <tt>sz &lt;filename&gt;</tt> at the <tt/kermit/ 
prompt.
-->
モデムが接続されている正しいポートを必ず指定してください。zmodem を使
うには、<tt/kermit/ のプロンプトで単に <tt/rz/ または
<tt>sz &lt;filename&gt;</tt> と入力してください。

<!--
<sect>Serial Tips And Miscellany
-->
<sect>シリアルに関するちょっとしたテクニックなど
<!--
<p> Here are some serial tips you might find helpful...
-->
<p>役に立つと思われるシリアル関連のちょっとしたテクニックを紹介します。

<!--
<sect1> Line Drivers
-->
<sect1> ラインドライバ
<!--
<p> For a text terminal, the EIA-232 speeds are fast enough but the
usable cable length is often too short.  Balanced technology could
fix this.  The common method of obtaining balanced communication with
a text terminal is to install 2@ line drivers in the serial line to
convert unbalanced to balanced (and conversely).  They are a
specialty item and are expensive if purchased new.
-->
<p>テキスト端末では EIA-232 は十分高速ですが、許されるケーブル長が短す
ぎることはよくあります。この問題は平衡型伝送技術により解決します。
テキスト端末で平衡型伝送を行うための一般的な方法は、シリアル回線に 2 
つのラインドライバをインストールして、非平衡型から平衡型への変換(およ
び逆変換)を行うことです。これは特殊な機器であり、新しく買うとなると高
価でしょう。
<!--
<sect1> Known Defective Hardware
-->
<sect1> 欠陥品として知られているハードウェア

<!--
<sect2> Avoiding IO Address Conflicts with Certain Video Boards <label
 id="8514_">
-->
<sect2> 特定のビデオボードで起こる I/O アドレスの衝突を回避する方法
<label  id="8514_">
<!--
<p> The IO address of the IBM 8514 video board (and others) is
allegedly 0x?2e8 where ? is 2, 4, 8, or 9.  This may conflict (but
shouldn't if the serial port is well designed) with the IO address of
<tt/ttyS3/ at 0x02e8 if the serial port ignores the leading 0 hex
digit when it decodes the address (many do).  That is bad news if you
try to use <tt/ttyS3/ at this IO address.  Another story is that Linux
will not detect your internal modem on <tt/ttyS3/ but that you can use
<tt>setserial</tt> to put <tt/ttyS3/ at this address and the modem
will work fine.
-->
<p> IBM 8514 ボード(など)の I/O アドレスは 0x?2e8 と言われています(? 
は 2, 4, 8, 9 のいずれか)。
シリアルポートがアドレスを展開する時に 16 進値の先頭の 0 である桁を
無視する(多くのシリアルポートはそのように動作します)場合には、これは 
0x02e8 にある <tt/ttyS3/ の I/O アドレスと衝突します(ただし
シリアルポートがうまく設計されていれば衝突しないはずです)。
これは、このアドレスで <tt/ttyS3/ を使おうとしている人には困った話です。
これとは別の問題で Linux は <tt/ttyS3/ にある内蔵モデムを検出で
きませんが、<tt>setserial</tt> を使ってこのアドレスに <tt/ttyS3/ を置
けば、モデムはうまく動作するでしょう。

<!--
<sect2> Problem with AMD Elan SC400 CPU (PC-on-a-chip)
-->
<sect2> AMD Elan SC400 CPU (PC-on-a-chip) での問題
<!--
<p> This has a race condition between an interrupt and a status register
of the UART.  An interrupt is issued when the UART transmitter
finishes the transmission of a byte and the UART transmit buffer
becomes empty (waiting for the next byte).  But a status register of
the UART doesn't get updated fast enough to reflect this.  As a
result, the interrupt service routine rapidly checks and determines
(erroneously) that nothing has happened.  Thus no byte is sent to the
port to be transmitted and the UART transmitter waits in vain for a
byte that never arrives.  If the interrupt service routine had waited
just a bit longer before checking the status register, then it would
have been updated to reflect the true state and all would be OK.
-->
<p>これは割り込みと UART の状態レジスタが競合するという問題です。UART 
のトランスミッタがバイトデータの送信を終え、UART の送信バッファが空に
なると(送信バッファは次のバイトデータを待ちます)割り込みが発行されます。
しかし  UART の状態レジスタは、これが十分反映されるほど速く更新されま
せん。
その結果、割り込みサービスルーチンが高速なチェックを行うと、何も
起こっていないと(間違って)判断します。したがって、次に転送すべきバイト
データはシリアルポートに送られず、UART のトランスミッタは届くことのな
いバイトデータを虚しく待ち続けることになります。割り込みサービスが状態
レジスタをチェックするまでの待ち時間がもう少し長ければ、実際の状態が反
映され、全てがうまく行くはずなのですが…。

<!--
There is a proposal to fix this by patching the serial driver.  But
Should linux be patched to accommodate defective hardware, especially
if this patch may impair performance of good hardware?
-->
シリアルドライバにパッチを当てることにより、この問題を解決しようという
提案もあります。しかし、欠陥ハードウェアに対応するために Linux にパッ
チを当てるべきでしょうか? しかも問題ないハードウェアでの性能が落ちるか
もしれないのに。

<!--
<sect>Troubleshooting <label id="trouble_shoot">
-->
<sect>トラブルシューティング <label id="trouble_shoot">
<!--
<p> See Modem-HOWTO for troubleshooting related to modems or getty for
modems.
-->
<p>モデムおよび、モデムに対して用いる getty に関しては、Modem-HOWTO の
トラブルシューティングの章をご覧ください。

<!--
<sect1> Serial Electrical Test Equipment
-->
<sect1> シリアルの電気的な診断を行う道具
<!--
<sect2> Breakout Gadgets, etc.
-->
<sect2> 中継コネクタ等の小物
<!--
<p> While a multimeter (used as a voltmeter) may be all that you need
for just a few terminals, simple special test equipment has been made
for testing serial port lines.  Some are called "breakout ... " where
breakout means to break out conductors from a cable.  These gadgets
have a couple of connectors on them and insert into the serial cable.
Some have test points for connecting a voltmeter.  Others have LED
lamps which light when certain modem control lines are asserted
(turned on).  Still others have jumpers so that you can connect any
wire to any wire.  Some have switches.  
-->
<p>端末が数個だけならばテスタ(電圧計として使います)があれば十分でしょ
うが、シリアルポートの配線を調べるための簡単な特殊器具もあります。その
中には「中継コネクタ(breakout)」と呼ばれるものがあります。
<!--
fujiwara: "breakout" って日本ではなんて呼んでます?
幸田さん: 秋月の広告とか見ると、「回線モニタ」とか「チェックテスタ」と
          いう名前になっているようですね。
水原さん: 「中継コネクタ」ではいかがでしょう。
-->
「breakout」という言葉は、導線をケーブルから取り出すといった意味です。
このような小物には 2 つコネクタが付いており、シリアルケーブルを繋ぐよ
うになっています。電圧計を繋ぐ端子がついているものもあります。特定の
モデム制御線がオンになっていると点灯する LED ランプがついているものもあ
ります。任意の線と線を接続できるようにジャンパがついているものもありま
す。スイッチがついているものもあります。

<!--
Radio Shack sells (in 1998) a "RS-232 Troubleshooter" or "RS-232 Line
Tester" which checks TD, RD, CD, RTS, CTS, DTR, and DSR.  A green
light means on (+12 v) while red means off (-12 v).  They also sell a
"RS-232 Serial Jumper Box" which permits connecting the pins anyway
you choose.
-->
Radio Shack 等の電器屋で「RS-232 Troubleshooter」つまり
「RS-232 結線テスタ」を売っています(1998 年)。これは TD, RD, CD, RTS, CTS,
DTR, DSR をチェックします。緑のランプはオン(+12 V)を表し、赤のランプは
オフ(-12 V)を表します。この店では「RS-232 シリアルジャンパボックス」と
いう、接続ピンを自由に選べる装置も売っています。

<!--
<sect2> Measuring Voltages
-->
<sect2> 電圧の測定
<!--
<p> Any voltmeter or multimeter, even the cheapest that sells for
about $10, should work fine.  Trying to use other methods for
checking voltage is tricky.  Don't use a LED unless it has a series
resistor to reduce the voltage across the LED.  A 470 ohm resistor is
used for a 20 ma LED (but not all LED's are 20 ma).  The LED will
only light for a certain polarity so you may test for + or - voltages.
Does anyone make such a gadget for automotive circuit testing??  Logic
probes may be damaged if you try to use them since the TTL voltages
for which they are designed are only 5 volts.  Trying to use a 12 V
incandescent light bulb is not a good idea.  It won't show polarity
and due to limited output current of the UART it probably will not
even light up.
-->
<p>どんな電圧計やテスタでも(10 ドルで売られているような安物でさえ)うま
く使えるはずです。
電圧のチェックに他の方法を使うのは面倒です。
抵抗を直列に繋い
で LED にかかる電圧を下げない限り、LED を使ってはいけません。
20 mA の LED では 470Ω の抵抗を使ってください(ただし全ての LED が 20
mA とは限りません)。LED は決まった極性でしか光らないので、+ と - の電
圧を調べることができます。自動的に回路を検査するこのような小物を誰か作
りませんか? 論理プローブは使おうとすると壊れてしまうかもしれません。
というのも、TTL が想定している電圧はたったの 5 V だからです。12
V の白熱電球を使うのはやめた方がいいでしょう。電球では極性はわかりませ
んし、UART の出力電流は限られているため、たぶん光ることさえないでしょ
う。

<!--
To measure voltage on a female connector you may plug in a bent paper
clip into the desired opening.  The paper clip's diameter should be no
larger than the pins so that it doesn't damage the contact.  Clip
an alligator clip (or the like) to the paper clip to connect up.
-->
メスのコネクタの電圧を測定するには、曲げたペーパークリップを調べたい穴
に差し込むとよいでしょう。ペーパークリップの直径はピンよりも小さいはず
なので、接触部を傷つけることはありません。接続するためには、ワニ口ク
リップ(等)でペーパークリップを挟みましょう。

<!--
<sect2> Taste Voltage
-->
<sect2> 電圧を味わってみる
<!--
<p> As a last resort, if you have no test equipment and are willing to
risk getting shocked (or even electrocuted) you can always taste the
voltage.  Before touching one of the test leads with your tongue, test
them to make sure that there is no high voltage on them.  Touch both
leads (at the same time) to one hand to see if they shock you.  Then
if no shock, wet the skin contact points by licking and repeat.  If
this test gives you a shock, you certainly don't want to use your
tongue.
-->
<p>テストに使える器具が無く、かつ電気ショックを受ける(感電さえする)覚
悟があれば、最後の手段として電圧を味わうという方法もあります。調べる導
線をなめる前には、高圧電流が流れていないことを確かめましょう。両方の導
線に(同時に)片方の手で触れ、ショックを受けるかどうかを確認します。
ショックを受けなければ接触部の肌をなめて濡らし、再び導線に触れてみましょ
う。これでショックを受ければ、なめてみる気はきっとなくなるでしょう。

<!--
For the test for 12 V, Lick a finger and hold one test lead in it.
Put the other test lead on your tongue.  If the lead on your tongue is
positive, there will be a noticeable taste.  You might try this with
flashlight batteries first so you will know what taste to expect.
-->
12 V を調べるには、まず指をなめて、一方の導線をその指に押しつけます。
次に別の導線に舌で触れます。舌で触れた導線に正の電圧がかかっていれ
ば、はっきりとした味がするでしょう。どんな味がするか前もって知っておき
たければ、懐中電灯の電池をなめてみるといいでしょう。

<!--
<sect1> Serial Monitoring/Diagnostics
-->
<sect1> シリアルポートの監視と診断
<!--
<p> A few Linux programs will monitor the modem control lines and
indicate if they are positive (1) or negative (0).  See section <ref
id="serial_mon" name="Serial Monitoring/Diagnostics">
-->
<p>モデム制御線を監視し、その電圧が正(1)であるか負(0)であるかを示す 
Linux 用のプログラムがいくつかあります。
<ref id="serial_mon" name="シリアルポートの監視/診断用のプログラム">
の章をご覧ください。

<!-- currently in <sect>Troubleshooting -->
<!-- troubleshooting.H begin 
Change Log: 
Apr. 00: 2 ports on same address		-->
<!--
<sect1> The following subsections are in both the Serial and Modem HOWTOs:
-->
<sect1> 以下の節は Serial-HOWTO にも Modem-HOWTO にもあります:

<!--
<sect1> My Serial Port is Physically There but Can't be Found 
-->
<sect1> 物理的にはシリアルポートがあるのに、検出されません
<label id="cant_find_port">
<!--O
<p> If a device (such as a modem) give evidence of working, then the
serial port that it's on has been found.  If it doesn't work at all, then
you need to make sure your serial port can be found.  
-->
<p> デバイス(モデムなど)が確かに動作しているなら、そのデバイスが
繋がっているシリアルポートは検出されています。
まったく動作しないのであれば、
シリアルポートが検出できることを確かめる必要があります。

<!--O
Check the BIOS menus and BIOS messages.  For the PCI bus use lspci.  
If it's an ISA bus PnP serial port, try "pnpdump -/-dumpregs" and/or
see Plug-and-Play-HOWTO.  Using "scanport" will scan all ISA bus ports
and may discover an unknown port that could be a serial port (but it
doesn't probe the port).  It could hang your PC.  You may try probing
with setserial.  See <ref id="probing_ss" name="Probing">.  If
nothing seems to get thru the port it may be accessible but have a bad
interrupt.  See <ref id="slow_" name="Extremely Slow: Text appears on
the screen slowly after long delays">.
-->
BIOS のメニューと出力メッセージを確認しましょう。
PCI バスならば lspci を使います。
ISA バス上の PnP 
シリアルポートの場合には、"pnpdump --dumpregs" を試したり、
Plug-and-Play-HOWTO をご覧になってください。
"scanport" を使うと、ISA 上の全てのポートをスキャンし、
シリアルポートかもしれない未知のポートを見つけることができます(ただし
ポートの探査は行いません)。scanport は PC をハングさせるかもしれません。
setserial を使って探査を行ってもよいで
しょう。<ref id="probing_ss" name="探査">の節を参照してください。
シリアルポートにデータが何も流れていないようであれば、シリアルポートは
あっても割り込みが間違っているかもしれません。
<ref id="slow_" name="この上なく遅い: テキストがすごく遅れてゆっくり画面に表示されます">
の節をご覧ください。

<!--O
If two ports have the same IO address then probing it will erroneously
indicate only one port.  Plug-and-play detection will find both ports
so this should only be a problem if at least one port is not
plug-and-play.  All sorts of errors may be reported/observed for
devices on "sharing" a port but the fact that there are two devices on
the same a port doesn't seem to get detected (except hopefully by
you).  If the IRQs are different then probing for IRQs with setserial
might "detect" this situation by failing to detect an IRQ.  See <ref
id="probing_ss" name="Probing">. 
-->
2 つのポートが同じ I/O アドレスを持っている場合、探査では間違って
ポートが一つしか示されません。プラグ&amp;プレイによる検出では
両方のポートが見つかるので、これが問題になるのは、プラグ&amp;プレイで
ないポートが少なくとも一つある場合だけです。
「共有」されているポートに接続しているデバイスではほとんどどんなエラー
でも報告/検出されることがありますが、同じポートに 2 つのデバイスが繋がっ
ているという事実は検出されないようです(幸いにも自分で見つける場合は除
きます)。IRQ が違う場合には、setserial で各 IRQ を探査したときに
IRQ の検出に失敗することにより、この状態を「検出」できると思います。
<ref id="probing_ss" name="探査">の節をご覧ください。

<!--
<sect1> Extremely Slow: Text appears on the screen slowly after long delays 
 <label id="slow_">
-->
<sect1> この上なく遅い: テキストがすごく遅れてゆっくり画面に表示されます
 <label id="slow_">
<!--
<p> It's likely mis-set/conflicting interrupts.  Here are some of the
symptoms which will happen the first time you try to use a modem,
terminal, or printer.  In some cases you type something but nothing
appears on the screen until many seconds later.  Only the last
character typed may show up.  It may be just an invisible
&lt;return&gt character so all you notice is that the cursor jumps
down one line.  In other cases where a lot of data should appear on
the screen, only a batch of about 16 characters appear.  Then there is
a long wait of many seconds for the next batch of characters.  You
might also get "input overrun" error messages (or find them in logs).
-->
<p> これは割り込みの設定が間違っているか、衝突しているためでしょう。
初めてモデムや端末、プリンタを使おうとしたときに出会うような現象をいく
つか示します。場合によっては、入力した文字が何秒も経たないと表示されな
いことがあります。入力した最後の文字しか表示されないこともあります。
また、その文字が単に目に見えない&lt;改行&gt;文字で、カーソルが 1 行下
に移動したことしかわからないこともあります。また別の場合としては、
画面にデータはたくさん表示されるのですが、16 文字ごとのかたまりでしか
表示されないこともあります。そして、あるかたまりの次のかたまりが表示さ
れるまでには何秒もの長い待ち時間が続きます。
「input overrun(入力オーバーラン)」のエラーメッセージが表示される(ある
いはログに残る)こともあります。

<!--
For more details on the symptoms and why this happens see
-->
詳しい症状とそれが起こる理由については、

<!--
<ref id="irq_prob_details" name="Interrupt Problem Details"> and/or <ref
id="irq_conflict" name="Interrupt Conflicts"> and/or <ref id="irq_ng"
name="Mis-set Interrupts">.
-->
<ref id="irq_prob_details" name="割り込みの問題に関する詳しい説明">の
章や<ref id="irq_conflict" name="割り込みの衝突">の節、<ref id="irq_ng"
name="割り込みの設定ミス">の節を見てください。
<!--
If it involves Plug-and-Play devices, see also Plug-and-Play-HOWTO. 
-->
プラグ&amp;プレイデバイスがらみの問題なら、Plug-and-Play-HOWTO も
見てください。

<!--
As a quick check to see if it really is an interrupt problem, set the
IRQ to 0 with "setserial".  This will tell the driver to use
polling instead of interrupts.  If this seems to fix the "slow"
problem then you had an interrupt problem.  You should still try to
solve the problem since polling uses excessive computer resources and
sometimes drastically decreases your thruput.
-->
本当に割り込みの問題かどうかを簡易的に調べるには、"setserial" で IRQ 
を 0 に設定してください。これにより、ドライバは割り込みではなくポーリ
ングを使うようになります。
これで「遅い」問題が解決するようであれば、割り込みの問題が起きています。
ただし、その場合でも割り込みの問題を解決すべきです。なぜなら、
ポーリングはコンピュータの資源を大量に消費しますし、時には
スループットを劇的に低下させるからです。

<!--
Checking to find the interrupt conflict may not be easy since Linux
supposedly doesn't permit any interrupt conflicts and will send you a
<ref id="busy_err" name="/dev/ttyS?: Device or resource busy"> error
message if it thinks you are attempting to create a conflict.  But a
real conflict can be created if "setserial" has incorrect information.
Thus using "setserial" will not reveal the conflict (nor will looking
at /proc/interrupts which bases its info on "setserial").  You still
need to know what "setserial" thinks so that you can pinpoint where
it's wrong and change it when you determine what's really set in the
hardware.
-->
割り込みの衝突を見つけだすのは容易ではないかもしれません。というのも、
Linux は割り込みの衝突を全く許さず、ユーザが衝突を起こそうとしていると
判断すると<ref id="busy_err" name="/dev/ttyS?: Device or resource busy"> 
エラーを送ることになっているからです。
しかし、本当に衝突が起こる可能性があるのは
"setserial" が間違った情報を指定していた場合です。
したがって、"setserial" 
を使っても衝突は明らかになりません(また、"setserial" の情報に基づいて
設定される /proc/interrupts を調べても衝突はわかりません)。
それでもハードウェアの実際の設定を調べる時に、間違っている部分を正確に
突き止めて直すには、"setserial" に設定されている情報を知らなければなり
ません。

<!--O
What you need to do is to check how the hardware is set by checking
jumpers or using PnP software to check how the hardware is actually
set.  For PnP run either "pnpdump -/-dumpregs" (if ISA bus) or run
"lspci" (if PCI bus).  Compare this to how Linux (e.g. "setserial")
thinks the hardware is set.
-->
こういった場合に行うべき作業は、ジャンパや PnP 設定ソフトウェアを使っ
て、ハードウェアに実際に設定されている情報を調べることです。PnP の場合
には、"pnpdump --dumpregs" (ISA バスの場合)または "lspci" (PCI バスの
場合)を実行しましょう。
そして、Linux ("setserial" 等)が考えているハードウェアの設定とこの結果
を比べてください。

<!--O
<sect1> Somewhat Slow: I expected it to be a few times faster
-->
<sect1> なぜか遅い: あと 2、3 倍は速いはずなのですが
<!--O
<p> One reason may be that whatever is on the serial port (such as a
modem, terminal, printer) doesn't work as fast as you thought it did.
-->
<p> 考えられる理由の一つは、シリアルポートを使っているデバイス(モデム
や端末、プリンタ)が、あなたが考えているほど速く動作しないことです。

<!--O
Another possible reason is that the serial driver thinks you have an
obsolete serial port (UART 8250,16450 or early 16550).  See <ref
id="uart_" name="What Are UARTs?">.  Use "setserial -g /dev/ttyS*".
If it shows anything less than a 16550A, this is likely your problem.
Then if "setserial" has it wrong, change it.  See <ref id="set_serial"
name="What is Setserial"> for more info.  Of course if you really do
have an obsolete serial port, lying about it to setserial will only
make things worse.
-->
考えられる別の理由は、あなたが使っているシリアルポートが古い
(UART 8250, 16450 や初期の 16550)とシリアルドライバが認識していること
です。<ref id="uart_" name="UART とは何ですか?">を参照し、
"setserial -g /dev/ttyS*" を使ってください。その結果として 16550A より
性能がよくない UART が表示されたら、これは多分設定の問題です。
この場合は、"setserial" の設定に問題があれば、これを変更します。
詳しくは <ref id="set_serial" name="setserial とは何か?">を見てください。
当然のことですが、実際は古いシリアルポートを使っているのに setserial 
をだまそうとしても、単に事態が悪化するだけです。

<!--
<sect1>The Startup Screen Show Wrong IRQs for the Serial Ports.
-->
<sect1>システム起動時の画面で、シリアルポートの IRQ が間違って表示されます
<!--
<p> Linux does not do any IRQ detection on startup.  When the serial
module loads it only does serial device detection.  Thus, disregard
what it says about the IRQ, because it's just assuming the standard
IRQs.  This is done, because IRQ detection is unreliable, and can be
fooled.  But if and when setserial runs from a start-up script, it
changes the IRQ's and displays the new (and hopefully correct) state
on on the startup screen.  If the wrong IRQ is not corrected by a
later display on the screen, then you've got a problem.
-->
<p>Linux カーネルはシステムの起動時に IRQ の検出は全く行いません。
serial モジュールがロードされた時に、シリアルデバイスの検出が行われる
だけです。したがって、カーネルが IRQ に関して行う表示は無視してくださ
い。なぜなら、この時点では標準の IRQ を決め打ちしているからです。この
ようになっているのは、IRQ 検出は当てにならず、間違うことがあるからです。
しかし setserial が起動スクリプトから実行された場合には、setserial は 
IRQ を変更し、新しい(そして多分正しい)状態を起動画面に表示します。
間違った IRQ が後で訂正されて画面に表示されなければ、何か問題が起こっ
ています。

<!--
So, even though I have my <tt/ttyS2/ set at IRQ 5, I still see
-->
よって、IRQ 5 に設定されている <tt/ttyS2/ がある場合であっても、Linux 
の起動時には
<tscreen><verb>
ttyS02 at 0x03e8 (irq = 4) is a 16550A
</verb></tscreen>
<!--
at first when Linux boots.  (Older kernels may show "ttyS02" as "tty02")
You have to use <tt/setserial/ to tell Linux the IRQ you are using.
-->
と表示されます(古いカーネルでは "ttyS02" のところが "tty02" となります)。
実際に使う IRQ を Linux に知らせるには、<tt/setserial/ を使わなければ
なりません。

<!--
<sect1> "Cannot open /dev/ttyS?: Permission denied"
-->
<sect1> "Cannot open /dev/ttyS?: Permission denied" というエラーが出ます
<!--
<p> Check the file permissions on this port with "ls -l /dev/ttyS?"_
If you own the ttyS? then you need read and write permissions: crw
with the c (Character device) in col. 1.  It you don't own it then it
should show rw- in cols. 8 &amp; 9 which means that everyone has read and
write permission on it.  Use "chmod" to change permissions.  There are
more complicated ways to get access like belonging to a "group" that
has group permission.
-->
<p> "ls -l /dev/ttyS?" を実行してそのポートのファイルのパーミッション
を調べてみましょう。ttyS? の所有者が自分であれば、読み書きのパーミッショ
ンとして crw が必要です。最初の桁は c (キャラクタデバイス)です。ポート
の所有者でなければ、8 桁目と 9 桁目が rw- でなければなりません。つまり
誰でもそのポートを読み書きできなければなりません。
パーミッションを変更するには "chmod" を使います。
アクセス権限を得る方法としては、グループパーミッションを持っている
「グループ」に所属するといったもっと複雑なものもあります。

<!--
<sect1> "Operation not supported by device" for ttyS?
-->
<sect1> ttyS? について "Operation not supported by device" というエラーが出る
<!--
<p> This means that an operation requested by setserial, stty, etc.
couldn't be done because the kernel doesn't support doing it.
Formerly this was often due to the "serial" module not being loaded.
But with the advent of PnP, it may likely mean that there is no modem
(or other serial device) at the address where the driver (and
setserial) thinks it is.  If there is no modem there, commands (for
operations) sent to that address obviously don't get done.  See <ref
id="io-irq_in_hdw" name="What is set in my serial port hardware?">
-->
<p> このエラーは、カーネルがサポートしていないために、setserial や 
stty 等が要求した操作が行えないという意味です。以前は "serial" モジュー
ルがロードされてないことが原因の場合が多かったのですが、PnP の登場によ
り、このエラーはドライバ(および setserial)が考えているアドレスにモデム
(あるいは他のシリアルデバイス)がないことを示すことが多くなりました。こ
ういったアドレスにモデムがなければ、そのアドレスに送られた(操作のため
の)コマンドは当然ながら処理されません。
<ref id="io-irq_in_hdw" name="シリアルポートのハードウェアの設定は?">
の節をご覧ください。

<!--
If the "serial" module wasn't loaded but "lsmod" shows you it's now
loaded it might be the case that it's loaded now but wasn't loaded
when you got the error message.  In many cases the module will
automatically loaded when needed (if it can be found).  To force
loading of the "serial" module it may be listed in the file:
/etc/modules.conf or /etc/modules.  The actual module should reside
in: /lib/modules/.../misc/serial.o.
-->
"serial" モジュールがロードされていなかったが今ロードしたと 
"lsmod" が表示する場合は、モジュールは今ロードされたけれど、
エラーが出た時にはロードされていなかったのかもしれません。
多くの場合、モジュールは必要な時に自動的にロードされます(もし見つけること
ができれば)。"serial" モジュールを強制的にロードさせるには、
/etc/modules.conf または /etc/modules に記述しておきます。モジュールそ
のものは /lib/modules/.../misc/serial.o にあるはずです。

<!--
<sect1> "Cannot create lockfile. Sorry"
-->
<sect1> "Cannot create lockfile. Sorry" (エラーメッセージ)
<!--
<p> When a port is "opened" by a program a lockfile is created in
/var/lock/.  Wrong permissions for the lock directory will not allow a
lockfile to be created there.  Use "ls -ld /var/lock" to see if the
permissions are OK: usually rwx for everyone (repeated 3 times).  If
it's wrong, use "chmod" to fix it.  Of course, if there is no "lock"
directory no lockfile can be created there.  For more info on
lockfiles see <ref id="lockfiles_" name="What
Are Lock Files"> 
-->
<p> 何らかのプログラムがポートを「オープン」する時、ロックファイル
が /var/lock/ に作られます。lock ディレクトリのパーミッションが間違っ
ていると、ここにロックファイルを作れません。パーミッションが正しいかど
うかを確認するには "ls -ld /var/lock" を使います。普通は全員に対して
rwx です(rwx が 3 度繰り返されます)。パーミッションが間違っている場合
には、"chmod" コマンドを使って修正します。もちろん、"lock" ディレクト
リがなければ、そこにロックファイルを作ることはできません。ロックファイ
ルに関する、より詳しい情報については
<ref id="lockfiles_" name="ロックファイルとは何ですか?">の節をご覧くだ
さい。

<!--O
<sect1> "Device /dev/ttyS? is locked."
-->
<sect1> "Device /dev/ttyS? is locked." (デバイス /dev/ttyS? がロックされています)
<!--O
<p> This means that someone else (or some other process) is supposedly
using the serial port.  There are various ways to try to find out what
process is "using" it.  One way is to look at the contents of the
lockfile (/var/lock/LCK...).  It should be the process id.  If the
process id is say 261 type "ps 261" to find out what it is.  Then if
the process is no longer needed, it may be gracefully killed by "kill
261".  If it refuses to be killed use "kill -9 261" to force it to be
killed, but then the lockfile will not be removed and you'll need to
delete it manually.  Of course if there is no such process as 161 then
you may just remove the lockfile but in most cases the lockfile should
have been automatically removed if it contained a stale process id
(such as 261).
-->
<p>このメッセージが出た場合にはおそらく、誰か他の人(あるいは他のプロセ
ス)がシリアルポートを使っています。このポートを「使用中」のプロセスを
見つける方法はいくつもあります。一つの方法は、ロックファイル
(/var/lock/LCK...)の中身を見ることです。これは、ポートを使っている
プロセスの ID のはずです。プロセス ID が 例えば 261 ならば、"ps 261" 
を実行し、それが何かを調べましょう。そして、そのプロセスがもはや不要であれば、
"kill 261" で優しく kill してもいいでしょう。これで終了しないなら、
"kill -9 261" を実行して強制的に kill してください。ただし、この場合に
はロックファイルが消されずに残るので、手で消す必要があるでしょう。
もちろん、261 のようなプロセスが存在しなければ単にロックファイルを消
してかまいません。しかし、ロックファイルが示すプロセス ID (261 等)が
無効であれば、多くの場合そのロックファイルは自動的に削除されるはずです。

<!--O
<sect1> "/dev/ttyS?: Device or resource busy" <label id="busy_err">
-->
<sect1> "/dev/ttyS?: Device or resource busy" <label id="busy_err">
<!--O
<p> This means that the device you are trying to access (or use) is
supposedly busy (in use) or that a resource it needs (such as an IRQ)
is supposedly being used by another device.  Sometimes it actually is
"busy" but in other cases it erroneously appears to be "busy".
-->
<p>これはアクセス(つまり使用)しようとしているデバイスがビジー状態
(使用中)と考えられるか、デバイスが必要としているリソース(IRQ 等)が
他のデバイスに使われていると考えられることを示します。本当に
「ビジー状態」のこともありますが、そうでなければ間違って
「ビジー状態」のように見えているだけです。

<!--O
The ``resource busy'' part often means (example for <tt/ttyS2/) ``You
can't use <tt/ttyS2/ since another device is using ttyS2's
interrupt.'' The potential interrupt conflict is inferred from what
"setserial" thinks.  A more accurate error message would be ``Can't
use <tt/ttyS2/ since the setserial data (and kernel data) indicates
that another device is using <tt/ttyS2/'s interrupt''.  If two devices
use the same IRQ and you start up only one of the devices, everything
is OK because there is no conflict yet.  But when you next try to
start the second device (without quitting the first device) you get a
"... resource busy" error message.  This is because the kernel only
keeps track of what IRQs are actually in use and conflicts don't
happen unless the devices are in use (open).
-->
``resource busy'' の部分はよく、(例えば ttyS2 で)「他のデバイスが <tt/ttyS2/ 
の割り込みを使用中なので、<tt/ttyS2/ は使えません」という意味になります。
"setserial" の設定による割り込みの衝突の可能性が考えられます。このエラー
メッセージをもっと正確に言うと、「<tt/ttyS2/ を使えません。setserial の
データ(とカーネルのデータ)が、他のデバイスが <tt/ttyS2/ の割り込みを使っ
ていると示しています」となるでしょう。2 つのデバイスが同じ IRQ を使っ
ていても、そのうちの片方しか起動していなければ何も問題は起きません。
まだ衝突は起きていないからです。しかし、次に(最初のデバイスを終了させ
ないままで) 2 番目のデバイスを起動しようとすると、"... resource busy" 
のエラーメッセージが出ます。こうなるのは、カーネルが追跡するのはどの 
IRQ が実際に使われているかだけなので、デバイスが使用(オープン)されなけ
れば衝突は起きないからです。

<!--O
There are two cases.  There may be a real interrupt conflict that is
being avoided.  But if setserial has it wrong, there may be no reason
why <tt/ttyS2/ can't be used, except that setserial erroneously predicts a
conflict.  What you need to do is to find the interrupt setserial
thinks <tt/ttyS2/ is using.  This is easier said than done since you can't
use the "setserial" command for <tt/ttyS2/ since the IRQ for ttyS2 is
supposedly "busy" and you will get the same "... busy" error message.
To fix this either reboot or: exit or gracefully kill all likely
conflicting processes.   If you reboot: 1. Watch the boot-time
messages for the serial ports.  2. Hope that the file that runs
"setserial" at boot-time doesn't (by itself) create the same conflict
again.
-->
2 通りの場合が考えられます。
まず、本当に割り込みが衝突しそうなので、それを避けようとしているという
場合もあるでしょう。
しかし、setserial が勘違いをしているという場合もありますし、
そうだとすると(setserial が間違った衝突を予測したという以外には) 
<tt/ttyS2/ が使えない理由はどこにもないはずです。
ここですべきことは、<tt/ttyS2/ が使っていると 
setserial が考えている割り込み番号を調べることです。これは言うのは簡単
ですが、<tt/ttyS2/ に対して "setserial" を使えないため、実際にやるのは
面倒です。"setserial" が使えないのは、ttyS2 の IRQ は「ビジー状態」と
いうことになっており、同じく "device busy" のエラーメッセージを出すからです。
これを解決するには、再起動するか、衝突していそうなプロセスを優しく 
kill してください。再起動する際には次のことを行ってください。
<enum>
<item>シリアルポートに関する起動メッセージをよく見る。
<item>起動時に "setserial" を実行するファイルが(単独で)同じ衝突を繰り
返して起こさないことを祈る。
</enum>

<!--O
If you think you know what IRQ <tt/ttyS2/ is using then you may look
at /proc/interrupts to find what else is currently using this IRQ.
You might also want to double check that any suspicious IRQs shown
here (and by "setserial") are correct (the same as set in the
hardware).  A way to test whether or not it is a potential interrupt
conflict is to set the IRQ to 0 (polling) using "setserial".  Then if
the busy message goes away, it was likely a potential interrupt
conflcit.  It's not a good idea to leave it permanently set at 0 since
more CPU resources will be used.
-->
<tt/ttyS2/ が使っている IRQ を知っているつもりであれば、
/proc/interrupts を見て、現在その IRQ を使っている他のデバイスを見つけ
るとよいでしょう。/proc/interrupts (や "setserial")が示す疑わしい IRQ 
が正しい(ハードウェアの設定と同じ)かどうかを全てチェックし直すのもよい
でしょう。割り込みが衝突している可能性があるかどうかを調べる方法は、
"setserial" を使って IRQ に 0 (ポーリング)を設定することです。
IRQ にずっと 0 を設定したままにするのはよくありません。というのも、CPU 
の資源を余計に使うからです。

<!--
<sect1> Troubleshooting Tools
-->
<sect1> トラブル対処のためのツール
<!--O
<p> These are some of the programs you might want to use in
troubleshooting:
-->
<p> トラブルに対処する時に使うとよいプログラムがいくつかあります:
<itemize>
<!--O
<item> "lsof /dev/ttyS*" will list serial ports which are open.
-->
<item> "lsof /dev/ttyS*" により、オープンされているシリアルポートが
リスト表示されます。
<!--O
<item> "setserial" shows and sets the low-level hardware configuration
 of a port (what the driver thinks it is).  See <ref id="set_serial"
 name="What is Setserial">
-->
<item> "setserial" は、シリアルポートの低レベルハードウェア設定の表示
と設定を行います(ドライバ側の設定です)。詳しくは
<ref id="set_serial"  name="setserial とは何か?">
の節を見てください。
<!--O
<item> "stty" shows and sets the configuration of a port (except for
 that handled by "setserial").
  See the section <ref id="stty_" name="Stty"><item> "modemstat" or "statserial" will show the current state of
 various modem signal lines (such as DTR, CTS, etc.)
-->
<item> "stty" はシリアルポートの設定("setserial" が扱う部分を除く)の表
示と設定を行います。<ref id="stty_" name="stty"> の節を見てください。
<item> "modemstat" と "statserial" は、モデムの各種信号線(DTR, 
CTS など)の現在の状態を表示します。
<!--
<item> "irqtune" will give serial port interrupts higher
 priority to improve performance.
-->
<item> "irqtune" を使えば、シリアルポートの割り込みの優先度を上げて
性能を向上させることができます。
<!--O
<item> "hdparm" for hard-disk tuning may help some more.
-->
<item> ハードディスクのチューニングを行う "hdparm" もいくらか役に立
つかもしれません。
<!--O
<item> "lspci" shows the actual IRQs, etc. of hardware on the PCI bus.
-->
<item> "lspci" は、PCI バス上のハードウェアの実際の IRQ 等を表示します。
<!--O
<item> "pnpdump -/-dumpregs" shows the actual IRQs, etc. of hardware for
 PnP devices on the ISA bus.
-->
<item>  "pnpdump --dumpregs" は、ISA バス上の PnP デバイスについて、
ハードウェアの実際の IRQ 等を表示します。
<!--O
<item> Some "files" in the /proc tree (such as ioports and
 interrupts).
-->
<item> /proc ディレクトリの「ファイル」のいくつか(ioports や 
interrupts 等)。
</itemize>
<!-- troubleshooting.H end -->

<!--
<sect> Interrupt Problem Details <label id="irq_prob_details">
-->
<sect> 割り込みの問題に関する詳しい説明 <label id="irq_prob_details">
<!--
<p> While the section <ref id="trouble_shoot" name="Troubleshooting">
lists problems by symptom, this section explains what will happen if
interrupts are set incorrectly.  This section helps you understand what
caused the symptom, what other symptoms might be due to the same
problem, and what to do about it.
-->
<p><ref id="trouble_shoot" name="トラブルシューティング">の章では症状
別に問題点を挙げていますが、この章では割り込みの設定を誤っている場合に
何が起こるのかを説明します。この章は、何がその症状を起こすのか、同じ原
因で他のどんな症状が出るのか、これらにどう対処すべきなのかを理解する助
けになるでしょう。

<!--O
<sect1> Types of interrupt problems
-->
<sect1> 割り込みの問題の種類
<!--O
<p> The "setserial" program will show you how serial driver thinks the
interrupts are set.  If the serial driver (and setserial) has it right
then everything regarding interrupts should be OK.  Of course a
/dev/ttyS must exist for the device and Plug-and-Play (or jumpers)
must have set an address and IRQ in the hardware.  Linux will not
knowingly permit an interrupt conflict and you will get a "Device or
resource busy" error message if you attempt to do something that would
create a conflict.
-->
<p> "setserial" プログラムは、シリアルドライバが考えている割り込みの
設定を表示します。シリアルドライバ(と setserial)が正しい情報を持ってい
れば、割り込みに関することは全てうまく行くはずです。もちろん、
デバイスに対応する /dev/ttyS ファイルは存在しなければなりませんし、
プラグ&amp;プレイ(またはジャンパ)でハードウェアにアドレスと IRQ を設定
していなければなりません。Linux は割り込みの衝突を知っていて許可するこ
とはないので、衝突を起こすような設定を試みると
"Device or resource busy" というエラーメッセージが表示されます。

<!--O
Since the kernel tries to avoid interrupt conflicts and gives you the
"resource busy" message if you try to create a conflict, how can
interrupt conflicts happen?  Easy.  "setserial" may have it wrong and
erroneously predicts no conflict when there will actually be a real
conflict based on what is set in the hardware.  When this happens
there will be no "... busy" message but performance will be extremely
slow.  Both devices will send identical interrupt signals on the same
wire and the CPU will erroneously think that the interrupts only come
from one device.  This will be explained in detail in the following
sections.
-->
ユーザが割り込みを衝突させそうになるとカーネルは割り込みの衝突を避けよ
うとして "resource busy" というメッセージを出します。
すると割り込みの衝突が起こることはあり得ないのでしょうか?
いいえ、簡単に起こります。
ハードウェアの設定が本当に衝突を起こしそうなときに setserial が判断を
誤り、「衝突はない」と嘘をつくこともあるのです。
このような場
合、"... busy" というメッセージは出ませんが、性能が著しく悪くなります。
2 つのデバイスは同じ割り込み信号を同じ信号線に送るので、CPU は割り込み
が 1 つのデバイスからしか来ていないと勘違いします。
これについては以降の節で詳しく説明します。

<!--O
Linux doesn't complain when you assign two devices the same IRQ
provided that neither device is in use.  As each device starts up
(initializes), it asks Linux for permission to use its hardware
interrupt.  Linux keeps track of which interrupt is assigned to whom,
and if your interrupt is already in use, you'll see this "... busy"
error message.  Thus if two devices use the same IRQ and you start up
only one of the devices, everything is OK.  But when you next try to
start the second device (without quitting the first device) you get
"... busy" error message.
-->
2 つのデバイスに同じ IRQ を割り当てても、どちらのデバイスも使われてい
なければ Linux は文句を言いません。それぞれのデバイスは開始(初期化)の
際に、Linux にハードウェア割り込みを使う許可を求めます。Linux はどの
割り込みがどのデバイスに割り当てられているかを管理しているので、その
割り込みが既に使われていると、"... busy" のエラーメッセージが出力され
ることになります。したがって、2 つのデバイスが同じ IRQ を使っていても、
1 つのデバイスしか使わなければ、何も問題はありません。しかし、(最初の
デバイスを終了させずに)次のデバイスを使おうとすると、"... busy" の
エラーメッセージが出ることになります。

<!--
<sect1> Symptoms of Mis-set or Conflicting Interrupts
-->
<sect1> 割り込みの誤設定や衝突で起こる症状
<!--
<p> The symptoms depend on whether or not you have a modern serial port
with FIFO buffers or an obsolete serial port without FIFO buffers.
It's important to understand the symptoms for the obsolete ones also 
since sometimes modern ports seem to behave that way.
-->
<p> 起きる症状は、最近の FIFO バッファを持っているシリアルポートを使っ
ているかどうか、あるいは FIFO バッファを持たない古いシリアルポートを使っ
ているかどうかで変わってきます。古いシリアルポートで起こる症状を理解す
ることも重要です。なぜなら、同じことが新しいシリアルポートで起こること
が時々あるようだからです。

<!--
For the obsolete serial ports, only one character gets thru every
several seconds.  This is so slow that it seems almost like nothing is
working (especially if the character that gets thru is invisible (such
a space or newline).  For the modern ports with FIFO buffers you
will likely see bursts of up to 16 characters every several seconds.
-->
古いシリアルポートの場合には、数秒ごとに 1 文字しか通過できません。こ
れは非常に遅いので、ほとんど動作していないように見えます(特に、空白文字
や改行文字などの見えない文字が通過する場合)。FIFO バッファを持つ新しい
シリアルポートの場合には、数秒後の間に 16 文字までが流れていくのが見
えるでしょう。

<!--
If you have a modem on the port and dial a number, it seemingly
not connect since the CONNECT message may not make it thru.  But after
a long wait it may finally connect and you may see part of a login
message (or the like).  The response from your side of the connection
may be so delayed that the other side gives up and disconnects you,
resulting in a NO CARRIER message.
-->
ポートにモデムが繋がっていて電話番号をダイアルしても、CONNECT メッセー
ジが通らないため、接続していないように見えます。しかしずっと待ってか
ら接続し、ログインメッセージ(あるいはその類)の一部が最終的に表示される
かもしれません。接続のあなた側からの応答が遅れて、相手側があきらめて接
続を切ってしまい、"NO CARRIER" メッセージが出るかもしれません。

<!--
If you use minicom, a common test to see if things are working is to
type the simplest "AT" command and see if the modem responds.  Typing
just at&lt;enter&gt; should normally (if interrupts are OK) result in
an immediate "OK" response from the modem.  With bad interrupts you
type at&lt;enter&gt; and may see nothing.  But then after 10 seconds
or so you see the cursor drop down one line.  What is going on is that
the FIFO is behaving like it can only hold one byte.  The "at" you
typed caused it to overrun and both letters were lost.  But the final
&lt;enter&gt; got thru since you waited for it and you "see" this
invisible character by noting that the cursor jumped down one line.
If you were to type a single letter and then wait about 10 seconds,
you should see it echo back to the screen.  This is fine if your
typing speed is less that one word per minute :-)
-->
minicom を使っている場合にうまく動作しているかどうか調べるための一般的
なテスト方法は、一番簡単なコマンドである "AT" を入力し、これにモデムが
反応するかどうかを調べることです。単に at&lt;enter&gt; を入力すると、
普通は(割り込みが OK ならば)即座にモデムから "OK" という返事があるはずです。
割り込みの設定がおかしければ、at&lt;enter&gt; を入力しても何も返ってこ
ないかもしれません。しかし 10 秒くらい経ってからカーソルが 1 行下がる
かもしれません。何が起こっているかというと、FIFO が 1 バイトしか保持で
きないように動作しているのです。入力した "at" は FIFO をオーバーランさ
せ、どちらの文字も消えてしまいます。しかし、しばらく待っていたために最
後の &lt;enter&gt; だけは通り、カーソルが 1 行下がることによって、この
見えない文字を「見る」ことになります。1 文字を入力してから 10 秒待てば、
その文字が画面にエコーバックされるはずです。あなたが文字を打てる速度が 
1 分間当り 1 単語より少なければ、これでも大丈夫でしょう :-)

<!--
<sect1> Mis-set Interrupts <label id="irq_ng">
-->
<sect1> 割り込みの設定ミス <label id="irq_ng">
<!--
<p> If you don't understand what an interrupt does see <ref
id="interrupt_" name="Interrupts">.  If a serial port has one IRQ set
in the hardware but a different one set in the device driver, the
device driver will not catch any interrupts sent by the serial port.
Since the serial port uses interrupts to call its driver to service
the port (fetching bytes from its 16-byte receive buffer or putting
another 16-bytes in its transmit buffer) one might expect that the
serial port would not work at all.  
-->
<p>割り込みの役割が分からなければ、先に
<ref id="interrupt_" name="割り込み">の節を見てください。
シリアルポートのハードウェアには IRQ が 1 つ設定されているけれど、
デバイスドライバ
にこれと異なる IRQ が設定されている場合、デバイスドライバはシリアル
ポートから送られる割り込みを全く捕捉しません。シリアルポートは割り込み
を使ってデバイスを呼び出してサービス(16 バイトの受信バッファからのバイ
トデータの受け取りや、16 バイトの送信バッファへのバイトデータの書き込み)
を要求するので、シリアルポートは全く動作しないと思われます。

<!--
But it still may work anyway &#045;&#045;sort of.  Why?  Well, besides the
interrupt method of servicing the port there's a slow polling method
that doesn't need interrupts.  The way it works is that every so often
the device driver checks the serial port to see if it needs anything
such as if it has some bytes that need fetching from its receive
buffer.  If interrupts don't work, the serial driver falls back to
this polling method.  But this polling method was not intended to be
used a substitute for interrupts.   It's so slow that it's not
practical to use and may cause buffer overruns.  Its purpose may have
been to get things going again if just one interrupt is lost or fails
to do the right thing.  It's also useful in showing you that
interrupts have failed.
-->
しかしそれでも動く--あるいは動いているように見えることもあります。これ
はどうしてでしょうか? つまり、シリアルポートにサービスを提供する方法に
は、割り込み以外にも遅いポーリングを使う方法があるのです。この方法は割り込
みを必要としません。ポーリングとは、デバイスドライバが時々シリアルポー
トを調べて、何か必要としているかどうか(例えば、受信バッファから取り込
む必要があるバイトデータが存在するかどうか)を見る方法です。割り込みが
使えなければ、シリアルドライバはこのポーリング法を最終的に使います。
しかし、このポーリングは割り込みの代わりに使うための方法ではありません。
ポーリングは遅いので実用的ではありませんし、バッファオーバーランを起
こすこともあるからです。ポーリングの目的は、割り込みが 1 つだけ無くな
るか、動作が正しくなかったときに、繰り返し正しい動作を行わせることだっ
たと思います。割り込みが失敗したことを示す際にも便利です。

<!--
For the 16-byte transmit buffer, 16 bytes will be transmitted and then
it will wait until the next polling takes place (several seconds
later) before the next 16 bytes are sent out.  Thus transmission is
very slow and in small chunks.  Receiving is slow too since bytes that
are received by the receive buffer are likely to remain there for
several seconds until it is polled.
-->
16 バイトの送信バッファは、16 バイトを転送すると待ちに入り、次の
ポーリングが(数秒後に)起こってからさらに 16 バイトを送りだします。
したがって、転送は非常に遅く、また細切れになります。
受信も遅くなります。なぜなら、受信バッファが受け取ったバイトデータは、
ポーリングが行われるまでの数秒間はバッファに留まるからです。

<!--
This explains why it takes so long before you see what you typed.
When you type say AT to a modem, the AT goes out the serial port to
the modem.  The modem then echos the AT back thru the serial port to
the screen.  Thus the AT characters have to pass twice thru the serial
port.  Normally this happens so fast that AT seems to appear on the
screen at the same time you hit the keys on the keyboard.  With
polling delays thru the serial port, you don't see what you typed
until many seconds later.
-->
入力した文字が表示されるまでに非常に時間がかかるのは、これが理由です。
例えば「AT」という文字列をモデムに送ると、「AT」はシリアルポートを出て
モデムに送られます。モデムはシリアルポートを通じて「AT」をスクリーンに
エコーバックします。このように、「AT」という文字列はシリアルポートを 2 
回通らなければなりません。普通はこの動作が非常に高速なので、キーボード
で入力したのと同時に「AT」という文字列が表示されるように見えます。ポー
リングのためにシリアルポートが遅い場合には、入力した文字は何秒も待たな
いと表示されません。

<!--
What about overruns of the 16-byte receive buffer?  This will happen
with an external modem since the modem just sends to the serial port
at high speed which is likely to overrun the 16-byte buffer.  But for
an internal modem, the serial port is on the same card and it's likely
to check that this receive buffer has room for more bytes before
putting received bytes into it.  In this case there will be no overrun
of this receive buffer, but text will just appear on your screen in
16-byte chunks spaced at intervals of several seconds.  
-->
16 バイトの受信バッファのオーバーランについてはどうでしょうか? これは
外付けモデムを使っている場合に起こります。というのも、モデムはシリアル
ポートに高速にデータを送るだけなので、16 バイトのバッファがオーバーラ
ンしてしまいます。しかし内蔵モデムの場合にはシリアルポートはモデムと同
じカード上にあるので、受信したバイトデータをこの受信バッファに入れる前
にバッファに空きがあるかどうかが多分チェックされます。この場合には、受
信バッファがオーバーランすることはありませんが、テキストは 16 バイトの
まとまりごとに数秒の間隔を置いて表示されます。

<!--
Even with an external modem you might not get overruns.  If just a few
characters (under 16) are sent you don't get overruns since the buffer
likely has room for them.  But attempts to send a larger number of
bytes from your modem to your screen may result in overruns.  However,
more than 16 (with no gaps) can get thru without overruns if the
timing is right.  For example, suppose a burst of 32 bytes is sent
into the port from the external cable.  The polling might just happen
after the first 16 bytes came in so it would pick up these 16 bytes
OK.  Then there would be space for the next 16 bytes so that entire 32
bytes gets thru OK.  While this scenario is not very likely, similar
cases where 17 to 31 bytes make thru are more likely.  But it's even
more likely that only an occasional 16-byte chunk will get thru with
possible loss of data.
-->
外付けモデムであってもオーバーランが起こらないことがあります。数文字
(16 文字以下)しか送られていない場合にはオーバーランは起こりません。バッ
ファには大抵、これだけの空きがあるからです。しかしこれより多いバイト数
をモデムから送ろうとすると、画面ではオーバーランが起こります。ただし、
タイミングさえ良ければオーバーランなしに 16 バイト(隙間無し)以上が通る
こともあります。例えば 32 バイトが外付けケーブルからポートに一気に送ら
れた場合を考えてみましょう。
前半の 16 バイトが来た後に、この 16 バイトをうまく受け取れるよう、
ポーリングが起こることもあります。
すると
次の 16 バイトまでには空き時間があるでしょうから、32 ビット全体がうま
く通ります。このシナリオ通りになることはあまりありませんが、同様の条件
により 17 バイトから 31 バイトが通ることはもっと高い可能性で起こります。
しかし、データを落としながら 16 バイトのデータのかたまりだけが断続的に
届くということはさらによくあります。

<!--
If you have an obsolete serial port with only a 1-byte buffer (or it's
been incorrectly set to work like a 1-byte buffer) then the situation
will be much worse than described above and only one character will
occasionally make it thru the port.  Every character received causes
an overrun (and is lost) except for the last character received.  This
character is likely to be just a line-feed since this is often the
last character to be transmitted in a burst of characters sent to your
screen.  Thus you may type AT&lt;return&gt to the modem but never see
AT on the screen.  All you see several seconds later is that the
cursor drops down one line (a line feed).  This has happened to me
with a 16-byte FIFO buffer that was behaving like a 1-byte buffer.
-->
1 バイトのバッファしか持たない古いシリアルポートの場合(あるいは設定を
誤って 1 バイトのバッファのような動作になっている場合)には、前に書いた
よりもずっと悪い状況になります。
つまり、1 つの文字だけが時々シリアルポートを通る
といった状態になります。最後に受け取った文字を除くと、受け取った文字は
全てオーバーランを起こします(そして失われます)。この最後の文字は単なる
改行文字であることがよくあります。というのも、改行文字は画面に一気に送
られる文字の中で最後の文字となることが多いからです。したがって、
AT&lt;return&gt; とモデムに入力しても、画面には AT と表示されないこと
があります。そして数秒後に起こるのは、カーソルが一行下に移動する(改行
文字)ことだけです。筆者には、16 バイトの FIFO バッファが 1 バイトのバッ
ファのように動作した経験があります。

<!--
When a communication program starts up, it expects interrupts to be
working.  It's not geared to using this slow polling-like mode of
operation.  Thus all sorts of mistakes may be made such as setting up
the serial port and/or modem incorrectly.  It may fail to realize when
a connection has been made.  If a script is being used for login, it
may fail (caused by timeout) due to the polling delays.
-->
通信プログラムは起動の時に、割り込みが動作していることを期待します。
ポーリング的なモードの遅い動作を使うようにはなっていません。
したがって、シリアルポートやモデムの設定ミスなど、どんな誤りを引き起こ
してもおかしくありません。
接続が確立した瞬間を見逃してしまうこともありえます。
ログインするためにスクリプトを使っている場合には、ポーリングの遅延のた
めにログインが(タイムアウトにより)失敗するかもしれません。

<!--
<sect1> Interrupt Conflicts <label id="irq_conflict">
-->
<sect1> 割り込みの衝突 <label id="irq_conflict">
<!--
<p> When two devices have the same IRQ number it's called sharing
interrupts.  Under some conditions this sharing works out OK.
Starting with kernel version 2.2, serial ports may, in some cases,
share interrupts with other serial ports.  Devices on the PCI bus may
share the same IRQ interrupt with other devices on the PCI bus.  In
other cases where there is potential for conflict, there should be no
problem if no two devices with the same IRQ are ever "in use" at the
same time.   More precisely, "in use" really means "open" (in
programmer jargon).  In cases other than the exceptions mentioned
above (unless special software and hardware permit sharing), sharing
is not allowed and conflicts arise if sharing is attempted.
-->
<p>2 つのデバイスが同じ IRQ 番号を使っていると、割り込みを共有している
と言われます。条件によっては、この共有はうまく動作します。
バージョン 2.2 以降のカーネルは、場合によっては、シリアルポートと別の
シリアルポートで割り込みを共有できます。
PCI バス上のデバイスは、PCI バス上の他のデバイスと IRQ を共有できます。
これ以外で衝突の可能性がある場
合でも、同じ IRQ のデバイス 2 つを同時に「使う」ことがなければ、問題は
起きないはずです。
正確に書くと、「使う」とは(プログラマ言葉で)「オープンする」と
いう意味です。以上の例外を除くと、(割り込み共有を可能にする特殊なソフ
トウェアとハードウェアを使わない限り)共有は許されておらず、共有を行お
うとすると衝突が起こります。

<!--
Even if two processes with conflicting IRQs run at the same time, one
of the devices will likely have its interrupts caught by its device
driver and may work OK.  The other device will not have its interrupts
caught by the correct driver and will likely behave just like a
process with mis-set interrupts.  See <ref id="irq_ng" name="Mis-set
Interrupts"> for more details.
-->
IRQ が衝突している 2 つのプロセスが同時に実行された場合であっても、片
方のデバイスの割り込みがデバイスドライバに捕捉され、そちらだけはうまく
動作することもよくあります。他方のデバイスの割り込みは正しいドライバに
捕捉されないので、割り込みの設定ミスがある時のプロセスとちょうど同じよ
うに動作するでしょう。詳しくは <ref id="irq_ng" name="割り込みの設定ミス">
の章をご覧ください。

<!--
<sect1> Resolving Interrupt Problems
-->
<sect1> 割り込みの問題の解決
<!--
<p> If you are getting a very slow response as described above, then
one test is to change the IRQ to 0 (uses fast polling instead of
interrupts) and see if the problem goes away.  Note that the polling
due to IRQ=0 is orders of magnitude faster than the slow "polling" due
to bad interrupts.  If IRQ=0 seems to fix the problem, then there was
likely something wrong with the interrupts.  Using IRQ=0 is very
resource intensive and is only a temporary fix.  You should try to
find the cause of the interrupt problem and not permanently use IRQ=0.
-->
<p>上記のように応答が非常に遅い場合のテスト方法の一つは、IRQ を 0 に変
更して(割り込みの代わりに高速なポーリングを用いる)、これで問題が解決す
るかどうかを調べてください。IRQ=0 によるポーリングは、不正な割り込みに
よる「ポーリング」と比べて桁違いに高速です。IRQ=0 で問題が解決するよう
であれば、割り込みに何か問題があると考えられます。IRQ=0 はリソースを
大量に消費するので、一時的な修正のためだけに使ってください。割り込みの
問題の原因を見つけるべきであり、いつまでも IRQ=0 を使っていてはいけま
せん。

<!--O
Check /proc/interrupts to see if the IRQ is currently in use by another
process. If it's in use by another serial port you could try "top"
(type f and then enable the TTY display) or "ps -e" to find out which
serial ports are in use.  If you suspect that setserial has a wrong
IRQ then see <ref id="what_is_io_irq" name="What is the current IO
address and IRQ of my Serial Port ?">
-->
/proc/interrupts を調べて、他のプロセスが現在その IRQ を使っていないか
どうかを見てください。他のシリアルポートがその割り込みを使っているなら
ば、"top" (f を入力して TTY 表示を有効にしてください)か "ps -e" を使って
どのシリアルポートが使われているかを調べてください。setserial に間違っ
た IRQ が設定されている疑いがある場合には、
<ref id="what_is_io_irq" name="シリアルポートの現在の I/O アドレスと IRQ の設定は?">
の節を見てください。

<!--
<sect>What Are UARTs?  How Do They Affect Performance? <label id="uart_">
-->
<sect>UART とは何ですか?  性能にどのような影響を与えるのでしょうか? <label id="uart_">
<!-- uart.H begin
<sect>What Are UARTs?  How Do They Affect Performance? <label id="uart_"> -->

<!--
<sect1> Introduction to UARTS
-->
<sect1> UART 入門
<!--
<p> (This section is also in 
the Modem-HOWTO)
UARTs (<BF/U/niversal <BF/A/synchronous <BF/R/eceiver
<BF/T/ransmitter) are serial chips on your PC motherboard (or on an
internal modem card).   The UART function may also be done on a chip
that does other things as well.  On older computers like many 486's,
the chips were on the disk IO controller card.  Still older computer
have dedicated serial boards.
-->
<p>(この節は Modem-HOWTO にもあります。)
UART (<BF/U/niversal <BF/A/synchronous <BF/R/eceiver <BF/T/ransmitter) 
とは、PC のマザーボード(あるいは内蔵モデムカード)に載っているシリアル
用チップのことです。UART の機能は、他の用途のチップが兼用で実現してい
ることもあります。多くの 486 マシンのような古いコンピュータでは、この
チップはディスク I/O コントローラカードに載っていました。
さらに古いコンピュータの中には、まだ専用のシリアルボードを載せているも
のもあります。

<!--
The UART's purpose is to convert bytes from the PC's parallel bus to a
serial bit-stream.  The cable going out of the serial port is serial
and has only one wire for each direction of flow.  The serial port
sends out a stream of bits, one bit at a time.  Conversely, the bit
stream that enters the serial port via the external cable is converted
to parallel bytes that the computer can understand.  UARTs deal with
data in byte sized pieces, which is conveniently also the size of
ASCII characters. 
-->
UART の目的は、PC のパラレルバスからやってくるバイトデータをシリアルの
ビットストリームに変換することです。シリアルポートから出ているケーブル
はデータをシリアル(直列)に送るようになっており、データが流れる方向それぞれ
について 1 つしか線がありません。シリアルポートは一度に 1 ビットずつ
ビットストリームを送ります。逆に、外付けケーブルを経由してシリアルポート
に入ってきたビットストリームは、コンピュータが処理できるパラレルなバイト
データに変換されます。UART はデータをバイト単位で扱います。この単位は
都合がいいことに ASCII 文字の大きさでもあります。

<!--
Say you have a terminal hooked up to your PC.  When you type a
character, the terminal gives that character to its transmitter (also
a UART).  The transmitter sends that byte out onto the serial line,
one bit at a time, at a specific rate.  On the PC end, the receiving
UART takes all the bits and rebuilds the (parallel) byte and puts it
in a buffer.
-->
PC にぶら下がっている端末があるものとします。ユーザが文字を入力すると、
端末はその文字をトランスミッタに(UART にも)送ります。トランスミッタは
そのバイトデータをシリアル回線に送り、送信は 1 バイトずつ、特定の速度
で行われます。PC 側では、受信を行う UART がビット列を全て受け取り、(パ
ラレルの)バイトデータに復元し、これをバッファに入れます。

<!--
Along with converting between serial and parallel, the UART does some
other things as a byproduct (side effect) of its primary task.  The
voltage used to represent bits is also converted (changed).  Extra
bits (called start and stop bits) are added to each byte before it is
transmitted.  See the Serial-HOWTO section, ``Voltage Waveshapes'' for
details.  Also, while the flow rate (in bytes/sec) on the parallel bus
inside the computer is very high, the flow rate out the UART on the
serial port side of it is much lower.  The UART has a fixed set of
rates (speeds) which it can use at its serial port interface.  
-->
シリアルとパラレルの変換に加えて、UART は主な処理の副産物(副作用)とし
て他の処理もいくつか行います。ビット列を表すために使う電圧も変換(変更)
されます。バイトデータが送信される前にそれぞれのバイトに対して追加のビッ
ト(いわゆるスタートビットとストップビット)が加えられます。詳しくは 
Serial-HOWTO の<ref id="volt_shape" name="電圧の波形">の節を見てくださ
い。また、コンピュータ内部のパラレルバス上のフローレート(バイト/秒)は
非常に高いですが、シリアルポート側の UART から出るフローレートはこれよ
りもずっと低いです。UART はいくつかの決められたフローレート(速度)の組
を持っていて、これをシリアルポートインタフェースで使うことができます。

<!--
<sect1> Two Types of UARTs
-->
<sect1> 2 種類の UART
<!--
<p> There are two basic types of UARTs: dumb UARTS and FIFO UARTS.
Dumb UARTs are the 8250, 16450, early 16550, and early 16650.  They
are obsolete but if you understand how they work it's easy to
understand how the modern ones work with FIFO UARTS ( late 16550,
16550A, 16c552, late 16650, 16750, and 16C950).
-->
<p> UART の基本的な種類は 2 つ(ダム UART と FIFO UART)あります。ダム 
UART は 8250, 16450, 初期型 16550, 初期型 16650 です。これらは時代遅れ
のものですが、これらの動作の仕組みがわかれば、FIFO UART(最近の 16550,
16550A, 16c552, 最近の 16650, 16750, 16C950)の動作を理解するのも容易で
す。

<!--
There is some confusion regarding 16550.  Early models had a bug and
worked properly only as 16450's (no FIFO).  Later models with the bug
fixed were named 16550A but many manufacturers did not accept the name
change and continued calling it a 16550.  Most all 16550's in use
today are like 16550A's.  Linux will report it as being a 16550A even
though your hardware manual (or a label note) says it's a 16550.  A
similar situation exists for the 16650 (only it's worse since the
manufacturer allegedly didn't admit anything was wrong).  Linux will
report a late 16650 as being a 16650V2.  If it reports it as 16650 it
is bad news and only is used as if it had a one-byte buffer.
-->
16550 については紛らわしい点がいくつかあります。初期モデルにはバグがあ
り、(FIFO を持たない)16450 としてしか正しく動作しません。バグが修正さ
れた最近のモデルに
は 16550A という名前が付いていますが、多くのメーカーは名前を変更してお
らず、16550 と呼び続けています。現在使われている 16550 の大部分は
16550A のようです。ハードウェアの説明書に 16550 であると書かれてい
ても(あるいはラベルにそのように刻印されていても)、Linux は 16550A であ
ると認識してくれます。同様の事情が
16650 にもあります(こちらの方が深刻です。というのも、聞いた話ではメー
カーがバグを認めなかったからです)。Linux は最近の 16650 を 16650V2 と
して認識します。16650 と認識された場合には残念ながら、1 バイトのバッファ
しか持っていないように動作します。

<!--
<sect1> FIFOs <label id="fifo_">
-->
<sect1> FIFO <label id="fifo_">
<!--
<p> To understand the differences between dumb and FIFO (First In,
First Out queue discipline) first let's examine what happens when a
UART has sent or received a byte.  The UART itself can't do anything
with the data passing thru it, it just receives and sends it.  For the
original dumb UARTS, the CPU gets an interrupt from the serial device
every time a byte has been sent or received.  The CPU then moves the
received byte out of the UART's buffer and into memory somewhere, or
gives the UART another byte to send.  The 8250 and 16450 UARTs only
have a 1 byte buffer.  That means, that every time 1 byte is sent or
received, the CPU is interrupted.  At low transfer rates, this is OK.
But, at high transfer rates, the CPU gets so busy dealing with the
UART, that is doesn't have time to adequately tend to other tasks.  In
some cases, the CPU does not get around to servicing the interrupt in
time, and the byte is overwritten, because they are coming in so fast.
This is called an "overrun" or "overflow".
-->
<p> ダムと FIFO(キューの動作がファーストイン・ファーストアウト(First In, First
Out)である)の違いを説明するために、まずは UART が 1 バイトのデータを送
受信した場合のことを調べてみましょう。UART 本体は自分を通るデータに関
しては何も行わず、単にデータを送受信するだけです。元々のダム UART の場
合は、バイトデータが送受信される度に CPU がシリアルデバイスから割り込
みを受け取ります。CPU はこれを受けて、受信したバイトデータを UART のバッ
ファから取り出してメモリ上のどこかに置くか、送信すべき次のバイトデータ
を UART に渡すかのどちらか動作を行います。8250 と 16450 UART には 1 バ
イトしかバッファがありません。つまり、1 バイトのデータを送受信する度に 
CPU に割り込みがかかります。転送速度が低ければこれでも大丈夫です。しか
し転送速度が高速である場合には、UART の処理の負荷が CPU にかかりすぎる
ため、他の処理をうまく行えるだけの時間がなくなってしまいます。場合によっ
ては、CPU の割り込み処理が間に合わなくなってしまい、バイトデータが上書
きされてしまいます。なぜなら、データが入ってくるのが速過ぎるからです。
これは「オーバーラン(overrun)」あるいは「オーバーフロー(overflow)」と
呼ばれます。

<!--
That's where the FIFO UARTs are useful.  The 16550A (or 16550) FIFO
chip comes with 16 byte FIFO buffers.  This means that it can receive
up to 14 bytes (or send 16 bytes) before it has to interrupt the CPU.
Not only can it wait for more bytes, but the CPU then can transfer all
14 (or more) bytes at a time.  This is a significant advantage over
the other UARTs, which only have 1 byte buffers.  The CPU receives
less interrupts, and is free to do other things.  Data is not lost,
and everyone is happy.  Note that the interrupt threshold of FIFO
buffers (trigger level) may be set at less than 14.  1, 4 and 8 are
other possible choices.  
-->
これが FIFO UART が役立つ理由です。16550A(あるいは 16550)の FIFO チッ
プには 16 バイトの FIFO バッファが付いています。つまり、CPU に割り込み
がかかるまでに 14 バイトまでを受け取れます(16 バイトまでを送れます)。
たくさんのバイトデータを待てるだけではなく、CPU は 14 バイト全て(また
はそれ以上)のバイトデータを同時に転送できます。これは、バッファを 1 バ
イトしか持っていない他の UART に対して特に優れている点です。CPU が受け
る割り込みも少なく他の処理に回せますし、データがなくなることもなく皆幸
せになれます。FIFO バッファの割り込みの閾値(トリガレベル)には 14 以下
の値が設定できる点に注意してください。この他には 1, 4, 8 が選べます。

<!--
While most PC's only have a 16550 with 16-byte buffers, better UARTS
have even larger buffers.  Note that the interrupt is issued slightly
before the buffer get full (at say a "trigger level" of 14 bytes for a
16-byte buffer).  This allows room for a few more bytes to be received
during the time that the interrupt is being serviced.  The trigger
level may be set to various permitted values by kernel software.  A
trigger level of 1 will be almost like a dumb UART (except that it
still has room for 15 more bytes after it issues the interrupt).
-->
大抵の PC には 16 バイトのバッファを持つ 16550 しか付いていませんが、
高級な UART にはもっと大きなバッファがあります。割り込みはバッファがいっ
ぱいになる直前(例えば 16 バイトのバッファでは 14 バイトの
「トリガレベル」の時点)に発行される点に注意してください。
こうすることにより、割り込みサービスが実行される間にも何バイトかの
データを受け取れる余裕が残ります。
このトリガレベルには、カーネルのソフトウェアが許可した色々な値を
設定できます。トリガレベルを 1 にすると、ダム UART とほぼ同
じになります(ただし、割り込みを発行した後にもさらに 15 バイトを受け取
る空きが残っている点が異なります)。

<!--
If you type something while visiting a BBS, the characters you type go
out thru the serial port.  Your typed characters that you see on the
screen are what was echoed back thru the telephone line thru your modem
and then thru your serial port to the screen.  If you had a 16-byte
buffer on the serial port which held back characters until it had 14
of them, you would need to type many characters before you could see
what you typed (before they appeared on the screen).  This would be
very confusing but there is a "timeout" to prevent this.  Thus you
normally see a character on the screen just as soon as you type it.
-->
BBS に入っている時に何か文字を入力した場合、入力した文字はシリアルポー
ト経由で送り出されます。入力した文字が画面に表示されるのは、その文字が
電話回線・モデム・シリアルポート経由で画面にエコーバックされているから
です。もしシリアルポートに 16 バイトのバッファが付いていて、14 バイト
集まるまで文字を送ってくれないとしたら、文字をたくさん入力しなければ
入力した文字が目で確認できない(画面に表示されない)ことになります。
これではややこしくてたまらないのですが、そんな事態を防ぐために
「タイムアウト」があります。
だからこそ普通は入力した文字が即座に表示されるのです。

<!--
The "timeout" works like this for the receive UART buffer: If
characters arrive one after another, then an interrupt is issued only
when say the 14th character reaches the buffer.  But if a character
arrives and the next character doesn't arrive soon thereafter, then an
interrupt is issued.  This happens even though there are not 14
characters in the buffer (there may only be one character in it).
Thus when what you type goes thru this buffer, it acts almost like a
1-byte buffer even though it is actually a 16-byte buffer (unless
your typing speed is a hundred times faster than normal).  There
is also "timeout" for the transmit buffer as well.
-->
UART の受信バッファの場合、この「タイムアウト」は 以下のように動作しま
す: 文字が次々とやってくるなら、バッファに例えば 14 個目の文字がバッファ
に来たときにだけ割り込みが発行されます。
しかし、ある文字が届いた後にしばらく次の文字が届かなくてもやはり
割り込みが発行されます。この割り込みはたとえバッ
ファに 14 個文字が入っていなくても発行されます(1 文字でも入っていれば
発行されます)。したがって、このバッファを通して文字を入力すると、バッ
ファの大きさが実際には 16 バイトであっても(あなたが文字を打ち込む速さ
が普通の 100 倍でなければ) 1 バイトのバッファのように動作します。同様
の「タイムアウト」が送信バッファにもあります。

<!--
<sect1> UART Model Numbers
-->
<sect1> UART のモデル番号
<!--
<p> Here's a list of UARTs.  <em/TL/ is <em/T/rigger <em/L/evel
-->
<p> 以下に UART の一覧を示します。<em/TL/ はトリガレベル(<em/T/rigger <em/L/evel)
です。
<itemize>
<!--
<item> 8250, 16450, early 16550: Obsolete with 1-byte buffers
-->
<item> 8250, 16450, 初期の 16550: バッファの大きさが 1 バイトである時
代遅れの UART です
<!--
<item> 16550, 16550A, 16c552: 16-byte buffers, TL=1,4,8,14 
-->
<item> 16550, 16550A, 16c552: 16 バイトのバッファがあります
(TL=1,4,8,14)
<!--
<item> 16650:  32-byte buffers. Speed up to 460.8 kbps
-->
<item> 16650:  32 バイトのバッファがあります。460.8 kbps までの速度に
対応しています
<!--
<item> 16750:  64-byte buffer for send, 56-byte for receive.  Speed up
 to 921.6 Kbps
-->
<item> 16750:  64 バイトの送信バッファ、56 バイトの受信バッファがあり
ます。921.6 kbps までの速度に対応しています
<!--
<item> Hayes ESP: 1k-byte buffers. 
-->
<item> Hayes ESP: 1k バイトのバッファがあります
</itemize>

<!--
The obsolete ones are only good for modems no higher than 14.4k (DTE
speeds up to 38400 bps).  For modern modems you need at least a 16550
(and not an early 16550).  For V.90 56k modems, it may be a several
percent faster with a 16650 (especially if you are downloading
uncompressed files).  The main advantage of the 16650 is its larger
buffer size as the extra speed isn't needed unless the modem
compression ratio is high.  Some 56k internal modems may come with a
16650 ?? 
-->
時代遅れの UART がうまく動作するのは 14.4k より遅いモデム(DTE 速度は 
38400 bps まで)の場合だけです。最近のモデムでは、少なくとも 16550
(初期型 16550 は含みません)が必要です。V.90 規格の 56k モデムの場合に
は、16650 を使うと数パーセント速くなることがあります(特に圧縮されてい
ないファイルをダウンロードする時)。16650 を使う主な利点はバッファの
サイズが大きいことです。というのも、モデムの圧縮比が高くなければ特に
速度は必要ないからです。
一部の 56k 内蔵モデムには 16650 が載っています(筆者は確かめていません)。

<!--
Non-UART, and intelligent multiport boards use DSP chips to 
do additional buffering and control, thus relieving the CPU
even more.  For example, the Cyclades Cyclom, and Stallion
EasyIO boards use a Cirrus Logic CD1400 RISC UART, and many 
boards use 80186 CPUs or even special RISC CPUs, to handle the
serial IO.
-->
UART でなくインテリジェントなマルチポートボードでは、DSP チップを使っ
てさらなるバッファリングと制御を行っています。したがって、CPU の負荷は
さらに軽くなっています。例えば、Cyclades 製の Cyclom や Stallion 製の 
EasyIO ボードは Cirrus Logic CD1400 RISC UART を使って、これ以外の多く
のボードは 80186 CPU や特殊な RISC CPU さえ使ってシリアル I/O を処理し
ます。

<!--
Most newer PC's (486's, Pentiums, or better) come with 16550A's
(usually called just 16550's).  If you have something really old the
chip may unplug so that you may be able to upgrade by buying a 16550A
chip and replacing your existing 16450 UART.  If the functionality has
been put on another type of chip, you are out of luck.  If the UART is
socketed, then upgrading is easy (if you can find a replacement).  The
new and old are pin-to-pin compatible.  It may be more feasible to
just buy a new serial board on the Internet (few retail stores stock
them today).
-->
最近の PC のほとんど(486, Pentium 以降のマシン)には 16550A (普通は単に 
16550 と呼ばれます)が載っています。本当に古い PC をお使いにの場合は、
既存の 16450 チップを外して、新しく買った 16550A チップと置き換えるこ
とによりアップグレードできます。他のタイプのチップ
が載っていた場合は、残念ながらあきらめてください。UART がソケット形式
ならば、(置き換えるチップさえあれば)アップグレードは簡単でしょう。新し
いチップと古いチップのピン配置は互換です。新しいシリアルボードをインター
ネットで購入できるかもしれません(現在はシリアルボードを扱っ
ている小売店はほとんどありません)。
<!-- uart.H end -->


<!--
<sect> Pinout and Signals <label id="pinout_">
-->
<sect> ピン配置と信号 <label id="pinout_">
<!--
<sect1> Pinout
-->
<sect1> ピン配置
<p>
<!--
<verb>
	PINOUT of the SERIAL PORT    (&#045;&#045;> direction is out of PC)
		(Note DCD is sometimes labeled CD)
Pin #	Pin #	Acronym	 Full-Name   Direction	What-it-May-Do/Mean
9-pin	25-pin
 3	 2	TxD	Transmit Data	  &#045;&#045;>	Transmits byte out of PC
 2	 3	RxD	Receive Data	  <&#045;&#045;	Receives bytes into PC
 7	 4	RTS	Request To Send	  &#045;&#045;>	RTS/CTS flow control
 8	 5	CTS	Clear To Send	  <&#045;&#045;	RTS/CTS flow control
 6	 6	DSR	Data Set Ready	  <&#045;&#045;	I'm ready to communicate
 4	20	DTR	Data Terminal Ready&#045;&#045;>  I'm ready to communicate
 1	 8	DCD	Data Carrier Detect<&#045;&#045;	Modem connected to another
 9	22	RI	Ring Indicator	  <&#045;&#045;	Telephone line ringing
 5	 7		Signal Ground
</verb>
-->
<verb>
        シリアルポートのピン配置   (「→」 が PC から外部への方向です)
                (DCD は CD と記載されることもあります)
ピン番号 ピン番号 略称	 正式名称            方向	動作および目的
9ピン    25ピン
 3        2       TxD    Transmit Data        →       PC からバイトデータを送信する
 2        3       RxD    Receive Data         ←        PC がバイトデータを受け取る
 7        4       RTS    Request To Send      →       RTS/CTS フロー制御
 8        5       CTS    Clear To Send        ←        RTS/CTS フロー制御
 6        6       DSR    Data Set Ready       ←        通信可能になったことを知らせる
 4       20       DTR    Data Terminal Ready  →       通信可能になったことを知らせる
 1        8       DCD    Data Carrier Detect  ←        モデムが相手と繋がっていることを示す
 9       22       RI    Ring Indicator        ←        電話のベルが鳴っている状態を示す
 5        7             Signal Ground
</verb>

<!--
<sect1> Signals May Have No Fixed Meaning
-->
<sect1> 信号は決まった意味を持っていないことがあります
<!--
<p> Only 3 of the 9 pins have a fixed assignment: transmit, receive
and signal ground.  This is fixed by the hardware and you can't change
it.  But the other signal lines are controlled by software and may do
(and mean) almost anything at all.  However they can only be in one of
two states: asserted (+12 volts) or negated (-12 volts).  Asserted is
"on" and negated is "off".  For example, Linux software may command
that DTR be negated and the hardware only carries out this command and
puts -12 volts on the DTR pin.  A modem (or other device) that
receives this DTR signal may do various things.  If a modem has been
configured a certain way it will hang-up the telephone line when DTR
is negated.  In other cases it may ignore this signal or do something
else when DTR is negated (turned off).
-->
<p> 9 本のピンのうち、割り当てが固定されているのは 3 つだけです
(transmit(送信), receive(受信), signal ground(接地))。これはハードウェ
アに固定されており、変更することはできません。しかし他の信号線はソフト
ウェアで制御することができ、ほとんど何にでも使うことができます。しかし、
配線は 2 つの状態しか取れません。すなわち正(+12 V)と負(-12 V)
です。正は「オン」であり、負は「オフ」です。例えば、Linux 用のソフトウェ
アが DTR に負になるように命令を出すと、ハードウェアは単にこの命令を実
行し、DTR ピンの電圧を -12 V にします。DTR 信号を受け取るモデム(あ
るいは他のデバイス)は色々な動作をします。モデムの設定によっては、DTR 
が負の状態になると電話を切ります。DTR が負(オフ)になったときに無視した
り、他の動作をすることもあります。

<!--
It's like this for all the 6 signal lines.  The hardware only sends
and receives the signals, but what action (if any) they perform is up
to the Linux software and the configuration/design of devices that you
connect to the serial port.  However, most pins have certain functions
which they normally perform but this may vary with the operating
system and the device driver configuration.  Under Linux, one may
modify the source code to make these signal lines behave differently
(some people have).
-->
同じようなことが 6 本の線全てについて言えます。ハードウェアは信号を送
受信するだけですが、それによってどんな動作が行われるのかは、Linux のソ
フトウェアやシリアルポートに接続しているデバイスの設定/設計次第です。
また、ほとんどのピンには通常行われる特定の機能がありますが、これは OS 
やデバイスドライバの設定によって変わってきます。Linux の場合は、ソース
コードを変更すれば、これらの信号線の動作を変えることができます(そうし
ている人もいます)。

<!--
<sect1> Cabling Between Serial Ports <label id="cabling_">
-->
<sect1> シリアルポート間のケーブル接続 <label id="cabling_">
<!--
<p> A cable from a serial port always connects to another serial port.
A modem or other device that connects to the serial port has a serial
port built into it.  For modems, the cable is always straight thru:
pin 2 goes to pin 2, etc.  The modem is said to be DCE (Data
Communications Equipment) and the computer is said to be DTE (Data
Terminal Equipment).  Thus for connecting DTE-to-DCE you use
straight-thru cable.  For connecting DTE-to-DTE you must use a
null-modem cable and there are many ways to wire such cable (see
examples in Text-Terminal-HOWTO subsection: "Direct Cable Connection")
-->
<p>シリアルポートからのケーブルは、必ず別のシリアルポートに接続されま
す。モデム等の、シリアルポートに接続するデバイスには、内部にシリアルポート
が組み込まれています。モデムの場合、ケーブルは必ずストレートケーブル
(同じピン同士が接続される)です。モデムは DCE (Data Communications Equipment)
と言われ、コンピュータは DTE (Data Terminal Equipment)と言われます。こ
のように DTE と DCE を繋ぐ場合にはストレートケーブルが使われます。DTE 
同士を繋ぐにはクロスケーブルを使わなければなりません。このようなケーブル
の結線にはたくさんの種類があります(Text-Terminal-HOWTO の
"Direct Cable Connection" 節に書かれている例をご覧ください)。

<!--
There are good reasons why it works this way.  One reason is that the
signals are unidirectional.  If pin 2 sends a signal out of it (but is
unable to receive any signal) then obviously you can't connect it to
pin 2 of the same type of device.  If you did, they would both send
out signals on the same wire to each other but neither would be able
to receive any signal.  There are two ways to deal with this
situation.  One way is to have a two different types of equipment
where pin 2 of the first type sends the signal to pin 2 of the second
type (which receives the signal).  That's the way it's done when you
connect a PC (DTE) to a modem (DCE).  There's a second way to do this
without having two different types of equipment: Connect pin sending
pin 2 to a receiving pin 3 on same type of equipment.  That's the way
it's done when you connect 2 PC's together or a PC to a terminal
(DTE-to-DTE).  The cable used for this is called a null-modem cable.
The above example is for a 25 pin connector but for a 9-pin connector
the pin numbers are just the opposite.
-->
このように色々なケーブルを使うのには理由があります。その 1 つは、信号
が片方向性を持つからです。ピン 2 が信号を送る場合は、(ピン 2 は信号を
受け取ることはできないので)ピン 2 を同じ種類のデバイスのピン 2 に接続
できないのは明らかです。接続してしまうと、両方のピンが同じ線に互いに信
号を送るのに、どちらも信号を受け取れないという状態になってしまいます。
これを解決する方法は 2 つあります。1 つめの方法は、2 種類の異なる機器
を使う方法であり、最初の機器のピン 2 が 2 番目の機器のピン 2 (これは信
号を受信できます)に信号を送るというものです。これは PC(DTE)をモデム
(DCE)に繋ぐ時の方法です。2 つめの方法は、異なる種類の機器を使わずに接
続を行う方法です。すなわち送信ピン 2 を同じ種類の機器のピン 3(受
信ピン)に繋ぎます。これは 2 台の PC を接続する時や、PC を端末に
繋ぐ時の方法です(DTE 同士の接続)。この目的で使われるケーブルは
クロスケーブルと呼ばれます。
この例は 25 ピンコネクタの場合ですが、9 ピンコネクタの場合は
ピンの番号はちょうど逆になります。

<!--
The serial pin designations were originally intended for connecting a
dumb terminal to a modem.  The terminal was DTE (Data Terminal
Equipment) and the modem was DCE (Data Communication Equipment).
Today the PC is usually used as DTE instead of a terminal (but real
terminals may still be used this way).  The names of the pins are the
same on both DTE and DCE.  The words: "receive" and "transmit" are in
this case from the point of view of the PC (DTE).  The transmit pin
from the PC transmits to the "transmit" pin of the modem (but actually
the modem is receiving the data from this pin so from the point of view
of the modem it would be a receive pin).
-->
シリアルのピン指定は元々、ダム端末をモデムに接続するためのものでした。
端末は DTE (Data Terminal Equipment)で、モデムは DCE
(Data Communication Equipment)でした。現在は普通は端末ではなく PC が
DTE として使われます(ただし本物の端末もまだ DTE として使われています)。
ピンの名前は DTE でも DCE でも同じです。この場合には「受信(receive)」
「送信(transmit)」という言葉は PC (DTE) から見た立場で示されます。PC 
の送信ピンからはモデムの「送信」ピンにデータが送られます(しかし実際に
は、モデムはこのピンからデータを受け取るので、モデムの立場から見るとこ
れは受信ピンと言えます)。

<!--
The serial port was originally intended to be used for connecting DTE
to DCE which makes cabling simple: just use a straight-thru cable.
Thus when one connects a modem one seldom needs to worry about which
pin is which.  But people wanted to connect DTE to DTE (for example a
computer to a terminal) and various ways were found to do this by
fabricating various type of special cables.  In this case what pin
connects to what pin becomes more important.
-->
シリアルポートは元々、DTE を DCE に接続するためのものであり、その場合
にはケーブルの結線は単純です。単にストレートケーブルを使ってください。
したがってモデムを使う場合には、ピンの配置を気にする必要はほとんどあり
ません。
しかし、DTE を DTE に(例えばコンピュータを端末に)繋ぎたいという人々が
いて、色々な特殊ケーブルが開発され、さまざまな接続方法が考案されました。
この場合には、ピンの繋げ方は重要です。

<!--
<sect1> RTS/CTS and DTR/DSR Flow Control <label id="rts_cts">
-->
<sect1> RTS/CTS と DTR/DSR のフロー制御 <label id="rts_cts">
<!--
<p> This is "hardware" flow control.  Flow control was previously
explained in the <ref id="flow_control" name="Flow Control">
subsection but the pins and voltage signals were not.  Linux only
supports RTS/CTS flow control at present (but a special driver may
exist for a specific application which supports DTR/DSR flow control).
Only RTS/CTS flow control will be discussed since DTR/DSR flow control
works the same way.  To get RTS/CTS flow control one needs to either
select hardware flow control in an application program or use the
command:<newline> 
stty crtscts &lt /dev/ttyS2 (or the like).  This enables RTS/CTS
hardware flow control in the Linux device driver.
-->
<p>これは「ハードウェア」のフロー制御です。フロー制御は既に
<ref id="flow_control" name="フロー制御">の節で説明していますが、ピン
と電圧に関する説明はしていません。Linux は現時点では RTS/CTS によるフ
ロー制御しかサポートしていません(特定のアプリケーション用の特殊ドライ
バでは DTR/DSR フロー制御をサポートしているものもあります)。ここでは 
RTS/CTS フロー制御しか説明しません。なぜなら DTR/DSR フロー制御の動作
も同様だからです。RTS/CTS フロー制御を行うには、アプリケーションプログ
ラムでハードウェアフロー制御を選択するか、あるいは
「stty crtscts &lt; /dev/ttyS2」というコマンド(あるいは同様のコマンド)
を使う必要があります。これにより、Linux のデバイスドライバにおける、ハー
ドウェアによる RTS/CTS フロー制御が有効になります。

<!--
Then when a DTE (such as a PC) wants to stop the flow into it, it
negates RTS.  Negated "Request To Send" (-12 volts) means "Request NOT
To Send to me" (stop sending).  When the PC is ready for more bytes
it asserts RTS (+12 volts) and the flow of bytes to it resumes.  Flow
control signals are always sent in a direction opposite to the flow of
bytes that is being controlled.  DCE equipment (modems) works the same
way but sends the stop signal out the CTS pin.  Thus it's RTS/CTS flow
control using 2 lines.
-->
それから DTE (PC 等)が入ってくるデータを止めたい時には、RTS をオフにし
ます。RTS(「Request To Send」)をオフ(-12 V)にするのは「データをこ
ちらに送らないでくれという要求(Request NOT To Send to me)」(送信停止)
という意味です。PC が次のバイトデータを受け取る準備ができた時は、RTS 
をオン(+12 V)にすると、バイトデータが再び流れてくるようになります。
フロー制御信号が流れる向きは常に一方向であり、制御されているバイトデー
タの流れの逆向きです。DCE 機器(モデム)も同様に動作しますが、停止信号を 
CTS ピンから送ります。このように、RTS/CTS フロー制御では線を 2 本を使
います。

<!--
On what pins is this stop signal received?  That depends on whether we
have a DCE-DTE connection or a DTE-DTE connection.  For DCE-DTE it's a
straight-thru connection so obviously the signal is received on a pin
with the same name as the pin it's sent out from.  It's RTS&#045;&#045;>RTS (PC
to modem) and CTS<&#045;&#045;CTS (modem to PC).  For DTE-to-DTE the connection
is also easy to figure out.  The RTS pin always sends and the CTS pin
always receives.  Assume that we connect two PCs (PC1 and PC2)
together via their serial ports.  Then it's RTS(PC1)&#045;&#045;>CTS(PC2) and
CTS(PC1)<&#045;&#045;RTS(PC2).  In other words RTS and CTS cross over.  Such a
cable (with other signals crossed over as well) is called a "null
modem" cable.  See <ref id="cabling_" name="Cabling Between Serial
Ports">
-->
この停止信号はどのピンで受信されるのでしょうか? それは DCE-DTE 接続と 
DTE-DTE 接続で異なります。DCE-DTE 接続の場合には、ストレートケーブルが
使われるので、信号が受信されるのは当然ながら信号が送られたピンと同じ名前
のピンです。この場合は RTS→RTS (PC からモデムの向き)および 
CTS←CTS(モデムから PC の向き)となります。DTE 同士の接続の場合も説明
は簡単です。常に RTS ピンが送信を行い、CTS ピンが受信を行います。
2 台の PC (PC1 と PC2)がシリアルポート経由で接続される場合を考えてみま
しょう。この場合は RTS(PC1)→CTS(PC2) および CTS(PC1)←RTS(PC2) とな
ります。言い換えれば、RTS と CTS が交差しています。このようなケーブル
は(他の信号も交差しています)、「クロス」ケーブルと呼ばれます。詳しくは 
<ref id="cabling_" name="シリアルポート間のケーブル接続">の節をご覧く
ださい。

<!--
What is sometimes confusing is that there is the original use of RTS
where it means about the opposite of the previous explanation above.
This original meaning is: I Request To Send to you.  This request was
intended to be sent from a terminal (or computer) to a modem which, if
it decided to grant the request, would send back an asserted CTS from
its CTS pin to the CTS pin of the computer: You are Cleared To Send to
me.  Note that in contrast to the modern RTS/CTS bi-directional flow
control, this only protects the flow in one direction: from the
computer (or terminal) to the modem.  This original use appears to be
little used today on modern equipment (including modems).
-->
元々の RTS の使い方は先程の説明と反対なので、時々紛らわしくなります。この元々
の使い方とは「データをそちらに送るという要求(I Request To Send to you)」
です。この要求は端末(またはコンピュータ)からモデムに送ることを想定した
もので、この要求が受け入れられると、モデムの CTS ピンからコンピュータ
の CTS ピンへ CTS 信号が送り返されます(CTS は「データをこちらに送って
もよい(You are Cleared To Send to me)」という意味です)。最近の RTS/CTS 
双方向フロー制御と異なり、これは片方向のフロー(コンピュータ(または端末)
からモデムの方向)しか保護しません。この元々の使用法は、(モデムを含めた)
現在の機器ではほとんど使われていないようです。

<!--
<sect2> The DTR and DSR Pins
-->
<sect2> DTR と DSR のピン
<!--
<p> Just like RTS and CTS, these pins are paired.  For DTE-to-DTE
connections they are likely to cross over.  There are two ways to use
these pins.  One way is to use them as a substitute for RTS/CTS flow
control.  The DTR pin is just like the RTS pin while the DSR pin
behaves like the CTS pin.  Although Linux doesn't support DTR/DSR flow
control, it can be obtained by connecting the RTS/CTS pins at the PC
to the DSR/DTR pins at the device that uses DTR/DSR flow control.  DTR
flow control is the same as DTR/DSR flow control but it's only one-way
and the DSR pin is not used.  Many text terminals and some printers
use this type of flow control.
-->
<p>RTS と CTS の組合せと同様に、これらのピンも対になっています。DTE 同
士の接続の場合、これらは交差しているでしょう。
これらのピンの使用法は 2 通りあり
ます。1 つは RTS/CTS フロー制御の代わりとして使う方法です。DTR ピンは 
RTS ピンと同様に使えますし、DSR ピンは CTS ピンのように動作します。
Linux は DTR/DSR フロー制御はサポートしていませんが、PC の RTS/CTS ピ
ンを DTR/DSR フロー制御を使うデバイスの DSR/DTR ピンに接続することによ
り、このようなフロー制御を行うことができます。DTR フロー制御は DTR/DSR 
フロー制御とほぼ同じですが、片方向通信であり、DSR ピンが使われない点が
異なります。多くのテキスト端末や一部のプリンタではこの種のフロー制御が
使われています。

<!--
The normal use of DTR and DSR is as follows: A device asserting DTR
says that its powered on and ready to operate.  For a modem, the
meaning of a DTR signal from the PC depends on how the modem is
configured.  To send a DTR signal manually from a PC using the stty
command set the baud rate to 0.  Negating DTR is sometimes called
"hanging up" but it doesn't always do this.  
-->
DTR, DSR の通常の使用法を以下に示します。DTR がオンになっているデバイ
スは、電源が入っており動作準備ができていることを示します。モデムの場合
は、PC がモデムに送る DTR 信号の意味はモデムの設定によって変わってきま
す。DTR 信号を PC から stty コマンドを使って手動で送るには、ボーレート
を 0 に設定してください。DTR をオフにすることは「ハングアップ」と呼ば
れることもありますが、常にそれが行われるわけではありません。

<!--
<sect1> Preventing a Port From Opening
-->
<sect1> ポートのオープンを禁止する方法
<!--
<p> If "stty -clocal" (or getty is used with the "local" flag negated)
then a serial port can't open until DCD gets an assert (+12 volts)
signal.
-->
<p>"stty -clocal" を実行する(あるいは "local" フラグを無効にして getty 
を用いる)と、DCD がオン(+12 V)になるまではシリアルポートを
オープンできません。

<!--
<sect> Voltage Waveshapes <label id="volt_shape">
-->
<sect> 電圧の波形 <label id="volt_shape">

<!--
<sect1> Voltage for a Bit
-->
<sect1> ビット 1 つを表す電圧
<!--
<p> At the EIA-232 serial port, voltages are bipolar (positive or
negative with respect to ground) and should be about 12 volts in
magnitude (some are 5 or 10 volts).   For the transmit and receive
pins +12 volts is a 0-bit (sometimes called "space") and -12 volts is
a 1-bit (sometimes called "mark").  This is known as inverted logic
since normally a 0-bit is both false and negative while a one is
normally both true and positive.  Although the receive and transmit
pins are inverted logic, other pins (modem control lines) are normal
logic with a positive voltage being true (or "on" or "asserted") and a
negative voltage being false (or "off" or "negated").  Zero voltage
has no meaning (except it usually means that the unit is powered off).
-->
<p>EIA-232 準拠のシリアルポートでは、電圧は二極式(接地電圧に対して正ま
たは負)であり、その大きさは約 12 V です(5 または 10 V のものもあ
ります)。送信ピンと受信ピンでは +12 V が 0 を表すビット(「space」
と呼ばれることもあります)で、-12 V が 1 を表すビットです(「mark」
と呼ばれることもあります)。これは反転論理として知られています。という
のも、普通は 0 を表すビットは偽かつ負であり、1 は真と正を表すからです。
送信ピンと受信ピンは反転論理ですが、他のピン(モデム制御線)
は通常の論理を用いており、正の電圧が真(または「オン」)であり、負の電圧
が偽(または「オフ」)を表します。電圧 0 は意味を持ちません(その機器の電
源が切れているという意味だけは持ちます)。

<!--
A range of voltages is allowed.  The specs say the magnitude of a
transmitted signal should be between 5 and 15 volts but must never
exceed 25 V.  Any voltage received under 3 V is undefined (but some
devices will accept a lower voltage as valid).  One sometimes sees
erroneous claims that the voltage is commonly 5 volts (or even 3
volts) but it's usually 11-12 volts.  If you are using a EIA-422 port
on a Mac computer as an EIA-232 (requires a special cable) or EIA-423
then the voltage will actually be only 5 V.  The discussion here
assumes 12 V.
-->
電圧に範囲を持たせることもできます。仕様においては、送信される信号の強
さは 5 V と 15 V の間でなければならず、25 V を超えてはなり
ません。3 V 未満の電圧は未定義です(ただしデバイスによっては電圧が
低くても有効であるとして受け付けます)。
電圧はたいてい 11-12 V なのですが、「一般的に 5 V (あるいは 3 V)
である」とする誤りをときどき見かけます。
ただし Macintosh の EIA-422 ポートを EIA-232 (特殊なケーブルが必要)や 
EIA-423 としてお使いならば、電圧はまさしくわずか 5 V のはずです。
ここでの説明では 12 V を使うものとします。

<!--
Note that normal computer logic normally is just a few volts (5 volts
was once the standard) so that if you try to use test equipment
designed for testing 3-5 volt computer logic (TTL) on the 12 volts of a
serial port, it may damage the test equipment.
-->
通常のコンピュータの論理回路は数 V (かつては 5 V が標準だったこ
ともありますが)しか使わないので、3-5 V のコンピュータ回路(TTL)の試
験用に設計されたテスト機器を 12 V のシリアルポートに対して用いると、
テスト機器が壊れてしまうことがあります。

<!--
<sect1> Voltage Sequence for a Byte <label id="byte_seq">
-->
<sect1> バイトデータを表す電圧シーケンス <label id="byte_seq">
<!--
<p> The transmit pin (TxD) is held at -12 V (mark) at idle when nothing
is being sent.  To start a byte it jumps to +12 V (space) for the
start bit and remains at +12 V for the duration (period) of the start
bit.  Next comes the low-order bit of the data byte.  If it's a 0-bit
nothing changes and the line remains at +12 V for another bit-period.
If it's a 1-bit the voltage jumps from +12 to -12 V.  After that comes
the next bit (-12 V if a 1 or +12 V if a 0), etc., etc.  After the
last data bit a parity bit may be sent and then a -12 V (mark) stop
bit.  Then the line remains at -12 V (idle) until the next start bit.
Note that there is no return to 0 volts and thus there is no simple
way (except by a synchronizing signal) to tell where one bit ends and
the next one begins for the case where 2 consecutive bits are the same
polarity (both zero or both one).
-->
<p>送信ピン(TxD)は、何も送っていないアイドル状態の時には -12 V (mark 
状態)を保持しています。バイトデータを送る際には、送信ピンはスタートビッ
トを送るために +12 V (space 状態)となり、スタートビットを送る間(区間)
は +12 V を保ちます。次にバイトデータの下位ビットが送られます。0 を表
すビットの場合は、何も変化せず、このバイト区間の間は送信ピンは +12 V 
のままです。1 を表すビットの場合は、電圧は +12 V から -12 V に変わりま
す。次のビット以降も同様に送られます(1 ならば -12 V, 0 ならば +12 V)。
最後のデータビットの後にはパリティビットや、その後の -12 V (mark 状態)
のストップビットが送られることもあります。その後は、次のスタートビット
までは送信ピンは -12 V(アイドル状態)のままです。
0 V が返ってくることがないことと、そのため同じ極性を持つビットが 
2 つ続く場合(0 が続く、あるいは 1 が続く場合)には、あるビットが終わっ
て次のビットが始まることを表す簡単な方法が(同期信号以外には)ない点に注
意してください。

<!--
A 2nd stop bit would also be -12 V, just the same as the first stop
bit.  Since there is no signal to mark the boundaries between these
bits, the only effect of the 2nd stop bit is that the line must remain
at -12 V idle twice as long.  The receiver has no way of detecting the
difference between a 2nd stop bit and a longer idle time between
bytes.  Thus communications works OK if one end uses one stop bit and
the other end uses 2 stop bits, but using only one stop bit is
obviously faster.  In rare cases 1 1/2 stop bits are used.  This means
that the line is kept at -12 V for 1 1/2 time periods (like a stop bit
50% wider than normal).
-->
2 番目のストップビットも -12 V になります。これは最初のストップビット
と同じです。これらのビット間の境界を示す信号が無いため、2 番目の
ストップビットの影響は、送信ピンが続けている -12 V のアイドル状態の長
さが 2 倍になる以外にはありません。2 番目のストップビットとバイト間の
長いアイドル時間の区別を付ける方法は、受信側にはありません。
したがって、うまく通信できるのは、通信の片側がストップビットを 1 つ用
い、その反対側がストップビットを 2 つ用いた場合です。ただし、1 つしか
ストップビットを用いない方が明らかに高速です。稀ですが、1 1/2 個の
ストップビットが使われることがあります。これは送信ピンが 1 1/2 区間の
間 -12 V を保つという意味です(ストップビットの長さが通常の 5 割増しに
なったようになります)。

<!--
<sect1> Parity Explained <label id="parity_def">
-->
<sect1> パリティ検査 <label id="parity_def">
<!--
<p> Characters are normally transmitted with either 7 or 8 bits of
data.  An additional parity bit may (or may not) be appended to this
resulting in a byte length of 7, 8 or 9 bits.  Some terminal emulators
and older terminals do not allow 9 bits.  Some prohibit 9 bits if 2
stop bits are used (since this would make the total number of bits too
large: 12 bits total after adding the start bit).
-->
<p>文字は普通、7 ビットまたは 8 ビットのデータで送信されます。これに
パリティビットを追加すると(追加しないこともあります) 1 バイトの長さは 
7, 8, 9 ビットのいずれかとなります。一部の端末エミュレータや古い端末で
は、9 ビットは使えません。ストップビットを 2 つ使うと 9 ビットが使えな
くなる端末もあります(というのも、スタートビットを追加した後の合計のビッ
ト数が 12 ビットと多くなりすぎるからです)。

<!--
The parity may be set to odd, even or none (mark and space parity may
be options on some terminals or other serial devices).  With odd
parity, the parity bit is selected so that the number of 1-bits in a
byte, including the parity bit, is odd.  If a such a byte gets
corrupted by a bit being flipped, the result is an illegal byte of
even parity.  This error will be detected and if it's an incoming byte
to the terminal an error-character symbol will appear on the screen.
Even parity works in a similar manner with all legal bytes (including
the parity bit) having an even number of 1-bits.  During set-up, the
number of bits per character usually means only the number of data
bits per byte (7 for true ASCII and 8 for various ISO character sets).
-->
パリティには「奇数(odd)」、「偶数(even)」、「なし(none)」のいずれかを
設定します(一部の端末やシリアルデバイスでは、mark パリティや space パリティがオプション
として使えます)。奇数パリティを使うと、バイトデータ中で値が 1 になって
いるビットの数が(パリティビットも含めて)奇数となるようにパリティビット
が決められます。ビットがひっくり返って、このようなバイトデータが壊れた
場合、得られるデータは不正な偶数パリティのデータとなります。このエラー
は検出されるので、これが端末が受け取ったバイトデータであった場合には、
文字化けを表す記号を画面に表示できます。偶数パリティの動作も同様であり、
有効なバイトデータ中の 1 であるビット数が(パリティビットも含めて)偶数
となるようにします。設定時には通常、文字当たりのビット数はバイト当たり
のデータビットの数だけを意味します(正式な ASCII の場合には 7 ですし、
各種 ISO 文字集合の場合には 8 です)。

<!--
A "mark" is a 1-bit (or logic 1) and a "space" is a 0-bit (or logic
0).  For mark parity, the parity bit is always a one-bit.  For space
parity it's always a zero-bit.  Mark or space parity (also known as
"sticky parity") only wastes bandwidth and should be avoided if
feasible.  The <tt/stty/ command can't set sticky parity but it's
supported by serial hardware and can be dealt with by programming in
C.  "No parity" means that no parity bit is added.   For terminals
that don't permit 9 bit bytes, "no parity" must be selected when using
8 bit character sets since there is no room for a parity bit.
-->
"mark" は値が 1 であるビット(つまり論理値の 1)であり、"space" は値が 0 
であるビット(つまり論理値の 0)です。mark パリティの場合には、パリティ
ビットは常に値が 1 であるビットです。space パリティの場合には、これは
常に値が 0 であるビットです。mark パリティや space パリティ
(「sticky パリティ」とも呼ばれます)
は単にバンド幅を無駄にするだけなので、できる限り使わないようにすべきです。
<tt/stty/ コマンドは sticky パリティを設定できませんが、
シリアルポートのハードウェアはこのパリティに対応しており、C 言語の
プログラムで扱うことができます。
「パリティ無し」は、パリティビットを追加しないという意味です。9 ビットからな
るバイトデータを受け付けない端末を使う場合、8 ビット文字集合を使うなら
ば「パリティ無し」を選択しなければなりません。これはパリティビットを入
れる空きが無いからです。

<!--
<sect1> Forming a Byte (Framing)
-->
<sect1> バイトデータの構成 (フレーム分割)
<!--
<p> In serial transmission of bytes via EIA-232 ports, the low-order
bit is always sent first.  Serial ports on PC's use asynchronous
communication where there is a start bit and a stop bit to mark the
beginning and end of a byte.  This is called framing and the framed
byte is sometimes called a frame.  As a result a total of 9, 10, or 11
bits are sent per byte with 10 being the most common.   8-N-1 means 8
data bits, No parity, 1 stop bit.  This adds up to 10 bits total when
one counts the start bit.  One stop bit is almost universally used.
At 110 bits/sec (and sometimes at 300 bits/sec) 2 stop bits were once
used but today the 2nd stop bit is used only in very unusual
situations (or by mistake since it still works OK that way but wastes
bandwidth).
-->
<p>EIA-232 ポートを使ったバイトデータのシリアル伝送では、常に低位のビットか
ら先に送られます。PC のシリアルポートは非同期通信を行います。この非同
期通信では、スタートビットとストップビットがバイトデータの始めと終わりを示
します。このような区切り方はフレーム分割と呼ばれ、フレーム分割されたバ
イトデータはフレームと呼ばれることがあります。結果として、1 バイトごと
に 9 個 あるいは 10, 11 個のビットデータが送られます。この中で最も一般
的なのは 10 個です。8-N-1 とは、データビット 8 個、パリティ無し、ストップ
ビット 1 個という意味です。スタートビットを数に入れると合計 10 ビットに
なります。ストップビット 1 つはほぼ例外なく使われます。
110 ビット/秒(300 ビット/秒の時もあります)では、ストップビットが 2 つ使わ
れていたこともありましたが、現在は 2 つめのストップビットが使われるのは
ごく例外の時(あるいは、その設定でもうまく動作するために間違って使われ
ているけれど、バンド幅を無駄に消費している)だけです。

<!--
<sect1> How "Asynchronous" is Synchronized
-->
<sect1> 「非同期」通信で同期を行う方法

<!--
<p> The EIA-232 serial port as implemented on PC is asynchronous which
in effect means that there is no "clock" signal sent with "ticks" to
mark when each bit is sent..  There are only two states of the
transmit (or receive) wire: mark (-12 V) or space (+12 V).  There is
no state of 0 V.  Thus a sequence of 1-bits is transmitted by just a
steady -12 V with no markers of any kind between bits.  For the
receiver to detect individual bits it must always have a clock signal
which is in synchronization with the transmitter clock.  Such a clock
would generate a "tick" in synchronization with each transmitted (or
received) bit.
-->
<p>PC が装備している EIA-232 のシリアルポートは非同期です。
つまり実際には、それぞれのビットを送る時に「時間を刻む」ための「クロッ
ク」信号が送られないということです。送信(受信)用の線には 2 つしか状態
がありません。すなわち mark 状態(-12 V) と space 状態(+12 V)です。0 V 
の状態はありません。したがって 1 ビットのシーケンスは、ビットとビット
の間を示すマーカーが無い定常的な -12 V だけを使って送られます。受信側
で個々のビットを区別するためには、送信側のクロックと同期しているクロッ
ク信号が必ず必要です。このようなクロックは送信(受信)される各ビットと同
期している「時間の刻み」を生成します。

<!--
For asynchronous transmission, synchronization is achieved by framing
each byte with a start bit and a stop bit (done by hardware).  The
receiver listens on the negative line for a positive start bit and
when it detects one it starts its clock ticking.  It uses this clock
tick to time the reading of the next 7, 8 or 9 bits.  (It actually is
a little more complex than this since several samples of a bit are
normally taken and this requires additional timing ticks.)  Then the
stop bit is read, the clock stops and the receiver waits for the next
start bit.  Thus async is actually synchronized during the reception
of a single byte but there is no synchronization between one byte and
the next byte.
-->
非同期の伝送においては、スタートビットとストップビットを使って各バイトを
フレーム分割することによって同期を実現します(これはハードウェアが行い
ます)。受信側は負の電圧の配線上で正のスタートビットを待ち、このビットを検
出するとクロックを刻み始めます。受信側はこのクロック刻みを使って、次の
7, 8, 9 個のビットを読み込む時間を計ります(実際にはこれよりももう少し
複雑です。というのも、普通は 1 ビットからサンプル点をいくつか取るので、
そのために別のタイミング刻みが必要になるからです)。そしてストップビット
が読み込まれると、受信側はクロックを止めて、次のスタートビットを待ちま
す。このように、単独のバイトデータを受け取る際には非同期伝送も実際には
同期伝送になりますが、複数のバイトデータの間での同期は行われません。

<!--
<sect> Other Serial Devices (not async EIA-232) <label id="non_rs232">
-->
<sect> その他のシリアルデバイス (非同期 EIA-232 以外のもの) <label id="non_rs232">

<!--
<sect1> Successors to EIA-232 <label id="non_232">
-->
<sect1> EIA-232 の後継 <label id="non_232">
<!--
<p> A number of EIA standards have been established for higher speeds
and longer distances using twisted-pair (balanced) technology.
Balanced transmission can sometimes be a hundred times faster than
unbalanced EIA-232.  For a given speed, the distance (maximum cable
length) may be many times longer with twisted pair.  But PC-s keep
being made with the "obsolete" EIA-232 since it works OK with modems
and mice since the cable length is short.  If this appears in the
latest version of this HOWTO, please let me know if any of the
non-EIA-232 listed below are supported by Linux.
-->
<p>ツイストペア(平衡型伝送)技術を用いて高速・長距離を実現するために、
たくさんの EIA 規格が今までに作られました。平衡型の伝送は、場合によっ
ては 非平衡型の EIA-232 よりも百倍も速いことがあります。ある速度の場合、
距離(最大ケーブル長)はツイストペアを使った方が何倍も長くできます。です
が PC では「時代遅れな」EIA-232 が使われ続けています。というのも、
モデムやマウスはケーブルが短いため、これで十分だからです。この HOWTO 
文書が最新版であり、かつ以下に示す非 EIA-232 を Linux がサポートしてい
れば、筆者にお知らせください。

<!--
<sect1> EIA-422-A (balanced) and EIA-423-A (unbalanced)
-->
<sect1> EIA-422-A (平衡型) と EIA-423-A (非平衡型)
<!--
<p> EIA-423 is just like the unbalanced EIA-232 except that the
voltage is only 5 volts.  Since this falls within EIA-232 specs it
can be connected to a EIA-232 port.  Its specs call for somewhat
higher speeds than the EIA-232 (but this may be of little help on a
long run where it's the unbalance that causes interference).
-->
<p>EIA-423 は非平衡型の EIA-232 とほとんど同じですが、電圧が 5 V 
しかない点が異なります。これは EIA-232 規格に含まれるので、EIA-423 は 
EIA-232 ポートに接続することができます。この仕様は EIA-232 より多少
速い速度を求めています(ですが長時間動作すると非平衡伝送が衝突を起こす
ので、これはほとんど役に立ちません)。

<!--
Apple's Mac computer prior to mid-1998 with its EIA-232/EIA-422 Port
provided twisted-pairs (balanced) for transmit and receive (when used
as a 422).  It is (per specs) exactly 100 times as fast as EIA-423
(which in turn is somewhat faster than EIA-232)  The Mac used a small
round "mini-DIN-8" connector.  It also provided conventional EIA-232
but at only at 5 volts (which is still legal EIA-232).  To make it
work like at EIA-232 one must use a special cable which (signal)
grounds RxD+ (one side of a balanced pair) and use RxD- as the receive
pin.  While TxD- is used as the transmit pin, for some reason TxD+
should not be grounded.  See <url
url="http://www.modemshop.com/csm-comm-faq.html" name="Macintosh
Communications FAQ">.  However, due to the fact that Macs (and
upgrades for them) cost more than PC's, they are not widely as host
computers for Linux.
-->
Apple の Macintosh のうち、1998 年の中頃より古いものには 
EIA-232/EIA-422 ポートが付いており、ツイストペア(平衡型)を送受信(422 
として使った時)に使うことができました。これは(仕様上は) EIA-423(これ自
体は EIA-232 より多少高速です) のちょうど 100 倍高速です。 Macintosh 
は小さくて丸い "ミニ DIN-8" コネクタを使っていました。従来の EIA-232 
ポートも付いていましたが、これは 5 V でしか使えませんでした(それで
も正当な EIA-232 です)。これを EIA-232 と同じように使うには、
RxD+ (平衡ペアの片方の端)を接地した特殊なケーブルを使い、
RxD- を受信ピンとして使わなければなりません。
TxD- は送信ピンとして使われますが、いくつかの理由によって TxD+ は接地
してはなりません。<url
url="http://www.modemshop.com/csm-comm-faq.html" name="Macintosh
Communications FAQ"> も参照してください。しかし、Macintosh (およびこれ
を改良したもの)は PC よりも値段が高いため、Linux 用のホストコンピュー
タとしてはあまり使われていません。

<sect1> EIA-485
<!--
<p> This is like EIA-422 (balanced).  It is half-duplex.  It's not
just point-to-point but may be used for a multidrop LAN (up to 32
nodes).  There are no connector specs.
-->
<p> これは EIA-422 (平衡型) に似ています。半二重です。これは 
point-to-point 接続だけでなく、マルチドロップ LAN (32 ノードまで)にも
使うことができます。コネクタの仕様は存在しません。

<sect1> EIA-530
<!--
<p> EIA-530-A (balanced but can also be used unbalanced) at 2Mbits/s
(balanced) was intended to be a replacement for EIA-232 but few have
been installed.  It uses the same 25-pin connector as EIA-232.  
-->
<p> 2M ビット/秒(平衡型) の EIA-530-A (平衡型ですが、非平衡型として使
うこともできます)は EIA-232 を置き換えるためのものでしたが、ほとんど使
われませんでした。EIA-232 と同じ 25 ピンコネクタを使います。

<sect1> EIA-612/613
<!--
<p> The High Speed Serial Interface ( HSSI = EIA-612/613) uses a
50-pin connector and goes up to about 50 Mbits/s but the distance is
limited to only several meters.  For Linux there are PCI cards
supporting HSSI.  The companies that sell the cards often provide (or
point you to) a Linux driver.  A mini-howto or the like is needed for
this topic.
-->
<p>高速シリアルインタフェース
(High Speed Serial Interface, HSSI = EIA-612/613)では 50 ピンのコネク
タを使います。約 50 M ビット/秒の速度が出ますが、数メートルの距離でし
か使えません。Linux 用にも HSSI をサポートしている PCI カードがありま
す。このようなカードを販売している会社が Linux 用のドライバを提供して
いること(あるいはドライバのありかを示していること)もよくあります。この
話題については、mini-HOWTO のようなものが必要でしょう。

<!--
<sect1> The Universal Serial Bus (USB)
-->
<sect1> 汎用シリアルバス (Universal Serial Bus, USB)
<!--
<p> The Universal Serial Bus (USB) is being built into PCI chips.  New
PC's have them.  It is 12 Mbits/s over a twisted pair with a 4-pin
connector (2 wires are power supply) but it also is limited to short
distances of at most 5 meters (depends on configuration).
-->
<p>汎用シリアルバス(USB)は、PCI チップに組み込まれています。新しい PC 
は USB を備えています。USB は 4 ピンコネクタを持つツイストペアケーブル
(2 つの結線は電源供給)を使って 12M ビット/秒の速度で通信できます。
ただし最長 5 メートル(この数字は構成によって変化します)という短い距離
でしか接続できません。

<!--
Another HOWTO is needed for it.  Work is underway for supporting it
in Linux (but no HOWTO).  It is synchronous and transmits in special
packets like a network.  Just like a network, it can have several
devices attached to it.  Each device on it gets a time-slice of
exclusive use for a short time.  A device can also be guaranteed the
use of the bus at fixed intervals.  One device can monopolize it if no
other device wants to use it.  It's not simple to describe in detail.
-->
USB を説明するには別の HOWTO 文書が必要です。Linux で USB をサポートす
るための作業は現在進行中です(ただし HOWTO 文書はまだありません)。USB 
は同期通信を行い、ネットワークと同様に特殊なパケットを使って送信を行い
ます。ちょうどネットワークと同じように、USB には複数のデバイスを接続す
ることができます。USB 上の各デバイスには、排他的な使用を行うための短い
時間のタイムスライスが与えられます。デバイスは、バスを固定の時間間隔で
使用できることが保証されます。他のデバイスが USB バスを使おうとしなけ
れば、1 つのデバイスが USB バスを独占することができます。USB を詳しく
説明することは容易ではありません。

<!--
<sect1> Synchronization &amp; Synchronous <label id="sync">
-->
<sect1> 同期通信と同期性 <label id="sync">
<!--
<p> Beside the asynchronous EIA-232 (and others) there are a number of
synchronous serial port standards.  In fact EIA-232 includes
synchronous specifications but they aren't normally implemented for
serial ports on PC's.  But first we'll explain what a synchronous
means.
-->
<p> EIA-232 の非同期通信(など)の他に、同期シリアルポート通信の規格が
たくさんあります。実際は EIA-232 に同期通信の仕様がありますが、これは
普通は PC のシリアルポートには付いていません。しかしまずは同期通信がど
ういうものかを説明しましょう。

<!--
<sect2> Defining Asynchronous vs Synchronous
-->
<sect2> 非同期と同期の定義

<!--
<p> Asynchronous (async) means "not synchronous".  In practice, an
async signal is what the async serial port sends and receives which is
a stream of bytes each delimited by a start and stop bit.  Synchronous
(sync) is most everything else.  But this doesn't explain the basic
concepts.
-->
<p> 非同期(async, asynchronous)とは「同期的でない」という意味です。
<!--
fujiwara: 日本語訳にするとちょっと間抜け…。
-->
実際には非同期信号は、非同期シリアルポートが送受信するデータであり、ス
タートビットとストップビットによって範囲が定められたバイト列のストリー
ムです。同期(sync)とは、非同期でないものほとんど全てです。ですが、これ
では基本的な概念の説明になりませんね。

<!--
In theory, synchronous means that bytes are sent out at a constant
rate one after another in step with a clock signal tick.  There is
often a separate wire or channel for sending the clock signal.  
Asynchronous bytes may be sent out erratically with various time
intervals between bytes (like someone typing characters at a
keyboard).
-->
理論的には、同期通信とは一定の速度でクロック信号の刻みに合わせてバイ
ト列が順に送られることです。クロック信号を送るための配線やチャンネルが
別になっていることもよくあります。非同期通信の場合には、バイトデータの
間の時間が(キーボードで文字を打ちこむ場合のように)不規則に変化しても送
信ができます。

<!--
There are certain situations that need to be classified as either
sync or async.  The async serial port often sends out bytes in a
steady stream which would make this a synchronous case but since they
still have the start/stop bits (which makes it possible to send them
out erratically) it's called async.  Another case is where data
bytes (without any start-stop bits) are put into packets with possible
erratic spacing between one packet and the next.  This is called sync
since the bytes within each packet must be transmitted synchronously.
-->
同期通信あるいは非同期通信のどちらかへの分類が必要となる場合があります。
非同期シリアルポートでも、多くの場合は一定速度のストリームを送ります。
これは同期通信のように思われるかもしれませんが、それでもスタートビット
やストップビットがあるので(これによりデータを不規則な速度で送信できま
す)非同期通信と呼ばれます。別の場合としては、(スタートビットやストップ
ビットを含まない)バイトデータが、不規則なパケット間隔を持つことがある
パケットに入れられることがあります。これは同期通信です。というのも、各
パケットに入っているバイト列は同期させて送信しなければならないからです。

<!--
<sect2> Synchronous Communication
-->
<sect2> 同期通信
<!--
<p> Did you ever wonder what all the unused pins are for on a 25-pin
connector for the serial port?  Most of them are for use in
synchronous communication which is seldom implemented on PC's.  There
are pins for sync timing signals as well as for a sync reverse
channel.  The EIA-232 spec provides for both sync and async but PC's
use a UART (Universal Asynchronous Receiver/Transmitter) chip such as
a 16450, 16550A, or 16650 and can't deal with sync.  For sync one
needs a USART chip or the equivalent where the "S" stands for
Synchronous.  Since sync is a niche market, a sync serial port is
likely to be quite expensive.
-->
<p>読者の皆さんは、シリアルポート用の 25 ピンコネクタの未使用のピンが
一体何なのかを疑問に思ったことはないでしょうか? 未使用のピンのほとんど
は同期通信用なのですが、同期通信を PC で行うことは滅多にありません。
同期タイミング信号や同期反転チャネルのためのピンがあります。
EIA-232 の仕様には同期通信と非同期通信の両方が定義されていますが、PC 
は 16450, 16550A, 16650 等の UART (Universal Asynchronous Receiver/Transmitter)
チップを使っており、同期通信を扱えません。
同期通信を行うには USART チップあるいはそれと同等のチップを使う必要が
あります。
USART の S は同期(synchronous)を表しています。
同期通信はすきま市場なので、同期シリアルポートは多くの場合かなり高くつ
きます。

<!--
Besides the sync part of the EIA-232, there are various other EIA 
synchronous standards.  For EIA-232, 3 pins of the connector are
reserved for clock (or timing) signals.  Sometimes it's a modem's task
to generate some timing signals making it impossible to use
synchronous communications without a synchronous modem (or without a
device called a "synchronous modem eliminator" which provides the
timing signals).
-->
EIA-232 の同期に関する部分の他にも、EIA には同期に関する規格が色々あり
ます。EIA-232 では、コネクタの 3 つのピンがクロック(あるいはタイミング)
信号のために予約されています。
また、ときにはモデムが何らかのタイミング信号を生成し、同期モデム
(あるいは同じくタイミング信号を生成する「同期モデムエリミネータ」)
なしには同期通信ができないようにすることもあります。
<!--
fujiwara: 「同期モデムエリミネータ」はアレかな(^_^;
-->

<!--
Although few serial ports are sync, synchronous communication
does often take place over telephone lines using modems which use
V.42 error correction.  This strips off the start/stop bits and puts
the date bytes in packets resulting in synchronous operation over the
phone line.
-->
シリアルポートが同期対応であることはほとんどないのですが、
V.42 エラー訂正を使うモデムを用いた、電話回線上での同期通信はよく行わ
れます。このエラー訂正はスタートビットとストップビットを取り除き、パケッ
ト中に日付バイトを入れるもので、その結果として電話回線上で同期操作を実
現します。

<!--
<sect> Other Sources of Information
-->
<sect> 他の情報源
<!--
<sect1> Books
-->
<sect1> 書籍
<p> 
<enum>
<item> Axleson, Jan: Serial Port Complete, Lakeview Research, Madison,
	WI, 1998.
<item> Black, Uyless D.: Physical Layer Interfaces &amp; Protocols, IEEE
	Computer Society Press, Los Alamitos, CA, 1996.
<item> Campbell, Joe: The RS-232 Solution, 2nd ed., Sybex, 1982.
<item>  <url url="http://www.ora.com/catalog/posix/" name="Levine, Donald: 
	POSIX Programmer's Guide">, (ISBN 0-937175-73-0; O'Reilly)
<item> Putnam, Byron W.: RS-232 Simplified, Prentice Hall, 1987.
<item> Seyer, Martin D.: RS-232 Made Easy, 2nd ed., Prentice Hall,
	1991.
<item>  <url 
  url="http://heg-school.aw.com/cseng/authors/stevens/advanced/advanced.nclk"
 name="Stevens, Richard W.: Advanced Programming in the UNIX Environment">,  
 (ISBN 0-201-56317-7; Addison-Wesley) 
<item> Tischert, Michael &amp; Bruno Jennrich: PC Intern, Abacus 1996.
 Chapter 7: Serial Ports
</enum>

<!--
Notes re books:
-->
書籍に関するメモ:
<enum>
<!--
<item>"... Complete" has hardware details (including register) but the
 programming aspect is Window oriented.
-->
<item>"... Complete" には(レジスタを含む)ハードウェアについて詳しく書
かれていますが、プログラミングについては Windows 向けに書かれています。
<!--
<item>"Physical Layer ..." covers much more than just EIA-232.
-->
<item>"Physical Layer ..." は EIA-232 以外の話題もたくさん扱っています。
</enum>

<!--
<sect1> Serial Software
-->
<sect1> シリアルポート用ソフトウェア
<!--
<p> It's best to use the nearest mirror site, but here's the main
sites:<newline>
-->
<p> 最も近いミラーサイトを使うのが好ましいのですが、ここではメインのサ
イトを紹介します:<newline>
<!--
<url url="ftp://metalab.unc.edu/pub/Linux/system/serial/"
name="Serial Software"> for Linux software for the serial ports
including getty and port monitors.<newline>
-->
<url url="ftp://metalab.unc.edu/pub/Linux/system/serial/"
name="Serial Software"> には、getty やポートモニタを含むシリアルポート
用のソフトウェア(Linux 用)があります。<newline>
<!--
<url url="ftp://metalab.unc.edu/pub/Linux/apps/serialcomm"
name="Serial Communications"> for communication programs.
-->
<url url="ftp://metalab.unc.edu/pub/Linux/apps/serialcomm"
name="Serial Communications"> には通信プログラムがあります。

<itemize>
<!--
<item> <tt/irqtune/ will give serial port interrupts higher
 priority to improve performance.  Using <tt/hdparm/ for hard-disk tuning
 may help some more.
-->
<item> <tt/irqtune/ はシリアルポートの割り込みの優先度を高くし、性能を
向上させます。<tt/hdparm/ を使ったハードディスクのチューニングも役に立
つと思います。
<!--
<item> <tt/modemstat/ and <tt/statserial/ show the current state of
 various modem control lines.  See <ref id="serial_mon" name="Serial
Monitoring/Diagnostics">
-->
<item> <tt/modemstat/ と <tt/statserial/ は各種モデム制御線の現在
の状態を表示します。<ref id="serial_mon"
name="シリアルポートの監視/診断用のプログラム">の節を見てください。
</itemize>

<!--
<sect1> Linux Documents
-->
<sect1> Linux 向けの文書
<p>
<itemize>
<!--
<item>man pages for: <tt>setserial(8) stty </tt> 
-->
<item><tt>setserial(8) stty </tt> のマニュアルページ
<!--
<item>libc (or glibc) docs package: "Low Level Terminal Interface"
-->
<item>libc (または glibc) のドキュメント集: "低レベル端末インタフェース"
<!--
<item>Modem-HOWTO: modems on the serial port
-->
<item>Modem-HOWTO: シリアルポートに接続するモデムについて
<!--
<item>PPP-HOWTO: help with PPP (using a modem on the serial port)
-->
<item>PPP-HOWTO: (シリアルポート接続のモデムを通じた)PPP 接続の手引き
<!--
<item>Printing-HOWTO: for setting up a serial printer
-->
<item>Printing-HOWTO: シリアルプリンタの設定
<!--
<item>Serial-Programming-HOWTO: for some aspects of serial-port programming 
-->
<item>Serial-Programming-HOWTO: シリアルポートを使うプログラミングに関する話題
<!--
<item>Text-Terminal-HOWTO: how they work and how to install and configure 
-->
<item>Text-Terminal-HOWTO: テキスト端末の動作とインストール・設定方法
<!--
<item>UPS-HOWTO: setting up UPS sensors connected to your serial port 
-->
<item>UPS-HOWTO: シリアルポートに接続する UPS センサの設定について
<!--
<item>UUCP-HOWTO: for information on setting up UUCP
-->
<item>UUCP-HOWTO: UUCP の設定に関する情報
</itemize>

<!--
<sect1> Usenet newsgroups:
-->
<sect1> Usenet のニュースグループ:
<p>
<itemize>
<item> comp.os.linux.answers
<!--
<item> comp.os.linux.hardware:  Hardware compatibility with the Linux 
 operating system.
-->
<item> comp.os.linux.hardware:  Linux で使えるハードウェアについて
<!--
<item> comp.os.linux.networking:  Networking and communications under Linux.
-->
<item> comp.os.linux.networking:  Linux におけるネットワークと通信について
<!--
<item> comp.os.linux.setup:  Linux installation and system administration.
-->
<item> comp.os.linux.setup:  Linux のインストールとシステム管理
</itemize>

<!--
<sect1> Serial Mailing List
-->
<sect1> シリアルポートに関するメーリングリスト
<p>
<!--
 The Linux serial mailing list.  To join, send email to <tt><htmlurl
 url="mailto:majordomo@vger.rutgers.edu"
 name="majordomo@vger.rutgers.edu"></tt>, with ``<tt>subscribe
 linux-serial</tt>'' in the message body.  If you send ``<tt/help/'' in
 the message body, you get a help message.  The server also serves
 many other Linux lists.  Send the ``<tt/lists/'' command for a list
 of mailing lists.
-->
Linux シリアルメーリングリストがあります。参加するには、
メール本文が ``<tt>subscribe linux-serial</tt>'' であるメールを
<tt><htmlurl  url="mailto:majordomo@vger.rutgers.edu" name="majordomo@vger.rutgers.edu"></tt>
宛に送ってください。メール本文が ``<tt/help/'' であるメールを送ると、
ヘルプメッセージが送られてきます。このサーバは、他にも多くの Linux 関
連メーリングリストを管理しています。メーリングリストの一覧を入手するに
は、``<tt/lists/'' コマンドを送ってください。

<!--
<sect1> Internet
-->
<sect1> インターネット上の情報
<p> 
<itemize>
<!--O
<item> <url url="ftp://scicom.alphacdc.com/pub/linux" name="Serial
 Suite"> by Vern Hoxie is a collection of blurbs about the care and
 feeding of the Linux serial port plus some simple programs.  When
 logging into 'scicom' as "anonymous", you must use your full e-mail
 address as the password.  For example: greg.hankins@cc.gatech.edu
-->
<item> Vern Hoxie さんによる <url
url="ftp://scicom.alphacdc.com/pub/linux" name="Serial Suite"> は、
Linux のシリアルポートの扱いに関する資料と、簡単なプログラムの例を集め
たものです。'scicom' に "anonymous" としてログインする時には、パスワー
ドとして完全な電子メールアドレスを使わなければなりません。例えば
greg.hankins@cc.gatech.edu などです。
<!--O
 <item> A white paper discussing serial communications and multiport
 serial boards was available from Cyclades at <tt><htmlurl
 url="http://www.cyclades.com" name="http://www.cyclades.com"></tt>.
-->
<item> シリアル通信とマルチポートシリアルボードの議論を行った白書が 
Cyclades の WWW ページ <tt><htmlurl url="http://www.cyclades.com"
 name="http://www.cyclades.com"></tt> から入手できます。
</itemize>

<sect> 日本語訳について
<p>
日本語訳は Linux Japanese FAQ Project が行いました。
翻訳に関するご意見は JF プロジェクト &lt;JF@linux.or.jp&gt;
宛に連絡してください。

改訂履歴を以下に示します。

<descrip>
<tag>v1.10j, 30 June 1997</tag>
翻訳:
永田靖人 &lt;nagata-y@bnn-net.or.jp&gt;
<tag>v2.00j, 30 June 1999</tag>
<p>
<tag>v2.01j, 29 September 1999</tag>
<p>
<tag>v2.02j, 19 October 1999</tag>
<p>
<tag>v2.03j, 21 November 1999</tag>
<p>
<tag>v2.04j, 9 December 1999</tag>
<p>
<tag>v2.05j, 22 January 2000</tag>
<p>
<tag>v2.07j, 21 May 2000</tag>
翻訳:
藤原輝嘉 &lt;fujiwara@linux.or.jp&gt;

校正 &amp; テクニカルチェック:
<itemize>
<item>川岸良治 &lt;kawagisi@yk.rim.or.jp&gt;
<item>幸田章宏 &lt;coda@post.kek.jp&gt;
<item>武井伸光 &lt;takei@kondara.org&gt;
<item>山下義之 &lt;dica@eurus.dti.ne.jp&gt;
</itemize>
</descrip>
<!--
END OF Serial-HOWTO
-->
以上
</article>
