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

updated

This commit is contained in:
gferg 2000-12-27 16:02:51 +00:00
parent 1e848cf44c
commit f21ecf4958
2 changed files with 1040 additions and 893 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

File diff suppressed because it is too large Load Diff

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

@ -3,11 +3,13 @@
<title> Text-Terminal-HOWTO
<author> David S. Lawyer <url url="mailto:dave@lafn.org">
<date> v1.17, December 2000
<date> v1.18, December 2000
<!--
Change log:
v1.17 December 2000 Don't run getty from the command line,
v1.18 Dec. 2000 mesg command, respawning error cause, chaos when 2
processes open same terminal, rebooting
v1.17 Dec. 2000 Don't run getty from the command line,
XDM-and-X-Terminal mini-HOWTO, substitutes for "local mode",
character mapping with "mapchan"
v1.16 October 2000 Thin clients+; NC Howtos; Correction of bad typo
@ -151,10 +153,9 @@ sites see: <url url="http://linuxdoc.org/mirrors.html">.
Various formats are available. If you only want to quickly check the
date of the latest version look at <url
url="http://linuxdoc.org/HOWTO/Text-Terminal-HOWTO.html">. The
version your are currently reading is: v1.17, December 2000 . New in this version
is: Don't run getty from the command line,
XDM-and-X-Terminal mini-HOWTO, substitutes for "local mode",
character mapping with "mapchan"
version your are currently reading is: v1.18, December 2000 . New in this version:
v1.18: mesg command, respawning error cause, chaos when 2 processes
open same terminal, rebooting.
<sect1> Related HOWTOs, etc. <label id="related_howtos">
<p> Go to the websites shown above to get these.
@ -1810,7 +1811,7 @@ Using the above 2 connections provide full modem control signals and
seemingly allow one to set "stty -clocal". Then one must turn on the
terminal first (asserts DTR) before the port may be opened in a normal
manner by getty, etc. But there is likely to be trouble if you fail
to turn on the terminal first (see <ref id="fast_respawn" name="Getty
to turn on the terminal first (see <ref id="rapid_respawn" name="Getty
Respawning Too Rapidly">). For this reason one should use "stty
clocal" which is the default (ignores modem control lines) and the
additional wires in these cables then serve no useful purpose.
@ -3206,6 +3207,7 @@ which runs <tt/stty/ since on seldom need it.
Change Log:
May 2000: <sect2> IRQs near end ttyS0 -> ttyS1 + clarity
Nov. 2000: auto_irq may work on the 2nd try
Dec. 2000: saving state of serial module
-->
<p> This part is in 3 HOWTOs: Modem, Serial, and Text-Terminal. There
are some minor differences, depending on which HOWTO it appears in.
@ -3239,14 +3241,15 @@ Linux.
<tt/Setserial/ is often run automatically at boot-time by a start-up
shell-script for the purpose of assigning IRQs, etc. to the driver.
Setserial will only work if the serial module is loaded (or if the
equivalent was compiled into your kernel). If you should (for some
reason) unload the serial module later on, the changes previously made
by <tt/setserial/ will be forgotten by the kernel. So <tt/setserial/
must be run again to reestablish them. In addition to running via a
start-up script, something akin to <tt/setserial/ also runs earlier
when the serial module is loaded (or the like). Thus when you watch
the start-up messages on the screen it may look like it ran twice, and
in fact it has.
equivalent was compiled into your kernel). If the serial module gets
unloaded later on, the changes previously made by <tt/setserial/ will
be forgotten by the kernel. But recent (2000) distributions may
contain scripts that save and restore this. If not, then
<tt/setserial/ must be run again to reestablish them. In addition to
running via a start-up script, something akin to <tt/setserial/ also
runs earlier when the serial module is loaded (or the like). Thus
when you watch the start-up messages on the screen it may look like it
ran twice, and in fact it has.
Setserial can set the time that the port will keep operating after
it's closed (in order to output any characters still in its buffer in
@ -3287,15 +3290,16 @@ having problems there is a good chance that "setserial" has it wrong.
In fact, you can run "setserial" and assign a purely fictitious I/O
port address, any IRQ, and whatever uart type you would like to have.
Then the next time you type "setserial ..." it will display these
bogus values without complaint. Of course the serial port driver will
not work correctly (if at all) if you attempt to use such a port.
Thus when giving parameters to "setserial" anything goes. Well
almost. If you assign one port a base address that is already assigned
(such as 3e8) it will not accept it. But if you use 3e9 it will
accept it. Unfortunately 3e9 is already assigned since it is within
the range starting at base address 3e8. Thus the moral of the story
is to make sure of your data before assigning resources with
setserial.
bogus values without complaint. They will also be officially
registered with the kernel as seen by the "scanport" command.
Of course the serial port driver will not work correctly (if at all)
if you attempt to use such a port. Thus when giving parameters to
"setserial" anything goes. Well almost. If you assign one port a
base address that is already assigned (such as 3e8) it will not accept
it. But if you use 3e9 it will accept it. Unfortunately 3e9 is
already assigned since it is within the range starting at base address
3e8. Thus the moral of the story is to make sure of your data before
assigning resources with setserial.
While assignments made by setserial are lost when the PC is powered
off, a configuration file may restore them (or a previous
@ -3338,7 +3342,7 @@ probe for UARTs is made automatically and reported on the screen. But
the IRQs shown may be wrong. The second report of the same is the
result of a script which usually does no probing and thus provides no
reliable information as to how the hardware is actually set. It only
shows configuration date someone wrote into the script or data that
shows configuration data someone wrote into the script or data that
got saved in /etc/serial.conf.
It may be that two serial ports both have the same IO address set in
@ -3855,7 +3859,7 @@ characters which are sent to the screen (output). This is nice for
remapping the keyboard for foreign language alphabets. Most
distributions don't seem to supply it (let me know if any do). Source
code by Yura Kalinichenko (Ukraine) is at <url
url="http://www.kron.vinnica.ua/free">
url="http://www.kron.vinnica.ua/free/download/">
<sect>Terminfo and Termcap (detailed) <label id="termcap2">
@ -4185,7 +4189,7 @@ by default. Check <tt>/etc/profile</tt>, etc. for <tt/ls/ aliases.
See <ref id="ls_color" name="Example for ls Function"> for how to
have <tt/ls/ do color for the console and do monochrome for terminals.
<sect1> Display Freezes (hung terminal)
<sect1> Display Freezes (hung terminal) <label id="display_freezes">
<p> The symptom of a hung terminal is where what you type doesn't display
on the terminal (or in some cases displays but doesn't do anything).
If what you type is invisible (or does nothing) type ^Q to restart flow
@ -4198,11 +4202,14 @@ you interaction with it fatally illegal.
If you want to quit the program you were running and you can't do it
by the usual methods (some programs have special keys you must hit to
exit) then try killing it from another terminal using "top" or "kill".
If the process refuses to die, you may try sending it signal 9 from
top which should force it to exit. The "9" type of forced exit may
leave some temporary files lying around as well as a corrupted
interface. Killing the login shell should result in a startup of
getty with a new login prompt.
If the process refuses to die, then kill it with signal 9 from top (or
use "kill" on the command line). The "9" type of forced exit may leave
some temporary files lying around as well as a corrupted interface.
If this doesn't work, killing the login shell should result in a
startup of getty with a new login prompt. If all else fails, you may
need to reboot the computer or even power it down. Just rebooting may
not alter the possibly corrupted content of the serial port hardware
registers.
<label id="ctrl_s">
People new to Linux may unintentionally press Ctrl-S (^S) (or the "No
@ -4565,7 +4572,7 @@ the host computer and not inside the terminal as they are with
<sect1> Logging Out
<p> To log out type either "logout" or "exit". Under some
circumstances your request will be refused, but you should be told why.
One reason for refusal is if you are not in the same shell into which
One reason for refusal is if you are not in the same shell that
you logged into. Another way to log out is to press ^D. Since ^D is
also used for other purposes, you may not want it to log you out. If
you set IGNOREEOF in the Bash shell then ^D will no longer log you
@ -4574,8 +4581,9 @@ out.
<sect1> Chatting between Terminals, Spying
<p> If two persons logged into terminals on the same host computer
want to chat with each other they may use the "write" or the "talk"
program. On the Internet, chatting may be done using the "lynx"
browser.
(better) program. One may prevent anyone (except the superuser) from
writing (sending messages) to their terminal by using the "mesg"
command.
For spying on what someone else is doing at their terminal use the
"ttysnoop" program. In "ttysnoop" the two terminals have the same
@ -4657,19 +4665,25 @@ involves the serial port itself see the Serial-HOWTO.
Here is a list of possible problems:
<itemize>
<item> <ref id="term_OK" name="Is the Terminal OK ?">
<item><ref id="term_OK" name="Is the Terminal OK ?">
Suspect the terminal is defective.
<item> <ref id="flow_ctrl_ng" name="Missing Text"> Either skips
over some text or displays some text OK and hangs.
<item> <ref id="stopped_" name="Programs get Stopped"> with
<item><ref id="display_freezes" name="Display Freezes (hung
terminal)">
<ref id="keys_erratic" name="All Keys Work Erratically; Must Hit a Key
a Few Times">
<item><ref id="flow_ctrl_ng" name="Missing Text"> Either skips
over some text or displays some text OK and hangs.
<item><ref id="keys_erratic" name="All Keys Work Erratically; Must Hit
a Key a Few Times">
<item><ref id="stopped_" name="Programs get Stopped"> with
message "Stopped"
<item> <ref id="fast_respawn" name="Getty Respawning Too Rapidly">
<item><ref id="rapid_respawn" name="Getty Respawning Too Rapidly">
(console error message)
<item> <ref id="after_login" name="Fails Just After Login">
<item> <ref id="cant_login" name="Can't Login"> but login prompt is
<item><ref id="after_login" name="Fails Just After Login">
<item><ref id="cant_login" name="Can't Login"> but login prompt is
OK.
<item> <ref id="garbled" name="Garbled Login Prompt">
<item> <ref id="blank_" name="No Sign of any Login Prompt">
<item><ref id="garbled" name="Garbled Login Prompt">
<item><ref id="blank_" name="No Login Prompt">
</itemize>
There are two cases where the terminal goes bad. One is when it's
@ -4749,28 +4763,62 @@ for this is to turn it on with the keyboard unplugged and see if it
displays an error message.
<sect1> Missing Text <label id="flow_ctrl_ng">
<p> 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 <ref id="flow_control" name="Flow Control">
<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 <ref id="flow_control" name="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 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 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.
<sect1> Getty Respawning Too Rapidly <label id="fast_respawn">
<sect2> Serial Module Not Loaded
<p> Use the "lsmod" command to see if the serial module is loaded.
<sect1> All Keys Work Erratically; Must Hit a Key a Few Times
<label id="keys_erratic">
<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.
<sect2> No Modem Control Signal
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 this. 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.
<sect1> Getty Respawning Too Rapidly <label id="rapid_respawn">
<sect2> No serial support
<p> Linux provides serial support either by selecting it when
compiling the kernel or by loading the serial module. 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.
<sect2> No modem control signal
<p> If getty can't open and/or use a port because of the lack of a
positive modem control voltage on one of the pins, then getty might
be killed. Then, per the instructions in inittab, getty respawns and
@ -4843,15 +4891,26 @@ 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.
<sect1> No Sign of any Login Prompt <label id="blank_">
<sect1> No Login Prompt <label id="blank_">
<p> 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
to the correct connector on both the computer and terminal. Other
causes include defective hardware or cables (must be null-modem),
getty not running, 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).
local mode, etc.
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 getty 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 (it will restart automatically) helps.
At this point two different avenues of approach are (you may pursue
more than one at a time).
<itemize>
<item> <ref id="consoleD" name="Diagnose Problem from the Console">
@ -4860,23 +4919,16 @@ approach are (you may pursue more than one at a time).
</itemize>
<sect2> Diagnose Problem from the Console <label id="consoleD">
<p> 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 getty 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.
One test is to try 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.
<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.
<sect2> Measure Voltages <label id="measure_volts">
<p> If you have a voltmeter handy check for a negative voltage (-4v to
@ -4887,21 +4939,24 @@ grounded). If there is no such negative voltage then check for it at
the transmit pin (TxD) on the computer (see <ref id="DB_pin-out"
name="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 a software
diagnostic test or replace it.
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 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 known good device (such as another terminal or an
external modem) to the serial port and see if it works OK.
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.
<sect1> Slow: pauses of several seconds between bursts of characters
<p> You likely have mis-set interrupts> See the Serial-HOWTO section