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: Wed, 24 Mar 2010 00:31:43 +0100
Cc: linux-mips@linux-mips.org
In-reply-to: <20100323010403.GT4554@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20100321110241.GA25569@Chamillionaire.breakpoint.cc> <20100322145918.GR4554@linux-mips.org> <20100323010403.GT4554@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.20 (2009-08-17)
On Tue, Mar 23, 2010 at 02:04:03AM +0100, Ralf Baechle 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.

I've committed two more patches to fix the M3 errata handler.  I don't
have hardware affected by this CPU bug so I had to test the code with
a little hack on another system.  So tests on Swarm boards, especially
with SOC versions older than C0 would be appreciated.  After I receive
positive feedback I will cherrypick the fixes into the stable branches.

  Ralf

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