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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel