2021 Call for Code Awards: Live from New York, with SNL’s Colin Jost! Learn more

Learn Linux, 101: Configure hardware settings


In this tutorial, learn to configure and check the hardware for your Linux system. Learn to:

  • Enable and disable integrated peripherals
  • Distinguish different types of mass storage devices
  • Know what hardware resources devices use
  • Use tools to list and manipulate devices, including USB devices
  • Understand sysfs, procfs, udev, and dbus

Computer hardware

Today’s computers have come a long way from the IBM PCs introduced in 1981. Apart from massive increases in speed, memory, and storage capabilities, perhaps the most notable changes have been in configuration and setup. In this tutorial, I cover some common hardware settings that you might make on current computers, and I explore the commands that Linux has for listing and managing hardware.

This tutorial helps you prepare for Objective 101.1 in Topic 101 of the Linux Server Professional (LPIC-1) exam 101. The objective has a weight of 2.


To get the most from the tutorials in this series, you need a basic knowledge of Linux and a working Linux system on which you can practice the commands that are covered in this tutorial. Sometimes different versions of a program format output differently, so your results might not always look exactly like the listings and figures that are shown here. The examples in this tutorial come from 64-bit systems with traditional Basic Input-Output Services (BIOS) or with the newer Universal Extensible Firmware Interface (UEFI).

Hardware settings

You usually configure settings by using either BIOS or UEFI firmware. Unless a setting is specific to UEFI, I use the term BIOS settings to cover both BIOS and UEFI settings.

You can access BIOS settings when you turn on your computer. Usually you do this by pressing a key such as Del, F1, or F8 after turning on the computer but before the operating system load starts. As machines have become faster and solid-state drives (SSDs) have reduced boot time to a few seconds, you might find that your system has a special button or key sequence to use. Check your system documentation to find out how to access the BIOS settings. The examples that are shown here illustrate the kinds of settings you might find, but the actual layout of your BIOS interface will probably be different from mine.

Figure 1 shows an example of a BIOS main screen for a system that I built. On this screen, you can change the system date and time. You can also change parameters for the legacy floppy drive if you have one. You also see the summary of installed drives. My system has only SATA drives, although IDE drives are also supported through the on-board controllers.

Figure 1. BIOS main screen with date and time settings
Screenshot of a BIOS main screen with date and time settings

View larger image

If your system supports legacy peripheral interfaces, you might have a place to configure them. In my case, I can use the Advanced menu to configure the serial and parallel port interrupt requests (IRQs) and I/O port starting addresses. Figure 2 shows the advanced settings for my system. In addition to configuring the legacy serial and parallel ports, note that I can enable or disable the on-board LAN and 1394 (FireWire) controllers. Note that the LAN controller also has a boot ROM that I have disabled. You enable the boot ROM if you want the system to load over a LAN from a remote server. You might want this for a kiosk machine or for reimaging a large number of systems.

Figure 2. Configuring serial, parallel, and on-board devices with BIOS
Screenshot of configuring serial, parallel and on-board devices with BIOS

Your BIOS can also have settings that you can use to boot without a keyboard or mouse. When there is a boot error or maybe a change in configuration (such as the addition of memory), many systems — particularly older ones — require you to press a key to enter BIOS setup. What happens if the system has no keyboard? Today, you might plug in a Universal Serial Bus (USB) keyboard, but older systems with PS2 keyboard connectors could sometimes be damaged when a keyboard was plugged in. So, on many BIOS systems, you can disable either the keyboard itself or the warning that you might get if the keyboard is not present. I have a keyboard on my system, so my Wait for ‘F1’ If Error setting is enabled, as shown in Figure 3.

Figure 3. Disabling keyboard or keyboard boot error with BIOS
Screenshot of disabling keyboard or keyboard boot error with BIOS

Another important setting that you might need to make is the order of boot devices. As shown in Figure 4, my system is set to check the first floppy drive, then the first SATA drive, and finally a CD or DVD. I haven’t had a working floppy drive for several years, so I could probably safely drop it from the sequence. If my hard drive isn’t working, I have the CD or DVD as a backup. See the tutorial “Learn Linux, 101: Boot the system” for information on how to choose the CD or DVD if you want to boot from it only once.

Figure 4. Configuring boot device order with BIOS
Screenshot of configuring boot device order with BIOS

For UEFI systems, many settings are similar to those for traditional BIOS, including date, time, and whether on-board devices are enabled or not. Figure 5 shows an example from a Lenovo Yoga 2 Pro.

Figure 5. Configuring date, time, and on-board devices with UEFI
Screenshot of configuring date, time, and on-board devices with UEFI

One major difference with UEFI systems is, of course, support for UEFI booting. Your system might support UEFI-only booting or it might also support legacy BIOS-like booting. My system has a Boot Mode parameter with two choices, as shown in Figure 6. When I choose Legacy Support, I can boot a legacy system or a UEFI system. My system will only boot UEFI systems if I choose UEFI.

Figure 6. Choosing UEFI boot mode
Screenshot of choosing UEFI boot mode

If you select UEFI-only booting, then you will probably not see some items that are related to legacy support, such as the legacy USB support option that you saw in Figure 5. You will also probably have options for support of secure boot, which allows only signed binaries to be booted. Figure 7 shows some of the security options that you might see if you select UEFI-only booting. On my system, there are both status values and options that you can change. For example, the Platform Mode setting of User confirms that security keys have been installed. If no keys are installed, the value is likely to be Setup instead. I can use the Reset to Setup Mode to install new keys, or I can use the Restore Factory Keys to restore the preinstalled factory keys.

Figure 7. Secure boot options with UEFI
Screenshot of secure boot options with UEFI

Mass storage devices

Computers use several types of mass storage, and this storage can be attached in various ways. Today, most mass storage devices use standard interfaces, and either the device is detected when connected or the BIOS configuration is mostly automatic. Later in this tutorial, you’ll see how to determine which resources a device needs. For now, let’s look at the different types of common mass storage devices.

Hard drives

The hard drive has been the workhorse of data storage on PCs since the early 1980s. Hard drives come in a sealed unit and contain several recording surfaces or platters. The ST-506 introduced in 1980 had a 5MB capacity and used a controller card to translate requests from the computer to the internal commands needed to access the data on the disk platters. In 1984, IBM introduced the IBM PC/AT computer with a 16-bit AT bus, later known as an Industry Standard Architecture (ISA) bus. The AT attachment interface (ATA) standardized the interface between the controller card and the computer, preserving compatibility with the ST-506 command set. In the early 1980s, Western Digital moved the controller function inside the drive housing under the name Integrated Drive Electronics (IDE). You will find several later standards and terms, including ATA-1, ATA-2, ATA-4, and EIDE, among others. When Serial ATA (SATA) was introduced in 2003, the original ATA interface became known as Parallel ATA (PATA).

Another popular disk-attachment interface is the Small Computer System Interface (SCSI). SCSI was developed around 1978 for attaching various devices, including hard drives and printers. SCSI disks are still popular in larger servers.

The original ATA interface was designed for hard drives. The ATA interface was extended to the ATA Packet Interface (ATAPI) for use with other devices, such as floppy drives, Zip drives, or CD drives. ATAPI added capability to detect media presence, or eject media, among other features not needed for a normal hard drive. The ATAPI interface can carry SCSI commands in packets and thus support various device types.

