[Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1

[Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 3931 bytes --]

Hi!

I've started looking at mips(el) again, here's some first status report
for 2.4.19-rc1. Machine is a R4600 Indy.

1st boot:
	SIGBUS for e2fsck, freeze after

2nd boot:
	Freeze somewhere during boot-up

3rd boot:
	Numerous messages like this:

		swap_free: Bad swap file entry 3c04881a
		swap_free: Bad swap offset entry 2484c500
	
	I think this is because swap has been activated during 2nd
	boot-up and some swap pages are marked as "used" (from previous
	boot-up) but aren't used...

	Then an Oops during ntpdate (or ntp?) startup:

ksymoops 2.4.5 on mips 2.4.16.  Options used
     -v /boot/vmlinux-2.4.19-rc1--00 (specified)
     -K (specified)
     -L (specified)
     -o /lib/modules/2.4.16/ (default)
     -m /boot/System.map-2.4.19-rc1--00 (specified)

No modules in ksyms, skipping objects
$0 : 00000000 3000cc02 c0006000 c0006622 00031180 88185d98 00031180 00000000
$8 : 88185d98 07200720 07200720 07200720 07200720 00000000 881b5cc0 07200720
$16: 8816fb5c 00000000 00031180 00121000 0030a000 8bb95244 2b0f6000 00005000
$24: 00000000 00000007                   8bb32000 8bb33df8 00000000 88040984
epc  : 88016cd8    Not tainted
Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000
Status: 3000cc03
Cause : 00008010
Process mount (pid: 20, stackpage=8bb32000)
Stack: 8813c7e4 8813c780 24a5cb60 00000010 88040984 883bc76c 8803258c 8803244c
       2acf6000 2acfb000 8816fb5c ffffffbf 00000040 88030a50 8bb95300 2acf6000
       00000000 00000000 00000001 00005000 2acfb000 00000000 2b0f6000 8bb95244
       8816f300 8bb9d2b0 8bb973d4 880393e0 8816f31c 8bb95360 8bb95360 2acf5b6c
       8bb33ebc 8bb33eb8 8bb33ec0 8bb95300 00000073 2acf6000 8816f300 00000000
       00005000 ...
Code: 00000000  bc600000  bc600020 <bc600040> bc600060  bc600080  bc6000a0  bc6000c0  bc6000e0 


>>$1; 3000cc02 Before first symbol
>>$2; c0006000 <END_OF_CODE+37e4edb0/????>
>>$3; c0006622 <END_OF_CODE+37e4f3d2/????>
>>$4; 00031180 Before first symbol
>>$5; 88185d98 <swap_info+0/708>
>>$6; 00031180 Before first symbol
>>$8; 88185d98 <swap_info+0/708>
>>$9; 07200720 Before first symbol
>>$10; 07200720 Before first symbol
>>$11; 07200720 Before first symbol
>>$12; 07200720 Before first symbol
>>$14; 881b5cc0 <font_data+0/fc>
>>$15; 07200720 Before first symbol
>>$16; 8816fb5c <netfilter_init+10/48>
>>$18; 00031180 Before first symbol
>>$19; 00121000 Before first symbol
>>$20; 0030a000 Before first symbol
>>$21; 8bb95244 <END_OF_CODE+39ddff4/????>
>>$22; 2b0f6000 Before first symbol
>>$23; 00005000 Before first symbol
>>$26; 8bb32000 <END_OF_CODE+397adb0/????>
>>$27; 8bb33df8 <END_OF_CODE+397cba8/????>
>>$29; 88040984 <free_swap_and_cache+20/114>

>>PC;  88016cd8 <r4k_flush_cache_range_d32i32+dc/16c>   <=====

Code;  88016ccc <r4k_flush_cache_range_d32i32+d0/16c>
00000000 <_PC>:
Code;  88016ccc <r4k_flush_cache_range_d32i32+d0/16c>
   0:   00000000  nop
Code;  88016cd0 <r4k_flush_cache_range_d32i32+d4/16c>
   4:   bc600000  0xbc600000
Code;  88016cd4 <r4k_flush_cache_range_d32i32+d8/16c>
   8:   bc600020  0xbc600020
Code;  88016cd8 <r4k_flush_cache_range_d32i32+dc/16c>   <=====
   c:   bc600040  0xbc600040   <=====
Code;  88016cdc <r4k_flush_cache_range_d32i32+e0/16c>
  10:   bc600060  0xbc600060
Code;  88016ce0 <r4k_flush_cache_range_d32i32+e4/16c>
  14:   bc600080  0xbc600080
Code;  88016ce4 <r4k_flush_cache_range_d32i32+e8/16c>
  18:   bc6000a0  0xbc6000a0
Code;  88016ce8 <r4k_flush_cache_range_d32i32+ec/16c>
  1c:   bc6000c0  0xbc6000c0
Code;  88016cec <r4k_flush_cache_range_d32i32+f0/16c>
  20:   bc6000e0  0xbc6000e0


4th boot:
	Using 2.4.16 (from Debian installer) and everything is fine
	again. Cache issues again?


MfG, JBG

-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 653 bytes --]

