[Fwd: [Linuxppc-dev] Re: [Linuxppc-cvs64] CVS: linuxppc64_2_4/arch/ppc64/kernel head.S,1.32.6.1,1.32.6.2]

[Dave Engebretsen]

Anton,

I was working on an explaination for this but you beat me to the punch
with the question ...

Fundamentally, the problem is that the OS does not have any control over
the ERAT and it may be invalidated at any point in time.  What we found
is that when castouts from the SLB start to occur and we get into this
code path with some frequency, we end up in a state where the SLB is
full, and there are additional translations in the ERAT for kernel
address which are not in the SLB.  This set up a situation where we were
preparing to rfi (do_signal_ret) and were in the crital section where
SRRO/1 were loaded when the ERAT entry for the stack gets invalidated
from under us (presumably via a tlbie from another processor).  We then
take an SLB fault, where the handler proceeds to clobber SRR0/1, and
things fall apart.

Given that this should be a generally low use path (SLB castout), I
don't expect there would be any performance impact.

Dave.
-------------- next part --------------
An embedded message was scrubbed...
From: Anton Blanchard <anton at au.ibm.com>
Subject: [Linuxppc-dev] Re: [Linuxppc-cvs64] CVS: linuxppc64_2_4/arch/ppc64/kernel head.S,1.32.6.1,1.32.6.2
Date: Fri, 21 Jun 2002 14:35:44 -0500
Size: 1009
Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20020621/6a669536/attachment.mht