HP-UX/Tru64 UNIX System Administration Interoperability phần 3 doc

Also, in both instances, the names of the directories for character device special file names for disks are preceded with the letter r for “raw.” Both operating systems differ in their s

Crash Dumps

Runtime Crash Dumps

Runtime Crash Dumps

Tru64 UNIX features the Create Dump Snapshot utility, which enables you to perform a crash dump during runtime

Use the following procedure to create a dump snapshot of a Tru64 UNIX system:

1 Log in as superuser (root)

2 Invoke the SysMan Menu

3 Select Support and Services

4 Select Create Dump Snapshot The Create Dump Snapshot window opens

5 Select either the Partial or Full radio button depending on the type of dump you want

6 Optionally select the Enable Compression check box and use the slider to specify the Compression ratio

Crash Dumps

Runtime Crash Dumps

7 Optionally select the Disable Suppression and Ignore insufficient space warning options

8 Specify the directory where the dump will be stored

9 Select Update MB to determine the amount of disk space is available

10 Select OK The Create Dump Snapshot window closes

Crash Dumps

Commands and Utilities

Commands and Utilities

The HP-UX and Tru64 UNIX operating systems use a variety of commands and utilities to configure, save, and analyze crash dumps

The Configure System Dump utility (Tru64 UNIX)

The Configure System Dump utility to configure the generic system configuration variables associated with the savecore command

Use the Configure System Dump utility to:

• Disable or enable crash dumps

• Choose to save either a partial or full crash dump

• Disable or enable compression of the dump file

• Choose whether the crash dump will be saved to memory, disk, or both

• Enable or disable the use of paged data, which is exempted from the crash dump by default

Selecting Support and Services->Configure Dump in the SysMan Menu opens the Configure System Dump main window

The crashconf command (HP-UX)

The crashconf command displays and/or changes the current system crash dump configuration The crash dump configuration consists of three lists:

• The crash dump device list, which identifies all devices that can be used to store a crash dump

• The included class list, which identifies all system memory classes that must be included in any crash dump

• The excluded class list, which identifies all system memory classes that should be excluded from a crash dump

Most system memory classes are in neither the included class list nor the excluded class list Instead, the system determines whether or not to dump those classes of memory based on the type of crash that occurs.Any changes to the configuration take effect immediately and remain in effect until the next system reboot, or until changed with a subsequent invocation of the crashconf command

The output of crashconf is not designed to be parsed by applications or scripts Applications that require crash

dump configuration information should retrieve that information using pstat(2).

The crashdc utility (Tru64 UNIX)

The crashdc utility examines the core image of the operating system to extract critical diagnostic data This utility is a shell script that invokes several tools and commands that extract selected parameters of a running or a crashed system (for example, system configuration, running processes, and panic messages).The Tru64 UNIX operating system usually invokes the crashdc utility during system startup If the most recent core dump has been saved by the savecore command, both the core image and the system kernel (respectively vmcore.n and vmunix.n, where the variable n is the crash number) are saved in the crash

Crash Dumps

Commands and Utilities

directory (by default, /var/adm/crash) Also, the crashdc utility saves the output as the file crash-data.n

(where the variable n is the crash number) in the crash directory The crashdc utility is invoked only if crash-data.n output in the crash directory does not exist or is not from the most recent crash

The crashutil command (HP-UX)

The crashutil command copies and preserves crash dump data, and performs format conversions on it Common uses of crashutil include:

• Copying portions of a dump that still reside on a raw dump device into a crash dump directory

• Converting between different formats of crash dumps

• Copying crash dumps from one directory, or medium, to another

The crashutil command reads a crash dump from a specified source and writes this data to a specified file When crashutil completes successfully, the entire contents of the crash dump will exist at the specified destination file, including any portions that had been on raw dump devices

The Create Dump Snapshot utility (Tru64 UNIX)

