Re: possible Malta 4Kc cache problem ...

["Kevin D. Kissell" <kevink@mips.com>]

> > I think that Carsten's patch (or equivalent) should certainly be
> > applied to the main tree, but I wonder how relevant it is here.
> > The flushes associated with trampolines don't do indexed
> > flush operations, do they?
> 
> True, but are we sure that it's the trampoline that's the problem here?

Jun Sun seemed to think it was. To quote his original message

"The problem involves emulating a "lw" instruction in cp1 branch delay
 slot, which needs to  set up trampoline in user stack.  The net effect
 looks as if the icache line or dcache line is not flushed properly."

I don't know what his actual observations were that lead to that
conclusion, but the resemblence to what was reported under LTP
with the pre-break_cow()-patch kernel intrigues me.

So, I repeat... 
> > ...I don't have a 4Kc platform at
> > hand, but I think that Jun Sun *may* have found a better
> > way to get at the other problem I was referring to, which
> > we rarely saw on non-superscalar issue CPUs, and which
> > seems to be masked by an otherwise superfluous flush of
> > the Icache that was added to the latest versions of break_cow().
> > If Carsten's patch solves the problem without applying that
> > other update, I'd want to know that.  If it *doesn't*, I'd be
> > really interested to know if, by any chance, there is a
> > corelation between failures of Jun Sun's test and the incidence
> > of page faults on the CACHE op in protected_icache_invalidate_line().
> >
> >             Kevin K.