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