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.
Xenomai-core mailing list