Book Excerpt

Know the hardware in your computer: task 2.2

Task 2.2: Learn about Your Hardware

The x86 PC architecture, and therefore the x86-64 architecture derived from it, has evolved

    Requires Free Membership to View

over a period of more than two decades. For this reason, many parts of the design of these systems are limiting or strange—what seemed a good solution to a problem in the 1980s might be inadequate today. Furthermore, old methods of manually configuring hardware must continue to be supported today, or they may have left behind vestiges of themselves in today's hardware and software.

One consequence of these facts is that configuring PC hardware can be difficult. Adding a new card or other device can sometimes break a working computer, and the many different types of hardware can lead to confusion. This task examines how you can learn about your hardware from within Linux in order to avoid problems when adding new hardware. The next task expands on this topic and looks at troubleshooting procedures.


To prepare for planned system upgrades, you must create an inventory of hardware in your computer, including the resources this hardware consumes. This inventory will enable you to decide what additional hardware you can add, as well as any secondary upgrades you might need to support the ones you plan (for instance, whether you need to add a new disk controller to support additional hard drives).

Scope of Task

This task involves running commands that report on system status, examining configuration and log files, and examining the contents of files in the /proc pseudo-filesystem.


This task should take about half an hour to complete. If you need to obtain a specific piece of information in the future, you should be able to do so in a few seconds to a few minutes once you're familiar with the files and utilities in question.


To prepare for this task, log into your Linux computer. Because some of these commands require rootaccess, you may want to open two sessions, one as a regular user and one as root; or you can switch back and forth or run all the commands as root(although the latter option increases the risks involved in performing this task). Having a working printer will enable you to easily create a hard copy of some of the configuration files and text output created by the commands described in this task.


The usual caveats concerning root access to the computer apply to the parts of this task that require this access.

Some of the commands and procedures described here don't give a complete accounting of the resources used by your computer unless all the relevant drivers are loaded. Thus, it's possible your hardware inventory will be missing some items. You should have a general idea of what hardware is already installed and be able to activate that hardware before taking your inventory.


This task involves looking up data in two basic ways. First, you'll check system resources used by (optimally) all the hardware installed in your system. Second, you'll check information resources devoted to specific types of devices and for the system generally.

Checking IRQs

IRQs were mentioned earlier, in Task 2.1. Early PCs supported just eight IRQ lines, numbered 0 to 7. Each device, in the form of motherboard features or plug-in Industry Standard Architecture (ISA) card, used a single IRQ. Later PCs expanded the number of IRQs to 15, numbered 0 to 15 (IRQ 2 serves as an interface to the higher IRQs, with IRQ 9 serving as a substitute for IRQ 2). The latest designs support larger numbers of IRQs—typically 24 or more. Each hardware device, such as a hard disk controller, sound card, or USB port, uses a single interrupt line to signal the CPU when it needs attention. Hardware connected to these devices, such as individual hard disks or USB devices (printers, mice, and so on), don't need IRQs themselves; they communicate with their controllers, which in turn communicate with the CPU.

IRQs are limited in number. Particularly on older computers that use the ISA bus, IRQs shouldn't be shared between devices. Modern computers can usually share IRQs between devices without problems.

IRQs are assigned by jumpers or dip switches on older cards or motherboards or automatically via Plug and Play (PnP) technology on newer ISA cards, Peripheral Component Interconnect (PCI) cards, and devices built into modern motherboards. When adding a device, it's best to assign it its own IRQ, either manually or by tweaking the way the motherboard or OS does so.

You can check which IRQs are currently in use by examining the contents of the /proc/ interrupts pseudo-file:

$ cat /proc/interrupts


 0: 503295414 
1: 272015 
8: 0 
9: 0 
14: 767672 
15: 4058 
16: 33306146 
17: 858835 
18: 112 
19: 5491622 
20: 48966520 
NMI: 58940 
LOC: 503233990 
ERR: 0 
MIS: 0 

timeri8042rtcacpiide0ide1eth0, nvidialibatasym53c8xxuhci_hcd:usb1, uhci_hcd:usb2, ehci_hcd:usb3VIA8237

This command's output shows that several devices are consuming IRQs. Some of these, such as timer (IRQ 0) and rtc (IRQ 8), are motherboard devices. Others, such as nvidia (IRQ 16) and sym53c8xx (IRQ 18), are plug-in cards. Knowing which is which is a matter of knowing the hardware in your system.

In this example, two IRQs are shared: 16 (eth0 and nvidia) and 19 (three USB controllers). This example system is a fairly modern x86-64 system that can handle such IRQ sharing, so this isn't a problem.

Notably absent from this output are IRQs for some standard devices, such as the floppy controller, RS-232 serial ports, and parallel printer port. The reason for their absence is that these devices had not been accessed when the command was issued. If a device is used (say, by mounting a floppy disk), its entry will appear in subsequent accesses of /proc/interrupts. Thus, if you don't use a device, its entry might not appear in /proc/interrupts but it could still claim its interrupt at some future time. In creating an inventory of used IRQs, you should take this fact into consideration and use every device that your system contains before creating your inventory. Table 2.1 summarizes some of the common IRQs and their uses. This table omits IRQs for some common modern devices, such as USB ports, which are likely to map to different IRQs on different systems.

