linux-mips
[Top] [All Lists]

Re: [PATCH] mips/mm: fix module support on SiByte

To: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Subject: Re: [PATCH] mips/mm: fix module support on SiByte
From: Ralf Baechle <ralf@linux-mips.org>
Date: Tue, 23 Mar 2010 02:04:03 +0100
Cc: linux-mips@linux-mips.org
In-reply-to: <20100322145918.GR4554@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20100321110241.GA25569@Chamillionaire.breakpoint.cc> <20100322145918.GR4554@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.20 (2009-08-17)
On Mon, Mar 22, 2010 at 03:59:18PM +0100, Ralf Baechle wrote:

> On Sun, Mar 21, 2010 at 12:02:41PM +0100, Sebastian Andrzej Siewior wrote:
> 
> > Since commit 656be92f aka "Load modules to CKSEG0 if
> > CONFIG_BUILD_ELF64=n" module support is broken on 64bit. Since then
> > modules arr loaded into 32bit compat adresses which are sign extended
> > 64bit addresses. The SiByte war handler was not updated and those
> > addresses were not recognized by the TLB hadling.
> > This patch fixes this by shifting away the upper bits including the R
> > and Fill bits. Now we compare VPN2 of C0_ENTRYHI against the matching
> > bits at C0_BADVADDR.
> 
> Good detective work but I'll check against the errata documents (which
> are non-public, sigh ...) before applying your patch.
> 
> The M3 workaround in which you found this bug is currently applied to all
> Sibyte SB1 cores while probably only a relativly small number of the cores
> in circulation are affected so we should refine the workaround to be only
> applied if the System Revision Register indicates a system older than
> revision C0.  This could get rid of 6 instructions which according to the
> usual rule of thumb would result in a speedup of ~ 3%.

I've just committed a patch on the master branch to handle this issue.
On cores that are not affected by the M3 bug this also fixes the module
issue.

  Ralf

<Prev in Thread] Current Thread [Next in Thread>