On 08/03/2012 01:10 AM, Gilles Chanteperdrix wrote:
Hi Philippe, please find at the usual place: git://git.xenomai.org/ipipe-gch.git, branch for-core-3.4 The current state of the I-pipe core patch for Linux 3.4 running on x86 and ARM. Compared to the last mail: * several issues were fixed on ARM (with a severe one in switch_mm) * some optimizations were made on x86 reducing drastically the latencies on atom N230: - the irq_hold handler for ioapic masks the irq line before sending the eoi, avoiding the irq to be retriggered when the irq is of the level type
Gasp. This is a regression which sneaked in with the introduction of the irq_hold handler in the 3.2 series.
- the fpu is never restored during linux context switches, as it increases the context switch irq masking time. I tried to further decrease the context switch critical section by splitting the context switch in three parts, and even by trying to run the context switch with irqs on, to no avail. * the I-pipe core API was changed, so the API revision was incremented from 1 to 2: - ipipe_timers_request now takes a cpumask argument specifying on which cpus the timers should be requested - the delay passed to ipipe_timer_set is now converted from clock frequency to timer frequency, without a division, by the I-pipe. Issues observed: - when running with the I-pipe tracer on on x86, and CONFIG_IPIPE_TRACE_IRQSOFF is enabled, we get a kernel oops. That is because the definition of the "interrupt" macros makes use of the "rbp" register to restore some other registers values after the call to the interrupt function, but rbp is set to 0 on irq entry starting with linux 3.4
Jan, would you have a fix for that one already in your local patch queue?
- pic muting has an issue with unlocked context switches: when a context swich from xenomai domain to root domain happens, low priorities irqs are unmasked before the unmasked context switch, so may trigger, with a timer interrupt at the same time triggering in fact a re-switch to the xenomai domain. The cure seems to be, in __xnpod_schedule, to only call xnarch_reenter_root after the test at the end of the unlocked switch, I tried that, but got lockups on AT91. So, I must be missing something.
Can't be a missing unmute in the shadow epilogue? -- Philippe. _______________________________________________ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
