rtems_message_queue_receive / rtems_event_receive issues

[Catalin Demergian]

Hi,
This is the result of task command in shell after SCrx task gets stuck

[/] # task

  ID       NAME           PRI  STATE MODES   EVENTS    WAITID  WAITARG
NOTES

------------------------------------------------------------------------------

0a010001   UI1              1 Wevnt  P:T:nA    NONE   2002a77c 0x80673a3

0a010002   LOGT            99 Wmsg   P:T:nA    NONE   22010001 0x80673a3

0a010003   ntwk           100 Wsysev P:T:nA    NONE   2005d8a4 0x80673a3

0a010004   SCtx           100 Wsysev P:T:nA    NONE   2005ed0c 0x80673a3

*0a010005   SCrx           100 READY  P:T:nA  08000000 2005fd1c 0x80673a3*

0a010006   SHLL           100 READY  P:T:nA    NONE   fef90700 0x80673a3

[/] #

SCrx is ready and my USB event is set (08000000); still, SCrx doesn't get
CPU time.
Here is the result of cpuuse at two different times

[/] # cpuuse

-------------------------------------------------------------------------------

                              CPU USAGE BY THREAD

------------+----------------------------------------+---------------+---------

ID         | NAME                                   | SECONDS       |
PERCENT

------------+----------------------------------------+---------------+---------

0x09010001 | IDLE                                   |   9218.757029 |
99.562

0x0a010001 | UI1                                    |      1.067066 |
0.011

0x0a010002 | LOGT                                   |      0.000015 |
0.000

0x0a010003 | ntwk                                   |      0.639828 |
0.006

0x0a010004 | SCtx                                   |      0.199488 |
0.002

*0x0a010005 | SCrx                                   |      0.138781 |
0.001*

*0x0a010006 | SHLL                                   |     38.550932 |
0.416*

------------+----------------------------------------+---------------+---------

TIME SINCE LAST CPU USAGE RESET IN SECONDS:
            9259.353153

-------------------------------------------------------------------------------

[/] #

[/] #

[/] #

[/] # cpuuse

-------------------------------------------------------------------------------

                              CPU USAGE BY THREAD

------------+----------------------------------------+---------------+---------

ID         | NAME                                   | SECONDS       |
PERCENT

------------+----------------------------------------+---------------+---------

0x09010001 | IDLE                                   |   9223.354634 |
99.560

0x0a010001 | UI1                                    |      1.067066 |
0.011

0x0a010002 | LOGT                                   |      0.000015 |
0.000

0x0a010003 | ntwk                                   |      0.640091 |
0.006

0x0a010004 | SCtx                                   |      0.199519 |
0.002

*0x0a010005 | SCrx                                   |      0.138781 |
0.001*

*0x0a010006 | SHLL                                   |     38.674044 |
0.417*

------------+----------------------------------------+---------------+---------

TIME SINCE LAST CPU USAGE RESET IN SECONDS:
9264.074153

As seen, the shell task is getting CPU (38.674044  > 38.550932), but SCrx
is unchanged (0.138781). This is what we know.

In my debugging sessions I"m verifying different conditions that may change
the scheduling policy.
(
https://docs.rtems.org/releases/rtems-docs-4.11.2/c-user/scheduling_concepts.html,
section 5.3)
*I think it's not caused by priority because I changed it from 100 to 98
for SCrx and then to 105 and I could reproduce the issue.*

Also I checked if another task has preemption disabled and that's why my
task doesn't run, but it's not happening here.
Also I checked CPU budget allocation, but that's not the cause either.

Maybe I should check the RTEMS dispatcher code, since it's the component
responsible for allocating the CPU for a ready task ?

regards,
Catalin


On Wed, Sep 19, 2018 at 5:58 AM Mingyu Li <lmy2010lmy at gmail.com> wrote:

> Hi Catalin.
>
> I find the problem you encountered interesting. I hope to offer some hints
> that might be helpful to you:
>
> 1. use a user task to first rtems_event_send then rtems_event_receive, in
> order to make sure the internal IPC of RTEMS kernel you are using (4.11.2)
> works as expected.
> 2. ensure to disable/lock interrupts while operating the message_queue inside
> USB ISR. Try to check if clock ISR is still responded when USB ISR exits,
> so that the kernel task can be scheduled to obtain the message.
>
> Best regards,
> Mingyu
>
> 2018-09-18 20:20 GMT+08:00 Catalin Demergian <demergian at gmail.com>:
>
>> Hello,
>> I am using RTEMS 4.11.2 and I tried first to use RTEMS message queues in
>> my USB FS driver.
>> I'm populating the queue from the ISR and then use
>> rtems_message_queue_receive from a kernel task to
>> read the messages. After some debugging sessions I came to the conlusion
>> that rtems_message_queue_receive function
>> hangs even if there are messages in the queue. (manpage says it should
>> return immediately if there is at least one message
>> in the queue; in my case the queue gets full, but still the function
>> hangs)
>>
>> I tried then rtems_event_receive. I used my own queues and from ISR I
>> only called rtems_event_send; the same issue
>> happened again, this time rtems_event_receive hangs even if I see the
>> event was raised (with task command in the shell)
>>
>> My question is: are there any known issues/bugs with these functions ?
>>
>> thanks,
>> Catalin
>>
>> _______________________________________________
>> 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/20180925/b0eba3e8/attachment-0001.html>