From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20605 invoked by alias); 26 Oct 2007 02:45:32 -0000 Received: (qmail 20595 invoked by uid 22791); 26 Oct 2007 02:45:31 -0000 X-Spam-Check-By: sourceware.org Received: from wa-out-1112.google.com (HELO wa-out-1112.google.com) (209.85.146.179) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 26 Oct 2007 02:45:28 +0000 Received: by wa-out-1112.google.com with SMTP id l35so980309waf for ; Thu, 25 Oct 2007 19:45:25 -0700 (PDT) Received: by 10.114.94.1 with SMTP id r1mr2884418wab.1193366725037; Thu, 25 Oct 2007 19:45:25 -0700 (PDT) Received: by 10.115.90.6 with HTTP; Thu, 25 Oct 2007 19:45:24 -0700 (PDT) Message-ID: Date: Fri, 26 Oct 2007 02:45:00 -0000 From: "Grant Likely" To: benh@kernel.crashing.org Subject: Re: Apparent kernel bug with GDB on ppc405 Cc: "Matt Mackall" , gdb@sourceware.org, linuxppc-embedded@ozlabs.org In-Reply-To: <1193363202.7018.36.camel@pasglop> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071024194640.GB19691@waste.org> <1193363202.7018.36.camel@pasglop> X-Google-Sender-Auth: 872236132b76f9af 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/msg00254.txt.bz2 On 10/25/07, Benjamin Herrenschmidt wrote: > > On Wed, 2007-10-24 at 14:46 -0500, Matt Mackall wrote: > > > > My first suspicion was a dcache/icache coherency issue in > > copy_to_user_page, so I added flush_dcache_icache_page(page) here to > > no avail. On closer inspection, it looks like both icache and dcache > > are already being flushed by flush_icache_user_range(). > > > > Adding printk(".") (or any printk) in this function here fixes things > > (serial console at 115k), while printk("") and udelay(100) do not. > > Which still suggests an icache bug..? > > > > Any suggestions? > > I think you're hitting a known bug of 44x support. Those CPUs have a > crazy virtually tagged icache and the kernel doesn't deal with it at all > (pretty much...). We just are lucky things generally work :-) > > That means among other things that flush_icache_* will not work because > they kmap pages and use that mapping. The only way to flush icache user > pages with 44x is to actually flush with the user virtual address > (meaning you have to be in the current context, and you probably need to > have a TLB entry there... yuck)... or just blow the whole icache away. This is actually 405. Does that have the same issue? Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. grant.likely@secretlab.ca (403) 399-0195