IRQs and PCI things are a little different with the PCI bus. PCI allocates four IRQs that can be used by the PCI/AGP cards in your system. In general, these IRQs can be shared among multiple devices. (If you do this, make sure that all the devices doing the sharing are PCI and AGP devices.) IRQ sharing is important, especially for modern machines that may have five PCIs and one AGP slot. Without IRQ sharing, you would be unable to have more than four IRQ-using cards in your system. There are, however, some limitations to PCI IRQ sharing. While modern motherboards' BIOS and Linux kernels generally support PCI IRQ sharing, certain PCI cards may simply refuse to work properly when sharing an IRQ with another device. If you're experiencing random system lockups, especially lockups that appear to be correlated with the use of a specific hardware device, you may want to try and get all your PCI devices to use their own IRQs, just to be on the safe side. The first step is to see if any devices in your system are sharing IRQs to begin with. To do this, follow these steps: Use the various hardware devices in your system, such as disk, sound, video, SCSI, etc. This ensures that Linux will handle interrupts for these various devices. cat /proc/interrupts, which will display a list and count of all interrupts which the Linux kernel has handled so far. Look in the far right column in this list. If two or more devices are listed in a single row, then they're sharing that particular IRQ. If one of the devices in question is a non-PCI device (ISA or other legacy cards) then you've found yourself an IRQ conflict, which you can attempt to fix with your BIOS, the isapnptools package, or the physical jumpers on your peripheral cards. Note that if a device is built in to your motherboard, it is most likely a PCI device even though it doesn't occupy a physical PCI slot. If all the devices in question are PCI or AGP devices, then whether or not you have a problem depends on your hardware. Here are some steps you can take to attempt to get all your PCI/AGP devices on their own IRQs: Enter your system BIOS and disable any unused peripherals (USB, parallel port, etc.) This can free up several IRQs, giving each piece of hardware in use a greater chance of being assigned its own unique IRQs. Enter the PnP section of your BIOS and make sure that your BIOS is configured for a "non-PnP" operating system. Then select the "Reset ESCD data" option. This will force your BIOS to reassign IRQs to all of your hardware devices the next time you reboot. Boot Linux, use your hardware, cat /proc/interrupts and look at the result. Hopefully, all your devices are now on their own IRQs. If your two suspect PCI devices are still sharing IRQs, you have two additional options. Some BIOS setup programs allow you to assign certain IRQs to specific PCI slots. If you have one of these rare BIOS setup programs, you can use this functionality to eliminate the conflict. If you don't have this option in your BIOS (most of us don't), there is one other sure fix for this problem -- shut down your machine, turn off the power, unplug your PC from the wall, and wait a few minutes. Then, open your system case and physically move your PCI cards to different slots. This option may seem a bit odd, but it will definitely work and is especially effective if you have a few free PCI slots in your system (but it may take you some time to find the correct slot for each of your cards.) performed the "PCI card-shuffling trick" and was able to get all the devices in my system to use a unique IRQ. Well, almost. As you can see, two of my IDE devices still shared an IRQ: Code Listing 2.1: IRQ sharing # cat /proc/interrupts CPU0 0: 52063600 XT-PIC timer 1: 616810 XT-PIC keyboard 2: 0 XT-PIC cascade 5: 89084 XT-PIC ide2, ide3 7: 1515741 XT-PIC eth0 8: 155928 XT-PIC rtc 9: 1139761505 XT-PIC nvidia 10: 164000 XT-PIC Ensoniq AudioPCI 12: 4458823 XT-PIC PS/2 Mouse 14: 664176 XT-PIC ide0 15: 38661 XT-PIC ide1 NMI: 0 ERR: 0 However, this was normal because the ide2 and ide3 devices were integrated onto the same chip on my Promise FastTrak IDE card. So, now that (almost) all my devices had a unique IRQ, I tried my accelerated drivers and ... still experienced a lock-up in less than an hour. Apparently, the shared PCI IRQ was not the problem at all. Oh, well ... time to look elsewhere (yet again).
It would be nice if you linked to part one in the beginning, & came back to link to part 3 if you ever make it.