Status of RISCV port on sis

Jiri Gaisler jiri at gaisler.se
Mon Jan 7 15:38:38 UTC 2019


On 1/7/19 3:55 PM, Sebastian Huber wrote:
> On 07/01/2019 15:47, Jiri Gaisler wrote:
>> On 1/7/19 3:31 PM, Sebastian Huber wrote:
>>> On 07/01/2019 15:21, Jiri Gaisler wrote:
>>>> The sp37 test fails with an interesting error:
>>>>
>>>>    *** BEGIN OF TEST SP 37 ***
>>>> ] *** TEST VERSION:
>>>> 5.0.0.eba55a6ad63a1433f50ba0d627394f447bacd04f-modified
>>>> ] *** TEST STATE: EXPECTED-PASS
>>>> ] *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
>>>> ] *** TEST TOOLS: 9.0.0 20181112 (RTEMS 5, RSB
>>>> 96673d751ab488d5d892ae67c1842aef9d5c068b, Newlib
>>>> df6915f029ac9acd2b479ea898388cbd7dda4974)
>>>> ]
>>>> /home/jiri/ibm/src/rtems/rtems.seb/c/src/../../testsuites/sptests/sp37/init.c:
>>>>
>>>> 185 normal_interrupt_level != _ISR_Get_level()
>>>> ]
>>>> ] *** FATAL ***
>>>>
>>>> The RISCV port has only two interrupt levels (on/off), and it seems that
>>>> when a task at level one (irq off) is deleted, the heir inherits
>>>> interrupt level one rather then restore its original level. Has anyone
>>>> seen this on RISCV before? It is probably something in my setup (sim or
>>>> bsp) but the test runs without interrupts and always fails the same way
>>>> regardless of compiler optimization etc.
>>> This is indeed an interesting case. The RISC-V and ARM context switch
>>> code no longer saves and restores the interrupt status. You probably
>>> found a weak spot in threaddispatch.c:
>>>
>>> void _Thread_Do_dispatch( Per_CPU_Control *cpu_self, ISR_Level level )
>>> {
>>>    Thread_Control *executing;
>>>
>>>    _Assert( cpu_self->thread_dispatch_disable_level == 1 );
>>>
>>> #if defined(RTEMS_SCORE_ROBUST_THREAD_DISPATCH)
>>>    if (
>>>      !_ISR_Is_enabled( level )
>>> #if defined(RTEMS_SMP)
>>>        && rtems_configuration_is_smp_enabled()
>>> #endif
>>>    ) {
>>>      _Internal_error( INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT );
>>>    }
>>> #endif
>>>
>>> I think we have to remove the rtems_configuration_is_smp_enabled()
>>> condition. Deleting the thread with interrupts disabled should result
>>> in a fatal error (INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT).
>> I compared this with SPARC/leon3, which has 16 levels (0 - 15). At level
>> 15, interrupts are effectively disabled but the interrupt level is still
>> restored and sp37 test works. At the moment I do not compile with SMP
>> and I don't have RTEMS_SCORE_ROBUST_THREAD_DISPATCH defined. So none of
>> the above code is active ...
>>
>
> This is another bug, the RISC-V should have this:
>
> #define CPU_ENABLE_ROBUST_THREAD_DISPATCH TRUE
>
So I added this define and now I get a couple of more fails:

Passed:        562
Failed:         12
User Input:      5
Expected Fail:   0
Indeterminate:   0
Benchmark:       3
Timeout:         0
Invalid:         0
Wrong Version:   0
Wrong Build:     0
Wrong Tools:     0
------------------
Total:         582
Failures:
 sp01.exe
 sp14.exe
 sp37.exe
 spcbssched01.exe
 spedfsched01.exe
 spfifo03.exe
 spfifo05.exe
 spintrcritical06.exe
 spintrcritical07.exe
 spintrcritical11.exe
 spintrcritical12.exe
 spintrcritical15.exe

The spintrcritical fails as before, while the other tests fail with:

 fatal code: 31 (INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT)

Should I take it that the RISC-V port is not quite ready for prime-time ...?

It's not a major problem for me, I will work on adding SMP support to my grlib bsp instead. That should keep me busy for a while ... :-)







More information about the devel mailing list