All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Heikki Lindholm <holindho@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-core] [rfc] unit testing context switches.
Date: Sat, 3 Jun 2006 18:46:44 +0200	[thread overview]
Message-ID: <17537.48372.286093.220257@domain.hid> (raw)
In-Reply-To: <44813683.9040202@domain.hid>

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.


  reply	other threads:[~2006-06-03 16:46 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-02 20:20 [Xenomai-core] [rfc] unit testing context switches Gilles Chanteperdrix
2006-06-02 23:50 ` Jim Cromie
2006-06-03  7:13 ` Heikki Lindholm
2006-06-03 16:46   ` Gilles Chanteperdrix [this message]
2006-06-03 17:26     ` Gilles Chanteperdrix
2006-06-03 20:16       ` Heikki Lindholm
2006-06-04 12:58         ` Gilles Chanteperdrix
2006-06-04 13:47           ` Heikki Lindholm
2006-06-04 17:48             ` Gilles Chanteperdrix
2006-06-04 18:19               ` Heikki Lindholm
2006-06-03  8:04 ` Jan Kiszka
2006-06-07 18:00 ` Gilles Chanteperdrix
2006-06-07 18:25   ` Jan Kiszka
2006-06-07 18:30   ` Philippe Gerum
2006-06-07 18:42   ` Jan Kiszka
2006-06-08 12:28     ` Gilles Chanteperdrix
2006-06-08 17:35       ` Heikki Lindholm
2006-06-08 18:42         ` Gilles Chanteperdrix
2006-06-08 19:27           ` Heikki Lindholm
2006-06-08 20:44             ` Gilles Chanteperdrix

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17537.48372.286093.220257@domain.hid \
    --to=gilles.chanteperdrix@xenomai.org \
    --cc=holindho@domain.hid \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.