The Create Dump Snapshot utility configures the dumpsys command, which dumps a snapshot of memory manually into a file when you cannot halt the system to generate a normal crash dump Selecting Support and Services->Create Dump Snapshot in the SysMan Menu opens the Create Dump Snapshot main window Use the Create Dump Snapshot utility to:

• Capture a portion or the entire contents of physical memory

• Set compression preferences for the dump file

• Choose the directory where the dump file will be saved

The expand_dump command (Tru64 UNIX)

The expand_dump utility can only be used on compressed crash dump files; it produces a file that can be read

by tools that have not been upgraded to support compressed crash dump files, as well as tools which support compressed crash dump files

The kdbx command (Tru64 UNIX)

The kdbx debugger is a crash analysis and kernel debugging tool, which is an interactive program that serves

as a front-end to the dbx debugger The kdbx debugger is extensible, can be customized, and is insensitive to changes of offsets and sizes of fields in structures The only dependencies on kernel header files are for bit definitions in flag fields

The kdbx debugger lets you examine either the running kernel or dump files created by the savecore

command In either case, you examine an object file and a core file For running systems, these files are usually /vmunix and /dev/mem, respectively Dump files created by the savecore command are saved in the directory specified by the /sbin/init.d/savecore script By default, the directory is /var/adm/crash

The Kernel Tuner Graphical User Interface (Tru64 UNIX)

The Kernel Tuner graphical user interface enables you to modify or display kernel subsystem attributes The dxkerneltuner(8) reference page describes this utility

Crash Dumps

Commands and Utilities

The kctune command (HP-UX)

The kctune command is administrative command for HP-UX kernel tunable parameters It gives

information about tunable parameters and their values, and makes changes to tunable values.

The libcrash library (HP-UX)

The libcrash library provides access to system crash dumps Access to a dump through the library is independent of the format of the crash dump It is also independent of the location of the dump, which could

be on a raw dump device, in files in a file system, or a mixture of the two

The main kernel crash dump debuggers, q4 and adb(1), use this library It is not necessary to save the crash dump from the dump device into the file system before it can be debugged The savecrash

command must be run - it has to create a directory for the dump and an INDEX file, at minimum - but it can

be told not to copy the dump data out of the dump devices

SAM (HP-UX)

The SAM utility provides a method for selecting the dump device and for modifying the dump order

The savecrash command (HP-UX)

The savecrash command saves the crash dump information of the system (assuming one was made when the system crashed) and writes a reboot message in the shutdown log file

Usually, savecrash creates the INDEX file in the crash directory from the crash dump header, copies all kernel modules that were loaded in memory at the time of the crash, and copies all dump device contents into crash image files

When savecrash writes out a crash dump directory, it checks the space available on the file system

containing the specified directory name parameter savecrash will not use that portion of the file system space which is reserved for the superuser Additional space on the file system can be reserved for other uses with -m minfree, where minfree is the amount of additional space to reserve This option is useful for ensuring enough file system space for normal system activities after a panic

If there is insufficient space in the file system for the portions of the crash dump that need to be saved,

savecrash will save as much as will fit in the available space (Priority is given to the index file, then to the kernel module files, and then to the physical memory image.) The dump will be considered saved, and

savecrash will not attempt to save it again, unless there was insufficient space for any of the physical memory image

The savecrash command also writes a reboot message in the shutdown log file (/etc/shutdownlog), if one exists (If a shutdown log file does not exist, the savecrash command does not create one.) If the system crashes as a result of a kernel panic, the savecrash command also records the panic string in the shutdown log

The savecore command (Tru64 UNIX)

The savecore command is usually invoked automatically during system startup It determines whether a crash dump has been made, and if there is enough file system space to save it When invoked with the -f option, the savecore program copies the dump even if there seems to be insufficient file space If space is insufficient, only a portion of the dump is saved into the crash dump file as a truncated dump If compressed, truncated dumps are not usable, information is stored in the /var/adm/crash directory by default

Crash Dumps

Commands and Utilities

