|
» |
|
|
|
To add peripherals to your system, consult the
following documentation: The hardware installation
manual that came with the peripheral. For PCI OL* information,
see the manual Interface Card OL* Support Guide. For PCI OL* information on nPartition-able systems, see the manual nPartition Administrator's Guide. PCI OL*, previously known as OLAR, is the ability to
add or remove a PCI card without needing to completely shutdown the
entire system. The system hardware combined with operating system
support allows per-slot power control. Instead of turning off the
entire system, you can turn off and on power to a specific PCI slot. PCI latches and doorbells refer to physical latches
and buttons on the system itself that allows for enabling and disabling
power to a PCI slot. The procedures for PCI OL* can be performed through
a GUI, such as pdweb or the Partition Manager,
or through HP-UX commands, such as rad (olrad as of 11i v2). All are documented in the preceding
manuals. | | | | | CAUTION: Before attempting these procedures, please read the manuals
mentioned above. Turning off power to certain PCI slots can have disastrous
effects; for example if the PCI slot connects to an unmirrored root
or swap disk, the system will crash. Further, the I/O card itself
needs to be checked for OL* functional compatibility as well as compatibility
to the specific PCI slot; for example, you cannot insert a 33 MHz
card to a slot running a 66 MHz bus. | | | | |
For general peripherals,
see the manual Configuring HP-UX for Peripherals. See the HP-UX
11i Release Notes for the titles of documents that may
be relevant to installing peripherals. Such documents may contain
specific information on the software driver and the device special
file for communication with particular peripherals.
The easiest way to add peripherals is to run HP
SMH or Partition Manager for nPartition-able systems. However, you
can also add peripherals using HP-UX commands. For HP-UX to communicate with a new peripheral
device, you may need to reconfigure your system’s kernel to
add a new driver. If using HP-UX commands, use the /usr/sbin/mk_kernel command (which HP SMH uses). For details, see mk_kernel(1M), HP SMH online help, and HP-UX System Administrator’s
Guide: Configuration Management. Setting Up Non-HP Terminals | |
For detailed information on setting up non-HP
terminals, see Configuring HP-UX for Peripherals. To set up a user with a non-HP terminal, do the
following: Make
sure the fileset NONHPTERM is on
the system by using either of these methods: swlist
-l fileset NonHP-Terminfo If the fileset exists, the entry for NonHP-Terminfo.NONHPTERM will be displayed. ll
/var/adm/sw/products/NonHP-Terminfo If the fileset exists, the directory /var/adm/sw/products/NonHP-Terminfo/NONHPTERM will exist.
If the fileset is not on the system, you will
need to load it from your latest HP-UX media. See “Managing Software” or the manual, Software Distributor Administration Guide, for details. Look
in the directory /usr/share/lib/terminfo for
a file that corresponds to the terminal you want to set up. For example,
suppose you want to set up a user with a Wyse™ 100 terminal.
All supported terminals whose names begin with w are contained in the /usr/share/lib/terminfo/w directory. Because this directory contains an entry wy100, you have probably found the correct file.
To be sure, examine the contents of the file with more. You will see a screen full of special characters, but near the
beginning you will see wy100|100|wyse 100. This verifies the correct file and shows that you can refer to
the Wyse 100 by any of the names wy100, 100, or wyse 100. If there is a terminfo file for the terminal you want to add, skip the next step and go
to Step 4. If there is no terminfo file
for the terminal you want to add, you will need to create one. See
the next step for details. To
create a terminfo file, follow the directions
in terminfo(4). To adapt an existing file, follow these steps: Log
in as superuser. Make
an ASCII copy of an existing terminfo file. For
example, make a copy of the file /usr/share/lib/terminfo/w/wy100 by entering: untic /usr/share/lib/terminfo/w/wy100> new_file
|
Edit
the new file to reflect the capabilities of the new terminal. Make
sure you change the name(s) of the terminal in the first line. Compile
the new terminfo file: For more further information, see tic(1M) and untic(1M)
Set the user’s TERM variable in
the appropriate login script (either .profile for Korn and POSIX shell users or .login for
C shell users in their home directory) to any of the names you uncovered
in Step 2. For example: export TERM=wy100 (Korn or POSIX shell)
|
setenv TERM wy100 (C shell)
|
The default versions of these scripts prompt the user for the terminal
type upon log in, so rather than editing the script, you could simply
tell the user to respond with the terminal name. For example: You can also set the TERM variable
with the /sbin/ttytype command.
Troubleshooting Problems with Terminals | |
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”. 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. Check
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. Check
to see if an editor is running on the terminal. This is best done from another terminal. Issue the command: Look in the
column marked TTY for 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 XON/XOFF protocol to start
and stop output to them. If output to the terminal was stopped because
an XOFF signal (ctrl-s) was sent
from the terminal to the computer, it can be restarted by sending
the computer an XON signal (type ctrl-q from the problem terminal’s keyboard). Sending the XON signal
does not harm anything even if no XOFF 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 ctrl-C to see
if you can get a shell prompt back (ctrl-C is the default interrupt character; you might use a different
one). If you need to find out what the interrupt character for the
affected terminal is, go to a working terminal and enter the command: stty < /dev/device_filename_for_the_problem_terminal
|
| | | | | CAUTION: The stty command, above, should
only be used with device file names for currently
active terminal device files (use the who command to see which device files are active). If you attempt to
execute stty with a non-active device file, you
will hang the terminal where you entered the commands. | | | | |
Reset
the terminal. The terminal itself may be stuck in an unusable state. Try resetting
it. Consult your terminal owner’s manual 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. Check
the terminal configuration. The terminal might not be configured
correctly. You should check the following: Is the terminal in Remote
* mode? It should be. Is Block * mode turned
ON? It shouldn’t be. Is Line * mode turned
ON? It shouldn’t be. Is Modify * mode turned
ON? It shouldn’t 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 killcommand 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: The output will look similar to this: UID PID PPID C STIME TTY TIME COMMAND
root 95 1 0 Jul 20 ? 0:00 /usr/sbin/getty -h ttyd1p0 9600
root 94 0 0 Jul 20 tty0p5 0:00 /usr/sbin/getty -h tty0p5 9600
root 22095 1 0 13:29:17 ? 0:00 /usr/sbin/getty -h ttyd2p1 9600
root 22977 1 0 14:42:28 ? 0:00 /usr/sbin/getty -h ttyd2p0 9600
root 14517 1 0 Jul 21 ttyd1p4 0:01 -csh [csh]
root 107 1 0 Jul 20 ? 0:00 /usr/sbin/getty -h ttyd3p0 9600
stevem 20133 1 0 11:20:24 ttyd2p5 0:00 -csh [csh] |
Look in the column marked TTY for those processes that are associated with the terminal with which
you are having problems. Look at the column marked PID for those entries (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: kill -9 process-id[process-id]... If, in the example above, we wanted to kill the
process associated with terminal ttyd2p5, we
would execute the command: 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. Usecatto 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/motddisplayed 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 files
permissions mode to 622 (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 yourinittab 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 your terminal has a
self-test feature, activate it. If not, power the terminal off, wait
several seconds, and power the terminal back on. This will test (at
least to some degree) your terminal hardware. 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.
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 data The 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 than 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.)
|