>Yes, rtems 5 also has it. I can create a ticket. Here is the link to the ticket https://devel.rtems.org/ticket/4385#ticket. BTW the proposed solution for the master branch can be also applied to 5 as well.
>Regarding the proposed solution, I wanted to start a thread for discussing it >(maybe there is better was to do it). > > >>Is this a bug in rtems 5 also? >> >>If so, does it warrant a back-port fix and a ticket? >> >>On Mon, Apr 12, 2021 at 3:16 AM Moyano, Gabriel <gabriel.moy...@dlr.de> wrote: >>> >>> Hello everyone, >>> >>> I've found what can be an issue in the function genirq_set_active(): under >>> some conditions it can return a value greater than 1. >>> >>> This function is used by genirq_enable() and genirq_disable() and both of >>> them returns the value returned by genirq_set_active(). According to the >>> documentation in genirq.h, they should return -1, 0 or 1. >>> >>> When this issue can happen? If there are 3 entries in the list of IRQ and 2 >>> of them are already enabled, the variable `enabled` would be 2, because of >>> `enabled += isrentry->enabled`. >>> >>> As a possible solution, the value of `enabled` can changed to 1 if it's >>> greater than 1 (see the patch) or maybe improve the search. >>> >>> Thanks in advance, >>> >>> Gabriel Moyano >>> >>> >>> >>> Moyano, Gabriel (1): >>> grlib/genirq: Taking into account that it could be more than one ISR >>> enabled/disabled >>> >>> bsps/shared/grlib/irq/genirq.c | 5 +++++ >>> 1 file changed, 5 insertions(+) _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
