Diagnosing IRQ and Driver Conflicts on Real Hardware Running FreeDOS
A sound card, network card, or serial device doesn't work, or the system hangs when two devices are used together. Classic IRQ conflicts, and how to actually resolve them.
On real, physical hardware, FreeDOS (like the DOS-era systems it’s compatible with) still deals with interrupt request lines (IRQs) the old-fashioned way — a limited, shared set of hardware interrupt numbers that every device competes for, without the plug-and-play resource negotiation modern operating systems handle transparently.
Understanding why this is still a real concern
Legacy ISA-era hardware and firmware-flashing scenarios (the most common reason to run FreeDOS on real hardware today) frequently involve components — sound cards, older network interface cards, serial and parallel port devices — expecting a specific, manually-configured IRQ, DMA channel, and I/O base address. Two devices configured to use the same IRQ will either silently fail (one device simply doesn’t work), or actively conflict, hanging or crashing the system when both are accessed.
Step 1: identify what’s actually installed and what it expects
Check any documentation or jumper settings for each installed card — older hardware often has physical jumpers or a DOS-based configuration utility (frequently shipped with the card itself) for setting its IRQ, DMA, and I/O address explicitly:
C:\>DEBUG
-d 0:0 (inspect the interrupt vector table directly, for advanced diagnosis)
Many cards from this era shipped a SETUP.EXE or similarly named configuration utility specifically for querying and changing these settings — check for one on the card’s original driver disk before resorting to manual jumper inspection.
Step 2: check for an obvious conflict pattern
The classic symptom is: device A works fine alone, device B works fine alone, but enabling both simultaneously causes one (or both) to fail or the system to hang. This strongly suggests an IRQ or I/O address collision between the two. Common default IRQ assignments worth checking first: IRQ 5 and IRQ 7 are frequently used by sound cards and parallel ports respectively, and were common collision points; COM ports traditionally share IRQ 4 (COM1/COM3) and IRQ 3 (COM2/COM4) in pairs, which is a frequent source of conflicts when more than two serial devices are in use.
Step 3: reassign one device to an unused IRQ
Once you’ve identified a collision, reconfigure one of the conflicting devices (via jumpers, a DOS setup utility, or BIOS settings for onboard devices) to use a genuinely free IRQ instead. Check your motherboard/BIOS setup for which IRQs are already claimed by onboard chipset functions before picking one, to avoid trading one conflict for another.
Step 4: update CONFIG.SYS and AUTOEXEC.BAT to match
If a device’s driver takes IRQ/address parameters directly on its DEVICE= line or in its AUTOEXEC.BAT load command, update those to match whatever you just reconfigured in hardware — a mismatch between what the hardware is actually jumpered/configured for and what the driver is told to expect produces the exact same symptoms as a genuine conflict, even after the underlying hardware conflict is resolved:
DEVICE=C:\DRIVERS\SOUND.SYS /IRQ=5 /DMA=1
Step 5: for onboard/integrated devices, check BIOS resource settings
Modern hardware running FreeDOS (via a bootable USB for firmware flashing, most commonly) generally handles resource assignment automatically through UEFI/BIOS rather than requiring manual IRQ jumpers — if you’re troubleshooting on genuinely modern hardware rather than a legacy ISA-era machine, check the system’s BIOS/UEFI setup for any legacy device resource settings before assuming this is a DOS-level configuration problem at all.
Why this class of problem is largely historical, but still real
IRQ conflicts were a defining frustration of PC hardware through the mid-1990s, largely solved industry-wide by Plug and Play and later ACPI-based resource negotiation — but FreeDOS’s continued use on genuinely old hardware, or in scenarios deliberately avoiding a full BIOS/OS resource-negotiation layer, means this older, manual approach to hardware configuration is still occasionally the actual thing standing between you and a working setup.