PCI + AGP Information

This page is dedicated to programming and other technical information about the PCI & AGP Busses. This is information that you CANNOT get for free from the PCI SIG; they want to charge you exorbitant amounts of money for the information. Everything you see here is the result of the hard work of many independent persons who have learnt PCI the hard way - without any 'official' documentation.
 

Please select a section for more information...

The Great AGP Rip-off

Don't buy a lemon: Read about how not all AGP cards are created equal!

What is PCI anyhow, and why write about it?

A short tutorial on the history of PCI.

PCI Programs, resources and links

A suite of tools for technicians for exploring, fault-finding, diagnosis and repair. Includes our famous database of all known PCI and AGP devices ever created!

Download the latest PCIDEVS.TXT Get your updates to my PCI program's database here!

PCI Programmers notes:
    AGP PRO
    AGP
    Subsystem ID's

Loads of technical chat for programmers of PCI.
   

PCI, Windows 9x and IRQ's - Mysteries solved

A tutorial for those suffering the Windows IRQ conflict blues.

How to Submit new PCI device entry to our database

How to tell us about new PCI devices you've discovered that aren't in our database.

Programmers PCI Resources:

My own DOS based PCI Information utility. Includes free full Turbo Pascal source code for the curious.

It has come to my attention that my PCI program fails to work in the Windows 2000, NT and Novell Netware server environments. If you wish to test out a 2000, NT or Novell PC, please boot from a DOS boot disk and run PCI in that environment. PCI works well in most other environments - I've tested it under MS-DOS 5.0, 6,22, Windows 3.0, 3.1, WFW3.11, Win95 (incl OSR2, OSR2.1 & OSR2.5) & Win98.

My own PCI Vendor & Device database which currently includes over 7500 known PCI & AGP vendor & device codes. Download this file regularly to stay up to date with the latest PCI cards coming out. Unlike other PCI database maintainers, I do update my database regularly, and am always on the lookout for new submissions. This file is more current than the one that comes with the program mentioned above, so get it too!

I now have a simple database integrity checking tool for PCIDEVS.TXT; it looks for formatting errors, wrongly keyed hex-bytes, invalid tags, truncated lines and the like, as well as doing some simple statistics. If you like to edit PCIDEVS.TXT yourself, you can download it here. It may come in handy to pick up typo's etc. I'm pleased to say it found no errors at all when run over the current database!

One of my regular PCI ID contributors Marco Koetsveld has produced an interactive DOS PCI explorer program, which features nice scrolling windows, a menu driven interface, dump-to-file ability, etc. It is based mostly around my code, with his "front end". If you think my program is ugly, try Marco's instead! Click here to Download Marco's program (Version 0.71ß) Marco's program uses my VENDORS.TXT, so it's a bit out of date now.

A new PCI infoprogram for Windows 9x has just been developed by Holger. Visit http://www.hollgi.de/index_e.html for a free copy of PCIScan. As yet, it does not handle subsystem information, but it does use my PCIDEVS.TXT file, so it will probably be expanded in the future to do so.

ALTIPCI is a GUI-based PCI info-program for Windows NT (The other programs above don't work under NT) which is written by ALTITECH and released as freeware.

David Welch has developed some C source code for Windows NT to demonstrate accessing the PCI registers/Configuration space. If you're interested in coding PCI stuff under NT, you can get his source code here. (New URL!)

An <unnamed> programmer has written a C program that takes my (VENDORS.TXT) PCI database and turns it into binary type files, ready to link directly into programs. Personally, I don't agree with his 'style' of programming, since it makes the database impossible for the end user to update..(the program needs re-compiling to update). If you are interested, click here to download the program... includes full source, make files, etc. and is released as freeware.

Ralf Brown's PCI Stuff. Get Ralf's PCICFG program & his Interrupt List. His interrupt list has some great programming information on almost every PC related topic there is (including a great section on PCI) and his PCICFG program also comes with source code, in C. Ralf updates his PCI database from mine (and me from his); in fact he has written his program with a function to import my database into his, so you still need my database to be the most up to date you can be...  Lately Ralf has been getting sloppy, with a growing number of duplicate, blank, out-of-order and just plain badly formatted entries... I hope he has a good clean-up soon!

The PCI SIG also maintain a vendors list (no device lists though) and supply the 'official' standards, should you want to pay for them. I think the PCI SIG sucks because of this attitude, but here's their URL anyhow. Why not email them and tell them how you feel too? Please read the docs in PCI for my full opinion!

Jim Boemler's vendor list is now offline, and Jim reports the project is now dead as he is no longer involved in PCI. At a personal level, Jim and I never saw eye to eye regarding how to make our two databases work together, so on one hand I'm not really all that sad to see him go, but on the other hand he was the first (to my knowledge) to work towards a public PCI database, and many have put a lot of effort into his list; effort that will live on to a certain extent through this list.

Programming Plug and Play is quite possibly the only book to ever carry a decent, more-or-less complete set of interrupt calls on PCI, PnP, PnPISA, ESCD and other cool topics. If you want a book on PCI, check this one out.

Links Don't like those choices? Try my general links page.

 Return to PCI Index


PCI, Windows 9x and IRQ's - Mysteries solved!

One of THE most common questions I see on newsgroups and get asked is for an explination of how IRQ's work on PCI. The questions usually go a little like this:

What's the IRQ Holder for PCI steering in Windows 9x, and can I delete it? Where did it come from? What does it do? Can I share PCI IRQ's? Why won't two devices on the same IRQ work together?

OK.. here is sort of mini-FAQ with lots of notes on the issues and loads of help, hints and tips. Please read through this section carefully, there's a lot covered and it's tough going sometimes, but once you understand it, the knowledge gained will be invaluable for fixing problems, I promise :-)

Q. Is PCI IRQ sharing possible?
A. YES, it is, but with several conditions! IRQ Sharing between multiple PCI devices is explicitly part of the PCI standard. It is NOT possible to share an IRQ between a PCI and any type of non-PCI device, however. (this is exactly the same as MCA and EISA). There is no limit to the number of PCI devices sharing the same IRQ - it can be more than two! You'll need win95B (OSR2) or later to perform IRQ sharing; WIN95A (OSR1 / original release / win3.x upgrade) doesn't have the necessary driver code to support shared PCI IRQs.

I've been called a liar more than once, in making these claims. In response, I refer the reader to the Compaq Armada 1750 laptop. This unit has no less than FIVE PCI devices using the same IRQ! Well done, Compaq. This product is a prime example of PCI hardware and Windows software all implemented correctly.

ISA bus devices, PnP or not, don't share IRQ's with anything else, period. The ISA bus simply doesn't support IRQ sharing at the hardware level.

Cardbus controllers/cards are PCI devices, and support IRQ sharing. PCMCIA controllers/devices are ISA devices and DO NOT support IRQ sharing. Putting a cardbus card into a PCMCIA slot WILL NOT give you a sharable IRQ (and often just wont work, period).

When fixing/building a system with IRQ troubles, firstly set all non-PnP ISA devices (legacy devices) to their own unique IRQ. In the system's CMOS setup, mark these IRQ's as not available to the PnP system (the method varies from BIOS to BIOS). The remaining IRQ's will be distributed between the PnP devices (PCI, PnPISA, EISA, MCA, etc). Try to get the BIOS to give each PnP card it's own unique IRQ (you must do this on 95A), but if that's not possible, let the BIOS make PCI devices share the same IRQ, and make sure that any PnPISA cards have their own unique IRQs each.

Many BIOS's have shocking bugs in their IRQ assignment software! Sometimes you just plain can't get the BIOS to work properly - resign yourself to accepting that some BIOS's are just shit and therefore you can't do what you want. Try to get a newer BIOS if possible. (Try this website for BIOS upgrades). Also please realise that if your legacy (non-PnP) devices + PnPISA devices take up all available IRQ's then you ain't gonna get a working config, period.

If possible, set the BIOS's PnP aware OS setting to YES. What this does is leave any non-boot PnP devices unconfigured. Windows will then configure the devices during boot instead of the BIOS. This is a preferable choice as Windows has more 'skill' in coming up with a working configuration - it can draw on the information in the driver's .INF files, take into account legacy devices, draw on you the user's input, is upgradeable via newer driver versions etc, whereas the BIOS has none of these inputs available to it... it has to figure it all out without and outside help, and frankly, many BIOS's are so poorly written that they just can't do it right.

