RTEMS | riscv: clock driver may fall behind (#5576)

[Gedare Bloom (@gedare)]

Gedare Bloom created an issue: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5576

Assignee: Gedare Bloom

## Summary
<!--
Please provide as much information as possible such as error messages or attaching logs
-->

The bsps/riscv/riscv/clock/clockdrv.c was reworked to use a fixed interval each tick that is based on the last tick. This exposed a problem where a target that has a timebase frequency < CPU frequency can fall behind and start setting timeout intervals that are in the past. This leads to missing, spurious, or arbitrarily delayed timer interrupts and sporadic testsuite failures.

I don't think this would be a problem in real hardware. It comes about because the qemu virt machine has a clock frequency derived from the host, so that the advancing $time register jumps a lot for each executed instruction. For example, on my machine I observed a single jump instruction causing `$time` to advance by about 1,400 ticks. With a default configuration, the clock interrupt fires each 10,000 ticks, so there's only a few instructions that execute between interrupts.

I think that adding the `icount shift=auto` to the qemu command line can resolve this problem.

## Steps to reproduce

I found this while debugging `spcpucounter01.exe` failures with both s-mode and m-mode variants.

<!-- Pre-set options
- milestone
-->

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5576
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/20260514/23bb0ab9/attachment.htm>