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: [PATCH RFC v5] net: add PCINet driver
    ... These are PCI boards, not PCIe. ... I tried enabling MSI on the Freescale boards in the driver, ... does not have an interrupt line. ... Scanning 0 areas for low memory corruption ...
    (Linux-Kernel)
  • 2.6.17-rc3 "Bus #03 (-#06) is hidden behind transparent bridge"
    ... PCI: PCI BIOS revision 2.10 entry at 0xf031f, ... ACPI: Interpreter enabled ... Using PIC for interrupt routing ... Using APIC driver default ...
    (Linux-Kernel)
  • Re: Accessing PCI device behind a non-transparent bridge.
    ... Maybe you need your own driver for non-transparent PCI bridge, ... Such a driver of your own should have implemented the DMA interface and the ... I have a PCI bridge that originates a PCI like bus on its secondary device. ...
    (microsoft.public.development.device.drivers)
  • Re: [PATCH]: PCI Error Recovery Implementation
    ... > to use this API to recover from PCI errors. ... > +errors, and to be notified of, and respond to, a reset sequence. ... > +A driver doesn't have to implement all of these callbacks. ... If you get an interrupt and your ...
    (Linux-Kernel)
  • Re: IRQ assignment in Windows 2K/XP/2003...
    ... board) are required to use the same PCI slot interrupt line ... PCI configuration header has to be different (they both don't request ... So, no driver, Windows PnP manager, or BIOS problems were the ... the bridge wasn't "directly" involved with the routing of the ...
    (microsoft.public.development.device.drivers)