I did more tests. it seems not the same type of error happens every time. I
got the _Configuration_Scheduler_priority_dflt a few times, but also
the 'enabled interrupts when they suppposed to be disabled' happened as
well
RTEMS_INLINE_ROUTINE void _Scheduler_priority_Ready_queue_enqueue(
Chain_Node *node,
Scheduler_priority_Ready_queue *ready_queue,
Priority_bit_map_Control *bit_map
)
{
Chain_Control *ready_chain = ready_queue->ready_chain;
//_Assert(_ISR_Get_level() != 0);
if(_ISR_Get_level() == 0)
gIntrErrs++;
cnt_before = _Chain_Node_count_unprotected(ready_chain);
_Chain_Append_unprotected( ready_chain, node );
cnt_after = _Chain_Node_count_unprotected(ready_chain);
if(cnt_after != cnt_before + 1)
gIntrErrs++;
_Priority_bit_map_Add( bit_map, &ready_queue->Priority_map );
}
.. and I modified the cpuuse command to display gIntrErrs
# cpuuse
-------------------------------------------------------------------------------
CPU USAGE BY THREAD
------------+----------------------------------------+---------------+---------
ID | NAME | SECONDS |
PERCENT
------------+----------------------------------------+---------------+---------
*cdemergian build 10.40 am gIntrErrs=3*
0x09010001 | IDLE | 391.115963 |
99.323
0x0a010001 | UI1 | 1.059489 |
0.269
0x0a010002 | ntwk | 0.229622 |
0.058
0x0a010003 | SCtx | 0.167826 |
0.042
0x0a010004 | SCrx | 0.224951 |
0.057
0x0a010005 | eRPC | 0.000049 |
0.000
0x0a010006 | SHLL | 0.868036 |
0.220
0x0b010001 | | 0.000096 |
0.000
0x0b010002 | | 0.114388 |
0.029
------------+----------------------------------------+---------------+---------
TIME SINCE LAST CPU USAGE RESET IN SECONDS:
393.836064
-------------------------------------------------------------------------------
[/] #
It seems it's 3. (I've seen values as 2 or 4 at other test runs)
Catalin
On Tue, Apr 2, 2019 at 4:37 AM Catalin Demergian <demerg...@gmail.com>
wrote:
> it's just the way Eclipse shows it, it's part of the call stack, but not
> the name of a normal function.
>
>
> On Tue, Apr 2, 2019 at 2:02 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>>
>>
>> On 02/04/2019 12:59, Catalin Demergian wrote:
>> > Hi,
>> > I was able to reproduce the issue again, but it doesn't look like the
>> > interrupts are enabled
>> > in the functions where you added Asserts in the patch. So, my changes
>> > don't fix the problem.
>> > My analysis would have been correct if the interrupts were enabled,
>> > but it looks it's not the case.
>> >
>> > Still, a problem exists somewhere .. _Chain_Append_unprotected fails
>> > and the task starves as a result.
>> > If it's not interrupts, I have to think again what could produce the
>> > failure. (any idea/hint here is welcome :) )
>> >
>> > Also, during my tests I even saw a crash (probably not related to this
>> > issue). Call stack looks like this
>> > Thread #1 (Suspended:Signal:SIGINT:Interrupt)
>> > _ARMV7M_Exception_default() at armv7m-exception-default.c:25 0x805aff0
>> > <signal_handler_called>() at 0xfffffffd
>> > _Configuration_Scheduler_priority_dflt() at 0x2400063c
>>
>> What is signal_handler_called()?
>>
>> --
>> 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.hu...@embedded-brains.de
>> PGP : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
>>
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
