Running out of interrupt events

If you're working with interrupts, you might see an Out of Interrupt Events error, which leads to a kernel shutdown.

When running in an interrupt context, the kernel can't use the memory manager to allocate new events. Instead, the kernel uses a pre-allocated pool of interrupt events, taking one event for each handler (unless it's an ISR that doesn't return a sigevent). Then, the kernel queues these interrupt events for processing outside of the interrupt context, in the normal kernel context. When the interrupt event has been processed, it's returned to the pool.

The pool initially stores 2000 interrupt events. To mitigate against depleting the pool, the OS dynamically grows it by 25% when the pool reaches a low water mark. However, if the interrupts keep coming in at a very high rate, the pool can still become depleted, in which case the kernel shuts down and the system moves to its Design Safe State (DSS).

The best way to avoid this problem is to make your interrupt handler do the minimum amount of work required to clear the interrupt. You can queue long-running work that isn't directly related to clearing the interrupt request from your hardware for handling by threads in your driver.

Also, before you call InterruptAttach(), look at your handler code and make sure you're properly clearing the interrupt condition from the device before returning to the OS.

If you still encounter the Out of Interrupt Events error and you're sure all your interrupt handlers are fine, it could be caused by broken interrupt callouts in the BSP. For information about writing interrupt callouts, see the Interrupt controller section in the Building Embedded Systems.