Re: CONFIG_PREEMPT causes corruption of application's FPU stack

[j . mell]

Hi,

> On Sat, May 17, 2008 at 06:31:08PM +0200, J?rgen Mell wrote:
> I tracked this down to a single kernel configuration option. If
> CONFIG_PREEMPT is set to 'y' the application will start crashing.
> If  CONFIG_PREEMPT is replaced by CONFIG_PREEMPT_VOLUNTARY, the
> application will run without errors.

With lots of help from Heinz-Bernd, Bernd and Oliver of the Einstein@Home 
project I now found the the following:

1. Einstein@home will crash with trap #8 if the problem is present. The 
error occurs between some minutes after starting Einstein up to more than 
10 hours after starting Einstein. This seems to depend on how many other 
applications are used on the system (it takes much more time, if only the 
Einstein processes are active on the system).

2. The error was introduced between kernel.org kernels 2.6.19.7 and 2.6.20. 
It is still present in 2.6.26-rc4

3. If I revert the patch
 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=acc207616a91a413a50fdd8847a747c4a7324167

in 2.6.20, Einstein does not crash anymore (program was run for more than 
30 hours while system was in normal use with programming, multi-media 
etc.). Unfortunately git refuses to revert this patch in 2.6.26-rc4.

Now I need some help as I am not an expert in this area. What I assume is 
that either the state of the FPU is not always restored (perhaps if the 
process is swapped between the two cores?) or it is restored more than 
once. Please keep in mind, that I am always running two Einstein processes 
simultaneously on my two cores!
I am willing to do further testing of this problem if someone can give me a 
hint how to continue.

Bye,

          Jürgen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/