Bug 108221 - amdgpu: mouse cursor flickers + black boxes
Summary: amdgpu: mouse cursor flickers + black boxes
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-21 10:11 UTC by Fred Santos
Modified: 2016-01-27 07:21 UTC (History)
2 users (show)

See Also:
Kernel Version: >= 4.3.0-7
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
Log: Xorg.0.log (78.87 KB, text/plain)
2016-01-18 07:36 UTC, Fred Santos
Details
xorg.log on r9-380 (50.83 KB, text/x-log)
2016-01-18 14:07 UTC, Ondřej Súkup
Details
xorg log r9-380 (42.77 KB, application/octet-stream)
2016-01-18 14:08 UTC, Ondřej Súkup
Details

Description Fred Santos 2015-11-21 10:11:37 UTC
For kernel >= 4.3.0-3:
Mouse cursor constantly flickers and disappears. A black box stays on screen when clicking on some elements of the GNOME desktop.
More generally, there are problems with screen refresh.
The problem is present only since an update to the kernel 4.3.0-3, the first versions of 4.3.x were OK for me. Recent updates of the kernel and amdgpu did not help.

Details about hardware:
#/sbin/lspci -nnv | grep 'VGA' -A2
	Flags: bus master, VGA palette snoop, 66MHz, medium devsel, latency 64
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=64

--
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Tonga PRO [Radeon R9 285/380] [1002:6939] (rev f1) (prog-if 00 [VGA controller])
	Subsystem: XFX Pine Group Inc. Device [1682:9380]
	Flags: bus master, fast devsel, latency 0, IRQ 38


# glxinfo
name of display: :0
display: :0  screen: 0
direct rendering: Yes
[...]
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD TONGA (DRM 3.1.0, LLVM 3.7.0)
OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.0.2
OpenGL core profile shading language version string: 4.10
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
Comment 1 Alex Deucher 2015-11-23 14:52:22 UTC
Can you bisect?
Comment 2 Fred Santos 2015-11-24 09:20:51 UTC
I'm not familiar with git, but I can try to learn how to do that. I'll tell you!

For now, I just can say that the problem appears to have started with an update providing:
- Linux kernel 4.3.0-3
- xf86-video-amdgpu ~git20151105
- xf86-video-ati ~git201501122
everything being obtained on openSUSE repos.
(Sorry if this is only a very rough information.)
Comment 3 Michel Dänzer 2015-11-25 03:37:17 UTC
FWIW, xf86-video-ati is irrelevant for Tonga.
Comment 4 Fred Santos 2016-01-17 09:51:24 UTC
(Probably won't help much, but the problem is still present with kernel 4.4.0 and the latest version of amdgpu.
For the bug itself, I also forgot to mention that the mouse pointer leaves trails all over the screen.) 

I also add a link to a bug submitted by someone else on bugzilla.opensuse.org, so the bug can be confirmed.
Comment 5 Michel Dänzer 2016-01-18 06:41:41 UTC
Please attach the Xorg log file and the output of xrandr when the problem occurs.
Comment 6 Fred Santos 2016-01-18 07:36:32 UTC
Created attachment 200361 [details]
Log: Xorg.0.log
Comment 7 Fred Santos 2016-01-18 07:37:35 UTC
And here is the output of xrandr (the problem *always* and *constantly* occurs):

Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
DP-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 521mm x 293mm
   1920x1080      59.9*+   60.0     50.0     59.9 
   1920x1080i     60.1     50.0     60.0 
   1600x1200      75.0     70.0     65.0     60.0 
   1680x1050      59.9 
   1400x1050      74.8     60.0     59.9 
   1280x1024      75.0     60.0 
   1440x900       59.9 
   1280x960       60.0 
   1152x864       75.0 
   1280x720       60.0     50.0     59.9 
   1440x576       50.0 
   1024x768       75.0     60.0     75.1     75.0     70.1     60.0 
   960x720        75.0     60.0 
   1440x480       60.0     59.9 
   928x696        75.0     60.1 
   896x672        75.0     60.0 
   832x624        74.6 
   800x600        75.0     70.0     65.0     60.0     72.2     75.0     60.3     56.2 
   720x576        50.0 
   720x576i       50.1 
   700x525        74.8     60.0 
   720x480        60.0     59.9 
   720x480i       60.1     60.1 
   640x512        75.0     60.0 
   640x480        60.0     75.0     72.8     72.8     75.0     66.7     60.0     59.9 
   720x400        70.1 
   576x432        75.0 
   512x384        75.0     70.1     60.0 
   416x312        74.7 
   400x300        72.2     75.1     60.3     56.3 
   320x240        72.8     75.0     60.1 
DVI-D-1 disconnected (normal left inverted right x axis y axis)
DVI-I-1 disconnected (normal left inverted right x axis y axis)
Comment 8 Michel Dänzer 2016-01-18 07:57:19 UTC
Looks like xf86-video-amdgpu wasn't installed correctly, so Xorg can't find it and uses the generic modesetting driver instead. Does the problem persist if you actually use xf86-video-amdgpu (preferably a newer snapshot than from last November)?
Comment 9 Fred Santos 2016-01-18 08:24:41 UTC
Thanks for your answer.

Yes, the log is quite strange about that, since xf86-video-amdgpu is indeed installed, but doesn't seem to be found... (Is there a way to 'force' the use of amdgpu?)

Btw, the problem occurs even with a Live USB of the latest snapshot of openSUSE Tumbleweed for example (with kernel 4.4.0-2 too), so it should be easily reproducible by owners of Tonga GPUs.
(Well... I hope the problem is not openSUSE-specific...)
Comment 10 Michel Dänzer 2016-01-18 09:56:11 UTC
(In reply to Fred Santos from comment #9)
> Yes, the log is quite strange about that, since xf86-video-amdgpu is indeed
> installed, but doesn't seem to be found...

Maybe 10-amdgpu.conf isn't installed in /usr/share/X11/xorg.conf.d .


> (Is there a way to 'force' the use of amdgpu?)

Yes, you can force it in Section "Device" in /etc/X11/xorg.conf . If there is no such file yet, creating it with only something like this should work:

Section "Device"
        Identifier "Device0"
        Driver  "amdgpu"
EndSection
Comment 11 Ondřej Súkup 2016-01-18 14:07:35 UTC
Created attachment 200391 [details]
xorg.log on r9-380

with Xorg autodetection...
Comment 12 Ondřej Súkup 2016-01-18 14:08:26 UTC
Created attachment 200401 [details]
xorg log r9-380

with /etc/X11/xorg.conf.d/10-amdgpu.conf
Comment 13 Michel Dänzer 2016-01-19 09:30:20 UTC
(In reply to Fred Santos from comment #0)
> The problem is present only since an update to the kernel 4.3.0-3, the first
> versions of 4.3.x were OK for me.

Can you find out what changed in 4.3.0-3 compared to the previous kernel you were using that worked OK?
Comment 14 Fred Santos 2016-01-22 08:36:16 UTC
(In reply to Michel Dänzer from comment #10)
> (In reply to Fred Santos from comment #9)
> > (Is there a way to 'force' the use of amdgpu?)
> 
> Yes, you can force it in Section "Device" in /etc/X11/xorg.conf . If there
> is no such file yet, creating it with only something like this should work:
> 
> Section "Device"
>         Identifier "Device0"
>         Driver  "amdgpu"
> EndSection

I compiled and booted some old kernels, and here are my observations:

1. Even when booting with old kernels that should have worked fine (e.g., 4.2), the problem persists...

2. We found (Comment #10) that amdgpu was not found/activated during boot: when 'forcing' its use by creating this /etc/X11/xorg.conf file, everything is OK, with all kernels I have tested (4.4, 4.3, 4.2). To put it in a nutshell, no matter the kernel we use, we have the same behavior: it works if and only if we add this /etc/X11/xorg.conf file.

Maybe an Xorg autodetection problem that doesn't come from the kernel itself? (Is it possible?)
Comment 15 Michel Dänzer 2016-01-27 07:21:46 UTC
(In reply to Fred Santos from comment #14)
> 2. We found (Comment #10) that amdgpu was not found/activated during boot:
> when 'forcing' its use by creating this /etc/X11/xorg.conf file, everything
> is OK, with all kernels I have tested (4.4, 4.3, 4.2). To put it in a
> nutshell, no matter the kernel we use, we have the same behavior: it works
> if and only if we add this /etc/X11/xorg.conf file.

If /etc/X11/xorg.conf.d/10-amdgpu.conf / /usr/share/X11/xorg.conf.d/10-amdgpu.conf isn't enough, then it sounds like maybe the amdgpu kernel driver isn't loaded yet the first time Xorg starts up during boot.

Also, it sounds like there's a bug in the Xorg modesetting driver causing the artifacts you described.

Probably no kernel bug here though.

Note You need to log in before you can comment on or make changes to this bug.