System resources are the communications channels, addresses, and other signals hardware devices use to communicate on the bus of an x86 or Itanium-based server. At their lowest level, these resources typically include the following:
These are listed roughly in the order in which you would experience problems with them. Memory conflicts are perhaps the most troublesome of these and certainly the most difficult to fully explain and overcome. Memory conflicts are discussed in Chapter 5. This chapter focuses on the other resources listed here, in the order in which you will likely have problems with them. Historically, IRQs have caused more problems than DMAs because they are in much higher demand; virtually all cards use IRQ channels. Fewer problems exist with DMA channels because fewer cards use them: DMA channels are only used by legacy devices, and there are usually more than enough channels to go around. I/O ports are used by all hardware devices on the bus, but there are technically 64KB of them, which means there are plenty to go around. If you are managing a modern server that uses PnP configuration, hardware resources are configured automatically for you. However, if you are working with older servers that use ISA cards or use non-PnP operating systems such as Windows NT 4.0, you are responsible for ensuring that each hardware device has nonconflicting resources. These resources are required and used by many components of a system. Adapter cards need these resources to communicate with the system and accomplish their purposes. Not all adapter cards have the same resource requirements. A serial communications port, for example, needs an IRQ channel and an I/O port address, whereas most network cards use an IRQ channel and an I/O port address, and some also use a 16KB block of memory addresses. As a system's complexity increases, the chance for resource conflicts increases, particularly if your system does not use PnP configuration. Modern servers with several additional devices can really push the envelope and become a configuration nightmare for the uninitiated. Sometimes under these situations the automatic configuration capability of PnP can get confused or fail to optimally configure resources so that everything will work. There are two major methods that you can use for managing PnP configuration:
Depending on which type of PnP handler you are using and the operating system, you might be able to modify resource assignments by using the PnP software that comes with the card (typically used by ISA cards with PnP configuration options) or the Device Manager in Windows 2000 Server and Windows Server 2003. Thus, you can sometimes improve on a default configuration by making some changes. Even if the automatic configuration gets confused (which happens more often than it should), fortunately, in almost all cases, a logical way to configure the system existswhen you know the rules. IRQIRQ channels, or hardware interrupts, are used by various hardware devices to signal the motherboard that a request must be fulfilled. This procedure is the same as a student raising his hand to indicate that he needs attention. These interrupt channels are represented by wires on the motherboard running to the slot connectors and to onboard devices. When a particular interrupt is invoked, a special routine takes over the system, which first saves all the CPU register contents in a stack and then directs the system to the interrupt vector table. This vector table contains a list of memory addresses that correspond to the interrupt channels. Depending on which interrupt was invoked, the program corresponding to that channel is run. The pointers in the vector table point to the address of whatever software driver is used to service the card that generated the interrupt. For a network card, for example, the vector might point to the address of the network drivers that have been loaded to operate the card; for a hard disk controller, the vector might point to the BIOS code that operates the controller. After the particular software routine finishes performing whatever function the card needed, the interrupt control software returns the stack contents to the CPU registers, and the system then resumes whatever it was doing before the interrupt occurred. Through the use of interrupts, a system can respond to external events in a timely fashion. Each time a serial port presents a byte to the system, an interrupt is generated to ensure that the system reads that byte before another comes in. Keep in mind that in some cases a port devicein particular, a modem with a 16550 or higher UART chipmight incorporate a byte buffer that allows multiple characters to be stored before an interrupt is generated. Hardware interrupts are generally prioritized by their numbers; with some exceptions, the highest-priority interrupts have the lowest numbers. Higher-priority interrupts take precedence over lower-priority interrupts by interrupting them. As a result, several interrupts can occur in a system concurrently, with each interrupt nesting within another. Interrupts are handled in two ways:
The ISA and EISA buses use edge-triggered interrupt sensing, in which an interrupt is sensed by a changing signal sent on a particular wire located in the slot connector. A different wire corresponds to each possible hardware interrupt. Because the motherboard can't recognize which slot contains the card that used an interrupt line and therefore generated the interrupt, confusion results if more than one card is set to use a particular interrupt. Each interrupt, therefore, is usually designated for a single hardware device. The only documented interrupt sharing supported by the ISA/EISA bus was the assignment of COM 1 and COM 3 to IRQ 4 and COM 2 and COM 4 to IRQ 3. However, this "sharing" was valid only if COM 1 and COM 3 (or COM 2 and COM 4) were not in use at the same time. Any attempt to use two devices set to the same IRQ crashed the system. On the other hand, devices connected to the PCI bus (which also includes PCI-X, PCI Express, AGP slots and USB and IEEE 1394 ports) can share interrupts. The real problem is that there are technically two sets of hardware interrupts in the system: PCI interrupts and ISA interrupts. For PCI cards to work in a PC or server, the PCI interrupts are first mapped to ISA interrupts, which are then configured as non-shareable. Consequently, early PCI users continued to have problems with IRQs. Fortunately, PCI IRQ steering was introduced starting with Windows 95 OSR 2.x and is part of Windows 2000 Server and Windows Server 2003. PCI IRQ steering allows a plug-and-play operating system such as Windows to dynamically map, or "steer," PCI cards (which almost all use PCI INTA#) to standard PC interrupts and allows several PCI cards to be mapped to the same interrupt. You can find more information on PCI IRQ steering in the section "PCI Interrupts," later in this chapter. Hardware interrupts are sometimes referred to as maskable interrupts, which means the interrupts can be masked or turned off for a short time while the CPU is used for other critical operations. It is up to the system BIOS and programs to manage interrupts properly and efficiently for the best system performance. The following sections discuss the IRQs that any standard devices use, as well as what might be free in your system. Table 4.13 shows the typical uses for interrupts in the 16-bit ISA and 32-bit PCI/AGP buses and lists them in priority order from highest to lowest. The obsolete ISA and EISA buses used a similar IRQ map.
Note 32-bit and 64-bit cards also use 16-bit IRQs (915). Notice that interrupts 0, 1, 2, 8, and 13 are not on the bus connectors and are not accessible to adapter cards. Interrupts 8, 10, 11, 12, 13, 14, and 15 are from the second interrupt controller and are accessible only by boards that use the 16-bit extension connector because that is where those wires are located. IRQ9 is rewired to the 8-bit slot connector in place of IRQ2, so IRQ9 replaces IRQ2 and, therefore, is available to 8-bit cards, which treat it as though it were IRQ2. IRQs used by 16-bit ISA cards are also used by newer expansion bus types such as PCI, PCI-X, AGP, and PCI Express. If you are managing an older server that uses ISA or EISA cards, or even a server that uses onboard legacy devices such as serial and parallel ports, the likelihood of IRQ conflicts is greater than on servers that use only PCI/AGP/PCI-X/PCI Express slots and onboard PCI devices. PCI InterruptsThe PCI bus supports hardware interrupts (IRQs) that can be used by PCI devices to signal to the bus that they need attention. The four PCI interrupts are called INTA#, INTB#, INTC#, and INTD#. These INTx# interrupts are level sensitive, which means the electrical signaling enables them to be shared among PCI cards. In fact, all single-device or single-function PCI chips or cards that use only one interrupt must use INTA#. This is one of the rules in the PCI specification. If additional devices are within a chip or onboard a card, the additional devices can use INTB# through INTD#. Because there are very few multifunction PCI chips or boards, practically all the devices on a given PCI bus share INTA#. Before the development of PCI IRQ steering, PCI interrupts had to be mapped to ISA interrupts. Because ISA interrupts cannot be shared, the result was that each PCI card using INTA# on the PCI bus was mapped to a different non-shareable ISA interrupt. For example, you could have a system with four PCI slots and four PCI cards installed, each using PCI interrupt INTA#. These cards would each be mapped to a different available ISA interrupt request, such as IRQ9, IRQ10, IRQ11, or IRQ5 in most cases. PCI IRQ steering enables multiple PCI-bus devices to share a single IRQ. In addition to using a compatible operating system, such as Windows 2000 Server or Windows Server 2003, the system BIOS must also support IRQ steering. Generally, the BIOS assigns unique IRQs to PCI devices. Although Windows has the capability to change these settings, it typically does not do so automatically, except where necessary to eliminate conflicts. If there are insufficient free IRQs to go around, IRQ steering allows Windows to assign multiple PCI devices to a single IRQ, thus enabling all the devices in the system to function properly. Without IRQ steering, Windows begins to disable devices after it runs out of free IRQs to assign. On systems running Windows 2000 Server 2000 and Windows Server 2003, IRQ steering is obvious in the Device Manager: Multiple PCI devices would be listed with the same IRQ. You can have several PCI devices mapped to the same ISA IRQ only in the following situations:
Advanced Programmable Interrupt Controller (APIC)As a replacement for the traditional pair of 8259 interrupt controllers, Intel developed APIC in the mid-1990s. Although all processors since the original Pentium contain an APIC, an APIC must also be present in the motherboard's chipset, and the BIOS and operating system must also support APIC. APIC support is present on most recent motherboards, and it is also supported by Windows 2000 Server, Windows Server 2003, and recent Linux distributions. You can enable or disable APIC support in the system BIOS. APIC provides support for multiple processors, but it is also used on single-processor computers. The major benefit of APIC for a single-processor system is support for virtual PCI IRQs above 15. Most APIC implementations support virtual IRQs up to 24. Although Windows 2000 tends to place PCI IRQs into the traditional ISA range of 015, even when APIC is enabled, Windows Server 2003 and Linux distributions with APIC support make full use of APIC services when installed on a system with APIC enabled. On Windows Server 2003, APIC limits IRQ sharing to enable devices to perform better with fewer conflicts. For example, on one typical Windows system with APIC enabled (see Figure 4.34), PCI IRQs are assigned thus:
Figure 4.34. The IRQ map for a typical system with APIC support.Note that APIC must be enabled in the system BIOS when Windows 2000 Server or Windows Server 2003 is installed to make APIC services available. Note The default view used by Device Manager in Windows 2000, Windows Server 2003, and client operating systems displays devices by type. To view IRQs and other hardware resources such as DMA, I/O port addresses, and memory addresses, select View, Resources by Type. Linux Interrupt HandlingLinux handles PCI interrupts differently than Windows 2000 Server or Windows Server 2003. Linux does not assign IRQs to devices until they are actually used. To ensure that Linux has assigned IRQs to all onboard devices, you should use each onboard device as soon as Linux is installed. To view Linux IRQ usage, you can use the command-line program cat/procs/interrupts. Each IRQ in use is listed by its IRQ number. Each IRQ number displays the type of interrupt controller used to generate the IRQ and the device that is using the IRQ. Unlike Windows 2000 Server and Windows Server 2003, Linux is not designed to share IRQs. If two or more IRQs are listed as using the same IRQ when you run cat/procs/interrupts, you have an IRQ conflict unless the devices are using the same add-on card. To resolve the conflict, see the following tip. Tip To fix conflicts between cards on a modern x86 server that uses a PnP BIOS or operating system, try the following:
Recent Linux distributions also support APIC, enabling you to use PCI interrupts above 15, if APIC is enabled in the system BIOS. If APIC is enabled, each PCI device is likely to be assigned to its own IRQ, eliminating conflicts. Linux is not designed to support IRQ sharing, so the use of APIC on a Linux-based server is even more essential to avoid IRQ problems. Note that APIC is fully supported in Linux kernel v2.6 and higher. The PCI bus enables two types of devices to exist: bus masters (initiators) and slaves (targets). A bus master is a device that can take control of the bus and initiate a transfer. The slave device is the intended destination of the transfer. Most PCI devices can act as both masters and slaves, and to be compliant with the PC'97 and newer system design guides, all PCI slots must support bus master cards. The PCI bus is an arbitrated bus: A central arbiter (part of the PCI bus controller in the motherboard chipset) governs all bus transfers, giving fair and controlled access to all the devices on the bus. Before a master can use the bus, it must first request control from the central arbiter, and then it is granted control for only a specified maximum number of cycles. This arbitration allows equal and fair access to all the bus master devices, prevents a single device from hogging the bus, and prevents deadlocks because of simultaneous multiple device access. In this manner, the PCI bus acts much like a local area network (LAN), albeit one that is contained entirely within the system and runs at a much higher speed than conventional external networks between PCs. DMA ChannelsCommunications devices that must send and receive information at high speeds use DMA channels. A serial port does not use a DMA channel, but an ISA-based SCSI adapter often does, as does a parallel port using ECP or EPP/ECP modes. DMA channels can sometimes be shared if the devices are not the type that would need them simultaneously. However, there is hardly any need to share DMA channels on a system that has no ISA or EISA slots. Note There are several types of DMA in a modern PC. The DMA channels referred to in this section involve the ISA bus. Other buses, such as the ATA/IDE bus used by hard drives, have different DMA uses. The DMA channels explained here don't involve your ATA/IDE drives, even if they are set to use DMA or Ultra DMA transfers. Since the introduction of the 286 CPU, the ISA bus has supported eight DMA channels, with seven channels available to the expansion slots. Similar to the expanded IRQ lines described earlier in this chapter, the added DMA channels were created by cascading a second DMA controller to the first one. DMA channel 4 is used to cascade channels 03 to the microprocessor. Channels 03 are available for 8-bit transfers, and channels 57 are for 16-bit transfers only. Table 4.14 shows the typical uses for the DMA channels on a typical x86 or Itanium server.
In Table 4.14, DMA channels 0, 1, and 5 would be assigned to audio if the server had an ISA sound card or a PCI sound card or integrated audio that emulates the Creative Labs Sound Blaster Pro. However, these DMA channels are listed as available because most servers do not have onboard or card-based audio. I/O Port AddressesA computer's I/O ports enable communications between devices and software in the system. They are equivalent to two-way radio channels. If you want to talk to the serial port, you need to know on which I/O port (radio channel) it is listening. Similarly, if you want to receive data from the serial port, you need to listen on the same channel on which it is transmitting. Unlike IRQs and DMA channels, systems have an abundance of I/O ports. There are 65,535 ports to be exactnumbered from 0000h to FFFFhwhich is an artifact of the Intel processor design more than anything else. Even though most devices use up to 8 ports for themselves, with that many to spare, you won't run out anytime soon. The biggest problem you have to worry about is setting two devices to use the same port. Most modern plug-and-play systems resolve any port conflicts and select alternative ports for one of the conflicting devices. One confusing issue is that I/O ports are designated by hexadecimal addresses similar to memory addresses. They are not memory; they are ports. The difference is that when you send data to memory address 1000h, it gets stored in your SIMM or DIMM memory. If you send data to I/O port address 1000h, it gets sent out on the bus on that "channel," and anybody listening in could then "hear" it. If nobody is listening to that port address, the data reaches the end of the bus and is absorbed by the bus-terminating resistors. Driver programs primarily interact with devices at the various port addresses. The driver must know which ports the device is using to work with it, and vice versa. That is not usually a problem because the driver and device come from the same company. Motherboard and chipset devices are usually set to use I/O port addresses 0hFFh, and all other devices use 100hFFFFh. Table 4.15 shows the commonly used motherboard and chipset-based I/O port usage.
To find out exactly which port addresses are being used on your motherboard, consult the board documentation or look up the settings in the Windows Device Manager. Bus-based devices typically use the addresses from 100h up. Table 4.16 lists the commonly used bus-based device addresses and some common adapter cards and their settings.
To find out exactly what your devices are using, you should consult the documentation for the device or look up the device in the Windows Device Manager. Note that the documentation for some devices might list only the starting address instead of the full range of I/O port addresses used. Figure 4.35 shows a portion of the I/O port address map for a typical 32-bit Windows system. Note that some I/O port address ranges appear to have a conflict, such as 03B003FBB, which is used by the chipset's AGP controller and the installed video card (RADEON 9000). However, this is not a conflict but actually indicates that the I/O port address range is used to communicate between the devices listed. Figure 4.35. A portion of a system's I/O port address, as displayed by the Windows Device Manager.Virtually all devices on the system buses use I/O port addresses. Most of these are fairly standardized, which means conflicts or problems do not often occur with these settings. |