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;