If you suspect that the problem is a hardware problem, see Repair and Diagnose section .
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 if you think about what recently happened it will likely give a clue to the cause of the problem.
The problem may be obvious such as an error message when the terminal is first turned on. If it makes a 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 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.
A good terminal will usually start up with some words on the screen. If these words convey no error message, its probably OK. If there is no sign of power (no lights on, 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. 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.
If some text displays on the terminal OK and then it stops without finishing (in the middle of a word, etc.) or if 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 single characters are missing, perhaps the serial port is being overrun by too fast a speed. Try a slower baud rate.
If you are using a baud rate under 1200 (very slow, mostly used for old hard-copy terminals and printers) 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.
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 indicating that due to getty respawning too rapidly it has been temporarily disabled. Try using the "local" option with getty and/or check the modem control settings and voltages.
Another possible cause of getty respawning is if a keyboard key is shorted, giving the same result as if the key was continuously held down. With auto-repeat enabled, this "types" thousands 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. If you're not already using the "local" option with getty, do so to disable the modem control lines. See Getty (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.
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 or incompatible parity. 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 or parity 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.
If you are using agetty (often just named getty), the agetty program will detect and set parity if you type something. Try it with a return to see if it fixes possible parity errors.
This is when nothing at all happens at the terminal, but the terminal seems to be working OK. One of the first things to do is to make sure that all cable connections are tight and connected correctly. Other problems could be: A baud rate mismatch, broken hardware, or Getty not running. At this point two different avenues of approach are (you may pursue more than one at a time).
At the console (or another working terminal), use "top" or "ps -al" to see if getty is running on the port. Don't confuse it with getty programs running on other ports or on the virtual consoles. You will not get a login prompt unless getty runs. If it's running then you may disable it so that you can try to copy a file to the terminal as a test.
To disable getty, edit /etc/inittab and comment out the getty command with an initial # so that it will not respawn after you kill it. Then kill the old getty using the k key while in "top".
To copy a short file to the terminal (It might be a good idea to try this near the start of the installation process before setting up getty) use the Linux copy command such as: cp file_name /dev/ttyS1. 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 -12 V (-5 to -15) 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, then the serial port on the computer is dead. Test it with software diagnostics or replace it.
If the serial port is alive, you may want to send a file to it (with modem controls disabled) and see if anything gets to it. To check for a transmitted signal with an analog voltmeter, look at the needle at -12 V when the line is idle. Then start sending a file (or start getty). You should see the needle dropping to 0 and fluttering about 0 as it measures short-run averages of the bit stream. You can see this also on the AC scale provided that your meter has a capacitor to block out DC voltages when on the AC scale. If it doesn't, then the idle DC of -12 V will cause a high false AC reading. Without a meter, you could connect a good device (such as another terminal or an external modem) to the serial port and see if it works OK.
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 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. 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 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 terminals, 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 on them and insert into the serial cable. Some have test points for connecting a voltmeter. Others have LED lamps which light when certain modem control lines are asserted (turned on). Still others have jumpers so that you can connect any wire to any wire. Some have switches.
Radio Shack sells (in 1998) a "RS-232 Troubleshooter" or "RS-232 Line Tester" which 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" which permits connecting the pins anyway you choose.
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.
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.