| Bug ID | 111244 |
|---|---|
| Summary | amdgpu kernel 5.2 blank display after resume from suspend |
| Product | DRI |
| Version | DRI git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | cspack@verizon.net |
Created attachment 144901 [det=
ails]
kernel log
Model: Lenovo Ideapad S340 15"
CPU: AMD Ryzen 5 3500U
Starting with kernel 5.2, laptop has a blank display after resuming from
suspend. Problem doesn't appear with recent kernels up to 5.1.16. Attached =
is a
kernel log and git bisect logs.
Created attachment 144902 <=
a href=3D"attachment.cgi?id=3D144902&action=3Dedit" title=3D"first bise=
ct log">[details]
first bisect log
Created attachment 144903 =
[details]
second bisect log
| What | Removed | Added |
|---|---|---|
| Attachment #144901 mime type | text/x-log | text/plain |
| What | Removed | Added |
|---|---|---|
| CC | nicholas.kazlauskas@amd.com |
The fact that you got two different bisection results indicate= s that the problem might be not 100% reproducible, and you accidentally marked some affected commits as good. Please test a given commit longer / more often be= fore declaring it "good".
The first bisect pointed to a merge commit so the second was d= one to bisect within the merged commits.
(In reply to cspack from comment #4) > The first bisect pointed to a merge commit so th= e second was done to bisect > within the merged commits. That doesn't invalidate my previous comment. :) git bisect identifying a me= rge commit already indicates the same thing by itself. In particular, the fact = that it identified a merge commit means that you declared all of its parent comm= its good. (There *are* rare cases where a problem is actually introduced by a merge commit itself, but then the second bisection should have either identified = the same merge commit again (if you tested it again), or failed, because all the other commits you tested should have been good again.)
I see your point, and you are correct. It seems the issue is n=
ot 100%
reproducible. I will redo the bisect and test more thoroughly. Thank you.
| What | Removed | Added |
|---|---|---|
| Status | NEW | NEEDINFO |
@cspack I am currently repeating your bisection on similar= hardware, however I have found 27eaa4927dc3be669ed70670241597ac73595caf to be bad. Could you pl= ease retest that commit as well?
Created attachment 144928 [details] Result of git bisect Model: HP EliteBook 745 G5 CPU/GPU: AMD Ryzen 7 PRO 2700U I completed my bisection and this is the log. The first bad commit seems to be this one. It's actually a fairly innocent commit, so it's probably causing a bug somewhere else. df8368be1382b442384507a5147c89978cd60702 is the first bad commit commit df8368be1382b442384507a5147c89978cd60702 Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Date: Wed Feb 27 12:56:36 2019 -0500 drm/amdgpu: Bump amdgpu version for per-flip plane tiling updates To help xf86-video-amdgpu and mesa know DC supports updating the tiling attributes for a framebuffer per-flip. Cc: Michel D=C3=A4nzer <mi= chel@daenzer.net> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Marek Ol=C5=A1=C3=A1k <marek.olsak@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Created attachment 1=
44929 [details]
Kernel log displaying issue
Compressed here is my kernel log, which shows repeating stack traces
Interestingly the same commit is blamed for anther issue https://bugs.freedesktop.org/show_bug.= cgi?id=3D111122
| What | Removed | Added |
|---|---|---|
| See Also | https://bugs.freedesktop.org/show_bug.cgi?id=3D111122 |
@Samuele Yes, after redoing the bisect I got the same resu= lt as you did. Thanks.
One thing to note, the problem doesn't seem to occur for me if= a compositor isn't running. In my case, after disabling compton I could not reproduce the problem.
| What | Removed | Added |
|---|---|---|
| Status | NEEDINFO | NEW |
Similar thing for me: disabling composition in Plasma makes su= spend/resume work again.
Another workaround is to switch to the text terminal (Ctrl+Alt= +F2) before suspending. Occuring on Thinkpad T495, Ryzej 3700U, openSUSE Tumbleweed (kernel 5.2.2-1= )
Are any other known workarounds? Perhaps some kernel options?<=
/pre>
This commit in xf86-video-amdgpu seem to be where things break https://github.com/freedesktop/xorg-= xf86-video-amdgpu/commit/a2b32e72fdaff3007a79b84929997d8176c2d512 Adding amdgpu.dc=3D1 to kernel options seems fix the issue for me.
Created attachment =
144967 [details]
xf86-video-amdgpu git bisect
| What | Removed | Added |
|---|---|---|
| Attachment #144967 mime type | text/x-log | text/plain |
(In reply to cspack from comment #16) > Adding amdgpu.dc=3D1 to kernel options seems fix= the issue for me. Presumably you mean amdgpu.dc=3D0 ? Your findings indicate that the kernel driver DC code doesn't handle flippi= ng between buffers with different tiling parameters correctly in some cases.