Today, internal hard drives usually use either SCSI or SATA attachment. Drives can also be attached externally using USB, IEE-1394 (FireWire), External Serial Advanced Technology Attachment (eSATA), or Apple’s Thunderbolt.

Hard drives can be partitioned to divide their space for different uses, and they can be combined into arrays for redundancy. Hard drives can also be grouped together using tools such as Logical Volume Manager to make several smaller disks appear as one or more larger ones.

CD and DVD drives

CD, DVD, and Blu-Ray drives use optical storage to hold much more data than a floppy drive. Early CD drives were often attached through a sound card, and the interfaces were many and varied. Later CD and then DVD drives standardized on the ATAPI interface. Today, you will find CD drives internally connected using SATA, or externally connected using the same kinds of interfaces used for hard drives. Software packages are often distributed on CD or DVD, which were initially read-only media. Now, using devices and media, users can create (burn) their own CDs and DVDs for backup or data storage.

Flash or thumb drives

Perhaps the most common means of exchanging data today is the flash or thumb drive. These drives use nonvolatile RAM to store data. They are much more reliable, faster, and higher-capacity than floppy disks and can be reused many times, unlike CD or DVD media. Most are about the size of a human thumb — hence the name — and usually attach to a USB port. Most support USB 2.0, which has a maximum speed of 480Mbps. Newer devices support USB 3.0 with a speed of up to 5Gbps. At the time of writing, typical sizes range from 1GB to 256GB, with a few larger 512GB and 1TB models available. You can partition thumb drives like hard drivesa. If you download a new Linux distribution, you might burn it to a USB thumb drive so you can install it from that device.

Solid-state drives

Solid-state drives (SSDs) are a newer form of drive that is being used in many notebook computers. Compared to the traditional hard drive, SSDs are lighter and faster, use less power, and do not suffer from mechanical failure. Initially, SSDs were often housed like 2.5-inch notebook drives and used the same SATA interfaces. To handle even thinner laptops, a variant called mini-SATA or mSATA was developed. The connector is smaller than a standard SATA connector and drives are approximately 1 inch by 2 inch and very thin.

Next Generation Form Factor (NGFF) SSDs were developed to replace mSATA. They are essentially similar to SATA drives but use a new connector known as M.2. The M.2 connector supports USB and PCI Express (PCIe) devices if the motherboard supports these. Earlier motherboards may only support NGFF M.2 devices.

SATA interfaces can limit the theoretical capabilities of an SSD. A newer attachment called NVM Express (NVMe) has been developed for PCIe-based SSDs. The specification is designed to better use SSDs over PCIe. These also use the M.2 connector and may operate at SATA speeds or even faster PCIe speeds.

Virtual files for hardware and system information

Several virtual filesystems provide an in-memory look at your system as the kernel sees it. These filesystems are virtual in the sense that no real files exist on storage devices. Rather, the virtual filesystems provide insight into kernel data structures and into your system hardware.

Sysfs and /sys

Sysfs is a virtual filesystem that the Linux kernel uses to export information about kernel objects to processes running in user space. It was introduced in the 2.6 kernel and was originally derived from ramfs, which dated from the 2.4 kernel. As a virtual filesystem, sysfs is an in-memory filesystem that is mounted at /sys. If it is not mounted during initialization by an entry in /etc/fstab, you can always mount it using the command:

mount ‑t sysfs sysfs /sys

Sysfs is a simple filesystem with files that represent object attributes. The objects themselves are represented by directories. Symbolic links represent relationships between objects. The top-level directories in sysfs represent major subsystems. Listing 1 shows examples of the top-level /sys directory and the /sys/bus and /sys/devices directories.

Listing 1. Some entries from the sysfs filesystem

[ian@atticf22 ~]$ ls /sys
block  class  devices   fs          kernel  power
bus    dev    firmware  hypervisor  module
[ian@atticf22 ~]$ ls /sys/bus
acpi         edac          i2c           mipi‑dsi     platform  usb
clockevents  event_source  machinecheck  node         pnp       usb‑serial
clocksource  firewire      mdio_bus      pci          scsi      workqueue
container    hdaudio       media         pci_express  serio     xen
cpu          hid           memory        pcmcia       snd_seq   xen‑backend
[ian@atticf22 ~]$ ls /sys/devices/
breakpoint  ibs_fetch  LNXSYSTM:00  platform  software  tracepoint
cpu         ibs_op     pci0000:00   pnp0      system    virtual

If you look at /sys/block, you find your block devices. In my case, I have three hard drives — sda, sdb, and sdc — and one CD/DVD drive: sr0. These are actually links to directories under the /sys/devices directory. If you follow these links, you find the partitions of sda. Looking at the size file, you see that the disk has 2,040,192 sectors, a value confirmed by fdisk -lfdisk-l, as illustrated in Listing 2.

Listing 2. Block devices in /sys

[ian@atticf22 ~]$ ls /sys/block
sda  sdb  sdc  sr0
[ian@atticf22 ~]$ ls ‑l /sys/block
total 0
lrwxrwxrwx. 1 root root 0 Sep  9 12:11 sda ‑> 
lrwxrwxrwx. 1 root root 0 Sep  9 12:11 sdb ‑> 
lrwxrwxrwx. 1 root root 0 Sep  9 12:11 sdc ‑> 
lrwxrwxrwx. 1 root root 0 Sep 10 20:30 sr0 ‑> 
[ian@atticf22 ~]$ ls /sys/"devices/pci0000:00/0000:00:11.0/ata1/host0/target0:0:0/0:0:0:0/block/sda"
alignment_offset   events             power      sda10  sda5  slaves
bdi                events_async       queue      sda11  sda6  stat
capability         events_poll_msecs  range      sda12  sda7  subsystem
dev                ext_range          removable  sda2   sda8  trace
device             holders            ro         sda3   sda9  uevent
discard_alignment  inflight           sda1       sda4   size
[ian@atticf22 ~]$ ls /sys/"devices/pci0000:00/0000:00:11.0/ata1/host0/target0:0:0/0:0:0:0/block/sda"/sda1
alignment_offset  discard_alignment  inflight   power  size   stat       trace
dev               holders            partition  ro     start  subsystem  uevent
[ian@atticf22 ~]$ cat 
> /sys/"devices/pci0000:00/0000:00:11.0/ata1/host0/target0:0:0/0:0:0:0/block/sda"/sda1/size
[ian@atticf22 ~]$ su ‑
root@atticf22 ~fdisk ‑l /dev/sda1
Disk /dev/sda1: 996.2 MiB, 1044578304 bytes, 2040192 sectors

Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos

The tree command is a useful tool for exploring /sys. Note also that you have to escape special characters such as the colon (:) by enclosing them in quotation marks or using the backslash (\) character.

procfs and /proc

The procfs filesystem provides insight into many of the kernel data structures and even allows a few to be changed on the fly. procfs is usually mounted at /proc. Listing 3 shows a listing of /proc on my system.

Listing 3. Listing of /proc

