Table of Contents

footballenoughΛογισμικό & κατασκευή λογ/κού

30 Οκτ 2013 (πριν από 3 χρόνια και 5 μήνες)

100 εμφανίσεις

Notes

Table of Contents

Hardware Overview

................................
................................
.............................

2

Device Drivers

................................
................................
.............................

2

The Static Ker
nel 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

Pr
ocessor Support

................................
................................
..........................

8

Symmetric Multiprocessing (SMP)

................................
................................
.............

8

/proc/cpuinfo

................................
................................
............................

8

Memory

................................
................................
................................
.....

9

/proc/meminfo

................................
................................
............................

9

Harddisks

................................
................................
................................
.

10

IDE disks and /pro
c/ide

................................
................................
.................

10

SCSI disks

................................
................................
..............................

11

SATA drives

................................
................................
.............................

11

Examples: Becomi
ng Familiar with a New Machine

................................
.............................

12

PCI Devices

................................
................................
................................
..

1
3

The PCI bus

................................
................................
...............................

13

Hardware Resourc
es

................................
................................
........................

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

"Eve
rything 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

Sy
mbolic 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 Pe
rformance

................................
................................
...........................

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 h
ardware, 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

repor
ts information about the system's memory.



The directory
/proc/ide/

reports information
a
bout the system's IDE drives.

Devic
e 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 har
dware, 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 t
he 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 p
arameters (if any) are specified.

The Static Kernel Image


The static kernel image is the file that is loaded w
hen 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 pr
ocess, 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 t
he 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, o
r, 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. F
or
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
-


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 Drivers

Installing device drivers for particular devices is not an issue in Linux as in other operating
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 defa
ult. 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 bootti
me 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.co
nf

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
i
nformation), 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 com
munity 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 a
s 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 th
e
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 con
figures 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 du
nd kdump rha
-
unittest

apm
-
scripts firstboot kernel rha
-
unittest.rpmsave

auditd grub keyboard rhn

authconfig hidd

kudzu



獡浢s

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_s
upplicant



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 curr
ent
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 ID
E"

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 Win
modem"

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 d
evice 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 a
re 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) ve
rsions 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 o
f 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

c
ommand 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/h
da3 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 fo
rm.

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 H
ardware 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 i
nformation 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 architecture
s. 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

repor
ts 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


: 48.323

cache size


: 26 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.4

The following fields tend to provide the most useful information.



The 灲潣ess潲 num扥r⸠ On a⁳ingle 灲潣ess潲 machineⰠ this is 〮⁏n an SMPachineⰠ the
cpuinfo

file contains multiple stanzas, each identified by a distinct processor number.



The CPU潤ol⸠



The s灥e搠潦 the CPU⸠



The size 潦 the CPUem潲y cacheⰠwhich can significa湴ly re摵ce mem潲y access times⸠



Vari潵s flagsⰠ which in摩cate ca灡扩lities 潦 the CPU⸠F潲⁥xam灬eⰠ the
tsc

flag indicates that the
CPU supports a time stamp counter (which can be used for precise t
iming information), while the
pae

flag specifies that the CPU can support physical addressing extensions (more on these, below).



A misleadi湧 an搠潦ten misuse搠 statistic that is use搠t漠c潲relate CPU⁣ycles t漠oeal w潲l搠 time⸠ It
潮ly merits mention 扥
cause it is 潦ten ina灰p潰oiately use搠as aeasure 潦 灲潣ess潲 s灥e搮⁕se
the MHz 灡rameter (a扯be) instea搮d

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 sy
stem can be rebooted and the PAE kernel can be chosen from
GRUB's boot menu.

/proc/meminfo


The proc filesyst
em 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
Sw
apTotal

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 autom
atically 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 deskt
op 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
hd
x
, 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 s
ubdirectory 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/i
de/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/i
dentify <==

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 2
55 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
sd
x
, 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 r
ebooting) 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 loc
ally
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 Pentiu
m 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: 43
080 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 detect
ed 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 expansi
on 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: Creati
ve 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. U
SB (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 [ProSavag
e8 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 de
vice 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 motherboar
d 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 th
at 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 transf
erring 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 pro
c 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 in
terrupts 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 filesyst
em 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 E
thernet 10/100 model NC100


c800
-
c8ff : tulip

...

Device Memory Buffers and /proc/iomem


Many modern device
s 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
/pr
oc/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
-
0009fb
ff :

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 anoth
er 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
devic
e 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 no
t 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 th
e
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 dev
ice 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 cas
e, 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 whi
ch are not yet familiar; they will (mostly) be discussed later in the course.

Table

1.


Common Aliases Found in
modprobe.conf


Alias

Role

eth
N


The device driver appropriate for the network interface card associated with
network interface
eth
N
.

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 th
e 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 c
onfiguration.

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

c
ommand 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 contin
uing 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 inte
rface: 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 PC
I 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 Mobil
ity 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 vid
eo
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 supp
orts 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 k
ernel) and a minor number.



Filesystem device nodes can be created with the
mknod

command.

"Everything is a File"


The pr
evious 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 info
rmation 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 termi
nal 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 s
upports
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 ar
e 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 w
as 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 b
y a “
b
”.

Why Two Types of Nodes?


The filesystem allows for two different types of device nodes because the Linux kerne
l 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
i
mproved 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 w
ith 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 o
f 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 i
s 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 u
sed 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@stat
ion 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 (bloc
k 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 /d
ev/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 nod
e 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 prob
lems 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 de
vice 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 Enterpri
se 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 w
ith 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 mino
r
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, nat
urally:

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 f
rom the filesystem.

[root@station root]# rm mytty4

rm: remove character special file `mytty4'?
y

Commonly Used Device No
des


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

tty
n

Virtual Console number
n

ttyS
n

Serial Port
n

lp
n

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 w
hich 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 tes
t 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 t
he 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 i
t 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.

Inte
restingly, 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 acc
ess 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 inform
ation. 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



Lin
ux 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 me
mory 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 lon
g 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 common
ly 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 tim
e averages are maintained: A 1 minute average, a 5 minute average, and
a 15 minute average).

The top Comman
d


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 c
ommands, 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 ret
urn 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
whic
h 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 cool
ing 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 t
o 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 o
n
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 har
dware 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 receive
d 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 resource
s
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, administrat
ors can think of the Linux kernel trying to balance
the memory demands of two important tasks.

Process Memo
ry


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 i
s 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 focus
ing 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 i
s
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 mega
bytes of physical memory, about 150 megabytes (or
over half) is currently devoted to the I/O cache.

Monitor
ing 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 Syst
em 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, 104404
0k 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.