 |
» |
|
|
|
There are a number of terminal-related problems
that can occur. Many of these result in a terminal that appears not
to communicate with the computer. Other problems cause “garbage” to appear on the screen (either instead of the data you expected
or intermixed with your data). This section primarily addresses problems with
alpha-numeric display terminals; however, many of the steps discussed
here can also be applied to problems with terminal emulators such
as HP AdvanceLink (running on a Vectra PC) or X Window terminal processes
(such as hpterm and xterm).
Also see “Other Terminal Problems”. Unresponsive Terminals | |
There are many things that can cause a terminal
not to respond (no characters are displayed except, perhaps, those
which are displayed by the terminal’s local echo setting).
Here is a procedure you can use to find many of them. Determine
the status of the system. Is the system still up? If not, you’ve probably
found your problem. You will need to reboot the system. Is the system in single
user state? If so, the only active terminal will be the
system console. Other terminals will not respond. You will need to
switch to a multiuser state. See the init(1M) manpage
for more information on changing run states. Determine
if an editor is running on the terminal. This is best done from another terminal. Issue the command: This displays all processes
associated with the terminal with which
you are having problems. For each entry, check in the column marked COMMAND to see if the process represented by that entry
is an editor. If you find that an editor is running at the terminal, it is probably in a text-entry mode. You
will need to save the work and exit the editor. For directions on
how to do this, consult the manpage for the appropriate editor. | | | |  | CAUTION: If you are not sure of the status of the work
being edited, DO NOT simply save the file and
exit. You will overwrite the previous contents of the file with unknown
text. Save the work in progress to a temporary file so that both the
original and edited versions of the file are accessible. | | | | |
Enter Ctrl-Q at the terminal
keyboard. Terminals frequently use the start/stop (XON/XOFF) protocol
to start and stop output to them. stop is
usually defined as Ctrl-S (XOFF) and start as Ctrl-Q (XON). If output
to the terminal was stopped because a stop signal was sent from the terminal to the computer, it can be restarted
by sending the computer a start signal (for
example, type Ctrl-Q from the problem terminal’s keyboard). Sending
the start signal does not harm anything even
if no stop signal was previously sent. If the problem is an application program that’s
looping or not functioning properly, try pressing the Break key and then try the intr signal (usually Ctrl-C) or the quit signal (usually Ctrl-\) to see if you can get a shell prompt
back. To find out what the intr or quit signal is for the affected terminal, go to a working
terminal and enter the command: # stty -a < /dev/terminal-device |
For example: | | | |  | NOTE: The stty command, above, should
only be used with device file names for currently active terminal device files (use the who -R command
to see which device files are active). If you attempt to execute stty with a nonactive tty device file, the command may
hang, waiting for input. Press Ctrl-C to abort it. | | | | |
Reset
the terminal. The terminal itself may be
stuck in an unusable state. Try resetting it. Consult your terminal
owners document for information on how to do this. Powering the terminal
off, waiting for a few seconds and powering it back on will also reset
the terminal. | | | | | NOTE: Power cycling a terminal can have the same effect
as sending a BREAK, which can make the host think it got a BREAK and
change the baud rate. If this happens a lot, use a gettydefs entry that does not cycle through baud rates. | | | | |
Check
the terminal configuration. The terminal
may not be configured correctly. You should verify the following: Is the terminal in Remote
* mode? It should be. Is Block * mode turned
ON? It should not be. Is Line * mode turned
ON? It should not be. Is Modify * mode turned
ON? It should not be.
Check
the physical connection. Check to make sure
that: All cables are firmly
attached and in their proper locations. All interface cards are
firmly seated in their slots. The power cord to the
terminal is firmly connected. The power switch is turned
on.
Kill
processes associated with the problem terminal. | | | | | CAUTION: Use extreme caution when
killing processes. The processes will be immediately and unconditionally
terminated. Some valid processes might take a long time to complete.
Be sure to type carefully when entering the PID numbers for the kill command to avoid killing the wrong process. | | | | |
If you have another terminal that is still working,
go to that terminal and log in (you will need to be superuser). Execute
the command: This displays all processes
associated with the terminal with which
you are having problems. Look at the column marked PID (these are the process IDs for the processes associated with that
terminal). Execute the following command, listing each process ID
associated with the problem terminal: For example: This should kill all processes associated with
that terminal. The init process will then respawn
a getty process for that terminal (if it has
been set up to do that, in the /etc/inittab file)
and you should once again be able to log in. Attempt
to log in to the previously hung terminal again. If you are successful, you’ve fixed the problem.
If not, continue to the next step. Use cat to send an ASCII file to the hung terminal’s
device file. HP-UX communicates with peripherals
through device files. These special files are typically located in
the directory /dev and are used by HP-UX to determine
which driver should be used to talk to the device (by referencing
the major number) and to determine
the address and certain characteristics of the device with which HP-UX
is communicating (by referencing the minor number). Try using the cat command to
send an ASCII file (such as /etc/motd or /etc/issue) to the device file associated with the problem
terminal. For example, if your problem terminal is associated with
the device file ttyd1p4: # cat /etc/motd > /dev/ttyd1p4 |
You should expect to see the contents of the file /etc/motd displayed on the terminal associated with the
device file /dev/ttyd1p4. If you do not, continue
to the next step. Check
the parameters of the device file for the problem terminal. Device files have access permissions associated with
them, just as other files do. The file’s access permissions
must be set so that you have access to the file. If you set the file's
permissions mode to 0622 (crw--w--w-), you should
be safe. If the file’s permissions are set to allow
write access and the file isn’t displayed on the terminal,
check the major and minor numbers of the device file. You can list
them with the ll command. You can use the lssf command to interpret the major and minor numbers and
display the results. Other
things to check. Make sure your inittab entries are active If
you are just adding this terminal and have made a new entry in the /etc/inittab file by editing it, remember that this doesn’t
automatically make your new entry active. To do that you need to enter
the command: This tells the init process
to scan the /etc/inittab file to update the information
in its internal tables. Check for functioning
hardware. Now is the time to check the hardware.
To do this, check the following items: If the known good terminal
doesn’t function on the suspect terminal’s cable, and
the suspect terminal is working fine in its new location, you can
be confident that the terminal itself is functioning properly and
the problem is elsewhere.
Other Terminal Problems | |
The other type of problem you’re likely
to run into with terminals is that of garbage on the screen. Garbage
on the screen comes in two types: garbage intermixed with valid data
characters and complete garbage. What to Check for When Garbage is Mixed with Valid DataThe following is a list of possible reasons for
garbage characters intermixed with your valid data: Noise on the data line: RS-232 Cable too long
(maximum recommended length is 50 feet) Data cable near electrically
noisy equipment (motors, etc.) Partially shorted or broken
wires within the cable Noisy connection (if using
phone lines)
Hardware problem with
a modem, interface card, or the terminal itself The program performing
I/O could be sending the garbage The Display Functns* feature
of your terminal is enabled (which displays characters that would
not normally print)
What to Check for When Everything Printed is GarbageOne of the most common reasons for total garbage
on the screen (and certainly the first thing
you should check) is a baud-rate mismatch. If your terminal’s
speed setting is different from that of the line (as set with the stty command), you will get garbage on your screen (if
anything at all). Here is a list of other possible reasons for total
garbage on your screen. If you have not yet logged in, try pressing the Break key. This tells getty to try
the next entry in the /etc/gettydefs file. The gettydefs file can be set up so that, as getty tries various entries, it will also be trying various speed settings
(this is usually how it’s set up). getty will then try various speeds (with each press of the Break key). When the correct speed is matched, you will get a login prompt
that is readable. The shell environment
variable called TERM isn’t set to a value appropriate
to your terminal. If you have an HP terminal, try setting the value
of TERM to hp (lowercase) using
your shell’s set command. A running process is producing
garbage output Excessive noise on the
data line A hardware failure (bad
interface card, modem, MUX, etc.)
|
Printable version
