Docstoc

Filesystem Device Nodes

Document Sample
Filesystem Device Nodes Powered By Docstoc
					Notes


Table of Contents
Hardware Overview .............................................................................................. 2
  Device Drivers ............................................................................................... 2
  The Static Kernel Image ...................................................................................... 2
  Kernel Modules ............................................................................................... 3
  The Red Hat Supported Hardware Database ...................................................................... 4
  Sources of Hardware Information .............................................................................. 4
     Kernel Messages, the dmesg Buffer, and /var/log/dmesg ...................................................... 4
     The kudzu Utility.......................................................................................... 5
     The Hardware Abstraction Layer: hald and lshal ............................................................. 6
     The /proc Filesystem....................................................................................... 7
     The GNOME Hardware Browser ................................................................................. 7
  Processor Support ............................................................................................ 8
  Symmetric Multiprocessing (SMP) .............................................................................. 8
     /proc/cpuinfo ............................................................................................. 8
  Memory ....................................................................................................... 9
     /proc/meminfo ............................................................................................. 9
  Harddisks ................................................................................................... 10
     IDE disks and /proc/ide ................................................................................... 10
     SCSI disks ............................................................................................... 11
     SATA drives .............................................................................................. 11
  Examples: Becoming Familiar with a New Machine .............................................................. 12
