Modem-HOWTO
v0.32, December 2003
Help with selecting, connecting, configuring, trouble-shooting, and
understanding analog modems for a PC. Limited coverage of V.90
digital modems.
This HOWTO covers conventional analog modems for PCs on the
ISA, PCI, or USB buses. USB coverage is weak. For other types of
modems see:
For modems on the PCMCIA bus see the PCMCIA-HOWTO: PCMCIA serial
and modem devices. This HOWTO also doesn't cover PPP (used to connect
to the Internet via a modem) or communication programs. Except it
does show how to use communication programs to test that your modem
works OK and can make phone calls. If you want to use a modem to
connect to the Internet then you need to set up PPP. There's a lot of
documentation for PPP (including a PPP-HOWTO). More documentation
should be found in /usr/doc/ppp, /usr/share/doc/ppp or the like.
Copyright
Copyright (c) 1998-2003 by David S. Lawyer
mailto:dave@lafn.org
Please freely copy and distribute (sell or give away) this document
in any format. Send any corrections and comments to the document
maintainer. You may create a derivative work and distribute it
provided that you:
- 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@en.tldp.org.
- 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.
- Give due credit to previous authors and major contributors.
If you're considering making a derived work other than a
translation, it's requested that you discuss your plans with the
current maintainer.
Disclaimer
While I haven't intentionally tried to mislead you, there are
likely a number of errors in this document. Please let me know about
them. Since this is free documentation, it should be obvious that I
cannot be held legally responsible for any errors.
Trademarks.
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.
"Hayes" is a trademark of Microcomputer Products Inc. I use
"winmodem" to mean any modem which originally required MS-Windows and
not in the trademark sense. All other trademarks belong to their
respective owners.
Credits
The following is only a rough approximation of how this this
document (as of 2000) was created: About 1/4 of the material here was
lifted directly from Serial-HOWTO v. 1.11 (1997) by Greg Hankins.
mailto:gregh@twoguys.org (with his permission). About
another 1/4 was taken from that Serial-HOWTO and revised. The
remaining 1/2 is newly created by the new author: David S. Lawyer
mailto:dave@lafn.org.
Since I don't follow the many different brands/models of modems
please don't email me with questions about them (or suggestions of
which one to buy). If you are interested in a certain model (to find
out if it works under Linux, etc.) see the huge list at
Web Sites. Also, please don't ask me how to
configure a modem unless you've looked over this HOWTO and still can't
do it. I've no personal experience with software-based modems.
Please let me know of any errors in facts, opinions, logic, spelling,
grammar, clarity, links, etc. But first, if the date is over a month
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.
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:
http://www.tldp.org/mirrors.html If you
only want to quickly compare the date of this the version v0.32, December 2003 with
the date of the latest version go to:
http://www.tldp.org/HOWTO/Modem-HOWTO.html
For a full revision history going back to the first version see
the source file (in linuxdoc format) at
http://www.ibiblio.org/pub/linux/docs/HOWTO/other-formats/sgml/Modem-HOWTO.sgml.gz.
- v0.32 Dec. 2003: Still newer gromitkc url w/o pop ups; more on devfs
- v0.31 Nov. 2003: Mgetty dial-in, setserial rewritten
- v0.30 August 2003: New gromitkc url
- v0.29 July 2003 New gromitkc url, but many links in it are broken
- v0.28 June 2003: Parallel port modems, lockfile permissions for wvdial
- v0.27 May 2003: "Flow control" improved
- 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?
A modem (or analog modem) is a device that lets one send digital
signals over an ordinary telephone line not designed for digital
signals. If telephone lines were all digital then you wouldn't need a
modem. But sometimes, a substitute for an analog modem, connected to
a digital phone line, is imprecisely called a "digital modem". A
modem permits your computer to connect to and communicate with the
rest of the world. When you use a modem, you normally use a
communication program or web browser to utilize the modem and dial-out
on a telephone line. Advanced modem users can set things up so that
others may phone in to them and use their computer. This is called
"dial-in".
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. 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
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 regarding internal modems will generally apply also to built-in
modems.
For a more detailed comparison see
External 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 common serial ports are named ttyS0, ttyS1, etc. (or
tts/0, tts/1 for the device file system (devfs). These ports usually
corresponding respectively to COM1, COM2, etc. in Dos/Windows). But
in special cases, the names are longer: ttySHCF0 is the 0th serial
port for a type of winmodem (HCF = Host Controlled Family). New types
of serial ports just add some more letter to ttyS.
See
Modem & Serial Port Basics for more details on how modems and serial ports
work.
With a USB modem, the driver simulates a serial port at for example
/dev/ttySHCFUSB or /dev/usb/asm/0 (for devfs).
Modems usually include the ability to send Faxes (Fax Modems). See
Fax for a list of fax software. "Voice" modems
can work like an automatic answering machine and handle voicemail.
See
Voicemail Software.
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 ?).
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
each one looks like a jack on the interior wall of a building where a
telephone plugs in. One of the pair should be labeled "line" (or the
like) which is where you plug in the telephone line.
Network cards also have modular jacks, but they are seldom in pairs
and are slightly wider since they normally have 8 pins. Internal DSL
"modems" exist and also have modular telephone jacks, but I think they
are not very common (most DSL modems are external) as of 2002.
External Modem Install
With a straight-thru or modem cable, connect the modem to an
unused serial port on the PC. Make sure you know the name of the
serial port: in most cases COM1 is ttyS0, COM2 is ttyS1, etc. You may
need to check the BIOS setup menu to determine this. Plug in the
power cord to provide power to the modem. See
All Modems for further instructions.
Internal Modems (ISA, PCI and AMR)
The first thing to do is to make sure that the modem will work
under Linux since (as of 2002) many modems don't. If it's a
"winmodem" you'll need a driver for it (if one exists). See
modem list and
Software-based Modems (winmodems). If the
modem is both PnP and directly supported by the serial driver (kernel
2.4 +) or by a winmodem driver then there is no configuring for you to
do since the driver should configure it.
To physically install a modem card, remove the cover of the PC by
/removing some screws. Find a matching vacant slot for the card next
to the other adapter cards. Before inserting the card in the slot,
remove a small cover plate on the back of the PC so that the telephone
jacks on the card will be accessible from the rear of the PC. Then
carefully align the card with the slot and push the card all the way
down into the slot. Attach the card with a mounting screw (usually
3mm, .5mm pitch --don't use the wrong size).
You may watch the boot-time messages to see if your modem is detected.
Use "dmesg" to see them or shift-page-up to scroll the screen back
after they have flashed by.
Internal Modems: Manual configuration
If it didn't get automatically assigned a port such as ttyS2 and an
IRQ (or you need to change these values) then you need to configure it
yourself. You first need to decide which ttySx (or ttys/x) to assign
it to. Pick a ttySx that is not already in use by other serial ports.
Then you have the problem of setting an IRQ number and IO address.
For PnP modems: If the BIOS has already set these in the physical
device (which a PnP BIOS will do if it thinks you don't have a PnP OS)
then you need to determine the IRQ and IO address and then tell this
to "setserial".
In other cases you may have some choice of IRQs and IO addresses
(including the case where you are able to change what the BIOS has
set). See
Choosing Serial IRQs and
Choosing Addresses. For ISA modems there
are standard IO addresses to use (corresponding to the ttySx). For
example you may find it feasible to use /dev/ttyS2 at IO address 0x3e8
and IRQ 11. PCI modems seem to use different IO addresses so as not
to conflict with ISA modems.
ISA Modems: What IOs and IRQs may be used?
For old modems with jumpers look at the manual or look for
printing on the modem card that tells you what the jumpers do.
If the BIOS has already configured the ISA modem then "pnpdump
--dumpregs" should show it. If you need to set or change them use
"isapnp". Use the "pnpdump" to see what changes are possible.
Both PCI and ISA: Use setserial to tell the serial driver
You must find the file where "setserial" is run at boot-time and
add a line something like: "setserial /dev/ttyS2 irq 5 port 0x0b8".
For setserial v2.15 and later the results of running "setserial" on
the command line may (or may not) be saved to /etc/serial.conf so that
it runs each time you boot. See
What is Setserial for more info. See the next subsection
All Modems for further instructions on quick
installation.
Use MS Windows to set the BIOS (A last resort method)
If you are using the BIOS to configure you may attempt to use MS
Windows9x to "force" the BIOS to set a certain IRQ and/or IO. It can
set them into the PnP BIOS's flash memory where they will be used to
configure for Linux as well as Windows. See "Plug-and-Play-HOWTO and
search for "forced" (occurs in several places). For Windows3.x you
can do the same thing using the ICU under Windows 3.x. A few modems
have a way to disable PnP in the modem hardware using software (under
Windows) that came with the modem.
All Modems
Plug the modem into a telephone line. Then configure a
dialing program. If you have an Internet Service Provider (ISP) you
might configure one of these : wvdial, gnome-ppp, modem lights (Gnome)
or kppp. They not only dial out but start PPP, which you need to
connect to the Internet. Otherwise, you might try configuring the
minicom dialer which isn't designed for connecting to the Internet,
but is good for testing. Whether it's minicom or a dialer that starts
PPP, set the serial port speed to a baud rate a few times higher than
the bit rate of your modem. See
Speed Table for more details on the "best" speeds to use. Tell it the
full name of your serial port such as /dev/ttyS1 (or /dev/ttys/1).
Minicom is one way to set up and test your modem. Set hardware flow
control (RTS/CTS). With minicom you may check to see if your modem is
there (and ready to dial). Once you've set up minicom, type the
command: AT, hit enter and you should see an "OK" response which comes
directly from the modem. See
Dialing Out with Minicom.
A modem for a PC may be either internal or external. The
internal one is installed inside of your PC (you must remove screws,
etc. to install it) and the external one just plugs into a serial port
connector on a PC. Internal modems are less expensive, are less
likely to to suffer data loss due to buffer overrun, usually use less
electricity, and use up no space on your desk.
External modems are usually easier to install and usually require less
configuration. They have lights which may give you a clue as to what
is happening and aid in troubleshooting. The fact that the serial
port and modem can be physically separated also aids in
troubleshooting. External modems are easy to move to another
computer. If you need to turn the power off to reset your modem (this
is seldom necessary) then with an external you don't have to power
down the entire PC.
Unfortunately most external modems have no switch to turn off the
power supply when not in use and thus are likely to consume a little
electricity even when turned off (unless you unplug the power supply
from the wall). Each watt they draw usually costs you over $1/yr.
Another possible disadvantage of an external is that you will be
forced to use an existing serial port which may not support a speed of
over 115,200 bps (although as of late 2000 most new internal modems
don't either --but some do). For details
Can't Set a High Enough Speed
Internal modems present a special problem for Linux, but will work
just as well as external modems provided you avoid the ones that will
work only for MS Windows. Configuring them ranges from very easy
(automatically) to difficult depending on both the modem, your skills,
and how easy it is to find info about your modem --info that is not
all in this HOWTO. Some of the modems will work only under MS Windows
due to lack of Linux modem drivers (for software modems). If you buy
a new one that you're not sure will work under Linux, try to get an
agreement that you can return it for a refund if it doesn't work out.
While most new modems are plug-and-play you have various ways to deal
with the PnP configuring:
- The serial driver does it all for you (more likely for a PCI modem)
- Use the "isapnp" program
- Let a PnP BIOS do the configuring
The last 2 items of the above have shortcomings. Isapnp documentation
is difficult to understand although reading the Plug-and-Play-HOWTO
(long) will aid in understanding it. If you want the PnP BIOS to do
the configuring, all you need to do is to make sure that it knows that
you don't have a PnP operating system. But it may not do it correctly
and you may need to find out what it's done see
What is set in my serial port hardware?.
Many Linux users still say that it's a lot simpler just to get an
external modem and plug it in. But if you get the right internal
modem it may be just as easy.
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
run under Linux. So you must use a Linux driver (if it exists). See
Software-based Modems (winmodems, linmodems)
PnP External Modems
Many external modems are labeled "Plug and Play" (PnP) but they
should all work fine as non-PnP modems. While the serial port itself
may need to be configured (IRQ number and IO address) unless the
default configuration is OK, an external modem uses no such IRQ/IO
configuration. You just plug the modem into the serial port.
How can an external modem be called PnP since it can't be configured
by PnP? Well, it has a special PnP identification built into it that
can be read (thru the serial port) by a PnP operating system. Such an
operating system would then know that you have a modem on a certain
port and would also know the id number. If it's a software modem, it
could try to locate a driver for it. It could also tell application
programs what port your modem is on. (such as /dev/ttyS2 or COM3).
But since you don't have such a PnP operating system you may need to
configure your application program manually by giving it the /dev id
(such as /dev/ttyS2). Some programs can probe for a modem on various
ports.
Cabling & Installation
Connecting an external modem is simple compared to connecting
most other devices to a serial port that require various types of
"null modem" cables (which will not work for modems). Modems use
straight through cable, with no pins crossed over. Most computer
stores should have this. Make sure you get the correct gender and
number of pins. Hook up your modem to one of your serial ports. If
you are willing to accept the default IRQ and IO address of the port
you connect it to, then you are ready to start your communication
program and configure the modem itself.
What the Lights (LED's) Mean (for some external modems)
- TM Test Modem
- AA Auto Answer (If on, your modem will answer an incoming call)
- RD Receive Data line = RxD
- SD Send Data line = TxD
- TR data Terminal Ready = DTR (set by your PC)
- RI Ring Indicator (If on, someone is "ringing" your modem)
- OH Off Hook (If off, your modem has hung up the phone line)
- MR Modem Ready = DSR ??
- EC Error Correction
- DC Data Compression
- HS High Speed (for this modem)
An internal modem is installed in a PC by taking off the cover of
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 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
modem.
Setting the IO address and IRQ for a serial port was formerly done by
jumpers on the card. These are little black rectangular "cubes" about
5x4x2 mm in size which push in over pins on the card. Plug-and-Play
modems (actually the serial port part of the modems) don't use jumpers
for setting these but instead are configured by sending configuration
commands to them over the bus inside the computer. Such configuration
commands can be sent by a PnP BIOS, by the isapnp program (for the ISA
bus only), by setpci (for the PCI bus), or by newer serial device
drivers for certain modems. Under Linux you may have a choice of how
to configure the ones that don't get io-irq configured by the serial
driver.
- ISA bus: Use "isapnp" which may be run automatically at
every boot-time
- Let a PnP BIOS do it, and then maybe tell setserial the IO and
IRQ
- PCI bus: Use lspci -vv to look at it and setpci to configure.
See
Quick Install for more details,
especially for the PCI bus.
Introduction to software modems (winmodems)
Software modems turn over some (or even almost all) of the work of
the modem to the main processor (CPU) chip of your computer (such as a
Pentium chip). This requires special software (a modem driver) to do
the job. Until late 1999, such software was released only for MS
Windows and wouldn't work with Linux. Even worse was that the maker
of the modem kept the interface to the modem secret so that no one
could write a Linux driver for it (even though a few volunteers were
willing to write Linux drivers).
But things have improved some since then so that today (late 2001)
many such modems do have a linux driver. There is no standard
interface so that different brands/models of software-modems need
different drivers (unless the different brands/models happen to use
the same chipset internally).
Another name for a software modem (used by MS) is "driver-based
modem". The conventional hardware-based modem (that works with Linux)
doesn't need a modem driver (but does use the Linux serial driver)
After about mid-1998 most new internal modems were software modems.
Software modems fall into 2 categories: linmodems and winmodems.
Winmodems will only work under MS Windows. Linmodems will work under
Linux (but formerly were mostly winmodems so some still call them
"winmodems"). The term "Winmodem" is also a trademark for a certain
model of "winmodem" but that's not the meaning of it in this document.
Linmodems
In late 1999, two software-based modems appeared that could work
under Linux and were thus called "linmodems". Lucent Technologies
(LT) unofficially released a Linux binary-only code to support most of
its PCI modems. PC-TEL (includes "Zoltrix") introduced a new
software-based modem for Linux. After that, interest increased for
getting winmodems to work under linux. There is a GPL'ed driver for
Intel's (Modem Silicon Operations) MD563x HaM chipset (nee Ambient
division of Cirrus Logic). As of mid-2001 there are also drivers for:
Conexant HSF and HCF, Motorola SM56, ESS (ISA only), and IBM's Mwave
for Thinkpads 600+.
What percent of software modems now (2001) work under Linux? Well,
there's a number of modem chips not supported: Lucent/Agere ARM
(Scorpio), 3COM/US Robotics, some SmartLink (3 different chipsets),
Ambient HSP, and possibly others. But there might be support for some
of these by the time you read this. So it seems that over half the
software modem chips are now supported (as of late 2001).
Be warned in advance that determining if your modem is a linmodem may
or may not be easy. You may need to first find out what chipset you
have and who makes it. Just knowing the brand and model number of
your modem may not be sufficient. There are complex ways to find this
out using say "lspci" (more than once) and then looking up the chip
maker using the long modem number. This requires checking a database
or searching the Internet. It's not always simple. It could happen
that you will put a fair amount of effort into this only to get the
bad news that your modem isn't supported. See Linmodem-HOWTO for more
details.
Linmodem sites and documentation
- Linmodem-HOWTO
- Winmodems-and-Linux-HOWTO (not as well written as Linmodem-HOWTO)
-
http://linmodems.org is a project to turn winmodems
into linmodems. Has a mailing list.
- Conexant+Rockwell-modem-HOWTO
-
modem list Has links to
linmodem info.
- PCTel-HSP-MicroModem-Configuration-mini-HOWTO
Software-based modem types
There are two basic types of software modems. In one type the
software does almost all of the work. The other is where the software
only does the "control" operations (which is everything except
processing the digital waveshapes --to be explained later). Since the
hardware doesn't do the control it's called a "controllerless" modem.
The first type is an all-software modem (sometimes just called a
software modem).
For both of these types there must be analog hardware in the modem to
generate an electrical waveshape to send out the phone line. It's
generated from a digital signal (which is sort of a "digital
waveshape"). It's something like the digital electronics creates a
lot of discrete points on graph paper and then the modem draws a
smooth curve thru them. There must also be hardware to convert the
incoming waveshape to digital. This is just analog-to-digital
conversion (and conversely). It's done by a codec (coder-decoder).
Then this digital waveshape must be converted to a data byte stream.
This is known as demodulation, while turning data bytes into a digital
waveshape is known as modulation. The modem can't just send an
incoming data byte stream to the PC but must first do decompression,
error correction, and convert from serial to the parallel bus of the
computer. Likewise for an outgoing data byte stream.
The difference between the two types of software-based modems is where
the digital modulation takes place. In the all-software modem this
modulation is done in the CPU using a Host Signal Processor (HSP). In
the controllerless modem it's done in the modem but all other digital
work is done by the CPU. This other digital work consists of dealing
with AT-commands, data compression, error correction, and simulating a
serial port. In the all-software modem, there are still two items
handled by hardware: the A/D conversion of waveshapes by the codec and
echo cancellation.
Is this modem a software modem?
How do you determine if an internal modem is a software modem?
First see if the name, description of it, or even the name of the MS
Windows driver for it indicates it's a software modem: HSP (Host
Signal Processor) , HCF (Host Controlled Family), HSF (Host Signal
Family), controllerless, host-controlled, host-based, and soft-...
modem. If it's one of these modem it will only work for the cases
where a Linux driver is available. Since software modems cost less, a
low price is a clue that it's a software modem.
If you don't know the model of the modem and you also have Windows on
your Linux PC, click on the "Modem" icon in the "Control Panel". Then
check out the modem list (see
Web Sites.
If the above doesn't work (or isn't feasible), you can look at the
package it came in (or a manual). Read the section on the package
that says something like "Minimum System Requirements" or just "System
Requirements".
A hardware modem will work fine on old CPUs (such as the 386 or
better). So if it requires a modern CPU (such as a Pentium or other
"high speed" CPU of say over 150 MHz) this is a clue that it's a
all-software modem. If it only requires a 486 CPU (or better) then
it's likely a host-controlled software modem. Saying that it only
works with Windows is also bad news. However, even in this case there
may be a Linux driver for it.
Otherwise, it may be a hardware modem if it fails to state explicitly
that you must have Windows. By saying it's "designed for Windows" it
may only mean that it fully supports Microsoft's plug-and-play which
is OK since Linux uses the same plug-and-play specs (but it's harder
to configure under Linux). Being "designed for Windows" thus gives no
clue as to whether or not it will work under Linux. You might check
the Website of the manufacturer or inquire via email. Some
manufacturers are specifically stating that certain models work under
Linux. Sometimes they are linmodems that require you to obtain and
install a certain linmodem driver.
Should I get a software modem?
Only if you know there is a Linux driver for it that works OK.
Besides the problems of getting a driver, what are the pros and cons
of software modems? Since the software modem uses the CPU to do some
(or all) of its work, the software modem requires less on-board
electronics and thus costs less. At the same time, the CPU work load
is increased by the modem which may result in slower operation.
The percentage of loading of the CPU by the modem depends on both what
CPU you have and whether or not it's an all-software modem. For a
modern CPU and a modem that only uses the CPU as a controller, there's
little loss of performance. Even if it's an all-software modem, you
will not suffer a loss of performance if there are no other
CPU-intensive tasks are running at the same time. Of course, when
you're not using the software modem there is no degradation in
performance at all.
Is the modem cost savings worth it? In many cases yes, especially if
you don't use the modem much and/or are not running any other CPU
intensive tasks when the modem is in use. The savings in modem cost
could be used for a better CPU which would speed things up a little.
But the on-board electronics of a modem can do the job more
efficiently than a general purpose CPU (except that it's not efficient
at all when it's not in use). So if you use the modem a lot it's
probably better to avoid all-software modems (and then you can use a
less powerful CPU :-).
A PCI modem card is one which inserts into a PCI-bus slot on the
motherboard of a PC. While many PCI winmodems will not work under
Linux (no driver available) other PCI modems will work under Linux.
The Linux serial driver has been modified to support certain PCI
hardware modem cards (but not winmodems/linmodems). If it's a
linmodem, it will work only if you install a certain linmodem driver.
If the Linux serial driver supports your hardware modem then the
driver will set up the PnP configuration for you. See
PCI Bus Support Underway. If no special
support for your PCI hardware modem is in the Linux serial driver it
may still work OK but you have to do some work to configure it.
These are all winmodems that insert into a special AMR (Audio Modem
Riser) slot on the motherboard. Audio cards are sometimes used in this
slot. The slot's main use is for HSF type modems where the CPU does
almost all of the work. This results in a small modem card and thus a
short AMR slot. Such a "modem" is actually little more than a codec
which transforms digital signals representing an analog voltage wave
into the analog wave itself (and conversely). Linux supports at least
one of them.
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.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: /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.
MWave and some DSP Modems
Note that there's now a Linux driver for the ACP (Mwave) modem
used in IBM Thinkpads 600+. See the mini-HOWTO: ACP-Modem.
While hardware modems used use DSPs (Digital Signal Processors) some
of these DSPs are programmed by a driver which must be downloaded from
the hard disk to the DSPs memory just before using the modem.
Unfortunately, such downloading is normally done by Dos/Windows
programs (which doesn't work for Linux). But there has been
substantial success in getting some of these modems to work with
Linux. For example, there is a Linux driver available to run a Lucent
(DSP) modem.
Ordinary modems that work fine with Linux (without needing a driver
for the modem) often have a DSP too (and may mention this on the
packaging), but the program that runs the DSP is stored inside the
modem. These work fine under Linux. An example of a DSP modem that
has problems working under Linux is the old IBM's Aptiva MWAVE.
One way to get some DSP modems to work with Linux is to boot from DOS
(if you have it on your Linux PC). You first install the driver under
DOS (using DOS and not Window drivers). Then start Dos/Windows and
start the driver for the modem so as to program the DSP. Then without
turning off the computer, start Linux.
One may write a "batch" file (actually a script) to do this. Here is
an example but you must modify it to suit your situation.
rem mwave is a batch file supplied by the modem maker
call c:\mww\dll\mwave start
rem loadlin.exe is a DOS program that will boot Linux from DOS (See
rem Config-HOWTO).
c:\linux\loadlin f:\vmlinuz root=/dev/hda3 ro
One may create an icon for the Window's desktop which points to such a
batch file and set the icon properties to "Run in MSDOS Mode". Then
by clicking on this icon one sets up the modem and goes to Linux.
Another possible way to boot Linux from DOS is to press CTRL-ALT-DEL
and tell it to reboot (assuming that you have set things up so that
you can boot directly into Linux). The modem remains on the same com
port (same IO address) that it used under DOS.
The Newcom ifx modem needs a small kernel patch to work correctly
since its simulation of a serial port is non-standard. The patch and
other info for using this modem with Linux is at
http://quinine.pharmacy.ohio-state.edu/~ejolson/linux/newcom.html.
Old Rockwell (RPI) Drivers
Some older Rockwell chips need Rockwell RPI (Rockwell
Protocol Interface) drivers for compression and error correction.
They can still be used with Linux even though the driver software
works only under MS Windows. This is because the MS Windows software
(which you don't have) does only compression and error correction. If
you are willing to operate the modem without compression and error
correction then it's feasible to use it with Linux. To do this you
will need to disable RPI by sending the modem (via the initialization
string) a "RPI disable" command each time you power on your modem. On
my old modem this command was +H0. Not having data compression
available makes it slower to get webpages but is just as fast when
downloading files that are already compressed.
These are multiple modems which might be used by an ISP or by an
organization that has a number of phone lines for dialing in and out.
There are two types of modem pools: analog and digital. An ISP will
use digital so that they can support 56k (V.90, V.92) modems at near
maximum speed.
A modem pool could be a number of modems on the same card (such as an
analog multi-port modem card) or many modems in an external chassis
(something like an external modem). The modems may be analog modems
similar to modems used for home/office PCs (can't send above 33.6k
even if they are "56k modems"). They also could be "digital modems"
which can send at nearly 56k (if you have a good line). The "digital
modems" require a digital connection to the telephone line and don't
use any serial ports at all. All of these modem pools will require
that you install special drivers for them.
A "multimodem card" is short for "multiport modem card". Some put
a hyphen after "multi": multi-modem or multi-port. An analog modem
pool is just many analog modems (the common home/office modem)
provided either on an internal plug-in card or in an external chassis.
Each modem comes with a built-in serial port. There is usually a
system of sharing interrupts or of handling interrupts by their own
electronics, thus removing much of this burden from the CPU. Note
that these modems are not "digital modems" and will thus not be able
to use 56k for people who dial-in.
Here is a list of some companies that make analog multiport modem
cards which plug into slots in a PC. 8 modems/card is common. The
cards listed claim to work with Linux and the websites should point
you to a driver for them.
Multi-modem Cards (analog, not digital):
"digital modems" are much different than the analog modems that
most people use in their PCs. They require a digital connection to
the telephone line and don't use serial ports for the interface to the
computer. Instead, they interface directly to a computer bus via a
special card(s) (which may also contain the "digital modems"). They are
able to send at near 56k, something no analog modem can do. They are
often a component of "remote access servers" (RASs) or "digital modem
pools"
The cables from the phone company that carry digital signals have been
designed for high bandwidth so that the same cable carries multiple
telephone calls. It's done by "time-division multiplexing". A single
phone call in a cable is carried on two different channels, one for
each direction. So the RAS must connect each such channel-pair to the
appropriate "digital modem" that services that phone call. Such tasks
are done by what is sometimes called a "... concentrator".
Now the digital signal received by a "digital modem" may really
represent an analog signal which has been sent to it by an analog
modem. One way to deal with it would be to convert it to an analog
signal and then put that thru an analog modem to get the digital data
sent by the analog modem. But why do all this work? Since the signal
is already in digital form, why not process it digitally? That's how
it's done. The digital signal is processed and converted to another
digital stream of bytes which represents data bytes sent by the analog
modem. A "digital signal processor" (DSP) is commonly used for this
task. A CPU could also handle it but it would be heavily loaded.
Likewise, a "digital modem" must handle sending digital signals in the
opposite direction from a RAS to a digital telephone line. Thus it
only makes digital-to-digital conversions and doesn't deal in analog
at all. It thus is not really a modem at all since it doesn't
modulate any analog carrier. So the name "digital modem" is a
misnomer but it does do the job formerly done by modems. Thus some
"digital modems" call themselves "digital signal processors", or
"remote access servers", etc. and may not even mention the word
"modem".
Such a RAS system may be a stand-alone proprietary server, a chassis
containing digital modems that connects to a PC via a special
interface card, or just a card itself. Digi calls one such card a
"remote access server concentrator adapter". One incomplete
description of what is needed to become an ISP is: See
What do I need to be an ISP?. Cyclades promotes their own
products here so please do comparison shopping before buying anything.
You don't have to understand the basics to use and install a
modem. But understanding it may help to determine what is wrong if
you run into problems. After reading this section, if you want to
understand it even better you may want to see
How Modems Work in this document (not yet
complete). More details on the serial port (including much of this
section) will be found in Serial-HOWTO.
Most all telephone main lines are digital already but the lines
leading to your house (or business) are usually analog which means
that they were designed to transmit a voltage wave which is an exact
replica of the sound wave coming out of your mouth. Such a voltage
wave is called "analog". If viewed on an oscilloscope it looks like a
sine wave of varying frequency and amplitude. A digital signal is
like a square wave. For example 3 v (volts) might be a 1-bit and 0 v
could be a 0-bit. For most serial ports (used by external modems) +12
v is a 0-bit and -12 v is a 1-bit (some are + or - 5 v).
To send data from your computer over the phone line, the modem takes
the digital signal from your computer and converts it to "analog". It
does this by both creating an analog sine wave and then "MODulating"
it. Since the result still represents digital data, it could also be
called a digital signal instead of analog. But it looks something
like an analog signal and almost everyone calls it analog. At the
other end of the phone line another modem "DEModulates" this signal
and the pure digital signal is recovered. Put together the "mod" and
"dem" parts of the two words above and you get "modem" (if you drop
one of the two d's). A "modem" is thus a MODulator-DEModulator. Just
what modulation is may be found in the section
Modulation Details.
Intro to Serial
The UART serial port (or just "serial port for short" is an I/O (Input/Output) device.
Since modems have a serial port between them and the computer,
it's necessary to understand the serial port as well as the modem.
Most PC's have one or two serial ports. Each has a 9-pin connector
(sometimes 25-pin) on the back of the computer. Computer programs can
send data (bytes) to the transmit pin (output) and receive bytes from
the receive pin (input). The other pins are for control purposes and
ground.
The serial port is much more than just a connector. It converts the
data from parallel to serial and changes the electrical representation
of the data. Inside the computer, data bits flow in parallel (using
many wires at the same time). Serial flow is a stream of bits over a
single wire (such as on the transmit or receive pin of the serial
connector). For the serial port to create such a flow, it must
convert data from parallel (inside the computer) to serial on the
transmit pin (and conversely).
Most of the electronics of the serial port is found in a computer chip
(or a part of a chip) known as a UART. For more details on UARTs
see the section
"What are UARTS" in the Serial-HOWTO.
But you may want to finish this section first so that you will
hopefully understand how the UART fits into the overall scheme of
things.
Pins and Wires
Old PC's used 25 pin connectors but only about 9 pins were
actually used so today most connectors are only 9-pin. Each of the 9
pins usually connects to a wire. Besides the two wires used for
transmitting and receiving data, another pin (wire) is signal ground.
The voltage on any wire is measured with respect to this ground. Thus
the minimum number of wires to use for 2-way transmission of data is
3. Except that it has been known to work with no signal ground wire
but with degraded performance and sometimes with errors.
There are still more wires which are for control purposes (signalling)
only and not for sending bytes. All of these signals could have been
shared on a single wire, but instead, there is a separate dedicated
wire for every type of signal. Some (or all) of these control wires
are called "modem control lines". Modem control wires are either in
the asserted state (on) of +12 volts or in the negated state (off) of
-12 volts. One of these wires is to signal the computer to stop
sending bytes out the serial port cable. Conversely, another wire
signals the device attached to the serial port to stop sending bytes
to the computer. If the attached device is a modem, other wires may
tell the modem to hang up the telephone line or tell the computer that
a connection has been made or that the telephone line is ringing
(someone is attempting to call in). See the Serial-HOWTO:
Pinout and Signals for more details.
Internal Modem Contains Serial Port
For an internal modem there is no 9-pin connector but the behavior
is almost exactly as if the above mentioned cable wires existed.
Instead of a a 12 volt signal in a wire giving the state of a modem
control line, the internal modem may just use a status bit in its own
memory (a register) to determine the state of this non-existent
"wire". The internal modem's serial port looks just like a real
serial port to the computer. It even includes the speed limits that
one may set at ordinary serial ports such as 115200 bits/sec.
Unfortunately for Linux, many internal modems today don't work exactly
this way but instead use software (running on the CPU) to do much of
the modem's work. Unfortunately, such software is often only
available for the MS Windows OS (it hasn't been ported to Linux).
Thus you can't use most of these modems with Linux See
Software-based Modems (winmodems).
Since the computer needs to communicate with each serial port, the
operating system must know that each serial port exists and where it
is (its I/O address). It also needs to know which wire (IRQ number)
the serial port must use to request service from the computer's CPU.
It requests service by sending an interrupt on this wire. Thus every
serial port device must store in its non-volatile memory both its I/O
address and its Interrupt ReQuest number: IRQ. See
Interrupts. For the PCI bus it doesn't work
exactly this way since the PCI bus has its own system of interrupts.
But since the PCI-aware BIOS sets up chips to map these PCI interrupts
to IRQs, it seemingly behaves just as described above except that
sharing of interrupts is allowed (2 or more devices may use the same
IRQ number).
I/O addresses are not the same as memory addresses. When an I/O
addresses is put onto the computer's address bus, another wire is
energized. This both tells main memory to ignore the address and
tells all devices which have I/O addresses (such as the serial port)
to listen to the address to see if it matches the device's. If the
address matches, then the I/O device reads the data on the data bus.
The serial ports are named ttyS0, ttyS1, etc. (and usually
correspond respectively to COM1, COM2, etc. in DOS/Windows). The /dev
directory has a special file for each port. Type "ls /dev/ttyS*" to
see them. Just because there may be (for example) a ttyS3 file,
doesn't necessarily mean that there exists a physical serial port
there.
Which one of these names (ttyS0, ttyS1, etc.) refers to which
physical serial port is determined as follows. The serial driver
(software) maintains a table showing which I/O address corresponds to
which ttyS. This mapping of names (such as ttyS1) to I/O addresses
(and IRQ's) may be both set and viewed by the "setserial" command.
See
What is Setserial. This does
not set the I/O address and IRQ in the hardware itself (which is
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
ttyS2) and thus it can't be used. See
Serial Port Devices /dev/ttyS2, etc. for more details>
Bytes come in over the phone line to the modem, are converted from
analog to digital by the modem and passed along to the serial port on
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 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 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
example, ttyS0 normally uses IRQ number 4 known as IRQ4 (or IRQ 4). A
list of them and more will be found in "man setserial" (search for
"Configuring Serial Ports"). Interrupts are issued whenever the
serial port needs to get the CPU's attention. It's important to do
this in a timely manner since the buffer inside the serial port can
hold only 16 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 may be no way (such as flow control) to
stop the flow rapidly enough to prevent such an overrun. For an
internal modem, the 16-byte FIFO buffer is on the same card and most
modems will not write to it if it's full. Thus it will not overrun
the 16-byte buffers but it may need to use
Modem-to-Modem Flow Control to prevent the modem itself from
being overrun. This is one advantage of internal modems over an
external.
Interrupts are also issued when the serial port has just sent out all
of its bytes from its small transmit FIFO 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.
The buffers mentioned above are all hardware buffers. The serial port
also has large buffers in main memory. This will be explained later
Interrupts convey a lot of information but only indirectly. The
interrupt itself just tells a chip called the interrupt controller
that a certain serial port needs attention. The interrupt controller
then signals the CPU. The CPU then runs a special program to service
the serial port. That program is called an interrupt service routine
(part of the serial driver software). It tries to find out what has
happened at the serial port and then deals with the problem such a
transferring bytes from (or to) the serial port's hardware buffer.
This program can easily find out what has happened since the serial
port has registers at IO addresses known to the the serial driver
software. These registers contain status information about the serial
port. The software reads these registers and by inspecting the
contents, finds out what has happened and takes appropriate action.
Before continuing with the basics of the serial port, one needs to
understand about something done by the modem: data compression. In
some cases this task is actually done by software run on the
computer's CPU but unfortunately at present, such software only works
for MS Windows. The discussion here will be for the case where the
modem itself does the compression since this is what must happen in
order for the modem to work under Linux.
In order to send data faster over the phone line, one may compress
(encode it) using a custom encoding scheme which itself depends on the
data. The encoded data is smaller than the original (less bytes) and
can be sent over the Internet in less time. This process is called
"data compression".
If you download files from the Internet, they are likely already
compressed and it is not feasible for the modem to try to compress
them further. Your modem may sense that what is passing thru has
already been compressed and refrain from trying a compress it any
more. If you are receiving data which has been compressed by the
other modem, your modem will decompress it and create many more bytes
than were sent over the phone line. Thus the flow of data from your
modem into your computer will be higher than the flow over the phone
line to you. The ratio of this flow is called the compression ratio.
Compression ratios as high as 4 are possible, but not very likely.
Similar to data compression, modems may be set to do error
correction. While there is some overhead cost involved which slows
down the byte/sec flow rate, the fact that error correction strips off
start and stop bits actually increases the data byte/sec flow rate.
For the serial port's interface with the external world, each 8-bit
byte has 2 extra bits added to it: a start-bit and a stop-bit.
Without error correction, these extra start and stop bits usually go
right thru the modem and out over the phone lines. But when error
correction is enabled, these extra bits are stripped off and the 8-bit
bytes are put into packets. This is more efficient and results in
higher byte/sec flow in spite of the fact that there are a few more
bytes added for packet headers and error correction purposes.
Data (bytes representing letters, pictures, etc.) flows from your
computer to your modem and then out on the telephone line (and
conversely). Flow rates (such as 56k (56000) bits/sec) are
(incorrectly) called "speed". But almost everyone says "speed"
instead of "flow rate". If there were no data compression the flow
rate from the computer to the modem would be about the same as the
flow rate over the telephone line.
Actually there are two different speeds to consider at your end of the
phone line:
- The speed on the phone line itself (DCE speed) modem-to-modem
- The speed from your computer's serial port to your modem (DTE speed)
When you dial out and connect to another modem on the other end of the
phone line, your modem often sends you a message like "CONNECT 28800"
or "CONNECT 115200". What do these mean? Well, its either the DCE
speed or the DTE speed. If it's higher than the advertised modem speed
it must be the DTE modem-to-computer speed. This is the case for the
115200 speed shown above. The 28800 must be a DCE (modem-to-modem)
speed since the serial port has no such speed. One may configure the
modem to report either speed. Some modems report both speeds and
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 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
line. Waits (or idle time) result in a lower average speed. These
waits may include long waits of perhaps a second due to
Flow Control. At the other extreme there
may be very short waits (idle time) of several micro-seconds
separating the end of one byte and the start of the next byte. In
addition, modems will fallback to lower speeds if the telephone line
conditions are less than pristine.
For a discussion of what DTE speed is best to use see section
What Speed Should I Use.
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 and other hardware to allow a jump in instantaneous flow rates.
Example of Flow Control
For example, consider the case where you connect a 33.6k external
modem via a short cable to your serial port. The modem sends and
receives bytes over the phone line at 33.6k bits per second (bps).
Assume it's not doing any data compression or error correction. You
have set the serial port speed to 115,200 bits/sec (bps), and you are
sending data from your computer to the phone line. Then the flow from
the your computer to your modem over the short cable is at 115.2k bps.
However the flow from your modem out the phone line is only 33.6k bps.
Since a faster flow (115.2k) is going into your modem than is coming
out of it, the modem is storing the excess flow (115.2k -33.6k = 81.6k
bps) in one of its buffers. This buffer would soon overrun (run out
of free storage space) unless the high 115.2k flow is stopped.
But now flow control comes to the rescue. When the modem's buffer is
almost full, the modem sends a stop signal to the serial port. The
serial port passes on the stop signal on to the device driver and the
115.2k bps flow is halted. Then the modem continues to send out data
at 33.6k bps drawing on the data it previous accumulated in its
buffer. Since nothing is coming into this buffer, the number of bytes
in it starts to drop. When almost no bytes are left in the buffer,
the modem sends a start signal to the serial port and the 115.2k flow
from the computer to the modem resumes. In effect, flow control
creates an average flow rate in the short cable (in this case 33.6k)
which is significantly less than the "on" flow rate of 115.2k bps.
This is "start-stop" flow control.
In the above simple example it was assumed that the modem did no data
compression. This could happen when the modem is sending a file
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). This compression ratio is
3.43 (115.2/33.6). In this case the modem is able to compress 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 if it should drop
below 3.43, flow control will be needed
In the above example, the modem was an external modem. But the same
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.
In the above example of flow control, the flow was from the computer to
a modem. But there is also flow control which is used for the
opposite direction of flow: from a modem (or other device) to a
computer. Each direction of flow involves 3 buffers: 1. in the modem
2. in the UART chip (called FIFOs) and 3. in main memory managed by the
serial driver. Flow control protects all buffers (except the FIFOs)
from overflowing.
Under Linux, the small UART FIFO buffers are not protected by flow
control but instead rely 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 the one in the UART is named "FIFO". This is the essence of flow
control but there are still some more details.
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 a 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
Modem-to-Modem Flow Control.
Hardware vs. Software Flow Control
If feasible, it's best to use "hardware" flow control that uses two
dedicated "modem control" wires to send the "stop" and "start"
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.
But for a printer, another PC, or a non-modem device, it's usually a
CTS pin so a "crossover" or "null modem" cable is required. This
cable connects the CTS pin at one end with the RTS pin at the other
end (two wires since each end of the cable has a CTS pin). 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 to the CTS
pin on the PC. For a non-modem, the RTS pin sends the signal. Thus
modems and non-modems have the roles of their RTS and CTS pins
interchanged. Some non-modems such as dumb terminals may use other
pins for flow control such as the DTR pin instead of RTS.
Software flow control uses the main receive and transmit wires to send
the start and stop signals. It uses the ASCII control characters DC1
(start) and DC3 (stop) for this purpose. They are just inserted into
the regular stream of data. Software flow control is not only slower
in reacting but also does not allow the sending of binary data unless
special precautions are taken. Since binary data will likely contain
DC1 and DC3, special means must be taken to distinguish between a DC3
that means a flow control stop and a DC3 that is part of the binary
code. Likewise for DC1.
To get software flow control to work for binary data requires both
modem (hardware) and software support.
Symptoms of No Flow Control
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 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.
Modem-to-Modem Flow Control
This is the flow control of the data sent over the telephone lines
between two modems. It works as long as error correction is enabled.
Actually, even without error correction it's possible to enable
software flow control between modems but it may interfere with sending
binary data so it's not often used.
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
other member of the pair consists of 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.
application 8k-byte 16-byte 1k-byte tele-
BROWSER ------- MEMORY -------- FIFO --------- MODEM -------- phone
program buffer buffer buffer line
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 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 three 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. Third, the
serial driver (located between the memory buffer and the FIFO) has
it's own buffer (in main memory) used to process characters.
Commands to the modem are sent to it from the communication
software over the same conductor as used to send data. The commands
are short ASCII strings. Examples are "AT&K3" for enabling
hardware flow control (RTS/CTS) between your computer and modem; and
"ATDT5393401 for Dialing the number 5393401. Note all commands are
prefaced by "AT". Some commands such as enabling flow control help
configure the modem. Other commands such as dialing a number actually
do something. There are about a hundred or so different possible
commands. When your communication software starts running, it first
sends an "init" string of commands to the modem to configure it. All
commands are sent on the ordinary data line before the modem dials (or
receives a call).
Once the modem is connected to another modem (on-line mode),
everything that is sent from your computer to your modem goes directly
to the other modem and is not interpreted by the modem as a command.
There is a way to "escape" from this mode of operation and go back to
command mode where everything sent to the modem will be interpreted as
a command. The computer just sends "+++" with a specified time
spacing before and after it. If this time spacing is correct, the
modem reverts to command mode. Another way to do this is by a signal
on a certain modem control line.
There are a number of lists of modem commands on the Internet. The
section
Web Sites has links to a couple of
such web-sites. Different models and brands of modems do not use
exactly the same set of such commands. So what works for one modem
might not work for another. Some common commands (not guaranteed to
work on all modems) are listed in this HOWTO in the section
Modem Configuration
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
if it's needed. In earlier kernels, you had to have kerneld
running in order to do auto-load modules on demand. Otherwise the
serial module needed to be explicitly listed in /etc/modules. Before
modules became popular with Linux, the serial driver was usually built
into the kernel (and sometimes still is). If it's built-in don't let
the serial module load or else you will have two serial drivers
running at the same time. With 2 drivers there are all sorts of
errors including a possible "I/O error" when attempting to open a
serial port. Use "lsmod" to see if the module is loaded.
When the serial module is loaded it displays a message on the screen
about the existing serial ports (often showing a wrong IRQ). But once
the module is used by setserial to tell the device driver the
(hopefully) correct IRQ then you should see a second display similar
to the first but with the correct IRQ, etc. See
"Serial Module" in the Serial-HOWTO.
See
What is Setserial for more info on
setserial.
Since each modem has an associated serial port and the port has both
hardware and software, there are three parts to configuring a modem:
The above omits a few other things that "setserial" can do besides
locating the serial ports. But normally you don't need to use them.
Setserial may be used in the future to enable super-high speed.
Communication programs include minicom, seyon, or
wvdial (for PPP) and mgetty for dial-in. Such
communication programs require that you configure them, although the
default configuration they come with may only need a little tweaking.
Unfortunately the communication program doesn't locate the serial
port. This "locating" is the low-level PnP configuring of the serial
port: setting its IO address and IRQ in both the hardware and the
driver. If you are lucky, this will happen automatically when you
boot Linux. Setting these in the hardware was formerly done by
jumpers and then running "setserial" but today it's done by
"Plug-and-Play" software. You may still need "setserial". So if
Linux (or the wvdial program, etc.) doesn't report what serial port
your modem is on, then you can try to find it yourself per the next
section but it may not be easy.
For a serial port to work properly, it must have both an IRQ and
an IO address. Without an IO address, it can't be located and will not
work at all. Without an IRQ it will need to use inefficient polling
methods for which one must set the IRQ to 0 in the serial driver. So
every serial port needs an IO address and IRQ. In olden days this was
set by jumpers on a serial port card. Today it's set by digital
signals sent to the hardware and this is part of "Plug-and-Play (PnP).
It all should get configured automatically so that you only need to
read this if you're having problems or if you want to understand how
it works.
The driver must also know both the IO address and IRQ so that it can
talk to the port chip. Modern serial port drivers (kernel 2.4) try to
determine this by PnP methods so one doesn't normally need to tell the driver
(by using "setserial"). The modern driver might also enable the serial
port and set an IO address or IRQ in the hardware. But unfortunately,
there is some PCI serial port hardware that the driver doesn't
recognize so you might need to enable the port yourself. See
PCI: Enabling a disabled port
The driver also probes likely 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 ISA PnP port when the driver doesn't do ISA
PnP (prior to kernel 2.4).
Locating the serial port by giving it an IRQ and IO address is
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 = tts/2). This IO-IRQ pair must be set in both the
hardware and told to the serial driver. And the driver needs to call
this pair a name (such as ttyS2). 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
there is no PnP but the driver might detect the port if the jumpers
are set to the usual I0/IRQ. 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) serial ports. Exactly what happens depends on your BIOS,
hardware, Linux distribution, kernel version, etc. If the serial
ports work OK, there may be no need for you to do any more low-level
configuring.
If you're having problems with the serial ports, then you may need to
do low-level configuring. If you have kernel 2.2 or lower,
then you need to do it if you:
- Plan to use more than 2 ISA serial ports
- Are installing a new serial port (such as an internal modem)
Starting with 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 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
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 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 don't have any IO address and thus can't be used. However PnP
tools such as lspci should be able to find them. Applications, and
utilities such as "setserial" and "scanport" (Debian only ??) only
probe I0 addresses, don't use PnP tools, and thus can't detect
disabled ports.
Even if an ISA port can be found by the probing done by the serial
driver it may work extremely slow if the IRQ is wrong. See
Extremely Slow: Text appears on the screen slowly after long 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
types of "resources" so the term has many other meanings. In summary,
the low-level configuring consists of enabling the device, giving it a
name (ttyS2 for example) and putting two values (an IRQ number and IO
address) into two places:
- the device driver (done by PnP or "
setserial")
- configuration registers of the serial port hardware itself
(done by PnP or jumpers)
You may watch the start-up (= boot-time) messages. They are usually
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
I/O Address & IRQ: Boot-time messages.
Introduction
Although some PCI modems are "winmodems" without a Linux driver
(and will not work under Linux), other PCI modems will often work OK
under Linux. If it's a software modem, then you need to find a driver
for it since support for "winmodems" is not built into ther serial
driver. See Linmodem-HOWTO.
If you have kernel 2.4, then there should be support for PnP (either
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.
While kernel 2.2 supported PCI in general, it 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 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.
There is a possible problem if you don't use the device filesystem.
The driver may assign the port to say "ttyS04" per a boot-time
message (use dmesg to see it). But if you don't have a "file" dev/ttyS4
then the port will not work. So you will then need to create it,
using
cd /dev and then ./MAKEDEV ttyS4
For the device filesystem, the driver should create the device
tts/1
More info on PCI
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
"setserial" the IO port and the IRQ.
Some people have gotten a 3COM 3CP5610 PCI Modem to work that
way.For example, if lspci shows IRQ 10, I/O at 0xecb8 and you decide to
name it ttyS2 then the command is:
setserial /dev/ttyS2 irq 10 port 0xecb8 autoconfig
Note that the boot-time message "Probing PCI hardware" means reading
the PnP configuration registers in the PCI cards which reveals the IO
addresses and IRQs. This is different that the probing of IO
addresses by the serial driver which means reading certain IO
addresses to see if what's read looks like there's a serial port at
that address.
Here are some common mistakes people make:
- setserial command: They run it (without the "autoconfig" and
auto_irq options) and think it has checked the hardware to see if
what it shows is correct (it hasn't).
- setserial messages: They see them displayed on the screen at
boot-time (or by giving the setserial command) and erroneously think
that the result always shows how their hardware is actually
configured.
- /proc/interrupts: When their serial device isn't in use they
don't see its interrupt there, and erroneously conclude that their
serial port can't be found (or doesn't have an interrupt set).
- /proc/ioports and /proc/tty/driver/serial: People think this
shows the actual hardware configuration when it only shows about the
same info (possibly erroneous) as setserial.
There are really two answers to the question "What is my IO and
IRQ?" 1. What the device driver thinks has been set (This is what
setserial usually sets and shows.). 2. What is actually set in the
hardware. Both 1. and 2. above should be the same. If they're not it
spells trouble since the driver has incorrect info on the physical
serial port. In some cases the hardware is disabled so it has no IO
address or IRQ.
If the driver has the wrong IO address it will try to send data to a
non-existing serial port --or even worse, to some other device. If it
has the wrong IRQ the driver will not get interrupt service requests
from the serial port, resulting in a very slow or no response. See
Extremely Slow: Text appears on the screen slowly after long delays. If it has the wrong model of UART there
is also apt to be trouble. To determine if both I0-IRQ pairs are
identical you must find out how they are set in both the driver and
the hardware.
Introduction
What the driver thinks is not necessarily how the hardware is
actually set. If everything works OK then what the driver thinks is
likely correct (set in the hardware) and you don't need to investigate
(unless you're curious or want to become a guru). Ways to determine
what the driver thinks include: boot-time messages
I/O Address & IRQ: Boot-time messages, the
/proc directory "files"
The /proc directory and setserial, and the "setserial" command.
I/O Address & IRQ: Boot-time messages
In many cases your ports will automatically get low-level
configured at boot-time (but not always correctly). To see what is
happening, look at the start-up messages on the screen. Don't neglect
to check the messages from the BIOS before Linux is loaded (no
examples shown here). These BIOS messages may be frozen by pressing
the Pause key. Use Shift-PageUp to scroll back to the messages after
they have flashed by. Shift-PageDown will scroll in the opposite
direction. The dmesg command (or looking at logs in /var/log)
will show some of the messages but they seem to miss important ones
from setserial. Here's an example of the start-up messages (as of mid
1999). Note that ttyS00 is the same as /dev/ttyS0.
At first you see what was detected (but the irq is only a wild guess):
Serial driver version 4.27 with no serial options enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
ttyS02 at 0x03e8 (irq = 4) is a 16550A
Later setserial shows you what was saved, but it's not necessarily
correct either:
Loading the saved-state of the serial devices...
/dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A
/dev/ttyS1 at 0x02f8 (irq = 3) is a 16550A
/dev/ttyS2 at 0x03e8 (irq = 5) is a 16550A
Note that there is a slight disagreement: The first message shows
ttyS2 at irq=4 while the second shows it at irq=5. dmesg may not
display the second message. In most cases the second message is the
correct one. But if your having trouble it may be misleading. Before
reading the explanation of all of this complexity in the rest of this
section, you might just try using your serial port and see if it works
OK. If so it may not be essential to read further.
The second message is from the setserial program being run at
boot-time. It shows what the device driver thinks is the correct
configuration. But this too could be wrong. For example, the irq
could actually be set to irq=8 in the hardware (both messages wrong).
The irq=5 could be there because someone incorrectly put this into a
configuration file (or the like). The fact that Linux sometimes gets
IRQs wrong is because it doesn't by default probe for IRQs. It just
assumes the "standard" ones (first message) or accepts what you told
it when you configured it (second message). Neither of these is
necessarily correct. If the serial driver has the wrong IRQ, the
serial port is very slow or doesn't seem to work at all.
The first message is a result of Linux probing the serial port
addresses but it doesn't probe for IRQs. If a port shows up here it
exists but the IRQ may be wrong. Linux doesn't check IRQs because
doing so is not foolproof. It just assumes the IRQs are as shown
because they are the "standard" values. Your may check them manually
with setserial using the autoconfig and auto_irq
options but this isn't guaranteed to be correct either.
The data shown by the BIOS messages (which you see at first before
Linux is booted) is what is initially set in the hardware. If your
serial port is Plug-and-Play (PnP) then it's possible that "isapnp" or
"setpci" will run and change these settings. Look for messages about
this after Linux starts. The last serial port message shown in the
example above should agree with the BIOS messages (as possibly
modified by isapnp or setpci). If they don't agree then you either
need to change the setting in the port hardware or use setserial to
tell the driver what is actually set in the hardware.
Also, if you have Plug-and-Play (PnP) serial ports, they can only be
found by PnP software unless the IRQ and IO has been set inside the
hardware by Plug-and-Play software. Prior to kernel 2.4 this was a
common reason why the start-up messages did not show a serial port
that physically exists. A PnP BIOS may automatically low-level
configure them. PnP configuring will be explained later.
The /proc directory and setserial
Type "setserial -g /dev/ttyS*". There are some other
ways to find this info by looking at "files" in the /proc directory.
Be warned that there is no guarantee that the same is set in the
hardware.
/proc/ioports will show the IO addresses that the drivers are using.
/proc/interrupts shows the IRQs that are used by drivers of
currently running processes (that have devices open). It shows how
many interrupts have actually be issued.
/proc/tty/driver/serial shows much of the above, plus the
number of bytes that have been received and sent (even if the device
is not now open).
Note that for the IO addresses and IRQ assignments, you are only seeing
what the driver thinks and not necessarily what is actually set in the
hardware. The data on the actual number of interrupts issued and
bytes processed is real however. If you see a large number of
interrupts and/or bytes then it probably means that the device is (or
was) working. But the interrupts might be from another device. If
there are no bytes received (rx:0) but bytes were transmitted (tx:3749
for example), then only one direction of flow is working (or being
utilized).
Sometimes a showing of just a few interrupts doesn't mean that the
interrupt is actually being physically generated by any serial port.
Thus if you see almost no interrupts for a port that you're trying to
use, that interrupt might not be set in the hardware. To view
/proc/interrupts to check on a program that you're currently running
(such as "minicom") you need to keep the program running while you
view it.
Introduction
If it's PCI or ISA PnP then what's set in the hardware has been done
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
completely lost. See
ISA PnP ports,
PCI: What IOs and IRQs have been set?,
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
remain the same with the power off. That's why a PnP port is more
likely to be found in a disabled state than an old non-PnP one.
PCI: What IOs and IRQs have been set?
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". 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
PCI: Enabling a disabled port for how to enable it.
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.
PCI: Enabling a disabled port
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-" (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).
ISA PnP ports
For an ISA Plug-and-Play (PnP) port one may try the pnpdump
program (part of isapnptools). If you use the --dumpregs option
then it should tell you the actual IO address and IRQ set in the port.
It should also find an ISA PnP port that is disabled. The address it
"trys" is not the device's IO address, but a special address used for
communicating with PnP cards.
Finding a port that is not disabled (ISA, PCI, PnP, non-PnP)
Perhaps the BIOS messages will tell you some info before Linux
starts booting. Use the shift-PageUp key to step back thru the
boot-time messages and look at the very first ones which are from the
BIOS. This is how it was before Linux started. Setserial can't
change it but isapnp or setpci can. Starting with kernel 2.4, the
serial driver can make such changes for many (but not all) serial
ports.
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
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
using a DOS program, then it's set at whatever the person who ran that
program set it to.
Exploring via MS Windows (a last resort)
For PnP ports, checking on how it's configured under DOS/Windows
may (or may not) imply how it's under Linux. MS Windows stores its
configuration info in its Registry which is not used by Linux so they
are not necessarily configured the same. If you let a PnP BIOS
automatically do the configuring when you start Linux (and have told
the BIOS that you don't have a PnP operating system when starting
Linux) then Linux should use whatever configuration is in the BIOS's
non-volatile memory. Windows also makes use of the same non-volatile
memory but doesn't necessarily configure it that way.
If you have Plug-and-Play ports then either a PnP BIOS or a
serial driver may configure all your devices for you so then you may
not need to choose any IRQs. PnP software determines what it thinks
is best and assigns them (but it's not always best). But if you
directly use isapnp (ISA bus) or jumpers then you have to choose. If
you already know what IRQ you want to use you could skip this section
except that you may want to know that IRQ 0 has a special use (see the
following paragraph).
IRQ 0 is not an IRQ
While IRQ 0 is actually the timer (in hardware) it has a special
meaning for setting a serial port with setserial. It tells the driver
that there is no interrupt for the port and the driver then will use
polling methods. Such polling puts more load on the CPU but can be
tried if there is an interrupt conflict or mis-set interrupt. The
advantage of assigning IRQ 0 is that you don't need to know what
interrupt is set in the hardware. It should be used only as a
temporary expedient until you are able to find a real interrupt to
use.
Interrupt sharing, Kernels 2.2+
Sharing of IRQs is where two devices use the same IRQ. As a
general rule, this wasn't allowed for the ISA bus. The PCI bus may
share IRQs but one can't share the same IRQ between the ISA and the
PCI bus. Most multi-port boards may share IRQs. Sharing is not as
efficient since every time a shared interrupt is given a check must be
made to determine where it came from. Thus if it's feasible, it's
nicer to allocate every device its own interrupt.
Prior to kernel 2.2, serial IRQs could not be shared with each other
except for most multiport boards. Starting with kernel 2.2 serial
IRQs may be sometimes shared between serial ports. In order for
sharing to work in 2.2 the kernel must have been compiled with
CONFIG_SERIAL_SHARE_IRQ, and the serial port hardware must support
sharing (so that if two serial cards put different voltages on the
same interrupt wire, only the voltage that means "this is an
interrupt" will prevail). Since the PCI bus specs permit sharing, any
PCI card should allow sharing.
What IRQs to choose?
The serial hardware often has only a limited number of IRQs. Also
you don't want IRQ conflicts. So there may not be much of a choice.
Your PC may normally come with ttyS0 and ttyS2 at IRQ 4, and
ttyS1 and ttyS3 at IRQ 3. Looking at
/proc/interrupts will show which IRQs are being used by
programs currently running. You likely don't want to use one of
these. Before IRQ 5 was used for sound cards, it was often used for a
serial port.
Here is how Greg (original author of Serial-HOWTO) set his up in
/etc/rc.d/rc.serial. rc.serial is a file (shell script) which runs at
start-up (it may have a different name or location). For versions of
"setserial" after 2.15 it's not always done this way anymore but this
example does show the choice of IRQs.
/sbin/setserial /dev/ttyS0 irq 3 # my serial mouse
/sbin/setserial /dev/ttyS1 irq 4 # my Wyse dumb terminal
/sbin/setserial /dev/ttyS2 irq 5 # my Zoom modem
/sbin/setserial /dev/ttyS3 irq 9 # my USR modem
Standard IRQ assignments:
IRQ 0 Timer channel 0 (May mean "no interrupt". See below.)
IRQ 1 Keyboard
IRQ 2 Cascade for controller 2
IRQ 3 Serial port 2
IRQ 4 Serial port 1
IRQ 5 Parallel port 2, Sound card
IRQ 6 Floppy diskette
IRQ 7 Parallel port 1
IRQ 8 Real-time clock
IRQ 9 Redirected to IRQ2
IRQ 10 not assigned
IRQ 11 not assigned
IRQ 12 not assigned
IRQ 13 Math coprocessor
IRQ 14 Hard disk controller 1
IRQ 15 Hard disk controller 2
There is really no Right Thing to do when choosing interrupts. Try to
find one that isn't being used by the motherboard, or any other
boards. 2, 3, 4, 5, 7, 10, 11, 12 or 15 are possible choices. Note
that IRQ 2 is the same as IRQ 9. You can call it either 2 or 9, the
serial driver is very understanding. If you have a very old serial
board it may not be able to use IRQs 8 and above.
Make sure you don't use IRQs 1, 6, 8, 13 or 14! These are used by
your motherboard. You will make her very unhappy by taking her IRQs.
When you are done you might want to double-check
/proc/interrupts when programs that use interrupts are being
run and make sure there are no conflicts.
Here's a problem with some old serial cards. The IO address of
the IBM 8514 video board (and others like it) is allegedly 0x?2e8
where ? is 2, 4, 8, or 9. This may conflict with the IO address of
ttyS3 at 0x02e8. Your may think that this shouldn't happen since
the addresses are different in the high order digit (the leading 0 in
02e8). You're right, but a poorly designed serial port may ignore the
high order digit and respond to any address that ends in 2e8. That is
bad news if you try to use ttyS3 (ISA bus) at this IO address.
For the ISA bus you should try to use the default addresses shown
below. PCI cards use different addresses so as not to conflict with
ISA addresses. The addresses shown below represent the first address
of an 8-byte range. For example 3f8 is really the range 3f8-3ff.
Each serial device (as well as other types of devices that use IO
addresses) needs its own unique address range. There should be no
overlaps (conflicts). Here are the default addresses for commonly
used serial ports on the ISA bus:
ttyS0 address 0x3f8
ttyS1 address 0x2f8
ttyS2 address 0x3e8
ttyS3 address 0x2e8
Suppose there is an address conflict (as reported by setserial -g
/dev/ttyS*) between a real serial port and another port which
does not physically exist (and shows UART: unknown). Such a conflict
shouldn't cause problems but it sometimes does in older kernels. To
avoid this problem don't permit such address conflicts or delete
/dev/ttySx if it doesn't physically exist.
After it's set in the hardware don't forget to insure that it also
gets set in the driver by using setserial. For non-PnP serial
ports they are either set in hardware by jumpers or by running a DOS
program ("jumperless") to set them (it may disable PnP). The rest of
this subsection is only for PnP serial ports. Here's a list of the
possible methods of configuring PnP serial ports:
- Using a PnP BIOS CMOS setup menu
(usually only for external
modems
on ttyS0 (Com1) and ttyS1 (Com2))
- Letting a PnP BIOS automatically configure a PnP serial port
See
Using a PnP BIOS to I0-IRQ Configure
- Doing nothing if the serial driver recognized your card OK
- Using
isapnp for a PnP serial port non-PCI)
- Using setpci (pciutils or pcitools) for the PCI bus
The IO address and IRQ must be set (by PnP) in their registers each
time the system is powered on since PnP hardware doesn't remember how
it was set when the power is shut off. A simple way to do this is to
let a PnP BIOS know that you don't have a PnP OS and the BIOS will
automatically do this each time you start. This might cause problems
in Windows (which is a PnP OS) if you start Windows with the BIOS
thinking that Windows is not a PnP OS. See Plug-and-Play-HOWTO.
Plug-and-Play (PnP) was designed to automate this io-irq configuring,
but for Linux it initially made life much more complicated. In modern
Linux (2.4 kernels --partially in 2.2 kernels), each device driver has
to do it's own PnP (using supplied software which it may utilize).
There is unfortunately no centralized planning for assigning IO
addresses and IRQs as there is in MS Windows. But it usually works
out OK in Linux anyway.
Using a PnP BIOS to I0-IRQ Configure
While the explanation of how to use setpci or isapnp for io-irq
configuring should come with such software, this is not the case if
you want to let a PnP BIOS do such configuring. Not all PnP BIOS can
do this. The BIOS usually has a CMOS menu for setting up the first
two serial ports. This menu may be hard to find. For an "Award"
BIOS it was found under "chipset features setup" There is often
little to choose from. For ISA serial ports, the first two ports
normally get set at the standard IO addresses and IRQs. See
More on Serial Port Names
Whether you like it or not, when you start up a PC, a PnP BIOS starts
to do PnP (io-irq) configuring of hardware devices. It may do the job
partially and turn the rest over to a PnP OS (which Linux is in some
sense) or if thinks you don't have a PnP OS it may fully configure all
the PnP devices but not configure the device drivers.
If you tell the BIOS that you don't have a PnP OS, then the PnP BIOS
should do the configuring of all PnP serial ports --not just the first
two. An indirect way to control what the BIOS does (if you have
Windows 9x on the same PC) is to "force" a configuration under
Windows. See Plug-and-Play-HOWTO and search for "forced". It's
easier to use the CMOS BIOS menu which may override what you
"forced" under Windows. There could be a BIOS option that can set or
disable this "override" capability.
If you add a new PnP device, the BIOS should PnP configure it. It
could even change the io-irq of existing devices if required to avoid
any conflicts. For this purpose, it keeps a list of non-PnP devices
provided that you have told the BIOS how these non-PnP devices are
io-irq configured. One way to tell the BIOS this is by running a
program called ICU under DOS/Windows.
But how do you find out what the BIOS has done so that you set up the
device drivers with this info? The BIOS itself may provide some info,
either in its setup menus of via messages on the screen when you turn
on your computer. See
What is set in my serial port hardware?. Other ways of finding out is to use lspci for
the PCI bus or isapnp --dumpregs for the ISA bus. The cryptic results
it shows you may not be clear to a novice.
Once you've set the IRQ and IO address in the hardware (or arranged
for it to be done by PnP) you also need to insure that the "setserial"
command is run each time you start Linux. See the subsection
Boot-time Configuration
This configuring is normally done by your communications program
such as wvdial. It may do much of it without even letting you know what
it's done. In olden days it was done with the "stty" utility. If you
set something manually with stty, the communications program may
change the setting to something else so it's usually best to just let
the communications program handle it. See
What is stty ?
See
Flow Control for an explanation of
it. You should always use hardware flow control if possible. Your
communication program or "getty" should have an option for
setting it (and hopefully it's enabled by default). It needs to be
set both inside your modem (by an init string or default) and in the
device driver. Your communication program should set both of these
(if you configure it right).
If none of the above will fully enable hardware flow control. Then
you must do it yourself. For the modem, make sure that it's either
done by the init string or is on by default. If you need to tell the
device driver to do it is best done on startup by putting it in a file
that runs at boot-time. See the subsection
Boot-time Configuration You need to add the following to such
a file for each serial port (example is ttyS2) you want to enable
hardware flow control on:
stty -F /dev/ttyS2 crtscts
or
stty crtscts < /dev/ttyS2
If you want to see if flow control is enabled do the following: In
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). Remember that communication
programs change these settings so you may want to check them after you
have started up your communication program.
Besides flow control there is speed. See
What Speed Should I Use with My Modem. There's also are
parity and bits-per-byte settings. Normally the port is set by the
communications program at 8N1 (8-bits per byte, No parity, and 1 stop
bit). If you're running PPP then you must use 8N1. So if you get a
complaint that it's not 8-bit clean then it's likely not 8N1 like it
should be.
If the modem is not sending a CD signal and clocal is disabled
(stty shows -clocal) then a program may not be able to open the serial
port. If the port can't open, the program may just hang, waiting
(often in vain) for a CD signal from the modem. Actually, a skilled
programmer can write the program in such a way as to force the port to
open even when CD and -clocal say not to so it's not always a problem.
One way to avoid any possible problems is to send "AT&C" to the
modem so that CD from the modem will always be on. CD always-on is
fine for dial-out but for dial-in the CD signal is sometimes (but
rarely) used to detected an incoming call.
Minicom sets clocal automatically when it starts up so there is no
problem. But version 6.0.192 of Kermit hung when I set -clocal and
tried to "set line ...".
Here's a problem that existed prior to the year 2000 or thereabouts.
It's since been fixed. If -clocal is set and there is no CD signal,
then the "stty" command will hang and there is seemingly no way to set
clocal (except by running minicom). But minicom will restore -clocal
when it exits. One way to get out of this is to use minicom to send
the "AT&C" to the modem (to get the CD signal) and then exit
minicom with no reset so that the CD signal always remains on. Then
you may use stty again.
stty is something like setserial but it sets the speed (baud
rate), hardware flow control, and other parameters of a serial port.
Typing "stty -F /dev/ttyS2 -a" should show you how ttyS2 is
configured. Most of the stty settings are for things that you never
need to use with modems. Many of the setting are only needed for
Text-Terminals (and some are only needed for antique terminals of the
1970s). Your communication package should automatically set up the
several settings needed for modems. For this reason you normally don't
need to use stty so it's not covered much in this Modem-HOWTO. But
stty is sometimes useful for trouble-shooting. More is said about
stty in the Serial-HOWTO or Text-Terminal-HOWTO..
<
