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.
Fix PR 2068:
Reproducable crashes occur when using pthreads and the capture engine
at the same time. 'pthread_create()' is the culprit. It creates a SCORE thread
and then calls Thread_Start( ) without disabling thread-dispatching.
According with comment in
rtems_cache_invalidate_multiple_instruction_lines(), final_address
indicates the last address which needs to be invalidated. But if in
while loop we got final_address == i_addr condition then loop breaks and
final_address will not be invalidated.
STOP_TRANSMISSION command is used to finish READ_MULTIPLE_BLOCK
command and its format is regular command format.
It requires valid CRC-7 to have effect at least on
same cards types else it is ignored and attempt
to issue next READ or WRITE commands results in
illegal command condition (0x04) preceded by strange
(0x3f) for tested card.
Signed-off-by: Pavel Pisa <ppisa@pikron.com>
The _Thread_queue_Process_timeout() operation had several race
conditions in the event of nested interrupts. Protect the critical
sections via disabled interrupts.
CSB336 i.MX1/i.MXS memory map organization
- SDRAM starts at address 0x08000000 but 2 MB are reserved
for boot-block/loader (or other use) before RTEMS image
origin/load address (that is kept from previous setup)
- Caching of 30 MB of SDRAM used for RTEMS (start at 0x08200000)
is changed to writeback mode which provides higher throughput.
- The first 1 MB of RTEMS dedicated SDRAM is remapped to address 0
to provide area for ARM CPU exceptions table.
- Internal registers and rest of the Flash (above 1 MB) are mapped
one to one. Registers region is extended to 2 MB to cover
eSRAM found on i.MX1 chip variant.
- The first two megabytes of SDRAM unused by RTEMS are mapped
with attributes to allow specific purposes.
- the first MB (at address 0x08000000) is nocached to allow
directly set some values read by booot-block after warm reset
- the second MB (at address 0x08100000) is set for write-through
caching. That allows to use memory for LCD frame-buffer without
need to flush cache after each redraw.
Signed-off-by: Pavel Pisa <pi@baree.pikron.com>
The original version is missing void and result is that (*x >> 16) is
optimized to ldh rX,[rY]. But it is not allowed/supported to access
bus/address range used by AITC by other than 32 bit wide accesses
and 16-bit access results in the data abort exception.
The corrected version works on real hardware and is even
more readable.
Signed-off-by: Pavel Pisa <ppisa@pikron.com>
Commit 4b45c1393c marked a test in
_Event_Timeout() as debug only. This test is required also in non-debug
configurations since otherwise state corruption can happen. A revised
test sptests/spintrcritical10 checks the relevant sequences.
Under certain conditions it is possible that a call to
_Watchdog_Adjust_to_chain() happens with a unit parameter value of zero
(for example sptests/spintrcritical17). Remove superfluous checks that
prevent an adjust to a chain of a watchdog chain which first element has
a delta zero value.
Do not use the unavailable block count as the erased blocks starvation
threshold. Use instead the block count of the largest segment. This
improves the starvation resolution gain of available blocks.
The compaction process needs erased blocks. It is only possible to
erase an entire segment. Thus in order to make a progress we always
need enough erased blocks to empty a used or available segment which can
be erased in turn. A (possibly the worst case) lower bound of erased
blocks is the block count of the largest segment. The number of
unavailable blocks specified by the configuration will be used to
determine the erase blocks starvation situation. The number of
unavailable blocks must be greater than or equal to the number of blocks
in the largest segment.
