RE: [PATCH] invalid instructions in kernel mode

RE: [PATCH] invalid instructions in kernel mode

[Fillod Stephane]

Kumar Gala wrote:
> Are you running this via a ramdisk or nfs?  If ramdisk can you post it

> somewhere that I can get to?

I'm running via NFS.

> Also, can you email the list with the kernel oops that shows up.

I'll do that next week.

Anyway, reading the source suffices to realize there's a problem when=20
MATH_EMULATION is disabled on a FPU-less system with user programs=20
using load/store fp instructions.

--=20
Stephane

Re: [PATCH] invalid instructions in kernel mode

[Kumar Gala]

Ok,

After some debug on Friday and this weekend I understand what's going=20
on.  The reason we hit the code path in the kernel is due to the fact=20
that we are actually executing an integer load/store that is=20
misaligned, however when we read the instruction from memory we get a=20
float point instruction.  This is due to the fact that test app is not=20=

properly handling its self generated code.

Note, I was testing with math-emu turned on.

It seems to me that when we introduce CONFIG_PPC_FPU that we ifdef=20
around the code and return 0 in the 44x/e500 cases w/o FPUs

- kumar

On Apr 8, 2005, at 12:36 PM, Fillod Stephane wrote:

> Kumar Gala wrote:
>  > Are you running this via a ramdisk or nfs?=A0 If ramdisk can you =
post=20
> it
>
> > somewhere that I can get to?
>
> I'm running via NFS.
>
> > Also, can you email the list with the kernel oops that shows up.
>
> I'll do that next week.
>
> Anyway, reading the source suffices to realize there's a problem when
> MATH_EMULATION is disabled on a FPU-less system with user programs
> using load/store fp instructions.
>
> --=20
> Stephane

RE: [PATCH] invalid instructions in kernel mode

[Fillod Stephane]

Kumar Gala wrote:
> What is the crash01 test doing that causes this code to get invoked? =20

crash01[1] (of LTP) is derived from crashme[2], a tool by George J.
Carrette.
It simulates real user programs by generating pseudo-random code and
jumping
into it. This is a great tool to stress test operating system
robustness.
It is very good at testing weird corner cases that no one enjoy doing,=20
eventually finding bugs that may have bitten you in the field.=20
For instance, 2.6.11.6 kernels with math emulation off have a problem
with=20
load/store of fp regs. Please see my question in another mail with Dan.

[1]
http://cvs.sourceforge.net/viewcvs.py/ltp/ltp/testcases/misc/crash/crash
01.c?only_with_tag=3DHEAD&view=3Dmarkup
[2] http://people.delphiforums.com/gjc/crashme.html

> is the kernel you are using using build with math emulation on or off?

My kernel is built with math emulation off. My toolchain is soft-fp
based.


Best Regards,
--=20
Stephane

RE: [PATCH] invalid instructions in kernel mode

[Fillod Stephane]

Dan Malek wrote:
>> What I don't understand, is how the FP load/store operations
>> in misc.S can "work" on a system with no FPU and *no* math-emu?
>
>What should happen is to follow the example used by 8xx for
>many years.  As I said, when math emulation is disabled, there is
>still code that will emulate the load/store FP instructions.  These
>instructions are used in may places even if user applications
>are compiled without any FP usage.

Ok.

>> Many years? Allow me to doubt it's really used :).
>
>I wrote it in 1998 for the 8xx.  I thought 4xx and e500 used the
>same model.  If they don't, they should.

Let's get it fixed.

>> Though, it does work for 8xx thanks to Soft_emulate_8xx, but doesn't
>> for other FPU-less cores when CONFIG_MATH_EMULATION is disabled.
>
>Well, then that should get fixed.

What's the right way to fix it?

>> So here is another patch,
[..]
>The only patch I'm interested in is making the 4xx and e500 follow the
>same path as 8xx.  All of the non-FP cores should work the same way.

Speaking for myself, I don't plan on using the SPE FPU of the e500, but
would like to see the MATH_EMULATION=3Dn fixed. So how should we fix it?

It seems you didn't like my last patch which lets make enter the
math-emu
subdirectory only to compile the load/store (8xx could do that too).
Would you prefer a fix along the line of Soft_emulate_8xx() ?
Then should we make it a Soft_emulate_85xx and Soft_emulate_4xx or can
we attempt to fuse them altogether and rename(+make it generic)
Soft_emulate_8xx as Soft_emulate_classic?

>The e500 is a special case because it doesn't have a classic FPU but
>rather can utilize the SPE for floating point.  Put some thought into=20
>that.

I don't know what Kumar and his team have in mind for the e500, whether
they will use SPE FPU for the classic load/store "emulation". Kumar,
can you please enlighten us on this topic?


Thanks,
--=20
Stephane

Re: [PATCH] invalid instructions in kernel mode

[Dan Malek]

On Apr 5, 2005, at 8:24 AM, Fillod Stephane wrote:

> Speaking for myself, I don't plan on using the SPE FPU of the e500,

Why?

> It seems you didn't like my last patch which lets make enter the
> math-emu
> subdirectory only to compile the load/store (8xx could do that too).
> Would you prefer a fix along the line of Soft_emulate_8xx() ?

I'm not sure.  I need to think about it for a moment.  I was rushed to
do some travel, and now I'm back to work on it.

> I don't know what Kumar and his team have in mind for the e500,

The e500 tools use the SPE FPU for all single precision floating
point.  For our initial development we used the floating point 
emulation.


	-- Dan

RE: [PATCH] invalid instructions in kernel mode

[Fillod Stephane]

Hi Dan,

Please be aware I am no expert in that field, so bear with me :)

Dan Malek wrote:
>> When CPU has no (classic) FPU, and math emulation is disabled,
>> fp instructions are not allowed in kernel mode.
>
>FP Instructions are never allowed in kernel mode regardless of the CPU.
>However, with math emulation disabled and no FPU, we still emulate
>FP load/store operations because they are usually hard coded in
>some of the context save/restore functions of the C library.

What I don't understand, is how the FP load/store operations
in misc.S can "work" on a system with no FPU and *no* math-emu?

>> This bug has been found with crashme (crash01) of LTP, on a e500=20
>> system.
>
>What is the bug?  This patch disables a big feature we have been
>using for many years.  Please take another look at this.

Many years? Allow me to doubt it's really used :). I took a better=20
look, at math-emu/math.c. And then I understood why my previous
patch should not have disabled cvt_fd et al in misc.S.

The fact is, with CONFIG_MATH_EMULATION disabled, make does not enter
the math-emu/ subdir, math.c does not get compiled (so no lfs/etc.
emulation), and  by the way, nobody even call do_mathemu in
traps.c because it's always surrounded with #ifdef
CONFIG_MATH_EMULATION.
Though, it does work for 8xx thanks to Soft_emulate_8xx, but doesn't
for other FPU-less cores when CONFIG_MATH_EMULATION is disabled.

So here is another patch, which hopefully is a better fix,
yet find a solution to my problem. Please comment on it,
as I'm not sure whether ProgramCheckException is right.
Rem: it looks weird to use FP load/store operations when
you do know that you don't have a FPU and CONFIG_MATH_EMULATION
is disabled. Should we do like 8xx, and call directly
the emulation layer? Could we re-use Soft_emulate_8xx() (made generic
without the *_8xx_pte) for the 4xx and e500 ?


Signed-off-by: Stephane Fillod <fillods@gmail.com>=20

--- linux/arch/ppc/Makefile	26 Mar 2005 03:28:39 -0000	1.1.1.2
+++ linux/arch/ppc/Makefile	31 Mar 2005 18:59:25 -0000
@@ -55,10 +55,10 @@
 head-$(CONFIG_POWER4)		+=3D arch/ppc/kernel/idle_power4.o
=20
 core-y				+=3D arch/ppc/kernel/ arch/ppc/platforms/
\
-				   arch/ppc/mm/ arch/ppc/lib/
arch/ppc/syslib/
+				   arch/ppc/mm/ arch/ppc/lib/
arch/ppc/syslib/ \
+				   arch/ppc/math-emu/
 core-$(CONFIG_4xx)		+=3D arch/ppc/platforms/4xx/
 core-$(CONFIG_85xx)		+=3D arch/ppc/platforms/85xx/
-core-$(CONFIG_MATH_EMULATION)	+=3D arch/ppc/math-emu/
 core-$(CONFIG_XMON)		+=3D arch/ppc/xmon/
 core-$(CONFIG_APUS)		+=3D arch/ppc/amiga/
 drivers-$(CONFIG_8xx)		+=3D arch/ppc/8xx_io/
--- linux/arch/ppc/kernel/traps.c	30 Mar 2005 16:25:07 -0000
1.3
+++ linux/arch/ppc/kernel/traps.c	31 Mar 2005 18:59:25 -0000
@@ -540,7 +540,6 @@
 	    return;
 #endif /* CONFIG_ADEOS_CORE */
=20
-#ifdef CONFIG_MATH_EMULATION
 	/* (reason & REASON_ILLEGAL) would be the obvious thing here,
 	 * but there seems to be a hardware bug on the 405GP (RevD)
 	 * that means ESR is sometimes set incorrectly - either to
@@ -552,7 +551,6 @@
 		emulate_single_step(regs);
 		return;
 	}
-#endif /* CONFIG_MATH_EMULATION */
=20
 	if (reason & REASON_FP) {
 		/* IEEE FP exception */
--- linux/arch/ppc/kernel/process.c	26 Mar 2005 03:28:20 -0000
1.1.1.2
+++ linux/arch/ppc/kernel/process.c	31 Mar 2005 18:59:25 -0000
@@ -342,7 +342,7 @@
 	printk("\n");
 #ifdef CONFIG_KALLSYMS
 	/*
-	 * Lookup NIP late so we have the best change of getting the
+	 * Lookup NIP late so we have the best chance of getting the
 	 * above info out without failing
 	 */
 	printk("NIP [%08lx] ", regs->nip);



Thanks for the reply
--=20
Stephane

Re: [PATCH] invalid instructions in kernel mode

[Dan Malek]

On Mar 31, 2005, at 2:17 PM, Fillod Stephane wrote:

> What I don't understand, is how the FP load/store operations
> in misc.S can "work" on a system with no FPU and *no* math-emu?

What should happen is to follow the example used by 8xx for
many years.  As I said, when math emulation is disabled, there is
still code that will emulate the load/store FP instructions.  These
instructions are used in may places even if user applications
are compiled without any FP usage.

> Many years? Allow me to doubt it's really used :).

I wrote it in 1998 for the 8xx.  I thought 4xx and e500 used the
same model.  If they don't, they should.

> Though, it does work for 8xx thanks to Soft_emulate_8xx, but doesn't
> for other FPU-less cores when CONFIG_MATH_EMULATION is disabled.

Well, then that should get fixed.

> So here is another patch,

The only patch I'm interested in is making the 4xx and e500 follow the
same path as 8xx.  All of the non-FP cores should work the same way.
The e500 is a special case because it doesn't have a classic FPU but
rather can utilize the SPE for floating point.  Put some thought into 
that.

Thanks.


	-- Dan

[PATCH] invalid instructions in kernel mode

[Fillod Stephane]

Hi,

When CPU has no (classic) FPU, and math emulation is disabled,
fp instructions are not allowed in kernel mode.
This bug has been found with crashme (crash01) of LTP, on a e500 system.

The patch was made against linux 2.6.11.6.
A trivial typo fix has been appended.

Rem: a CONFIG_PPCFPU define could make life easier.


Signed-off-by: Stephane Fillod <fillods@gmail.com>

--- linux/arch/ppc/kernel/align.c	6 Dec 2004 16:18:11 -0000
1.1.1.1
+++ linux/arch/ppc/kernel/align.c	31 Mar 2005 16:33:25 -0000
@@ -333,10 +333,14 @@
 	}
=20
 	if (flags & F) {
+#if !(defined(CONFIG_4xx) || defined(CONFIG_8xx) ||
defined(CONFIG_E500)) || defined(CONFIG_MATH_EMULATION)
 		preempt_disable();
 		if (regs->msr & MSR_FP)
 			giveup_fpu(current);
 		preempt_enable();
+#else
+		return 0;
+#endif
 	}
=20
 	/* If we read the operand, copy it in, else get register values
*/
@@ -366,6 +370,8 @@
 		}
 		break;
=20
+#if !(defined(CONFIG_4xx) || defined(CONFIG_8xx) ||
defined(CONFIG_E500)) || defined(CONFIG_MATH_EMULATION)
+
 	/* Single-precision FP load and store require conversions... */
 	case LD+F+S:
 		preempt_disable();
@@ -379,6 +385,7 @@
 		cvt_df(&data.d, &data.f, &current->thread.fpscr);
 		preempt_enable();
 		break;
+#endif
 	}
=20
 	if (flags & ST) {
--- linux/arch/ppc/kernel/misc.S	26 Mar 2005 03:28:36 -0000
1.1.1.2
+++ linux/arch/ppc/kernel/misc.S	31 Mar 2005 16:33:25 -0000
@@ -1096,7 +1096,8 @@
  * and exceptions as if the cpu had performed the load or store.
  */
=20
-#if defined(CONFIG_4xx) || defined(CONFIG_E500)
+#if !(defined(CONFIG_4xx) || defined(CONFIG_E500) ||
defined(CONFIG_8xx)) ||  defined(CONFIG_MATH_EMULATION)
+#if defined(CONFIG_4xx) || defined(CONFIG_E500)
 _GLOBAL(cvt_fd)
 	lfs	0,0(r3)
 	stfd	0,0(r4)
@@ -1125,6 +1126,7 @@
 	stfd	0,-4(r5)
 	blr
 #endif
+#endif
=20
 /*
  * Create a kernel thread
--- linux/arch/ppc/kernel/process.c	26 Mar 2005 03:28:20 -0000
1.1.1.2
+++ linux/arch/ppc/kernel/process.c	31 Mar 2005 16:33:25 -0000
@@ -342,7 +342,7 @@
 	printk("\n");
 #ifdef CONFIG_KALLSYMS
 	/*
-	 * Lookup NIP late so we have the best change of getting the
+	 * Lookup NIP late so we have the best chance of getting the
 	 * above info out without failing
 	 */
 	printk("NIP [%08lx] ", regs->nip);


Best Regards,

--=20
Stephane

Re: [PATCH] invalid instructions in kernel mode

[Dan Malek]

On Mar 31, 2005, at 12:47 PM, Fillod Stephane wrote:

> When CPU has no (classic) FPU, and math emulation is disabled,
> fp instructions are not allowed in kernel mode.

FP Instructions are never allowed in kernel mode regardless of the CPU.
However, with math emulation disabled and no FPU, we still emulate
FP load/store operations because they are usually hard coded in
some of the context save/restore functions of the C library.

> This bug has been found with crashme (crash01) of LTP, on a e500 
> system.

What is the bug?  This patch disables a big feature we have been
using for many years.  Please take another look at this.

Thanks.


	-- Dan

Re: [PATCH] invalid instructions in kernel mode

[Kumar Gala]

What is the crash01 test doing that causes this code to get invoked? =20
is the kernel you are using using build with math emulation on or off?

- kumar

On Mar 31, 2005, at 11:47 AM, Fillod Stephane wrote:

> Hi,
>
> When CPU has no (classic) FPU, and math emulation is disabled,
>  fp instructions are not allowed in kernel mode.
>  This bug has been found with crashme (crash01) of LTP, on a e500=20
> system.
>
> The patch was made against linux 2.6.11.6.
>  A trivial typo fix has been appended.
>
> Rem: a CONFIG_PPCFPU define could make life easier.
>
>
>
> Signed-off-by: Stephane Fillod <fillods@gmail.com>
>
> --- linux/arch/ppc/kernel/align.c=A0=A0=A0=A0=A0=A0 6 Dec 2004 =
16:18:11 -0000
>  1.1.1.1
>  +++ linux/arch/ppc/kernel/align.c=A0=A0=A0=A0=A0=A0 31 Mar 2005 =
16:33:25 -0000
>  @@ -333,10 +333,14 @@
>  =A0=A0=A0=A0=A0=A0=A0 }
>  =A0
>  =A0=A0=A0=A0=A0=A0=A0 if (flags & F) {
>  +#if !(defined(CONFIG_4xx) || defined(CONFIG_8xx) ||
>  defined(CONFIG_E500)) || defined(CONFIG_MATH_EMULATION)
> =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 preempt_disable();
> =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 if (regs->msr & MSR_FP)
>  =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =
giveup_fpu(current);
> =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 preempt_enable();
> +#else
>  +=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 return 0;
>  +#endif
>  =A0=A0=A0=A0=A0=A0=A0 }
>  =A0
>  =A0=A0=A0=A0=A0=A0=A0 /* If we read the operand, copy it in, else get =
register=20
> values
> */
>  @@ -366,6 +370,8 @@
>  =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 }
>  =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 break;
>  =A0
>  +#if !(defined(CONFIG_4xx) || defined(CONFIG_8xx) ||
>  defined(CONFIG_E500)) || defined(CONFIG_MATH_EMULATION)
> +
>  =A0=A0=A0=A0=A0=A0=A0 /* Single-precision FP load and store require =
conversions...=20
> */
>  =A0=A0=A0=A0=A0=A0=A0 case LD+F+S:
>  =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 preempt_disable();
> @@ -379,6 +385,7 @@
>  =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 cvt_df(&data.d, &data.f, =
&current->thread.fpscr);
> =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 preempt_enable();
> =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 break;
>  +#endif
>  =A0=A0=A0=A0=A0=A0=A0 }
>  =A0
>  =A0=A0=A0=A0=A0=A0=A0 if (flags & ST) {
>  --- linux/arch/ppc/kernel/misc.S=A0=A0=A0=A0=A0=A0=A0 26 Mar 2005 =
03:28:36 -0000
>  1.1.1.2
>  +++ linux/arch/ppc/kernel/misc.S=A0=A0=A0=A0=A0=A0=A0 31 Mar 2005 =
16:33:25 -0000
>  @@ -1096,7 +1096,8 @@
>  =A0 * and exceptions as if the cpu had performed the load or store.
>  =A0 */
>  =A0
>  -#if defined(CONFIG_4xx) || defined(CONFIG_E500)
> +#if !(defined(CONFIG_4xx) || defined(CONFIG_E500) ||
>  defined(CONFIG_8xx)) ||=A0 defined(CONFIG_MATH_EMULATION)
> +#if defined(CONFIG_4xx) || defined(CONFIG_E500)
> =A0_GLOBAL(cvt_fd)
> =A0=A0=A0=A0=A0=A0=A0 lfs=A0=A0=A0=A0 0,0(r3)
>  =A0=A0=A0=A0=A0=A0=A0 stfd=A0=A0=A0 0,0(r4)
>  @@ -1125,6 +1126,7 @@
>  =A0=A0=A0=A0=A0=A0=A0 stfd=A0=A0=A0 0,-4(r5)
>  =A0=A0=A0=A0=A0=A0=A0 blr
>  =A0#endif
>  +#endif
>  =A0
>  =A0/*
>  =A0 * Create a kernel thread
>  --- linux/arch/ppc/kernel/process.c=A0=A0=A0=A0 26 Mar 2005 03:28:20 =
-0000
>  1.1.1.2
>  +++ linux/arch/ppc/kernel/process.c=A0=A0=A0=A0 31 Mar 2005 16:33:25 =
-0000
>  @@ -342,7 +342,7 @@
>  =A0=A0=A0=A0=A0=A0=A0 printk("\n");
>  =A0#ifdef CONFIG_KALLSYMS
> =A0=A0=A0=A0=A0=A0=A0 /*
>  -=A0=A0=A0=A0=A0=A0=A0 * Lookup NIP late so we have the best change =
of getting the
>  +=A0=A0=A0=A0=A0=A0=A0 * Lookup NIP late so we have the best chance =
of getting the
>  =A0=A0=A0=A0=A0=A0=A0=A0 * above info out without failing
>  =A0=A0=A0=A0=A0=A0=A0=A0 */
>  =A0=A0=A0=A0=A0=A0=A0 printk("NIP [%08lx] ", regs->nip);
>
>
>
> Best Regards,
>
> --=20
> Stephane

Re: [PATCH] invalid instructions in kernel mode

[Tom Rini]

On Thu, Mar 31, 2005 at 07:47:32PM +0200, Fillod Stephane wrote:

> When CPU has no (classic) FPU, and math emulation is disabled,
> fp instructions are not allowed in kernel mode.
[snip]
> --- linux/arch/ppc/kernel/misc.S	26 Mar 2005 03:28:36 -0000
> 1.1.1.2
> +++ linux/arch/ppc/kernel/misc.S	31 Mar 2005 16:33:25 -0000
> @@ -1096,7 +1096,8 @@
>   * and exceptions as if the cpu had performed the load or store.
>   */
>  
> -#if defined(CONFIG_4xx) || defined(CONFIG_E500)
> +#if !(defined(CONFIG_4xx) || defined(CONFIG_E500) ||
> defined(CONFIG_8xx)) ||  defined(CONFIG_MATH_EMULATION)
> +#if defined(CONFIG_4xx) || defined(CONFIG_E500)
>  _GLOBAL(cvt_fd)
>  	lfs	0,0(r3)
>  	stfd	0,0(r4)
> @@ -1125,6 +1126,7 @@
>  	stfd	0,-4(r5)
>  	blr
>  #endif
> +#endif

The problem here is, HEY! (classic) FP instrs in the kernel.  The
question is why?  Or rather, why are these four classic FP instrs
(lfs/lfd/stfd/stfs) being done on CONFIG_4xx || E500 when neither has
classic FP?  I think the problem here is that on !FPU
(which is 4xx||E500||8xx, or so), we need to rewrite these two
functions (yes, 8xx does emulate them if hit, but that's a tangent).

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: [PATCH] invalid instructions in kernel mode

[Kumar Gala]

On Apr 7, 2005, at 12:38 PM, Tom Rini wrote:

> On Thu, Mar 31, 2005 at 07:47:32PM +0200, Fillod Stephane wrote:
>
> > When CPU has no (classic) FPU, and math emulation is disabled,
>  > fp instructions are not allowed in kernel mode.
>  [snip]
>  > --- linux/arch/ppc/kernel/misc.S=A0=A0=A0=A0=A0 26 Mar 2005 =
03:28:36 -0000
>  > 1.1.1.2
>  > +++ linux/arch/ppc/kernel/misc.S=A0=A0=A0=A0=A0 31 Mar 2005 =
16:33:25 -0000
>  > @@ -1096,7 +1096,8 @@
>  >=A0=A0 * and exceptions as if the cpu had performed the load or =
store.
>  >=A0=A0 */
>  >=A0
> > -#if defined(CONFIG_4xx) || defined(CONFIG_E500)
> > +#if !(defined(CONFIG_4xx) || defined(CONFIG_E500) ||
>  > defined(CONFIG_8xx)) ||=A0 defined(CONFIG_MATH_EMULATION)
> > +#if defined(CONFIG_4xx) || defined(CONFIG_E500)
> >=A0 _GLOBAL(cvt_fd)
> >=A0 =A0=A0=A0=A0 lfs=A0=A0=A0=A0 0,0(r3)
>  >=A0 =A0=A0=A0=A0 stfd=A0=A0=A0 0,0(r4)
>  > @@ -1125,6 +1126,7 @@
>  >=A0 =A0=A0=A0=A0 stfd=A0=A0=A0 0,-4(r5)
>  >=A0 =A0=A0=A0=A0 blr
>  >=A0 #endif
>  > +#endif
>
> The problem here is, HEY! (classic) FP instrs in the kernel.=A0 The
>  question is why?=A0 Or rather, why are these four classic FP instrs
>  (lfs/lfd/stfd/stfs) being done on CONFIG_4xx || E500 when neither has
>  classic FP?=A0 I think the problem here is that on !FPU
> (which is 4xx||E500||8xx, or so), we need to rewrite these two
>  functions (yes, 8xx does emulate them if hit, but that's a tangent).

What is not clear to me is what condition causes these to get hit on an=20=

e500.

- kumar

Re: [PATCH] invalid instructions in kernel mode

[Tom Rini]

On Thu, Apr 07, 2005 at 04:41:59PM -0500, Kumar Gala wrote:
> 
> On Apr 7, 2005, at 12:38 PM, Tom Rini wrote:
> 
> >On Thu, Mar 31, 2005 at 07:47:32PM +0200, Fillod Stephane wrote:
> >
> >> When CPU has no (classic) FPU, and math emulation is disabled,
> > > fp instructions are not allowed in kernel mode.
> > [snip]
> > > --- linux/arch/ppc/kernel/misc.S????? 26 Mar 2005 03:28:36 -0000
> > > 1.1.1.2
> > > +++ linux/arch/ppc/kernel/misc.S????? 31 Mar 2005 16:33:25 -0000
> > > @@ -1096,7 +1096,8 @@
> > >?? * and exceptions as if the cpu had performed the load or store.
> > >?? */
> > >?
> >> -#if defined(CONFIG_4xx) || defined(CONFIG_E500)
> >> +#if !(defined(CONFIG_4xx) || defined(CONFIG_E500) ||
> > > defined(CONFIG_8xx)) ||? defined(CONFIG_MATH_EMULATION)
> >> +#if defined(CONFIG_4xx) || defined(CONFIG_E500)
> >>? _GLOBAL(cvt_fd)
> >>? ???? lfs???? 0,0(r3)
> > >? ???? stfd??? 0,0(r4)
> > > @@ -1125,6 +1126,7 @@
> > >? ???? stfd??? 0,-4(r5)
> > >? ???? blr
> > >? #endif
> > > +#endif
> >
> >The problem here is, HEY! (classic) FP instrs in the kernel.? The
> > question is why?? Or rather, why are these four classic FP instrs
> > (lfs/lfd/stfd/stfs) being done on CONFIG_4xx || E500 when neither has
> > classic FP?? I think the problem here is that on !FPU
> >(which is 4xx||E500||8xx, or so), we need to rewrite these two
> > functions (yes, 8xx does emulate them if hit, but that's a tangent).
> 
> What is not clear to me is what condition causes these to get hit on an 
> e500.

They are called in align.c from fix_alignment().  As has been said, some
of the stress testing apps in LTP will trigger this.  Since the comment
around the code in question (in fix_alignent()) is
/* Single-precision FP load and store require conversions... */
perhaps it's more valid to not define these functions on e500 || 4xx,
and make the two cases in the switch there depend on !e500 && !4xx.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: [PATCH] invalid instructions in kernel mode

[Kumar Gala]

[snip]
>  > >The problem here is, HEY! (classic) FP instrs in the kernel.? The
>  > > question is why?? Or rather, why are these four classic FP instrs
>  > > (lfs/lfd/stfd/stfs) being done on CONFIG_4xx || E500 when neither=20=

> has
>  > > classic FP?? I think the problem here is that on !FPU
>  > >(which is 4xx||E500||8xx, or so), we need to rewrite these two
>  > > functions (yes, 8xx does emulate them if hit, but that's a=20
> tangent).
>  >
> > What is not clear to me is what condition causes these to get hit on=20=

> an
> > e500.
>
> They are called in align.c from fix_alignment().=A0 As has been said,=20=

> some
>  of the stress testing apps in LTP will trigger this.=A0 Since the=20
> comment
>  around the code in question (in fix_alignent()) is
>  /* Single-precision FP load and store require conversions... */
>  perhaps it's more valid to not define these functions on e500 || 4xx,
>  and make the two cases in the switch there depend on !e500 && !4xx.

What I'm concerned about what instruction is actually causing this=20
fault that e500 actually gets into this case to began with.  Maybe I=20
missed something in the email thread, but it would seem the only way to=20=

get here is via kernel emulation of the floating point load/store=20
instructions, but that seems odd since they would have to be doing=20
normal integer load/store... something is not quiet right in all this.

Before we go start making changes I really do want to know what=20
instruction, with what effective address is causing this case to get=20
triggered.

Can someone add something like the following:

if (__get_user(instr, (unsigned int __user *) regs->nip))
    return 0;

int insn_orig;
....

insn_orig =3D instr;

....

case LD+F+S:
     printk ("align fault [LD+F+S] for insn =3D %x @ %x\n", insn_orig,=20=

regs->nip);
..
case ST+F+S:
     printk ("align fault [ST+F+S] for insn =3D %x @ %x\n", insn_orig,=20=

regs->nip);

and report back the results.

thanks

- kumar

Re: [PATCH] invalid instructions in kernel mode

[Kumar Gala]

Fillod,

Are you running this via a ramdisk or nfs?  If ramdisk can you post it 
somewhere that I can get to?

Also, can you email the list with the kernel oops that shows up.

thanks

- kumar