On Sun, 2002-06-30 00:05:13 +0200, Jan-Benedict Glaw <jbglaw@lug-owl.de>
wrote in message <20020629220513.GC17216@lug-owl.de>:
[...]
>   10:   bc600060  0xbc600060
> Code;  88016ce0 <r4k_flush_cache_range_d32i32+e4/16c>
>   14:   bc600080  0xbc600080

Well, I've bulid the same kernel with CONFIG_MIPS_UNCACHED and the box
is running^Wsnailing fine with it. I'm experiencing a little peformance
drop (100 BogoMips -> 2.79 BogoMips), but it comes up in finite time:-)

MfG, JBG

-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]

On Sun, 2002-06-30 19:47:17 +0200, Jan-Benedict Glaw <jbglaw@lug-owl.de>
wrote in message <20020630174717.GI17216@lug-owl.de>:
> On Sun, 2002-06-30 00:05:13 +0200, Jan-Benedict Glaw <jbglaw@lug-owl.de>
> wrote in message <20020629220513.GC17216@lug-owl.de>:
> [...]
> >   10:   bc600060  0xbc600060
> > Code;  88016ce0 <r4k_flush_cache_range_d32i32+e4/16c>
> >   14:   bc600080  0xbc600080
> 
> Well, I've bulid the same kernel with CONFIG_MIPS_UNCACHED and the box
> is running^Wsnailing fine with it. I'm experiencing a little peformance
> drop (100 BogoMips -> 2.79 BogoMips), but it comes up in finite time:-)

I've got some mail that support for my early R4600 (well, the bug fixes
for it...) got removed some time ago. I've looked at the diff of r1.3
(2.4.16) and r1.3.2.3 (2.4.19-rc1) and it seems that mostly calls to
__save_and_cli() and __restore_flags() got removed. Reading <asm/war.h>,
it really seems that this is causing my problem.

Ralf, would you accept a patch adding these lines again surrounded by
#ifdef CONFIG_CPU_R4X00 ... #endif /* CONFIG_CPU_R4X00 */? The current
state however isn't that fine: running uncached is no fun:-(

MfG, JBG

-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 2399 bytes --]

On Mon, 2002-07-01 11:13:22 +0200, Jan-Benedict Glaw <jbglaw@lug-owl.de>
wrote in message <20020701091321.GO17216@lug-owl.de>:
> On Sun, 2002-06-30 19:47:17 +0200, Jan-Benedict Glaw <jbglaw@lug-owl.de>
> wrote in message <20020630174717.GI17216@lug-owl.de>:
> > On Sun, 2002-06-30 00:05:13 +0200, Jan-Benedict Glaw <jbglaw@lug-owl.de>
> > wrote in message <20020629220513.GC17216@lug-owl.de>:
> > [...]
> > >   10:   bc600060  0xbc600060
> > > Code;  88016ce0 <r4k_flush_cache_range_d32i32+e4/16c>
> > >   14:   bc600080  0xbc600080
> > 
> > Well, I've bulid the same kernel with CONFIG_MIPS_UNCACHED and the box
> > is running^Wsnailing fine with it. I'm experiencing a little peformance
> > drop (100 BogoMips -> 2.79 BogoMips), but it comes up in finite time:-)
> 
> I've got some mail that support for my early R4600 (well, the bug fixes
> for it...) got removed some time ago. I've looked at the diff of r1.3
> (2.4.16) and r1.3.2.3 (2.4.19-rc1) and it seems that mostly calls to
> __save_and_cli() and __restore_flags() got removed. Reading <asm/war.h>,
> it really seems that this is causing my problem.
> 
> Ralf, would you accept a patch adding these lines again surrounded by
> #ifdef CONFIG_CPU_R4X00 ... #endif /* CONFIG_CPU_R4X00 */? The current
> state however isn't that fine: running uncached is no fun:-(

