Use the tm27 support to test a spurious interrupt. This helps to run the
validation test case on targets which have no software interrupt available for
tests (for example riscv/PLIC/CLINT in the SMP configuration).
By default, allocate the IDLE task storage areas from the RTEMS Workspace.
This avoids having to estimate the thread-local storage size in the default
configuration.
Add the application configuration option CONFIGURE_IDLE_TASK_STORAGE_SIZE to
request a static allocation of the task storage area for IDLE tasks.
Update #3835.
Update #4524.
Add the INTERNAL_ERROR_IDLE_THREAD_CREATE_FAILED fatal error in case the
creation of an idle thread fails. This may happen due to a failing create
extension provided by the application.
Allow the IDLE stack allocator to change the stack size. This can be
used by applications with a very dynamic thread-local storage size to
adjust the thread storage area of the IDLE tasks dynamically.
Update #4524.
A relative CLOCK_REALTIME time out shall not be affected by CLOCK_REALTIME
changes through clock_settime(). Since our CLOCK_REALTIME is basically just
CLOCK_MONOTONIC plus an offset, we can simply use the CLOCK_MONOTONIC watchdog
for relative CLOCK_REALTIME time outs.
Update #4690.
Threads may join the thread termination of another thread using the
pthread_join() or rtems_task_delete() directives. The thread cancel operation
used a special case priority boosting mechanism implemented by
_Thread_Raise_real_priority(). The problem was that this approach
* is not transitive,
* does not account for priority adjustments of the calling task
while waiting for the join,
* does not support clustered scheduling, and
* does not detect deadlocks.
All these problems are fixed by using a priority inheritance thread queue for
the join operation.
Close#4679.
This particular state during a reconsider help request scheduler operation was
only covered by the existing test suites under some timing conditions.
Update #3716.
Use CLOCK_REALTIME and CLOCK_MONOTONIC for relative thread queue timeouts
instead of CLOCK_REALTIME_COARSE and CLOCK_MONOTONIC_COARSE. This fixes an
issue with clock_nanosleep() in combination with clock_gettime().
Close#4669.
In the SMP_FATAL_MULTITASKING_START_ON_NOT_ONLINE_PROCESSOR test case,
the boot processor ends up in the idle body. Do not issue a fatal error
here and instead enter the idle loop. The secondary processor will
terminate the system.
Add SMP-specifc SMP_FATAL_MULTITASKING_START_ON_NOT_ONLINE_PROCESSOR
fatal error. This fatal error helps to diagnose a broken SMP startup
sequence. Without this error a context switch using the NULL pointer
for the thread control block happens which may be difficult to debug.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
The test source code is generated from specification items
by the "./spec2modules.py" script contained in the
git://git.rtems.org/rtems-central.git Git repository.
Please read the "How-To" section in the "Software Requirements Engineering"
chapter of the RTEMS Software Engineering manual to get more information about
the process.
Update #3716.
Sebastian Huber