IRQ Sharing with PCI Device

Discussion in 'Windows Vista Drivers' started by bbartson, Oct 18, 2006.

  1. bbartson

    bbartson Guest

    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,
     
    bbartson, Oct 18, 2006
    #1
    1. Advertisements


  2. 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 :(
     
    already5chosen, Oct 18, 2006
    #2
    1. Advertisements

  3. bbartson

    bbartson Guest

    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
     
    bbartson, Oct 19, 2006
    #3
  4. 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);
     
    already5chosen, Oct 19, 2006
    #4
  5. bbartson

    bbartson Guest

    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)?
     
    bbartson, Oct 20, 2006
    #5
  6. bbartson

    bbartson Guest

    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
     
    bbartson, Oct 20, 2006
    #6
  7. Are you handling shared interrupts correctly? Means do you return FALSE when
    you determine it's not your interrupt?
     
    Alexander Grigoriev, Oct 21, 2006
    #7
  8. bbartson

    bbartson Guest

    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.
     
    bbartson, Oct 24, 2006
    #8
  9. bbartson

    bbartson Guest

    Yes this is being done in the ISR.
     
    bbartson, Oct 25, 2006
    #9
  10. bbartson

    bbartson Guest

    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.
     
    bbartson, Nov 7, 2006
    #10
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.