Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
 HP Servers and Workstations: Managing Systems and Workgroups > Chapter 3 Configuring a System

Adding Peripherals
» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Index

spacerspacerspacer
spacer
spacer
  		 
 

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 HP Systems Partitions Guide: Administration for nPartitions.

    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 compatiblity 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 SAM 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 SAM uses). For details, see mk_kernel(1M), SAM online help, and “Reconfiguring the Kernel
(Prior to HP-UX 11i Version 2)”.

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:

  1. 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.

  2. 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 screenful 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.

  3. To create a terminfo file, follow the directions in terminfo(4).

    To adapt an existing file, follow these steps:

    1. Log in as superuser.

    2. 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

    3. 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.

    4. Compile the new terminfo file:

      tic new_file

      For more further information, see tic(1M) and untic(1M)

  4. 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:

    TERM = (hp) wy100

    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”.

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.

  1. 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.

    NOTE: To check what run state your system is in (from a working terminal) type:
    who -r

    The output will look something like:

     .       system boot  Feb 10 07:10    2    0    S 

    The current state of the machine is in the field immediately to the right of the time (third field from the right). For complete information on each of the fields, consult the who(1) manpage.

  2. Check to see if an editor is running on the terminal.

    This is best done from another terminal. Issue the command:

    ps -ef

    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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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:

    ps -ef

    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:

    kill -9 20133

    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.

  8. 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.

  9. 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.

  10. 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.

  11. 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:

      init -q

      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.

      • An alternate method to test the terminal hardware is to swap the suspect terminal with a known good one. This will help identify problems within the terminal that are not caught by the terminal selftest.

        NOTE: Be sure to swap only the terminal (along with its keyboard and mouse). You want the known good terminal at the end of the SAME cable that the suspect terminal was plugged into). Also, plug the suspect terminal (with its keyboard and mouse) into the same cable that the known good terminal was plugged into and see if it functions there.

      • 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 next thing7 to check is the cable connecting the terminal to the computer. Swap the suspect cable with a known good one.

        NOTE: Since you know the terminal at the end of each cable is working, you only have to swap the ends of the cables where they connect to the computer. If the problem remains with the terminal it was associated with prior to the cable swap, you probably have a broken or miswired cable. If the problem transfers to the other terminal (and the previously bad terminal/cable combination works in its new location), then the problem is most likely with your MUX, port, or interface card.

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 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 garbage

One 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

  • A miswired cable

  • Excessive noise on the data line

  • A hardware failure (bad interface card, modem, MUX, etc.)



Controlling Access to a System
  		 


Setting Up the Online Manpages  
Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 1997-2006 Hewlett-Packard Development Company, L.P.