From a26a935279a341d7090639f66ee027b5a81a29e8 Mon Sep 17 00:00:00 2001
From: gferg <>
Date: Mon, 10 Mar 2003 14:22:55 +0000
Subject: [PATCH] updated
---
LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml | 6 +-
LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml | 4 +-
.../docbook/HOWTO-INDEX/networkingSect.sgml | 2 +-
.../docbook/HOWTO-INDEX/programmSect.sgml | 2 +-
.../docbook/Secure-Programs-HOWTO/ChangeLog | 10 +
.../Secure-Programs-HOWTO.sgml | 92 +-
LDP/howto/linuxdoc/Modem-HOWTO.sgml | 538 ++++++-----
LDP/howto/linuxdoc/Serial-HOWTO.sgml | 844 ++++++++++--------
8 files changed, 863 insertions(+), 635 deletions(-)
diff --git a/LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml b/LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml
index 537e12aa..34250500 100644
--- a/LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml
+++ b/LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml
@@ -1834,7 +1834,7 @@ and their solutions, availability and more.
Modem-HOWTO,
Modem HOWTO
-Updated: September 2002.
+Updated: March 2003.
Help with selecting, connecting, configuring, trouble-shooting, and
understanding modems for a PC.
@@ -2524,7 +2524,7 @@ SCSI-Generic-HOWTO for more current information.
Secure-Programs-HOWTO,
Secure Programming for Linux and Unix HOWTO
-Updated: February 2003.
+Updated: March 2003.
Provides a set of design and implementation guidelines for writing
secure programs for Linux and Unix systems.
@@ -2591,7 +2591,7 @@ Addresses Linux localization issues specific to Serbian users
Serial-HOWTO,
Serial HOWTO
-Updated: March 2002.
+Updated: February 2003.
Describes serial port features other than those which should be
covered by other HOWTOs. Lists information on multiport serial cards
and contains detailed technical information about the serial port
diff --git a/LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml b/LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml
index 3e6f851a..6b67ffc0 100644
--- a/LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml
+++ b/LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml
@@ -1011,7 +1011,7 @@ attached to this system with other systems over a TCP/IP network.
Modem-HOWTO,
Modem HOWTO
-Updated: September 2002.
+Updated: March 2003.
Help with selecting, connecting, configuring, trouble-shooting, and
understanding modems for a PC.
@@ -1131,7 +1131,7 @@ SCSI-Generic-HOWTO for more current information.
Serial-HOWTO,
Serial HOWTO
-Updated: March 2002.
+Updated: February 2003.
Describes serial port features other than those which should be
covered by other HOWTOs. Lists information on multiport serial cards
and contains detailed technical information about the serial port
diff --git a/LDP/howto/docbook/HOWTO-INDEX/networkingSect.sgml b/LDP/howto/docbook/HOWTO-INDEX/networkingSect.sgml
index 157397bd..86733660 100644
--- a/LDP/howto/docbook/HOWTO-INDEX/networkingSect.sgml
+++ b/LDP/howto/docbook/HOWTO-INDEX/networkingSect.sgml
@@ -207,7 +207,7 @@ Configuring your modem and pppd to use a 2 wire twisted pair leased line. ,
Modem HOWTO
-Updated: September 2002.
+Updated: March 2003.
Help with selecting, connecting, configuring, trouble-shooting, and
understanding modems for a PC.
diff --git a/LDP/howto/docbook/HOWTO-INDEX/programmSect.sgml b/LDP/howto/docbook/HOWTO-INDEX/programmSect.sgml
index 13e61081..81e9625c 100644
--- a/LDP/howto/docbook/HOWTO-INDEX/programmSect.sgml
+++ b/LDP/howto/docbook/HOWTO-INDEX/programmSect.sgml
@@ -489,7 +489,7 @@ operating systems with XML-RPC support.
Secure-Programs-HOWTO,
Secure Programming for Linux and Unix HOWTO
-Updated: February 2003.
+Updated: March 2003.
Provides a set of design and implementation guidelines for writing
secure programs for Linux and Unix systems.
diff --git a/LDP/howto/docbook/Secure-Programs-HOWTO/ChangeLog b/LDP/howto/docbook/Secure-Programs-HOWTO/ChangeLog
index 93c41fbb..d60ff865 100644
--- a/LDP/howto/docbook/Secure-Programs-HOWTO/ChangeLog
+++ b/LDP/howto/docbook/Secure-Programs-HOWTO/ChangeLog
@@ -1,3 +1,13 @@
+2002-02-18 David A. Wheeler
+ * Clarified more about GUI applications.
+ * Updated my picture, now it actually looks more like me.
+ * Changed URL for libsafe.
+ * Renamed LCLint to splint.
+ * Mentioned dreamland.
+
+2002-02-16 David A. Wheeler
+ * Released version 3.007.
+
2002-02-02 David A. Wheeler
* Noted Shamir and Tromir's paper on Factoring Large Numbers with
the TWIRL device (a draft paper at this time) - the paper basically
diff --git a/LDP/howto/docbook/Secure-Programs-HOWTO/Secure-Programs-HOWTO.sgml b/LDP/howto/docbook/Secure-Programs-HOWTO/Secure-Programs-HOWTO.sgml
index c0d934f3..a30e7cf3 100644
--- a/LDP/howto/docbook/Secure-Programs-HOWTO/Secure-Programs-HOWTO.sgml
+++ b/LDP/howto/docbook/Secure-Programs-HOWTO/Secure-Programs-HOWTO.sgml
@@ -134,8 +134,8 @@ http://www.gocsi.com/press/20020407.html
David A.Wheeler
dwheeler@dwheeler.com
-v3.007, 16 February 2003
-v3.007
+v3.010, 3 March 2003
+v3.010
1999
@@ -2261,9 +2261,9 @@ Information Assurance Glossary defines hacker as
``A person who delights in having an intimate understanding of the
internal workings of computers and computer networks.
The term is misused in a negative context where `cracker' should be used.''
-The
+The
Jargon File has a
-
+
long and complicate definition for hacker, starting with
``A person who enjoys exploring the details of programmable systems
and how to stretch their capabilities,
@@ -2285,7 +2285,7 @@ While this may cause a minor loss of typographical beauty, the traditional
American system causes extraneous characters to be placed inside the quotes.
These extraneous characters have
no effect on prose but can be disastrous in code or computer commands.
-
+
I use standard American (not British) spelling; I've yet to meet an
@@ -3463,6 +3463,12 @@ and then call a program, these variables will have full effect.
Other Unix-like systems handle the situation differently but for the
same reason: a setuid/setgid program should not be unduly affected
by the environment variables set.
+Note that graphical user interface toolkits generally do permit
+user control over dynamically linked libraries, because
+executables that directly invoke graphical user inteface toolkits
+should never, ever, be setuid (or have other special privileges) at all.
+For more about how to develop secure GUI applications, see
+.
@@ -7241,11 +7247,12 @@ that any buffer overflows are contained within the current stack frame.
Their initial performance analysis suggests that this
library's overhead is very small.
Libsafe papers and source code are available at
-http://www.bell-labs.com/org/11356/libsafe.html.
+
+http://www.research.avayalabs.com/project/libsafe.
+
The Libsafe source code is available under the completely
-open source LGPL license,
-and there are indications that many Linux distributors are interested
-in using it.
+open source LGPL license.
@@ -7847,9 +7854,10 @@ versions of the linux kernel.
-One Linux-unique tool you can use to simplify minimizing granted privileges
+One tool you can use to simplify minimizing granted privileges
is the ``compartment'' tool developed by SuSE.
-This tool sets the filesystem root, uid, gid, and/or the
+This tool, which only works on Linux,
+sets the filesystem root, uid, gid, and/or the
capability set, then runs the given program.
This is particularly handy for running some other program without
modifying it.
@@ -7886,8 +7894,12 @@ typical Linux distributions, but this may quickly change.
You can download the program via
http://www.suse.de/~marc.
+A similar tool is dreamland; you can that at
+
+http://www.7ka.mipt.ru/~szh/dreamland.
+
Note that not all Unix-like systems,
implement POSIX capabilities, and PR_SET_KEEPCAPS is currently
@@ -8048,24 +8060,45 @@ Another approach is to have separate commands in separate
executables; one command might be a complex
tool that can do a vast number of tasks for a privileged user (e.g., root),
while the other tool is setuid but is a small, simple tool that
-only permits a small command subset.
+only permits a small command subset (and does not trust its invoker).
The small, simple tool checks to see if the input meets various criteria for
acceptability, and then if it determines the input is acceptable, it
passes the data on to the complex tool.
Note that the small, simple tool must do a thorough job checking its inputs
and limiting what it will pass along to the complex tool, or this can
be a vulnerability.
+The communication could be via shell invocation, or any IPC mechanism.
These approaches can even be layered several ways, for example,
a complex user tool could call a simple setuid
``wrapping'' program (that checks its inputs for secure values)
that then passes on information to another complex trusted tool.
-This approach is especially helpful for GUI-based systems; have the GUI portion
-run as a normal user, and then pass security-relevant
-requests on to another program
-that has the special privileges for actual execution.
-
+
+This approach is the normal approach for developing GUI-based applications
+which requre privilege, but must be run by unprivileged users.
+The GUI portion is run as a normal unprivileged user process;
+that process then passes security-relevant requests on to another process
+that has the special privileges (and does not trust the first process, but
+instead limits the requests to whatever the user is allowed to do).
+Never develop a program that is
+privileged (e.g., using setuid) and also directly invokes a graphical toolkit:
+Graphical toolkits aren't designed to be used this way, and it would be
+extremely difficult to audit graphical toolkits
+in a way to make this possible.
+Fundamentally, graphical toolkits must be large, and it's extremely
+unwise to place so much faith in the perfection of that much code, so
+there is no point in trying to make them do what should never be done.
+Feel free to create a small setuid program that invokes two separate programs:
+one without privileges (but with the graphical interface), and one with
+privileges (and without an external interface).
+Or, create a small setuid program that can be invoked by the unprivileged
+GUI application.
+But never combine the two into a single process.
+For more about this, see the statement by
+Owen Taylor about GTK
+and setuid, discussing why GTK_MODULES is not a security hole.
+
Some applications can be best developed by dividing the problem
@@ -11793,7 +11826,7 @@ When MALLOC_CHECK_ is set, a special (less efficient) implementation
is used which is designed to be tolerant against simple errors,
such as double calls of free() with the same argument,
or overruns of a single byte (off-by-one bugs).
-Not all such errors can be proteced against, however, and memory leaks
+Not all such errors can be protected against, however, and memory leaks
can result.
If MALLOC_CHECK_ is set to 0, any detected heap corruption
is silently ignored;
@@ -14680,13 +14713,15 @@ ITS4 is available at
http://www.rstcorp.com/its4.
-LCLint is a tool for statically checking C programs.
-With minimal effort, LCLint can be used as a better lint.
+Splint (formerly named LCLint) is a tool for statically checking C programs.
+With minimal effort, splint can be used as a better lint.
If additional effort is invested adding annotations to programs,
-LCLint can perform stronger checking than can be done by any standard lint.
+splint can perform stronger checking than can be done by any standard lint.
For example, it can be used to statically detect likely buffer overflows.
-The software is licensed under the GPL and is available from
-http://lclint.cs.virginia.edu.
+The software is licensed under the GPL and is available at
+http://www.splint.org.
+
cqual is a type-based analysis tool for finding bugs in C programs. cqual
@@ -14755,6 +14790,9 @@ detect certain memory management errors.
(public domain) and
YAMD (GPL)
can detect memory allocation problems for C and C++.
+You can even use the built-in capabilities of the
+GNU C library's malloc library, which has the
+MALLOC_CHECK_ environment variable (see its manual page for more information).
There are many others.
@@ -15126,7 +15164,7 @@ Free Software Project Management HOWTO and
Software Release Practice HOWTO;
you should also read
-
+
The Cathedral and the Bazaar.
@@ -16068,7 +16106,7 @@ Raymond, Eric.
1997.
The Cathedral and the Bazaar.
http://www.tuxedo.org/~esr/writings/cathedral-bazaar
+url="http://www.catb.org/~esr/writings/cathedral-bazaar">http://www.catb.org/~esr/writings/cathedral-bazaar
@@ -16077,7 +16115,7 @@ Raymond, Eric.
April 1998.
Homesteading the Noosphere.
http://www.tuxedo.org/~esr/writings/homesteading/homesteading.html
+url="http://www.catb.org/~esr/writings/homesteading/homesteading.html">http://www.catb.org/~esr/writings/homesteading/homesteading.html
@@ -17461,7 +17499,7 @@ per the license agreement included above.
-
+
David A. Wheeler
diff --git a/LDP/howto/linuxdoc/Modem-HOWTO.sgml b/LDP/howto/linuxdoc/Modem-HOWTO.sgml
index 28f96601..dd9418db 100644
--- a/LDP/howto/linuxdoc/Modem-HOWTO.sgml
+++ b/LDP/howto/linuxdoc/Modem-HOWTO.sgml
@@ -3,11 +3,12 @@
Modem-HOWTO
<author>David S.Lawyer
<tt><url url="mailto:dave@lafn.org"></tt>
-<date> v0.25, September 2002
+<date> v0.26, March 2003
<!--
Change log: + => added more info ++ => added new topic
-
+v0.26 March 2003: USB clarity improved, v.92 modem "on hold" supported?,
+3Com AT codes
v0.25 September 2002: Must restart minicom after configuring it unless
you used the -s option. HCF is not an all-software modem as was
incorrectly claimed. Better clarity for "Quick Install" and 56k
@@ -111,8 +112,8 @@ should be found in /usr/doc/ppp, /usr/share/doc/ppp or the like.
<sect1> Copyright, Disclaimer, Trademarks, & Credits
<sect2> Copyright
-<p> Copyright (c) 1998-2001 by David S. Lawyer <url url="mailto:dave@lafn.org">
-<!-- license.H begin -->
+<p> Copyright (c) 1998-2003 by David S. Lawyer <url url="mailto:dave@lafn.org">
+<!-- license.D begin -->
Please freely copy and distribute (sell or give away) this document
in any format. Send any corrections and comments to the document
@@ -123,7 +124,7 @@ provided that you:
<item> If it's not a translation: Email a copy of your derivative work
(in a format LDP accepts) to the author(s) and maintainer (could be
the same person). If you don't get a response then email the LDP
- (Linux Documentation Project): submit@linuxdoc.org.
+ (Linux Documentation Project): submit@en.tldp.org.
<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.
@@ -141,9 +142,9 @@ them. Since this is free documentation, it should be obvious that I
cannot be held legally responsible for any errors.
<sect2>Trademarks.
-<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 -->
+<p> Any brand names (starts with a capital letter such as MS Windows)
+should be assumed to be a trademark). Such trademarks belong to their
+respective owners. <!-- license.D end -->
"Hayes" is a trademark of Microcomputer Products Inc. I use
@@ -175,31 +176,27 @@ or two old, check to see that you have the latest version. Please
send me any other info that you think belongs in this document.
<sect1> New Versions of this HOWTO <label id="new_vers">
-<p> New versions of this Modem-HOWTO come out every few months. The
-modem situation is rapidly changing (and I'm still learning). Your
-problem might be solved in the latest version. It will be available
-to browse and/or download at LDP mirror sites. For a list of such
-sites see: <url url="http://www.tldp.org/mirrors.html"> If you
-only want to quickly compare the date of this the version v0.25, September 2002 with
+<p> New versions of this Modem-HOWTO should come out every few months.
+Your problem might be solved in the latest version. It will be
+available to browse and/or download at LDP mirror sites. For a list
+of such sites see: <url url="http://www.tldp.org/mirrors.html"> If you
+only want to quickly compare the date of this the version v0.26, March 2003 with
the date of the latest version go to: <url
url="http://www.tldp.org/HOWTO/Modem-HOWTO.html">
<sect1> New in Recent Versions
-<p> For a full revision history going back to v0.00 see the source file
-(in linuxdoc format) at
-<url
+<p> For a full revision history going back to the first version see
+the source file (in linuxdoc format) at <url
url="http://www.ibiblio.org/pub/linux/docs/HOWTO/other-formats/sgml/Modem-HOWTO.sgml.gz">.
+v0.26 March 2003: USB clarity improved, v.92 modem "on hold" supported?,
+3Com AT codes
v0.25 September 2002: Must restart minicom after configuring it unless
you used the -s option. HCF is not an all-software modem as was
incorrectly claimed. Better clarity for "Quick Install" and 56k
modems. Does my PC have a modem?<newline>
v0.24 June 2002: new callback link, "You are already online" error,
fixed several typos reported by Francesco Ronconi<newline>
-v0.23 January 2002: dropped connection w/V.90, X3 to force dialing if
- NO DIALTONE, more on USB, wvdial added to "Trying Out Your Modem",
- major revision to "Antique Modems", several broken links fixed,
- better clarity re RAS, digital modems.
<sect1> What is a Modem ? <label id="what_is_modem">
<p> A modem is a device that lets one send digital signals over an
@@ -215,10 +212,11 @@ may phone in to them and use their computer. This is called
There are four basic types of modems for a PC: external, USB, internal
and built-in. The external and USB set on your desk outside the PC
while the other two types are not visible since they're inside the PC.
-The external modem plugs into a connector on the back of the PC known
-as a "serial port". The USB modem plugs into the USB bus cable. See
-<ref id="usb_" name="USB Modems">. The internal modem is a card that
-is inserted inside the computer. The built-in modem is part of the
+Sometimes the USB type is called "USB external". The external serial
+modem plugs into a connector on the back of the PC known as a "serial
+port". The USB modem plugs into the USB bus cable. See <ref
+id="usb_" name="USB Modems">. The internal modem is a card that is
+inserted inside the computer. The built-in modem is part of the
motherboard and is thus built into the computer. It's is just like an
internal modem except it can't be removed or replaced. As of 2001,
built-in modems are primarily for laptops. What is said in this HOWTO
@@ -226,21 +224,30 @@ regarding internal modems will generally apply also to built-in
modems.
For a more detailed comparison see <ref id="int_vs_ext" name="External
-vs. Internal">. When you get an internal, built-in, or USB modem,
+vs. Internal">. When you get an internal or, built-in, modem,
you also get a dedicated serial port (which can only be used with the
modem and not with anything else such as another modem or a printer).
In Linux, the serial ports are named ttyS0, ttyS1, etc. (usually
corresponding respectively to COM1, COM2, etc. in Dos/Windows). For
the new devfs they are all in the /dev/ttys/ directory and named 0, 1,
etc. See <ref id="basics_" name="Modem & Serial Port Basics"> for
-more details on modems and serial ports.
+more details on modems and serial ports. With a USB modem, the driver
+simulates a serial port at say /dev/usb/asm/0.
Modems usually include the ability to send Faxes (Fax Modems). See
<ref id="fax_" name="Fax"> for a list of fax software. "Voice" modems
can work like an automatic answering machine and handle voicemail.
-See <ref id="voice_" name="Voicemail">.
+See <ref id="voice_" name="Voicemail Software">.
-<sect1> Does My Computer Contain a Modem ?
+The v.92 protocol can put the modem "on hold" when someone makes an
+ordinary voice call to your telephone, provided that you have "call
+waiting" from your telephone company. Thus you can get a phone call
+while online. As of Jan. 2003 Linux doesn't seem to support it. If
+this is the latest version of this HOWTO, let me know about any
+Linux support for it. Some linmodem drivers may support it (but what
+if you have a hardware modem ?).
+
+<sect1> Does My Computer Contain an Internal Modem ?
<p> Internal modems usually have a pair of modular telephone jacks on
the back of the computer. They should be right next to each other and
look like a jack on the wall of a house where a telephone plugs in.
@@ -403,13 +410,13 @@ external modem and plug it in. But if you get the right internal
modem it may be just as easy.
<sect1> Is a Driver Needed ?
-<p> Hardware modems (including all external modems) don't really need
-any modem driver. But any software modem (winmodem, linmodem) must
-have a modem driver (if it exists for Linux). The serial port the
-modem resides on does need a driver and it's supplied either as a
-Linux serial module or compiled into the kernel. Any serial driver
-for a PCI Modem should install automatically since they are detected
-by system software.
+<p> Hardware modems (including all serial external modems) don't
+really need any modem driver. But any software modem (winmodem,
+linmodem) must have a modem driver (if it exists for Linux). The
+serial port the modem resides on does need a driver and it's supplied
+either as a Linux serial module or compiled into the kernel. Any
+serial driver for a PCI Modem should install automatically since they
+are detected by system software.
Software modems require software to run them and obviously do need a
driver. The drivers for MS Windows are *.exe programs which will not
@@ -469,7 +476,7 @@ program and configure the modem itself.
the PC and inserting the modem card into a vacant slot on the
motherboard. There are modems for PCI slots, other modems for the
older ISA slots, and ARM software "modems" for the new small AMR slot.
-Some new PC don't have any ISA slots. Only some newer PCs will have
+Some new PCs don't have any ISA slots. Only some newer PCs will have
ARM slots. While external modems plug into the serial port (via a
short cable) the internal modems have the serial port built into the
modem. In other words, the modem card is both a serial port and a
@@ -696,11 +703,14 @@ one of them.
<p>USB = Universal Serial Bus. Some USB modems work with Linux and
some don't. Linux has support for modems that conform to the USB
Communication Device Class Abstract Control Model (= USB CDC ACM).
-There's a module for ACM named acm.o. See the /usb/acm... document in
+There's a module for ACM named acm.o. See the /usb/acm.txt document in
the kernel documentation directory (/usr/share/doc/kernel-doc-2.4.x in
Debian, perhaps /usr/doc/kernel... in some distributions). The ACM
-serial port for the first (0th) such modem is (with devfs) is:
-/dev/usb/acm/0. Otherwise it might be /dev/usb/ttyACM0.
+"serial port" for the first (0th) such modem is: /dev/usb/acm/0 or
+possibly /dev/usb/ttyACM0. This should be the case regardless of
+whether or not you use the new "device file system". It's not really
+a serial port, but the driver makes it look like a serial port to
+software which uses the modem.
<sect1> Which Internal Modems might not work with Linux <label id="m_to_avoid">
<p>
@@ -901,6 +911,7 @@ Sept. '00: data flow diagram
Dec. '00 flow control +
July '01 done -> down
Feb. '02 4k buffer -> 8k
+Feb '03: UARTs with auto flow control. Rewrite of Flow Control.
-->
<!-- ifdef MODEM_ -->
<p> You don't have to understand the basics to use and install a
@@ -940,7 +951,7 @@ name="Modulation Details">.
<sect1> What is a Serial Port ?
<sect2> Intro to Serial
-<p> The serial port is an I/O (Input/Output) device.
+<p> The UART serial port (or just "serial port for short" is an I/O (Input/Output) device.
<!-- ifdef MODEM_ -->
Since modems have a serial port between them and the computer,
it's necessary to understand the serial port as well as the modem.
@@ -1051,7 +1062,7 @@ 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
+set by jumpers or by plug-and-play software). Thus which 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
@@ -1068,18 +1079,18 @@ their way to their destination inside your computer.
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.
+normally used only by that port. Thus the FIFO waits until it has
+received a number of bytes and then issues an interrupt.
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.
+Thus if the bytes are being received slowly (such as from 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 in an interval of time, 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.
Each interrupt conductor (inside the computer) has a number (IRQ) and
the serial port must know which conductor to use to signal on. For
@@ -1088,13 +1099,13 @@ 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.
-<!-- ifdef MODEM_ -->
+hold only 16 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.
-For an external modem, there is no way (such as flow control) to stop
+<!-- ifdef MODEM_ -->
+For an external modem, there may be no way (such as flow control) to stop
the flow rapidly enough to prevent this. For an internal modem the
16-byte FIFO buffer is on the same card and a good modem will not
write to it if it's full. Thus a good internal modem will not overrun
@@ -1104,11 +1115,11 @@ being overrun. This is one advantage of an internal modem over an
external. <!-- ifdef MODEM end -->
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.
+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.
+changes state, an interrupt is issued.
The buffers mentioned above are all hardware buffers. The serial port
also has large buffers in main memory. This will be explained later
@@ -1201,8 +1212,9 @@ report the modem-to-modem speed as (for example): CARRIER 28800.
If you have an internal modem you would not expect that there would be
any speed limit on the DTE speed from your modem to your computer
since you modem is inside your computer and is almost part of your
-computer. But there is since the modem contains a dedicated serial
-port within it.
+computer. But there usually is since the modem contains a dedicated
+serial port within it. On some software modems there is no such speed
+limit.
It's important to understand that the average speed is often less than
the specified speed, especially on the short DTE computer-to-modem
@@ -1224,7 +1236,7 @@ id="speed_" name="What Speed Should I Use">.
<p> Flow control means the ability to slow down the flow of bytes in a
wire. For serial ports this means the ability to stop and then
restart the flow without any loss of bytes. Flow control is needed
-for modems to allow a jump in instantaneous flow rates.
+for modems and other hardware to allow a jump in instantaneous flow rates.
<sect2> Example of Flow Control
<p> For example, consider the case where you connect a 33.6k external
@@ -1259,18 +1271,19 @@ which is already compressed and can't be compressed further. Now
let's consider the opposite extreme where the modem is compressing the
data with a high compression ratio. In such a case the modem might
need an input flow rate of say 115.2k bps to provide an output (to the
-phone line) of 33.6k bps (compressed data). The compression ratio is
-3.43 (115.2/33.6) which is much higher than average. In this case the
-modem is able to compress and the 115.2 bps PC-to-modem flow and send
-the same data out on the phone line at 33.6bps. There's no need for
-flow control here. But such a high compression ratio rarely happens
-so that most of the time flow control is needed to slow down the flow
-on the 115.2 bps PC-to-modem cable. The flow is stopped and started
-so that the average flow is usually well under the "on" flow of 115.2
-bps.
+phone line) of 33.6k bps (compressed data). This compression ratio is
+3.43 (115.2/33.6). In this case the modem is able to compress and
+the 115.2 bps PC-to-modem flow and send the same data (in compressed
+form) out the phone line at 33.6bps. There's no need for flow control
+here so long as the compression ratio remains higher that 3.43. But
+the compression ratio varies from second to second and is likely to
+drops below 3.43. Thus, some of the time flow control is needed to
+slow down the average flow on the 115.2 bps PC-to-modem cable. The
+flow is stopped and started so that the average flow is usually lower
+than the "on" flow of 115.2 bps.
In the above example the modem was an external modem. But the same
-situation exists (as of late 2000) for most internal modems. There is
+situation exists (as of early 2003) for most internal modems. There is
still a speed limit on the PC-to-modem speed even though this flow
doesn't take place over an external cable. This makes the internal
modems compatible with the external modems.
@@ -1280,23 +1293,25 @@ 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.
+serial driver. Flow control protects all buffers (except the FIFOs)
+from overflowing.
+
+Under Linux, the small UART FIFO buffers are not protected in this way
+but rely instead on a fast response to the interrupts they issue.
+Some UART chips can be set to do hardware flow control to protect
+their FIFOs but Linux (as of early 2003) doesn't seem to support it.
+FIFO stand for "First In, First Out" which is the way it handles bytes
+in a queue. All the 3 buffers use the FIFO rule but only one of them
+is named "FIFO". This is the essence of flow control but there
+are still some more details.
<!-- ifdef MODEM_ -->
-You don't often need flow control in the direction from the modem to a
-PC. For complex example of a case where it's needed see "Complex Flow
-Control Example" in the Serial-HOWTO. But if you don't have a high
-enough speed set between the modem and the computer (serial port
-speed) then you do need to slow down the flow coming into the modem
-from the telephone line. To do this your modem must tell the other
-modem to stop sending. See <ref id="M-M_flow_c" name="Modem-to-Modem
-Flow Control">.
+If you have set the highest PC-to-modem speed, you may not need flow
+control in the direction from the modem to a PC. For complex example
+of a case where it's needed see "Complex Flow Control Example" in the
+Serial-HOWTO. To slow down this incoming flow, your modem must tell
+the other modem to stop sending. See <ref id="M-M_flow_c"
+name="Modem-to-Modem Flow Control">.
<!-- ifdef MODEM end -->
@@ -1304,11 +1319,24 @@ Flow Control">.
<sect2> Hardware vs. Software Flow Control
<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.
-<!-- ifdef MODEM_ -->
-Modern modems almost always use hardware flow control between the
-modem and the serial port.
-<!-- ifdef MODEM end -->
+signals. Hardware flow control at the serial port works like this:
+The two pins, RTS (Request to send) and CTS (Clear to send) are used.
+When the computer is ready to receive date it asserts RTS by putting a
+positive voltage on the RTS pin (meaning "request to send to me").
+When the computer is not able to receive any more bytes, it negates
+RTS by putting a negative voltage on the pin saying: "stop sending to
+me". The RTS pin is connected by the serial cable to another pin on
+the modem, printer, terminal, etc. This other pin's only function is
+to receive the signal.
+
+For the case of a modem this "other" pin will be the modem's RTS pin
+(same pin label as the PC). But for a printer or terminal, it will be
+a CTS pin and requires "crossover" or "null modem" cable so as to
+connect the CTS pin at one end with the RTS pin at the other end. For
+a modem, a straight-thru cable is used. For the opposite direction of
+flow a similar scheme is used. For a modem, the CTS pin is used to
+send the flow control signal and the RTS pin a receive it. For a
+non-modem, the roles of the RTS and CTS pins are interchanged.
Software flow control uses the main receive and transmit wires to send
the start and stop signals. It uses the ASCII control characters DC1
@@ -1326,19 +1354,19 @@ modem (hardware) and software support
<sect2> Symptoms of No Flow Control
<p> Understanding flow-control theory can be of practical use. For
example I used my modem to access the Internet and it seemed to work
-fine. But after a few months I tried to send long files from my PC to
-an ISP and a huge amount of retries and errors resulted (but
-eventually Kermit could send a long file after many retries).
-Receiving in the other direction (from my ISP to me) worked fine. The
-problem turned out to be a modem with broken flow control. My modem's
-buffer was overflowing (overrunning) on long outgoing files since no
-"stop" signal was ever sent to my computer to halt sending to the
-modem. There was no problem in the direction from the modem to my
-computer since the capacity (say 115.2 kbps) was always higher than the
-flow over the telephone line. But it was a problem in the other
-direction where the PC could send at 115.2 kbps until it overran the
-modem). The fix was to enable flow control by putting into the init
-string an enable-flow-control command for the modem.
+fine. But after a few months I tried to send out long files from my PC
+and a huge amount of retries and errors resulted but it finally
+succeeded. Receiving in the other direction (from my ISP to me) worked
+fine. The problem turned out to be a modem with flow control disabled.
+My modem's buffer was overflowing (overrunning) on long outgoing files
+since no "stop" signal was ever sent to my computer to halt sending to
+the modem. There was no problem in the direction from the modem to my
+computer since the capacity (say 115.2 kbps) was always higher than
+the flow from the telephone line. But it was a problem in the other
+direction where the PC would send at 115.2 kbps and the modem couldn't
+handle this high flow resulting in overruns of the modem's buffer.
+The fix was to enable flow control by putting into the modem's init
+string an enable-flow-control command.
<sect2> Modem-to-Modem Flow Control <label id="M-M_flow_c">
<p> This is the flow control of the data sent over the telephone lines
@@ -1350,48 +1378,53 @@ used.
<!-- ifdef MODEM end -->
<sect1> Data Flow Path; Buffers
-<p> Much has been explained about this including flow control, a pair
-of 16-byte FIFO buffers (in the UART), and a pair of larger buffers
-inside a device connected to the serial port (such as a modem). But
-there is still another pair of buffers. These are large buffers
-(perhaps 4k) in main memory also known as serial port buffers. When
-an application program sends bytes to the serial port
-(and modem)they first get stashed in 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. Here's an example
-diagram for the case of browsing the Internet with a browser.
-Transmit data flow is left to right while receive flow is right to
-left.
+<p>It's been mention that there are 3 buffers for each direction of
+flow (3 pairs altogether): 16-byte FIFO buffers (in the UART), a pair
+of larger buffers inside a device connected to the serial port (such
+as a modem), and a pair of buffers (say 8k) in main memory.
+When an application program sends bytes to the serial port they first
+get stashed in the transmit serial port buffer in main memory. The
+pair consists of both the transmit buffer and a receive buffer for
+the opposite direction of byte-flow. Here's an example diagram for
+the case of browsing the Internet with a browser. Transmit data flow
+is left to right while receive flow is right to left. There is a
+separate buffer for each direction of flow.
<verb>
-application 4k-byte 16-byte 1k-byte tele-
-BROWSER ------- MEMORY -------- UART --------- MODEM -------- phone
+application 8k-byte 16-byte 1k-byte tele-
+BROWSER ------- MEMORY -------- FIFO --------- MODEM -------- phone
program buffer buffer buffer line
</verb>
-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 UART for transmission. Once in that transmit buffer, there
-is no way to stop them from being transmitted. They are then
-transmitted to the modem
-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 modem has stopped, an application program
-may keep sending bytes to the 4k transmit buffer until it becomes
-fill.
+For the transmit case, the serial device driver takes out say 16 bytes
+from this transmit buffer (in main memory), one byte at a time and
+puts them into the 16-byte transmit buffer in the serial UART for
+transmission. Once in that transmit buffer, there is no way to stop
+them from being transmitted. They are then transmitted to the
+modem or (other 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 modem has stopped, an application program may keep sending
+bytes to the 8k transmit buffer until it becomes fill. At the same
+time, the bytes stored in the FIFO and MODEM continue to be sent out
+until these buffers empty.
-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".
+When the memory buffer 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 since it may switch to running other processes while it's
+waiting at a flow control stop.
+
+The above was a little oversimplified in two ways. First, some UARTs
+can do automatic hardware flow control which can stop the transmission
+out of the FIFO buffers if needed (not yet supported by Linux).
+Second, while an application process is waiting to write to the
+transmit buffer, it could possibly perform other tasks.
<!-- ifdef MODEM_ -->
<sect1> Modem Commands
@@ -1432,7 +1465,7 @@ id="modem_conf" name="Modem Configuration">
<sect1> Serial Driver Module
<p> The device driver for the serial port is the software that
operates the serial port. It is now provided as a serial module.
->From kernel 2.2 on, this module will normally get loaded automatically
+From kernel 2.2 on, this module will normally get loaded automatically
if it's needed. 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
@@ -1500,6 +1533,7 @@ Aug. 2001: removed mention of patch to convert Linux to a PnP OS;
better explanation of PCI
July 2001: Improve PCI part. Remove "card" since serial ports are
often built into the motherboard.
+Feb. 2003: Removed request to send info to Ted Tso.
-->
<sect1> IO & IRQ Overview
@@ -1614,7 +1648,7 @@ got them working anyway). The 2.4 serial driver will read the id
number digitally stored in the serial hardware to determine how to
support it (if it knows how). It should assign an I/O address to it,
determine it's IRQ, etc. So you don't need to use "setserial" for it.
-
+<!--
<sect2> Requesting that future drivers support your serial port
<p>If you have a
PCI internal modem which you are convinced is not a winmodem
@@ -1637,7 +1671,7 @@ 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">.
-
+-->
<sect2>More info on PCI
<p>PCI ports are not well standardized. Some use main memory for
communication with the PC. Some require special enabling of the IRQ.
@@ -2174,11 +2208,12 @@ stty -F /dev/ttyS2 crtscts
</verb></tscreen>
If you want to see if flow control is enabled do the following: In
-minicom (or the like) type AT&V to see how the modem is configured
-and look for &K3 which means hardware flow control. Then without
-exiting the communications program (such as minicom) see if the device
-driver knows about it by typing: stty -F /dev/ttyS2 -a. Look for
-"crtscts" (without a disabling minus sign).
+minicom (or the like) type AT&V (or ATI4 on 3Com modems) to see
+how the modem is configured and look for &K3 (or &H1 on 3Com
+modems) which means hardware flow control. Then without exiting the
+communications program (such as minicom) see if the device driver
+knows about it by typing: stty -F /dev/ttyS2 -a. Look for "crtscts"
+(without a disabling minus sign).
<sect1> Speed Settings
<p> Besides flow control there is speed. See <ref id="speed_"
@@ -2426,9 +2461,10 @@ these AT commands:
best not to have any other process running on the modem port when you
do this. If you have set up minicom for your modem, then you may type
on the command line: <tt>minicom -o</tt> to start minicom without
-restoring the saved modem profile. Then type <tt>at&v</tt> to
-display the profile. To exit minicom without disturbing this profile,
-use the q (quit) command for exiting without resetting.
+restoring the saved modem profile. Then type <tt>at&v</tt> (or
+atI4 on 3Com modems) to display the profile. To exit minicom without
+disturbing this profile, use the q (quit) command for exiting without
+resetting.
The above may not work for various reasons. If the modem has been set
not to echo result codes it may not even display any profile. If there
@@ -2497,6 +2533,7 @@ interface and makes it easy to deal with a huge number of devices.
The device names have all changed as well. But there's an option to
continue using the old names. For a detailed description of it see:
<url url="http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html">
+Also see the kernel documentation tree: filesystems/devfs.
The name changes (if used) are: ttyS2 becomes tts/2 (Serial port),
tty3 becomes vc/3 (Virtual Console), ptyp1 becomes pty/m1 (PTY
@@ -2513,10 +2550,10 @@ in the /dev directory.
There formerly was a "cua" name for each serial port and it behaved
just a little differently. For example, ttyS2 would correspond to
-cua2. The cua major number was 5 and minor numbers started at 64.
-You may still have the cua devices in your /dev directory but they are
-now deprecated. Their drivers behave slightly different than for the
-ttyS ones. name="cua Device Obsolete">."')
+cua2. It was mainly used for modems. The cua major number was 5 and
+minor numbers started at 64. You may still have the cua devices in
+your /dev directory but they are now deprecated. For details see
+Modem-HOWTO, section: cua Device Obsolete.
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.
@@ -2590,6 +2627,7 @@ May 2000: <sect2> IRQs near end ttyS0 -> ttyS1 + clarity
Nov. 2000: auto_irq may work on the 2nd try
Dec. 2000: saving state of serial module
June 2001 OK to use setserial with Laptops
+Nov. 2002 Debian's /var/lib/serial.conf
-->
<p> This part is in 3 HOWTOs: Modem, Serial, and Text-Terminal. There
are some minor differences, depending on which HOWTO it appears in.
@@ -2724,14 +2762,15 @@ IRQ's but this doesn't always work right either. In one case it first
gave the wrong irq but when the command was repeated it found the
correct irq. In versions of setserial >= 2.15, the results of your
last probe test could be automatically 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 data someone wrote into the script
-or data that got saved in /etc/serial.conf.
+configuration file <tt>/etc/serial.conf</tt> or
+<tt>/var/lib/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 data someone wrote into the script or data that
+got saved in /etc/serial.conf.
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
@@ -3340,8 +3379,8 @@ waiting for an incoming phone call. There is a supplemental program
called <tt/vgetty/ which handles voicemail for some modems.
<tt/mgetty/ documentation is fair (except for voice mail), and is not
supplemented in this HOWTO. To automatically start PPP one must edit
-/etc/mgetty/login.conf to enable "AutoPPP" You can find the latest
-information on <tt/mgetty/ at <htmlurl
+/etc/mgetty/login.conf to use "AutoPPP" (has example). You can find
+the latest information on <tt/mgetty/ at <htmlurl
url="http://www.leo.org/˜doering/mgetty/"
name="http://www.leo.org/˜doering/mgetty/"> and <url
url="http://alpha.greenie.net/mgetty/">
@@ -3909,7 +3948,7 @@ your computer (PC-to-modem speed). This is sometimes called "DTE
speed" where "DTE" stands for Data Terminal Equipment (Your computer
is a DTE.) You need to set this speed high enough so this part of the
signal path will not be a bottleneck. The setting for the DTE speed
-is the maximum speed of this link. Most of the time it should
+is the maximum speed of this link. Most of the time it will likely
actually operate at lower speeds.
For an external modem, DTE speed is the speed (in bits/sec) of the
@@ -3917,9 +3956,10 @@ flow over the cable between you modem and PC. For an internal modem,
it's the same idea since the modem also emulates a serial port. It
may seem ridiculous having a speed limit on communication between a
computer and a modem card that is directly connected inside the
-computer to a much higher speed bus. But it's that way since the
-modem card probably includes a dedicated serial port which does have
-speed limits (and settable speeds).
+computer to a much higher speed bus. But it's usually that way since
+the modem card probably includes a dedicated serial port which does
+have speed limits (and settable speeds). However, some software
+modems have no such speed limits.
<sect1> Speed and Data Compression
<p> What speed do you choose? If it were not for "data compression"
@@ -3929,9 +3969,9 @@ computer and encodes them into a fewer number of bytes. For example,
if the flow (speed) from the PC to the modem was 20,000 bytes/sec
(bps) and the compression ratio was 2 to 1, then only 10,000 bytes/sec
would flow over the telephone line. Thus for a 2:1 compression ratio
-you need to set the DTE speed to double the maximum modem speed on the
-phone line. If the compression ratio were 3 to 1 you need to set it 3
-times faster, etc.
+you would need to set the DTE speed to double the maximum modem speed
+on the phone line. If the compression ratio were 3 to 1 you would
+need to set it 3 times faster, etc.
<sect1> Where do I Set Speed ?
<p> This DTE (PC-to-modem) speed is normally set by a menu in your
@@ -3946,6 +3986,7 @@ different speeds, then they couldn't communicate with each other.
<sect1> Can't Set a High Enough Speed <label id="high_speed">
<!-- high_speed.H begin In Serial and Modem HOWTOs but some of the speed
section is unique to each HOWTO.
+Feb. 2003,
-->
<sect2> Speeds over 115.2k
<p> The top speed of 115.2k has been standard since the mid 1990's.
@@ -3965,17 +4006,19 @@ setserial (unless the serial driver does this for you). The software
will then use a divisor of 1 to set the highest speed. All this will
hopefully be supported by the Linux kernel sometime in 2002.
-A non-standard way to do this is to use a very large number for the
-divisor which isn't really a divisor at all. It's just a code number
-to tell the serial driver what speed to use. In such cases you need
-to compile the kernel with special patches.
+A non-standard way that some manufacturers have implemented high speed
+is to use a very large number for the divisor to get the high speed.
+This number isn't really a divisor at all since it doesn't divide
+anything. It's just serves as a code number to tell the hardware what
+speed to use. In such cases you need to compile the kernel with
+special patches.
-One patch to support this second type of high-speed is called shsmod
-(Super High Speed Mode). There are both Windows and Linux versions of
-this patch. See <url url="http://www.devdrv.com/shsmod/">. There is
-also a module for the VIA VT82C686 chip <url
-url="http://www.kati.fi/viahss/">. Using it may result in buffer
-overflow.
+One patch to support this second type of high-speed hardware is called
+shsmod (Super High Speed Mode). There are both Windows and Linux
+versions of this patch. See <url
+url="http://www.devdrv.com/shsmod/">. There is also a module for the
+VIA VT82C686 chip <url url="http://www.kati.fi/viahss/">. Using it
+may result in buffer overflow.
For internal modems, only a minority of them advertise that they
support speeds of over 115.2k for their built-in serial ports.
@@ -4341,11 +4384,14 @@ response could be due to the modem being in "online data" mode where
it can't accept any AT commands. You may have been using the modem
and then abruptly disconnected (such as killing the process with
signal 9). In that case your modem did not get reset to "command
-mode" where it can interact to AT commands. Thus the message from
-minicom "You are already online. Hangup first." Well, you are sort
-of online but you are may not be connected to anything over the phone
-line. Wvdial will report "modem not responding" for the same
-situation.
+mode" where it can interact to AT commands. "Minicom" may display
+"You are already online. Hangup first." (For another meaning of this
+minicom message see
+<ref id="already_online" name= "You are already online! Hang up
+first.">)
+Well, you are sort of online but you are may not be connected to
+anything over the phone line. Wvdial will report "modem not
+responding" for the same situation.
To fix this as a last resort you could reboot the computer. Another
way to try to fix this is to send +++ to the modem to tell it to
@@ -4375,8 +4421,8 @@ error" one may get when trying to use "stty -F /dev/ttySx"). To get a
few of these stty parameters, the true address of the port must be
known to the driver. So the driver may have the wrong address. The
setserial" command will display what the driver thinks but it's likely
-wrong in this case. So what the "modem busy" really means is that the
-serial port (and the modem) can't be found.
+wrong in this case. So what the "modem busy" often means is that the
+serial port (and thus the modem) can't be found.
If you have a pci modem, then use one of these commands: lspci, or cat
/proc/pci, or dmesg to find the correct address and irq of the
@@ -4388,12 +4434,13 @@ the kernel to understand the lspci data correctly. You might notice
this in a boot-time message.
<sect1> "You are already online! Hang up first." (from minicom)
+<label id="already_online">
<p> The modem has its CD signal on. Either you are actually online
(a remote modem is sending you a carrier) or your modem has been setup
to always send the CD signal. In minicom, type at&v to see if
&C or &C0 is set. If so, CD will be on even if you are
-offline and you'll get this error message. The fix is to set &C1
-in the init string or save it in the modem.
+offline and you'll erroneously get this error message. The fix is to
+set &C1 in the init string or save it in the modem.
<sect1> I can't get near 56k on my 56k modem
<p> There must be very low noise on the line for it to work at even
@@ -4541,6 +4588,9 @@ Nov. '00: which connector is ttyS1, etc. Input/output error, overrun
Dec. '00: /proc/tty/driver/serial shows info, I/O error+, pid 161 in
example n.g.
July '02: typo: is doesn't => it doesn't, clarity re port not found
+Dec. '02: IO error may mean IRQ conflict or IO address conflict.
+Jan. '03: LSR safety check error
+Feb. '03: Interrupts may be shared on PCI Bus
-->
<sect1>(The following subsections are in both the Serial and Modem HOWTOs)
@@ -4551,20 +4601,22 @@ often because it's disabled and has no address (PnP hasn't enabled it)
or that it is enabled but is not at the I/O address that setserial
thinks it's at. Thus it can't be found.
-Check the BIOS menus and BIOS messages at boot-time. For the PCI bus
-use lspci or scanpci. If it's an ISA bus PnP serial port, try
-"pnpdump --dumpregs" and/or see Plug-and-Play-HOWTO. If the port
-happens to be enabled then the following two paragraphs may help find
-it:
+First check BIOS messages at boot-time (and possible the BIOS menu for
+the serial port). For the PCI bus use lspci or scanpci. If it's an
+ISA bus PnP serial port, try "pnpdump --dumpregs" and/or see
+Plug-and-Play-HOWTO. If the port happens to be enabled then the
+following two paragraphs may help find it:
-Using "scanport" (Debian only ??) 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">. Use <tt>setserial -g</tt> to
-see what the serial driver thinks and check for IRQ and I0 address
+For a non-PnP ISA legacy port, using "scanport" (Debian only ??) will
+scan all 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">. Use <tt>setserial -g</tt>
+to see what the serial driver thinks and check for IRQ and I0 address
conflicts. Even if you see no conflicts the driver may have incorrect
information (view it by "setserial") and conflicts may still exist.
@@ -4717,25 +4769,27 @@ have been automatically removed if it contained a stale process id
<sect1> "/dev/tty? Device or resource busy" <label id="busy_err">
<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 (the resource is "busy").
+is supposedly being used by another device and can't be shared.
This message is easy to understand if it only means that the device is
-busy (in use). But it often means that a resource is in use. What
-makes it even more confusing is that in some cases neither the device
-nor the resources that it needs are actually "busy".
+busy (in use). But it often means that a needed resource is already
+in use (busy). What makes it even more confusing is that in some cases
+neither the device nor the resources that it needs are actually
+"busy".
-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
-"... busy" error message. This is because the kernel only keeps track
-of what IRQs are actually in use and actual conflicts don't happen
-unless the devices are in use (open). The situation for I/O address
-(such as 0x3f8) conflict is similar.
+The following example is where interrupts can't be shared (at least
+one of the interrupts is on the ISA bus). 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 "... busy" error message. This is because the
+kernel only keeps track of what IRQs are actually in use and actual
+conflicts don't happen unless the devices are in use (open). The
+situation for I/O address (such as 0x3f8) conflict is similar.
This error is sometimes due to having two serial drivers: one a module
and the other compiled into the kernel. Both drivers try to grab the
@@ -4749,9 +4803,8 @@ There are two possible cases when you see this message:
</enum>
What you need to do is to find the interrupt setserial thinks
-<tt/ttyS2/ is using. Look at /proc/tty/driver/serial (if you have
-it). You should also be able to see it with the "setserial" command
-for <tt/ttyS2/.
+<tt/ttyS2/ is using. Look at /proc/tty/driver/serial. You should
+also be able to find it with the "setserial" command for <tt/ttyS2/.
Bug in old versions: Prior to 2001 there was a bug which wouldn't let
you see it with "setserial". Trying to see it would give the same
@@ -4773,15 +4826,21 @@ not it's a potential interrupt conflict is to set the IRQ to 0
was likely a potential interrupt conflict. It's not a good idea to
leave it permanently set at 0 since it will put more load on the CPU.
-<sect1> "Input/output error" from setserial or stty
-<p> You may have typed "ttys" instead of "ttyS". You will see this
-error message if you try to use the setserial command for any device
-that is not a serial port. It also may mean that the serial port is
-in use (busy or opened) and thus the attempt to get/set parameters by
-setserial or stty failed. It could also mean that there isn't any
-serial port at the IO address that setserial thinks your port is at.
+<sect1>"Input/output error" from setserial, stty, pppd, etc.
+<p> This means that communication with the serial port isn't working
+right. It could mean that there isn't any serial port at the IO
+address that setserial thinks your port is at. It could also be an
+interrupt conflict (or an IO address conflict). It also may mean that
+the serial port is in use (busy or opened) and thus the attempt to
+get/set parameters by setserial or stty failed. It will also happen
+if you make a typo in the serial port name such as typing "ttys"
+instead of "ttyS".
-<sect1> Overrun errors on serial port
+<sect1>"LSR safety check engaged"
+<p>LSR is the name of a hardware register. It's claimed that this
+means there is no serial port at the specified address.
+
+<sect1>Overrun errors on serial port
<p> This is an overrun of the hardware FIFO buffer and you can't
increase its size. Bug note (reported in 2002): Due to a bug in some
kernel 2.4 versions, the port number may be missing and you will only
@@ -5505,7 +5564,7 @@ system). Such slow (and expensive modems) were later mainly used
for transmitting data between mainframe computers or for connecting a
dumb terminal to a mainframe computer over phone lines. Many dumb
terminals didn't even have a screen display, but printed on paper
-instead.
+what you typed at the keyboard along with responses from the computer.
<sect2> PCs and BBSs
<p>With the advent of the personal computer (PCs) in the early 1980s,
@@ -5513,12 +5572,15 @@ the PC was used like a dumb terminal for connecting to mainframes.
But now files could be transferred and one PC could connect to
another.
-The 1980s saw the rise of the Bulletin Board System (BBS). The public
+The 1980s saw the rise of the Bulletin Board System (BBS). This was
+just a computer with a modem listening for incoming calls. The public
could dial up a BBS with a modem and then downloadable free software,
participate in discussions on various topics, play on-line games, etc.
-It was something like visiting a large Internet site. Many BBSs would
-have a monthly charge but some were run by volunteers and were free.
-Many companies established BBSs for customers that contained support
+Dialing in to a BBS was something like an Internet site. Except that
+to go to another BBS site, you would need to dial another number (and
+possible pay long distance telephone charges). Many BBSs would have a
+monthly charge but some were run by volunteers and were free. Many
+companies established BBSs for customers that contained support
information, catalogs, etc. In the early 1990s, BBSs were booming.
By the mid 1990s some even offered Internet connections. For some
history of BBSs see <url
diff --git a/LDP/howto/linuxdoc/Serial-HOWTO.sgml b/LDP/howto/linuxdoc/Serial-HOWTO.sgml
index 402babf3..74f01bae 100644
--- a/LDP/howto/linuxdoc/Serial-HOWTO.sgml
+++ b/LDP/howto/linuxdoc/Serial-HOWTO.sgml
@@ -4,9 +4,11 @@
<author>David S.Lawyer
<tt><htmlurl url="mailto:dave@lafn.org" name="dave@lafn.org"></tt>
original by Greg Hankins
-<date> v2.16 March 2002
+<date> v2.17 February 2003
<!-- Change log:
+v2.17 Feb. 2003 url signum->cendio, Mac port names, clarity when
+stopping data flow when printing, ide2 address conflict
v2.16 March 2002 fixed a few broken links.
v2.15 November 2001: mention of MIDI ports, problems with lockfiles
for devfs
@@ -80,7 +82,7 @@ other architectures.
<p>
Copyright (c) 1993-1997 by Greg Hankins, (c) 1998-2001 by David S.
Lawyer <url url="mailto:dave@lafn.org">
-<!-- license.H begin -->
+<!-- license.D begin -->
Please freely copy and distribute (sell or give away) this document
in any format. Send any corrections and comments to the document
@@ -91,7 +93,7 @@ provided that you:
<item> If it's not a translation: Email a copy of your derivative work
(in a format LDP accepts) to the author(s) and maintainer (could be
the same person). If you don't get a response then email the LDP
- (Linux Documentation Project): submit@linuxdoc.org.
+ (Linux Documentation Project): submit@en.tldp.org.
<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.
@@ -109,9 +111,9 @@ them. Since this is free documentation, it should be obvious that I
cannot be held legally responsible for any errors.
<sect2>Trademarks.
-<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 -->
+<p> Any brand names (starts with a capital letter such as MS Windows)
+should be assumed to be a trademark). Such trademarks belong to their
+respective owners. <!-- license.D end -->
<sect2>Credits
@@ -128,20 +130,22 @@ half is by David Lawyer. Ted Ts'o has continued to be helpful.
<sect1> New Versions of this Serial-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://www.linuxdoc.org/mirrors.html">.
+sites see: <url url="http://www.tldp.org/mirrors.html">.
Various formats are available. If you only want to quickly check the
date of the latest version look at <url
-url="http://www.linuxdoc.org/HOWTO/Serial-HOWTO.html"> and compare
-it to this version: v2.16 March 2002 . New in recent versions:<newline>
-v2.16 March 2002 fixed a few broken links.
-v2.15 November 2001: mention of MIDI ports, problems with lockfiles
- for devfs
-v2.14 August 2001: major revision of Configuring the Serial Port
-v2.13 August 2001: fixed typos: done->down and "is is", USRT chip,
- synchronous defined better
-v2.12 July 2001: serial printing under LPRng<newline>
-v2.11 May 2001: stty 0 => hangup (was ok in v2.08. )
-v2.10 EIA-485, frame errors on networks, gkermit, firewire
+url="http://www.tldp.org/HOWTO/Serial-HOWTO.html"> and compare
+it to this version: v2.17 February 2003 .
+
+<sect1>New in Recent Versions
+<p> For a full revision history going back to the time I started
+maintaining this HOWTO, see the source file (in linuxdoc format) at
+<url
+url="http://www.ibiblio.org/pub/linux/docs/HOWTO/other-formats/sgml/Serial-HOWTO.sgml.gz">.
+
+v2.18 January 2003: url signum->cendio,
+v2.17 June 2002: Mac port names, clarity when stopping data flow when
+printing, ide2 address conflict<newline>
+v2.16 March 2002 fixed a few broken links<newline>
<sect1> Related HOWTO's re the Serial Port <label id="related_howtos">
<p> Modems, Text-Terminals, some printers, and other peripherals often
@@ -162,6 +166,8 @@ explained above.
configure, and repair them. It includes a section on "Make a
Terminal the Console" which is useful for using a remote terminal to
control a server (via the serial port).
+<item><tt>Remote-Serial-Console-HOWTO</tt> is about making a
+ text-terminal be the console so it can display boot-time messages, etc.
</itemize>
<sect1>Feedback
@@ -176,9 +182,9 @@ Lawyer)</tt>.
<sect1> What is a Serial Port?
<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. It's possible, however, to put a conventional serial port
-device on the USB.
+(Apple Computer) after mid-1998 only have the USB port. It's
+possible, however, to put a conventional serial port device on the
+USB but the ports are expensive.
The common specification for the conventional serial port is RS-232
(or EIA-232). The connector for the serial port is often seen as one
@@ -355,6 +361,7 @@ Sept. '00: data flow diagram
Dec. '00 flow control +
July '01 done -> down
Feb. '02 4k buffer -> 8k
+Feb '03: UARTs with auto flow control. Rewrite of Flow Control.
-->
@@ -367,7 +374,7 @@ name="How the Hardware Transfers Bytes"> but in greater detail.
<sect1> What is a Serial Port ?
<sect2> Intro to Serial
-<p> The serial port is an I/O (Input/Output) device.
+<p> The UART serial port (or just "serial port for short" is an I/O (Input/Output) device.
<!-- ifdef SERIAL_ -->
An I/O device is just a way to get data into and out of a computer.
@@ -478,7 +485,7 @@ 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
+set by jumpers or by plug-and-play software). Thus which 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
@@ -491,18 +498,18 @@ Port Devices /dev/ttyS2, etc."> for more details>
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.
+normally used only by that port. Thus the FIFO waits until it has
+received a number of bytes and then issues an interrupt.
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.
+Thus if the bytes are being received slowly (such as from 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 in an interval of time, 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.
Each interrupt conductor (inside the computer) has a number (IRQ) and
the serial port must know which conductor to use to signal on. For
@@ -511,19 +518,20 @@ 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.
+hold only 16 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.
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.
+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.
+changes state, an interrupt is issued.
The buffers mentioned above are all hardware buffers. The serial port
also has large buffers in main memory. This will be explained later
@@ -567,7 +575,7 @@ be reduced.
<p> Flow control means the ability to slow down the flow of bytes in a
wire. For serial ports this means the ability to stop and then
restart the flow without any loss of bytes. Flow control is needed
-for modems to allow a jump in instantaneous flow rates.
+for modems and other hardware to allow a jump in instantaneous flow rates.
<sect2> Example of Flow Control
<p> For example, consider the case where you connect a 33.6k external
@@ -602,18 +610,19 @@ which is already compressed and can't be compressed further. Now
let's consider the opposite extreme where the modem is compressing the
data with a high compression ratio. In such a case the modem might
need an input flow rate of say 115.2k bps to provide an output (to the
-phone line) of 33.6k bps (compressed data). The compression ratio is
-3.43 (115.2/33.6) which is much higher than average. In this case the
-modem is able to compress and the 115.2 bps PC-to-modem flow and send
-the same data out on the phone line at 33.6bps. There's no need for
-flow control here. But such a high compression ratio rarely happens
-so that most of the time flow control is needed to slow down the flow
-on the 115.2 bps PC-to-modem cable. The flow is stopped and started
-so that the average flow is usually well under the "on" flow of 115.2
-bps.
+phone line) of 33.6k bps (compressed data). This compression ratio is
+3.43 (115.2/33.6). In this case the modem is able to compress and
+the 115.2 bps PC-to-modem flow and send the same data (in compressed
+form) out the phone line at 33.6bps. There's no need for flow control
+here so long as the compression ratio remains higher that 3.43. But
+the compression ratio varies from second to second and is likely to
+drops below 3.43. Thus, some of the time flow control is needed to
+slow down the average flow on the 115.2 bps PC-to-modem cable. The
+flow is stopped and started so that the average flow is usually lower
+than the "on" flow of 115.2 bps.
In the above example the modem was an external modem. But the same
-situation exists (as of late 2000) for most internal modems. There is
+situation exists (as of early 2003) for most internal modems. There is
still a speed limit on the PC-to-modem speed even though this flow
doesn't take place over an external cable. This makes the internal
modems compatible with the external modems.
@@ -623,13 +632,17 @@ 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.
+serial driver. Flow control protects all buffers (except the FIFOs)
+from overflowing.
+
+Under Linux, the small UART FIFO buffers are not protected in this way
+but rely instead on a fast response to the interrupts they issue.
+Some UART chips can be set to do hardware flow control to protect
+their FIFOs but Linux (as of early 2003) doesn't seem to support it.
+FIFO stand for "First In, First Out" which is the way it handles bytes
+in a queue. All the 3 buffers use the FIFO rule but only one of them
+is named "FIFO". This is the essence of flow control but there
+are still some more details.
@@ -646,8 +659,24 @@ contiguous chunks.
<sect2> Hardware vs. Software Flow Control
<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.
+signals. Hardware flow control at the serial port works like this:
+The two pins, RTS (Request to send) and CTS (Clear to send) are used.
+When the computer is ready to receive date it asserts RTS by putting a
+positive voltage on the RTS pin (meaning "request to send to me").
+When the computer is not able to receive any more bytes, it negates
+RTS by putting a negative voltage on the pin saying: "stop sending to
+me". The RTS pin is connected by the serial cable to another pin on
+the modem, printer, terminal, etc. This other pin's only function is
+to receive the signal.
+For the case of a modem this "other" pin will be the modem's RTS pin
+(same pin label as the PC). But for a printer or terminal, it will be
+a CTS pin and requires "crossover" or "null modem" cable so as to
+connect the CTS pin at one end with the RTS pin at the other end. For
+a modem, a straight-thru cable is used. For the opposite direction of
+flow a similar scheme is used. For a modem, the CTS pin is used to
+send the flow control signal and the RTS pin a receive it. For a
+non-modem, the roles of the RTS and CTS pins are interchanged.
Software flow control uses the main receive and transmit wires to send
the start and stop signals. It uses the ASCII control characters DC1
@@ -661,50 +690,53 @@ code. Likewise for DC1.
<sect1> Data Flow Path; Buffers
-<p> Much has been explained about this including flow
-control, a pair of 16-byte FIFO buffers (in the UART), and a pair of
-larger buffers inside a device connected to the serial port (such as a
-modem. But there is still another pair of buffers. These are large
-buffers (perhaps 4k) 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. Here's an example
-diagram for the case of browsing the Internet with a browser.
-Transmit data flow is left to right while receive flow is right to
-left.
+<p>It's been mention that there are 3 buffers for each direction of
+flow (3 pairs altogether): 16-byte FIFO buffers (in the UART), a pair
+of larger buffers inside a device connected to the serial port (such
+as a modem), and a pair of buffers (say 8k) in main memory.
+When an application program sends bytes to the serial port they first
+get stashed in the transmit serial port buffer in main memory. The
+pair consists of both the transmit buffer and a receive buffer for
+the opposite direction of byte-flow. Here's an example diagram for
+the case of browsing the Internet with a browser. Transmit data flow
+is left to right while receive flow is right to left. There is a
+separate buffer for each direction of flow.
<verb>
-application 4k-byte 16-byte 1k-byte tele-
-BROWSER ------- MEMORY -------- UART --------- MODEM -------- phone
+application 8k-byte 16-byte 1k-byte tele-
+BROWSER ------- MEMORY -------- FIFO --------- MODEM -------- phone
program buffer buffer buffer line
</verb>
-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 UART for transmission. Once in that transmit buffer, there
-is no way to stop them from being transmitted. They are then
-transmitted to the modem or other 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 4k transmit buffer until it becomes
-fill.
+For the transmit case, the serial device driver takes out say 16 bytes
+from this transmit buffer (in main memory), one byte at a time and
+puts them into the 16-byte transmit buffer in the serial UART for
+transmission. Once in that transmit buffer, there is no way to stop
+them from being transmitted. They are then transmitted to the
+modem or (other 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 modem has stopped, an application program may keep sending
+bytes to the 8k transmit buffer until it becomes fill. At the same
+time, the bytes stored in the FIFO and MODEM continue to be sent out
+until these buffers empty.
-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".
+When the memory buffer 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 since it may switch to running other processes while it's
+waiting at a flow control stop.
+
+The above was a little oversimplified in two ways. First, some UARTs
+can do automatic hardware flow control which can stop the transmission
+out of the FIFO buffers if needed (not yet supported by Linux).
+Second, while an application process is waiting to write to the
+transmit buffer, it could possibly perform other tasks.
@@ -712,17 +744,18 @@ while it is waiting to "write".
<sect1> Complex Flow Control Example
<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.
+text-terminal connected to a PC with a modem to access a BBS (Bulletin
+Board System). 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.
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"
@@ -730,15 +763,15 @@ 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 4k serial buffer (in main
+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 4k buffer.
+the terminal into this 8k buffer.
-When this 4k transmit buffer (on the first serial port) is full,
+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 4k receive buffer on the
+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 4k buffer too fills up and sends a different "stop" to the
+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
@@ -747,11 +780,11 @@ 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.
-Thus a stop signal from a text terminal has halted a programs on a BBS
+Thus a stop signal from a text terminal has halted a program 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 4k one and the hardware 16-byte one. The application
+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.
@@ -790,7 +823,7 @@ happened there, bytes intended for the hard-disk were lost.
<sect1> Serial Driver Module
<p> The device driver for the serial port is the software that
operates the serial port. It is now provided as a serial module.
->From kernel 2.2 on, this module will normally get loaded automatically
+From kernel 2.2 on, this module will normally get loaded automatically
if it's needed. 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
@@ -1061,6 +1094,8 @@ support for them into the kernel.<newline>
<item>Moxa C104, Moxa C104+ (AST FourPort compatible) *
<item><url
url="http://digital.natinst.com/manuals.nsf/web%2Fbyproductcurrent?OpenView&Start=1&Count=500&Expand=15.1#15.1" name="NI-SERIAL"> by National Instruments
+<item>NetBus (2 ports)<url url="http://www.netbus.com"> using patch from
+<url url="http://lists.insecure.org/linux-kernel/2001/Feb/2809.html">
<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)
@@ -1152,14 +1187,14 @@ driver status: for 2.2 kernel. Supported by Chase.
<item>Decision PCCOM (2-8 ports; ISA and PCI; aka PC COM)<newline>
ISA:<newline>
contact: <tt><url url="mailto:info@cendio.se"></tt><newline>
- driver location: (dead link) <tt><htmlurl url="ftp://ftp.signum.se/pub/pccom8"
- name="ftp://ftp.signum.se/pub/pccom8"></tt><newline>
+ driver location: (dead link) <tt><htmlurl url="ftp://ftp.cendio.se/pub/pccom8"
+ name="ftp://ftp.cendio.se/pub/pccom8"></tt><newline>
PCI:<newline>
drivers: <url url="http://www.decision.com.tw"><newline>
driver status: Support in serial driver 5.03. For an earlier driver,
there exists a patch for kernel 2.2.16 at <url
url="http://www.qualica.com/serial/"> and for kernels 2.2.14-2.2.17
- at<url url="htp://www.pccompci.com/mains/installing_pci_linux1.html">
+ at<url url="http://www.pccompci.com/mains/installing_pci_linux1.html">
<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>
@@ -1316,6 +1351,9 @@ See the section <ref id="stty_" name="Stty">
Change-log:
Aug. 2001: removed mention of patch to convert Linux to a PnP OS;
better explanation of PCI
+July 2001: Improve PCI part. Remove "card" since serial ports are
+often built into the motherboard.
+Feb. 2003: Removed request to send info to Ted Tso.
-->
<sect1> IO & IRQ Overview
@@ -1328,24 +1366,33 @@ a serial port card. Today it's set by digital signals sent to the
hardware and this is part of "Plug-and-Play (PnP).
The driver must also know both the IO address and IRQ so that it can
-locate the card. Modern drivers (kernel 2.4) determine this by PnP
-methods so one doesn't need to tell them (by using "setserial"). The
-driver uses PnP functions provided by Linux to determine what the IO
-and IRQ are and to set them if necessary. The driver also probes
-possible serial port addresses to see if there are any serial ports
-there. This works for the case of jumpers and sometimes works for a
-PnP port when the driver doesn't do PnP.
+locate the port chip. Modern serial port drivers (kernel 2.4) try to
+determine this by PnP methods so one doesn't need to tell them (by
+using "setserial"). Such a driver might also set an IO address or
+enable the hardware. But unfortunately, there is some PCI serial port
+hardware that the driver doesn't recognize so you may need to enable
+the port yourself. See <ref id="pci_enabled" name="PCI: Enabling a
+disabled port">
+
+The driver also probes possible ISA serial port addresses to see if
+there are any serial ports there. This works for the case of jumpers
+and sometimes works for a PnP port when the driver doesn't do PnP
+(prior to kernel 2.4).
Locating the serial port by giving it an IRQ and IO address is
-low-level configuring. What follows repeats what was said above in
-more detail. This low-level configuring consists of assigning 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 could call
-this "io-irq" configuring for short. The "setserial" program is one
-way to tell the driver. The other way is for the driver to use PnP
-methods to determine/set the IO/IRQ and then remember what it did.
-For jumpers you must always use "setserial". If you need to configure
-but don't understand certain details it's easy to get into trouble.
+low-level configuring. It's often automatically done by the serial
+driver but sometimes you have to do it yourself. What follows repeats
+what was said above but in more detail.
+
+The low-level configuring consists of assigning 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. Only the driver needs to know
+the name.We could call this "io-irq" configuring for short. The
+"setserial" program is one way to tell the driver. The other way is
+for the driver to use PnP methods to determine/set the IO/IRQ and then
+remember what it did. For jumpers you must always use "setserial".
+If you need to configure but don't understand certain details it's
+easy to get into trouble.
When Linux starts, some effort is made to detect and configure
(low-level) a few serial ports. Exactly what happens depends on your
@@ -1363,25 +1410,25 @@ then you need to do it if you:
For kernel 2.2+ you may be able to use more that 2 serial ports
without doing any low-level configuring by sharing interrupts. All
-PCI cards should support this but for ISA it only works for some
+PCI ports should support this but for ISA it only works for some
hardware. It may be just as easy to give each port a unique interrupt
if they is available. See <ref id="int_share-2.2" name="Interrupt
sharing and Kernels 2.2+">
The low-level configuring (setting the IRQ and IO address) seems to
-cause people more trouble than the high-level, although for many it's
-fully automatic and there is no configuring to be done. Until the
-serial driver knows the correct IRQ and IO address, the port will not
-usually not work at all. Also, PnP ports can be disabled so that they
-can't be found (except with PnP tools). Applications, and utilities
-such as "setserial" and "scanport" don't use PnP tools and thus can't
-detect disabled ports. For example, an IO enabling bit must be set in
-PCI serial port hardware by PnP so that it's IO address may be used.
+cause people more trouble than the high-level stuff, although for many
+it's fully automatic and there is no configuring to be done. Until
+the serial driver knows the correct IRQ and IO address, the port will
+not usually not work at all. Also, PnP ports can be disabled so that
+they can't be found (except with PnP tools such as lspci).
+Applications, and utilities such as "setserial" and "scanport" (Debian
+only ??) don't use PnP tools and thus can't detect
+disabled ports.
-Even if the port can be found by normal (non-PnP) software, it may
-work extremely slow if the IRQ is wrong. See <ref id="slow_"
+Even if an ISA port can be found by the probing of the serial driver
+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">.
+delays">. PCI ports are less likely to get the IRQ wrong.
In the Wintel world, the IO address and IRQ are called "resources" and
we are thus configuring certain resources. But there are many other
@@ -1393,32 +1440,33 @@ address) into two places:
<enum>
<item> the device driver (often by running "<tt/setserial/" at
boot-time)
-<item> memory registers of the serial port hardware itself
+<item> configuration registers of the serial port hardware itself
</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
-the ones that look like "setserial" output don't show the true
-configuration of the hardware (and they are not necessarily supposed
-to). See <ref id="boot_mesgs" name="I/O Address & IRQ: Boot-time
-messages">.
+correct. But if you're having problems, your serial port may not show
+up at all or if you do see a message from "setserial" it may not
+show the true configuration of the hardware (and it is not necessarily
+supposed to). See <ref id="boot_mesgs" name="I/O Address & IRQ:
+Boot-time messages">.
<sect1> PCI Bus Support <label id="PCI_ser_conf">
+<sect2>Introduction
<p>
If you have kernel 2.4, then there should be support for PnP (either
-built-in or by modules). Some PCI serial cards can be automatically
-detected and low-level configured by the serial driver. Others will
+built-in or by modules). Some PCI serial ports can be automatically
+detected and low-level configured by the serial driver. Others may
not be.
Kernel 2.2 had no support for PCI serial ports (although some people
got them working anyway). The 2.4 serial driver will read the id
-number digitally stored on the serial hardware to determine how to
-support it (if it knows how). It should assign the I/O address to it,
-determine it's IRQ, etc. So you don't need to use "setserial" for it
-??
-
-If you have a
+number digitally stored in the serial hardware to determine how to
+support it (if it knows how). It should assign an I/O address to it,
+determine it's IRQ, etc. So you don't need to use "setserial" for it.
+<!--
+<sect2> Requesting that future drivers support your serial port
+<p>If you have a
PCI modem card you should be looking at Modem-HOWTO and not this
Serial-HOWTO. If you just have a PCI serial port card (with no modem
@@ -1439,8 +1487,9 @@ 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">.
-
-PCI ports are not well standardized. Some use main memory for
+-->
+<sect2>More info on PCI
+<p>PCI ports are not well standardized. Some use main memory for
communication with the PC. Some require special enabling of the IRQ.
The output of "lspci -vv" can help determine if one can be supported.
If you see a 4-digit IO port, the port might work by just telling
@@ -1620,9 +1669,9 @@ view it.
by PnP methods. Even if nothing has been set or the port disabled,
PnP ports may still be found by using "lspci -v" or "isapnp
--dumpregs". Ports disabled by jumpers (or hardware failures) are
-lost. See <ref id="isa_pnp_dump" name="ISA PnP ports">,
+completely lost. See <ref id="isa_pnp_dump" name="ISA PnP ports">,
<ref id="pci_io_irq" name="PCI: What IOs and IRQs have been set?">,
-<ref id="pci_enabled" name="PCI: Is the port enabled?">
+<ref id="pci_enabled" name="PCI: Enabling a disabled port">
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
@@ -1633,29 +1682,48 @@ likely to be found in a disabled state than an old non-PnP one.
<p> For PCI, the BIOS almost always sets the IRQ and may set the IO
address as well. To see how it's set use "lspci -vv" (best) or look
in /proc/bus/pci (or for kernels <2.2 /proc/pci). The modem's
-serial port is often called a "Communication controller". If more
-than one IO address is shown, the first one is more likely to be it.
-You can't change the IRQ (at least not with "setpci") This is
-because if one writes it in it's hardware register no action is taken
-on it. It's the BIOS that should actually set up the IRQs and then
-write the correct value to this register for lspci to view. If you
-must, change the IO address with "setpci" by changing the
-BASE_ADDRESS_0 or the like. The _0 (or _1) after BASE_ADDRESS must be
-the correct register.
+serial port is often called a "Communication controller". Look for
+this. If lspci shows "I/O ports at ... [disabled]" then the serial
+port is disabled and the hardware has no IO address so it's lost and
+can't be used. See <ref id="pci_enabled" name="PCI: Enabling a
+disabled port"> for how to enable it.
-<sect2> PCI: Is the port enabled? <label id="pci_enabled">
-<p>If the port communicates via an IO address "then lspci -vv" should
+If more than one IO address is shown, the first one is more likely to
+be it. You can't change the IRQ (at least not with "setpci") This
+is because if one writes an IRQ it it's hardware register no action is
+taken on it. It's the BIOS that should actually set up the IRQs and
+then write the correct value to this register for lspci to view. If
+you must, change the IO address with "setpci" by changing the
+BASE_ADDRESS_0 or the like.
+
+<sect2> PCI: Enabling a disabled port <label id="pci_enabled">
+<p>If the port communicates via an IO address then "lspci -vv" should
show "Control: I/O+ ..." with + meaning that the IO address is
-enabled. If it shows "I/O-" then you may need to use the setpci
-command to enable it. For example "setpci -d 151f:000 command=101".
-The "command" means the command register which is the same as the
-"Control" register displayed by lspci. The 101h sets two bits: the 1
-sets I/O to + and the 100 part keeps SERR# set to +. In this case
-only the SERR# bit of the Control register was initially observed to
-be + when the lspci command was run. So we kept it enabled to + by
-setting bit 8 (where bit 0 is I/O) to 1 by the first 1 in 101. My
-apologies if setting bits is confusing. Bit 8 is actually the 9th bit
-since we started counting bits from 0.
+enabled. If it shows "I/O-" (and "I/O ports at ... [disabled]") then
+you may need to use the setpci command to enable it. For example
+"setpci -d 151f:000 command=101". 151f is the vendor id, and 000 is
+the device id both obtained from "lspci -n -v" or from /proc/bus/pci
+or from "scanpci -v". The "command=101" means that 101 is put into
+the command register which is the same as the "Control" register
+displayed by "lspci". The 101h sets two bits: the 1 sets I/O to + and
+the 100 part keeps SERR# set to +. In this case only the SERR# bit
+of the Control register was initially observed to be + when the lspci
+command was run. So we kept it enabled to + by setting bit 8 (where
+bit 0 is I/O) to 1 by the first 1 in 101. Some serial cards don't use
+SERR# so if you see SERR#- then there's no need to enable it so then
+use: command=1. Then you'll need to set up "setserial" to tell the
+driver the IO and IRQ.
+
+Bit 8 is actually the 9th bit since we started counting bits from 0.
+Don't be alarmed that lspci shows a lot of - signs showing that the
+card doesn't have many features available (or enabled). Serial ports
+are relatively slow and don't need these features.
+
+Another way to enable it is to let the BIOS do it by telling the BIOS
+that you don't have a plug-and-play operating system. Then the BIOS
+should enable it when you start your PC. If you have MS Windows9x on
+the same PC then doing this might cause problems with Windows (see
+Plug-and-Play-HOWTO).
<sect2>ISA PnP ports <label id="isa_pnp_dump">
<p>For an ISA Plug-and-Play (PnP) port one may try the <tt/pnpdump/
@@ -1670,14 +1738,15 @@ communicating with PnP cards.
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 setpci can. Starting with kernel 2.4, these
-are built into the serial driver.
+change it but isapnp or setpci can. Starting with kernel 2.4, the
+serial driver can make such changes for many (but not all) serial
+ports.
-Using "scanport" will probe all I/O ports and will indicate what it
-thinks may be serial port. After this you could try probing with
-setserial using the "autoconfig" option. You'll need to guess the
-addresses to probe at (using clues from "scanport"). See <ref
-id="set_serial" name="What is Setserial">.
+Using "scanport" (Debian only ??) will probe all I/O ports and will
+indicate what it thinks may be serial port. After this you could try
+probing with setserial using the "autoconfig" option. You'll need to
+guess the addresses to probe at (using clues from "scanport"). See
+<ref id="set_serial" name="What is Setserial">.
For a port set with jumpers, the IO ports and IRQs are set per the
jumpers. If the port is not Plug-and-Play (PnP) but has been setup by
@@ -1977,6 +2046,7 @@ interface and makes it easy to deal with a huge number of devices.
The device names have all changed as well. But there's an option to
continue using the old names. For a detailed description of it see:
<url url="http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html">
+Also see the kernel documentation tree: filesystems/devfs.
The name changes (if used) are: ttyS2 becomes tts/2 (Serial port),
tty3 becomes vc/3 (Virtual Console), ptyp1 becomes pty/m1 (PTY
@@ -1993,26 +2063,26 @@ in the /dev directory.
There formerly was a "cua" name for each serial port and it behaved
just a little differently. For example, ttyS2 would correspond to
-cua2. The cua major number was 5 and minor numbers started at 64.
-You may still have the cua devices in your /dev directory but they are
-now deprecated. Their drivers behave slightly different than for the
-ttyS ones. name="cua Device Obsolete">."') See the Modem-HOWTO section: "cua Device
- Obsolete">.
+cua2. It was mainly used for modems. The cua major number was 5 and
+minor numbers started at 64. You may still have the cua devices in
+your /dev directory but they are now deprecated. For details see
+Modem-HOWTO, section: cua Device Obsolete.
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). The major/minor numbers don't exist with the devfs.
+different). The major/minor numbers don't exist with the devfs. For
+the PCI bus the IO addresses are different.
-<tscreen><verb>
+<verb>
ISA IO devfs usb
dos major minor address devfs devfs usb acm modem
COM1 /dev/ttyS0 4, 64; 3F8 /dev/tts/0 /dev/usb/tts/0 /dev/usb/acm/0
COM2 /dev/ttyS1 4, 65; 2F8 /dev/tts/1 /dev/usb/tts/1 /dev/usb/acm/1
COM3 /dev/ttyS2 4, 66; 3E8 /dev/tts/2 /dev/usb/tts/2 /dev/usb/acm/2
COM4 /dev/ttyS3 4, 67; 2E8 /dev/tts/3 /dev/usb/tts/3 /dev/usb/acm/3
-</verb></tscreen>
+</verb>
<sect1> USB (Universal Serial Bus) Ports
<p>The serial ports on the USB are: /dev/ttyUSB0, /dev/ttyUSB1, etc.
@@ -2181,6 +2251,7 @@ May 2000: <sect2> IRQs near end ttyS0 -> ttyS1 + clarity
Nov. 2000: auto_irq may work on the 2nd try
Dec. 2000: saving state of serial module
June 2001 OK to use setserial with Laptops
+Nov. 2002 Debian's /var/lib/serial.conf
-->
<p> This part is in 3 HOWTOs: Modem, Serial, and Text-Terminal. There
are some minor differences, depending on which HOWTO it appears in.
@@ -2266,14 +2337,15 @@ 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. They will also be officially
registered with the kernel as displayed (at the top of the screen) by
-the "scanport" command. Of course the serial port driver will not
-work correctly (if at all) if you attempt to use such a port. Thus
-when giving parameters to "setserial" anything goes. Well almost. If
-you assign one port a base address that is already assigned (such as
-3e8) it will not accept it. But if you use 3e9 it will accept it.
-Unfortunately 3e9 is already assigned since it is within the range
-starting at base address 3e8. Thus the moral of the story is to make
-sure your data is correct before assigning resources with setserial.
+the "scanport" command (Debian). Of course the serial
+port driver will not work correctly (if at all) if you attempt to use
+such a port. Thus when giving parameters to "setserial" anything
+goes. Well almost. If you assign one port a base address that is
+already assigned (such as 3e8) it may not accept it. But if you use
+3e9 it will accept it. Unfortunately 3e9 is already assigned since it
+is within the range starting at base address 3e8. Thus the moral of
+the story is to make sure your data is correct before assigning
+resources with setserial.
While assignments made by setserial are lost when the PC is powered
off, a configuration file may restore them (or a previous
@@ -2287,10 +2359,11 @@ name="Configuration Scripts/Files">
<sect2> Probing <label id="probing_ss">
<p>Prior to probing with "setserial", one may run the "scanport"
-command to check all possible ports in one scan. It makes crude
-guesses as to what is on some ports but doesn't determine the IRQ. But
-it's a fast first start. It may hang your PC but so far it's worked
-fine for me.
+(Debian) command to check all possible ports in one scan. It makes
+crude guesses as to what is on some ports but doesn't determine the
+IRQ. But it's a fast first start. It may hang your PC but so far
+it's worked fine for me. Note that non-Debian distributions don't
+seem to supply "scanport". Is there an another scan program?
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
@@ -2317,14 +2390,15 @@ IRQ's but this doesn't always work right either. In one case it first
gave the wrong irq but when the command was repeated it found the
correct irq. In versions of setserial >= 2.15, the results of your
last probe test could be automatically 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 data someone wrote into the script
-or data that got saved in /etc/serial.conf.
+configuration file <tt>/etc/serial.conf</tt> or
+<tt>/var/lib/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 data someone wrote into the script or data that
+got saved in /etc/serial.conf.
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
@@ -2652,7 +2726,7 @@ way to stop the hang.
One way to try to get out of the above hang is to use the newer -F
option and set "clocal" and/or "crtscts" as needed. If you don't have
-the -F option then you may try to run some program (such a minicom) on
+the -F option then you may try to run some program (such as minicom) 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
@@ -2768,6 +2842,7 @@ uses the serial port. See <ref id="stty_" name="Stty">
<sect1> Can't Set a High Enough Speed
<!-- high_speed.H begin In Serial and Modem HOWTOs but some of the speed
section is unique to each HOWTO.
+Feb. 2003,
-->
<sect2> Speeds over 115.2k
<p> The top speed of 115.2k has been standard since the mid 1990's.
@@ -2776,23 +2851,30 @@ But by the year 2000, most new serial ports supported higher speeds of
seldom uses these speeds due to lack of drivers. Thus such ports
behave just like 115.2k ports unless the higher speeds are enabled by
special software. To get these speeds you need to compile the kernel
-with special patches but it seems that the 2.4 kernels are not yet
-supported
+with special patches until support is built into the kernel's serial
+driver.
-The patch software is fairly simple since it only needs to enable the
-higher speeds by dialog with the hardware. But it's not quite as
-simple as just putting an enable byte in a hardware register since the
-registers weren't designed for this. But unfortunately, there is no
-standard way to enable the higher speeds so the serial driver needs to
-support a variety of hardware.
+Unfortunately serial port manufacturers never got together on a
+standard way to support high speeds, so the serial driver needs to
+support a variety of hardware. Once high speed is enabled, a standard
+way to choose it is to set baud_base to the highest speed with
+setserial (unless the serial driver does this for you). The software
+will then use a divisor of 1 to set the highest speed. All this will
+hopefully be supported by the Linux kernel sometime in 2002.
-A patch to support high-speed is called shsmod (Super High Speed
-Mode). There are both Windows and Linux versions of this patch. See
-<url url="http://www.devdrv.com/shsmod/">. For Linux (as of late
-2001), most of the documentation is only in Japanese and the patch is
-for the old kernel 2.2.x. There is also a module for the VIA
-VT82C686 chip <url url="http://www.kati.fi/viahss/">. Using it may
-result in buffer overflow.
+A non-standard way that some manufacturers have implemented high speed
+is to use a very large number for the divisor to get the high speed.
+This number isn't really a divisor at all since it doesn't divide
+anything. It's just serves as a code number to tell the hardware what
+speed to use. In such cases you need to compile the kernel with
+special patches.
+
+One patch to support this second type of high-speed hardware is called
+shsmod (Super High Speed Mode). There are both Windows and Linux
+versions of this patch. See <url
+url="http://www.devdrv.com/shsmod/">. There is also a module for the
+VIA VT82C686 chip <url url="http://www.kati.fi/viahss/">. Using it
+may result in buffer overflow.
For internal modems, only a minority of them advertise that they
support speeds of over 115.2k for their built-in serial ports.
@@ -2801,7 +2883,7 @@ Does shsmod support these ??
<sect2> How speed is set in hardware: the divisor and baud_base <label
id="divisor_">
<p> Speed is set by having the serial port's clock change frequency.
-But this change happens not by acutally changing the frequency of the
+But this change happens not by actually changing the frequency of the
oscillator driving the clock but by "dividing" the clock's frequency.
For example, to divide by two, just ignore every other clock tick.
This cuts the speed in half. Dividing by 3 makes the clock run at 1/3
@@ -3086,23 +3168,28 @@ specialty item and are expensive if purchased new.
<sect1> Stopping the Data Flow when Printing, etc.
<p> Normally flow control and/or application programs stop the flow of
-bytes when its needed. But sometimes they don't. One example is
-printing to printer on the serial port. If you want to instantly stop
-printing you may try turning off the printer. With older versions of
-the serial driver, the printer would attempt to resume printing if you
-turned the printer back on again (before the time specified by
-closing_wait of setserial had expired). The attempt to resume would
-happen even if you used a command to stop the printing. The problem
-was that once the printer software sent bytes to the large serial
-buffer to be printed, these bytes were not removed from this buffer
-when the print job was canceled. One way to remove them (for newer
-serial drivers) is to simply turn off the printer. This will drop all
-modem control signals from the printer and empty the buffer. Modern
-printers have large buffers and often a button on the printer to empty
-the buffer.
+bytes when its needed. But sometimes they don't. The problem is that
+output to the serial port first passes thru the large serial buffer
+in the PC's main memory. So if you want to abort printing, whatever is
+in this buffer should be removed. When you tell an application program
+to stop printing, it may not empty this buffer so printing continues
+until it's empty. In addition, your printer has it's own buffer which
+needs to be cleared. So telling the PC to stop printing may not work
+due to these two buffers that continue to supply bytes for the printer.
+It's a problem with printer software not knowing about the serial port
+and that modem control lines need to be dropped to stop the printer.
-<sect1> Known Defective Hardware
-<sect2> Avoiding IO Address Conflicts with Certain Video Boards <label
+One way to insure that printing stops is to just turn off the printer.
+With newer serial drivers, this works OK. The buffers are cleared and
+printing doesn't resume. With older serial drivers, the PC's serial
+buffer didn't clear and it would sometimes continue to print when the
+printer was turned back on. To avoid this, you must wait a time
+specified by setserial's closing_wait before turning the printer back
+on again. You may also need to remove the print job from the print
+queue so it won't try to resume.
+
+<sect1>Known IO Address Conflicts
+<sect2>Avoiding IO Address Conflicts with Certain Video Boards <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
@@ -3113,7 +3200,14 @@ 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.
+<sect2>IO address conflict with ide2 hard drive
+<p>The address of ttyS2 is 3e8-3ef while hard drive ide2 uses 3ee
+which is in this range. So when booting Linux you may see a report
+of this conflict. Most people don't use ide2 (the 3rd hard drive
+cable) and may ignore this conflict message. You may have 2 hard
+drives on ide0 and two more on ide1 so most people don't need ide2.
+<sect1> Known Defective Hardware
<sect2> Problem with 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
@@ -3150,16 +3244,16 @@ LED lamps which light when certain modem control lines are asserted
signal (positive or negative voltage). Still others have jumpers so
that you can connect any wire to any wire. Some have switches.
-Radio Shack sells (in 2001) a "RS-232 Troubleshooter" (formerly called
-"RS-232 Line Tester") Cat. #276-1401. It 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" Cat.
+Radio Shack sells (in 2002) a "RS-232 Troubleshooter" (formerly called
+"RS-232 Line Tester") Cat. #276-1401. It 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" Cat.
#276-1403. This permits connecting the pins anyway you choose. Both
these items are under the heading of "Peripheral hookup helpers".
Unfortunately, they are not listed in the index to the printed
-catalog. They are on the same page as the D type connecters so
-look in the index under "Wire & Cable, Connectors. Or look
-under "Tools, D-Sub Connection Pin ...". A store chain named "Active Component
+catalog. They are on the same page as the D type connecters so look
+in the index under "Connectors, Computer, D-Sub". A store chain named
+"Active Components" may have them.
<sect2> Measuring voltages
<p> Any voltmeter or multimeter, even the cheapest that sells for
@@ -3211,28 +3305,38 @@ Nov. '00: which connector is ttyS1, etc. Input/output error, overrun
error link
Dec. '00: /proc/tty/driver/serial shows info, I/O error+, pid 161 in
example n.g.
+July '02: typo: is doesn't => it doesn't, clarity re port not found
+Dec. '02: IO error may mean IRQ conflict or IO address conflict.
+Jan. '03: LSR safety check error
+Feb. '03: Interrupts may be shared on PCI Bus
-->
<sect1>(The following subsections are in both the Serial and Modem HOWTOs)
<sect1> My Serial Port is Physically There but Can't be Found
<label id="cant_find_port">
-<p> If a physical device (such as a modem) doesn't work at all it may
-mean that the device is not at the I/O address that setserial
-thinks it's at. It could also mean (for a PnP card) that is doesn't
-yet have an address. Thus it can't be found.
+<p> If a physical device (such as a modem) doesn't work at all it's
+often because it's disabled and has no address (PnP hasn't enabled it)
+or that it is enabled but is not at the I/O address that setserial
+thinks it's at. Thus it can't be found.
-Check the BIOS menus and BIOS messages. For the PCI bus use lspci or
-scanpci. 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">. Use <tt>setserial -g</tt> to
-see what the serial driver thinks and check for IRQ and I0 address
+First check BIOS messages at boot-time (and possible the BIOS menu for
+the serial port). For the PCI bus use lspci or scanpci. If it's an
+ISA bus PnP serial port, try "pnpdump --dumpregs" and/or see
+Plug-and-Play-HOWTO. If the port happens to be enabled then the
+following two paragraphs may help find it:
+
+For a non-PnP ISA legacy port, using "scanport" (Debian only ??) will
+scan all 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">. Use <tt>setserial -g</tt>
+to see what the serial driver thinks and check for IRQ and I0 address
conflicts. Even if you see no conflicts the driver may have incorrect
-information (view it by "setserial" and conflicts may still exist.
+information (view it by "setserial") and conflicts may still exist.
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
@@ -3310,14 +3414,14 @@ will only make things worse.
<sect1>The Startup Screen Show Wrong IRQs for the Serial Ports.
<label id="irqs_shown_wrong">
-<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> For non-PnP ports, 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.
So, even though I have my <tt/ttyS2/ set at IRQ 5, I still see
<tscreen><verb>
@@ -3381,25 +3485,27 @@ have been automatically removed if it contained a stale process id
<sect1> "/dev/tty? Device or resource busy" <label id="busy_err">
<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 (the resource is "busy").
+is supposedly being used by another device and can't be shared.
This message is easy to understand if it only means that the device is
-busy (in use). But it often means that a resource is in use. What
-makes it even more confusing is that in some cases neither the device
-nor the resources that it needs are actually "busy".
+busy (in use). But it often means that a needed resource is already
+in use (busy). What makes it even more confusing is that in some cases
+neither the device nor the resources that it needs are actually
+"busy".
-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
-"... busy" error message. This is because the kernel only keeps track
-of what IRQs are actually in use and actual conflicts don't happen
-unless the devices are in use (open). The situation for I/O address
-(such as 0x3f8) conflict is similar.
+The following example is where interrupts can't be shared (at least
+one of the interrupts is on the ISA bus). 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 "... busy" error message. This is because the
+kernel only keeps track of what IRQs are actually in use and actual
+conflicts don't happen unless the devices are in use (open). The
+situation for I/O address (such as 0x3f8) conflict is similar.
This error is sometimes due to having two serial drivers: one a module
and the other compiled into the kernel. Both drivers try to grab the
@@ -3413,9 +3519,8 @@ There are two possible cases when you see this message:
</enum>
What you need to do is to find the interrupt setserial thinks
-<tt/ttyS2/ is using. Look at /proc/tty/driver/serial (if you have
-it). You should also be able to see it with the "setserial" command
-for <tt/ttyS2/.
+<tt/ttyS2/ is using. Look at /proc/tty/driver/serial. You should
+also be able to find it with the "setserial" command for <tt/ttyS2/.
Bug in old versions: Prior to 2001 there was a bug which wouldn't let
you see it with "setserial". Trying to see it would give the same
@@ -3437,15 +3542,21 @@ not it's a potential interrupt conflict is to set the IRQ to 0
was likely a potential interrupt conflict. It's not a good idea to
leave it permanently set at 0 since it will put more load on the CPU.
-<sect1> "Input/output error" from setserial or stty
-<p> You may have typed "ttys" instead of "ttyS". You will see this
-error message if you try to use the setserial command for any device
-that is not a serial port. It also may mean that the serial port is
-in use (busy or opened) and thus the attempt to get/set parameters by
-setserial or stty failed. It could also mean that there isn't any
-serial port at the IO address that setserial thinks your port is at.
+<sect1>"Input/output error" from setserial, stty, pppd, etc.
+<p> This means that communication with the serial port isn't working
+right. It could mean that there isn't any serial port at the IO
+address that setserial thinks your port is at. It could also be an
+interrupt conflict (or an IO address conflict). It also may mean that
+the serial port is in use (busy or opened) and thus the attempt to
+get/set parameters by setserial or stty failed. It will also happen
+if you make a typo in the serial port name such as typing "ttys"
+instead of "ttyS".
-<sect1> Overrun errors on serial port
+<sect1>"LSR safety check engaged"
+<p>LSR is the name of a hardware register. It's claimed that this
+means there is no serial port at the specified address.
+
+<sect1>Overrun errors on serial port
<p> This is an overrun of the hardware FIFO buffer and you can't
increase its size. Bug note (reported in 2002): Due to a bug in some
kernel 2.4 versions, the port number may be missing and you will only
@@ -3718,7 +3829,7 @@ rates (speeds) which it can use at its serial port interface.
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).
+16550A, and higher numbers)
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
@@ -3809,24 +3920,23 @@ was large, then many more bytes would be sent in violation of flow
control's request to stop.
<sect1> UART Model Numbers
-<p> Here's a list of UARTs. <em/TL/ is <em/T/rigger <em/L/evel
+<p> Here's a list of some UARTs. <em/TL/ is <em/T/rigger <em/L/evel
<itemize>
<item> 8250, 16450, early 16550: Obsolete with 1-byte buffers
-<item> 16550, 16550A, 16c552: 16-byte buffers, TL=1,4,8,14
-<item> 16650: 32-byte buffers. Speed up to 460.8 kbps
-<item> 16750: 64-byte buffer for send, 56-byte for receive. Speed up
- to 921.6 kbps
+<item> 16550, 16550A, 16C552: 16-byte buffers, TL=1,4,8,14;
+ 115.2 kbps standard, many support 230.4 or 460.8 kbps
+<item> 16650: 32-byte buffers. 460.8 kbps
+<item> 16750: 64-byte buffer for send, 56-byte for receive. 921.6 kbps
+<item> 16850, 16C850: 128-byte buffers. 460.8 kbps or 1.5 mbps
+<item> 16950
<item> Hayes ESP: 1k-byte buffers.
</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 large
-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 ??
+For V.90 56k modems, it may be a several percent faster with a 16650
+(especially if you are downloading large 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 ??
Non-UART, and intelligent multiport boards use DSP chips to
do additional buffering and control, thus relieving the CPU
@@ -3943,7 +4053,7 @@ 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 < /dev/ttyS2 (or the like). This enables RTS/CTS
+stty -F /dev/ttyS2 crtscts (or the like). This enables RTS/CTS
hardware flow control in the Linux device driver.
Then when a DTE (such as a PC) wants to stop the flow into it, it
@@ -4148,13 +4258,17 @@ the next byte.
<sect1> Successors to 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.
+Balanced transmission make possible higher speeds, and can 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.
+
+High speed serial ports (over 460.8 kbps) will often support both
+EIA-232 and EIA-485/EIA-422 modes. At such high speeds EIA-232 is not
+of much use (except for a very short cable).
<sect1> EIA-422-A (balanced) and EIA-423-A (unbalanced)
<p> EIA-423 is just like the unbalanced EIA-232 except that the
@@ -4162,33 +4276,36 @@ 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). Since
-EIA-423 is not much of an improvement over EIA-232, it is not popular
+EIA-423 is not much of an improvement over EIA-232, it is seldom used
except on old Mac computers.
EIA-422 is twisted pair (known as "balanced" or "differential) and is
(per specs) exactly 100 times as fast as EIA-423 (which in turn is
-somewhat faster than EIA-232). Apple's Mac computer prior to mid-1998
-with its EIA-232/EIA-422 Port uses it. 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.
+somewhat faster than EIA-232). Apple's Mac computer used it prior to
+mid-1998 with its EIA-232/EIA-422 port. The Mac used a small round
+"mini-DIN-8" connector and named these serial ports as "modem port",
+"printer port", and/or "GeoPort".
+
+Mac 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.
<sect1> EIA-485
<p> This is like EIA-422 (balanced = differential). It is
-half-duplex. It's not just point-to-point but is like ethernet or
-the USB since all devices (nodes) on it share the same "bus". It may
-be used for a multidrop LAN (up to 32 nodes or more). Since many
-nodes share the same twisted pair the need to use the electrical
-tri-state mode where besides the 0 and 1 binary states there is also
-an open circuit state to permit other nodes to uses the twisted pair
-line. Instead of a transmitter keeping a 1-state voltage on the line
-during line idle, the line is open circuited and all nodes just listen
+half-duplex. It's not just point-to-point but is like ethernet or the
+USB since all devices (nodes) on it share the same "bus". It may be
+used for a multidrop LAN (up to 32 nodes or more). Since many nodes
+share the same twisted pair, there's a need to use the electrical
+tri-state mode. Besides the 0 and 1 binary states there is also an
+open circuit state to permit other nodes to use the twisted pair line.
+Instead of a transmitter keeping a 1-state voltage on the line during
+line idle, the line is open circuited and all nodes just listen
(receive mode).
The most common architecture is master/slave. The master polls the
@@ -4245,16 +4362,18 @@ conductors. You may compile firewire support into the Linux kernel.
Like USB, it's also limited to short distances.
<sect1> MIDI
-<p>Sound cards often have a 15-pin MIDI connector. There are also
-such connectors not associated with a sound card. They are for
-connecting a musical keyboard to a PC so that you can create musical
-recordings. You could also connect a MIDI sound system. The MIDI
-standard uses 31250 baud (1M/32) which is not available on an ordinary
-serial port. Some MIDI devices are designed so that they can be
-connected directly to an ordinary serial port.
+<p>Sound cards often have a 15-pin game port connector used for MIDI.
+They are for connecting a musical keyboard to a PC so that you can
+create musical recordings. You could also connect a MIDI sound
+system. The MIDI standard uses 31250 baud (1M/32) which is not
+available on an ordinary serial port. Some MIDI devices are designed
+so that they can be connected directly to an ordinary serial port.
-Besides the 15-pin connector, many use a 5-pin DIN connector.
-The /dev/midi00 is for MIDI.
+Besides the 15-pin connector, a 5-pin DIN connector is also a MIDI
+standard but the flow of sound is only one way thru it so for
+bidirectional sound you need 2 of them. Breakout cables often have a
+15-pin connector on one end and 2 or more 5-pin connectors on the
+other end. The /dev/midi00 is for MIDI.
<sect1> Synchronization & Synchronous <label id="sync">
<p> Beside the asynchronous EIA-232 (and others) there are a number of
@@ -4436,7 +4555,7 @@ meaning of "stty" commands, etc.
<sect1>Replacing obsolete UARTS
<p> Many 486 PCs (old) and all Pentiums (or the like) should have
modern 16550As (usually called just 16550's) with FIFOs. If you have
-something really old the chip may unplug so that you may be able to
+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 built into another type of chip,
you are out of luck. If the UART is socketed, then upgrading is easy
@@ -4447,4 +4566,3 @@ the Internet (few retail stores stock them today) or find a used one.
<p> END OF Serial-HOWTO
</article>
-