<div dir="ltr">This is really strange. If you use cpsid/cpsie around the append_cnt ++ <br>and --, then append_cnt should never be > 1. If this really the case, <br>then this looks like a processor bug. <div>-> No, after I saw that it didn't fix the problem I commented the dis/en, so </div><div>the value 2 was obtained without the dis/en in the code.</div><div><span style="color:rgb(80,0,80)"><br></span></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 25, 2018 at 12:17 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 25/10/2018 11:00, Catalin Demergian wrote:<br>
> Hi,<br>
> First, I would like to conceptually understand how a function as <br>
> simple as _Chain_Append_unprotected could fail.<br>
<br>
The chain operations fail if you try to append a node that is already on <br>
a chain or extract a node which is not on a chain.<br>
<br>
> I added a patch like this<br>
> RTEMS_INLINE_ROUTINE void _Chain_Append_unprotected(<br>
> Chain_Control *the_chain,<br>
> Chain_Node *the_node<br>
> )<br>
> {<br>
> append_cnt++;<br>
> if(append_cnt > append_cnt_max)<br>
> append_cnt_max = append_cnt;<br>
> Chain_Node *tail = _Chain_Tail( the_chain );<br>
> Chain_Node *old_last = tail->previous;<br>
><br>
> the_node->next = tail;<br>
> tail->previous = the_node;<br>
> old_last->next = the_node;<br>
> the_node->previous = old_last;<br>
> append_cnt--;<br>
> }<br>
><br>
> I could see append_cnt_max=2 in the output bellow, meaning at some <br>
> point there were two function calls<br>
> in progress (don't know if it was for the same chain, as the patch <br>
> dind't look if it's the_chain parameter is the same)<br>
> How would be possible as a scenario to have two calls in the same time ?<br>
<br>
Some chain operations are by a mutex and not interrupt disable/enable.<br>
<br>
><br>
> I have to say that I even tried to temporary dis/en interrupts with <br>
> __asm__ volatile ("cpsid i" : : : "memory") /__asm__ volatile ("cpsie <br>
> i" : : : "memory")<br>
> , but I could still reproduce. plus I also reproduced it <br>
> with append_errs=0 .. I hope this doesn't break my theory :D<br>
<br>
This is really strange. If you use cpsid/cpsie around the append_cnt ++ <br>
and --, then append_cnt should never be > 1. If this really the case, <br>
then this looks like a processor bug.<br>
<br>
><br>
> [/] # i<br>
> Instruction count for the last second is 215992979.<br>
> CPU load is 99.99%.<br>
> intr_cnt=3220<br>
> cond1=1<br>
> cond2=1<br>
> jiffies=1622210<br>
> dbg_ready_UI1=287402<br>
> dbg_ready_LOGT=374072<br>
> dbg_ready_ntwk=1622094084077<br>
> dbg_ready_SCtx=1621678898952<br>
> dbg_ready_SCrx=1621678862701<br>
> dbg_ready_SHLL=1622201084177<br>
> dbg_extract_UI1=67127037<br>
> dbg_extract_LOGT=67144458<br>
> dbg_extract_ntwk=1622094096292<br>
> dbg_extract_SCtx=1621678924213<br>
> dbg_extract_SCrx=1621678883552<br>
> dbg_extract_SHLL=1622200088846<br>
> append_errs=0<br>
> ready_queue_100_elems=1<br>
> append_cnt_max=2<br>
> [/] #<br>
> [/] #<br>
> [/] #<br>
> [/] #<br>
> [/] # assertion "first != _Chain_Tail( &ready_queues[ index ] )" <br>
> failed: file <br>
> "../../cpukit/../../../stm32f7/lib/include/rtems/score/schedulerpriorityimpl.h", <br>
> line 232, function: _Scheduler_priority_Ready_queue_first<br>
><br>
> *** PROFILING REPORT BEGIN PMC_APP ***<br>
> <ProfilingReport name="PMC_APP"><br>
> <PerCPUProfilingReport processorIndex="0"><br>
> <MaxThreadDispatchDisabledTime <br>
> unit="ns">2</MaxThreadDispatchDisabledTime><br>
> <MeanThreadDispatchDisabledTime <br>
> unit="ns">1</MeanThreadDispatchDisabledTime><br>
> <TotalThreadDispatchDisabledTime <br>
> unit="ns">3369295</TotalThreadDispatchDisabledTime><br>
> <ThreadDispatchDisabledCount>3369216</ThreadDispatchDisabledCount><br>
> <MaxInterruptDelay unit="ns">0</MaxInterruptDelay><br>
> <MaxInterruptTime unit="ns">0</MaxInterruptTime><br>
> <MeanInterruptTime unit="ns">0</MeanInterruptTime><br>
> <TotalInterruptTime unit="ns">0</TotalInterruptTime><br>
> <InterruptCount>0</InterruptCount><br>
> </PerCPUProfilingReport><br>
> </ProfilingReport><br>
> *** PROFILING REPORT END PMC_APP ***<br>
> Creating /etc/passwd and group with three usable accounts<br>
> root/pwd , test/pwd, rtems/NO PASSWORD, chroot/NO PASSWORD<br>
><br>
> I may have to begin the integration again for 4.11.3 ... are there any <br>
> chances this might not reproduce in 4.11.3 ?<br>
> are there any changes in this area ?<br>
<br>
I don't think an update to 4.11.3 will solve your problem.<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>