From: "Kevin D. Kissell" <kevink@mips.com>
To: <linux-mips@oss.sgi.com>
Subject: Re: Bug in the _save_fp_context.
Date: Mon, 19 Mar 2001 17:03:49 +0100 [thread overview]
Message-ID: <00f901c0b08e$3099bc00$0deca8c0@Ulysses> (raw)
In-Reply-To: 00e901c0b08b$50bed400$0deca8c0@Ulysses
Oops! I hadn't noticed that Carsten had copied the
Linux-MIPS mailing list on this, so I treated it as a
point-to-point communication. The rest of you can
ignore my last paragraph!
Kevin K.
----- Original Message -----
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Carsten Langgaard" <carstenl@mips.com>; <linux-mips@oss.sgi.com>
Sent: Monday, March 19, 2001 4:43 PM
Subject: Re: Bug in the _save_fp_context.
> > 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.
>
> 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.
>
WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: linux-mips@oss.sgi.com
Subject: Re: Bug in the _save_fp_context.
Date: Mon, 19 Mar 2001 17:03:49 +0100 [thread overview]
Message-ID: <00f901c0b08e$3099bc00$0deca8c0@Ulysses> (raw)
Message-ID: <20010319160349.QkX6O7LAJ1DQjGlvCSR56Uf1hySSXILS7i5HqM3plrc@z> (raw)
In-Reply-To: 00e901c0b08b$50bed400$0deca8c0@Ulysses
Oops! I hadn't noticed that Carsten had copied the
Linux-MIPS mailing list on this, so I treated it as a
point-to-point communication. The rest of you can
ignore my last paragraph!
Kevin K.
----- Original Message -----
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Carsten Langgaard" <carstenl@mips.com>; <linux-mips@oss.sgi.com>
Sent: Monday, March 19, 2001 4:43 PM
Subject: Re: Bug in the _save_fp_context.
> > 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.
>
> 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.
>
next prev parent reply other threads:[~2001-03-19 15:59 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 [this message]
2001-03-19 16:03 ` Kevin D. Kissell
2001-03-19 18:14 ` Jun Sun
2001-03-19 16:13 ` Carsten Langgaard
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='00f901c0b08e$3099bc00$0deca8c0@Ulysses' \
--to=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.