Diagnosing IRQ and Driver Conflicts on Real Hardware Running FreeDOS

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.

The full standard IRQ table worth having on hand

On a classic ISA-era PC/AT-compatible system, the sixteen available IRQ lines had well-established conventional assignments: IRQ0 (system timer), IRQ1 (keyboard), IRQ2 (cascade to the second controller), IRQ3 (COM2/COM4), IRQ4 (COM1/COM3), IRQ5 (commonly free, hence its popularity for sound cards), IRQ6 (floppy controller), IRQ7 (LPT1), IRQ8 (real-time clock), IRQ9 through IRQ15 (largely free for expansion cards, with IRQ12 conventionally reserved for a PS/2 mouse, IRQ13 for the math coprocessor, and IRQ14 for the primary IDE channel). Knowing this table by heart isn’t necessary, but having it as a reference when a card’s jumpers or setup utility only show numbers, with no indication of what’s already likely claimed, saves real guesswork.

The cascade mechanism, and why IRQ2 and IRQ9 are secretly the same line

The original 8-bit ISA bus only exposed eight IRQ lines (0–7); the later 16-bit AT extension added a second interrupt controller chained onto the first specifically through IRQ2, meaning any device signaling on IRQ9 through IRQ15 actually routes through that same IRQ2 cascade line to reach the CPU. This is why some period documentation refers to “IRQ2/9” as effectively a single shared resource — a device jumpered for IRQ9 and another genuinely configured for IRQ2 can produce conflict symptoms that look identical to a same-numbered clash, even though the jumper settings themselves appear different at a glance.

Related:

Sources: