Could you please tell us, which 4Kc you are running on ? What are the cache configuration (size, number of ways) ? Are you running on the latest kernel sources from the CVS tree ? Have you tried the mips32_cache.h file I send and/or have you tried the kernel from the ftp.mips.com FTP server ? Many question at the same time ;-) /Carsten Daniel Jacobowitz wrote: > 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