PCI Devices ................................................................................................... 13
  The PCI bus ................................................................................................. 13
  Hardware Resources .......................................................................................... 14
     Interrupt Request Line (IRQ's) and /proc/interrupts ....................................................... 14
     I/O Ports and /proc/ioports ............................................................................... 14
     Device Memory Buffers and /proc/iomem ..................................................................... 15
  Configuring PCI Devices ..................................................................................... 15
  Loading Modular Device Drivers .............................................................................. 16
  Assigning Resources ......................................................................................... 16
  Examples: Exploring a New Machine ........................................................................... 17
Filesystem Device Nodes........................................................................................ 18
  "Everything is a File" ...................................................................................... 18
  Filesystem Device Nodes ..................................................................................... 18
  Why Two Types of Nodes? ..................................................................................... 19
  The Anatomy of a Device Node ................................................................................ 19
  Managing Device Nodes: mknod ................................................................................ 21
  Commonly Used Device Nodes .................................................................................. 21
  Symbolic Links as Functional Names .......................................................................... 22
  Dynamic Device Node Creation: udev .......................................................................... 23
  Examples Using the dd Command to Create a backup of a Drive's Master Boot Record ............................. 23
Performance Monitoring......................................................................................... 24
  Performance Monitoring ...................................................................................... 24
  CPU Performance ............................................................................................. 24
     The uptime Command........................................................................................ 24
     The top Command........................................................................................... 25
     Memory Utilization........................................................................................ 26
     Process Memory............................................................................................ 26
     Disk I/O Cache............................................................................................ 26
  Monitoring Memory Utilization with /proc/meminfo ............................................................ 27
  Monitoring Memory Utilization with top ...................................................................... 27
  Why is My Memory Always 90% Full? ........................................................................... 27
  Examples Using top to Analyze System Activity ............................................................... 27
Hardware Overview

Key Concepts

      Device drivers can either be compiled into the static kernel image, or implemented as a kernel
       module. Device drivers implemented as kernel modules can be configured in the
       /etc/modprobe.conf configuration file.
      Red Hat maintains a database of supported hardware, accessible at
       http://bugzilla.redhat.com/hwcert.
      Kernel messages are stored in a dynamic buffer referred to as the dmesg buffer. The contents of
       the dmesg buffer can be examined with the dmesg command.
      The file /var/log/dmesg contains a snapshot of the dmesg buffer taken soon after the most
       recent boot.
      The file /proc/cpuinfo reports information about the system's processors.
      The file /proc/meminfo reports information about the system's memory.
      The directory /proc/ide/ reports information about the system's IDE drives.

Device Drivers

One of the primary roles of the Linux kernel is to provide access to the machine's hardware. Some
hardware components, such as the CPU or memory, are so fundamental that their management is part of
the core functionality of the kernel. Other hardware, such as network interface cards, USB devices, and
disks, use more specialized components of the kernel referred to as device drivers. Many device drivers
are configurable, usually by passing parameters to the device driver as it is loaded.

One of the reasons for the popularity of the Linux kernel is its modular design. Device drivers may be
implemented in either of two ways: as part of the static kernel image, or as a kernel module. How a
device driver is implemented dictates how its configuration parameters (if any) are specified.

The Static Kernel Image

The static kernel image is the file that is loaded when your system is booted. In Red Hat Enterprise
Linux, the image file conventionally lives in the /boot directory, with the name vmlinuz-version,
where version is replaced with the kernel's version number.

Device drivers which are used during the boot process, before filesystems are available, such as IDE
device drivers and console drivers, are usually implemented in the core kernel image. Because these
device drives are loaded as part of the kernel image itself, the only way to pass parameters to them is at
boottime. Most Linux bootloaders, such as GRUB and LILO, allow users to pass parameters to the
kernel as it is booted, through the kernel command line. Here, we only introduce the concept of the
kernel command line. Later in the course, we discuss how it is configured.

When read, the file /proc/cmdline reports the command line that was used to boot the current instance
of the kernel.

[root@station root]# cat /proc/cmdline
ro root=LABEL=/ vga=0x317


Documentation for some of the more commonly used kernel boottime parameters can be found in the
bootparam(7) man page.
Kernel Modules

Supplementary device drivers (which are not needed during the initial stages of system booting), such as
network interface drivers and sound card drivers, are usually implemented as kernel modules. Kernel
modules exist as files in the filesystem, usually underneath the directory /lib/modules/version,
where again, version is replaced with the relevant kernel version. Linux kernel modules are loaded "on
demand": as the kernel first tries to access a particular device, the device driver for that device is loaded
from the filesystem. If the device corresponding to a particular device driver module is not present (or
not used), that kernel module is never loaded.

The lsmod command will generate a list of currently loaded kernel modules, or, equivalently, the file
/proc/modules may be examined.

[root@station root]# lsmod
Module                  Size   Used by
autofs4                23749   2
hidp                   23105   2
rfcomm                 42457   0
l2cap                  29505   10 hidp,rfcomm
bluetooth              53925   5 hidp,rfcomm,l2cap
...


Parameters may be passed to modular device drivers as they are loaded. Whenever a module is loaded
"on demand" by the kernel, the file /etc/modprobe.conf is examined for module parameters. For
example, the sb kernel module, which implements the device driver for SoundBlaster compatible
soundcards, can be configured to expect a particular type of soundcard by passing a parameter of the
form type=N, where N is replaced with some integer. If the appropriate line is added to the file
/etc/modprobe.conf, this parameter will be set whenever the kernel loads the sb module.

[root@station root]# cat /etc/modprobe.conf
options sb type=3 
alias eth0 e100
alias eth1 airo
alias snd-card-0 snd-intel8x0
install snd-intel8x0 /sbin/modprobe --ignore-install snd-intel8x0 && /usr/sbin/alsactl
restore >/dev/null 2>&1
remove snd-intel8x0 { /usr/sbin/alsactl store >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-
remove snd-intel8x0
alias usb-controller uhci-hcd
  This line specifies parameters to be used whenever the sb kernel module is implicitly loaded.

 No Need to "Install" Device Driversdevices is not an issue in Linux as in other operating
  Installing device drivers for particular
       systems. Because of the modular nature of the kernel and the freedoms provided by open source
       software, modules for most supported hardware are included by default. A device driver
       implemented as a kernel module is only loaded if the hardware it manages is detected, so the only
       wasted resource is a little bit of disk space.

While not discussing the specifics of any particular device driver, this discussion has tried to introduce
the following concepts.

       Device drivers in Linux can be implemented either statically or as a module.
       Static device drivers are configured at boottime through the kernel command line.
       Modular device drivers are configured primarily through the /etc/modprobe.conf file at load
        time.
More about configuring the kernel command line, managing kernel modules in general, and the role of
the /etc/modprobe.conf file will be covered later in the course.

The Red Hat Supported Hardware Database

The advantages and disadvantages of the open source development model are particularly relevant to
hardware support. The disadvantage: because the open source community often does not have
relationships with hardware vendors, and is not privy to pre-release information (or sometimes any
information), the most recent version of a a given video card, sound card, or some other device is often
not supported. (The emergence of Linux distributors, such as Red Hat, is changing this trend.) The
advantage: eventually, someone in the open source community will want to take advantage of the
features of the new device, and there is a greater chance that it will eventually be supported.

Because of these competing influences, keeping track of which hardware is supported and which is not
can be an issue. Red Hat maintains a database of supported hardware at https://hardware.redhat.com/.
The searchable database helps identify hardware that is well supported by the Red Hat distribution (and
Red Hat technical support services), and hardware that is known to work, but not officially supported by
Red Hat.

Sources of Hardware Information

The following resources can be used to help determine which hardware is installed (and recognized by
the kernel) on your system.

Kernel Messages, the dmesg Buffer, and /var/log/dmesg

The first evidence of detected hardware is the stream of messages emitted by kernel as the system boots,
which quickly flow off of the top of the screen, apparently never to be seen again. These messages, and
all messages emitted by the kernel, are stored in a dynamic kernel buffer referred to as the dmesg buffer.
The dmesg buffer is a "ring buffer". Once the buffer's space has been consumed with messages, it will
begin overwriting the oldest messages with newer ones.

The current contents of the dmesg buffer can be dumped to standard out with the dmesg command.
Soon after the most recent boot, the buffer begins with the same messages seen at boottime.

[root@station root]# dmesg
Linux version 2.6.18-8.el5 (brewbuilder@ls20-bc2-14.build.redhat.com) (gcc version 4.1.1 20070105 (Red
Hat 4.1.1-52)) #1 SMP Fri Jan 26 14:42:21 EST 2007
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000ca000 - 00000000000cc000 (reserved)
 BIOS-e820: 00000000000dc000 - 00000000000e0000 (reserved)
 BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
...


If a machine has been running for a while, however, the buffer will be consumed by intermittent kernel
messages, and this information will be lost. During the default Red Hat Enterprise Linux startup process,
however, a snapshot of the dmesg buffer is recorded in the file /var/log/dmesg. This file is overwritten
with each boot, so its contents will reflect the most recent startup.
The kudzu Utility

The kudzu utility is a bootup utility that detects newly added or removed hardware, and configures the
machine appropriately. While kudzu does not directly report detected hardware, examining its
infrastructure helps understand how hardware configuration occurs in the Red Hat Enterprise Linux
system.

We start by examining a directory that will become familiar as the course progresses, the
/etc/sysconfig directory. In Red Hat Enterprise Linux, this directory serves as a general repository for
hardware and software configuration information.

[root@station root]# ls /etc/sysconfig/
apmd         dund              kdump          rha-unittest
apm-scripts firstboot          kernel         rha-unittest.rpmsave
auditd       grub              keyboard       rhn
authconfig   hidd              kudzu          samba
autofs       httpd             mkinitrd       saslauthd
bluetooth    hwconf           modules        selinux
cbq          i18n              network        sendmail
clock        init              networking     smartmontools
conman       ip6tables-config network-scripts syslog
console      ipmi              ntpd           system-config-securitylevel
cpuspeed     iptables-config   pand           system-config-users
crond        irda              prelink        vncservers
desktop      irqbalance        readonly-root  wpa_supplicant

  The hwconf file is a text database file of currently detected hardware maintained by kudzu.
  The kudzu file is used to configure how aggressively kudzu probes for newly detected hardware.

You might think that this discussion will focus on the /etc/sysconfig/kudzu configuration file.
Actually, this file is relatively uninteresting. When kudzu performs its probe, it might throw trash to
serial lines, and other minor glitches. If this might be a concern, kudzu can be put into a "safe" mode by
editing the last line, setting SAFE=yes.

[root@station root]# cat /etc/sysconfig/kudzu
# Set to anything other than 'no' to force a 'safe' probe on startup.
# 'safe' probe disables:
# - serial port probing
# - DDC monitor probing
# - PS/2 probing
SAFE=no


Instead, our discussion will focus on databases used by kudzu. The first, /etc/sysconfig/hwconf is a
dynamic database of currently detected hardware. Skimming this file can give an overview of a current
machine's hardware.

[root@station root]# head /etc/sysconfig/hwconf
-
class: OTHER
bus: PCI
detached: 0
driver: agpgart
desc: "Intel Corp.|440BX/ZX/DX - 82443BX/ZX/DX Host bridge"
vendorId: 8086
deviceId: 7190
subVendorId: 0000
subDeviceId: 0000
[root@station root]# grep desc /etc/sysconfig/hwconf
desc: "Intel Corp.|440BX/ZX/DX - 82443BX/ZX/DX Host bridge"
desc: "Intel Corp.|440BX/ZX/DX - 82443BX/ZX/DX AGP bridge"
desc: "Intel Corp.|82371AB/EB/MB PIIX4 ISA"
desc: "Intel Corp.|82371AB/EB/MB PIIX4 IDE"
desc: "Intel Corp.|82371AB/EB/MB PIIX4 ACPI"
desc: "USB UHCI Root Hub"
desc:   "3Com Corporation|3c556 Hurricane CardBus"
desc:   "Generic Mouse (PS/2)"
desc:   "ESS Technology|ES1983S Maestro-3i PCI Audio Accelerator"
desc:   "3Com Corporation|Mini PCI 56k Winmodem"
desc:   "ATI|Rage Mobility M3 AGP 2x"
desc:   "3.5" 1.44MB floppy drive"
desc:   "IBM-DJSA-210"
desc:   "Intel Corp.|82371AB/EB/MB PIIX4 USB"
desc:   "Texas Instruments|PCI1420"
desc:   "Texas Instruments|PCI1420"


The remaining databases are found in the /usr/share/hwdata directory. This directory stores text
catalogs of hardware which the Red Hat Enterprise Linux system expects to encounter. For example, the
file /usr/share/hwdata/pcitable tables PCI devices by vendor ID and device ID. When a particular
PCI device is detected, this file is used to associate a text name to the device, and possibly a relevant
kernel module to serve as the device's device driver.

[root@station root]# ls /usr/share/hwdata/
MonitorsDB pci.ids upgradelist usb.ids videoaliases       videodrivers


These text database files can give insight into the types of hardware Red Hat Enterprise Linux expects to
encounter.

The Hardware Abstraction Layer: hald and lshal

While much of traditional Unix design has withstood the test of time, traditional Unix, and early
versions of Linux, did not anticipate "hot attached" devices. Hot attached devices are devices, such as
USB thumb drives, which are not present as the system boots, but instead are connected once the system
is already up and running. In this case, a start up service such as kudzu is of little help.

Much work has gone into recent (2.6) versions of the Linux kernel to better accomodate hot attached
devies, and the hald ("Hardware Abastraction Layer Daemon") utilizes these enhancements. In Red Hat
Enterprise Linux 5, much of the work of kudzu is being transferred to hald.

While the design of the hardware abstraction layer is beyond our scope, one can view a list of devices
currently manged by hald using the lshal command.

[root@station ~]# lshal

Dumping 110 device(s) from the Global Device List:
-------------------------------------------------
udi = '/org/freedesktop/Hal/devices/computer'
  info.addons = {'hald-addon-cpufreq', 'hald-addon-acpi'} (string list)
  info.bus = 'unknown' (string)
  info.callouts.add = {'hal-acl-tool --remove-all', 'hal-storage-cleanup-all-mountpoints'} (string list)
  info.callouts.session_active = {'hal-acl-tool --reconfigure'} (string list)
  info.callouts.session_add = {'hal-acl-tool --reconfigure'} (string list)
...


By default, lshal dumps a comprehensive and initimidating amount of information.

The lshal command can also be used to monitor hardware changed dynamically, by adding a -m
command line switch. The following output reflects a USB mouse being attached to the system,
followed by a power management notification from a laptop battery.

[root@station ~]$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
12:00:40.899: usb_device_46d_c404_noserial added
12:00:41.031:   usb_device_46d_c404_noserial_if0 added
12:00:41.057:   usb_device_46d_c404_noserial_usbraw added
12:00:41.178:   usb_device_46d_c404_noserial_if0_logicaldev_input added
12:01:48.705:   acpi_BAT0 property battery.charge_level.current = 69460 (0x10f54)
12:01:48.707:   acpi_BAT0 property battery.voltage.current = 12362 (0x304a)
12:01:48.709:   acpi_BAT0 property battery.reporting.current = 69460 (0x10f54)


The /proc Filesystem

Another invaluable resource for determining hardware configuration is the proc filesystem. The proc
filesystem is a virtual filesystem which is implemented by the Linux kernel, invariably mounted to the
/proc directory.

[root@station hwdata]# mount
/dev/hda3 on / type ext3 (rw)
proc on /proc type proc (rw) 
usbdevfs on /proc/bus/usb type usbdevfs (rw)
/dev/hda1 on /boot type ext3 (rw)
...

     The proc virtual filesystem, associated with the device “proc”, is mounted to the /proc mount
 
     point.

What is meant by a virtual filesystem? All of the files underneath /proc do not exist on any physical
media. They might be considered a figment of the kernel's imagination, albeit a useful figment. When a
file is read from, the kernel returns a dynamically generated response. (Some files within /proc, when
written to, can be used to change parameters within the kernel.) When the kernel no longer exists, such
as when the machine is shut down, the files in the proc filesystem no longer exist either, in any form.

In our discussion of various hardware, we will appeal to files within the /proc filesystem many times.
Later in the course, we focus on using the /proc filesystem as a mechanism for configuring kernel
parameters. In the meantime, the proc(5) man page, the cat command, and some time spent in
exploration can serve as an introduction.

The GNOME Hardware Browser

Lastly, we mention the GNOME Hardware Browser, which can be started by choosing System
Tools:Hardware Browser from the main system menu, or running hwbrowser from the command line.
This graphical application collects much of the relevant information that can be found in the various
other sources mentioned above into a single, simple utility.

Figure 1. The GNOME Hardware Browser
Processor Support

In addition to the Intel x86 (and compatible) family of processors, the Red Hat Enterprise Linux
distribution supports the IA-64 (Intel 64 bit processors), Compaq Alpha and IBM iSerires, eSeries, and
S/390 architectures. This course, and the RHCT and RHCE certifications, cover only the x86 compatible
version of the distribution.

Symmetric Multiprocessing (SMP)

Linux supports symmetric multiple processing, with support for up to 32 CPU's, though more than 8 is
seldom implemented in the x86 architecture. Multiprocessor granularity occurs naturally at the process
level (i.e., with two CPU's, a single process will not run twice as fast, but two processes can run
concurrently, each on a separate CPU). With targeted development, Linux also supports multi-threaded
processes, where a single process can spawn multiple threads of execution, which can then run
concurrently on multiple CPU's.

/proc/cpuinfo

The proc filesystem file /proc/cpuinfo reports information about detected CPU(s), as seen in the
following example.

[root@station root]# cat /proc/cpuinfo
processor    : 0
vendor_id       : GenuineIntel
cpu family      : 6
model        : 8
model name      : Pentium III (Coppermine)
stepping        : 6
cpu MHz      : 548.323
cache size  : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
pat pse36 mmx fxsr sse
bogomips        : 1094.45
The following fields tend to provide the most useful information.

         The processor number. On a single processor machine, this is 0. On an SMP machine, the cpuinfo
 
         file contains multiple stanzas, each identified by a distinct processor number.
        The CPU model.
        The speed of the CPU.
        The size of the CPU memory cache, which can significantly reduce memory access times.
         Various flags, which indicate capabilities of the CPU. For example, the tsc flag indicates that the
        CPU supports a time stamp counter (which can be used for precise timing information), while the
         pae flag specifies that the CPU can support physical addressing extensions (more on these, below).
         A misleading and often misused statistic that is used to correlate CPU cycles to real world time. It
        only merits mention because it is often inappropriately used as a measure of processor speed. Use
         the MHz parameter (above) instead.

Memory

Because the x86 family is a 32-bit architecture, one could reasonably expect the Linux kernel to support
4 GB of memory (where 2 raised to the 32nd power is equal to about 4 gigabytes). Unintuitively, there
are some Intel (and compatible) 32 bit processors that support "Physical Address Extensions" (PAE)
extensions, whereby a 32 bit processor can actually access up to 64 GB of memory (though not all at the
same time).

In order to accomodate large memory systems, the Red Hat distribution ships with multiple versions of
the kernel. The default kernel is configured to take advange of up to 4 GB of memory. The Red Hat
Enterprise Linux 5 distribution ships with a reconfigured kernel found in the kernel-PAE package. Once
this package is manually installed, the system can be rebooted and the PAE kernel can be chosen from
GRUB's boot menu.

/proc/meminfo

The proc filesystem file /proc/meminfo provides statistics about the amount of detected memory, and
current memory utilization, as seen in the following example.

[root@station root]# cat /proc/meminfo
MemTotal:       512172 kB
MemFree:         51996 kB
Buffers:         65064 kB
Cached:         322792 kB
...
SwapTotal:      530136 kB
SwapFree:       530136 kB
...


For now, our discussion is limited to the following fields.

         The first two fields report how much physical memory is present, and how much is freely
          available.
         The Buffers and Cached fields collectively report how much memory is currently devoted to the
          the I/O cache. On a healthy machine, the I/O cache can take up the majority of system memory.
          The I/O cache will be discussed in a later lesson.
         The SwapTotal and SwapFree fields report the amount of disk space available as a memory
          reserve ("swap space"), and how much of that reserve is available.
Many of the remaining statistics in this file report in more detail how the "used" memory is being
utilized. We will return to this topic in a later lesson.

Harddisks

Like processors and memory, the kernel is responsible for automatically detecting the presence of
harddisks. Harddisks generally use either the IDE or SCSI bus protocol, and Linux uses the following
naming convention for each.

IDE disks and /proc/ide

The IDE bus protocol allows computers to have multiple IDE controllers, each of which can manage
two disks (referred to as the "master" and the "slave" drives). Many common desktop computers ship
with two IDE controllers, referred to as the "primary" and "secondary" controllers. This configuration
allows four IDE drives to be connected, referred to as the "primary master", "primary slave", "secondary
master", and "secondary slave" drives. The role of a particular drive is determined entirely by how it is
physically cabled to the machine.

Linux refers to IDE drives as hdx, where x is replaced by a single lowercase letter. The letters are
mapped directly to the physical positions of the drive.

Table 1. IDE Harddisk Naming Conventions

Name         Position
hda    primary master
hdb    primary slave
hdc    secondary master
hdd    secondary slave
hde    tertiary master
...    ...

The proc filesystem directory /proc/ide contains subdirectories for every detected IDE drive, named
after the drive. (Actually, the files are symbolic links, which refer to subdirectories of directories called
ide0, ide1, etc. These directories refer to the primary ide controller, the secondary IDE controller,
etc...). A ls of the /proc/ide directory can quickly determine which IDE disks are recognized by the
kernel. In the following example, only a single drive (hda) is detected.

[root@station ide]# ls /proc/ide/
drivers hda ide0 piix


The subdirectory related to a particular disk contains files which provide various (often low level)
information about the disk. (In the following output, notice that the file named capacity is duplicated!
In a normal file system, this would not be allowed. In the proc filesystem, this is a kernel bug.)

[root@station ide]# ls /proc/ide/hda
cache     capacity geometry media settings                smart_values
capacity driver     identify model smart_thresholds
[root@station ide]# head /proc/ide/hda/*
==> /proc/ide/hda/cache <==
384
==> /proc/ide/hda/capacity <==
11733120

==> /proc/ide/hda/capacity <==
11733120

==> /proc/ide/hda/driver <==
ide-disk version 1.17

==> /proc/ide/hda/geometry <==
physical     12416/15/63
logical      730/255/63

==> /proc/ide/hda/identify <==
045a 3080 c837 000f 0000 0000 003f 0000
0000 0000 2020 2020 2020 2020 2034 3256
...

==> /proc/ide/hda/media <==
disk

==> /proc/ide/hda/model <==
IBM-DJSA-210

==> /proc/ide/hda/settings <==
name                         value            min                max                mode
----                         -----            ---                ---                ----
acoustic                0                 0           254              rw
address                 0                 0           2                rw
bios_cyl                730               0           65535            rw
bios_head               255               0           255              rw
bios_sect               63                0           63               rw
breada_readahead        8                 0           255              rw
bswap                   0                 0           1                r
current_speed           66                0           70               rw
...


SCSI disks

The Linux naming convention for SCSI disks is not as transparent as for IDE disks. Usually, Linux uses
names of the form sdx, where x is replaced with one or more lowercase letters. Unfortunately, the names
cannot be mapped directly to the physical position of the drive, or even to the drive's SCSI ID. Linux
usually refers to the first detected SCSI drive as sda, the second drive as sdb, and so on. Predicting
which of multiple connected drives Linux will consider the "first", "second", and so on, however, is
notoriously difficult. Even worse, if a new SCSI drive is added to the machine, a preexisting disk
referred to as sdb might (upon rebooting) become sdc, with the newly connected drive taking the name
sdb.

Although the proc filesystem provides a /proc/scsi directory, and in particular a file
/proc/scsi/scsi which lists all detected disks, neither provides simple information about the names of
currently recognized SCSI disks. The best approach is to watch for kernel messages (as reported by the
dmesg command, or in the file /var/log/dmesg) about detected SCSI disks.

SATA drives

Recently, drives which support the newer "Serial ATA" interface have become popular. Althought these
drives are technically IDE drives, recent Linux kernels, and Red Hat Enterprise Linux 5, uses a SCSI
emmulation to interface with the SATA controller. Therefore, in Red Hat Enterprise Linux 5, SATA
drives are reported as IDE drives.

As an example, the following output from /proc/scsi/scsi reports an "ATA" vendor for a locally
attached IDE SATA drive.
[root@station ~]$ cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: HTS541010G9SA00        Rev: MBZI
  Type:   Direct-Access                          ANSI SCSI revision: 05


Examples: Becoming Familiar with a New Machine

The user elvis has logged into his account on a new machine, and would like to find out more about its
hardware. First, he examines the machine's CPU.

[elvis@station elvis]$ cat /proc/cpuinfo
processor        :    0
vendor_id        :    GenuineIntel
cpu family       :    6
model            :    8
model name       :    Pentium III (Coppermine)
stepping         :    6
cpu MHz          :    697.867
cache size       :    256 KB
fdiv_bug         :    no
...


He notes that the processor is an Intel Pentium III 800 MHz processor, with a 256 kilobyte cache. He
next examines the machine's memory.

[elvis@station elvis]$ cat /proc/meminfo
MemTotal:        255232     kB
MemFree:          22100     kB
Buffers:          35400     kB
Cached:          102472     kB
SwapCached:       43080     kB


Observing the MemTotal: line, he determines that the machine has 256 megabytes of RAM. He next
checks to see which drives are connected, if they are hard disks or CD-ROMS, and their model.

[elvis@station elvis]$ ls /proc/ide/
drivers   hda   hdb   hdc   ide0   ide1   piix
[elvis@station elvis]$ head /proc/ide/hd*/media
==> /proc/ide/hda/media <==
disk

==> /proc/ide/hdb/media <==
disk

==> /proc/ide/hdc/media <==
cdrom

[elvis@station elvis]$ head /proc/ide/hd*/model
==> /proc/ide/hda/model <==
Maxtor 51536H2

==> /proc/ide/hdb/model <==
ST310212A

==> /proc/ide/hdc/model <==
LTN485
PCI Devices

Key Concepts

       The lspci command lists all detected PCI devices. Including the -v command line switch lists
        configuration information associated with each device.
       The file /proc/interrupts lists the system's interrupt request line (IRQ) assignments and
        activity.
       The file /proc/ioports lists the system's I/O port assignments.
       The file /proc/iomem lists the physical addresses of the system's RAM and device memory
        buffers.

The PCI bus

The PCI bus plays a primary role in most x86 compatible architectures. All PCI devices share a common
configuration protocol, whereby PCI devices can identify themselves with hardwired Vendor and
Device ID's. PCI devices include common expansion cards based devices, such as sound cards and
network controller, but also bridges which connect other buses to the primary PCI bus. The lspci
command can be used to list all attached PCI devices, as in the following example.

[root@station root]# lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT8375 [KM266/KL266] Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP]
00:05.0 Multimedia audio controller: Creative Labs SB Audigy (rev 03)
00:05.1 Input device controller: Creative Labs SB Audigy MIDI/Game port (rev 03)
00:05.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port
00:07.0 Ethernet controller: Linksys Network Everywhere Fast Ethernet 10/100 model NC100 (rev 11)
00:10.0 USB Controller: VIA Technologies, Inc. USB (rev 80)
00:10.1 USB Controller: VIA Technologies, Inc. USB (rev 80)
00:10.2 USB Controller: VIA Technologies, Inc. USB (rev 80)
00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
00:11.1IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master
IDE (rev 06)
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
01:00.0 VGA compatible controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266]


   This device connects the AGP ("Advanced Graphics Port"), used by many video cards, to the PCI
    bus.
   The Audigy soundcard on this machine is an example of a "multifunction" PCI device. This and the
    following three lines identify the single device filling the role of three individual devices: a
    soundcard, a MIDI/joystick controller, and a FireWire controller.
   These two devices are two individual network interface cards. (Although not evident from this
    output, one is supplied with the motherboard as an "on board" component, and the other is an
    expansion card.)
   These three PCI "devices" are examples of controllers for alternate buses: The USB bus, the ISA bus,
    and the IDE bus. The PCI bus provides the base infrastructure for other buses. Notice that IDE, ISA,
    and USB devices will not be listed by the lspci command, only the bus controllers.

The lspci command provides a good starting place when attempting to discover what hardware is
connected to an unfamiliar machine.
Hardware Resources

The x86 architecture provides common mechanisms for hardware devices to interact with the Linux
kernel. When adding new devices to a machine, care must be taken to share the following resources
without conflicts between the various devices.

Interrupt Request Line (IRQ's) and /proc/interrupts

Every device needs some way to grab the kernel's attention, as if to say "Hey, someone just moved the
mouse, and I want to tell you about it", or "Hey, I've finished transferring that block of information to
the disk like you told me to". Many devices use an interrupt request line, or IRQ, for this purpose. In the
x86 architecture, 15 IRQ lines are available, and multiple devices can share a single IRQ line as well.

The proc filesystem file /proc/interrupts displays the available IRQ lines, and any device drivers
which are using them. The absolute number of times that the interrupt has occurred (since the machine
booted) is included as well.

[root@station root]# cat /proc/interrupts
CPU0
0:    6091325          XT-PIC timer
1:      41608          XT-PIC keyboard
2:          0          XT-PIC cascade
3:          0          XT-PIC ehci-hcd
5:     115473          XT-PIC usb-uhci
8:          1          XT-PIC rtc
10:   16384184          XT-PIC usb-uhci, eth0
11:    9720993          XT-PIC usb-uhci, eth1, Audigy
12:     848836          XT-PIC PS/2 Mouse
 14:     190363          XT-PIC ide0
 15:    1765002          XT-PIC ide1
NMI:          0
ERR:          0
   On an SMP machine, hardware interrupts are raised on individual CPU's, and a separate column of
    interrupt activity for each CPU would be included.
   IRQ 0 is invariably used by the timer device driver. The timer interrupts the kernel at a constant rate
    of 1000 interrupts per second, prompting the kernel to interrupt the normal flow of activity and
    perform any periodic or pending tasks.
   Three completely unrelated device drivers (the USB controller, an Ethernet network interface card,
    and the Audigy sound card) are all sharing IRQ 11.
   The NMI field counts the number of occurrences of "Non Maskable Interrupts". These interrupts are
    normally used to signal low level hardware error conditions.

I/O Ports and /proc/ioports

After getting the kernel's attention (by raising an interrupt), devices usually want to perform some type
of data transfer into or out of the system. The x86 architecture provides a distinct 16 bit address space
for devices, whose addresses are referred to as I/O ports. When communicating with the kernel through
I/O ports, the kernel and the device must agree on what ports are being used.

The proc filesystem file /proc/ioports displays which ports have been claimed by which device driver.
(The port addresses are displayed as hexadecimal digits.)

[root@station root]# cat /proc/ioports
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f :   keyboard
0070-007f :   rtc
...
03c0-03df :   vesafb
03f6-03f6 :   ide0
03f8-03ff :   serial(auto)
0cf8-0cff :   PCI conf1
c000-c01f :   Creative Labs SB Audigy
  c000-c01f   : Audigy
c400-c407 :   Creative Labs SB Audigy MIDI/Game port
c800-c8ff :   Linksys Network Everywhere Fast Ethernet 10/100 model NC100
  c800-c8ff   : tulip
...


Device Memory Buffers and /proc/iomem

Many modern devices implement their own memory, which once mapped into the memory address
space of a system, can be used to easily transfer data back and forth. Video cards are a classic example
of devices that provide their own memory buffers.

The proc filesystem file /proc/iomem displays all of the devices whose memory buffers have been
mapped into physical memory, and the physical memory addresses which have been assigned to each
buffer (listed in hexadecimal digits).

[root@station root]# cat /proc/iomem
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-2dfeffff : System RAM
  00100000-002766f6 : Kernel code
  002766f7-00384807 : Kernel data
...
e3000000-e3003fff : Creative Labs SB Audigy FireWire Port
e3004000-e30043ff : Linksys Network Everywhere Fast Ethernet 10/100 model NC100
  e3004000-e30043ff : tulip
e3005000-e30057ff : Creative Labs SB Audigy FireWire Port
e3006000-e30060ff : VIA Technologies, Inc. USB 2.0
  e3006000-e30060ff : ehci-hcd
e3007000-e30070ff : VIA Technologies, Inc. VT6102 [Rhine-II]
  e3007000-e30070ff : via-rhine
...
   As far as this file is concerned, the machine's main memory (RAM, or "Random Access Memory")
    is considered "just another device", and mapped into lower physical address spaces.
   The physical address space does not need to be used contiguously (without gaps). Here, the mapping
    of the system's RAM is interrupted in order to map the VGA video device. The address of this
    device occurs early in the physical address space, and for legacy reasons cannot be moved.
   Most modern devices that implement memory buffers are mapped into the upper addresses of the
    physical address space.

Configuring PCI Devices

When attaching new devices to a Red Hat Enterprise Linux system, two steps must generally occur to
configure the kernel to use the new device. First, if the device driver for the device is implemented as a
kernel module, the module must be loaded (if not already). Secondly, the device driver (and the device)
must be configured to use any or all of the resources mentioned above in a manner that will not conflict
with any other devices. The following outlines how this is accomplished for PCI devices. Usually, both
steps occur with minimal intervention on the part of the administrator.
Loading Modular Device Drivers

When a new PCI device is recognized by the Hardware Abstraction Layer, if a driver for the device is
not already present in the kernel, a table of appropriate modules for various PCI devices is consulted,
found at /lib/modules/2.6.18-8/modules.pcimap (where 2.6.18-8 might be replaced by an updated
kernel version). If the device's vendor and product id are recognized, an appropriate module will be
automatically inserted into the kernel.

Often, the kernel recognizes the need for a particular driver because of the role it fulfills. As an example,
consider the following modprobe.conf file, which is used to configure the same devices discovered
with the lspci command above.

[root@station root]# cat /etc/modprobe.conf
alias eth0 tulip
alias eth1 via-rhine
alias snd-card-0 audigy
...
alias usb-controller usb-uhci
alias usb-controller1 ehci-hcd


The kernel might be aware that it must load the appropriate kernel module to fill a particular role, such
as "the usb-controller", or "the eth0 network interface", or "the SCSI controller", but the kernel is not
aware which of several different modular device drivers that could fill that role is appropriate for the
local hardware. Using aliases in the modprobe.conf file, when the kernel attempts to load "the eth0
interface", the appropriate modular device driver for the local hardware is loaded (in this case, the tulip
kernel module).

The following table outlines some of the "roles" that the kernel is aware of, and that kudzu (or the
Anaconda installer) configures modprobe.conf to fill appropriately. Do not be concerned when the table
discusses concepts which are not yet familiar; they will (mostly) be discussed later in the course.

Table 1. Common Aliases Found in modprobe.conf

       Alias                                                    Role
                         The device driver appropriate for the network interface card associated with
ethN
                         network interface ethN.

snd-card-N
                         The device driver appropriate for the sound card associated with the appropriate
                         slot in the sound subsystem.
usb-controller           The device driver appropriate for the system's USB controller.
scsi_hostadaptor         The device driver appropriate for the system's SCSI controller.
char-major-N             The device driver associated with character device node major number N.
block-major-N            The device driver associated with block device node major number N.

You can also use the install and remove keywords to specify custom commands to use when a particular
module is loaded or unloaded or specify options to be passed to a module with the options keyword.

Assigning Resources

In addition to loading the appropriate kernel module, resources must be assigned to the device. Usually,
this is handled at boottime using the Plug n' Play protocol. All PCI devices use a common mechanism
for advertising which of usually multiple different configurations they can support (such as IRQ 11 at
I/O port 0xe000, or IRQ 10 at I/O port 0xc800), and for assigning a particular configuration.

At bootup, all PCI devices are probed, and a set of non-conflicting resources are specified for each card.
Usually, this happens with no intervention on the part of the administrator. The lspci command
introduced above, if used with the -v command line switch, will report the resources associated with
each device. In the following example, the lspci -v command reveals the IRQ, I/O port, and physical
memory address assigned to the Linksys Ethernet card (10, 0xc800, and 0xe300400, respectively).

[root@station root]# lspci -v
...
00:07.0 Ethernet controller: Linksys Network Everywhere Fast Ethernet 10/100 mod
el NC100 (rev 11)
        Subsystem: Linksys: Unknown device 0574
        Flags: bus master, medium devsel, latency 32, IRQ 10
        I/O ports at c800 [size=256]
        Memory at e3004000 (32-bit, non-prefetchable) [size=1K]
        Expansion ROM at <unassigned> [disabled] [size=128K]
        Capabilities: [c0] Power Management version 2
...


Occasionally, an administrator might need to tweak these assignments. Usually, this can be
accomplished by using option lines in the modprobe.conf file to associate parameters with the
appropriate kernel modules. The relevant option names tend to vary from module to module. Appendix
A of the Red Hat Enterprise Linux Reference Guide itemizes commonly encountered hardware, the
relevant kernel module associated with it, and parameters that are commonly passed to the kernel
module, where relevant.

Examples: Exploring a New Machine

The user elvis is continuing to explore a new machine. In order to discover what PCI devices are
connected to the machine, elvis uses the lspci command.

[elvis@station elvis]$ /sbin/lspci
00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)00:03.0 CardBus bridge:
Texas Instruments PCI1420
00:03.1 CardBus bridge: Texas Instruments PCI1420
00:07.0 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:08.0 Multimedia audio controller: ESS Technology ES1983S Maestro-3i PCI Audio Accelerator (rev 10)
00:10.0 Ethernet controller: 3Com Corporation 3c556 Hurricane CardBus (rev 10)
00:10.1 Communication controller: 3Com Corporation Mini PCI 56k Winmodem (rev 10)
01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility M3 AGP 2x (rev 02)
02:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03)
02:00.1 Serial controller: Xircom Cardbus Ethernet + 56k Modem (rev 03)


