IRQ Sharing with PCI Device
in [Device Drivers]
|
Prev: Problem in installing signed driver with DPInst.exe on VistaX64 RC
Next: KMDF Class Filter Driver Installs on Vista/XP.. Fails on 2K
From: bbartson on 18 Oct 2006 08:23 Hello, I've inherited a windows driver that was designed for the NT4 style architecture (non-PNP and non-WDM). Our company manufactures VMEbus cpu boards. This driver is for interfacing to the vmebus (via a pci-to-vme bridge device, the Tundra chip, which is a single function device). This driver works just fine on our older (2000 design) cpu boards which are using the same chip but a Phoenix bios. We've designed a new cpu, using the same chip but with a new bios (from General Software). The bios is ACPI compliant but currently it is only running in PIC mode (not APIC). My problem is this old NT4 style driver fails when it tries to allocate interrupts. It can get access to IO ports and PCI memory via the Tundra OK. The interrupt allocation fails with STATUS_CONFLICTING_ADDRESSES. This error code comes from IoAssignResources. The bios's pci enumeration allocates int 11 to the Tundra device. This gets stored in the pci config space for the Tundra device and this is what the driver attempts to use too. If I look at device manager I can see that ints 9,10 & 11 are shared between about 10 different devices (the Tundra shows up as a 'pci bridge device'). Mostly 6300 south bridge devices are on these ints. I have tried many different things to work around this. I have tried turning off PlugNPlay, tried masking certain INTs in the bios, mods to the driver code to use other api calls such as IoReportDetectedDevice, etc. Currently APIC mode is not turned ON in the bios because according to the bios vendor it is not fully debugged yet and they are working on fixing it. However, they don't think this will resolve the issue because the Tundra is wired on the board to use INT#A and this is shared with other devices. So my question is do you think that APIC mode would resolve this and if not is there some other approach the driver code could take, OR is this more likely a fundamental hardware issue with how the interrupts are routed on the board. Thanks,
From: already5chosen on 18 Oct 2006 12:35 bbartson wrote: > Hello, > > I've inherited a windows driver that was designed for the NT4 style > architecture (non-PNP and non-WDM). Our company manufactures VMEbus cpu > boards. This driver is for interfacing to the vmebus (via a pci-to-vme > bridge device, the Tundra chip, which is a single function device). > This driver works just fine on our older (2000 design) cpu boards which > are using the same chip but a Phoenix bios. > > We've designed a new cpu, using the same chip but with a new bios (from > General Software). The bios is ACPI compliant but currently it is only > running in PIC mode (not APIC). My problem is this old NT4 style driver > fails when it tries to allocate interrupts. It can get access to IO > ports and PCI memory via the Tundra OK. The interrupt allocation fails > with STATUS_CONFLICTING_ADDRESSES. This error code comes from > IoAssignResources. > > The bios's pci enumeration allocates int 11 to the Tundra device. This > gets stored in the pci config space for the Tundra device and this is > what the driver attempts to use too. If I look at device manager I can > see that ints 9,10 & 11 are shared between about 10 different devices > (the Tundra shows up as a 'pci bridge device'). Mostly 6300 south > bridge devices are on these ints. > > I have tried many different things to work around this. I have tried > turning off PlugNPlay, tried masking certain INTs in the bios, mods to > the driver code to use other api calls such as IoReportDetectedDevice, > etc. Currently APIC mode is not turned ON in the bios because according > to the bios vendor it is not fully debugged yet and they are working on > fixing it. However, they don't think this will resolve the issue > because the Tundra is wired on the board to use INT#A and this is > shared with other devices. > > So my question is do you think that APIC mode would resolve this and if > not is there some other approach the driver code could take, OR is this > more likely a fundamental hardware issue with how the interrupts are > routed on the board. > > Thanks, Nt4-style PCI drivers must use HalAssignSlotResources(). All other approaches are conflict-prone. Of course, if backward compatibility is not required you could just convert everything to WDM. Then instead of being at mercy of BIOS vendor you end up at mercy of Microsoft. I'm not sure which one is worse :(
From: bbartson on 19 Oct 2006 11:13 already5chosen(a)yahoo.com wrote: > bbartson wrote: > > Hello, > > > > I've inherited a windows driver that was designed for the NT4 style > > architecture (non-PNP and non-WDM). Our company manufactures VMEbus cpu > > boards. This driver is for interfacing to the vmebus (via a pci-to-vme > > bridge device, the Tundra chip, which is a single function device). > > This driver works just fine on our older (2000 design) cpu boards which > > are using the same chip but a Phoenix bios. > > > > We've designed a new cpu, using the same chip but with a new bios (from > > General Software). The bios is ACPI compliant but currently it is only > > running in PIC mode (not APIC). My problem is this old NT4 style driver > > fails when it tries to allocate interrupts. It can get access to IO > > ports and PCI memory via the Tundra OK. The interrupt allocation fails > > with STATUS_CONFLICTING_ADDRESSES. This error code comes from > > IoAssignResources. > > > > The bios's pci enumeration allocates int 11 to the Tundra device. This > > gets stored in the pci config space for the Tundra device and this is > > what the driver attempts to use too. If I look at device manager I can > > see that ints 9,10 & 11 are shared between about 10 different devices > > (the Tundra shows up as a 'pci bridge device'). Mostly 6300 south > > bridge devices are on these ints. > > > > I have tried many different things to work around this. I have tried > > turning off PlugNPlay, tried masking certain INTs in the bios, mods to > > the driver code to use other api calls such as IoReportDetectedDevice, > > etc. Currently APIC mode is not turned ON in the bios because according > > to the bios vendor it is not fully debugged yet and they are working on > > fixing it. However, they don't think this will resolve the issue > > because the Tundra is wired on the board to use INT#A and this is > > shared with other devices. > > > > So my question is do you think that APIC mode would resolve this and if > > not is there some other approach the driver code could take, OR is this > > more likely a fundamental hardware issue with how the interrupts are > > routed on the board. > > > > Thanks, > > > Nt4-style PCI drivers must use HalAssignSlotResources(). All other > approaches are conflict-prone. > > Of course, if backward compatibility is not required you could just > convert everything to WDM. Then instead of being at mercy of BIOS > vendor you end up at mercy of Microsoft. I'm not sure which one is > worse :( Thanks for the reply. So I've started using HalAssignSlotResources however now I get an error from IoConnectInterrupt (STATUS_INVALID_PARAMETER = 0xC000000D). Is there some other call I should be using instead of this? BTW, all of this legacy code works on one of our older board designs with XP and a Phoenix bios. Backward compatibility is not a requirement and I do plan to rewrite as WDM but right now I just need to get it working so we can show our customers the new hardware is viable. This is what the call looks like : status = IoConnectInterrupt( &m_InterruptObject, Isr, context, NULL, //m_pSpin m_Vector, m_Irql, m_SynchIrql, m_Mode, TRUE, //m_bShareVector, m_Affinity, FALSE //m_bSaveFloat ); And the debug output from WinDbg (DbgPrint immediately after call to IoConnect) : IN KInterrupt::Connect IoConnectInterrupt call, status=0xC000000D, Isr=0xF65D7D1A, context=0x85D26C80 m_pSpin=0x0, m_Vector=0x39, m_Irql=0x12, m_SynchIrql=0x12, m_Mode=0x1, m_Affinity=0x1
From: already5chosen on 19 Oct 2006 14:12 bbartson wrote: > already5chosen(a)yahoo.com wrote: > > bbartson wrote: > > > Hello, > > > > > > I've inherited a windows driver that was designed for the NT4 style > > > architecture (non-PNP and non-WDM). > > > <snip> > > > My problem is this old NT4 style driver fails when it tries to allocate interrupts. > > > The interrupt allocation fails with STATUS_CONFLICTING_ADDRESSES. This error code comes from > > > IoAssignResources. > > > > > > > > > Nt4-style PCI drivers must use HalAssignSlotResources(). All other > > approaches are conflict-prone. > > > > Of course, if backward compatibility is not required you could just > > convert everything to WDM. Then instead of being at mercy of BIOS > > vendor you end up at mercy of Microsoft. I'm not sure which one is > > worse :( > > Thanks for the reply. So I've started using HalAssignSlotResources > however now I get an error from IoConnectInterrupt > (STATUS_INVALID_PARAMETER = 0xC000000D). Is there some other call I > should be using instead of this? IoConnectInterrupt() is o.k. but you should map interrupt vector obtained from HalAssignSlotResources via HalGetInterruptVector(). Something like that: KIRQL mapped_system_Irql = pPartialDescriptor->u.Interrupt.Level, KAFFINITY mapped_system_Affinity = pPartialDescriptor->u.Interrupt.Affinity; ULONG mapped_system_vector = HalGetInterruptVector(PCIBus, BusNumber, pPartialDescriptor->u.Interrupt.Level, pPartialDescriptor->u.Interrupt.Vector, &mapped_system_Irql, &mapped_system_Affinity); status = IoConnectInterrupt( &m_InterruptObject, Isr, context, NULL, mapped_system_vector, mapped_system_Irql, mapped_system_Irql, LevelSensitive, TRUE, mapped_system_Affinity, FALSE);
From: bbartson on 20 Oct 2006 12:17
already5chosen(a)yahoo.com wrote: > bbartson wrote: > > already5chosen(a)yahoo.com wrote: > > > bbartson wrote: > > > > Hello, > > > > > > > > I've inherited a windows driver that was designed for the NT4 style > > > > architecture (non-PNP and non-WDM). > > > > <snip> > > > > My problem is this old NT4 style driver fails when it tries to allocate interrupts. > > > > The interrupt allocation fails with STATUS_CONFLICTING_ADDRESSES. This error code comes from > > > > IoAssignResources. > > > > > > > > > > > > > Nt4-style PCI drivers must use HalAssignSlotResources(). All other > > > approaches are conflict-prone. > > > > > > Of course, if backward compatibility is not required you could just > > > convert everything to WDM. Then instead of being at mercy of BIOS > > > vendor you end up at mercy of Microsoft. I'm not sure which one is > > > worse :( > > > > Thanks for the reply. So I've started using HalAssignSlotResources > > however now I get an error from IoConnectInterrupt > > (STATUS_INVALID_PARAMETER = 0xC000000D). Is there some other call I > > should be using instead of this? > > IoConnectInterrupt() is o.k. but you should map interrupt vector > obtained from HalAssignSlotResources via HalGetInterruptVector(). > Something like that: > > KIRQL mapped_system_Irql = pPartialDescriptor->u.Interrupt.Level, > KAFFINITY mapped_system_Affinity = > pPartialDescriptor->u.Interrupt.Affinity; > ULONG mapped_system_vector = HalGetInterruptVector(PCIBus, > BusNumber, > pPartialDescriptor->u.Interrupt.Level, > pPartialDescriptor->u.Interrupt.Vector, > &mapped_system_Irql, > &mapped_system_Affinity); > > status = IoConnectInterrupt( > &m_InterruptObject, > Isr, > context, > NULL, > mapped_system_vector, > mapped_system_Irql, > mapped_system_Irql, > LevelSensitive, > TRUE, > mapped_system_Affinity, > FALSE); OK, so this was already being done for the most part but you did point out something which I was not doing and that is to set the InterruptMode to LevelSensitive. Once I did this I was able to get IoConnectInterrupt to return SUCCESS. So I tried generating an interrupt, on the VMEbus and it does generate an interrupt (which only means it's communcating with the Tundra through PCI memory) but it won't call the ISR associated with this INT. Early in the debug process I had to unload the graphics driver (855 GME) and allow XP to use it's native vga.sys driver so just for grins I decided to load the 855 driver again. What happens is I lose video completely. The system appears to boot (according to what I see in WinDbg) but no video. The other peculiar thing is the the address for the ISR changes dramatically with the video driver loaded which makes me wonder if somehow they are sharing the ISR (since the video device and Tundra do share the same IRQ). How can I use WinDbg to tell if something like this is happening (there is some conflict between the Intel 855 video driver and my driver)? |