If your BIOS offers the choice of level triggered or edge trigged IRQs, you should select level triggered; this is the "normal" option on PCI, and is the one that will permit IRQ sharing. This sort of thing is only seen on the very earliest PCI 2.0 chipset BIOSs. Edge triggering is the technique the ISA bus uses, which does not permit IRQ sharing - don't ever use it!!

Note: The serial, parallel & IDE port IRQs on modern motherboards are STILL connected to the ISA bus, therefore they are not available for sharing with other devices (unless the port is disabled).

The following table lists common IRQ usage on modern 486+ systems.
 

IRQ Uses
0 System Timer (Not available to any cards)
1 System Keyboard Controller (Not available to any cards)
2 Cascade IRQ (Not available to any cards)
3 Normally COM2:
4 Normally COM1:
5 Normally ISA SoundBlaster PRO/16
6 Floppy Disk Controller (Available to cards, but generally never used except for Floppy Controllers)
7 Normally LPT1: when in ECP mode or older ISA SoundBlaster 1.x
8 Real Time Clock (Not available to any cards)
9 normally free 
10 normally free
11 normally free
12 PS/2 Mouse if fitted, otherwise free
13 Math Coprocessor (Not available to any cards)
14 Primary IDE Hard disk controller
15 Secondary IDE Hard disk controller

Q. What is 'IRQ Holder for PCI Steering' in Windows 9x?
A. This is a plug and play mechanism that is built into Windows 9x. There will be multiple IRQ holders if there are multiple IRQs assigned to PCI devices - one for each IRQ. The IRQ holder is designed to 'reserve' an IRQ for PCI useage, even though no device may actually be using that IRQ 'right now'.

IRQ steering is really only useful on laptops that do hot-plugging (docking station, Cardbus). By reserving an IRQ, a hot-plug event doesn't cause a raft of resource reassignments, since the correct "spare" resource can be guaranteed to be available, it is just "enabled" or "disabled" as the hot-plug is made or broken. Without the IRQ bieng reserved, the resource reassignments required could potentially require a reboot; by "reserving" the necessary resources ahead of time, the reboot is avoided, and hot-plug plug and play functions successfully.

As trouble-shooters, we should look for IRQ holders that don't belong to any PCI devices, and delete them. This is sometimes necessary when you remove a PCI device (thus freeing it's IRQ) then try to use that IRQ on a non-PCI device. Until the holder is removed, Windows sees the IRQ as "used" and won't permit it to be assigned to anything else non-PCI. Deleting the holder "frees" the IRQ, thus permitting it to be re-assigned to another device. Don't ever delete any IRQ holders that belong to hot-plug devices that aren't pluged in "now" but will be later; otherwise you'll defeat the whole hot-plug system.

Contrary to previous advice seen here, IRQ Steering isn't directly involved in any IRQ sharing issues; sorry for the error!


A Correctly configured PCI Steering Page

Q. How do I know if IRQ Steering is working?
A. Go into Device Manager, select system devices, PCI Bus, properties. Look at the IRQ Steering tab. All the information you could hope for will be found there. If IRQ Steering is not working, the normal reason is that you have failed to load the correct patches to the OS for your motherboad chipset. For example, Intel Chipset boards such as the 430TX, 440LX, 440BX, require the PIIX4 patch, whilst VIA chipset boards require the VIA chipset registry and INF files update.

You may need to update your motherboard's FlashBIOS to fix bugs with it's IRQ routing table, if you receive a routing table related error message. Visit http://www.ping.be/bios for BIOS updates. Some motherboards either don't support the MS IRQ routing specification or have erroneous support - my PCI program can test the support and report on any issues found.

The screenshot at right shows what a correctly configured Win95 PCI Bus with IRQ Steering enabled looks like. The various releases of win9x have slightly different looking dialogs, but the information conveyed therein is what's important