Skimming the list, he sees an ESS soundcard, a 3Com networking card , a Winmodem, an ATI video
card, and what is apparently a combined Ethernet/modem Xircom (PCMCIA) card.

Curious which kernel modules are being used as device drivers for these devices, he examines the file
/etc/modprobe.conf.

[elvis@station elvis]$ cat /etc/modprobe.conf
alias parport_lowlevel parport_pc
alias eth0 3c59x
alias snd-card-0 maestro3
install snd-card-0 /bin/aumix-minimal -f /etc/.aumixrc -L >/dev/null 2> &1 || :
remove snd-card-0 /bin/aumix-minimal -f /etc/.aumixrc -S >/dev/null 2> &1
|| :
alias usb-controller usb-uhci




Filesystem Device Nodes

Key Concepts

       Processes access device drivers through a special file type referred to as device nodes.
       Linux supports two fundamentally different types of devices, block devices and character
        devices. Consequently, file system nodes are either block or character nodes.
       Every filesystem device node has a major number (which indexes a particular device driver in
        the kernel) and a minor number.
       Filesystem device nodes can be created with the mknod command.

"Everything is a File"

The previous Lessons have discussed device drivers as specialized kernel components which allow the
kernel to communicate with various devices. This Lesson addresses the next layer: how do processes
communicate with device drivers? When managing the flow of information to and from processes,
Linux (and Unix) follows a simple design philosophy: everything is a file. Following this philosophy,
the previous question is answered: processes communicate with device drivers as if they were files.

For example, the terminal device driver for virtual console number 4 is referenced by the device node
/dev/tty4. What happens when information is written to this file?

[root@station root]# echo "hello world" > /dev/tty4


The information is passed to the terminal device driver, which does what a terminal device driver should
do when information is written to it: displays it on the terminal. Switching to the (previously unused)
virtual console number 4, we find the following.

Red Hat Enterprise Linux ES release 4 (Nahant)
Kernel 2.6.9-5.EL on an i686




station login: hello world

       The terminal device driver displayed the information that was written to /dev/tty4 at the current
       cursor location.

Filesystem Device Nodes

The files which reference device drivers are referred to as device nodes. The Linux filesystem supports
several different file types. Most users are familiar with three: regular files, directories, and symbolic
(soft) links. System administrators usually become acquainted with two more: block and character
device nodes. By convention, device nodes are found in a dedicated /dev directory. When a new device
is detected by the kernel, a device node is added for it here. Note that this differs from the behavior of
older versions of Linux, where a device node existed for every possible device, whether it was in use or
not.

[root@station root]# ls -l /dev
total 0
crw-rw----   1   root   root    14, 12 Aug        5    16:30   adsp
crw-------   1   root   root    10, 175 Aug       5    16:30   agpgart
crw-------   1   root   root    36,   8 Aug       5    16:30   arpd
crw-------   1   root   root    14,   4 Aug       5    16:30   audio
lrwxrwxrwx   1   root   root          3 Aug       5    16:30   cdrom -> hdc
crw-------   1   root   root     5,   1 Aug       5    16:30   console
...
brw-rw----   1   root   disk     3,     0   Aug   5    16:30   hda
brw-rw----   1   root   disk     3,     1   Aug   5    16:30   hda1
brw-rw----   1   root   disk     3,     2   Aug   5    16:30   hda2
brw-rw----   1   root   disk     3,     3   Aug   5    16:30   hda3
brw-rw----   1   root   disk    22,     0   Aug   5    16:30   hdc


When listed with the ls -l command, block and character device nodes can be recognized by the first
character on each line. While regular files are identified by a “-”, and directories by a “d”, character
device nodes are identified by a “c”, and block device nodes are identified by a “b”.

Why Two Types of Nodes?

The filesystem allows for two different types of device nodes because the Linux kernel distinguishes
between two different types of devices.

Block Devices

       Block Devices are devices that allow random access, and transfer information in fixed size
       chucks, or "blocks". Generally, disks are thought of as block devices. More importantly, for
       improved I/O performance, all transfers to and from block devices make a use of cache within
       the kernel, sometimes referred to as the "Page Cache", "Buffer Cache", or simply "I/O Cache".

Character Devices

       Character Devices are devices that don't interact with the I/O cache. Often, character device
       operate on stream of sequential bytes (or "characters"), such as keystrokes on a terminal, or data
       sent to a printer. Character devices can also provide access to arbitrary buffers, however, such as
       memory buffers on video cards.

The Anatomy of a Device Node

In the following, the ls command is used to generate a long listing of a regular file, and the /dev/fd0
device node.

[root@station root]# ls -l /etc/passwd


-rw-r--r--    1 root     root                         4004 Sep 17 12:34 /etc/passwd
[root@station root]# ls -l /dev/fd0


brw-rw----       1 root        floppy             2,           0 Jan 30   2003 /dev/fd0

     Regular files are used to store information on a harddisk. Accordingly, the ls -l command reports
     the amount of information stored in the file (i.e, the length of the file).
     Device nodes, in contrast, are not used for storing information. Instead, they serve as a conduit,
     transferring information to and from an underlying device driver. Therefore, the concept of a
     filesize is meaningless. In its place, the ls -l command reports two numbers which are associated
     with every device node, the device node's major number and minor number.
