From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17537.48372.286093.220257@domain.hid> Date: Sat, 3 Jun 2006 18:46:44 +0200 Subject: Re: [Xenomai-core] [rfc] unit testing context switches. In-Reply-To: <44813683.9040202@domain.hid> References: <17536.40316.183366.284818@domain.hid> <44813683.9040202@domain.hid> From: Gilles Chanteperdrix List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Heikki Lindholm Cc: xenomai@xenomai.org 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 lost. 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. -- Gilles Chanteperdrix.