Am 27.03.2017 um 02:58 schrieb Michel Dänzer: > From: Michel Dänzer <michel.daenzer at amd.com> > > We were accidentally only overriding the first VRAM placement. For BOs > with the RADEON_GEM_NO_CPU_ACCESS flag set, > radeon_ttm_placement_from_domain creates a second VRAM placment with > fpfn == 0. If VRAM is almost full, the first VRAM placement with > fpfn > 0 may not work, but the second one with fpfn == 0 always will > (the BO's current location trivially satisfies it). Because "moving" > the BO to its current location puts it back on the LRU list, this > results in an infinite loop. > > Fixes: 2a85aedd117c ("drm/radeon: Try evicting from CPU accessible to > inaccessible VRAM first") > Reported-by: Zachary Michaels <zmichaels at oblong.com> > Reported-and-Tested-by: Julien Isorce <jisorce at oblong.com> > Signed-off-by: Michel Dänzer <michel.daenzer at amd.com> Reviewed-by: Christian König <christian.koenig at amd.com> > --- > drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c > index 5c7cf644ba1d..37d68cd1f272 100644 > --- a/drivers/gpu/drm/radeon/radeon_ttm.c > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c > @@ -213,8 +213,8 @@ static void radeon_evict_flags(struct ttm_buffer_object *bo, > rbo->placement.num_busy_placement = 0; > for (i = 0; i < rbo->placement.num_placement; i++) { > if (rbo->placements[i].flags & TTM_PL_FLAG_VRAM) { > - if (rbo->placements[0].fpfn < fpfn) > - rbo->placements[0].fpfn = fpfn; > + if (rbo->placements[i].fpfn < fpfn) > + rbo->placements[i].fpfn = fpfn; > } else { > rbo->placement.busy_placement = > &rbo->placements[i];