Device Management | Solaris 9 Sun Certified System Administrator Study Guide

As a systems administrator, you should be able to add devices to your system. Depending on your computer's role, either as a stand-alone system or on a network, various peripherals are needed. They could include a tape drive for system backups, additional network cards, video adapters, modems, or disk drives.

Regardless of the type of device you wish to install, you need to install another component that enables the device to work with Solaris. This vital piece of software is called a device driver. Device drivers are small programs with one function: to enable Solaris and hardware to communicate. They are translators, if you will. Drivers are either built into Solaris or installed from floppy disk or CD-ROM. No device will function without the appropriate driver, and the driver must be written specifically for Solaris.

When Solaris boots, the system core, or kernel, is configured. Device drivers are called loadable kernel modules, because as a device is accessed, the appropriate driver is loaded into the kernel for usage. This automatic loading and unloading of device drivers is called autoconfiguration. Put another way, the kernel dynamically autoconfigures itself based on the drivers needed.

Autoconfiguration makes memory usage more efficient, because drivers are loaded only when they are needed. This eliminates "memory hogging" that happens in other operating systems requiring the driver to load and stay perma+++nently loaded in memory. These types of programs are called Terminate and Stay Residents (TSRs). Also, because the kernel is configured dynamically, it's reconfigured automatically-there is no need to reboot the system to rebuild the kernel when loading and unloading device drivers for testing purposes.

Multiple files compose the kernel. The platform-generic portion of the kernel is a file called /kernel/genunix. The platform-specific kernel portion is /platform/`uname -m`/kernel/unix. By modifying the /etc/system file, you can tailor the way in which you want kernel modules to load.

Solaris comes bundled with many device drivers and natively supports a wide array of hardware products. The pre-installed drivers are located in the /kernel/drv and /platform /`uname -m`/kernel/drv directories.

Note

The `uname -m` variable used in this chapter refers to the output that your machine produces when you use the uname -m command. For example, the Sun Blade 100 (part of the sun4u family) would have a platform-specific kernel module of /platform/sun4u/kernel/unix.

If you purchase a device that does not have a driver built into Solaris, you will need to obtain a driver from the device manufacturer. Solaris drivers come in two parts: the driver itself and its associated .conf (configuration) file. Drivers and configuration files should be placed in the /drv directories mentioned previously.

Listing Devices

Solaris has three commands to display system and device configuration information: prtconf, sysdef, and dmesg.

prtconf displays system configuration information. This includes the hardware platform, memory, and device configuration. The output of prtconf will vary widely, based on the devices installed in your computer. Here is a sample portion of a prtconf output:

 # prtconf System Configuration: Sun Microsystems sun4u Memory size: 256 Megabytes System Peripherals (Software Nodes): SUNW,Sun-Blade-100     packages (driver not attached)         SUNW,builtin-drivers (driver not attached)         deblocker (driver not attached)         disk-label (driver not attached)         terminal-emulator (driver not attached)         obp-tftp (driver not attached)         dropins (driver not attached)         kbd-translator (driver not attached)         ufs-file-system (driver not attached)     openprom (driver not attached)         client-services (driver not attached)     pci, instance #0         ebus, instance #1             flashprom (driver not attached)             eeprom (driver not attached)             idprom (driver not attached)         isa, instance #0             dma, instance #0                 floppy, instance #0                 parallel, instance #0             power, instance #0             serial, instance #0             serial, instance #1         network, instance #0         usb, instance #0             mouse, instance #0             keyboard, instance #1         ide, instance #0             disk (driver not attached)             cdrom (driver not attached)             dad, instance #0             sd, instance #0         SUNW,m64B, instance #0         pci, instance #0     SUNW,UltraSPARC-IIe, instance #0 #

Devices are listed in a hierarchical structure, just as the system sees them. All devices that have drivers installed are listed with their instance number. The first instance of each device type will be instance #0. If there are multiple types of the same device, such as serial ports, the second device will be instance #1.

One message you see a lot of in this output is (driver not attached). This could mean a few things. One possibility is that the device does not have a driver installed. More likely, though, is that the device is simply not being used at the moment. The computer producing this output has a CD-ROM, but the output says the driver is not attached. The CD-ROM does work, and if accessed, the driver will be automatically loaded.

