Running a 2.6.* kernel with math emulation ( Does the math emulation work ?)
I am trying to build a peared down v3.6.* kernel to run on a single chip 386 processor.
As I understand it, the math emulation library must be enabled ( compiled into the kernel ) to cater for the absence of a proper HW FPU. I am doing the builds on a more modern x86 desktop machine running Fedora 8 ( which is based on 2.6.23.1 kernel ), and as a first step I tried enabling the math emulation using 'make menuconfig'. To test this feature on my build machine ( which does have an FPU ) I supply the 'no387' boot parameter in order to simulate a nonexisting FPU. Runing the mathemu enabled kernel in this way causes a kernel panic which happens before spawning 'init' and switching to user space initialization. I have observed this condition with: i) two different versions of the kernel ( 2.6.23.1. & 2.6.12.6 ) running on an 'Intel Celeron 331' ( i.e. netburst P4 type ) ii) version 2.6.11.12 running on an AMD Semperon type machine Using the 'earlyprintk=vga' bootparamter and some printk statements sprinkled in the appropriate corners of the code ( i.e. '__init' function 'no387()' in bug.c ) I was able to observe that in all three cases the 'no387()' snippet executes its stuff without hickups when the 'no388' boot parameter is processed ( i.e. the two statements boot_cpu_data.hard_math = 0; write_cr0(0xE  read_cr0()); ) The kernel freeze happens as a result of a panic in 'fpu_entry.c' ( here I have reproduced code and line no.s from the file as it exists in v2.6.23.1 under 'arch/i386/mathemu' ) 179 else if ( FPU_CS == __KERNEL_CS ) 180 { 181 printk("math_emulate: %04x:%08lx\n",FPU_CS,FPU_EIP); 182 panic("Math emulation needed in kernel"); 183 } 184 else In all cases the following lines are the last outputs to the console: math_emulate: <some FPU_CS value>:<some FPU_EIP value> Kernel panicnot syncing: Math emulation neded in kernel So it appears to me that even though I have 'enabled' math emulation using 'menuconfig', the logic of the code takes the kernel into the above 'else', i.e. the kernel thinks that there is no 'math emulation'. Searching the web I was able to find references to this problem in several threads but no apparent solution to it. Mathemulation albeit not a widely used feature, should have been around long enough for someone to have stumbled upon such an obvious problem. Q1) Am I doing anything wrong? or Q2) Is this a problem in the code? and Q3) Any suggestions for how I could get a 2.6 kernel to actually run with the mathemu? Thanks in advance for any tips, pointers and advice Regards dar_beh_dar 
OK, so you did the "make menuconfig", but it's not clear in your post whether you actually compiled and installed the kernel for that .config.

Yes, I did compile and attempt to boot the kernel.
That is how I noticed the problem and produced the diagnostics. I was expecting the kernel to consume the 'no387' bootparameter, which it does ( as revealed by the use of the 'earlyprintk=vga' boot param and the 'printk()' statements ). Without the 'no387' the kernel boots fine since the FPU is used despite the mathemulation being compiled/enabled ( as advertised per kernel documentation ). As a next step, to fake an FPU'less CPU and test the emulation, I supplied the 'no387' param, the result being that the 'no387()' does its thing as it should ( verified by early console messages ) however when the kernel later enters 'math_emulate()' in 'arch/i386/mathemu/fpu_entry.c' it executes the following branch . . . 178 else if ( FPU_CS == __KERNEL_CS ) 179 { 180 printk("math_emulate: %04x:%08lx\n",FPU_CS,FPU_EIP); 181 panic("Math emulation needed in kernel"); 182 } 183 else . . . In short the test 'FPU_CS == __KERNEL_CS' is true leading the kernel to print the FPU pointer to the console and panic. Without knowing anything about the details of the mathemulation logic, I am simply wondering why it does that? After all: i) I enabled 'mathemulation' in the configuration, so ( at least I think ) the math emulation is enabled ii) I have told the kernel to forget the FPU, which is apparently also registered since the 'no387()' is correctly executed Yet the kernel panics as observed. To be absolutely sure: i) I downloaded the source rpms for the Fedora distro I am running ( Fedora Core 8 which runs a modified version of the 2.6.23.1 kernel ). ii) I compiled the Fedora kernel version thus obtained ( using the supplied distro .config ) and it boots fine iii) I then change a single parameter of the original configuration, i.e. enable mathemulation and I observed the problem ( kernel panics with the 'no387' param supplied ) iv) I then reproduced the same problem booting a 'kernel.org' vanilla 2.6.23.1 kernel with the same configuration and observed the same problem. v) Finally several different versions of the 'kernel.org' vanilla source were compiled with the same configuration ( the FC8 distro '.config' with just the 'mathemu' enabled ) on three different PCs. Each time the same problem: Each mathemu enabled kernel boots fine, until you supply the 'no387' option, in which case all of them hang at the same place. ==================================================================================================== ====== Configuration used as base: That of the Fedora 8 distro Parameter changed: CONFIG_MATH_EMULATION=y Kernels tested: 2.6.23.1 source rpm for Fedora 8 2.6.23.1 'vanilla' from 'kernel.org' 2.6.11.12 'vanilla' from 'kernel.org' 2.6.12.6 'vanilla' from 'kernel.org' 2.6.28.8 'vanilla' from 'kernel.org' CPUs/machines used: Intel Celeron 331 ( Netburst type P4 ) AMD Semperon AMD Athlon 
Well, it does look like you've pressed all the right buttons and turned all the right knobs, then. ;) You might google "no387 behavior" (as well as using the search button, here), and if you don't find anything, then you might locate the proper kernel development mailing list and reask your question there.

All times are GMT 5. The time now is 10:38 AM. 