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

I never did report what I found out on this:

I discovered in the PCI bridge spec (chapter 9, revision 1.1) that if
multiple devices on the other side of a PCI-to-PCI bridge (on an
expansion
board) are required to use the same PCI slot interrupt line
(INTA#-INTD#)
and therefore same IRQ#, the "interrupt pin" request in each of the
device's
PCI configuration header has to be different (they both don't request
INTA#
as I thought). For the first device, it had to specify INTA# and the
second
device needed to specify INTD#. When BIOS POST code is initializing
the
system, it assumes a pre-defined set of routing information and writes
a
common IRQ# to each device's "interrupt line" register in the
configuration
space.

Who would have thunk it?

So, no driver, Windows PnP manager, or BIOS problems were the
culprit--just
a misconfiguration in hardware...

So Mark, the bridge wasn't "directly" involved with the routing of the
interrupts--but the presence of the bridge did change the configuration
requirements for the devices on the secondary bus...

Cosmo


Mark Roddy wrote:
> 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: A question about hot-pluggable PCI.
    ... I program a hard-coded window into the PCI bridge behind CardBus. ... It turns out interrupt routing is the problem. ... When I added the following, I found drivers attaching to devices inside the ...
    (freebsd-hackers)
  • Re: A question about hot-pluggable PCI.
    ... I program a hard-coded window into the PCI bridge behind CardBus. ... It turns out interrupt routing is the problem. ... ...whereas normally the code was 'routing' IRQ 6 to INTA on the bridge. ...
    (freebsd-hackers)
  • Re: IRQ assignment in Windows 2K/XP/2003...
    ... I discovered in the PCI bridge spec ... board) are required to use the same PCI slot interrupt line ... So, no driver, Windows PnP manager, or BIOS problems were the ...
    (microsoft.public.development.device.drivers)
  • Re: Potential source of interrupt aliasing
    ... > that the device is asserting the interrupt on the WRONG PIN. ... allocated consecutively across APICs. ... > * The bridge chips have a limited number of IRQ pins. ...
    (freebsd-current)
  • Re: bridge with access on both interfaces
    ... >>'inside' and 'outside' IPs separately on each bridge interface, ... Some tcpdumps on both in and outside interfaces suggest an ARP ... > If you want to use IP while bridging, ... and net4801 is that the 3 ethernet controllers now share one interrupt. ...
    (freebsd-net)