[ian@atticf22 ~]$ ls /proc
1     1274  1891  2155  254   460   559   7651       devices      mtrr
10    1278  19    2160  255   468   56    768        diskstats    net
107   1281  1903  2174  256   47    562   7745       dma          pagetypeinfo
1080  1287  1947  2185  257   48    565   7885       driver       partitions
1083  13    1951  22    26    488   57    799        execdomains  sched_debug
11    1326  1952  2243  2604  490   570   8          fb           scsi
1120  14    1957  2261  2650  495   585   8077       filesystems  self
1121  15    1959  2264  266   496   588   8159       fs           slabinfo
1144  1548  1971  2289  27    5     590   8182       interrupts   softirqs
1181  1557  1990  23    2711  50    599   8189       iomem        stat
1187  1561  1996  2310  28    51    603   859        ioports      swaps
1192  1591  1999  2327  285   512   6243  9          irq          sys
1195  1659  2     2338  286   513   64    940        kallsyms     sysrq‑trigger
1199  1662  20    2341  29    517   66    942        kcore        sysvipc
12    17    2040  2342  3     518   669   947        keys         thread‑self
1206  1728  2046  24    30    52    67    949        key‑users    timer_list
1226  1734  2052  2438  31    53    68    973        kmsg         timer_stats
1230  1789  2057  2440  32    539   6896  acpi       kpagecount   tty
1232  1792  21    2442  33    54    69    asound     kpageflags   uptime
1243  1796  2111  2444  36    548   7     buddyinfo  loadavg      version
1246  18    2117  2448  37    549   749   bus        locks        vmallocinfo
1249  1804  2119  25    375   55    7505  cgroups    mdstat       vmstat
1254  1808  2122  250   392   551   751   cmdline    meminfo      zoneinfo
1256  1828  2126  251   407   5525  753   consoles   misc
1265  1836  2133  252   411   553   759   cpuinfo    modules
1269  1853  2153  253   459   557   762   crypto     mounts

You see a large number of numbered directories — one for each running process on your system. The number is the process ID (PID). Listing 4 shows the first few entries for a running bash command prompt (PID=$$ — the current PID). Note that almost all entries in the procfs filesystem have a length of 0, even though they might not be empty and you can see data if you use the cat command. Most entries are not terminated with a newline character, so I use the echo command in Listing 4 for clarity.

Listing 4. Showing /proc entries for the current process

[ian@atticf22 ~]$ ls ‑l /proc/$$/ | head ‑n 15
total 0
dr‑xr‑xr‑x. 2 ian ian 0 Sep 10 22:44 attr
‑rw‑r‑‑r‑‑. 1 ian ian 0 Sep 10 22:44 autogroup
‑r‑‑‑‑‑‑‑‑. 1 ian ian 0 Sep 10 22:44 auxv
‑r‑‑r‑‑r‑‑. 1 ian ian 0 Sep 10 22:44 cgroup
‑‑w‑‑‑‑‑‑‑. 1 ian ian 0 Sep 10 22:44 clear_refs
‑r‑‑r‑‑r‑‑. 1 ian ian 0 Sep 10 20:35 cmdline
‑rw‑r‑‑r‑‑. 1 ian ian 0 Sep 10 22:44 comm
‑rw‑r‑‑r‑‑. 1 ian ian 0 Sep 10 22:44 coredump_filter
‑r‑‑r‑‑r‑‑. 1 ian ian 0 Sep 10 22:44 cpuset
lrwxrwxrwx. 1 ian ian 0 Sep 10 22:44 cwd ‑> /home/ian
‑r‑‑‑‑‑‑‑‑. 1 ian ian 0 Sep 10 22:44 environ
lrwxrwxrwx. 1 ian ian 0 Sep 10 20:35 exe ‑> /usr/bin/bash
dr‑x‑‑‑‑‑‑. 2 ian ian 0 Sep 10 20:08 fd
dr‑x‑‑‑‑‑‑. 2 ian ian 0 Sep 10 22:44 fdinfo
bash[ian@atticf22 ~]$ #Now display our command line
bash[ian@atticf22 ~]$ cat /proc/$$/cmdline;echo ""

The parameters that you can control by setting values in the procfs filesystem can also be controlled via the sysctl command. Refer to the sysctl and procfs man pages for more information.

The procfs filesystem also provides information about interrupt, Direct Memory Access (DMA), and I/O port resources used by your system.

Listing 5 shows the contents of /proc/interrupts on my system. Older single-processor computers using the ISA bus use certain well-known interrupts (or IRQs), I/O ports, and DMA resources. These were in limited supply, so adding a sound card that needed IRQ 5 might prevent use of a second parallel port that also needed IRQ 5. The PCI bus includes a capability for Message Signalling Interrupts (MSI), which has significantly eased the resource limitations found in older systems. ISA bus device interrupts are numbered from 0 through 15. This system does have a parallel printer port using IRQ7 but does not have serial ports, which normally use IRQ3 or IRQ 4. If you have error messages or a device that does not work and you suspect interrupt conflicts, looking at /proc/interrupts is a good place to start.

Listing 5. Listing of /proc/interrupts

[ian@atticf22 ~]$ cat /proc/interrupts 
           CPU0       CPU1       
  0:        133          0   IO‑APIC‑edge      timer
  1:          0          2   IO‑APIC‑edge      i8042
  7:          0          0   IO‑APIC‑edge      parport0
  8:          0          1   IO‑APIC‑edge      rtc0
  9:          0          0   IO‑APIC‑fasteoi   acpi
 12:          1          4   IO‑APIC‑edge      i8042
 14:          0          0   IO‑APIC‑edge      pata_atiixp
 15:        157     166172   IO‑APIC‑edge      pata_atiixp
 16:        752     764097   IO‑APIC  16‑fasteoi   ohci_hcd:usb3, ohci_hcd:usb4, snd_hda_intel
 17:        125      74351   IO‑APIC  17‑fasteoi   ehci_hcd:usb1, firewire_ohci
 18:          0          3   IO‑APIC  18‑fasteoi   ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7
 19:          4       1264   IO‑APIC  19‑fasteoi   ehci_hcd:usb2, snd_hda_intel
 22:        286     186458   IO‑APIC  22‑fasteoi   0000:00:11.0
 27:       1073    1250614   PCI‑MSI‑edge      enp3s0
 28:       7457   10965287   PCI‑MSI‑edge      nvkm

NMI:        850        888   Non‑maskable interrupts
LOC:   25779766   25467714   Local timer interrupts
SPU:          0          0   Spurious interrupts
PMI:        850        888   Performance monitoring interrupts
IWI:          0          2   IRQ work interrupts
RTR:          0          0   APIC ICR read retries
RES:   40628246   39894661   Rescheduling interrupts
CAL:        823        986   Function call interrupts
TLB:    1972576    2052293   TLB shootdowns
TRM:          0          0   Thermal event interrupts
THR:          0          0   Threshold APIC interrupts
MCE:          0          0   Machine check exceptions
MCP:        568        568   Machine check polls
HYP:          0          0   Hypervisor callback interrupts
ERR:          0
MIS:          0

DMA was a technique used in ISA bus systems whereby fast devices such as hard drives could transfer data to computer memory without involving the processor. DMA frees up the processor to do other work while the data is being read from or written to the device. The PCI bus architecture uses bus mastering to achieve a similar goal. Listing 6 shows the contents of /proc/dma on my system. If you have ISA bus resources, you usually see more than this, and you might need this information to help diagnose conflicts.

Listing 6. Listing of /proc/interrupts

[ian@atticf22 ~]$ cat /proc/dma
 4: cascade

Another resource list you can use to help resolve problems is the listing of I/O ports in /proc/ioports. Several I/O ports used in ISA bus systems are well known, such as the range 0378 to 037a usually used for the first parallel port. Note that the ports are specified in hexadecimal.

Listing 7. Listing of /proc/ioports

[ian@atticf22 ~]$ cat /proc/ioports
0000‑0cf7 : PCI Bus 0000:00
  0000‑001f : dma1
  0020‑0021 : pic1
  0040‑0043 : timer0
  0050‑0053 : timer1
  0060‑0060 : keyboard
  0061‑0061 : PNP0800:00
  0064‑0064 : keyboard
  0070‑0071 : rtc0
  0080‑008f : dma page reg
  00a0‑00a1 : pic2
  00c0‑00df : dma2
  00f0‑00ff : PNP0C04:00
    00f0‑00ff : fpu
  0170‑0177 : 0000:00:14.1
    0170‑0177 : pata_atiixp
  01f0‑01f7 : 0000:00:14.1
    01f0‑01f7 : pata_atiixp
  0230‑023f : pnp 00:07
  0290‑029f : pnp 00:07
  0300‑030f : pnp 00:07
  0376‑0376 : 0000:00:14.1
    0376‑0376 : pata_atiixp
  0378‑037a : parport0
  03c0‑03df : vga+
  03f6‑03f6 : 0000:00:14.1
    03f6‑03f6 : pata_atiixp
  03f8‑03ff : serial
  040b‑040b : pnp 00:06
  04d0‑04d1 : pnp 00:06
  04d6‑04d6 : pnp 00:06
  0800‑0803 : ACPI PM1a_EVT_BLK
  0804‑0805 : ACPI PM1a_CNT_BLK
  0808‑080b : ACPI PM_TMR
  0810‑0815 : ACPI CPU throttle
  0820‑0827 : ACPI GPE0_BLK
  08ff‑08ff : ACPI PM2_CNT_BLK
  0900‑090f : pnp 00:06
  0910‑091f : pnp 00:06
  0a30‑0a3f : pnp 00:07
  0b00‑0b3f : pnp 00:06
    0b20‑0b2f : pnp 00:06
  0c00‑0c01 : pnp 00:06
  0c14‑0c14 : pnp 00:06
  0c50‑0c51 : pnp 00:06
  0c52‑0c52 : pnp 00:06
  0c6c‑0c6c : pnp 00:06

  0c6f‑0c6f : pnp 00:06
  0cd0‑0cd1 : pnp 00:06
  0cd2‑0cd3 : pnp 00:06
  0cd4‑0cd5 : pnp 00:06
  0cd6‑0cd7 : pnp 00:06
  0cd8‑0cdf : pnp 00:06
0cf8‑0cff : PCI conf1
0d00‑ffff : PCI Bus 0000:00
  8000‑800f : 0000:00:11.0
    8000‑800f : ahci
  9000‑9003 : 0000:00:11.0
    9000‑9003 : ahci
  a000‑a007 : 0000:00:11.0
    a000‑a007 : ahci
  b000‑b003 : 0000:00:11.0
    b000‑b003 : ahci
  c000‑c007 : 0000:00:11.0
    c000‑c007 : ahci
  d000‑dfff : PCI Bus 0000:01
    dc00‑dc7f : 0000:01:00.0
  e000‑efff : PCI Bus 0000:03
    e800‑e8ff : 0000:03:00.0
      e800‑e8ff : r8169
  fe00‑fefe : pnp 00:06
  ff00‑ff0f : 0000:00:14.1
    ff00‑ff0f : pata_atiixp

The lsdev command

The procinfo package contains the lsdev command, which simplifies the presentation of the information from /proc by gathering the DMA, IRQ, and I/O port information for each device into a simple tabular format. Listing 8 shows the lsdev output for my system.

Listing 8. Output from lsdev

[ian@atticf22 ~]$ lsdev
Device            DMA   IRQ  I/O Ports
0000:00:11.0             22  8000‑800f 9000‑9003 a000‑a007 b000‑b003 c000‑c007
0000:00:14.1                 0170‑0177 01f0‑01f7 0376‑0376 03f6‑03f6 ff00‑ff0f
0000:01:00.0                 dc00‑dc7f
0000:03:00.0                 e800‑e8ff
acpi                      9 
ACPI                         0800‑0803 0804‑0805 0808‑080b 0810‑0815 0820‑0827 08ff‑08ff
ahci                         8000‑800f 9000‑9003 a000‑a007 b000‑b003 c000‑c007
cascade             4       
dma                          0080‑008f
dma1                         0000‑001f
dma2                         00c0‑00df
enp3s0                   27 
firewire_ohci            17 
fpu                          00f0‑00ff
i8042                  1 12 
keyboard                     0060‑0060 0064‑0064
nvkm                     28 
ohci_hcd:usb7            18 
parport0                  7  0378‑037a
pata_atiixp           14 15  0170‑0177 01f0‑01f7 0376‑0376 03f6‑03f6 ff00‑ff0f
PCI                          0000‑0cf7 0cf8‑0cff 0d00‑ffff d000‑dfff e000‑efff
pic1                         0020‑0021
pic2                         00a0‑00a1
pnp                          0230‑023f 0290‑029f 0300‑030f 040b‑040b 04d0‑04d1 04d6‑04d6 0900‑090f 
                             0910‑091f 0a30‑0a3f 0b00‑0b3f 0b20‑0b2f 0c00‑0c01 0c14‑0c14 0c50‑0c51 
                             0c52‑0c52 0c6c‑0c6c 0c6f‑0c6f 0cd0‑0cd1 0cd2‑0cd3 0cd4‑0cd5 0cd6‑0cd7 
                             0cd8‑0cdf fe00‑fefe
PNP0800:00                   0061‑0061
PNP0C04:00                   00f0‑00ff
r8169                        e800‑e8ff
rtc0                      8  0070‑0071
serial                       03f8‑03ff
snd_hda_intel         16 19 
timer                     0 
timer0                       0040‑0043
timer1                       0050‑0053
vga+                         03c0‑03df

The procinfo package also contains the procinfo command, which summarizes other information from /proc. Try it or see the man page for details.

udev and /dev

udev is responsible for the dynamic device management needed for hot plugging devices. Information about configured and active devices is contained in the /dev virtual filesystem. When a device is added to or removed from the system, or it changes state, the kernel sends an event to the systemd-udevd.service daemon, which manages udev events. The daemon searches configured rules to match the event with a rule to identify the device. The kernel usually assigns a name that is neither meaningful nor repeatable, so udev usually assigns a more meaningful and consistent name.

The udev rules are in /usr/lib/udev/rules.d, with additional local rules in /etc/udev/rules.d. You can create additional rules in the volatile /run/udev/rules.d directory. You can configure udev using the /etc/udev/udev.conf file. NOTE: Some systems place rules in /lib/udev/rules.d rather than /usr/lib/udev/rules.d. Check the udev man page on your system.

The /dev filesystem describes the devices on your system. In a long listing, you find one of four values in the first column:

Represents a block device such as a disk drive

