This chapter is from the book
This chapter is from the book
This chapter is from the book
Physical Device Name
Before the OS is loaded, the system locates a particular device through the device tree, also called the full device pathname. Full device pathnames are described in the “PROM Device Tree (Full Device Pathnames)” section of Chapter 3, “Boot and Shutdown Procedures for SPARC and x86-Based Systems.” After the kernel is loaded, however, a device is located by its physical device pathname. Physical device names represent the full device pathname for a device. Note that the two names have the same structure. For example, the full device pathname for a SCSI disk at target 0 on a SunFire T2000 system is as follows:
/pci@780/pci@0/pci@9/scsi@0/disk@0
Intel-based systems commonly use IDE or Serial AT Attachment (SATA) disk drives. On the x86 platform, the SATA disk (target 0) looks like this:
/pci@0,0/pci8086,2829@d/disk@0,0
Now let’s look at the corresponding physical device name from the OS level. Use the dmesg command, described later in this section, to obtain information about devices connected to your system. By viewing information displayed by the dmesg command, you’ll receive the following information about the SunFire T2000’s SAS disk 0:
# dmesg |grep scsi<cr> Jan 23 16:02:42 server rootnex: [ID 349649 kern.info] scsi_vhci0 at root Jan 23 16:02:42 server genunix: [ID 936769 kern.info] scsi_vhci0 is /scsi_vhci Jan 23 16:02:45 server scsi: [ID 583861 kern.info] sd0 at ahci0: target 0 lun 0 Jan 23 16:02:45 server scsi: [ID 583861 kern.info] sd1 at ahci0: target 1 lun 0 Jan 23 16:03:04 server rootnex: [ID 349649 kern.info] iscsi0 at root Jan 23 16:03:04 server genunix: [ID 936769 kern.info] iscsi0 is /iscsi
This same information is also available in the /var/adm/messages file.
As you can see, the physical device name listed above and the full device name seen at the OpenBoot PROM are the same. The difference is that the full device pathname is simply a path to a particular device. The physical device is the actual driver used by Oracle Solaris to access that device from the OS.
Physical device files are found in the /devices directory. The content of the /devices directory is controlled by the devfs file system. The entries in the /devices directory dynamically represent the current state of accessible devices in the kernel and require no administration. New device entries are added when the devices are detected and added to the kernel. The physical device files for SAS disks 0 and 1 connected to the primary SCSI controller would be
/devices/pci@780/pci@0/pci@9/scsi@0/sd@0,0:<#> /devices/pci@780/pci@0/pci@9/scsi@0/sd@1,0:<#>
for the block device and
/devices/pci@780/pci@0/pci@9/scsi@0/sd@0,0:<#>,raw /devices/pci@780/pci@0/pci@9/scsi@0/sd@1,0:<#>,raw
for the character (raw) device, where <#> is a letter representing the disk slice. Block and character devices are described later in this chapter in the section titled “Block and Raw Devices.”
The system commands used to provide information about physical devices are described in Table 4-1.
Table 4-1 Device Information Commands
Command |
Description |
prtconf |
The prtconf command displays system configuration information, including the total amount of memory and the device configuration, as described by the system’s hierarchy. This useful tool verifies whether a device has been seen by the system. |
sysdef |
The sysdef command displays device configuration information, including system hardware, pseudo devices, loadable modules, and selected kernel parameters. |
dmesg |
The dmesg command displays system diagnostic messages as well as a list of devices attached to the system since the most recent restart. |
format |
The format command displays both physical and logical device names for all available disks. |
Type the prtconf command:
# prtconf<cr>
System Configuration: Oracle Corporation sun4v
Memory size: 3968 Megabytes
System Peripherals (Software Nodes):
SUNW,Sun-Fire-T200
scsi_vhci, instance #0
packages (driver not attached)
SUNW,builtin-drivers (driver not attached)
deblocker (driver not attached)
disk-label (driver not attached)
<Output has been truncated.>
Use the -v option to display detailed information about devices.
The sysdef command can also be used to list information about hardware devices, pseudo devices, system devices, loadable modules, and selected kernel tunable parameters as follows:
# sysdef<cr>
*
* Hostid
*
8510e818
*
* sun4v Configuration
*
*
* Devices
*
scsi_vhci, instance #0
packages (driver not attached)
SUNW,builtin-drivers (driver not attached)
deblocker (driver not attached)
disk-label (driver not attached)
terminal-emulator (driver not attached)
dropins (driver not attached)
SUNW,asr (driver not attached)
kbd-translator (driver not attached)
obp-tftp (driver not attached)
zfs-file-system (driver not attached)
*Output has been truncated.
* System Configuration
*
swap files
swapfile dev swaplo blocks free
/dev/zvol/dsk/rpool/swap 228,2 16 2097136 2097136
*
* Tunable Parameters
*
81469440 maximum memory allowed in buffer cache (bufhwm)
30000 maximum number of processes (v.v_proc)
99 maximum global priority in sys class (MAXCLSYSPRI)
29995 maximum processes per user id (v.v_maxup)
30 auto update time limit in seconds (NAUTOUP)
25 page stealing low water mark (GPGSLO)
1 fsflush run rate (FSFLUSHR)
25 minimum resident memory for avoiding deadlock (MINARMEM)
*Output has been truncated
Use the output of the prtconf command to identify which disk, tape, and CD/DVD-ROM devices are connected to the system. As shown in the preceding prtconf and sysdef examples, some devices display the driver not attached message next to the device instance. 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. The OS automatically loads drivers when the device is accessed, and it unloads them when it is not in use.
The system determines which devices are attached to it at startup. This is why it is important to have all peripheral devices powered on at startup, even if they are not currently being used. During startup, the kernel configures itself dynamically, loading needed modules into memory. 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 if needed. As described in Chapter 3, the system administrator can customize the way in which kernel modules are loaded by modifying the /etc/system file.