Do not supsend self while waiting for termination since the
rtems_task_delete() may take place while the rtems_task_suspend() waits
for the Giant lock preventing delivery of the inter-processor interrupt.
The result is a suspended and terminated thread (this is a valid state,
but leads in this case to a test failure).
The previous timeout handling was flawed. In case a waiting thread
helped out the owner could use the scheduler node indefinitely long.
Update the resource tree in _MRSP_Timeout() to avoid this issue.
Bug reported by Luca Bonato.
The dummy.c was a de-facto default configuration. Rename it to
default-configuration.c. Use unlimited objects and the stack checker.
This makes it easier for new RTEMS users which will likely use this file
if they just work with the usual main() function as the application
entry point. Provide proper arguments for main() using the BSP command
line. Add spare user extensions and drivers.
Do not initialize the network by default. Delete bspinit.c.
The LEON3 BSP have support for up to 8 termios consoles, the
LEON3-FT GR712RC uses 6 UARTs.
This does not take into account the BSP maximum devices instead
it is hardcoded to 6. This patch increases it the maximum
devices of DEVFS04 from 6 to 10.
Ensure that scheduler nodes in the SCHEDULER_HELP_ACTIVE_OWNER or
SCHEDULER_HELP_ACTIVE_RIVAL helping state are always
SCHEDULER_SMP_NODE_READY or SCHEDULER_SMP_NODE_SCHEDULED to ensure the
MrsP protocol properties.
Make sure also the size is cache aligned since otherwise we may have
some overlap with the next allocation block. A cache invalidate on this
area would be fatal.
New test case for smptests/smpmrsp01.
Fix _Scheduler_Block_node() in case the node is in the
SCHEDULER_HELP_ACTIVE_RIVAL helping state. For example a
rtems_task_suspend() on a task waiting for a MrsP semaphore.
Fix _Scheduler_Unblock_node() in case the node is in the
SCHEDULER_SMP_NODE_READY state. For example a rtems_task_resume() on a
task owning or waiting for a MrsP semaphore.
posix_memalign() is prototyped to take a non-NULL parameter. But our
test is deliberately passing one in. With the -Wnon-null warning flag
enabled, we will always get warnings on this test unless we disable
that warning for this single test case.