From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32494 invoked by alias); 27 Oct 2007 01:31:25 -0000 Received: (qmail 32478 invoked by uid 22791); 27 Oct 2007 01:31:24 -0000 X-Spam-Check-By: sourceware.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 27 Oct 2007 01:31:21 +0000 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.13.8/8.13.8) with ESMTP id l9R1UtWv024275; Fri, 26 Oct 2007 20:30:56 -0500 Subject: Re: Apparent kernel bug with GDB on ppc405 From: Benjamin Herrenschmidt Reply-To: benh@kernel.crashing.org To: Matt Mackall Cc: Grant Likely , gdb@sourceware.org, linuxppc-embedded@ozlabs.org In-Reply-To: <20071026144134.GW19691@waste.org> References: <20071024194640.GB19691@waste.org> <1193363202.7018.36.camel@pasglop> <1193369005.7018.46.camel@pasglop> <20071026144134.GW19691@waste.org> Content-Type: text/plain Date: Sat, 27 Oct 2007 01:31:00 -0000 Message-Id: <1193448653.18243.9.camel@pasglop> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00281.txt.bz2 On Fri, 2007-10-26 at 09:41 -0500, Matt Mackall wrote: > On Fri, Oct 26, 2007 at 01:23:25PM +1000, Benjamin Herrenschmidt > wrote: > > > > > This is actually 405. Does that have the same issue? > > > > hrm... I don't remember :-) There -is- something fishy about the > icache > > on 405 but I don't remember for sure. Try sticking an iccci in there > and > > tell us if that helps. > > I did. I stuck an iccci -and- a dccci loop in. I threw in the tlbia > when I ran out of other ideas. And the tlbia + existing > flush_icache_range appears to be sufficient (tested on a non-trivial > app). > > According to my docs, the 405fx's icache is virtually > indexed/physically mapped, while the dcache is phys/phys. I think there is a bug in the 40x/44x support at this stage, it only doing invalidations for the current PID. That means that a process trying to invalidate TLB entries of another address space will fail to do so ... oops. That can be fixed by adding a pid argument to to _tlbie, and using it in the assembly. In the 40x case, probably by switching SPRN_PID to that and then back, in the 44x case, by using that value instead of SPRN_PID for the MMUCR register. It's part of a patche I have around taking dirt that rework signficantly the 44x (though not the 40x yet) TLB handling, cleaning things and fixing bugs (such as this one, I remember it now). I need to spend a bit of time to clean it up, remove some experimental stuff from it, and submit it. I'll try to do that early next week, and maybe come up with a fix for that specific bug today or tomorrow. Ben.