kernel panic despite enabling math-emulation

kernel panic despite enabling math-emulation

[Reza Mostafid]

I am trying to build a stripped down v2.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
( based on 2.6.23.1 kernel ) using the source from Fedora 8 ( i.e.
with the F8 patches
  applied against a 2.6.23.1 kernel )

As a first step, after building the kernel with
'CONFIG_MATH_EMULATION=y' I tried to test
this feature on my build machine ( which does have an FPU ), by
supplying the 'no387'
boot parameter in order to simulate a non-existing FPU.

Running the math-emu enabled kernel in this way causes a kernel panic
which happens before
spawning 'init' and early-user space initialization.

I have observed this condition with several 2.6.* kernel versions and
several Intel/AMD boxes.

Using the 'earlyprintk=vga' bootparameter 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()' code snippet executes
its stuff without hick ups
when the 'no388' boot parameter is processed

 37 static int __init no_387(char *s)
 38 {
 39         boot_cpu_data.hard_math = 0;
 40         write_cr0(0xE | read_cr0());
 41         return 1;
 42 }
 43
 44 __setup("no387", no_387);

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 needed in kernel

So it appears that even with math emulation enabled the logic of the
code in 'fpu_entry.c' 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 overlooking anything?

 or

Q2) Is this a problem in the code?

 and finally

Q3) Any suggestions for how I could get a 2.6 kernel to actually run
with the math-emu?



Regards


Reza Mostafid



==========================================================================================================

Here is a reproduction of the steps I took:


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 problem was observed on:

Intel Celeron 331 ( Netburst type P4 )
AMD Semperon
AMD Athlon

Re: kernel panic despite enabling math-emulation

[Randy Dunlap]

Reza Mostafid wrote:
> I am trying to build a stripped down v2.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
> ( based on 2.6.23.1 kernel ) using the source from Fedora 8 ( i.e.
> with the F8 patches
>   applied against a 2.6.23.1 kernel )
> 
> As a first step, after building the kernel with
> 'CONFIG_MATH_EMULATION=y' I tried to test
> this feature on my build machine ( which does have an FPU ), by
> supplying the 'no387'
> boot parameter in order to simulate a non-existing FPU.
> 
> Running the math-emu enabled kernel in this way causes a kernel panic
> which happens before
> spawning 'init' and early-user space initialization.
> 
> I have observed this condition with several 2.6.* kernel versions and
> several Intel/AMD boxes.
> 
> Using the 'earlyprintk=vga' bootparameter 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()' code snippet executes
> its stuff without hick ups
> when the 'no388' boot parameter is processed
> 
>  37 static int __init no_387(char *s)
>  38 {
>  39         boot_cpu_data.hard_math = 0;
>  40         write_cr0(0xE | read_cr0());
>  41         return 1;
>  42 }
>  43
>  44 __setup("no387", no_387);
> 
> 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 needed in kernel
> 
> So it appears that even with math emulation enabled the logic of the
> code in 'fpu_entry.c' 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 overlooking anything?
> 
>  or
> 
> Q2) Is this a problem in the code?
> 
>  and finally
> 
> Q3) Any suggestions for how I could get a 2.6 kernel to actually run
> with the math-emu?
> 
> 
> 
> Regards
> 
> 
> Reza Mostafid
> 
> 
> 
> ==========================================================================================================
> 
> Here is a reproduction of the steps I took:
> 
> 
> 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 problem was observed on:
> 
> Intel Celeron 331 ( Netburst type P4 )
> AMD Semperon
> AMD Athlon


I can easily reproduce this on a Pentium M running 2.6.30-rc7,
although it's a bit difficult to get a backtrace of it.

-- 
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/

Re: kernel panic despite enabling math-emulation

[Randy Dunlap]

Randy Dunlap wrote:
> Reza Mostafid wrote:
>> I am trying to build a stripped down v2.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
>> ( based on 2.6.23.1 kernel ) using the source from Fedora 8 ( i.e.
>> with the F8 patches
>>   applied against a 2.6.23.1 kernel )
>>
>> As a first step, after building the kernel with
>> 'CONFIG_MATH_EMULATION=y' I tried to test
>> this feature on my build machine ( which does have an FPU ), by
>> supplying the 'no387'
>> boot parameter in order to simulate a non-existing FPU.
>>
>> Running the math-emu enabled kernel in this way causes a kernel panic
>> which happens before
>> spawning 'init' and early-user space initialization.
>>
>> I have observed this condition with several 2.6.* kernel versions and
>> several Intel/AMD boxes.
>>
>> Using the 'earlyprintk=vga' bootparameter 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()' code snippet executes
>> its stuff without hick ups
>> when the 'no388' boot parameter is processed
>>
>>  37 static int __init no_387(char *s)
>>  38 {
>>  39         boot_cpu_data.hard_math = 0;
>>  40         write_cr0(0xE | read_cr0());
>>  41         return 1;
>>  42 }
>>  43
>>  44 __setup("no387", no_387);
>>
>> 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 needed in kernel
>>
>> So it appears that even with math emulation enabled the logic of the
>> code in 'fpu_entry.c' 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 overlooking anything?
>>
>>  or
>>
>> Q2) Is this a problem in the code?
>>
>>  and finally
>>
>> Q3) Any suggestions for how I could get a 2.6 kernel to actually run
>> with the math-emu?
>>
>>
>>
>> Regards
>>
>>
>> Reza Mostafid
>>
>>
>>
>> ==========================================================================================================
>>
>> Here is a reproduction of the steps I took:
>>
>>
>> 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 problem was observed on:
>>
>> Intel Celeron 331 ( Netburst type P4 )
>> AMD Semperon
>> AMD Athlon
> 
> 
> I can easily reproduce this on a Pentium M running 2.6.30-rc7,
> although it's a bit difficult to get a backtrace of it.

Booting with "no387 nofxsr noxsave" allows me to boot successfully.

(noxsave is a very recent addition, after 2.6.30-rc7.  I don't know
if it's really required, but it makes sense to me to use it along
with the other 2.)



-- 
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/