rtems_message_queue_receive / rtems_event_receive issues

[Catalin Demergian]

Hi,
I saw an event basically means setting a bit in a 32 bit integer, so, yes,
they don't queue.
I got into the same issue with
rtems_message_queue_receive(RTEMS_NO_TIMEOUT), it blocks even
if there are messages in the queue like I said. Not even
rtems_message_queue_receive without timeout
didn't return. But I don't think
rtems_message_queue_receive/rtems_event_receive have bugs, I think these
functions do their job, but if my task is not scheduled anymore, of course
they don't make any progress.

I confirmed my task doesn't get CPU time by printing cpu_time_used from the
TCB of the task.
This is a cummulative value that signifies the total amount of CPU time the
task got since its creation.
After the issue is seen, I don't see this value incrementing at all, but
other tasks get CPU slices.

So my question is: why would a task stop getting CPU time ?
Where is the code in the RTEMS scheduler that decides what is the next task
to put on the CPU ?
I saw there are 58 files with scheduler functionality in the code base ..
where should I start to look ?

regards,
Catalin


On Thu, Sep 20, 2018 at 5:05 PM Joel Sherrill <joel at rtems.org> wrote:

> 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 scenario.is expected.
>
> --joel
>
> On Thu, Sep 20, 2018, 7:44 AM Sebastian Huber <
> sebastian.huber at embedded-brains.de> wrote:
>
>> Hello Catalin,
>>
>> could you please check if you have the same behaviour on the RTEMS master.
>>
>> On ARMv-7M and RTEMS exceptions and interrupts with a priority value of
>> less than 0x80 are non-maskable with respect to the operating system and
>> therefore must not use operating system services. If you use operating
>> system services in non-maskable interrupts, then the system behaviour is
>> quite undefined.
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone   : +49 89 189 47 41-16
>> Fax     : +49 89 189 47 41-09
>> E-Mail  : sebastian.huber at embedded-brains.de
>> PGP     : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
>> _______________________________________________
>> users mailing list
>> users at rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20180921/415c1ddd/attachment-0001.html>