Contained WithinFind More DocumentationFeatured Support Resources |
Part VI Managing DevicesThis part provides instructions for managing devices in the Solaris 2.x environment. This part contains these chapters.
Chapter 19 Device Management (Overview/Tasks)The chapter provides overview information about managing peripheral devices in the Solaris 2.x environment. This is a list of overview information in this chapter. This is a list of step-by-step instructions in this chapter. For information about accessing devices, see Chapter 20, Accessing Devices (Overview). Device management in the Solaris 2.x environment usually includes adding and removing peripheral devices from systems, possibly adding a third-party device driver to support a device, and displaying system configuration information. Table 19-1 describes where to find step-by-step procedures for adding serial devices, such as printers and modems, and peripheral devices, such as a disk, CD-ROM, or tape drive to your system. Table 19-1 Where to Find Instructions for Adding a Device
About Device DriversA computer typically uses a wide range of peripheral and mass-storage devices. Your system, for example, probably has a SCSI disk drive, a keyboard and a mouse, and some kind of magnetic backup medium. Other commonly used devices include CD-ROM drives, printers and plotters, light pens, touch-sensitive screens, digitizers, and tablet-and-stylus pairs. The Solaris software does not directly communicate with all these devices. Each type of device requires different data formats, protocols, and transmission rates. A device driver is a low-level program that allows the operating system to communicate with a specific piece of hardware. The driver serves as the operating system's "interpreter" for that piece of hardware. Automatic Configuration of DevicesThe kernel, consisting of a small generic core with a platform-specific component and a set of modules, is configured automatically in the Solaris 2.x environment. A kernel module is a hardware or software component that is used to perform a specific task on the system. An example of a loadable kernel module is a device driver that is loaded when the device is accessed. The platform-independent kernel is /kernel/genunix. The platform-specific component is /platform/`uname -m`/kernel/unix. The kernel modules are described in Table 19-2. Table 19-2 Description of Kernel Modules
The system determines what devices are attached to it at boot time. Then the kernel configures itself dynamically, loading needed modules into memory. At this time, device drivers are loaded when devices, such as disk and tape devices, are accessed for the first time. This process is called autoconfiguration because all kernel modules are loaded automatically when needed. You can customize the way in which kernel modules are loaded by modifying the /etc/system file. See Chapter 66, Tuning Kernel Parameters (Tasks) for instructions on modifying this file. Features and BenefitsThe benefits of autoconfiguration are:
The autoconfiguration process is used by a system administrator when adding a new device (and driver) to the system. At this time, the administrator performs a reconfiguration boot so the system will recognize the new device. What You Need For Unsupported DevicesDevice drivers needed to support a wide range of standard devices are included in the Solaris 2.x environment. These drivers can be found in the /kernel/drv and /platform/`uname -m`/kernel/drv directories. However, if you've purchased an unsupported device, the manufacturer should provide the software needed for the device to be properly installed, maintained, and administered. At a minimum, this software includes a device driver and its associated configuration (.conf) file. The .conf files reside in the drv directories. In addition, the device may be incompatible with Solaris 2.x utilities, and may require custom maintenance and administrative utilities. Contact your device manufacturer for more information. Adding a Peripheral Device to a SystemAdding a new peripheral device usually involves:
Use the procedure below to add the following devices to a system:
In some cases, you may have to add a third-party device driver to support the new device. How to Add a Peripheral Device
How to a Add a Device DriverThis procedure assumes that the device has already been added to the system. If not, see "How to Add a Peripheral Device".
Example--Adding a Device DriverThe following example installs and verifies a package called XYZdrv.
Displaying Device Configuration InformationThree commands are used to display system and device configuration information:
See "Device Naming Conventions" for information on the device names used to identify devices on the system. driver not attached MessageThe following driver-related message may be displayed by the prtconf and sysdef commands:
This message does not always mean that a driver is unavailable for this device. It means that no driver is currently attached to the device instance because there is no device at this node or the device is not in use. Drivers are loaded automatically when the device is accessed and unloaded when the device is not in use. Identifying a System's DevicesUse the output of prtconf and sysdef commands to identify which disk, tape, and CD-ROM devices are connected to the system. The output of these commands display the driver not attached messages next to the device instances. Since these devices are always being monitored by some system process, the driver not attached message is usually a good indication that there is no device at that device instance. For example, the following prtconf output identifies a device at instance #3 and instance #6, which is probably a disk device at target 3 and a CD-ROM device at target 6 of the first SCSI host adapter (esp, instance #0).
The same device information can be gleaned from the sysdef output. How to Display System Configuration InformationUse the prtconf command to display system configuration information.
Use the sysdef command to display system configuration information including pseudo devices, loadable modules, and selected kernel parameters.
Examples--Displaying System Configuration InformationThe following prtconf output is displayed on a SPARC system.
The following sysdef output is displayed from an x86 system.
How to Display Device InformationDisplay device information with the dmesg command.
The dmesg output is displayed as messages on the system console and identifies which devices are connected to the system since the last reboot. Examples--Displaying Device InformationThe following dmesg output is displayed from a SPARC system.
The following dmesg output is displayed from an x86 system.
Chapter 20 Accessing Devices (Overview)This chapter provides information about how system administrators access the devices on their systems. This is a list of overview information in this chapter. For overview information about configuring devices, see Chapter 19, Device Management (Overview/Tasks). Accessing DevicesSystem administrators need to know how to specify device names when using commands to manage disks, file systems, and other devices. In most cases, system administrators use logical device names to represent devices connected to the system. Both logical and physical device names are represented on the system by logical and physical device files. How Device Information Is CreatedWhen a system is booted for the first time, a device hierarchy is created to represent all the devices connected to the system. The kernel uses the device hierarchy information to associate drivers with their appropriate devices, and provides a set of pointers to the drivers that perform specific operations. See OpenBoot 3.x Command Reference Manual for more information on device hierarchy information. Device Naming ConventionsDevices are referenced in three ways in the Solaris 2.x environment.
Logical Disk Device NamesLogical device names are used to access disk devices when you:
Many administration commands take arguments that refer to a disk slice or file system. Refer to a disk device by specifying the subdirectory to which it is symbolically linked (either /dev/dsk or /dev/rdsk), followed by a string identifying the particular controller, disk, and slice. 
Specifying the Disk SubdirectoryDisk and file administration commands require the use of either a raw (or character) device interface, or a block device interface. The distinction is made by how data is read from the device. Raw device interfaces transfer only small amounts of data at a time. Block device interfaces include a buffer from which large blocks of data are read at once. Different commands require different interfaces.
Table 20-1 shows which interface is required for a few commonly used disk and file system commands. Table 20-1 Device Interface Type Required by Some Frequently Used Commands
Specifying the SliceThe string you use to identify a specific slice on a specific disk depends on the controller type, either direct or bus-oriented. Table 20-2 describes the different types of direct or bus-oriented controllers on different platforms. Table 20-2 Controller Types
The conventions for both types of controllers are explained in the following subsections. Note - Controller numbers are assigned automatically at system initialization. The numbers are strictly logical and imply no direct mapping to physical controllers. SPARC: Disks With Direct ControllersTo specify a slice on a disk with a direct controller on a SPARC system, follow the naming convention shown in Figure 20-1. Figure 20-1 Naming Convention for Disks With Direct Controllers on SPARC Systems
To indicate the whole disk, specify slice 2 (2). If you have only one controller on your system, x will always be 0. x86: Disks With Direct ControllersTo specify a slice on a disk with an IDE controller on an x86 system, follow the naming convention shown in Figure 20-2. Figure 20-2 Naming Convention for Disks With IDE Controllers on x86 Systems
To indicate the entire Solaris fdisk partition, specify slice 2 (s2). If you have only one controller on your system, w will always be 0. SPARC: Disks With Bus-Oriented ControllersTo specify a slice on a disk with a bus-oriented controller (SCSI, for instance) on a SPARC system, follow the naming convention shown in Figure 20-3. Figure 20-3 Naming Convention for Disks With Bus-Oriented Controllers on SPARC Systems
If you have only one controller on your system, w will always be 0. For SCSI controllers, x is the target address as set by the switch on the back of the unit, and y is the logical unit number (LUN) of the drive attached to the target. If the disk has an embedded controller, y is usually 0. To indicate the whole disk, specify slice 2 (s2). x86: Disks With SCSI ControllersTo specify a slice on a disk with a SCSI controller on an x86 system, follow the naming convention shown in Figure 20-4. Figure 20-4 Naming Convention for Disks With SCSI Controllers on x86 Systems
If you have only one controller on your system, v will always be 0. For SCSI controllers, w is the target address as set by the switch on the back of the unit, and x is the logical unit number (LUN) of the drive attached to the target. If the disk has an embedded controller, x is usually 0. To indicate the entire Solaris fdisk partition, specify slice 2 (s2). Logical Tape Device NamesLogical tape device files are found in the /dev/rmt/* directory as symbolic links from the /devices directory.  The first tape device connected to the system is 0 (/dev/rmt/0), which may be one of the following types: QIC-11, QIC-24, QIC-150, or Exabyte. Tape density values (l, m, h, c, and u) are described in Chapter 38, Managing Tape Drives (Tasks). Logical CD-ROM Device NamesThe logical device name that represents the first CD-ROM device on a system is /dev/dsk/c0t6d0s0. Since CD-ROMS are managed by Volume Management, the logical CD-ROM device name is usually not used unless you want to mount the CD manually. See Chapter 11, Guidelines for Using CDs and Diskettes (Overview), for information on accessing your CD-ROM device. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|