Issue created by Sebastian Huber: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5726
`Cause_tm27_intr()` of the `microblaze_fpga` family raises the test interrupt with the second counter of the AXI timer. The counter raises the interrupt some counter ticks after the request. A validation test which needs the interrupt inside the intend to block window of `_Thread_queue_Enqueue()` never receives it there. `ts-validation-no-clock-0` reports 14707 failed steps and ends in `INTERNAL_ERROR_THREAD_QUEUE_DEADLOCK`. The missed timeout leaves a MrsP semaphore owned, the delete fails, and every later semaphore create returns `RTEMS_TOO_MANY`, which accounts for 14004 of those steps. The BSP also gives the test support one vector only. `RtemsIntrReqEntryInstall` asks for a vector which it can raise, and `bsp_interrupt_raise()` returns `RTEMS_UNSATISFIED` for every vector of this BSP. The scan finds none, the test uses the vector count as a vector, and every directive returns `RTEMS_INVALID_ID`. `ts-validation-intr` reports 7402 failed steps from this cause alone. A write to the interrupt status register of the AXI interrupt controller raises an interrupt in software, but only while the hardware interrupt enable of the master enable register is clear. That enable is write once on some implementations, so a probe decides which mechanism the BSP uses. The BSP also links the software CPU counter of `bsps/shared`. `_CPU_Counter_read()` of that counter increments a static variable per call and `_CPU_Counter_frequency()` returns 1000000000, so nothing in it measures time. `rtems_counter_delay_nanoseconds()` therefore delays by a count of calls and `getentropy()` takes no entropy from the time. The AXI timer has two counters and the clock driver uses the first, so the second can be a free running up counter of the full width. `spcpucounter01` passed on this BSP only because the delay it measures and the counter it measures with were the same fiction. With a real counter it fails on Qemu. The counter is a register of the AXI timer, and Qemu takes the tick interrupt later out of a loop which reads that register than out of the poll loop the test synchronizes with. The test busy waits exactly one clock tick period and asserts that a tick elapsed, so it has no margin for the difference. Two defects of the Qemu AXI timer model were found and fixed while measuring this, and neither is part of this issue. Found while running the full test suite on eleven simulators. This description was created with Claude Code assistance. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5726 You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/5-escj19wvyzcq8kqvq3ueye0e1-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
