Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Peter Horton <phorton@bitbox.co.uk>
To: linux-mips@linux-mips.org
Subject: Re: Kernel 2.4.23 on Cobalt Qube2 - area of problem
Date: Fri, 12 Dec 2003 10:45:08 +0000	[thread overview]
Message-ID: <3FD99C34.9090001@bitbox.co.uk> (raw)

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

More info on the random segmentation faults and data corruption on my Qube2.

2.4.21 from CVS is the first kernel to exhibit the problem. I tracked it 
down to the cache handling changes that went in between 2.4.20 and 2.4.21.

By (not very scientifically) removing flush_dcache_page() and 
re-instating flush_page_to_ram() I managed to get the 2.4.21 kernel 
stable (see attached patch). Applying a similiar patch to 2.4.23 (CVS 
HEAD) allows me to run 2.4.23 too.

I don't know how to track the problem any further - the kernel's cache 
handling is a bit out of my league.

Anyone got a clue stick they can point me in the right direction with ?

P.







[-- Attachment #2: cobalt-patch --]
[-- Type: text/plain, Size: 3261 bytes --]

diff -urN linux-2.4.21-xxx/arch/mips/mm/c-r4k.c linux-2.4.21/arch/mips/mm/c-r4k.c
--- linux-2.4.21-xxx/arch/mips/mm/c-r4k.c	Thu Dec 11 20:20:28 2003
+++ linux-2.4.21/arch/mips/mm/c-r4k.c	Thu Dec 11 10:02:54 2003
@@ -1037,16 +1037,6 @@
 	return 1;
 }
 
-static void r4k_flush_page_to_ram_d16(struct page *page)
-{
-	blast_dcache16_page((unsigned long)page_address(page));
-}
-
-static void r4k_flush_page_to_ram_d32(struct page *page)
-{
-	blast_dcache32_page((unsigned long)page_address(page));
-}
-
 static void __init setup_noscache_funcs(void)
 {
 	unsigned int prid;
@@ -1059,7 +1049,6 @@
 			_clear_page = r4k_clear_page32_d16;
 		_copy_page = r4k_copy_page_d16;
 
-		_flush_page_to_ram = r4k_flush_page_to_ram_d16;
 		break;
 	case 32:
 		prid = read_c0_prid() & 0xfff0;
@@ -1076,8 +1065,6 @@
 				_clear_page = r4k_clear_page32_d32;
 			_copy_page = r4k_copy_page_d32;
 		}
-
-		_flush_page_to_ram = r4k_flush_page_to_ram_d32;
 		break;
 	}
 }
diff -urN linux-2.4.21-xxx/arch/mips/mm/cache.c linux-2.4.21/arch/mips/mm/cache.c
--- linux-2.4.21-xxx/arch/mips/mm/cache.c	Thu Dec 11 20:15:37 2003
+++ linux-2.4.21/arch/mips/mm/cache.c	Fri Jul 18 15:16:06 2003
@@ -20,8 +20,6 @@
 	return 0;
 }
 
-#if 0
-
 void flush_dcache_page(struct page *page)
 {
 	unsigned long addr;
@@ -67,5 +65,3 @@
 }
 
 EXPORT_SYMBOL(flush_dcache_page);
-
-#endif
diff -urN linux-2.4.21-xxx/arch/mips/mm/loadmmu.c linux-2.4.21/arch/mips/mm/loadmmu.c
--- linux-2.4.21-xxx/arch/mips/mm/loadmmu.c	Thu Dec 11 20:25:23 2003
+++ linux-2.4.21/arch/mips/mm/loadmmu.c	Thu Dec 11 10:02:54 2003
@@ -40,8 +40,6 @@
 void (*_flush_data_cache_page)(unsigned long addr);
 void (*_flush_icache_all)(void);
 
-void (*_flush_page_to_ram)(struct page * page);
-
 #ifdef CONFIG_NONCOHERENT_IO
 
 /* DMA cache operations. */
diff -urN linux-2.4.21-xxx/include/asm-mips/cacheflush.h linux-2.4.21/include/asm-mips/cacheflush.h
--- linux-2.4.21-xxx/include/asm-mips/cacheflush.h	Thu Dec 11 20:22:51 2003
+++ linux-2.4.21/include/asm-mips/cacheflush.h	Tue Apr  1 00:29:06 2003
@@ -46,16 +46,12 @@
 extern void (*_flush_icache_all)(void);
 extern void (*_flush_data_cache_page)(unsigned long addr);
 
-extern void (*_flush_page_to_ram)(struct page * page);
-
-#define flush_dcache_page(page)		do { } while(0)
-
 #define flush_cache_all()		_flush_cache_all()
 #define __flush_cache_all()		___flush_cache_all()
 #define flush_cache_mm(mm)		_flush_cache_mm(mm)
 #define flush_cache_range(mm,start,end)	_flush_cache_range(mm,start,end)
 #define flush_cache_page(vma,page)	_flush_cache_page(vma, page)
-#define flush_page_to_ram(page)		_flush_page_to_ram(page)
+#define flush_page_to_ram(page)		do { } while (0)
 
 #define flush_icache_range(start, end)	_flush_icache_range(start,end)
 #define flush_icache_user_range(vma, page, addr, len) \
diff -urN linux-2.4.21-xxx/include/asm-mips/pgtable.h linux-2.4.21/include/asm-mips/pgtable.h
--- linux-2.4.21-xxx/include/asm-mips/pgtable.h	Thu Dec 11 20:36:56 2003
+++ linux-2.4.21/include/asm-mips/pgtable.h	Thu Dec 11 10:04:27 2003
@@ -261,7 +261,7 @@
 	unsigned long address, pte_t pte)
 {
 	__update_tlb(vma, address, pte);
-//	__update_cache(vma, address, pte);
+	__update_cache(vma, address, pte);
 }
 
 /* Swap entries must have VALID and GLOBAL bits cleared. */

             reply	other threads:[~2003-12-12 10:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-12 10:45 Peter Horton [this message]
2003-12-13 17:07 ` Kernel 2.4.23 on Cobalt Qube2 - area of problem Ralf Baechle
2003-12-13 18:20   ` Peter Horton
2003-12-13 18:38   ` Peter Horton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3FD99C34.9090001@bitbox.co.uk \
    --to=phorton@bitbox.co.uk \
    --cc=linux-mips@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox