On Wed, Aug 06, 2003 at 08:52:46PM +0800, Fuxin Zhang wrote: > I am not sure. It is stardard X distribution from debian-woody. Fairly > easy to reproduce,just move the mouse > around and click here and there then it would die. Will check this > later,but I think such a giant as Xserver won't fork frequently. The scenario I was describing was just how we did originally discover the bug. Supposedly that was fixed but your register dump and dissassembly show the exact fingerprint of that old problem, so I though I should describe it in the hope it's going to help you. > If the new process touch the cow page first,shouldn't it get a new page > and leave the original page for parent? > If so,the parent should be able to see the trampoline content from > icache anyway(either L2 or memory should > have the value),though the child may not? RM7000 has a physically indexed cache. That means if the copy of the page wasn't explicitly or implicitly written back to L2 the process whichever ends up with the copy of the page might fetch stale instructions from memory - boom. > > not been flushed proplerly in the previous step, thereby failing to > > execute the trampoline - crash. > > > RM7000 has 16k 4-way set-associated primary caches,which are supposed to > have no cache aliasing problem The described scenario is not an aliasing problem; it's the case where the copy of the cow page hasn't properly been flushed at all. When we isolated the bug was that neither flush_page_to_ram() nor flush_cache_page() were flushing the cache. I suspect your case must be something fairly similar. Ralf