Okay, stupid idea. All these flush functions seem to be never called in
parallel or recursive, so if might be possible to have a global flags
variable and instead of always calling __save..() and __restore..(),
we bulid a pair of inline functions doing this. This wouldn't give
any penalty for !CONFIG_CPU_R4X00 and doesn't obscure the code so much
as all those #ifdef and #endif's would do... I'll test my suggestion
as fast as I reach my Indy again (is powered down at home...).

#ifdef CONFIG_CPU_R4X00
long buggy_r4600_flags;
#endif /* CONFIG_CPU_R4X00 */


static inline void
r4600_bug_start()
{
#ifdef CONFIG_CPU_R4x00
	__save_and_cli(buggy_r4600_flags);
#endif /* CONFIG_CPU_R4x00 */
	return;
}

static inline void
r4600_bug_finish()
{
#ifdef CONFIG_CPU_R4x00
	__restore_flags(buggy_r4600_flags);
#endif /* CONFIG_CPU_R4x00 */
	return;
}

MfG, JBG

-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1

[Maciej W. Rozycki]

On Mon, 1 Jul 2002, Jan-Benedict Glaw wrote:

> Okay, stupid idea. All these flush functions seem to be never called in
> parallel or recursive, so if might be possible to have a global flags
> variable and instead of always calling __save..() and __restore..(),
> we bulid a pair of inline functions doing this. This wouldn't give
> any penalty for !CONFIG_CPU_R4X00 and doesn't obscure the code so much
> as all those #ifdef and #endif's would do... I'll test my suggestion
> as fast as I reach my Indy again (is powered down at home...).

 Feel free to use the change privately.  Otherwise please code a real fix,
i.e. a set of buggy-R4600-specific functions, as CONFIG_CPU_R4X00 means
other processors as well, e.g. R4000 or R4400 which are fine here. 

 Actually blocking interrupts for over 0.01s as it used to be done is
unacceptable, even for buggy R4600 processors.  A fix should use a more
fine-grained interrupt masking. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 2074 bytes --]

On Mon, 2002-07-01 16:28:13 +0200, Maciej W. Rozycki <macro@ds2.pg.gda.pl>
wrote in message <Pine.GSO.3.96.1020701161009.7601E-100000@delta.ds2.pg.gda.pl>:
> On Mon, 1 Jul 2002, Jan-Benedict Glaw wrote:
> 
> > Okay, stupid idea. All these flush functions seem to be never called in
> > parallel or recursive, so if might be possible to have a global flags
> > variable and instead of always calling __save..() and __restore..(),
> > we bulid a pair of inline functions doing this. This wouldn't give
> > any penalty for !CONFIG_CPU_R4X00 and doesn't obscure the code so much
> > as all those #ifdef and #endif's would do... I'll test my suggestion
> > as fast as I reach my Indy again (is powered down at home...).
> 
>  Feel free to use the change privately.  Otherwise please code a real fix,
> i.e. a set of buggy-R4600-specific functions, as CONFIG_CPU_R4X00 means
> other processors as well, e.g. R4000 or R4400 which are fine here. 
> 
>  Actually blocking interrupts for over 0.01s as it used to be done is

Ah. That would explain the huge time drifts when the box is under
load...

> unacceptable, even for buggy R4600 processors.  A fix should use a more
> fine-grained interrupt masking. 

I'm just compiling with my proposed "fix". However, is it really a good
idea to duplicate so much code? Taking my 2nd idea (having inline
functions for saveing/restoring flags which are complete no-ops if
!CONFIG_CPU_R4X00), would it be much overhead for 4400 and 4000 to check
if we need to shuffle around flags and cut off interrupts?

I'm not really familiar w/ cache and interrupt handling/masking, and I
don't (yet) exactly know how to check for the buggy old R4600, but I
think I'll have to become an expert around that:-O

