IRQ assignment in Windows 2K/XP/2003...

OS: Windows 2K/XP/2003
Hardware Platform: Intel x86-based PC, PIII, 815E chipset
Drivers: WDM-style

I have two independent, single-function PCI devices on the other side of a
PCI-to-PCI bridge:

PCI slot <---> PCI-to-PCI bridge <---> PCI device #1
|
---> PCI device #2

Both PCI devices request an interrupt and are physically attached to INTA on
the PCI bus. A seperate WDM device driver is written to control each of the
PCI devices.

When the drivers load for each of the two devices, the system (PnP manager)
dynamically assigns an IRQ # for each of the two devices. Sometimes the IRQ
# is the same and sometimes the IRQ # is different. I can disable and
re-enable each device via the Windows XP Device Manager and get the IRQ #
assignments to change.

Now, when the two devices are assigned a common IRQ # and INTA is asserted
by either device, the ISR in each of the drivers is called to determine if
they are interrupting (one says no and the other says yes--hardware is
serviced and all is well). However, when the two devices are assigned
different IRQ #s, only the ISR for one of the drivers is called. If the
other device happened to be generating the interrupt, the system is locked
up as the non-interrupting device's ISR is continually called in a loop.

I am inclined to believe that as long as the two PCI devices are assigned
different IRQ #s by PnP when they both use the same INTA interrupt line on
the PCI bus, both device's ISRs are not guaranteed to be consulted.

What can be done to cure this problem? Can something different be done in
the driver during start time? In the IoConnectInterrupt() call? Right now
I am simply passing the information handed to the driver by the PnP manager
into the IoConnectInterrupt() call. Any other options? Can anything be
done to the PCI configuration space of the end-devices or PCI-to-PCI bridge
to influence the system's choice of IRQ #? I would like to understand this
behavior better (what is going on under the covers).

Regards,
Cosmo


.

Relevant Pages

  • Re: IRQ assignment in Windows 2K/XP/2003...
    ... Both PCI devices request an interrupt and are physically attached to INTA ... When the drivers load for each of the two devices, ... dynamically assigns an IRQ # for each of the two devices. ...
    (microsoft.public.development.device.drivers)
  • IRQ assignment in Windows 2K/XP/2003...
    ... Both PCI devices request an interrupt and are physically attached to INTA on ... When the drivers load for each of the two devices, ... Sometimes the IRQ ...
    (microsoft.public.development.device.drivers)
  • Re: IRQ assignment in Windows 2K/XP/2003...
    ... He has two devices behind the bridge, each of which are given separate interrupt vectors by the OS, indicating that the OS believes them to be separately routable. ... Both PCI devices request an interrupt and are physically attached to INTA on ... When the drivers load for each of the two devices, ... Sometimes the IRQ ...
    (microsoft.public.development.device.drivers)
  • Re: [patch 2.6.20-rc1 5/6] SA1100 GPIO wrappers
    ... require drivers map the other way themselves when they need to. ... Having that GPIO-to-IRQ mapping is quite routine; ... GPIO is in the required state. ... IRQ framework can't do "all" the needed stuff on platforms ...
    (Linux-Kernel)
  • Re: [RFC] [PATCH -mm] ASIC3 driver
    ... asic3 defines an additional range of IRQs for the ... so this delves into the innards of the IRQ management. ... Currently nothing, but the plan is to push several drivers (leds, MMC, ... * Copyright 2001 Compaq Computer Corporation. ...
    (Linux-Kernel)
Loading