Created attachment 139715 [details] dmesg Gigabyte X470-AORUS-ULTRA-GAMING board with AMD Ryzen 5 2400g APU, Fedora 28, git MESA, git AMDGPU; box was migrated today from AMD A10-5800 based solution. I found these in xorg.log: [ 1894.583] (WW) AMDGPU(0): flip queue failed: Cannot allocate memory [ 1894.583] (WW) AMDGPU(0): Page flip failed: Cannot allocate memory [ 1894.583] (EE) AMDGPU(0): present flip failed [ 1894.594] (WW) AMDGPU(0): flip queue failed in amdgpu_scanout_flip: Cannot allocate memory, TearFree inactive until next modeset
Created attachment 139716 [details] messages
Created attachment 139717 [details] xorg log
Please also attach the dmesg output from before the problem occurs, containing at least all the amdgpu and TTM initialization messages.
Created attachment 139718 [details] [review] Print fpfn/lpfn values in ttm_bo_mem_space_debug Can you rebuild the ttm.ko module with this patch applied, and attach the resulting dmesg output when the problem occurs again? It might shed some more light on why we fail to evict a BO to GTT, even though there seems to be enough space there.
There is no dmesg from before the problem occurs. I will try the patch!
Created attachment 139719 [details] journal
Actually, it seems clear that this happens because 1 GB of VRAM and 3 GB of GTT are full with buffer objects. Unless this keeps happening even immediately after closing applications / logging out and back in / restarting X, this looks like a userspace issue (could be a leak somewhere).
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/394.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.