TABLE 2.1 IRQs and Their Common Uses

IRQ Typical Use Notes
0 System timer Reserved for internal use.
1 Keyboard Reserved for keyboard use only.
2 Cascade for IRQs 8–15 The original x86 IRQ-handling circuit can manage just 8 IRQs; 2 are tied together to handle 16 IRQs, but IRQ 2 must be used to handle IRQs 8–15
3 Second RS-232 serial port (COM2: in Windows) May also be shared by a fourth RS-232 serial port.
4 First RS-232 serial port (COM1:in Windows) May also be shared by a third RS-232 serial port.
5 Sound card or second parallel port (LPT2: in Windows)
6 Floppy disk controller Reserved for the first floppy disk controller.
7 First parallel port (LPT1: in Windows)
8 Real-time clock Reserved for system clock use only.
9 Open interrupt
10 Open interrupt
11 Open interrupt
12 PS/2 mouse
13 Math coprocessor Reserved for internal use.
14 Primary ATA controller The controller for ATA devices such as hard drives; typically /dev/hda and /dev/hdb under Linux.
15 Secondary ATA controller The controller for more ATA devices; typically /dev/ hdc and /dev/hdd under Linux.

To create an IRQ inventory, copy /proc/interrupts to a file in your home directory or print it. On most systems, typing cat /proc/interrupts | lpr will do the trick.

Checking I/O Addresses

I/O addresses are similar to IRQs in that the PC architecture supports a limited number of them and most devices require an I/O address for communication with the CPU. There are, however, more I/O addresses than IRQs, so conflicts for I/O addresses are rarer than are IRQ conflicts. You can learn about your used I/O addresses by examining the /proc/ioports pseudo-file; so copy it to a file in your home directory or print it:

$ cat /proc/ioports | lpr

Many of the same caveats that apply to /proc/interruptsalso apply to /proc/ioports. In particular, demand for an I/O port might not show up until after a device is used. Table 2.2 summarizes some of the more common I/O ports; however, this table is incomplete, particularly with respect to more modern devices with less fixed I/O port addresses.

TABLE 2.2 Common Linux Devices Linux Device Windows Name Typical IRQ I/O Address /dev/ttyS0 COM1 4 0x03f8 /dev/ttyS1 COM2 3 0x02f8 Page 66 Monday, September 18, 2006 8:58 AM 66 Phase 2 Managing Hardware and the Kernel TABLE 2.2 Common Linux Devices (continued) Linux Device Windows Name Typical IRQ I/O Address /dev/ttyS2 COM3 4 0x03e8 /dev/ttyS3 COM4 3 0x02e8 /dev/lp0 LPT1 7 0x0378-0x037f /dev/lp1 LPT2 5 0x0278-0x027f /dev/fd0 A: 6 0x03f0-0x03f7 /dev/fd1 B: 10 0x0370-0x0377

Checking DMA Channels

Direct memory addressing (DMA) is an alternative method of communication to I/O ports. Rather than have the CPU mediate the transfer of data between a device and memory, DMA permits the device to transfer data directly, without the CPU's attention. The result can be lower CPU requirements for I/O activity, which can improve overall system performance.

To support DMA, the x86 and x86-64 architectures implement several DMA channels, each of which can be used by a particular device. To learn what DMA channels are in use on your system, examine the /proc/dma file:

$ cat /proc/dma
3: parport0 
4: cascade

This output indicates that DMA channels 3 and 4 are in use. As with IRQs and I/O ports, DMA channels should not normally be shared. In practice, DMA channel conflicts are rarer than IRQ conflicts, so chances are you won't run into problems. Copy or print the contents of /proc/dma on your system to preserve a record of this information.

Checking Hard Disk Data

