From: Carsten Langgaard <carstenl@mips.com>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: linux-mips@oss.sgi.com
Subject: Re: Bug in the _save_fp_context.
Date: Mon, 19 Mar 2001 17:13:06 +0100 [thread overview]
Message-ID: <3AB63012.B2DF9CD6@mips.com> (raw)
In-Reply-To: 00e901c0b08b$50bed400$0deca8c0@Ulysses
"Kevin D. Kissell" wrote:
> > I think there is a bug in the _save_fp_context function in
> > arch/mips/kernel/r4k_fpu.S
> >
> > The problem is the following piece of code:
> >
> > jr ra
> > .set nomacro
> > EX(sw t0,SC_FPC_EIR(a0))
> > nop
> > .set macro
> >
> > First of all what should the ".set nomacro" do?
> > If it means that the EX macro shouldn't be used then this entry wouldn't
> > get into __ex_table, which would be wrong.
> > But it look like it uses the macro anyway, regardless of the ".set
> > nomacro", at least with the compiler I use.
>
> Not surprising, really. "EX" is presumably a cpp macro
> that gets expanded by gcc from the .S file, based on
> some include file. .set directives affect only the assembler,
> and would inhibit assembler-level macros only. I'm not
> sure just what the definition of an assembler macro
> would be - it may or may not include pseudo-instructions
> like "la" or "li 32_bit_constant". I *think* that what the
> author was trying to do here was to ensure that the
> "sw" instruction in the EX expansion was really and
> truly a single instruction.
>
> > Never the less we do not handle entries in the __ex_table which is
> > located in a branch delay.
> > So we need to handle the situation where we take a page fault on an
> > instruction which is located in a brach delay slot, or we don't put the
> > "potential" faulting instruction in a delay slot.
> >
> > Any ideas, how we should handle this in a nice and clean way?
>
> Is the __ex_table really ending up in the delay slot?
> Just looking at the source, I have the impression
> that the "sw t0,..." instruction should be in the delay
> slot, followed by the __ex_table.
The problem is that the address of the delay slot is put in the __ex_table
and then we take a page fault EPC is pointing at the jr instruction and not
the delay slot.
This result in a miss match when we try to lookup in __ex_table, resulting in
a kernel crash.
The faulting situation look like this:
EPC = address of delay slot
entry in __ex_table = address of delay slot - 4
Hopes that clarify it a bit more.
>
> On another topic, now that I've patched the kernel to
> turn off the stupid stuck interrupt on my Malta board,
> I've realized that I can't just connect my old Atlas SCSI
> disk. I'm torn between ordering a Tekram 390 PCI
> SCSI card, which should be able to use our "MIPS
> safe" NCR driver as-is (I hope) and buying an IDE
> disk and going through the network install ritual.
> Which do you recommend? One thing I really never
> knew was just what kernel config options I need to
> select to build a kernel that can do the NFS-root
> bootstrap. Can you help me there?
>
> Regards,
>
> Kevin K.
--
_ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com
|\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527
| \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555
TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556
Denmark http://www.mips.com
next prev parent reply other threads:[~2001-03-19 16:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-19 14:07 Bug in the _save_fp_context Carsten Langgaard
2001-03-19 15:43 ` Kevin D. Kissell
2001-03-19 15:43 ` Kevin D. Kissell
2001-03-19 16:03 ` Kevin D. Kissell
2001-03-19 16:03 ` Kevin D. Kissell
2001-03-19 18:14 ` Jun Sun
2001-03-19 16:13 ` Carsten Langgaard [this message]
2001-03-19 18:10 ` SCSI card [Re: Bug in the _save_fp_context.] Jun Sun
-- strict thread matches above, loose matches on Subject: below --
2002-01-17 13:34 Bug in the _save_fp_context Carsten Langgaard
[not found] ` <20020610114323.A25705@lucon.org>
2002-06-10 19:41 ` Carsten Langgaard
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=3AB63012.B2DF9CD6@mips.com \
--to=carstenl@mips.com \
--cc=kevink@mips.com \
--cc=linux-mips@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.