The PIP modifications from #3359 introduced new data structures
to track priority inheritance. Prioritized mutexes without PIP
share some of the code paths, and may result in NULL pointer
accesses. This patch checks for NULL, and also adds ISR critical
sections to an uncovered corner case during thread restarts.
Closes#3829.
Adds enqueue, dequeue, requeue, evaluate, and release functions
for the thread priority node priority queue of inherited priorities.
Add calls to these functions as needed to maintain the priority
queue due to blocking, unblocking, and priority changes.
Closes#3359.
Encapsulate the current_priority and real_priority fields of
the thread control block with a Thread_Priority_node struct.
Propagate modifications throughout the tree where the two
fields are directly accessed.
Updates #3359.
For FAT32 msdos_format() used to initialize first FAT entries to
non-zero values only if a volume label was given. Absence of these
entries made mounting such a FAT32 volume fail.
Use _Workspace_Allocate_or_fatal_error() consistently in case auto
extend is turned off. This helps to avoid undefined behaviour in
_API_Mutex_Allocate() in case _API_Mutex_Information() fails.
The XDR library has a problem on architectures with short enums like the
default ARM EABI. Short enums means that the size of the enum type is
variable and the smallest integer type to hold all enum values will be
selected. For many enums this is char. The XDR library uses int32_t
for enum_t. There are several evil casts from an enum type to enum_t
which leads to invalid memory accesses on short enum architectures. A
workaround is to add appropriate dummy enum values.
The file size was wrong in the no space left on device condition. This
resulted in turn in a read of an invalid block which lead to an EIO
error status.
BSPs for simulators which do not include a clock tick interrupt source
are incapable of running some tests successfully. This is a common
characteristic of some BSPs and a fixed set of tests. There is no point
in duplicating this list of tests in those BSPs test configuration.
Read testsuites/testdata/require-tick-isr.tcfg for details.
Conflicts:
testsuites/automake/test-subdirs.am
tools/build/rtems-test-check
The current algorithm scans all PCI busses (0..ff)
and all devices (0..31) on each bus for bridges
and determines the maximum of all subordinate
busses encountered.
However, the algorithm does not scan all functions
present in multi-function devices -- I have a PCI express
root complex (82801H) where multiple (non-zero index)
functions are 'PCI bridges' whose subordinate bus number is
missed by the original algorithm.
This commit makes sure that the scan
is extended to all functions of multi-function
devices.
See #2067
Bug report by Oleg Kravtsov:
In rtems_bdbuf_swapout_processing() function there is the following
lines:
if (bdbuf_cache.sync_active && !transfered_buffers)
{
rtems_id sync_requester;
rtems_bdbuf_lock_cache ();
...
}
Here access to bdbuf_cache.sync_active is not protected with anything.
Imagine the following test case:
1. Task1 releases buffer(s) with bdbuf_release_modified() calls;
2. After a while swapout task starts and flushes all buffers;
3. In the end of that swapout flush we are before that part of code, and
assume there is task switching (just before "if (bdbuf_cache.sync_active
&& !transfered_buffers)");
4. Some other task (with higher priority) does bdbuf_release_modified
and rtems_bdbuf_syncdev().
This task successfully gets both locks sync and pool (in
rtems_bdbuf_syncdev() function), sets sync_active to true and starts
waiting for RTEMS_BDBUF_TRANSFER_SYNC event with only sync lock got.
5. Task switching happens again and we are again before "if
(bdbuf_cache.sync_active && !transfered_buffers)".
As the result we check sync_active and we come inside that "if"
statement.
6. The result is that we send RTEMS_BDBUF_TRANSFER_SYNC event! Though
ALL modified messages of that task are not flushed yet!
close#1485
Waiting for mbufs at this level is a bad solution. It would be better
to try to allocate a new mbuf chain before we hand over the current mbuf
chain to the upper layer. In case the allocation fails we should drop
the current packet and use its mbuf chain for a new packet.
