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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
