Resolving IRQ Sharing Conflicts on PCIe Expansion Cards Using MSI Interrupts

Multiple PCIe devices enumerating to the same legacy IRQ — with Device Manager refusing to reassign any of them — is a class of conflict that shows up in card-dense industrial systems, and it has a clean fix where the hardware supports it: Message Signaled Interrupts. This application note documents the diagnostic approach and the per-device registry procedure DuroPC support uses in the field, based on a documented case involving a DAP Technology 1394 (FireTrac / MIL1394) PCIe card.

Background

On legacy PCIe interrupt handling, multiple devices can be assigned to the same shared IRQ line. In most configurations this is transparent to the user. On some platforms and PCIe topologies, however, several devices sharing a single legacy IRQ can prevent the operating system from allocating additional IRQ resources, and Windows Device Manager will not permit a manual IRQ reassignment (the option appears greyed out under Device Properties).

This condition has been observed on DuroPC systems where a DAP Technology 1394 (FireTrac / MIL1394) PCIe interface card is installed alongside other PCIe devices — for example, a National Instruments GPIB card and a Comtrol (Rocketport) serial adapter. All three devices were observed enumerating to the same IRQ, with no available means to force any of them onto a separate IRQ through the standard Device Manager interface.

Message Signaled Interrupts (MSI) address this by allowing a device to signal the CPU via a memory write rather than a dedicated physical interrupt line, removing it from legacy IRQ sharing entirely. Where a device supports MSI, enabling it is typically sufficient to resolve this class of conflict.

Recommended Diagnostic Approach

Before modifying interrupt handling, rule out simpler platform-level causes. In field cases handled by DuroPC support, the following steps were used to isolate the issue to interrupt allocation rather than a hardware or platform fault:

1. Confirm system BIOS is at the latest available version for the platform.
2. Install the latest chipset driver package for the platform (e.g., current Intel Chipset INF Utility for Intel-based platforms).
3. In BIOS, review the ACPI configuration settings, including any "ACPI Auto-Configuration" option — test with this setting both enabled and disabled. Note that changing this setting can affect the existing OS installation.
4. If the platform has multiple PCIe switches on the backplane, try relocating the affected cards across slots routed through different switches, not just different physical slots on the same switch.
5. If a custom Windows image was used, confirm whether it was built on the same hardware platform being tested, or migrated from a different system — IRQ and driver state can carry over incorrectly between platforms.

In one documented case, all of the above steps were performed without resolving the shared-IRQ condition, which confirmed the issue was specific to legacy interrupt allocation on that platform/card combination rather than a BIOS, driver, or OS configuration fault. This narrowed the fix to interrupt mode itself.

Enabling MSI Mode via Registry Edit

This procedure enables MSI support for a specific PCIe device by editing its interrupt management registry key. It applies per-device and does not require any BIOS changes.

Caution: Create a full system backup or a Windows System Restore Point before making any registry changes. Modify one registry value at a time and restart the system between each change so that any adverse effect can be isolated. Editing the registry incorrectly can affect system stability — proceed carefully and only on the specific value documented below.

1. Locate the device's registry key

1. Open Device Manager and locate the target device.
2. Right-click the device and select Properties, then switch to the Details tab.
3. From the Property drop-down list, select Device Instance Path and note the value shown, e.g. PCI\VEN_10EC&DEV_8168&SUBSYS_816810EC&REV_02\6&12634193&0&00000020.

This path is relative to the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum.

2. Navigate to the device's interrupt management key

Open Registry Editor (regedit) and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI. Locate the subkey matching the vendor/device identifier from the Device Instance Path (e.g. VEN_10EC&DEV_8168&SUBSYS_816810EC&REV_02), then the instance ID beneath it. Expand the subtree to Device Parameters\Interrupt Management\MessageSignaledInterruptProperties.

If a device does not expose a MessageSignaledInterruptProperties key, or has no MSISupported value under it, that device does not support software-enabled MSI. In this situation, an MSI-capable firmware or driver update from the card manufacturer is required before this procedure can be applied — see the firmware-level resolution section below.

3. Enable MSI

1. Double-click the MSISupported DWORD value.
2. Change the value data from 0 to 1.
3. Restart the system.
4. Return to Device Manager and confirm the device's IRQ. A successful change will show a negative IRQ value, which indicates the device is now using MSI rather than a legacy shared line-based interrupt.

To revert to legacy interrupt mode, set MSISupported back to 0 and restart.

Applicability and Known Limitations

This registry-based approach only works for devices whose driver already exposes MSI capability in the interrupt management key. In field testing, this was true for the DAP 1394 card but not for either the NI-GPIB card or the Comtrol (Rocketport) serial adapter installed in the same system — neither exposed a MessageSignaledInterruptProperties key, and no further options were available under their device parameters.

Where a device does not expose MSI support, other mitigations to consider include:

• Contacting the card manufacturer to confirm whether an MSI-capable firmware or driver release is available or planned.
• Evaluating an alternate DuroPC platform with a PCIe topology (switch/slot arrangement) that avoids the conflicting IRQ assignment — DuroPC can advise on platform options with additional independent PCIe lanes/switches for card-dense configurations.
• Re-testing card placement across PCIe slots routed through different backplane switches, as IRQ sharing behavior can vary by which switch a slot is routed through.

Firmware-Level Resolution (Vendor Coordination)

Where a device's existing driver does not support MSI at all, a registry edit cannot enable it — MSI capability must be built into the device's firmware and driver. In a documented case involving the DAP 1394 card, DuroPC engaged directly with DAP Technology's engineering team, working alongside the customer's own engineering staff, to pursue an MSI-capable firmware update for the card once the registry-based approach alone proved insufficient across all affected devices. DAP Technology subsequently released an MSI-capable FireStack firmware/software update for the 1394 card, which resolved the interrupt conflict in that deployment.

Throughout this process, DuroPC ran the platform-level diagnostics documented above to rule out BIOS, driver, and OS-level causes, coordinated directly with DAP Technology's engineering team on the firmware development, and proposed alternate DuroPC hardware platforms as a parallel contingency to keep the customer's program schedule protected while the firmware fix was in development.

For current MSI-capable firmware/driver availability for a specific DAP Technology card model, contact DAP Technology directly or reach out to DuroPC support, who can coordinate with DAP Technology on the customer's behalf.