 |
» |
|
|
|
This section addresses problems with alphanumeric display
terminals; however, the techniques can be applied to problems with
terminal emulators such as AdvanceLink or X-Windows terminal processes
(such as hpterm and xterm). Unresponsive Terminals | |
Several conditions can cause a terminal not to display any
characters except for those it echoes when you type. Proceed through
these steps (working from an active terminal) to solve many of them. Check the status of the system. If
the system is still running, try resetting the terminal. If the system is in single-user mode, the only active terminal
will be the system console; other terminals will not respond. Switch
to a multi-user state. Consult the init(1m) manpage in the HP-UX
Reference for information on changing run levels. Check your system run-level as follows: who -r
. run-level 2 Sep 28 10 07:10 2 0 S |
The current state of the machine (run-level 2 in this example)
is shown in the highlighted field. For complete information on each
of the fields, consult the who(1) manpage. Look for an editor running on the terminal. Examine
the active processes associated with the unresponsive terminal and
look for an editor (such as an active vi process). For example, for terminal tty0p1, /etc/fuser /dev/tty0p1
or
ps -t tty0p1 -f |
If you find an active editor process running at the terminal,
it is probably in a text-entry mode. You will need to save the work
to a temporary file and exit the editor. 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. If all else fails, kill the editor process from the
console, as described in step 8.) Enter Ctrl-Q at the terminal keyboard. If output to the unresponsive terminal
was stopped because an XOFF signal (Ctrl-S) was sent from the terminal to the computer, you can restart
it by sending an XON signal (Ctrl-Q). If an application program is looping or functioning improperly,
press the Break key and then Ctrl-C to attempt to regain a shell prompt. If the unresponsive terminal uses something other than Ctrl-C as the interrupt character, you can identify it by logging
into another terminal and executing the command stty -a against the device special file of the unresponsive
terminal. Use the stty command only with device
file names for currently active terminal device
files. (Use who to see which device files are active.) Executing stty with an inactive device file will hang the terminal
from which you enter the command. For example, Compare the baud rate shown in the stty output and that set on the terminal. They should
match. Reset the terminal. On an HP terminal, try a soft reset
of Shift-Reset. If the terminal is stuck in an unusable state, power
the terminal off, wait for a few seconds, and power it back on.
This will reset the terminal, though the terminal owner's manual
may have information on a better way to do it. You also might need
to set the tabs with the tabs command. On an HP terminal, use the menu keys to examine
the modes configuration. Is the terminal in Remote * mode? It
should be. Is Block * mode turned ON? If so, turn
it OFF Is Line * mode turned ON? If so, turn
it OFF Is Modify * mode turned ON? If so, turn
it OFF
Check the physical connection of the terminal to
ensure that all cables are firmly attached and properly located,
all interface cards are firmly seated, the power cord is firmly
connected, and the power switch is turned on. Send a short ASCII file to the unresponsive
terminal's device file.
Execute this in the background to
retain the current terminal's responsiveness. For example, for an
unresponsive terminal associated with the device file ttyd1p4, cat /etc/motd > /dev/ttyd1p4 & |
If you have solved the problem, you will see the contents
of the file /etc/motd displayed on the terminal associated with /dev/ttyd1p4. Kill processes associated with
the problem terminal. Before killing processes use extreme
caution to be sure you are not killing a valid process
that just happens to be taking a long time to complete.
First examine
the system's active processes, as shown. Then, to kill all processes
associated with a specific TTY device (for example, ttyd2p5), execute the kill command to force specified process IDs (
PID) to terminate. Execute the kill command in the following sequence: kill -15, kill -3, kill -1, kill -9. (See signal(5) for definitions.)
ps -ef
UID PID PPID C STIME TTY TIME COMMAND
...
root 94 1 0 Jul 20 tty0p5 0:00 /usr/sbin/getty -h tty0p5 9600
root 14517 1 0 Jul 21 ttyd1p4 0:01 -csh [csh]
jaz 20133 1 0 11:20:24 ttyd2p5 0:00 -csh [csh]
root 22147 1 0 13:33:45 ? 0:00 /etc/getty -h ttyd2p3 9600
jaz 21234 20133 0 12:22:05 ttyd2p5 0:01 rlogin remote
jaz 21235 21234 0 12:22:12 ttyd2p5 0:04 rlogin remote
kill -15 21235 21234 20133 |
Once the processes terminate, init restarts a new getty process for that terminal (provided its /etc/inittab entry contains respawn). Check the parameters of the unresponsive
terminal's device file. Like all files, device special
files have access permissions that must be set to allow you access.
For example, permissions set to 622 (crwww-) are appropriate for a terminal. Make certain
the file is a character device file. Make sure your inittab entries are active. To
force init to update its initialization tables from /etc/inittab, execute the command init q. Make sure the /dev/muxn and /dev/tty files are present. The /dev/muxn is the device file associated with the interface
card. The /dev/tty is a pseudo-device used in many places to refer
to the login terminal. Check the functionality of your hardware. If the unresponsive terminal has a self-test
feature, activate it. If not, power the terminal off, wait several
seconds, and power the terminal back on. Swap the unresponsive terminal with one known to be
functioning. Swap only the terminal and keyboard.
Attach the properly functioning terminal to the same cable the
unresponsive terminal used. Plug the unresponsive terminal and keyboard
to the same cable used by the properly functioning terminal and
see if it works there. If the properly functioning terminal does not work on the unresponsive
terminal's cable and the unresponsive terminal works at the new
location, the unresponsive terminal is not the problem. Check the cable connecting the unresponsive terminal
to the computer. Swap the suspect cable with a known good one. If
this solves the problem, the cable is bad or is not wired correctly.
If this does not solve the problem, your MUX, port, or interface
card might be malfunctioning. On Series 800 multiplexers, problems occur when /dev/muxn is deleted or has inappropriate permissions. the download firmware is deleted or has inappropriate permissions. /sbin/dasetup is not run from /etc/inittab. dasetup should only be run from inittab. Do not run it in any state
other than single-user mode.
Garbage Displayed on the Terminal Screen | |
If garbage is mixed with valid data,
the problem might be: Noise on the data line, because RS-232-C cable is too long (maximum
recommended length is 50 feet or 15 meters at 9600 baud). data cable is situated near electrically noisy equipment,
such as motors. wires are partially shorted or broken within the
cable. telephone connection is noisy
Hardware problem with a modem, interface card, or
the terminal itself The program performing I/O might be sending the
garbage The Display Functns* feature of your terminal is
enabled (which displays characters that would not normally print) You might be displaying a non-ASCII file.
If everything printed is garbage, examine
these possible causes: Baud-rate mismatch (most
likely) If your terminal's speed setting differs from
that read by the stty command, garbage will appear on your screen. If you have not yet logged in, press the Break key, followed by Return, Return, to force getty to try the next entry in /etc/gettydefs. Typically, the gettydefs file is set up so that each time you press the Break key, getty tries the next speed setting, as defined in /etc/gettydefs. When getty matches the speed set to your terminal, you will
get a readable login prompt.
Parity generation/checking mismatch. Use stty to determine the proper settings for the terminal. The TERM environment variable is incorrectly set. If you
have an HP terminal, try setting the TERM value to hp using your shell's set command. A running process is producing garbage output. The cable might be miswired or the data line might
be noisy. You might have a hardware failure in your interface
card, modem, MUX or other device.
The TERM environment variable is required for software
compatibility with the terminal. At the time of login, HP-UX software reads the terminfo setting. If you have changed the configuration
during a terminal session, you need to alert the software to the
change by exporting the TERM variable. For example, in Korn shell, export TERM=vt100 Refer to the terminfo(4) manpage for further explanation. |
Printable version
