Managing Hardware Under Linux
Every hard disk drive has several parameters that are collectively called the driveís geometry.These parameters are used by your system to determine how the drive is to be accessed and where data can be stored. The parameters that compose the drive geometry include the following:
Heads: Refers to the number of read/write heads in the drive.
Cylinders: Refers to the concentric parallel tracks on all sides of all platters in the hard disk drive. Imagine a hollow cylinder that penetrates down through all of the platters in a hard drive. Depending on how wide the cylinder is, you can fit a certain number of progressively wider cylinders, beginning in the center of the platters and working your way outward to the edge, within the drive platters.
Sectors Per Track: Refers to the number of wedges the platters have been divided into. In addition to creating imaginary cylinders in the drive, you can also slice each platter up into imaginary pie-shaped wedges.
SATA Hard Disk Drives
One signal path to transmit data serially, bit by bit
A second serial channel to return receipt acknowledgments to the sender
Most modern operating systems, including Linux, will see SATA devices as SCSI devices.
SCSI Hard Disk Drives
Internal: The internal connector is used to connect internal SCSI devices using a SCSI ribbon cable
External: The external connector is used to connect external SCSI devices to the controller.
Older SCSI controllers supported up to eight devices (including the SCSI controller itself ) in the SCSI chain.
Many newer SCSI controllers support up to 16 devices (again, including the SCSI controller). The controller determines what data should be sent to which device in the chain using the SCSI ID. Each device in the SCSI chain must have a unique ID number between 0 and 7 (0 and 15 on newer controllers).
SCSI ID:
Itís simply a logical number we assign. However, the SCSI ID does perform a crucial function. It defines the priority of the device in the SCSI chain.
The higher the SCSI ID assigned to a device, the higher its priority.
The lower the ID number, the higher the device is in the boot order.
ID: x:n
The x parameter identifies the ID of the SCSI controller to which the device is connected.
The n parameter identifies the ID of the device on that controllerís bus
Thus, 0:0 indicates the drive is the first SCSI device on the first SCSI controller
In addition to SCSI ID, you also need to be concerned with termination when setting up a SCSI chain.
Each end of the SCSI chain must have a terminating resistor installed to absorb data signals. This prevents the signal from reflecting back down the bus.Termination can be implemented in a variety of ways on the SCSI chain. Some terminators are implemented by attaching a terminator to the end of the SCSI ribbon cable for internal devices. For external devices, the terminator may be a special plug that is inserted in the second SCSI port on the last external device in the SCSI chain.Termination can also be implemented on the SCSI devices themselves.
This can be done in the following ways:
Resistor packs: Resistor packs are inserted in the SCSI deviceís circuit board to enable termination.
Jumpers: A shunted jumper is frequently used to enable termination on the device.
Software: SCSI controller boards usually include a software setup program run from the controller board's BIOS that can be used to turn termination off and on.
Active termination: Many SCSI devices use active termination. With active termination, the device checks to see if itís the last device on the chain. If it is, it automatically enables the terminating resistor.
My experience has been that about 95 percent of problems encountered when working with SCSI are due to misconfigured SCSI IDs or terminators.
Be aware that there is a new, high-end SCSI standard that is used almost exclusively in server systems called Serial Attached SCSI (SAS). SAS also overcomes device limitations associated with traditional SCSI. Instead of eight or 16 devices, SAS can support (theoretically) up to 65,535 devices. SAS is also faster. It supports data transfer speeds up to 6 Gbps.
Solid-State Drives
A solid-state drive is a storage device that functions much like a standard hard disk drive, using the same block-based I/O operations. However, unlike traditional hard disks, SSDs use flash memory to store data.Unfortunately, these benefits come at a cost, as SSDs are also much more expensive than hard drives.One of the cool features of SSDs is the fact that they use the same SATA interface used by traditional hard disk drives.
Optical Storage Devices
They can store a relatively large amount of data.
They are highly portable.
They are very inexpensive to manufacture.
Optical discs were originally introduced for use in PCs as a read-only media. To encode the pits and lands that store binary PC data, an optical disc had to be pressed at a manufacturing facility. Once the disc was pressed, no more data could be added to it.
Today, that has all changed. In a modern PC system, you can implement writable and re-writable optical drives (usually called burners). Optical burner drives implement a second, high-intensity laser in addition to the standard read laser. This second laser is used to write information to the bottom side of a burnable disc. Once-writable discs use a special photo-reactive dye on the bottom side of the disc. When the high-intensity laser in an optical burner strikes this dye, it changes the pigment to a darker color. By doing this, we can encode binary data on the disc using light and dark spots that operate much like the pits and lands found on a factory-pressed optical disc.
With a CD-R, DVD-R, or BD-R optical burner, the data becomes fixed as soon as it is burned. You canít erase or modify the data after that. To be able to do this, you need to use a re-writable optical burner (called a CD-RW, DVD-RW, or BD-RE drive). A re-writable burner uses a high-intensity secondary laser just like a CD-R, DVD-R, or BD-R. However, the bottom surface of an RW or RE disc uses a photo-reactive crystalline coating. These discs can be encoded with light and dark spots just like an -R disc. They can also be erased. Using the right intensity and frequency in the laser, an RW drive can reset the crystals on the bottom surface of the disc back to their original state, allowing you to burn new data.
Flash Drives
Like an SSD hard drive, flash storage uses flash memory. Flash memory can be electronically erased and reprogrammed. Flash memory is also persistent. Once written, it retains its contents even if the electrical current is turned off.
Essentially, a flash drive is little more than a printed circuit board with a flash memory chip installed that is connected to a USB interface.
Universal Serial Bus
Universal Serial Bus (USB) is a high-speed removable hardware interface that has pretty much replaced serial, parallel, mouse, and keyboard ports on the PC. Most PC systems today include an integrated USB interface in the motherboard. USB can be used to connect a wide variety of external devices, including these:
External hard drives
External CD and DVD drives
Printers
Scanners
Digital cameras
Mice
Keyboards
Flash drives
A single USB bus can include up to 127 external devices. All devices on the bus are grouped into one of three categories:
Hubs: USB hubs are central connecting points for USB devices. USB uses a star topology. All devices on the bus connect to a USB hub. The USB interface in your PC, whether it is an expansion board or is built in to the motherboard, functions as the root hub in your USB bus. The cool thing about USB is the fact that you can cascade multiple USB hubs together to connect additional devices to the bus. Simply plugging one USB hub into a USB port on another hub does this. This makes USB extremely scalable.
Functions: Functions are individual external USB devices such as printers, scanners, hard drives, keyboards, and mice.
Hub and function: Some USB devices are both a function and a hub at the same time. For example, many USB keyboards include several USB ports that you can use to connect additional USB devices. This type of device is both a function and a hub.
IEEE 1394
IEEE 1394 is very similar to USB. It is designed to support high-speed data transfers between exter-nal devices and your PC system. IEEE 1394 was originally developed by Apple. In fact, Appleís Macintosh computer lines were equipped with IEEE 1394 before USB. Today, IEEE 1394 isnít as widely implemented as USB. Most PC systems sold today do not include an IEEE 1394 interface.
Managing System Resources
Interrupt Request Channels
IRQs or just interrupts. When a device is installed in a PC system, it needs some means of letting the CPU know when it needs attention. Many devices in your PC need lots of CPU time; other devices need the PU only on occasion. We need a way to make sure the busy devices get the attention they need without wasting time on devices that donít need as much. This is done through interrupts.
When working with interrupts, you should keep in mind the following important facts:
ïEvery device in the PC must be assigned an interrupt.
ïTwo PCI devices can share interrupts.
ïSome system devices have interrupts assigned to them by default. Some of these can be changed or disabled; many cannot:
IRQ 0 ñSystem timer
IRQ 1 Keyboard
IRQ 3 ñCOM 2
IRQ 4 COM 1
IRQ 5 ñLPT 2
IRQ 6 Floppy drive
IRQ 7 ñLPT 1
IRQ 8 Real-time clock
Interrupts 0, 1, and 8 are hardwired. Under no circumstances can you use these interrupts for any other device in the system.
If a device with a default interrupt assignment isnít installed in the system or is disabled, you can use its interrupt for another device
Input/Output Addresses
I/O ports,port addresses, or simply as ports.
I/O addresses allow communications between the devices in the PC and the operating system. I/O addresses are very similar to mailboxes. To send a letter to someone, you must know their mailing address. You write their address on the letter and the mail carrier delivers it to the box with that address. Likewise, the person you wrote to can respond to your letter and leave it in their mailbox for the mail carrier to pick up.
I/O addresses work in much the same manner. They serve as mailboxes for the devices installed in the system. Data can be left for a device in its I/O address. Data from the device can be left in the I/O address for the operating system to pick up.
On a personal computer, there are 65,535 port addresses for devices to use.
I/O addresses are written using hexadecimal notation.
When working with I/O addresses, you should keep the following important facts in mind:
All devices must have an I/O address assigned.
Most devices will use a range of I/O addresses.
Devices must use unique I/O ports.
Default I/O port assignments include the following:
0000h DMA controller
0020h PIC 1
0030h PIC 2
0040h System timer
0060h Keyboardï0070h ñ CMOS clock
00C0h ñDMA controllerï00F0h ñ Math co-processor
0170h Secondary IDE hard disk controller
01F0h Primary IDE hard disk controllerï0200h ñ Joystick
0278h LPT2ï02E8h ñ COM4ï02F8h ñ COM2
0378h LPT1ï03E8h ñ COM3
03F0h Floppy disk drive controller
03F8h COM1
Direct Memory Access Channels
In addition to interrupts and I/O addresses, some devices also require a direct memory access (DMA) channel. DMA channels are used by high-throughput devices to communicate directly with RAM without involving the CPU. Bypassing the CPU can dramatically increase the deviceís data transfer rate.
Not all devices need DMA. Other devices, however, would be severely handicapped if they couldnít use DMA. These devices include
Sound boards
Some hard disk drives
DMA is implemented on the motherboard using the DMA controller chip (DCC). The DCC is very similar to the PIC chip we reviewed earlier. The DCC has four leads that connect it to the memory controller chip (MCC) and the expansion bus slots. Each of these leads is referred to as a DMA channel. Data from an expansion slot is routed through the DCC to the MCC, thus allowing direct access to the system memory.When working with DMA, you should keep the following points in mind:
No two devices can use the same channel.
Modern systems use cascaded DMA controllers to increase the number of available DMA channels.
Plug and Play
The PnP standard is designed to automatically configure the system resources used by your expansion boards for you every time you boot the system. It makes life so much easier for a system administrator. All you have to do is install the board in an available slot and turn on the systemóno jumpers, no DIP switches, no misplaced configuration diskettes.
Managing Integrated Devices
Most motherboards include a plethora of integrated devices on board, including
•I/O ports (including serial, parallel, USB, and FireWire)
•Video interfaces
•Network interfaces
•Sound boards
•Storage controllers
•And so on...
Managing Systems Without External Peripherals
Depending on your job role, you may need to manage systems that don’t have any external peripherals, not even a keyboard. Many servers are managed in this manner, as are many virtualized systems running on a hypervisor.
You have a couple of options for managing these types of systems. If the system has an integrated management interface (such as is found on high-end server systems), you can usually access this interface using a web browser and perform all kinds of management tasks, including accessing the system display, shutting down the system, and even powering the system on.If the system doesn’t have an integrated management interface, you have two other options:
•SSH: Using SSH, you can securely access the shell prompt of the system and run commands as if you were sitting in front of the system. You can also tunnel X server traffic through the SSH connection, which allows you to securely access the graphical desktop of the system.
•VNC: You can also use Virtual Network Computing (VNC) to remotely access the graphical desktop of the system. VNC is great, but it lacks the security provided by SSH tunneling, so it is usually used only on secure networks.
Working with Linux Drivers
If you are going to be responsible for managing Linux systems, it’s very important that you understand how drivers work on the operating system. If you’ve used a Windows system, you’re probably already familiar with the process required to load a driver to support a piece of hardware. However, the way drivers work under Linux is somewhat different.
What Exactly Is a Driver, Anyway?
The key idea you need to understand when discussing drivers is the fact that the CPU on your motherboard doesn’t natively know how to communicate with other hardware devices installed in your system.
To be able to do these things, the CPU needs instructions in the form of software to tell it how to communicate with these devices. For basic devices, such as your system clock and keyboard, basic drivers can be stored in a chip on the motherboard. However, the software for more complex devices, such as network and sound boards, can’t be easily stored in a chip on the motherboard. There are so many different makes and models of these types of devices that it is completely unfeasible to store all the software needed for every last device within a motherboard chip. Instead, we store the software on the system’s hard drive. As the system boots, the operating system loads the software (called a driver) from the hard disk into RAM. Once this is done, the CPU has the instructions it needs to communicate with the associated hardware.
How Drivers Are Implemented Under Linux
There are two different ways in which Linux can implement a device driver for a particular piece of hardware in your PC system. First of all, the driver can be loaded as a kernel module. Once the Linux kernel has been loaded into memory during the boot process, it can be configured to load kernel modules, which allow the CPU and operating system to work with the hardware installed in the system.
Kernel modules have a .ko or .o extension and are stored within the /lib/modules/kernel_version/kernel/drivers directory on your Linux system. Within this directory is a series of subdirectories where kernel modules for your hardware devices are actually stored.
The second way hardware support can be implemented in Linux is to actually compile the necessary driver support directly within the kernel itself. Doing so requires that you manually recompile your kernel from its source code and specify which hardware support you want integrated directly within the kernel in the process. After you do so, kernel modules for those devices are no longer needed because the operating system now has all the software it needs within the kernel itself.
t is a good strategy for some drivers; however, as a general rule of thumb, you should limit the drivers compiled into the kernel to only those drivers the system needs to boot up (keyboard drivers, storage drivers, and so on). The rest should be loaded as kernel modules.
First of all, each driver you compile into the kernel increases the overall size of the kernel. You should try to keep your kernel as lean and clean as possible. Second, configuring a kernel is a more complex operation, requiring in-depth information about the hardware and what each configuration element provides.
Finally, the issue of modularity comes into play. If you never modify, upgrade, or reconfigure your computer system, then compiling more drivers directly into the kernel may make sense. However, it doesn’t make sense for PC surgeons like me. I’m constantly adding, removing, and reconfiguring hardware in my PCs. By loading kernel modules, I can add or remove support for hardware devices very quickly from the command line. If I compile them into the kernel, I may end up with a bloated kernel that contains support for hardware that is no longer in the system. Essentially, kernel modules allow your system to be much more dynamic.
Managing Kernel Modules
When I first started learning about managing kernel modules back when Linux was young, I was really intimidated. It sounded really difficult. Like many other aspects of Linux, however, it’s really pretty easy. Manage kernel modules on your system.
Viewing Installed Hardware
A key skill you need to have as a Linux system admin is to know how to view currently installed hardware in the system. One of the best tools for doing this is the good old /proc directory. I introduced you to /proc earlier. Remember, the /proc directory doesn’t actually exist in the file system. Instead, it’s a pseudo file system that is dynamically created whenever it is accessed.
•cpuinfo: Contains details about the CPU installed in the system. You can use cat, less, more, or any text editor to view the contents of this file.
•devices: Contains a list of devices installed in the system.
•dma: Contains a list of DMA channel assignments in the system.
•interrupts: Contains a list of IRQ assignments in the system.
•iomem: Contains a list of I/O port assignments in the system.
•modules: Contains a list of all the kernel modules currently being used by the system.
•version: Contains the information about the version of the Linux kernel running on the system.
•/scsi/: Contains files that hold information about the SCSI devices in your system if you’re using a SCSI adapter.
•/bus/devices: Contains information about the USB devices in the system.
In addition to /proc, the /sys/ directory also provides information about the hardware installed in the system. The file system is organized in a tree structure grouped by the hardware bus, the hardware devices, and their associated drivers. The top level of the /sys directory contains many subdirectories, including:
•/sys/block: Contains a symbolic link file for each block device in the system
•/sys/bus: Contains a directory for each data bus in the system, including the PCI, SCSI, and USB busses.Each bus directory has two subdirectories—devices and drivers.
The devices subdirectory contains entries for every device on that bus, whereas the drivers directory contains subdirectories for each driver loaded for a device on this bus:
•/sys/class: Contains all device classes available
•/sys/devices: Contains an entry for every discovered device
•/sys/module: Contains subdirectories for each module loaded into the kernel.
Most Linux distributions also include a variety of command-line tools you can use to view information about the hardware in your system. Some of these tools actually pull their information right out of the /proc directory. You can use the following commands:
•hdparm /dev/device: Displays information about your hard drive. Replace device with sda, sdb, and so on.
•sg_scan: Scans your SCSI bus and lists all the devices connected to your SCSI controller.
•sginfo –l: Also lists all connected SCSI devices.
•lsusb: Displays information about USB devices connected to your Linux system.
•hwinfo: Displays a comprehensive overview of the system hardware. It probes the system hardware and generates a system overview report.
If you don’t specify any options with the command, it can produce a rather long report. However, you can limit the report to a single device subsystem using the --device option. See the hwinfo man page to see a list of devices you can use with this option.
•lspci: Lists all PCI devices installed in the system. You can use the –k option with this command to see the kernel modules associated with each device.
Using Shell Commands to Manage Kernel Modules
To view all currently loaded kernel modules, you can use the lsmod command. This command pulls data from the /proc/modules file and reformats it for display on the screen. To use this command, simply enter
>lsmod
To view more information about a particular loaded module, you can use the modinfo command. You can first use lsmod to find the name of the module in question and then enter
>modinfo module_name
In the preceding example, one of the modules displayed by lsmod is joydev. This is your system’s joystick kernel module. To view more information about this particular module, you can enter
>modinfo joydev
To load a kernel module, you first need to run the
>depmod
command from the shell prompt. This command is used to build a file named modules.dep that is stored in /lib/modules/kernel_version/
Within this file, depmod lists the dependencies between modules. This helps other kernel module management utilities ensure that dependent modules are loaded whenever you load a module.
You can use one of two different commands to do this. The first is the insmod command. The syntax for insmod is
>insmod module_filename
The module filename is usually a kernel module located in a subdirectory of /lib/modules/kernel_version/kernel/. For example, if you wanted to load the driver for a standard PC parallel port, you would enter insmod /lib/modules/version/kernel/drivers/parport/parport_pc.ko at the shell prompt.
In addition to insmod, you can also use the modprobe command. Most Linux admins prefer modprobe to insmod. The key issue here is that the insmod command doesn’t take into account the module dependencies identified by depmod.
The syntax for using modprobe is
>modprobe module_name
As with insmod, the module you load with modprobe resides in a subdirectory of /lib/modules/kernel_version/kernel/. For example, the /lib/modules/kernel_version/kernel/drivers/net/ethernet directory contains kernel modules for a variety of network boards.
>modprobe 3c590
You’re probably wondering, at this point, if the module will be persistent across system restarts after it has been loaded with modprobe. The answer is no, it won’t (unless the device is automatically detected during boot). However, modprobe is automatically run every time the kernel loads. It reads the information contained in your /etc/modprobe.conf file to determine what kernel modules should be loaded during startup.
If the /etc/modprobe.conf file doesn’t exist, then modprobe will use the files located in the /etc/modprobe.d directory to determine the kernel modules that will be loaded at boot.
The modprobe.conf file uses the following directives:
•install module_name: Tells modprobe to load the specified module. It can also be used to run any valid shell command, providing you with a high degree of flexibility when loading your modules.
•alias alias_name module_name: Gives a kernel module an alias name that can be used to reference it from the shell prompt.
•options module_name options: Gives modprobe a list of options, such as irq= and io=, that should be used when a particular kernel module loads.
You’ll probably notice that there is a big note at the beginning of the file that warns you not to modify /etc/modprobe.conf directly. Instead, if you need to manually specify that a particular kernel module be loaded at system startup, you should enter it in the /etc/modprobe.conf.local file using the modprobe.conf directives just specified.
Alternatively, you could also insert the modprobe module_namecommand in your rc.local or boot.local file to ensure that the module is loaded at system startup. However, my experience has been that you will rarely need to do this. Most distributions run a hardware detection routine at system boot that scans for new hardware and automatically loads the appropriate kernel module.
If you need to unload a currently loaded kernel module, you can use the
>rmmod module_name
command at the shell prompt. Be warned that this command won’t work if the device serviced by the module is in use. If it is, the command won’t remove the module. Like insmod, rmmod doesn’t take module dependencies into account and doesn’t do anything with them.
If you want to remove a module and take dependencies into account, you should use modprobe instead. The syntax for removing a module with modprobe is
>modprobe –r module_name
Working with Hot-Plug and Cold-Plug Devices
When working with PC hardware and kernel modules under Linux, you need to keep in mind that your PC hardware can be grouped into two different categories:
•Cold-plug devices: Cold-plug devices can be physically connected to or disconnected from the PC system only when it is powered off. PC components such as the CPU, RAM, expansion cards, and storage devices are examples of internal cold-plug devices. Peripherals such as parallel printers and external SCSI devices are examples of external cold-plug devices.
The key thing to remember about cold-plug devices is the fact that if you plug them in while the system is running, they probably won’t be detected and recognized by the system. If you connect them properly while the system is off and then attempt to unplug them while the system is running, you will probably damage the component (or the system itself ) electrically. By default, only processes running in the kernel space are allowed to communicate directly with the system hardware.
To allow user space processes to access hardware, the /dev directory is provided. As discussed earlier in this book, the hardware in your Linux system is accessed through a device file through /dev. Cold-plug devices (such as your hard disk drive) are accessed in this way.
•Hot-plug devices: Hot-plug devices, on the other hand, are designed to be connected and disconnected dynamically while the system is up and running. Software on the Linux system detects the changes to the system as these types of devices are attached and detached. The system will recognize the device when it is connected and load the appropriate modules. USB and FireWire devices are examples of hot-plug devices.
The problem with addressing hot-plug devices lies with how they are accessed. Remember, cold-plug devices are accessed through a device file in /dev. Can hot-plug devices be accessed in this way, too? Yes, but the process needs some help. One option would be to create a device file in /dev for every possible device that could ever be connected to the system. This would allow applications on the system to access hot-plug hardware whenever they were connected to the system through the appropriate device file.
Although this approach works, it’s also very messy. A better approach would be to dynamically create a device file in /dev whenever a hot-plug device is connected and then remove it whenever the device is disconnected. For this to work, the new hardware must be recognized by the operating system, the appropriate device files must be created in /dev, and any processes running on the system must be notified that the new hardware is available.
Several Linux components are needed to do this. The first component is sysfs. This component provides the /sys virtual file system we discussed earlier in this chapter. Its job is to export information about system hardware devices (both hot-plug and cold-plug) so that applications and utilities running on the system can access them.
The second component is the Hardware Abstraction Layer (HAL) daemon (hald). This daemon is run automatically at startup. Its job is to provide applications running on the system with information about the hardware (both hot-plug and cold-plug) available in the system.
The next component is the Desktop Bus (dbus). It also runs as a daemon on your Linux system, providing several key functions. For our purposes here, however, you need to remember that it is the dbus daemon that notifies running processes whenever a hot-plug device is connected or disconnected from the system.
Finally, Linux also uses udev. The udev daemon (udevd) creates a virtual file system that is mounted at /dev. It communicates with the Linux kernel through the uevent interface. When a hot-plug device has been added or removed, the kernel sends out a uevent message that is picked up by udevd, which does the following, based on the rules defined in the files in the /etc/udev/rules.d directory:
•It initializes the device.
•It creates the appropriate device file in the /dev directory.
•If the new device is a network interface, it configures it using the ifup utility.
•If the new device is a storage device, it mounts it using the information in /etc/fstab.
•It informs running processes about the new device.
No comments:
Post a Comment