yes, I realized yesterday evening that gIntrErrs could be incremented in
the second if.
so I rewrote it like this
int gIntrptErrs;
int gInsertErrs;
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)
gIntrptErrs++;
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)
gInsertErrs++;
_Priority_bit_map_Add( bit_map, &ready_queue->Priority_map );
}
It didn't seem that we enter that code with interrupts enabled .. output was
# cpuuse
-------------------------------------------------------------------------------
CPU USAGE BY THREAD
------------+----------------------------------------+---------------+---------
ID | NAME | SECONDS |
PERCENT
------------+----------------------------------------+---------------+---------
*cdemergian build 11.15 gIntrptErrs=0 gInsertErrs=2*
0x09010001 | IDLE | 244.595117 |
99.238
0x0a010001 | UI1 | 1.000929 |
0.406
0x0a010002 | ntwk | 0.099342 |
0.040
0x0a010003 | SCtx | 0.068705 |
0.027
0x0a010004 | SCrx | 0.089272 |
0.036
0x0a010005 | eRPC | 0.000050 |
0.000
0x0a010006 | SHLL | 0.550608 |
0.223
0x0b010001 | | 0.000096 |
0.000
0x0b010002 | | 0.068307 |
0.027
------------+----------------------------------------+---------------+---------
TIME SINCE LAST CPU USAGE RESET IN SECONDS:
246.528065
-------------------------------------------------------------------------------
[/] #
Not all time time, most of the runs both globals were zero, which is wierd
..
I also tried the patch. The issue was reproduced as well.
[/] # cpuuse
-------------------------------------------------------------------------------
CPU USAGE BY THREAD
------------+----------------------------------------+---------------+---------
ID | NAME | SECONDS |
PERCENT
------------+----------------------------------------+---------------+---------
*cdemergian build 16.25 gIntrptErrs=233694 gInsertErrs=1*
0x09010001 | IDLE | 94.488726 |
98.619
0x0a010001 | UI1 | 1.000931 |
1.044
0x0a010002 | ntwk | 0.030101 |
0.031
0x0a010003 | SCtx | 0.021441 |
0.022
0x0a010004 | SCrx | 0.027176 |
0.028
0x0a010005 | eRPC | 0.000049 |
0.000
0x0a010006 | SHLL | 0.215693 |
0.225
0x0b010001 | | 0.000096 |
0.000
0x0b010002 | | 0.027211 |
0.028
------------+----------------------------------------+---------------+---------
TIME SINCE LAST CPU USAGE RESET IN SECONDS:
95.867059
-------------------------------------------------------------------------------
we are getting big numbers for gIntrptErrs (is that normal ? I don't
understand all the aspects of the patch just yet)
Catalin
On Tue, Apr 2, 2019 at 10:26 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> 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.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
