Need help to explain the test result

[Joel Sherrill]

On 01/10/2010 10:25 AM, Leon Pollak wrote:
> On Sunday January 10 2010, Joel Sherrill wrote:
>    
>> On 01/10/2010 09:17 AM, Leon Pollak wrote:
>>      
>>> Hello, all.
>>>
>>> I am trying to do the task switch logger.
>>> For this I installed the user extension and the function "TASK SWITCH
>>> Extension", which logs (into cyclic buffer) the
>>> current_task->Object.name.
>>>
>>> Everything seems to work, but I have 2 questions:
>>>
>>> 1. Sometimes I see the name 0x10e150 to appear. Under debugger, I see
>>> this name when an external interrupt occurs and task switch is called
>>> from the ISR handler. Strange, as I thought that IRQ has no "task"
>>> context. OK, but what is this name? I did:
>>> (gdb) p/x current_task->Object
>>> p/x current_task->Object
>>> $59 = {Node = {next = 0x54f410, previous = 0x54f40c}, id = 0x9010001,
>>> name = 0x10e150}
>>>        
>> Some object types have string names.  This is the id of the idle
>> thread.  I am betting *(char *) 0x10e150 is "IDLE".
>>      
> Yes, you were right. But why in this way?
> Object name always was an integer, not a pointer!?
>
>
>    
Object name was always an integer for the Classic API.
In the SuperCore they can be strings since the POSIX objects
that have names have string names.  We just decided to use that
for the "Internal Thread Class" as well.

And while we are here.. you can assign a name to a POSIX thread
now using rtems_object_set_name() or similar.  Then when you
print reports, they have names.  This is beyond the POSIX standard
but handy.
>>> 2. For now, I designated the above as "*IRQ" name and continued. Then, I
>>> received something that I can not understand:
>>> *IRQ    MRT2    V2HD    FCr1    FCr1    V2HD    FCr1    FCr1    V2HD
>>> FCr1 V2HD    FCr1
>>>
>>> How can it be that FCr1 is repeated? There was a context switch to
>>> itself!?
>>>        
>> Signal? Or a reevaluation?  Hard to say.
>>      
> Please, Joel, what do you mean?
> What is "signal"?
>    
rtems_signal_xxx or POSIX signal.
> Why reevaluation (whatever is it) may switch context to itself? If so, isn't
> it a wasting of the CPU?
>    
Yes but it may not have gotten completely through before the next
interrupt made it relook at things.  It may also be a bug but may also
be a weird side-effect.

Look at the main loop around switching in score/src/threaddispatch.c.
If it is making two passes through the loop, then an ISR must be setting
_Context_Switch_necessary after it is cleared and we commit to a switch.
We would have to know what the ISR is doing.