The /procfilesystem provides a way to learn about your PATA hard drives: the /proc/ide directory tree. This directory contains several subdirectories, but the simplest way to get at the data you want is to use the symbolic links that are named after your hard drives, such as /proc/ide/hdafor the master drive on the primary controller or /proc/ide/hddfor the slave drive on the secondary controller. These symbolic links point to directories that contain several files each, such as model(the hard drive's model number), settings(many low-level settings), capacity (the drive's size in 512-byte blocks), and driver (the name and version number of the Linux driver that's responsible for the drive). You can examine these files by using cat or less:

$ cat /proc/ide/hda/driver 
ide-disk version 1.188

Although the /proc/idedirectory tree provides useful information, it's not always the best way to learn about your disk devices. One good alternative is the hdparmutility, which enables you to read or set various hard disk options. To obtain a summary of information on your drive, use the -i option as root.

# hdparm -i /dev/hda 


 Model=WDC WD600AB-32BVA0, FwRev=21.01H21, SerialNo=WD-WMA7E1272684



 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off



 PIO modes: pio0 pio1 pio2 pio3 pio4

 DMA modes: mdma0 mdma1 mdma2

 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5

 AdvancedPM=no WriteCache=enabled


signifies the current active mode

This command returns a wide range of basic information, including the drive's model, firmware revision, serial number, cylinder/head/sector (CHS) counts, buffer size, access modes supported (PIO, DMA, and UDMA), and more. Even if most of this information is like Greek to you, having a record of it should be useful, so save it to a file or print it for future reference.

Unfortunately, both the /proc/ide directory tree and hdparm are useful only for PATA drives or for SATA drives that are managed by drivers in the PATA section of the Linux kernel. For SCSI drives and SATA drives that are handled by drivers in the SCSI section of the Linux kernel, less information is available through these methods. There is a /proc/scsi directory tree, but its contents are more concerned with the SCSI host adapter than with the devices it handles.

For both PATA and SCSI devices (including SCSI-driven SATA drives), you can obtain some basic information and data on drive partitioning by using the fdisk utility's -l option as root, which displays the partition table on the drive:

# fdisk -l /dev/sdb 

Disk /dev/sdb: 81.9 GB, 81964302336 bytes 
16 heads, 63 sectors/track, 158816 cylinders 
Units = cylinders of 1008 * 512 = 516096 bytes

 Device Boot Start End Blocks Id System 
/dev/sdb1 1 9689 4883224+ a5 FreeBSD 
/dev/sdb2 9690 158816 75160008 5 Extended 
/dev/sdb5 9690 13565 1953472+ c W95 FAT32 (LBA) 
/dev/sdb6 13566 15504 977224+ 83 Linux 
/dev/sdb7 15505 60073 22462744+ 8e Linux LVM 
/dev/sdb8 60074 158816 49766440+ 8e Linux LVM

PATA drives have drive identifiers of the form /dev/hdx, where x is a letter from a onward. SCSI drives have identifiers of the form /dev/sdx, where x is a letter from aonward. SATA drive identifiers can take either form, depending on the driver that handles the SATA controller.

The partition information can be useful in certain disaster recovery situations. It can also be helpful if you need to add, remove, or otherwise modify your partitions. For these reasons, you should archive this information to a file or print it. Phase 5 describes Linux partition management in greater detail.

Checking PCI and USB Data

Modern computers use the PCI bus to connect most devices. Even devices that are built into the motherboard, such as USB controllers, are likely to use the PCI bus internally. You can learn about PCI devices from the /proc/pci pseudo-file. Much of the information retrieved from this pseudo-file will seem meaningless to you unless you're a hardware expert; nonetheless, it can prove useful in debugging problems, once you learn what certain key things mean. Thus, you should copy this pseudo-file or print it out for future reference.

The /proc/bus/usb/devices pseudo-file holds information on USB devices. As with the /proc/pci pseudo-file, much of the information will seem like gibberish, but it's worth saving. With the USB information, though, you may at least be able to spot manufacturer names or device model numbers.

Checking Kernel Messages

When Linux boots, it displays a large number of messages about the hardware it finds. These messages scroll by so quickly that you're unlikely to be able to read them; however, you can review them by typing dmesg | lessor print them by typing dmesg | lpr. The dmesgcommand displays the contents of the kernel ring buffer, where kernel messages are stored. This buffer is of limited size, and as the system continues to operate, the kernel is likely to place additional messages in this buffer. Thus, your original kernel messages may scroll out of the buffer in time. Some distributions store a copy of the kernel ring buffer as it existed when the computer first booted in a log file, such as /var/log/dmesg.

You should review your kernel ring buffer to familiarize yourself with the messages it contains. You needn't study every detail, but try to spot information on important subsystems, such as your hard disk, so that you know what types of messages to expect from a working system. In the event of hardware problems, the kernel ring buffer can be an invaluable resource. You might find that hardware isn't detected (no mention of it appears in the ring buffer), or you might spot error messages relating to the hardware in the ring buffer.

Criteria for Completion

To complete this task, you should create a disk file or set of printouts that includes information on several hardware features:

. Used IRQs . Used I/O addresses . Used DMA channels Low-level hard disk information (for PATA disks) Disk formatting information PCI summary information .

USB summary information You should also review your kernel ring buffer messages and be familiar with the basic format of these messages.


Managing Linux hardware and the kernel
  Home: Introduction
 Part 1: Set BIOS Options for Linux: task 2.1
 Part 2: Know the hardware in your computer, task 2.2
 Part 3: Resolve hardware conflicts, task. 2.3
 Part 4: Configure USB devices to Linux, task. 2.4
 Part 5: Configure Linux Disk Drive, task 2.5
 Part 7: Use Linux power management features, task 2.7
 Part 8: Configure X options for Linux, task 2.8
 Part 9: Manage X logins for Linux, task 2.9

This was first published in January 2007

There are Comments. Add yours.


REGISTER or login:

Forgot Password?
Sort by: OldestNewest

Forgot Password?


Your password has been sent to: