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 non-existing FPU.

Runing the math-emu 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/math-emu' )

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 panic-not 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.

Math-emulation 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 math-emu?

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 math-emulation 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/math-emu/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 math-emulation logic, I am simply wondering why it does that?

After all:

i) I enabled 'math-emulation' 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 math-emulation 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 'math-emu' enabled ) on three different PCs.
Each time the same problem: Each math-emu 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 re-ask your question there.