[PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

[Michel Dänzer]

On 24/03/17 12:31 AM, Zachary Michaels wrote:
> 
> I should also note that we are experiencing another issue where the
> kernel locks up in similar circumstances. As Julien noted, we get no
> output, and the watchdogs don't seem to work. It may be the case that
> Xorg and our process are calling ttm_bo_mem_force_space concurrently,
> but I don't think we have enough information yet to say for
> sure. Reverting this commit does not fix that issue. I have some small
> amount of evidence indicating that bos flagged for CPU access are
> getting placed in CPU inaccessible memory. Could that cause this sort of
> kernel lockup?

Possibly, does this help?

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c
index 37d68cd1f272..40d1bb467a71 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -198,7 +198,8 @@ static void radeon_evict_flags(struct ttm_buffer_object *bo,
        case TTM_PL_VRAM:
                if (rbo->rdev->ring[radeon_copy_ring_index(rbo->rdev)].ready == false)
                        radeon_ttm_placement_from_domain(rbo, RADEON_GEM_DOMAIN_CPU);
-               else if (rbo->rdev->mc.visible_vram_size < rbo->rdev->mc.real_vram_size &&
+               else if (!(rbo->flags & RADEON_GEM_CPU_ACCESS) &&
+                        rbo->rdev->mc.visible_vram_size < rbo->rdev->mc.real_vram_size &&
                         bo->mem.start < (rbo->rdev->mc.visible_vram_size >> PAGE_SHIFT)) {
                        unsigned fpfn = rbo->rdev->mc.visible_vram_size >> PAGE_SHIFT;
                        int i;



-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer