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.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to