On 09/19/2012 02:15 PM, Wolfgang Mauerer wrote:
> On 18/09/12 21:36, Gilles Chanteperdrix wrote:
>> On 09/18/2012 05:27 PM, Wolfgang Mauerer wrote:
>>
>>> On 18/09/12 16:25, Gilles Chanteperdrix wrote:
>>>> On 09/18/2012 04:11 PM, Wolfgang Mauerer wrote:
>>>>> Dear all,
>>>>>
>>>>> here's a rebase of the x86-specific bits of core-4 to core-5. I've
>>>>> included all x86 specific changes that are not yet in core-5, and
>>>>> also added the patches I sent earlier for core-4. I did not include a
>>>>> separate patch for the mechanical changes required to apply the
>>>>> x86 base patch on top of core-5, but can surely do so if desired.
>>>>
>>>> I am not quite finished with x86 on 3.4. So, I would like to start 3.5
>>>> from the finishing point on 3.4. There are already commits in my branch
>>>> which you did not take:
>>>>
>>>> http://git.xenomai.org/?p=ipipe-gch.git;a=shortlog;h=refs/heads/for-core-3.4
>>> that's true; my last pull was too old. I'll add the corresponding
>>> commits to the tree (FYI, the purpose of this tree is mainly to do some
>>> experiments with the latest ipipe release and the latest kernel, and
>>> I wanted to make sure that work is not duplicated in case someone else
>>> is pursuing similar goals)
>>
>>
>> Ok. We have a currently pending issue on x86 which you should be
>> informed about before discovering it during your tests: using
>> rthal_supported_cpus is broken in I-pipe core patches when using the
>> LAPIC timer: since there is only one irq handler for all the LAPIC
>> timers, the handler is registered on all cpus, but on non started cpus,
>> the handler will do nothing at best, and not foward the LAPIC ticks to
>> Linux (which is still in control of the LAPIC timer on these cpus).
>>
>> This problem is due to the fact that we keep the same vector as Linux,
>> and so the same irq. There are two ways out of this:
>>
>> - change the LAPIC vector when xenomai takes the control of the LAPIC
>> timer, like we use to do, this is racy with current code because the
>> timer is taken by Xenomai but still used a bit by Linux, before it is
>> programmed by Xenomai, and Xenomai assumes that the host tick irq is the
>> same as the timer irq. All this can be fixed, but the last drawback of
>> this approach is that it does not fix the issue on architectures where
>> the local timer irq is the same on all cpus, but can not be changed,
>> hence the second approach;
>> - the second approach is to add a test at the beginning of
>> xnintr_clock_handler and forward the irq to the root domain if the
>> current cpu does not belong to xnarch_supported_cpus. This means some
>> patching of I-pipe timers so that ipipe_percpu.hrtimer_irq also gets
>> defined for non supported cpus when they use the timer shared with other
>> cpus, essentially what this patch tries (but fails) to achieve:
>>
>> http://www.xenomai.org/pipermail/xenomai/2012-September/026066.html
>
> thanks for the info! Unfortunately, I was not able to reproduce this
> issue quickly using two latency instances bound to different CPUs on a
> machine booted with isolcpus=1, though.
The issue is not with isolcpus, but with rthal_supported_cpus, that is
xenomai "supported_cpus" parameter. And maybe Linux is running fine with
the bug, but if you do a cat /proc/interrupts, you should see the local
timer interrupt no longer incrementing on cpus not intercepted by xenomai.
--
Gilles.
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