Represents a character device such as a terminal or printer, or a special device such as null

Represents a directory

Represents a symbolic link to another directory of file, either in /dev, /proc, or /run

Listing 9 shows a partial listing of /dev on my system where you see examples of each type of entry.

Listing 9. Partial listing of /dev

[ian@atticf22 ~]$ ls ‑l /dev| head ‑n 60
total 0
crw‑‑‑‑‑‑‑. 1 root root     10, 235 Sep  9 12:11 autofs
drwxr‑xr‑x. 2 root root         620 Sep 11 06:05 block
drwxr‑xr‑x. 2 root root         140 Sep 11 06:05 bsg
crw‑rw‑‑‑‑. 1 root disk     10, 234 Sep  9 12:11 btrfs‑control
drwxr‑xr‑x. 3 root root          60 Sep  9 12:11 bus
lrwxrwxrwx. 1 root root           3 Sep  9 12:11 cdrom ‑> sr0
drwxr‑xr‑x. 2 root root        3820 Sep 11 09:59 char
crw‑‑‑‑‑‑‑. 1 root root      5,   1 Sep  9 12:12 console
lrwxrwxrwx. 1 root root          11 Sep  9 12:11 core ‑> /proc/kcore
drwxr‑xr‑x. 4 root root         100 Sep  9 12:11 cpu
crw‑‑‑‑‑‑‑. 1 root root     10,  62 Sep  9 12:11 cpu_dma_latency
drwxr‑xr‑x. 8 root root         160 Sep 11 06:05 disk
drwxr‑xr‑x. 2 root root         100 Sep  9 12:11 dri
crw‑rw‑‑‑‑. 1 root video    29,   0 Sep  9 12:11 fb0
lrwxrwxrwx. 1 root root          13 Sep  9 12:11 fd ‑> /proc/self/fd
crw‑rw‑rw‑. 1 root root      1,   7 Sep  9 12:11 full
crw‑rw‑rw‑. 1 root root     10, 229 Sep  9 14:46 fuse
crw‑‑‑‑‑‑‑. 1 root root    249,   0 Sep  9 12:11 fw0
crw‑‑‑‑‑‑‑. 1 root root    250,   0 Sep  9 12:11 hidraw0
crw‑‑‑‑‑‑‑. 1 root root    250,   1 Sep 11 09:59 hidraw1
crw‑‑‑‑‑‑‑. 1 root root     10, 228 Sep  9 12:11 hpet
drwxr‑xr‑x. 3 root root           0 Sep  9 12:11 hugepages
crw‑‑‑‑‑‑‑. 1 root root     10, 183 Sep  9 12:11 hwrng
lrwxrwxrwx. 1 root root          25 Sep  9 12:11 initctl ‑> /run/systemd/initctl/fifo
drwxr‑xr‑x. 4 root root         420 Sep 11 09:59 input
crw‑r‑‑r‑‑. 1 root root      1,  11 Sep  9 12:11 kmsg
crw‑rw‑rw‑+ 1 root kvm      10, 232 Sep  9 12:11 kvm
lrwxrwxrwx. 1 root root          28 Sep  9 12:11 log ‑> /run/systemd/journal/dev‑log
crw‑rw‑‑‑‑. 1 root disk     10, 237 Sep  9 12:11 loop‑control
crw‑rw‑‑‑‑. 1 root lp        6,   0 Sep  9 12:11 lp0
crw‑rw‑‑‑‑. 1 root lp        6,   1 Sep  9 12:11 lp1
crw‑rw‑‑‑‑. 1 root lp        6,   2 Sep  9 12:11 lp2
crw‑rw‑‑‑‑. 1 root lp        6,   3 Sep  9 12:11 lp3
drwxr‑xr‑x. 2 root root          60 Sep  9 12:11 mapper
crw‑‑‑‑‑‑‑. 1 root root     10, 227 Sep  9 12:11 mcelog
crw‑‑‑‑‑‑‑. 1 root root    247,   0 Sep  9 12:11 media0
crw‑r‑‑‑‑‑. 1 root kmem      1,   1 Sep  9 12:11 mem
crw‑‑‑‑‑‑‑. 1 root root     10,  59 Sep  9 12:11 memory_bandwidth
drwxrwxrwt. 2 root root          40 Sep  9 12:11 mqueue
drwxr‑xr‑x. 2 root root          60 Sep  9 12:11 net
crw‑‑‑‑‑‑‑. 1 root root     10,  61 Sep  9 12:11 network_latency
crw‑‑‑‑‑‑‑. 1 root root     10,  60 Sep  9 12:11 network_throughput
crw‑rw‑rw‑. 1 root root      1,   3 Sep  9 12:11 null
crw‑‑‑‑‑‑‑. 1 root root     10, 144 Sep  9 12:11 nvram
crw‑rw‑r‑‑. 1 root lp       99,   0 Sep  9 12:11 parport0
crw‑r‑‑‑‑‑. 1 root kmem      1,   4 Sep  9 12:11 port
crw‑‑‑‑‑‑‑. 1 root root    108,   0 Sep  9 12:11 ppp
crw‑rw‑rw‑. 1 root tty       5,   2 Sep 11 10:33 ptmx
drwxr‑xr‑x. 2 root root           0 Sep  9 12:11 pts
crw‑rw‑rw‑. 1 root root      1,   8 Sep  9 12:11 random
drwxr‑xr‑x. 2 root root          60 Sep  9 12:11 raw
crw‑rw‑r‑‑+ 1 root root     10,  58 Sep  9 14:46 rfkill
lrwxrwxrwx. 1 root root           4 Sep  9 12:11 rtc ‑> rtc0
crw‑‑‑‑‑‑‑. 1 root root    254,   0 Sep  9 12:11 rtc0
brw‑rw‑‑‑‑. 1 root disk      8,   0 Sep  9 12:11 sda
brw‑rw‑‑‑‑. 1 root disk      8,   1 Sep  9 12:11 sda1
brw‑rw‑‑‑‑. 1 root disk      8,  10 Sep  9 12:11 sda10
brw‑rw‑‑‑‑. 1 root disk      8,  11 Sep  9 12:11 sda11
brw‑rw‑‑‑‑. 1 root disk      8,  12 Sep  9 12:11 sda12

Listing 10 shows the linkage between some kernel-assigned names and some more-familiar names for hard-drive partitions.

Listing 10. Symbolic links to familiar hard drive names

[ian@atticf22 ~]$ ls ‑l /dev/block/8\:?
lrwxrwxrwx. 1 root root 6 Sep  9 12:11 /dev/block/8:0 ‑> ../sda
lrwxrwxrwx. 1 root root 7 Sep  9 12:11 /dev/block/8:1 ‑> ../sda1
lrwxrwxrwx. 1 root root 7 Sep  9 12:11 /dev/block/8:2 ‑> ../sda2
lrwxrwxrwx. 1 root root 7 Sep  9 12:11 /dev/block/8:3 ‑> ../sda3
lrwxrwxrwx. 1 root root 7 Sep  9 12:11 /dev/block/8:4 ‑> ../sda4
lrwxrwxrwx. 1 root root 7 Sep  9 12:11 /dev/block/8:5 ‑> ../sda5
lrwxrwxrwx. 1 root root 7 Sep  9 12:11 /dev/block/8:6 ‑> ../sda6
lrwxrwxrwx. 1 root root 7 Sep  9 12:11 /dev/block/8:7 ‑> ../sda7
lrwxrwxrwx. 1 root root 7 Sep  9 12:11 /dev/block/8:8 ‑> ../sda8
lrwxrwxrwx. 1 root root 7 Sep  9 12:11 /dev/block/8:9 ‑> ../sda9

