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 <lmy2010...@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 <demerg...@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@rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>>
>
>
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
