Resolving IRQ Conflicts On A Mother Board
| Field | Computer Engineering |
| Went Obsolete | Somewhere halfway the nineties |
| Made Obsolete By | Plug and Play technology |
| Knowledge Assumed | Basic knowledge of interrupts in computer hardware |
| When useful | When upgrading really old computers (or you have hardware that's _really_ picky about it's environment) |
When extra hardware was added to IBM-compatible PCs? the hardware needed to have an interrupt or IRQ assigned to function properly. Extra hardware was usually in the form of an expansion board, and a set of jumpers could be found on these to configure the IRQ used. Happy go lucky types just plugged the board into the slot and booted hoping chance would protect them from conflicts (two pieces of hardware using the same IRQ). This was somewhat haphazzard as an IRQ conflict might or might not result in an actual error message. More often, it would result in one or more pieces of hardware behaving erratically. The exciting thing was that any piece of hardware, be it a video card, the sound card, a memory expansion board or what have you, could break down and result in very beautiful failures. More concise types would keep lists showing the 15 interrupts for each computer and which was taken by what and would configure jumpers before actually installing the hardware.
—
- Actually, it's still necessary to resolve IRQ conflicts from time to time on PCs? that use specialized hardware like pro-grade soundcards with very low latencies. These cards want 1000 times a second updates to achieve 1ms latency. If that IRQ is shared with second device, it very much depends on the second device's behaviour.
