From: Ralf Baechle <ralf@oss.sgi.com>
To: Carsten Langgaard <carstenl@mips.com>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
linux-mips@fnet.fr, linux-mips@oss.sgi.com
Subject: Re: [patch] MIPS64 R4k TLB refill CP0 hazards
Date: Fri, 2 Aug 2002 13:05:52 +0200 [thread overview]
Message-ID: <20020802130552.C27824@dea.linux-mips.net> (raw)
In-Reply-To: <3D4A519B.3EF5459@mips.com>; from carstenl@mips.com on Fri, Aug 02, 2002 at 11:32:18AM +0200
On Fri, Aug 02, 2002 at 11:32:18AM +0200, Carsten Langgaard wrote:
> > > After looking at the generated assembly I discovered the handlers don't
> > > fit in 128 bytes. They didn't crash since I have modules disabled for
> > > now, so the vmalloc path didn't get hit and the user path happened to fit,
> > > but it was pure luck. The path got hit before I fixed a bug in gas though
> > > -- that's the explanation of the false cache error exceptions I used to
> > > observe.
> >
> > Ouch. It was a known problem but we simply ignored it for a while as that
> > handler just overwrites the cache error handler which normally should be
> > used extremly rarely, if at all. The problem is somewhat itching by now
> > as we're supporting the SB1 core which in it's revision one may throw
> > spurious cache errors, so the handler is actually used ...
> >
>
> Maybe it's time for some intelligent check for the size of these exception
> routine.
Easy trick at compile time which will just inflate the object code a little
bit:
.align 5
LEAF(except_vec1_r4k)
[...]
END(except_vec1_r4k)
.org except_vec1_r4k + 0x80
This will result in an assembler error if the body of the except_vec1_r4k
function is bigger than 0x80.
Ralf
next prev parent reply other threads:[~2002-08-02 11:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-29 15:23 [patch] MIPS64 R4k TLB refill CP0 hazards Maciej W. Rozycki
2002-07-29 20:10 ` Carsten Langgaard
2002-07-30 6:59 ` Carsten Langgaard
2002-07-30 11:29 ` Ralf Baechle
2002-07-30 12:09 ` Carsten Langgaard
2002-07-30 12:44 ` Maciej W. Rozycki
2002-07-30 22:47 ` Ralf Baechle
2002-07-31 11:34 ` Maciej W. Rozycki
2002-07-31 20:31 ` Ralf Baechle
2002-08-01 15:24 ` Maciej W. Rozycki
2002-08-01 17:18 ` Ralf Baechle
2002-08-02 9:32 ` Carsten Langgaard
2002-08-02 11:05 ` Ralf Baechle [this message]
2002-08-02 11:09 ` Carsten Langgaard
2002-07-30 12:39 ` Kevin D. Kissell
2002-07-30 12:39 ` Kevin D. Kissell
2002-07-31 2:05 ` Ralf Baechle
2002-07-31 7:28 ` Kevin D. Kissell
2002-07-31 7:28 ` Kevin D. Kissell
2002-07-31 11:49 ` Maciej W. Rozycki
2002-07-31 18:22 ` Ralf Baechle
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=20020802130552.C27824@dea.linux-mips.net \
--to=ralf@oss.sgi.com \
--cc=carstenl@mips.com \
--cc=linux-mips@fnet.fr \
--cc=linux-mips@oss.sgi.com \
--cc=macro@ds2.pg.gda.pl \
/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.