Apparent kernel bug with GDB on ppc405

Benjamin Herrenschmidt benh at kernel.crashing.org
Sat Oct 27 11:30:53 EST 2007


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.





More information about the Linuxppc-embedded mailing list