The Practical Aspect

So far, this has all been an over-the-top discussion of PNP configuration. Now, let’s get down to the nuts and bolts of it all from a user’s point of view. I often hear questions regarding PCI devices and IRQ assignments, and especially about the listing of multiple devices being assigned to a single IRQ. Many users, after years of being told that devices cannot share IRQ’s, get upset when they see multiple devices listed as using the same IRQ. Even worse, they see such cryptic listings as IRQ Holder for PCI Steering (see Figure 10)… and they often see multiple instances of that entry.

Don’t worry – it’s perfectly normal and absolutely workable, and here’s what it’s all about. Remember that earlier I said that there were only sixteen total IRQ’s available in a modern system, and that of that number, only four are available for additional devices in many systems? Four IRQ’s don’t allow for much expansion if each device must have a unique IRQ. As a result, the engineering gurus came up with a method of effectively sharing IRQ’s between devices that are specifically designed for such sharing. That is an important point – the devices that will share a system IRQ must have been designed with the ability to share IRQ’s. If they are not so designed, one or more of the sharing devices may not operate properly even though the SDM is not reporting a resource conflict! In a nutshell, each of the involved devices is technically properly configured when considered individually, and therefore no resource conflict is reported by the system.

The PCI bus was an innovation that met three specific goals. One was that of an expansion bus that could and would operate at a higher speed than those that came before it. Another was that of an expansion bus that was not processor dependent, negating the need for continual redesign of the bus as new and/or different processor types became available. There were several earlier attempts at high-speed bus designs, but all of them were either manufacturer-specific (proprietary) or processor-specific (able to function only with a certain processor). The third goal was for the new bus to be capable of supporting the (then) new concept of being almost self-configuring. As is indicated by its wide acceptance, the PCI bus has become a huge success, meeting all of these goals and adding other enhancements as well.

Simply put, the PCI design effectively separates the I/O subsystem from the CPU/RAM/cache subsystem. If a PC uses the PCI bus, all installed PCI devices communicate with the PCI controller, which in turn communicates with the processor’s local bus through a PCI-to-host bridge device. The PCI subsystem is afforded four individual interrupt lines for its own internal use. To identify these as PCI internal interrupts rather than system hardware interrupt lines (IRQ’s), they are labeled as INTA, INTB, INTC, and INTD. Each of these lines is made available to each PCI expansion slot in the system, and the total number of PCI slots that a given system can support depends upon the number of PCI devices that are integrated on the mainboard. Now here’s where I lose most newbies; each of these interrupts, if needed by a device installed in an expansion slot, is then mapped to (or linked with) one of the available system IRQ lines. The PCI controller chip keeps track of which PCI interrupt is mapped to which system IRQ.

Clear so far? Great! All is well if there are exactly four PCI slots on the mainboard and four available system IRQ’s from which to choose. As you might have guessed by now, it can’t be that easy! For example, many earlier BIOS’es will “lock” a given IRQ to a particular PCI slot, effectively preventing the use of any other IRQ for the device in that slot. In that case, the user is forced to shuffle cards between slots in order to find an IRQ combination that will work. For example, if a particular device was designed only to use IRQ’s 5,7,9, and 10, but is installed into a slot that is locked to IRQ11, the device may not operate until it is moved to another slot. Some BIOS models would allow the user to specify the associations of IRQ’s to PCI internal interrupts, though, as well as specifying the association of PCI internal interrupts to physical slots.

The most important thing to remember from all of this is that there are no hard and fast rules when it comes to PCI slots versus PCI interrupts versus IRQ’s! This is because there is no one standard governing these relationships. The application of the basic PCI design to a given mainboard is left up to the maker of that mainboard. There are however some “rules of thumb” that help in assembling and configuring PCI-based systems.

Newer systems have much more flexibility for automatic configuration. If the system is using a PNP operating system, all that the user needs to do is enable the BIOS option for the PNP OS and let the OS do the configuration. Current versions of Windows 98 will update the ESCD after device configuration, saving the information for the next startup. Because of the flexibility of newer BIOS’es and PCI chipsets, it is now common for the PCI controller to assign multiple devices to a single hardware IRQ. When this does happen, you will see SDM entries for IRQ Holder for PCI Steering. There will usually be one of these entries for each device assigned to a given IRQ, and the SDM will also show the actual devices that are linked to the PCI Steering entries. For an illustration of this, take a closer look at the devices listed for IRQ9, IRQ10, and IRQ11 in Figures 10B and 10C. These entries are for devices in the PCI expansion slots.

OK – now take a look at the information shown in Figure 12. This figure contains two screen shots taken while using Micro 2000’s Micro-Scope 8 to read the PCI information on another PC. This one is fairly straightforward, having (in addition to the mainboard integrated devices) only a sound card, a modem, a network adapter card, and a video adapter card installed. The sound card is an ISA-PNP card and the video adapter is an AGP type. The network adapter (NIC) is in the first PCI slot (immediately adjacent to the AGP slot), and the modem is in the fourth and last PCI slot. Figure 13 shows the SDM listing for the same PC. Let’s take a few minutes to analyze some of the information that Micro-Scope 8 (MS8) has extracted.

For each PCI device found, MS8 shows specific data about that device and its relationships within the PC. Figure 11 below provides a key to the information shown.