The crash dump contains the copy of a selected portion of physical memory (or all of physical memory in the case of a full crash dump) as of the time of the crash The savecore command saves this information in the

vmzcore.n file if the dump is in the compressed form, or in the vmcore n file if in the uncompressed form The command also copies the kernel executable image, usually /vmunix, (or whatever UNIX image filename was recorded as the name of the booted file) to the /var/adm/crash/vmunix.n file You analyze the

vmzcore.n (or vmcore.n) and vmunix.n files to determine the cause of the crash

The sysconfig command (Tru64 UNIX)

The sysconfig command is used to query or modify the kernel subsystem configuration Use this command

to add subsystems to your running kernel, reconfigure subsystems already in the kernel, ask for information about (query) subsystems in the kernel, and unconfigure and remove subsystems from the kernel

A subset of kernel subsystems can be managed using the sysconfig command This command allows you to add and remove loadable subsystems from the running kernel It also allows you to modify the value of subsystem attributes if the subsystem supports run-time modifications

You can also use the dxkerneltuner application to modify the value of subsystem attributes This application provides a graphical user interface for tuning kernel subsystems

Devices and Device Special Files

Devices and Device Special Files

Devices

Under UNIX, devices are made available to the rest of the system through device special files located in the

/dev directory The UNIX kernel needs to be able to associate a device file with the appropriate hardware address and driver When you configure system hardware, you instruct the operating system regarding that hardware Much of this configuration is performed automatically when you boot the system; the extend of what you need to do depends on whether or not the device is autoconfigurable and whether or not the driver is present in the currently running kernel

Thus, for a peripheral device to work under UNIX:

• The device must be connected to the computer and turned on

• The appropriate drivers must be part of the kernel

• The drivers must be connected in the proper order

• At least one device file must exist for the device

Devices are categorized as block devices and character devices:

Block device A block device transfers data a block at a time using the system buffers; an example of a

block device is a disk drive holding a mountable file system

Character device A character device reads or writes data one character at a time Tape drives are usually

character devices

Some devices are capable of I/O in both block and character mode Such devices require two device files: one for block and one for character mode A hard disk is an example of a device which uses both character and block device files Use the block device file when mounting a disk as a file, but use the character device file when you access the same disk for backups

System Initialization

On both operating systems, the kernel performs several system initialization tasks, including probing all hardware installed on the system, during the initial system boot During the hardware probe, the kernel identifies all devices - buses, channel adapters, device adapters, and external devices - that can be auto configured The kernel binds an appropriate driver to each autoconfigurable device detected at a specific hardware address

After completing system initialization tasks, including hardware probing, the kernel invokes the init

command, which reads the /etc/inittab file and invokes several system startup commands listed in that file Some of these startup commands create device special files as needed

Device Special Files

A device special file enables an application, such as a database application, to access a device through its device driver, which is a kernel module that controls one or more hardware components of a particular type Examples include network controllers, graphics controllers, and disks (including CD-ROM devices)

Device special files are located in the /dev directory hierarchy They are identified by their file name and major and minor numbers You can look at this information when you list the files in the /dev directory

Devices and Device Special Files

Notice that the names for these disk device special files differ between both operating systems Also, in both instances, the names of the directories for character device special file names for disks are preceded with the letter r for “raw.” Both operating systems differ in their special device file naming conventions

All Hewlett-Packard peripheral devices supported by HP-UX 10 and HP-UX 11 can be configured

automatically Device files for devices or I/O cards are automatically created during the reboot process Device special files are created during the Tru64 UNIX full installation and, during subsequent reboots, the operating system creates new device special files for any new supported peripherals it encounters

By convention, device files are maintained in the /dev directory Some device files are found in /dev itself, while others are grouped in its subdirectories Device files defined in subdirectories are grouped by device type (reel tape, cartridge tape, etc.) and by device class (block or character)

The following table shows the location of some of the devices files in /dev directory

Table 5-1 Location of Device Special Files

(V5.0 and higher)

