Re: CONFIG_PREEMPT causes corruption of application's FPU stack

[Jürgen Mell]

On Sonday, 18. May 2008, you wrote:
> 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.
> >
> > The problem is reproducible in so far as the error always occurs when
> > CONFIG_PREEMPT is set, but the time to the first occurrence varies
> > greatly from some minutes up to more than 10 CPU hours.
> >
> > I found this error first on an openSUSE kernel 2.6.22.17-0.1-rt. I
> > verified the problem on the following kernel versions:
> >
> > openSUSE 2.6.22.17-0.1-default
> > openSUSE 2.6.23.17-ccj64-rt
> > kernel.org 2.6.26-rc1
> > kernel.org 2.6.26-rc2-git5
>
> So you see this error in both the SuSE RT kernel, *and* mainline
> kernel.org?

Yes, that is correct. The error is present from the 2.6.22 SUSE kernel up 
to the most recent mainline kernel. It is also present in the standard 
SUSE kernel, if I just modify *only* CONFIG_PREEMPT.
What makes me wonder: I am using the machine in a production environment 
for programming, multi-media etc. Why does only the Einstein program catch 
the SIGFPE? Normally I would expect other programs to crash, too, if the 
problem is present. But up to now this never happened.

> If you see it in the kernel.org kernel, can you please do a git-bisect
> to see which commit caused the problem?

This is a bit of a problem. I do not know whether there was *ever* a kernel 
version with CONFIG_PREEMPT and without this problem as I have not tried 
any older kernel version yet. I will go back to SUSE 10.2 and try the 
2.6.18 kernel that comes with it.

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/