Print the uptime and difference in nanoseconds to the previous
record in the ctrace output. For example:
0:00:59.474927121 14760 0a01000c TNTD 235 235 CREATED_BY
0:00:59.474927418 297 0a010012 /dev 235 235 CREATED
0:00:59.474930799 3381 0a01000c TNTD 235 235 STARTED_BY
0:00:59.474931105 306 0a010012 /dev 235 235 STARTED
0:00:59.475072297 141192 0a01000c TNTD 235 235 SWITCHED_OUT
The readv() and writev() support was implemented in terms of multiple
calls to the read and write handlers. This imposes a problem on device
files which use an IO vector as single request entity. For example a
low-level network device (e.g. BPF(4)) may use an IO vector to create
one frame from multiple protocol layers each with its own IO vector
entry.
This adds five tests for <sys/cpuset.h>. It does not include
tests for CPU_XXX_S methods. The autotools should be able to
avoid enabling the tests unless the toolset has <sys/cpuset.h>.
The capture did not work due to changes in the workspace allocator.
The engine now scans all existing tasks when enabled and does any
allocations then.
Fixed a bug in the ctset commandi in the CLI.
Updated the capture engine to use 64bit nanosec timestamps.
Fixed the CLI showing the stack usage.
This allows an application to provide a localised clock freq with
needing to go down the BSP opts path. This is important with the
Zynq where the Xilinx tools generate the frequency.
This is for the RFS file system. There is a bug in the
rtems_rfs_bitmap_create_search loop. It is supposed to iterate
over the range of bits in a search element ( usually 32 bits ),
so it should loop through bits 0 through 31. Instead it loops
through 0 - 32, causing some blocks not to be allocated. As in
PR 2163, this depends on the block size and number of blocks in
a file system. Block sizes and group sizes that are powers of 2
seem to work fine ( 512 byte blocks, 4096 block groups, etc ).
When the block sizes are not powers of 2, then this loop error
causes some of the blocks at the end of a group to be skipped,
preventing 100% of the blocks from being used. A simple test
for this and PR2163 is to create a RAM disk with block size
3900 and at least 1 full group ( 31200 blocks ). A file system
with these sizes will not be able to allocate 100% of the blocks.
This is for the RFS file system. The statvfs call reports 1 block free
when the file system is full because it does not account for the superblock
in its calculation of free blocks.
This is a simple fix that adjusts the number of blocks reported to account
for the superblock. We may want to wait for a more complete solution such
as locating the superblock in each group.
This is for the RFS file system. There is a bug in the group search
algorithm where it will skip groups, causing blocks to remain
unallocated. This is dependant on the size of the blocks and number
of blocks in a group, so it does not always show up. The fix corrects
the skipping of groups during the search, allowing all of the blocks
to be found.
