Hi, We are enabling a new Stoney Ridge laptop. The issue can be reproduced on branch drm-next-4.16-wip and amd-staging-drm-next. Reproduce steps: 1. Plug HDMI monitor. 2. Change to extended mode. 3. Unplug the HDMI monitor 4. Plug the HDMI monitor Internal display may go blank in step 3. The internal display may also go blank in step 4. The external one shows desktop correctly though. I can see lots of message flooding once I plugged HDMI: [ 120.933668] amdgpu 0000:00:01.0: 0000000030e07f1f pin failed [ 120.933859] [drm:amdgpu_crtc_page_flip_target [amdgpu]] *ERROR* failed to pin new abo buffer before flip These messages stop as soon as the HDMI is unplugged.
Created attachment 136186 [details] lspci
Created attachment 136187 [details] dmesg with drm.debug=0x0e
The fundamental issue here is that only 32 MB of memory are reserved as VRAM for the GPU. https://patchwork.freedesktop.org/patch/192451/ should fix it (with DC enabled).
(In reply to Michel Dänzer from comment #3) > The fundamental issue here is that only 32 MB of memory are reserved as VRAM > for the GPU. > > https://patchwork.freedesktop.org/patch/192451/ should fix it (with DC > enabled). I applied both [1] and [2], also enabled DC for it, now the Unity Desktop is garbled. Unity Greeter in LightDM is fine though. [1] https://patchwork.freedesktop.org/patch/192451/ [2] https://patchwork.freedesktop.org/patch/192450/
Created attachment 136191 [details] Garbled display.
Hmm, maybe a separate DC patch is needed as well. Christian?
Hi Michel, Before the buffer been pined to a location, can the buffer be moved to other place? My opinion, this is not about VRAM size, it is the mechanism of buffer move. Is this buffer content of rendering output or source or it is GPU command buffer? Is there any better way we can narrow down or investigate?
(In reply to Alex_Zhang1 from comment #7) Without the patch referenced in comment 3, a buffer must be pinned to VRAM before it can be scanned out (displayed). The problem described in this report happens because pinning to VRAM fails, because there isn't enough space in VRAM. The patch allows buffers to be pinned to GTT instead of VRAM for scanout. Another DC patch is probably needed to fix the garbled display described in comment 4. Maybe try the patch on top of the amd-staging-drm-next branch.
Created attachment 136321 [details] [review] DC scatter gather patch You'll need this DC patch.
Hi Harry, I'm wondering if there is also an equivalence method to fix it on v4.13 kernel.
(In reply to Harry Wentland from comment #9) > Created attachment 136321 [details] [review] [review] > DC scatter gather patch > > You'll need this DC patch. Hi Harry, As patch below, + /* + * TODO debug why this doesn't work on Raven + */ + if (adev->flags & AMD_IS_APU && + adev->asic_type >= CHIP_CARRIZO && + adev->asic_type < CHIP_RAVEN) + init_data.flags.gpu_vm_support = true; Seems this is just for debug, if I am wrong, please correct me. Do the flags gpu_vm_support has support on 4.13 kernel? Could you please help to confirm if this patch can be used on 4.13 kernel? Thanks
(In reply to Harry Wentland from comment #9) > Created attachment 136321 [details] [review] [review] > DC scatter gather patch > > You'll need this DC patch. I can confirm that the issue is fixed by this patch (with the additional two patches above). Thanks.
(In reply to AceLan Kao from comment #10) > Hi Harry, > > I'm wondering if there is also an equivalence method to fix it on v4.13 > kernel. You could try applying the patches mentioned by Michel, plus my patch. I'm not sure whether they'll apply well or work. The DC patch shouldn't be a problem if it applies but I'm not sure about the other patches Michel mentioned.
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.