From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fed1rmmtao07.cox.net (fed1rmmtao07.cox.net [68.230.241.32]) by ozlabs.org (Postfix) with ESMTP id 1132F6867C for ; Tue, 8 Nov 2005 05:22:13 +1100 (EST) Date: Mon, 7 Nov 2005 11:22:11 -0700 From: Tom Rini To: Joakim Tjernlund Message-ID: <20051107182211.GI3839@smtp.west.cox.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Cc: Dan Malek , linuxppc-embedded@ozlabs.org, gtolstolytkin@ru.mvista.com Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, Nov 07, 2005 at 07:14:15PM +0100, Joakim Tjernlund wrote: > > -----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: > > > Joakim! > > > > > > On Mon, Nov 07, 2005 at 03:32:52PM +0100, Joakim Tjernlund wrote: > > > > Hi Marcelo > > > > > > > > [SNIP] > > > > > 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. > > > > > > > > > > The bug is that the zeroed TLB is not invalidated (the > > same reason > > > > > for the "dcbst" misbehaviour), resulting in infinite > > TLBError faults. > > > > > > > > > > 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 > > > > 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 > > > changes in our v2.4 tree and never experienced such problem. > > > > > > It should be pretty easy to hit it right? (instruction > > pagefaults should > > > fail). > > > > > > Grigori, Tom, can you enlight us about the issue on the URL > > above. How > > > 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/