linux-mips
[Top] [All Lists]

RE: problems on D-cache alias in 2.4.22

To: <linux-mips@linux-mips.org>
Subject: RE: problems on D-cache alias in 2.4.22
From: "Bob Breuer" <bbreuer@righthandtech.com>
Date: Thu, 13 May 2004 17:05:52 -0500
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
Thread-index: AcQ5NnTrK9jtHiAwTiu//MgHM8HyDA==
Thread-topic: problems on D-cache alias in 2.4.22
> -----Original Message-----
> Date: Thu, 13 May 2004 14:52:53 +0800
> From: wuming <wuming@ict.ac.cn>
> Subject: problems on D-cache alias in 2.4.22
> 
>  I am developing in linux-2.4.22 on the machine with virtual address
> indexed and physical
> address tagged. But when I compile some application programs, 
> I met the
> following error:
> 
> cc1: internal compiler error: Segmentation fault
> 
> I have searched about this error from internet, it's due to some
> hardware fault or
> a wrong pte fault handler. Because my machine have D-cache 
> aliasing, so
> I think
> this error should be due to a wrong pte fault handler. After 
> my painful
> kernel hacking,
> I found some strange problems and it's in function __update_cache( ):
> 
> void __update_cache(struct vm_area_struct *vma, unsigned long address,
> pte_t pte)
> {
> unsigned long addr;
> struct page *page;
> 
> if (!cpu_has_dc_aliases)
> return;
> 
> page = pte_page(pte);
> 
> /*This printk is added by myself*/
> printk("<1>valid page:%d\tpage mapping:0x%p\tpage flags:%d\n",\
> VALID_PAGE(page), page->mapping, (page->flags & (1UL << 
> PG_dcache_dirty)));
> 
> if (VALID_PAGE(page) && page->mapping &&
> (page->flags & (1UL << PG_dcache_dirty))) {
> if (pages_do_alias((unsigned long) page_address(page), address &
> PAGE_MASK)) {
> addr = (unsigned long) page_address(page);
> flush_data_cache_page(addr);
> }
> ClearPageDcacheDirty(page);
> }
> }
> 
> When my kernel is running, I found the condition "page->mapping" and
> "(page->flags & (1UL << PG_dcache_dirty))"
> will never be true at the same time. so the function
> flush_data_cache_page( ) will never be called.
> Then I commented the two condition, the compiler error disappeared.
> I do not understand the phenomenon very clearly, so I need some help.
> 
> 

I am having a similar problem with 2.4.26 on an NEC VR5500 with a 32k
2-way cache.  This is with a 32 bit little-endian kernel, and an ext2
filesystem on an ide hard drive in pio mode.

Removing just the check for PG_dcache_dirty fixes the problem for me.

Along the way, I found a bogus check for cache aliases in c-r4k.c.  In
the ld_mmu_r4xx0 function, it has the check:
    if (c->dcache.sets * c->dcache.ways > PAGE_SIZE)
which will never work for a 32k cache.

Bob Breuer

<Prev in Thread] Current Thread [Next in Thread>