This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Apparent kernel bug with GDB on ppc405


On 10/25/07, Benjamin Herrenschmidt <benh@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@secretlab.ca
(403) 399-0195


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]