LVM Logical volumes (Block devices) /dev/vgnn/lvolN N/A

LVM Logical volumes (Character devices) /dev/vgnn/lrvolN N/A

Cartridge Tape Drives (Character devices) /dev/rct/ /dev/

Master pseudo terminal device files /dev/ptym/ /dev/ (/dev/ptym[0-9|a-f])

Slave pseudo terminal device files /dev/pty/ /dev/ (/dev/ptyXX)

Magneto-optical devices (Character devices) /dev/rac/ N/A

Cartridge Tape Drives (Character devices) /dev/rct/ /dev/

Master pseudo terminal device files /dev/ptym/ /dev/ (/dev/ptym[0-9|a-f])

Slave pseudo terminal device files /dev/pty/ /dev/ (/dev/ptyXX)

Magneto-optical devices (Character devices) /dev/rac/ N/A

kernel pseudo-driver file, used by setboot /dev/kepd N/A

Devices and Device Special Files

The operating system also uses device special files to access pseudo device drivers that do not control a hardware component, for example, a pseudo terminal (pty) terminal driver, which simulates a terminal device The pty terminal driver is a character driver typically employed by remote logins

Major and Minor Device Numbers

When you use the ls -l command to list the console device special file on an HP-UX operating system, the output resembles the following:

crw w w- 1 root sys 0 0x000000 Apr 14 18:18 /dev/console

When you use the ls -l command to list the console device special file on a Tru64 UNIX operating system, the output resembles the following:

crw w w- 1 root terminal 0, 0 Apr 21 14:43 /dev/console

Notice the c character at the beginning of the output; it indicates that this device file is for a character device Notice also that there are two sets of numbers, indicating the major device number and the minor device number For the HP-UX operating system, the minor device number is expressed as a hexadecimal value while the Tru64 UNIX operating system expresses both device numbers as decimal values

The major device number identifies the kernel driver that is referenced to by the device file The value chosen for the major device number is based on both the device driver and the access method (block or character) For devices needing both a character and block device file, like disks, there are different character device major numbers and block device major numbers

The output for the ls -l command to list the disk device files for a disk on an HP-UX operating system resembles the following:

# ls -l /dev/dsk/c0t0d0 /dev/rdsk/c0t0d0

brw-r - 1 bin sys 31 0x000000 Mar 13 2001 /dev/dsk/c0t0d0

crw-r - 1 bin sys 188 0x000000 Mar 13 2001 /dev/rdsk/c0t0d0

The output for the ls -l command to list the disk device files for a disk on an Tru64 UNIX operating system resembles the following:

$ ls -l /dev/disk/dsk0c /dev/rdisk/dsk0c

brw - 1 root system 19, 6 Dec 31 1995 /dev/disk/dsk0c

crw - 1 root system 19, 7 Dec 31 1995 /dev/rdisk/dsk0c

The first character of each line identifies the type of device file: a b denotes a block device, and a c indicates a character device

The major number of the block device on the HP-UX system is 31; the major number of the character device is

188 The minor number of the character device is (hexadecimal) zero in both cases On the Tru64 UNIX system, the disk has the same major device number but the minor device numbers differ

The HP-UX lsdev command lists the major device numbers and the names of device drivers configured into the system and available for invocation via special files Here is an example of the output

The first two columns list character and block major numbers respectively A -1 in either column means that

a major number does not exist for that type of driver Note that in the example above the SCSI disk driver (sdisk) has both a character and a block major number Thus a listing of the device files for such a disk at SCSI address 6 would look like the following:

Devices and Device Special Files

/dev/rdsk:

total 0

crw-r - 1 root sys 188 0x006000 Aug 11 11:50 c0t6d0

The directory containing the block device special file, with a major number of 31, is /dev/dsk, and the directory containing the character device file is /dev/rdsk (The letter r is used here because character mode

is often referred to as “raw” mode)

For HP-UX, the minor number is an encryption of address and configuration information It typically defines one or both of the following:

