Gilles Chanteperdrix wrote:
> Heikki Lindholm wrote:
> > Gilles Chanteperdrix kirjoitti:
> > > Now that the big context switches bugs have been solved, here is a patch
> > > that adds a unit test for context switches and FPU switches
> > > with various type of threads (kernel, user, user in secondary mode,
> > > not using FPU, using FPU, etc...). As is the case of the latency test
> > > there is a small RTDM driver in kernel-space, put in the benchmark
> > > class, even though this test is for unit testing, not for benchmarking.
> > Some months back when I was debugging an FPU bug on the ppc, I made
> > similar test cases. Do you test the Linux side at all (does linux
> > user/kernel task's fpu state get messed)?
> No, currently the only Linux regular task, the idle task, does not use
> FPU, but it may be changed easily.
> > Though, I'm not sure if any
> > driver uses FPU in linux kernel, but at least the PPC Altivec unit is
> > used by RAID drivers. Btw. at least back then, Xenomai would have messed
> > FPU state for a linux kernel task.
> x86 has the same issue: RAID driver use mmx, sse or sse2, and manually
> disable preemption, clear the ts bit, save the FPU registers
> contents before using mmx, sse or sse2, and restore the original state
> when done. If Xenomai ever preempts at that point, and the underlying
> task has not use its FPU, the contents of the FPU registers will be
> The only fix I see is to change the FPU switching code to only rely on
> the state of the FPU hardware FPU bits, and not on the status bits of
> the interrupted task.
Actually, only the mmx code is problematic because mmx registers are
aliased to the regular floating point registers. sse and sse2 use
distinct registers, so as long as real-time code does not use SSE
registers, there is no problem. Altivec seems to be in the same
case as SSE, or am I missing something ?
Xenomai-core mailing list