From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 107045] [4.18rc2] RX470 dGPU on hybrid laptop freezes screen after use Date: Fri, 31 Aug 2018 19:21:15 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0751894798==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 2480D6E04F for ; Fri, 31 Aug 2018 19:21:15 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0751894798== Content-Type: multipart/alternative; boundary="15357432750.e8C66.23247" Content-Transfer-Encoding: 7bit --15357432750.e8C66.23247 Date: Fri, 31 Aug 2018 19:21:15 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated https://bugs.freedesktop.org/show_bug.cgi?id=3D107045 --- Comment #22 from taijian@posteo.de --- OK, after some further testing, here is some more information on my issue: 1) It turns out that the crashing/hanging behaviour ONLY happens when I'm logged into a graphical session (GNOME in my case). When working exclusively from a tty, then the system remains stable. 2) A Wayland session seems to be slightly more stable/resillient to crashing than an X11 session. While the latter crashes almost immediately when doing anything with the backlight, the former goes through a couple of cycles of extreme lag, stuttering and recovery before finally succumbing to whatever = the problem is. 3) I can reliably and reproduceably crash my graphical session by messing w= ith screen brightness in any way - either through the tools of the graphical sh= ell or by doing #echo X > /sys/class/backlight/intel_backlight/brightness. 4) Why is this an amdgpu bug then? Because the issue only arises when amdgp= u is loaded in DC mode, because in this mode the display connectors directly connected to the dGPU (DP, eDP and HDMI) are being ennumerated. With dc=3D0= they are not recognized and can therefore not create any problems. 5) What I think happens is that the graphical shell tries to adjust brightn= ess on the displays that are ennumerated as connectors but not actually connect= ed, and by doing so eventually get amdgpu to crash irrecoverably.=20 6) When intel_backlight gets manipulated, the following always shows up in dmesg (the first couple of times the dGPU gets to the 'reset', at some poin= t is just crashes before that, taking the system with it). Aug 31 17:58:54 alien-arch kernel: [drm] PCIE GART of 256M enabled (table at 0x000000F400000000). Aug 31 17:58:54 alien-arch kernel: amdgpu: [powerplay]=20 failed to send message 62 ret is 0=20 Aug 31 17:58:54 alien-arch kernel: amdgpu: [powerplay]=20 last message was failed ret is 0 Aug 31 17:58:55 alien-arch kernel: amdgpu: [powerplay]=20 failed to send message 18f ret is 0=20 Aug 31 17:58:55 alien-arch kernel: [drm] UVD and UVD ENC initialized successfully. Aug 31 17:58:55 alien-arch kernel: [drm] VCE initialized successfully. Aug 31 17:58:56 alien-arch kernel: [drm] Cannot find any crtc or sizes Aug 31 17:58:57 alien-arch kernel: amdgpu: [powerplay]=20 failed to send message 15b ret is 0=20 Aug 31 17:58:58 alien-arch kernel: amdgpu: [powerplay]=20 failed to send message 155 ret is 0=20 Aug 31 17:59:06 alien-arch kernel: amdgpu: [powerplay]=20 failed to send message 281 ret is 0=20 Aug 31 17:59:07 alien-arch kernel: amdgpu: [powerplay]=20 last message was failed ret is 0 Aug 31 17:59:07 alien-arch kernel: amdgpu: [powerplay]=20 failed to send message 261 ret is 0=20 Aug 31 17:59:08 alien-arch kernel: amdgpu: [powerplay]=20 last message was failed ret is 0 Aug 31 17:59:08 alien-arch kernel: amdgpu: [powerplay]=20 failed to send message 261 ret is 0=20 Aug 31 17:59:09 alien-arch kernel: amdgpu: [powerplay]=20 last message was failed ret is 0 Aug 31 17:59:10 alien-arch kernel: amdgpu: [powerplay]=20 failed to send message 261 ret is 0=20 Aug 31 17:59:10 alien-arch kernel: amdgpu: [powerplay]=20 last message was failed ret is 0 Aug 31 17:59:11 alien-arch kernel: amdgpu: [powerplay]=20 failed to send message 261 ret is 0=20 Aug 31 17:59:12 alien-arch kernel: amdgpu: [powerplay]=20 last message was failed ret is 0 Aug 31 17:59:12 alien-arch kernel: amdgpu: [powerplay]=20 failed to send message 261 ret is 0=20 Aug 31 17:59:13 alien-arch kernel: amdgpu: [powerplay]=20 last message was failed ret is 0 Aug 31 17:59:13 alien-arch kernel: amdgpu: [powerplay]=20 failed to send message 261 ret is 0=20 Aug 31 17:59:14 alien-arch kernel: amdgpu: [powerplay]=20 last message was failed ret is 0 Aug 31 17:59:14 alien-arch kernel: amdgpu: [powerplay]=20 failed to send message 261 ret is 0=20 Aug 31 17:59:14 alien-arch kernel: amdgpu 0000:01:00.0: GPU pci config reset --=20 You are receiving this mail because: You are the assignee for the bug.= --15357432750.e8C66.23247 Date: Fri, 31 Aug 2018 19:21:15 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated

Comme= nt # 22 on bug 10704= 5 from taijian@posteo.d= e 
OK, after some further testing, here is some more information =
on my issue:

1) It turns out that the crashing/hanging behaviour ONLY happens when I'm
logged into a graphical session (GNOME in my case). When working exclusively
from a tty, then the system remains stable.

2) A Wayland session seems to be slightly more stable/resillient to crashing
than an X11 session. While the latter crashes almost immediately when doing
anything with the backlight, the former goes through a couple of cycles of
extreme lag, stuttering and recovery before finally succumbing to whatever =
the
problem is.

3) I can reliably and reproduceably crash my graphical session by messing w=
ith
screen brightness in any way - either through the tools of the graphical sh=
ell
or by doing #echo X > /sys/class/backlight/intel_backlight/brightness.

4) Why is this an amdgpu bug then? Because the issue only arises when amdgp=
u is
loaded in DC mode, because in this mode the display connectors directly
connected to the dGPU (DP, eDP and HDMI) are being ennumerated. With dc=3D0=
 they
are not recognized and can therefore not create any problems.

5) What I think happens is that the graphical shell tries to adjust brightn=
ess
on the displays that are ennumerated as connectors but not actually connect=
ed,
and by doing so eventually get amdgpu to crash irrecoverably.=20

6) When intel_backlight gets manipulated, the following always shows up in
dmesg (the first couple of times the dGPU gets to the 'reset', at some poin=
t is
just crashes before that, taking the system with it).


Aug 31 17:58:54 alien-arch kernel: [drm] PCIE GART of 256M enabled (table at
0x000000F400000000).
Aug 31 17:58:54 alien-arch kernel: amdgpu: [powerplay]=20
                                    failed to send message 62 ret is 0=20
Aug 31 17:58:54 alien-arch kernel: amdgpu: [powerplay]=20
                                    last message was failed ret is 0
Aug 31 17:58:55 alien-arch kernel: amdgpu: [powerplay]=20
                                    failed to send message 18f ret is 0=20
Aug 31 17:58:55 alien-arch kernel: [drm] UVD and UVD ENC initialized
successfully.
Aug 31 17:58:55 alien-arch kernel: [drm] VCE initialized successfully.
Aug 31 17:58:56 alien-arch kernel: [drm] Cannot find any crtc or sizes
Aug 31 17:58:57 alien-arch kernel: amdgpu: [powerplay]=20
                                    failed to send message 15b ret is 0=20
Aug 31 17:58:58 alien-arch kernel: amdgpu: [powerplay]=20
                                    failed to send message 155 ret is 0=20
Aug 31 17:59:06 alien-arch kernel: amdgpu: [powerplay]=20
                                    failed to send message 281 ret is 0=20
Aug 31 17:59:07 alien-arch kernel: amdgpu: [powerplay]=20
                                    last message was failed ret is 0
Aug 31 17:59:07 alien-arch kernel: amdgpu: [powerplay]=20
                                    failed to send message 261 ret is 0=20
Aug 31 17:59:08 alien-arch kernel: amdgpu: [powerplay]=20
                                    last message was failed ret is 0
Aug 31 17:59:08 alien-arch kernel: amdgpu: [powerplay]=20
                                    failed to send message 261 ret is 0=20
Aug 31 17:59:09 alien-arch kernel: amdgpu: [powerplay]=20
                                    last message was failed ret is 0
Aug 31 17:59:10 alien-arch kernel: amdgpu: [powerplay]=20
                                    failed to send message 261 ret is 0=20
Aug 31 17:59:10 alien-arch kernel: amdgpu: [powerplay]=20
                                    last message was failed ret is 0
Aug 31 17:59:11 alien-arch kernel: amdgpu: [powerplay]=20
                                    failed to send message 261 ret is 0=20
Aug 31 17:59:12 alien-arch kernel: amdgpu: [powerplay]=20
                                    last message was failed ret is 0
Aug 31 17:59:12 alien-arch kernel: amdgpu: [powerplay]=20
                                    failed to send message 261 ret is 0=20
Aug 31 17:59:13 alien-arch kernel: amdgpu: [powerplay]=20
                                    last message was failed ret is 0
Aug 31 17:59:13 alien-arch kernel: amdgpu: [powerplay]=20
                                    failed to send message 261 ret is 0=20
Aug 31 17:59:14 alien-arch kernel: amdgpu: [powerplay]=20
                                    last message was failed ret is 0
Aug 31 17:59:14 alien-arch kernel: amdgpu: [powerplay]=20
                                    failed to send message 261 ret is 0=20
Aug 31 17:59:14 alien-arch kernel: amdgpu 0000:01:00.0: GPU pci config rese=
t

You are receiving this mail because:
  • You are the assignee for the bug.
= --15357432750.e8C66.23247-- --===============0751894798== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0751894798==--