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

User Name

Remember Me?

Password

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.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

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

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?

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.

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.