All of lore.kernel.org
 help / color / mirror / Atom feed
From: wuming <wuming@ict.ac.cn>
To: linux-mips@linux-mips.org
Subject: problems on D-cache alias in 2.4.22
Date: Thu, 13 May 2004 14:52:53 +0800	[thread overview]
Message-ID: <40A31B45.7060204@ict.ac.cn> (raw)

 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.

             reply	other threads:[~2004-05-13  6:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-13  6:52 wuming [this message]
2004-05-14  7:45 ` problems on D-cache alias in 2.4.22 Peter Horton
  -- strict thread matches above, loose matches on Subject: below --
2004-05-13 22:05 Bob Breuer
2004-05-13 22:05 ` Bob Breuer
2004-05-14  2:59 ` wuming
2004-05-14  7:52   ` Peter Horton
2004-05-15  0:12   ` Ralf Baechle
2004-05-15 12:31     ` Fuxin Zhang
2004-05-18 18:17 Bob Breuer
2004-05-18 18:17 ` Bob Breuer
2004-05-18 18:45 ` Jun Sun
2004-05-18 19:10   ` Peter Horton
2004-05-18 19:50     ` Ralf Baechle
2004-05-18 18:24       ` Alan Cox
2004-05-18 21:21       ` Peter Horton
2004-05-18 22:25     ` Jun Sun
2004-05-18 23:29       ` Peter Horton
2004-05-18 20:02 ` Ralf Baechle
2004-05-18 20:10 ` Thiemo Seufer

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=40A31B45.7060204@ict.ac.cn \
    --to=wuming@ict.ac.cn \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.