If you suspect that the problem is a hardware problem, see the
Repair and Diagnose section. If it's the
Keyboards. If it responds
incorrectly (if at all) to what you type. see
Corrupted Terminal Interface. If the
problem involves the serial port itself see the Serial-HOWTO.
There are two cases where the terminal goes bad. One is when it's
been recently working OK and suddenly goes bad. This is discussed in
the next sub-section. The other case is where things don't work right
just after you install a terminal. For this case you may skip over
the next section.
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 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
Repair & Diagnose. First,
think about what has been done or changed recently as it's likely the
cause of the problem. Did the problem happen just after new system
software was installed or after a change in the configuration?
If you've just connected up a terminal to a computer per
instructions and it doesn't work this section is for you. If a
terminal that formerly worked OK doesn't work now then see
Terminal Was Working OK If you suspect
that the serial port on your computer may be defective you might try
running a diagnostic test program on it. At present (June 1998) it
seems that Linux doesn't yet have such a diagnostic program so you may
need to run diagnostics under MS DOS/Windows. There are some programs
to monitor the various serial lines such at DTR, CTS, etc. and this
may help. See
One approach is to first see if the the terminal will work by trying
to copy a file to the terminal (cp my_file /dev/ttyS?) under the most
simple situation. This means with the modem control lines disabled
and at a show speed that doesn't need flow control (make sure that any
hardware flow control is disabled). If this copy works, then make the
situation a little more complicated and see if it still works, etc.,
etc. When the trouble appears just after you made a change, then that
change is likely the source of the trouble. Actually, its more
efficient (but more complex) to jump from the simple situation to
about half way to the final configuration so that the test eliminates
about half of the remaining possible causes of the problem. Then
repeat this methodology for the next test. This way it would only
take about 10 tests to find the cause out of a thousand possible
causes. You should deviate a little from this method based on hunches
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
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
and try typing on it. See
Before you have trouble, you should find out if your terminal displays
error messages if the hardware is bad. One way to test a terminal
for this is to turn it on with the keyboard unplugged and see if it
displays an error message.
If several lines or text displays on the terminal OK and then it
stops without finishing (in the middle of a word, etc.) or if big
chunks of text are missing, you likely have a problem with flow
control. If you can't figure out right away what's causing it,
decrease the speed. If that fixes it, it's likely a flow control
problem. It may be that flow control is not working at all due to
failure to configure it correctly, or due to incorrect cable wiring
(for hardware flow control). See
If you can type OK at the terminal but when text is sent to the
terminal, only about 1 in every 16 characters sent gets thru, then you
may have given the wrong UART to setserial. This will happen if the
port is an obsolete 16550 (or lower) but you've told setserial it's a
16550A or higher.
If single characters are missing, perhaps the serial port is being
overrun by too fast a speed. Try a slower baud rate.
If your device is under 1200 baud (probably a very slow old hard-copy
terminal or printer) and the text gets truncated, then the problem may
be in the serial device driver. See Printing-HOWTO under "Serial
devices" on how to fix this.
This is where you need to hit a key a few times before it works
(and see the letter you typed on the screen). If you type a word,
some (or even all) of the letters may be missing on the screen. If
letters are missing from a command it doesn't work and even if all
letters are present you may need to hit the return-key several times
to get the command to execute.
This may be due to two different processes opening the serial port. Both
try to read what you type. Sometimes one process (the right one
--perhaps the shell) reads what you type and at other times the other
process reads what you type. An example is where the other process is
for a serial mouse (such as gpm) which doesn't echo what you type.
So another process running on the same ttySx is eating some of what
you type. To fix this, use "ps -alx" to see what else is running on
your ttySx and kill that process.
You might think that lockfiles would prevent two programs from using
the same serial port at the same time. But neither the 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.
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: Id "S2") where S2 is the label 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.
Getty line in /etc/inittab file incorrect
Make sure the the line which calls getty in /etc/inittab is
correct. A typo in "ttySx" (or "DTxxxx" for uugetty) or in "getty"
may cause this problem.
No modem control signal
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
No such serial device
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" (Debian only ??) and/or "setserial" to probe for the device
or try another ttyS. Perhaps the device has been disabled in the
CMOS. See "Serial-HOWTO".
No serial support
Linux provides serial support either by selecting it when
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. To see if
serial support is built into the kernel, check a kernel configuration
file (in /boot, in the source tree, etc.)
Another possible cause of getty respawning too rapidly is if a
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
If you can login OK but then you can't use the terminal it may be
because the starting of the login shell has reconfigured the terminal
(to an incorrect setting) by a command which someone put into one of
the files that are run when you login and a shell starts. These files
include /etc/profile and ~/.bashrc. Look for a command starting with
"stty" or "setserial" and make sure that it's correct. Even if it's
done OK in one initialization file, it may be reset incorrectly in
another initialization file that you are not aware of. Ways to get
into the systems to fix it are to use another terminal or console, use
a rescue diskette, or type: "linux single" at the lilo prompt which
puts you into single user mode without running startup files.
If you get a login prompt but get no response (or perhaps a
garbled response) to your login attempts a possible cause is that the
communication is bad one-way from the terminal to the computer. It
could be a bad or mis-wired cable/connector. If you're not already
using the "local" option with getty, do so to disable the modem
control lines. See
Getty (used in /etc/inittab). You might also disable hardware flow control (stty
-crtscts) if it was enabled. If it now works OK then your modem
control lines are likely either not wired correctly or there's a
mistake in your set-up. Some terminals allow setting different values
(such as baud rate) for send and receive so the receive could be OK
but the send bad.
You should also (at the console) try "stty < /dev/ttyS1" (if you use
ttyS1) to see that it's set up correctly. It will often be in raw
mode (and this is probably OK) with -icanon and -echo etc. If the
terminal incorrectly set at half-duplex (HDX), then one set of the
characters you see when you type are coming from the terminal itself.
If the characters are doubled, then the echos from the computer are OK
and you may switch to full-duplex to fix this. But if half-duplex is
set and you only see what looks like normal "echos", then they are not
coming from the computer as they should be.
If you get a message saying something like "login failed" then if
there is no error in typing or in the password, there may be some
restrictions on logins which will not allow you to log in.
Unfortunately, this message, may not tell you why it failed. See
This may be due to using the wrong character set, transmission
errors due to too high of a baud rate, incompatible baud rates,
incompatible parity, or the wrong number of bits per byte. If it's a
variety of strange characters you have the wrong character set or a
high order bit is being set by mistake. If words are misspelled, try
a lower baud rate. For baud, parity, or bits/character incompatibilities
you see a lot of the same "error character" which represents a real
character that can't be displayed correctly due to an error in parity
or baud rate. The "error character" may be an upside-down question
mark or some other strange looking character such as a rectangle.
If you are using agetty (often just named getty), the agetty program
will detect and set parity and/or bits/character if you type something.
Try it with a return to see if it fixes it.
If there's no login prompt displayed after hitting the return-key
a few times then check the following: Use the "top" or "ps" programs
to make sure that a getty (or login) process is actually running on
the terminal. Is the terminal getting power? Is the null modem cable
plugged in to the correct ports on both the terminal and computer?
Check that getty isn't hanging because there is no CD signal (or no CD
wire in the cable). If such a CD signal doesn't exist you should have
specified "local" to getty by either:
If agetty (Debian, etc.) a -L flag in /etc/inittab (See
If getty (or login) isn't running, carefully check the format for calling getty
in /etc/inittab. Make sure that it includes the current runlevel
(shown by typing the command "runlevel") and that it is valid for your
flavor of getty. Sometimes killing getty or login (it will restart
Terminal was working OK
Although hardware failures are possible, the problem is likely due
to something that someone did by mistake. Did someone do something
that might have loosened a cable? Did someone modify /etc/inittab or
make some other change to the software so as to prevent terminal
login? If this doesn't reveal the cause, continue reading.
The above should solve most cases (unless you've just installed a
terminal). Other causes include defective hardware or cables (must be
null-modem), terminal setup at wrong baud-rate, terminal in local
mode, etc. At this point two different avenues of approach are (you
may pursue more than one at a time).
One test is to try to copy a something to the terminal (It might
be a good idea to try this near the start of the installation process
before setting up getty). You may use the Linux copy command such as:"cp
file_name /dev/ttyS1". Or your could use: "echo any_word >
/dev/ttySx". If it doesn't work, use stty to make the interface as
simple as possible with everything disabled (such as hardware flow
control: -crtscts; parity, and modem control signals: clocal). Be
sure the baud rates and the bits/byte are the same. If nothing
happens verify that the port is alive with a voltmeter per the next
If you have a voltmeter handy check for a negative voltage (-4v to
-15v) at pin 3 (receive data) at the terminal side of the null-modem
cable. The positive lead of the meter should be connected to a good
ground (the metal connectors on the ends of cables are often not
grounded). If there is no such negative voltage then check for it at
the transmit pin (TxD) on the computer (see
DB9-DB25 for the pin-out). If it's present there but not at
the receive pin (RxD) at the terminal, then the cable is bad (loose
connection, broken wire, or not a null-modem). If voltage is absent
at the computer, then its serial port is dead. Test it with a
software diagnostic test or replace it.
If the serial port is alive, you may want to send a file to it (with
modem controls disabled) and watch the signal on a voltmeter (or other
electronic gadget). To check for a transmitted signal with a voltmeter,
check for a steady negative voltage when the line is idle. Then start
sending a file (or start getty). On an analog meter you should see
the needle dropping to almost 0 and fluttering about 0 as it measures
short-run averages of the bit stream. On a digital meter you will not
see the fluctuations as well but you can switch to the AC scale to see
the AC voltage created by the flow of bits. If your meter fails to
block out DC on the AC scale (the default of most analog meters), then
you could get a false high AC reading when looking at the idle DC of
-12 V on the AC scale. Without a meter, you could connect a known
good device (such as another terminal or an external modem) to the
serial port and see if it works OK.
Don't confuse this with
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.
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
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
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 telnet knows that your computer can emulate
more than one terminal type).
Terminal set to display escape sequences
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
One reason may be that something is wrong with terminfo. Another
reason could be that you are outside the scrolling region set for the
terminal. Some stupid programs just assume that your terminal has 24
lines and set the scrolling region for 24 lines (by an escape sequence
sent to the terminal) without consulting terminfo to see how many
lines there actually are. Then when you use another program it may
leave the cursor on line 25 where it becomes trapped and the terminal
will not scroll. To avoid this problem, create an environment
variable "export LINES=25" and also "stty -F /dev/ttySx rows 25".
Then the programs that assume 24 lines will hopefully use 25 lines set
the scrolling region accordingly.
A few Linux programs will monitor the modem control lines and
indicate if they are positive (1) or negative (0).
statserial (in Debian distribution)
serialmon (doesn't monitor RTS, CTS, DSR but logs other
modemstat (only works on Linux PC consoles. Will coexist with
the command line)
You may already have them. If not, go to
Serial Software. When using these, bear in mind that what you
see is the state of the lines at the host computer. The situation at
the terminal will be different since some wires are often missing from
cables while other wires cross over. As of June 1998, I know of no
diagnostic program in Linux for the serial port.
In local mode, the terminal disconnects from the computer and
behaves like a typewriter (only it doesn't type on paper but on the
screen). Going back into on-line mode reconnects to the computer
allowing you to resume activities at the same point where you left off
when you went into "local". This is useful both for testing the
terminal and for educational purposes. For some terminals there is
no "local mode" but "block mode" may substitute for it. If there is
no "block mode", "half duplex" mode might work, except that what you
type gets sent to the computer also. In this case the computer may
echo the characters sent to it resulting in two characters displayed
on the screen for every character you type. To prevent this you could
shut down the computer, disconnect the RS-232 cable, etc.
When in local mode you may type escape sequences (starting with the
ESC key) and observe what they do. If the terminal doesn't work
correctly in local mode, it's unlikely that it will work correctly
when connected to the computer. If you're not exactly sure what an
escape sequence does, you can try it out in local mode. You might
also use it for trying out a terminal that is for sale. To get into
local mode on some terminals you first enter set-up mode and then
select "local" from a menu (or press a certain key). See
Getting Into Set-Up (Configuration) Mode.
While a multimeter (used as a voltmeter) may be all that you need
for just a few serial ports, simple special test equipment has been
made for testing serial port lines. Some are called "breakout ... "
where breakout means to break out conductors from a cable. These
gadgets have a couple of connectors which connect to serial port
connectors (either at the ends of serial cables or at the back of a
PC). Some have test points for connecting a voltmeter. Others have
LED lamps which light when certain modem control lines are asserted
(turned on). The color of the light may indicate the polarity of the
signal (positive or negative voltage). Still others have jumpers so
that you can connect any wire to any wire. Some have switches.
Radio Shack sells (in 2002) a "RS-232 Troubleshooter" (formerly called
"RS-232 Line Tester") Cat. #276-1401. It checks TD, RD, CD, RTS, CTS,
DTR, and DSR. A green light means on (+12 v) while red means off (-12
v). They also sell a "RS-232 Serial Jumper Box" Cat.
#276-1403. This permits connecting the pins anyway you choose. Both
these items are under the heading of "Peripheral hookup helpers".
Unfortunately, they are not listed in the index to the printed
catalog. They are on the same page as the D type connecters so look
in the index under "Connectors, Computer, D-Sub". A store chain named
"Active Components" may have them.
Any voltmeter or multimeter, even the cheapest that sells for
about $10, should work fine. Trying to use other methods for checking
voltage is tricky. Don't use a LED unless it has a series resistor to
reduce the voltage across the LED. A 470 ohm resistor is used for a
20 ma LED (but not all LED's are 20 ma). The LED will only light for
a certain polarity so you may test for + or - voltages. Does anyone
make such a gadget for automotive circuit testing?? Logic probes may
be damaged if you try to use them since the TTL voltages for which
they are designed are only 5 volts. Trying to use a 12 V incandescent
light bulb is not a good idea. It won't show polarity and due to
limited output current of the UART it probably will not even light up.
To measure voltage on a female connector you may plug in a bent paper
clip into the desired opening. The paper clip's diameter should be no
larger than the pins so that it doesn't damage the contact. Clip
an alligator clip (or the like) to the paper clip to connect up. Take
care not to touch two pins at the same time with any metal object.
As a last resort, if you have no test equipment and are willing to
risk getting shocked (or even electrocuted) you can always taste the
voltage. Before touching one of the test leads with your tongue, test
them to make sure that there is no high voltage on them. Touch both
leads (at the same time) to one hand to see if they shock you. Then
if no shock, wet the skin contact points by licking and repeat. If
this test gives you a shock, you certainly don't want to use your
For the test for 12 V, Lick a finger and hold one test lead in it.
Put the other test lead on your tongue. If the lead on your tongue is
positive, there will be a noticeable taste. You might try this with
flashlight batteries first so you will know what taste to expect.