My cpu PRID: 0x2732, runs at freq 133x2MHz
disassemble code before patch:
ffffffff8010f2fc <r4k_flush_cache_sigtramp>: ffffffff8010f2fc: 3c03802c lui v1,0x802c ffffffff8010f300: 246367ec addiu v1,v1,26604 ffffffff8010f304: 94620010 lhu v0,16(v1) ffffffff8010f308: 94650000 lhu a1,0(v1) ffffffff8010f30c: 00021023 negu v0,v0 ffffffff8010f310: 00821024 and v0,a0,v0 ffffffff8010f314: bc550000 cache 0x15,0(v0) ffffffff8010f318: 00052823 negu a1,a1 ffffffff8010f31c: 00852024 and a0,a0,a1 ffffffff8010f320: bc900000 cache 0x10,0(a0) ffffffff8010f324: 03e00008 jr ra ffffffff8010f328: 00000000 nop
disassemble code after patch: ffffffff8010ceb0 <r4k_flush_cache_sigtramp>: ffffffff8010ceb0: 3c03802f lui v1,0x802f ffffffff8010ceb4: 2463e3ac addiu v1,v1,-7252 ffffffff8010ceb8: 94620010 lhu v0,16(v1) ffffffff8010cebc: 94650000 lhu a1,0(v1) ffffffff8010cec0: 00021023 negu v0,v0 ffffffff8010cec4: 00821024 and v0,a0,v0 ffffffff8010cec8: bc550000 cache 0x15,0(v0) ffffffff8010cecc: 0000000f sync ffffffff8010ced0: 00052823 negu a1,a1 ffffffff8010ced4: 00852024 and a0,a0,a1 ffffffff8010ced8: bc900000 cache 0x10,0(a0) ffffffff8010cedc: 03e00008 jr ra ffffffff8010cee0: 00000000 nop
We do have more than one set of ev64240 and RM7k cpu£¬but it will take some time for
me to get another one for test. I will tell you the result once i do it.
Thank you.
Adam Kiepul wrote:
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 thecould there be an errata explaining Fuxin's findings?
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.
Fuxin, what version are you running?
Ralf
