From: Jerome Glisse <j.glisse@free.fr>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
linuxppc64-dev <linuxppc64-dev@ozlabs.org>
Subject: Re: PATCH uninorth3 (G5) agp support
Date: Mon, 27 Dec 2004 14:50:01 +0100 [thread overview]
Message-ID: <41D01309.3000304@free.fr> (raw)
In-Reply-To: <1104154320.23891.27.camel@gaston>
>Sure. There is still a pending issue though with AGP on the G5. The
>problem is that we create a non-cacheable mapping for the RAM pages of
>the AGP aperture (both in-kernel and for userland) while they already
>have a cacheable mapping via the normal kernel linear mapping of main
>memory.
>
>The result is that there is a potential cache aliasing issue, aggravated
>by the fact that the G5 is quite aggressive on pre-fetching and thuis,
>may end up prefetching some of the AGP cache lines (via the linear
>mapping) even if no actual access is ever done to these pages.
>
>Unfortunately, if a collision occurs (a non-cacheable access to some
>space that do exist in the cache at the same time), the result is
>undefined, and is likely to result in a checkstop (the CPU just stops).
>
>I really don't know of a simple remedy at this point. The problem is
>partially due to the fact that we do the linear mapping using large
>pages, so we can't simply undo the cacheable mapping for the pages that
>ended up beeing allocated for AGP... An option would be to eventually
>reserve the AGP memory early during boot and not include it in the
>linear mapping at all. Another thing to test is that maybe U3 is smart
>enough to snoop AGP accesses, and thus we could have the AGP mappings be
>cacheable as well (though that may require some stronger synchronisation
>directives in the DRM code).
>
>Ben.
>
>
I got some lockup after adding agp support but i don't know if
it came from my playing with the r300 (most probable
source :)) or from the cache collision you are talking about.
Anyway it's not time to think to that :) Have good hollydays.
I will look a bit further in this to see if i can find anythings
that may helps.
best,
Jerome Glisse
next prev parent reply other threads:[~2004-12-27 13:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-26 14:12 PATCH uninorth3 (G5) agp support Jerome Glisse
2004-12-27 8:50 ` Benjamin Herrenschmidt
2004-12-27 8:52 ` Benjamin Herrenschmidt
2004-12-27 12:51 ` Jerome Glisse
2004-12-27 13:32 ` Benjamin Herrenschmidt
2004-12-27 13:50 ` Jerome Glisse [this message]
2004-12-27 13:52 ` Benjamin Herrenschmidt
2005-01-03 18:56 ` Jon Loeliger
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=41D01309.3000304@free.fr \
--to=j.glisse@free.fr \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=linuxppc64-dev@ozlabs.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.