From: Andrew Morton <akpm@linux-foundation.org>
Date: Mon, 30 Apr 2007 14:54:14 -0700

On Mon, 30 Apr 2007 22:36:27 +0100 (BST)
Mark Fortescue [off-list ref] wrote:

quoted

Hi all,

I have tracked down a failure to successfully load/run the init task on my 
Sparcstation 1 clone (SS1) and Sparcstation 2 (SS2), sparc32 sun4c 
systems, to a patch:

   commit 1a44e149084d772a1bcf4cdbdde8a013a8a1cfde.
   [PATCH] .text page fault SMP scalability optimization

Removing this patch fixes the issue and allows me to use kernels later 
than v2.5.14. (tested using linux-2.6.20.9).

Given the comment provided by the git bisect, backing out this patch will 
probably have undesirable conseqnences for other platforms (especially 
powerpc64) so, if an architecture independent solution is not available, 
some/all of the code in handle_pte_fault() in mm/memory.c will need be to 
made architecture dependent.

I am not sufficiently familear with the how the SS1/SS2 mmu works and how 
the linux memory management system works to understand why this patch 
prevents my sun4c SS1/SS2 systems from working.

Advice and help on the approch to take and any code changes regarding this 
issue would be most welcome.

Interesting - thanks for working that out.  Let's keep linux-mm on cc please.

You can't elide the update_mmu_cache() call on sun4c because that will
miss some critical TLB setups which are performed there.

The sun4c TLB has two tiers of entries:

1) segment maps, these hold ptes for a range of addresses
2) ptes, mapped into segment maps

update_mmu_cache() on sun4c take care of allocating and setting
up the segment maps, so if you elide the call this never happens
and we fault forever.