From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> Date: Mon, 30 Apr 2007 14:54:14 -0700 > On Mon, 30 Apr 2007 22:36:27 +0100 (BST) > Mark Fortescue <mark@xxxxxxxxxxxxxxxxxx> wrote: > > > 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. - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
