On Wed, Dec 04, 2002 at 06:08:22PM +0100, Kevin D. Kissell wrote: > > > 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. Here's some of the actual observations: if you single-step over the bc1t instruction, then it comes out as you'd expect; the load in the delay slot was executed. Even if you breakpoint in the general vicinity and then continue. But if you breakpoint _after_ the instruction, it is evident that the load did not occur as expected. > 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. > > > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
