All of lore.kernel.org
 help / color / mirror / Atom feed
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! :-)

  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 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.