<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi,<div>I saw an event basically means setting a bit in a 32 bit integer, so, yes, they don't queue. </div><div>I got into the same issue with rtems_message_queue_receive(RTEMS_NO_TIMEOUT), it blocks even</div><div>if there are messages in the queue like I said. Not even rtems_message_queue_receive without timeout</div><div>didn't return. But I don't think rtems_message_queue_receive/rtems_event_receive have bugs, I think these</div><div>functions do their job, but if my task is not scheduled anymore, of course they don't make any progress.</div><div><br></div><div>I confirmed my task doesn't get CPU time by printing cpu_time_used from the TCB of the task.</div><div>This is a cummulative value that signifies the total amount of CPU time the task got since its creation.</div><div>After the issue is seen, I don't see this value incrementing at all, but other tasks get CPU slices.</div><div><br></div><div>So my question is: why would a task stop getting CPU time ?</div><div>Where is the code in the RTEMS scheduler that decides what is the next task to put on the CPU ?</div><div>I saw there are 58 files with scheduler functionality in the code base .. where should I start to look ?</div><div><br></div><div>regards,</div><div>Catalin</div><div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 20, 2018 at 5:05 PM Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Also the subject says message queue and event receive but the scenario described is just about events. Events do not queue. They are one deep. If the receiving task ever misses an event send (2 sends before.one receive), then the described <a href="http://scenario.is" target="_blank">scenario.is</a> expected.<div dir="auto"><br></div><div dir="auto">--joel</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 20, 2018, 7:44 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">Hello Catalin,<br>
<br>
could you please check if you have the same behaviour on the RTEMS master.<br>
<br>
On ARMv-7M and RTEMS exceptions and interrupts with a priority value of <br>
less than 0x80 are non-maskable with respect to the operating system and <br>
therefore must not use operating system services. If you use operating <br>
system services in non-maskable interrupts, then the system behaviour is <br>
quite undefined.<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" rel="noreferrer" 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>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org" rel="noreferrer" target="_blank">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a></blockquote></div>
</blockquote></div>