[lkml]   [2008]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: CONFIG_PREEMPT causes corruption of application's FPU stack

> 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.
> 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 kernels and 2.6.20.
It is still present in 2.6.26-rc4

3. If I revert the patch;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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2008-06-01 11:05    [W:0.088 / U:19.664 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site