If you suspect that the problem is a hardware problem, see the Repair and Diagnose section. If it's the keyboard see 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.
Here is a list of possible problems:
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. See 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 the terminal isn't responding correctly (if at all) to what you type to it, you may have a Corrupted Terminal Interface.
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 Serial Monitoring/Diagnostics
One approach is to first see if 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 and clues.
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 Local Mode. 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 Flow Control
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 rapidly respawns over and over. But the operating system intervenes and stops this nonsense (for 5 minutes). The following sections show possible causes and fixes.
Make sure 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.
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 getty_ps).
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.
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".
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 can happen if the key gets stuck in the down position. 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 characters).
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 try at another terminal (such as the console) "stty -F /dev/ttyS1" (or ttyS whatever) 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 Login Restrictions
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 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 automatically) helps.
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 file-transfer), 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 section.
If you have a voltmeter handy check for a negative voltage (-4v to -15v) at pin 3 or 2 (receive data) at the terminal side of the file-transfer cable. The positive lead of the meter should be connected to a good ground (a metal connector on the end of the cable may not be 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 file-transfer aka null-modem). If this 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 -12v (or -5v) 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 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).
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).
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 Control Codes.
You likely have mis-set interrupts> See the Serial-HOWTO section starting with "Slow:"
This error happens when you expect the cursor to move to the next character but instead it seems to jump to another character. It can happen in the vim editor when you've selected "showmatch" to highlight matching brackets (or parentheses). There is nothing wrong with the terminal and the cursor isn't jumping, but it looks like it is.
What is happening is that the cursor is reverse video and the highlighting is also reverse video. So suppose you highlight (or emphasize) a character by reverse video and then put a reverse-video cursor over it. The cursor's reverse video will then reverse the existing reverse video of the character and result in normal video. The result is that both the cursor and character highlighting have disappeared for that character and the cursor is invisible (until you move it to a non-highlighted character).
OK, so the cursor suddenly disappears, but what makes it jump? For the vim "showmatch" when you move the cursor to an opening bracket it also highlights the closing bracket. Thus the closing bracket suddenly becomes reverse video and it looks just like the cursor has jumped there, but it hasn't. Similar "illusions" happen when you move the cursor to a closing bracket (or parenthesis). This illusion when you reverse reverse-video happens in other cases besides the vim example just presented.
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).
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 tongue.
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.