[Top] [All Lists]

Re: problems on D-cache alias in 2.4.22

To: Peter Horton <>
Subject: Re: problems on D-cache alias in 2.4.22
From: Jun Sun <>
Date: Tue, 18 May 2004 15:25:39 -0700
Cc: Bob Breuer <>,,
In-reply-to: <20040518191019.GA11007@skeleton-jack>; from on Tue, May 18, 2004 at 08:10:19PM +0100
Original-recipient: rfc822;
References: <> <> <20040518191019.GA11007@skeleton-jack>
User-agent: Mutt/1.2.5i
On Tue, May 18, 2004 at 08:10:19PM +0100, Peter Horton wrote:
> On Tue, May 18, 2004 at 11:45:19AM -0700, Jun Sun wrote:
> > 
> > Like others suggested, this is not the right fix.  flush_page_to_ram()
> > is correctly nullified.  Its job should be done somewhere else
> > by other routines.
> > 
> > Here are a couple of random ideas for finding the true root cause:
> > 
> We know what the true root cause is :-)
> IDE PIO fills the D-cache with the read data (write allocate) as it
> copies it to the page cache.
> The kernel maps the page cache page into user space ... BANG! possible
> D-cache alias.
> The kernel doesn't bother flushing the page cache page from the D-cache
> as it's never accessed at it's page cache address.

The kernel (or driver) should flush the page if it is mapped to user space 
and the content is modified.

> The current fix in the Cobalt patches (2.4 & 2.6) just flushes the read
> data out of the D-cache after every IDE insw()/insl(). This is the least
> intrusive fix.

It should be fixed at a higher layer before we return back to userland.

If you can illustrate the call stack, I can probably take a look and
give my opinion.


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