![[RTEMS Logo]](/images/logo.png){kind=logo}
Opened on 07/06/23 at 17:01:01
Last modified on 07/10/23 at 13:49:21
#4922 new defect
QEMU delivers back-to-back timer ticks after task switches
| Reported by: | Kinsey Moore | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Indefinite |
| Component: | tool/rsb | Version: | 6 |
| Severity: | normal | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: |
Description
A selection of tests in the RTEMS testsuite will fail consistently or intermittently when running under QEMU while they pass consistently on real hardware or more accurate simulators. This is due to QEMU getting context-switched out on the host system and when it gets more run time it delivers all outstanding clock ticks as quickly as possible according to the wall clock. Naturally, this is more severe on heavily loaded systems. The tests that fail in this manner are heavily dependent on timing and inter-tick processing to verify their correct operation.
The tests known to fail in this manner on ARM and AArch64 BSPs are at least:
psx12
psxclock
psxtimes01
psxualarm
rtmonuse
rtmonusxtimes01
smpclock01
smpfatal01
smpfatal03
smpmrsp01
smpmutex01
smppsxmutex01
smpschedaffinity01
smpschedaffinity02
smpschededf01
smpschededf03
smpscheduler04
smpthreadpin01
sp04
sp20
sp68
sp69
sp71
spcpucounter01
spedfsched02
spedfsched04
spintrcritical01
spintrcritical02
spintrcritical03
spintrcritical04
spintrcritical05
spintrcritical06
spintrcritical07
spintrcritical08
spintrcritical09
spintrcritical10
spintrcritical11
spintrcritical12
spintrcritical13
spintrcritical14
spintrcritical15
spintrcritical16
spintrcritical17
spintrcritical18
spintrcritical19
spintrcritical20
spintrcritical21
spintrcritical22
spintrcritical23
spintrcritical24
sprmsched01
sptimecounter01
sptimecounter02
sptimecounter04
ttest02
This issue does not exist to rectify the situation with QEMU so much as to document the issue so that it can be referenced from non-pass expected test outcomes for those affected BSPs that are dedicated to the QEMU platform.
Change History (4)
comment:1 Changed on 07/06/23 at 17:22:16 by Kinsey Moore
comment:2 Changed on 07/06/23 at 17:46:25 by Joel Sherrill
One of the challenges we have had on issues like this where a BSP runs fine on hardware but not on the simulator is that if the same variant name is used in both cases, there is no way to distinguish HW vs simulator expectation. On the aarch64, I don't think this applies but at least for sparc and i386, the same BSP variant runs on HW and simulator. Our test annotations apply to a BSP -- not BSP plus "hw/sim".
Intermittent failures are worse because you can't mark them as expected failures either.
comment:3 Changed on 07/06/23 at 18:14:00 by Kinsey Moore
Yes, those reasons and differing peripheral support are exactly why I've made sure to have separate QEMU BSPs for all the work I've done. I suspect that sparc and i386 should really have separate BSPs for at least QEMU and maybe also for other simulators that have similar problems.
comment:4 Changed on 07/10/23 at 13:49:21 by Kinsey Moore <kinsey.moore@…>
In [changeset:"f46c15fd76a4c1904760360cd220a061d74edad4/rtems" f46c15f/rtems]:
I mistakenly left out these tests:
validation-0
validation-smp-only-0