Running a 2.6.* kernel with math emulation ( Does the math emulation work ?)

Linux - KernelThis forum is for all discussion relating to the Linux kernel.

Notices

Welcome to LinuxQuestions.org, a friendly and active Linux Community.

You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

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 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

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' )

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

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

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'

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.

LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.