[PATCH] aarch64: Add tests that are failing intermittently

Chris Johns chrisj at rtems.org
Sat Aug 28 00:01:22 UTC 2021


On 27/8/21 9:36 am, Kinsey Moore wrote:
> On 8/20/2021 22:06, Chris Johns wrote:
>> On 21/8/21 2:38 am, Kinsey Moore wrote:
>>> On 8/19/2021 18:03, Chris Johns wrote:
>>> My comment in that regard was that other system
>>> loading (or multiple simultaneous test runs) can also cause the same problem
>>> and so
>>> this is only a partial solution. Barring a fix for RTEMS or QEMU for these load-
>>> dependent and sporadic failures, this at least still needs to be documented
>>> in some
>>> form.
>> Yes and the failures should highlight an issue on the host that needs to be
>> looked into.
> 
> Since I'm working on SMP and I've had some of those tests failing sporadically
> as well, I took a dive into smpschededf01.exe on AArch64 and the issue that
> particular test seems to be encountering is a mismatch between the busy wait
> delay using rtems_test_busy_cpu_usage() and the number of kernel ticks that have
> been experienced. My hypothesis is that QEMU is prone to dumping a pile of timer
> ticks into the virtual CPU all at once to catch up to wall time after returning
> from a context switch on the host OS. This would support the observation that
> failures are sporadic and increase under system load.  I instrumented the code
> and can see that the loop in rtems_test_busy_cpu_usage() isn't running
> substantially between these tick interrupts if at all.

Oh that would confuse things.

> I guess my next step is seeing if QEMU has an option to run its timers closer to
> the illusion of metal instead of being based on the wall clock.

QEMU would need to handle instruction or a CPU timer to manage this.

Chris


More information about the devel mailing list