• The device’s physical address

• operational information, such as tape density or rewind options in the case of tape drives

Device File Naming Conventions

Device File Naming Conventions

The HP-UX operating system and the Tru64 UNIX have different device file naming conventions Each is discussed in this section

HP-UX

The device special file naming conventions under the HP-UX operating system may vary depending whether the device is a disk, an LV volume, a tape drive, a terminal, a printer, or a modem These are discussed here

Disks (Physical Volumes)

Physical volumes are identified by their device file names The following convention applies to device file names for disks:

/dev/[r]dsk/cCtTdD[sS]

rdsk Specifies a raw, or character, device The file is located in the /dev/rdsk directory for

disks

dsk Specifies a block device The file is located in the /dev/dsk directory for disks

C Specifies the Controller on the system to which the disk drive is connected This number is

the same for all disks connected to that controller

T Specifies the Target number Each disk on a SCSI bus has its unique target number

D Specifies the hardware device unit number This is important only for disks (and tape

drives) that have two or more devices with a shared controller

The device unit number is always 0 (zero) for all disks that are not on a shared controller The device unit numbers reference the internal number of the device units for disks on shared controller

S Specifies the section number of the disk By default, the insf command does not create

device files for all sections of a disk If you do not want to use the logical volume manager (LVM) you must create the device files manually for the different disk sections with mksf The following examples illustrate the naming convention:

Device File Naming Conventions

By default, volume groups are maintained in directories named vg00, vg01, vgnn according to the order in which they were created

When LVM creates a logical volume, it creates both block and character device special files LVM then places the device files for a logical volume in the appropriate volume group directory

The default naming convention for these special files is:

/dev/vgnn/[r]lvolX

where:

r indicates that the device is a character, or raw, device

nn is a two-digit value for the volume group directory

X specifies the logical volume number

For example, the default block name for the first logical volume created in volume group vg02 would have the full path name /dev/vg02/lvol1

See Chapter 13 for more information on LVM

Only use the raw device special file to create a physical volume or to restore a volume group configuration Use the block device for all other tasks

Tape Drives

The device file naming convention for tape drives is nearly identical as to that for disk drives After selecting the tape drive in the name, the options for this device are named To simplify the use of tape device file names, the insf command automatically creates more than one device file 9-track reel tapes can be written with four densities: 800 bpi, 1600 bpi, 6250 bpi, and compressed DDS/DAT tape drives support two different densities: compressed or noncompressed

Tape device files take the following forms:

/dev/[r]mt/cCtTdD[options]

/dev/[r]mt/T[options]

where

rmt indicates that the device is a character, or raw, tape device

mt indicates that the device is a block tape device

C is the tape drive controller number

T is the target number of the tape drive

options include any of the following:

BEST sets the best known options for this device, including hardware compression on all devices

supporting compressionh|m|l specifies the density at which the tape is to be written or read:

• l indicates low density (800 bpi),

• m indicates medium density (1600 bpi), and

• h indicates high density (6250 bpi)

Device File Naming Conventions

n indicates the tape will not be rewound or repositioned in any way when the device file is

Terminals, Modems, and Printers

Device special files for terminals, modems, and printers are usually character device special files; they are maintained in the /dev directory, not in any subdirectory They follow these naming conventions:

/dev/tty[d]CpN for a terminal

/dev/cu[l|a]CpN for a modem, an outbound auto-call unit

/dev/lpX for a printer

where:

C is the controller unit number of the multiplexor (MUX) card

N is the port number of the MUX card; port numbering starts with 0

X indicates the printer number; printer numbers start from 0 or 1

For example, /dev/tty0p2 is the character device file for a terminal port on the first MUX at port 2

Tru64 UNIX

The device naming convention for Tru64 UNIX underwent a major change in Version 5.0 Before that version, there was a limitation of eight devices per bus The special device file names encoded the bus and the logical unit number (LUN) of the device encoded in the format

With the advent of new busses that allowed more than eight devices per bus (wide SCSI supports 16 devices per bus; FibreChannel supports thousands of devices), Tru64 UNIX adopted a new device naming convention for all disk and tape devices with Version 5.0 FibreChannel also allows the LUNs to change dynamically, which the old device naming scheme also could not support

The new device naming convention also uses the world-wide identifier (WWID) of a device, usually a disk, internally A WWID is a unique identifier number set by the manufacturer for devices that support it Therefore, no two devices can have the same WWID Using the WWID to identify a disk has two implications, particularly for disk devices:

Device File Naming Conventions

• Once a disk device is recognized by the operating system, the disk's name will stay the same, even if its SCSI address changes

• Tru64 UNIX can support multipathing to a disk where the disk is accessible through different SCSI controllers Therefore, within a Tru64 UNIX Version 5.0 cluster environment, as disks are moved from one node to another node, the disk names and how they are accessed remains the same

See the Tru64 UNIX Hardware Administration manual for more information.

In this section, the term “legacy’ refers to devices before Version 5.0, and the term “current” refers to the naming conventions for devices from Version 5.0 forward

The following utilities were added to enhance the support for device naming and hardware management:

• the Device Special File Manager (dsfmgr) for managing device special file names

• the Hardware Manager (hwmgr) to assist in device management; this utility replaced the scsimgr utility

Disk Drives

The current naming conventions for disk special device file names have the following format:

/dev/[r]disk/dskNx

where

rdisk indicates that the disk is a raw, or character, device

disk indicates that the disk is a block device

N identifies the numeric disk name (disk 1, disk 2, and so on)

x indicates the disk partition The value c specifies the entire disk

An example would be /dev/disk/dsk2c

Some device special file directories are CDSLs, which enable devices to be available on a cluster-wide basis when a system is part of a TruCluster system

The legacy naming convention for disk special device file names had the following format:

/dev/[r]rz((bus*8)+N)X

where

rrz indicates that the disk is a raw, or character, device

rz indicates that the disk is a block device

N identifies the numeric disk name (disk 1, disk 2, and so on)

x indicates the disk partition The value c specifies the entire disk

An example would be /dev/rz2c to indicate the entire third disk (block device) on the first bus

Device File Naming Conventions

tape and ntape are the directories for the tape device special files Tape devices reside under the /dev/tape

directory; no-rewind tape devices reside under the /dev/ntape directory

n specifies the tape drive number

_dx is the tape density factor suffix The device special file name without this suffix uses the

default density Also, the suffix c indicates that the default density with compression is used A tape density factor of _dx uses the density associated with entry x (0, 1, 2, ) in the

/etc/ddr.dbase file

Tru64 UNIX supports existing device names as a compatibility option, but the same device cannot be

accessed through both the old and new name at the same time

For more information on the formats, see the Tru64 UNIX System Administration manual.

Creating Device Special Files

Creating Device Special Files

Creating device special files is a rare occurrence When either operating system is installed initially, it creates the device special files for all the devices it discovers Each time the system is rebooted, it searches for new devices that might be connected to the system and, if possible, creates the device special files for them However, you may need to create a device special file for the following instances:

• To restore accidentally deleted device special files

• To override standard naming conventions

• To create device special files that the operating system cannot create

HP-UX

The HP-UX operating system enables you to create device special files:

• when the device is already known to the system and

• when the device has not been assigned yet

With the HP-UX operating system, you can use either SAM or the mksf command to create a device special file if the device is already known to the system

You can use SAM’s Peripheral Driver window to access the Cards, Printers and Plotters, Terminals and Modems, and Uninterruptable Power Supplies dialog boxes You can add any of these device types by using the Add option in the Actions menu in the appropriate dialog box

See the mksf(1M) reference page for information on the options to the mksf command Examples for creating these device special file creation include the following:

The mksf command creates only one device file for a device Use the mksf to create a single device file that does not use standard naming conventions and to create device files that insf could not create