On Tue, 18 Nov 2014, Leonid Yegoshin wrote: > > I repeat, there is no use in the current kernel of the MIPS_CACHE_VTAG > > flag for the D-cache, there's no single piece of code throughout the > > kernel that would check the presence of this flag once it has been set > > and this erratum workaround piece is the only place where the flag is > > set for the D-cache. The flag is completely ignored for the D-cache and > > the only existing uses of this flag are for the I-cache. > > Please look into http://patchwork.linux-mips.org/patch/8459/ > Look into cpu_has_vtag_dcache usage. > It is a second or 2rd (or 3rd etc) attempt to put using of that information > upstream for last 1.5 year. That doesn't appear to have anything to do with ptrace(2) and cache-coherency issues seen around software breakpoints, and the buggy 74K is the only system of all that we have that shows that problem. And the problem goes away with my fix. So perhaps MIPS_CACHE_ALIASES is actually needed here, or maybe a more lightweight alternative fix, but an item that addresses HIGHMEM support is clearly irrelevant. This is easily reproduced by running the GDB test suite, I'd have to double-check old logs from before my fix, but it may be more prominent with MIPS16 code for some reason. So I suggest that you run the GDB test suite, for the MIPS16 multilib and on the upstream kernel as it is, on a good and a bad 74K processor and compare results, and then see if any of your outstanding fixes makes any changes. The symptoms are either spurious SIGTRAP signals delivered (if a stale breakpoint remaining in the I-cache was hit) or breakpoint misses (if a stale original instruction remaining in the I-cache was executed). Please note that these failures are not extensive, there'll be a couple across the whole test suite run (several thousands tests) -- it's not like software breakpoints are unusable. > > Leonid, I spent several hours chasing cache coherency issues util I > > realised the workaround in its current form does not do anything, so > > unless you propose an alternative fix, this change is the only way known > > to bring systems affected to sanity. > > You may ask me, I work last 3 years in MIPS (now IMG) on it and did a most of > coherency fixes all that time. Well, I-cache coherency issues around ptrace(2), specifically the PTRACE_POKETEXT request, appear to persist -- how often do you verify your code by getting the GDB test suite run on it (e.g. by your toolchain team)? Which so far is I believe the best way to trigger any I-cache coherency issues there, and I remember still seeing issues with software breakpoints in heavily threaded code across all processors I could check with (and GDB's Remote Serial Protocol logs indicated they were correctly propagated down to ptrace(2), so it was all up to the kernel to sort out), at least a 24Kc, a 74Kc and an M14Kc. Please note that I test using gdbserver with GDB connecting remotely from another system, I don't normally run native testing on these boards, they are too weak for that. It is an important detail as native testing implies much higher cache pressure (gdbserver is a lightweight agent while GDB itself is a large blob) where incoherent cache lines are much more likely to cure by themselves in the course of line replacement on cache fills. Maciej