Q.
Whats the INTA/INTB/INTC/INTD line and how does each correlate to an eventual IRQ.
A. Each PCI device has four interrupt lines INTA-INTD. This means that each device can generate up to four different types of interrupts. Normally only INTA is used, however there are exceptions: the USB controller in the Intel PIIX4 chipset is manufactured to always use INTD, and some PCI cards have jumper selectable INTx choices. The jumper-selectable technique was a very early convention designed before PCI standard revision 2.1, where most BIOS's had zero user control over IRQ assignment. Jumpers should never be required in any modern PCI card as system BIOS's now have comprehensive IRQ mapping controls.

The system Chipset, motherboard layout & BIOS all influence the mapping of each INTx line to an IRQ. This is because the PCI Standards permit the mapping of IRQ's to INTs to happen in any way the vendor chooses; there are no specific requirements as to how things are implemented, so therefore there are many different chipsets doing the mapping many different ways. Even the same chipset on two different motherboards may be wired up differently, thus changing the possible combinations of assignable resources. This means that a certain way of operation learned for a specific motherboard may be totally wrong when applied to a different board. This fools many people!! One of your tasks as a technician will be to discover what limitations the particular chipset has with it's IRQ to INT mappings, and to learn to avoid the limited advice of those whose total sum of experience happens to be with the one single board in the only computer they own.

The BIOS controls the boot-time mappings of INTs to IRQs, and it can do this on a slot-by slot basis (within the limitations of the chipset and motherboard layout, as explained above). Therefore, slot 1's INTA might be mapped to IRQ9, but slot 2's INTA is mapped to IRQ11, yet at the same time a motherboard PCI device can be using INTD at IRQ11 too! This is also why moving cards to different slots causes the assigned IRQ's to change, and why re-ordering the cards in the slots can sometimes (by fluke rather than good management, IMHO) appear to fix problems. Those advocating the 're-order your cards' technique of problem fixing really are just guessing - clearly they fail to understand how the system truely works, and it doesn't help that the same chipset can operate differently on different vendors motherboards. "Card-jugglers' fluke results by pure luck - freeing up an IRQ that was conflicting with another device or getting the shared IRQ's setup properly by chance only.

The only times I see 'card juggling' bieng necessary are:

Card juggling is necessary in these cases as the PCI slots may be scanned and configured "left to right" or "right to left"; therefore your desired 'first' card needs to be the closest to the starting end, so that it is assigned the primary, legacy compatible resources.

Q. What exactly is Windows IRQ steering for?
A.
IRQ Steering is MS's system for reading the proprietory INT to IRQ mapping information from the motherboard/chipset. When Windows can read this information, it then knows exactly how it can reprogram the chipset if it wishes to change the IRQ assingnments (for example, in response to the need to change resouce assignments when a hot-dock occurs). If Windows can't read the IRQ routing info, it can't change the BIOS-assigned IRQs, and therefore it may be unable to successfully configure the newly hot-docked device without a reboot, or perhaps even at all. IRQ steering is really only of major importance in a system that is hot-dockable or has Cardbus support (ie laptops). The vast majority of desktops can do without IRQ Steering working, however it can help when the BIOS assigns conflicting IRQ's to PCI resources, and refuses to be told otherwise, since as soon as Windows loads, windows can then try to "set things right".

Q. I've read all of this, and my two PCI devices still won't work on the same IRQ under Windows. What do I do now?
A. OK Fault finding time. The very first thing to do is check your windows version in control panel, system. Windows 95 4.00.950 and 4.00.950A DO NOT support IRQ sharing!!! You need at least OSR2 win95 which is 4.00.950B.

Assuming you have 95B, 95C, 98 or 98SE, check that the IRQ holders are present and working: Find out the IRQs which PCI devices are using using my PCI tool, or read the BIOS info-box if it has one. Go to Device manager, system devices, and look at each IRQ Holder for PCI steering.Verify that there is a holder for each PCI IRQ, and that they're all working (No yellow ! marks or red X marks on anything). Delete any IRQ Holders that you know are definately not bieng used for PCI devices. Go to the PCI Bus (system devices) And find out if the IRQ Steering function is enabled and working, or not. Keep this in mind if this is a hot-dock capable system.

Ensure all the hardware drivers for your motherboard chipset are installed - for example the Intel PIIX3 or PIIX4 patch, VIA 4 in 1 patch, USBSUPP patch (all for win95), for example. If you dont have all the drivers loaded (ie all the chipset-specific drivers in place) then don't expect things to work properly!!! Win98 needs driver updates less often, but since new chipsets are forever coming, in time it too will pretty much be requiring patches on a regular basis.

