Message-ID: <3C4E9291.8DA0BD7F@stud.uni-saarland.de>
Date: Wed, 23 Jan 2002 10:38:09 +0000
From: Studierende der Universitaet des Saarlandes 
	<masp0008@stud.uni-saarland.de>
Reply-To: manfred@colorfullife.com
Organization: Studierende Universitaet des Saarlandes
MIME-Version: 1.0
To: Daniel Robbins <drobbins@gentoo.org>
CC: linux-kernel@vger.kernel.org
Subject: Re: Athlon/AGP issue update
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

> 
> The effect of the store is to write-allocate a cache line in the data
> cache and fill that cache line with data from the underlying physical
> memory. Because the line was write-allocated it is subsequently written
> back to physical memory even though the bits have not been changed by
> the processor. 

I'm not sure if I understand you correctly:

speculative write operations always set the cache line dirty bit, even
if the write operations is not executed (e.g. discarded due to a
mispredicted jump)

memory mapped by GART is not cache coherent, and the write-back of the
cache causes data corruptions.

Result: data corruption.

Is that correct?

Then "nopentium" only works by chance: I assume that speculative
operations do not walk the page tables, thus the probability that a
valid TLB entry is found for the GART mapped page is slim. But if there
is an entry, then the corruption would still occur.

How could we work around it?
a) At GART mapping time, we'd have to
- flush the cache
- unmap the pte entries that point to the pages that will be mapped by
GART
- create a new, uncached, ioremap mapping to the pages.

Obviously that won't work with 4 MB pages.

b) abuse highmem.
highmem memory is not mapped. If we only use highmem pages for GART, and
ensure that page->virtual is 0, then we know that no valid pte points
into the GART pages.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/