RTEMS | Draft: rtems/bsps: Test software code placed inside #if #endif (!1078)

[Samuel Viegas (@samuel.viegas)]

Samuel Viegas commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1078#note_149485


Ok, so regarding these specific tests for gr712/740, the code comments mention that the read-modify-write on ipend can accidentally clear pending interrupts set by peripherals. My understanding is that the problematic scenario is when a hardware interrupt becomes pending between the load and store of ipend and the store overwrites that new pending bit. To try to reproduce this, would it make sense to use a high-frequency hardware interrupt source (GPTIMER) as the asynchronous interrupt generator and concurrently stress bsp_interrupt_raise() from one or more tasks, to then try detecting lost interrupts by comparing an ISR counter against the expected interrupt rate? Does this approach sound correct, can it actually expose this race condition?

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1078#note_149485
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260505/59badaaa/attachment.htm>