Shared Interrupts RRS feed

  • Question

  • I am working on a custom X86 system that has numerous devices on the PCI bus.  In most cases,  the device drivers use an installable interrupt service routine (IISR) and multiple devices share interrupts.  The configuration works quite well with the exception of an installable audio driver that shares IRQ6 with a custom device driver that I wrote.  The audio driver implements the normal shared approach where the audio hardware is checked to see if it is the interrupt source while my custom driver simply get calls if no other device sharing this interrupt has signaled the interrupt.  Although this works well for long periods (>6 hours) when the custom driver is signalled every 10 ms and the audio driver is signalled 5-10 times per minute, it ultimately fails with an access violation exception in the audio driver.  I suspect that the audio driver may be at fault (it has had other issues) but I want to confirm thata my custom driver is not at fault.

    I think that it is safe to have my custom driver use the default sysinter associated with IRQ6 as the event for any installed IRQ6 driver will be signalled prior to falling through to it.  Is this correct?

    Also, my custom driver runs in kernel mode while the audio driver is user mode - any issues with this?





    Tuesday, January 11, 2011 1:01 AM

All replies

  • Hi,

    Since the setup works well for greater than 6 hours, there should be something wrong with the Audio Driver itself.

    If it is possible to reproduce the error without installing your custom driver, you can confirm that there is something wrong with the Audio Driver.

    If you have source code for Audio Driver, you can enable some retail messages to know what causes the access violation. It may be the Audio Buffer or any resources used by Audio Driver.



    Tuesday, January 11, 2011 6:30 AM
  • Hi,

    Unfortunately, we do not have source code for the driver and the vendor is unwilling to supply it.  Although they are willing and interested in investigating the problem, the test configuration is quite involved and the failure is infrequent.  Thus far, the failure has only been observed when both drivers are present and active.


    Tuesday, January 11, 2011 7:25 PM
  • Another approach is to create a minimal driver for your device that do nothing but ack/clear IRQ and/or other necessary procedures to keep device working and sending out interrupts.
    In the case, if the audio driver is still failed, you can tell the vendor and show your dummy code to them that the dummy driver is too simple to screw up anything but it must be something wrong elsewhere (Audio Driver).

    In a IRQ sharing scenario, once the IRQ is trigger, OAL would mask the IRQ line source until InterruptDone called.

    So if you have an IST takes a while to accomplish its task (another case is you have low IST priority so it keeps pre- empted by other threads), then the OAL won't receive any IRQ (even the device already sent out) until the InterruptDone get invoked.

    Tuesday, January 11, 2011 10:04 PM
  • Thanks for the comments and suggestions. 

    Actually, the interrupt handling in my custom driver is very simple and is essentially what you suggested.  When the interrupt is signaled, it simply sets a global event shared with our application code and calls InterruptDone.  A thread in our application code pends on this named event and runs when it is signalled.  The code is below.


    // Handle interrupts until its time to exit


    while( !ExitMBCThread )


    // Wait for interrupt to be signalled

    WaitForSingleObject( MBCEvent, INFINITE );

    // Signal the global event used by the application

    SetEvent( gMBCEvent );

    // Enable interrupts




    Wednesday, January 12, 2011 2:56 PM
  • What is the thread priority of the IST?
    Also try to comment out the SetEvent statement to see if it makes any change?
    Wednesday, January 12, 2011 7:29 PM
  • The code that sets the gMBCEvent() is running in the kernel mode driver while the thread that pends on the event is running at priority 238.  Other threads in the app run at both higher and lower priority.  Since InterruptDone(MBCSysIntr); is in the kernel mode driver, I don't see that the IST has much of an effect on when it executes.

    Although commenting out the SetEvent statement was a great suggestion, when I did that, the application behaved badly due the thread watchdogging and other system issues.  I looked at addressing these issues but it seemed the changes would be be so pervasive that the test results wouldn't add much insight.     

    Friday, January 14, 2011 3:45 PM
  • While the driver shared the same IRQ with audio, as long as InterruptDone(MBCSysIntr) doesn't execute, the IRQ source won't be unmasked. (And audio driver may not serve its IRQ on-time).
    Since priority 238 is relative low prioriy, other higher priority threads (especially the one in your app that waiting for gMBCEvent) can pre-empt the IST and cause the delay of InterruptDone call.
    The IST priority should higher than any thread in your application to ensure IST can be always completed in time.
    Also you may want to measure the IRQ latency (from HW IRQ trigger in your system to the end of InterruptDone) to determine if there is a extreme delay of before calling InterruptDone.

    Friday, January 14, 2011 7:45 PM