On Tue, Feb 03, 2004 at 04:30:33PM +0100, Maciej W. Rozycki wrote: > > > How do we assure tails of interrupt handlers don't trigger the errata? > > > > The problem can only be triggered if instructions surrounding the > > cacheop use the dcache; exceptions such as interrupts are not relevant. > > Why? How is an "eret" with its preceding instructions different to other > instructions? There may be a data cache miss soon before an "eret" and > the response buffer may contain data. And you may get an exeption right > before a CACHE instruction. > > > Which I'm really happy about. Disabling interrupts is a problem in cases > > were we can't avoid page faults. > > I worry this is unsafe and given the unlikeliness of getting an interrupt > just between the dummy load and the CACHE instruction, this change creates > a completely obscure bug that'll bite unpredictably and possibly > invisibly, just corrupting data, every once and then. But the situation > may be not that bad -- what does exactly happen when the erratum gets > triggered? Missing a Create_Dirty_Excl_D operation should itself be a > performance hit only, but given the problems reported I suppose data gets > corrupted, either in the cache or in the main memory. Am I right? I don't know details but since the person who answered my question was directly working on the CPU design I have to take that as authoritative information and after all, the systems seems stable. Daring a guess, the CPU restarts the pipeline following an eret therefore instructions preceeding the eret can't cause the problem. Ralf