Any hints for online resources? I've had a look at idt.com (found it in
./asm-mips/war.h), but I cannot find the resources there:-(

MfG, JBG

-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Buggy R4600 support (was: [Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1)

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 11439 bytes --]

On Mon, 2002-07-01 16:28:13 +0200, Maciej W. Rozycki <macro@ds2.pg.gda.pl>
wrote in message <Pine.GSO.3.96.1020701161009.7601E-100000@delta.ds2.pg.gda.pl>:
> On Mon, 1 Jul 2002, Jan-Benedict Glaw wrote:
> > Okay, stupid idea. All these flush functions seem to be never called in
> > parallel or recursive, so if might be possible to have a global flags
> > variable and instead of always calling __save..() and __restore..(),
> > we bulid a pair of inline functions doing this. This wouldn't give
> > any penalty for !CONFIG_CPU_R4X00 and doesn't obscure the code so much
> > as all those #ifdef and #endif's would do... I'll test my suggestion
> > as fast as I reach my Indy again (is powered down at home...).
> 
>  Feel free to use the change privately.  Otherwise please code a real fix,
> i.e. a set of buggy-R4600-specific functions, as CONFIG_CPU_R4X00 means
> other processors as well, e.g. R4000 or R4400 which are fine here. 

Well, here's step 1. I've created inline functions for save/restore
flags and dropped them in where (as of 2.4.16) the calls where. My Indy
already runs (fine) with this. Now, there are two possibilities: I could
double all the cache handling functions for old R4600 and set
appropriate pointers in all the __init functions at the end of c-r4k.c.
The other variant would be to work on the inline functions to only
save/restore if this is a buggy CPU. The next step could be to only mask
out some interrupts as suggested, but I'm currently not experienced
enough to do this. I've now also looked at www.mips.com, but I cannot
find the erratta for R4600:-( I'm too dumb...

However, here's what I currently have. Feel free to throw stones at me:

Ralf: There's a little spellinck ficks at patches end...

Index: c-r4k.c
===================================================================
RCS file: /cvs/linux/arch/mips/mm/c-r4k.c,v
retrieving revision 1.3.2.3
diff -u -r1.3.2.3 c-r4k.c
--- c-r4k.c	2002/05/29 03:03:17	1.3.2.3
+++ c-r4k.c	2002/07/01 15:40:03
@@ -54,6 +54,10 @@
 
 struct bcache_ops *bcops = &no_sc_ops;
 
+#ifdef CONFIG_CPU_R4X00
+unsigned long	r4600_buggy_flags;
+#endif /* CONFIG_CPU_R4X00 */
+
 /*
  * On processors with QED R4600 style two set assosicative cache
  * this is the bit which selects the way in the cache for the
@@ -62,6 +66,26 @@
 #define icache_waybit (icache_size >> 1)
 #define dcache_waybit (dcache_size >> 1)
 
+static inline void
+r4600_bug_start(void)
+{
+#ifdef CONFIG_CPU_R4X00
+	__save_and_cli(r4600_buggy_flags);
+	__asm__ __volatile__("nop;nop;nop;nop");
+#endif /* CONFIG_CPU_R4X00 */
+	return;
+}
+
+static inline void
+r4600_bug_finish(void)
+{
+#ifdef CONFIG_CPU_R4X00
+	__restore_flags(r4600_buggy_flags);
+#endif /* CONFIG_CPU_R4X00 */
+	return;
+}
+
+
 /*
  * If you think for one second that this stuff coming up is a lot
  * of bulky code eating too many kernel cache lines.  Think _again_.
@@ -77,47 +101,65 @@
 
 static inline void r4k_flush_cache_all_s16d16i16(void)
 {
+	r4600_bug_start();
 	blast_dcache16(); blast_icache16(); blast_scache16();
+	r4600_bug_finish();
 }
 
 static inline void r4k_flush_cache_all_s32d16i16(void)
 {
+	r4600_bug_start();
 	blast_dcache16(); blast_icache16(); blast_scache32();
+	r4600_bug_finish();
 }
 
 static inline void r4k_flush_cache_all_s64d16i16(void)
 {
+	r4600_bug_start();
 	blast_dcache16(); blast_icache16(); blast_scache64();
+	r4600_bug_finish();
 }
 
 static inline void r4k_flush_cache_all_s128d16i16(void)
 {
+	r4600_bug_start();
 	blast_dcache16(); blast_icache16(); blast_scache128();
+	r4600_bug_finish();
 }
 
 static inline void r4k_flush_cache_all_s32d32i32(void)
 {
+	r4600_bug_start();
 	blast_dcache32(); blast_icache32(); blast_scache32();
+	r4600_bug_finish();
 }
 
 static inline void r4k_flush_cache_all_s64d32i32(void)
 {
+	r4600_bug_start();
 	blast_dcache32(); blast_icache32(); blast_scache64();
+	r4600_bug_finish();
 }
 
 static inline void r4k_flush_cache_all_s128d32i32(void)
 {
+	r4600_bug_start();
 	blast_dcache32(); blast_icache32(); blast_scache128();
+	r4600_bug_finish();
 }
 
 static inline void r4k_flush_cache_all_d16i16(void)
 {
+	r4600_bug_start();
 	blast_dcache16(); blast_icache16();
+	r4600_bug_finish();
 }
 
 static inline void r4k_flush_cache_all_d32i32(void)
 {
+	r4600_bug_start();
 	blast_dcache32(); blast_icache32();
+	r4600_bug_finish();
 }
 
 static void
@@ -143,6 +185,7 @@
 			pmd_t *pmd;
 			pte_t *pte;
 
+			r4600_bug_start();
 			while (start < end) {
 				pgd = pgd_offset(mm, start);
 				pmd = pmd_offset(pgd, start);
@@ -152,6 +195,7 @@
 					blast_scache16_page(start);
 				start += PAGE_SIZE;
 			}
+			r4600_bug_finish();
 		}
 	}
 }
@@ -179,6 +223,7 @@
 			pmd_t *pmd;
 			pte_t *pte;
 
+			r4600_bug_start();
 			while(start < end) {
 				pgd = pgd_offset(mm, start);
 				pmd = pmd_offset(pgd, start);
@@ -188,6 +233,7 @@
 					blast_scache32_page(start);
 				start += PAGE_SIZE;
 			}
+			r4600_bug_finish();
 		}
 	}
 }
@@ -214,6 +260,7 @@
 			pmd_t *pmd;
 			pte_t *pte;
 
+			r4600_bug_start();
 			while(start < end) {
 				pgd = pgd_offset(mm, start);
 				pmd = pmd_offset(pgd, start);
@@ -223,6 +270,7 @@
 					blast_scache64_page(start);
 				start += PAGE_SIZE;
 			}
+			r4600_bug_finish();
 		}
 	}
 }
@@ -249,6 +297,7 @@
 			pmd_t *pmd;
 			pte_t *pte;
 
+			r4600_bug_start();
 			while(start < end) {
 				pgd = pgd_offset(mm, start);
 				pmd = pmd_offset(pgd, start);
@@ -258,6 +307,7 @@
 					blast_scache128_page(start);
 				start += PAGE_SIZE;
 			}
+			r4600_bug_finish();
 		}
 	}
 }
@@ -284,6 +334,7 @@
 			pmd_t *pmd;
 			pte_t *pte;
 
+			r4600_bug_start();
 			while(start < end) {
 				pgd = pgd_offset(mm, start);
 				pmd = pmd_offset(pgd, start);
@@ -293,6 +344,7 @@
 					blast_scache32_page(start);
 				start += PAGE_SIZE;
 			}
+			r4600_bug_finish();
 		}
 	}
 }
@@ -319,6 +371,7 @@
 			pmd_t *pmd;
 			pte_t *pte;
 
+			r4600_bug_start();
 			while(start < end) {
 				pgd = pgd_offset(mm, start);
 				pmd = pmd_offset(pgd, start);
@@ -328,6 +381,7 @@
 					blast_scache64_page(start);
 				start += PAGE_SIZE;
 			}
+			r4600_bug_finish();
 		}
 	}
 }
@@ -354,6 +408,7 @@
 			pmd_t *pmd;
 			pte_t *pte;
 
+			r4600_bug_start();
 			while(start < end) {
 				pgd = pgd_offset(mm, start);
 				pmd = pmd_offset(pgd, start);
@@ -363,6 +418,7 @@
 					blast_scache128_page(start);
 				start += PAGE_SIZE;
 			}
+			r4600_bug_finish();
 		}
 	}
 }
@@ -375,7 +431,9 @@
 #ifdef DEBUG_CACHE
 		printk("crange[%d,%08lx,%08lx]", (int)mm->context, start, end);
 #endif
+		r4600_bug_start();
 		blast_dcache16(); blast_icache16();
+		r4600_bug_finish();
 	}
 }
 
@@ -387,7 +445,9 @@
 #ifdef DEBUG_CACHE
 		printk("crange[%d,%08lx,%08lx]", (int)mm->context, start, end);
 #endif
+		r4600_bug_start();
 		blast_dcache32(); blast_icache32();
+		r4600_bug_finish();
 	}
 }
 
@@ -504,6 +564,7 @@
 #ifdef DEBUG_CACHE
 	printk("cpage[%d,%08lx]", (int)mm->context, page);
 #endif
+	r4600_bug_start();
 	page &= PAGE_MASK;
 	pgdp = pgd_offset(mm, page);
 	pmdp = pmd_offset(pgdp, page);
@@ -533,6 +594,7 @@
 	} else
 		blast_scache16_page(page);
 out:
+	r4600_bug_finish();
 }
 
 static void r4k_flush_cache_page_s32d16i16(struct vm_area_struct *vma,
@@ -553,6 +615,7 @@
 #ifdef DEBUG_CACHE
 	printk("cpage[%d,%08lx]", (int)mm->context, page);
 #endif
+	r4600_bug_start();
 	page &= PAGE_MASK;
 	pgdp = pgd_offset(mm, page);
 	pmdp = pmd_offset(pgdp, page);
@@ -581,6 +644,7 @@
 	} else
 		blast_scache32_page(page);
 out:
+	r4600_bug_finish();
 }
 
 static void r4k_flush_cache_page_s64d16i16(struct vm_area_struct *vma,
@@ -601,6 +665,7 @@
 #ifdef DEBUG_CACHE
 	printk("cpage[%d,%08lx]", (int)mm->context, page);
 #endif
+	r4600_bug_start();
 	page &= PAGE_MASK;
 	pgdp = pgd_offset(mm, page);
 	pmdp = pmd_offset(pgdp, page);
@@ -629,6 +694,7 @@
 	} else
 		blast_scache64_page(page);
 out:
+	r4600_bug_finish();
 }
 
 static void r4k_flush_cache_page_s128d16i16(struct vm_area_struct *vma,
@@ -649,6 +715,7 @@
 #ifdef DEBUG_CACHE
 	printk("cpage[%d,%08lx]", (int)mm->context, page);
 #endif
+	r4600_bug_start();
 	page &= PAGE_MASK;
 	pgdp = pgd_offset(mm, page);
 	pmdp = pmd_offset(pgdp, page);
@@ -678,6 +745,7 @@
 	} else
 		blast_scache128_page(page);
 out:
+	r4600_bug_finish();
 }
 
 static void r4k_flush_cache_page_s32d32i32(struct vm_area_struct *vma,
@@ -698,6 +766,7 @@
 #ifdef DEBUG_CACHE
 	printk("cpage[%d,%08lx]", (int)mm->context, page);
 #endif
+	r4600_bug_start();
 	page &= PAGE_MASK;
 	pgdp = pgd_offset(mm, page);
 	pmdp = pmd_offset(pgdp, page);
@@ -727,6 +796,7 @@
 	} else
 		blast_scache32_page(page);
 out:
+	r4600_bug_finish();
 }
 
 static void r4k_flush_cache_page_s64d32i32(struct vm_area_struct *vma,
@@ -747,6 +817,7 @@
 #ifdef DEBUG_CACHE
 	printk("cpage[%d,%08lx]", (int)mm->context, page);
 #endif
+	r4600_bug_start();
 	page &= PAGE_MASK;
 	pgdp = pgd_offset(mm, page);
 	pmdp = pmd_offset(pgdp, page);
@@ -776,6 +847,7 @@
 	} else
 		blast_scache64_page(page);
 out:
+	r4600_bug_finish();
 }
 
 static void r4k_flush_cache_page_s128d32i32(struct vm_area_struct *vma,
@@ -796,6 +868,7 @@
 #ifdef DEBUG_CACHE
 	printk("cpage[%d,%08lx]", (int)mm->context, page);
 #endif
+	r4600_bug_start();
 	page &= PAGE_MASK;
 	pgdp = pgd_offset(mm, page);
 	pmdp = pmd_offset(pgdp, page);
@@ -824,6 +897,7 @@
 	} else
 		blast_scache128_page(page);
 out:
+	r4600_bug_finish();
 }
 
 static void r4k_flush_cache_page_d16i16(struct vm_area_struct *vma,
@@ -844,6 +918,7 @@
 #ifdef DEBUG_CACHE
 	printk("cpage[%d,%08lx]", (int)mm->context, page);
 #endif
+	r4600_bug_start();
 	page &= PAGE_MASK;
 	pgdp = pgd_offset(mm, page);
 	pmdp = pmd_offset(pgdp, page);
@@ -872,6 +947,7 @@
 		blast_dcache16_page_indexed(page);
 	}
 out:
+	r4600_bug_finish();
 }
 
 static void r4k_flush_cache_page_d32i32(struct vm_area_struct *vma,
@@ -892,6 +968,7 @@
 #ifdef DEBUG_CACHE
 	printk("cpage[%d,%08lx]", (int)mm->context, page);
 #endif
+	r4600_bug_start();
 	page &= PAGE_MASK;
 	pgdp = pgd_offset(mm, page);
 	pmdp = pmd_offset(pgdp, page);
@@ -921,6 +998,7 @@
 		blast_dcache32_page_indexed(page);
 	}
 out:
+	r4600_bug_finish();
 }
 
 static void r4k_flush_cache_page_d32i32_r4600(struct vm_area_struct *vma,
@@ -941,6 +1019,7 @@
 #ifdef DEBUG_CACHE
 	printk("cpage[%d,%08lx]", (int)mm->context, page);
 #endif
+	r4600_bug_start();
 	page &= PAGE_MASK;
 	pgdp = pgd_offset(mm, page);
 	pmdp = pmd_offset(pgdp, page);
@@ -970,6 +1049,7 @@
 		blast_dcache32_page_indexed(page ^ dcache_waybit);
 	}
 out:
+	r4600_bug_finish();
 }
 
 /* If the addresses passed to these routines are valid, they are
@@ -1063,7 +1143,7 @@
 		flush_cache_all();
 	} else {
 #ifdef R4600_V2_HIT_CACHEOP_WAR
-		/* Workaround for R4600 bug.  See comment in <asm/war>. */
+		/* Workaround for R4600 bug.  See comment in <asm/war.h>. */
 		__save_and_cli(flags);
 		*(volatile unsigned long *)KSEG1;
 #endif




-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1

[Maciej W. Rozycki]

On Mon, 1 Jul 2002, Jan-Benedict Glaw wrote:

> I'm just compiling with my proposed "fix". However, is it really a good
> idea to duplicate so much code? Taking my 2nd idea (having inline
> functions for saveing/restoring flags which are complete no-ops if
> !CONFIG_CPU_R4X00), would it be much overhead for 4400 and 4000 to check
> if we need to shuffle around flags and cut off interrupts?

 No need to duplicate anything -- templates may be used with bits
substituted as needed depending on what file is generated.  See e.g. 
arch/mips64/kernel/binfmt_elf32.c for an example idea. 

> I'm not really familiar w/ cache and interrupt handling/masking, and I
> don't (yet) exactly know how to check for the buggy old R4600, but I
> think I'll have to become an expert around that:-O

 The check is already in place -- see setup_noscache_funcs() in
arch/mips/mm/c-r4k.c, only the implementation is incomplete which started
biting after interrupts became active.

> Any hints for online resources? I've had a look at idt.com (found it in
> ./asm-mips/war.h), but I cannot find the resources there:-(

 I contacted them some time ago, soon after the fix for interrupt masking
went in (someone reported a problem with an old R4600 then). 
Unfortunately my conversation with them was disappointing and currently I
lack incentive to code a workaround for their buggy chips.  Especially as
I have tasks I consider more important to do. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]

On Mon, 2002-07-01 19:02:38 +0200, Maciej W. Rozycki <macro@ds2.pg.gda.pl>
wrote in message <Pine.GSO.3.96.1020701185152.7601J-100000@delta.ds2.pg.gda.pl>:
> On Mon, 1 Jul 2002, Jan-Benedict Glaw wrote:
> > I'm not really familiar w/ cache and interrupt handling/masking, and I
> > don't (yet) exactly know how to check for the buggy old R4600, but I
> > think I'll have to become an expert around that:-O
> 
>  The check is already in place -- see setup_noscache_funcs() in
> arch/mips/mm/c-r4k.c, only the implementation is incomplete which started
> biting after interrupts became active.

Hmmm... I think Ill have to read some heavy MIPS books first:-)

MfG, JBG

-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1

[Karel van Houten]

> On Mon, 2002-07-01 16:28:13 +0200, Maciej W. Rozycki <macro@ds2.pg.gda.pl>
> wrote in message
> <Pine.GSO.3.96.1020701161009.7601E-100000@delta.ds2.pg.gda.pl>:
> > On Mon, 1 Jul 2002, Jan-Benedict Glaw wrote:
> > 
> > > Okay, stupid idea. All these flush functions seem to be never called in
> > > parallel or recursive, so if might be possible to have a global flags
> > > variable and instead of always calling __save..() and __restore..(),
> > > we bulid a pair of inline functions doing this. This wouldn't give
> > > any penalty for !CONFIG_CPU_R4X00 and doesn't obscure the code so much
> > > as all those #ifdef and #endif's would do... I'll test my suggestion
> > > as fast as I reach my Indy again (is powered down at home...).
> > 
> >  Feel free to use the change privately.  Otherwise please code a real fix,
> > i.e. a set of buggy-R4600-specific functions, as CONFIG_CPU_R4X00 means
> > other processors as well, e.g. R4000 or R4400 which are fine here. 
> > 
> >  Actually blocking interrupts for over 0.01s as it used to be done is
> 
> Ah. That would explain the huge time drifts when the box is under
> load...
> 

Indeed, I'm now running 2.4.18, and for the first time my DS5000/260 and
DS5000/200 can keep exact time, even under heavy load.
Btw, I use a R4400SC CPU.

-- 
Karel van Houten

----------------------------------------------------------
The box said "Requires Windows 95 or better."
I can't understand why it won't work on my Linux computer. 
----------------------------------------------------------

Re: [Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

On Mon, 2002-07-01 19:24:59 +0200, Karel van Houten <vhouten@kpn.com>
wrote in message <200207011725.TAA16476@sparta.research.kpn.com>:
> > On Mon, 2002-07-01 16:28:13 +0200, Maciej W. Rozycki <macro@ds2.pg.gda.pl>
> > wrote in message
> > <Pine.GSO.3.96.1020701161009.7601E-100000@delta.ds2.pg.gda.pl>:
> > > On Mon, 1 Jul 2002, Jan-Benedict Glaw wrote:
> > >  Feel free to use the change privately.  Otherwise please code a real fix,
> > > i.e. a set of buggy-R4600-specific functions, as CONFIG_CPU_R4X00 means
> > > other processors as well, e.g. R4000 or R4400 which are fine here. 
> > > 
> > >  Actually blocking interrupts for over 0.01s as it used to be done is
> > 
> > Ah. That would explain the huge time drifts when the box is under
> > load...
> 
> Indeed, I'm now running 2.4.18, and for the first time my DS5000/260 and
> DS5000/200 can keep exact time, even under heavy load.
> Btw, I use a R4400SC CPU.

Oh. Lucke you, unlucky /me...

MfG, JBG

-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Oops] Indy R4600 Oops(es) w/ 2.4.19-rc1

[Maciej W. Rozycki]

On Mon, 1 Jul 2002, Karel van Houten wrote:

> Indeed, I'm now running 2.4.18, and for the first time my DS5000/260 and
> DS5000/200 can keep exact time, even under heavy load.

 Well, for the /200 you should have always had stable time, although with
a coarse resolution, due to the lack of a high-precision timer (which for
the DECstation family is available either internally in R4k CPUs or
externally in the I/O ASIC).

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +