It appears to me that lazy fpu switch has no relevancy to CPUs that don't have
FPU.
If you do a scan, you will see last_task_used_math are used in four kernel
files:
ptrace.c
process.c
signal.c
traps.c
In the case of ptrace.c and process.c, the variable is used only when CPU has
FPU.
In the case of traps.c (do_cpu()), it used redaundantly with another condition
checking.
In the case of signal.c, no matter what last_task_used_math is, the same code
will be executed anyway.
Now think about it, it actually makes sense - if we don't have hardware FPU,
why do we care of fpu context switch.
Anyhow, the problem I am seeing with FPU/SMP case seems to be caused by FPU
emulation code itself, if we can assume it is not caused by fpu context
switch. Right now the FPU is not turned on on the box.
The following patch cleans it up a little based on the above observation.
Make sense?
Jun
diff -Nru linux/arch/mips/kernel/traps.c.orig linux/arch/mips/kernel/traps.c
--- linux/arch/mips/kernel/traps.c.orig Wed Jan 30 15:17:12 2002
+++ linux/arch/mips/kernel/traps.c Thu Feb 21 18:46:28 2002
@@ -678,14 +678,11 @@
return;
fp_emul:
- if (last_task_used_math != current) {
- if (!current->used_math) {
- fpu_emulator_init_fpu();
- current->used_math = 1;
- }
+ if (!current->used_math) {
+ fpu_emulator_init_fpu();
+ current->used_math = 1;
}
sig = fpu_emulator_cop1Handler(regs);
- last_task_used_math = current;
if (sig)
force_sig(sig, current);
return;