Messages in this thread Patch in this message |  | | Date | Fri, 20 Oct 2000 16:46:26 +0200 | From | Andrea Arcangeli <> | Subject | missing mxcsr initialization |
| |
mxcsr is per-process thing and it's saved and restored with the fpu and it should be initialized to its default value at reset the first time a task uses the FPU as we do with the other parts of the FPU (default value at reset means all SIMD exceptions are masked).
--- 2.4.0-test10-pre3/arch/i386/kernel/i387.c.~1~ Sat Oct 14 19:00:15 2000 +++ 2.4.0-test10-pre3/arch/i386/kernel/i387.c Thu Oct 19 04:02:18 2000 @@ -33,6 +33,21 @@ #endif /* + * The _current_ task is using the FPU for the first time + * so initialize it and set the mxcsr to its default + * value at reset if we support FXSR and then + * remeber the current task has used the FPU. + */ +void init_fpu(void) +{ + __asm__("fninit"); + if ( HAVE_FXSR ) + load_mxcsr(0x1f80); + + current->used_math = 1; +} + +/* * FPU lazy state save handling. */ --- 2.4.0-test10-pre3/arch/i386/kernel/traps.c.~1~ Thu Oct 12 03:04:39 2000 +++ 2.4.0-test10-pre3/arch/i386/kernel/traps.c Thu Oct 19 04:02:56 2000 @@ -741,11 +741,7 @@ if (current->used_math) { restore_fpu(current); } else { - /* - * Our first FPU usage, clean the chip. - */ - __asm__("fninit"); - current->used_math = 1; + init_fpu(); } current->flags |= PF_USEDFPU; /* So we fnsave on switch_to() */ } --- 2.4.0-test10-pre3/include/asm-i386/bugs.h.~1~ Sun Oct 15 17:51:59 2000 +++ 2.4.0-test10-pre3/include/asm-i386/bugs.h Thu Oct 19 04:01:58 2000 @@ -94,7 +94,6 @@ printk(KERN_INFO "Enabling unmasked SIMD FPU exception support... "); set_in_cr4(X86_CR4_OSXMMEXCPT); printk("done.\n"); - load_mxcsr(0x1f80); } #endif --- 2.4.0-test10-pre3/include/asm-i386/i387.h.~1~ Sun Oct 15 17:51:59 2000 +++ 2.4.0-test10-pre3/include/asm-i386/i387.h Thu Oct 19 04:03:19 2000 @@ -16,6 +16,7 @@ #include <asm/sigcontext.h> #include <asm/user.h> +extern void init_fpu(void); /* * FPU lazy state save handling... */ --- 2.4.0-test10-pre3/include/asm-i386/user.h.~1~ Thu Oct 19 04:11:32 2000 +++ 2.4.0-test10-pre3/include/asm-i386/user.h Thu Oct 19 04:37:44 2000 @@ -48,8 +48,8 @@ long twd; long fip; long fcs; - long fdp; - long fds; + long foo; + long fos; long st_space[20]; /* 8*10 bytes for each FP-reg = 80 bytes */ }; The last part (user.h) shouldn't matter, that structure seems significant only for its size but it's a typo so I correted it.
(btw such bug was not present in Doug's 2.2.x alternative version of the PIII FPU support)
Patch is downloadable also from here:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.0-test10-pre3/PIII-fxsr-1
2.2.x backport of the PIII support with the above bugfix included against 2.2.18pre15aa1 is here (I will include in the next aa patchkit):
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre15aa1/PIII-3.bz2
Such patch is been generated by a mix of PIII 2.2.x patch and the PIII 2.4.x support plus some additional change. (at the end it's very similar to 2.4.x, but the 2.2.x version is been very useful too for doing comparison)
This 2.2.x version is completly dynamic (an i386 compile will use fxsr if CPU running the kernel supports it). None compile time configuration option is added.
Two kernel kernel parameters are added: "serialnumber" and "nofxsr".
The former tells the kernel not to disable the serial number (so if the BIOS doesn't disable it it will remain enabled). The latter forces the kernel not to use fxsr even if the feature is present in the CPU.
The patch only provides new instructions to userspace and it __never__ takes adavantage of the FPU in kernel space and it also doesn't change at all the logic for the lazy FPU handling. It also provides simd exceptions via signal and the fxsr state via two new ptrace operations with the same interface of 2.4.0-test10-pre3.
It also handles the case of an asymmetric MP system with some CPU supporting FXSR and some without FXSR by detecting the condition and then doing:
panic("To boot use the `nofxsr' kernel parameter");
asymmetric MP almost always are because people plugins a new CPU by hand, so they're expected to know also what is a kernel parameter :). The panic at boot with hint with the solution is much better than breaking later at runtime as I got bugreport for that. I didn't hanlded that condition automatically via IPI because that was tricky and it didn't worth the effort IMHO.
Many thanks to Doug and Gabriel for very useful explanations about this FPU stuff. I suggest Gabriel to submit his way faster and more correct tag word conversion function to Linus for 2.4.x.
Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |