Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 36 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
36
Dung lượng
2,42 MB
Nội dung
Crash Dumps Runtime Crash Dumps Chapter 4 73 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 Chapter 4 74 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 Chapter 4 75 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 Chapter 4 76 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 Chapter 4 77 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 Chapter 4 78 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. Chapter 5 79 5 Devices This chapter describes how the HP-UX and Tru64 UNIX operating systems recognize devices through device files. It also describes the naming conventions for the device files and the commands and utilities for scanning, manipulating, and creating devices. Devices Devices and Device Special Files Chapter 5 80 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 Devices and Device Special Files Chapter 5 81 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 Device Special Files HP-UX Tru64 UNIX (V5.0 and higher) Terminals /dev/ (/dev/ttyXX) /dev/ (/dev/ttyXX) Modems /dev/ /dev/ Printers /dev/ (/dev/lpN) /dev/ (/dev/lpN) Disks (Block devices) /dev/dsk/ /dev/disk/ Disks (Character devices) /dev/rdsk/ /dev/rdisk/ LVM Volume Groups /dev/vgnn/ N/A LVM Logical volumes (Block devices) /dev/vgnn/lvolN N/A LVM Logical volumes (Character devices) /dev/vgnn/lrvolN N/A LSM Logical volumes (Block devices) N/A /dev/vol/ LSM Logical volumes (Character devices) N/A /dev/rvol/ 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 (Block devices) /dev/ac/ N/A 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 (Block devices) /dev/ac/ N/A Magneto-optical devices (Character devices) /dev/rac/ N/A kernel pseudo-driver file, used by setboot /dev/kepd N/A Devices Devices and Device Special Files Chapter 5 82 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. # lsdev Character Block Driver Class 0 -1 cn pseudo 1 -1 asio0 tty 2 -1 SCentIf unknown 3 -1 mm pseudo 4 -1 olar_psm_if olar 5 -1 dev_olar olar 6 -1 devkrs pseudo 7 -1 lpr0 unknown 8 0 sioflop unknown 10 -1 hcd usb 11 -1 usbd usbdev [...]...Devices Devices and Device Special Files 12 13 14 15 16 17 18 19 20 21 22 23 25 26 27 28 31 32 33 36 37 38 44 45 48 49 50 51 54 57 58 61 62 63 64 69 72 73 74 97 116 119 156 157 164 168 174 1 83 188 189 2 03 207 216 227 229 232 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 64 -1 -1 -1 -1 97 -1 -1 -1 -1 -1 -1 -1 -1 31 -1 -1 -1 -1 -1 -1 -1 hub hid btlan maclan... noted above) to /vmunix as follows: # cp /usr/sys/MYSYS/vmunix/vmunix If you used the -n option, you must copy vmunix as well If you built a bootstrap linked kernel using the -b option, follow the instructions displayed by the doconfig program to copy the built modules and new /etc/sysconfigtab file into place 8 Reboot the system as follows: # /usr/sbin/shutdown -r now See the Tru64 UNIX doconfig (8) reference... 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 The sys_check utility (Tru64 UNIX) The sys_check utility examines various system attributes and makes recommendations for their appropriate settings See Chapter 3 of the Tru64 UNIX System Administration manual for... displays them on the standard output The diagnostic messages are printed by the system when unusual events occur, such as when system tables overflow or the system crashes Examples of such events are a system crash or system table overflow The dsfmgr command (Tru64 UNIX) The dsfmgr command, now obsolete, was used to manage Tru64 UNIX device special files (before V5.1A) using the file naming format introduced... instead Tru64 UNIX Kernel Configuration Commands and Utilities The following utilities and, in some cases, their associated database files for Tru64 UNIX kernel creation and configuration are described here The doconfig command (Tru64 UNIX) This is the utility that you use to build the Tru64 UNIX kernel with the settings specified in the current system configuration files The kopt command(Tru64 UNIX) This... Location of the vmunix kernel, illustrates the file systems of both the HP-UX and Tru64 UNIX operating system in terms of the location of the kernel file and their build environment Figure 6-1 98 Location of the vmunix kernel Chapter 6 Kernel Configuration Building the Kernel Building the Kernel The kernel is usually reconfigured to add or remove drivers, modify system parameters to tune the system, adding... The autosysconfig utility (Tru64 UNIX) Use this utility to maintain the list of dynamic Tru64 UNIX kernel subsystems that are configured automatically 102 Chapter 6 Kernel Configuration Commands and Utilities The cfgmgr command (Tru64 UNIX) This server is used by the sysconfig and other utilities to manage kernel subsystems See the kloadsrv(8) reference page, which documents the kernel load server... commands (Tru64 UNIX) The sysconfig command line utility and its database, sysconfigtab, are used to maintain the kernel subsystem configuration and to modify or display kernel subsystem attributes The sysconfigtab command documents the file format of the configuration database Use the sysconfigdb command line utility to manage the subsystem configuration database The stanza command documents the format... number The assignment of major and minor device numbers is specific to each system Under Tru64 UNIX, you can determine the device numbers by examining the conf.c system source file; if you change the contents of that file to add a device driver, you must rebuild the kernel Refer to the System Administrator manuals supplied with your system for additional information The mksf command (HP-UX) The HP-UX mksf... “DEVICE” from the system The scsimgr command (Tru64 UNIX) The now obsolete Tru64 UNIX scsimgr utility, which was superseded by the hwmgr and dsfmgr commands) automatically made device special files for new devices The scan options stopped updating the device special files for a device when they encounter an error 94 Chapter 5 Devices Commands and Utilities SAM (HP-UX) The HP-UX System Administration Manager . pseudo 23 -1 stcpmap pseudo 25 -1 nuls pseudo 26 -1 netqa pseudo 27 -1 dmem pseudo 28 -1 diag0 diag 31 -1 tun pseudo 32 -1 telm strtelm 33 -1 tels strtels 36 -1 tlclts pseudo 37 -1 tlcots. 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. 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