7    Managing Specific Device Types

Most information that you use to install and configure a device is provided in the owner's manual that is shipped with the device itself. The owner's manual contains installation instructions for the device and specifies any special configuration requirements or usage restrictions for releases of the Tru64 UNIX operating system. This information is often supplemented in the Release Notes manual for a given release of the operating system.

The Release Notes describe any known problems or temporary restrictions on using a device. This chapter provides information on configuration options, permanent configuration requirements, or usage restrictions and discusses the following topics:

Note

This chapter describes how to configure certain devices and operating system options. Some of these devices are platform-dependent. That is, the device is only supported on certain models of processor. Similarly, some operating system features are also restricted to certain models of processor. Other operating system options depend on your configuration. Consult your system's hardware documentation for more information.

Follow the instructions in the Installation Guide and those provided by your hardware and firmware documentation when you add new options or change your system hardware. However, if the new option is supported only in the newest version of the operating system, you must perform the upgrade in the following sequence:

  1. Update your operating system software.

  2. Upgrade your firmware.

  3. Upgrade your hardware or install the new option.

  4. Follow the instructions in the Tru64 UNIX Installation Guide to rebuild your system kernel.

7.1    Storage Devices

This section provides specific information about configuring and managing storage devices and storage arrays under Tru64 UNIX. The following topics are included:

Notes

You must use the StorageWorks Command Console (SWCC) Version 2.3 or higher to manage HSZ or HSG controllers. Versions prior to Version 2.3 are not supported for use on Tru64 UNIX Version 5.0, or higher.

Some HSZ-series controller hardware is retired in Tru64 UNIX Version 5.1B. See the Release Notes for information on retiring hardware options and see the online

7.1.1    Parallel Scanning

Parallel scanning is a new feature in Tru64 UNIX Version 5.1B that is designed to shorten the system's boot time. Parallel scanning is disabled in the default system configuration. To enable this feature you must set the value of a configuration variable, as described later in this section.

When you enable parallel scanning of SCSI and Fibre Channel buses, the system initiates the scan on all buses simultaneously (rather than sequentially). This feature reduces the time required to find devices. On systems with moderate to large numbers of storage devices, the reduction of time required to boot can be significant.

However, parallel scanning affects the assignment of device names to newly added devices. Because the scan probes all buses simultaneously, the names assigned to new devices appear to be in random order. The system derives these device names from the numerical order in which it discovers devices during the scan.

For example, a storage array might contain disks that are named /dev/disk/dsk8 through /dev/disk/dsk32. When you add a new device, its device name might be named /dev/disk/dsk159, depending on when it is discovered by the scan. This is only a problem if you want to name the devices in your storage configuration in a contiguous sequence.

Consequently, if you require a specific device name sequence you must turn off parallel scanning before the system scans any newly added devices. You can turn parallel scanning on or off by using several methods. Depending on how it is set, the setting remains in force until you reset it or until you reboot the system. Use the following procedure to temporarily turn parallel scanning on or off:

  1. Shut down the system.

    Refer to the System Administration manual and shutdown(8) for information on your shutdown options.

  2. Install the new host bus adapter and the new devices.

  3. Reboot the system interactively by using the following console command: 

    P0>>> boot -flag ai
UNIX boot - Friday December 15, 2000
 
