RTEMS scheduler bug ?

Sebastian Huber sebastian.huber at embedded-brains.de
Wed Apr 3 13:46:02 UTC 2019


On 03/04/2019 15:41, Catalin Demergian wrote:
> 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)

Can you set a break point to the gIntrptErrs++ and print the stack traces?

-- 
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.




More information about the users mailing list