RTEMS / RTOS / RTEMS¶
Go to Issues or Merge Requests
Issues Summary
Merge Requests Summary
Issues¶
4130 - Multiple references to autoconf build system left in documentation¶
Id |
4130 |
State |
closed |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Kinsey Moore |
Closed by |
Joel Sherrill |
Created |
2020-10-07T13:59:25.000Z |
Closed |
2026-08-13T22:42:29.263Z |
Updated |
2026-08-13T22:42:29.498Z |
Milestone |
6.3 |
Labels |
priority::normal, tickettype::defect, version::6 |
Link |
|
Merges |
1 |
I searched for “enable-” in rtems-docs and it looks like there are multiple places where the autoconf build system is referenced. I got over 50 hits on that phrase but some do appear to ok as they are for rtems-tools. All need to be reviewed.
Searching for bootstrap turned up 39 hits.
Searching for the word configure is probably too hard. We need to have a few key phrases to search for to find documentation that needs to change.
The same list of search terms needs to be done to the wiki but that’s a separate ticket.
Author: Trac Migrate
2020-10-10T13:20:23.000Z
From my point of view this is not a waf blocker. Once the old build system is removed from the tree and the user interface of the new build system is stable, we should start cleaning up the documentation.
Author: Trac Migrate
2021-12-16T21:31:02.000Z
Milestone changed from %”6.1” to %”Indefinite”
Author: Amar Takhar
2025-09-05T02:57:44.949Z
changed the description
Author: Kinsey Moore
2026-05-15T15:31:41.897Z
There are still references to the old build system in
user/bld/index.md,user/hosts/posix.md,user/tools/bsp-builder.md, anduser/tracing/examples.md.
Author: Kinsey Moore
2026-06-11T22:33:25.509Z
assigned to @opticron
Author: Kinsey Moore
2026-06-11T22:33:29.986Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-30T23:23:13.507Z
set status to In progress
Author: Chris Johns
2026-07-30T23:23:22.371Z
added rtems#15 as parent item
Author: Kinsey Moore
2026-07-31T15:25:29.055Z
mentioned in commit opticron/rtems-docs@795c8ffc7f75cc4dc83bd3de38e13f772a932eb3
Author: Kinsey Moore
2026-07-31T15:25:54.394Z
mentioned in merge request rtems/docs/rtems-docs!249
Author: Kinsey Moore
2026-07-31T16:26:25.527Z
The most recent pair of MRs for main and 6 branch should resolve this issue: rtems/docs/rtems-docs!249 rtems/docs/rtems-docs!250
Author: Joel Sherrill
2026-08-13T22:38:36.702Z
mentioned in commit opticron/rtems-docs@81b03b69334e63e563c2d2f4f81a658eaddda8d2
Author: Kinsey Moore
2026-08-13T22:41:53.129Z
mentioned in commit opticron/rtems-docs@4497b3c9e7263249c6a6356dafb945ab87b8fe8a
Author: Joel Sherrill
2026-08-13T22:42:31.828Z
set status to Done
3923 - Add traceability information to the application configuration options¶
Id |
3923 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Sebastian Huber |
Closed by |
Sebastian Huber |
Created |
2020-04-02T08:32:10.000Z |
Closed |
2026-08-05T08:41:21.303Z |
Updated |
2026-08-05T08:41:21.571Z |
Milestone |
6.3 |
Labels |
priority::normal, qualification, tickettype::project, version::6 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
There exists a specification of the application configuration options here:
https://git.rtems.org/rtems-central/tree/spec/acfg
For the RTEMS Qualification project we need traceability from the specification to the source code and vice versa. Methods and tools for this needs to be agreed on, documented, and implemented:
https://lists.rtems.org/pipermail/devel/2020-March/058744.html
https://lists.rtems.org/pipermail/devel/2020-March/058745.html
Document the configuration related specification items in the RTEMS Software Engineering manual along with the traceability approach.
Author: Trac Migrate
2020-04-02T08:35:41.000Z
Original author: sebastian.huber
Original author: sebastian.huber
Description changed
- There exist a specification of the application configuration options (work in progress) here: + There exists a specification of the application configuration options (work in progress) here: ? + https://git.rtems.org/sebh/rtems-qual.git/tree/spec/acfg/opt/ For the RTEMS Qualification project we need traceability from the specification to the source code and vice versa. Methods and tools for this needs to be agreed on, documented, and implemented: https://lists.rtems.org/pipermail/devel/2020-March/058744.html https://lists.rtems.org/pipermail/devel/2020-March/058745.html
Author: Trac Migrate
2020-04-02T08:38:37.000Z
Original author: sebastian.huber
Original author: sebastian.huber
Description changed
There exists a specification of the application configuration options (work in progress) here: https://git.rtems.org/sebh/rtems-qual.git/tree/spec/acfg/opt/ For the RTEMS Qualification project we need traceability from the specification to the source code and vice versa. Methods and tools for this needs to be agreed on, documented, and implemented: https://lists.rtems.org/pipermail/devel/2020-March/058744.html https://lists.rtems.org/pipermail/devel/2020-March/058745.html + + Document the configuration related specification items in the RTEMS Software Engineering manual along with the traceability approach.
Author: Trac Migrate
2022-07-21T07:52:00.000Z
Original author: sebastian.huber
Original author: sebastian.huber
Description changed
- There exists a specification of the application configuration options (work in progress) here: ? ------------------- + There exists a specification of the application configuration options here: - https://git.rtems.org/sebh/rtems-qual.git/tree/spec/acfg/opt/ ? ----- ^^ ---- ----- + https://git.rtems.org/rtems-central/tree/spec/acfg ? ^^^^^ For the RTEMS Qualification project we need traceability from the specification to the source code and vice versa. Methods and tools for this needs to be agreed on, documented, and implemented: https://lists.rtems.org/pipermail/devel/2020-March/058744.html https://lists.rtems.org/pipermail/devel/2020-March/058745.html Document the configuration related specification items in the RTEMS Software Engineering manual along with the traceability approach.
Milestone changed from %”6.1” to %”7.1”
Author: Trac Migrate
2022-07-21T07:55:34.000Z
Original author: sebastian.huber
The application configuration options (defines) are evaluated by header files in
cpukit/include/rtems/confdefs*. Traceability from the specification to the source code and vice versa can be done via a Doxygen map file. However, this doesn’t work for the application configuration since the evaluation of defines cannot be documented through Doxygen. We would need the ability to reference source code blocks in the specification.
Author: Amar Takhar
2024-04-25T20:47:58.690Z
changed the description
Author: Joel Sherrill
2025-09-19T00:02:03.741Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-30T23:19:12.663Z
assigned to @sebhub
Author: Chris Johns
2026-07-30T23:19:27.939Z
Please update the Status.
Author: Sebastian Huber
2026-08-05T08:41:21.371Z
set status to Done
Author: Sebastian Huber
2026-08-05T08:41:22.191Z
This was fixed in the tooling.
5481 - Backport to 6 branch: “Complete the u-boot support for qoriq BSP”¶
Id |
5481 |
State |
closed |
Type |
ISSUE |
Author |
Kinsey Moore |
Closed by |
Kinsey Moore |
Created |
2026-02-05T22:12:31.856Z |
Closed |
2026-07-31T00:34:35.652Z |
Updated |
2026-07-31T00:34:35.812Z |
Milestone |
6.3 |
Labels |
backport |
Link |
|
Merges |
1 |
The following discussion from !976 should be addressed:
[] @opticron started a discussion:
This needs a backport issue and the issue should be referenced from the commit message with:
Closes #issuenumberhere
Author: Kinsey Moore
2026-02-05T22:12:32.023Z
added rtems#15 as parent epic
Author: Kinsey Moore
2026-02-05T22:12:32.119Z
set status to To do
Author: Kinsey Moore
2026-02-05T22:12:58.324Z
mentioned in merge request !976
Author: Vijay Banerjee
2026-07-09T15:50:23.465Z
set status to Done
Author: Joel Sherrill
2026-07-19T15:26:11.796Z
set status to To do
Author: Joel Sherrill
2026-07-19T15:26:12.409Z
The MR for this seems to be the origin of this warning across a lot of PowerPC BSPS:
no-posix powerpc/qoriq_e6500_64 build: configure: /home/tester/rtems-cron-7/rtems/waf configure\\ --prefix=/home/tester/rtems-cron-7/tools/7/bsps\\ --top=/home/tester/rtems-cron-7/rtems --rtems-config=config-powerpc-\\ qoriq_e6500_64-no-posix.ini error: home/tester/bsps/powerpc/shared/u-boot/uboot_getenv.c:73:13: error: no previous prototype for 'bsp_uboot_getenv' [-Werror=missing-prototypes]See build sweep post for a full list of BSPs impacted.
Author: Vijay Banerjee
2026-07-20T15:43:59.900Z
mentioned in merge request !1359
Author: Vijay Banerjee
2026-07-20T15:45:26.173Z
The MR removed the HAS_UBOOT guard from the implementation but kept it in the header file. I added !1359 to add the conditional and remove unused function
Author: Kinsey Moore
2026-07-31T00:34:35.711Z
set status to Done
5386 - Initializing network (libbsd) issue on 6-freebsd-12 powerpc beatnik¶
Id |
5386 |
State |
closed |
Type |
ISSUE |
Author |
Heinz Junkes |
Closed by |
Chris Johns |
Created |
2025-10-31T21:28:53.777Z |
Closed |
2026-07-31T00:25:20.250Z |
Updated |
2026-07-31T00:25:20.255Z |
Milestone |
6.3 |
Labels |
libbsd::freebsd-12 |
Link |
|
Merges |
0 |
Summary¶
on call rtems_bsd_initialize() :
_taskqueue_start_threads: kthread_add(kqueue_ctx taskq): error 12emerg: kproc_create() failed with 12
git clone https://gitlab.rtems.org/rtems/tools/rtems-source-builder rsb
cd rsb
git checkout tags/6.1
git clone https://gitlab.rtems.org/rtems/rtos/rtems.git kernel
cd kernel
git checkout tags/6.1
git clone https://gitlab.rtems.org/rtems/pkg/rtems-libbsd
cd rtems-libbsd
git checkout 6-freebsd-12
git submodule init
git submodule update rtems_waf
## Steps to reproduce
Booting beatnik:
Startup. get time from RTC time set to : 10/31/25 22:13:26.000006539 UTC
* RTEMS Version: rtems-6.0.0 (PowerPC/Generic (classic FPU)/beatnik) *
* Initializing network (libbsd) * _taskqueue_start_threads: kthread_add(kqueue_ctx taskq): error 12emerg: kproc_create() failed with 12
/milestone %6.2
Author: Heinz Junkes
2025-10-31T21:28:53.911Z
set status to To do
Author: Heinz Junkes
2025-11-01T07:37:33.337Z
Please do not work on this issue yet. I cannot rule out a hardware defect at this point. The battery that powers the NVRAM is dead. This means that the CPU settings may be corrupt. I will test it on another CPU on Monday. Sorry…
Author: Heinz Junkes
2025-11-03T09:01:37.585Z
Unfortunately, the behavior is the same on another CPU:
Now BSP_mem_size = 0x1fe00000 Configuration.work_space_size = f99e0 Page table setup finished; will activate it NOW... Going to start PCI buses scanning and initialization Number of PCI buses found is : 3 MSR 0x2003032 Exit from bspstart unable to find the universe in pci config space Tundra Tsi148 PCI-VME bridge detected at 0x81100000, IRQ 84 Tsi148 Outbound Ports: Port VME-Addr Size PCI-Adrs Mode: 0: 0x20000000 0x0e000000 0x90000000 A32, SUP, D32, SCT 1: 0x00000000 0x00ff0000 0x9f000000 A24, SUP, D32, SCT 2: 0x00000000 0x00010000 0x9fff0000 A16, SUP, D32, SCT 7: 0x00000000 0x01000000 0x9e000000 CSR, SUP, D32, SCT Tsi148 Inbound Ports: Port VME-Addr Size PCI-Adrs Mode: 0: 0x90000000 0x1fe00000 0x00000000 A32, PGM, DAT, SUP, USR, MBLT, BLT vmeTsi148 IRQ manager: looking for registers on VME... Trying to find CSR on VME... vmeTsi148 - IRQ manager using VME CSR to flush FIFO Registering /dev/console as minor 0 (==/dev/ttyS0) Startup. time set to : 04/14/24 07:30:35.000006119 UTC ***** RTEMS Version: rtems-6.0.0 (PowerPC/Generic (classic FPU)/beatnik) ***** ***** Initializing network (libbsd) ***** _taskqueue_start_threads: kthread_add(kqueue_ctx taskq): error 12emerg: kproc_create() failed with 12What strikes me is that after “Registering /dev/console …” it takes a very long time for the next output to appear.
Author: Heinz Junkes
2025-11-03T10:23:11.646Z
With 6-freebsd-14 I see this:
***** Initializing network (libbsd) ***** emerg: assertion "area != NULL" failed: file "../../rtemsbsd/rtems/rtems-kernel-page.c", line 143, function: rtems_bsd_page_init
Author: Chris Johns
2025-11-10T22:26:28.150Z
set status to Needs funding
Author: Chris Johns
2025-11-10T22:27:37.775Z
Please try
6-freebsd-14to see if the problem exists there?
Author: Chris Johns
2025-11-10T22:27:44.329Z
set status to To do
Author: Chris Johns
2026-07-31T00:25:16.866Z
Please use
6-freesd-14.
Author: Chris Johns
2026-07-31T00:25:20.287Z
set status to Won’t do
5165 - Use of pkg-config –libs is unreliable¶
Id |
5165 |
State |
closed |
Type |
ISSUE |
Author |
Sebastian Huber |
Assignee(s) |
Sebastian Huber |
Closed by |
Chris Johns |
Created |
2024-11-28T12:58:42.398Z |
Closed |
2026-07-31T00:12:35.422Z |
Updated |
2026-07-31T00:12:35.427Z |
Milestone |
6.3 |
Labels |
qualification |
Link |
|
Merges |
0 |
Summary¶
I noticed a strange issue with pkg-config for a BSP with special linker flags:
https://github.com/pkgconf/pkgconf/issues/371
I think we should provide the linker flags also through an LDFLAGS variable.
Author: Sebastian Huber
2024-11-28T12:58:42.511Z
assigned to @sebhub
Author: Sebastian Huber
2024-11-28T14:26:59.811Z
mentioned in merge request !335
Author: Sebastian Huber
2024-11-28T14:28:04.148Z
mentioned in merge request !336
Author: Gedare Bloom
2024-12-04T21:39:42.250Z
Author: Sebastian Huber
2024-12-05T03:02:18.776Z
cloned to #5169
Author: Chris Johns
2024-12-22T03:37:31.386Z
Author: Chris Johns
2025-02-11T05:34:34.959Z
This change breaks libbsd and I suspect more. See https://gitlab.rtems.org/rtems/pkg/rtems-libbsd/-/issues/38 for details.
Author: Chris Johns
2025-02-11T05:36:33.803Z
The MR needs to be revert it.
Author: Sebastian Huber
2025-02-11T05:38:22.683Z
mentioned in commit e36ba91110724b5cc8a9e07659d98d0bcb96e4d4
Author: Sebastian Huber
2025-02-11T05:38:56.744Z
I would first like to investigate why this change causes something to break. The LDFLAGS were previously not visible by pkg-config.
Author: Sebastian Huber
2025-02-11T06:26:22.134Z
It seems the removal of the
Ldflags:is the issue here. This part of the patch needs to be reverted. Thertems_wafpackage uses the option--ldflagswhich is not documented bypkg-config --help.
Author: Chris Johns
2025-02-11T06:26:22.134Z
I suggest this change is reverted and then a new change can created, review and merged. Any change has to build
rtems_wafbase packages such aslibbsdto be approved.
Author: Sebastian Huber
2025-02-11T06:26:22.134Z
Why don’t you give people a business day to fix this?
Author: Chris Johns
2025-02-11T06:26:22.134Z
That depends on the fix and how long it takes to be reviewed and merged. A revert works, I have tested it so it lets LibBSD build which is important. I am a little unsure what the problem is with a revert?
Author: Sebastian Huber
2025-02-11T06:26:22.134Z
I am already working on a patch.
Author: Chris Johns
2025-02-11T06:26:22.134Z
Sure and thanks. I am only providing a way to solve this breakage. It would helpful if you could please explain your position of no reverts? Gitlab has a Revert button because it is useful and used so if a change breaks something it is helpful.
Author: Sebastian Huber
2025-02-11T06:26:22.134Z
In the past, patches were not reverted this quickly.
Author: Amar Takhar
2025-02-11T06:27:01.628Z
These should be reverted because it caused the breakage it’s a good way to record the issue in GitLab. New MRs should come with the alternate change.
The reason we moved to GitLab is to make these processes easy we’re not in a race I appreciate you wanting more time but the policy should always be to revert ASAP when we see breakage and have a new change in come via a new MR this is an easier way to track changes. This also means that any future changes can be properly considered without being under pressure due to current breakage.
Author: Sebastian Huber
2025-02-11T06:26:22.134Z
Please go ahead, I will have a look at it in a couple of days.
Author: Chris Johns
2025-02-11T05:50:43.935Z
mentioned in merge request !413
Author: Amar Takhar
2025-02-11T05:58:44.327Z
mentioned in merge request !414
Author: Chris Johns
2025-10-02T22:29:33.931Z
added rtems#15 as parent epic
Author: Chris Johns
2026-07-31T00:12:35.455Z
set status to Obsolete
4981 - Overwork Flashdev¶
Id |
4981 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2023-12-28T16:01:07.000Z |
Closed |
2026-07-31T00:08:30.074Z |
Updated |
2026-07-31T00:08:30.078Z |
Milestone |
6.3 |
Labels |
priority::normal, tickettype::defect, version::6 |
Link |
|
Merges |
0 |
Original author: blofeld80
Hi, Aaron Nyholm has added a nice flashdev API this year. I wanted to put LittleFS on top of this API and encountered some difficulties / found some bugs / have some open questions / would like to make some breaking API changes. Therefore, I hope that Aaron can comment.
C++ include guards are missing in flashdev.h
The switch case in flashdev.c => rtems_flashdev_ioctl is missing a default case
Is there a guideline for naming IOCTLs? There are several defines and functions which, I feel, could have a more descriptive name. For example, there is the define RTEMS_FLASHDEV_IOCTL_PAGE_COUNT which is used to get the number of pages within the flash. Could we have it called RTEMS_FLASHDEV_IOCTL_GET_PAGE_COUNT so that it is immediately clear what is good for? Basically, I would like to add “_GET” / “_get” at all appropriate places (i.e. refactor the corresponding function names, too). I guess there will be an issue with the 80 char per line limit, but I’d provide a proposal for handling them at a final stage when all other issues have been addressed.
4. I need to be able to create more than one flashdev. Therefore, the mutex initializer in rtems_flashdev_do_init is a bit of a roadblocker as it would use the same name for the mutex inside each flashdev instance. From my point of view, the easiest way to deal with this is to have the mutex name as an argument to the initializer. However, I’d prefer to a. shorten the name - like FDEV_MTX_${Number} b. loop over ${Number} until we can create the mutex Is there an rtems_get_id_by_name? I’ve only found a function to get the name of an id.
5. Some thoughts on the “regions”. Regions behave much like paritions, except that not every region / partition gets its own file handle, right? a. Why not calling the regions partitions? b. Do we really need to set them up “dynamically”, or could we pass a partition table to the flashdev initialisation? c. There are the IOCTLs RTEMS_FLASHDEV_IOCTL_REGION_SET and RTEMS_FLASHDEV_IOCTL_REGION_UNSET. Looking at the implementation I feel they do more than I’d expect. For example, RTEMS_FLASHDEV_IOCTL_REGION_SET creates the region, or even redefines a region if one has not called unset, and then it activates the region. I’d like to refactor this into four IOCTLs: * RTEMS_FLASHDEV_IOCTL_ REGION or PARTITION _CREATE * RTEMS_FLASHDEV_IOCTL_ REGION or PARTITION _DELETE * RTEMS_FLASHDEV_IOCTL_ REGION or PARTITION _ACTIVATE * RTEMS_FLASHDEV_IOCTL_ REGION or PARTITION _DEACTIVATE
For my use case, setting up a static partition table would be good enough. We could spare the _CREATE, _DELETE, check the partitions more thoroughly during initalisation (for example that they do not overlap), and would not have to provide a mechanism to be able to resize them during runtime.
Flashdev shall work for NAND flashes, too. I am not an expert when it comes to NAND flashes. Therefore, I would like to outline my basic understanding and hope someone tells me if I am completely off.
Some parts I find often in designs:
NAND - W25N01 https://www.mouser.de/datasheet/2/949/w25n01gv_revl_050918_unsecured-1489588.pdf
Memory layout: bytes form pages, pages form sectors and sectors form blocks. There is always some confusion as some vendors omit the term sector
Read operations: can start at every address and have arbitrary length
Write / Program operations: work on single pages. Therefore, at max. PAGE_SIZE Bytes can be written in one go. There is a wrap around in case the configured address was not byte 0 in the current page. Usually, the minimum write size is 1 byte. However, setting a minimum write size to a different value might allow using additional features (such as ECC for the s25fl when using 16 Byte writes to 16 byte aligned addresses).
Erase operations: work on sectors and they always erase the complete sector. If an address is passed which points right in the middle of the sector, also the sector memory before the address is erased.
6. Wrt. the write operations. I think RTEMS_FLASHDEV_IOCTL_WRITE_BLOCK_SIZE is misleading as the term “block” is already defined in the context of flash memories. The implementation / comments / unit tests show that we are looking at the minimum write size. a. Could we refactor this to RTEMS_FLASHDEV_IOCTL_GET_MIN_WRITE_SIZE? b. Especially regarding the ECC features of some flashes. The addresses need to be aligned to RTEMS_FLASHDEV_IOCTL_GET_MIN_WRITE_SIZE. I think we should test the adress alignment on writes.
7. Wrt. the erase operations. The erase operations work on sectors! a. I need an API extension to get the erase size b. We should test that the address passed to the erase function is aligned to the erase size. c. The erase size puts constraints on the regions / partions. Their addresses need to be aligned with the erase size and their length must be a multiple of the erase size
Some unit tests (testsuite flashdev01) fail as expected, but not due to expected reason. Take for example line 148 in testsuites/libtests/flashdev01/init.c and change
read_data = fgets(buff, 2048, file);
to
read_data = fgets(buff, 1, file);
Actually, the test case is expected to fail as the sector size is only 512 bytes and we try to read 2048 bytes. Unfortunatelly, reading a single byte doesnt work either. This is due to the fact that by default buffered IO is used. On my side, each fgets translates to one or more read operations of 1024 bytes length. I.e. this testcase will always succeed as we expect the test to fail. a. I like to propose that we initialise flashdev to operate in buffered mode using RTEMS_FLASHDEV_IOCTL_GET_MIN_WRITE_SIZE. b. I think we should add a raw_read and raw_write to be able to transfer larger junks of data.
I can work on this and start providing patches for review.
Author: Trac Migrate
2023-12-28T16:03:10.000Z
Original author: blofeld80
Owner set to blofeld80
Status changed from new to assigned
Author: Trac Migrate
2023-12-28T16:11:14.000Z
Original author: blofeld80
6b / 8a) Of course I thought of using the return values of RTEMS_FLASHDEV_IOCTL_GET_MIN_WRITE_SIZE for alignment / size checks
Author: Trac Migrate
2024-01-16T16:58:26.000Z
Original author: blofeld80
In [changeset:”a43163d058bd8d9da901e7a7e48591e2ff6aaabe/rtems” a43163d0/rtems]:
flashdev.h: Add missing C++ include guards Updates #4981
Author: Trac Migrate
2024-01-16T16:58:29.000Z
Original author: blofeld80
In [changeset:”bd898b503fd0d250b11cbffddc041e1e29e3fc7e/rtems” bd898b50/rtems]:
flashdev: Add missing default case Updates #4981
Author: Trac Migrate
2024-01-16T16:58:32.000Z
Original author: blofeld80
In [changeset:”a73b52d6a469c330d21e02ea8f82a05edce9fb73/rtems” a73b52d/rtems]:
flashdev.c: return error if both buffers are NULL Updates #4981
Author: Chris Johns
2025-09-19T01:42:04.817Z
changed the description
Author: Chris Johns
2026-07-31T00:08:19.769Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-31T00:08:30.107Z
set status to Done
4919 - QEMU CGEM Priority Queue Bug¶
Id |
4919 |
State |
closed |
Type |
ISSUE |
Author |
Kinsey Moore |
Closed by |
Chris Johns |
Created |
2023-06-14T18:41:44.000Z |
Closed |
2026-07-31T00:00:42.804Z |
Updated |
2026-07-31T00:00:42.809Z |
Milestone |
6.3 |
Labels |
old-indefinite, priority::normal, tickettype::defect, tool, version::6 |
Link |
|
Merges |
0 |
There is a bug in QEMU’s implementation of the CGEM priority queueing. This issue exists to track its inclusion in upstream QEMU.
Author: Kinsey Moore
2023-06-14T18:42:04.000Z
Attachment cgem_zynqmp_versal.patch added
Patch to fix priority queue interrupt issues
Author: Trac Migrate
2023-06-16T13:16:39.000Z
In [changeset:”ac1fee4f04fe5619cca52f960b8ec858adaab7d8/rtems-source-builder” ac1fee4/rtems-source-builder]:
qemu-5-1: Add patch for ZynqMP/Versal CGEMs This temporarily adds a patch to fix badly behaving CGEM peripherals under QEMU. The referenced patch has been submitted for inclusion in the upstream QEMU repository. Updates #4919
Author: Joel Sherrill
2023-06-22T20:59:32.000Z
Milestone changed from %”6.1” to %”Indefinite”
Changing milestone because this is tracking upstream qemu merging this and us using it in the RSB.
Author: Kinsey Moore
2023-06-26T17:45:04.000Z
Attachment 0001-hw-arm-xlnx-Connect-secondary-CGEM-IRQs.patch added
Add v2 of the cgem fix
Author: Kinsey Moore
2023-10-06T19:18:18.000Z
Attachment 0001-hw-arm-xlnx-Connect-secondary-CGEM-IRQs-xlnx.patch added
A version of this patch that cleanly applies to the Xilinx QEMU tree
Author: Trac Migrate
2023-10-07T19:22:46.000Z
In [changeset:”deba39fea4483754784458fb23337b1d5736834c/rtems-source-builder” deba39f/rtems-source-builder]:
qemu: Adjust cgem interrupt patch This patch is being moved to the 5.2.0-1 QEMU configuration because the Xilinx QEMU build uses the 5-1 configuration and this patch does not apply to Xilinx's modified tree. This also adds a new patch that applies correctly to Xilinx's modified QEMU tree. Updates #4919
Author: Kinsey Moore
2024-10-04T00:43:06.661Z
This patch has finally made it on to the QEMU upstream master branch, but is not yet on a release branch: https://github.com/qemu/qemu/commit/604b72dd3c393bf6a7cac59c3a74a2bec4673a80
Author: Amar Takhar
2025-09-05T02:55:32.489Z
changed the description
Author: Kinsey Moore
2026-05-15T14:42:45.355Z
These changes are now present in QEMU 10.x upstream releases
Author: Chris Johns
2026-07-31T00:00:39.677Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-31T00:00:42.839Z
set status to Done
4883 - GDB cannot see TLS variables¶
Id |
4883 |
State |
closed |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Kinsey Moore |
Closed by |
Chris Johns |
Created |
2023-03-21T22:40:16.000Z |
Closed |
2026-07-30T23:56:21.991Z |
Updated |
2026-07-30T23:56:21.996Z |
Milestone |
6.3 |
Labels |
priority::normal, tickettype::defect, tool::gdb, version::6, version::7 |
Link |
|
Merges |
0 |
GDB does not know how to handle TLS variables on RTEMS. This make debugging newlib hard because newlib now uses TLS for it’s reent data.
Author: Chris Johns
2024-02-16T00:36:24.000Z
Milestone changed from %”6.1” to %”Indefinite”
Version changed from ~”6” to ~”7”
We need to understand what GDB needs to have done to it support TLS variables. At the moment it is not possible to determine the scale of effort needed.
We will move this to 7 and when solved we can make a dot release for 6 and release a working GDB.
Author: Kinsey Moore
2025-06-18T18:59:43.193Z
mentioned in merge request !518
Author: Kinsey Moore
2025-06-18T18:59:57.611Z
mentioned in merge request !517
Author: Kinsey Moore
2025-06-19T20:34:52.499Z
The base functionality in RTEMS is added by !517 and !518. There is a piece to this puzzle that still needs to be added to GDB.
Author: Kinsey Moore
2025-06-19T20:34:51.922Z
Attached is the GDB patch that I used to test the TLS functionality.`gdb-tls.patch <https://gitlab.rtems.org/-/project/uploads/2f72fc89002e9a1652c3c943e10be8b0/gdb-tls.patch>`_
While this patch is obviously not suitable for upstream consumption, it does work. It could theoretically be pulled in to the GDB build by RSB in the short term and used to enable TLS functionality for RTEMS until a more polished version of the patch can be incorporated upstream.
Author: Chris Johns
2025-06-19T20:47:35.889Z
Does this mean GDB needs RTEMS support per arch?
Author: Kinsey Moore
2025-06-19T20:50:08.129Z
Unfortunately, I think the answer is yes.
Author: Kinsey Moore
2025-06-19T20:50:47.456Z
And that patch only adds it for AArch64 because that’s what I was testing.
Author: Kinsey Moore
2025-06-19T21:41:04.600Z
~~There is a section that provides a place to hook in OS-targeted objects instead of architecture-targeted objects, so I’ll look into that to see if that can be made to work.~~
This still needs a per-arch stub to point at it, but it will be good for sharing RTEMS details that apply to all architectures.
Author: Kinsey Moore
2025-06-20T20:43:39.076Z
Attached is a more polished version of the GDB patch which should be far more acceptable upstream.`0001-gdb-Add-support-for-TLS-under-RTEMS.patch <https://gitlab.rtems.org/-/project/uploads/ac8467cb05964de8569d62798681d5fd/0001-gdb-Add-support-for-TLS-under-RTEMS.patch>`_
I managed to get all the RTEMS-related support in one place so we don’t have to proliferate files throughout GDB just to support RTEMS. This was built by adding it to the 15.2 GDB recipe in RSB on 6 branch and it was tested with libbsd 6-freebsd-12 with the patch support the vGetTLSAddr query. The version of libbsd should be irrelevant. This is the patch for RSB main GDB recipe (16.2) which has also been tested against the 6-freebsd-12 build: 0001-gdb-Add-support-for-TLS-under-RTEMSv16.2.patch
Author: Kinsey Moore
2026-05-08T19:37:15.226Z
Attached is an even more polished version with feedback from the GDB mailing list that targets 17.1/main.`0001-gdb-Add-support-for-TLS-under-RTEMSv17.1.patch <https://gitlab.rtems.org/-/project/uploads/f4a37404615b82ab9cb8400ecc64e500/0001-gdb-Add-support-for-TLS-under-RTEMSv17.1.patch>`_
Author: Amar Takhar
2025-09-05T02:55:31.997Z
changed the description
Author: Chris Johns
2026-07-30T23:55:53.899Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-30T23:56:00.428Z
assigned to @opticron
Author: Chris Johns
2026-07-30T23:56:22.028Z
set status to Done
4852 - Deprecated Functions¶
Id |
4852 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2023-02-13T14:13:41.000Z |
Closed |
2026-07-30T23:55:07.913Z |
Updated |
2026-07-30T23:55:07.919Z |
Milestone |
6.3 |
Labels |
old-indefinite, priority::normal, qualification, tickettype::defect, version::6 |
Link |
|
Merges |
1 |
Original author: dppinto
It is stated in the comments that these functions are deprecated: * cpukitincludertemsfatal.h: RTEMS_NO_RETURN void rtems_fatal_error_occurred( uint32_t fatal_code ); * cpukitincludertemsscorethread.h: void rtems_iterate_over_all_threads( );
Can these be removed now or are there still portability reasons to still keep these?
Additional Notes: This ticket was raised as an outcome of the Independent SW Verification and Validation (ISVV) for ESA-promoted RTEMS SMP Qualification Data Packs (https://rtems-qual.io.esa.int). The original ISVV reference for this issue is RTEMS-SMP-CODE-VER-018.
Author: Trac Migrate
2023-03-23T16:22:37.000Z
Original author: dppinto
Milestone set to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Author: Amar Takhar
2024-04-25T20:50:35.916Z
changed the description
Author: Samuel Viegas
2026-02-25T12:04:16.774Z
mentioned in merge request !1081
Author: Chris Johns
2026-07-30T23:55:02.956Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-30T23:55:07.950Z
set status to Obsolete
4849 - “Timer Server” Cannot be Used in Systems with Static Memory Allocation¶
Id |
4849 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2023-02-10T12:57:39.000Z |
Closed |
2026-07-30T23:54:51.877Z |
Updated |
2026-07-30T23:54:51.882Z |
Milestone |
6.3 |
Labels |
old-indefinite, priority::normal, qualification, tickettype::defect, tickettype::enhancement, version::6 |
Link |
|
Merges |
0 |
Original author: dppinto
For the current pre-qualified feature set of RTEMS, one wants to use rtems_timer_initiate_server(), then it has to provide a custom stack allocator. This makes it inconvenient to use. One option would be to provide a new directive to construct the timer server, for example rtems_timer_server_construct().
Additional Notes: This ticket was raised as an outcome of the Independent SW Verification and Validation (ISVV) for ESA-promoted RTEMS SMP Qualification Data Packs (https://rtems-qual.io.esa.int). The original ISVV reference for this issue is RTEMS-SMP-VAL-001.
Author: Joel Sherrill
2023-02-10T14:02:28.000Z
Original author: dppinto
Summary changed from “Timer Server” is not directly usable to “Timer Server” Cannot be Used in Systems with Static Memory Allocation
Author: Trac Migrate
2023-03-23T16:23:36.000Z
Original author: dppinto
Milestone set to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Author: Amar Takhar
2024-04-25T20:50:34.593Z
changed the description
Author: Chris Johns
2026-07-30T23:54:44.760Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-30T23:54:51.911Z
set status to Obsolete
4570 - devel/qemu is not buildable on Mac OS X.¶
Id |
4570 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2021-12-12T16:04:20.000Z |
Closed |
2026-07-30T23:45:34.529Z |
Updated |
2026-07-30T23:45:34.589Z |
Milestone |
6.3 |
Labels |
old-indefinite, priority::normal, tickettype::defect, tool::rtems-source-builder, version::6 |
Link |
|
Merges |
0 |
Original author: kgardas
Hi,
using recent (as of 2021-12-11) rsb source code from git, I’m not able to build devel/qemu on Mac OS X. It fails on glib compilation which fails on configure step in two ways: missing __int64 type and missing gettext library – looks like DYLD_LIBRARY_PATH=$SYSROOT/lib is not working as expected.
Steps to reproduce:
cd bare
../source-builder/sb-set-builder --prefix=/tmp devel/qemu
anyway, I’m attaching both report and glib’s config.log here which contain all the clues.
Author: Trac Migrate
2021-12-12T16:08:01.000Z
Original author: kgardas
Attachment rsb-report-glib-2.48.2-x86_64-apple-darwin19.6.0-1.txt.xz added
rsb report
Author: Trac Migrate
2021-12-12T16:08:24.000Z
Original author: kgardas
Attachment config-3.log added
config log
Author: Chris Johns
2022-11-29T23:50:19.000Z
Original author: kgardas
Status update?
Author: Joel Sherrill
2023-06-22T20:49:31.000Z
Original author: kgardas
Any updates? We’d like to know it works or not and close this ticket.
Author: Joel Sherrill
2023-06-22T21:47:51.000Z
Original author: kgardas
Milestone changed from %”6.1” to %”Indefinite”
Version ~”6” deleted
Author: Joel Sherrill
2023-06-22T21:48:14.000Z
Original author: kgardas
Owner set to Needs Funding
Status changed from new to assigned
Just kicking it down the road.
Author: Trac Migrate
2023-07-10T09:11:56.000Z
Original author: kgardas
Tested today, it fails even more sooner on configuration of autoconf:
karel@mini rtems % ../source-builder/sb-set-builder --prefix=/tmp/test devel/qemu RTEMS Source Builder - Set Builder, 6 (8e568b2ca348) warning: exe: absolute exe found in path: (__install_info) /usr/bin/install-info warning: exe: absolute exe found in path: (__makeinfo) /usr/bin/makeinfo Build Set: devel/qemu Build Set: devel/autotools-internal.bset config: devel/autoconf-2.69-1.cfg package: autoconf-2.69-arm64-apple-darwin22.5.0-1 building: autoconf-2.69-arm64-apple-darwin22.5.0-1 error: building autoconf-2.69-arm64-apple-darwin22.5.0-1 Build FAILED See error report: rsb-report-autoconf-2.69-arm64-apple-darwin22.5.0-1.txt Note: In some cases the error appears only in the complete build log (see --log option) error: building autoconf-2.69-arm64-apple-darwin22.5.0-1 Build Set: Time 0:00:01.562289 error: building autoconf-2.69-arm64-apple-darwin22.5.0-1 Build Set: Time 0:00:01.566968 Build FAILEDand autoconf fails on classical issue with unrecognized
arm64-applename:+ cd autoconf-2.69 + test yes = yes + ac_prefix=/Users/karel/git/rtems-source-builder-ref/rtems/build/tmp/sb-502/tmp/test + test arm64-apple-darwin22.5.0 '!=' arm64-apple-darwin22.5.0 + export CFLAGS CFLAGS_FOR_BUILD CC + CFLAGS='-O2 -pipe -fbracket-depth=1024 -I/Users/karel/git/rtems-source-builder-ref/rtems/build/tmp/sb-502/devel/autotools-internal/tmp/test/include ' + ./configure --build=arm64-apple-darwin22.5.0 --host=arm64-apple-darwin22.5.0 --verbose --disable-nls --without-included-gettext --prefix=/Users/karel/git/rtems-source-builder-ref/rtems/build/tmp/sb-502/tmp/test configure: WARNING: unrecognized options: --disable-nls, --without-included-gettext checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... build-aux/install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes Invalid configuration `arm64-apple-darwin22.5.0': machine `arm64-apple' not recognized configure: error: /bin/sh build-aux/config.sub arm64-apple-darwin22.5.0 failed checking build system type... checking build system type... shell cmd failed: /bin/sh -ex /Users/karel/git/rtems-source-builder-ref/rtems/build/autoconf-2.69-arm64-apple-darwin22.5.0-1/do-build error: building autoconf-2.69-arm64-apple-darwin22.5.0-1
Author: Amar Takhar
2025-09-05T02:57:51.741Z
changed the description
Author: Kinsey Moore
2026-05-15T16:32:35.716Z
Looks like there is currently an error during build likely due to a newer GCC version: https://lists.rtems.org/pipermail/build/2026-May/073276.html
Author: Joel Sherrill
2026-05-15T16:32:35.667Z
@chris’ addition of std=support should make it easy to fix. Whatever package that is will likely be fixed with gnu17 for C and gnu++17 for C++.
If this is on the 6 branch, the milestone shouldn’t have been removed. It should have been moved to 6.5 if we aren’t fixing it for 6.4. but we should fix it.
Author: Kinsey Moore
2026-05-15T16:36:43.602Z
%6.3 hasn’t even been released yet and it still has that milestone on it.
Author: Chris Johns
2026-07-30T23:45:34.562Z
set status to Obsolete
4498 - libelftc_dem_gnu3.c: Resource leak spotted by Coverity¶
Id |
4498 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2021-08-17T15:02:12.000Z |
Closed |
2026-07-30T23:45:18.806Z |
Updated |
2026-07-30T23:45:18.862Z |
Milestone |
6.3 |
Labels |
priority::normal, tickettype::defect, tool, version::6 |
Link |
|
Merges |
0 |
Original author: rlong
Upstream issue [https://sourceforge.net/p/elftoolchain/tickets/607/]
CID 1305425: Resource leak
2913 if (!vector_str_push(&v.ext_name, ddata->cur, len))
CID 1305425 (#1 of 1): Resource leak (RESOURCE_LEAK)48. leaked_storage: Variable exp_str going out of scope leaks the storage it points to.
2914 return (0);
Author: Joel Sherrill
2021-12-16T15:56:11.000Z
Original author: rlong
Milestone changed from %”6.1” to %”7.1”
Author: Joel Sherrill
2025-09-19T00:14:28.063Z
changed the description
Author: Joel Sherrill
2025-09-19T00:14:28.109Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-30T23:45:18.838Z
set status to Done
4497 - libelftc_dem_gnu2.c: Resource leak spotted by Coverity¶
Id |
4497 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2021-08-17T14:57:46.000Z |
Closed |
2026-07-30T23:45:03.274Z |
Updated |
2026-07-30T23:45:03.350Z |
Milestone |
6.3 |
Labels |
priority::normal, tickettype::defect, tool, version::6 |
Link |
|
Merges |
0 |
Original author: rlong
Upstream ticket [https://sourceforge.net/p/elftoolchain/tickets/607/]
CID 1262520: Resource leak
244
CID 1262520 (#1 of 1): Resource leak (RESOURCE_LEAK)39. leaked_storage: Variable arg going out of scope leaks the storage it points to.
245 return (rtn);
246}
Author: Trac Migrate
2021-08-17T15:04:07.000Z
Original author: rlong
Version set to ~”6”
Author: Joel Sherrill
2021-12-16T15:55:49.000Z
Original author: rlong
Milestone changed from %”6.1” to %”7.1”
Author: Joel Sherrill
2025-09-19T00:14:17.140Z
changed the description
Author: Joel Sherrill
2025-09-19T00:14:17.179Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-30T23:45:03.314Z
set status to Done
4496 - libelftc_dem_arm.c: Resource leak spotted by Coverity¶
Id |
4496 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2021-08-17T14:51:04.000Z |
Closed |
2026-07-30T23:44:50.944Z |
Updated |
2026-07-30T23:44:51.004Z |
Milestone |
6.3 |
Labels |
priority::normal, tickettype::defect, tool, version::6 |
Link |
|
Merges |
0 |
Original author: rlong
Upstream ticket [https://sourceforge.net/p/elftoolchain/tickets/607]
CID 1262518: Resource leak
229
CID 1262518 (#1 of 1): Resource leak (RESOURCE_LEAK)56. leaked_storage: Variable arg going out of scope leaks the storage it points to.
230 return (rtn);
231}
CID 1262519: Resource leak
958 if (VEC_PUSH_STR(&d->vec, "::operator ") == false)
CID 1262529: Resource leak (RESOURCE_LEAK) [select issue]
CID 1262519 (#1 of 1): Resource leak (RESOURCE_LEAK)18. leaked_storage: Variable to_str going out of scope leaks the storage it points to.
959 return (false);
CID 1262529: Resource leak
958 if (VEC_PUSH_STR(&d->vec, "::operator ") == false)
CID 1262519: Resource leak (RESOURCE_LEAK) [select issue]
CID 1262529 (#1 of 1): Resource leak (RESOURCE_LEAK)19. leaked_storage: Variable from_str going out of scope leaks the storage it points to.
959 return (false);
Author: Trac Migrate
2021-08-17T15:03:11.000Z
Original author: rlong
Version set to ~”6”
Author: Joel Sherrill
2021-12-16T15:55:24.000Z
Original author: rlong
Milestone changed from %”6.1” to %”7.1”
Author: Joel Sherrill
2025-09-19T00:13:38.366Z
changed the description
Author: Joel Sherrill
2025-09-19T00:13:38.432Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-30T23:44:50.979Z
set status to Done
4447 - rtems-source-builder undefined reference to `BCryptGenRandom’¶
Id |
4447 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2021-06-01T12:55:05.000Z |
Closed |
2026-07-30T23:44:32.318Z |
Updated |
2026-07-30T23:44:32.322Z |
Milestone |
6.3 |
Labels |
priority::normal, tickettype::defect, version::6 |
Link |
|
Merges |
0 |
Original author: tai.burakdeniz
When trying to build RTEMS by RSB with below instruction I get following error;
“../source-builder/sb-set-builder –prefix=$HOME/quick-start/rtems/6 6/rtems-sparc”
Error; ” C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ../gnulib/import/libgnu.a(getrandom.o): in function `getrandom’:
C:msys64homew7quick-startsrcrsbrtemsbuildsrg7xwm1buildgnulibimport/../../../sourceware-mirror-binutils-gdb-7ab567f/gnulib/import/getrandom.c:129: undefined reference to `BCryptGenRandom’
collect2.exe: error: ld returned 1 exit status
make[2]: *** [Makefile:1866: gdb.exe] Error 1
make[2]: Leaving directory ‘/c/msys64/home/w7/quick-start/src/rsb/rtems/build/srg7xwm1/build/gdb’
make[1]: *** [Makefile:9410: all-gdb] Error 2
make[1]: Leaving directory ‘/c/msys64/home/w7/quick-start/src/rsb/rtems/build/srg7xwm1/build’
make: *** [Makefile:866: all] Error 2
shell cmd failed: sh -ex /c/msys64/home/w7/quick-start/src/rsb/rtems/build/srg7xwm1/do-build
error: building srg7xwm1 “
OS: Windows 7 64 bit, Rtems Version: 6 using MSYS2
Author: Joel Sherrill
2021-06-01T12:59:36.000Z
Original author: tai.burakdeniz
This looks like gdb on msys2 is not being linked against a random number library.
https://docs.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptgenrandom
Also looks like that may be deprecated.
Author: Trac Migrate
2021-06-01T13:47:37.000Z
Original author: tai.burakdeniz
Replying to Joel Sherrill:
This looks like gdb on msys2 is not being linked against a random number library. https://docs.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptgenrandom Also looks like that may be deprecated.
Hello Joel, thank you for your comment. I check the file on this path ;”/mingw64/x86_64-w64-mingw32/include” by grep and the file is exist but not exist in “/mingw64/include”. I will try to copy or install. $find . | grep “bcrypt.h” ./bcrypt.h
Author: Joel Sherrill
2021-06-01T16:47:11.000Z
Original author: tai.burakdeniz
I found this thread which I read as you might be missing a DLL:
http://sourceware-org.1504.n7.nabble.com/Unable-to-build-GDB-on-Windows-td649748.html
It is also possible based on that thread that gdb is missing some configure magic still.
Author: Chris Johns
2025-09-19T01:42:00.553Z
changed the description
Author: Chris Johns
2026-07-30T23:44:20.880Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-30T23:44:32.350Z
set status to Obsolete
4431 - record-filter-zlib.cc: Unchecked return value from library error spotted by Coverity¶
Id |
4431 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2021-05-19T14:45:26.000Z |
Closed |
2026-07-30T23:44:05.071Z |
Updated |
2026-07-30T23:44:05.076Z |
Milestone |
6.3 |
Labels |
old-indefinite, priority::normal, scan::coverity, tickettype::defect, tool, version::6 |
Link |
|
Merges |
0 |
Original author: rlong
CID 1503013: Unchecked return value from library in ZlibFilter().
CID 1503013 (#1 of 1): Unchecked return value from library (CHECKED_RETURN)1. check_return: Calling inflateInit_(&this->stream_, "1.2.7", 112) without checking return value. This library function may fail and return an error code.
38 inflateInit(&stream_);
Author: Trac Migrate
2021-12-16T21:19:31.000Z
Original author: rlong
Milestone changed from %”6.1” to %”Indefinite”
Author: Amar Takhar
2024-04-25T20:49:03.287Z
changed the description
Author: Chris Johns
2026-07-30T23:43:19.919Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-30T23:44:05.105Z
set status to Done
4381 - crypt-sha256.c: Constant variable guards dead code¶
Id |
4381 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2021-04-07T13:01:01.000Z |
Closed |
2026-07-30T23:43:08.901Z |
Updated |
2026-07-30T23:43:08.907Z |
Milestone |
6.3 |
Labels |
library, priority::normal, tickettype::defect, version::6 |
Link |
|
Merges |
0 |
Original author: rlong
CID 1018089: Constant variable guards dead code in crypt_sha256_r().
assignment: Assigning: copied_salt = NULL.
77 copied_salt = NULL;
.
.
.
null: At condition copied_salt != NULL, the value of copied_salt must be NULL.
dead_error_condition: The condition copied_salt != NULL cannot be true.
265 if (copied_salt != NULL)
CID 1018089 (#1 of 1): 'Constant' variable guards dead code (DEADCODE)dead_error_line: Execution cannot reach this statement: memset(copied_salt, 0, salt....
CID 1018090: Constant variable guards dead code in crypt_sha256_r().
assignment: Assigning: copied_key = NULL.
76 copied_key = NULL;
.
.
.
null: At condition copied_key != NULL, the value of copied_key must be NULL.
dead_error_condition: The condition copied_key != NULL cannot be true.
263 if (copied_key != NULL)
CID 1018090 (#1 of 1): 'Constant' variable guards dead code (DEADCODE)dead_error_line: Execution cannot reach this statement: memset(copied_key, 0, key_l....
Author: Trac Migrate
2021-04-07T13:02:48.000Z
Original author: rlong
These variables are no longer in the code according to the latest stable version of freeBSD. https://cgit.freebsd.org/src/tree/lib/libcrypt/crypt-sha256.c?h=stable/13#n71
Author: Trac Migrate
2021-12-16T16:42:18.000Z
Original author: rlong
Milestone changed from %”6.1” to %”Indefinite”
Author: Amar Takhar
2025-09-05T02:57:50.268Z
changed the description
Author: Chris Johns
2026-07-30T23:43:04.715Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-30T23:43:08.938Z
set status to Done
4379 - crypt-sha512.c: Constant variable guards dead code¶
Id |
4379 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2021-04-06T21:03:29.000Z |
Closed |
2026-07-30T23:42:55.898Z |
Updated |
2026-07-30T23:42:55.902Z |
Milestone |
6.3 |
Labels |
library, priority::normal, tickettype::defect, version::6 |
Link |
|
Merges |
0 |
Original author: rlong
CID 1018087: Constant variable guards dead code in crypt_sha512_r().
assignment: Assigning: copied_salt = NULL.
77 copied_salt = NULL;
.
.
.
276 memset(copied_key, '\\0', key_len);
null: At condition copied_salt != NULL, the value of copied_salt must be NULL.
dead_error_condition: The condition copied_salt != NULL cannot be true.
277 if (copied_salt != NULL)
CID 1018088: Constant variable guards dead code in crypt_sha512_r().
75
assignment: Assigning: copied_key = NULL.
76 copied_key = NULL;
.
.
.
274 memset(&alt_ctx, '\\0', sizeof(alt_ctx));
null: At condition copied_key != NULL, the value of copied_key must be NULL.
dead_error_condition: The condition copied_key != NULL cannot be true.
275 if (copied_key != NULL)
Author: Trac Migrate
2021-04-07T13:05:48.000Z
Original author: rlong
These variables/checks are no longer in this code according to the source code of the latest stable release https://cgit.freebsd.org/src/tree/lib/libcrypt/crypt-sha512.c?h=stable/13#n71.
Author: Trac Migrate
2021-12-16T20:48:15.000Z
Original author: rlong
Milestone changed from %”6.1” to %”Indefinite”
Author: Amar Takhar
2025-09-05T02:57:50.056Z
changed the description
Author: Chris Johns
2026-07-30T23:42:28.449Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-30T23:42:55.930Z
set status to Done
4373 - qemu: qemu-system-arm hangs during cron’ed test runs with rtems-test¶
Id |
4373 |
State |
closed |
Type |
ISSUE |
Author |
Joel Sherrill |
Closed by |
Chris Johns |
Created |
2021-04-03T19:22:41.000Z |
Closed |
2026-07-30T23:42:14.385Z |
Updated |
2026-07-30T23:42:14.397Z |
Milestone |
6.3 |
Labels |
priority::normal, tickettype::defect, tool, version::6 |
Link |
|
Merges |
0 |
When I run the automated build sweep on the CentOS server, I see some qemu hang but only on arm. I thought it might be the qemu BSP but I noticed this time it is xilinx_zynq_zc706 which might be a clue.
Anyway, I login and check on things and this only happens on this machine. The same script should be running on FreeBSD and Ubuntu but I don’t see this behavior on those servers.
[joel@devel ~]$ ps -ef | grep " qemu-system"
joel 6457 6408 91 Apr02 ? 18:29:20 qemu-system-arm -no-reboot -nographic -net none -serial null -serial mon:stdio -M xilinx-zynq-a9 -m 1024M -kernel ./arm-rtems6/c/xilinx_zynq_zc706/testsuites/fstests/fsdosfsname02.exe
joel 8429 6408 91 Apr02 ? 18:15:06 qemu-system-arm -no-reboot -nographic -net none -serial null -serial mon:stdio -M xilinx-zynq-a9 -m 1024M -kernel ./arm-rtems6/c/xilinx_zynq_zc706/testsuites/fstests/mimfs_fspatheval.exe
joel 12157 6408 91 Apr02 ? 17:55:49 qemu-system-arm -no-reboot -nographic -net none -serial null -serial mon:stdio -M xilinx-zynq-a9 -m 1024M -kernel ./arm-rtems6/c/xilinx_zynq_zc706/testsuites/libtests/mathf.exe
joel 15393 6408 91 Apr02 ? 17:38:08 qemu-system-arm -no-reboot -nographic -net none -serial null -serial mon:stdio -M xilinx-zynq-a9 -m 1024M -kernel ./arm-rtems6/c/xilinx_zynq_zc706/testsuites/psxtests/psxautoinit02.exe
joel 19015 6408 92 Apr02 ? 17:20:36 qemu-system-arm -no-reboot -nographic -net none -serial null -serial mon:stdio -M xilinx-zynq-a9 -m 1024M -kernel ./arm-rtems6/c/xilinx_zynq_zc706/testsuites/psxtests/psxsignal07.exe
joel 19815 6408 92 Apr02 ? 17:16:48 qemu-system-arm -no-reboot -nographic -net none -serial null -serial mon:stdio -M xilinx-zynq-a9 -m 1024M -kernel ./arm-rtems6/c/xilinx_zynq_zc706/testsuites/psxtests/psxusleep.exe
joel 25821 25724 0 14:17 pts/1 00:00:00 grep --color=auto qemu-system
joel 28277 6408 95 Apr02 ? 16:41:27 qemu-system-arm -no-reboot -nographic -net none -serial null -serial mon:stdio -M xilinx-zynq-a9 -m 1024M -kernel ./arm-rtems6/c/xilinx_zynq_zc706/testsuites/sptests/spedfsched03.exe
joel 31545 6408 95 Apr02 ? 16:28:14 qemu-system-arm -no-reboot -nographic -net none -serial null -serial mon:stdio -M xilinx-zynq-a9 -m 1024M -kernel ./arm-rtems6/c/xilinx_zynq_zc706/testsuites/sptests/spnsext01.exe
Author: Chris Johns
2021-04-08T01:36:29.000Z
Summary changed from rtems-test: qemu-system-arm hangs during cron’ed test runs to qemu: qemu-system-arm hangs during cron’ed test runs with rtems-test
I am sorry but you are going to have to debug this to resolve it because it is not been seen else where and/or we do not have a suitable set up to duplicate it.
At the core of the bug is qemu stopping and it should not unless our test code or the BSP has a problem you have exposed. I agree there is a secondary bug where
rtems-testis not killing the process but I am reluctant to look at that until the reason qemu hangs is found. A fixedrtems-testonly results in more tests being (maybe) incorrectly tag asindeterminateand I prefer we look to get better qemu test results.A few suggestions…
Is console output still being generated?
See if you can find out where in an RTEMS test executable things are hanging. This means adding the gdb server flag to each qemu however I am not sure if this breaks when a number of qemu sessions are run in parallel, ie port binding.
Can you connect a python debugger to an active process based on pid? If you could debug what is happening that would help the
rtems-testof things but as stated IMO that is secondary to the real issue.Hack
rtems-testto add some trace around the job handling. Again onlyrtems-testrelated.
Author: Joel Sherrill
2021-12-17T20:35:44.000Z
Milestone changed from %”6.1” to %”Indefinite”
Changing the milestone because this is hard to reproduce and could randomly go away with a different qemu version.
Author: Amar Takhar
2025-09-05T02:57:49.787Z
changed the description
Author: Chris Johns
2026-07-30T23:41:23.263Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-30T23:42:14.445Z
set status to Done
Author: Chris Johns
2026-07-30T23:42:15.690Z
The fix is project input from
/dev/nullto QEMU or it hangs.
4333 - rtl-allocator.c: Dereference null return value error spotted by Coverity¶
Id |
4333 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2021-03-10T19:48:17.000Z |
Closed |
2026-07-30T23:39:03.959Z |
Updated |
2026-07-30T23:39:03.964Z |
Milestone |
6.3 |
Labels |
old-indefinite, priority::normal, tickettype::defect, version::6 |
Link |
|
Merges |
0 |
Original author: rlong
CID 1444139: Dereference null return value in rtems_rtl_alloc_hook().
1. returned_null: rtems_rtl_lock returns NULL (checked 23 out of 28 times). [show details]
2. var_assigned: Assigning: rtl = NULL return value from rtems_rtl_lock.
164 rtems_rtl_data* rtl = rtems_rtl_lock ();
CID 1444139 (#1 of 1): Dereference null return value (NULL_RETURNS)3. dereference: Dereferencing rtl, which is known to be NULL.
165 rtems_rtl_allocator previous = rtl->allocator.allocator;
Author: Trac Migrate
2021-12-16T20:47:12.000Z
Original author: rlong
Milestone changed from %”6.1” to %”Indefinite”
Author: Amar Takhar
2025-09-05T02:57:49.230Z
changed the description
Author: Chris Johns
2026-07-30T23:38:58.675Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-30T23:39:03.992Z
set status to Done
4332 - rtl-obj.c: Derefernce null return value error spotted by Coverity¶
Id |
4332 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2021-03-10T19:45:42.000Z |
Closed |
2026-07-30T23:38:44.274Z |
Updated |
2026-07-30T23:38:44.279Z |
Milestone |
6.3 |
Labels |
old-indefinite, priority::normal, tickettype::defect, version::6 |
Link |
|
Merges |
0 |
Original author: rlong
CID 1444138: Derference null return value in rtems_rtl_obj_find_file().
4. returned_null: rtems_rtl_lock returns NULL (checked 23 out of 28 times). [hide details]
5. var_assigned: Assigning: rtl = NULL return value from rtems_rtl_lock.
410 rtl = rtems_rtl_lock ();
411
CID 1444138 (#1 of 1): Dereference null return value (NULL_RETURNS)6. dereference: Dereferencing rtl, which is known to be NULL.
412 if (!rtems_rtl_find_file (pname, rtl->paths, &obj->fname, &obj->fsize))
Author: Trac Migrate
2021-12-16T20:45:25.000Z
Original author: rlong
Milestone changed from %”6.1” to %”Indefinite”
Author: Amar Takhar
2025-09-05T02:57:49.030Z
changed the description
Author: Chris Johns
2026-07-30T23:38:39.334Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-30T23:38:44.309Z
set status to Done
4327 - shell.c: Dereference after null check error spotted by Coverity¶
Id |
4327 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2021-03-10T14:59:32.000Z |
Closed |
2026-07-30T23:38:19.535Z |
Updated |
2026-07-30T23:38:19.539Z |
Milestone |
6.3 |
Labels |
library, priority::normal, tickettype::defect, version::6 |
Link |
|
Merges |
0 |
Original author: rlong
CID 26083: Dereference after null check in rtems_shell_login().
791
CID 26083 (#1 of 1): Dereference after null check (FORWARD_NULL)3. var_deref_model: Passing null pointer out to rtems_shell_login_prompt, which dereferences it. [show details]
792 return rtems_shell_login_prompt(in, out, env->devname, env->login_check);
Author: Trac Migrate
2021-12-16T20:43:43.000Z
Original author: rlong
Milestone changed from %”6.1” to %”Indefinite”
Author: Amar Takhar
2025-09-05T02:57:48.834Z
changed the description
Author: Chris Johns
2026-07-30T23:38:09.332Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-30T23:38:19.567Z
set status to Done
4292 - rtems-rfs-bitmaps.c: Useless call (CID 1399749)¶
Id |
4292 |
State |
closed |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Chris Johns |
Closed by |
Chris Johns |
Created |
2021-03-03T21:04:09.000Z |
Closed |
2026-07-30T23:37:58.294Z |
Updated |
2026-07-30T23:37:58.359Z |
Milestone |
6.3 |
Labels |
filesystem::rfs, priority::normal, tickettype::defect, version::6 |
Link |
|
Merges |
0 |
Coverity Scan spotted this in rtems-rfs-bitmaps.c as CID 1399749). On the face of it, Scan appears to be correct but this issue should be reviewed by the original author of this code.
}
623 else
624 {
625 bits = *map;
626 available = rtems_rfs_bitmap_element_bits ();
627 }
628
629 if (rtems_rfs_bitmap_match (bits, RTEMS_RFS_BITMAP_ELEMENT_SET))
CID 1399749 (#1 of 1): Useless call (USELESS_CALL)
side_effect_free: Calling rtems_rfs_bitmap_set(*search_map, bit) is only useful for its return value, which is ignored. [show details]
630 rtems_rfs_bitmap_set (*search_map, bit);
631 else
632 {
Author: Joel Sherrill
2021-03-03T21:04:21.000Z
Owner set to @chrisj
Status changed from new to assigned
Author: Chris Johns
2024-05-16T23:08:01.788Z
changed the description
Author: Chris Johns
2024-05-16T23:08:05.781Z
Please create merge request.
Author: Gedare Bloom
2024-12-04T21:40:37.082Z
Author: Chris Johns
2025-10-02T22:39:56.306Z
added rtems#15 as parent epic
Author: Chris Johns
2026-07-30T23:37:58.332Z
set status to Done
4300 - rtl-shell.c: Resource leak error spotted by Coverity¶
Id |
4300 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2021-03-04T17:06:29.000Z |
Closed |
2026-07-30T23:37:12.217Z |
Updated |
2026-07-30T23:37:12.278Z |
Milestone |
6.3 |
Labels |
old-indefinite, priority::normal, tickettype::defect, version::6 |
Link |
|
Merges |
0 |
Original author: rlong
CID 1444140: Resource leak in rtems_rtl_shell_object().
Author: Trac Migrate
2021-03-04T17:07:35.000Z
Original author: rlong
739 if (unresolved != 0) 740 { 741 rtems_printf (printer, "warning: unresolved symbols present\\n"); CID 1444140 (#3 of 3): Resource leak (RESOURCE_LEAK)24. leaked_storage: Variable handle going out of scope leaks the storage it points to. 742 return 1; 743 }
Author: Trac Migrate
2021-12-16T20:41:14.000Z
Original author: rlong
Milestone changed from %”6.1” to %”Indefinite”
Author: Amar Takhar
2025-09-05T02:57:48.048Z
changed the description
Author: Chris Johns
2026-07-30T23:37:12.251Z
set status to Done
4296 - hexdump-parse.c: Resource leak error spotted by Coverity¶
Id |
4296 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2021-03-04T15:51:02.000Z |
Closed |
2026-07-30T23:33:50.523Z |
Updated |
2026-07-30T23:33:50.528Z |
Milestone |
6.3 |
Labels |
library, old-indefinite, priority::normal, tickettype::defect, version::6 |
Link |
|
Merges |
0 |
Original author: rlong
CID 26032: Resource leak in rtems_shell_hexdump_rewrite().
457#ifdef DEBUG
458 for (fu = fs->nextfu; fu; fu = fu->nextfu) {
459 (void)printf("fmt:");
460 for (pr = fu->nextpr; pr; pr = pr->nextpr)
461 (void)printf(" {%s}", pr->fmt);
462 (void)printf("\\n");
463 }
464#endif
CID 26032 (#2 of 2): Resource leak (RESOURCE_LEAK)57. leaked_storage: Variable nextpr going out of scope leaks the storage it points to.
465}
Author: Trac Migrate
2021-12-16T17:13:06.000Z
Original author: rlong
Milestone changed from %”6.1” to %”Indefinite”
I don’t see that anything was done to fix this issue, but I also don’t see it in the list of Resource leak issues in Coverity.
Author: Amar Takhar
2025-09-05T02:57:47.436Z
changed the description
Author: Chris Johns
2026-07-30T23:33:40.580Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-30T23:33:50.558Z
set status to Done
4208 - RSB: GMP not configured correctly in MSYS in newlib build step¶
Id |
4208 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2021-01-01T14:34:30.000Z |
Closed |
2026-07-30T23:29:26.688Z |
Updated |
2026-07-30T23:29:26.693Z |
Milestone |
6.3 |
Labels |
old-indefinite, priority::normal, tickettype::defect, version::6, version::7 |
Link |
|
Merges |
0 |
Original author: rmueller
I had issues with a Cxc cross-compiled toolchain (ARM) on Windows so I tried to recompile it natively (there were some updates, GMP is built now).
However, there are issues building newlib related to GMP. The build is configured with the following options:
configure: summary of build options:
Version: GNU MP 6.1.0 Host type: none-w64-mingw32 ABI: standard Install prefix: /c/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6 Compiler: x86_64-w64-mingw32-gcc -O2 -g -pipe -I/c/Users/Robin/Documents/RTEMS/rtems-tools/src/rsb/rtems/build/tmp/sb-197609/6a/c/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/include Static libraries: yes Shared libraries: no
And the build fails with the following error:
In file included from ../../../gnu-mirror-gcc-03e2d83/gmp/gmp-impl.h:146,
from fib_table.c:4:
../fib_table.h:4:1: warning: data definition has no type or storage class
4 | Error, error, this data is for 32 bits
../fib_table.h:4:1: warning: type defaults to ‘int’ in declaration of ‘Error’ [-Wimplicit-int]
I tried to compile GMP separately, using the following commands:
./configure –prefix=/c/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6 –disable-shared –enable-static make make install
And this appeared to work.
configure: summary of build options:
Version: GNU MP 6.1.0 Host type: x86_64-w64-mingw32 ABI: 64 Install prefix: /c/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6 Compiler: gcc Static libraries: yes Shared libraries: no
Maybe ABI is not set properly? Also, GMP was alreay (successfully) built so I am confused that it is built again as part of the newlib build with these settings.
I am also a bit confused that Host was set to none-w64-mingw32 because the sb program recognized that the systemis a x86_64 system as well (I printed out the value which is assigned to _build to test this in the sb program).
I attached the error report as well
Kind Regards Robin
Author: Trac Migrate
2021-01-01T14:39:18.000Z
Original author: rmueller
Summary changed from GMP not configured correctly in MSYS in newlib build step to RSB: GMP not configured correctly in MSYS in newlib build step
Author: Trac Migrate
2021-01-01T14:41:37.000Z
Original author: rmueller
Could not attach file. Find it here: https://drive.google.com/file/d/1zKp7IWn9hW_5QvE92UA2oNz24TKs6uMc/view?usp=sharing
To reproduce the issue, run the following RSB set-builder command on Windows 10 on a x86_64 system:
../source-builder/sb-set-builder –prefix=$RTEMS_TOOLS 6/rtems-arm
Author: Trac Migrate
2022-05-17T05:41:02.000Z
Original author: rmueller
edit the Makefile.in in gcc source directory, change GMP configure line “–host=none-${host_vendor}-${host_os} –target=none-${host_vendor}-${host_os}” to “–host=${host_alias} –target=${host_alias}”, the build will be success.
Author: Chris Johns
2022-11-29T23:28:05.000Z
Original author: rmueller
Milestone changed from %”6.1” to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Version changed from ~”6” to ~”7”
Author: Amar Takhar
2025-09-05T02:57:46.420Z
changed the description
Author: Chris Johns
2026-07-30T23:29:18.242Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-30T23:29:26.724Z
set status to Obsolete
4199 - MSYS2: Building newlib appears to be stuck¶
Id |
4199 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2020-12-03T17:05:20.000Z |
Closed |
2026-07-30T23:28:14.941Z |
Updated |
2026-07-30T23:28:15.004Z |
Milestone |
6.3 |
Labels |
priority::normal, tickettype::defect, version::6 |
Link |
|
Merges |
0 |
Original author: rmueller
Just reporting this with the hope that I am not the only one with the issue when building the tool suite on Windows with MSYS2
I had another issues where the the building the tool suite failed when configuring expat. That issue went away (although I can’t reasonably explain why and how, maybe it was an update), but now the build process appears to be problematic somewhere else.
When building the newlib, the process appears to be stuck. This is the output from the command line:
downloading: sources/mpc-1.0.3.tar.gz - 654.2kB of 654.2kB (100%) download: https://ftp.gnu.org/gnu/gmp/gmp-6.1.0.tar.bz2 -> sources/gmp-6.1.0.tar.bz2 downloading: sources/gmp-6.1.0.tar.bz2 - 2.3MB of 2.3MB (100%) building: sparc-rtems5-gcc-7.5.0-newlib-7947581-x86_64-w64-mingw32-1
And this is the last output in the log file:
x86_64-w64-mingw32-g++ -O2 -g -pipe -I/c/Users/Robin/Documents/RTEMS/rtems-demo/toolchain/src/rsb/rtems/build/tmp/sb-197609/5s/c/Users/Robin/Documents/RTEMS/rtems-demo/toolchain/rtems/5/include -I../../gcc-7.5.0/libcpp -I. -I../../gcc-7.5.0/libcpp/../include -I../../gcc-7.5.0/libcpp/include -g -O2 -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -fno-exceptions -fno-rtti -I../../gcc-7.5.0/libcpp -I. -I../../gcc-7.5.0/libcpp/../include -I../../gcc-7.5.0/libcpp/include -c -o init.o -MT init.o -MMD -MP -MF .deps/init.Tpo ../../gcc-7.5.0/libcpp/init.c
rm -f libcpp.a
ar cru libcpp.a charset.o directives.o directives-only.o errors.o expr.o files.o identifiers.o init.o lex.o line-map.o macro.o mkdeps.o pch.o symtab.o traditional.o
ranlib libcpp.a
make[2]: Leaving directory ‘/c/Users/Robin/Documents/RTEMS/rtems-demo/toolchain/src/rsb/rtems/build/srg7n7xwm1/build/libcpp’
Kind Regards Robin
Author: Trac Migrate
2020-12-03T17:07:13.000Z
Original author: rmueller
I built with the git clone of the RTEMS Source builder. This happens for master as well as branch RTEMS version 5. The build command for RTEMS5:
../source-builder/sb-set-builder –prefix=$RTEMS_INST 5/rtems-sparc
and for RTEMS6:
../source-builder/sb-set-builder –prefix=$RTEMS_INST 6/rtems-sparc
Author: Chris Johns
2025-09-19T01:41:58.754Z
changed the description
Author: Chris Johns
2026-07-30T23:28:14.977Z
set status to Obsolete
4183 - MinGW64 RSB build fails with encoding error¶
Id |
4183 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2020-11-22T16:39:59.000Z |
Closed |
2026-07-30T23:24:29.779Z |
Updated |
2026-07-30T23:24:29.854Z |
Milestone |
6.3 |
Labels |
priority::normal, tickettype::defect, version::6 |
Link |
|
Merges |
0 |
Original author: rmueller
Hi,
I followed the quick start guide to install the RSB ([https://docs.rtems.org/branches/master/user/start/tools.html]) and encountered following error:
$ ../source-builder/sb-set-builder --prefix=/c/Users/Robin/Documents/RTEMS/quick-start/rtems/5 5/rtems-sparc
RTEMS Source Builder - Set Builder, 5.1
Build Set: 5/rtems-sparc
Build Set: Time 0:00:00.009008
Traceback (most recent call last):
File "../source-builder/sb/cmd-set-builder.py", line 26, in <module>
setbuilder.run()
File "../source-builder/sb/setbuilder.py", line 736, in run
b.build(deps, mail = mail)
File "../source-builder/sb/setbuilder.py", line 452, in build
bs.build(deps, nesting_count, mail)
File "../source-builder/sb/setbuilder.py", line 390, in build
log.notice('Build Set: %s' % (self.bset))
File "../source-builder/sb/log.py", line 88, in notice
print(l)
LookupError: unknown encoding: cp65001
I solved this by typing in the command line:
export PYTHONIOENCODING=UTF-8
I just though I report this, maybe it helps other people who have the same issue or maybe this is a problem related to more recent python installations.
Author: Trac Migrate
2020-11-22T16:41:49.000Z
Original author: rmueller
Summary changed from MinGW64 RSM build fails to MinGW64 RSB build fails with encoding error
Author: Trac Migrate
2020-12-02T10:53:34.000Z
Original author: rmueller
I submitted a patch which mentions this issue and how to fix it.
Author: Trac Migrate
2020-12-18T10:25:30.000Z
Original author: rmueller
Attachment python-quick-guide.patch added
Author: Trac Migrate
2020-12-18T10:26:31.000Z
Original author: rmueller
Version set to ~”6”
Author: Chris Johns
2025-09-19T01:41:58.240Z
changed the description
Author: Chris Johns
2026-07-30T23:24:29.818Z
set status to Won’t do
4091 - tester: BlockingIOError: [Errno 11] write could not complete without blocking¶
Id |
4091 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2020-09-23T07:54:16.000Z |
Closed |
2026-07-30T23:24:13.417Z |
Updated |
2026-07-30T23:24:13.475Z |
Milestone |
6.3 |
Labels |
old-indefinite, priority::normal, tickettype::defect, tool, version::6, version::7 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
The RTEMS Tester seems to have an issue with tests that produce a lot of output. This seems to be a sporadic error which depends also on the system load. For example (BSP: arm/realview_pbx_a9_qemu):
[628/628] p:602 f:5 u:6 e:0 I:0 B:3 t:0 L:0 i:0 W:0 | arm/realview_pbx_a9_qemu: ts-validation-0.exe
Result: failed Time: 0:00:02.515008 ts-validation-0.exe
=> exe: qemu-system-arm -no-reboot -nographic -net none -M realview-pbx-a9 -m 256M -kernel build/arm/realview_pbx_a9_qemu/testsuites/validation/ts-validation-0.exe
]
]
=> test start: Validation0
] *** BEGIN OF TEST Validation0 ***
] *** TEST VERSION: 6.0.0.2ac9a2de76966dc4501a5c098e265cd85a2d58b1
] *** TEST STATE: EXPECTED_PASS
] *** TEST BUILD: RTEMS_SMP
] *** TEST TOOLS: 10.2.1 20200918 (RTEMS 6, RSB 7595c3a42b388c26436f7a61d1c23f3cf437bb46, Newlib 749cbcc)
] A:Validation0
] S:Platform:RTEMS
] S:Compiler:10.2.1 20200918 (RTEMS 6, RSB 7595c3a42b388c26436f7a61d1c23f3cf437bb46, Newlib 749cbcc)
] S:Version:6.0.0.2ac9a2de76966dc4501a5c098e265cd85a2d58b1
] S:BSP:realview_pbx_a9_qemu
] S:RTEMS_DEBUG:0
] S:RTEMS_MULTIPROCESSING:0
] S:RTEMS_POSIX_API:0
] S:RTEMS_PROFILING:0
] S:RTEMS_SMP:1
] B:RtemsUserextValIdent
] P:0:0:RUN:tc-userext-ident.c:88
] P:1.0:0:RUN/Invalid/NullPtr:tr-object-ident-local.c:171
] P:1.1:0:RUN/Invalid/NullPtr:tr-object-ident-local.c:198
] P:1.2:0:RUN/Invalid/Valid:tr-object-ident-local.c:176
] P:1.3:0:RUN/Invalid/Valid:tr-object-ident-local.c:192
] P:1.4:0:RUN/Invalid/Valid:tr-object-ident-local.c:193
] P:1.5:0:RUN/Valid/NullPtr:tr-object-ident-local.c:171
] P:1.6:0:RUN/Valid/NullPtr:tr-object-ident-local.c:198
] P:1.7:0:RUN/Valid/Valid:tr-object-ident-local.c:166
] P:1.8:0:RUN/Valid/Valid:tr-object-ident-local.c:203
] P:1.9:0:RUN/Valid/Valid:tr-object-ident-local.c:204
] P:1:0:RUN:tc-userext-ident.c:96
] E:RtemsUserextValIdent:N:12:F:0:D:0.014274
] B:RtemsTimerValIdent
] P:0:0:RUN:tc-timer-ident.c:86
] P:1.0:0:RUN/Invalid/NullPtr:tr-object-ident-local.c:171
] P:1.1:0:RUN/Invalid/NullPtr:tr-object-ident-local.c:198
] P:1.2:0:RUN/Invalid/Valid:tr-object-ident-local.c:176
] P:1.3:0:RUN/Invalid/Valid:tr-object-ident-local.c:192
] P:1.4:0:RUN/Invalid/Valid:tr-object-ident-local.c:193
] P:1.5:0:RUN/Valid/NullPtr:tr-object-ident-local.c:171
] P:1.6:0:RUN/Valid/NullPtr:tr-object-ident-local.c:198
] P:1.7:0:RUN/Valid/Valid:tr-object-ident-local.c:166
] P:1.8:0:RUN/Valid/Valid:tr-object-ident-local.c:203
] P:1.9:0:RUN/Valid/Valid:tr-object-ident-local.c:204
] P:1:0:RUN:tc-timer-ident.c:94
] E:RtemsTimerValIdent:N:12:F:0:D:0.006552
] B:RtemsTaskReqIdent
] P:0:0:RUN:tc-task-ident.c:194
] P:1:0:RUN/Self:tc-task-ident.c:170
] P:2:0:RUN/Self:tc-task-ident.c:171
] P:3:0:RUN/Self:tc-task-ident.c:172
] P:4.0:0:RUN/Generic/Invalid/Local/NullPtr:tr-object-ident.c:227
] P:4.1:0:RUN/Generic/Invalid/Local/NullPtr:tr-object-ident.c:259
] P:4.2:0:RUN/Generic/Invalid/Local/Valid:tr-object-ident.c:232
] P:4.3:0:RUN/Generic/Invalid/Local/Valid:tr-object-ident.c:253
] P:4.4:0:RUN/Generic/Invalid/Local/Valid:tr-object-ident.c:254
] P:4.5:0:RUN/Generic/Invalid/Remote/NullPtr:tr-object-ident.c:227
] P:4.6:0:RUN/Generic/Invalid/Remote/NullPtr:tr-object-ident.c:259
] P:4.7:0:RUN/Generic/Invalid/Remote/Valid:tr-object-ident.c:232
] P:4.8:0:RUN/Generic/Invalid/Remote/Valid:tr-object-ident.c:253
] P:4.9:0:RUN/Generic/Invalid/Remote/Valid:tr-object-ident.c:254
] P:4.10:0:RUN/Generic/Invalid/Invalid/NullPtr:tr-object-ident.c:227
] P:4.11:0:RUN/Generic/Invalid/Invalid/NullPtr:tr-object-ident.c:259
] P:4.12:0:RUN/Generic/Invalid/Invalid/Valid:tr-object-ident.c:232
] P:4.13:0:RUN/Generic/Invalid/Invalid/Valid:tr-object-ident.c:253
] P:4.14:0:RUN/Generic/Invalid/Invalid/Valid:tr-object-ident.c:254
] P:4.15:0:RUN/Generic/Invalid/SearchAll/NullPtr:tr-object-ident.c:227
] P:4.16:0:RUN/Generic/Invalid/SearchAll/NullPtr:tr-object-ident.c:259
] P:4.17:0:RUN/Generic/Invalid/SearchAll/Valid:tr-object-ident.c:232
] P:4.18:0:RUN/Generic/Invalid/SearchAll/Valid:tr-object-ident.c:253
] P:4.19:0:RUN/Generic/Invalid/SearchAll/Valid:tr-object-ident.c:254
] P:4.20:0:RUN/Generic/Invalid/SearchOther/NullPtr:tr-object-ident.c:227
] P:4.21:0:RUN/Generic/Invalid/SearchOther/NullPtr:tr-object-ident.c:259
] P:4.22:0:RUN/Generic/Invalid/SearchOther/Valid:tr-object-ident.c:232
] P:4.23:0:RUN/Generic/Invalid/SearchOther/Valid:tr-object-ident.c:253
] P:4.24:0:RUN/Generic/Invalid/SearchOther/Valid:tr-object-ident.c:254
] P:4.25:0:RUN/Generic/Invalid/SearchLocal/NullPtr:tr-object-ident.c:227
] P:4.26:0:RUN/Generic/Invalid/SearchLocal/NullPtr:tr-object-ident.c:259
] P:4.27:0:RUN/Generic/Invalid/SearchLocal/Valid:tr-object-ident.c:232
] P:4.28:0:RUN/Generic/Invalid/SearchLocal/Valid:tr-object-ident.c:253
] P:4.29:0:RUN/Generic/Invalid/SearchLocal/Valid:tr-object-ident.c:254
] P:4.30:0:RUN/Generic/Valid/Local/NullPtr:tr-object-ident.c:227
] P:4.31:0:RUN/Generic/Valid/Local/NullPtr:tr-object-ident.c:259
] P:4.32:0:RUN/Generic/Valid/Local/Valid:tr-object-ident.c:222
] P:4.33:0:RUN/Generic/Valid/Local/Valid:tr-object-ident.c:264
] P:4.34:0:RUN/Generic/Valid/Local/Valid:tr-object-ident.c:265
] P:4.35:0:RUN/Generic/Valid/Remote/NullPtr:tr-object-ident.c:227
] P:4.36:0:RUN/Generic/Valid/Remote/NullPtr:tr-object-ident.c:259
] P:4.37:0:RUN/Generic/Valid/Remote/Valid:tr-object-ident.c:232
] P:4.38:0:RUN/Generic/Valid/Remote/Valid:tr-object-ident.c:253
] P:4.39:0:RUN/Generic/Valid/Remote/Valid:tr-object-ident.c:254
] P:4.40:0:RUN/Generic/Valid/Invalid/NullPtr:tr-object-ident.c:227
] P:4.41:0:RUN/Generic/Valid/Invalid/NullPtr:tr-object-ident.c:259
] P:4.42:0:RUN/Generic/Valid/Invalid/Valid:tr-object-ident.c:232
] P:4.43:0:RUN/Generic/Valid/Invalid/Valid:tr-object-ident.c:253
] P:4.44:0:RUN/Generic/Valid/Invalid/Valid:tr-object-ident.c:254
] P:4.45:0:RUN/Generic/Valid/SearchAll/NullPtr:tr-object-ident.c:227
] P:4.46:0:RUN/Generic/Valid/SearchAll/NullPtr:tr-object-ident.c:259
] P:4.47:0:RUN/Generic/Valid/SearchAll/Valid:tr-object-ident.c:222
] P:4.48:0:RUN/Generic/Valid/SearchAll/Valid:tr-object-ident.c:264
] P:4.49:0:RUN/Generic/Valid/SearchAll/Valid:tr-object-ident.c:265
] P:4.50:0:RUN/Generic/Valid/SearchOther/NullPtr:tr-object-ident.c:227
] P:4.51:0:RUN/Generic/Valid/SearchOther/NullPtr:tr-object-ident.c:259
] P:4.52:0:RUN/Generic/Valid/SearchOther/Valid:tr-object-ident.c:232
] P:4.53:0:RUN/Generic/Valid/SearchOther/Valid:tr-object-ident.c:253
] P:4.54:0:RUN/Generic/Valid/SearchOther/Valid:tr-object-ident.c:254
] P:4.55:0:RUN/Generic/Valid/SearchLocal/NullPtr:tr-object-ident.c:227
] P:4.56:0:RUN/Generic/Valid/SearchLocal/NullPtr:tr-object-ident.c:259
] P:4.57:0:RUN/Generic/Valid/SearchLocal/Valid:tr-object-ident.c:222
] P:4.58:0:RUN/Generic/Valid/SearchLocal/Valid:tr-object-ident.c:264
] P:4.59:0:RUN/Generic/Valid/SearchLocal/Valid:tr-object-ident.c:265
] P:4:0:RUN:tc-task-ident.c:212
] E:RtemsTaskReqIdent:N:65:F:0:D:0.045622
] B:RtemsTaskReqConstructErrors
] P:0:0:RUN:tc-task-construct-errors.c:529
] P:1:0:RUN/Id/Valid/Valid/Avail/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:462
] P:2:0:RUN/Id/Valid/Valid/Avail/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:463
] P:3:0:RUN/Id/Valid/Valid/Avail/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:464
] P:4:0:RUN/Id/Valid/Valid/Avail/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:467
] P:5:0:RUN/Id/Valid/Valid/Avail/Enough/Enough/Ok/No:tc-task-construct-errors.c:503
] P:6:0:RUN/Id/Valid/Valid/Avail/Enough/Enough/Ok/No:tc-task-construct-errors.c:504
] P:7:0:RUN/Id/Valid/Valid/Avail/Enough/Enough/Err/Yes:tc-task-construct-errors.c:503
] P:8:0:RUN/Id/Valid/Valid/Avail/Enough/Enough/Err/Yes:tc-task-construct-errors.c:504
] P:9:0:RUN/Id/Valid/Valid/Avail/Enough/Enough/Err/No:tc-task-construct-errors.c:503
] P:10:0:RUN/Id/Valid/Valid/Avail/Enough/Enough/Err/No:tc-task-construct-errors.c:504
] P:11:0:RUN/Id/Valid/Valid/Avail/Enough/Small/Ok/Yes:tc-task-construct-errors.c:491
] P:12:0:RUN/Id/Valid/Valid/Avail/Enough/Small/Ok/Yes:tc-task-construct-errors.c:492
] P:13:0:RUN/Id/Valid/Valid/Avail/Enough/Small/Ok/No:tc-task-construct-errors.c:491
] P:14:0:RUN/Id/Valid/Valid/Avail/Enough/Small/Ok/No:tc-task-construct-errors.c:492
] P:15:0:RUN/Id/Valid/Valid/Avail/Enough/Small/Err/Yes:tc-task-construct-errors.c:491
] P:16:0:RUN/Id/Valid/Valid/Avail/Enough/Small/Err/Yes:tc-task-construct-errors.c:492
] P:17:0:RUN/Id/Valid/Valid/Avail/Enough/Small/Err/No:tc-task-construct-errors.c:491
] P:18:0:RUN/Id/Valid/Valid/Avail/Enough/Small/Err/No:tc-task-construct-errors.c:492
] P:19:0:RUN/Id/Valid/Valid/Avail/Small/Enough/Ok/Yes:tc-task-construct-errors.c:491
] P:20:0:RUN/Id/Valid/Valid/Avail/Small/Enough/Ok/Yes:tc-task-construct-errors.c:492
] P:21:0:RUN/Id/Valid/Valid/Avail/Small/Enough/Ok/No:tc-task-construct-errors.c:491
] P:22:0:RUN/Id/Valid/Valid/Avail/Small/Enough/Ok/No:tc-task-construct-errors.c:492
] P:23:0:RUN/Id/Valid/Valid/Avail/Small/Enough/Err/Yes:tc-task-construct-errors.c:491
] P:24:0:RUN/Id/Valid/Valid/Avail/Small/Enough/Err/Yes:tc-task-construct-errors.c:492
] P:25:0:RUN/Id/Valid/Valid/Avail/Small/Enough/Err/No:tc-task-construct-errors.c:491
] P:26:0:RUN/Id/Valid/Valid/Avail/Small/Enough/Err/No:tc-task-construct-errors.c:492
] P:27:0:RUN/Id/Valid/Valid/Avail/Small/Small/Ok/Yes:tc-task-construct-errors.c:491
] P:28:0:RUN/Id/Valid/Valid/Avail/Small/Small/Ok/Yes:tc-task-construct-errors.c:492
] P:29:0:RUN/Id/Valid/Valid/Avail/Small/Small/Ok/No:tc-task-construct-errors.c:491
] P:30:0:RUN/Id/Valid/Valid/Avail/Small/Small/Ok/No:tc-task-construct-errors.c:492
] P:31:0:RUN/Id/Valid/Valid/Avail/Small/Small/Err/Yes:tc-task-construct-errors.c:491
] P:32:0:RUN/Id/Valid/Valid/Avail/Small/Small/Err/Yes:tc-task-construct-errors.c:492
] P:33:0:RUN/Id/Valid/Valid/Avail/Small/Small/Err/No:tc-task-construct-errors.c:491
] P:34:0:RUN/Id/Valid/Valid/Avail/Small/Small/Err/No:tc-task-construct-errors.c:492
] P:35:0:RUN/Id/Valid/Valid/None/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:497
] P:36:0:RUN/Id/Valid/Valid/None/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:498
] P:37:0:RUN/Id/Valid/Valid/None/Enough/Enough/Ok/No:tc-task-construct-errors.c:497
] P:38:0:RUN/Id/Valid/Valid/None/Enough/Enough/Ok/No:tc-task-construct-errors.c:498
] P:39:0:RUN/Id/Valid/Valid/None/Enough/Enough/Err/Yes:tc-task-construct-errors.c:497
] P:40:0:RUN/Id/Valid/Valid/None/Enough/Enough/Err/Yes:tc-task-construct-errors.c:498
] P:41:0:RUN/Id/Valid/Valid/None/Enough/Enough/Err/No:tc-task-construct-errors.c:497
] P:42:0:RUN/Id/Valid/Valid/None/Enough/Enough/Err/No:tc-task-construct-errors.c:498
] P:43:0:RUN/Id/Valid/Valid/None/Enough/Small/Ok/Yes:tc-task-construct-errors.c:497
] P:44:0:RUN/Id/Valid/Valid/None/Enough/Small/Ok/Yes:tc-task-construct-errors.c:498
] P:45:0:RUN/Id/Valid/Valid/None/Enough/Small/Ok/No:tc-task-construct-errors.c:497
] P:46:0:RUN/Id/Valid/Valid/None/Enough/Small/Ok/No:tc-task-construct-errors.c:498
] P:47:0:RUN/Id/Valid/Valid/None/Enough/Small/Err/Yes:tc-task-construct-errors.c:497
] P:48:0:RUN/Id/Valid/Valid/None/Enough/Small/Err/Yes:tc-task-construct-errors.c:498
] P:49:0:RUN/Id/Valid/Valid/None/Enough/Small/Err/No:tc-task-construct-errors.c:497
] P:50:0:RUN/Id/Valid/Valid/None/Enough/Small/Err/No:tc-task-construct-errors.c:498
] P:51:0:RUN/Id/Valid/Valid/None/Small/Enough/Ok/Yes:tc-task-construct-errors.c:497
] P:52:0:RUN/Id/Valid/Valid/None/Small/Enough/Ok/Yes:tc-task-construct-errors.c:498
] P:53:0:RUN/Id/Valid/Valid/None/Small/Enough/Ok/No:tc-task-construct-errors.c:497
] P:54:0:RUN/Id/Valid/Valid/None/Small/Enough/Ok/No:tc-task-construct-errors.c:498
] P:55:0:RUN/Id/Valid/Valid/None/Small/Enough/Err/Yes:tc-task-construct-errors.c:497
] P:56:0:RUN/Id/Valid/Valid/None/Small/Enough/Err/Yes:tc-task-construct-errors.c:498
] P:57:0:RUN/Id/Valid/Valid/None/Small/Enough/Err/No:tc-task-construct-errors.c:497
] P:58:0:RUN/Id/Valid/Valid/None/Small/Enough/Err/No:tc-task-construct-errors.c:498
] P:59:0:RUN/Id/Valid/Valid/None/Small/Small/Ok/Yes:tc-task-construct-errors.c:497
] P:60:0:RUN/Id/Valid/Valid/None/Small/Small/Ok/Yes:tc-task-construct-errors.c:498
] P:61:0:RUN/Id/Valid/Valid/None/Small/Small/Ok/No:tc-task-construct-errors.c:497
] P:62:0:RUN/Id/Valid/Valid/None/Small/Small/Ok/No:tc-task-construct-errors.c:498
] P:63:0:RUN/Id/Valid/Valid/None/Small/Small/Err/Yes:tc-task-construct-errors.c:497
] P:64:0:RUN/Id/Valid/Valid/None/Small/Small/Err/Yes:tc-task-construct-errors.c:498
] P:65:0:RUN/Id/Valid/Valid/None/Small/Small/Err/No:tc-task-construct-errors.c:497
] P:66:0:RUN/Id/Valid/Valid/None/Small/Small/Err/No:tc-task-construct-errors.c:498
] P:67:0:RUN/Id/Valid/Zero/Avail/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:485
] P:68:0:RUN/Id/Valid/Zero/Avail/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:486
] P:69:0:RUN/Id/Valid/Zero/Avail/Enough/Enough/Ok/No:tc-task-construct-errors.c:485
] P:70:0:RUN/Id/Valid/Zero/Avail/Enough/Enough/Ok/No:tc-task-construct-errors.c:486
] P:71:0:RUN/Id/Valid/Zero/Avail/Enough/Enough/Err/Yes:tc-task-construct-errors.c:485
] P:72:0:RUN/Id/Valid/Zero/Avail/Enough/Enough/Err/Yes:tc-task-construct-errors.c:486
] P:73:0:RUN/Id/Valid/Zero/Avail/Enough/Enough/Err/No:tc-task-construct-errors.c:485
] P:74:0:RUN/Id/Valid/Zero/Avail/Enough/Enough/Err/No:tc-task-construct-errors.c:486
] P:75:0:RUN/Id/Valid/Zero/Avail/Enough/Small/Ok/Yes:tc-task-construct-errors.c:485
] P:76:0:RUN/Id/Valid/Zero/Avail/Enough/Small/Ok/Yes:tc-task-construct-errors.c:486
] P:77:0:RUN/Id/Valid/Zero/Avail/Enough/Small/Ok/No:tc-task-construct-errors.c:485
] P:78:0:RUN/Id/Valid/Zero/Avail/Enough/Small/Ok/No:tc-task-construct-errors.c:486
] P:79:0:RUN/Id/Valid/Zero/Avail/Enough/Small/Err/Yes:tc-task-construct-errors.c:485
] P:80:0:RUN/Id/Valid/Zero/Avail/Enough/Small/Err/Yes:tc-task-construct-errors.c:486
] P:81:0:RUN/Id/Valid/Zero/Avail/Enough/Small/Err/No:tc-task-construct-errors.c:485
] P:82:0:RUN/Id/Valid/Zero/Avail/Enough/Small/Err/No:tc-task-construct-errors.c:486
] P:83:0:RUN/Id/Valid/Zero/Avail/Small/Enough/Ok/Yes:tc-task-construct-errors.c:485
] P:84:0:RUN/Id/Valid/Zero/Avail/Small/Enough/Ok/Yes:tc-task-construct-errors.c:486
] P:85:0:RUN/Id/Valid/Zero/Avail/Small/Enough/Ok/No:tc-task-construct-errors.c:485
] P:86:0:RUN/Id/Valid/Zero/Avail/Small/Enough/Ok/No:tc-task-construct-errors.c:486
] P:87:0:RUN/Id/Valid/Zero/Avail/Small/Enough/Err/Yes:tc-task-construct-errors.c:485
] P:88:0:RUN/Id/Valid/Zero/Avail/Small/Enough/Err/Yes:tc-task-construct-errors.c:486
] P:89:0:RUN/Id/Valid/Zero/Avail/Small/Enough/Err/No:tc-task-construct-errors.c:485
] P:90:0:RUN/Id/Valid/Zero/Avail/Small/Enough/Err/No:tc-task-construct-errors.c:486
] P:91:0:RUN/Id/Valid/Zero/Avail/Small/Small/Ok/Yes:tc-task-construct-errors.c:485
] P:92:0:RUN/Id/Valid/Zero/Avail/Small/Small/Ok/Yes:tc-task-construct-errors.c:486
] P:93:0:RUN/Id/Valid/Zero/Avail/Small/Small/Ok/No:tc-task-construct-errors.c:485
] P:94:0:RUN/Id/Valid/Zero/Avail/Small/Small/Ok/No:tc-task-construct-errors.c:486
] P:95:0:RUN/Id/Valid/Zero/Avail/Small/Small/Err/Yes:tc-task-construct-errors.c:485
] P:96:0:RUN/Id/Valid/Zero/Avail/Small/Small/Err/Yes:tc-task-construct-errors.c:486
] P:97:0:RUN/Id/Valid/Zero/Avail/Small/Small/Err/No:tc-task-construct-errors.c:485
] P:98:0:RUN/Id/Valid/Zero/Avail/Small/Small/Err/No:tc-task-construct-errors.c:486
] P:99:0:RUN/Id/Valid/Zero/None/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:485
] P:100:0:RUN/Id/Valid/Zero/None/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:486
] P:101:0:RUN/Id/Valid/Zero/None/Enough/Enough/Ok/No:tc-task-construct-errors.c:485
] P:102:0:RUN/Id/Valid/Zero/None/Enough/Enough/Ok/No:tc-task-construct-errors.c:486
] P:103:0:RUN/Id/Valid/Zero/None/Enough/Enough/Err/Yes:tc-task-construct-errors.c:485
] P:104:0:RUN/Id/Valid/Zero/None/Enough/Enough/Err/Yes:tc-task-construct-errors.c:486
] P:105:0:RUN/Id/Valid/Zero/None/Enough/Enough/Err/No:tc-task-construct-errors.c:485
] P:106:0:RUN/Id/Valid/Zero/None/Enough/Enough/Err/No:tc-task-construct-errors.c:486
] P:107:0:RUN/Id/Valid/Zero/None/Enough/Small/Ok/Yes:tc-task-construct-errors.c:485
] P:108:0:RUN/Id/Valid/Zero/None/Enough/Small/Ok/Yes:tc-task-construct-errors.c:486
] P:109:0:RUN/Id/Valid/Zero/None/Enough/Small/Ok/No:tc-task-construct-errors.c:485
] P:110:0:RUN/Id/Valid/Zero/None/Enough/Small/Ok/No:tc-task-construct-errors.c:486
] P:111:0:RUN/Id/Valid/Zero/None/Enough/Small/Err/Yes:tc-task-construct-errors.c:485
] P:112:0:RUN/Id/Valid/Zero/None/Enough/Small/Err/Yes:tc-task-construct-errors.c:486
] P:113:0:RUN/Id/Valid/Zero/None/Enough/Small/Err/No:tc-task-construct-errors.c:485
] P:114:0:RUN/Id/Valid/Zero/None/Enough/Small/Err/No:tc-task-construct-errors.c:486
] P:115:0:RUN/Id/Valid/Zero/None/Small/Enough/Ok/Yes:tc-task-construct-errors.c:485
] P:116:0:RUN/Id/Valid/Zero/None/Small/Enough/Ok/Yes:tc-task-construct-errors.c:486
] P:117:0:RUN/Id/Valid/Zero/None/Small/Enough/Ok/No:tc-task-construct-errors.c:485
] P:118:0:RUN/Id/Valid/Zero/None/Small/Enough/Ok/No:tc-task-construct-errors.c:486
] P:119:0:RUN/Id/Valid/Zero/None/Small/Enough/Err/Yes:tc-task-construct-errors.c:485
] P:120:0:RUN/Id/Valid/Zero/None/Small/Enough/Err/Yes:tc-task-construct-errors.c:486
] P:121:0:RUN/Id/Valid/Zero/None/Small/Enough/Err/No:tc-task-construct-errors.c:485
] P:122:0:RUN/Id/Valid/Zero/None/Small/Enough/Err/No:tc-task-construct-errors.c:486
] P:123:0:RUN/Id/Valid/Zero/None/Small/Small/Ok/Yes:tc-task-construct-errors.c:485
] P:124:0:RUN/Id/Valid/Zero/None/Small/Small/Ok/Yes:tc-task-construct-errors.c:486
] P:125:0:RUN/Id/Valid/Zero/None/Small/Small/Ok/No:tc-task-construct-errors.c:485
] P:126:0:RUN/Id/Valid/Zero/None/Small/Small/Ok/No:tc-task-construct-errors.c:486
] P:127:0:RUN/Id/Valid/Zero/None/Small/Small/Err/Yes:tc-task-construct-errors.c:485
] P:128:0:RUN/Id/Valid/Zero/None/Small/Small/Err/Yes:tc-task-construct-errors.c:486
] P:129:0:RUN/Id/Valid/Zero/None/Small/Small/Err/No:tc-task-construct-errors.c:485
] P:130:0:RUN/Id/Valid/Zero/None/Small/Small/Err/No:tc-task-construct-errors.c:486
] P:131:0:RUN/Id/Valid/Inv/Avail/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:485
] P:132:0:RUN/Id/Valid/Inv/Avail/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:486
] P:133:0:RUN/Id/Valid/Inv/Avail/Enough/Enough/Ok/No:tc-task-construct-errors.c:485
] P:134:0:RUN/Id/Valid/Inv/Avail/Enough/Enough/Ok/No:tc-task-construct-errors.c:486
] P:135:0:RUN/Id/Valid/Inv/Avail/Enough/Enough/Err/Yes:tc-task-construct-errors.c:485
] P:136:0:RUN/Id/Valid/Inv/Avail/Enough/Enough/Err/Yes:tc-task-construct-errors.c:486
] P:137:0:RUN/Id/Valid/Inv/Avail/Enough/Enough/Err/No:tc-task-construct-errors.c:485
] P:138:0:RUN/Id/Valid/Inv/Avail/Enough/Enough/Err/No:tc-task-construct-errors.c:486
] P:139:0:RUN/Id/Valid/Inv/Avail/Enough/Small/Ok/Yes:tc-task-construct-errors.c:485
] P:140:0:RUN/Id/Valid/Inv/Avail/Enough/Small/Ok/Yes:tc-task-construct-errors.c:486
] P:141:0:RUN/Id/Valid/Inv/Avail/Enough/Small/Ok/No:tc-task-construct-errors.c:485
] P:142:0:RUN/Id/Valid/Inv/Avail/Enough/Small/Ok/No:tc-task-construct-errors.c:486
] P:143:0:RUN/Id/Valid/Inv/Avail/Enough/Small/Err/Yes:tc-task-construct-errors.c:485
] P:144:0:RUN/Id/Valid/Inv/Avail/Enough/Small/Err/Yes:tc-task-construct-errors.c:486
] P:145:0:RUN/Id/Valid/Inv/Avail/Enough/Small/Err/No:tc-task-construct-errors.c:485
] P:146:0:RUN/Id/Valid/Inv/Avail/Enough/Small/Err/No:tc-task-construct-errors.c:486
] P:147:0:RUN/Id/Valid/Inv/Avail/Small/Enough/Ok/Yes:tc-task-construct-errors.c:485
] P:148:0:RUN/Id/Valid/Inv/Avail/Small/Enough/Ok/Yes:tc-task-construct-errors.c:486
] P:149:0:RUN/Id/Valid/Inv/Avail/Small/Enough/Ok/No:tc-task-construct-errors.c:485
] P:150:0:RUN/Id/Valid/Inv/Avail/Small/Enough/Ok/No:tc-task-construct-errors.c:486
] P:151:0:RUN/Id/Valid/Inv/Avail/Small/Enough/Err/Yes:tc-task-construct-errors.c:485
] P:152:0:RUN/Id/Valid/Inv/Avail/Small/Enough/Err/Yes:tc-task-construct-errors.c:486
] P:153:0:RUN/Id/Valid/Inv/Avail/Small/Enough/Err/No:tc-task-construct-errors.c:485
] P:154:0:RUN/Id/Valid/Inv/Avail/Small/Enough/Err/No:tc-task-construct-errors.c:486
] P:155:0:RUN/Id/Valid/Inv/Avail/Small/Small/Ok/Yes:tc-task-construct-errors.c:485
] P:156:0:RUN/Id/Valid/Inv/Avail/Small/Small/Ok/Yes:tc-task-construct-errors.c:486
] P:157:0:RUN/Id/Valid/Inv/Avail/Small/Small/Ok/No:tc-task-construct-errors.c:485
] P:158:0:RUN/Id/Valid/Inv/Avail/Small/Small/Ok/No:tc-task-construct-errors.c:486
] P:159:0:RUN/Id/Valid/Inv/Avail/Small/Small/Err/Yes:tc-task-construct-errors.c:485
] P:160:0:RUN/Id/Valid/Inv/Avail/Small/Small/Err/Yes:tc-task-construct-errors.c:486
] P:161:0:RUN/Id/Valid/Inv/Avail/Small/Small/Err/No:tc-task-construct-errors.c:485
] P:162:0:RUN/Id/Valid/Inv/Avail/Small/Small/Err/No:tc-task-construct-errors.c:486
] P:163:0:RUN/Id/Valid/Inv/None/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:485
] P:164:0:RUN/Id/Valid/Inv/None/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:486
] P:165:0:RUN/Id/Valid/Inv/None/Enough/Enough/Ok/No:tc-task-construct-errors.c:485
] P:166:0:RUN/Id/Valid/Inv/None/Enough/Enough/Ok/No:tc-task-construct-errors.c:486
] P:167:0:RUN/Id/Valid/Inv/None/Enough/Enough/Err/Yes:tc-task-construct-errors.c:485
] P:168:0:RUN/Id/Valid/Inv/None/Enough/Enough/Err/Yes:tc-task-construct-errors.c:486
] P:169:0:RUN/Id/Valid/Inv/None/Enough/Enough/Err/No:tc-task-construct-errors.c:485
] P:170:0:RUN/Id/Valid/Inv/None/Enough/Enough/Err/No:tc-task-construct-errors.c:486
] P:171:0:RUN/Id/Valid/Inv/None/Enough/Small/Ok/Yes:tc-task-construct-errors.c:485
] P:172:0:RUN/Id/Valid/Inv/None/Enough/Small/Ok/Yes:tc-task-construct-errors.c:486
] P:173:0:RUN/Id/Valid/Inv/None/Enough/Small/Ok/No:tc-task-construct-errors.c:485
] P:174:0:RUN/Id/Valid/Inv/None/Enough/Small/Ok/No:tc-task-construct-errors.c:486
] P:175:0:RUN/Id/Valid/Inv/None/Enough/Small/Err/Yes:tc-task-construct-errors.c:485
] P:176:0:RUN/Id/Valid/Inv/None/Enough/Small/Err/Yes:tc-task-construct-errors.c:486
] P:177:0:RUN/Id/Valid/Inv/None/Enough/Small/Err/No:tc-task-construct-errors.c:485
] P:178:0:RUN/Id/Valid/Inv/None/Enough/Small/Err/No:tc-task-construct-errors.c:486
] P:179:0:RUN/Id/Valid/Inv/None/Small/Enough/Ok/Yes:tc-task-construct-errors.c:485
] P:180:0:RUN/Id/Valid/Inv/None/Small/Enough/Ok/Yes:tc-task-construct-errors.c:486
] P:181:0:RUN/Id/Valid/Inv/None/Small/Enough/Ok/No:tc-task-construct-errors.c:485
] P:182:0:RUN/Id/Valid/Inv/None/Small/Enough/Ok/No:tc-task-construct-errors.c:486
] P:183:0:RUN/Id/Valid/Inv/None/Small/Enough/Err/Yes:tc-task-construct-errors.c:485
] P:184:0:RUN/Id/Valid/Inv/None/Small/Enough/Err/Yes:tc-task-construct-errors.c:486
] P:185:0:RUN/Id/Valid/Inv/None/Small/Enough/Err/No:tc-task-construct-errors.c:485
] P:186:0:RUN/Id/Valid/Inv/None/Small/Enough/Err/No:tc-task-construct-errors.c:486
] P:187:0:RUN/Id/Valid/Inv/None/Small/Small/Ok/Yes:tc-task-construct-errors.c:485
] P:188:0:RUN/Id/Valid/Inv/None/Small/Small/Ok/Yes:tc-task-construct-errors.c:486
] P:189:0:RUN/Id/Valid/Inv/None/Small/Small/Ok/No:tc-task-construct-errors.c:485
] P:190:0:RUN/Id/Valid/Inv/None/Small/Small/Ok/No:tc-task-construct-errors.c:486
] P:191:0:RUN/Id/Valid/Inv/None/Small/Small/Err/Yes:tc-task-construct-errors.c:485
] P:192:0:RUN/Id/Valid/Inv/None/Small/Small/Err/Yes:tc-task-construct-errors.c:486
] P:193:0:RUN/Id/Valid/Inv/None/Small/Small/Err/No:tc-task-construct-errors.c:485
] P:194:0:RUN/Id/Valid/Inv/None/Small/Small/Err/No:tc-task-construct-errors.c:486
] P:195:0:RUN/Id/Inv/Valid/Avail/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:479
] P:196:0:RUN/Id/Inv/Valid/Avail/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:480
] P:197:0:RUN/Id/Inv/Valid/Avail/Enough/Enough/Ok/No:tc-task-construct-errors.c:479
] P:198:0:RUN/Id/Inv/Valid/Avail/Enough/Enough/Ok/No:tc-task-construct-errors.c:480
] P:199:0:RUN/Id/Inv/Valid/Avail/Enough/Enough/Err/Yes:tc-task-construct-errors.c:479
] P:200:0:RUN/Id/Inv/Valid/Avail/Enough/Enough/Err/Yes:tc-task-construct-errors.c:480
] P:201:0:RUN/Id/Inv/Valid/Avail/Enough/Enough/Err/No:tc-task-construct-errors.c:479
] P:202:0:RUN/Id/Inv/Valid/Avail/Enough/Enough/Err/No:tc-task-construct-errors.c:480
] P:203:0:RUN/Id/Inv/Valid/Avail/Enough/Small/Ok/Yes:tc-task-construct-errors.c:479
] P:204:0:RUN/Id/Inv/Valid/Avail/Enough/Small/Ok/Yes:tc-task-construct-errors.c:480
] P:205:0:RUN/Id/Inv/Valid/Avail/Enough/Small/Ok/No:tc-task-construct-errors.c:479
] P:206:0:RUN/Id/Inv/Valid/Avail/Enough/Small/Ok/No:tc-task-construct-errors.c:480
] P:207:0:RUN/Id/Inv/Valid/Avail/Enough/Small/Err/Yes:tc-task-construct-errors.c:479
] P:208:0:RUN/Id/Inv/Valid/Avail/Enough/Small/Err/Yes:tc-task-construct-errors.c:480
] P:209:0:RUN/Id/Inv/Valid/Avail/Enough/Small/Err/No:tc-task-construct-errors.c:479
] P:210:0:RUN/Id/Inv/Valid/Avail/Enough/Small/Err/No:tc-task-construct-errors.c:480
] P:211:0:RUN/Id/Inv/Valid/Avail/Small/Enough/Ok/Yes:tc-task-construct-errors.c:479
] P:212:0:RUN/Id/Inv/Valid/Avail/Small/Enough/Ok/Yes:tc-task-construct-errors.c:480
] P:213:0:RUN/Id/Inv/Valid/Avail/Small/Enough/Ok/No:tc-task-construct-errors.c:479
] P:214:0:RUN/Id/Inv/Valid/Avail/Small/Enough/Ok/No:tc-task-construct-errors.c:480
] P:215:0:RUN/Id/Inv/Valid/Avail/Small/Enough/Err/Yes:tc-task-construct-errors.c:479
] P:216:0:RUN/Id/Inv/Valid/Avail/Small/Enough/Err/Yes:tc-task-construct-errors.c:480
] P:217:0:RUN/Id/Inv/Valid/Avail/Small/Enough/Err/No:tc-task-construct-errors.c:479
] P:218:0:RUN/Id/Inv/Valid/Avail/Small/Enough/Err/No:tc-task-construct-errors.c:480
] P:219:0:RUN/Id/Inv/Valid/Avail/Small/Small/Ok/Yes:tc-task-construct-errors.c:479
] P:220:0:RUN/Id/Inv/Valid/Avail/Small/Small/Ok/Yes:tc-task-construct-errors.c:480
] P:221:0:RUN/Id/Inv/Valid/Avail/Small/Small/Ok/No:tc-task-construct-errors.c:479
] P:222:0:RUN/Id/Inv/Valid/Avail/Small/Small/Ok/No:tc-task-construct-errors.c:480
] P:223:0:RUN/Id/Inv/Valid/Avail/Small/Small/Err/Yes:tc-task-construct-errors.c:479
] P:224:0:RUN/Id/Inv/Valid/Avail/Small/Small/Err/Yes:tc-task-construct-errors.c:480
] P:225:0:RUN/Id/Inv/Valid/Avail/Small/Small/Err/No:tc-task-construct-errors.c:479
] P:226:0:RUN/Id/Inv/Valid/Avail/Small/Small/Err/No:tc-task-construct-errors.c:480
] P:227:0:RUN/Id/Inv/Valid/None/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:479
] P:228:0:RUN/Id/Inv/Valid/None/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:480
] P:229:0:RUN/Id/Inv/Valid/None/Enough/Enough/Ok/No:tc-task-construct-errors.c:479
] P:230:0:RUN/Id/Inv/Valid/None/Enough/Enough/Ok/No:tc-task-construct-errors.c:480
] P:231:0:RUN/Id/Inv/Valid/None/Enough/Enough/Err/Yes:tc-task-construct-errors.c:479
] P:232:0:RUN/Id/Inv/Valid/None/Enough/Enough/Err/Yes:tc-task-construct-errors.c:480
] P:233:0:RUN/Id/Inv/Valid/None/Enough/Enough/Err/No:tc-task-construct-errors.c:479
] P:234:0:RUN/Id/Inv/Valid/None/Enough/Enough/Err/No:tc-task-construct-errors.c:480
] P:235:0:RUN/Id/Inv/Valid/None/Enough/Small/Ok/Yes:tc-task-construct-errors.c:479
] P:236:0:RUN/Id/Inv/Valid/None/Enough/Small/Ok/Yes:tc-task-construct-errors.c:480
] P:237:0:RUN/Id/Inv/Valid/None/Enough/Small/Ok/No:tc-task-construct-errors.c:479
] P:238:0:RUN/Id/Inv/Valid/None/Enough/Small/Ok/No:tc-task-construct-errors.c:480
] P:239:0:RUN/Id/Inv/Valid/None/Enough/Small/Err/Yes:tc-task-construct-errors.c:479
] P:240:0:RUN/Id/Inv/Valid/None/Enough/Small/Err/Yes:tc-task-construct-errors.c:480
] P:241:0:RUN/Id/Inv/Valid/None/Enough/Small/Err/No:tc-task-construct-errors.c:479
] P:242:0:RUN/Id/Inv/Valid/None/Enough/Small/Err/No:tc-task-construct-errors.c:480
] P:243:0:RUN/Id/Inv/Valid/None/Small/Enough/Ok/Yes:tc-task-construct-errors.c:479
] P:244:0:RUN/Id/Inv/Valid/None/Small/Enough/Ok/Yes:tc-task-construct-errors.c:480
] P:245:0:RUN/Id/Inv/Valid/None/Small/Enough/Ok/No:tc-task-construct-errors.c:479
] P:246:0:RUN/Id/Inv/Valid/None/Small/Enough/Ok/No:tc-task-construct-errors.c:480
] P:247:0:RUN/Id/Inv/Valid/None/Small/Enough/Err/Yes:tc-task-construct-errors.c:479
] P:248:0:RUN/Id/Inv/Valid/None/Small/Enough/Err/Yes:tc-task-construct-errors.c:480
] P:249:0:RUN/Id/Inv/Valid/None/Small/Enough/Err/No:tc-task-construct-errors.c:479
] P:250:0:RUN/Id/Inv/Valid/None/Small/Enough/Err/No:tc-task-construct-errors.c:480
] P:251:0:RUN/Id/Inv/Valid/None/Small/Small/Ok/Yes:tc-task-construct-errors.c:479
] P:252:0:RUN/Id/Inv/Valid/None/Small/Small/Ok/Yes:tc-task-construct-errors.c:480
] P:253:0:RUN/Id/Inv/Valid/None/Small/Small/Ok/No:tc-task-construct-errors.c:479
] P:254:0:RUN/Id/Inv/Valid/None/Small/Small/Ok/No:tc-task-construct-errors.c:480
] P:255:0:RUN/Id/Inv/Valid/None/Small/Small/Err/Yes:tc-task-construct-errors.c:479
] P:256:0:RUN/Id/Inv/Valid/None/Small/Small/Err/Yes:tc-task-construct-errors.c:480
] P:257:0:RUN/Id/Inv/Valid/None/Small/Small/Err/No:tc-task-construct-errors.c:479
] P:258:0:RUN/Id/Inv/Valid/None/Small/Small/Err/No:tc-task-construct-errors.c:480
] P:259:0:RUN/Id/Inv/Zero/Avail/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:479
] P:260:0:RUN/Id/Inv/Zero/Avail/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:480
] P:261:0:RUN/Id/Inv/Zero/Avail/Enough/Enough/Ok/No:tc-task-construct-errors.c:479
] P:262:0:RUN/Id/Inv/Zero/Avail/Enough/Enough/Ok/No:tc-task-construct-errors.c:480
] P:263:0:RUN/Id/Inv/Zero/Avail/Enough/Enough/Err/Yes:tc-task-construct-errors.c:479
] P:264:0:RUN/Id/Inv/Zero/Avail/Enough/Enough/Err/Yes:tc-task-construct-errors.c:480
] P:265:0:RUN/Id/Inv/Zero/Avail/Enough/Enough/Err/No:tc-task-construct-errors.c:479
] P:266:0:RUN/Id/Inv/Zero/Avail/Enough/Enough/Err/No:tc-task-construct-errors.c:480
] P:267:0:RUN/Id/Inv/Zero/Avail/Enough/Small/Ok/Yes:tc-task-construct-errors.c:479
] P:268:0:RUN/Id/Inv/Zero/Avail/Enough/Small/Ok/Yes:tc-task-construct-errors.c:480
] P:269:0:RUN/Id/Inv/Zero/Avail/Enough/Small/Ok/No:tc-task-construct-errors.c:479
] P:270:0:RUN/Id/Inv/Zero/Avail/Enough/Small/Ok/No:tc-task-construct-errors.c:480
] P:271:0:RUN/Id/Inv/Zero/Avail/Enough/Small/Err/Yes:tc-task-construct-errors.c:479
] P:272:0:RUN/Id/Inv/Zero/Avail/Enough/Small/Err/Yes:tc-task-construct-errors.c:480
] P:273:0:RUN/Id/Inv/Zero/Avail/Enough/Small/Err/No:tc-task-construct-errors.c:479
] P:274:0:RUN/Id/Inv/Zero/Avail/Enough/Small/Err/No:tc-task-construct-errors.c:480
] P:275:0:RUN/Id/Inv/Zero/Avail/Small/Enough/Ok/Yes:tc-task-construct-errors.c:479
] P:276:0:RUN/Id/Inv/Zero/Avail/Small/Enough/Ok/Yes:tc-task-construct-errors.c:480
] P:277:0:RUN/Id/Inv/Zero/Avail/Small/Enough/Ok/No:tc-task-construct-errors.c:479
] P:278:0:RUN/Id/Inv/Zero/Avail/Small/Enough/Ok/No:tc-task-construct-errors.c:480
] P:279:0:RUN/Id/Inv/Zero/Avail/Small/Enough/Err/Yes:tc-task-construct-errors.c:479
] P:280:0:RUN/Id/Inv/Zero/Avail/Small/Enough/Err/Yes:tc-task-construct-errors.c:480
] P:281:0:RUN/Id/Inv/Zero/Avail/Small/Enough/Err/No:tc-task-construct-errors.c:479
] P:282:0:RUN/Id/Inv/Zero/Avail/Small/Enough/Err/No:tc-task-construct-errors.c:480
] P:283:0:RUN/Id/Inv/Zero/Avail/Small/Small/Ok/Yes:tc-task-construct-errors.c:479
] P:284:0:RUN/Id/Inv/Zero/Avail/Small/Small/Ok/Yes:tc-task-construct-errors.c:480
] P:285:0:RUN/Id/Inv/Zero/Avail/Small/Small/Ok/No:tc-task-construct-errors.c:479
] P:286:0:RUN/Id/Inv/Zero/Avail/Small/Small/Ok/No:tc-task-construct-errors.c:480
] P:287:0:RUN/Id/Inv/Zero/Avail/Small/Small/Err/Yes:tc-task-construct-errors.c:479
] P:288:0:RUN/Id/Inv/Zero/Avail/Small/Small/Err/Yes:tc-task-construct-errors.c:480
] P:289:0:RUN/Id/Inv/Zero/Avail/Small/Small/Err/No:tc-task-construct-errors.c:479
] P:290:0:RUN/Id/Inv/Zero/Avail/Small/Small/Err/No:tc-task-construct-errors.c:480
] P:291:0:RUN/Id/Inv/Zero/None/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:479
] P:292:0:RUN/Id/Inv/Zero/None/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:480
] P:293:0:RUN/Id/Inv/Zero/None/Enough/Enough/Ok/No:tc-task-construct-errors.c:479
] P:294:0:RUN/Id/Inv/Zero/None/Enough/Enough/Ok/No:tc-task-construct-errors.c:480
] P:295:0:RUN/Id/Inv/Zero/None/Enough/Enough/Err/Yes:tc-task-construct-errors.c:479
] P:296:0:RUN/Id/Inv/Zero/None/Enough/Enough/Err/Yes:tc-task-construct-errors.c:480
] P:297:0:RUN/Id/Inv/Zero/None/Enough/Enough/Err/No:tc-task-construct-errors.c:479
] P:298:0:RUN/Id/Inv/Zero/None/Enough/Enough/Err/No:tc-task-construct-errors.c:480
] P:299:0:RUN/Id/Inv/Zero/None/Enough/Small/Ok/Yes:tc-task-construct-errors.c:479
] P:300:0:RUN/Id/Inv/Zero/None/Enough/Small/Ok/Yes:tc-task-construct-errors.c:480
] P:301:0:RUN/Id/Inv/Zero/None/Enough/Small/Ok/No:tc-task-construct-errors.c:479
] P:302:0:RUN/Id/Inv/Zero/None/Enough/Small/Ok/No:tc-task-construct-errors.c:480
] P:303:0:RUN/Id/Inv/Zero/None/Enough/Small/Err/Yes:tc-task-construct-errors.c:479
] P:304:0:RUN/Id/Inv/Zero/None/Enough/Small/Err/Yes:tc-task-construct-errors.c:480
] P:305:0:RUN/Id/Inv/Zero/None/Enough/Small/Err/No:tc-task-construct-errors.c:479
] P:306:0:RUN/Id/Inv/Zero/None/Enough/Small/Err/No:tc-task-construct-errors.c:480
] P:307:0:RUN/Id/Inv/Zero/None/Small/Enough/Ok/Yes:tc-task-construct-errors.c:479
] P:308:0:RUN/Id/Inv/Zero/None/Small/Enough/Ok/Yes:tc-task-construct-errors.c:480
] P:309:0:RUN/Id/Inv/Zero/None/Small/Enough/Ok/No:tc-task-construct-errors.c:479
] P:310:0:RUN/Id/Inv/Zero/None/Small/Enough/Ok/No:tc-task-construct-errors.c:480
] P:311:0:RUN/Id/Inv/Zero/None/Small/Enough/Err/Yes:tc-task-construct-errors.c:479
] P:312:0:RUN/Id/Inv/Zero/None/Small/Enough/Err/Yes:tc-task-construct-errors.c:480
] P:313:0:RUN/Id/Inv/Zero/None/Small/Enough/Err/No:tc-task-construct-errors.c:479
] P:314:0:RUN/Id/Inv/Zero/None/Small/Enough/Err/No:tc-task-construct-errors.c:480
] P:315:0:RUN/Id/Inv/Zero/None/Small/Small/Ok/Yes:tc-task-construct-errors.c:479
] P:316:0:RUN/Id/Inv/Zero/None/Small/Small/Ok/Yes:tc-task-construct-errors.c:480
] P:317:0:RUN/Id/Inv/Zero/None/Small/Small/Ok/No:tc-task-construct-errors.c:479
] P:318:0:RUN/Id/Inv/Zero/None/Small/Small/Ok/No:tc-task-construct-errors.c:480
] P:319:0:RUN/Id/Inv/Zero/None/Small/Small/Err/Yes:tc-task-construct-errors.c:479
] P:320:0:RUN/Id/Inv/Zero/None/Small/Small/Err/Yes:tc-task-construct-errors.c:480
] P:321:0:RUN/Id/Inv/Zero/None/Small/Small/Err/No:tc-task-construct-errors.c:479
] P:322:0:RUN/Id/Inv/Zero/None/Small/Small/Err/No:tc-task-construct-errors.c:480
] P:323:0:RUN/Id/Inv/Inv/Avail/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:479
] P:324:0:RUN/Id/Inv/Inv/Avail/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:480
] P:325:0:RUN/Id/Inv/Inv/Avail/Enough/Enough/Ok/No:tc-task-construct-errors.c:479
] P:326:0:RUN/Id/Inv/Inv/Avail/Enough/Enough/Ok/No:tc-task-construct-errors.c:480
] P:327:0:RUN/Id/Inv/Inv/Avail/Enough/Enough/Err/Yes:tc-task-construct-errors.c:479
] P:328:0:RUN/Id/Inv/Inv/Avail/Enough/Enough/Err/Yes:tc-task-construct-errors.c:480
] P:329:0:RUN/Id/Inv/Inv/Avail/Enough/Enough/Err/No:tc-task-construct-errors.c:479
] P:330:0:RUN/Id/Inv/Inv/Avail/Enough/Enough/Err/No:tc-task-construct-errors.c:480
] P:331:0:RUN/Id/Inv/Inv/Avail/Enough/Small/Ok/Yes:tc-task-construct-errors.c:479
] P:332:0:RUN/Id/Inv/Inv/Avail/Enough/Small/Ok/Yes:tc-task-construct-errors.c:480
] P:333:0:RUN/Id/Inv/Inv/Avail/Enough/Small/Ok/No:tc-task-construct-errors.c:479
] P:334:0:RUN/Id/Inv/Inv/Avail/Enough/Small/Ok/No:tc-task-construct-errors.c:480
] P:335:0:RUN/Id/Inv/Inv/Avail/Enough/Small/Err/Yes:tc-task-construct-errors.c:479
] P:336:0:RUN/Id/Inv/Inv/Avail/Enough/Small/Err/Yes:tc-task-construct-errors.c:480
] P:337:0:RUN/Id/Inv/Inv/Avail/Enough/Small/Err/No:tc-task-construct-errors.c:479
] P:338:0:RUN/Id/Inv/Inv/Avail/Enough/Small/Err/No:tc-task-construct-errors.c:480
] P:339:0:RUN/Id/Inv/Inv/Avail/Small/Enough/Ok/Yes:tc-task-construct-errors.c:479
] P:340:0:RUN/Id/Inv/Inv/Avail/Small/Enough/Ok/Yes:tc-task-construct-errors.c:480
] P:341:0:RUN/Id/Inv/Inv/Avail/Small/Enough/Ok/No:tc-task-construct-errors.c:479
] P:342:0:RUN/Id/Inv/Inv/Avail/Small/Enough/Ok/No:tc-task-construct-errors.c:480
] P:343:0:RUN/Id/Inv/Inv/Avail/Small/Enough/Err/Yes:tc-task-construct-errors.c:479
] P:344:0:RUN/Id/Inv/Inv/Avail/Small/Enough/Err/Yes:tc-task-construct-errors.c:480
] P:345:0:RUN/Id/Inv/Inv/Avail/Small/Enough/Err/No:tc-task-construct-errors.c:479
] P:346:0:RUN/Id/Inv/Inv/Avail/Small/Enough/Err/No:tc-task-construct-errors.c:480
] P:347:0:RUN/Id/Inv/Inv/Avail/Small/Small/Ok/Yes:tc-task-construct-errors.c:479
] P:348:0:RUN/Id/Inv/Inv/Avail/Small/Small/Ok/Yes:tc-task-construct-errors.c:480
] P:349:0:RUN/Id/Inv/Inv/Avail/Small/Small/Ok/No:tc-task-construct-errors.c:479
] P:350:0:RUN/Id/Inv/Inv/Avail/Small/Small/Ok/No:tc-task-construct-errors.c:480
] P:351:0:RUN/Id/Inv/Inv/Avail/Small/Small/Err/Yes:tc-task-construct-errors.c:479
] P:352:0:RUN/Id/Inv/Inv/Avail/Small/Small/Err/Yes:tc-task-construct-errors.c:480
] P:353:0:RUN/Id/Inv/Inv/Avail/Small/Small/Err/No:tc-task-construct-errors.c:479
] P:354:0:RUN/Id/Inv/Inv/Avail/Small/Small/Err/No:tc-task-construct-errors.c:480
] P:355:0:RUN/Id/Inv/Inv/None/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:479
] P:356:0:RUN/Id/Inv/Inv/None/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:480
] P:357:0:RUN/Id/Inv/Inv/None/Enough/Enough/Ok/No:tc-task-construct-errors.c:479
] P:358:0:RUN/Id/Inv/Inv/None/Enough/Enough/Ok/No:tc-task-construct-errors.c:480
] P:359:0:RUN/Id/Inv/Inv/None/Enough/Enough/Err/Yes:tc-task-construct-errors.c:479
] P:360:0:RUN/Id/Inv/Inv/None/Enough/Enough/Err/Yes:tc-task-construct-errors.c:480
] P:361:0:RUN/Id/Inv/Inv/None/Enough/Enough/Err/No:tc-task-construct-errors.c:479
] P:362:0:RUN/Id/Inv/Inv/None/Enough/Enough/Err/No:tc-task-construct-errors.c:480
] P:363:0:RUN/Id/Inv/Inv/None/Enough/Small/Ok/Yes:tc-task-construct-errors.c:479
] P:364:0:RUN/Id/Inv/Inv/None/Enough/Small/Ok/Yes:tc-task-construct-errors.c:480
] P:365:0:RUN/Id/Inv/Inv/None/Enough/Small/Ok/No:tc-task-construct-errors.c:479
] P:366:0:RUN/Id/Inv/Inv/None/Enough/Small/Ok/No:tc-task-construct-errors.c:480
] P:367:0:RUN/Id/Inv/Inv/None/Enough/Small/Err/Yes:tc-task-construct-errors.c:479
] P:368:0:RUN/Id/Inv/Inv/None/Enough/Small/Err/Yes:tc-task-construct-errors.c:480
] P:369:0:RUN/Id/Inv/Inv/None/Enough/Small/Err/No:tc-task-construct-errors.c:479
] P:370:0:RUN/Id/Inv/Inv/None/Enough/Small/Err/No:tc-task-construct-errors.c:480
] P:371:0:RUN/Id/Inv/Inv/None/Small/Enough/Ok/Yes:tc-task-construct-errors.c:479
] P:372:0:RUN/Id/Inv/Inv/None/Small/Enough/Ok/Yes:tc-task-construct-errors.c:480
] P:373:0:RUN/Id/Inv/Inv/None/Small/Enough/Ok/No:tc-task-construct-errors.c:479
] P:374:0:RUN/Id/Inv/Inv/None/Small/Enough/Ok/No:tc-task-construct-errors.c:480
] P:375:0:RUN/Id/Inv/Inv/None/Small/Enough/Err/Yes:tc-task-construct-errors.c:479
] P:376:0:RUN/Id/Inv/Inv/None/Small/Enough/Err/Yes:tc-task-construct-errors.c:480
] P:377:0:RUN/Id/Inv/Inv/None/Small/Enough/Err/No:tc-task-construct-errors.c:479
] P:378:0:RUN/Id/Inv/Inv/None/Small/Enough/Err/No:tc-task-construct-errors.c:480
] P:379:0:RUN/Id/Inv/Inv/None/Small/Small/Ok/Yes:tc-task-construct-errors.c:479
] P:380:0:RUN/Id/Inv/Inv/None/Small/Small/Ok/Yes:tc-task-construct-errors.c:480
] P:381:0:RUN/Id/Inv/Inv/None/Small/Small/Ok/No:tc-task-construct-errors.c:479
] P:382:0:RUN/Id/Inv/Inv/None/Small/Small/Ok/No:tc-task-construct-errors.c:480
] P:383:0:RUN/Id/Inv/Inv/None/Small/Small/Err/Yes:tc-task-construct-errors.c:479
] P:384:0:RUN/Id/Inv/Inv/None/Small/Small/Err/Yes:tc-task-construct-errors.c:480
] P:385:0:RUN/Id/Inv/Inv/None/Small/Small/Err/No:tc-task-construct-errors.c:479
] P:386:0:RUN/Id/Inv/Inv/None/Small/Small/Err/No:tc-task-construct-errors.c:480
] P:387:0:RUN/Null/Valid/Valid/Avail/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:472
] P:388:0:RUN/Null/Valid/Valid/Avail/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:473
] P:389:0:RUN/Null/Valid/Valid/Avail/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:474
] P:390:0:RUN/Null/Valid/Valid/Avail/Enough/Enough/Ok/No:tc-task-construct-errors.c:472
] P:391:0:RUN/Null/Valid/Valid/Avail/Enough/Enough/Ok/No:tc-task-construct-errors.c:473
] P:392:0:RUN/Null/Valid/Valid/Avail/Enough/Enough/Ok/No:tc-task-construct-errors.c:474
] P:393:0:RUN/Null/Valid/Valid/Avail/Enough/Enough/Err/Yes:tc-task-construct-errors.c:472
] P:394:0:RUN/Null/Valid/Valid/Avail/Enough/Enough/Err/Yes:tc-task-construct-errors.c:473
] P:395:0:RUN/Null/Valid/Valid/Avail/Enough/Enough/Err/Yes:tc-task-construct-errors.c:474
] P:396:0:RUN/Null/Valid/Valid/Avail/Enough/Enough/Err/No:tc-task-construct-errors.c:472
] P:397:0:RUN/Null/Valid/Valid/Avail/Enough/Enough/Err/No:tc-task-construct-errors.c:473
] P:398:0:RUN/Null/Valid/Valid/Avail/Enough/Enough/Err/No:tc-task-construct-errors.c:474
] P:399:0:RUN/Null/Valid/Valid/Avail/Enough/Small/Ok/Yes:tc-task-construct-errors.c:472
] P:400:0:RUN/Null/Valid/Valid/Avail/Enough/Small/Ok/Yes:tc-task-construct-errors.c:473
] P:401:0:RUN/Null/Valid/Valid/Avail/Enough/Small/Ok/Yes:tc-task-construct-errors.c:474
] P:402:0:RUN/Null/Valid/Valid/Avail/Enough/Small/Ok/No:tc-task-construct-errors.c:472
] P:403:0:RUN/Null/Valid/Valid/Avail/Enough/Small/Ok/No:tc-task-construct-errors.c:473
] P:404:0:RUN/Null/Valid/Valid/Avail/Enough/Small/Ok/No:tc-task-construct-errors.c:474
] P:405:0:RUN/Null/Valid/Valid/Avail/Enough/Small/Err/Yes:tc-task-construct-errors.c:472
] P:406:0:RUN/Null/Valid/Valid/Avail/Enough/Small/Err/Yes:tc-task-construct-errors.c:473
] P:407:0:RUN/Null/Valid/Valid/Avail/Enough/Small/Err/Yes:tc-task-construct-errors.c:474
] P:408:0:RUN/Null/Valid/Valid/Avail/Enough/Small/Err/No:tc-task-construct-errors.c:472
] P:409:0:RUN/Null/Valid/Valid/Avail/Enough/Small/Err/No:tc-task-construct-errors.c:473
] P:410:0:RUN/Null/Valid/Valid/Avail/Enough/Small/Err/No:tc-task-construct-errors.c:474
] P:411:0:RUN/Null/Valid/Valid/Avail/Small/Enough/Ok/Yes:tc-task-construct-errors.c:472
] P:412:0:RUN/Null/Valid/Valid/Avail/Small/Enough/Ok/Yes:tc-task-construct-errors.c:473
] P:413:0:RUN/Null/Valid/Valid/Avail/Small/Enough/Ok/Yes:tc-task-construct-errors.c:474
] P:414:0:RUN/Null/Valid/Valid/Avail/Small/Enough/Ok/No:tc-task-construct-errors.c:472
] P:415:0:RUN/Null/Valid/Valid/Avail/Small/Enough/Ok/No:tc-task-construct-errors.c:473
] P:416:0:RUN/Null/Valid/Valid/Avail/Small/Enough/Ok/No:tc-task-construct-errors.c:474
] P:417:0:RUN/Null/Valid/Valid/Avail/Small/Enough/Err/Yes:tc-task-construct-errors.c:472
] P:418:0:RUN/Null/Valid/Valid/Avail/Small/Enough/Err/Yes:tc-task-construct-errors.c:473
] P:419:0:RUN/Null/Valid/Valid/Avail/Small/Enough/Err/Yes:tc-task-construct-errors.c:474
] P:420:0:RUN/Null/Valid/Valid/Avail/Small/Enough/Err/No:tc-task-construct-errors.c:472
] P:421:0:RUN/Null/Valid/Valid/Avail/Small/Enough/Err/No:tc-task-construct-errors.c:473
] P:422:0:RUN/Null/Valid/Valid/Avail/Small/Enough/Err/No:tc-task-construct-errors.c:474
] P:423:0:RUN/Null/Valid/Valid/Avail/Small/Small/Ok/Yes:tc-task-construct-errors.c:472
] P:424:0:RUN/Null/Valid/Valid/Avail/Small/Small/Ok/Yes:tc-task-construct-errors.c:473
] P:425:0:RUN/Null/Valid/Valid/Avail/Small/Small/Ok/Yes:tc-task-construct-errors.c:474
] P:426:0:RUN/Null/Valid/Valid/Avail/Small/Small/Ok/No:tc-task-construct-errors.c:472
] P:427:0:RUN/Null/Valid/Valid/Avail/Small/Small/Ok/No:tc-task-construct-errors.c:473
] P:428:0:RUN/Null/Valid/Valid/Avail/Small/Small/Ok/No:tc-task-construct-errors.c:474
] P:429:0:RUN/Null/Valid/Valid/Avail/Small/Small/Err/Yes:tc-task-construct-errors.c:472
] P:430:0:RUN/Null/Valid/Valid/Avail/Small/Small/Err/Yes:tc-task-construct-errors.c:473
] P:431:0:RUN/Null/Valid/Valid/Avail/Small/Small/Err/Yes:tc-task-construct-errors.c:474
] P:432:0:RUN/Null/Valid/Valid/Avail/Small/Small/Err/No:tc-task-construct-errors.c:472
] P:433:0:RUN/Null/Valid/Valid/Avail/Small/Small/Err/No:tc-task-construct-errors.c:473
] P:434:0:RUN/Null/Valid/Valid/Avail/Small/Small/Err/No:tc-task-construct-errors.c:474
] P:435:0:RUN/Null/Valid/Valid/None/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:472
] P:436:0:RUN/Null/Valid/Valid/None/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:473
] P:437:0:RUN/Null/Valid/Valid/None/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:474
] P:438:0:RUN/Null/Valid/Valid/None/Enough/Enough/Ok/No:tc-task-construct-errors.c:472
] P:439:0:RUN/Null/Valid/Valid/None/Enough/Enough/Ok/No:tc-task-construct-errors.c:473
] P:440:0:RUN/Null/Valid/Valid/None/Enough/Enough/Ok/No:tc-task-construct-errors.c:474
] P:441:0:RUN/Null/Valid/Valid/None/Enough/Enough/Err/Yes:tc-task-construct-errors.c:472
] P:442:0:RUN/Null/Valid/Valid/None/Enough/Enough/Err/Yes:tc-task-construct-errors.c:473
] P:443:0:RUN/Null/Valid/Valid/None/Enough/Enough/Err/Yes:tc-task-construct-errors.c:474
] P:444:0:RUN/Null/Valid/Valid/None/Enough/Enough/Err/No:tc-task-construct-errors.c:472
] P:445:0:RUN/Null/Valid/Valid/None/Enough/Enough/Err/No:tc-task-construct-errors.c:473
] P:446:0:RUN/Null/Valid/Valid/None/Enough/Enough/Err/No:tc-task-construct-errors.c:474
] P:447:0:RUN/Null/Valid/Valid/None/Enough/Small/Ok/Yes:tc-task-construct-errors.c:472
] P:448:0:RUN/Null/Valid/Valid/None/Enough/Small/Ok/Yes:tc-task-construct-errors.c:473
] P:449:0:RUN/Null/Valid/Valid/None/Enough/Small/Ok/Yes:tc-task-construct-errors.c:474
] P:450:0:RUN/Null/Valid/Valid/None/Enough/Small/Ok/No:tc-task-construct-errors.c:472
] P:451:0:RUN/Null/Valid/Valid/None/Enough/Small/Ok/No:tc-task-construct-errors.c:473
] P:452:0:RUN/Null/Valid/Valid/None/Enough/Small/Ok/No:tc-task-construct-errors.c:474
] P:453:0:RUN/Null/Valid/Valid/None/Enough/Small/Err/Yes:tc-task-construct-errors.c:472
] P:454:0:RUN/Null/Valid/Valid/None/Enough/Small/Err/Yes:tc-task-construct-errors.c:473
] P:455:0:RUN/Null/Valid/Valid/None/Enough/Small/Err/Yes:tc-task-construct-errors.c:474
] P:456:0:RUN/Null/Valid/Valid/None/Enough/Small/Err/No:tc-task-construct-errors.c:472
] P:457:0:RUN/Null/Valid/Valid/None/Enough/Small/Err/No:tc-task-construct-errors.c:473
] P:458:0:RUN/Null/Valid/Valid/None/Enough/Small/Err/No:tc-task-construct-errors.c:474
] P:459:0:RUN/Null/Valid/Valid/None/Small/Enough/Ok/Yes:tc-task-construct-errors.c:472
] P:460:0:RUN/Null/Valid/Valid/None/Small/Enough/Ok/Yes:tc-task-construct-errors.c:473
] P:461:0:RUN/Null/Valid/Valid/None/Small/Enough/Ok/Yes:tc-task-construct-errors.c:474
] P:462:0:RUN/Null/Valid/Valid/None/Small/Enough/Ok/No:tc-task-construct-errors.c:472
] P:463:0:RUN/Null/Valid/Valid/None/Small/Enough/Ok/No:tc-task-construct-errors.c:473
] P:464:0:RUN/Null/Valid/Valid/None/Small/Enough/Ok/No:tc-task-construct-errors.c:474
] P:465:0:RUN/Null/Valid/Valid/None/Small/Enough/Err/Yes:tc-task-construct-errors.c:472
] P:466:0:RUN/Null/Valid/Valid/None/Small/Enough/Err/Yes:tc-task-construct-errors.c:473
] P:467:0:RUN/Null/Valid/Valid/None/Small/Enough/Err/Yes:tc-task-construct-errors.c:474
] P:468:0:RUN/Null/Valid/Valid/None/Small/Enough/Err/No:tc-task-construct-errors.c:472
] P:469:0:RUN/Null/Valid/Valid/None/Small/Enough/Err/No:tc-task-construct-errors.c:473
] P:470:0:RUN/Null/Valid/Valid/None/Small/Enough/Err/No:tc-task-construct-errors.c:474
] P:471:0:RUN/Null/Valid/Valid/None/Small/Small/Ok/Yes:tc-task-construct-errors.c:472
] P:472:0:RUN/Null/Valid/Valid/None/Small/Small/Ok/Yes:tc-task-construct-errors.c:473
] P:473:0:RUN/Null/Valid/Valid/None/Small/Small/Ok/Yes:tc-task-construct-errors.c:474
] P:474:0:RUN/Null/Valid/Valid/None/Small/Small/Ok/No:tc-task-construct-errors.c:472
] P:475:0:RUN/Null/Valid/Valid/None/Small/Small/Ok/No:tc-task-construct-errors.c:473
] P:476:0:RUN/Null/Valid/Valid/None/Small/Small/Ok/No:tc-task-construct-errors.c:474
] P:477:0:RUN/Null/Valid/Valid/None/Small/Small/Err/Yes:tc-task-construct-errors.c:472
] P:478:0:RUN/Null/Valid/Valid/None/Small/Small/Err/Yes:tc-task-construct-errors.c:473
] P:479:0:RUN/Null/Valid/Valid/None/Small/Small/Err/Yes:tc-task-construct-errors.c:474
] P:480:0:RUN/Null/Valid/Valid/None/Small/Small/Err/No:tc-task-construct-errors.c:472
] P:481:0:RUN/Null/Valid/Valid/None/Small/Small/Err/No:tc-task-construct-errors.c:473
] P:482:0:RUN/Null/Valid/Valid/None/Small/Small/Err/No:tc-task-construct-errors.c:474
] P:483:0:RUN/Null/Valid/Zero/Avail/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:472
] P:484:0:RUN/Null/Valid/Zero/Avail/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:473
] P:485:0:RUN/Null/Valid/Zero/Avail/Enough/Enough/Ok/Yes:tc-task-construct-errors.c:474
] P:486:0:RUN/Null/Valid/Zero/Avail/Enough/Enough/Ok/No:tc-task-construct-errors.c:472
] P:487:0:RUN/Null/Valid/Zero/Avail/Enough/Enough/Ok/No:tc-task-construct-errors.c:473
] P:488:0:RUN/Null/Valid/Zero/Avail/Enough/Enough/Ok/No:tc-task-construct-errors.c:474
] P:489:0:RUN/Null/Valid/Zero/Avail/Enough/Enough/Err/Yes:tc-task-construct-errors.c:472
] P:490:0:RUN/Null/Valid/Zero/Avail/Enough/Enough/Err/Yes:tc-task-construct-errors.c:473
] P:491:0:RUN/Null/Valid/Zero/Avail/Enough/Enough/Err/Yes:tc-task-construct-errors.c:474
] P:492:0:RUN/Null/Valid/Zero/Avail/Enough/Enough/Err/No:tc-task-construct-errors.c:472
] P:493:0:RUN/Null/Valid/Zero/Avail/Enough/Enough/Err/No:tc-task-construct-errors.c:473
] P:494:0:RUN/Null/Valid/Zero/Avail/Enough/Enough/Err/No:tc-task-construct-errors.c:474
] P:495:0:RUN/Null/Valid/Zero/Avail/Enough/Small/Ok/Yes:tc-task-construct-errors.c:472
] P:496:0:RUN/Null/Valid/Zero/Avail/Enough/Small/Ok/Yes:tc-task-construct-errors.c:473
] P:497:0:RUN/Null/Valid/Zero/Avail/Enough/Small/Ok/Yes:tc-task-construct-errors.c:474
] P:498:0:RUN/Null/Valid/Zero/Avail/Enough/Small/Ok/No:tc-task-construct-errors.c:472
] P:499:0:RUN/Null/Valid/Zero/Avail/Enough/Small/Ok/No:tc-task-construct-errors.c:473
] P:500:0:RUN/Null/Valid/Zero/Avail/Enough/Small/Ok/No:tc-task-construct-errors.c:474
] P:501:0:RUN/Null/Valid/Zero/Avail/Enough/Small/Err/Yes:tc-task-construct-errors.c:472
] P:502:0:RUN/Null/Valid/Zero/Avail/Enough/Small/Err/Yes:tc-task-construct-errors.c:473
] P:503:0:RUN/Null/Valid/Zero/Avail/Enough/Small/Err/Yes:tc-task-construct-errors.c:474
] P:504:0:RUN/Null/Valid/Zero/Avail/Enough/Small/Err/No:tc-task-construct-errors.c:472
] P:505:0:RUN/Null/Valid/Zero/Avail/Enough/Small/Err/No:tc-task-construct-errors.c:473
] P:506:0:RUN/Null/Valid/Zero/Avail/Enough/Small/Err/No:tc-task-construct-errors.c:474
] P:507:0:RUN/Null/Valid/Zero/Avail/Small/Enough/Ok/Yes:tc-task-construct-errors.c:472
] P:508:0:RUN/Null/Valid/Zero/Avail/Small/Enough/Ok/Yes:tc-task-construct-errors.c:473
] P:509:0:RUN/Null/Valid/Zero/Avail/Small/Enough/Ok/Yes:tc-task-construct-errors.c:474
] P:510:0:RUN/Null/Valid/Zero/Avail/Small/Enough/Ok/No:tc-task-construct-errors.c:472
] P:511:0:RUN/Null/Valid/Zero/Avail/Small/Enough/Ok/No:tc-task-construct-errors.c:473
] P:512:0:RUN/Null/Valid/Zero/Avail/Small/Enough/Ok/No:tc-task-construct-errors.c:474
] P:513:0:RUN/Null/Valid/Zero/Avail/Small/Enough/Err/Yes:tc-task-construct-errors.c:472
] P:514:0:RUN/Null/Valid/Zero/Avail/Small/Enough/Err/Yes:tc-task-construct-errors.c:473
] P:515:0:RUN/Null/Valid/Zero/Avail/Small/Enough/Err/Yes:tc-task-construct-errors.c:474
] P:516:0:RUN/Null/Valid/Zero/Avail/Small/Enough/Err/No:tc-task-construct-errors.c:472
] P:517:0:RUN/Null/Valid/Zero/Avail/Small/Enough/Err/No:tc-task-coTraceback (most recent call last):
File "/build/rtems/6/share/rtems/tester/rt/cmd-test.py", line 42, in <module>
test.run(sys.argv[1:], command_path = base)
File "/build/rtems/6/share/rtems/tester/rt/test.py", line 498, in run
job_trace)
File "/build/rtems/6/share/rtems/tester/rt/test.py", line 195, in report_finished
reports.log(tst.executable, log_mode)
File "/build/rtems/6/share/rtems/tester/rt/report.py", line 281, in log
log.output(output)
File "/build/rtems/6/share/rtems/rtemstoolkit/log.py", line 112, in output
_output(text, log)
File "/build/rtems/6/share/rtems/rtemstoolkit/log.py", line 93, in _output
default.output(text)
File "/build/rtems/6/share/rtems/rtemstoolkit/log.py", line 193, in output
self.fhs[f].write(out)
BlockingIOError: [Errno 11] write could not complete without blocking
Author: Chris Johns
2020-09-24T00:45:28.000Z
Original author: sebastian.huber
Is
ts-validation-0.exeavailable onmaster?
Author: Trac Migrate
2020-09-24T04:41:12.000Z
Original author: sebastian.huber
Yes, it is available on the master, however, with a bit less output. You can increase the output with:
diff --git a/testsuites/validation/ts-validation-0.c b/testsuites/validation/ts-validation-0.c index 3e60fb6ab8..5c10ca6d71 100644 --- a/testsuites/validation/ts-validation-0.c +++ b/testsuites/validation/ts-validation-0.c @@ -102,7 +102,9 @@ static void runner_task( rtems_task_argument arg ) rtems_test_begin( rtems_test_name, TEST_STATE ); T_register(); + for (int i = 0; i < 100; ++i) { exit_code = T_main( &test_config ); + } if ( exit_code == 0 ) { rtems_test_end( rtems_test_name );It is a sporadic error. I can’t reproduce it reliably, but I observed this BlockingIOError error on several machines.
Author: Chris Johns
2020-09-24T05:45:53.000Z
Original author: sebastian.huber
Thanks. Which host OS?
Author: Trac Migrate
2020-09-24T08:23:48.000Z
Original author: sebastian.huber
Yes, on Linux (OpenSUSE).
I found this:
https://github.com/travis-ci/travis-ci/issues/8920
They suggest to add something like this:
python -c "import fcntl; fcntl.fcntl(1, fcntl.F_SETFL, 0)"
Author: Trac Migrate
2020-09-24T09:16:28.000Z
Original author: sebastian.huber
I added some debug output to log.py. Someone sets f = 0 which is fhs = <_io.TextIOWrapper name=’<stdout>’ mode=’w’ encoding=’UTF-8’> to non-blocking. In log.__init__ stdout is set to blocking.
Author: Trac Migrate
2020-09-24T12:47:16.000Z
Original author: sebastian.huber
It is a bit weird. The stdout suddenly changes to non-blocking.
diff --git a/rtemstoolkit/log.py b/rtemstoolkit/log.py index 00fdb05..65d487e 100755 --- a/rtemstoolkit/log.py +++ b/rtemstoolkit/log.py @@ -37,6 +37,7 @@ from __future__ import print_function import os import sys import threading +import fcntl from rtemstoolkit import error @@ -135,6 +136,19 @@ def flush(log = None): elif default is not None: default.flush() +def get_status(fileno): + fl = fcntl.fcntl(fileno, fcntl.F_GETFL) + if (fl & os.O_NONBLOCK) == os.O_NONBLOCK: + print(fileno, "nonblocking") + else: + print(fileno, "blocking") + +def check(fd, ctx): + print("check", ctx, fd) + fl = fcntl.fcntl(fd.fileno(), fcntl.F_GETFL) + if (fl & os.O_NONBLOCK) == os.O_NONBLOCK: + raise IOError + class log: """Log output to stdout or a file.""" def __init__(self, streams = None, tail_size = 100): @@ -145,12 +159,20 @@ class log: if streams: for s in streams: if s == 'stdout': + get_status(sys.stdout.fileno()) self.fhs[0] = sys.stdout + fcntl.fcntl(self.fhs[0], fcntl.F_SETFL, 0) + check(self.fhs[0], "init stdout") elif s == 'stderr': + get_status(sys.stderr.fileno()) self.fhs[1] = sys.stderr + fcntl.fcntl(self.fhs[1], fcntl.F_SETFL, 0) + check(self.fhs[1], "init stderr") else: try: self.fhs.append(open(s, 'w')) + fcntl.fcntl(self.fhs[-1], fcntl.F_SETFL, 0) + check(self.fhs[-1], "init file") except IOError as ioe: raise error.general("creating log file '" + s + \\ "': " + str(ioe)) @@ -173,9 +195,11 @@ class log: self.tail = self.tail[-self.tail_size:] def has_stdout(self): + check(self.fhs[0], "has_stdout") return self.fhs[0] is not None def has_stderr(self): + check(self.fhs[1], "has_stderr") return self.fhs[1] is not None def output(self, text): @@ -190,7 +214,13 @@ class log: try: for f in range(0, len(self.fhs)): if self.fhs[f] is not None: - self.fhs[f].write(out) + check(self.fhs[f], "output") + try: + self.fhs[f].write(out) + except BlockingIOError: + print("f =", f, "fhs =", self.fhs[f]) + get_status(self.fhs[f].fileno()) + raise self.flush() except: raise @@ -201,6 +231,7 @@ class log: """Flush the output.""" for f in range(0, len(self.fhs)): if self.fhs[f] is not None: + check(self.fhs[f], "flush") self.fhs[f].flush() if __name__ == "__main__":With this patch I get this output:
rtems-test --rtems-bsp=realview_pbx_a9_qemu build/arm/realview_pbx_a9_qemu 1 blocking check init stdout <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'> check has_stdout <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'> check output <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'> RTEMS Testing - Tester, 6.0.not_released check flush <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'> check output <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'> Command Line: /build/rtems/6/bin/rtems-test --rtems-bsp=realview_pbx_a9_qemu build/arm/realview_pbx_a9_qemu Host: Linux huber-nb-linux.suse 4.12.14-lp151.28.59-default #1 SMP Wed Aug 5 10:58:34 UTC 2020 (337e42e) x86_64 Python: 3.6.10 (default, Jan 16 2020, 09:12:04) [GCC] check flush <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'> check output <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'> Host: Linux-4.12.14-lp151.28.59-default-x86_64-with-glibc2.3.4 (Linux huber-nb-linux.suse 4.12.14-lp151.28.59-default #1 SMP Wed Aug 5 10:58:34 UTC 2020 (337e42e) x86_64 x86_64) check flush <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'> check has_stdout <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'> check has_stdout <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'> [ 2/598] p:0 f:0 u:0 e:0 I:0 B:0 t:0 L:0 i:0 W:0 | arm/realview_pbx_a9_qemu: linpack.exe [ 4/598] p:0 f:0 u:0 e:0 I:0 B:0 t:0 L:0 i:0 W:0 | arm/realview_pbx_a9_qemu: fsbdpart01.exe check has_stdout <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'> check has_stdout <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'> check has_stdout <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'> check has_stdout <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'> check has_stdout <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'> check has_stdout <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'> check has_stdout <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'> check has_stdout <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'> check has_stdout <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'> check has_stdout <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'> Traceback (most recent call last): File "/build/rtems/6/share/rtems/tester/rt/cmd-test.py", line 42, in <module> test.run(sys.argv[1:], command_path = base) File "/build/rtems/6/share/rtems/tester/rt/test.py", line 489, in run tst.reraise() File "/build/rtems/6/share/rtems/tester/rt/test.py", line 161, in reraise reraise.reraise(*self.result) File "/build/rtems/6/share/rtems/rtemstoolkit/reraise.py", line 63, in reraise raise value.with_traceback(tb) File "/build/rtems/6/share/rtems/tester/rt/test.py", line 143, in runner self.test.run() File "/build/rtems/6/share/rtems/tester/rt/test.py", line 115, in run self.config.run() File "/build/rtems/6/share/rtems/tester/rt/config.py", line 370, in run self.load(self.name) File "/build/rtems/6/share/rtems/rtemstoolkit/config.py", line 772, in load dir, info, data = self._process_directive(r, dir, info, data) File "/build/rtems/6/share/rtems/rtemstoolkit/config.py", line 638, in _process_directive directive, into, data = self._directive_filter(results, directive, info, data) File "/build/rtems/6/share/rtems/tester/rt/config.py", line 320, in _directive_filter bsp_arch, bsp, self.show_header) File "/build/rtems/6/share/rtems/tester/rt/report.py", line 124, in start log.notice(header, stdout_only = True) File "/build/rtems/6/share/rtems/rtemstoolkit/log.py", line 117, in notice (default is not None and not default.has_stdout() or stdout_only): File "/build/rtems/6/share/rtems/rtemstoolkit/log.py", line 199, in has_stdout check(self.fhs[0], "has_stdout") File "/build/rtems/6/share/rtems/rtemstoolkit/log.py", line 150, in check raise IOError OSErrorSo, stdout is blocking for a while and then changes to non-blocking.
Author: Chris Johns
2020-09-26T01:30:23.000Z
Original author: sebastian.huber
I suggest you print the id of the thread being checked? The original trace shows the exception in the original thread for the process and this last exception is in the worker thread for the test. Are the thread’s picking up the original state and not the modified state?
Also I wonder if
print(l)should besys.stdout.write(l)? That is, maybe the low level layer oflog.pyshould work at the handle level only and not mix things up.
Author: Joel Sherrill
2021-12-17T17:01:20.000Z
Original author: sebastian.huber
Did you resolve this?
Author: Chris Johns
2022-11-29T23:22:26.000Z
Original author: sebastian.huber
Milestone changed from %”6.1” to %”Indefinite”
Owner set to Needs Funding
Status changed from new to assigned
Version changed from ~”6” to ~”7”
Author: Amar Takhar
2025-09-05T02:57:44.701Z
changed the description
Author: Chris Johns
2026-07-30T23:24:13.450Z
set status to Won’t do
4147 - rtems-bsp-builder: Attempts all even when tools are not in PATH¶
Id |
4147 |
State |
closed |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2020-10-14T19:02:48.000Z |
Closed |
2026-07-30T23:23:51.201Z |
Updated |
2026-07-30T23:23:51.265Z |
Milestone |
6.3 |
Labels |
old-indefinite, priority::normal, tickettype::defect, tool, version::6, version::7 |
Link |
|
Merges |
0 |
Apparently you have to have RTEMS tools in your PATH before running the bsp builder. I just finished a run that took 2 hours to basically tell me to add RTEMS tools to my PATH. Could this be error checked and bail out early?
Average BSP Build Time: 0:00:04.463226
Total Time 2:06:09.632269
Passes: 0 Failures: 1696
real 126m11.106s
user 32m0.580s
sys 31m3.187s
Author: Chris Johns
2022-11-29T23:23:49.000Z
Milestone changed from %”6.1” to %”Indefinite”
Version changed from ~”6” to ~”7”
Author: Amar Takhar
2025-09-05T02:57:45.797Z
changed the description
Author: Chris Johns
2026-07-30T23:23:51.238Z
set status to Won’t do
3963 - Add build specification item verification¶
Id |
3963 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Sebastian Huber |
Closed by |
Chris Johns |
Created |
2020-04-22T05:12:17.000Z |
Closed |
2026-07-30T23:22:42.026Z |
Updated |
2026-07-30T23:22:42.103Z |
Milestone |
6.3 |
Labels |
priority::normal, qualification, rtems::build, tickettype::enhancement, version::6 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
The new build system uses build specification items to define what is built and how it is built. Add a ./waf –rtems-verify-spec option to verify that the build specification items are sane. For example, check that there are no cycles in the graph, all required attributes are present, the attribute values have the proper type, no additional attributes are present, all UIDs are resolvable, etc.
Author: Trac Migrate
2020-05-28T11:03:17.000Z
Original author: sebastian.huber
The basic functionality for a verification of build items is implemented in the RTEMS Qualification Tools repository:
https://git.rtems.org/sebh/rtems-qual.git/tree/specverify.py
To make use of it, one option would be to install the RTEMS Qualification Tools Python modules under ${prefix}/share/rtems parallel to the rtemstoolkit modules. Only if the wscript should do the verification, then the module is loaded.
Missing features are:
verify that the directed graph of specification items has no cycles (depending on the link role)
specify and verify required links, roles, and target types for item types
detect isolated items
add warning conditions
improve the output of failed assertions
Author: Trac Migrate
2022-09-08T07:37:09.000Z
Original author: sebastian.huber
Milestone changed from %”6.1” to %”7.1”
Author: Amar Takhar
2024-04-25T20:48:07.114Z
changed the description
Author: Joel Sherrill
2025-09-19T00:02:51.907Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-30T23:20:49.532Z
assigned to @sebhub
Author: Chris Johns
2026-07-30T23:21:07.473Z
Please update the Status.
Author: Chris Johns
2026-07-30T23:22:42.078Z
set status to Done
Author: Chris Johns
2026-07-30T23:22:42.867Z
Duplicate of #5296
4087 - libbsd: sh architecture build is broken¶
Id |
4087 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2020-09-23T05:45:35.000Z |
Closed |
2026-07-30T23:22:01.005Z |
Updated |
2026-07-30T23:22:01.064Z |
Milestone |
6.3 |
Labels |
arch:sh, old-indefinite, priority::normal, tickettype::defect, version::6 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
/build/rtems/6/lib/gcc/sh-rtems6/10.2.1/../../../../sh-rtems6/bin/ld: ./libbsd.a(af_nd6.c.11.o):/ramdisk/git-rtems-libbsd/build/sh-rtems6-simsh4-default/../../freebsd/sbin/ifconfig/af_nd6.c:181: more undefined references to `warn' follow
/build/rtems/6/lib/gcc/sh-rtems6/10.2.1/../../../../sh-rtems6/bin/ld: ./libbsd.a(ifbridge.c.11.o): in function `bridge_addresses':
/ramdisk/git-rtems-libbsd/build/sh-rtems6-simsh4-default/../../freebsd/sbin/ifconfig/ifbridge.c:246: undefined reference to `err'
/build/rtems/6/lib/gcc/sh-rtems6/10.2.1/../../../../sh-rtems6/bin/ld: ./libbsd.a(ifbridge.c.11.o): in function `setbridge_flushall':
/ramdisk/git-rtems-libbsd/build/sh-rtems6-simsh4-default/../../freebsd/sbin/ifconfig/ifbridge.c:475: undefined reference to `err'
/build/rtems/6/lib/gcc/sh-rtems6/10.2.1/../../../../sh-rtems6/bin/ld: /ramdisk/git-rtems-libbsd/build/sh-rtems6-simsh4-default/../../freebsd/sbin/ifconfig/ifbridge.c:475: undefined reference to `err'
/build/rtems/6/lib/gcc/sh-rtems6/10.2.1/../../../../sh-rtems6/bin/ld: ./libbsd.a(ifbridge.c.11.o): in function `setbridge_delete':
/ramdisk/git-rtems-libbsd/build/sh-rtems6-simsh4-default/../../freebsd/sbin/ifconfig/ifbridge.c:327: undefined reference to `err'
/build/rtems/6/lib/gcc/sh-rtems6/10.2.1/../../../../sh-rtems6/bin/ld: ./libbsd.a(ifbridge.c.11.o): in function `unsetbridge_span':
/ramdisk/git-rtems-libbsd/build/sh-rtems6-simsh4-default/../../freebsd/sbin/ifconfig/ifbridge.c:391: undefined reference to `err'
/build/rtems/6/lib/gcc/sh-rtems6/10.2.1/../../../../sh-rtems6/bin/ld: ./libbsd.a(ifbridge.c.11.o):/ramdisk/git-rtems-libbsd/build/sh-rtems6-simsh4-default/../../freebsd/sbin/ifconfig/ifbridge.c:380: more undefined references to `err' follow
Author: Amar Takhar
2025-09-05T02:57:44.323Z
changed the description
Author: Chris Johns
2026-07-30T23:22:01.039Z
set status to Won’t do
4085 - libbsd: x86_64 architecture build is broken¶
Id |
4085 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2020-09-23T05:42:44.000Z |
Closed |
2026-07-30T23:21:46.598Z |
Updated |
2026-07-30T23:21:46.661Z |
Milestone |
6.3 |
Labels |
arch:i386, old-indefinite, priority::normal, tickettype::defect, version::6 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
../../freebsd/sbin/sysctl/sysctl.c:67:10: fatal error: sys/efi.h: No such file or directory
67 | #include <sys/efi.h>
| ^~~~~~~~~~~
Author: Amar Takhar
2025-09-05T02:57:44.128Z
changed the description
Author: Chris Johns
2026-07-30T23:21:46.631Z
set status to Won’t do
3738 - Refactor the Software Engineering Manual¶
Id |
3738 |
State |
closed |
Type |
ISSUE |
Author |
Gedare Bloom |
Assignee(s) |
Joel Sherrill |
Closed by |
Chris Johns |
Created |
2019-04-23T16:51:04.000Z |
Closed |
2026-07-30T23:17:52.731Z |
Updated |
2026-07-30T23:17:52.789Z |
Milestone |
6.3 |
Labels |
old-indefinite, priority::normal, tickettype::project, version::6 |
Link |
|
Merges |
0 |
The newest RTEMS Manual is the [Software Engineering (SwE)](https://docs.rtems.org/branches/master/eng/index.html) Manual, which is intended to document the software engineering practices of RTEMS development. This project will improve the completeness and consistency of the SwE Manual with respect to primary sources and our intentions for this manual’s use.
One of the main sources of content for the SwE book is our wiki. We would like to have the content of the SwE manual cross-checked with the respective wiki pages, and have those wiki pages be replaced with a link to the SwE book as the authoritative source for the information moving forward. This check should ensure the content is correctly reproduced, and identify any re-formatting that should be done in the manual to improve typesetting etc.
The primary remaining task is to review sections taken from the wiki, ensure the conversion looks correct, delete the wiki page, and correct all references from the web to the delete page.
In addition, the flow and organization of the SwE Manual likely could be greatly improved. We created the manual by filling in an outline with large dumps of text. A balanced and thoughtful approach to the manual’s organization would likely provide great benefits to its usability and maintenance.
Author: Joel Sherrill
2020-01-14T21:16:19.000Z
Description changed
The newest [RTEMS Manual](https://docs.rtems.org/) is the [Software Engineering (SwE)](https://docs.rtems.org/branches/master/eng/index.html) Manual, which is intended to document the software engineering practices of RTEMS development. This project will improve the completeness and consistency of the SwE Manual with respect to primary sources and our intentions for this manual's use. One of the main sources of content for the SwE book is our wiki. We would like to have the content of the SwE manual cross-checked with the respective wiki pages, and have those wiki pages be replaced with a link to the SwE book as the authoritative source for the information moving forward. This check should ensure the content is correctly reproduced, and identify any re-formatting that should be done in the manual to improve typesetting etc. + * The primary remaining task is to review sections taken from the wiki, ensure the conversion looks correct, delete the wiki page, and correct all references from the web to the delete page. + In addition, the flow and organization of the SwE Manual likely could be greatly improved. We created the manual by filling in an outline with large dumps of text. A balanced and thoughtful approach to the manual's organization would likely provide great benefits to its usability and maintenance.
Author: Amar Takhar
2025-09-05T03:01:14.761Z
changed the description
Author: Chris Johns
2026-07-30T23:17:52.764Z
set status to Done
3597 - Variable tmp_dirent not initialized CID 1440356¶
Id |
3597 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Joel Sherrill |
Closed by |
Chris Johns |
Created |
2018-11-07T17:09:53.000Z |
Closed |
2026-07-30T23:09:00.187Z |
Updated |
2026-07-30T23:09:00.192Z |
Milestone |
6.3 |
Labels |
filesystem, old-indefinite, priority::normal, scan::coverity, tickettype::defect, version::6 |
Link |
|
Merges |
0 |
Original author: zehata
From rtems root directory, cd cpukit/libfs/src/dosfs/msdos_dir.c tmp.dirent was used 18 times but isn’t initialized anywhere in the file. In line 325, memcpy was used, with the second parameter, a constant, being tmp_dirent, however, before this, it was not initialized at all, leading to the usage of an uninitialized variable (in memcpy)
64 msdos_dir_read(rtems_libio_t *iop, void *buffer, size_t count)
65 {
...
73 struct dirent tmp_dirent;
...
154 if ((*MSDOS_DIR_ATTR(entry) & MSDOS_ATTR_LFN_MASK) == MSDOS_ATTR_LFN)
155 {
...
324 if ( cmpltd >= 0 ) {
Uninitialized scalar variable (UNINIT) uninit_use_in_call: Using uninitialized value tmp_dirent. Field tmp_dirent.d_type is uninitialized when calling memcpy.
325 memcpy(buffer + cmpltd, &tmp_dirent, sizeof(struct dirent));
326
327 iop->offset = iop->offset + sizeof(struct dirent);
328 cmpltd += (sizeof(struct dirent));
329 count -= (sizeof(struct dirent));
330
331 /* inode number extracted, close fat-file */
332 rc = fat_file_close(&fs_info->fat, tmp_fat_fd);
333 if (rc != RC_OK)
334 {
335 msdos_fs_unlock(fs_info);
336 return rc;
337 }
338 }
339 }
...
349 }
Author: Trac Migrate
2018-11-07T17:16:12.000Z
Original author: zehata
Milestone set to %”Indefinite”
Version set to ~”6”
Per Coverity scan CID 1440356, the file at cpukit/libfs/src/dosfs/msdos_dir.c uses uninitialized variable tmp_dirent multiple times in the file.
Author: Trac Migrate
2018-11-07T19:03:05.000Z
Original author: zehata
Summary changed from Variable tmp_dirent not initialized to Variable tmp_dirent not initialized CID 1440356
Author: Joel Sherrill
2018-11-10T13:26:50.000Z
Original author: zehata
Description changed
From rtems root directory, cd cpukit/libfs/src/dosfs/msdos_dir.c tmp.dirent was used 18 times but isn't initialized anywhere in the file. + In line 325, memcpy was used, with the second parameter, a constant, being tmp_dirent, however, before this, it was not initialized at all, leading to the usage of an uninitialized variable (in memcpy) + + {{{ + 64 msdos_dir_read(rtems_libio_t *iop, void *buffer, size_t count) + 65 { + + ... + + 73 struct dirent tmp_dirent; + + ... + + 154 if ((*MSDOS_DIR_ATTR(entry) & MSDOS_ATTR_LFN_MASK) == MSDOS_ATTR_LFN) + 155 { + + ... + + 324 if ( cmpltd >= 0 ) { + }}} + Uninitialized scalar variable (UNINIT) + uninit_use_in_call: Using uninitialized value tmp_dirent. Field tmp_dirent.d_type is uninitialized when calling memcpy. + + {{{ + 325 memcpy(buffer + cmpltd, &tmp_dirent, sizeof(struct dirent)); + 326 + 327 iop->offset = iop->offset + sizeof(struct dirent); + 328 cmpltd += (sizeof(struct dirent)); + 329 count -= (sizeof(struct dirent)); + 330 + 331 /* inode number extracted, close fat-file */ + 332 rc = fat_file_close(&fs_info->fat, tmp_fat_fd); + 333 if (rc != RC_OK) + 334 { + 335 msdos_fs_unlock(fs_info); + 336 return rc; + 337 } + 338 } + 339 } + + ... + + 349 } + }}}
Author: Amar Takhar
2024-04-25T20:46:41.816Z
changed the description
Author: Chris Johns
2026-07-30T23:05:08.762Z
assigned to @joel
Author: Chris Johns
2026-07-30T23:05:13.306Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-30T23:08:57.673Z
Not showing up in Coverity any more.
Author: Chris Johns
2026-07-30T23:09:00.223Z
set status to Done
3230 - RSB does not report –rsb-file for patches correctly.¶
Id |
3230 |
State |
closed |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Chris Johns |
Closed by |
Chris Johns |
Created |
2017-11-12T04:45:41.000Z |
Closed |
2026-07-30T22:59:36.392Z |
Updated |
2026-07-30T22:59:36.464Z |
Milestone |
6.3 |
Labels |
priority::normal, tickettype::defect, tool::rtems-source-builder, version::5 |
Link |
|
Merges |
0 |
The reports from the RSB do not report the --rsb-file option correctly.
Author: Chris Johns
2017-11-12T04:46:01.000Z
Status changed from assigned to accepted
Author: Chris Johns
2019-12-12T23:32:22.000Z
Milestone changed from %”5.1” to %”6.1”
Author: Amar Takhar
2024-05-17T01:59:37.817Z
changed the description
Author: Amar Takhar
2024-05-17T02:00:00.357Z
Moving to %6.2 since it’s been bumped once already.
Author: Gedare Bloom
2024-12-04T21:40:35.716Z
Author: Chris Johns
2025-10-02T23:12:55.779Z
added rtems#15 as parent epic
Author: Chris Johns
2026-07-30T22:59:36.433Z
set status to Won’t do
2960 - RSB: Reports modified Git version in case RSB is a Git submodule¶
Id |
2960 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Chris Johns |
Closed by |
Chris Johns |
Created |
2017-03-30T11:50:10.000Z |
Closed |
2026-07-30T22:59:20.618Z |
Updated |
2026-07-30T22:59:20.680Z |
Milestone |
6.3 |
Labels |
old-indefinite, priority::normal, tickettype::defect, tool::rtems-source-builder, version::6 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
In case the RSB is used as a Git submodules the git status yields
git status
# HEAD detached at b64b38e
nothing to commit, working directory clean
leading to
RTEMS Source Builder - Set Builder, 4.12 (b64b38ef076c modified)
Author: Chris Johns
2017-03-30T20:44:03.000Z
Original author: sebastian.huber
Is the bug you would like fixed the
modifiedbeing added to the git hash?
Author: Trac Migrate
2017-03-31T04:55:34.000Z
Original author: sebastian.huber
Replying to Chris Johns:
Is the bug you would like fixed the
modifiedbeing added to the git hash?Yes I think so, nothing is modified. I had some problems to understand the git.status() function in git.py.
Author: Chris Johns
2017-03-31T04:59:40.000Z
Original author: sebastian.huber
The status function should return a dict of discovered states. I wonder if the last
elifshould be anif?
Author: Trac Migrate
2017-06-08T09:09:54.000Z
Original author: sebastian.huber
I tried to fix this, but I have no idea what repo.status() is supposed to do (especially the last elif part).
Author: Chris Johns
2017-09-22T01:27:03.000Z
Original author: sebastian.huber
Replying to Sebastian Huber:
I have no idea what repo.status() is supposed to do (especially the last elif part).
The last
elifpart when there is a valid state picks of the content of a section of thestatusoutput. For example:Untracked files: (use "git add <file>..." to include in what will be committed) xThe
_stateis selected and then the contents of the state are parsed and added to the state or a new state is selected.
Author: Chris Johns
2017-09-22T01:45:26.000Z
Original author: sebastian.huber
I can ignore a detached HEAD as condition for being dirty. That seems reasonable.
I will also ignore untracked files. They should be ignored in a build if nothing is modified. It does assume the build is not modified by untracked files. Untracked cannot be easily handled as I cannot look into the files or make assumptions. This is a change to the initial implementation but I am seeing tool builds with up to date repos that have untracked files like logs, or patches and that is not a true indication of the state. Needing a completely clean directory does seem a little onerous.
Is a modified submodule considered dirty? I think so. For example:
$ git st On branch master Your branch is up-to-date with 'origin/master'. Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) (commit or discard the untracked or modified content in submodules) modified: freebsd-org (new commits, untracked content)
Author: Trac Migrate
2017-11-09T06:27:14.000Z
Original author: sebastian.huber
Milestone changed from %”4.12.0” to %”5.1”
Milestone renamed
Author: Chris Johns
2018-10-14T00:54:02.000Z
Original author: sebastian.huber
Status changed from new to accepted
Author: Chris Johns
2018-10-19T00:10:54.000Z
Original author: sebastian.huber
Milestone changed from %”5.1” to %”Indefinite”
Version set to ~”6”
Author: Amar Takhar
2025-09-05T03:01:05.166Z
changed the description
Author: Chris Johns
2026-07-30T22:59:20.653Z
set status to Won’t do
2780 - Capture engine accesses ‘capture_per_cpu’ without first checking.¶
Id |
2780 |
State |
closed |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Trac Migrate |
Closed by |
Chris Johns |
Created |
2016-08-26T03:45:35.000Z |
Closed |
2026-07-30T22:58:55.874Z |
Updated |
2026-07-30T22:58:55.938Z |
Milestone |
6.3 |
Labels |
old-indefinite, priority::normal, tickettype::defect, version::5, version::6 |
Link |
|
Merges |
0 |
The capture does not check if an open has created the capture_per_cpu data which holds the lock used to check the flags.
Author: Trac Migrate
2017-05-11T07:31:02.000Z
Milestone changed from %”4.12” to %”4.12.0”
Author: Trac Migrate
2017-11-09T06:27:14.000Z
Milestone changed from %”4.12.0” to %”5.1”
Milestone renamed
Author: Chris Johns
2018-10-14T00:51:27.000Z
Milestone changed from %”5.1” to %”Indefinite”
Status changed from new to assigned
Version changed from ~”5” to ~”6”
Author: Amar Takhar
2025-09-05T03:01:02.834Z
changed the description
Author: Chris Johns
2026-07-30T22:58:55.911Z
set status to Won’t do
5310 - Remove Mongoose Web Server from RTEMS 6.3¶
Id |
5310 |
State |
closed |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Chris Johns |
Closed by |
Chris Johns |
Created |
2025-07-24T22:55:06.577Z |
Closed |
2026-07-29T03:20:46.303Z |
Updated |
2026-07-29T03:20:46.369Z |
Milestone |
6.3 |
Labels |
cpukit |
Link |
|
Merges |
0 |
Summary¶
The Mongoose webserver (mghttpd) in RTEMS is old and pre-dates the change to GPL. The project forked and the permissive licensed code lives on as Civitweb. The mghttpd code in RTEMS is from before the split and is unmaintained upstream.
Civitweb can be built using the RSB. It is an active project.
It is recommended that users migrate to Civitweb.
The mghttd code is deprecated in RTEMS 6 and will be removed before RTEMS 7 branches.
It is being removed from 6 as of 6.3 because it is not actively maintained and have CVEs which are addressed in Civitweb.
Related ticket is #5303 for 7
Pre-set options¶
Author: Joel Sherrill
2025-07-24T22:55:06.698Z
set status to To do
Author: Kinsey Moore
2026-05-15T14:31:56.515Z
mentioned in issue #5367
Author: Chris Johns
2026-07-27T02:30:10.972Z
mentioned in merge request !1372
Author: Chris Johns
2026-07-27T02:30:48.248Z
assigned to @chris
Author: Chris Johns
2026-07-27T02:31:00.843Z
set status to In progress
Author: Chris Johns
2026-07-29T03:20:46.339Z
set status to Done
5638 - Fix thread names in top to show classic and POSIX names¶
Id |
5638 |
State |
closed |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Chris Johns |
Closed by |
Chris Johns |
Created |
2026-07-08T22:37:35.518Z |
Closed |
2026-07-29T03:20:09.492Z |
Updated |
2026-07-29T03:20:09.559Z |
Milestone |
6.3 |
Labels |
cpukit::shell |
Link |
|
Merges |
0 |
Summary¶
RTEMS currently has an inconsistent and sort of broken thread name management. Update top to work around the issue of an Object name and a POSIX non-portable name being set on threads.
Author: Chris Johns
2026-07-08T22:37:35.620Z
cloned from #5637
Author: Chris Johns
2026-07-27T02:52:49.937Z
mentioned in merge request !1374
Author: Chris Johns
2026-07-29T03:20:09.530Z
set status to Done
5640 - Add TCB pointer to libdebugger’s extra thread info¶
Id |
5640 |
State |
closed |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Chris Johns |
Closed by |
Chris Johns |
Created |
2026-07-08T22:45:09.545Z |
Closed |
2026-07-29T03:19:13.501Z |
Updated |
2026-07-29T03:19:13.561Z |
Milestone |
6.3 |
Labels |
cpukit::debugger |
Link |
|
Merges |
0 |
Summary¶
Print the TCB or Thread_Control pointer in the thread extra info query output. This is shown when you enter info thread at a GDB prompt.
The TCB is useful then inspecting objects that contain the TCB pointer. For example:
(gdb) p *__mutex
$4 = {
_Queue = {
_Lock = {
_next_ticket = 7632,
_now_serving = 7632
},
_heads = 0x7f49308,
_owner = 0x7f44668,
_name = 0x0
}
}
(gdb) p __mutex->_Queue._owner
$5 = (_Thread_Control *) 0x7f44668
The __mutex->_Queue._owner field is the TCB and if the info thread command shows the TCB for a thread you can see which it is without the need to dump other thread specific details.
Author: Chris Johns
2026-07-08T22:45:09.639Z
cloned from #5639
Author: Chris Johns
2026-07-27T03:34:03.943Z
mentioned in merge request !1376
Author: Chris Johns
2026-07-29T03:19:13.536Z
set status to Done
5666 - Set environment variables from PPCBug GEV data on MVME2700¶
Id |
5666 |
State |
closed |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Chris Johns |
Closed by |
Chris Johns |
Created |
2026-07-28T05:13:10.709Z |
Closed |
2026-07-29T03:18:52.343Z |
Updated |
2026-07-29T03:18:52.410Z |
Milestone |
6.3 |
Labels |
arch:powerpc |
Link |
|
Merges |
0 |
Summary¶
Set environment variables using the MOTLoad Global Environment Variables (GEV) the boot loader maintains. GEV variables are available on some PowerPC BSPs.
This work is part of the `EPICS RTEMS Support Project <https://github.com/epics-base/epics-base/discussions/851>`_to improve the RTEMS initialization in EPCIS. Currently EPICS has very specific code to extract these GEV variables and to use them to initialize the network. Moving the code to RTEMS and using environment variables expands the number of BSPs EPICS could support.
The initial work is for the power/motorola_powerpc BSP.
Author: Chris Johns
2026-07-28T05:13:10.806Z
cloned from #5621
Author: Chris Johns
2026-07-28T05:13:27.967Z
set status to In progress
Author: Chris Johns
2026-07-28T05:15:13.574Z
Backport the fix to 6
Author: Chris Johns
2026-07-28T05:16:47.502Z
mentioned in merge request !1380
Author: Chris Johns
2026-07-29T03:18:52.381Z
set status to Done
5664 - Print all environment variables with the shell getenv command¶
Id |
5664 |
State |
closed |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Chris Johns |
Closed by |
Chris Johns |
Created |
2026-07-28T04:13:28.546Z |
Closed |
2026-07-29T03:17:44.017Z |
Updated |
2026-07-29T03:17:44.081Z |
Milestone |
6.3 |
Labels |
cpukit::shell |
Link |
|
Merges |
0 |
Summary¶
The getenv command only prints the requested environment variable and that makes painful to see all the variables in the table.
Add -a support to print all the environment variables.
Author: Chris Johns
2026-07-28T04:13:28.633Z
cloned from #5572
Author: Chris Johns
2026-07-28T04:13:41.856Z
added rtems#15 as parent item
Author: Chris Johns
2026-07-28T04:13:44.448Z
assigned to @chris
Author: Chris Johns
2026-07-28T04:13:46.945Z
set status to In progress
Author: Chris Johns
2026-07-28T04:14:10.109Z
This command is useful when working with EPICS and environment tables.
Author: Chris Johns
2026-07-28T04:22:20.382Z
mentioned in merge request !1378
Author: Chris Johns
2026-07-29T03:17:44.052Z
set status to Done
5665 - Backport powerpc/beatnik converting MOTLoad GEV variables into env variables¶
Id |
5665 |
State |
closed |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Chris Johns |
Closed by |
Chris Johns |
Created |
2026-07-28T04:27:43.732Z |
Closed |
2026-07-29T03:17:09.929Z |
Updated |
2026-07-29T03:17:09.934Z |
Milestone |
6.3 |
Labels |
arch:powerpc |
Link |
|
Merges |
0 |
Summary¶
Backport converting the MOTLoad GEV variables into environment variables.
Author: Chris Johns
2026-07-28T04:27:43.899Z
added rtems#15 as parent item
Author: Chris Johns
2026-07-28T04:27:43.984Z
set status to In progress
Author: Chris Johns
2026-07-28T04:27:44.130Z
assigned to @chris
Author: Chris Johns
2026-07-28T04:33:51.474Z
mentioned in merge request !1379
Author: Chris Johns
2026-07-29T03:17:09.972Z
set status to Done
5652 - Backport to 6 branch “cpukit/flashdev: Clarify interface and update consumers”¶
Id |
5652 |
State |
closed |
Type |
ISSUE |
Author |
Kinsey Moore |
Assignee(s) |
Kinsey Moore |
Closed by |
Chris Johns |
Created |
2026-07-16T21:47:30.709Z |
Closed |
2026-07-28T01:36:24.917Z |
Updated |
2026-07-28T01:36:24.988Z |
Milestone |
6.3 |
Labels |
device::flash |
Link |
|
Merges |
0 |
The following discussion from !1353 should be addressed:
[] @opticron started a discussion:
This needs a backport to 6 branch.
Author: Kinsey Moore
2026-07-16T21:47:30.924Z
added rtems#15 as parent item
Author: Kinsey Moore
2026-07-16T21:47:31.020Z
set status to To do
Author: Kinsey Moore
2026-07-16T21:50:56.503Z
mentioned in merge request !1354
Author: Chris Johns
2026-07-27T02:38:20.461Z
mentioned in merge request !1373
Author: Chris Johns
2026-07-27T03:07:38.525Z
set status to In progress
Author: Chris Johns
2026-07-27T03:07:48.615Z
assigned to @opticron
Author: Chris Johns
2026-07-28T01:36:24.960Z
set status to Done
5661 - Backport PowerPC ASM warning fixes¶
Id |
5661 |
State |
closed |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Chris Johns |
Closed by |
Chris Johns |
Created |
2026-07-27T01:23:17.447Z |
Closed |
2026-07-28T01:35:49.395Z |
Updated |
2026-07-28T01:35:49.466Z |
Milestone |
6.3 |
Labels |
arch:powerpc |
Link |
|
Merges |
0 |
Backport:
e74e5e1644ae9cc8fb95d8f457cab06c8b3e21a6
16faa870a571dc6e7b89ef53d1fa385fa672112d
db19f09a21e76827188e5c12dc2b5c39730211c2
Author: Chris Johns
2026-07-27T01:23:17.678Z
added rtems#15 as parent item
Author: Chris Johns
2026-07-27T01:23:17.793Z
set status to In progress
Author: Chris Johns
2026-07-27T01:23:18.001Z
assigned to @chris
Author: Chris Johns
2026-07-27T01:36:10.811Z
changed the description
Author: Chris Johns
2026-07-27T02:10:51.965Z
mentioned in merge request !1371
Author: Chris Johns
2026-07-28T01:35:49.435Z
set status to Done
5662 - Libdebugger register block corruption¶
Id |
5662 |
State |
closed |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Chris Johns |
Closed by |
Chris Johns |
Created |
2026-07-27T03:17:28.253Z |
Closed |
2026-07-28T01:35:38.189Z |
Updated |
2026-07-28T01:35:38.259Z |
Milestone |
6.3 |
Labels |
cpukit::debugger |
Link |
|
Merges |
0 |
Summary¶
If more than 32 threads are active the thread->register pointer may end up referencing an old block pointer depending on the value returned by a realloc call. This has not been a problem on ARM or AARCH64 builds but is a problem on PowerPC although it is a definite issue on all architectures.
I suspect a key difference is PowerPC has a 412 byte register buffer per thread, significantly more than ARM and AARCH64, so a block resize using realloc is more likely to results in the pointer returned having a different address. The corruption is each thread has taken a pointer to the registers from the original block for each thread and it is not re-based after the realloc moves the pointer.
Solution¶
Add a rebase handler to the block code that is called if the base pointer of a block moves so the pointer can be remapped.
_Note_, only the registers is effected as all other blocks do not have references taken.
Steps to reproduce¶
Run a simple EPICS IOC application on PowerPC, connect then list the threads and then print thread’s registers. The values are garbage.
Author: Chris Johns
2026-07-27T03:17:28.357Z
cloned from #5635
Author: Chris Johns
2026-07-27T03:18:37.524Z
set status to In progress
Author: Chris Johns
2026-07-27T03:27:15.048Z
mentioned in merge request !1375
Author: Chris Johns
2026-07-27T03:38:44.621Z
added rtems#15 as parent item
Author: Chris Johns
2026-07-28T01:35:38.229Z
set status to Done
4922 - QEMU delivers back-to-back timer ticks after task switches¶
Id |
4922 |
State |
closed |
Type |
ISSUE |
Author |
Kinsey Moore |
Assignee(s) |
Trac Migrate |
Closed by |
Gedare Bloom |
Created |
2023-07-06T17:01:01.000Z |
Closed |
2026-07-02T18:43:34.482Z |
Updated |
2026-07-02T18:43:34.487Z |
Milestone |
6.3 |
Labels |
old-indefinite, priority::normal, tickettype::defect, tool::rtems-source-builder, version::6 |
Link |
|
Merges |
0 |
A selection of tests in the RTEMS testsuite will fail consistently or intermittently when running under QEMU while they pass consistently on real hardware or more accurate simulators. This is due to QEMU getting context-switched out on the host system and when it gets more run time it delivers all outstanding clock ticks as quickly as possible according to the wall clock. Naturally, this is more severe on heavily loaded systems. The tests that fail in this manner are heavily dependent on timing and inter-tick processing to verify their correct operation.
The tests known to fail in this manner on ARM and AArch64 BSPs are at least: psx12 psxclock psxtimes01 psxualarm rtmonuse rtmonusxtimes01 smpclock01 smpfatal01 smpfatal03 smpmrsp01 smpmutex01 smppsxmutex01 smpschedaffinity01 smpschedaffinity02 smpschededf01 smpschededf03 smpscheduler04 smpthreadpin01 sp04 sp20 sp68 sp69 sp71 spcpucounter01 spedfsched02 spedfsched04 spintrcritical01 spintrcritical02 spintrcritical03 spintrcritical04 spintrcritical05 spintrcritical06 spintrcritical07 spintrcritical08 spintrcritical09 spintrcritical10 spintrcritical11 spintrcritical12 spintrcritical13 spintrcritical14 spintrcritical15 spintrcritical16 spintrcritical17 spintrcritical18 spintrcritical19 spintrcritical20 spintrcritical21 spintrcritical22 spintrcritical23 spintrcritical24 sprmsched01 sptimecounter01 sptimecounter02 sptimecounter04 ttest02
This issue does not exist to rectify the situation with QEMU so much as to document the issue so that it can be referenced from non-pass expected test outcomes for those affected BSPs that are dedicated to the QEMU platform.
Author: Kinsey Moore
2023-07-06T17:22:16.000Z
I mistakenly left out these tests: validation-0 validation-smp-only-0
Author: Joel Sherrill
2023-07-06T17:46:25.000Z
One of the challenges we have had on issues like this where a BSP runs fine on hardware but not on the simulator is that if the same variant name is used in both cases, there is no way to distinguish HW vs simulator expectation. On the aarch64, I don’t think this applies but at least for sparc and i386, the same BSP variant runs on HW and simulator. Our test annotations apply to a BSP – not BSP plus “hw/sim”.
Intermittent failures are worse because you can’t mark them as expected failures either.
Author: Kinsey Moore
2023-07-06T18:14:00.000Z
Yes, those reasons and differing peripheral support are exactly why I’ve made sure to have separate QEMU BSPs for all the work I’ve done. I suspect that sparc and i386 should really have separate BSPs for at least QEMU and maybe also for other simulators that have similar problems.
Author: Trac Migrate
2023-07-10T13:49:21.000Z
In [changeset:”f46c15fd76a4c1904760360cd220a061d74edad4/rtems” f46c15f/rtems]:
spec: Add QEMU test annotations QEMU is known to fail certain tests intermittently due to clock tick delivery issues. This defines those tests as intermittent for BSPs intended to run on QEMU alone. Updates #4922 Updates #4072
Author: Amar Takhar
2025-09-05T02:57:54.725Z
changed the description
Author: Gedare Bloom
2026-05-15T15:15:44.609Z
mentioned in merge request rtems/tools/rtems-tools!87
Author: Gedare Bloom
2026-05-15T16:20:25.028Z
mentioned in commit gedare/rtems-tools@7a80eb79f50fa963875afd79c9d956f6bdc60459
Author: Gedare Bloom
2026-07-02T18:43:34.516Z
set status to Done
5589 - Move powerpc/beatnik BSP to generic interrupts¶
Id |
5589 |
State |
closed |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Chris Johns |
Closed by |
Chris Johns |
Created |
2026-05-25T22:28:53.843Z |
Closed |
2026-06-01T22:21:08.191Z |
Updated |
2026-06-01T22:21:08.261Z |
Milestone |
6.3 |
Labels |
arch:powerpc |
Link |
|
Merges |
0 |
Move the powerpc/beatnik BSP to the generic interrupt support so it can be used LibBSD.
Author: Chris Johns
2026-05-25T22:28:53.973Z
cloned from #5567
Author: Chris Johns
2026-05-25T22:29:12.636Z
added rtems#15 as parent epic
Author: Chris Johns
2026-05-25T22:29:18.578Z
set status to In progress
Author: Chris Johns
2026-05-26T01:19:51.790Z
mentioned in merge request !1262
Author: Chris Johns
2026-06-01T22:21:08.231Z
set status to Done
4846 - Code for test software¶
Id |
4846 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Closed by |
Kinsey Moore |
Created |
2023-02-09T14:54:34.000Z |
Closed |
2026-05-24T04:17:24.699Z |
Updated |
2026-05-24T04:17:24.790Z |
Milestone |
6.3 |
Labels |
arch:sparc, old-indefinite, priority::normal, qualification, resolution::wontfix, tickettype::defect, version::6 |
Link |
|
Merges |
1 |
Original author: dppinto
Within function bsp_interrupt_raise ther is code active despite described as being dangerous and only to be used for test purposes. It would be a good idea to insert a pragma in the code to present a warning when this is included/used. -> “#pragma GCC warning message”
Additional Notes: To raise an IRQ# from 0-15 there is a proper register that permits that, but to raise IRQ# from 31-16 it is needed to write on top of the pending associated IRQ bit, which can override an already IRQ pending in that line. That is why that code may be dangerous and in the case of forcing IRQ# from 31-16 can only be used for testing.
This ticket was raised as an outcome of the Independent SW Verification and Validation (ISVV) for ESA-promoted RTEMS SMP Qualification Data Packs (https://rtems-qual.io.esa.int). Original ISVV reference for this issue is RTEMS-SMP-CODE-VER-044.
File list: bspssparcleon3starteirq.c (function bsp_interrupt_raise) (line 154-158)
Author: Trac Migrate
2023-02-10T15:08:06.000Z
Original author: dppinto
Milestone set to %”6.1”
Resolution set to ~”wontfix”
Status changed from new to closed
This warning is pretty useless since it is invisible to the user. The hardware limitations are documented in the hardware manuals. We could introduce some sort of a test mode which guards this feature. To keep it simple I tend to not fix it.
Author: Trac Migrate
2023-02-13T08:23:31.000Z
Original author: dppinto
Milestone changed from %”6.1” to %”Indefinite”
Resolution ~”wontfix” deleted
Status changed from closed to reopened
One option is to remove the raise implementation for extended interrupts and test the extended interrupts through BSP-specific code.
Author: Trac Migrate
2023-02-13T08:24:00.000Z
Original author: dppinto
Owner set to Needs Funding
Status changed from reopened to assigned
Author: Amar Takhar
2024-04-25T20:50:33.707Z
changed the description
Author: Samuel Viegas
2026-02-25T11:40:19.736Z
mentioned in merge request !1078
Author: Kinsey Moore
2026-05-24T04:17:26.424Z
set status to Done
5580 - Backport to 6 branch: “bsps/zynq-uart: fix parity configuration handling”¶
Id |
5580 |
State |
closed |
Type |
ISSUE |
Author |
Kinsey Moore |
Assignee(s) |
Kinsey Moore |
Closed by |
Kinsey Moore |
Created |
2026-05-18T19:15:39.231Z |
Closed |
2026-05-18T22:25:59.960Z |
Updated |
2026-05-18T22:26:00.115Z |
Milestone |
6.3 |
Link |
|
Merges |
0 |
The following discussion from !1212 should be addressed:
[] @opticron started a discussion:
This needs to be backported to 6 branch at least.
Author: Kinsey Moore
2026-05-18T19:15:39.396Z
added rtems#15 as parent epic
Author: Kinsey Moore
2026-05-18T19:15:39.488Z
set status to To do
Author: Kinsey Moore
2026-05-18T19:15:39.596Z
assigned to @opticron
Author: Kinsey Moore
2026-05-18T19:16:02.079Z
mentioned in merge request !1212
Author: Kinsey Moore
2026-05-18T19:21:11.496Z
mentioned in merge request !1252
Author: Kinsey Moore
2026-05-18T22:26:00.018Z
set status to Done
4890 - Defect: devel/qemu does not build¶
Id |
4890 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Closed by |
Kinsey Moore |
Created |
2023-03-24T04:03:34.000Z |
Closed |
2026-05-15T17:29:41.129Z |
Updated |
2026-05-15T17:29:41.285Z |
Milestone |
6.3 |
Labels |
priority::normal, tickettype::defect, tool, version::6 |
Link |
|
Merges |
0 |
Original author: jkillelea
The command ../source-builder/sb-set-builder --prefix=$HOME/projects/rtems/6 devel/qemu.bset fails on Ubuntu 22.04.
The reported error is:
config: devel/qemu-5.2.0-1.cfg
package: qemu-5.2.0-rc1-x86_64-linux-gnu-1
building: qemu-5.2.0-rc1-x86_64-linux-gnu-1
error: building qemu-5.2.0-rc1-x86_64-linux-gnu-1
Build FAILED
See error report: rsb-report-qemu-5.2.0-rc1-x86_64-linux-gnu-1.txt
Note: In some cases the error appears only in
the complete build log (see --log option)
error: building qemu-5.2.0-rc1-x86_64-linux-gnu-1
Build Set: Time 0:04:25.439249
Build FAILED
The end of rsb-report-qemu-5.2.0-rc1-x86_64-linux-gnu-1.txt says:
NOTE: guest cross-compilers enabled: cc cc
The Meson build system
Version: 0.63.2
Source dir: /home/jacob/projects/rtems/src/rsb/rtems/build/qemu-5.2.0-rc1-x86_64-linux-gnu-1/qemu-5.2.0-rc1
Build dir: /home/jacob/projects/rtems/src/rsb/rtems/build/qemu-5.2.0-rc1-x86_64-linux-gnu-1/build
Build type: native build
WARNING: You should add the boolean check kwarg to the run_command call.
It currently defaults to false,
but it will default to true in future releases of meson.
See also: https://github.com/mesonbuild/meson/issues/9300
Project name: qemu
Project version: 5.1.91
../qemu-5.2.0-rc1/meson.build:1:0: ERROR: Compiler gcc -O2 -g -pipe -I/home/jacob/projects/rtems/src/rsb/rtems/build/tmp/sb-1000/devel/qemu/home/jacob/projects/rtems/6/include -I/home/jacob/projects/rtems/src/rsb/rtems/build/tmp/sb-1000/devel/qemu/home/jacob/projects/rtems/6/include/glib-2.0 -I/home/jacob/projects/rtems/src/rsb/rtems/build/tmp/sb-1000/devel/qemu/home/jacob/projects/rtems/6/lib/glib-2.0/include -I/home/jacob/projects/rtems/src/rsb/rtems/build/tmp/sb-1000/devel/qemu/home/jacob/projects/rtems/6/include/pixman-1 can not compile programs.
A full log can be found at /home/jacob/projects/rtems/src/rsb/rtems/build/qemu-5.2.0-rc1-x86_64-linux-gnu-1/build/meson-logs/meson-log.txt
ERROR: meson setup failed
shell cmd failed: /bin/sh -ex /home/jacob/projects/rtems/src/rsb/rtems/build/qemu-5.2.0-rc1-x86_64-linux-gnu-1/do-build
error: building qemu-5.2.0-rc1-x86_64-linux-gnu-1
build/qemu-5.2.0-rc1-x86_64-linux-gnu-1/build/meson-logs/meson-log.txt says:
linker stdout:
GNU ld (GNU Binutils for Ubuntu) 2.39
Copyright (C) 2022 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
linker stderr:
collect2 version 12.2.0
/usr/bin/ld -plugin /usr/lib/gcc/x86_64-linux-gnu/12/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper -plugin-opt=-fresolution=/tmp/ccm0GBvx.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/Scrt1.o /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/12/crtbeginS.o -L/home/jacob/projects/rtems/src/rsb/rtems/build/tmp/sb-1000/devel/qemu/home/jacob/projects/rtems/6/lib -L/usr/lib/gcc/x86_64-linux-gnu/12 -L/usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/12/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/12/../../.. --version -rpath /home/jacob/projects/rtems/6/lib -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-linux-gnu/12/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/crtn.o
Sanity testing C compiler: gcc -O2 -g -pipe -I/home/jacob/projects/rtems/src/rsb/rtems/build/tmp/sb-1000/devel/qemu/home/jacob/projects/rtems/6/include -I/home/jacob/projects/rtems/src/rsb/rtems/build/tmp/sb-1000/devel/qemu/home/jacob/projects/rtems/6/include/glib-2.0 -I/home/jacob/projects/rtems/src/rsb/rtems/build/tmp/sb-1000/devel/qemu/home/jacob/projects/rtems/6/lib/glib-2.0/include -I/home/jacob/projects/rtems/src/rsb/rtems/build/tmp/sb-1000/devel/qemu/home/jacob/projects/rtems/6/include/pixman-1
Is cross compiler: False.
Sanity check compiler command line: gcc -O2 -g -pipe -I/home/jacob/projects/rtems/src/rsb/rtems/build/tmp/sb-1000/devel/qemu/home/jacob/projects/rtems/6/include -I/home/jacob/projects/rtems/src/rsb/rtems/build/tmp/sb-1000/devel/qemu/home/jacob/projects/rtems/6/include/glib-2.0 -I/home/jacob/projects/rtems/src/rsb/rtems/build/tmp/sb-1000/devel/qemu/home/jacob/projects/rtems/6/lib/glib-2.0/include -I/home/jacob/projects/rtems/src/rsb/rtems/build/tmp/sb-1000/devel/qemu/home/jacob/projects/rtems/6/include/pixman-1 sanitycheckc.c -o sanitycheckc.exe -D_FILE_OFFSET_BITS=64 -Wl,-rpath -Wl,/home/jacob/projects/rtems/6/lib -L/home/jacob/projects/rtems/src/rsb/rtems/build/tmp/sb-1000/devel/qemu/home/jacob/projects/rtems/6/lib
Sanity check compile stdout:
-----
Sanity check compile stderr:
/usr/bin/ld: cannot find : No such file or directory
collect2: error: ld returned 1 exit status
-----
../qemu-5.2.0-rc1/meson.build:1:0: ERROR: Compiler gcc -O2 -g -pipe -I/home/jacob/projects/rtems/src/rsb/rtems/build/tmp/sb-1000/devel/qemu/home/jacob/projects/rtems/6/include -I/home/jacob/projects/rtems/src/rsb/rtems/build/tmp/sb-1000/devel/qemu/home/jacob/projects/rtems/6/include/glib-2.0 -I/home/jacob/projects/rtems/src/rsb/rtems/build/tmp/sb-1000/devel/qemu/home/jacob/projects/rtems/6/lib/glib-2.0/include -I/home/jacob/projects/rtems/src/rsb/rtems/build/tmp/sb-1000/devel/qemu/home/jacob/projects/rtems/6/include/pixman-1 can not compile programs.
It looks like there’s an argument missing, since ld cannot find <empty string here?>:.
Author: Amar Takhar
2024-04-25T20:50:43.188Z
changed the description
Author: Kinsey Moore
2026-05-15T17:14:44.068Z
@jkillelea Is this still reproducible? We moved to the 5.2.0 non-RC release a while back and I think we’ve moved to a 9.x release more recently.
Author: Jacob Killelea
2026-05-15T17:14:44.012Z
Hey @opticron, with the latest
rsb(cadcd4195781ea8c5713d4a36e2e67ab681d4906), it builds fine. You can close this ticket or I can.
Author: Kinsey Moore
2026-05-15T17:29:41.185Z
set status to Done
3431 - Eliminate use of __ppc_generic and other PowerPC model defines in BSP configure.ac¶
Id |
3431 |
State |
closed |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Trac Migrate |
Closed by |
Kinsey Moore |
Created |
2018-05-18T13:20:18.000Z |
Closed |
2026-05-15T15:37:19.687Z |
Updated |
2026-05-15T15:37:19.842Z |
Milestone |
6.3 |
Labels |
arch:powerpc, old-indefinite, priority::normal, tickettype::defect, version::5, version::6 |
Link |
|
Merges |
0 |
Reduce use of PowerPC CPU model defines now in various PowerPC BSP configure.ac required bsps/powerpc/include/rtems/powerpc/powerpc.h. Some may indicate that the set of predefined CPP macros set as a side-effect of -mcpu=XXX are incomplete.
Author: Joel Sherrill
2018-10-13T22:57:17.000Z
Milestone changed from %”5.1” to %”5.2”
Author: Chris Johns
2018-10-14T00:22:12.000Z
Milestone changed from %”5.2” to %”Indefinite”
Version changed from ~”5” to ~”6”
Author: Amar Takhar
2025-09-05T03:01:11.475Z
changed the description
Author: Kinsey Moore
2026-05-15T15:37:19.743Z
set status to Done
Author: Kinsey Moore
2026-05-15T15:37:20.495Z
This is no longer relevant and _ppc_generic does not appear in the current repository.
4188 - Quick Start 2.6 Not working for me and some tests failing for sparc-rtems6¶
Id |
4188 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Closed by |
Kinsey Moore |
Created |
2020-11-24T14:00:27.000Z |
Closed |
2026-05-15T15:26:20.236Z |
Updated |
2026-05-15T15:26:20.416Z |
Milestone |
6.3 |
Labels |
old-indefinite, priority::normal, tickettype::defect, version::6 |
Link |
|
Merges |
0 |
Original author: rmueller
The chapter to test the test the built BSP is not working for me in its current form. I had to use the following command to perform the tests:
rtems-test –rtems-bsp=erc32-sis ../../rtems/6/sparc-rtems6/erc32/tests
But maybe I also did something wrong? I took care to follow the guide exactly and the BSP was not installed in the src path like recommended. Maybe it would be a good idea to update the command specified in 2.6.
Also, some of the tests failed apparently:
Passed: 577 Failed: 3 User Input: 6 Expected Fail: 1 Indeterminate: 0 Benchmark: 3 Timeout: 0 Test too long: 0 Invalid: 0 Wrong Version: 0 Wrong Build: 0 Wrong Tools: 0 —————— Total: 590 Failures: User Input: capture.exe dl10.exe fileio.exe monitor.exe termios.exe top.exe Expected Fail: psxfenv01.exe Benchmark: dhrystone.exe linpack.exe whetstone.exe Average test time: 0:00:00.264940 Testing time : 0:02:36.314482
Kind Regards Robin
Author: Trac Migrate
2020-11-24T14:14:06.000Z
Original author: rmueller
I am correcting the used command:
cd $HOME/quick-start/rtems/6 bin/rtems-test –rtems-bsp=erc32-sis sparc-rtems6/erc32/tests
Author: Trac Migrate
2020-12-03T17:09:08.000Z
Original author: rmueller
Patch was sent to address this issue
Author: Trac Migrate
2020-12-18T10:44:30.000Z
Original author: rmueller
Version set to ~”6”
Author: Trac Migrate
2020-12-18T11:33:17.000Z
Original author: rmueller
Attachment mueller-quickstart-test-fix.patch added
Fixes for Quick Start commands to run tests
Author: Amar Takhar
2025-09-05T02:57:46.002Z
changed the description
Author: Kinsey Moore
2026-05-15T15:26:20.292Z
set status to Done
Author: Kinsey Moore
2026-05-15T15:26:21.103Z
The documentation is now clear about needing to adjust the path based on how you performed the build.
4187 - Update QuickStart 2.4 for git install¶
Id |
4187 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Closed by |
Kinsey Moore |
Created |
2020-11-24T10:54:49.000Z |
Closed |
2026-05-15T15:11:03.971Z |
Updated |
2026-05-15T15:11:04.125Z |
Milestone |
6.3 |
Labels |
doc, priority::normal, tickettype::defect, version::6 |
Link |
|
Merges |
0 |
Original author: rmueller
When installing the tool suite for a git clone, the build set 5/rtems-sparc does not appear to be available anymore.
It would be a good idea to update to Quick Start guide accordingly.
Running ../source-builder/sb-set-builder –list-bsets yields the list of build sets and 5/rtems-sparc is not among them.
So installing 5/rtems-sparc is not possible.
Kind Regards Robin
Author: Chris Johns
2020-12-01T23:08:14.000Z
Original author: rmueller
Would you be able to provide a patch to the documentation to update the Quick Start guide?
Author: Trac Migrate
2020-12-02T10:10:24.000Z
Original author: rmueller
I can look into it. It’s probably a better idea to adapt the getting the git sources section to checkout version 5 instead.
Author: Trac Migrate
2020-12-18T11:16:20.000Z
Original author: rmueller
Version set to ~”6”
Author: Trac Migrate
2020-12-18T11:19:52.000Z
Original author: rmueller
Attachment mueller-version-5-6-replacements.patch added
Version 5/6 fixes for QuickStart
Author: Amar Takhar
2024-04-25T20:48:30.149Z
changed the description
Author: Kinsey Moore
2026-05-15T15:11:04.026Z
set status to Done
Author: Kinsey Moore
2026-05-15T15:11:04.692Z
The documentation has been updated and it’s a bit more clear that you’ll need to adapt the versions to what you downloaded.
4825 - Issue building stack using RTEMS quick start guide¶
Id |
4825 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Closed by |
Kinsey Moore |
Created |
2023-01-25T17:34:10.000Z |
Closed |
2026-05-15T14:57:26.567Z |
Updated |
2026-05-15T15:00:51.576Z |
Milestone |
6.3 |
Labels |
priority::normal, tickettype::defect, version::6 |
Link |
|
Merges |
0 |
Original author: OneV_2
In section 2.3 of the quick start guide quick start, when using the curl command, it downloads the release version 5.
curl https://ftp.rtems.org/pub/rtems/releases/5/5.1/sources/rtems-source-builder-5.1.tar.xz | tar xJf -
In section 2.4, the command
../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 6/rtems-sparc tries to install the suite by looking for version 6, but since the curl downloads version 5, the install suite fails with an error. error: no build set file found
Author: Chris Johns
2025-09-19T01:42:02.920Z
changed the description
Author: Kinsey Moore
2026-05-15T14:57:26.624Z
set status to Done
Author: Kinsey Moore
2026-05-15T14:57:27.319Z
The documentation surrounding that command in section 2.3 is clear that it is an example of how to obtain release sources (and that you should expect to adapt further commands for this situation) and the build command documentation in 2.4 is also clear that you should adapt the version specified to your downloaded sources.
Author: Amar Takhar
2026-05-15T15:00:51.551Z
set status to Won’t do
4773 - Can’t build ATSAM BSP¶
Id |
4773 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Chris Johns |
Closed by |
Kinsey Moore |
Created |
2022-12-12T22:05:47.000Z |
Closed |
2026-05-15T15:00:32.361Z |
Updated |
2026-05-15T15:00:32.513Z |
Milestone |
6.3 |
Labels |
bsp, priority::normal, tickettype::task, version::6 |
Link |
|
Merges |
0 |
Original author: novium.kyle
I have been trying to build the BSP for the ATSAM architecture following the Quick Start Guide and the RSB BSP Build. However, the build keeps failing.
RSB seems to be set up properly:
$ ../source-builder/sb-check
RTEMS Source Builder - Check, 6 (65f83cf973d6)
Environment is ok
And I can see the bset:
$ ../source-builder/sb-set-builder --list-bsets
RTEMS Source Builder - Set Builder, 6 (65f83cf973d6)
Examining: config
Examining: ../source-builder/config
Examining: ../bare/config
Examining: config
...
7/rtems-x86_64.bset
bsps/atsamv.bset
bsps/beagleboneblack.bset
...
This is the command I’m trying to use:
$ ../source-builder/sb-set-builder --prefix=$HOME/qs/rtems/6 --target=arm-rtems6 --with-rtems-bsp=atsamv --with-rtems-tests=yes 6/rtems-kernel
RTEMS Source Builder - Set Builder, 6 (65f83cf973d6)
Build Set: 6/rtems-kernel
config: tools/rtems-kernel-6.cfg
package: rtems-kernel-bsps-1
building: rtems-kernel-bsps-1
error: building rtems-kernel-bsps-1
Build FAILED
See error report: rsb-report-rtems-kernel-bsps-1.txt
error: building rtems-kernel-bsps-1
Build Set: Time 0:00:00.301361
Build FAILED
I have also tried:
--with-rtems-bsp=atsam
and:
--with-rtems-bsp=arm
This is the error from the log file mentioned:
building: rtems-kernel-bsps-1
run: /bin/sh -ex /home/kyle/qs/src/rsb/rtems/build/rtems-kernel-bsps-1/do-build
+ export SB_ORIG_PATH=/home/kyle/.vscode-server/bin/5235c6bb189b60b01b1f49062f4ffa42384f8c91/bin/remote-cli:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/mnt/c/windows/system32:/mnt/c/windows:/mnt/c/windows/System32/Wbem:/mnt/c/windows/System32/WindowsPowerShell/v1.0/:/mnt/c/windows/System32/OpenSSH/:/mnt/c/Program Files (x86)/Windows Kits/8.1/Windows Performance Toolkit/:/mnt/c/Program Files/Microchip/xc32/v4.20/bin:/mnt/c/Program Files/Docker/Docker/resources/bin:/mnt/c/ProgramData/chocolatey/bin:/mnt/c/Program Files/Microsoft VS Code/bin:/mnt/c/Program Files/Git/cmd:/mnt/c/Program Files/TortoiseSVN/bin:/mnt/c/Program Files/nodejs/:/mnt/c/Program Files/gs/gs9.56.1/bin:/mnt/c/Users/kyle.williams/AppData/Local/Microsoft/WindowsApps:/mnt/c/tools/neovim/nvim-win64/bin:/mnt/c/Users/kyle.williams/AppData/Roaming/npm:/snap/bin
/home/kyle/qs/src/rsb/rtems/build/rtems-kernel-bsps-1/do-build: 4: export: (x86)/NVIDIA: bad variable name
shell cmd failed: /bin/sh -ex /home/kyle/qs/src/rsb/rtems/build/rtems-kernel-bsps-1/do-build
error: building rtems-kernel-bsps-1
What am I doing wrong here? And where in the manual is this explained?
Author: Joel Sherrill
2022-12-14T23:38:10.000Z
Original author: novium.kyle
Owner set to @chrisj
Status changed from new to assigned
I normally just use the RSB to build the tools and then waf to build the BSP. This procedure is covered in the Users Manual. This works well so I am not sure what happened here unless the kernel RSB bset has an issue.
In fact, today I posted results from the rtems-bsp-builder tool which builds every BSP in multiple configurations and there were no failures. The atsamv built fine per https://lists.rtems.org/pipermail/build/2022-December/038438.html.
My guess at this point is that your $PATH has a space in it based on this output from your post:
/home/kyle/qs/src/rsb/rtems/build/rtems-kernel-bsps-1/do-build: 4: export: (x86)/NVIDIA: bad variable nameBeyond that, is there something in a log or rsb-* file which might indicate what went wrong?
Author: Trac Migrate
2022-12-21T03:17:30.000Z
Original author: novium.kyle
That $PATH problem was my mistake. I had started a new shell when I went to reproduce the problem and copy the output for this ticket. I forgot to do the export on my $PATH which typically is this:
/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/kyle/qs/rtems/6/binIn which case the error is this:
+ ./waf configure --prefix=/home/kyle/qs/rtems/6 --rtems-config=config.ini Setting top to : /home/kyle/qs/src/rsb/rtems/build/rtems-kernel-bsps-1/rtems-kernel-bsps-1-d0b92735b0dfd509e1edb82c7145042b67714f43/rtems-d0b92735b0dfd509e1edb82c7145042b67714f43 Setting out to : /home/kyle/qs/src/rsb/rtems/build/rtems-kernel-bsps-1/rtems-kernel-bsps-1-d0b92735b0dfd509e1edb82c7145042b67714f43/rtems-d0b92735b0dfd509e1edb82c7145042b67714f43/build Regenerate build specification cache (needs a couple of seconds)... Section name 'atsamv' is a malformed 'arch/bsp' tuple (complete log in /home/kyle/qs/src/rsb/rtems/build/rtems-kernel-bsps-1/rtems-kernel-bsps-1-d0b92735b0dfd509e1edb82c7145042b67714f43/rtems-d0b92735b0dfd509e1edb82c7145042b67714f43/build/config.log) shell cmd failed: /bin/sh -ex /home/kyle/qs/src/rsb/rtems/build/rtems-kernel-bsps-1/do-build error: building rtems-kernel-bsps-1The line:
Section name 'atsamv' is a malformed 'arch/bsp' tuplegave me a clue. So I used:
../source-builder/sb-set-builder --prefix=$HOME/qs/rtems/6 --target=arm-rtems6 --with-rtems-bsp=arm/atsamv --with-rtems-tests=yes 6/rtems-kernelWhich begs the question, why does the Quick Start Guide use:
--with-rtems-bsp=erc32in Section 2.5.1 if its supposed to be ‘arch/bsp’?
But that command seems to complete successfully:
$ ../source-builder/sb-set-builder --prefix=$HOME/qs/rtems/6 --target=arm-rtems6 --with-rtems-bsp=arm/atsamv --with-rtems-tests=yes 6/rtems-kernel RTEMS Source Builder - Set Builder, 6 (65f83cf973d6) Build Set: 6/rtems-kernel config: tools/rtems-kernel-6.cfg package: rtems-kernel-bsps-1 building: rtems-kernel-bsps-1 sizes: rtems-kernel-bsps-1: 225.306MB (installed: 33.319MB) cleaning: rtems-kernel-bsps-1 reporting: tools/rtems-kernel-6.cfg -> rtems-kernel-bsps-1.txt reporting: tools/rtems-kernel-6.cfg -> rtems-kernel-bsps-1.xml staging: rtems-kernel-bsps-1 -> /home/kyle/qs/src/rsb/rtems/build/tmp/sb-1000-staging installing: rtems-kernel-bsps-1 -> /home/kyle/qs/rtems/6 cleaning: rtems-kernel-bsps-1 installing: 6/rtems-kernel -> /home/kyle/qs/rtems/6 clean staging: 6/rtems-kernel Staging Size: 33.323MB Build Set: Time 0:00:15.271741But then the test fails:
$ rtems-test --rtems-bsp=arm/atsamv build/arm/atsamv RTEMS Testing - Tester, 6.0.not_released Command Line: /home/kyle/qs/rtems/6/bin/rtems-test --rtems-bsp=arm/atsamv build/arm/atsamv Host: Linux DESKTOP-U0P8IUP 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 Python: 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0] Host: Linux-5.10.16.3-microsoft-standard-WSL2-x86_64-with-glibc2.35 (Linux DESKTOP-U0P8IUP 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64) error: cannot find bsp configuration file: arm/atsamv.iniWhere am I going wrong? Am I malforming the command parameters again? Are the proper forms documented anywhere? I haven’t seen anything in the manual yet.
Author: Trac Migrate
2023-05-19T04:04:25.000Z
Original author: novium.kyle
I can confirm this is an error in the documentation - it should be made with a slash, that is
../rsb/source-builder/sb-set-builder --prefix=$HOME/rtems/6/ --host=sparc-rtems6 --with-rtems-bsp=sparc/erc32 6/rtems-libbsd, or../rsb/source-builder/sb-set-builder --prefix=$HOME/rtems/6/ --target=aarch64-rtems6 --with-rtems-bsp=aarch64/raspberrypi4b --with-rtems-test=yes 6/rtems-kernel
Author: Chris Johns
2025-09-19T01:42:02.538Z
changed the description
Author: Kinsey Moore
2026-05-15T15:00:32.416Z
set status to Done
Author: Kinsey Moore
2026-05-15T15:00:33.131Z
This has been fixed in the documentation.
5367 - Remove Mongoose Web Server¶
Id |
5367 |
State |
closed |
Type |
ISSUE |
Author |
Chris Johns |
Closed by |
Kinsey Moore |
Created |
2025-10-02T23:27:00.074Z |
Closed |
2026-05-15T14:38:37.517Z |
Updated |
2026-05-15T14:38:37.703Z |
Milestone |
6.3 |
Link |
|
Merges |
0 |
Summary¶
The Mongoose webserver (mghttpd) in RTEMS is old and pre-dates the change to GPL. The project forked and the permissive licensed code lives on as Civitweb. The mghttpd code in RTEMS is from before the split and is unmaintained upstream.
Civitweb can be built using the RSB. It is an active project.
It is recommended that users migrate to Civitweb.
The mghttd code is deprecated in RTEMS 6 and will be removed before RTEMS 7 branches.
Pre-set options¶
Author: Joel Sherrill
2025-07-18T13:44:44.807Z
changed the description
Author: Joel Sherrill
2025-07-18T13:45:29.487Z
mentioned in issue #5304
Author: Joel Sherrill
2025-07-24T22:55:11.149Z
mentioned in issue #5310
Author: Chris Johns
2025-10-02T23:24:55.117Z
added #10 as parent epic
Author: Chris Johns
2025-10-02T23:26:11.606Z
added #15 as parent epic
Author: Chris Johns
2025-10-02T23:26:36.234Z
added #10 as parent epic
Author: Chris Johns
2025-10-02T23:27:00.455Z
cloned from #5303
Author: Chris Johns
2025-10-02T23:27:23.196Z
added rtems#15 as parent epic
Author: Chris Johns
2025-10-02T23:27:31.723Z
changed title from
Deprecate and
Remove Mongoose Web Server
to
Remove Mongoose Web Server
Author: Kinsey Moore
2026-05-15T14:31:55.455Z
This is a duplicate of #5310
Author: Kinsey Moore
2026-05-15T14:38:37.583Z
set status to Done
5202 - Termios: cannot set all baud rates with rtems_termios_set_best_baud()¶
Id |
5202 |
State |
closed |
Type |
ISSUE |
Author |
Gedare Bloom |
Assignee(s) |
Jan Sommer |
Closed by |
Kinsey Moore |
Created |
2025-02-03T19:00:52.672Z |
Closed |
2026-05-15T14:33:42.476Z |
Updated |
2026-05-15T14:33:42.674Z |
Milestone |
6.3 |
Labels |
cpukit |
Link |
|
Merges |
3 |
Summary¶
Steps to reproduce¶
https://gitlab.rtems.org/rtems/rtos/rtems/-/blob/main/cpukit/libcsupport/src/termios_baudtable.c?ref_type=heads https://gitlab.rtems.org/rtems/rtos/rtems/-/blob/main/cpukit/libcsupport/src/termios_setbestbaud.c?ref_type=heads#L43
The algorithm in rtems_termios_set_best_baud() successively iterates over the elements of the rtems_termios_baud_table and searches for a fitting baud rate (checking by “is element lower than the baud parameter, then checks the next element, …).
The table of baud rates is not sorted correctly from a certain point on, therefore the algorithm for choosing the optimal baud rate does not work for every baud rate.
e.g. if the input is 7200 (which is in the table) the search terminates at 9600 as that is larger, the last entry was 4800, so in the check it sets it to either of those, but not the 7200.
We observed it when we entered 38401 (due to measurement errors on the hardware was a bit larger).
We identified the search ending at 57600 and it ended using the last = 28800.
Pre-set options¶
Author: Gedare Bloom
2025-02-03T19:00:52.815Z
cloned from #5162
Author: Gedare Bloom
2025-02-03T19:00:52.746Z
assigned to @thesummer
Author: Gedare Bloom
2025-02-03T19:01:07.472Z
Author: Gedare Bloom
2025-02-03T19:05:34.225Z
mentioned in merge request !381
Author: Jan Sommer
2025-02-06T03:35:43.024Z
mentioned in commit 9641e1e97d8195d567a6218228ef0f0f2d7fdc25
Author: Chris Johns
2025-10-02T22:31:52.159Z
added rtems#15 as parent epic
Author: Kinsey Moore
2026-05-15T14:33:42.543Z
set status to Done
Author: Kinsey Moore
2026-05-15T14:33:43.296Z
This has been merged into 6 branch.
5236 - Runtime symbols loading is broken¶
Id |
5236 |
State |
closed |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Chris Johns |
Closed by |
Kinsey Moore |
Created |
2025-04-01T00:58:33.568Z |
Closed |
2026-05-15T14:32:56.760Z |
Updated |
2026-05-15T14:32:56.961Z |
Milestone |
6.3 |
Labels |
cpukit::dl, tool::rtems-tools |
Link |
|
Merges |
0 |
Summary¶
Run time symbol loading from an object file is broken. The change to track dependencies added support to check the origin of a symbol to track dependencies. Runtime loading of symbols requires the symbol rtems_rtl_base_sym_global_add be in the symbol table. Loading an symbol object file causes a constrictor attribute function to be run and that calls rtems_rtl_base_sym_global_add adding the base image global symbols. Currently attempting to load a symbol object file results in an unresolved external to rtems_rtl_base_sym_global_add because the symbols is inserted into the global symbol table and not added to the base image’s global symbols.
Also rtems-syms does not correctly export the needed TLS data.
Author: Chris Johns
2025-04-01T00:58:33.714Z
cloned from #5234
Author: Chris Johns
2025-04-01T00:58:33.637Z
assigned to @chris
Author: Chris Johns
2025-04-01T01:34:24.159Z
mentioned in merge request !461
Author: Kinsey Moore
2025-04-01T13:51:00.525Z
Author: Chris Johns
2025-12-03T04:17:13.243Z
added rtems#15 as parent epic
Author: Kinsey Moore
2026-05-15T14:32:56.821Z
set status to Done
Author: Kinsey Moore
2026-05-15T14:32:57.586Z
This has been merged into 6 branch.
5375 - Backport to 6 branch “bsps/qspi: Make flashdev control structure private”¶
Id |
5375 |
State |
closed |
Type |
ISSUE |
Author |
Kinsey Moore |
Closed by |
Kinsey Moore |
Created |
2025-10-16T16:29:49.878Z |
Closed |
2026-05-15T14:31:15.089Z |
Updated |
2026-05-15T14:31:15.170Z |
Milestone |
6.3 |
Labels |
device::spi |
Link |
|
Merges |
0 |
The following discussion from !805 should be addressed:
[] @opticron started a discussion:
This needs a backport to 6 branch.
Author: Kinsey Moore
2025-10-16T16:29:49.966Z
set status to To do
Author: Kinsey Moore
2025-10-16T16:30:09.532Z
added rtems#15 as parent epic
Author: Kinsey Moore
2025-10-16T16:34:29.244Z
mentioned in merge request !806
Author: Kinsey Moore
2025-10-16T16:35:19.182Z
mentioned in merge request !804
Author: Chris Johns
2025-10-20T14:42:07.187Z
mentioned in commit 36a3845d9cf896bb14ad9a9534b8f6acacba39b4
Author: Kinsey Moore
2026-05-15T14:31:15.144Z
set status to Done
Author: Kinsey Moore
2026-05-15T14:31:15.767Z
This has been merged into 6 branch.
5382 - Back port fix for flashdev JFFS2 double free of mount_data and instance to 6¶
Id |
5382 |
State |
closed |
Type |
ISSUE |
Author |
Aaron Nyholm |
Closed by |
Kinsey Moore |
Created |
2025-10-28T03:32:31.556Z |
Closed |
2026-05-15T14:30:58.484Z |
Updated |
2026-05-15T14:30:58.560Z |
Milestone |
6.3 |
Link |
|
Merges |
0 |
Summary¶
Back port the fix for #5381 to 6 branch
Steps to reproduce¶
Author: Aaron Nyholm
2025-10-28T03:32:31.783Z
set status to To do
Author: Aaron Nyholm
2025-10-28T03:35:22.066Z
mentioned in merge request !816
Author: Kinsey Moore
2026-05-15T14:30:58.536Z
set status to Done
Author: Kinsey Moore
2026-05-15T14:30:59.134Z
This has been merged into 6 branch.
5435 - Add -D_LDBL_EQ_DBL=1 workaround to ABI_FLAGS on Coldfires¶
Id |
5435 |
State |
closed |
Type |
ISSUE |
Author |
Chris Johns |
Closed by |
Kinsey Moore |
Created |
2026-01-27T06:54:14.032Z |
Closed |
2026-05-15T14:30:39.929Z |
Updated |
2026-05-15T14:30:40.125Z |
Milestone |
6.3 |
Labels |
arch:m68k, lang::c |
Link |
|
Merges |
0 |
Summary¶
Add a work around to issues in newlib.
Steps to reproduce¶
The following code:
#include <ieeefp.
Author: Chris Johns
2026-01-27T06:54:14.185Z
added rtems#15 as parent epic
Author: Chris Johns
2026-01-27T06:54:14.293Z
set status to To do
Author: Chris Johns
2026-01-27T06:56:45.357Z
mentioned in merge request !951
Author: Jeremy Lorelli
2026-01-27T07:05:35.148Z
Original MR: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/937
Author: Kinsey Moore
2026-05-15T14:30:39.990Z
set status to Done
Author: Kinsey Moore
2026-05-15T14:30:40.636Z
This has been merged into 6 branch.
5212 - machine/_timecounter.h is missing _Timecounter_Getboottime(_tvp)¶
Id |
5212 |
State |
closed |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Chris Johns |
Closed by |
Chris Johns |
Created |
2025-02-11T22:24:18.786Z |
Closed |
2025-10-02T23:17:28.281Z |
Updated |
2026-03-13T01:16:54.157Z |
Milestone |
6.3 |
Labels |
qualification, rtems::kernel |
Link |
|
Merges |
1 |
The machine/_kernel_time.h header has:
#define getboottime(_tvp) _Timecounter_Getboottime(_tvp)
#define getboottimebin(_bt) _Timecounter_Getboottimebin(_bt)
however machine/_timecounter.h does not have a prototype for _Timecounter_Getboottime and GCC 14 now generates an error.
Author: Chris Johns
2025-02-11T22:24:18.920Z
cloned from #5211
Author: Chris Johns
2025-02-11T22:24:18.850Z
assigned to @chris
Author: Chris Johns
2025-02-11T22:24:31.498Z
Author: Chris Johns
2025-02-11T22:25:03.138Z
GCC 13 does not complain but the issue is still present.
Author: Chris Johns
2025-02-11T22:27:23.402Z
mentioned in merge request !416
Author: Chris Johns
2025-10-02T23:16:53.159Z
added rtems#15 as parent epic
Author: Chris Johns
2025-10-02T23:17:28.309Z
set status to Won’t do
4736 - RISC-V - ISR_stack allocation and usage by harts > CONFIGURE_MAXIMUM_PROCESSORS¶
Id |
4736 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Closed by |
Gedare Bloom |
Created |
2022-10-05T15:38:19.000Z |
Closed |
2026-02-19T18:19:16.016Z |
Updated |
2026-02-19T18:19:16.029Z |
Milestone |
6.3 |
Labels |
arch:riscv, priority::normal, tickettype::defect, version::5 |
Link |
|
Merges |
0 |
Original author: lsilistr
When running SMP with CONFIGURE_MAXIMUM_PROCESSORS < total number of harts, the unused harts that start will allocate interrupt stacks from the sections following .rtemsstack. 16 bytes are used (written) while parking the core in _CPU_Thread_Idle_body.
Unallocated _Per_CPU_Information is also used but only for pointer math - this seems to work out fine.
It does seem like practically, with the default linkcmds, unless the cores are held/delayed by a debugger, they would never end up writing in memory before that memory is used -.rtemsstack is followed by .work.
Is this intended/known behaviour?
Author: Trac Migrate
2022-10-07T05:06:16.000Z
Original author: lsilistr
This is a bug. The arm start.S does not have this issue for example.
Author: Trac Migrate
2022-10-07T05:07:44.000Z
Original author: lsilistr
Milestone set to %”6.1”
Author: Chris Johns
2022-11-30T00:03:38.000Z
Original author: lsilistr
Status update?
Author: Joel Sherrill
2023-06-22T21:00:39.000Z
Original author: lsilistr
Owner set to hesham
Status changed from new to assigned
Hesham.. can you please take a shot at this?
Author: Joel Sherrill
2023-06-22T21:07:55.000Z
Original author: lsilistr
Summary changed from ISR_stack allocation and usage by harts > CONFIGURE_MAXIMUM_PROCESSORS to RISC-V - ISR_stack allocation and usage by harts > CONFIGURE_MAXIMUM_PROCESSORS
Author: Amar Takhar
2024-05-17T02:09:03.268Z
changed the description
Author: Amar Takhar
2024-05-17T02:09:23.582Z
@joel can this be bumped to %6.2 hesham is not on GitLab.
Author: Joel Sherrill
2025-09-19T00:21:53.492Z
unassigned @tracmigrate
Author: Gedare Bloom
2026-02-19T18:19:16.074Z
set status to Done
Author: Gedare Bloom
2026-02-19T18:19:16.699Z
This was fixed in e5233057be3396e9cd75ffd3a92d2048df316a4b
5490 - Backport “cpukit/libio: Fix race condition in iop free”¶
Id |
5490 |
State |
closed |
Type |
ISSUE |
Author |
Kinsey Moore |
Assignee(s) |
Kinsey Moore |
Closed by |
Gedare Bloom |
Created |
2026-02-12T21:05:54.747Z |
Closed |
2026-02-12T21:36:06.400Z |
Updated |
2026-02-12T21:36:06.614Z |
Milestone |
6.3 |
Link |
|
Merges |
0 |
The following discussion from !1048 should be addressed:
[] @opticron started a discussion:
This needs a backport to 6 branch as well.
Author: Kinsey Moore
2026-02-12T21:05:54.941Z
added rtems#15 as parent epic
Author: Kinsey Moore
2026-02-12T21:05:55.038Z
set status to To do
Author: Kinsey Moore
2026-02-12T21:05:55.183Z
assigned to @opticron
Author: Kinsey Moore
2026-02-12T21:09:33.536Z
mentioned in merge request !1060
Author: Gedare Bloom
2026-02-12T21:36:06.468Z
set status to Done
5411 - Follow-up from “cpukit/libio: Support close with IOP references held”¶
Id |
5411 |
State |
closed |
Type |
ISSUE |
Author |
Kinsey Moore |
Assignee(s) |
Chris Johns |
Closed by |
Kinsey Moore |
Created |
2025-12-26T19:02:47.354Z |
Closed |
2026-02-12T21:06:00.887Z |
Updated |
2026-02-12T21:06:01.071Z |
Milestone |
6.3 |
Link |
|
Merges |
1 |
The following discussion from !635 should be addressed:
[] @opticron started a discussion:
@chris This appears to have broken the newlib01 test on at least zynqmp_qemu.
Author: Kinsey Moore
2025-12-26T19:02:47.481Z
set status to To do
Author: Kinsey Moore
2025-12-26T19:02:56.885Z
added rtems#15 as parent epic
Author: Kinsey Moore
2025-12-26T19:03:17.498Z
assigned to @chris
Author: Allan Hessenflow
2026-01-16T03:54:44.833Z
I’m testing in main, not a 6.x branch, but newlib01 is also broken for the efm32gg11 bsp and it runs okay if I revert the referenced IOP changes. It seems likely to be the same issue seen with the zynqmp_qemu. Here’s what I’ve found and a possible fix:
This call chain occurs (omitting some irrelevant stuff) exit() -> fatal_extension() -> fstat() -> rtems_libio_get_iop().
That calls rtems_libio_iop_hold() followed by rtems_libio_iop_drop() because the descriptor is closed.
Then rtems_libio_iop_drop() -> rtems_libio_free() -> rtems_libio_free_iop(). However the referenced iop is already on the free list. So I added an additional check below before calling rtems_libio_free_iop(), which appears to fix the problem. However I don’t feel I have a good understanding of how all this IOP stuff is intended to work so hopefully someone who does will evaluate and comment.
I’ll also note that spintrcritical24 was failing as well on the efm32gg11 and it also appears to be fixed with this change. It had been ending up in an infinite loop trying to count free iops because rtems_libio_iop_free_head->data1 == rtems_libio_iop_free_head. That state is consistent with an iop being appended to the free list twice.
diff --git a/cpukit/include/rtems/libio_.h b/cpukit/include/rtems/libio_.h index 21a57cdc4f..0bd088d498 100644 --- a/cpukit/include/rtems/libio_.h +++ b/cpukit/include/rtems/libio_.h @@ -150,12 +150,13 @@ static inline void rtems_libio_free( * the iop so consider it an indirect reference. We cannot return * the iop to the free list while the user owns the fd. * - * Read the flags once as it is an atomic and we need to test 2 + * Read the flags once as it is an atomic and we need to test 3 * flags. No convenience call as this is the only case we have. */ const unsigned int flags = rtems_libio_iop_flags( iop ); if ( ( ( flags & LIBIO_FLAGS_OPEN ) == 0 ) - && ( ( flags & LIBIO_FLAGS_REFERENCE_MASK ) == 0 ) ) { + && ( ( flags & LIBIO_FLAGS_REFERENCE_MASK ) == 0 ) + && ( ( flags & LIBIO_FLAGS_FREE ) == 0 ) ) { rtems_libio_free_iop( iop ); } }
Author: Allan Hessenflow
2026-01-16T17:27:01.435Z
On further reflection the possible fix above is certainly incorrect. A better fix would be the one below, replace the test !rtems_ibio_iop_is_free() inside rtems_libio_free_iop() with an atomic test and set of LIBIO_FLAGS_FREE prior to the rtems_libio_lock(). I’m fairly confident this correctly addresses the newlib01 case. I don’t know about spintrcritical24 (it does pass with the efm32gg11 bsp with either patch but I can’t explain why; it is very sensitive to timing).
diff --git a/cpukit/libcsupport/src/libio.c b/cpukit/libcsupport/src/libio.c index 0a0c238d43..cd1bf2e851 100644 --- a/cpukit/libcsupport/src/libio.c +++ b/cpukit/libcsupport/src/libio.c @@ -156,10 +156,12 @@ void rtems_libio_free_iop( ) { size_t zero; + unsigned int flags; - rtems_libio_lock(); + flags = rtems_libio_iop_flags_set( iop, LIBIO_FLAGS_FREE ); + if ( ( flags & LIBIO_FLAGS_FREE ) == 0 ) { + rtems_libio_lock(); - if ( !rtems_libio_iop_is_free( iop ) ) { /* * Clear the flags. All references should have been dropped. */ @@ -176,9 +178,10 @@ void rtems_libio_free_iop( */ *rtems_libio_iop_free_tail = iop; rtems_libio_iop_free_tail = &iop->data1; + + rtems_libio_unlock(); } - rtems_libio_unlock(); } int rtems_libio_count_open_iops(
Author: Allan Hessenflow
2026-01-18T01:32:59.209Z
With additional testing I can now explain the spintrcritical24 failures I’ve seen and the patch above that adds the atomic test and set of LIBIO_FLAGS_FREE in rtems_libio_free_iop outside the semaphore protected section is a correct fix for that as well as for newlib01.
In spintrcritical24 fcntl() is called from inside an interrupt on a file descriptor that is being closed from a normal task at approximately the same time. The close() results in rtems_libio_free_iop() being called. If the interrupt occurs inside that function after the test for LIBIO_FLAGS_FREE and before that flag is set then the free occurs twice on the same descriptor, messing up the free list.
The newlib01() test is similar in that it causes rtems_libio_free_iop() to be called at a point in the exit() process when semaphores can no longer be taken.
After this patch I’m not certain there isn’t still a window for spintrcritical24 to cause a problem. If the interrupt were to occur earlier, but still after LIBIO_FLAGS_OPEN has been cleared and the hold close() had on the descriptor has been dropped, then the rtems_libio_free_iop() would actually occur during the interrupt context. Assuming this scenario is possible, one solution would be to check for interrupt context prior to the test+set of LIBIO_FLAGS_FREE and not proceed in that case.
Finally, I think it would also be acceptable to just declare spintrcritical24 as invalid since I don’t think fcntl() is ever guaranteed to be safe from an interrupt context. If it was my decision I’d still fix it on the off chance there is or will someday be a function that takes a file descriptor and that’s specified as interrupt safe, by using either of the above patches combined with an ISR_Is_in_progress() check. In the case of newlib01, in general calling fstat() on an already closed file isn’t safe since the descriptor could have been reused, but when newlib01 does it that isn’t posslbe and either of the two above patches would allow newlib01 to do so.
Author: Chris Johns
2026-02-06T00:05:39.380Z
set status to In progress
Author: Aaron Nyholm
2026-02-06T04:59:18.803Z
mentioned in merge request !1048
Author: Kinsey Moore
2026-02-12T21:06:02.190Z
set status to Done
5488 - Complete the u-boot support for qoriq_e500¶
Id |
5488 |
State |
closed |
Type |
ISSUE |
Author |
Gedare Bloom |
Closed by |
Gedare Bloom |
Created |
2026-02-12T16:29:01.822Z |
Closed |
2026-02-12T16:31:56.770Z |
Updated |
2026-02-12T16:31:56.855Z |
Milestone |
6.3 |
Labels |
arch:powerpc, backport |
Link |
|
Merges |
0 |
Summary¶
The u-boot support for powerpc/qoriq is not complete. Under bsps/powerpc/qoriq/include/bsp.h, bsp_uboot_getenv is declared if HAS_UBOOT is defined. However, in HAS_UBOOT is not configurable through waf and variables needed by bsp_uboot_getenv are not defined for qoriq.
Steps to reproduce¶
Add the .yml file under spec so that HAS_UBOOT can be defined in config.ini
Add uboot_support.c to define the u-boot environment base address and size
Expected behaviour¶
User can have “HAS_UBOOT = True” in config.ini when building RTEMS, and then use bsp_uboot_getenv in applications to access the u-boot environment variables.
powerpc, qoriq
Author: Gedare Bloom
2026-02-12T16:29:01.890Z
cloned from #5439
Author: Gedare Bloom
2026-02-12T16:29:57.722Z
mentioned in merge request !976
Author: Gedare Bloom
2026-02-12T16:30:37.068Z
added rtems#15 as parent epic
Author: Gedare Bloom
2026-02-12T16:31:56.831Z
set status to Done
5227 - testsuites/psxtests: psxaio05 fails on ZynqMP¶
Id |
5227 |
State |
closed |
Type |
ISSUE |
Author |
Kinsey Moore |
Assignee(s) |
Kinsey Moore |
Closed by |
Kinsey Moore |
Created |
2025-03-10T20:26:35.031Z |
Closed |
2026-01-30T19:38:43.726Z |
Updated |
2026-01-30T19:38:43.885Z |
Milestone |
6.3 |
Labels |
rtems::testing, version::6 |
Link |
|
Merges |
0 |
Summary¶
The psxaio05 test fails on both hardware and QEMU BSPs with:
../../../testsuites/psxtests/psxaio05/init.c: 142 status == 0
Steps to reproduce¶
Run the psxaio05 test under QEMU with:
qemu-system-aarch64 -no-reboot -nographic -serial mon:stdio -machine xlnx-zcu102 -m 4096 -kernel build/aarch64/zynqmp_qemu/testsuites/psxtests/psxaio05.exe
Pre-set options¶
Author: Kinsey Moore
2025-03-11T20:34:44.479Z
assigned to @opticron
Author: yang zhang
2025-03-20T06:32:27.762Z
I also find this issue, i think the reason maybe below: In toolchain, <limits.h> also define AIO_LISTIO_MAX /* * Definitions of the following may be omitted if the value is >= stated * minimum but is indeterminate. */
So AIO_LISTIO_MAX in <aio_misc.h> won’t be defined again.
Author: Amar Takhar
2025-10-12T18:25:20.534Z
Does this need fixing for 7.1? If not please bump.
Author: Kinsey Moore
2025-10-12T18:25:20.494Z
Moved.
Author: Kinsey Moore
2025-12-26T18:16:05.074Z
As Yang noted, this appears to be an issue with conflicting definitions and this is no longer present on main/7. I will submit a fix for the 6 branch that overrides the toolchain value.
Author: Kinsey Moore
2025-12-26T18:16:12.123Z
added rtems#15 as parent epic
Author: Kinsey Moore
2025-12-26T18:59:30.094Z
mentioned in merge request !884
Author: Joel Sherrill
2026-01-23T01:32:05.249Z
mentioned in commit 4d38bf6ec039efc0b522ba8e4da7539367f5ff7c
Author: Kinsey Moore
2026-01-30T19:38:43.843Z
set status to Done
5410 - Follow-up from “cpukit/sapi/src/interrtext.c: Add missing definition”¶
Id |
5410 |
State |
closed |
Type |
ISSUE |
Author |
Kinsey Moore |
Assignee(s) |
Kinsey Moore |
Closed by |
Kinsey Moore |
Created |
2025-12-26T18:20:10.574Z |
Closed |
2026-01-24T19:09:25.125Z |
Updated |
2026-01-24T19:09:25.278Z |
Milestone |
6.3 |
Labels |
backport |
Link |
|
Merges |
0 |
The following discussion from !883 should be addressed:
[] @opticron started a discussion:
This needs a backport to 6 branch.
Author: Kinsey Moore
2025-12-26T18:20:10.777Z
added rtems#15 as parent epic
Author: Kinsey Moore
2025-12-26T18:20:10.898Z
set status to To do
Author: Kinsey Moore
2025-12-26T18:20:13.401Z
assigned to @opticron
Author: Kinsey Moore
2025-12-26T18:34:20.915Z
mentioned in merge request !884
Author: Joel Sherrill
2026-01-23T01:32:05.214Z
mentioned in commit ac41d58472a1ead957f51829a043f76ac397e021
Author: Kinsey Moore
2026-01-24T19:09:25.186Z
set status to Done
5422 - Follow-up from “bsps/aarch64: Add isb instruction after write to sctlr_el1 in aarch64_mmu_enable”¶
Id |
5422 |
State |
closed |
Type |
ISSUE |
Author |
Kinsey Moore |
Assignee(s) |
Kinsey Moore |
Closed by |
Kinsey Moore |
Created |
2026-01-15T18:01:47.709Z |
Closed |
2026-01-16T22:06:32.047Z |
Updated |
2026-01-16T22:06:32.183Z |
Milestone |
6.3 |
Labels |
arch:aarch64 |
Link |
|
Merges |
0 |
The following discussion from !908 should be addressed:
[] @opticron started a discussion:
Thanks for the contribution! Would you mind also creating a backport MR that references the issue created from this thread?
Author: Kinsey Moore
2026-01-15T18:01:47.888Z
added rtems#15 as parent epic
Author: Kinsey Moore
2026-01-15T18:01:47.995Z
set status to To do
Author: Kinsey Moore
2026-01-15T18:01:48.133Z
assigned to @opticron
Author: Kinsey Moore
2026-01-15T18:02:09.383Z
mentioned in merge request !908
Author: Preetam Das
2026-01-15T20:13:40.133Z
mentioned in merge request !916
Author: Kinsey Moore
2026-01-16T22:06:01.829Z
mentioned in commit 7f064c49bdea4c0e7c4d6502e0500c4098f01786
Author: Kinsey Moore
2026-01-16T22:06:32.140Z
set status to Done
4095 - Remove doc from rtems-tools¶
Id |
4095 |
State |
closed |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Kinsey Moore |
Closed by |
Kinsey Moore |
Created |
2020-09-24T23:53:13.000Z |
Closed |
2025-10-12T19:45:57.375Z |
Updated |
2025-10-12T20:03:55.957Z |
Milestone |
6.3 |
Labels |
priority::normal, tickettype::task, tool, version::6 |
Link |
|
Merges |
0 |
This directory is not used and needs to go. I will push the change directly to the repo to avoid the clutter a review would generate as most of the files and imported.
Author: Joel Sherrill
2022-03-03T22:54:55.000Z
Is this done? Easy to close?
Author: Joel Sherrill
2022-12-28T19:51:02.000Z
Please check if this can be closed.
Author: Gedare Bloom
2023-01-23T20:41:52.000Z
https://git.rtems.org/rtems-tools/tree/doc
Still exists.
Author: Joel Sherrill
2023-02-09T16:04:32.000Z
I think that much of the content in rtems-tools/doc is NOT in the Users Guide. The discussion of the RTEMS Tester in the Users Guide takes a different view and appears to never show how to use it which is the focus of much of this documentation. I don’t think this is a simple remove some files.
Author: Joel Sherrill
2023-06-22T21:21:57.000Z
Owner set to @kinsey
Author: Amar Takhar
2024-05-17T02:01:29.459Z
Can this be moved to %6.2?
Author: Kinsey Moore
2024-05-17T02:54:17.851Z
This is fine to move to %”6.2”.
Author: Kinsey Moore
2024-05-17T02:54:22.287Z
changed the description
Author: Gedare Bloom
2024-12-04T21:40:36.469Z
Author: Chris Johns
2025-10-02T23:13:27.246Z
added rtems#15 as parent epic
Author: Kinsey Moore
2025-10-12T19:45:57.435Z
set status to Done
Author: Kinsey Moore
2025-10-12T19:45:58.291Z
This was removed in 82a8824fb5eecb61a6aa4e765f4502d051220e02
Author: Amar Takhar
2025-10-12T20:03:55.920Z
Adding link https://gitlab.rtems.org/rtems/tools/rtems-tools/-/commit/82a8824fb5eecb61a6aa4e765f4502d051220e02
5735 - Backport Fxp fix to 6-freebsd-14 (opened)¶
Id |
5735 |
State |
opened |
Type |
TASK |
Author |
Vijay Banerjee |
Assignee(s) |
Vijay Banerjee |
Created |
2026-08-31T15:11:08.537Z |
Updated |
2026-08-31T16:13:53.704Z |
Milestone |
6.3 |
Labels |
arch:powerpc |
Link |
|
Merges |
0 |
Summary¶
Backport https://gitlab.rtems.org/rtems/pkg/rtems-libbsd/-/merge_requests/157
Steps to reproduce¶
Author: Vijay Banerjee
2026-08-31T15:11:08.640Z
set status to To do
Author: Vijay Banerjee
2026-08-31T15:11:08.742Z
assigned to @vijay
5681 - Add libbsd support for MVME5100 (opened)¶
Id |
5681 |
State |
opened |
Type |
ISSUE |
Author |
Vijay Banerjee |
Assignee(s) |
Vijay Banerjee |
Created |
2026-08-06T17:29:01.822Z |
Updated |
2026-08-06T17:29:01.822Z |
Milestone |
6.3 |
Link |
|
Merges |
0 |
Summary¶
Add libbsd networking support for mvme5100
Steps to reproduce¶
Author: Vijay Banerjee
2026-08-06T17:29:02.077Z
added rtems#15 as parent item
Author: Vijay Banerjee
2026-08-06T17:29:02.208Z
set status to To do
Author: Vijay Banerjee
2026-08-06T17:29:02.372Z
assigned to @vijay
5679 - Fix mvme2100 bspreset (opened)¶
Id |
5679 |
State |
opened |
Type |
ISSUE |
Author |
Vijay Banerjee |
Assignee(s) |
Vijay Banerjee |
Created |
2026-08-06T17:21:40.740Z |
Updated |
2026-08-06T17:22:18.851Z |
Milestone |
6.3 |
Labels |
arch:powerpc, backport |
Link |
|
Merges |
0 |
Summary¶
Backport MVME2100 bsp reset fix https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1390
Steps to reproduce¶
Author: Vijay Banerjee
2026-08-06T17:21:40.927Z
added rtems#15 as parent item
Author: Vijay Banerjee
2026-08-06T17:21:41.019Z
set status to To do
Author: Vijay Banerjee
2026-08-06T17:21:41.145Z
assigned to @vijay
5677 - Backport MVME5100 support (opened)¶
Id |
5677 |
State |
opened |
Type |
ISSUE |
Author |
Vijay Banerjee |
Assignee(s) |
Vijay Banerjee |
Created |
2026-08-06T17:12:17.746Z |
Updated |
2026-08-06T17:13:12.511Z |
Milestone |
6.3 |
Labels |
arch:powerpc, backport |
Link |
|
Merges |
0 |
Summary¶
Backport commit https://gitlab.rtems.org/rtems/rtos/rtems/-/commit/47ffb323e53323278992ca4e511813198059b377
Steps to reproduce¶
Author: Vijay Banerjee
2026-08-06T17:12:17.847Z
set status to To do
Author: Vijay Banerjee
2026-08-06T17:12:17.905Z
changed Version to
6
Author: Vijay Banerjee
2026-08-06T17:12:18.024Z
assigned to @vijay
Author: Vijay Banerjee
2026-08-06T17:13:50.611Z
added rtems#15 as parent item
5676 - Remove 6-freebsd-12 from 6 releases (opened)¶
Id |
5676 |
State |
opened |
Type |
ISSUE |
Author |
Chris Johns |
Created |
2026-08-05T02:00:49.647Z |
Updated |
2026-08-05T02:00:49.647Z |
Milestone |
6.3 |
Labels |
libbsd::freebsd-12 |
Link |
|
Merges |
0 |
Summary¶
The 6-freebsd-12 is not secure and will be removed from 6 releases.
Author: Chris Johns
2026-08-05T02:00:49.817Z
added rtems#15 as parent item
Author: Chris Johns
2026-08-05T02:00:49.916Z
set status to To do
5235 - RTEMS GPIO Clear bug (opened)¶
Id |
5235 |
State |
opened |
Type |
ISSUE |
Author |
Ryan Simcock |
Assignee(s) |
Heinz Junkes |
Created |
2025-03-31T12:18:22.125Z |
Updated |
2026-07-31T09:16:54.472Z |
Milestone |
6.3 |
Labels |
bsp:beaglebone |
Link |
|
Merges |
0 |
Summary¶
This bug has been produced on the Beagleboneblack (AM335 chip). When the RTEMS API is used to clear a GPIO pin, all pins which are set, are cleared. I am using the released version of RTEMS 6.1.
Steps to reproduce¶
Environment: Ubuntu 22.04.5 (LTS) Using the released RTEMS source builder 6.1, I built the toolchain and the BSP for the beagleboneblack (following the user guide).
Expected behaviour¶
BSP - beagleboneblack RTEMS 6.1 When the function, rtems_gpio_bsp_clear is called, any GPIO that is currently set, is cleared. This is because mmio_set is being used, when in fact mmio_write is sufficient. mmio_set does a read of the register first and OR’s with your wanted pin and writes again. The AM335X_GPIO_CLEARDATAOUT does not work this way, when it is read, it returns the register value of GPIO_DATAOUT (In the datasheet), so it clears all set GPIO pins at that time.
Author: Heinz Junkes
2025-09-25T23:07:05.154Z
Hi Ryan, I’m currently working on this BSP and especially the GPIO.
https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5198
Here is my current status, but it is not reviewed and may still contain some errors. It would be nice if you could take a look at it. Thanks Heinz patch_2
Author: Chris Johns
2025-09-25T23:07:05.105Z
@junkes is the patch an MR? If not would you please be able to create one?
Author: Chris Johns
2026-07-31T00:20:00.314Z
@junkes Any update on making the patch an merge request?
Author: Chris Johns
2025-09-25T23:06:25.618Z
changed Version to
6
Author: Chris Johns
2025-09-25T23:07:20.935Z
assigned to @junkes
Author: Heinz Junkes
2026-07-31T09:16:54.445Z
There is a merge request, which fixes the GPIO Clear bug, IIRC https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/697
5270 - HardFault in __libc_init_array due to invalid constructor pointer on ATSAMV71 (RTEMS 6.1) (opened)¶
Id |
5270 |
State |
opened |
Type |
ISSUE |
Author |
Luís Neto |
Created |
2025-06-17T16:42:14.620Z |
Updated |
2026-07-31T00:21:54.861Z |
Milestone |
6.3 |
Labels |
arch:arm |
Link |
|
Merges |
0 |
Summary¶
A HardFault is consistently observed during application startup on the ATSAMV71 target when building and running the standard hello.exe sample from RTEMS 6.1. The fault occurs within the __libc_init_array function, indicating an issue with global static initialization.
Target Hardware Details:¶
Processor Architecture: ARM Cortex-M7
Chip Family/Model: ATSAMV711Q21
Board Support Package (BSP): atsamv (specifically, arm/atsamv as used in the sb-set-builder configuration)
Build Environment:¶
OS: Linux Ubuntu 22.04 LTS RTEMS Source: Download from https://ftp.rtems.org/pub/rtems/releases/6/6.1/sources/rtems-6.1.tar.xz RTEMS Source Builder: Download from https://ftp.rtems.org/pub/rtems/releases/6/6.1/sources/rtems-source-builder-6.1.tar.xz
Steps to reproduce¶
1. Build the RTEMS Toolchain using RSB:¶
../source-builder/sb-set-builder --prefix=/home/ln/samv71/rtems/6.1 --target=rtems-arm --with-rtems-bsp=arm/atsam --with-rtems-tests=yes --with-rtems-bspopts="ATSAM_CHIP=samv71q21" 6/rtems-arm
export PATH=/home/ln/samv71/rtems/6.1/bin:"$PATH"
2. Build the RTEMS hello.exe Sample:¶
1. ~/samv71/src/rtems-6.1$ ./waf bspdefaults --rtems-bsp=arm/atsamv > config.ini
2. ~/samv71/src/rtems-6.1$ ./waf clean
3. ~/samv71/src/rtems-6.1$ ./waf build
4. ~/samv71/src/rtems-6.1$ ./waf install
5. ~/samv71/src/rtems-6.1$ cp build/arm/atsamv/testsuites/samples/hello.exe build/arm/atsamv/testsuites/samples/hello.elf
3. Run the hello.exe Application:¶
Flash the eval board using MPLAB X IDE v6.25.
Expected Behavior:¶
The application should initialize successfully and print “Hello from RTEMS!” to the console.
Actual Undesired Behavior:¶
The application crashes with a HardFault immediately during startup.
Crash Analysis:¶
Upon inspecting the fault registers (captured from the HardFault handler), the following values were observed:
PC: 0xFFFFFFFE
LR: 0x0040a5db
SP: 0x20404f28
MMFSR: 0x00000001 (IACCVIOL bit is set)
MMFARVALID: 0
The PC = 0xFFFFFFFE combined with IACCVIOL = 1 indicates an Instruction Access Violation, meaning the processor attempted to fetch and execute an instruction from an invalid memory address.
Disassembly of hello.exe around the LR address (0x0040a5db) shows the context within __libc_init_array:
0040a5a0 <__libc_init_array>:
\ |md_0_160|\ 40a5a0: 4b0f\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ ldr r3, [pc, #60] @ (40a5e0 <__libc_init_array+0x40>)
\ |md_0_160|\ 40a5a2: b570\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ push {r4, r5, r6, lr}
\ |md_0_160|\ 40a5a4: 4d0f\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ ldr r5, [pc, #60] @ (40a5e4 <__libc_init_array+0x44>)
\ |md_0_160|\ 40a5a6: 42ab\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ cmp r3, r5
\ |md_0_160|\ 40a5a8: eba3 0605 sub.w r6, r3, r5
\ |md_0_160|\ 40a5ac: d007\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ beq.n 40a5be <__libc_init_array+0x1e>
\ |md_0_160|\ 40a5ae: 10b6\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ asrs r6, r6, #2
\ |md_0_160|\ 40a5b0: 2400\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ movs r4, #0
\ |md_0_160|\ 40a5b2: 3401\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ adds r4, #1
\ |md_0_160|\ 40a5b4: f855 3b04 ldr.w r3, [r5], #4
\ |md_0_160|\ 40a5b8: 4798\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ blx r3
\ |md_0_160|\ 40a5ba: 42a6\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ cmp r6, r4
\ |md_0_160|\ 40a5bc: d8f9\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ bhi.n 40a5b2 <__libc_init_array+0x12>
\ |md_0_160|\ 40a5be: 4d0a\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ ldr r5, [pc, #40] @ (40a5e8 <__libc_init_array+0x48>)
\ |md_0_160|\ 40a5c0: f002 fa66 bl 40ca90 <_init>
\ |md_0_160|\ 40a5c4: 4b09\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ ldr r3, [pc, #36] @ (40a5ec <__libc_init_array+0x4c>)
\ |md_0_160|\ 40a5c6: 1b5e\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ subs r6, r3, r5
\ |md_0_160|\ 40a5c8: 42ab\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ cmp r3, r5
\ |md_0_160|\ 40a5ca: ea4f 06a6 mov.w r6, r6, asr #2
\ |md_0_160|\ 40a5ce: d006\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ beq.n 40a5de <__libc_init_array+0x3e>
\ |md_0_160|\ 40a5d0: 2400\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ movs r4, #0
\ |md_0_160|\ 40a5d2: 3401\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ adds r4, #1
\ |md_0_160|\ 40a5d4: f855 3b04 ldr.w r3, [r5], #4
\ |md_0_160|\ 40a5d8: 4798\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ blx r3
\ |md_0_160|\ 40a5da: 42a6\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ cmp r6, r4
\ |md_0_160|\ 40a5dc: d8f9\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ bhi.n 40a5d2 <__libc_init_array+0x32>
\ |md_0_160|\ 40a5de: bd70\ |md_0_160|\ \ |md_0_160|\ \ |md_0_160|\ pop {r4, r5, r6, pc}
\ |md_0_160|\ 40a5e0: 0040ea2c .word 0x0040ea2c
\ |md_0_160|\ 40a5e4: 0040ea2c .word 0x0040ea2c
\ |md_0_160|\ 40a5e8: 0040ea2c .word 0x0040ea2c
\ |md_0_160|\ 40a5ec: 0040ea30 .word 0x0040ea30
At the point of crash:
The ldr.w r3, [r5], #4 instruction at 0x40a5d4 loads a value into r3.
The r5 value at crash (0x0040ea30) indicates that the load happened from 0x0040ea2c (since r5 is incremented by 4 after the load).
The objdump -s -j .init_array hello.exe confirms the content at 0x40ea2c:
Contents of section .init_array:
40ea2c ad044000
(Which, in little-endian, means 0x004004ad).
Therefore, the blx r3 instruction at 0x40a5d8 attempts to jump to 0x004004ad.
Further addr2line reveals:
addr2line -e hello.exe 0x004004ad output: crtstuff.c:?
However, this entry contains the address 0x004004ad, which is not a valid executable function pointer. Instead, it points to data or misaligned, non-executable bytes within the frame_dummy function (part of crtstuff.c and libgcc). Executing this address triggers the Instruction Access Violation.
This indicates that a corrupted or incorrect address has been placed as the initial constructor entry in the .init_array section during the compilation and linking of the hello.exe sample. This suggests a potential issue within the RTEMS 6.1 toolchain components (specifically libgcc/Newlib’s) for this target.
Author: Luís Neto
2025-06-17T16:44:39.873Z
changed the description
Author: Luís Neto
2025-06-17T16:45:32.550Z
changed the description
Author: Luís Neto
2025-06-17T16:46:03.780Z
changed the description
Author: Chris Johns
2025-09-25T23:00:12.671Z
changed Version to
6
Author: Chris Johns
2026-07-31T00:21:54.836Z
We think this is related to the linker script set up, the memory map or the memory set up before RTEMS runs. These tables are used to implement the
SYS_INITfeature which starts RTEMS.Are you able to do more debugging of this issue for us?
Author: Chris Johns
2026-07-31T00:22:20.375Z
Has there been any progress on this?
5269 - 6.1 GR740 SMP Driver Manager build fail (opened)¶
Id |
5269 |
State |
opened |
Type |
ISSUE |
Author |
Matteo Concas |
Created |
2025-06-17T07:52:54.262Z |
Updated |
2026-07-31T00:20:44.913Z |
Milestone |
6.3 |
Labels |
arch:sparc, smp |
Link |
|
Merges |
0 |
Summary¶
Building the GR740 BSP with RTEMS_SMP and RTEMS_DRVMGR_STARTUP set to True will fail in multiple ways.
The issues appear in bsps/shared/grlib/btimer/tlib_ckinit.c .
First issue¶
Excerpt from the build log:
../../../bsps/shared/grlib/btimer/tlib_ckinit.c: In function 'irqamp_get_timecount':
../../../bsps/shared/grlib/btimer/tlib_ckinit.c:373:28: error: 'irqamp' has no member named 'timestamp'
373 | return LEON3_IrqCtrl_Regs->timestamp[0].counter;
| ^~
The first issue appears in every instance of LEON3_IrqCtrl_Regs->timestamp[0] such as:
irqmp_ts = &LEON3_IrqCtrl_Regs->timestamp[0];
This stems from an earlier change where the type of the IRQ(A)MP timestamp register block was changed from irqmp_timestamp_regs to irqamp_timestamp. These two types represent the same thing but have different names for their members.
Possible fix¶
This can be fixed by using &LEON3_IrqCtrl_Regs->itstmp[0]; instead.
Second issue¶
Excerpt from the build log:
/opt/rtems/rtems-7-sparc/bin/../lib/gcc/sparc-rtems7/13.4.0/../../../../sparc-rtems7/bin/ld: ./librtemsbsp.a(tlib_ckinit.c.9.o): in function `tlib_clock_find_timer':
/home/matteo/dev/rtems-gaisler/build/sparc/gr740_smp/../../../bsps/shared/grlib/btimer/tlib_ckinit.c:141:(.text._Clock_Initialize+0x30): undefined reference to `leon3_up_counter_is_available'
collect2: error: ld returned 1 exit status
The second issue appears when linking the object files, the tlib_clock_find_timer() function calls leon3_up_counter_is_available() (declared and defined in bsps/sparc/leon3/include/bsp/leon3.h) but this function is only available when the BSP is defined as not having the SPARC ASR22 and ASR23 registers. This is not the case for the GR740 BSP:
LEON3_HAS_ASR_22_23_UP_COUNTER = True
From the output of ./waf bspdefaults --rtems-bsp=sparc/gr740 .
Possible fix¶
I am not sure why leon3_up_counter_is_available() is not always defined like the rest of the up_counter functions in the file. Removing the define guards fixes the issue.
Steps to reproduce¶
Create a gr740.ini file with the following contents:
[sparc/gr740_smp]
INHERIT=gr740
RTEMS_SMP=True
RTEMS_DRVMGR_STARTUP=True
Run ./waf configure --prefix=$RTEMS_PREFIX --rtems-config=gr740.ini and then ./waf .
Expected behaviour¶
The build should complete successfully.
/bsp sparc/gr740
Author: Chris Johns
2026-07-31T00:20:44.891Z
Please update the Status or move the milestone.
5206 - Back-port “wscript: Make builds with tar archives reproducible” (opened)¶
Id |
5206 |
State |
opened |
Type |
ISSUE |
Author |
Gedare Bloom |
Assignee(s) |
Gedare Bloom |
Created |
2025-02-07T20:41:02.457Z |
Updated |
2026-07-31T00:18:44.159Z |
Milestone |
6.3 |
Labels |
backport |
Link |
|
Merges |
0 |
The following discussion from !405 should be addressed:
[] @frank_k started a discussion: (+1 comment)
What do I need to do to get this patch also into RTEMS 6?
Author: Gedare Bloom
2025-02-07T20:41:02.632Z
assigned to @gedare
Author: Gedare Bloom
2025-02-07T20:41:03.799Z
Author: Chris Johns
2025-10-02T23:36:39.029Z
added rtems#15 as parent epic
Author: Chris Johns
2026-07-31T00:18:44.137Z
Please update the Status or move the milestone.
4903 - TMS570 console driver, SCI frame error (baudrate calculation error) (opened)¶
Id |
4903 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Created |
2023-05-08T11:46:26.000Z |
Updated |
2026-07-30T23:57:18.161Z |
Milestone |
6.3 |
Labels |
arch:arm, old-indefinite, priority::normal, tickettype::defect, version::6 |
Link |
|
Merges |
0 |
Original author: usha
bsps/arm/tms570/console/tms570-sci.c: tms570_sci_set_attributes()
/* Apply baudrate to the hardware */
baudrate *= 2 * 16;
bauddiv = (BSP_PLL_OUT_CLOCK + baudrate / 2) / baudrate;
ctx->regs->BRS = bauddiv? bauddiv - 1: 0;
replacing with 2 fixed frame error
ctx->regs->BRS = bauddiv? bauddiv - 2: 0;
there is issue in baudrate calculation
Author: Joel Sherrill
2023-06-22T20:58:14.000Z
Original author: usha
Can you please submit this as a patch? See https://docs.rtems.org/branches/master/user/support/contrib.html for details.
Thanks.
Author: Trac Migrate
2023-07-13T06:41:03.000Z
Original author: usha
Comment to the next patch proposal
--- a/bsps/arm/tms570/console/tms570-sci.c +++ b/bsps/arm/tms570/console/tms570-sci.c @@ -311,7 +311,7 @@ bool tms570_sci_set_attributes( /* Apply baudrate to the hardware */ baudrate *= 2 * 16; bauddiv = (BSP_PLL_OUT_CLOCK + baudrate / 2) / baudrate; - ctx->regs->BRS = bauddiv? bauddiv - 1: 0; + ctx->regs->BRS = bauddiv? bauddiv - 2: 0;I think that change is not correct. The actual used values for BSP_PLL_OUT_CLOCK and baudrate should be provided to analyze the case. The code can result in some rounding error and can be enhanced if fractional divider is used or even super fine-grained fractional divider. But these options are available only for for SCI/LIN peripheral case.
According to
TMS570LS31x/21x 16/32-Bit RISC Flash Microcontroller Technical Reference Manual Literature Number: SPNU499B
26.2.3 SCI Baud Rate
SCICLK Frequency = VCLK Frequency / (P + 1 + M / 16)
Asynchronous baud value = SCICLK Frequency / 16
So the subtraction of one corresponds to the manual.
Actual code does not use M part. It would be problem if it is leftover from some boot/monitor but it is part of BRS 32-bit register which is overwritten in the whole, so such problem should not appear either.
So I vote against the proposed change for now and suggest to do analysis what happens in the computation and what are input values and output. Change would/could affect negatively large number of combinations of the baudrate and clocks.
I would consider to discuss if the rounding formula could/should be updated, but I think that it is the best which cane be achieved for rations which do not result in exact ratio.
(BSP_PLL_OUT_CLOCK + baudrate / 2) / baudrate;If there is interrest then code can be enhanced by fraction dividers for SCI/LIN peripheral case. The field with variant should be added into tms570_sci_context and in this case the alternative formula can be used
long long bauddiv; bauddiv = (BSP_PLL_OUT_CLOCK * 16ll + baudrate / 2) / baudrate; ctx->regs->BRS = ((bauddiv >> 4) & 0xffffff) | ((bauddiv & 0xf) << 24);which should be rewritten after header for SCI/LIN update to
ctx->regs->BRS = TMS570_LIN_BRS_P(bauddiv >> 4) | TMS570_LIN_BRS_M(bauddiv & 0xf);
Author: Trac Migrate
2023-07-27T01:21:34.000Z
Original author: usha
Fri, 14 Jul, 21:37 (12 days ago) hi, so do you want me make this change? Gedare Bloom via gwmail.gwu.edu
Mon, 17 Jul, 14:17 (9 days ago)
to me, joel, Pavel, Přemysl, devel No, because we don’t have a reproducible test case.
Do you want to close this ticket as we do not have a test case?
Author: Gedare Bloom
2023-07-27T18:31:31.000Z
Original author: usha
Milestone changed from %”6.1” to %”Indefinite”
Leaving open for now, but not setting a milestone until the bug can be confirmed.
Author: Amar Takhar
2025-09-05T02:57:54.530Z
changed the description
Author: Chris Johns
2026-07-30T23:57:18.124Z
unassigned @tracmigrate
3701 - RTEMS Pre-Qualification (ECSS) for SMP (opened)¶
Id |
3701 |
State |
opened |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Sebastian Huber |
Created |
2019-02-26T10:19:31.000Z |
Updated |
2026-07-30T23:09:38.883Z |
Milestone |
6.3 |
Labels |
priority::normal, qualification, tickettype::project, version::6 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
This ticket summarises activities carried out by a 24 month project sponsored by the European Space Agency (ESA). The project start was February 2019.
The main goal of the project is to enable European space missions to use RTEMS as a software product in criticality category C (this is basically category B without independent software verification and validation, ISVV). Criticality category C means according to ECSS-Q-ST-80C:
“Software that if not executed, or if not correctly executed, or whose anomalous behaviour can cause or contribute to a system failure resulting in: Major consequences”
In ECSS-Q-ST-40C major consequences are characterized in Table 6-1 as a major mission degradation without effects to the outside world of the system. A future activity may perform ISVV to enable a use in category B settings.
The qualification will be done according to ECSS standards (ECSS-E-ST-40C and ECSS-Q-ST-80C). The standards are available at
free of charge after registration.
The project consists of four major tasks.
Qualification toolchain
This task aims to produce a tool chain so that qualification related work can be carried out efficiently. For example: document generation, test suite runs (including code coverage), test reporting, test result archiving, code metrics, static code analysis, traceability (e.g. requirements to tests), etc.
RTEMS SMP qualification data package
This task covers the main RTEMS components (source code, tests, documentation; new: requirements document, ECSS standard tailoring) so that a data package for space mission consumers can be generated.
3702: Space profile for RTEMS SMP¶
3703: Technical Specification (TS) for space profile¶
3715: Add Requirements Engineering chapter to RTEMS Software Engineering Handbook¶
3726: Select a requirements engineering tool¶
3705: Software Design Document (SDD) for space profile¶
3704: Review and update Doxygen recommendations¶
3706: Create a hierarchy of RTEMS software components using Doxygen groups¶
3707: Assign each code file to a Doxygen group¶
3708: Remove Doxygen comments from confdefs.h¶
3716: Unit, integration and validation tests for space profile¶
3717: Add test guidelines chapter to RTEMS Software Engineering Handbook¶
3718: Add support for test plans¶
3199: New test framework¶
RTEMS SMP formal verification
This is a research project. The aim is to apply formal methods for the verification of a subset of the RTEMS SMP algorithms.
RTEMS SMP application porting
The goal of this task is to port an existing uniprocessor space software from RTEMS 4.8 (RTEMS Improvement by Edisoft) to RTEMS SMP. The algorithms used by the software needs to be parallelized.
The project partners are:
Edisoft (prime) and [CISTER](http://www.cister.isep.ipp.pt/) from Portugal
Lero with Lero researchers from Trinity College Dublin and University of Limerick from Ireland
Jena-Optronik GmbH and [embedded brains GmbH](https://embedded-brains.de/) from Germany
The results of this activity should be open source and available to the RTEMS community.
Author: Trac Migrate
2019-02-26T13:30:45.000Z
Original author: sebastian.huber
Status changed from assigned to accepted
Author: Trac Migrate
2019-02-26T13:42:07.000Z
Original author: sebastian.huber
Original author: sebastian.huber
Description changed
This ticket summarises activities carried out by a 24 month project sponsored by the European Space Agency (ESA). The project start was February 2019. The main goal of the project is to enable European space missions to use RTEMS as a software product in criticality category C (this is basically category B without independent software verification and validation, ISVV). Criticality category C means according to [ECSS-Q-ST-80C](http://ecss.nl/standard/ecss-q-st-80c-rev-1-software-product-assurance-15-february-2017/): "Software that if not executed, or if not correctly executed, or whose anomalous behaviour can cause or contribute to a system failure resulting in: Major consequences" In [ECSS-Q-ST-40C](https://ecss.nl/standard/ecss-e-st-40c-software-general-requirements/) major consequences are characterized in Table 6-1 as a major mission degradation without effects to the outside world of the system. A future activity may perform ISVV to enable a use in category B settings. The qualification will be done according to ECSS standards (ECSS-E-ST-40C and ECSS-Q-ST-80C). The standards are available at http://ecss.nl/ free of charge after registration. The project consists of four major tasks. - 1. Qualification toolchain + 1. Qualification toolchain ? ++++++++++++ - This task aims to produce a tool chain so that qualification related work can be carried out efficiently. For example: document generation, test suite runs (including code coverage), test reporting, test result archiving, code metrics, static code analysis, traceability (e.g. requirements to tests), etc. - 2. RTEMS SMP qualification data package + 2. RTEMS SMP qualification data package ? ++++++++++++ + This task covers the main RTEMS components (source code, tests, documentation; new: requirements document, ECSS standard tailoring) so that a data package for space mission consumers can be generated. + * #3702: Space profile for RTEMS SMP + * #3703: Technical Specification (TS) for space profile + * #3705: Software Design Document (SDD) for space profile + * #3704: Review and update Doxygen recommendations + * #3706: Create a hierarchy of RTEMS software components using Doxygen groups + * #3707: Assign each code file to a Doxygen group - This task covers the main RTEMS components (source code, tests, documentation; new: requirements document, ECSS standard tailoring) so that a data package for space mission consumers can be generated. - - 3. RTEMS SMP formal verification + 3. RTEMS SMP formal verification ? ++++++++++++ - This is a research project. The aim is to apply formal methods for the verification of a subset of the RTEMS SMP algorithms. - 4. RTEMS SMP application porting + 4. RTEMS SMP application porting ? ++++++++++++ - The goal of this task is to port an existing uniprocessor space software from RTEMS 4.8 (RTEMS Improvement by Edisoft) to RTEMS SMP. The algorithms used by the software needs to be parallelized. The project partners are: * [Edisoft](http://www.edisoft.pt/) (prime) and [CISTER](http://www.cister.isep.ipp.pt/) from Portugal * [Lero](https://www.lero.ie/) with Lero researchers from Trinity College Dublin and University of Limerick from Ireland * [Jena-Optronik GmbH](https://www.jena-optronik.de/) and [embedded brains GmbH](https://embedded-brains.de/) from Germany The results of this activity should be open source and available to the RTEMS community.
Author: Trac Migrate
2019-02-26T14:27:27.000Z
Original author: sebastian.huber
Original author: sebastian.huber
Description changed
This ticket summarises activities carried out by a 24 month project sponsored by the European Space Agency (ESA). The project start was February 2019. The main goal of the project is to enable European space missions to use RTEMS as a software product in criticality category C (this is basically category B without independent software verification and validation, ISVV). Criticality category C means according to [ECSS-Q-ST-80C](http://ecss.nl/standard/ecss-q-st-80c-rev-1-software-product-assurance-15-february-2017/): "Software that if not executed, or if not correctly executed, or whose anomalous behaviour can cause or contribute to a system failure resulting in: Major consequences" In [ECSS-Q-ST-40C](https://ecss.nl/standard/ecss-e-st-40c-software-general-requirements/) major consequences are characterized in Table 6-1 as a major mission degradation without effects to the outside world of the system. A future activity may perform ISVV to enable a use in category B settings. The qualification will be done according to ECSS standards (ECSS-E-ST-40C and ECSS-Q-ST-80C). The standards are available at http://ecss.nl/ free of charge after registration. The project consists of four major tasks. 1. Qualification toolchain This task aims to produce a tool chain so that qualification related work can be carried out efficiently. For example: document generation, test suite runs (including code coverage), test reporting, test result archiving, code metrics, static code analysis, traceability (e.g. requirements to tests), etc. 2. RTEMS SMP qualification data package This task covers the main RTEMS components (source code, tests, documentation; new: requirements document, ECSS standard tailoring) so that a data package for space mission consumers can be generated. * #3702: Space profile for RTEMS SMP * #3703: Technical Specification (TS) for space profile * #3705: Software Design Document (SDD) for space profile * #3704: Review and update Doxygen recommendations * #3706: Create a hierarchy of RTEMS software components using Doxygen groups * #3707: Assign each code file to a Doxygen group + * #3708: Remove Doxygen comments from confdefs.h 3. RTEMS SMP formal verification This is a research project. The aim is to apply formal methods for the verification of a subset of the RTEMS SMP algorithms. 4. RTEMS SMP application porting The goal of this task is to port an existing uniprocessor space software from RTEMS 4.8 (RTEMS Improvement by Edisoft) to RTEMS SMP. The algorithms used by the software needs to be parallelized. The project partners are: * [Edisoft](http://www.edisoft.pt/) (prime) and [CISTER](http://www.cister.isep.ipp.pt/) from Portugal * [Lero](https://www.lero.ie/) with Lero researchers from Trinity College Dublin and University of Limerick from Ireland * [Jena-Optronik GmbH](https://www.jena-optronik.de/) and [embedded brains GmbH](https://embedded-brains.de/) from Germany The results of this activity should be open source and available to the RTEMS community.
Author: Trac Migrate
2019-03-04T13:09:08.000Z
Original author: sebastian.huber
Original author: sebastian.huber
Description changed
This ticket summarises activities carried out by a 24 month project sponsored by the European Space Agency (ESA). The project start was February 2019. The main goal of the project is to enable European space missions to use RTEMS as a software product in criticality category C (this is basically category B without independent software verification and validation, ISVV). Criticality category C means according to [ECSS-Q-ST-80C](http://ecss.nl/standard/ecss-q-st-80c-rev-1-software-product-assurance-15-february-2017/): "Software that if not executed, or if not correctly executed, or whose anomalous behaviour can cause or contribute to a system failure resulting in: Major consequences" In [ECSS-Q-ST-40C](https://ecss.nl/standard/ecss-e-st-40c-software-general-requirements/) major consequences are characterized in Table 6-1 as a major mission degradation without effects to the outside world of the system. A future activity may perform ISVV to enable a use in category B settings. The qualification will be done according to ECSS standards (ECSS-E-ST-40C and ECSS-Q-ST-80C). The standards are available at http://ecss.nl/ free of charge after registration. The project consists of four major tasks. 1. Qualification toolchain This task aims to produce a tool chain so that qualification related work can be carried out efficiently. For example: document generation, test suite runs (including code coverage), test reporting, test result archiving, code metrics, static code analysis, traceability (e.g. requirements to tests), etc. 2. RTEMS SMP qualification data package This task covers the main RTEMS components (source code, tests, documentation; new: requirements document, ECSS standard tailoring) so that a data package for space mission consumers can be generated. * #3702: Space profile for RTEMS SMP * #3703: Technical Specification (TS) for space profile + * #3715: Add Requirements Engineering chaper to RTEMS Software Engineering Handbook * #3705: Software Design Document (SDD) for space profile * #3704: Review and update Doxygen recommendations * #3706: Create a hierarchy of RTEMS software components using Doxygen groups * #3707: Assign each code file to a Doxygen group * #3708: Remove Doxygen comments from confdefs.h + * #3716: Unit, integration and validation tests for space profile + * #3717: Add test guidelines chapter to RTEMS Software Engineering Handbook + * #3718: Add support for test plans + * #3199: New test framework 3. RTEMS SMP formal verification This is a research project. The aim is to apply formal methods for the verification of a subset of the RTEMS SMP algorithms. 4. RTEMS SMP application porting The goal of this task is to port an existing uniprocessor space software from RTEMS 4.8 (RTEMS Improvement by Edisoft) to RTEMS SMP. The algorithms used by the software needs to be parallelized. The project partners are: * [Edisoft](http://www.edisoft.pt/) (prime) and [CISTER](http://www.cister.isep.ipp.pt/) from Portugal * [Lero](https://www.lero.ie/) with Lero researchers from Trinity College Dublin and University of Limerick from Ireland * [Jena-Optronik GmbH](https://www.jena-optronik.de/) and [embedded brains GmbH](https://embedded-brains.de/) from Germany The results of this activity should be open source and available to the RTEMS community. -
Author: Trac Migrate
2019-03-04T13:11:03.000Z
Original author: sebastian.huber
Original author: sebastian.huber
Description changed
This ticket summarises activities carried out by a 24 month project sponsored by the European Space Agency (ESA). The project start was February 2019. The main goal of the project is to enable European space missions to use RTEMS as a software product in criticality category C (this is basically category B without independent software verification and validation, ISVV). Criticality category C means according to [ECSS-Q-ST-80C](http://ecss.nl/standard/ecss-q-st-80c-rev-1-software-product-assurance-15-february-2017/): "Software that if not executed, or if not correctly executed, or whose anomalous behaviour can cause or contribute to a system failure resulting in: Major consequences" In [ECSS-Q-ST-40C](https://ecss.nl/standard/ecss-e-st-40c-software-general-requirements/) major consequences are characterized in Table 6-1 as a major mission degradation without effects to the outside world of the system. A future activity may perform ISVV to enable a use in category B settings. The qualification will be done according to ECSS standards (ECSS-E-ST-40C and ECSS-Q-ST-80C). The standards are available at http://ecss.nl/ free of charge after registration. The project consists of four major tasks. 1. Qualification toolchain This task aims to produce a tool chain so that qualification related work can be carried out efficiently. For example: document generation, test suite runs (including code coverage), test reporting, test result archiving, code metrics, static code analysis, traceability (e.g. requirements to tests), etc. 2. RTEMS SMP qualification data package This task covers the main RTEMS components (source code, tests, documentation; new: requirements document, ECSS standard tailoring) so that a data package for space mission consumers can be generated. * #3702: Space profile for RTEMS SMP * #3703: Technical Specification (TS) for space profile - * #3715: Add Requirements Engineering chaper to RTEMS Software Engineering Handbook + * #3715: Add Requirements Engineering chapter to RTEMS Software Engineering Handbook ? + * #3705: Software Design Document (SDD) for space profile * #3704: Review and update Doxygen recommendations * #3706: Create a hierarchy of RTEMS software components using Doxygen groups * #3707: Assign each code file to a Doxygen group * #3708: Remove Doxygen comments from confdefs.h * #3716: Unit, integration and validation tests for space profile * #3717: Add test guidelines chapter to RTEMS Software Engineering Handbook * #3718: Add support for test plans * #3199: New test framework 3. RTEMS SMP formal verification This is a research project. The aim is to apply formal methods for the verification of a subset of the RTEMS SMP algorithms. 4. RTEMS SMP application porting The goal of this task is to port an existing uniprocessor space software from RTEMS 4.8 (RTEMS Improvement by Edisoft) to RTEMS SMP. The algorithms used by the software needs to be parallelized. The project partners are: * [Edisoft](http://www.edisoft.pt/) (prime) and [CISTER](http://www.cister.isep.ipp.pt/) from Portugal * [Lero](https://www.lero.ie/) with Lero researchers from Trinity College Dublin and University of Limerick from Ireland * [Jena-Optronik GmbH](https://www.jena-optronik.de/) and [embedded brains GmbH](https://embedded-brains.de/) from Germany The results of this activity should be open source and available to the RTEMS community.
Author: Trac Migrate
2019-03-13T06:38:43.000Z
Original author: sebastian.huber
Original author: sebastian.huber
Description changed
This ticket summarises activities carried out by a 24 month project sponsored by the European Space Agency (ESA). The project start was February 2019. The main goal of the project is to enable European space missions to use RTEMS as a software product in criticality category C (this is basically category B without independent software verification and validation, ISVV). Criticality category C means according to [ECSS-Q-ST-80C](http://ecss.nl/standard/ecss-q-st-80c-rev-1-software-product-assurance-15-february-2017/): "Software that if not executed, or if not correctly executed, or whose anomalous behaviour can cause or contribute to a system failure resulting in: Major consequences" In [ECSS-Q-ST-40C](https://ecss.nl/standard/ecss-e-st-40c-software-general-requirements/) major consequences are characterized in Table 6-1 as a major mission degradation without effects to the outside world of the system. A future activity may perform ISVV to enable a use in category B settings. The qualification will be done according to ECSS standards (ECSS-E-ST-40C and ECSS-Q-ST-80C). The standards are available at http://ecss.nl/ free of charge after registration. The project consists of four major tasks. 1. Qualification toolchain This task aims to produce a tool chain so that qualification related work can be carried out efficiently. For example: document generation, test suite runs (including code coverage), test reporting, test result archiving, code metrics, static code analysis, traceability (e.g. requirements to tests), etc. 2. RTEMS SMP qualification data package This task covers the main RTEMS components (source code, tests, documentation; new: requirements document, ECSS standard tailoring) so that a data package for space mission consumers can be generated. * #3702: Space profile for RTEMS SMP * #3703: Technical Specification (TS) for space profile - * #3715: Add Requirements Engineering chapter to RTEMS Software Engineering Handbook ? --------------------- + * #3715: Add Requirements Engineering chapter to RTEMS Software + * #3726: Select a requirements engineering tool + Engineering Handbook * #3705: Software Design Document (SDD) for space profile * #3704: Review and update Doxygen recommendations * #3706: Create a hierarchy of RTEMS software components using Doxygen groups * #3707: Assign each code file to a Doxygen group * #3708: Remove Doxygen comments from confdefs.h * #3716: Unit, integration and validation tests for space profile * #3717: Add test guidelines chapter to RTEMS Software Engineering Handbook * #3718: Add support for test plans * #3199: New test framework 3. RTEMS SMP formal verification This is a research project. The aim is to apply formal methods for the verification of a subset of the RTEMS SMP algorithms. 4. RTEMS SMP application porting The goal of this task is to port an existing uniprocessor space software from RTEMS 4.8 (RTEMS Improvement by Edisoft) to RTEMS SMP. The algorithms used by the software needs to be parallelized. The project partners are: * [Edisoft](http://www.edisoft.pt/) (prime) and [CISTER](http://www.cister.isep.ipp.pt/) from Portugal * [Lero](https://www.lero.ie/) with Lero researchers from Trinity College Dublin and University of Limerick from Ireland * [Jena-Optronik GmbH](https://www.jena-optronik.de/) and [embedded brains GmbH](https://embedded-brains.de/) from Germany The results of this activity should be open source and available to the RTEMS community.
Author: Trac Migrate
2019-03-13T06:40:22.000Z
Original author: sebastian.huber
Original author: sebastian.huber
Description changed
This ticket summarises activities carried out by a 24 month project sponsored by the European Space Agency (ESA). The project start was February 2019. The main goal of the project is to enable European space missions to use RTEMS as a software product in criticality category C (this is basically category B without independent software verification and validation, ISVV). Criticality category C means according to [ECSS-Q-ST-80C](http://ecss.nl/standard/ecss-q-st-80c-rev-1-software-product-assurance-15-february-2017/): "Software that if not executed, or if not correctly executed, or whose anomalous behaviour can cause or contribute to a system failure resulting in: Major consequences" In [ECSS-Q-ST-40C](https://ecss.nl/standard/ecss-e-st-40c-software-general-requirements/) major consequences are characterized in Table 6-1 as a major mission degradation without effects to the outside world of the system. A future activity may perform ISVV to enable a use in category B settings. The qualification will be done according to ECSS standards (ECSS-E-ST-40C and ECSS-Q-ST-80C). The standards are available at http://ecss.nl/ free of charge after registration. The project consists of four major tasks. 1. Qualification toolchain This task aims to produce a tool chain so that qualification related work can be carried out efficiently. For example: document generation, test suite runs (including code coverage), test reporting, test result archiving, code metrics, static code analysis, traceability (e.g. requirements to tests), etc. 2. RTEMS SMP qualification data package This task covers the main RTEMS components (source code, tests, documentation; new: requirements document, ECSS standard tailoring) so that a data package for space mission consumers can be generated. * #3702: Space profile for RTEMS SMP * #3703: Technical Specification (TS) for space profile - * #3715: Add Requirements Engineering chapter to RTEMS Software + * #3715: Add Requirements Engineering chapter to RTEMS Software Engineering Handbook ? +++++++++++++++++++++ * #3726: Select a requirements engineering tool - Engineering Handbook * #3705: Software Design Document (SDD) for space profile * #3704: Review and update Doxygen recommendations * #3706: Create a hierarchy of RTEMS software components using Doxygen groups * #3707: Assign each code file to a Doxygen group * #3708: Remove Doxygen comments from confdefs.h * #3716: Unit, integration and validation tests for space profile * #3717: Add test guidelines chapter to RTEMS Software Engineering Handbook * #3718: Add support for test plans * #3199: New test framework 3. RTEMS SMP formal verification This is a research project. The aim is to apply formal methods for the verification of a subset of the RTEMS SMP algorithms. 4. RTEMS SMP application porting The goal of this task is to port an existing uniprocessor space software from RTEMS 4.8 (RTEMS Improvement by Edisoft) to RTEMS SMP. The algorithms used by the software needs to be parallelized. The project partners are: * [Edisoft](http://www.edisoft.pt/) (prime) and [CISTER](http://www.cister.isep.ipp.pt/) from Portugal * [Lero](https://www.lero.ie/) with Lero researchers from Trinity College Dublin and University of Limerick from Ireland * [Jena-Optronik GmbH](https://www.jena-optronik.de/) and [embedded brains GmbH](https://embedded-brains.de/) from Germany The results of this activity should be open source and available to the RTEMS community.
Author: Chris Johns
2019-03-20T01:33:11.000Z
Original author: sebastian.huber
Summary changed from RTEMS SMP Pre-Qualification (ECSS) to RTEMS Pre-Qualification (ECSS) for SMP
Correct the title.
Author: Chris Johns
2022-11-29T21:38:18.000Z
Original author: sebastian.huber
Please update. This ticket is still blocked by 3 other tickets?
Author: Trac Migrate
2022-11-30T08:50:46.000Z
Original author: sebastian.huber
Milestone changed from %”6.1” to %”7.1”
Yes, there are still open issues.
Author: Amar Takhar
2024-04-25T20:47:07.717Z
changed the description
Author: Amar Takhar
2024-04-25T20:47:08.650Z
mentioned in issue #3702
Author: Amar Takhar
2024-04-25T20:50:56.426Z
mentioned in issue #4963
Author: Sebastian Huber
2024-07-02T07:35:23.427Z
mentioned in commit 6c5925361cd8360768197cfcb907da731f28d496
Author: Joel Sherrill
2025-09-18T23:58:23.150Z
unassigned @tracmigrate
Author: Chris Johns
2026-07-30T23:09:38.840Z
assigned to @sebhub
Author: Chris Johns
2026-07-30T23:10:08.608Z
Please update the Status.
5663 - Follow-up from “spintrcritical0[1-5, 20, 23]: Fix sporadic test failures” (opened)¶
Id |
5663 |
State |
opened |
Type |
ISSUE |
Author |
Chris Johns |
Assignee(s) |
Sebastian Huber |
Created |
2026-07-28T01:27:09.386Z |
Updated |
2026-07-28T01:27:09.386Z |
Milestone |
6.3 |
Labels |
rtems::testing |
Link |
|
Merges |
0 |
The following discussion from !1370 should be addressed:
[] @chris started a discussion: (+1 comment)
Is the same issue on RTEMS 6?
Author: Chris Johns
2026-07-28T01:27:09.571Z
added rtems#15 as parent item
Author: Chris Johns
2026-07-28T01:27:09.668Z
set status to To do
Author: Chris Johns
2026-07-28T01:27:09.787Z
assigned to @sebhub
4364 - rtems-test Fails to list failed tests to user (opened)¶
Id |
4364 |
State |
opened |
Type |
ISSUE |
Author |
Joel Sherrill |
Assignee(s) |
Chris Johns |
Created |
2021-03-28T15:51:47.000Z |
Updated |
2025-10-02T22:39:35.876Z |
Milestone |
6.3 |
Labels |
priority::normal, tickettype::defect, tool::rtems-source-builder, version::6 |
Link |
|
Merges |
0 |
rtems-test does not report the set of failed tests to the user at the conclusion of its run. It only gives a summary by category. They ARE in the log file. I assume this is a minor issue now that I have spotted the pattern.
I assume this also applies to 5 but I spotted it on 6 during the recent heavy round of manual testing.
Author: Amar Takhar
2024-05-17T02:02:50.798Z
Joel are you OK with this being moved to %6.2 Since there is already a solution this is more of an ease-of-use feature.
Author: Joel Sherrill
2024-05-17T13:46:01.611Z
It is not an ease of use feature. If interactive, you do not get the list of failures unless you enable logging.
I don’t mind moving the milestone though. This has been sitting here for 3 years already.
Author: Amar Takhar
2024-05-17T15:09:16.482Z
changed the description
Author: Gedare Bloom
2024-12-04T21:40:36.939Z
Author: Chris Johns
2025-10-02T22:39:32.181Z
added rtems#15 as parent epic
Merge Requests¶
1439 - libfs/pipe: Add pipe and pipe2 indirect handler calls¶
Id |
1439 |
State |
merged |
Merged by |
Kinsey Moore |
Merged at |
2026-08-24T02:01:52.621Z |
Created |
2026-08-21T00:34:31.425Z |
Updated |
2026-08-24T02:01:52.613Z |
Milestone |
6.3 |
Labels |
cpukit |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1439 |
Commit |
Backport of ec42cadd3b4 (!1383) to 6, needed so rtems/pkg/rtems-libbsd!156 can follow to 6-freebsd-14 — the handler registration cannot link without the hooks. psxpipe01 passes on arm/xilinx_zynq_a9_qemu.
Author: Kinsey Moore
2026-08-23T00:06:21.378Z
enabled an automatic merge when all merge checks for 51f962fb3fd8e1eae4249d04f3821e7630eda774 pass
Author: Kinsey Moore
2026-08-23T00:06:22.395Z
approved this merge request
Author: Joel Sherrill
2026-08-24T02:01:49.747Z
approved this merge request
976 - Complete the u-boot support for qoriq BSP¶
Id |
976 |
State |
merged |
Merged by |
Kinsey Moore |
Merged at |
2026-07-31T00:33:40.157Z |
Created |
2026-01-30T21:19:00.503Z |
Updated |
2026-07-31T00:33:40.150Z |
Milestone |
6.3 |
Labels |
arch:powerpc, backport |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/976 |
Commit |
Summary¶
The u-boot support for powerpc/qoriq is not complete. Under bsps/powerpc/qoriq/include/bsp.h, bsp_uboot_getenv is declared if HAS_UBOOT is defined. However, in HAS_UBOOT is not configurable through waf and variables needed by bsp_uboot_getenv are not defined for qoriq.
Added the .yml files under spec so that HAS_UBOOT can be defined in config.ini
Updated .yml files for the added build dependencies
Added uboot_support.c to define the u-boot environment base address and size
Generative AI¶
Author: Joel Sherrill
2026-02-06T18:25:22.347Z
Please complete the Generative AI statement for the MR.
Author: Ran Hong
2026-02-06T18:25:22.347Z
I didn’t use Generative AI at all, so I left it blank as instructed in the comment from the template. Should I write anything there instead?
Author: Joel Sherrill
2026-02-06T18:31:18.325Z
Where did this address come from? It needs a reference.
Author: Ran Hong
2026-02-06T18:13:04.282Z
changed this line in version 2 of the diff
Author: Ran Hong
2026-02-06T18:31:18.325Z
This address is actually configurable by users. I am developing this feature for a specific board (mvme2500) that can run with the qoriq_e500 BSP. For mvme2500, it has a 512k MRAM (a type of nonvolatile memory) starting from address 0xfff00000, which can be configured to hold the u-boot environment, and it can be access using the same functions in bsps/powerpc/shared/u-boot. I updated the address and mentioned that this can be referenced to the mvme2500 manual.
Author: Joel Sherrill
2026-02-06T18:31:04.303Z
The comment blocks at the top of this file need to follow the RTEMS standard. There are plenty of examples beyond what’s documented.
Author: Ran Hong
2026-02-06T18:13:04.863Z
changed this line in version 2 of the diff
Author: Ran Hong
2026-02-06T18:31:04.303Z
Yes. Updated.
Author: Joel Sherrill
2026-02-06T18:30:23.328Z
Delete the white space except for one before the =
Author: Ran Hong
2026-02-06T18:13:05.390Z
changed this line in version 2 of the diff
Author: Ran Hong
2026-02-06T18:30:23.328Z
sure. Changed.
Author: Gedare Bloom
2026-02-09T22:19:57.900Z
Is there a reason this targets
6and not going intomain?
Author: Ran Hong
2026-02-09T22:19:57.900Z
Since most of my current development work is based on branch 6, so I would like to have it updated first. Then I will create a similar merge request for main.
Author: Gedare Bloom
2026-02-09T22:19:57.900Z
Please have a look at https://docs.rtems.org/docs/main/eng/release-maintenance.html#release-backports to see the process for MRs on release branch. You’ll need to create an issue for this, and might need some help to link it to the epic and set the issue metadata.
We will want to have the merge request available for
mainbefore we merge into6most likely.
Author: Ran Hong
2026-02-09T22:19:57.900Z
I do have a issue for this, but I am not so sure how to link the issue (https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5439) with this merge request. I will work on the merge request on main and link it to the issue. After reading Joel’s comment, I think I can make the uboot environment base address configurable via waf configure.
Author: Ran Hong
2026-02-09T22:19:57.900Z
I just created another merge request !1046. I modified the code according to the comments Joel gave. The related issue is #5439, but I am not sure how to link them together. Could anyone help? Thanks!
Author: Kinsey Moore
2026-02-06T18:48:00.346Z
This needs a backport issue and the issue should be referenced from the commit message with:
Closes #issuenumberhere
Author: Kinsey Moore
2026-02-05T22:12:32.227Z
created #5481 to continue this discussion
Author: Kinsey Moore
2026-02-06T18:48:00.346Z
I have created #5481 for this purpose.
Author: Kinsey Moore
2026-02-05T22:12:33.135Z
mentioned in issue #5481
Author: Ran Hong
2026-02-06T18:13:05.761Z
added 1 commit
bc1b7c79 - Add the u-boot support for powerpc/qoriq.
Author: Ran Hong
2026-02-06T18:20:39.305Z
added 1 commit
3a9aa308 - bsps/powerpc/qoriq: Add the u-boot support for powerpc/qoriq.
Author: Ran Hong
2026-02-06T18:31:18.509Z
left review comments
Author: Ran Hong
2026-02-09T22:19:57.922Z
resolved all threads
Author: Gedare Bloom
2026-02-23T19:29:18.173Z
Add “Closes #5481” to the commit message
Author: Ran Hong
2026-02-23T19:29:18.173Z
It is already in the current commit message. See below. Do I need to move it to the same line?
For qoriq boards with u-boot, user can use the same environment access fuctions shared with other bsps like gen83xx.
Closes #5481
Author: Gedare Bloom
2026-02-23T19:29:18.197Z
resolved all threads
Author: Gedare Bloom
2026-02-23T19:30:34.848Z
resolved all threads
Author: Gedare Bloom
2026-02-23T19:30:35.370Z
approved this merge request
Author: Sebastian Huber
2026-07-31T00:26:36.216Z
On which board was this change tested?
Author: Ran Hong
2026-07-31T00:26:36.216Z
mvme2500
Author: Ran Hong
2026-02-24T16:26:52.647Z
added 2 commits
f6933b9c - 1 commit from branch
rtems/rtos:61e5f181d - bsps/powerpc/qoriq: Add the u-boot support for powerpc/qoriq.
Author: Chris Johns
2026-07-31T00:26:36.239Z
resolved all threads
Author: Chris Johns
2026-07-31T00:26:43.356Z
approved this merge request
Author: Chris Johns
2026-07-31T00:26:53.770Z
added 14 commits
1e5f181d…536f52c4 - 13 commits from branch
rtems/rtos:66c00f0cc - bsps/powerpc/qoriq: Add the u-boot support for powerpc/qoriq.
Author: Chris Johns
2026-07-31T00:26:57.739Z
enabled an automatic merge when all merge checks for 6c00f0cc436ff51cc59db107614c9e59cd533fef pass
Author: Kinsey Moore
2026-07-31T00:33:22.034Z
added 1 commit
2be19a2a - bsps/powerpc/qoriq: Add the u-boot support for powerpc/qoriq.
Author: Kinsey Moore
2026-07-31T00:33:30.396Z
enabled an automatic merge when all merge checks for 2be19a2a0a6b35604f4bc55e714d854bcbfe32ef pass
1378 - libmisc/shell: Add -a to print all vars in the shell getenv command¶
Id |
1378 |
State |
merged |
Merged by |
Gedare Bloom |
Merged at |
2026-07-29T02:50:10.715Z |
Assignee(s) |
Chris Johns |
Created |
2026-07-28T04:22:15.350Z |
Updated |
2026-07-29T02:50:10.605Z |
Milestone |
6.3 |
Labels |
rtems::shell |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1378 |
Commit |
Summary¶
libmisc/shell: Add -a to print all vars in the shell getenv command
Closes #5664
Generative AI¶
None
Author: Chris Johns
2026-07-28T04:22:15.543Z
assigned to @chris
Author: Chris Johns
2026-07-28T04:22:22.330Z
enabled an automatic merge when all merge checks for ccc42007085e071156f9ce6a203d29a09ca5eb35 pass
Author: Kinsey Moore
2026-07-28T13:48:46.985Z
approved this merge request
Author: Chris Johns
2026-07-29T02:26:51.400Z
aborted the automatic merge because target branch was updated
Author: Gedare Bloom
2026-07-29T02:49:32.494Z
approved this merge request
Author: Gedare Bloom
2026-07-29T02:49:46.651Z
added 3 commits
ccc42007…50887ddf - 2 commits from branch
rtems/rtos:6536f52c4 - libmisc/shell: Add -a to print all vars in the shell getenv command
1380 - powerpc/motorola_powerpc: Convert PPCBug NVRAM vars into env vars¶
Id |
1380 |
State |
merged |
Merged by |
Gedare Bloom |
Merged at |
2026-07-29T02:34:25.666Z |
Assignee(s) |
Chris Johns |
Created |
2026-07-28T05:16:42.478Z |
Updated |
2026-07-29T02:34:25.659Z |
Milestone |
6.3 |
Labels |
arch:powerpc |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1380 |
Commit |
Summary¶
powerpc/motorola_powerpc: Convert PPCBug NVRAM vars into env vars
Closes #5666
Generative AI¶
None
Author: Chris Johns
2026-07-28T05:16:42.657Z
assigned to @chris
Author: Chris Johns
2026-07-28T05:16:49.783Z
enabled an automatic merge when all merge checks for cbb62bd6195745fb0f96784918ec27d41183d050 pass
Author: Vijay Banerjee
2026-07-28T13:41:19.035Z
approved this merge request
Author: Kinsey Moore
2026-07-28T13:49:13.760Z
approved this merge request
Author: Chris Johns
2026-07-29T02:26:51.032Z
aborted the automatic merge because target branch was updated
Author: Gedare Bloom
2026-07-29T02:27:22.084Z
added 2 commits
41622343 - 1 commit from branch
rtems/rtos:650887ddf - powerpc/motorola_powerpc: Convert PPCBug NVRAM vars into env vars
Author: Gedare Bloom
2026-07-29T02:33:47.705Z
approved this merge request
1379 - powerpc/beatnik: Convert MOTLoad GEV variables into env variables¶
Id |
1379 |
State |
merged |
Merged by |
Chris Johns |
Merged at |
2026-07-29T02:26:49.041Z |
Assignee(s) |
Chris Johns |
Created |
2026-07-28T04:33:46.457Z |
Updated |
2026-07-29T02:26:49.034Z |
Milestone |
6.3 |
Labels |
arch:powerpc |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1379 |
Commit |
Summary¶
powerpc/beatnik: Convert MOTLoad GEV variables into env variables
Closes #5665
Generative AI¶
None
Author: Chris Johns
2026-07-28T04:33:46.591Z
assigned to @chris
Author: Chris Johns
2026-07-28T04:33:54.561Z
enabled an automatic merge when all merge checks for 4162234368cf643db525028b26b461362eb2e5a4 pass
Author: Kinsey Moore
2026-07-28T13:48:56.000Z
approved this merge request
Author: Gedare Bloom
2026-07-29T02:26:46.445Z
approved this merge request
1354 - cpukit/flashdev: Clarify interface and update consumers¶
Id |
1354 |
State |
merged |
Merged by |
Joel Sherrill |
Merged at |
2026-07-27T21:35:14.597Z |
Assignee(s) |
Kinsey Moore |
Created |
2026-07-16T21:50:50.635Z |
Updated |
2026-07-27T21:35:14.588Z |
Milestone |
6.3 |
Labels |
device::flash |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1354 |
Commit |
Summary¶
cpukit/flashdev: Clarify interface and update consumers
This clarifies the flashdev out of band read and write interfaces and updates any consumers of those interfaces. This was partially refactored at one point and the refactoring didn’t extend to the consumers as it should have.
Closes #5652
Generative AI¶
None
Author: Kinsey Moore
2026-07-16T21:50:50.763Z
assigned to @opticron
Author: Kinsey Moore
2026-07-16T21:51:15.765Z
marked this merge request as blocked by !1353
Author: Kinsey Moore
2026-07-27T02:42:38.928Z
mentioned in merge request !1373
Author: Kinsey Moore
2026-07-27T02:43:04.160Z
enabled an automatic merge when all merge checks for 640dfd5c21caa977ee60077311fca87f1a9a739b pass
Author: Chris Johns
2026-07-27T02:47:48.249Z
approved this merge request
Author: Chris Johns
2026-07-27T14:11:43.855Z
aborted the automatic merge because target branch was updated
Author: Joel Sherrill
2026-07-27T21:34:50.108Z
approved this merge request
Author: Joel Sherrill
2026-07-27T21:34:57.707Z
added 8 commits
640dfd5c…e2859cf1 - 7 commits from branch
rtems/rtos:6178fee57 - cpukit/flashdev: Clarify interface and update consumers
Author: Joel Sherrill
2026-07-27T21:35:01.583Z
enabled an automatic merge when all merge checks for 178fee57713da888ae41062fa2e51d980cbb3d91 pass
1375 - Backport libdebugger fix for corruption of thread registers with 32 or more threads¶
Id |
1375 |
State |
merged |
Merged by |
Vijay Banerjee |
Merged at |
2026-07-27T14:26:27.216Z |
Assignee(s) |
Chris Johns |
Created |
2026-07-27T03:27:08.599Z |
Updated |
2026-07-27T14:26:27.202Z |
Milestone |
6.3 |
Labels |
cpukit::debugger |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1375 |
Commit |
Summary¶
libdebugger: Fix corruption of thread registers with 32 or more threads
The block logic uses realloc to resize memory used by libdebugger when creating a snapshot of threads. Thread registers take a reference to the block and if a realloc changes the base address any references are invalid. Add rebase handler support to blocks that is called when the block base changes and add a handler to thread register blocks to rebase a thread’s registers.
Exclude threads using both types of names they can have. This lets all names be reported in extra thread info packets.
Closes #5662
Generative AI¶
None
Author: Chris Johns
2026-07-27T03:27:08.984Z
assigned to @chris
Author: Chris Johns
2026-07-27T03:27:23.372Z
enabled an automatic merge when all merge checks for 8c57cbe765fc1ce564b501867359d77c047595db pass
Author: Chris Johns
2026-07-27T14:11:44.750Z
aborted the automatic merge because target branch was updated
Author: Joel Sherrill
2026-07-27T14:23:30.989Z
approved this merge request
Author: Joel Sherrill
2026-07-27T14:23:37.403Z
added 6 commits
8c57cbe7…d22c6298 - 5 commits from branch
rtems/rtos:6fcd5676b - libdebugger: Fix corruption of thread registers with 32 or more threads
Author: Joel Sherrill
2026-07-27T14:23:42.039Z
enabled an automatic merge when all merge checks for fcd5676b6d24131748db1eeb05d617f969df728a pass
Author: Joel Sherrill
2026-07-27T14:24:38.637Z
aborted the automatic merge because target branch was updated
Author: Vijay Banerjee
2026-07-27T14:25:58.922Z
approved this merge request
Author: Vijay Banerjee
2026-07-27T14:26:13.381Z
added 2 commits
5c074eb0 - 1 commit from branch
rtems/rtos:6e2859cf1 - libdebugger: Fix corruption of thread registers with 32 or more threads
Author: Vijay Banerjee
2026-07-27T14:26:22.248Z
enabled an automatic merge when all merge checks for e2859cf1c5dbfde7dc2ddb5e2e0aaa3c0dbda822 pass
1374 - Backport cpuuse fix of thread names in top¶
Id |
1374 |
State |
merged |
Merged by |
Joel Sherrill |
Merged at |
2026-07-27T14:24:36.541Z |
Assignee(s) |
Chris Johns |
Created |
2026-07-27T02:52:44.823Z |
Updated |
2026-07-27T14:24:36.533Z |
Milestone |
6.3 |
Labels |
rtems::shell |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1374 |
Commit |
Summary¶
libmisc/cpuuse: Fix thread names in top
Show classic and POSIX thread names working around the mess we now have with the name management in threads
Closes #5638
Generative AI¶
None
Author: Chris Johns
2026-07-27T02:52:44.993Z
assigned to @chris
Author: Chris Johns
2026-07-27T02:53:32.292Z
enabled an automatic merge when all merge checks for c2f5a380f1c9d5d4d46e1d24f7a9710e3ca94d0d pass
Author: Chris Johns
2026-07-27T03:05:05.045Z
changed title from
Backport puuse fix of thread names in top
to
Backport
c
puuse fix of thread names in top
Author: Kinsey Moore
2026-07-27T13:55:09.653Z
approved this merge request
Author: Chris Johns
2026-07-27T14:11:44.311Z
aborted the automatic merge because target branch was updated
Author: Joel Sherrill
2026-07-27T14:24:15.198Z
approved this merge request
Author: Joel Sherrill
2026-07-27T14:24:18.547Z
added 6 commits
c2f5a380…d22c6298 - 5 commits from branch
rtems/rtos:65c074eb0 - libmisc/cpuuse: Fix thread names in top
Author: Joel Sherrill
2026-07-27T14:24:21.185Z
enabled an automatic merge when all merge checks for 5c074eb03c35fb617ce4456925d2c1c55fe0c134 pass
1376 - Backport libdebugger to add TCB to extra thread info¶
Id |
1376 |
State |
merged |
Merged by |
Vijay Banerjee |
Merged at |
2026-07-27T14:22:21.473Z |
Assignee(s) |
Chris Johns |
Created |
2026-07-27T03:33:58.342Z |
Updated |
2026-07-27T14:22:21.465Z |
Milestone |
6.3 |
Labels |
cpukit::debugger |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1376 |
Commit |
Summary¶
libdebugger: Add TCB to extra thread info
Closes #5640
Generative AI¶
None
Author: Chris Johns
2026-07-27T03:33:58.516Z
assigned to @chris
Author: Chris Johns
2026-07-27T03:34:12.269Z
enabled an automatic merge when all merge checks for d4e04de9fb5a6811d3656b041a75debf4b8c157d pass
Author: Kinsey Moore
2026-07-27T13:53:01.358Z
approved this merge request
Author: Chris Johns
2026-07-27T14:11:44.968Z
aborted the automatic merge because target branch was updated
Author: Joel Sherrill
2026-07-27T14:19:49.408Z
approved this merge request
Author: Joel Sherrill
2026-07-27T14:19:58.189Z
added 5 commits
d4e04de9…d38a27d7 - 4 commits from branch
rtems/rtos:6d22c6298 - libdebugger: Add TCB to extra thread info
1372 - Remove MGHTTP (Mongoose) Web server¶
Id |
1372 |
State |
merged |
Merged by |
Vijay Banerjee |
Merged at |
2026-07-27T14:19:22.504Z |
Assignee(s) |
Chris Johns |
Created |
2026-07-27T02:30:02.964Z |
Updated |
2026-07-27T14:19:22.497Z |
Milestone |
6.3 |
Labels |
cpukit |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1372 |
Commit |
The Mongoose web server was subject to CVE notices. This change removed the code from RTEMS and we recommend all RTEMS 6 users move to the CivetWeb.
Closes #5310
Generative AI¶
None
Author: Chris Johns
2026-07-27T02:30:03.530Z
assigned to @chris
Author: Chris Johns
2026-07-27T02:30:18.945Z
enabled an automatic merge when all merge checks for cda97e309af7e0c8f721444c72b28e9867bc9a15 pass
Author: Kinsey Moore
2026-07-27T02:32:18.863Z
approved this merge request
Author: Chris Johns
2026-07-27T14:11:44.580Z
aborted the automatic merge because target branch was updated
Author: Vijay Banerjee
2026-07-27T14:18:09.723Z
added 4 commits
cda97e30…0e36f6ca - 3 commits from branch
rtems/rtos:6d38a27d7 - cpukit/mghttp: Remove
Author: Vijay Banerjee
2026-07-27T14:18:41.738Z
approved this merge request
1371 - Backport PowerPC assembler warnings fixes¶
Id |
1371 |
State |
merged |
Merged by |
Chris Johns |
Merged at |
2026-07-27T14:11:40.926Z |
Assignee(s) |
Chris Johns |
Created |
2026-07-27T02:10:44.460Z |
Updated |
2026-07-27T14:11:40.918Z |
Milestone |
6.3 |
Labels |
arch:powerpc |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1371 |
Commit |
The commits are backports of fixes in main.
Updates #5661
Generative AI¶
No
Author: Chris Johns
2026-07-27T02:10:44.670Z
assigned to @chris
Author: Chris Johns
2026-07-27T02:11:04.221Z
enabled an automatic merge when all merge checks for 0e36f6cae8e3320bce41b83a364983f59c8e4a89 pass
Author: Vijay Banerjee
2026-07-27T13:29:17.799Z
approved this merge request
Author: Kinsey Moore
2026-07-27T13:48:46.093Z
approved this merge request
Author: Joel Sherrill
2026-07-27T14:11:38.216Z
approved this merge request
1262 - 6 - powerpc/beatnik: Support generic IRQ¶
Id |
1262 |
State |
merged |
Merged by |
Joel Sherrill |
Merged at |
2026-05-28T23:22:57.773Z |
Assignee(s) |
Chris Johns |
Created |
2026-05-26T01:19:44.360Z |
Updated |
2026-05-28T23:22:57.762Z |
Milestone |
6.3 |
Labels |
arch:powerpc, backport |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1262 |
Commit |
Summary¶
powerpc/beatnik: Support generic IRQ
This effects the MVME6100 and MVME5500.
Closes #5589
Generative AI¶
None
Author: Chris Johns
2026-05-26T01:19:44.548Z
assigned to @chris
Author: Chris Johns
2026-05-26T01:25:24.433Z
added 1 commit
5db21622 - powerpc/beatnik: Support generic IRQ
Author: Gedare Bloom
2026-05-27T21:40:34.524Z
approved this merge request
Author: Joel Sherrill
2026-05-28T23:22:44.524Z
added 2 commits
c4553bbd - 1 commit from branch
rtems/rtos:62faafecb - powerpc/beatnik: Support generic IRQ
Author: Joel Sherrill
2026-05-28T23:22:46.423Z
approved this merge request
Author: Joel Sherrill
2026-05-28T23:22:51.072Z
enabled an automatic merge when all merge checks for 2faafecb7f9df8400fd78a1e6d9b3cf3df0eeccc pass
1252 - bsps/zynq-uart: fix parity configuration handling¶
Id |
1252 |
State |
merged |
Merged by |
Kinsey Moore |
Merged at |
2026-05-18T21:51:14.074Z |
Assignee(s) |
Kinsey Moore |
Created |
2026-05-18T19:21:03.401Z |
Updated |
2026-05-18T21:51:14.064Z |
Milestone |
6.3 |
Labels |
bsp, bsp::shared |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1252 |
Commit |
Summary¶
bsps/zynq-uart: fix parity configuration handling
Fix parity handling in zynq_uart_set_attributes() by clearing existing parity bits before setting a new mode instead of always ORing PAR_NONE, which caused incorrect or ignored parity; also fix inverted PARODD logic and add ZYNQ_UART_MODE_PAR_MASK to manage the parity field correctly.
Generative AI¶
See !1212
Author: Kinsey Moore
2026-05-18T19:21:04.355Z
assigned to @opticron
Author: Kinsey Moore
2026-05-18T19:21:28.719Z
mentioned in merge request !1212
Author: Kinsey Moore
2026-05-18T19:21:32.999Z
enabled an automatic merge when all merge checks for c4553bbd2d35d61adc6e8f5d0b1ca034a0e587d4 pass
Author: Joel Sherrill
2026-05-18T19:54:09.962Z
approved this merge request
Author: Gedare Bloom
2026-05-18T21:51:11.718Z
approved this merge request
1060 - cpukit/libio: Fix race condition in iop free¶
Id |
1060 |
State |
merged |
Merged by |
Joel Sherrill |
Merged at |
2026-02-12T21:35:14.631Z |
Assignee(s) |
Kinsey Moore |
Created |
2026-02-12T21:09:28.230Z |
Updated |
2026-02-12T21:35:14.620Z |
Milestone |
6.3 |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1060 |
Commit |
Summary¶
cpukit/libio: Fix race condition in iop free
Closes #5490
Generative AI¶
Author: Kinsey Moore
2026-02-12T21:09:28.382Z
assigned to @opticron
Author: Joel Sherrill
2026-02-12T21:13:10.187Z
enabled an automatic merge when all merge checks for f6933b9c6ff6780c1b3a56d80aa9577f181e5763 pass
Author: Joel Sherrill
2026-02-12T21:13:20.630Z
approved this merge request
Author: Gedare Bloom
2026-02-12T21:35:11.986Z
approved this merge request
951 - bsps/m68k: Add -D_LDBL_EQ_DBL=1 workaround to ABI_FLAGS¶
Id |
951 |
State |
merged |
Merged by |
Chris Johns |
Merged at |
2026-01-27T13:25:29.116Z |
Assignee(s) |
Jeremy Lorelli |
Reviewer(s) |
Chris Johns |
Created |
2026-01-27T06:06:03.587Z |
Updated |
2026-01-27T13:25:29.107Z |
Milestone |
6.3 |
Labels |
arch:m68k, lang::c |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/951 |
Commit |
Summary¶
Backport of !937
Author: Chris Johns
2026-01-27T07:06:34.137Z
We need an issue for an MR to the branch. I have created the https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5435. Could you please update the commit message to say
Closes #5435and also please update issue with the link to themainbranch MR so the original discussion is linked? Thanks.
Author: Chris Johns
2026-01-27T06:56:45.114Z
Updated commit message with the 6.3 milestone issue,
Author: Chris Johns
2026-01-27T06:56:45.168Z
requested changes
Author: Chris Johns
2026-01-27T06:57:20.702Z
assigned to @jjl77
Author: Chris Johns
2026-01-27T06:58:34.970Z
requested review from @chris
Author: Jeremy Lorelli
2026-01-27T07:04:01.613Z
added 1 commit
a0a80f08 - bsps/m68k: Add -D_LDBL_EQ_DBL=1 workaround to ABI_FLAGS
Author: Chris Johns
2026-01-27T07:06:34.154Z
resolved all threads
Author: Chris Johns
2026-01-27T07:06:37.041Z
approved this merge request
Author: Chris Johns
2026-01-27T07:06:40.196Z
enabled an automatic merge when all merge checks for a0a80f08cad29dc3fdc0fa31a0200725185fda3e pass
Author: Kinsey Moore
2026-01-27T13:25:25.959Z
approved this merge request
884 - Fix failing tests¶
Id |
884 |
State |
merged |
Merged by |
Joel Sherrill |
Merged at |
2026-01-23T01:32:03.974Z |
Assignee(s) |
Kinsey Moore |
Created |
2025-12-26T18:34:14.764Z |
Updated |
2026-01-23T01:32:03.939Z |
Milestone |
6.3 |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/884 |
Commit |
Summary¶
cpukit/sapi/src/interrtext.c: Add missing definition
This adds a missing text description for an internal error and updates the spinternalerror02 test to check for the correct end of internal error definitions.
Closes #5410
cpukit/posix/aio: Override AIO_LISTIO_MAX from newlib
Newer versions of newlib do not define AIO_LISTIO_MAX, so override this value for the RTEMS implementation.
Closes #5227
Author: Kinsey Moore
2025-12-26T18:34:15.701Z
assigned to @opticron
Author: Kinsey Moore
2025-12-26T18:59:29.981Z
changed title from
cpukit/sapi/src/interrtext.c: Add missing definition
to
Fix failing tests
Author: Kinsey Moore
2025-12-26T18:59:30.008Z
changed the description
Author: Kinsey Moore
2026-01-13T21:06:43.545Z
enabled an automatic merge when all merge checks for f9eb6a4bdf44878665e53d59af9a90930331fab1 pass
Author: Kinsey Moore
2026-01-16T22:06:04.468Z
aborted the automatic merge because target branch was updated
Author: Joel Sherrill
2026-01-21T16:54:59.265Z
approved this merge request
Author: Joel Sherrill
2026-01-21T16:55:11.101Z
added 3 commits
7f064c49 - 1 commit from branch
rtems/rtos:6ac41d584 - cpukit/sapi/src/interrtext.c: Add missing definition
4d38bf6e - cpukit/posix/aio: Override AIO_LISTIO_MAX from newlib
Author: Joel Sherrill
2026-01-21T16:56:57.600Z
enabled an automatic merge when all merge checks for 4d38bf6ec039efc0b522ba8e4da7539367f5ff7c pass
Author: Gedare Bloom
2026-01-23T01:31:48.217Z
approved this merge request
916 - bsps/aarch64: Add missing ISB after SCTLR write¶
Id |
916 |
State |
merged |
Merged by |
Kinsey Moore |
Merged at |
2026-01-16T22:06:00.481Z |
Created |
2026-01-15T20:13:36.113Z |
Updated |
2026-01-16T22:06:00.472Z |
Milestone |
6.3 |
Labels |
arch:aarch64 |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/916 |
Commit |
Summary¶
bsps/aarch64: Add missing ISB after SCTLR write
A write to the sctlr_el1 register is a ‘context-changing operation’ and thus requires a pipeline flush for the change to actually take effect on subsequent instructions.
The isb instruction gurantees this, and ensures mmu is enabled immediately.
Closes #5422
Author: Preetam Das
2026-01-15T20:15:57.499Z
mentioned in merge request !908
Author: Kinsey Moore
2026-01-15T20:19:16.861Z
enabled an automatic merge when all merge checks for 7f064c49bdea4c0e7c4d6502e0500c4098f01786 pass
Author: Kinsey Moore
2026-01-15T20:19:19.464Z
approved this merge request
Author: Joel Sherrill
2026-01-16T22:05:57.682Z
approved this merge request
763 - bsps/noelv: Align instruction in bsp_reset()¶
Id |
763 |
State |
merged |
Merged by |
Kinsey Moore |
Merged at |
2025-10-03T15:28:54.408Z |
Created |
2025-10-03T09:41:58.501Z |
Updated |
2025-12-05T00:45:39.623Z |
Milestone |
6.3 |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/763 |
Commit |
Summary¶
bsps/noelv: Align instruction in bsp_reset()
Closes #5368
Author: Joel Sherrill
2025-10-03T15:26:04.990Z
approved this merge request
Author: Kinsey Moore
2025-10-03T15:28:51.306Z
approved this merge request
806 - bsps/qspi: Make flashdev control structure private¶
Id |
806 |
State |
merged |
Merged by |
Chris Johns |
Merged at |
2025-10-20T14:42:05.939Z |
Assignee(s) |
Kinsey Moore |
Created |
2025-10-16T16:34:24.724Z |
Updated |
2025-10-20T14:42:05.931Z |
Milestone |
6.3 |
Labels |
device::spi |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/806 |
Commit |
Summary¶
bsps/qspi: Make flashdev control structure private
These structures are not required to be exposed to users for any functionality and users of the API have no way to make use of them.
Closes #5375
Author: Kinsey Moore
2025-10-16T16:34:24.863Z
assigned to @opticron
Author: Kinsey Moore
2025-10-16T16:35:19.456Z
mentioned in merge request !804
Author: Chris Johns
2025-10-16T21:57:24.723Z
approved this merge request
Author: Chris Johns
2025-10-16T21:57:31.007Z
enabled an automatic merge when all merge checks for 36a3845d9cf896bb14ad9a9534b8f6acacba39b4 pass
Author: Joel Sherrill
2025-10-20T14:42:04.042Z
approved this merge request
1373 - Backport of Flashdev fix to clarify interface and update consumers (closed)¶
Id |
1373 |
State |
closed |
Assignee(s) |
Chris Johns |
Reviewer(s) |
Kinsey Moore |
Closed by |
Chris Johns |
Created |
2026-07-27T02:38:13.085Z |
Closed |
2026-07-27T02:47:36.220Z |
Updated |
2026-07-27T03:32:55.565Z |
Milestone |
6.3 |
Labels |
device::flash |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1373 |
Commit |
cpukit/flashdev: Clarify interface and update consumers
This clarifies the flashdev out of band read and write interfaces and updates any consumers of those interfaces. This was partially refactored at one point and the refactoring didn’t extend to the consumers as it should have.
Closes #5652
Generative AI¶
None
Author: Chris Johns
2026-07-27T02:38:13.228Z
requested review from @opticron
Author: Chris Johns
2026-07-27T02:38:13.246Z
assigned to @chris
Author: Chris Johns
2026-07-27T02:38:26.066Z
enabled an automatic merge when all merge checks for d86d12119a46944f3cbf511d0fb204d8cffa6a38 pass
Author: Kinsey Moore
2026-07-27T02:47:33.070Z
This is a duplicate of !1354
Author: Chris Johns
2026-07-27T02:47:33.070Z
Sorry I did not see the linked MR.
Author: Kinsey Moore
2026-07-27T03:32:55.527Z
It is unfortunate that gitlab only appears to link the MRs one direction and does not show “MRs that depend on this one” for a given MR.
Author: Chris Johns
2026-07-27T02:47:33.093Z
resolved all threads
Author: Chris Johns
2026-07-27T02:47:36.408Z
aborted the automatic merge because merge request was closed
697 - bbb bsp: add modified gpio handling and adc section (opened)¶
Id |
697 |
State |
opened |
Created |
2025-09-03T14:06:24.244Z |
Updated |
2026-08-25T04:03:29.316Z |
Milestone |
6.3 |
Labels |
backport, bsp:beaglebone |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/697 |
Commit |
Summary¶
add modified gpio handling and adc section to BBB
could close #5198
This is based on the work of ketul93 (https://gist.github.com/ketul93/d717555951174a74c8b4)
All gpio I/O pins can be used (Mode7). Extension of the adc-section to be able to use optional channels.
I am unsure whether I meet the requirements for RTEMS code development ;-) However, I was able to put the BBB into production with these changes.
Author: Amar Takhar
2025-09-03T14:12:24.808Z
changed target branch from
mainto6
Author: Amar Takhar
2025-09-03T14:14:00.020Z
Couple of issues in the commit messages see: https://gitlab.rtems.org/rtems/rtos/rtems/-/jobs/14290
Author: Heinz Junkes
2025-09-03T15:29:35.575Z
Sorry, I wanted to delete the fork and do everything from scratch with 6.1 fork. Unfortunately I can’t manage it :-( I can’t delete my fork and the merge request. And I can’t create a new fork of 6.1 either. And customizing the commit message is not clear to me either. Unfortunately, I’ve probably gone off the rails here. Can you give me a tip on how to proceed? I would like to try again.
Author: Kinsey Moore
2025-09-03T15:29:35.538Z
First off, I would recommend against working directly on upstream branches going forward (once we’ve sorted all this out). When starting a new feature branch for 6, I tend to check out 6 branch, update it, and then create a new branch of the form br6-short-description. However, this advice does no good for you at the moment.
You need to edit your existing commit and push that updated commit with the -f flag to overwrite the content on your fork which will update this MR. Which step are you getting stuck on?
Author: Heinz Junkes
2025-09-03T15:32:17.990Z
I have now managed to change my commit message in the gilab gui and this time it went through. I am curious what will happen now ;-) Thank you
Author: Kinsey Moore
2025-09-03T15:33:44.061Z
Changing the title of the MR is not sufficient. You need to change the subject line of the commit which can still be seen as the original text under the “Commits” tab.
Author: Wayne Thornton
2025-09-03T15:40:26.921Z
@junkes The best way is to run a git commit –amend in your terminal and update the commit message to comply with what is being requested. Then run a git push -f (which forces the push to the repo). The MR will automatically update with the changed commit messages.
Author: Kinsey Moore
2025-09-03T15:50:14.918Z
@junkes I suggest you hop on discord so we can work out your workflow.
Author: Heinz Junkes
2025-09-03T15:26:46.113Z
changed title from
add modified gpio handling and adc section
to BBB
to
bbb bsp:
add modified gpio handling and adc section
Author: Heinz Junkes
2026-07-31T09:16:55.151Z
mentioned in issue #5235
Author: Chris Johns
2026-08-25T04:03:28.195Z
Please change the license to 2 Clause BSD. I emailed Ketul and permission has been given to make the change. We should also have a SPDX line at the start:
/* SPDX-License-Identifier: BSD-2-Clause */
Author: Chris Johns
2026-08-25T04:03:29.290Z
requested changes
424 - build: Provide LDFLAGS for pkg-config (opened)¶
Id |
424 |
State |
opened |
Assignee(s) |
Sebastian Huber |
Reviewer(s) |
Chris Johns |
Created |
2025-02-15T05:42:39.462Z |
Updated |
2026-03-18T01:55:21.279Z |
Milestone |
6.3 |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/424 |
Commit |
Summary¶
Some pkg-config variants perform transformations on the –libs options. This may lead to completely broken linker options:
https://github.com/pkgconf/pkgconf/issues/371
Provide the LDFLAGS as a variable. Do not add the ABI_FLAGS to LDFLAGS since they are already contained in the CFLAGS. The linker command line should include the compiler flags so that link-time optimization works properly.
Update #5165.
Author: Sebastian Huber
2025-02-15T05:42:39.627Z
assigned to @sebhub
Author: Sebastian Huber
2025-02-15T05:44:12.602Z
changed title from {-cpukit/jffs2/rtime: Fix off-by-one error in decompression check-} to {+build: Provide LDFLAGS for pkg-config+}
Author: Sebastian Huber
2025-02-15T05:44:12.631Z
changed the description
Author: Sebastian Huber
2025-02-15T05:44:12.670Z
changed target branch from
mainto6
Author: Sebastian Huber
2025-02-15T05:48:57.400Z
I created the MR with the wrong target branch. Now the pipeline is confused.
Author: Amar Takhar
2025-02-15T05:59:03.534Z
Yes, we actually enacted a new policy and adding to gitlab that branches targeted towards branches need to start with
5-*or6-*gitlab will then automatically set the branch.This just happened no doc updating the old way is still fine but this way this CI issue won’t happen. Let me try and see if restarting the pipeline manually fixes it.
Author: Amar Takhar
2025-02-15T06:00:16.820Z
Nope that didn’t fix it let me see how to properly handle this situation it may be how I have the CI setup
Author: Amar Takhar
2025-02-16T09:50:17.653Z
I think we’re stuck unless you do an update the source or we have to rebase on it. GitLab will snapshot the state when an MR comes in and use that. I have seen complaints about this exact issue but no solutions anywhere so we’ll wait until there is a chance to rebase.
Author: Kinsey Moore
2025-03-04T15:20:39.238Z
approved this merge request
Author: Amar Takhar
2025-07-02T18:25:44.075Z
added 8 commits
a5e5c058…dd490c5c - 7 commits from branch
rtems/rtos:63e90c378 - build: Provide LDFLAGS for pkg-config
Author: Amar Takhar
2025-07-02T18:25:58.823Z
reset approvals from @opticron by pushing to the branch
Author: Gedare Bloom
2025-08-05T14:04:56.716Z
requested review from @chris
Author: Chris Johns
2025-10-02T23:48:33.228Z
This was reverted on
main.
Author: Sebastian Huber
2025-10-03T01:12:29.082Z
This MR doesn’t contain the reverted change. There is an associated MR for main: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/425.
Author: Sebastian Huber
2026-03-18T01:41:10.821Z
added 40 commits
3e90c378…f6933b9c - 39 commits from branch
rtems/rtos:60f11145b - build: Provide LDFLAGS for pkg-config
725 - libio: Fix reference counting of file descriptors (opened)¶
Id |
725 |
State |
opened |
Assignee(s) |
Sebastian Huber |
Created |
2025-09-15T07:03:45.754Z |
Updated |
2025-12-19T00:58:50.224Z |
Milestone |
6.3 |
Labels |
filesystem |
Link |
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/725 |
Commit |
Summary¶
libio: Fix reference counting of file descriptors
Commit 0cf6de01df734c11212e63134551ee344a10ecec introduced a couple of issues:
ABI changes on a release branch
Redundant LIBIO_FLAGS_FREE flag: an iop is free if and only if it is
on the free list.
When the iop is freed, its reference count was set to zero. The iop
reference count must never be set to a specific value after initialization at system start. The only valid operations are increments and decrements.
In the iop free handling, there was a deadlock potential by obtaining
the libio lock while owning a file system lock.
The reference counting did not work at all under concurrent access.
This was indicated by the failing spintrcritical24 test program.
To fix this, remove the LIBIO_FLAGS_FREE and change the flag values back to the original values (restore ABI).
Actions must be performed based on state changes (flags, reference count) and not based on reading the current flags.
Remove dangerous functions rtems_libio_check_is_open(), rtems_libio_iop_flags_bad_fd(), rtems_libio_iop_is_held(), rtems_libio_iop_is_free(). The open property and references must be determined by inspecting the flags returned by rtems_libio_iop_hold() or similar.
In order to support closing a file descriptor with active references (LIBIO_FLAGS_CLOSE_BUSY), produce exactly one reference count while opening a file through the new function rtems_libio_iop_open(). An associated file node is freed when the reference count changes from one to zero.
This is an API change. Users of rtems_libio_allocate() must now call rtems_libio_iop_open() to make the iop available for use.
Author: Sebastian Huber
2025-09-15T07:03:45.916Z
requested review from @opticron
Author: Sebastian Huber
2025-09-15T07:03:45.934Z
assigned to @sebhub
Author: Sebastian Huber
2025-09-15T07:05:13.556Z
mentioned in issue #5311
Author: Kinsey Moore
2025-12-18T21:18:34.357Z
removed review request for @opticron