We have come across a case where our resource manager mixed with a user’s application is producing “out of Interrupt events” error messages with QNX6.3.0 SP3.
Our resource manger makes use of InterruptAttachEvent and has the correct InterruptUnmask call in the event handler.
We suspect the issue is related to something in their code, but wonder if anyone has any tips on querying the event queue from the qnx command line or from a program?
Is there some way of configuring the size of the interrupt event queue?
From the docu:
There are just 2 reasons mentioned in the docu and no workaround is known to me:
- The interrupt load is too high for the CPU (it’s spending all of the time handling the interrupt).
- There’s an interrupt handler – one connected with InterruptAttach(), not InterruptAttachEvent() – that doesn’t properly clear the interrupt condition from the device (leading to the case above).
May your interrupts take to long to finish? Try a small interrupt just sending a signal to another function to startup. This may shorten your IRs so you wonÂ´t run out of interrupt events.
Thanks for your input.
We are only making use of InterruptAttachEvent. Our Interrupt Event handler does not really do a tremendous amount of work either.
I really feel the issue lies within other programs on the test system.
Having some way of querying the queues would be very helpful, I think.
You could use the system profiler to figure out who’s doing what and for how long
You can get this if you have some HW failure or a mis-configuration in your board startup code since that is where the interrupt masking routines are set up.
As Mario said, a quick kernel trace is going to start by showing you which interrupt is going crazy (tracelogger without arguments).
If you are running with 6.3.2, you can also run pidin irq to see which interrupts are registered where just in case something escaped your view.
As far as the events go … if you don’t attach an event, do you still see the problem? It may be that you are building up such a queue of events to process that the system itself is failing to be able to queue them internally. This is generally the result of some intermediate process starving out your event processing thread(s). You should be able to see this with a quick pidin.