Status of RISCV port on sis

[Sebastian Huber]

On 07/01/2019 16:38, Jiri Gaisler wrote:
> 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 ...?

The problem with the robust thread dispatch is only in part a RISC-V 
specific problem. I work on this currently. It is not clear why the 
failures didn't show up on the Qemu test runs.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.