In this tutorial, learn to configure and check the hardware for your Linux system. Learn to:
- Enable and disable integrated peripherals
- Configure systems with or without external peripherals such as keyboards
- Distinguish different types of mass storage devices
- Understand cold-plug and hot-plug devices
- Know what hardware resources devices use
- Use tools to list and manipulate devices
- Understand sysfs, procfs, udev, and dbus
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).
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
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
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
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
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
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
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
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.
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 (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. SSDs are often housed like notebook drives and use the same interfaces, although this arrangement can limit the theoretical capabilities of an SSD. A newer attachment called NVM Express (NVMe) has been developed for PCI Express (PCIe)–based solid-state drives. The specification is designed to better use SSDs over PCIe.
Hot plug and cold plug
Hot plugging of devices became popular with notebook hardware that supported removable cards using the Personal Computer Memory Card International Association (PCMCIA) specification and later the CardBus specification, as well as exchange of a floppy drive for a CD. Linux introduced hot-plugging support starting with kernel 2.4 in 2001. The term cold plugging is used by analogy to refer to devices that are physically attached to the computer at boot time.
With the advent of USB and IEEE-1394 FireWire devices, hot plugging became the norm rather than the exception. Today, high-end servers can dynamically move resources such as memory or CPUs between Linux systems that are multiplexed on a single system. The result is that almost anything can be hot plugged. Consequently, the Linux system now uses only a few cold-plug devices to start the system, and then activates everything else using hot-plug events that drive udev rules. Even the cold-plugged devices are rescanned to drive udev events and effectively become hot plugged.
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 -l
fdisk-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 ‑> ../devices/pci0000:00/0000:00:11.0/ata1/host0/target0:0:0/0:0:0:0/block/sda lrwxrwxrwx. 1 root root 0 Sep 9 12:11 sdb ‑> ../devices/pci0000:00/0000:00:11.0/ata2/host1/target1:0:0/1:0:0:0/block/sdb lrwxrwxrwx. 1 root root 0 Sep 9 12:11 sdc ‑> ../devices/pci0000:00/0000:00:11.0/ata3/host2/target2:0:0/2:0:0:0/block/sdc lrwxrwxrwx. 1 root root 0 Sep 10 20:30 sr0 ‑> ../devices/pci0000:00/0000:00:14.1/ata6/host5/target5:0:0/5:0:0:0/block/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 2040192 [ian@atticf22 ~]$ su ‑ Password: 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
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 (
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 "" bash
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
PCI and lspci
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 Configuration 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)
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
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
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 Controller +‑[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
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
lsusb command to display information about your USB devices. As with
-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
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.
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
modprobe here. The
modprobe command has now replaced the function of the earlier
rmmod commands because it is more powerful.
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, ip6table_raw 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, nf_nat_masquerade_ipv4,nf_conntrack_broadcast,nf_conntrack_ipv4, nf_conntrack_ipv6 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 ...
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
--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 -r
uname-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 4.1.6‑200.fc22.x86_64 [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 kernel/drivers/usb/host/ehci‑hcd.ko kernel/drivers/usb/host/ehci‑pci.ko
As you’ve seen from the output of
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
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 <firstname.lastname@example.org> srcversion: 2883ED607A4D54A94830F37 depends: irda intree: Y vermagic: 4.4.0‑59‑generic SMP mod_unload modversions ian@attic‑u16:~$ modinfo ‑F depends irda crc‑ccitt
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
--all) option to load or insert the module and the
-r option to remove or unload the module. The
--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.
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
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 <email@example.com> 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
This concludes your introduction to hardware settings on Linux.