Enter: <kernel_name> [option_1 ... option_n]
or: ls [name][help] or: quit to return to console
Press Return to boot vmunix

    The system displays the interactive prompt (#).

  4. Disable parallel scanning (for this boot only) by using the following command: 

    # vmunix io:parallel_edt_scan=0

  5. When the system is up and running you can turn off parallel scanning by using the following command: 

    # sysconfig -r io_parallel_edt_scan=0

When the system is up, and if you want certain bus events (such as bus resets) to be processed faster, turn on parallel probing by using the following command: 

# # sysconfig -r io parallel_edt_scan=1

You can turn parallel probing on permanently (the setting is retained across a system boot) by using the sysconfigdb command or the dxkerneltuner utility. Use the following procedure:

  1. As root user, create the following io subsystem stanza file: 

    io:parallel_edt_scan=1

    Name this file parallel.stanza. If an io stanza already exists, add the preceding line to the existing file, instead of creating a new file.

  2. Determine whether any entries exist for the io subsystem by using the following command: 

    # sysconfigdb -l io

    The results of this step determine which command option (-a or -u) to use in Step 3.

  3. Configure parallel probing by using one of the following command variants:

7.1.2    Console-Level Multipath Support Restrictions

The console firmware on the AlphaServer 1000, AlphaServer 1000A, and AlphaServer 2x00 systems does not support selecting multiple boot or dump devices for storage units located behind HSZ70, HSZ80, or HSG80 RAID Array controllers that are enabled for multiple-bus failover mode.

The console must have a visible path to the storage unit that it is booting from or to which it is dumping. If a controller, in multiple-bus failover mode, fails over to the other controller, all devices served by the failed controller are now visible on alternate paths. Therefore, before booting the system, reset the bootdef_dev console environment variable to a path that is visible to the boot device.

After the operating system has been booted, multipath support is fully functional.

7.1.3    Fibre Channel Dump Configuration

If your system configuration includes Fibre Channel devices, its console ports must be configured with the unique world-wide identifier (WWID) of the boot and swap disks defined for the operating system. This configuration is required to enable crash dumps.

The system requirements and configuration settings are defined in the following procedure:

  1. The system must have the swap space configured to minimum of 1.25GB to twice the size of its physical memory. For example, a minimum of 5GB of on-disk swap space for 4GB of physical memory. Refer to the System Administration manual for information on how to add swap partitions and configure swap space.

  2. All the boot and swap devices must be configured to use one of the four console ports. Ensure that the console WWID number for each boot or swap device is identical to the WWID number displayed by using the following procedure:

    1. Identify the console port (Nn) and WWIDn mapping by using the consvar command as follows: 

      # consvar -g N1
# consvar -g wwid0

      Repeat the command for each of the four ports and WWID values.

    2. For each Fibre Channel boot and swap device, find the device name (dev/disk/dskN). You can do this by examining the /etc/fstab file, and by using the showfdmn for AdvFS root domains, and the swapon -s command for swap devices.

      Alternatively, use the SysMan Station as described in the System Administration Manual.

    3. For each Fibre Channel boot and swap device, find the device's hardware identifier (HWID) by using the device name that you obtained in the preceding step. For example: 

      # /sbin/hwmgr view devices | grep devname

    4. Obtain the WWID of each Fibre Channel boot and swap device by using the following command, specifying its HWID: 

      # /sbin/hwmgr show scsi -id HWID -full

    5. For each Fibre Channel boot and swap device, verify that the WWIDs displayed by the hwid command match the WWIDs that are mapped to the console ports.

  3. If the device WWID and the console port WWID values do not match, use the following procedure:

    1. Shut down the system by using the following command: 

      # /sbin/shutdown +5 "system going down for console reconfiguration"

    2. Use the wwidmgr utility as described in the Wwidmgr Users Manual to match the console WWID settings to the device WWIDs. The manual is located in the ../documentation directory on the system's Firmware CD-ROM.

7.1.4    Moving Disks Out of an Array

A disk's label might be unusable if a new LSM unit is constructed on a RAID array or if you move one or more disks from a RAID array to a direct connection under a host bus adapter. This might cause the disk's new block zero to be the same block as the old block zero for the prior unit. The system might see this incomplete label as valid, even though it might extend beyond the end of the disk. Use the following procedure to correct the disk label:

  1. Use the following command to zero the disk's label: 

    # disklabel -z dskNN

  2. Use either of the following commands to create a new default label, or to apply a preconfigured label from a proto file: 

    # disklabel -rwn dskNN
# # disklabel -Rr dskNN PROTOFILE

7.1.5    Replacing Failed HSZ40 and HSZ50 Controllers

This section describes how you replace a failed dual redundant controller for the following dual unit models:

If a controller fails, use the following procedure to replace the failed component and restart your configuration.

Caution

Several cautions are specified in the documentation for the controller's HSOF commands. To avoid the risk of data loss, familiarize yourself with the following CLI commands before proceeding:

The Tru64 UNIX operating system must not be at the console prompt (P0>>>). If it is, boot the system to single-user mode before applying the following procedure:

  1. Using the HSOF CLI on the good (functioning) controller, enter the following command to stop the failed controller: 

    
HSZnn> set nofailover

  2. Verify that the failed controller has stopped by ensuring that the green LED status light is no longer blinking.

  3. Physically remove the failed controller as described in the hardware documentation.

  4. At the UNIX command prompt, enter the following command: 

    # /sbin/hwmgr scan scsi -bus N

    The -scan option is asynchronous. When you issue this command, the prompt returns immediately, although the scan can still be working in the kernel, particularly if many devices are connected to the system. To test for discovery of the failed device, use the Event Manager (EVM) evmwatch command to monitor for hardware events as follows: 

    
# evmwatch -A -f '[name sys.unix.hw.*]'  
 
 

    The presence of tape devices increases the delay to complete the scan. Use the -bus qualifier to specify the bus you want to scan. Determine the correct bus number by examining the location field of the output from the following command: 

    # hwmgr view devices

    The display shows the HSZ units going from dual to single configuration.

  5. Install a replacement controller as described in the hardware documentation.

  6. Start the replacement controller as described in the hardware documentation.

  7. Repeat the hwmgr -scan scsi command described in Step 4.

  8. At the good controller, enter either of the following HSOF CLI commands to return the controllers to dual redundant mode in the appropriate failover mode: 

    > set failover copy=this 
> set multibus_failover copy=this

Messages are displayed indicating that the HSZ units are going from single to dual configuration, confirming that the operation was successful.

7.1.6    Replacing a Failed HSZ70 Controller

Some installations require a very strict recover or fail procedure, causing a HSZ70 controller to failover in a very short time when the system cannot recover the I/O path. However, this short failover time can cause problems if you want to change a running configuration, such as replace a failed controller. To avoid the recover or fail restriction you must temporarily set a system configuration parameter, causing the system to use a longer recovery period.

The following restrictions apply:

The following procedure describes how to reset the recovery period during a controller swap operation for a HSZ70 in multibus failover mode. The HSZ70 controller replacement procedure may create phantom entries for devices if the replacement is performed during times of heavy system I/O to the controller pair involved in the replacement. To avoid this problem, reduce or eliminate I/O to the controller pair before replacing a controller. (See the HSZ70's hardware documentation concerning the port quiesce buttons on the controller.)

Caution

Several data loss warnings are specified in the documentation for the controller's command line interface (HSOF). To avoid the risk of data loss, familiarize yourself with the following HSOF commands before proceeding:

  1. At the Tru64 UNIX system prompt, enter the following command to switch to alternate recovery timing during the subsequent steps: 

    # /sbin/sysconfig -r cam_disk rec_use_alt_params=1

  2. Set up an Event Manager (EVM) background task to monitor for hardware events by using the following command: 

    # evmwatch -A -f '[name sys.unix.hw.*]'
6771

    In later steps, this task will display hardware events resulting from hwmgr commands. Make a record of the process ID assigned to the task, which is 6771 in the preceding example.

  3. Using the HSOF command line interface on the good (functioning) controller, enter the following command to stop the failed controller: 

    HSZ70> set nofailover

    When its green LED status light is no longer blinking, the failed controller has stopped and you can proceed with the next step.

  4. Remove the failed controller as described in its hardware documentation.

  5. At the Tru64 UNIX system prompt, enter the following command: 

    # /sbin/hwmgr scan scsi

    Messages displayed at the console will show the HSZ70 controller pair going from dual to single configuration.

    The scan option is asynchronous. When you issue this command, the prompt returns immediately, although the scan can still be working in the kernel, particularly if many devices are connected to the system. Your background EVM task displays any messages that relate to the registration of the replacement controller.

    To make the scan complete as quickly as possible, use hwmgr commands to determine the system bus at which the controller persists, and specify a scan of that bus alone. Determine the correct bus number by examining the location field of the output from the following command: 

    # /sbin/hwmgr view devices

  6. Install and start the replacement HSZ70 controller as described in its hardware documentation.

  7. At the Tru64 UNIX system prompt, repeat the scan command as follows: 

    # /sbin/hwmgr scan scsi

  8. At the good controller (not the controller that you just replaced), enter the following HSOF command: 

    hsz70> set multibus_failover copy=this

    This command returns the controller pair to dual redundant mode in the appropriate failover mode.

  9. At the Tru64 UNIX system prompt, enter the following command to switch to default recovery timing: 

    # /sbin/sysconfig -r cam_disk rec_use_alt_params=0

When the HSZ70 controller pair goes from single to dual configuration, messages displayed at the console verify that the operation was successful.

7.1.7    Clearing Persistent Reservations on Disks Behind HSZ80 and HSG80 Controllers

TruCluster Server cluster members use persistent reservations to coordinate access to shared storage. These persistent reservations control access to devices and logical volumes, and are used to erect a barrier against any system that is not a member of the current cluster. The base operating system does not know how to manage these persistent reservations. Attempts by the base operating system to access a disk that has a persistent reservation will return I/O error messages. All I/O attempts will fail.

If you boot (or reinstall) the base operating system on a system that attempts to access disks that were previously used by a cluster behind an HSZ80 or HSG80 controller, the base operating system might not be able to see the disks. This is most likely because the disk participated previously in a cluster, and one of the cluster members set a reservation on the disk to prohibit any other hosts (or noncluster members) on this shared bus from accessing the disk. The problem occurs because the reservation was not cleared when the cluster member or the cluster was shut down.

To remove the reservations, use the /usr/sbin/cleanPR clean command. The cleanPR script finds and clears all persistent reservations from the attached HSZ80 and HSG80 devices.

Caution

Do not run the cleanPR script on a system that is in a cluster. You do not want to remove reservations that the running cluster is using to actively control disk access. Doing so can result in data corruption.

Consider the following two scenarios:

7.1.8    Compact Disk (CD-R/W) Burner Option

Some systems are shipped with a CD-R/W burner as a console storage device in place of both the CD-ROM reader and the 1.44MB floppy disk device. Unlike the floppy disk device, the CD-R/W device is not available for console operations, such as saving copies of your system configuration at the console. However, in multiuser mode you can burn files onto recordable CD-R and CD-RW media.

To burn a CD-R/W, see cdrecord(1) and mkisofs(8). A description of the procedure is provided in the online Best Practice Recording a Data CD-ROM at the following web location: http://www.tru64unix.compaq.com/docs/best_practices

The following constraints apply to systems equipped with the CD-R/W device instead of a floppy disk device:

7.1.9    Floppy Disk Configuration

The following procedure describes how to configure a floppy disk for use with Tru64 UNIX:

  1. Use the following commands to determine the type of floppy drive and its device special files: 

    # hwmgr view devices | grep floppy
69: /dev/disk/floppy0c           3.5in floppy     fdi0-unit-0
 
 

    The preceding command output indicates that the single floppy drive is an fdi-attached device rather than a SCSI device. Its device special files are named floppy0c. However, when formatting the drive, you use its a partition (floppy0a).

  2. Insert a blank diskette into the drive and enter the following command to format the diskette: 

    # /sbin/fddisk -fmt -f /dev/rdisk/floppy0a
Disk type: 3.50 inch, HD  (1.44MB)
Number of sectors per track: 18
Number of surfaces:   2
Number of cylinders: 80
Sector size:  512
interleave factor:  2:4
Formatting disk...
Percentage complete: Format complete, checking...
Quick check of disk passes OK.
 
 

  3. Write a disk label to the floppy: 

    # disklabel -rw /dev/rdisk/floppy0a
/dev/rdisk/floppy0a:    
2880 sectors in 80 cylinders of 2 tracks, 18 sectors
1.4MB in 5 cyl groups (16 c/g, 0.28MB/g, 64 i/g)
super-block backups (for fsck -b #) at:
32, 640, 1184, 1792, 2336,
 
 

  4. Create a UFS file system on the floppy: 

    # newfs  /dev/rdisk/floppy0a

  5. Mount the floppy for use: 

    # mount /dev/disk/floppy0a /mnt

    The preceding command assumes that the /mnt directory exists and is currently unused. If a mount directory is unavailable, create one by using the following command: 

    # mkdir /floppy_disk

See fddisk(8) for more information.

You can also access DOS-formatted floppies by using the mtools commands provided the appropriate software subsets are installed and the programs exist in the /usr/ucb directory. See the Installation Guide for information about the optional software subsets.

Before using the floppy with the mtools commands, you must create a target device as follows:

  1. Your /dev/disk directory must contain the device special files for two floppy disk partitions named /dev/disk/floppyNa, and /dev/disk/floppyNc. If these files do not exist, create them by using the dsfmgr -n command

  2. Link the floppy's c partition to the mtools target file as follows: 

    # ln -s /dev/disk/floppy0c /dev/disk/floppy

  3. To test the configuration of the diskette drive, insert a DOS-formatted disk and enter the following command: 

    # /usr/ucb/mtools/mdir
Volume in drive A is "volume_name."
	    Directory for A:/
 
	    file type size date time
	    file type size date time
 
 

You can use the commands located in the /usr/ucb/mtools directory to manage floppy diskettes in MS-DOS format. See mtools(1) for information about configuring SCSI-attached floppy drives.

7.2    Managing Host Bus Adapters (HBAs)

This section provides information on managing specific host bus adapters (HBAs), such as SCSI adapters. It describes how you can manage and obtain information on HBAs. It also includes information on configuring or operating specific models of HBA and documents any configuration restrictions.

7.2.1    KZPSA Firmware on AlphaServer 1000A and 2100A Systems

The KZPSA is a PCI to Single Channel, FWD, SCSI-2 Adapter. On AlphaServer 1000A and 2100A class systems, updating the firmware on a KZPSA SCSI adapter is not supported when the adapter is installed behind the PCI-to-PCI bridge. See your hardware installation manual for further information.

7.2.2    KZPBA (Qlogic ISP1040B) Configuration

On systems with a Qlogic ISP1040B option, CAM errors similar to the following might occur when you boot the system: 

pci2000 at pci0 slot 8
isp0 at pci2000 slot 0
isp0: QLOGIC ISP1020A
cam_logger: CAM_ERROR packet
cam_logger: bus 0
isp_probe
NVRAM parameters invalid, using driver Fast10 defaults

To correct the error, you must use the eeromcfg utility to program the NVRAM with the proper set of parameters. The eeromcfg utility is provided in the /mnt-pnt/utility directory of the Alpha Systems Firmware Update CD-ROM. Consult the readme.txt file in that directory for information about how to use the utility.

Note

The KZPBA SCSI controller has two variants. KZPBA-CA/CX is a Qlogic ISP1020/1040 Single Ended PCI to UltraSCSI single channel controller. KZPBA-CB/CY is a Qlogic ISP1020/1040 Differential PCI to UltraSCSI controller. Both controllers are identified as Qlogic ISP1020/1040 controllers at the SRM console.

To identify which controller is in the system, look for a symbol near the external connector 68 pin (HD). The marking on the left hand side of the external cable connector -< >> , indicates that the controller is an ISP1020/1040 Differential controller. The Single Ended PCI controller is marked -< > .

7.3    Graphics Adapters

This section describes how to obtain information about the graphic adapters installed on your system. It also describes how to configure certain models of graphic adapter.

Note

Ensure that your video monitor supports the settings before you make any of the optional changes referenced in this section. For monitors that are listed as supported in the Tru64 UNIX QuickSpecs, consult the section of your owner's manual that is titled Video Resolutions.

7.3.1    Related Documentation and Resources

See the following documents for more information on configuring graphics adapters:

Best Practice documents on the topic of graphics are available online at the following Web location:

http://www.tru64unix.compaq.com/docs/best_practices.

Current titles are as follows:

7.3.2    Obtaining Information About Graphics Controllers

To determine the current model of graphics controller that is installed and in use, enter the following command: 

# /usr/sbin/sizer -gt
COMET

You can also use the hwmgr command to display information about graphics controllers, as shown in the following example: 

# /sbin/hwmgr get attribute -category graphics_controller
57:
  name = comet0
  category = graphics_controller
  sub_category = 3D
  model = COMET
  power_mgmt_capable = 1
  video_memory_size =  4 MB
  num_planes = 8
  num_colors = 256
  X_resolution = 1024
  Y_resolution = 768
  registration_time = Thu Jul 25 13:12:24 2002
  user_name = (null) (settable)
  location = (null) (settable)
  software_module = (null)
  state = available
  state_previous = unknown
  state_change_time = none
  event_count = 0
  last_event_time = none
  access_state = online
  access_state_change_time = none
  capabilities = 0
  indicted = 0
  indicted_probability = (null)
  indicted_urgency = (null)
  disabled = 0
 
 

In the preceding example, the first command determines the name of the graphics adapter. The second command displays the attributes (properties) associated with the adapter. Using the adapter's name (comet0) and its hardware identifier (HWID) of 57, you can obtain other information about the graphics adapter, such as where it is located in the hardware hierarchy: 

# /sbin/hwmgr view hierarchy
52:   connection pci3slot6
57:     graphics_controller comet0

The preceding display is truncated for clarity. You can also use the SysMan Station to determine the location of a graphics adapter and display its attributes. See Chapter 2.

7.3.3    3Dlabs OXYGEN VX1 PCI/AGP Graphics Controller

The 3Dlabs OXYGEN VX1 PCI Graphics Controller (system option SN-PBXGF-AB) is a 2D controller based on the Graphics Chip 3Dlabs GLINT P3 graphics chip. It supports dual display and 24 color planes at a maximum resolution of 1920 x 1200 pixels (16-bit) at 70Hz frequency or 1280 x 1024 pixels (24 bit) at 85 Hz frequency. A single 15-pin VGA connector is provided on the card.

The 3DLabs OXYGEN VX1 AGP graphics controller accelerator module is a single expansion-slot, 32-bit AGP bus graphics option that provides 2D graphics acceleration for supported systems. It is based on 3DLabs' Permedia P4 graphics chip.

Installation and configuration instructions for supported releases of Tru64 UNIX are provided in the document titled 3Dlabs OXYGEN VX1 PCI Graphics Controller Installation Guide. You can download this manual from the following location:http://www.compaq.com/alphaserver/download/ek-vx1gc-ig.pdf

The following operating restrictions for Tru64 UNIX are specified in full in the hardware documentation:

7.3.4    Radeon 7500 PCI/AGP Graphics Controller

The ATI Radeon 7500 AGP & PCI (System options 3X-PBXGG-AB & 3X-PBXGG-AA, respectively) are 3D/2D graphics controllers based on ATI's RV200 Graphics Chip. The AGP variant is a single slot, 32 bit card that is compliant with the AGP Specification 2.0 at a 2X/4X speed. The PCI variant is a single PCI slot, 32 bit card that is compliant with the PCI 2.2 & hot-plug 1.1 specification at a 66MHZ bus speed.

The Radeon 7500 cards provide 64 MB of on-board DDR video memory, dual independent display controllers, and support for Digital Flat Panel Monitors (DVI-I). The primary video output port with connector for standard CRT monitors is capable of resolutions up to 2048 x 1536 pixels, 24 bits per pixel and 75 HZ refresh rate. The secondary video output port is capable of supporting either a Digital Flat Panel Monitor up to 1280 x1024 resolution, 24 bits per pixel and 75HZ refresh rate or a CRT monitor with resolutions upto 2048 X 1536, 24 bits per pixel, 75HZ.

7.3.4.1    Identifying the Radeon 7500

During system boot, the Radeon 7500 messages similar to the following are displayed at the console, depending on how many controllers are installed on the system: 

radeon0 at pci0 slot 13
AGP 0.99 on Titan @ 0x00000000 16777216MB
radeon_initialize: Initialized radeon 1.0.0 20010105
 
 

When the system is at single or multiuser mode, use the following hwmgr commands to determine the hardware identifier (used with the -id option) and display the controller's attributes (properties): 

# /sbin/hwmgr view hierarchy | grep graphics_controller
 57:             graphics_controller radeon0
# /sbin/hwmgr get attributes -id 57
   name = radeon0
   category = graphics_controller
   sub_category = 2D
   model = radeon
   power_mgmt_capable = 1
   video_memory_size =  0 MB
   num_planes = 8
   num_colors = 256
   X_resolution = 1280
   Y_resolution = 1024
   registration_time = Fri Jul 19 09:00:33 2002
   user_name = (null) (settable)
   location = (null) (settable)
   software_module = (null)
   state = available
   state_previous = unknown
   state_change_time = none
   event_count = 0
   last_event_time = none
   access_state = online
   access_state_change_time = none
   capabilities = 0
   indicted = 0
   indicted_probability = (null)
   indicted_urgency = (null)
   disabled = 0

The preceding output is an example. The actual output from the command might not equate to the controller's current settings, which are determined by the operating system. Refer to Section 7.3.4.4 and Section 7.3.4.5 for configuration information. You can determine the graphics resolution of the controller on a running system by using the following command: 

# /usr/sbin/sizer -gr
1024x768

7.3.4.2    Restrictions on Use

The following restrictions apply to the current release of Tru64 UNIX:

Refer to the hardware documentation for the Radeon 7500 for more information.

7.3.4.3    Radeon 7500 Video Modes

Table 7-1 lists the video modes (resolution) supported by the Radeon 7500 graphics controller (or adapter).

Table 7-1:  Radeon 7500 Video Modes (Resolution)

Resolution (pixels) Color Depth (bits per pixel) Refresh Rates (Hz)
640x480 24, 16, 8 60, 72, 75, 85
800x600 24, 16, 8 60, 72, 75, 85
1024x768 24, 16, 8 60, 70, 75, 85
1152x864 24, 16, 8 60
1280x1024 24, 16, 8 60, 75, 85
1600x1200 24, 16, 8 60, 65, 75, 85
1920x1440 24, 16, 8 60, 75
2048x1536 24, 16, 8 60, 65, 70, 75

The Radeon 7500 graphics adapter supports only one color depth at a time. The default visual mode is as follows:

7.3.4.4    Configuring the Xserver

Video modes are specified in the /usr/var/X11/Xserver.conf file, which is the Xserver configuration file. See Xdec(1X) for more information. To modify the video mode, change the following parameters as necessary:

The following procedure describes how to change your graphics mode:

  1. Log in as root user on a remote terminal.

    Make any changes by using a remote terminal login or the console character cell terminal. If you use the root CDE login, you might experience problems when the video resolution changes.

  2. Preserve the original version of the /usr/var/X11/Xserver.conf file so that you can restore it if there are problems with the new version. For example: 

    # cp /usr/var/X11/Xserver.conf /usr/var/X11/Xserver.confORIG

  3. Edit the original /usr/var/X11/Xserver.conf file with your required changes. At the end of the file you will see the following args location where you insert user command options: 

    ! you specify command line arguments here
args <
        -pn
>

    For example, to change the default video mode to a resolution of 1280x1024, 8 bits per pixel, PseudoColor, at 75 Hz, modify the args section of the Xserver.conf file as follows: 

    args <
     -pn -screen 1280x1024 -depth 8 -vclass PseudoColor -vsync 75

    Save the Xserver.conf file.

  4. Restart the Xserver as follows: 

    # /usr/sbin/init.d/xlogin stop
# /usr/sbin/init.d/xlogin start

7.3.4.5    Configuring the CDE Xserver

For the CDE user environment, you can change the default video mode by modifying the /var/dt/Xservers file as follows. This procedure works only for CDE and not for other X-compliant user environments.

  1. Log in as root user on a remote terminal.

  2. Verify that the /etc/dt/config directory exists. If it does not exist, create it as follows: 

    # mkdir /etc/dt/config 
# chmod 755 /etc/dt/config

  3. Copy the default Xservers file as follows: 

    # cp /usr/dt/config/Xservers etc/dt/config/Xservers

    At the end of the file you will see the following location where you insert your user command options: 

       :0   Local local@console /usr/bin/X11/X :0
 

  4. Edit the /etc/dt/config/Xservers file to add the appropriate options. For example, change the default to 1280x1024, 8 bits per pixel, PseudoColor, at 75 Hz, modify the Xservers file as follows: 

    :0 Local local@console /usr/bin/X11/X :0 -screen 1280x1024 -depth 8
-vclass PseudoColor -vsync 75

    There should be no line breaks in this line. The preceding example is shown on two lines for clarity.

  5. Restart the Xserver as follows: 

    # /usr/sbin/init.d/xlogin stop
# /usr/sbin/init.d/xlogin start