<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi,<div>I put more debugging effort into this.</div><div><br></div><div>I think it's all about the Wait.flags value when the ISR is arriving.</div><div>For Wait.flags=BLOCKED or Wait.flags=INTEND_TO_BLOCK things are working</div><div>(yes, _Thread_Unblock is called from _Event_Seize properly), but when Wait.flags=READY</div><div>things don't work because the conditions in if block from _Event_Surrender are not met and</div><div>nobody calls _Thread_Unblock; even if more ISRs arrive, Wait.flags remains READY and the</div><div>thread is not put on the CPU anymore.</div><div><br></div><div>1. how can Wait.flags be READY before the ISR is arriving ?</div><div>2. on the else of the if block I tried to put unblock=true to unblock my task</div><div><div> if (</div><div> _Event_Is_blocking_on_event( the_thread, wait_class )</div><div> && _Event_Is_satisfied( the_thread, pending_events, &seized_events )</div><div> ) {</div></div><div>, I did see _Thread_Unblock called, but in _Thread_Clear_state _Scheduler_Unblock was not called</div><div>because the_thread->current_state = 0.</div><div>do I have to set something else besides unblock=true to unblock my task ?</div><div><br></div><div>regards,</div><div>Catalin</div><div><br></div><div><br></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 5, 2018 at 3:58 PM Catalin Demergian <<a href="mailto:demergian@gmail.com">demergian@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi,<div>First of all, I verified if I have this fix in my code base and I do have it.</div><div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">"Are the flags == 0x101? In this case the thread is in the middle of </span><span style="color:rgb(0,0,0);white-space:pre-wrap">_Event_Seize()"</span></div><div><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;white-space:normal">Yes. Even if in my test the ping packets arrive once at every second and there is plenty of time, sometimes it</span>
</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;white-space:normal">happens that rtems_event_send() is called from the USB ISR when we are in _Event_Seize (called from rtems_event_receive)</span></pre></div><div>It's rare, but it happens. (it could happen quicker if I run ping flood (-f option))</div><div><br></div><div><pre style="white-space:pre-wrap;color:rgb(0,0,0)">"The unblock is done in _Event_Seize() in this case"</pre><pre><span style="color:rgb(34,34,34);white-space:normal;font-family:Arial,Helvetica,sans-serif">Ok, now I understand why </span><font face="Arial, Helvetica, sans-serif"><span style="white-space:normal">THREAD_WAIT_STATE_INTEND_TO_BLOCK</span></font><span style="color:rgb(0,0,0);white-space:pre-wrap"> </span><span style="font-family:Arial,Helvetica,sans-serif;white-space:normal">exists ... so that if an ISR arrives before </span><font face="Arial, Helvetica, sans-serif"><span style="white-space:normal">_Thread_Wait_flags_try_change</span></font></pre><pre><font face="Arial, Helvetica, sans-serif"><span style="white-space:normal">and changes the wait flags from INTEND_TO_BLOCK to READY_AGAIN, the function will return false and _Thread_Unblock will get called, right ? </span></font></pre><pre><font face="Arial, Helvetica, sans-serif"><span style="white-space:normal">Problem is, I don't think it is called; otherwise I would see the thread making progress. Maybe there is a synchronization issue with the wait flags that</span></font></pre><pre><font face="Arial, Helvetica, sans-serif"><span style="white-space:normal">I don't understand.</span></font></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)"></pre></div><div><br></div><div><div>regards,</div><div>Catalin</div><div><br></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 5, 2018 at 10:06 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">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"><br>
<br>
On 04/10/2018 15:33, Catalin Demergian wrote:<br>
> I eliminated the theory of memory corruption. I debugged and found we <br>
> set Wait.flags = 0x104 with a function call.<br>
> The USB interrupt can arrive at any time, so Wait.flags can be either <br>
> INTEND_TO_BLOCK, BLOCKED or READY_AGAIN.<br>
><br>
> Following the logic in _Event_Surrender:<br>
> If it arrives when Wait.flags = INTEND_TO_BLOCK<br>
<br>
Are the flags == 0x101? In this case the thread is in the middle of <br>
_Event_Seize()<br>
<br>
> then _Thread_Wait_flags_try_change_critical will return TRUE, <br>
> Wait.flags will be set to READY_AGAIN,<br>
> unblock = FALSE so _Thread_Unblock will not be called.<br>
<br>
The unblock is done in _Event_Seize() in this case:<br>
<br>
success = _Thread_Wait_flags_try_change_acquire(<br>
executing,<br>
intend_to_block,<br>
wait_class | THREAD_WAIT_STATE_BLOCKED<br>
);<br>
<br>
The success == false in this case.<br>
<br>
> Then all the other USB interrupts will catch Wait.flags = READY_AGAIN <br>
> and in this case_Event_Surrender doesn't do anything because unblock = <br>
> FALSE<br>
><br>
> .. so the task never runs again, but state remains marked as READY.<br>
> is this a bug ? or I'm not understanding correctly?<br>
<br>
There could be a synchronization issue with the wait flag or the <br>
interrupt disable/enable sequence.<br>
<br>
There was a severe bug on the ARMv7-M in this area, but it is fixed in <br>
the 4.11.2 release:<br>
<br>
<a href="https://git.rtems.org/rtems/commit/?h=4.11&id=7e91901303219f10cf865906931c07c31d2e37f4" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/commit/?h=4.11&id=7e91901303219f10cf865906931c07c31d2e37f4</a><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>
</blockquote></div>