RTEMS scheduler bug ?

[Sebastian Huber]

On 02/04/2019 16:28, Catalin Demergian wrote:
> I did more tests. it seems not the same type of error happens every 
> time. I got the _Configuration_Scheduler_priority_dflt  a few times, 
> but also
> the 'enabled interrupts when they suppposed to be disabled' happened 
> as well
>
> RTEMS_INLINE_ROUTINE void _Scheduler_priority_Ready_queue_enqueue(
>   Chain_Node                     *node,
>   Scheduler_priority_Ready_queue *ready_queue,
>   Priority_bit_map_Control       *bit_map
> )
> {
>   Chain_Control *ready_chain = ready_queue->ready_chain;
>   //_Assert(_ISR_Get_level() != 0);
>   if(_ISR_Get_level() == 0)
>     gIntrErrs++;
>
>   cnt_before = _Chain_Node_count_unprotected(ready_chain);
>   _Chain_Append_unprotected( ready_chain, node );
>   cnt_after = _Chain_Node_count_unprotected(ready_chain);
>
>   if(cnt_after != cnt_before + 1)
> gIntrErrs++;
>
>   _Priority_bit_map_Add( bit_map, &ready_queue->Priority_map );
> }
>
> .. and I modified the cpuuse command to display gIntrErrs

What do you get if you use separate counters for these errors?

I still believe that you use some interrupts with a too high priority. 
What happens if you apply the attached patch?

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Disable-the-highest-priority-interrupts.patch
Type: text/x-patch
Size: 893 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20190403/9570a73b/attachment-0002.bin>