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 20 Oct 2006 16:40 bbartson wrote: > 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)? I've decided to repair and/or reload XP (whichever is required to get a working system again). It seems even when my driver is not loaded the mere act of installing the Intel 82855 video driver causes the video to quit working - so it's unlikely a conflict with my driver that is the culprit. THanks
From: Alexander Grigoriev on 20 Oct 2006 23:38 Are you handling shared interrupts correctly? Means do you return FALSE when you determine it's not your interrupt? "bbartson" <bbartson(a)xycomvme.com> wrote in message news:1161376847.480599.30560(a)m73g2000cwd.googlegroups.com... > >> 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)? > > I've decided to repair and/or reload XP (whichever is required to get a > working system again). It seems even when my driver is not loaded the > mere act of installing the Intel 82855 video driver causes the video to > quit working - so it's unlikely a conflict with my driver that is the > culprit. > THanks >
From: bbartson on 24 Oct 2006 17:29 Alexander Grigoriev wrote: > Are you handling shared interrupts correctly? Means do you return FALSE when > you determine it's not your interrupt? > > "bbartson" <bbartson(a)xycomvme.com> wrote in message > news:1161376847.480599.30560(a)m73g2000cwd.googlegroups.com... > > > >> 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)? > > > > I've decided to repair and/or reload XP (whichever is required to get a > > working system again). It seems even when my driver is not loaded the > > mere act of installing the Intel 82855 video driver causes the video to > > quit working - so it's unlikely a conflict with my driver that is the > > culprit. > > THanks > > Yes this is being done in the ISR? Currently the driver is initializing but it appears the ISR is not attached to the interrupt (I've put DbgPrint statements in the ISR and they never get called) The bios is not running in APIC mode so all the pci devices are piled on irq's 9, 10 & 11 (10 different devices). My device is sharing irq 11 with at least one other device (vga) depending on how I configure the bios. It is always shared though with at least one.
From: bbartson on 25 Oct 2006 10:36 bbartson wrote: > Alexander Grigoriev wrote: > > Are you handling shared interrupts correctly? Means do you return FALSE when > > you determine it's not your interrupt? > > > > "bbartson" <bbartson(a)xycomvme.com> wrote in message > > news:1161376847.480599.30560(a)m73g2000cwd.googlegroups.com... > > > > > >> 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)? > > > > > > I've decided to repair and/or reload XP (whichever is required to get a > > > working system again). It seems even when my driver is not loaded the > > > mere act of installing the Intel 82855 video driver causes the video to > > > quit working - so it's unlikely a conflict with my driver that is the > > > culprit. > > > THanks > > > > > Yes this is being done in the ISR. Currently the driver is initializing > but it appears the ISR is not attached to the interrupt (I've put > DbgPrint statements in the ISR and they never get called) > > The bios is not running in APIC mode so all the pci devices are piled > on irq's 9, 10 & 11 (10 different devices). My device is sharing irq 11 > with at least one other device (vga) depending on how I configure the > bios. It is always shared though with at least one. Yes this is being done in the ISR.
From: bbartson on 7 Nov 2006 11:32
bbartson wrote: > bbartson wrote: > > Alexander Grigoriev wrote: > > > Are you handling shared interrupts correctly? Means do you return FALSE when > > > you determine it's not your interrupt? > > > > > > "bbartson" <bbartson(a)xycomvme.com> wrote in message > > > news:1161376847.480599.30560(a)m73g2000cwd.googlegroups.com... > > > > > > > >> 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)? > > > > > > > > I've decided to repair and/or reload XP (whichever is required to get a > > > > working system again). It seems even when my driver is not loaded the > > > > mere act of installing the Intel 82855 video driver causes the video to > > > > quit working - so it's unlikely a conflict with my driver that is the > > > > culprit. > > > > THanks > > > > > > > > Yes this is being done in the ISR. Currently the driver is initializing > > but it appears the ISR is not attached to the interrupt (I've put > > DbgPrint statements in the ISR and they never get called) > > > > The bios is not running in APIC mode so all the pci devices are piled > > on irq's 9, 10 & 11 (10 different devices). My device is sharing irq 11 > > with at least one other device (vga) depending on how I configure the > > bios. It is always shared though with at least one. > > Yes this is being done in the ISR. For the sake of anyone that may peruse this thread in the future, this problem was eventually resolved by running the BIOS in non-acpi mode and re-installing XP in the non-acpi mode also. This is a temporary solution but our market/customers don't really care about ACPI for now so it's not a big deal. |