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. I did also not see the issue with core-5, but that's because bdeaf76ba30a517 (ipipe/x86: use the vector_irq for system vectors too) leads to a stuck CPU bringup for >1 CPUs. Will maybe look into that a bit further. Best regards, Wolfgang _______________________________________________ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
