Potential SIS or RTEMS/libbsd problem

[Jiri Gaisler]

On 5/22/19 9:49 AM, Sebastian Huber wrote:
> On 22/05/2019 09:39, Jiri Gaisler wrote:
>> On 5/22/19 8:03 AM, Sebastian Huber wrote:
>>> Hello,
>>>
>>> in the libbsd there is a test for the Epoch Based Reclamation:
>>>
>>> https://git.rtems.org/rtems-libbsd/tree/testsuite/epoch01/test_main.c
>>>
>>> When I run this test using the leon3 BSP on real hardware (150MHz
>>> NGMP FP) the test completes successfully.
>>>
>>> If I run the test on the SIS, it is stuck at some point (using "-m
>>> 1" works):
>>>
>>> sparc-rtems5-sis -leon3 -nouartrx -r -tlim 200 s -m 2
>>> build/sparc-rtems5-leon3-everything/epoch01.exe
>>>
>>>
>> This test needs a shorter time-slice in the simulator to succeed (-d
>> option). The more cpus, the lower number of clocks in the slice is
>> needed. Through trial-and-error, these values seem to work:
>>
>> 2 CPUs: -m 2 -d 25
>>
>> 3 CPUs: -m 3 -d 10
>>
>> 4 CPUs will not work, even if -d 1 is set. This is most likely a
>> simulator problem, I will try to find time to look at it in more
>> detail. A quick trace shows that all CPUs are stuck in a loop
>> checking for a lock or similar:
>>
>
> It seems cpu 2 and 3 are in _SMP_barrier_Wait(). The cpu 0 and 1 still
> to some stuff in the EBR algorithm (ck_* functions). Maybe the
> algorithm works only in case some random timing fluctuations occur.

Either that or there is a hidden race condition in the test that does
not show up on real hardware. I noticed that increasing the time slice
actually make the test succeed even on 4 cpus ..!

-m 2 -d 200    PASS

-m 3 -d 200    PASS

-m 4 -d 200    FAIL

-m 4 -d 400    PASS!

BUT

-m 3 -d 400    FAIL!

I will try to add random delays to the interrupt response time to see if
that will make a difference. That is more inline with the real hardware ...

Jiri.