INFO: Sharing Interrupts in PCI Device Drivers

ID: Q191839

The information in this article applies to:

Microsoft Win32 Device Driver Kit (DDK) for Windows NT, version 4.0

SUMMARY

With the advent of the PCI bus and its associated PCI bus devices, shareable interrupts have become a common occurrence. Device driver programmers must adjust their programming approach in order to deal effectively with the problems created by shareable interrupts.

MORE INFORMATION

When more than one device is sharing the same physical interrupt this also means that the interrupt handlers of these devices are chained to the same interrupt. When any physical interrupt fires, the operating system then calls each interrupt handler by travelling down the chain of interrupt handlers until one of the handlers claims the interrupt. During this process, one problem can occur where the actual owner of the interrupt does not claim it.

There are two likely explanations for this scenario. One is that the device driver does not hook its interrupt handler. Another possible cause is that the device driver is loaded. Both of these cases are discussed in detail below.

Device Driver Does Not Hook Its Interrupt Handler

In this case, the device driver is initializing the device, which causes the interrupt to fire before it hooks up to its interrupt handler. This situation is one that you want to avoid at all costs. Some drivers are known to behave like this in the ISA bus interrupt environment (where interrupts cannot be shared). In ISA's "non-shareable" environment, the interrupt is masked at the programmable interrupt controller (PIC) until virtualized. When the interrupt fires before it is hooked up to its interrupt handler under these conditions, it is harmless. However, in the PCI bus' shareable interrupt environment, if other devices have already hooked up with the same interrupt and unmasked it at the PIC, the firing of the device interrupt before it is hooked up with the interrupt handler could cause this unclaimed interrupt to potentially crash the system.

Device Driver Is Not Loaded

In rare cases, this could suggest that the hardware device is at fault because a device should not fire any interrupt when it is first powered up until after a device driver has initialized the hardware, which usually includes hooking up the interrupt handler and unmasking the interrupt.

More commonly, this problem is caused by the device driver not shutting down properly before system restart. For example, a LAN card might be happily firing interrupts on packets it receives, as expected. For example, if the user should suddenly decide to restart the system, this means the device will receive a shut down notification and the system will subsequently unload. If the device driver does not disable the interrupt during shutdown and if the LAN card is sharing its interrupt with another device loaded ahead of the LAN driver when the system restarts, the LAN interrupt will be unclaimed because the LAN driver has not yet been loaded.

There are two possible culprits that could be causing this problem. The first is the device driver, which should always disable its interrupt during shutdown. The second is BIOS, which should also disable any interrupt of any non-boot motherboard devices during the power-on self test (POST). Although rare, reason that BIOS may be the cause is that the operating system might be rebooted without going through a proper shutdown. For example, a spontaneous reboot might occur as a result of a surprise removal of a device, or simply because of a bug in the operating system. This is why the BIOS should ensure that interrupts of all non-booting motherboard devices are shut off during POST.

If you disable interrupts during shutdown under Microsoft Windows 98, the device driver has to be able to handle three configuration messages, CONFIG_STOP, CONFIG_REMOVE, and CONFIG_SHUTDOWN. In all three of these configuration messages, the device driver should program the hardware devices to inactive state and mask all interrupts.


Keywords          : kbDDK kbNTOS400 kbWinOS2000 kbWinOS98 
Version           : 
Platform          : 
Issue type        : kbinfo

Last Reviewed: March 7, 1999