sysdef lists device configuration information, including recognized system hardware, pseudo devices, loadable modules, and some kernel tunable parameters. Here is a portion from a sysdef output:

 # sysdef * * Hostid   83150d18 * sun4u Configuration * Devices * pci, instance #0         network, instance #0         ide, instance #0                 disk (driver not attached)                 cdrom (driver not attached)                 dad, instance #0                 sd, instance #0 pseudo, instance #0         clone, instance #0 * * Loadable Objects * * Loadable Object Path = /platform/sun4u/kernel * genunix unix drv/dma drv/power drv/cpc         hard link:  sys/cpc drv/sparcv9/su * * System Configuration *   swap files swapfile             dev  swaplo blocks   free /dev/dsk/c0t0d0s1   136,1      16 1049312 926880 * * Tunable Parameters *  2449408        maximum memory allowed in buffer cache (bufhwm)     1866        maximum number of processes (v.v_proc)       99        maximum global priority in sys class (MAXCLSYSPRI)     1861        maximum processes per user id (v.v_maxup)       30        auto update time limit in seconds (NAUTOUP) * * IPC Shared Memory *    8388608      max shared memory segment size (SHMMAX)    100  shared memory identifiers (SHMMNI) * * Time Sharing Scheduler Tunables * 60      maximum time sharing user priority (TSMAXUPRI) SYS     system class name (SYS_NAME) #

In all, sysdef can easily produce more than 20 pages of output. To make the information useful, you might want to consider using sysdef | more.

The last display command is dmesg, which presents system diagnostic messages and a list of devices attached to the system since the last boot. Here is a small sample from a dmesg output:

 # dmesg Tue Aug 20 18:16:42 MDT 2002 Aug 20 17:15:36 Q-Sol genunix: [ID 172905 kern.notice] Copyright \ 1983-2002     Sun Microsystems, Inc.  All rights reserved. Aug 20 17:15:36 Q-Sol Use is subject to license terms. Aug 20 17:15:36 Q-Sol genunix: [ID 678236 kern.info] \ Ethernet address =    0:3:ba:15:d:18 Aug 20 17:15:47 Q-Sol genunix: [ID 936769 kern.info] uata0 is /pci@1f,0/ide@d Aug 20 17:15:48 Q-Sol swapgeneric: [ID 308332 kern.info] root on \ /pci@1f,    0/ide@d/disk@0,0:a fstype ufs Aug 20 17:15:49 Q-Sol usba: [ID 855233 kern.info] USB-device: keyboard@4,    \ hid1 at bus address 3 Aug 20 17:15:50 Q-Sol unix: [ID 882636 kern.warning] WARNING:    \ interrupt level 15 not serviced Aug 20 17:17:06 Q-Sol pseudo: [ID 129642 kern.info] pseudo-device: lockstat0 Aug 20 17:17:07 Q-Sol pcipsy: [ID 370704 kern.info] PCI-device: pci@5, pci_pci0 #

dmesg shows the date and time of the message, the computer and module generating the message, and then the message or warning itself. Like sysdef, dmesg can produce dozens of pages of output.

Adding Devices

Most standard PC devices are compatible with Solaris. Generally speaking, if the device is SCSI, IDE, PCI, or USB, it will work with Solaris. The biggest question is, does the device come with a Solaris device driver? Adding a device to Solaris is accomplished with the following steps:

Log in as root, or assume the superuser or equivalent role.
Prepare Solaris for a reconfiguration boot by creating a /reconfigure file.
```
 # touch /reconfigure 
```
Shut down the computer.
Install the new device into the computer. If the device requires parameter configuration, ensure that the device will not conflict with previously installed components. For example, if you are adding a SCSI device, make sure that the SCSI ID of this device is different from the ID of other devices.
Power on the computer.
After logging in, attempt to access the new device.

If you are unable to access the device, you might need to install the device driver. To install the driver, place the installation media (usually a floppy disk or CD-ROM) into the appropriate drive and use the pkgadd command. For more information on pkgadd, see Chapter 2, "Installation."

If after installing the driver, the device still does not work, it's time to troubleshoot. Check and double-check all your physical connections. It might even help to reseat the device (unplug it and plug it back in). Reinstall the driver. If none of these steps help, try the device in another computer if possible. If it still does not work, you might have a defective product.

Reconfiguring Devices

Solaris 9 supports the dynamic reconfiguration of devices. If the device and device adapter support hot plugging, you can add or remove devices without rebooting Solaris. If the peripherals that you are configuring do not support hot plugging, you will need to reboot Solaris in order to reconfigure the devices.

Hot plugging is the ability to add or remove components while the system is running. When hot-plugged components are added or removed, Solaris reconfigures the system in a process known as dynamic reconfiguration. With the cfgadm command, you can hot plug and dynamically reconfigure USB and SCSI devices on all Solaris 9 platforms, and PCI devices on Intel platforms.

The cfgadm command not only enables you to add or remove devices while the system is running, but it walks you through the steps required to properly add or remove the device. This command enables you to display and change system component configurations, test devices, and display configuration help messages.

Note

Whereas nearly all USB devices support hot plugging, some SCSI and PCI controllers do not. To see whether your SCSI or PCI adapter supports hot plugging under Solaris 9, check with your hardware vendor or look up your device in the Solaris 9 Hardware Compatibility List.

Running the cfgadm command displays information about attachment points. Attachment points are locations within the system where dynamic reconfiguration can occur. All attachment points have two parts. The first is the receptacle, which is the location in the system that can accept the device. The second is the occupant, which is the device that can be configured. Although it might go without saying, the occupant gets plugged into the receptacle.

With no arguments, the cfgadm command displays the current status of hot-pluggable devices in the system:

 # cfgadm Ap_Id        Type        Receptacle  Occupant          Condition c0           scsi-bus    connected   configured        unknown usb0/1       unknown     empty       unconfigured      ok usb0/2       usb-mouse   connected   configured        ok usb0/3       unknown     empty       unconfigured      ok usb0/4       usb-kbd     connected   configured        ok #

The Ap_Id represents the attachment point ID. Attachment point IDs can be represented by either their physical or logical name. The physical Ap_Id is the physical name of the attachment point, and the logical Ap_Id is a user-friendly name for the physical point. By default, the logical Ap_Id is displayed by cfgadm.

Receptacles can be in one of three states: connected, disconnected, or empty. Connected means the receptacle has an occupant, and the occupant is available for system access. A disconnected state means that the receptacle has an occupant but has isolated the occupant from normal system operations. This is useful for testing and configuration purposes. Empty implies that the receptacle does not have any occupants.

Occupants can be listed as either configured or unconfigured. Configured means that the device is operational. Unconfigured means that the device cannot be accessed for use but can be accessed for configuration purposes.

The Ap_Id can be in one of five conditions: unknown, ok, failing, failed, or unusable. The condition is calculated dynamically. If a working device experiences a critical failure, its condition might go from ok to failing or failed. Devices that are failing, failed, or unusable cannot be used by the system.

Note

The detailed procedures for configuring hot-pluggable USB, SCSI, and PCI adapters are beyond the scope of this book. For more information, please see the System Administration Guide: Basic Administration, from Sun Microsystems.

Accessing Devices

Devices in Solaris 9 can be accessed in most cases by either their physical device name or their logical device name. The physical and logical device names are represented in the system by physical and logical device files.

The devfsadm command manages the device files, located in the /devices and /dev directories. The device files representing the physical devices are located in /devices, and the logical device files are located in /dev. By default, devfsadm attempts to load every driver in the system during boot. If there are no devices for the driver, the driver is ignored.

Not only does devfsadm manage the /devices and /dev directories, it also maintains the /etc/path_to_inst file. This file keeps track of mappings of physical device names to instance numbers. The instance number helps device drivers determine which device they are to manage if they are capable of handling multiple devices. Generally, you won't need to update this file. It's read only during system boot and is updated automatically.

devfsadmd, the daemon version of devfsadm, manages the dynamic updating of the /devices and /dev directories. This daemon is started automatically during the boot process by run control (rc) scripts, so no manual intervention is needed.

Device Naming

The Solaris operating system accesses devices based on their naming structure. Programs can refer to devices by their physical device name, logical device name, or instance name.

The physical device name represents the device's full pathname in the system device hierarchy. Although this name is essentially guaranteed to identify the right device, it's cumbersome to use. Physical device names are stored in the /devices directory.

Most file system commands use logical device names. This is because multiple file systems can be on one physical device (a hard disk), and referring to the disk as a whole would not properly recognize the logical divisions. Logical device names are stored in the /dev directory and are symbolically linked to files in the /devices directory.

Instance names are essentially abbreviations for devices, as designated by the kernel. These names are stored in the /etc/path_to_inst file.

The key to using device management utilities is to understand which naming convention the application is looking for. For example, the newfs command, used to create file systems, wants to see a logical name. To find out which format the command you are using requires, view the man page for your command.

Logical Disk Naming

Whereas a physical name can refer to the specific hard disk, a logical name is required to isolate divisions, or slices, within the disk. Although different commands require different interface names, the two standards used are raw device interfaces and block device interfaces. The only real difference between the two is how information is read from the devices. Raw devices can transfer only small amounts of data at a time, whereas block devices can use a buffer and therefore transfer more information at once. Generally speaking, larger disk transfers increase the efficiency of the disk.

For commands that require the raw disk interface, device names in the /dev/rdsk directory are used. Block device names are stored in the /dev/dsk directory. Accessing disks based on raw and block device names is covered in more depth in Chapter 7, "File System Management."