Heading Data Represented
Bus# Device number assigned by PCI controller upon device detection
Vend Vendor ID as stored on device ROM
Device Device ID as stored on device ROM
Class/Sub Classification and/or subsystem class of device as stored on device ROM
Class Nomen Description of device classification as stored on device ROM
Sub Nomen Description of device subsystem class as stored on device ROM
IRQ System hardware IRQ assigned to device
Addr0 First memory address used by device
Addr1 Second memory address used by device
Addr2 Third memory address used by device

 

Figure 11 – Key to PCI Information Screen Shots

It is important to note that the only information that the manufacturer must store on the device ROM is the Vendor ID and the Device ID. Any and all other information stored there is of an optional nature. As might be guessed, many generic or inexpensive devices have no optional data on their ROM’s. This is the cause of those poorly identified or Unknown Device entries in the SDM.

Looking more closely at Figure 12, you will see that there are five entries listed with 00 in the IRQ field. This may seem confusing, as Figure 13A shows that IRQ0 (IRQ00) is used by the System Timer. All five of these devices are mainboard integrated components of the PCI control subsystem. Now look at the fifth entry in Figure 12A. This entry is for the USB device, and although this is also a mainboard integrated component, it is controlled by the PCI subsystem rather than being a part of that subsystem. It is for this reason that the USB is not grouped with the other integrated components. To further support this concept, consider the other integrated components that also receive discrete IRQ’s – the COM ports, the first LPT port, the floppy controller, and the two IDE interfaces.

What, you ask, about the last entry in Figure 12b – the one that shows and IRQ assignment of 255? That entry is for the AGP video adapter in this system. AGP (Accelerated Graphics Port) is an offshoot of the PCI specification, and is a topic for it’s own article. Briefly, though, the 255 value is displayed because there is no IRQ assigned to the VGA in this system. The system BIOS in use here offers the optional use of an IRQ for the video subsystem, and in this case the option was set to the “No” choice. Each of the other entries in the PCI Information shown in Figure 12 matches precisely with the SDM information shown in Figure 13. Note that the SDM shows the IRQ Holders for each of the PCI devices listed.

Note also that IRQ9, one of the standard IRQ’s used by the PCI bus, is not used at all by the PCI bus in this system. That is due to the fact that IRQ9 is in use by the sound card, and as I stated earlier, the sound card is an ISA-PNP type. Here comes another one of those pesky PCI rules – No interrupt can be shared between a PCI device and an ISA device. This means that any and all IRQ’s assigned to, used by, or reserved for ISA devices will be completely unavailable to the PCI bus. This is exactly why IRQ5 is not shown at all in Figure 13A. That IRQ has been reserved (together with an I/O range) for an industrial interface board that is installed in one of the ISA slots. This board is completely invisible to Windows 98, is configured by jumpers, and is initialized by the application software used to output jobs to the connected machine.

Before leaving these figures, compare the data shown in Figure 13 to that shown in Figure 10, noting the similarities for many of the IRQ’s. Now compare both of these figures to Figure 3. As should now be evident, most of these assignments are fairly consistent from one system to another, with the main difference being in the user-optional devices. Devices that have been deemed to be standard or basic system devices will always be found at the same IRQ.

 

Fig. 12A
Fig. 12B

 

Figures 12A & B – PCI Information As Reported By Micro-Scope 8
Fig. 13A
Fig. 13B
Fig. 13C

A complete explanation of the process that allows PCI IRQ sharing is beyond the scope of this article, and is really irrelevant anyway. All that matters to the user is that it works… as long as all of the requirements for IRQ sharing are met by both the mainboard (BIOS) and the expansion device.

Another issue with PCI configuration has to do with those resources that are customarily used for legacy devices. Consider the IRQ’s typically assigned for COM1: and COM2:. If your system has COM1: enabled in the BIOS but has COM2: disabled there, it would stand to reason that the IRQ normally used for COM2: should now be available for use in the PCI PNP resource pool, right? Unfortunately, it is not always recognized as being free, and therefore may not be used by the PCI bus. Typically, this problem is mainboard and/or BIOS specific, and is usually a problem only if the PNP configuration is done by the BIOS rather than by the operating system.

Wrapping It Up

The purpose of this article was to make basic hardware configuration less of a mystery to the PC user, especially as related to IRQ’s. It has been my experience that IRQ’s cause more configuration headaches than any other aspect of hardware configuration. I think that this is due to the scarcity of IRQ’s in comparison to I/O address ranges. While there are fewer DMA’s than IRQ’s, few devices really require a DMA assignment, but virtually every device wants an IRQ. The Plug-and-Play concept has gone a long way towards simplifying most hardware configuration jobs, but it is still nowhere near the hands-off task that we would like it to be. I sincerely hope that the information provided here will help to further your understanding of the concepts discussed. I hope that you will be able to apply some of this to your everyday configuration and troubleshooting chores, and I will gladly welcome comments on the usefulness of the information provided.

In future articles, we will look at the other hardware resource aspects that were not covered here. Specifically, we will cover I/O Addresses and DMA assignments. In addition, this article will be updated from time to time as needed, based upon emerging technology and reader comments. Stay tuned…

 

– ChrisP –

Download this article as a text file (Self-Extracting Zip)
View this article in printer-friendly plain-text format
E-mail this article to a friend

Leave a Comment: