When two or more devices use the same interrupt line (and the same IRQ number) it's either "Interrupt Sharing" or an "Interrupt Conflict". The PCI bus allows all PCI devices to share interrupts with each other so this is called "sharing". But if an ISA device (or a LPC device ??) uses the same interrupt (IRQ) as some other device (either PCI, ISA, or LPC ??) there is usually an interrupt conflict.
There are exceptions to what's stated above. Some very old PCI devices (pre 1995 ??) do not allow interrupt sharing. Conversely, a few ISA devices have been designed to share interrupts (between two ISA devices ??) but both ISA devices must be designed this way and be driven by software that knows about sharing interrupts. The motherboard must support it too. The following discussion pertains to PCs that have an ISA bus.
A conflict means that when an interrupt happens, no device driver (or the wrong one) may be called and bad things happen like buffer overruns (loss of data). A device may nearly ground its interrupt line when it's not sending its interrupt, thus preventing any other device from using that interrupt wire. That's OK if only that device uses that interrupt. But if a second device tries to use the same interrupt line it can't do so. If this second device also nearly grounds the line when not sending an interrupt, then neither device can use the interrupt. But both Linux and the two devices are unaware of this conflict and merrily send out interrupts anyway that mostly go nowhere and are thus lost.
Interrupt conflicts were common when the IRQs were set by jumpers on cards (ISA bus) because the kernel often didn't know how these jumpers were set. ISA plug-and-play (no jumpers on the cards) helped since the software could change IRQs. The demise of ISA in favor of PCI has nearly eliminated IRQ conflicts. Still, your PC likely has devices on the motherboard (not on a plug-in card) on an ISA bus, a LPC bus, or an X-bus. But the BIOS and the kernel should know how these are set and thus avoid using them for PCI devices, thereby avoiding interrupt conflicts. But there is still a possible interrupt problem with PCI since it could run out of available interrupts, especially on older PCs that only have 16 interrupts.
But IRQ sharing on the PCI bus, while eliminating the conflict problem, has introduced another problem which is less serious: the IRQ balancing problem. If too many high-irq-issuing devices share the same IRQ, it may cause delays in the IRQs getting serviced and can't even result in buffer overruns and other errors. This is not due to congestion on the interrupt line, but it's due to the way that the software determines which device issued the interrupt. PCI interrupt sharing
There are two types of interrupt conflicts. One is a real conflict as described above. In this case interrupts don't work and the device driver keeps trying to control its device and is not aware that interrupts are not working. The second type of interrupt conflict is where a device driver is started but discovers that the interrupt it needs is already in use so it issues an error message and exits. The message could say something like "resource busy", and not clearly state that it was an interrupt problem.
Both the BIOS and the the kernel will not knowingly allow any interrupt conflict, so how can they happen? One way is if someone has put an incorrect IRQ into a configuration file, such as giving a parameter to a module like: irq=9. In this example, suppose the irq of the device is really irq5. Then when another device driver starts up where its device is set to irq5, you have two real devices using irq5 and a real conflict. The kernel approved of letting the second device use irq5 since it erroneously thought that the first device was using irq9 and that irq5 was free.
There are other cases like this where the kernel fails to know that an irq is in use. One is when an old ISA card with an irq set by a jumper is present, but it's driver hasn't started yet (or it may not even have a driver). Another case is where the BIOS set an irq in the hardware but no linux driver for that hardware ever started and Linux doesn't know about that irq. This can happen even for a PCI card and the irq will show up in lspci -v but will not be in the /proc/interrupts directory and thus not known by the kernel. Is this a bug in the kernel?
What are the symptoms of an interrupt conflict. One might think that the devices will not work at all, but since the addresses are known, the driver does communicate. Interrupts are often used to control the flow of data to and from the device and without interrupts, flow is not controlled. This may mean buffer overruns or even no flow at all since interrupt are used to initiate flow. For a serial modem, the result is extremely slow flow with long pauses and frequent errors. For a sound card it may mean that a word or two is heard and then nothing more.
This is when a device driver starts but immediately exits in order to avoid an interrupt conflict. It should display or log an error message something like "resource busy".
One case when an ISA device is activated but can't be assigned an interrupt (IRQ) since none are available. Or an interrupt may be available, but it can't be used since the hardware of the device that needs the interrupt doesn't support the interrupt number available (or the motherboard doesn't support it due to "routing" problems, see PCI Interrupts). If the ISA devices use up all the interrupts, then one or more PCI cards may be in conflict since they can't get any IRQs.
Normally, the BIOS will assign interrupts and will not create conflicts. But it may be forced to create conflicts if it runs out of IRQs. This can happen if someone has set up the BIOS to reserve certain IRQs for legacy ISA devices that are not PnP. These settings may be wrong and should be checked out, especially if you're having problems. For example, someone may have reserved an IRQ for an ISA card that has long since been removed from the PC. If you unreserved this IRQ then this IRQ is available and and conflict disappears.
Sometimes the BIOS will solve the problem of an IRQ shortage by using what it calls IRQ 0. There is no such IRQ available since the real IRQ 0 is permanently assigned to the computer's timer. But IRQ 0 here means that the driver should use polling instead of IRQs. This means that the driver frequently checks the device (polls it) to see if the device needs servicing by the interrupt service routine. Of course, this wastes computer time and there's more likelihood of a buffer overrun inside a device since it might not get serviced by the driver promptly enough.