IRQ assignment in Windows 2K/XP/2003...
in [Device Drivers]
|
From: Cosmo on 5 Apr 2005 20:29 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
From: Mark Roddy on 5 Apr 2005 22:14 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
From: Paul L on 7 Apr 2005 13:13 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. Paul "Mark Roddy" <markr(a)hollistech.com> wrote in message news:%23y$Xs5kOFHA.2356(a)TK2MSFTNGP14.phx.gbl... > 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
From: Mark Roddy on 7 Apr 2005 19:32 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(a)hollistech.com> wrote in message > news:%23y$Xs5kOFHA.2356(a)TK2MSFTNGP14.phx.gbl... > >>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
From: Cosmo on 29 Apr 2005 15:42 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(a)hollistech.com> wrote in message > > news:%23y$Xs5kOFHA.2356(a)TK2MSFTNGP14.phx.gbl... > > > >>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
|
Pages: 1 Prev: WM_DEVICECHANGE/DBT_DEVICEARRIVAL is so slo-o-ow Next: Install kbfiltr |