From: "Christian König" <christian.koenig@amd.com>
To: Alexander Fyodorov <halcy@yandex.ru>,
airlied@linux.ie, dri-devel@lists.freedesktop.org
Subject: Re: r600_dma_ring_test() failed - synchronization problem with write-combining memory
Date: Thu, 9 Oct 2014 19:42:02 +0200 [thread overview]
Message-ID: <5436C8EA.4010200@amd.com> (raw)
In-Reply-To: <3692931412854762@web24j.yandex.ru>
Hi Alexander,
in the ring test we write the value 0xDEADBEEF and 0xCAFEDEAD into
registers, not VRAM.
And the register bar shouldn't be accessed write combined, cause that
could lead to a couple of ordering problems. Why do you think the access
is done write combined?
For VRAM it is true that we have a couple of different caches between
the CPU and the actually memory, which need to be flushed explicitly if
you want to see a value written by the GPU.
Regards,
Christian.
Am 09.10.2014 um 13:39 schrieb Alexander Fyodorov:
> Hi David,
>
> I'm using 3.10.53-rt56 kernel and encounter a problem in
> r600_dma_ring_test() when vram memory is mapped as write-combining:
> no matter how long the polling is done, old value (0xCAFEDEAD) is read.
>
> Looking with hardware analyzer at what actually happens in the PCI-E bus,
> the memory is accessed with 32-byte loads (8 words at a time). That is,
> when the memory is mapped as write-combining, the processor converts
> every readl() into a 32-bytes load transaction.
>
> After doing some more experiments, it seems that Radeon has some kind of
> cache that keeps the old value (0xCAFEDEAD), and this cache is invalidated
> when:
> 1) Some other VRAM address is accessed, or
> 2) Processor issues a 4-byte load transaction.
>
> The problem is that as long as the memory is write-combining, all loads
> will be converted to be 32-bytes long by the CPU, so the test fails with
> timeout. But if I comment out this particular ring test, everything
> seems to be working fine (tested with Doom 3).
>
> Is it possible that the situation r600_dma_ring_test() checks for does
> not happen in real life, and I should be OK commenting it out?
>
> Or maybe the test is broken and some cache-flushing command must be
> written into the ring buffer?
>
> BTW this is an out-of-tree architecture, so bisecting is not possible.
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2014-10-09 17:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-09 11:39 r600_dma_ring_test() failed - synchronization problem with write-combining memory Alexander Fyodorov
2014-10-09 17:42 ` Christian König [this message]
2014-10-09 18:15 ` Alexander Fyodorov
2014-10-09 18:32 ` Christian König
2014-10-09 19:10 ` Alexander Fyodorov
2014-10-10 16:00 ` Alex Deucher
2014-10-10 16:02 ` Alex Deucher
2014-10-10 16:03 ` Christian König
2014-10-13 17:50 ` Alex Deucher
2014-10-14 14:12 ` Alexander Fyodorov
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=5436C8EA.4010200@amd.com \
--to=christian.koenig@amd.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=halcy@yandex.ru \
/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