RTEMS | bsps/arm/raspberrypi: Fix IRQ dispatch with bank-1 IRQ pending (!1542)

Miroslaw Dach (@mirek23) gitlab at rtems.org
Sun Oct 18 05:15:01 UTC 2026



Miroslaw Dach created a merge request: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1542

Project:Branches: mirek23/rtems:5810-raspberrypi-irq-dispatch to rtems/rtos/rtems:main
Author: Miroslaw Dach

## Summary

bsps/arm/raspberrypi: Fix IRQ dispatch with bank-1 IRQ pending

bsp_interrupt_dispatch() reads BCM2835_IRQ_BASIC and, when any speed-up
bit is set, calls ffs() on the unmasked value.  Bit 8 ("one or more bits
set in pending register 1") is also set whenever a bank-1 interrupt
without a speed-up bit is pending, for example the system timer compare
3 used for the clock tick (GPU IRQ 3).  If such an interrupt is pending
together with a speed-up one, for example USB (GPU IRQ 9, speed-up bit
11), the register reads 0x900.  ffs(0x900) - 1 = 8,
bcm2835_irq_speedup_table[8] is -1, the vector becomes 0xffffffff, no
handler is called, the interrupt stays asserted and the CPU re-enters
the dispatcher forever.  On a Raspberry Pi 3B+ running rtems-libbsd
with USB Ethernet this shows up as a complete system freeze within
seconds to minutes.

Mask the value with BCM2835_IRQ_BASIC_SPEEDUP_USED_BITS before the bit
scan.  With 0x900 the USB interrupt is dispatched first; the immediate
re-entry sees 0x100, takes the IRQ_PENDING1 path and dispatches the
tick.

Tested on Raspberry Pi 3B+ (raspberrypi2 BSP, RTEMS 6.2, rtems-libbsd
6-freebsd-14, EPICS 7.0.10): more than 15 hours of continuous operation
with about 450 million USB transfers, versus a freeze within a minute
before the change.

Closes #5810


## Generative AI

<!-- If you have used AI please use the "AI Contribution" template otherwise leave this blank see our fulls statement at https://www.rtems.org/generative-ai/-->


<!-- Default settings, if it is a dropdown it will set after submission -->

Closes #5810

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1542
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/namespace/49/sent_notifications/6-7rmwp54oy1w0cwqnsy12excx1-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20261018/b1764a4e/attachment-0001.htm>


More information about the bugs mailing list