RE: [PATCH 2.6.14] mm: 8xx MM fix for

-----Original Message-----
From: Tom Rini [mailto:trini@kernel.crashing.org]=20
Sent: 07 November 2005 16:52
To: Marcelo Tosatti
Cc: Joakim Tjernlund; Pantelis Antoniou; Dan Malek;=20
linuxppc-embedded@ozlabs.org; gtolstolytkin@ru.mvista.com
Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
=20
On Mon, Nov 07, 2005 at 08:16:18AM -0200, Marcelo Tosatti wrote:

quoted

Joakim!
=20
On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim Tjernlund wrote:

quoted

Hi Marcelo
=20
[SNIP]=20

quoted

The root of the problem are the changes against the 8xx TLB=20
handlers introduced
during v2.6. What happens is the TLBMiss handlers load the=20
zeroed pte into
the TLB, causing the TLBError handler to be invoked (thats=20
two TLB faults per=20
pagefault), which then jumps to the generic MM code to=20

setup the pte.

quoted

quoted

quoted

=20
The bug is that the zeroed TLB is not invalidated (the=20

same reason

quoted

quoted

quoted

for the "dcbst" misbehaviour), resulting in infinite=20

TLBError faults.

quoted

quoted

quoted

=20
Dan, I wonder why we just don't go back to v2.4 behaviour.

=20
This is one reason why it is the way it is:
=20

http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016382.html

quoted

quoted

This details are little fuzzy ATM, but I think the reason for the
current
impl. was only that it was less intrusive to impl.

=20
Ah, I see. I wonder if the bug is processor specific: we=20

don't have such

quoted

changes in our v2.4 tree and never experienced such problem.
=20
It should be pretty easy to hit it right? (instruction=20

pagefaults should

quoted

fail).
=20
Grigori, Tom, can you enlight us about the issue on the URL=20

above. How

quoted

can it be triggered?

=20
So after looking at the code in 2.6.14 and current git, I think the
above URL isn't relevant, unless there was a change I missed (which
could totally be possible) that reverted the patch there and=20
fixed that
issue in a different manner.  But since I didn't figure that=20
out until I
had finished researching it again:

I wasn't clear enough. What I meant was that the above patch made me
think and
the result was that I came up with a simpler fix, the "two exception"
fix that
is in current kernels. See
http://linux.bkbits.net:8080/linux-2.6/diffs/arch/ppc/kernel/head_8xx.S@
1.19?nav=3Dindex.html|src/.|src/arch|src/arch/ppc|src/arch/ppc/kernel|his=
t
/arch/ppc/kernel/head_8xx.S
It appears this fix has some other issues :(

How do the other ppc arches do? I am guessing that they don't double
fault, but bails
out to do_page_fault from the TLB Miss handler, like 8xx used to do.

=20
Switching hats for a minute, this came from a bug a customer of
MontaVista found, so I can't give out the testcase :(
=20
To repeat what Joakim said back then:
"I think I have figured this out. The first TLB misses that happen at
app startup is Data TLB misses. These will then hit the NULL L1 entry
and end up in do_page_fault() which will populate the L1=20
entry. But when
you have a very large app that spans more than one L1 entry (16 MB I
think) it may happen that you will have I-TLB Miss first one of the L1
entrys which will make the I-TLB handler bail out to=20
do_page_fault() and
the app craches(SEGV)."

This still stands I think.

=20
Looking at the patch again, what I don't see is why I talk=20
about fudging
I-TLB Miss at 0x400 when it's I-TLB Error we fudge at being there, but
then get hung up that there can be a slight diff between the=20
two ("This
is because we check bit 4 of SRR1 in both cases, but in the case of an
I-TLB Miss, this bit is always set, and it only indicates a protection
fault on an I-TLB Error.") so instead of 0x1300 jumping to the handler
at 0x400, we treat it like a regular exception so we know=20
where we came
from, and perhaps missed fixing a case somewhere?

Didn't look into this part of your patch, sorry.

 Jocke

On Mon, Nov 07, 2005 at 07:14:15PM +0100, Joakim Tjernlund wrote:

quoted

-----Original Message-----
From: Tom Rini [mailto:trini@kernel.crashing.org] 
Sent: 07 November 2005 16:52
To: Marcelo Tosatti
Cc: Joakim Tjernlund; Pantelis Antoniou; Dan Malek; 
linuxppc-embedded@ozlabs.org; gtolstolytkin@ru.mvista.com
Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for

On Mon, Nov 07, 2005 at 08:16:18AM -0200, Marcelo Tosatti wrote:

quoted

Joakim!

On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim Tjernlund wrote:

quoted

Hi Marcelo

[SNIP] 

quoted

The root of the problem are the changes against the 8xx TLB 
handlers introduced
during v2.6. What happens is the TLBMiss handlers load the 
zeroed pte into
the TLB, causing the TLBError handler to be invoked (thats 
two TLB faults per 
pagefault), which then jumps to the generic MM code to 

setup the pte.

quoted

quoted

quoted

The bug is that the zeroed TLB is not invalidated (the 

same reason

quoted

quoted

quoted

for the "dcbst" misbehaviour), resulting in infinite 

TLBError faults.

quoted

quoted

quoted

Dan, I wonder why we just don't go back to v2.4 behaviour.

This is one reason why it is the way it is:

http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016382.html

quoted

quoted

This details are little fuzzy ATM, but I think the reason for the
current
impl. was only that it was less intrusive to impl.

Ah, I see. I wonder if the bug is processor specific: we 

don't have such

quoted

changes in our v2.4 tree and never experienced such problem.

It should be pretty easy to hit it right? (instruction 

pagefaults should

quoted

fail).

Grigori, Tom, can you enlight us about the issue on the URL 

above. How

quoted

can it be triggered?

So after looking at the code in 2.6.14 and current git, I think the
above URL isn't relevant, unless there was a change I missed (which
could totally be possible) that reverted the patch there and 
fixed that
issue in a different manner.  But since I didn't figure that 
out until I
had finished researching it again:

I wasn't clear enough. What I meant was that the above patch made me
think and
the result was that I came up with a simpler fix, the "two exception"
fix that
is in current kernels. See
http://linux.bkbits.net:8080/linux-2.6/diffs/arch/ppc/kernel/head_8xx.S@
1.19?nav=index.html|src/.|src/arch|src/arch/ppc|src/arch/ppc/kernel|hist
/arch/ppc/kernel/head_8xx.S
It appears this fix has some other issues :(

How do the other ppc arches do? I am guessing that they don't double
fault, but bails
out to do_page_fault from the TLB Miss handler, like 8xx used to do.

Assuming Dan doesn't come up with a more simple & better fix, maybe we
should go back to the original patch I made?

-- 
Tom Rini
http://gate.crashing.org/~trini/

On Nov 7, 2005, at 1:22 PM, Tom Rini wrote:

Assuming Dan doesn't come up with a more simple & better fix, maybe we
should go back to the original patch I made?

I'm working on it.  It'll look more like 2.4.

Thanks.

	-- Dan