This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Apparent kernel bug with GDB on ppc405
- From: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>
- To: Matt Mackall <mpm at selenic dot com>
- Cc: linuxppc-embedded at ozlabs dot org, gdb at sourceware dot org
- Date: Fri, 26 Oct 2007 11:46:42 +1000
- Subject: Re: Apparent kernel bug with GDB on ppc405
- References: <20071024194640.GB19691@waste.org>
- Reply-to: benh at kernel dot crashing dot org
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.
Try sticking an iccci in there and let me know if that helps.
Ben