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

Paul L wrote:
Why do you say that the motherboard has them or'd together? The Int A lines do not need to be bussed together. The mother board can route the Int lines from each slot anyway it wishes.


Yes indeed but from the description of the OP's problem it would appear that the lines are ORd together and that the BIOS is misreporting them as separate. It is not that it has to be this way, it is that this appears, from the evidence presented, to be a fact in this situation.

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. Call them DevA and DevB. DevB asserts an interrupt, but the ISR for DevA gets invoked. DevA.ISR returns False, as the interrupt is not for DevA. DevB.ISR does not get invoked. Instead, as the PCI interrupt is still asserted, DevA.ISR is immediately re-invoked. Repeat ad nauseum. I say that the bios is misreporting the interrupt wiring.

So the bridge is actually supposed to sort the INTA-D routing from its slot to its secondary PCI bus across all of the secondary slots. But the bios has to correctly report how the primary bus physical slot handles INTA-D. If it says they are separately routable when in fact they are OR'd together, I think big trouble is in the works. Of course it is also possible that the bridge device has the INTA-D sorting wrong as well.

Paul
"Mark Roddy" <markr@xxxxxxxxxxxxxx> wrote in message news:%23y$Xs5kOFHA.2356@xxxxxxxxxxxxxxxxxxxxxxx

Cosmo wrote:

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



My PCI book says that the interrupt lines on your pci devices are directly connected to the same interrupt lines on the connector slot your bridge is plugged into. In other words, for interrupts, the bridge is not really in the picture. So the situation appears to be that the OS thinks that these devices have separately routable interrupts when in fact they motherboard has them or'd together. So somebody is confused. The choices are: me, the bios, or the os.


--

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com





--

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
.

Relevant Pages

  • Re: Polling loop good here???
    ... The "vertical retrace interrupt" was IRQ 2... ... In today's hardware - as has been mentioned - they've almost certainly ... it...make use of the drivers... ...
    (alt.lang.asm)
  • 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...
    ... >> Both PCI devices request an interrupt and are physically attached to INTA ... >> dynamically assigns an IRQ # for each of the two devices. ... >> the driver during start time? ...
    (microsoft.public.development.device.drivers)
  • 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)
  • Re: [RFC] killing the NR_IRQS arrays.
    ... Subject: IRQ API ... interrupt controllers, and knowing hardware designers, they'll ... I believe that there are some common problems with the existing API ... architecture specific drivers now if they feel they would benefit ...
    (Linux-Kernel)