From: Kumar Gala <kumar.gala@freescale•com>
To: "Tom Rini" <trini@kernel•crashing.org>
Cc: linuxppc-dev@ozlabs•org
Subject: Re: [PATCH] invalid instructions in kernel mode
Date: Thu, 7 Apr 2005 17:29:32 -0500 [thread overview]
Message-ID: <159727e9d7fb3a3d217b6edf411e43c1@freescale.com> (raw)
In-Reply-To: <20050407221440.GT3396@smtp.west.cox.net>
[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
next prev parent reply other threads:[~2005-04-07 22:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-31 17:47 [PATCH] invalid instructions in kernel mode Fillod Stephane
2005-03-31 18:15 ` Dan Malek
2005-04-01 10:04 ` Kumar Gala
2005-04-07 17:38 ` Tom Rini
2005-04-07 21:41 ` Kumar Gala
2005-04-07 22:14 ` Tom Rini
2005-04-07 22:29 ` Kumar Gala [this message]
2005-04-08 16:02 ` Kumar Gala
-- strict thread matches above, loose matches on Subject: below --
2005-03-31 19:17 Fillod Stephane
2005-04-01 3:45 ` Dan Malek
2005-04-05 12:24 Fillod Stephane
2005-04-05 16:16 ` Dan Malek
2005-04-05 12:25 Fillod Stephane
2005-04-08 17:36 Fillod Stephane
2005-04-11 15:39 ` Kumar Gala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=159727e9d7fb3a3d217b6edf411e43c1@freescale.com \
--to=kumar.gala@freescale$(echo .)com \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=trini@kernel$(echo .)crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox