In this document:
Introduction
The HP Surestore Virtual Array 7100 (VA 7100) can be connected to a Linux host. Because the implementation of SCSI and fibre channel in the Linux kernel is not fully enterprise-ready, some patches may be needed. As tested, the configuration is a direct-connect from the host to the array. One or two controllers may be used. Release 1 of Command View Software Device Manager (SDM) can be installed on Red Hat Linux 6.2; however, some modifications must be made to the host's Linux kernel prior to installing the software.
The HP VA 7100 and Command View SDM software have been tested using QLogic's QLA2100 and QLA2200 fibre channel host bus adapters (HBAs) on Red Hat 6.2 with the 2.2.16-3 kernel patched as described herein. Other configurations may work, but are not supported. Specifically, these patches have not been tested in configurations with multiple SCSI devices (i.e., tape drives, CD-ROMs). The changes to support 16-byte SCSI command descriptor blocks (CDBs) may adversely affect the behavior of other drivers.
If the array will be configured and managed from another host, e.g., an HP-UX system, it is possible to connect the array directly to a Linux system without making all of the kernel changes described. The HP Surestore Virtual Array 7100 can also be configured using the RS-232 port on the array controllers using the virtual front panel (VFP). The VFP can be used to establish the correct host port behavior and to create and delete logical unit numbers (LUNs). Review the patch descriptions before deciding which are applicable for the installation.
About Linux
The Linux operating system (OS) for personal computers is a UNIX(R)-like OS and meets POSIX standards. It uses a kernel developed and made freely available by Linus Torvalds, for whom it is named. Originally developed over the global Internet, Linux has become a widely used OS that involves its users in developing and testing new features.
General public license
Linux is supplied as a set of executable files, accompanied by the corresponding source code. The files and code can be copied under the terms of a general public license (GPL). This means users can install and use it for free. In exchange, under the GPL, users who make changes in the source code (to extend the usefulness of the OS on their own installations) are required to make their changes available to the rest of the user community under the same terms.
Linux support
Linux installations can be time-consuming and each requires someone skillful in OS programming. Distributors of Linux, such as Red Hat Software of Research Triangle Park, NC, have created documentation, service, and support facilities for users that want to install Linux. The kernel and source code are still freely licensed, but the client pays for the convenience of installing the software as a package from a CD-ROM. Other services are also available for a fee.
How to obtain a copy of Linux
Learn more about ordering Linux by contacting:
Red Hat Software
2600 Meridian Parkway
Durham, NC 27713
Email: redhat@redhat.com
World Wide Web: http://www.redhat.com
Support is available in the United States by dialing (877) 4REDHAT. Linux may also be available for purchase locally at software stores. More information is available about Linux from http://www.linux.org.
Hardware requirements
Refer to the "Command View SDM Installation and User Guide." The HP VA 7100 may be connected to a Linux host using the QLogic QLA2100/QLA2200 host bus adapters. This document plus other information about the HP Surestore Virtual Array 7100 and Command View SDM can be found at the HP Web site http://www.hp.com/support/va7100.
Operating system requirements
- A clean install of the Red Hat 6.2 i386 Architecture Operating System. Support for remote login and ftp may be useful, but are not required.
- Linux kernel 2.2.16-3 upgrade. Click here to go to the Red Hat site http://www.redhat.com/support/errata/RHSA-2000-037-05.html for background, Red Hat package managers (RPMs) and instructions. The RPM packages are:
- kernel-headers-2.2.16-3.i386.rpm
- kernel-source-2.2.16-3.i386.rpm
- kernel-2.2.16-3.i386.rpm
- kernel-2.2.16-3.i586.rpm
- kernel-2.2.16-3.i686.rpm
- kernel-pcmcia-cs-2.2.16-3.i386.rpm
- kernel-utils-2.2.16-3.i386.rpm
- kernel-ibcs-2.2.16-3.i386.rpm
- kernel-doc-2.2.16-3.i386.rpm
- kernel-smp-2.2.16-3.i386.rpm
- kernel-smp-2.2.16-3.i586.rpm
- kernel-smp-2.2.16-3.i686.rpm
- kernel-BOOT-2.2.16-3.i386.rpm
Click here to go to the procedure for upgrading the kernel that is documented at http://www.redhat.com/support/docs/howto/kernel-upgrade/kernel-upgrade.html. When building a Linux kernel, carefully read the directions for the architecture being used before proceeding with the kernel upgrade.
The recommended upgrade path is to install the Linux 2.2.16-3 kernel headers and source, build the kernel for the machine, then apply the patches and build the new version (2.2.16-3HP). This method is safer because it retains the ability to boot into the original kernel.
Log in as root and use RPM to install the sources. At the prompt (usually a "#"), type
- rpm -Uvh kernel-headers-2.2.16-3.i386.rpm
- rpm -Uvh kernel-source-2.2.16-3.i386.rpm
Patches
After the kernel has been upgraded, consider applying the following patches to the kernel's SCSI subsystem source code. The patches are listed here and are summarized below.
- Command View SDM
- Device "Not Ready - LUN Becoming Ready"
- Refined SCSI error recovery
These patches apply to the Linux 2.2.16-3 kernel. The changes can be reached from http://www.hp.com/support/cvsdm. Click "update software and drivers".
The patches are commented to be easily discernable from the baseline code and can distinguish between the changes applicable for each patch. Each change section is bracketed with "begin" and "end" patch tag comments. The comments are of the form <patch tag> <description> <date> {begin | end}.
The patch tag, HP_VA7100, indicates the Hewlett-Packard patch for the HP Virtual Array 7100. The description summarizes its purpose, and the date indicates the timeliness of the patch; newer versions of the patch will have more recent dates. The "begin" will appear as the first line of a section of code that has been modified, and the "end" will appear after each modified change section.
This set of patches is commented as follows.
HP_VA7100 vendor unique data direction 2001-03-15
HP_VA7100 16 byte CDB 2001-03-15
HP_VA7100 device not ready - LUN becoming ready 2001-03-15
HP_VA7100 refined error recovery 2001-03-15
After all patches have been applied, grep HP_V * /usr/src/linux/drivers/scsi/ will return the following.
qlogicfc.c:/* HP_VA7100 refined error recovery 2001-03-15 begin */
qlogicfc.c:/* HP_VA7100 refined error recovery 2001-03-15 end */
qlogicfc.c:/* HP_VA7100 vendor unique data direction 2001-03-15 begin */
qlogicfc.c:/* HP_VA7100 vendor unique data direction 2001-03-15 end */
qlogicfc.c:/* HP_VA7100 vendor unique data direction 2001-03-15 begin */
qlogicfc.c:/* HP_VA7100 vendor unique data direction 2001-03-15 end */
qlogicfc.c:/* HP_VA7100 refined error recovery 2001-03-15 begin */
qlogicfc.c:/* HP_VA7100 refined error recovery 2001-03-15 end */
qlogicfc.h: * HP_VA7100 refined error recovery 2001-03-15
qlogicfc.h:/* HP_VA7100 refined error recovery 2001-03-15 begin */
qlogicfc.h:/* HP_VA7100 refined error recovery 2001-03-15 end */
scsi.c: * HP_VA7100 16 byte CDB 2001-03-15
scsi.c:/* HP_VA7100 16 byte CDB 2001-03-15 begin */
scsi.c:/* HP_VA7100 16 byte CDB 2001-03-15 end */
scsi.c:/* HP_VA7100 16 byte CDB 2001-03-15 begin */
scsi.c:/* HP_VA7100 16 byte CDB 2001-03-15 end */
scsi.c:/* HP_VA7100 16 byte CDB 2001-03-15 begin */
scsi.c:/* HP_VA7100 16 byte CDB 2001-03-15 end */
scsi.h: * HP_VA7100 16 byte CDB 2001-03-15
scsi.h:/* HP_VA7100 16 byte CDB 2001-03-15 begin */
scsi.h:/* HP_VA7100 16 byte CDB 2001-03-15 end */
scsi.h:/* HP_VA7100 16 byte CDB 2001-03-15 begin */
scsi.h:/* HP_VA7100 16 byte CDB 2001-03-15 end */
scsi.h:/* HP_VA7100 16 byte CDB 2001-03-15 begin */
scsi.h:/* HP_VA7100 16 byte CDB 2001-03-15 end */
scsi_ioctl.c:/* HP_VA7100 16 byte CDB 2001-03-15 begin */
scsi_ioctl.c:/* HP_VA7100 16 byte CDB 2001-03-15 end */
scsi_ioctl.c:/* HP_VA7100 16 byte CDB 2001-03-15 begin */
scsi_ioctl.c:/* HP_VA7100 16 byte CDB 2001-03-15 end */
scsi_ioctl.c:/* HP_VA7100 16 byte CDB 2001-03-15 begin */
scsi_ioctl.c:/* HP_VA7100 16 byte CDB 2001-03-15 end */
scsi_syms.c:/* HP_VA7100 refined error recovery 2001-03-15 begin */
scsi_syms.c:/* HP_VA7100 refined error recovery 2001-03-15 end */
sd.c: * HP_VA7100 device not ready - LUN becoming ready 2001-03-15
sd.c:/* HP_VA7100 device not ready - LUN becoming ready 2001-03-15 begin */
sd.c:/* HP_VA7100 device not ready - LUN becoming ready 2001-03-15 end */
Packaging
The patches can be found in the following patch files.
- HP_VA7100_2001_03_15_Command_View. This contains the patches needed to run HP Command View SDM on a Linux host. This includes the vendor unique data direction and the 16-byte CDB patches.
- HP_VA7100_2001_03_15_Device_Not_Ready. Contains the "Device not ready - LUN becoming ready" patch.
- HP_VA7100_2001_03_15_Error_Recovery. Contains the refined error recovery patch.
These patches can be applied separately depending upon the system requirements. Before applying any of these patches, be sure to read the descriptions below. There are tradeoffs to be made with the implementation of these patches and should be aware of the potential impacts of each.
It may be useful to edit the sources directly. This will allow for separation of the patches and to incorporate other changes, if necessary. The file, VA7100b.tar, has the complete original 2.2.16-3 sources and the modified sources for the HP_VA7100_2001_03_15_* patches.
The surest upgrade path is to extract the complete sources from the VA7100b.tar file using the command tar -xvZf VA7100b.tar and copy the source files to the target directory of /usr/src/linux/drivers/scsi. These files can be modified to remove any unwanted patches or to add other patches.
Command View patch
The Command View patch includes two distinguishable changes. One change is to set the data direction for vendor-unique commands. The other change allows SCSI CDBs that are up to 16 bytes in size to be passed through the kernel. These are described below.
Vendor-unique commands
Problem synopsis
The Linux 2.2.16 SCSI generic (sg) application programming interface (API) does not contain an explicit data direction field for SCSI commands. The SCSI low-level drivers, QLOGICFC in particular, must "snoop" the SCSI operation code (opcode) within the CDB to determine data direction from a standard lookup table. This procedure does not work with vendor-unique commands because data direction is product specific.
The specific operation codes, in hexadecimal, for which the patch is applied, are:
- 0x27
- 0x29
- 0xe2
- 0xed
- 0xf9
- 0xfa
- 0xfd
Patch description
The most straightforward solution is to patch the QLOGICFC driver code where SCSI opcodes are being snooped. Since the default data-direction is assumed to be data-in, the vendor-unique commands are added for the VA 7100, which has a data-out phase. A few SCSI-3 commands have been added to the QLOGICFC driver (FORMAT_UNIT, SEND_DIAGNOSTIC, WRITE_LONG, WRITE_SAME, MODE_SELECT_10, WRITE_12, WRITE_VERIFY_12, and SEND_VOLUME_TAG). Each of these commands also has a data-out phase.
Caveats
Because a certain range of opcodes is reserved for vendor-unique (product specific) SCSI commands, it is possible that one product may define a certain opcode to have a data-in phase while another product from a different vendor may define the same opcode to require a data-out phase. In this case, simply "snooping" the opcode would not be sufficient.
Recommendation
This patch is required if managing the HP VA 7100 through a Linux host. If other device management options are pursued, this patch is not required.
Files affected
../linux/drivers/scsi/qlogicfc.c
16-Byte SCSI CDBs
Problem synopsis
The Linux 2.2.16 SCSI subsystem supports CDBs up to 12 bytes in length. The constant, MAX_COMMAND_SIZE, defines this length but is not used consistently throughout the SCSI source code. In many places a CDB size of 12 bytes is hard-coded. Several management features specific to the HP VA7100 require 16-byte CDBs.
Patch description
This patch to the SCSI mid-layer removes all hard-coded size restrictions on CDB data structures. All such data structures now reference the MAX_COMMAND_SIZE constant, which has also been increased to 16 bytes.
Caveats
This patch applies to the entire SCSI subsystem, not just fibre channel devices. All processing of SCSI command data structures will now involve manipulating a 16-byte field instead of the typical 12 bytes. This is a modest amount of overhead to support the few commands that require 16-byte CDBs.
This patch has been tested successfully with QLogic fibre channel host adapters using the QLOGICFC and QLogic QLA2X00 drivers. The impact of this patch on other SCSI drivers (especially legacy drivers) has not been fully assessed. It is not exhaustively known, for example, how a legacy host adapter will behave if its respective driver makes assumptions about CDB length and passes the full 16 bytes of data down to hardware, which is limited to receive only 12-bytes. This change will adversely affect the following drivers. There may be others in addition to those listed below.
- 53c7xx (only 12 bytes copied)
- 53c7,8xx (corrupts structures)
- sym53c8xx
- Buslogic Flashpoint (firmware cannot handle 16-byte commands)
- NCR 53c9x (16-byte commands not supported)
- AHA1542 (only 12-byte commands handled by hardware)
- cpqfcTSinit (assumption in driver about kernel only)
- eata (command corrupts structures in device)
- esp (driver assumes no 16-byte commands exist)
- i91uscsi (driver assumes 12-byte buffers internally)
- ide-scsi (kernel buffer of 12 bytes, causes stack corruption)
- in2000 (driver assumes 12 bytes internal)
- ini9100u (driver assumes 12-byte structures)
- ips (driver assumes 12-byte structures)
- qlogicpti
- sim710 (driver assumption)
- tmscsim
- u14-34f (corrupts driver structures)
- ultrastor (corrupts driver structures)
- wd33c93
- wd7000 (corrupts driver structures)
Recommendation
This patch is required if managing the HP VA 7100 through a Linux host. If other device management options are pursued, this patch is not required.
Files affected
../linux/drivers/scsi/scsi.c
../linux/drivers/scsi/scsi.h
../linux/drivers/scsi/scsi_ioctl.c
Device "Not Ready - LUN Becoming Ready"
Problem synopsis
The Linux 2.2.16 SCSI subsystem does not appear to distinguish the various kinds of "Not Ready" device states. Some "Not Ready" sense codes indicate that a device is not ready and will require manual intervention in order to become ready, such as when media has been removed from a tape device. However, other "Not Ready" codes indicate that the device is not yet ready, but is in the process of becoming ready (such as during device initialization or self-diagnostics). In the latter case, the LUN is said to be "becoming ready" and all that is required is a retry. The HP VA 7100 can be in this "becoming ready" state for periods of up to 15 seconds or more during initialization, which typically causes the Linux subsystem to take the device offline, resulting in data loss and/or file system corruption.
Patch description
When the device reports a state of "Not Ready - LUN becoming ready", this patch will re-queue the command at the high-level SCSI device (sd) driver. In this case, the device will soon be available and it is preferable to wait rather than to give up.
Caveats
While the device is in this particular "becoming ready" state, there is currently no delay between command retry attempts.
Recommendation
Use this patch at your discretion. If the array needs to be re-initialized and you notice lengthy "becoming ready" periods, this patch should be considered.
Files affected
../linux/drivers/scsi/sd.c
Refined SCSI error recovery
Problem synopsis
The Linux 2.2.16 SCSI subsystem provides a reference sample error recovery function called SCSI_UNJAM_HOST. This routine does not have ideal behavior for time-outs and tends to mark fibre channel devices offline with very little provocation. This action usually results in data loss and/or file system corruption, as well as irremovable locked system processes. In the event of a time out that exceeds the 30-second default value, the error recovery thread is awakened. After attempting to reset the missing device, it is marked offline, resulting in file system corruption and hung processes.
Patch description
Fortunately, the Linux 2.2.16 SCSI subsystem provides a new error handling architecture whereby the default error recovery function can be overridden within each low-level driver. This patch to the QLOGICFC driver implements the new SCSI error handling mechanism and supplies an alternate error recovery behavior which affects only devices attached to the QLogic adapter. Other SCSI devices on the system continue to use the SCSI_UNJAM_HOST function and retain their normal recovery behavior. The SCSI_UNJAM_HOST routine was copied from scsi_error.c to qlogicfc.c and modified as an example of how to customize error recovery for a particular environment. On inserting the modified QLOGICFC module into the kernel, the driver registers its error handling function, now called ISP2X00_STRATEGY_HANDLER, with the SCSI host's EH_STRATEGY_HANDLER function pointer. The ISP2X00_STRATEGY_HANDLER function is now called in place of SCSI_UNJAM_HOST for QLogic-attached devices.
The major distinguishing behavior of the new recovery function is that there are now very few conditions in which a device will ever be taken offline. More specifically, the new error handler function will attempt to abort and retry any outstanding commands that have failed or timed out. If this retry also fails, the function will wait 15 seconds and try again. It continues aborting/retrying every 15 seconds for up to five minutes. At five minutes, it attempts to reset the offending device. This reset function does not appear to be implemented in the QLOGICFC driver. If this reset fails, it attempts to reset the bus, then the host adapter. If none of these resets allow for successful retirement of outstanding SCSI commands, the new error recovery function loops back and begins the entire recovery process from the top. This continues indefinitely until the device returns. The code is very straightforward and can be easily customized to eventually take the device offline if desired, after any combination or duration of aborts/retries/resets.
It should be noted that the QLA2X00.C driver, which is available from QLogic's Web page, attempts to address this same issue with what they refer to in their code as a "SCSI kluge." Their solution involves detecting when the fibre-channel loop is down and bumping the timer values on outstanding SCSI commands to prevent them from timing out. They then perform their own retries from a separate low-level command queue. The QLA2X00.C driver does not currently take advantage of the new error handling architecture and does not address the case where a device is timing out but is still present on the fibre channel loop. In such cases, a timeout that occurs against a device that is still present on the loop can still result in that device being taken offline with data loss and/or file system corruption. The "SCSI kluge" provided with that driver protects only against timeouts that occur because the link is down (device unplugged from the loop).
Caveats
The behavior of the HP patch to the QLOGICFC.C driver is not yet ideal. It assumes that a missing or timed-out device will eventually return to its original position. If the device will not return, or returns in some other device location on the system, then there is currently no means in place to manually notify the new error handler that it should give up and take the missing device offline. While the error recovery function is activated, all new or existing processes with outstanding I/Os to the QLogic HBA will remain blocked in error recovery waiting for the device to return, and cannot be killed. The assumption is made that "missing devices that never return" will be rare and that this approach is preferable to the potential for lost data or file system corruption for "missing devices that eventually return." In any case, this patch is offered as a safeguard and an example, which can be easily customized to provide a wide range of recovery policies specifically suited to QLogic-attached devices.
NOTE: Any process that attempts to access the device during an indefinite timeout condition will also be blocked. The HP SAN Manager HostAgent and the HP Command View SDM management software periodically check the status of system devices. If this patch is used, these processes will also be blocked indefinitely during device timeout conditions. This also means that no device status notices or warnings will be issued for any devices while the status discovery process is blocked. A missing device that never returns will prevent all status notification from the host until it is rebooted. If device status updates are essential, do not use this patch (or else do not use an indefinite retry policy as the example patch does). Furthermore, this patch could also adversely impact the implementation of clustering or any failover solution.
Recommendation
Use discretion. This patch fixes a select set of problems and is known to cause others. If device timeouts and/or file system corruption occur, consider incorporating this patch.
Files affected
../linux/drivers/scsi/qlogicfc.c
../linux/drivers/scsi/qlogicfc.h
../linux/drivers/scsi/scsi_syms.c
Rebuild kernel
Apply these patches to the 2.2-16-3 sources, re-build and install the kernel. Remember to configure the Linux loader (LILO) to boot the new kernel, but keep the option of booting to the previous version in case the new version will not boot. Copy an initial configuration file appropriate for your system from the /usr/src/linux/configs to /usr/src/linux/.config
The patches may be applied as follows.
- Copy the patch files using cp HP_VA7100_2001_03_15_* /usr/src/linux.
- At the prompt (usually a "#"), apply the desired patch, using the patch command as shown below.
- patch -p1 < HP_VA7100_2001_03_15_Command_View
- patch -p1 < HP_VA7100_2001_03_15_Device_Not_Ready
- patch -p1 < HP_VA7100_2001_03_15_Error_Recovery
NOTE: The kernel should be built with loadable modules. This will allow for removal and insertion of the HBA driver to force an initialization and corresponding scan for current LUNs.
Edit the kernel makefile to set the EXTRAVERSION to discriminate between the "stock" 2.2.16-3 kernel and the modified version to be built. Add the following lines:
VERSION = 2
PATCHLEVEL = 2
SUBLEVEL = 16
EXTRAVERSION = -3HP
cd /usr/src/linux
make mrproper (only once on SMP systems)
make clean (only if re-building)
make xconfig (need an initial .config file as noted above)
make dep
make bzImage
make modules
make modules_install
cp arch/i386/boot/bzImage /boot/vmlinuz-2.2.16-3HP
cp System.map /boot/System.map-2.2.16-3HP
cd /boot
ln -fs System.map-2.2.16-3HP System.map
modprobe loop
mkinitrd -v -f /boot/initrd-2.2.16-3HP.img 2.2.16-3HP
By default, Linux will probe SCSI devices for a single LUN. The max_scsi_luns parameter instructs the kernel to probe for multiple LUNs during boot-up. Edit /etc/lilo.conf to point to the new boot image and to set the max_scsi_luns kernel parameter as follows. The append statement can include multiple kernel directives as described in the following paragraph.
append="max_scsi_luns=8"
NOTE: There may be a need to tell Linux how much physical memory is installed. Under some conditions, the OS will not correctly configure the kernel's memory map to match the physical RAM available. This can be done by adding the mem parameter (append="max_scsi_luns=8 mem=256M") to the /etc/lilo.conf file.
An example of the contents of /etc/lilo.conf is shown below. In this example, the "#" designates a remark.
boot=/dev/sda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
linear
default=linux2.2.16-3HP
append="max_scsi_luns=8 mem=256M"
#image=/boot/vmlinuz-2.2.14-5.0smp
# label=linux.old
# initrd=/boot/initrd-2.2.14-5.0smp.img
# read-only
# root=/dev/sda7
#
#image=/boot/vmlinuz-2.2.14-5.0
# label=linux-up
# initrd=/boot/initrd-2.2.14-5.0.img
# read-only
# root=/dev/sda7
image=/boot/vmlinuz-2.2.16-3
label=linux2.2.16-3
initrd=/boot/initrd-2.2.16-3.img
read-only
root=/dev/sda7
image=/boot/vmlinuz-2.2.16-3HP
label=linux2.2.16-3HP
initrd=/boot/initrd-2.2.16-3HP.img
read-only
root=/dev/sda7
Remember to run lilo (lilo -v) to install the boot loader for the new kernel. Be sure to have a back up floppy boot disk before rebooting into the new kernel.
Installation of the gimp fonts
Command View SDM has a dependency on the availability of certain fonts. There is a need to install the fonts in the URW-FONTS.TAR.GZ file downloaded from http://www.gimp.org/fonts.html. If the Command View graphical user interface (GUI) client on the array host is to be used, the presence of these fonts will prevent a series of error messages when the Java run-time starts. If access to the host is via a Web browser, this step is optional.
Extract and install the URW fonts into the /usr/X11R6/lib/X11/fonts/URW directory. Edit the file /usr/X11R6/lib/X11/XF86Config to include FontPath for the installed directory. The Files section of a XF86Config may look like this:
# The location of the RGB database. Note, this is the name of the
# file minus the extension (like ".txt" or ".db"). There is normally
# no need to change the default.
RgbPath "/usr/X11R6/lib/X11/rgb"
# Multiple FontPath entries are allowed (they are concatenated together)
# By default, Red Hat 6.0 and later now use a font server independent of
# the X server to render fonts.
FontPath "/usr/X11R6/lib/X11/fonts/misc:unscaled"
FontPath "/usr/X11R6/lib/X11/fonts/75dpi:unscaled"
FontPath "/usr/X11R6/lib/X11/fonts/100dpi:unscaled"
FontPath "/usr/X11R6/lib/X11/fonts/URW"
FontPath "/usr/X11R6/lib/X11/fonts/Type1"
FontPath "/usr/X11R6/lib/X11/fonts/Speedo"
FontPath "/usr/X11R6/lib/X11/fonts/misc"
FontPath "/usr/X11R6/lib/X11/fonts/75dpi"
FontPath "/usr/X11R6/lib/X11/fonts/100dpi"
FontPath "/usr/X11R6/lib/X11/fonts/TrueType"
FontPath "unix/:-1"
Re-start the Linux session (referred to as an "X" session) after installing the fonts.
NOTE: One or more of the links above will take you outside the Hewlett-Packard Web site. HP does not control and is not responsible for information outside of the HP Web site.
TrueType (TM) is a
U.S. trademark of Apple Computer, Inc.
UNIX (R) is a registered
trademark of the Open Group.
Copyright Hewlett-Packard Co. 2001
This information is subject to change without notice and
is provided "as is" with no warranty.
Hewlett-Packard shall not be liable for any direct,
indirect, special, incidental or consequential damages
in connection with the use of this material.
