<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">yes, I realized yesterday evening that gIntrErrs could be incremented in the second if. <div>so I rewrote it like this</div><div><br></div><div><div>int gIntrptErrs;</div><div>int gInsertErrs;</div></div><div><br></div><div><div>RTEMS_INLINE_ROUTINE void _Scheduler_priority_Ready_queue_enqueue(</div><div>  Chain_Node                     *node,</div><div>  Scheduler_priority_Ready_queue *ready_queue,</div><div>  Priority_bit_map_Control       *bit_map</div><div>)</div><div>{</div><div>  Chain_Control *ready_chain = ready_queue->ready_chain;</div><div>  //_Assert(_ISR_Get_level() != 0);</div><div>  if(_ISR_Get_level() == 0)</div><div><span style="white-space:pre">   </span>gIntrptErrs++;</div><div><br></div><div>  cnt_before = _Chain_Node_count_unprotected(ready_chain);</div><div>  _Chain_Append/*_unprotected*/( ready_chain, node );</div><div>  cnt_after = _Chain_Node_count_unprotected(ready_chain);</div><div><br></div><div>  if(cnt_after != cnt_before + 1)</div><div><span style="white-space:pre">     </span>gInsertErrs++;</div><div><br></div><div>  _Priority_bit_map_Add( bit_map, &ready_queue->Priority_map );</div><div>}</div><div><br></div><div>It didn't seem that we enter that code with interrupts enabled .. output was</div><div><div># cpuuse</div><div>-------------------------------------------------------------------------------</div><div>                              CPU USAGE BY THREAD</div><div>------------+----------------------------------------+---------------+---------</div><div> ID         | NAME                                   | SECONDS       | PERCENT</div><div>------------+----------------------------------------+---------------+---------</div><div><b>cdemergian build 11.15 gIntrptErrs=0 gInsertErrs=2</b></div><div> 0x09010001 | IDLE                                   |    244.595117 |  99.238</div><div> 0x0a010001 | UI1                                    |      1.000929 |   0.406</div><div> 0x0a010002 | ntwk                                   |      0.099342 |   0.040</div><div> 0x0a010003 | SCtx                                   |      0.068705 |   0.027</div><div> 0x0a010004 | SCrx                                   |      0.089272 |   0.036</div><div> 0x0a010005 | eRPC                                   |      0.000050 |   0.000</div><div> 0x0a010006 | SHLL                                   |      0.550608 |   0.223</div><div> 0x0b010001 |                                        |      0.000096 |   0.000</div><div> 0x0b010002 |                                        |      0.068307 |   0.027</div><div>------------+----------------------------------------+---------------+---------</div><div> TIME SINCE LAST CPU USAGE RESET IN SECONDS:                        246.528065</div><div>-------------------------------------------------------------------------------</div><div>[/] #</div><div>Not all time time, most of the runs both globals were zero, which is wierd ..</div><div><br></div><div>I also tried the patch. The issue was reproduced as well.</div><div><div>[/] # cpuuse</div><div>-------------------------------------------------------------------------------</div><div>                              CPU USAGE BY THREAD</div><div>------------+----------------------------------------+---------------+---------</div><div> ID         | NAME                                   | SECONDS       | PERCENT</div><div>------------+----------------------------------------+---------------+---------</div><div><b>cdemergian build 16.25 gIntrptErrs=233694 gInsertErrs=1</b></div><div> 0x09010001 | IDLE                                   |     94.488726 |  98.619</div><div> 0x0a010001 | UI1                                    |      1.000931 |   1.044</div><div> 0x0a010002 | ntwk                                   |      0.030101 |   0.031</div><div> 0x0a010003 | SCtx                                   |      0.021441 |   0.022</div><div> 0x0a010004 | SCrx                                   |      0.027176 |   0.028</div><div> 0x0a010005 | eRPC                                   |      0.000049 |   0.000</div><div> 0x0a010006 | SHLL                                   |      0.215693 |   0.225</div><div> 0x0b010001 |                                        |      0.000096 |   0.000</div><div> 0x0b010002 |                                        |      0.027211 |   0.028</div><div>------------+----------------------------------------+---------------+---------</div><div> TIME SINCE LAST CPU USAGE RESET IN SECONDS:                         95.867059</div><div>-------------------------------------------------------------------------------</div></div><div><br></div><div>we are getting big numbers for gIntrptErrs (is that normal ? I don't understand all the aspects of the patch just yet)<br></div><div>Catalin<br></div><div><br></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 2, 2019 at 10:26 PM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 02/04/2019 16:28, Catalin Demergian wrote:<br>
> I did more tests. it seems not the same type of error happens every <br>
> time. I got the _Configuration_Scheduler_priority_dflt  a few times, <br>
> but also<br>
> the 'enabled interrupts when they suppposed to be disabled' happened <br>
> as well<br>
><br>
> RTEMS_INLINE_ROUTINE void _Scheduler_priority_Ready_queue_enqueue(<br>
>   Chain_Node                     *node,<br>
>   Scheduler_priority_Ready_queue *ready_queue,<br>
>   Priority_bit_map_Control       *bit_map<br>
> )<br>
> {<br>
>   Chain_Control *ready_chain = ready_queue->ready_chain;<br>
>   //_Assert(_ISR_Get_level() != 0);<br>
>   if(_ISR_Get_level() == 0)<br>
>     gIntrErrs++;<br>
><br>
>   cnt_before = _Chain_Node_count_unprotected(ready_chain);<br>
>   _Chain_Append_unprotected( ready_chain, node );<br>
>   cnt_after = _Chain_Node_count_unprotected(ready_chain);<br>
><br>
>   if(cnt_after != cnt_before + 1)<br>
> gIntrErrs++;<br>
><br>
>   _Priority_bit_map_Add( bit_map, &ready_queue->Priority_map );<br>
> }<br>
><br>
> .. and I modified the cpuuse command to display gIntrErrs<br>
<br>
What do you get if you use separate counters for these errors?<br>
<br>
I still believe that you use some interrupts with a too high priority. <br>
What happens if you apply the attached patch?<br>
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone   : +49 89 189 47 41-16<br>
Fax     : +49 89 189 47 41-09<br>
E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP     : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br>
</blockquote></div>