Apparent kernel bug with GDB on ppc405
Grant Likely
grant.likely at secretlab.ca
Fri Oct 26 12:45:24 EST 2007
On 10/25/07, Benjamin Herrenschmidt <benh at kernel.crashing.org> 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 at secretlab.ca
(403) 399-0195
More information about the Linuxppc-embedded
mailing list