Every device driver in the kernel registers for a major number, which is an integer that is used to identify
that device. The major number of a filesystem device node correlates to the major number of the device
driver with which it is associated. A list of device drivers which have registered with the kernel, and
their major numbers, is found in the proc filesystem file /proc/devices. In the following, note that
character devices and block devices are treated separately. The character device driver with major
number 2 is “pty”, while the block device driver with major number 2 is “fd”.

[root@station root]# cat /proc/devices
Character devices:
  1 mem
  2 pty
  3 ttyp
  4 ttyS
  5 cua
  6 lp
...
143 pts
162 raw
180 usb
254 pcmcia

Block devices:
  1 ramdisk
  2 fd
  3 ide0
  7 loop
  9 md
...
 58 lvm


The minor number associated with a device node is treated as a parameter, which is passed to the device
driver when data is written to or read from the node. Different device drivers implement minor numbers
differently. For example, the floppy driver (block major number 2) uses the minor number to distinguish
between possible floppy formats, while the primary IDE controller (block major number 3) uses the
minor number to distinguish different partitions on the harddisk (more on that in a later workbook).

[root@station   root]# ls -l /dev/fd*   /dev/hda*
brw-rw----      1 root     floppy       2,   0 Jan      30   2003   /dev/fd0
brw-rw----      1 root     floppy       2,   4 Jan      30   2003   /dev/fd0CompaQ
brw-rw----      1 root     floppy       2,   4 Jan      30   2003   /dev/fd0d360
brw-rw----      1 root     floppy       2, 12 Jan       30   2003   /dev/fd0D360
...
brw-rw----      1   root   disk         3,    0   Jan   30   2003   /dev/hda
brw-rw----      1   root   disk         3,    1   Jan   30   2003   /dev/hda1
brw-rw----      1   root   disk         3,   10   Jan   30   2003   /dev/hda10
brw-rw----      1   root   disk         3,   11   Jan   30   2003   /dev/hda11
...
brw-rw----      1 root     disk         3,   2 Jan 30        2003 /dev/hda2
...
brw-rw----      1 root     disk         3,   3 Jan 30        2003 /dev/hda3
...
brw-rw----      1 root     disk         3,   4 Jan 30        2003 /dev/hda4
brw-rw----      1 root     disk         3,   5 Jan 30        2003 /dev/hda5
brw-rw----      1 root     disk         3,   6 Jan 30        2003 /dev/hda6
...


Summarizing, device nodes have three parameters which are used to associate the device node to a
particular device driver: A block or character file type, a major number, and a minor number. Notice that
the filename of the device node is not included in this list, and is not used to determine the appropriate
device driver.

This scheme has problems associated with it. Commonly, a device node might exist, for which there is
no corresponding device driver in the kernel:

[root@station root]# echo "hello world" > /dev/sde
-bash: /dev/sde: No such device or address


Less commonly, there might be a device driver in the kernel with no device node referencing it, and thus
no traditional way for processes to interact with it.

Managing Device Nodes: mknod

Usually, administrators do not need to manage device nodes directly. Most Linux distributions,
including Red Hat Enterprise Linux, populate the /dev directory with device nodes for any conceivable
device. (Red Hat Enterprise Linux has more than 7500 files in the /dev directory.) Occasionally,
however, especially in minimal environments (such as a rescue shell), administrators may need to use
the mknod command to create device nodes.

The mknod command expects to be called with four arguments. The first argument is the name of the
file to create. The second argument may be either a “c” (to specify a character device node) or a “b” (to
specify a block device node). The subsequent two arguments are the major number and the minor
number, respectively.

For example, our initial demonstration (writing to the fourth virtual console) can be repeated by using a
custom created device node in root's home directory. First, root looks up the original device node's
major and minor number.

[root@station root]# ls -l /dev/tty4
crw-------    1 root     root       4,    4 Sep 27 06:52 /dev/tty4


Next, she uses mknod to create a new device node in her home directory, observes it with the ls -l
command, and then writes to the node.

[root@station   root]# mknod mytty4 c 4 4
[root@station   root]# ls -l mytty4
crw-r--r--      1 root     root       4,   4 Sep 27 07:34 mytty4
[root@station   root]# echo "hello my device node" > mytty4


Where is the information that she wrote? On the fourth virtual console, naturally:

Red Hat Enterprise Linux ES release 4 (Nahant)
Kernel 2.6.9-5.EL on an i686


station login: hello world
hello my device node


Again, the name of the device node is irrelevant. Only the type, and the major and minor numbers,
matter. Also, there is nothing special about the /dev directory, other than convention.

How are device nodes removed? The same way that anything is removed from the filesystem.

[root@station root]# rm mytty4
rm: remove character special file `mytty4'? y


Commonly Used Device Nodes

While the concept of device nodes is shared by all versions of Unix, the names traditionally associated
with device nodes tends to vary from one version of Unix to another. The following tables list the Linux
names of commonly used device nodes, which should be part of every Linux administrator's working
knowledge.

Table 1. Common Linux Block Device Nodes

Node Name         Associated Device
hda          Primary Master IDE Drive
hdb          Primary Slave IDE Drive
hdc          Secondary Master IDE Drive
hdd          Secondary Slave IDE Drive
sda          "First" SCSI Drive
sdb          "Second" SCSI Drive
fd0          First Floppy Disk
fd1          Second Floppy Disk

Table 2. Common Linux Character Device Nodes

Node Name                            Associated Device
ttyn         Virtual Console number n
ttySn        Serial Port n
lpn          Parallel Port n
null         All information written to this virtual device is discarded.
zero         When read, this device is an infinite source of binary zeros.
urandom      When read, this device is an infinite source of random binary data.

Symbolic Links as Functional Names

Often, applications are more concerned with the function of a device, rather than its actual device node.
For example, most CD-ROM drives implement either an IDE or SCSI interface, and thus could be
addressed by the hdc or sda device nodes. An audio music player application, however, would not care
if the device were an IDE or SCSI device, it would just like to use "the CD-ROM".

Red Hat Enterprise Linux often uses symbolic links in the /dev directory to help ease the configuration
of these applications. The following table list commonly created symbolic links, and the types of devices
to which they often resolve.

Table 1. Common Symbolic Links Found in the /dev Directory

Link Name        Sample Device Nodes
/dev/cdrom /dev/hdc, /dev/sdb
/dev/modem /dev/ttyS0, /dev/ttyS1
/dev/pilot /dev/ttyS0, /dev/usb/ttyS1
Dynamic Device Node Creation: udev

The traditional Unix technique for accessing devices (device nodes) has withstood the test of time, but
it's not without problems. For example, there can be a device driver in the kernel which cannot be
accessed because there's not a complementary device node in the filesystem. Conversely, there can be
device nodes in the file system without the corresponding device driver in the kernel, which leads to
confusion.

These problems are only exacerbated by the increasing popularity of hot swappable devices, which
people rightfully expect to plug into a machine and they "just work".

Originally, and up through Red Hat Enterprise Linux 3, Red Hat solved the problem by "prepopulating"
the /dev directory with every conceivable device node, even if the corresponding device drivers were
not present. As a result, the /dev directory had literally thousands of entries.

Starting with Red Hat Enterprise Linux 4 (and the Linux 2.6 kernel), Red Hat (and the Linux community)
is trying to take a more intelligent approach to the problem. The kernel now implements a notification
device (known as "netlink", because it is also associated with networking), which is monitored by a new
udevd daemon.

The gist is that when a new device is attached to the machine, the kernel notifies udevd, which consults
a database of rules found in /etc/udev. The rules tell the udevd daemon what type of device node to
create for the device, and what ownerships and permissions to apply to the node.

Likewise, when a device is removed, the udevd daemon again responds to a kernel notification, this
time by removing the device node.

Interestingly, the udevd daemon effectively considers every device as a hot swapped device. Permanent
devices "just happened to be there" as the system was bootstrapping.

There are a couple of consequences to the new technique.

   1. On the plus side, the /dev directory has many fewer device nodes, and the nodes that do exist are
      a direct reflection of the underlying detected hardware.
   2. On the down side, you can no longer simply use mknod to create your own device nodes within
      the /dev directory. More exactly, you can create the node, but because the /dev directory is now
      dynamically populated by udevd, you cannot expect the node to survive a reboot.

The details of configuring the udevd daemon are beyond the scope of this course, but the interested can
use rpm -ql udev to obtain a list of man pages (such as udev(8)), and more complete documentation in
the /usr/share/doc/udev-version directory.

Examples Using the dd Command to Create a backup of a Drive's Master Boot Record

In general, device nodes allow direct access to devices. Device nodes associated with disks allow users
to read the contents of the disk, byte for byte, as if the disk were one giant file. The dd command can be
used to extract specific lengths of data from specific locations of a file.

The first block (512 bytes) of a bootable harddisk is referred to as the "Master Boot Record", and
includes sensitive information, such as the boot loader and the drive's partition table. As a precaution, a
system administrator wants to make a backup of this information. He uses the dd to make a copy of the
first 512 bytes of the disk /dev/hda. He specifies that his input file should be /dev/hda, his output file
should be /tmp/MBR.backup, and that exactly 1 block should be transferred, using a block size of 512
bytes. As a result, he ends up with a file exactly 512 bytes in length.

[root@station root]# dd if=/dev/hda of=/tmp/MBR.backup bs=512 count=1
1+0 records in
1+0 records out
[root@station root]# ls -l /tmp/MBR.backup
-rw-r--r--    1 root     root          512 Sep 28 07:58 /tmp/MBR.backup


If his Master Boot Record ever becomes corrupted, it can be restored by inverting the previous
command.

[root@station root]# dd if=/tmp/MBR.backup of=/dev/hda


(Without arguments specifying otherwise, the dd command transfers the entire input file).


Performance Monitoring

Key Concepts

      Linux commonly uses a general measure of system activity referred to as the "load average".
      Linux uses memory for two fundamental purposes: supporting processes and caching block
       device I/O operations.
      The top command can be used to monitor processor and memory activity.

Performance Monitoring

We conclude this workbook by mentioning some simple tools and measures which are commonly used
to monitor performance on Linux systems.

CPU Performance
The uptime Command

As the name implies, the uptime command returns how long the machines has been operating without
powering down or rebooting.

[root@station root]# uptime
 08:14:10 up 1:28, 4 users,              load average: 0.56, 0.23, 0.12

While this machine has only been up one hour and 28 minutes, Linux has such a reputation for stability
that network servers often have uptimes measured in months rather than hours.

More relevant to CPU performance, the uptime command also returns a commonly used Linux (and
Unix) statistic referred to as the load average of the machine (often abbreviated loadavg). The load
average is a time average of the number of processes which are in the "Runnable" or "Involuntary Sleep"
state. Conventionally, three time averages are maintained: A 1 minute average, a 5 minute average, and
a 15 minute average).
The top Command

The top utility repeatedly lists processes on the running on the machine, sorted in order of CPU activity.
The list is refreshed about every five seconds. While top is running, the keyboard is "live", implying that
single keystrokes are interpreted as commands, without having to hit the RETURN key. Notably, the “q”
key quits top, while the “h” key displays a help screen, documenting other keystroke commands.

The top three lines of top's display monitor the system's CPU related activity. The top line return the
same information as the uptime command, notably including the load average.

[root@station root]# top
top - 09:33:48 up 12:07, 5 users, load average: 0.23, 0.40, 0.30
Tasks: 91 total,    2 running, 88 sleeping,  0 stopped,   1 zombie
Cpu(s): 8.6%us, 3.7%sy, 0.3%ni, 86.7%id, 0.7%wa, 0.0%hi, 0.0%si,          0.0%st

...


The second line enumerates the processes running on the machine, and the state they are in. Many
processes in the "runnable" state (more formally called "running") would imply a busy machine.

The third and fourth lines classify how the CPU has been using its time, using the following three
standard Unix classifications.

user - "us"

When the CPU is in "user" mode, it is performing calculations on behalf of a user process. Processes
performing computationally intensive calculations, such as an image manipulation program, or a
cryptographic library, would cause the CPU to spend a large amount of time in user mode.

system - "si"

When the CPU is in "system" mode, it is performing kernel acticities on behalf of a process. Examples
include servicing system calls on behalf of a process (such as disk read and write operations). Processes
which are transferring large amounts of data to and from disk, or to and from network connections,
would cause the CPU to spend a large amount of time in "system" mode.

idle - "id"

Just as the name suggests, this is the amount of time that the CPU spends cooling its heals because no
processes are in the runnable state.

Additionally, Red Hat Enterprise Linux tracks the following statistics.

nice - "ni"

This is the amount of time that the CPU spends acting on behalf of processes that have been "niced", so
as to have a lower execution priority. Time spent in this state is also counted as time spent in the "user"
or "system" state, as appropriate.

I/O wait - "wa"
As the name implies, this is the amount of time the CPU spends idling because a process in blocked on
I/O. Anytime the CPU would have been marked as idle, but a process is "blocked" in the uniterruptible
sleep ("D") state, the time is charged to wait instead.

Hardware Interrupt - "hi"

This is the amount of time that the CPU spends servicing lowlevel hardware requests, or "interrupts". As
the name implies, hardware may interrupt the normal flow of CPU execution when immediately
pertinent information is available, such as a mouse which has been moved to a new location, or an
Ethernet card which has received a packet over the network.

Software Interrupt - "si"

This is the amount of time that the CPU spends servicing deferred kernel tasks which are not directly
related to a process, such as the processing of network packets.

Stolen - "st"

This is the amount of time that the CPU would have run, but another virtualized host was using the CPU
instead. This field is only relevant on virtualized (Xen) systems.

Memory Utilization

Perhaps the most important task of the Linux kernel is to efficiently use one of the important resources
for overall system performance, memory. Linux memory management tends to be a complicated subject,
making it difficult to give simple answers to seemingly simple questions such as "how much memory is
this process using?". In general, however, administrators can think of the Linux kernel trying to balance
the memory demands of two important tasks.

Process Memory

The various processes running on the machine each make memory demands of the kernel. For smaller
processes, the memory demands may be as modest as 100 kilobytes or less per process. Larger
applications (particularly graphically intensive ones, such as the Firefox web browser) can request tens
of megabytes of memory.

Disk I/O Cache

The Linux kernel tries to optimize disk I/O by buffering all disk (or, more exactly, block device)
operations. The process of reading or writing information to a disk is dramatically slower than reading
or writing information to memory. When a process requests to read information from a disk, the
information is of course read as soon as possible into memory. When a process requests to write
information to a disk, however, the kernel quickly stores the information in the memory cache, and
returns control to the process. When there is a "quiet moment" (i.e., when there are few other pending
operations to perform), the kernel will perform the relatively slow operation of committing the cached
information to disk.

What happens if another process (or the same process) tries to read the same information from the disk
before it gets flushed from the cache? The kernel returns the information from the cache, bypassing the
disk altogether. Commonly used files, which are often read from or written to, might spend most of their
time in the I/O cache, only occasionally being synced back to disk. On systems with large amounts of
memory, the disk I/O cache may easily use more than half of it. Efficiently managing the disk I/O cache
leads to dramatically better overall system performance.

Monitoring Memory Utilization with /proc/meminfo

We look again at the contents of the /proc/meminfo, this time focusing on how much memory is
devoted to the disk I/O cache.

[root@station ~]# cat /proc/meminfo
MemTotal:       255232 kB
MemFree:          4340 kB
Buffers:         12096 kB
Cached:         138840 kB
...

   Recall the MemTotal line, which lists detected memory, and the MemFree line, which lists how
   much of the memory is left unused. We now focus on the Buffers and Cached lines. The
   meminfo file distinguishes between two subtly different variations of the I/O cache (the latter is
   for caching disk I/O which is related to the contents of regular files, the former is for all other
   block device interactions). For our purposes, the combined sum of both can be considered the
   "I/O cache".

On this machine, which contains about 256 megabytes of physical memory, about 150 megabytes (or
over half) is currently devoted to the I/O cache.

Monitoring Memory Utilization with top

The top command, introduced above, also monitors memory consumption. Above, we focused on the
first 3 lines of the top display, which related to CPU activity. We now focus on aspects of the next three
lines.

[root@station root]# top
top - 09:51:08 up 12:25, 6 users, load average: 0.00, 0.12, 0.28
Tasks: 91 total,    2 running, 88 sleeping,    0 stopped,  1 zombie
Cpu(s): 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si,          0.0%st
Mem:   514604k total, 505516k used,    9088k free, 219620k buffers
Swap: 1044216k total,       132k used, 1044084k free, 110568k cached
...


Why is My Memory Always 90% Full?

After observing the Linux kernel's memory dynamics during various operations, users new to Linux are
often surprised by their inability to "free up" memory, even after exiting all large applications. Why,
under Linux, is memory always 90% full? Because the kernel is doing exactly what it is supposed to be
doing, namely using its resources as efficiently as possible. Any memory not being currently used by
processes is devoted to improving the speed of I/O operations.

Examples Using top to Analyze System Activity

The user elvis has realized that his machine is acting sluggishly. He uses the top command to analyze
his machine's behavior.

[elvis@station elvis]$ top
top - 08:09:40 up 3 days, 15:29, 2 users, load average: 12.19, 6.00, 2.34
Tasks: 103 total,   9 running, 93 sleeping, 0 stopped,  1 zombie
Cpu(s): 20.0%us, 79.8%sy, 0.0%ni, 0.2%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem:      255148k total,    245412k used,        9772k free,     52968k buffers
Swap:    1044216k total,       176k used,     1044040k free,     111860k cached

  PID   USER      PR   NI   VIRT RES    SHR   S   %CPU %MEM    TIME+    COMMAND
15276   blondie   25    0   5208 1428   632   R   26.6 0.3    6:00.14   find
15278   blondie   25    0   5352 908    632   R   25.3 0.2    6:12.23   grep
15280   blondie   25    0   4720 1432   632   R   24.3 0.3    5:58.29   find
15282   blondie   25    0   4932 904    632   R   23.3 0.2    6:15.64   grep
15273   root      17    0   3852 968    756   S    0.3 0.2    0:04.60   top
15367   root      16    0   2848 964    756   R    0.3 0.2    0:00.18   top
    1   root      16    0   1932 516    440   S    0.0 0.1    0:00.56   init

...


First, he notices the number of grep and find commands that blondie appears to be running. He makes
the following observations.

     The 1 minute load average, 12.19, is high, while the 15 minute load average, 2.34, is comparatively
      low. This implies that the machine is responding to a burst of activity.
     His CPU is spending a lot of time in the "system" state, probably as a result of all of the I/O activity
      required by the find and grep commands.
     Of his machine's 256 megabytes of memory, 53 + 111 = 164 megabytes of memory is being used to
      cache I/O operations. As a result, other processes on the machine will probably respond very
      sluggishly, as they are short on physical memory.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:25
posted:2/26/2012
language:English
pages:28