Re: [Xenomai-core] [Xenomai-git] Jan Kiszka : nucleus: Fix interrupt handler tails

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 06/18/2011 03:47 PM, Jan Kiszka wrote:
> On 2011-06-18 15:40, Gilles Chanteperdrix wrote:
>> On 06/18/2011 03:16 PM, Jan Kiszka wrote:
>>> On 2011-06-18 15:12, Gilles Chanteperdrix wrote:
>>>> On 06/18/2011 03:07 PM, Jan Kiszka wrote:
>>>>> On 2011-06-18 14:56, Gilles Chanteperdrix wrote:
>>>>>>
>>>>>> Maybe in the irq handlers, we should skip the XNHTICK replay, when
>>>>>> current_domain is root_domain.
>>>>>>
>>>>>
>>>>> That would be against the purpose of the XNTICK replay (it only targets
>>>>> that particular case). And it would still leave us with broken ipipe due
>>>>> to enabled IRQs on return from the Xenomai handlers.
>>>>
>>>> What I mean is that xnintr_clock_handler, we should skip the XNHTICK
>>>> replay when the current domain upon return from xnpod_schedule is not
>>>> root. From what I understand, this case only happens when xnpod_schedule
>>>> migrated the thread, and in that case, the tick will have been forwarded
>>>> during xnpod_schedule anyway.
>>>
>>> In the problematic case, ie. when the XNHTICK replay uses an invalid
>>> sched, the current domain is root. It must be root because only then the
>>> context could have been migrated to a different CPU by Linux. So this
>>> does not help to avoid having to reload sched.
>>
>> I mean replace:
>> 	if (testbits(sched->lflags, XNHTICK) &&
>> 	    xnthread_test_state(sched->curr, XNROOT))
>> 		xnintr_host_tick(sched);
>>
>> with
>> 	if (!xnarch_root_domain_p() &&
>> 	    testbits(sched->lflags, XNHTICK) &&
>> 	    xnthread_test_state(sched->curr, XNROOT))
>> 	    xnintr_host_tick(sched);
>>
> 
> That breaks Linux timer ticks: If we are only running the root thread,
> where should the pending tick be replayed? It is always deferred, even
> over the root domain. And __xnpod_schedule, which could replay it as
> well, is only entered if there is rescheduling required.

I may be wrong, but it is my understanding that Adeos switches domain 
before executing interrupt handlers, so that the current Adeos domain 
when running xnintr_clock_handler is always Xenomai, except at this 
point if we have migrated. For instance, see the following trace :

 |   +func                -9296 __ipipe_grab_localtimer+0x10 (__irq_usr+0x3c)
 |   +func                -9295 __ipipe_grab_irq+0x10 (__ipipe_grab_localtimer+0x20)
 |   +func                -9295 __ipipe_handle_irq+0x10 (__ipipe_grab_irq+0x88)
 |   +func                -9295 __ipipe_ack_localtimer+0x10 (__ipipe_handle_irq+0xc8)
 |   +func                -9294 __ipipe_dispatch_wired+0x10 (__ipipe_handle_irq+0xd4)
 |   +func                -9293 __ipipe_dispatch_wired_nocheck+0x14 (__ipipe_dispatch_wired+0x50)
 |  # func                -9293 xnintr_clock_handler+0x14 (__ipipe_dispatch_wired_nocheck+0x88)

where we clearly see that the current domain is xenomai when executing
xntintr_clock_handler.

Anyway, reading ipipe_current_domain is probably as expensive as
reading xnpod_current_sched().

-- 
                                                                Gilles.