> Victor Zandy <email@example.com> writes:
> > We have found that one of our programs can cause system-wide
> > corruption of the x86 FPU under 2.2.16 and 2.2.17. That is, after we
> > run this program, the FPU gives bad results to all subsequent
> > processes.
> We have now tested 2.4.2 and 2.2.19.
> 2.2.19 has the same problem.
> 2.4.3 does not seem to be affected. Unfortunately, we really need a
> working 2.2 kernel at this time.
> We also patched the 2.2.19 kernel with the PIII patch found in
> on ftp.kernel.org. Same problem.
> Does anyone have any ideas for us?
Just for kicks, do whatever is necessary to "break" the fpu. Then run
If it "fixes" it, there is no problem with the FPU, but with the
'C' runtime library which doesn't initialize the FPU to a known
state before it uses it. It is possible for the kernel to work
around th 'C' library problem by clearing the FPU after every
fork(). The last time I checked (years ago), 'finit' was executed
during the fork. Maybe it isn't anymore because it takes many
machine-cycles to complete.
If this doesn't "fix" it, then your hardware may have a problem
like overheating, etc., (loose heatsink?).
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/