Re: CIK hangs with kernel 3.15, bisected

["Christian König" <deathsimple@vodafone.de>]

[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]

Couldn't reproduce the issue so far. So the attached patch is just a 
complete shoot into the dark found by rereading the code, but it might 
actually be the problem.

Please give it a try.

Going to keep testing in the meantime,
Christian.

Am 10.05.2014 10:23, schrieb Christian König:
>> I see hangs with kernel 3.15 and SI under memory pressure, e.g. if I 
>> boot with radeon.vramlimit=256 and then run Xonotic timedemo with 
>> high settings. I haven't had a chance to bisect it yet, but it might 
>> be a similar problem.
> Sounds like the same issue to me. Thx for the good test case.
>
>> Any idea what is wrong with it?
> Actually I already wondered that it went so smooth without any 
> regression so far, didn't noticed the bug in bugzilla.kernel.org yet.
>
>> Some of the tests allocate a lot of MSAA textures and the tests also
>> run in parallel, which creates a lot of memory pressure and probably
>> causes buffer evictions.
> Sounds like the underlying problem to me. We probably evict some part 
> of a page table without updating the page directory. Going to dig into 
> it today, it's probably just a one liner missing somewhere in the VM 
> code.
>
> Christian.
>
> Am 09.05.2014 23:39, schrieb Grigori Goronzy:
>> On 09.05.2014 20:03, Marek Olšák wrote:
>>>
>>> This commit which first appeared in 3.15-rc1 causes hangs on Bonaire:
>>> [...]
>>>
>>> The simplest way to reproduce the hangs is to run piglit with these 
>>> parameters:
>>> -t texelFetch.fs
>>>
>>> Some of the tests allocate a lot of MSAA textures and the tests also
>>> run in parallel, which creates a lot of memory pressure and probably
>>> causes buffer evictions.
>>>
>>
>> I see hangs with kernel 3.15 and SI under memory pressure, e.g. if I 
>> boot with radeon.vramlimit=256 and then run Xonotic timedemo with 
>> high settings. I haven't had a chance to bisect it yet, but it might 
>> be a similar problem.
>>
>> Grigori
>


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-drm-radeon-fix-buffer-placement-under-memory-pressur.patch --]
[-- Type: text/x-diff; name="0001-drm-radeon-fix-buffer-placement-under-memory-pressur.patch", Size: 1944 bytes --]

>From 93a89ae1bdf359a4261ae0120ba893039a6f05be Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig@amd.com>
Date: Sat, 10 May 2014 18:17:09 +0200
Subject: [PATCH] drm/radeon: fix buffer placement under memory pressure
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Some buffers (UVD/VM page tables) must be placed in VRAM,
but the byte restriction for moving buffers didn't took this
into account.

This patch not only fixed that bug, but also improves
the situation when we run out of GART space.

Signed-off-by: Christian König <christian.koenig@amd.com>
---
 drivers/gpu/drm/radeon/radeon_object.c | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c
index 72705fb..92ff6be 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -447,8 +447,6 @@ int radeon_bo_list_validate(struct radeon_device *rdev,
 		bo = lobj->robj;
 		if (!bo->pin_count) {
 			u32 domain = lobj->domain;
-			u32 current_domain =
-				radeon_mem_type_to_domain(bo->tbo.mem.mem_type);
 
 			/* Check if this buffer will be moved and don't move it
 			 * if we have moved too many buffers for this IB already.
@@ -458,11 +456,10 @@ int radeon_bo_list_validate(struct radeon_device *rdev,
 			 * into account. We don't want to disallow buffer moves
 			 * completely.
 			 */
-			if (current_domain != RADEON_GEM_DOMAIN_CPU &&
-			    (domain & current_domain) == 0 && /* will be moved */
-			    bytes_moved > bytes_moved_threshold) {
-				/* don't move it */
-				domain = current_domain;
+			if (bytes_moved > bytes_moved_threshold) {
+				/* if we already moved to many bytes accept
+				   the alternative domain as well */
+				domain = lobj->alt_domain;
 			}
 
 		retry:
-- 
1.9.1


[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel