From: wuming <wuming@ict.ac.cn>
To: linux-mips@linux-mips.org
Subject: Re: problems on D-cache alias in 2.4.22
Date: Fri, 14 May 2004 10:59:13 +0800 [thread overview]
Message-ID: <40A43601.70307@ict.ac.cn> (raw)
In-Reply-To: <B482D8AA59BF244F99AFE7520D74BF9609D4B1@server1.RightHand.righthandtech.com>
>
>
>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
>
>
>
>
>
I have understood the phenomenon, and I think this is a kernel's bug.
The real wrong place is not the judgement for condition "PG_dcache_dirty"
in function __update_cache( ).
in file mm/filemap.c and function filemap_nopage( ):
......
success:
/*
* Try read-ahead for sequential areas.
*/
if (VM_SequentialReadHint(area))
nopage_sequential_readahead(area, pgoff, size);
/*
* Found the page and have a reference on it, need to check sharing
* and possibly copy it over to another page..
*/
mark_page_accessed(page);
flush_page_to_ram(page);
return page;
......
flush_page_to_ram( ) has not been used for a long time, and in kernel 2.4.22
"include/asm-mips/cacheflush.h"
#define flush_page_to_ram(page) do { } while (0)
so the mapped page has not been flushed to ram, and the user space will not
know the latest data in the page.
the flush_page_to_ram( ) should be replaced by flush_dcache_page( ),
and if the flush_dcache_page( ) does not really flush the cache, it will set
the PG_dcache_dirty, and the real flush will be postponed to
__update_cache( ).
and if there is not the flush_dcache_page( ) here, no one will set the
PG_dcache_dirty,
and __update_cache( ) will not flush the page too, so the D-cache
aliasing happens.
at last, when I replaced flush_page_to_ram( ) with flush_dcache_page( ),
the internal compiler error disappeared.
I hope your problem will be solved by this way too. God bless you! :-)
next prev parent reply other threads:[~2004-05-14 2:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-13 22:05 problems on D-cache alias in 2.4.22 Bob Breuer
2004-05-13 22:05 ` Bob Breuer
2004-05-14 2:59 ` wuming [this message]
2004-05-14 7:52 ` Peter Horton
2004-05-15 0:12 ` Ralf Baechle
2004-05-15 12:31 ` Fuxin Zhang
-- strict thread matches above, loose matches on Subject: below --
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
2004-05-13 6:52 wuming
2004-05-14 7:45 ` 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=40A43601.70307@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox