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.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
