LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

updated

This commit is contained in:
gferg 2001-08-14 22:45:16 +00:00
parent 01a9ceb0c9
commit 884071f8fb
4 changed files with 677 additions and 410 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

377
LDP/howto/linuxdoc/Modem-HOWTO.sgml
View File

@ -3,11 +3,12 @@
<title> Modem-HOWTO </title>
<author>David S.Lawyer
<tt><url url="mailto:dave@lafn.org"></tt>
<date> v0.19, July 2001
<date> v0.20, August 2001
<!--
Change log: + => added more info ++ => added new topic
v0.20 August 2001: fixed typo: done->down, more linmodems
v0.19 July 2001: Dialing Out while Waiting for a Call. Antique modems
using "CONNECT" to set DTE speed.
v0.18 June 2001 new section: modem doubling (bonding, teaming, multilink)
@ -164,12 +165,14 @@ modem situation is rapidly changing (and since I'm still learning).
Your problem might be solved in the latest version. It will be
available to browse and/or download at LDP mirror sites. For a list
of such sites see: <url url="http://www.linuxdoc.org/mirrors.html">
If you only want to quickly compare the date of this the version v0.19, July 2001
If you only want to quickly compare the date of this the version v0.20, August 2001
with the date of the latest version go to:
<url url="http://www.linuxdoc.org/HOWTO/Modem-HOWTO.html">
<sect1> New in Recent Versions
<p>v0.19 July 2001: Dialing Out while Waiting for a Call. Antique modems
<p>
v0.20 August 2001: fixed typo: done->down, more linmodems
v0.19 July 2001: Dialing Out while Waiting for a Call. Antique modems
using "CONNECT" to set DTE speed.
v0.18 June 2001 new section: modem doubling (bonding, teaming,
multilink)<newline>
@ -227,9 +230,9 @@ need to check the BIOS setup menu to determine this. Plug in the
power cord to provide power to the modem. See <ref id="all_modems"
name="All Modems"> for further instructions.
<sect2> Internal Modems (Both ISA and PCI)
<sect2> Internal Modems (ISA, PCI and AMR)
<p> The first thing to do is to make sure that the modem will work
under Linux since (as of late 2000) most newer modems don't. See <url
under Linux since (as of 2001) many modems don't. See <url
url="http://www.idir.net/~gromitkc/winmodem.html" name="modem list">.
If the modem is both PnP and directly supported by the serial driver
(kernel 2.4 +) then there is no configuring for you to do since the
@ -243,7 +246,7 @@ 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).
size).
If you have a modem that is not a winmodem (see <ref id="soft_modem"
name="Software-based Modems (winmodems)">) the serial driver may
@ -273,10 +276,11 @@ say). 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.
<sect2> PCI Modems: What IOs and IRQs have been set?
<p> For PCI, the BIOS almost always sets the IRQ and may set the
IO address as well. To see how it's set use "lspci -v" or look in
/proc/bus/pci. If more than one IO address is shown, the first one is
<sect2> PCI (and AMR) Modems: What IOs and IRQs have been set?
<p> For PCI, the BIOS almost always sets the IRQ and may set the IO
address as well. To see how it's set use "lspci -v" (best) or look in
/proc/bus/pci. The modem's serial port is called a "Communication
controller". If more than one IO address is shown, the first one is
more likely to be it. You can't change the IRQ (at least not with
"setpci") If you must, change the IO address with "setpci" by
changing the BASE_ADDRESS_0 or the like. The _0 (or _1) after
@ -307,15 +311,16 @@ that came with the modem.
communication program such as minicom or a ppp program (such as
wvdial). Set the serial port speed to a baud rate a few times higher
than the bit rate of your modem. See <ref id="speed_table"
name="Speed Table"> for the "best" speeds to use. Tell it the full
name of your serial port such as /dev/ttyS1. Set hardware flow
control (RTS/CTS).
name="Speed Table"> for more details on the "best" speeds to use.
Tell it the full name of your serial port such as /dev/ttyS1. Set
hardware flow control (RTS/CTS).
Minicom is the easiest to set up and to use to test your modem. But
if you are lucky you may get ppp to work the first time and not need
to bother with minicom. With minicom you may simply type the command:
AT and hit enter (before dialing) to check that your modem is there
and responds with OK.
to bother with minicom. 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 direct from the modem.
<sect> Modems for a Linux PC
<sect1> External vs. Internal <label id="int_vs_ext">
@ -336,20 +341,23 @@ computer.
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 costs you about $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 1998 and late 2000 most new internal modems
don't either --but some do). If a new internal modem had say a 16650
UART it would put less load on the CPU.
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 1998 and late 2000 most new
internal modems don't either --but some do). If a new internal modem
had say a 16650 UART it would put less load on the CPU.
Internal modems present a special problem for Linux, but will work
just as well as external modems provided you avoid the high percentage
of them that will work only for MS Windows, and also provided that you
spend time (sometimes a lot of time) to configure them correctly.
Some of the modems which will work only under MS Windows are,
unfortunately, not labeled as such. If you buy a new one, make sure
that you can return it for a refund if it will not work under Linux.
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 which will work only under MS
Windows due to lack of Linux 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:
@ -358,19 +366,17 @@ with the PnP configuring:
<item> Use the "isapnp" program
<item> Let a PnP BIOS do the configuring
</itemize>
Each of the above has 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 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 <ref id="io-irq_in_hdw" name="What is set
in my serial port hardware?">.
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 <ref
id="io-irq_in_hdw" name="What is set in my serial port hardware?">.
There are many Linux users that say that it's a lot simpler just to
get an external modem and plug it in. But since new peripherals are
PnP today, you will sometime need to deal with it, so why delay the
inevitable? Still, the most expedient (and expensive) solution is an
external modem (if you have a free serial port).
In the late 1990s many Linux users said 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.
<sect1> External Modems
<sect2> PnP External Modems
@ -386,11 +392,12 @@ 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 model number. Then you might not need to
port and would also know the id number. Then you might not need to
configure application programs by telling them what port the modem is
on (such as /dev/ttyS2 or COM3). But since you don't have such a PnP
operating system you will need to configure your application program
manually by giving it the /dev id (such as /dev/ttyS2).
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.
<sect2> Cabling & Installation
<p> Connecting an external modem is simple compared to connecting
@ -403,7 +410,7 @@ 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.
<sect2> What the Lights (LED's) Mean (for some modems)
<sect2> What the Lights (LED's) Mean (for some external modems)
<p>
<itemize>
<item> TM Test Modem
@ -435,17 +442,19 @@ 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), or by newer serial device drivers for certain modems. Under
Linux you have a choice of how to configure the ones that don't get
io-irq configured by the serial driver.
bus only), 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.
<enum>
<item> Use "isapnp" which may be run automatically at every boot-time
<item>ISA bus modems: Use "isapnp" which may be run automatically at
every boot-time
<item> Let a PnP BIOS do it, and then maybe tell setserial the IO and
IRQ
</enum>
<sect1> Software-based Modems (winmodems) <label id="soft_modem">
<sect1> Software-based Modems (winmodems, linmodems)
<label id="soft_modem">
<sect2> Introduction software modems (winmodems)
<p> 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
@ -464,22 +473,44 @@ A third 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 winmodems and would
work only for MS Windows.
work only for MS Windows. That situation is changing.
<sect2> Linmodems
<p> Finally in late 1999 two software-based modems appeared that could
work under Linux and were sometimes called "linmodems". Lucent
Technologies (LT) unofficially released a Linux binary-only code to
support its PCI modems. PC-TEL (includes "Zoltrix") introduced a new
software-based modem for Linux. There is a GPL'ed driver being
developed for the Modem Silicon Operation MD563X HaM chipset (nee
support most of its PCI modems. PC-TEL (includes "Zoltrix")
introduced a new software-based modem for Linux. There is a GPL'ed
driver for Intel's (Modem Silicon Operations) MD563x HaM chipset (nee
Ambient division of Cirrus Logic). Will other companies follow these
leads and thus create "linmodems"? For a list of modems which
work/don't_work under Linux see <url
leads and thus create "linmodems"? Yes. As of mid-2001 there are
drivers for: Conexant HSF, Motorola SM56, ESS (ISA only), and IBM's
Mwave for Thinkpads 600+.
What percent of winmodems now (2001) work under Linux? Well, there's
a lot of modem chips not supported: Lucent/Agere ARM (Scorpio),
3COM/US Robotics, Conexant HCF, some SmartLink (3 different chipsets),
Ambient HSP, and possibly others. But there may be some support for
these by the time you read this. So over half the chips seem to be
supported. But what percentages of such chips sold will work with
Linux? I'm guessing it's somewhat over 50%. Let me know if you find
an estimate.
For a list of modems which work/don't_work under Linux see <url
url="http://www.idir.net/~gromitkc/winmodem.html" name="modem list">.
Links to "linmodem" drivers may also be found there. A project to get
winmodems to work under Linux is at <url url="http://linmodems.org">.
They also have a mailing list.
They also have a mailing list.
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 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.
There is some effort underway at reverse-engineering with at least one
report of a winmodem that has been made to work under Linux (but not
@ -517,11 +548,12 @@ computer.
The difference between the two types of software-based modems is where
these digital waveshapes are processed (generated and interpreted).
In the all-software modem this waveshape processing 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 (data
compression, AT-commands, etc.) For example the Rockwell HCF (Host
Controlled Family) does this. If the software that does these tasks
could be ported to Linux and then there wouldn't be a major problem.
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
(data compression, AT-commands, etc.) For example the Rockwell HCF
(Host Controlled Family) does this. If the software that does these
tasks could be ported to Linux and then there wouldn't be a major
problem.
<sect2> Is this modem a software modem?
<p> How do you determine if an internal modem will work under Linux?
@ -543,32 +575,38 @@ If it requires a Pentium CPU, then almost all of it's work is done by
software and it's not likely to work under Linux. If it requires a
486 CPU (or better) then it's likely a host-controlled modem that will
work only if there exists a Linux driver for it. Saying that it only
works with Windows is also bad news.
works with Windows is also bad news. However, even in this case there
may be a Linux driver for it.
Otherwise, it may work under Linux (without a driver) 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.
Otherwise, it may work under Linux 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.
<sect2> Should I get a software modem?
<p> 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
much of its work, the software modem requires less on-board
electronics and thus costs less. At the same time, the CPU is heavily
loaded by the modem which may result in slower operation. This is
especially true if other CPU-intensive tasks are running at the same
time the modem is being used. Of course when you're not using the
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. In most other cases, 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 cost savings worth it? In some cases yes, especially if you
seldom use the modem and/or are not running any other CPU intensive tasks
when the modem is in use. Thus there are cases where use of a
software modem is economically justified. The savings in modem cost
Is the 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
@ -578,20 +616,30 @@ CPU :-).
<sect1> PCI Modems <label id="PCIm">
<p> A PCI modem card is one which inserts into a PCI-bus slot on the
motherboard of a PC. While most PCI winmodems will not work under
Linux (no driver available) other PCI modems mostly work under Linux.
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 is being modified to support certain PCI modem
cards (but not winmodems). If the Linux serial driver supports it
then the driver will set up the PnP configuration for you. See <ref
id="PCI_ser_conf" name="PCI Bus Support Underway"> If no special
support is in the Linux serial driver but it may still work OK but you
support is in the Linux serial driver it may still work OK but you
have to do some work to configure it.
<sect1>AMR Modems
<p>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.
<sect1> Which Internal Modems might not work with Linux <label id="m_to_avoid">
<p>
<itemize>
<item> <ref id="soft_modem" name="Software-based Modems (winmodems)">
only work in rare cases where a Linux driver is available.
Only roughly half have a Linux driver available.
<item> <ref id="dsp_" name="MWave and DSP Modems"> might work, but only if
you first start Windows/Dos each time you power on your PC
<item> Modems with <ref id="rpi_" name="RPI (Rockwell)"> drivers work
@ -599,19 +647,22 @@ have to do some work to configure it.
</itemize>
<sect2> MWave and DSP Modems <label id="dsp_">
<p> Such modems use DSP's (Digital Signal Processors) which are
programmed by driver which must be downloaded from the hard disk to
the DSP's 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.
<p> Note that there's now a Linux driver for the ACP (Mwave) modem
used in IBM Thinkpads 600+. See the mini-HOWTO: ACP-Modem.
Such modems use DSPs (Digital Signal Processors) which are programmed
by 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. This is not a "DSP modem" in the sense of this section. An
example of a DSP modem is IBM's Aptiva MWAVE.
example of a DSP modem is the old IBM's Aptiva MWAVE.
If a DSP modem modem simulates a serial port, then it may be usable
with Linux provided you're willing/able to boot from DOS. You must
@ -746,6 +797,7 @@ products here so please do comparison shopping before buying anything.
Nov. '99: 2 serial drivers concurrently NG
Sept. '00: data flow diagram
Dec. '00 flow control +
July "01 done -> down
-->
<!-- ifdef MODEM_ -->
<p> You don't have to understand the basics to use and install a
@ -1066,7 +1118,7 @@ id="speed_" name="What Speed Should I Use">.
<sect1> Flow Control <label id="flow_control">
<p> Flow control means the ability to slow done the flow of bytes in a
<p> Flow control means the ability to slow down the flow of bytes in a
wire. For serial ports this means the ability to stop and then
restart the flow without any loss of bytes. Flow control is needed
for modems to allow a jump in instantaneous flow rates.
@ -1624,11 +1676,12 @@ which are from the BIOS. This is how it was before Linux started.
Setserial can't change it but isapnp or pciutils can and starting with
kernel 2.4, these will be built into the serial driver.
One crude method is try probing with setserial using the "autoconfig"
option. You'll need to guess the addresses to probe at. See <ref
id="set_serial" name="What is Setserial">. For a PCI serial port, use
the "lspci" command (for kernels &lt;2.2 look at /proc/pci). If your
serial port is is Plug-and-Play see the next two subsections.
Using "scanport" will probe all I/O ports and will indicate what it
thinks may be serial port. After this you could try probing with
setserial using the "autoconfig" option. You'll need to guess the
addresses to probe at (using clues from "scanport"). See <ref
id="set_serial" name="What is Setserial">. If your
serial port is is ISA Plug-and-Play or PCI see the next two subsections.
For a port set with jumpers, its how the jumpers were set. If the
port is not Plug-and-Play (PnP) but has been setup by using a DOS
@ -1643,20 +1696,23 @@ can reach a state where it doesn't have any IO address or IRQ and is
in effect disabled. It should still be possible to find the port
using the <tt/pnpdump/ program.
For Plug-and-Play (PnP) on the ISA bus one may try the <tt/pnpdump/
For a PCI serial port, use the "lspci" command (for kernels &lt;2.2
look at /proc/pci).
For an ISA Plug-and-Play (PnP) port one may try the <tt/pnpdump/
program (part of <tt/isapnptools/). If you use the --dumpregs option
then it should tell you the actual IO address and IRQ set in the port.
The address it "trys" is not the device's IO address, but a special
For PnP ports checking on how it's configured under DOS/Windows may not
be of much help. Windows stores its configuration info in its
Registry which is not used by Linux. It may supply the BIOS's
non-volatile memory with some info but it may not be kept in sync with
the current Window configuration in the Registry ?? If you let a PnP
BIOS automatically do the configuring when you start Linux (and have
told the BIOS that you don't have a PnP operating system when running
For PnP ports, checking on how it's configured under DOS/Windows may
(or may not) imply how it's under Linux. 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.
non-volatile memory. Windows also makes use of the same non-volatile
memory but doesn't necessarily configure it that way.
<sect1>Choosing Serial IRQs <label id="choose_IRQ">
@ -2374,15 +2430,15 @@ In fact, you can run "setserial" and assign a purely fictitious I/O
port address, any IRQ, and whatever uart type you would like to have.
Then the next time you type "setserial ..." it will display these
bogus values without complaint. They will also be officially
registered with the kernel as seen by the "scanport" command.
Of course the serial port driver will not work correctly (if at all)
if you attempt to use such a port. Thus when giving parameters to
"setserial" anything goes. Well almost. If you assign one port a
base address that is already assigned (such as 3e8) it will not accept
it. But if you use 3e9 it will accept it. Unfortunately 3e9 is
already assigned since it is within the range starting at base address
3e8. Thus the moral of the story is to make sure your data is correct
before assigning resources with setserial.
registered with the kernel as displayed (at the top of the screen) by
the "scanport" command. Of course the serial port driver will not
work correctly (if at all) if you attempt to use such a port. Thus
when giving parameters to "setserial" anything goes. Well almost. If
you assign one port a base address that is already assigned (such as
3e8) it will not accept it. But if you use 3e9 it will accept it.
Unfortunately 3e9 is already assigned since it is within the range
starting at base address 3e8. Thus the moral of the story is to make
sure your data is correct before assigning resources with setserial.
While assignments made by setserial are lost when the PC is powered
off, a configuration file may restore them (or a previous
@ -2395,7 +2451,13 @@ name="Configuration Scripts/Files">
<sect2> Probing <label id="probing_ss">
<p> With appropriate options, <tt/setserial/ can probe (at a given I/O
<p>Prior to probing with "setserial", one may run the "scanport"
command to check all possible ports in one scan. It makes crude
guesses as to what is on some ports but doesn't determine the IRQ. But
it's a fast first start. It may hang your PC but so far it's worked
fine for me.
With appropriate options, <tt/setserial/ can probe (at a given I/O
address) for a serial port but you must guess the I/O address. If you
ask it to probe for /dev/ttyS2 for example, it will only probe at the
address it thinks ttyS2 is at (2F8). If you tell setserial that ttyS2
@ -2406,11 +2468,12 @@ The purpose of this is to see if there is a uart there, and if so,
what its IRQ is. Use "setserial" mainly as a last resort as there are
faster ways to attempt it such as wvdialconf to detect modems, looking
at very early boot-time messages, or using <tt>pnpdump
--dumpregs</tt>. To try to detect the physical hardware use the -v
(verbose) and <tt/autoconfig/ command to <tt/setserial/. If the
resulting message shows a uart type such as 16550A, then you're OK.
If instead it shows "<tt/unknown/" for the uart type, then there is
supposedly no serial port at all at that I/O address. Some cheap
--dumpregs</tt>. To try to detect the physical hardware use for
example :<newline>
<tt>setserial /dev/ttyS2 -v autoconfig</tt><newline>
If the resulting message shows a uart type such as 16550A, then you're
OK. If instead it shows "<tt/unknown/" for the uart type, then there
is supposedly no serial port at all at that I/O address. Some cheap
serial ports don't identify themselves correctly so if you see
"<tt/unknown/" you still might have a serial port there.
@ -2418,15 +2481,15 @@ Besides auto-probing for a uart type, setserial can auto-probe for
IRQ's but this doesn't always work right either. In one case it first
gave the wrong irq but when the command was repeated it found the
correct irq. In versions of setserial >= 2.15, the results of your
last probe test may be saved and put into the configuration file
<tt>/etc/serial.conf</tt> which will be used next time you start
Linux. At boot-time when the serial module loads (or the like), a
probe for UARTs is made automatically and reported on the screen. But
the IRQs shown may be wrong. The second report of the same is the
result of a script which usually does no probing and thus provides no
reliable information as to how the hardware is actually set. It only
shows configuration data someone wrote into the script or data that
got saved in /etc/serial.conf.
last probe test could be automatically saved and put into the
configuration file <tt>/etc/serial.conf</tt> which will be used next
time you start Linux. At boot-time when the serial module loads (or
the like), a probe for UARTs is made automatically and reported on the
screen. But the IRQs shown may be wrong. The second report of the
same is the result of a script which usually does no probing and thus
provides no reliable information as to how the hardware is actually
set. It only shows configuration data someone wrote into the script
or data that got saved in /etc/serial.conf.
It may be that two serial ports both have the same IO address set in
the hardware. Of course this is not permitted but it sometimes
@ -2435,6 +2498,7 @@ are two. However if they have different IRQs, then the probe for IRQs
may show IRQ = 0. For me it only did this if I first used
<tt/setserial/ to give the IRQ a ficticious value.
<sect2> Boot-time Configuration <label id="sets_boot_time">
<p> When the kernel loads the serial module (or if the "module
equivalent" is built into the kernel) then only <tt/ttyS{0-3}/ are
@ -3640,26 +3704,26 @@ different speeds, then they couldn't communicate with each other.
<!-- high_speed.H begin In Serial and Modem HOWTOs but some of the speed
section is unique to each HOWTO.
-->
<p> You need to find out the highest speed supported by your hardware.
As of late 1998 most serial ports only supported speeds up to 115.2k
bps but as of 2001, most support higher speeds. Some 56k internal
modems support 230.4k bps (but it may be hard to find out which ones
do). Recent Linux kernels support high speeds (over 115.2k) but you
might have some problems using it because of one or both of the
following reasons:
<sect2> Speeds over 115.2k
<p> The top speed of 115.2k has been the standard speed since the
mid 1990's. By the year 2000, many serial ports supported higher
speeds but Linux seldom used them due to lack of drivers. These
high-speed ports by default only support 115.2k and must have special
software to enable the higher speeds. Today (2001) almost all new
serial ports support speeds of 230.4k and 460.8k. Some also support
921.6k. Unfortunately, to get these speeds you need to compile the
kernel with a special patch and it seems the patch doesn't support the
2.4 kernels yet.
<enum>
<item> It may require a special driver or a patch to the serial driver
<item> Older versions of an application program (or stty) may not
support the high speed.
<item> Setserial may show the wrong speed unless you use the baud_base
option. Even so, high speed will still work but the reported speed
will be wrong.
</enum>
For internal modems, only a minority of them advertise that they
support speeds of over 115.2k for their built-in serial ports.
Will shsmod support these ??
To support the higher speeds you may get a shsmod (Super High Speed)
patch for the serial driver. There is also a module for the VIA
VT82C686 chip <url url="www.kati.fi/viahss/">.
The patch to support high-speed is called shsmod (Super High Speed).
There are both Windows and Linux versions of this patch. See <url
url="http://www.devdrv.com/shsmod">. For Linux, much of the
documentation is only in Japanese. There is also a module for the
VIA VT82C686 chip <url url="www.kati.fi/viahss/">.
<sect2> How speed is set in hardware: the divisor and baud_base <label
id="divisor_">
@ -3752,12 +3816,11 @@ lower so long as it's above the modem speed.
<sect>Communications Programs And Utilities<label id="comms">
<p> While PPP is used for Internet access you also need a dialer
program that is designed to work with PPP. Such a dialer program will
dial a phone number. When the other side answers the phone then three
things happen: PPP is started at both ends and you get logged in
(often automatically). The exact sequence of these 3 events may vary.
Dialer programs for ppp include wvdial, chap scripts, kppp, and
gnome-ppp.
program (or script) that will work with PPP. Such a dialer program
will dial a phone number. When the other side answers the phone then
three things happen: PPP is started at both ends and you get logged in
automatically. The exact sequence of these 3 events may vary. Dialer
programs for ppp include wvdial, chap scripts, kppp, and gnome-ppp.
There are also other dialer programs which can dial out directly (thru
a modem) to local libraries, etc. This isn't the Internet.

59
LDP/howto/linuxdoc/Plug-and-Play-HOWTO.sgml
View File

@ -3,10 +3,11 @@
<title> Plug-and-Play-HOWTO </title>
<author>David S.Lawyer
<tt><url url="mailto:dave@lafn.org"></tt>
<date> v1.02, July 2001
<date> v1.03, August 2001
<!--
Change log:
v1.03 August 2001: error messages, boot-prompt parameters
v1.02 July 2001: PCI config regs.
v1.01 April 2001: less shortage today of bus-resouces, clarity in sect. 2,
Windows 2000 OK (even if "not a PnP OS" in CMOS)
@ -111,12 +112,16 @@ url="http://linuxdoc.org/mirrors.html">. Various formats are
available. If you only want to quickly check the date of the latest
version look at: <url
url="http://linuxdoc.org/HOWTO/Plug-and-Play-HOWTO.html">. The
version you are now reading is: v1.02, July 2001 .
version you are now reading is: v1.03, August 2001 .
<sect1> New in Recent Versions
<p> v1.02 July 2001: PCI config regs. v1.01 April 2001: less shortage
<p>
v1.03 August 2001: error messages, boot-prompt parameters
v1.02 July 2001: PCI config regs. v1.01 April 2001: less shortage
today of bus-resources, clarity in sect. 2, Windows 2000 OK (even if
"not a PnP OS" in CMOS)
v1.01 April 2001: less shortage today of bus-resources, clarity in sect. 2,
Windows 2000 OK (even if "not a PnP OS" in CMOS)
The version 1.0 (Nov. 2000) was long overdue and recognized that the
kernel is doing more in helping device drivers set up PnP. Kernel 2.4
@ -1155,10 +1160,10 @@ name="PnP driver project">
<sect1> Introduction
<p> Just how this is done depends upon the driver. Some drivers have
more than one way to find out how their physical device is configured.
At one extreme is the case where you must hard-code the bus-resources into
the kernel and recompile. At the other extreme, the driver does
everything automatically and you have nothing to do. It may even set
the bus-resources in the hardware using PnP methods.
At one extreme is the case where you must hard-code the bus-resources
into the kernel (or a module) and recompile. At the other extreme,
the driver does everything automatically and you have nothing to do.
It may even set the bus-resources in the hardware using PnP methods.
In the middle are cases where you run a program to give the resource
info to the driver or put the info in a file. In some cases the
@ -1169,13 +1174,23 @@ driver may use PnP methods to find the device and how the bus-resources
have been set, but will not actually set them. It may also look in
some of the files in the /proc directory.
One may need to give the bus-resources as a parameter to the kernel or to
a loadable module. See /usr/lib/modules_help/descr.gz for a list of
possible parameters. The module to load is listed in /etc/modules
along with its parameters. In some other case the bus-resources may be
given as parameters to the kernel. These are put into the lilo.conf
file as append="...". Then the lilo program must be run to save this
in the kernel boot code.
One may need to "manually" tell a driver what bus-resources it should
use. You give such bus-resources as a parameter to the kernel or to a
loadable module. If the driver is built into the kernel, you pass the
parameters to the kernel via the "boot-prompt". See The
Boot-Prompt-HOWTO which describes some of the bus-resource and other
parameters. Once you know what parameters to give to the kernel, one
may put them into lilo.conf file as append="...". Then the lilo
program must be run to get this info into the kernel loader.
If the driver is loaded as a module, you may need to give
bus-resources as parameters to the module. In some versions of Linux
/usr/lib/modules_help/descr.gz shows a list of possible module
parameters. Parameters to a module (including ones that automatically
load) may be specified in /etc/modules.conf. There are usually tools
used to modify this file which are distribution-dependent. A comment
in this file should help regarding how to modify it. Also, any module
your put in /etc/modules will get loaded along with its parameters.
While there is great non-uniformity about how drivers find out about
bus-resources, the end goal is the same. If you're having problems
@ -1343,7 +1358,21 @@ cases both Windows and Linux simply accept what the BIOS has set. But
where Windows and/or Linux do the configuring, they may do it
differently. So don't count on devices being configured the same.
<sect> Appendix
<sect>Error Messages
<sect1> Unexpected Interrupt
<p> This means that an interrupt happened that no driver expected.
It's unlikely that the hardware issued an interrupt by mistake. It's
more likely that the software has a minor bug and doesn't realize that
some software did something to cause the interrupt. In many cases you
can safely ignore this error message, especially if it only happens
once or twice at boot-time. For boot-time messages, look at the
messages which are nearby for a clue as to what is going on. For
example, if probing is going on, perhaps a probe for a physical device
caused that device to issue an interrupt that the driver didn't
expect. Perhaps the driver wasn't listening for the correct IRQ
number.
<sect>Appendix
<sect1> Universal Plug and Play (UPnP) <label id="UPnP_">
<p> This is actually a sort of network plug-and-play developed by
Microsoft but usable by Linux. You plug something into a network and

188
LDP/howto/linuxdoc/Serial-HOWTO.sgml
View File

@ -4,9 +4,11 @@
<author>David S.Lawyer
<tt><htmlurl url="mailto:dave@lafn.org" name="dave@lafn.org"></tt>
original by Greg Hankins
<date>v2.12, July 2001
<date> v2.13 August 2001
<!-- Change log:
v.2.13 August 2001: fixed typos: done->down and "is is", USRT chip,
synchronous defined better
v2.12 July 2001 serial printing under LPRng
v2.11 May 2001: stty 0 => hangup (was ok in v2.08. )
v2.10 Feb 2001: EIA-485, frame errors on networks, gkermit, firewire
@ -118,9 +120,11 @@ sites see: <url url="http://metalab.unc.edu/LDP/mirrors.html">.
Various formats are available. If you only want to quickly check the
date of the latest version look at <url
url="http://www.linuxdoc.org/HOWTO/Serial-HOWTO.html"> and compare
it to this version: v2.12 July 2001 . New in recent versions:<newline>
it to this version: v2.13 August 2001 . New in recent versions:<newline>
v.2.13 August 2001: fixed typos: done->down and "is is", USRT chip,
synchronous defined better
v2.12 July 2001: serial printing under LPRng<newline>
v2.11 stty 0 => hangup (was ok in v2.08)<newline>
v2.11 May 2001: stty 0 => hangup (was ok in v2.08. )
v2.10 EIA-485, frame errors on networks, gkermit, firewire
<sect1> Related HOWTO's re the Serial Port <label id="related_howtos">
@ -163,7 +167,7 @@ device on the USB.
The common specification for the conventional serial port is RS-232
(or EIA-232). The connector for the serial port is often seen as one
or two 9-pin connectors (in some cases 25-pin) on the back of a PC.
But the serial port is is more than just that. It includes the
But the serial port is more than just that. It includes the
associated electronics which must produce signals conforming to the
EIA-232 specification. See <ref id="volt_shape" name="Voltage
Waveshapes">. One pin is used to send out data bytes and another to
@ -333,6 +337,7 @@ transmit buffer in the hardware.
Nov. '99: 2 serial drivers concurrently NG
Sept. '00: data flow diagram
Dec. '00 flow control +
July "01 done -> down
-->
@ -542,7 +547,7 @@ be reduced.
<!-- ifdef SERIAL_ end -->
<sect1> Flow Control <label id="flow_control">
<p> Flow control means the ability to slow done the flow of bytes in a
<p> Flow control means the ability to slow down the flow of bytes in a
wire. For serial ports this means the ability to stop and then
restart the flow without any loss of bytes. Flow control is needed
for modems to allow a jump in instantaneous flow rates.
@ -1544,11 +1549,12 @@ which are from the BIOS. This is how it was before Linux started.
Setserial can't change it but isapnp or pciutils can and starting with
kernel 2.4, these will be built into the serial driver.
One crude method is try probing with setserial using the "autoconfig"
option. You'll need to guess the addresses to probe at. See <ref
id="set_serial" name="What is Setserial">. For a PCI serial port, use
the "lspci" command (for kernels &lt;2.2 look at /proc/pci). If your
serial port is is Plug-and-Play see the next two subsections.
Using "scanport" will probe all I/O ports and will indicate what it
thinks may be serial port. After this you could try probing with
setserial using the "autoconfig" option. You'll need to guess the
addresses to probe at (using clues from "scanport"). See <ref
id="set_serial" name="What is Setserial">. If your
serial port is is ISA Plug-and-Play or PCI see the next two subsections.
For a port set with jumpers, its how the jumpers were set. If the
port is not Plug-and-Play (PnP) but has been setup by using a DOS
@ -1563,20 +1569,23 @@ can reach a state where it doesn't have any IO address or IRQ and is
in effect disabled. It should still be possible to find the port
using the <tt/pnpdump/ program.
For Plug-and-Play (PnP) on the ISA bus one may try the <tt/pnpdump/
For a PCI serial port, use the "lspci" command (for kernels &lt;2.2
look at /proc/pci).
For an ISA Plug-and-Play (PnP) port one may try the <tt/pnpdump/
program (part of <tt/isapnptools/). If you use the --dumpregs option
then it should tell you the actual IO address and IRQ set in the port.
The address it "trys" is not the device's IO address, but a special
For PnP ports checking on how it's configured under DOS/Windows may not
be of much help. Windows stores its configuration info in its
Registry which is not used by Linux. It may supply the BIOS's
non-volatile memory with some info but it may not be kept in sync with
the current Window configuration in the Registry ?? If you let a PnP
BIOS automatically do the configuring when you start Linux (and have
told the BIOS that you don't have a PnP operating system when running
For PnP ports, checking on how it's configured under DOS/Windows may
(or may not) imply how it's under Linux. 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.
non-volatile memory. Windows also makes use of the same non-volatile
memory but doesn't necessarily configure it that way.
<sect1>Choosing Serial IRQs <label id="choose_IRQ">
@ -2143,15 +2152,15 @@ In fact, you can run "setserial" and assign a purely fictitious I/O
port address, any IRQ, and whatever uart type you would like to have.
Then the next time you type "setserial ..." it will display these
bogus values without complaint. They will also be officially
registered with the kernel as seen by the "scanport" command.
Of course the serial port driver will not work correctly (if at all)
if you attempt to use such a port. Thus when giving parameters to
"setserial" anything goes. Well almost. If you assign one port a
base address that is already assigned (such as 3e8) it will not accept
it. But if you use 3e9 it will accept it. Unfortunately 3e9 is
already assigned since it is within the range starting at base address
3e8. Thus the moral of the story is to make sure your data is correct
before assigning resources with setserial.
registered with the kernel as displayed (at the top of the screen) by
the "scanport" command. Of course the serial port driver will not
work correctly (if at all) if you attempt to use such a port. Thus
when giving parameters to "setserial" anything goes. Well almost. If
you assign one port a base address that is already assigned (such as
3e8) it will not accept it. But if you use 3e9 it will accept it.
Unfortunately 3e9 is already assigned since it is within the range
starting at base address 3e8. Thus the moral of the story is to make
sure your data is correct before assigning resources with setserial.
While assignments made by setserial are lost when the PC is powered
off, a configuration file may restore them (or a previous
@ -2164,7 +2173,13 @@ name="Configuration Scripts/Files">
<sect2> Probing <label id="probing_ss">
<p> With appropriate options, <tt/setserial/ can probe (at a given I/O
<p>Prior to probing with "setserial", one may run the "scanport"
command to check all possible ports in one scan. It makes crude
guesses as to what is on some ports but doesn't determine the IRQ. But
it's a fast first start. It may hang your PC but so far it's worked
fine for me.
With appropriate options, <tt/setserial/ can probe (at a given I/O
address) for a serial port but you must guess the I/O address. If you
ask it to probe for /dev/ttyS2 for example, it will only probe at the
address it thinks ttyS2 is at (2F8). If you tell setserial that ttyS2
@ -2175,11 +2190,12 @@ The purpose of this is to see if there is a uart there, and if so,
what its IRQ is. Use "setserial" mainly as a last resort as there are
faster ways to attempt it such as wvdialconf to detect modems, looking
at very early boot-time messages, or using <tt>pnpdump
--dumpregs</tt>. To try to detect the physical hardware use the -v
(verbose) and <tt/autoconfig/ command to <tt/setserial/. If the
resulting message shows a uart type such as 16550A, then you're OK.
If instead it shows "<tt/unknown/" for the uart type, then there is
supposedly no serial port at all at that I/O address. Some cheap
--dumpregs</tt>. To try to detect the physical hardware use for
example :<newline>
<tt>setserial /dev/ttyS2 -v autoconfig</tt><newline>
If the resulting message shows a uart type such as 16550A, then you're
OK. If instead it shows "<tt/unknown/" for the uart type, then there
is supposedly no serial port at all at that I/O address. Some cheap
serial ports don't identify themselves correctly so if you see
"<tt/unknown/" you still might have a serial port there.
@ -2187,15 +2203,15 @@ Besides auto-probing for a uart type, setserial can auto-probe for
IRQ's but this doesn't always work right either. In one case it first
gave the wrong irq but when the command was repeated it found the
correct irq. In versions of setserial >= 2.15, the results of your
last probe test may be saved and put into the configuration file
<tt>/etc/serial.conf</tt> which will be used next time you start
Linux. At boot-time when the serial module loads (or the like), a
probe for UARTs is made automatically and reported on the screen. But
the IRQs shown may be wrong. The second report of the same is the
result of a script which usually does no probing and thus provides no
reliable information as to how the hardware is actually set. It only
shows configuration data someone wrote into the script or data that
got saved in /etc/serial.conf.
last probe test could be automatically saved and put into the
configuration file <tt>/etc/serial.conf</tt> which will be used next
time you start Linux. At boot-time when the serial module loads (or
the like), a probe for UARTs is made automatically and reported on the
screen. But the IRQs shown may be wrong. The second report of the
same is the result of a script which usually does no probing and thus
provides no reliable information as to how the hardware is actually
set. It only shows configuration data someone wrote into the script
or data that got saved in /etc/serial.conf.
It may be that two serial ports both have the same IO address set in
the hardware. Of course this is not permitted but it sometimes
@ -2204,6 +2220,7 @@ are two. However if they have different IRQs, then the probe for IRQs
may show IRQ = 0. For me it only did this if I first used
<tt/setserial/ to give the IRQ a ficticious value.
<sect2> Boot-time Configuration <label id="sets_boot_time">
<p> When the kernel loads the serial module (or if the "module
equivalent" is built into the kernel) then only <tt/ttyS{0-3}/ are
@ -2638,26 +2655,26 @@ uses the serial port. See <ref id="stty_" name="Stty">
<!-- high_speed.H begin In Serial and Modem HOWTOs but some of the speed
section is unique to each HOWTO.
-->
<p> You need to find out the highest speed supported by your hardware.
As of late 1998 most serial ports only supported speeds up to 115.2k
bps but as of 2001, most support higher speeds. Some 56k internal
modems support 230.4k bps (but it may be hard to find out which ones
do). Recent Linux kernels support high speeds (over 115.2k) but you
might have some problems using it because of one or both of the
following reasons:
<sect2> Speeds over 115.2k
<p> The top speed of 115.2k has been the standard speed since the
mid 1990's. By the year 2000, many serial ports supported higher
speeds but Linux seldom used them due to lack of drivers. These
high-speed ports by default only support 115.2k and must have special
software to enable the higher speeds. Today (2001) almost all new
serial ports support speeds of 230.4k and 460.8k. Some also support
921.6k. Unfortunately, to get these speeds you need to compile the
kernel with a special patch and it seems the patch doesn't support the
2.4 kernels yet.
<enum>
<item> It may require a special driver or a patch to the serial driver
<item> Older versions of an application program (or stty) may not
support the high speed.
<item> Setserial may show the wrong speed unless you use the baud_base
option. Even so, high speed will still work but the reported speed
will be wrong.
</enum>
For internal modems, only a minority of them advertise that they
support speeds of over 115.2k for their built-in serial ports.
Will shsmod support these ??
To support the higher speeds you may get a shsmod (Super High Speed)
patch for the serial driver. There is also a module for the VIA
VT82C686 chip <url url="www.kati.fi/viahss/">.
The patch to support high-speed is called shsmod (Super High Speed).
There are both Windows and Linux versions of this patch. See <url
url="http://www.devdrv.com/shsmod">. For Linux, much of the
documentation is only in Japanese. There is also a module for the
VIA VT82C686 chip <url url="www.kati.fi/viahss/">.
<sect2> How speed is set in hardware: the divisor and baud_base <label
id="divisor_">
@ -4087,34 +4104,41 @@ the basic concepts.
In theory, synchronous means that bytes are sent out at a constant
rate one after another in step with a clock signal tick. There is
often a separate wire or channel for sending the clock signal.
often a separate wire or channel for sending the clock signal. The
clock signal might also be embedded in the transmitted bytes.
Asynchronous bytes may be sent out erratically with various time
intervals between bytes (like someone typing characters at a
keyboard). When a file is being sent thru the async serial port, the
flow of bytes will likely be at the speed of the port (say 115.2k)
which is a constant rate. This flow may frequently start and stop due
to flow control.
keyboard).
There are certain situations that need to be classified as either
sync or async. The async serial port often sends out bytes in a
steady stream which would make this a synchronous case but since they
still have the start/stop bits (which makes it possible to send them
out erratically) it's called async. Another case is where data
bytes (without any start-stop bits) are put into packets with possible
erratic spacing between one packet and the next. This is called sync
since the bytes within each packet must be transmitted synchronously.
When a file is being sent thru the async serial port, the flow of
bytes will likely be at the speed of the port (say 115.2k) which is a
constant rate. This flow may frequently start and stop due to flow
control. Is this sync or async? Ignoring the flow control stops, it
might seem like sync since it's a steady flow. But it's not because
there is no clock signal and the bytes could have been sent
erratically since they are framed by start/stop bits.
Another case is where data bytes (without any start-stop bits) are put
into packets with possible erratic spacing between one packet and the
next. This is called sync since the bytes within each packet are
transmitted synchronously.
<sect2> Synchronous Communication
<p> Did you ever wonder what all the unused pins are for on a 25-pin
connector for the serial port? Most of them are for use in
synchronous communication which is seldom implemented on PC's. There
are pins for sync timing signals as well as for a sync reverse
channel. The EIA-232 spec provides for both sync and async but PC's
use a UART (Universal Asynchronous Receiver/Transmitter) chip such as
a 16450, 16550A, or 16650 and can't deal with sync. For sync one
needs a USART chip or the equivalent where the "S" stands for
Synchronous. Since sync is a niche market, a sync serial port is
likely to be quite expensive.
synchronous communication which is seldom implemented in chips for
PC's. There are pins for sync timing signals as well as for a sync
reverse channel. The EIA-232 spec provides for both sync and async
but PC's use a UART (Universal Asynchronous Receiver/Transmitter) chip
such as a 16450, 16550A, or 16650 and can't deal with sync. For sync
one needs a USRT chip or the equivalent where the "S" stands for
Synchronous. A USART chip supports both synchronous and asynchronous.
Since sync is a niche market, a sync serial port is likely to be quite
expensive.
SCC stands for "Serial Communication Controller" or "Serial Controller
Chip". It's likely old terminology and since it doesn't say "sync"
or "async" it might support both.
Besides the sync part of the EIA-232, there are various other EIA
synchronous standards. For EIA-232, 3 pins of the connector are

463
LDP/howto/linuxdoc/Text-Terminal-HOWTO.sgml
View File

@ -2,10 +2,13 @@
<article>
<title> Text-Terminal-HOWTO
<author> David S. Lawyer <url url="mailto:dave@lafn.org">
<date> v1.23, July 2001
<date> v1.24, August 2001
<!--
Change log:
v1.24 Aug. 2001 Respawning too fast due to no such device, block mode
obsolete, troubleshooting: diplays escape sequences, detective work
for repair
v1.23 July 2001: 10-cond. is not RJ45/48 ?, corrupted character attributes
v1.22 May 2001 Clarity: 8-bit, ASCII, national replacement characters,
CP1252=MS-ANSI
@ -166,13 +169,15 @@ url="http://linuxdoc.org/mirrors.html">. Various formats are
available. If you only want to quickly check the date of the latest
version look at <url
url="http://linuxdoc.org/HOWTO/Text-Terminal-HOWTO.html">. The
version your are currently reading is: v1.23, July 2001 . New in recent
version your are currently reading is: v1.24, August 2001 . New in recent
versions:<newline>
v1.23 July 2001: 10-cond. is not RJ45/48 ?, corrupted character
attributes<newline>
v1.22 Clarity: 8-bit, ASCII, national replacement characters,
CP1252=MS-ANSI<newline>
v1.21 More on mgetty, getty-login sequence, agetty parity
v1.24 Aug. 2001 Respawning too fast due to no such device, block mode
obsolete, troubleshooting: displays escape sequences, detective work
for repair
v1.23 July 2001: 10-cond. is not RJ45/48 ?, corrupted character attributes
v1.22 May 2001 Clarity: 8-bit, ASCII, national replacement characters,
CP1252=MS-ANSI
v1.21 April 2001 More on mgetty, getty-login sequence, agetty parity
problem, types of "terminal servers", parity set shows upper 128
chars., Correction: PCTerm doesn't work with MS DOS, troubleshooting:
no CD signal
@ -1690,7 +1695,19 @@ presses control-S. Much less common is the opposite case where the PC
can't keep up with your typing speed and tells the terminal to stop
sending. The terminal "locks" its keyboard and a message or light
should inform you of this. Anything you type at a locked keyboard is
ignored.
ignored. When the PC catches up on it's work, then the keyboard
should unlock. When it doesn't, there is likely some sort of deadlock
going on.
Another type of keyboard lock happens when a certain escape sequence
(or just the ^O control character for Wyse 60) is sent to the
terminal. While the previous type of lock is done by the serial
driver, this type of lock is done by the hardware of a real terminal.
It's a catch-22 situation if this happens since you can't type any
commands to escape out of this lock. Going into setup and resetting
might work (but it failed on my Wyse 60 and I had to cycle power to
escape). One could also send an "unlock keyboard" escape sequence
from another terminal.
The term "locked" is also sometimes used for the common case of where
the computer is told to stop sending to a terminal. The keyboard is
@ -1922,17 +1939,18 @@ doesn't yet (2000).
<tscreen><verb>
PC male DB25 Terminal DB25
DSR Data Set Ready 6
|
DCD Carrier Detect 8 <-- 20 DTR Data Terminal Ready
TxD Transmit Data 2 --> 3 RxD Receive Data
RxD Receive Data 3 <-- 2 TxD Transmit Data
RTS Request To Send 4 --> 5 CTS Clear To Send
CTS Clear To Send 5 <-- 4 RTS Request To Send
DSR Data Set Ready 6
|
DCD Carrier Detect 8 <-- 20 DTR Data Terminal Ready
SG Signal Ground 7 --- 7 SG Signal Ground
6 DSR Data Set Ready
|
DTR Data Terminal Ready 20 --> 8 DCD Carrier Detect
|
6 DSR Data Set Ready
</verb></tscreen>
<label id="DB_pin-out">
Alternatively, a full DB9-DB25 null modem cable (will not work
@ -1950,7 +1968,7 @@ DCD Carrier Detect 1
DSR Data Set Ready 6 <-- 20 DTR Data Terminal Ready
RTS Request To Send 7 --> 5 CTS Clear To Send
CTS Clear To Send 8 <-- 4 RTS Request To Send
(RI Ring Indicator 9 not needed)
(RI Ring Indicator 9 (not needed)
</verb></tscreen>
(Yes, the pins 2 and 3 really do have opposite meanings for DB9 and
DB25 connectors!)
@ -2295,9 +2313,9 @@ Pin Signal Signal Pin
4 SG (RxD)--------------------|
5 RxD <--------------------------- TxD 3
6 DSR <--------------------------- RTS 7
|--- DTR 4
|--> DTR 4
|--> CD 1
RI 9
(no connection) RI 9
</verb></tscreen>
<sect3> 8-conductors and 10-conductors
<p> RJ45 and RJ48 are 8-conductor modular telephone plugs.
@ -3651,15 +3669,15 @@ In fact, you can run "setserial" and assign a purely fictitious I/O
port address, any IRQ, and whatever uart type you would like to have.
Then the next time you type "setserial ..." it will display these
bogus values without complaint. They will also be officially
registered with the kernel as seen by the "scanport" command.
Of course the serial port driver will not work correctly (if at all)
if you attempt to use such a port. Thus when giving parameters to
"setserial" anything goes. Well almost. If you assign one port a
base address that is already assigned (such as 3e8) it will not accept
it. But if you use 3e9 it will accept it. Unfortunately 3e9 is
already assigned since it is within the range starting at base address
3e8. Thus the moral of the story is to make sure your data is correct
before assigning resources with setserial.
registered with the kernel as displayed (at the top of the screen) by
the "scanport" command. Of course the serial port driver will not
work correctly (if at all) if you attempt to use such a port. Thus
when giving parameters to "setserial" anything goes. Well almost. If
you assign one port a base address that is already assigned (such as
3e8) it will not accept it. But if you use 3e9 it will accept it.
Unfortunately 3e9 is already assigned since it is within the range
starting at base address 3e8. Thus the moral of the story is to make
sure your data is correct before assigning resources with setserial.
While assignments made by setserial are lost when the PC is powered
off, a configuration file may restore them (or a previous
@ -3672,7 +3690,13 @@ name="Configuration Scripts/Files">
<sect2> Probing <label id="probing_ss">
<p> With appropriate options, <tt/setserial/ can probe (at a given I/O
<p>Prior to probing with "setserial", one may run the "scanport"
command to check all possible ports in one scan. It makes crude
guesses as to what is on some ports but doesn't determine the IRQ. But
it's a fast first start. It may hang your PC but so far it's worked
fine for me.
With appropriate options, <tt/setserial/ can probe (at a given I/O
address) for a serial port but you must guess the I/O address. If you
ask it to probe for /dev/ttyS2 for example, it will only probe at the
address it thinks ttyS2 is at (2F8). If you tell setserial that ttyS2
@ -3683,11 +3707,12 @@ The purpose of this is to see if there is a uart there, and if so,
what its IRQ is. Use "setserial" mainly as a last resort as there are
faster ways to attempt it such as wvdialconf to detect modems, looking
at very early boot-time messages, or using <tt>pnpdump
--dumpregs</tt>. To try to detect the physical hardware use the -v
(verbose) and <tt/autoconfig/ command to <tt/setserial/. If the
resulting message shows a uart type such as 16550A, then you're OK.
If instead it shows "<tt/unknown/" for the uart type, then there is
supposedly no serial port at all at that I/O address. Some cheap
--dumpregs</tt>. To try to detect the physical hardware use for
example :<newline>
<tt>setserial /dev/ttyS2 -v autoconfig</tt><newline>
If the resulting message shows a uart type such as 16550A, then you're
OK. If instead it shows "<tt/unknown/" for the uart type, then there
is supposedly no serial port at all at that I/O address. Some cheap
serial ports don't identify themselves correctly so if you see
"<tt/unknown/" you still might have a serial port there.
@ -3695,15 +3720,15 @@ Besides auto-probing for a uart type, setserial can auto-probe for
IRQ's but this doesn't always work right either. In one case it first
gave the wrong irq but when the command was repeated it found the
correct irq. In versions of setserial >= 2.15, the results of your
last probe test may be saved and put into the configuration file
<tt>/etc/serial.conf</tt> which will be used next time you start
Linux. At boot-time when the serial module loads (or the like), a
probe for UARTs is made automatically and reported on the screen. But
the IRQs shown may be wrong. The second report of the same is the
result of a script which usually does no probing and thus provides no
reliable information as to how the hardware is actually set. It only
shows configuration data someone wrote into the script or data that
got saved in /etc/serial.conf.
last probe test could be automatically saved and put into the
configuration file <tt>/etc/serial.conf</tt> which will be used next
time you start Linux. At boot-time when the serial module loads (or
the like), a probe for UARTs is made automatically and reported on the
screen. But the IRQs shown may be wrong. The second report of the
same is the result of a script which usually does no probing and thus
provides no reliable information as to how the hardware is actually
set. It only shows configuration data someone wrote into the script
or data that got saved in /etc/serial.conf.
It may be that two serial ports both have the same IO address set in
the hardware. Of course this is not permitted but it sometimes
@ -3712,6 +3737,7 @@ are two. However if they have different IRQs, then the probe for IRQs
may show IRQ = 0. For me it only did this if I first used
<tt/setserial/ to give the IRQ a ficticious value.
<sect2> Boot-time Configuration <label id="sets_boot_time">
<p> When the kernel loads the serial module (or if the "module
equivalent" is built into the kernel) then only <tt/ttyS{0-3}/ are
@ -4676,7 +4702,7 @@ the previous section.
<sect2> Symptoms and some fixes <label id="symptoms_">
<p> When the display doesn't look right, or when what you type doesn't
display correctly (if at all), or nothing happens when you type a
command, you may have a corrupted terminal interface. In rare cases
command, you may have a corrupted terminal interface. In rare cases,
when the serial port hardware gets itself corrupted, the only fix may
be to cycle power (turn off the PC and reboot). In some cases just
cycling power for the terminal will fix it. Sometimes logging in again
@ -4713,9 +4739,10 @@ may put your terminal into some strange mode of operation or even make
it unusable. Always view or edit a binary file with programs designed
for that purpose so that this doesn't happen. Most editors and pagers
will handle binary OK so as not to corrupt the interface. Some may
display a message telling you that they can't edit binary. But using
"cat ...." or "cp .... /dev/tty.." where .... is a binary file, will
send the binary to the terminal and likely corrupt things.
display a message telling you that they can't edit binary. But you're
likely to corrupt things if you: "cat ...." or "cp .... /dev/tty.." or
run a program which sends binary output to "standard output" (unless
you redirect such output with >, etc.).
Corruption it can also happen when using a communications program where
a remote computer may send binary to your screen. There are numerous
@ -5218,9 +5245,11 @@ stty rows 24
<sect> Trouble-Shooting <label id="trouble_shoot">
<p> If you suspect that the problem is a hardware problem, see the <ref
id="repair_" name="Repair and Diagnose"> section. If it's the keyboard
see <ref id="keyboards_" name="Keyboards">. If the problem involves
the serial port itself see the Serial-HOWTO.
id="repair_" name="Repair and Diagnose"> section. If it's the
keyboard see <ref id="keyboards_" name="Keyboards">. If it responds
incorrectly (if at all) to what you type. see <ref
id="corrupt_interface" name="Corrupted Terminal Interface">. If the
problem involves the serial port itself see the Serial-HOWTO.
Here is a list of possible problems:
<itemize>
@ -5228,12 +5257,13 @@ Here is a list of possible problems:
Suspect the terminal is defective.
<item><ref id="display_freezes" name="Display Freezes (hung
terminal)">
<item><ref id="displays_garbage" name="Displays Garbage"> Characters you
type or see are "foreign" letters/symbols.
<item><ref id="displays_foreign" name="Displays Foreign/Weird
Characters/Symbols">
<item><ref id="displays_esc-seqs" name="Displays Escape Sequences">
<item><ref id="flow_ctrl_ng" name="Missing Text"> Either skips
over some text or displays some text OK and hangs.
over some text or displays some text OK and hangs.
<item><ref id="keys_erratic" name="All Keys Work Erratically; Must Hit
a Key a Few Times">
a Key a Few Times">
<item><ref id="stopped_" name="If getty run from command line: Programs
get stopped"> with message "Stopped"
<item><ref id="rapid_respawn" name="Getty Respawning Too Rapidly">
@ -5255,7 +5285,7 @@ the next section.
<p> When a formerly working terminal suddenly goes bad it is often
easy to find the problem. That's because (except for hardware
failures) the problem is likely due to something that you did (or
something the software you used did).
something the software that you used did).
The problem may be obvious such as an error message when the terminal
is first turned on. If it makes a strange noise it likely needs
@ -5298,20 +5328,19 @@ causes. You should deviate a little from this method based on hunches
and clues.
<sect1> Is the Terminal OK ? <label id="term_OK">
<p> Many terminals will start up with some words on the
screen. If these words convey no error message, it's probably
OK. If there is no sign of power (a dark screen, etc.) re-plug in the
computer power cord at both ends. Make sure there is power at the
wall jack (or at the extension cord end). Try another power cord if
you have one. Make sure the terminal is turned on and that its fuse
is not blown. A blank (or dim) screen may sometimes be fixed by just
turning up the brightness and contrast using knobs or a keyboard key
in set-up mode.
<p> Many terminals will start up with some words on the screen. If
these words convey no error message, it's probably OK. If there is no
sign of power (a dark screen, etc.) re-plug in the computer power cord
at both ends. Make sure there is power at the wall jack (or at the
extension cord end). Try another power cord if you have one. Make
sure the terminal is turned on and that its fuse is not blown. A
blank (or dim) screen may sometimes be fixed by just turning up the
brightness and contrast using knobs or a keyboard key in set-up mode.
A terminal that's been stored for a long time may
take a while to "warm up" as the electrolytic capacitors heal
themselves under voltage. If it still won't work See <ref
id="repair_" name="Repair & Diagnose"> for tips on repairing it.
A terminal that's been stored for a long time may take a while to
"warm up" as the electrolytic capacitors heal themselves under
voltage. If it still won't work See <ref id="repair_" name="Repair &
Diagnose"> for tips on repairing it.
If the terminal starts up OK, but you suspect that something may be
wrong with it, go into "local mode" where is works like a typewriter
@ -5369,32 +5398,59 @@ terminal nor the gpm mouse program uses lockfiles. Since others may
need to write to your terminal, it's reasonable not to use lockfiles.
See Lock-Files in the Serial-HOWTO.
<sect1> Getty Respawning Too Rapidly <label id="rapid_respawn">
<sect1> ... respawning too fast: disabled for 5 minutes
<label id="rapid_respawn">
<sect2>What's happening
<p>You see a message on the console like: "Getty respawning too fast:
disabled for 5 minutes". Instead of "Getty" it may display a label
(such as "S2") for the line in /etc/inittab from where from where getty
was called.
When getty starts up, it tries to send a login message to the serial
port. But if there is something seriously wrong, getty will be
immediately killed. Since the /etc/inittab file line for getty says
to "respawn", getty is started again, only to be killed again, etc.
Thus getty respawns over and over. But the operating system
intervenes and stops this nonsense (for 5 minutes). The following
sections show possible causes and fixes.
<sect2> No modem control signal
<p> If getty can't open and/or use a port because of the lack of a
positive modem control voltage on one of the pins, then getty might
be killed. Then, per the instructions in inittab, getty respawns and
tries again, only to be killed again, etc., etc. You may see an error
message like: Getty respawning too fast: disabled for 5 minutes.
Instead of "Getty" it may give the label (such as S2) of the line in
/etc/inittab from where from where getty was called. Try using
the "local" option with getty and/or check the modem control settings
and voltages.
<p> If the terminal doesn't send the PC a CD signal on one of the pins
of the serial port, getty will be killed unless the "local" option has
been used with getty. So a quick fix is to just use a "local" option
(-L for agetty, "CLOCAL" in /etc/gettydefs for ps_getty).
Another approach is to determine why CD is not being asserted. In
many cases the cable to the terminal simply doesn't have a wire for
the CD pin so you must use the "local" option. If there is a wire for
the CD pin then there may not be any signal on it until the terminal
is powered on. Note that the CD pin signal is sometimes supplied by
the DTR pin of the terminal (or the PC) by using jumper wires inside
the connector.
<sect2> No such serial device
<p>If the device (such as /dev/ttyS2) is bogus (doesn't physically
exist or has been disabled), then getty will be killed. You may use
"scanport" and/or "setserial" to probe for the device or try another
ttyS. Perhaps the device has been disabled in the CMOS. See
"Serial-HOWTO".
<sect2> No serial support
<p> Linux provides serial support either by selecting it when
compiling the kernel or by loading the serial module. This
compiling the kernel or by loading the serial module: serial.o. This
"respawning" error happens if serial support has neither been built
into the kernel nor provided by a serial module. You many use the
"lsmod" command to see if the serial module is loaded.
"lsmod" command to see if the serial module is loaded. To see if
serial support is built into the kernel, check a kernel configuration
file (in /boot, in the source tree, etc.)
<sect2> Key shorted <label id="key_shorted_getty">
<p> Another possible cause of getty respawning too rapidly is if a
keyboard key is shorted, giving the same result as if the key was
keyboard key is shorted. This gives the same result as if the key was
continuously held down. With auto-repeat enabled, this "types"
thousands of characters to the login prompt. Look for a screen filled
with all the same character (in some cases with 2 or more different
with all the same character (in some cases, with 2 or more different
characters).
<sect1> Fails Just After Login <label id="after_login">
@ -5536,25 +5592,68 @@ you could get a false high AC reading when looking at the idle DC of
good device (such as another terminal or an external modem) to the
serial port and see if it works OK.
<sect1> Displays Garbage <label id="displays_garbage">
<p> If what you type or see on the screen is not what's expected but
looks like a foreign alphabet, math symbols, line-drawing character,
etc. then it could be that the many of bytes that are sent to your
terminal have the high order bit set (when it shouldn't be). You are
looking at the character set (or part of a character set) which has
the high order bit set. This may happen if you have the baud rate
wrong or parity set wrong (per stty). If you have parity set per stty
but inside the terminal it's 8-bit no-parity, then the high order bit
(= parity bit) will often be erroneously set. Try stty -F /dev/ttyS?
from another terminal to check if the baud rate and parity are
correct.
<sect1> Displays Foreign/Weird Characters/Symbols
<label id="displays_foreign">
<p> Don't confuse this with <ref id="displays_esc-seqs" name="Displays
Escape Sequences">. If what you type or see on the screen is not
what's expected but looks like a foreign alphabet, math symbols,
line-drawing character, etc. then it could be that the many of bytes
that are sent to your terminal have the high order bit set (when it
shouldn't be). You are looking at the character set (or part of a
character set) which has the high order bit set. This may happen if
you have the baud rate wrong or parity set wrong (per stty). If you
have parity set per stty but inside the terminal it's 8-bit no-parity,
then the high order bit (= parity bit) will often be erroneously set.
Try stty -F /dev/ttyS? from another terminal to check if the baud
rate and parity are correct.
Perhaps the wrong character set (font) has been installed. An
erroneous escape sequence sent to the terminal could have switched
character sets. If you are using the mapchan program to change the
keyboard mapping, it could be incorrect.
<sect1> Displays Escape Sequences <label id="displays_esc-seqs">
<p>You may see something like "5;35H22,1" or "3;4v" or "1;24r" or
"^[[21;6H", etc., etc. Of course, the numbers and letters will be
different. They will be scattered about (either randomly or in a
strange sense of order). The display will look a mess and will likely
have other defects. Some application and commands will result in
corrupted displays.
What you see are escape sequences (or fragments of them) that were
sent to your terminal in order to control it, but your terminal didn't
recognize them and passed them on to the screen. It's likely that the
program you're using erroneously thinks you are using another type of
terminal. Thus it sends escape sequences that your terminal doesn't
understand. This can sometimes do strange things to your display.
Check that the TERM environment variable is set correctly (type: echo
$TERM).
<sect2>Telnet
<p>The problem of getting TERM right can be a bit more complex if you use
telnet. Telnet doesn't emulate a terminal but passes the value of
your TERM variable to the remote computer. If the remote computer
doesn't support your type of terminal, or changes the value of TERM to
a wrong value (on the remote) then there's trouble. Telnet
should initially set the value of TERM correctly on the remote. But
changes to the value of TERM (on the remote) could be caused by an
incorrect shell configuration file there. The first thing to do is to
check the value of TERM, both on your computer and on the remote. The
above is overly simplified since it's possible for your telnet client
to present the remote server with a list of possible TERM values which
your computer supports (if it can emulate more than one terminal
type).
<sect2>Terminal set to display escape sequences
<p>Another possible cause is that your terminal happens to be in a
special mode where it displays the escape sequences instead of
executing them. Then you'll also see them on the screen but they will
display in an orderly fashion. This mode is more precisely, one that
displays control codes. But since each escape sequence starts with a
control code (the "escape" character), the whole escape sequence is
not recognized by the terminal and is passed along to the screen. See
<ref id="control_codes" name="Control Codes">.
<sect1> Slow: pauses of several seconds between bursts of characters
<p> You likely have mis-set interrupts> See the Serial-HOWTO section
starting with "Slow:"
@ -5670,11 +5769,11 @@ flashlight batteries first so you will know what taste to expect.
<p> Repairing a terminal has much in common with repairing a monitor
and/or keyboard. Sometimes the built-in diagnostics of the terminal
will tell you what is wrong on the screen. If not, then by the
symptoms, one may often isolate the trouble to one of the following:
bad keyboard, CRT dead, terminal digital electronics failure. It's
best to have a service manual, but even if you don't have one, many
terminals may still be repaired.
will display on the screen. By the symptoms, one may often isolate
the trouble to one of the following: bad keyboard, CRT dead, power
electronics failure, or digital electronics failure. It's best to
have a service manual, but even if you don't have one, you can
often still repair it.
<sect1> Repair Books & Websites <label id="repair_info">
<sect2> Books
@ -5752,40 +5851,43 @@ such names:
Changing linearity may change the size so that it will need to be
readjusted. A terminal that has been stored for some time may have a
small display rectangle on the screen surrounded by a large black
border. If it's difficult to adjust, wait a while before adjusting it
since it will likely recover some with use (the black borders will
shrink).
Before adjusting it, leave the terminal on for a while since it will
likely recover some with use (the black borders will shrink).
<sect1> Diagnose
<sect2> Terminal Made a Noise
<sect2> Terminal Made a Noise or Smoked
<p> If the terminal made some noise just before it failed (or when you
turn it on after it failed) that noise is a clue to what is wrong. If
you hear a sparking noise or see/smell smoke, immediately turn the
terminal off to prevent further damage. The problem is likely in the
high voltage power supply of several thousand volts. Remove the cover
and if the bad spot is not evident, turn it on again for a short time
in a dimly lit room to look for arcing. The high voltage
cable (runs between the flyback transformer and the side of the
picture tube) may have broken insulation that arcs to ground. Fix it
with high-voltage insulating dope, or special electrical tape designed
say for 10,000 volts.
you hear a noise or see/smell smoke, immediately turn the terminal off
to prevent further damage. A pop noise may be a capacitor exploding
or a fuse blowing. A buzzing noise is likely due to arcing. The
problem may be in the high voltage power supply of several thousand
volts.
Remove the cover. Look for discoloration and bulging/cracked
capacitors. If the bad spot is not evident, turn it on again for a
short time and look for smoking/arcing. For arcing, a dimly lit room
will help find it. The high voltage cable (runs between the flyback
transformer and the side of the picture tube) may have broken
insulation that arcs to ground. Fix it with high-voltage insulating
dope, or special electrical tape designed say for 10,000 volts.
The flyback transformer (high voltage) may make only a faint clicking
or sparking noise if it fails. You may not hear it until you turn the
terminal off for a while to rest and then turn it back on again. To
track down the noise you may use a piece of small rubber tubing (such
as used in automobiles) as a stethoscope to listen to it. But while
you are listening for the noise, the terminal is suffering more damage
so try find it fast (but not so fast as to risk getting shocked).
terminal off for a while and then turn it back on again. To track
down the noise you may use a piece of small rubber tubing (such as
used in automobiles) as a stethoscope to listen to it. But while you
are listening for the noise, the terminal is suffering more damage so
try find it fast (but not so fast as to risk getting shocked).
A short in the power supply may cause a fuse to blow with a pop.
Replacing a blown fuse may not solve the problem as the same short may
blow the fuse again. Inspect for any darkened spots due to high heat
and test those components. Shorted power transistors may cause the
fuse to blow. They may be tested with a transistor checker or even
with an ohm-meter. Use the low ohm scale on an ohm-meter so that the
voltage applied by the meter is low. This will reduce the possible
damage to good components caused by this test voltage.
A shorted power supply may cause a fuse to blow. Replacing a blown
fuse may not solve the problem as the same short may blow the fuse
again. Inspect for any darkened spots due to high heat and test those
components. Shorted power transistors may cause the fuse to blow.
They may be tested with a transistor checker or even with an
ohm-meter. Use the low ohm scale on an ohm-meter so that the voltage
applied by the meter is low. This will reduce the possible damage to
good components caused by this test voltage.
If the terminal has been exposed to dampness such as being stored in a
damp place or near a kitchen with steam from cooking, a fix may be to
@ -5813,20 +5915,28 @@ in local, then the problem is likely in the connection to the host
computer (or incorrect interface) or in the UART chips of the
terminal.
By carefully inspecting the circuitry, one may often find the cause of
the problem. Look for discoloration, cracks, etc. An intermittent
<sect1> Detective work
<p>By carefully inspecting the circuitry, one may often find the cause
of the problem. Look for discoloration, cracks, etc. An intermittent
problem may sometimes be found by tapping on components with a
ball-point pen (not the metal tip of course). A break in the
conductor of a printed circuit board may sometimes be revealed by
flexing the board. Solder that looks like it formed a drop or a
solder joint with little solder may need re-soldering. Soldering may
heat up transistors (and other components) and damage them so use a
heat sink if feasible.
heat sink if feasible. One failure may cause others, so unless you
find the original cause, the failure may reoccur.
If you have a common brand of terminal, you may be able to search
newsgroup postings on the Internet to find out what the most frequent
types of problems are for your terminal and perhaps information on how
to fix them.
If you have a common brand of terminal, you may be able to search the
Internet (including newsgroup postings) to find out what the most
frequent types of problems are for your terminal and perhaps
information on how to fix it. If you find that a certain component
is bad you may search for this component (for example R214 wyse) and
hopefully find a report by someone else who had the same problem.
Such a report may indicate other components that failed at the same
time. If a component is damaged so badly that its value can't be
read, then you might find it on the Internet. The manufacturer may
have on-line data that search engines don't index.
To see if the digital electronics work, try (using a good keyboard)
typing at the bad terminal. Try to read this typing at a
@ -5867,6 +5977,11 @@ leaving the terminal on for a while will help partially restore them.
If you can, exercise any terminals you have in storage by turning them
on for a while every year or two.
Note that cheap electrolytic capacitors designed for use in audio
circuits may fail if used in high frequency horizontal circuitry. For
this, you need low resistance (low ESR) capacitors. Replace
non-polarized capacitors (NP) with the same (or with "bi-polar").
<sect1> Keyboards <label id="keyboards_">
<sect2> Interchangeability
<p> The keyboards for terminals are not the same as keyboards for
@ -6584,38 +6699,42 @@ phone line.
<sect1> Block Mode <label id="block">
<sect2> Intro to Block Mode
<p> Block mode is seldom used with Linux. In block mode when one types
at a terminal, the results are saved in the terminal memory and are
not sent just yet to the host computer. Such terminals often have
built-in editing capabilities. When the user presses certain keys
(such as the send key) what has been saved in the terminal memory is
sent to the host computer. Now the Linux editors vi and emacs, react
instantly to pressing certain keys but in the above situation such
keys will be pressed and nothing will happen since nothing is sent
when a key is pressed. Thus using a block mode terminal will not
allow the use of such interactive programs. The old IBM mainframe
interface uses block mode (see <ref id="ibm_" name="IBM Terminals ">
so many IBM terminals are block-mode only and also synchronous (see
Section <ref id="sync" name="Synchronization & Synchronous">).
<sect2> Introduction to Block Mode
<p> Block mode is seldom used with Linux and is mainly of historical
interest. In block mode, when one types at a terminal the results are
saved in the terminal memory and are not sent just yet to the host
computer. Such terminals often have built-in editing capabilities.
When the user presses certain keys (such as the send key) what has
been saved in the terminal memory is sent to the host computer. Now
the Linux editors vi and emacs, must react instantly to typing certain
keys so block mode isn't feasible. Such editors and other interactive
programs can't permit the long delay in sending a keystroke to the
computer which is inherent in block mode. So they can't use block
mode.
The old IBM mainframe interface uses block mode (see <ref id="ibm_"
name="IBM Terminals "> so many IBM terminals are block-mode only and
also synchronous (see Section <ref id="sync" name="Synchronization &
Synchronous">).
<sect2> Types of Block Modes, Forms
<p> Block mode may itself have various sub-modes such as "page" (a
page at a time) and "line" (a line at a time). Some terminals have
both block transmission modes and conventional character modes and may
be switched from one mode to another. Async terminals which have
block modes include HP2622A, VT130, VT131, VT330, VT340, and
Visual500. Many later model terminals can emulate block mode. Block
modes may include a forms capability where the host computer sends a
form to the terminal. Then the user fills it out and hits the send
key which sends only the data in the form back to the host computer.
The form itself (not the data) is displayed on the screen in protected
fields which don't get transmitted to the host.
block modes include HP2622A, Wyse60, VT130, VT131, VT330, VT340, and
Visual500. Many later model terminals can emulate block mode. But
the Linux console can't. Block modes may include a forms capability
where the host computer sends a form to the terminal. Then the user
fills it out and hits the send key which sends only the data in the
form back to the host computer. The form itself (not the data) is
displayed on the screen in protected fields which don't get
transmitted to the host.
<sect2> Efficiency
<p> Block mode takes a great deal of load off the host computer,
especially if the host computer's hardware is designed for block modes
(as IBM mainframes were). In character mode every character typed is sent
<p> Block mode takes load off the host computer, especially if the
host computer's hardware is designed for block modes (as IBM
mainframes were). In character mode every character typed is sent
immediately to the serial port and usually causes an interrupt at the
host computer. The host that receives the byte must stop whatever it
is doing and fetch that character from the port hardware. Even with
@ -6636,6 +6755,27 @@ character (byte) typed is sent in its own packet including all the
overhead bytes (40 in a TCP/IP packet as used on the Internet). With
block mode, a large number of characters are sent in a single packet.
<sect2> Problems with block mode
<p>While block mode is more efficient, it is nearly extinct, and for
good reason. Faster and cheaper computers made the higher efficiency
less important. For example, a 56k modem results in hundreds of
interrupts per second (every 14 characters) while typing at a terminal
only causes a few interrupts per second (one for each character
typed). So the number of interrupts caused by typing at a terminal
is not very significant (unless you have hundred of terminals
connected to the same computer).
Another point is that the efficiency is not of much significance where
the user doesn't type in very much. Editors are a primary example of
where the user types in a lot. But if you use block mode for
editing, you must then use the crude editor built into terminal. Modern
editors like vim and emacs are much better but can't use block mode.
Even in the days of mainframes with terminals, block mode wasn't used
much except by IBM. A major reason was that software to utilize it
was not widely available (except for IBM). The terminfo data base
doesn't seem to include it and this would complicate writing software
for it.
<sect1> EIA-232 (RS-232) Books <label id="RS232_books">
<p> (Note: The first book covers much more than just EIA-232.)
<itemize>
@ -6760,6 +6900,15 @@ will also lead to some FAQ's for terminal numbers under 100 (such as
WY60). For the specs on more recent terminals see See <url
url="http://www.wyse.com/products/gpt/index.htm" name="Wyse terminals">.
Wyse terminals were lower in cost than other brands and they captured
a major share of the market. There were concerns about the quality
of these terminals, especially the Wyse 50. One reason for the large
number of reports of Wyse failures may be because there were so many
of them out there.
<sect2> Wyse 50
<p>Reported not to last very long.
<sect2> Wyse 60
<p> Display adjustments (must remove cover): Brightness VR202, Height
VR302, Width VR101 (also affects height). If you want to use it in
@ -6771,8 +6920,10 @@ edit /etc/inputrc so that the arrow keys will work in Bash. See <ref
id="bash_bug" name="Bugs in Bash">
<sect2> Wyse 85
<p> Can emulate VT52/VT100/VT200. Press F3 for setup. Scroll thru
setup with up/down keys.
<p> Can emulate VT52/VT100/VT200. Press F3 for setup. After moving
left/right to go the a menu "icon", press space to select it. Scroll
thru setup menus with up/down keys. Press F3 at any time to reenter
setup (without loosing any settings).
<sect2> Wyse 99-GT
<p> Here is the setup Menus of the Wyse99GT (late 1980's). Note that