Issue created by Sebastian Huber: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5684
`or1k_interrupt_disable()` clears `SR.IEE`, the interrupt exception enable of the supervision register. The tick timer of the architecture has an exception enable of its own, `SR.TEE`, and the function leaves it set. Every RTEMS critical section on this port therefore runs with the clock tick enabled, and the tick handler walks the watchdog chains which the code it interrupts is in the middle of. On a uniprocessor build an ISR lock is an interrupt disable and nothing else, so nothing detects the reentry. `_CPU_ISR_Set_level()` carries the same asymmetry: it sets both bits to enable interrupts and clears one bit to disable them. The clock driver of the BSP compounds it. The tick timer compares the low 28 bits of its counter with the time period field, and the driver takes the next period from the previous one. A handler which runs late writes a period which the counter already passed, and the timer then waits for the counter to run through the whole field. At 20 MHz that is 13.4 s, and the tick after it is late by the same amount, so the clock never recovers. A tick masked through a critical section is what makes the handler late. The BSP has no driver for the programmable interrupt controller and no way to raise an interrupt in software, so the interrupt manager cannot enable, disable or raise a vector, every test which calls `CallWithinISR()` waits forever, and the interrupt critical tests are excluded. Found while running the full test suite on Qemu. This description was created with Claude Code assistance. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5684 You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/5-2zkbpyo8kjufdp3vqla63jkke-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
