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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
