[PATCH] invalid instructions in kernel mode
kumar.gala at freescale.com
Fri Apr 8 08:29:32 EST 2005
> > >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
> > > 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
> > What is not clear to me is what condition causes these to get hit on
> > e500.
> They are called in align.c from fix_alignment(). As has been said,
> of the stress testing apps in LTP will trigger this. Since the
> 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
fault that e500 actually gets into this case to began with. Maybe I
missed something in the email thread, but it would seem the only way to
get here is via kernel emulation of the floating point load/store
instructions, but that seems odd since they would have to be doing
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
instruction, with what effective address is causing this case to get
Can someone add something like the following:
if (__get_user(instr, (unsigned int __user *) regs->nip))
insn_orig = instr;
printk ("align fault [LD+F+S] for insn = %x @ %x\n", insn_orig,
printk ("align fault [ST+F+S] for insn = %x @ %x\n", insn_orig,
and report back the results.
More information about the Linuxppc-dev