If you want to manage or monitor udev events, you can use the udevadm command. See the man pages for more information.

Tools and utilities

Some useful tools are available for determining information about your PCI and USB devices. Let’s look at lspci and lsusb.

PCI and lspci

Use lspci without options to see a basic listing of your PCI devices. What you see depends on your own system hardware. Listing 11 shows the Fedora 22 desktop system that I have been using for most of this tutorial.

Listing 11. Using lspci to display desktop PCI devices

[ian@atticf22 ~]$ #Fedora 22
[ian@atticf22 ~]$ lspci
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] RS780 Host Bridge
00:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] RS780 PCI to PCI bridge (ext gfx port 0)
00:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] RS780/RS880 PCI to PCI bridge (PCIE port 1)
00:06.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] RS780 PCI to PCI bridge (PCIE port 2)
00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller 
        IDE mode00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:12.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB OHCI1 Controller
00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:13.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB OHCI1 Controller
00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus Controller (rev 3a)
00:14.1 IDE interface: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 IDE Controller
00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 LPC host controller
00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 PCI to PCI Bridge
00:14.5 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI2 Controller
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor HyperTransport 
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Address Map
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Link Control
01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 610] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GF119 HDMI Audio Controller (rev a1)
02:00.0 FireWire (IEEE 1394): JMicron Technology Corp. IEEE 1394 Host Controller
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit 
        Ethernet Controller (rev 02)

Listing 12 shows a Ubuntu 15.04 system running on a Lenovo Yoga 2 Pro notebook.

Listing 12. Using lspci to display notebook PCI devices

ian@ubuntu:~$ #Ubuntu 15.04
ian@ubuntu:~$ lspci
00:00.0 Host bridge: Intel Corporation Haswell‑ULT DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Haswell‑ULT Integrated Graphics Controller (rev 09)
00:03.0 Audio device: Intel Corporation Haswell‑ULT HD Audio Controller (rev 09)
00:04.0 Signal processing controller: Intel Corporation Device 0a03 (rev 09)
00:14.0 USB controller: Intel Corporation 8 Series USB xHCI HC (rev 04)
00:16.0 Communication controller: Intel Corporation 8 Series HECI #0 (rev 04)
00:1b.0 Audio device: Intel Corporation 8 Series HD Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 1 (rev e4)
00:1d.0 USB controller: Intel Corporation 8 Series USB EHCI #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation 8 Series LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 8 Series SATA Controller 1 [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 8 Series SMBus Controller (rev 04)
00:1f.6 Signal processing controller: Intel Corporation 8 Series Thermal (rev 04)
01:00.0 Network controller: Intel Corporation Wireless 7260 (rev 6b)

The lspci command looks up much of its data in the /usr/share/hwdata/pci.ids file, which contains a list of all known IDs (vendors, devices, classes, and subclasses). Vendor and device codes are assigned numbers. Use the -n option if you want to see numbers instead of names. If you have a new device that is not yet in your local database, use the -q option to query the central PCI ID server database using a DNS lookup. If a device is found there, the information is saved in ~/.pciids-cache, and the device is recognized on later runs even if you do not specify -q.

PCI topology is described by four levels: domain, bus, slot, and function. You can restrict output by using any of these components along with the -s option. The -t option shows the output in a tree view. Other options of lspci control the verbosity and format of the output. You can have more or less verbose output, and the output can be suitable for machine or human reading.

Listing 13 shows the topology tree for devices in slot 00 on my system, using the -t and -v options.

Listing 13. Output of lspci -tv

[ian@atticf22 ~]$ lspci ‑tvv ‑s \:00
‑+‑[0000:03]‑‑‑00.0  Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet
 +‑[0000:02]‑‑‑00.0  JMicron Technology Corp. IEEE 1394 Host Controller
 +‑[0000:01]‑+‑00.0  NVIDIA Corporation GF119 GeForce GT 610 |           \‑00.1  NVIDIA Corporation GF119 HDMI Audio Controller
 \‑[0000:00]‑‑‑00.0  Advanced Micro Devices, Inc. [AMD] RS780 Host Bridge

You can also restrict output by vendor ID, device, or class by using the -d option. And the -k option tells you which kernel driver is handling the device and which kernel modules are capable of handling it. Listing 14 shows this output for the NVIDIA graphics and sound devices on my system. The vendor ID for NVIDIA is 10de, which you can find out by using the -nn option of lspci.

Listing 14. Output of lspci with -d and -k options

[ian@atticf22 ~]$ lspci ‑d 10de\:
01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 610] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GF119 HDMI Audio Controller (rev a1)
[ian@atticf22 ~]$ lspci ‑d 10de\: ‑k
01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 610] (rev a1)
    Subsystem: ASUSTeK Computer Inc. Device 8496
    Kernel driver in use: nouveau
    Kernel modules: nouveau
01:00.1 Audio device: NVIDIA Corporation GF119 HDMI Audio Controller (rev a1)
    Subsystem: ASUSTeK Computer Inc. Device 8496
    Kernel driver in use: snd_hda_intel
    Kernel modules: snd_hda_intel

See the man pages for the many other options for lspci. Some of them give you access to detailed information on PCI devices. There is also a setpci command, which enables a root user to query and configure PCI devices. Again, see the man pages for details.

USB and lsusb

Use the lsusb command to display information about your USB devices. As with lspci, the -t option displays information in a tree layout, as shown in Listing 15.

Listing 15. Tree output of lsusb

root@atticf22 ~lsusb ‑t
/:  Bus 07.Port 1: Dev 1, Class=roothub, Driver=ohci‑pci/2p, 12M
/:  Bus 06.Port 1: Dev 1, Class=roothub, Driver=ohci‑pci/3p, 12M
/:  Bus 05.Port 1: Dev 1, Class=roothub, Driver=ohci‑pci/3p, 12M
/:  Bus 04.Port 1: Dev 1, Class=roothub, Driver=ohci‑pci/3p, 12M
/:  Bus 03.Port 1: Dev 1, Class=roothub, Driver=ohci‑pci/3p, 12M
    | Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 12M
        | Port 1: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        | Port 4: Dev 15, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci‑pci/6p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci‑pci/6p, 480M
    | Port 5: Dev 7, If 0, Class=Hub, Driver=hub/4p, 480M
        | Port 2: Dev 13, If 0, Class=Mass Storage, Driver=usb‑storage, 480M
    | Port 6: Dev 4, If 0, Class=Video, Driver=uvcvideo, 480M
    |_ Port 6: Dev 4, If 1, Class=Video, Driver=uvcvideo, 480M
    | Port 6: Dev 4, If 2, Class=Audio, Driver=snd‑usb‑audio, 480M
    | Port 6: Dev 4, If 3, Class=Audio, Driver=snd‑usb‑audio, 480M

USB devices connect to a hub. The root hubs are at the top level and can support USB 1, 2, or 3. The OHCI (or UHCI) driver supports USB 1.1 (12Mbps), the EHCI driver supports USB 2.0 (480Mbps), and the XHCI driver supports USB 3.0 (5Gbps). USB Attached SCSI (UAS) is a faster protocol developed for USB 3.0 that also supports USB 2.0 speeds. UAS was introduced into Linux at kernel 3.15.

Attached devices fall into several classes:

  • Human-interface devices include keyboards, mice, and other such devices.
  • Communications devices include modems and serial, Ethernet, or WiFi interfaces.
  • Mass storage devices include hard drives, CD and DVD drives, flash drives, memory card readers, and cameras.
  • Audio devices include sound cards, MIDI devices, speakers, and microphones.
  • IrDA devices use infrared communication and include medical devices and test equipment.
  • Printer devices include printers and other devices such as numerically controlled machines.
  • Video devices include webcams.

Many attached devices use a class driver, such as usb-storage for a storage device, usbhid for a human-interface device such as mouse or keyboard, or hub for a cascaded hub. The list in Listing 15 includes two human-interface devices (my mouse and keyboard) and a USB 2.0 hub with an attached storage device (a thumb drive). Some specialized devices might require a unique driver for the device.

As with PCI devices, you can limit the output by USB topology or by vendor or device ID. Listing 16 shows an example of each.

Listing 16. Limiting the output of lsusb

[ian@atticf22 ~]$ lsusb ‑d 046d:
Bus 001 Device 004: ID 046d:081b Logitech, Inc. Webcam C310
Bus 003 Device 015: ID 046d:c50e Logitech, Inc. Cordless Mouse Receiver
[ian@atticf22 ~]$ lsusb ‑s 01:
Bus 001 Device 004: ID 046d:081b Logitech, Inc. Webcam C310
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

There is also a usbview command that you can use to view USB information graphically. The data is presented in tree view in the left pane. Selecting an entry shows the details in the right pane. The example in Usbfig 1 shows details for a USB drive.

Figure 8. Using usbview
Screenshot of using usbview

Message passing and D-Bus

When new hardware is plugged in, or a printer runs out of paper, a user often needs to be notified. D-Bus (also known as dbus) is a message-passing bus developed under the auspices of freedesktop.org. A single system daemon allows communication between the kernel and user space for events such as new hardware found. D-Bus messages can drive notifications to a user, and the receiving application can then suggest actions such as opening a file browser when a CD or DVD is inserted in a drive or when a USB thumb drive is plugged in.

There is also a per-user-session daemon that is launched at login time. The user daemon provides interprocess communication between the user applications. The D-Bus protocol is a general one-to-one message-passing framework. Two applications could even communicate using the framework without messages passing through the dbus daemon.

See resources on the right side of the article for additional information on D-Bus.

Kernel modules

A long time ago, computer operating systems were configured and built to handle a specific set of attached hardware. If a device was not built into the operating system kernel, it could not be added or used. As the variety of devices increased and as the need grew to dynamically add devices by hot plugging, this model no longer worked. Today the kernel is minimal, and device support is configured by loadable kernel modules (LKMs). A basic set of device-support modules is usually included in an initial RAM disk that is loaded as part of the boot process. Once the system is up, the kernel probes the system further and loads needed device modules as new devices are discovered.

Several commands are used for interrogating and manipulating kernel modules. I’ll cover lsmod, modinfo, and modprobe here. The modprobe command has now replaced the function of the earlier insmod and rmmod commands because it is more powerful.

Using lsmod

The lsmod command formats the information from /proc/modules to give you a current status of the modules in your Linux system. The lsmod command has no options. Listing 17 shows a partial listing of the module status on my system.

Listing 17. Partial listing of module status with lsmod

[ian@atticf22 ~]$ lsmod 
Module                  Size  Used by
vfat                   24576  1
fat                    69632  1 vfat
uas                    24576  0
usb_storage            65536  2 uas
xt_CHECKSUM            16384  1
ipt_MASQUERADE         16384  3
nf_nat_masquerade_ipv4    16384  1 ipt_MASQUERADE
nf_conntrack_netbios_ns    16384  0
nf_conntrack_broadcast    16384  1 nf_conntrack_netbios_ns
ip6t_rpfilter          16384  1
ip6t_REJECT            16384  2
nf_reject_ipv6         16384  1 ip6t_REJECT
xt_conntrack           16384  22
ebtable_nat            16384  1
ebtable_broute         16384  1
ebtable_filter         16384  1
ebtables               32768  3 ebtable_broute,ebtable_nat,ebtable_filter
ip6table_nat           16384  1
nf_conntrack_ipv6      20480  12
nf_defrag_ipv6         36864  1 nf_conntrack_ipv6
nf_nat_ipv6            16384  1 ip6table_nat
ip6table_mangle        16384  1
ip6table_security      16384  1
ip6table_raw           16384  1
ip6table_filter        16384  1
ip6_tables             28672  5 ip6table_filter,ip6table_mangle,ip6table_security,ip6table_nat,
iptable_nat            16384  1
nf_conntrack_ipv4      16384  12
nf_defrag_ipv4         16384  1 nf_conntrack_ipv4
nf_nat_ipv4            16384  1 iptable_nat
nf_nat                 28672  3 nf_nat_ipv4,nf_nat_ipv6,nf_nat_masquerade_ipv4
nf_conntrack          106496  9 nf_conntrack_netbios_ns,nf_nat,nf_nat_ipv4,nf_nat_ipv6,xt_conntrack,
iptable_mangle         16384  1
iptable_security       16384  1
iptable_raw            16384  1
bnep                   24576  2
bluetooth             491520  5 bnep
rfkill                 24576  2 bluetooth
fuse                   94208  3
tun                    28672  1
bridge                114688  1 ebtable_broute
ppdev                  20480  0
uvcvideo               90112  0
kvm_amd                65536  0
kvm                   495616  1 kvm_amd
videobuf2_vmalloc      16384  1 uvcvideo
videobuf2_core         49152  1 uvcvideo
videobuf2_memops       16384  1 videobuf2_vmalloc
v4l2_common            16384  1 videobuf2_core
videodev              159744  3 uvcvideo,v4l2_common,videobuf2_core
media                  24576  2 uvcvideo,videodev
snd_usb_audio         180224  3
k10temp                16384  0
btrfs                 974848  0
edac_core              53248  0

Using modinfo

Use the modinfo command to get information about a module. You can give a full filename or just the module name.Listing 18 shows information for the vfat module, which handles the various forms of FAT-formatted drives.

Listing 18. Information about the vfat module

[ian@atticf22 ~]$ modinfo vfat
filename:       /lib/modules/4.1.6‑200.fc22.x86_64/kernel/fs/fat/vfat.ko.xz
author:         Gordon Chaffee
description:    VFAT filesystem support
license:        GPL
alias:          fs‑vfat
depends:        fat
intree:         Y
vermagic:       4.1.6‑200.fc22.x86_64 SMP mod_unload 
signer:         Fedora kernel signing key
sig_key:        95:D8:8B:1A:62:3B:BF:DF:EF:E2:58:6B:05:ED:0A:C5:C2:88:C1:3A
sig_hashalgo:   sha256