Next, make sure no non-PCI devices are sharing the same IRQ... this includes 'inactive' cards you may have physically installed but not loaded drivers for!!! If you don't want to use it, TAKE IT OUT or DISABLE IT!!! This can be a problem with some multi-function cards that have multiple functions onboard that may not be individually configurable (many sound cards with IDE or proprietory CD-ROM interfaces come to mind).

Next, make sure that 32-bit, drivers are loaded for each device - 16 bit Win3.x and real mode DOS type drivers don't support IRQ sharing. Upgrade to 32-bit drivers throughout whenever possible - the extra performance gained is always worth the effort, since 32-bit drivers are optimised in many ways other than just supporting IRQ sharing. 16-bit drivers are generally loaded in config.sys, autoexec.bat, or win.ini (load= and run= lines) and occasionally system.ini ([386enh] section). If in doubt, contact the hardware vendor for advice on the type of driver and it's IRQ sharing compatability.

You may need to boot windows in safe mode, go to device manager and delete any old or duplicate devices. When booting Windows normally, device manager only shows you the device listings for the 'current' detected set of (PnP) hardware, but there can be inactive entries still in the registry stuffing things up. Booting in safe mode makes device manager display ALL it's entries, regardless of wether they're detected, active, inactive, disabled, or from a different hardware profile. A classic example is when you upgrade to a new motherboard with a different chipset - windows will detect the new hardware and device manger will look just fine, but after a safe mode boot you'll see that many devices are now doubled up - you'll have two PCI busses, two standard floppy disk controllers, six hard disk controllers, two (or four) floppy drives etc. The trick here is to delete ALL copies of the duplicated item(s) and then re-boot normally. Windows will re-detect the 'right' device and you'll end up with a cleaner registry. This also goes even for changing hard disks, video cards, and any PnP devices. A system that's been upgraded a few times will be littered with a dozen or more inactive entries.

When you remove a PnP device, it vanishes from device manager but all it's setup is still in the registry, awaiting the possability that one day the device may return; this is mainly a feature for "hot-docking" of laptops (it avoids the whole add new hardware & reboot sequence every time you dock or undock), but in a desktop PC when you know that old device is never coming back, you can get rid of it's registry entries once and for all... but you can't delete what's not shown onscreen, so you need to use safe mode to 'see' the device to select and delete it!

Always try the BIOS 'Reset Configuration Data' function - sometimes the BIOS frustrates itself into a state of confusion that it can't get out of (especially if you change cards a lot) and this is the only way to 'wipe the slate' and start over. Windows 9x actually inserts into the configuration data the resources used by non-PnP devices, so that the BIOS knows to not use them. If you subsequently remove the device, Windows doesn't remove it's configuration data entry!!! Therefore, the BIOS still thinks that the resources are unavailable and won't use them. Resetting the configuration data makes the BIOS rebuild the data from scratch (wiping out what Windows did), and the resources will again be available. This data is the (part of ) the "ESCD" and/or "DMI" data you often see referred to at boot time. A hang when "verifying" this data usually indicates the need for it to be cleared using these techniques.

Some BIOS's don't have a reset configuration data function: in that case, remove the CMOS battery for a few minutes, or use the clear CMOS jumper; wiping the CMOS usually wipes the configuration data or forces the BIOS to re-build the data from scratch too. Don't use the CMOS setup's "load defualts" option - that usually doesn't clear the necessary info. Some flashbios programming utilities also have a clear function as a commandline option...

If IRQ sharing _still_ won't work, the most likely explination is that one of the software drivers are probably poorly written and just don't support sharing properly. There are quite a few older drivers that fall into this category, where the programmer didn't quite understand the issues and techniques involved (they probably came from ISA days, where sharing wasn't an issue). Complain loudly to the vendor for better drivers. To determine which is the nasty driver, find two devices that will share OK (using your test system, of course), then try each questionable device in turn with your known 'share friendly' device and find which one doesn't play ball. Perhaps upgrading to the latest drivers from the vendor may help? If not, then you'll have to ensure that the lousy device gets a unique IRQ all to itself.


Return to home page