Hi Fuxin, Could you please provide me with the _original_ Kernel code disassembly snippet around the point where your SYNC patch applies? Also, can you check what RM7000 part revision is on your board? You can find it out by reading the PrID register. I will check if there is an erratum that the code could trigger. By the way, are you aware of any other ev64240 board that would exhibit the same behavior? I would be quite careful drawing any conclusions at the moment since we can not preclude the possibility that it is simply a "bad CPU on the board" case. Please note that the SYNC instruction changes a lot in the manner things physically happen in the CPU so it can often mask off various problems, such as a bad part. Thank you, Adam -----Original Message----- From: Fuxin Zhang [mailto:fxzhang@ict.ac.cn] Sent: Thursday, July 31, 2003 9:59 PM To: Ralf Baechle Cc: Adam Kiepul; MAKE FUN PRANK CALLS Subject: Re: RM7k cache_flush_sigtramp I am using a slightly modified 2.4.21-pre4,based on cvs of early this month(?). We have merged with latest cvs, I will run it and report the result tonight. Ralf Baechle wrote: >Adam, > >On Fri, Aug 01, 2003 at 08:40:14AM +0800, Fuxin Zhang wrote: > > > >>Current linux code does exactly this. But I was seeing all kinds of >>faults occuring around the >>sigreturn point on the stack without a sync? And a sync does greatly >>improve the stablity. >> >> >> >>>The ordering does matter however since the Hit_Invalidate_I makes sure the >>>write buffer is flushed. >>> >>> > >could there be an errata explaining Fuxin's findings? > >Fuxin, what version are you running? > > Ralf > > > >