The module information includes the full path to the file and information about any other names (aliases) the module might be known by. Dependencies, if any, are also listed. So, from Mod 2, you can see that the vfat module is also known as fs-vfat and depends on another module called fat. Try running modinfo with these module names.

You can use the -F or --field option to limit the output to a specific field. This option is useful for scripts.

If you don’t specify a full filename, modinfo searches for a module in /lib/modules/version/kernel, where version is your kernel release as given by uname -runame-r. In the example in Listing 18, the file vfat.ko.xz (the vfat kernel module) is found in /lib/modules/4.1.6-200.fc22.x86_64/kernel/fs/fat. Listing 19 illustrates how you might start looking for module files on your system.

Listing 19. Locating module files on your system

[ian@atticf22 ~]$ uname ‑r
[ian@atticf22 ~]$ ls /lib/modules/$(uname ‑r)
build                modules.dep          modules.softdep
kernel               modules.dep.bin      modules.symbols
modules.alias        modules.devname      modules.symbols.bin
modules.alias.bin    modules.drm          source
modules.block        modules.modesetting  updates
modules.builtin      modules.networking   vdso
modules.builtin.bin  modules.order
[ian@atticf22 ~]$ ls /lib/modules/$(uname ‑r)/kernel
arch  crypto  drivers  fs  kernel  lib  mm  net  security  sound

You can also find several plain-text files in your /lib/modules/$(uname -r) directory — including modules.dep, which lists dependencies, and modules.alias, which lists aliases. The modules.builtin file lists modules that are built in to the kernel. These include drivers needed for core functionality on most systems. If you try to use modinfo to find out about the ehci-pci driver that you might have noticed in the lsusb output, you probably won’t find it because it is a built-in driver. Listing 20 illustrates this scenario.

Listing 20. Finding built-in drivers

[ian@atticf22 ~]$ modinfo ehci‑pci
modinfo: ERROR: Module ehci‑pci not found.
[ian@atticf22 ~]$ grep ehci /lib/modules/4.1.6‑200.fc22.x86_64/modules.builtin

Using modprobe

As you’ve seen from the output of lspci, lsusb, lsmod, and modinfo, your system uses several kernel modules to drive devices. You have also seen that some of these modules have dependencies. So, loading the right modules in the right order is important. Fortunately, the modprobe command has taken over the earlier manual work of insmod and rmmod, which can each insert or remove one module from the system.

I’ll use the irnet module for this example on my Ubuntu 16.04.1 LTS system. Use modinfo to see more about this module, as shown in Listing 21.

Listing 21. Module information for irrnet

ian@ubuntu:~$ modinfo irnet
ian@attic‑u16:~$ modinfo irnet
filename:       /lib/modules/4.4.0‑59‑generic/kernel/net/irda/irnet/irnet.ko
alias:          char‑major‑10‑187
license:        GPL
description:    IrNET : Synchronous PPP over IrDA
author:         Jean Tourrilhes <jt@hpl.hp.com>
srcversion:     2883ED607A4D54A94830F37
depends:        irda
intree:         Y
vermagic:       4.4.0‑59‑generic SMP mod_unload modversions 
ian@attic‑u16:~$ modinfo ‑F depends irda

As you see, this module has a dependency on irda, which has a further dependency on crc-ccitt. By using grep to search for irda or crc-ccitt in your modules.dep file, you can see the value of modularizing driver support. Each of these drivers is used by many other drivers.

If you want to manually load or unload a driver, use modprobe with the -a (or --all) option to load or insert the module and the -r option to remove or unload the module. The -n, --dry-run, or --show option shows you what will be done, without doing it. You usually use the -v option with these to see more information. Listing 22 shows what will happen if I try to load the irda module.

Listing 22. Dry run loading the irnet module

ian@attic‑u16:~$ modprobe ‑nav irnet
insmod /lib/modules/4.4.0‑59‑generic/kernel/lib/crc‑ccitt.ko 
insmod /lib/modules/4.4.0‑59‑generic/kernel/net/irda/irda.ko 
insmod /lib/modules/4.4.0‑59‑generic/kernel/net/irda/irnet/irnet.ko 

The output shows the insmod commands needed to load each required module with dependencies resolved.

The modprobe command takes into account modules that are already loaded. In Listing 22, I first load the crc-ccitt module, then do another dry run, and finally load the irnet module. Note that the actual loading or unloading requires root authority.

Listing 22. Loading the irnet module

ian@attic‑u16:~$ sudo modprobe ‑av crc‑ccitt
insmod /lib/modules/4.4.0‑59‑generic/kernel/lib/crc‑ccitt.ko 
ian@attic‑u16:~$ modprobe ‑nav irnet
insmod /lib/modules/4.4.0‑59‑generic/kernel/net/irda/irda.ko 
insmod /lib/modules/4.4.0‑59‑generic/kernel/net/irda/irnet/irnet.ko 
ian@attic‑u16:~$ sudo modprobe ‑av irnet
insmod /lib/modules/4.4.0‑59‑generic/kernel/net/irda/irda.ko 
insmod /lib/modules/4.4.0‑59‑generic/kernel/net/irda/irnet/irnet.ko 
ian@attic‑u16:~$ lsmod | grep "ir[dn]|ccitt"
irnet                  24576  0
irda                  196608  1 irnet
crc_ccitt              16384  1 irda

You remove modules by using the -r option of modprobe. You cannot remove a module if it is being used. Listing 23 shows you some examples.

Listing 23. Unloading the irnet module

ian@attic‑u16:~$ modprobe ‑nvr crc‑ccitt
modprobe: FATAL: Module crc_ccitt is in use.
ian@attic‑u16:~$ modprobe ‑nvr irnet
rmmod irnet
ian@attic‑u16:~$ sudo modprobe ‑vr crc‑ccitt
modprobe: FATAL: Module crc_ccitt is in use.
ian@attic‑u16:~$ sudo modprobe ‑vr irnet
rmmod irnet
rmmod irda
rmmod crc_ccitt

Module parameters

Some modules have parameters. For example, a device driver might need to know which IRQ or I/O port to use. Listing 24 shows module information for the nsc-ircc module, which has several such parameters.

Listing 24. Modules with parameters

ian@attic‑u16:~$ modinfo nsc‑ircc
filename:       /lib/modules/4.4.0‑59‑generic/kernel/drivers/net/irda/nsc‑ircc.ko
license:        GPL
description:    NSC IrDA Device Driver
author:         Dag Brattli <dagb@cs.uit.no>
srcversion:     9AA374A6DFC1C886D632DC3
alias:          acpi:IBM0071:
alias:          pnp:dIBM0071
alias:          acpi:HWPC224:
alias:          pnp:dHWPC224
alias:          acpi:NSC6001:
alias:          pnp:dNSC6001*
depends:        irda
intree:         Y
vermagic:       4.4.0‑59‑generic SMP mod_unload modversions 
parm:           qos_mtt_bits:Minimum Turn Time (int)
parm:           io:Base I/O addresses (array of int)
parm:           irq:IRQ lines (array of int)
parm:           dma:DMA channels (array of int)
parm:           dongle_id:Type‑id of used dongle (int)

You specify module parameters on the modprobe command line when loading the module. See the man page for more details and for details on the other available modprobe options.

This concludes your introduction to hardware settings on Linux.