623 lines
33 KiB
HTML
623 lines
33 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.21">
|
|
<TITLE> Text-Terminal-HOWTO: Trouble-Shooting </TITLE>
|
|
<LINK HREF="Text-Terminal-HOWTO-20.html" REL=next>
|
|
<LINK HREF="Text-Terminal-HOWTO-18.html" REL=previous>
|
|
<LINK HREF="Text-Terminal-HOWTO.html#toc19" REL=contents>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="Text-Terminal-HOWTO-20.html">Next</A>
|
|
<A HREF="Text-Terminal-HOWTO-18.html">Previous</A>
|
|
<A HREF="Text-Terminal-HOWTO.html#toc19">Contents</A>
|
|
<HR>
|
|
<H2><A NAME="trouble_shoot"></A> <A NAME="s19">19.</A> <A HREF="Text-Terminal-HOWTO.html#toc19">Trouble-Shooting </A></H2>
|
|
|
|
<P> If you suspect that the problem is a hardware problem, see the
|
|
<A HREF="Text-Terminal-HOWTO-20.html#repair_">Repair and Diagnose</A> section. If it's the
|
|
keyboard see
|
|
<A HREF="Text-Terminal-HOWTO-20.html#keyboards_">Keyboards</A>. If it responds
|
|
incorrectly (if at all) to what you type. see
|
|
<A HREF="Text-Terminal-HOWTO-17.html#corrupt_interface">Corrupted Terminal Interface</A>. If the
|
|
problem involves the serial port itself see the Serial-HOWTO.</P>
|
|
<P>Here is a list of possible problems:
|
|
<UL>
|
|
<LI>
|
|
<A HREF="#term_OK">Is the Terminal OK ?</A>
|
|
Suspect the terminal is defective.</LI>
|
|
<LI>
|
|
<A HREF="Text-Terminal-HOWTO-17.html#display_freezes">Display Freezes (hung terminal)</A></LI>
|
|
<LI>
|
|
<A HREF="#displays_foreign">Displays Foreign/Weird Characters/Symbols</A></LI>
|
|
<LI>
|
|
<A HREF="#displays_esc-seqs">Displays Escape Sequences</A></LI>
|
|
<LI>
|
|
<A HREF="#flow_ctrl_ng">Missing Text</A> Either skips
|
|
over some text or displays some text OK and hangs.</LI>
|
|
<LI>
|
|
<A HREF="#keys_erratic">All Keys Work Erratically; Must Hit a Key a Few Times</A></LI>
|
|
<LI>
|
|
<A HREF="Text-Terminal-HOWTO-15.html#stopped_">If getty run from command line: Programs get stopped</A> with message "Stopped"</LI>
|
|
<LI>
|
|
<A HREF="#rapid_respawn">Getty Respawning Too Rapidly</A>
|
|
(console error message)</LI>
|
|
<LI>
|
|
<A HREF="#after_login">Fails Just After Login</A></LI>
|
|
<LI>
|
|
<A HREF="#cant_login">Can't Login</A> but login prompt is
|
|
OK.</LI>
|
|
<LI>
|
|
<A HREF="#garbled">Garbled Login Prompt</A></LI>
|
|
<LI>
|
|
<A HREF="#no_login_prompt">No Login Prompt</A></LI>
|
|
<LI>
|
|
<A HREF="#cursor_jumps">Cursor Jumps</A></LI>
|
|
</UL>
|
|
</P>
|
|
<P>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.</P>
|
|
|
|
<H2><A NAME="term_was_ok"></A> <A NAME="ss19.1">19.1</A> <A HREF="Text-Terminal-HOWTO.html#toc19.1">Terminal Was Working OK </A>
|
|
</H2>
|
|
|
|
<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 that you used did).</P>
|
|
<P>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
|
|
<A HREF="Text-Terminal-HOWTO-20.html#repair_">Repair & Diagnose</A>. 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?</P>
|
|
<P>If the terminal isn't responding correctly (if at all) to what you
|
|
type to it, you may have a
|
|
<A HREF="Text-Terminal-HOWTO-17.html#corrupt_interface">Corrupted Terminal Interface</A>.</P>
|
|
|
|
<H2><A NAME="trouble_shoot_new"></A> <A NAME="ss19.2">19.2</A> <A HREF="Text-Terminal-HOWTO.html#toc19.2">Terminal Newly Installed </A>
|
|
</H2>
|
|
|
|
<P> 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
|
|
<A HREF="#term_was_ok">Terminal Was Working OK</A> 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
|
|
<A HREF="#serial_mon">Serial Monitoring/Diagnostics</A></P>
|
|
<P>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.</P>
|
|
|
|
<H2><A NAME="term_OK"></A> <A NAME="ss19.3">19.3</A> <A HREF="Text-Terminal-HOWTO.html#toc19.3">Is the Terminal OK ? </A>
|
|
</H2>
|
|
|
|
<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>
|
|
<P>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
|
|
<A HREF="Text-Terminal-HOWTO-20.html#repair_">Repair & Diagnose</A> for tips on repairing it.</P>
|
|
<P>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
|
|
<A HREF="#local_mode">Local Mode</A>.
|
|
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.</P>
|
|
|
|
<H2><A NAME="flow_ctrl_ng"></A> <A NAME="ss19.4">19.4</A> <A HREF="Text-Terminal-HOWTO.html#toc19.4">Missing Text </A>
|
|
</H2>
|
|
|
|
<P> 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
|
|
<A HREF="Text-Terminal-HOWTO-11.html#flow_control">Flow Control</A></P>
|
|
<P>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.</P>
|
|
<P>If single characters are missing, perhaps the serial port is being
|
|
overrun by too fast a speed. Try a slower baud rate.</P>
|
|
<P>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.</P>
|
|
|
|
<H2><A NAME="keys_erratic"></A> <A NAME="ss19.5">19.5</A> <A HREF="Text-Terminal-HOWTO.html#toc19.5">All Keys Work Erratically; Must Hit a Key a Few Times</A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
|
|
<H2><A NAME="rapid_respawn"></A> <A NAME="ss19.6">19.6</A> <A HREF="Text-Terminal-HOWTO.html#toc19.6">... respawning too fast: disabled for 5 minutes</A>
|
|
</H2>
|
|
|
|
<H3>What's happening</H3>
|
|
|
|
<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: Id "S2") where S2 is the label for the line in /etc/inittab
|
|
from where from where getty was called.</P>
|
|
<P>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.</P>
|
|
|
|
<H3>Getty line in /etc/inittab file incorrect</H3>
|
|
|
|
<P>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. </P>
|
|
|
|
<H3>No modem control signal</H3>
|
|
|
|
<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 getty_ps).</P>
|
|
<P>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.</P>
|
|
|
|
<H3>No such serial device</H3>
|
|
|
|
<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" (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".</P>
|
|
|
|
<H3>No serial support</H3>
|
|
|
|
<P> 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.)</P>
|
|
|
|
<H3><A NAME="key_shorted_getty"></A> Key shorted </H3>
|
|
|
|
<P> 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).</P>
|
|
|
|
<H2><A NAME="after_login"></A> <A NAME="ss19.7">19.7</A> <A HREF="Text-Terminal-HOWTO.html#toc19.7">Fails Just After Login </A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
|
|
<H2><A NAME="cant_login"></A> <A NAME="ss19.8">19.8</A> <A HREF="Text-Terminal-HOWTO.html#toc19.8">Can't Login </A>
|
|
</H2>
|
|
|
|
<P> 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
|
|
<A HREF="Text-Terminal-HOWTO-15.html#getty_">Getty (used in /etc/inittab)</A>. 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.</P>
|
|
<P>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.</P>
|
|
<P>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
|
|
<A HREF="Text-Terminal-HOWTO-15.html#login_restr">Login Restrictions</A></P>
|
|
|
|
<H2><A NAME="garbled"></A> <A NAME="ss19.9">19.9</A> <A HREF="Text-Terminal-HOWTO.html#toc19.9">Garbled Login Prompt </A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
<P>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.</P>
|
|
|
|
<H2><A NAME="no_login_prompt"></A> <A NAME="ss19.10">19.10</A> <A HREF="Text-Terminal-HOWTO.html#toc19.10">No Login Prompt </A>
|
|
</H2>
|
|
|
|
<P> 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?</P>
|
|
<P>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:
|
|
<UL>
|
|
<LI>If getty_ps (Redhat, etc.) two CLOCAL flags in /etc/gettydefs
|
|
(See
|
|
<A HREF="Text-Terminal-HOWTO-15.html#getty_ps">getty (part of getty_ps)</A>).</LI>
|
|
<LI>If agetty (Debian, etc.) a -L flag in /etc/inittab (See
|
|
<A HREF="Text-Terminal-HOWTO-15.html#agetty_">agetty</A>).</LI>
|
|
</UL>
|
|
</P>
|
|
<P>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.</P>
|
|
|
|
<H3>Terminal was working OK</H3>
|
|
|
|
<P> 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.</P>
|
|
|
|
<H3>More diagnose</H3>
|
|
|
|
<P> 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).</P>
|
|
<P>
|
|
<UL>
|
|
<LI>
|
|
<A HREF="#consoleD">Diagnose problem from the console</A></LI>
|
|
<LI>
|
|
<A HREF="#measure_volts">Measure voltages</A></LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H3><A NAME="consoleD"></A> Diagnose problem from the console </H3>
|
|
|
|
<P> 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.</P>
|
|
|
|
<H3><A NAME="measure_volts"></A> Measure voltages </H3>
|
|
|
|
<P> 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
|
|
<A HREF="Text-Terminal-HOWTO-12.html#DB_pin-out">DB9-DB25</A> 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.</P>
|
|
<P>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.</P>
|
|
|
|
<H2><A NAME="displays_foreign"></A> <A NAME="ss19.11">19.11</A> <A HREF="Text-Terminal-HOWTO.html#toc19.11">Displays Foreign/Weird Characters/Symbols</A>
|
|
</H2>
|
|
|
|
<P> Don't confuse this with
|
|
<A HREF="#displays_esc-seqs">Displays Escape Sequences</A>. 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.</P>
|
|
<P>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.</P>
|
|
|
|
<H2><A NAME="displays_esc-seqs"></A> <A NAME="ss19.12">19.12</A> <A HREF="Text-Terminal-HOWTO.html#toc19.12">Displays Escape Sequences </A>
|
|
</H2>
|
|
|
|
<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.</P>
|
|
<P>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).</P>
|
|
|
|
<H3>Telnet</H3>
|
|
|
|
<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 telnet knows that your computer can emulate
|
|
more than one terminal type).</P>
|
|
|
|
<H3>Terminal set to display escape sequences</H3>
|
|
|
|
<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
|
|
<A HREF="Text-Terminal-HOWTO-8.html#control_codes">Control Codes</A>.</P>
|
|
|
|
<H2><A NAME="ss19.13">19.13</A> <A HREF="Text-Terminal-HOWTO.html#toc19.13">Slow: pauses of several seconds between bursts of characters</A>
|
|
</H2>
|
|
|
|
<P> You likely have mis-set interrupts> See the Serial-HOWTO section
|
|
starting with "Slow:"</P>
|
|
|
|
<H2><A NAME="cursor_jumps"></A> <A NAME="ss19.14">19.14</A> <A HREF="Text-Terminal-HOWTO.html#toc19.14">Cursor Jumps </A>
|
|
</H2>
|
|
|
|
<P>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.</P>
|
|
<P>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).</P>
|
|
<P>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.</P>
|
|
|
|
<H2><A NAME="no_scroll_25"></A> <A NAME="ss19.15">19.15</A> <A HREF="Text-Terminal-HOWTO.html#toc19.15">Terminal doesn't scroll </A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
|
|
<H2><A NAME="serial_mon"></A> <A NAME="ss19.16">19.16</A> <A HREF="Text-Terminal-HOWTO.html#toc19.16">Serial Monitoring/Diagnostics </A>
|
|
</H2>
|
|
|
|
<P> A few Linux programs will monitor the modem control lines and
|
|
indicate if they are positive (1) or negative (0).
|
|
<UL>
|
|
<LI> statserial (in Debian distribution)</LI>
|
|
<LI> The "file": /proc/tty/driver/serial. Use "watch head ..." to
|
|
monitor it. Has info on errors and byte flow.</LI>
|
|
<LI> modemstat (only works on Linux PC consoles. Will coexist with
|
|
the command line)</LI>
|
|
</UL>
|
|
|
|
You may already have the above programs. If not, go to
|
|
<A HREF="http://ibiblio.org/pub/Linux/system/serial/">Serial Software</A>. 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.</P>
|
|
|
|
<H2><A NAME="local_mode"></A> <A NAME="ss19.17">19.17</A> <A HREF="Text-Terminal-HOWTO.html#toc19.17">Local Mode </A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
<P>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
|
|
<A HREF="Text-Terminal-HOWTO-14.html#enter_setup">Getting Into Set-Up (Configuration) Mode</A>.</P>
|
|
|
|
<H2><A NAME="ser_elect_test"></A> <A NAME="ss19.18">19.18</A> <A HREF="Text-Terminal-HOWTO.html#toc19.18">Serial Electrical Test Equipment </A>
|
|
</H2>
|
|
|
|
<H3>Breakout Gadgets, etc.</H3>
|
|
|
|
<P> 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.</P>
|
|
<P>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.</P>
|
|
|
|
<H3>Measuring voltages</H3>
|
|
|
|
<P> 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.</P>
|
|
<P>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.</P>
|
|
|
|
<H3>Taste voltage</H3>
|
|
|
|
<P> 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.</P>
|
|
<P>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.</P>
|
|
|
|
|
|
<HR>
|
|
<A HREF="Text-Terminal-HOWTO-20.html">Next</A>
|
|
<A HREF="Text-Terminal-HOWTO-18.html">Previous</A>
|
|
<A HREF="Text-Terminal-HOWTO.html#toc19">Contents</A>
|
|
</BODY>
|
|
</HTML>
|