Bug 93800 - xfwm4 with compositing hangs indefinitely after after coming back from dpms off
Summary: xfwm4 with compositing hangs indefinitely after after coming back from dpms off
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: XOrg git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-20 18:26 UTC by Harald Judt
Modified: 2016-04-24 09:26 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg.0.log (151.79 KB, text/plain)
2016-01-20 18:26 UTC, Harald Judt
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Judt 2016-01-20 18:26:29 UTC
Created attachment 121158 [details]
Xorg.0.log

I'm not sure whether this belongs to mesa or xf86-video-ati or somewhere else, so I'll simply state the problem:

Steps to reproduce:
1) Start xfwm4 (latest git from master), which uses opengl for vsyncing to avoid screen tearing.
2) xset dpms force off; sleep 3; xset dpms force on

This alone is enough to make xfwm4 hang indefinitely. I've attached gdb to the xfwm4 process and got this backtrace:

Program received signal SIGINT, Interrupt.
0x00007f7584ffd50d in poll () at ../sysdeps/unix/syscall-template.S:84
84      in ../sysdeps/unix/syscall-template.S
#0  0x00007f7584ffd50d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f75846f8ac2 in poll (__timeout=-1, __nfds=1, __fds=0x7ffc8e0e2a80) at /usr/include/bits/poll2.h:46
#2  _xcb_conn_wait (c=c@entry=0x10fd820, cond=cond@entry=0x1447f88, vector=vector@entry=0x0, count=count@entry=0x0) at /var/tmp/portage/x11-libs/libxcb-1.11.1/work/libxcb-1.11.1/src/xcb_conn.c:459
#3  0x00007f75846fa7f9 in xcb_wait_for_special_event (c=0x10fd820, se=0x1447f60) at /var/tmp/portage/x11-libs/libxcb-1.11.1/work/libxcb-1.11.1/src/xcb_in.c:789
#4  0x00007f75817ef6db in dri3_wait_for_event (draw=draw@entry=0x1447608) at /var/tmp/portage/media-libs/mesa-9999/work/mesa-9999/src/loader/loader_dri3_helper.c:280
#5  0x00007f75817efa78 in loader_dri3_wait_for_msc (draw=0x1447608, target_msc=<optimized out>, divisor=<optimized out>, remainder=<optimized out>, ust=0x7ffc8e0e2cb8, msc=0x7ffc8e0e2cc0, sbc=0x7ffc8e0e2cd0)
    at /var/tmp/portage/media-libs/mesa-9999/work/mesa-9999/src/loader/loader_dri3_helper.c:314
#6  0x00007f75817ea8f1 in dri3_wait_for_msc (pdraw=<optimized out>, target_msc=<optimized out>, divisor=<optimized out>, remainder=<optimized out>, ust=<optimized out>, msc=<optimized out>, sbc=0x7ffc8e0e2cd0)
    at /var/tmp/portage/media-libs/mesa-9999/work/mesa-9999/src/glx/dri3_glx.c:389
#7  0x00000000004170a9 in wait_glx_vblank (screen_info=0x1216df0) at compositor.c:1424
#8  paint_all (buffer=<optimized out>, region=<optimized out>, screen_info=0x1216df0) at compositor.c:2202
#9  repair_screen (screen_info=<optimized out>) at compositor.c:2318
#10 compositor_timeout_cb (data=0x1216df0, data@entry=<error reading variable: value has been optimized out>) at compositor.c:2335
#11 0x00007f7585f66643 in g_timeout_dispatch (source=0x14ee290, callback=<optimized out>, user_data=<optimized out>) at /var/tmp/portage/dev-libs/glib-2.46.2-r1/work/glib-2.46.2/glib/gmain.c:4577
#12 0x00007f7585f65bad in g_main_dispatch (context=0x1129e70) at /var/tmp/portage/dev-libs/glib-2.46.2-r1/work/glib-2.46.2/glib/gmain.c:3154
#13 g_main_context_dispatch (context=context@entry=0x1129e70) at /var/tmp/portage/dev-libs/glib-2.46.2-r1/work/glib-2.46.2/glib/gmain.c:3769
#14 0x00007f7585f65f80 in g_main_context_iterate (context=0x1129e70, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at /var/tmp/portage/dev-libs/glib-2.46.2-r1/work/glib-2.46.2/glib/gmain.c:3840
#15 0x00007f7585f662a2 in g_main_loop_run (loop=0x148f2e0) at /var/tmp/portage/dev-libs/glib-2.46.2-r1/work/glib-2.46.2/glib/gmain.c:4034
#16 0x00007f758744b137 in IA__gtk_main () at /var/tmp/portage/x11-libs/gtk+-2.24.29/work/gtk+-2.24.29/gtk/gtkmain.c:1268
#17 0x000000000040d5d4 in main (argc=1, argv=0x7ffc8e0e3178) at main.c:686


Note this problem does not occur on another graphics card (sandybridge, haswell). I've tried to reproduce it using compiz, but it didn't happen that way (maybe it wasn't using vsync, don't know).

Here are the xorg settings:
Section "Device"
    Identifier  "ATI Radeon R9 390"
    Driver      "radeon"
    Option      "DRI3" "on"
    Option      "ColorTiling" "on"
    Option      "SwapbuffersWait" "on"
    Option      "EnablePageFlip" "on"
    Option      "ColorTiling2D" "on"
EndSection
Comment 1 Harald Judt 2016-01-20 18:30:18 UTC
This does not happen with Option "DRI3 "off".

Note I am using xf86-video-ati and mesa git, xorg-server is 1.17.4 and Linux 4.4.0.
Comment 3 Harald Judt 2016-01-21 21:00:32 UTC
The commit does not apply on top of 1.17.4, so I've updated to latest git master. Unfortunately, that did not fix anything, and it still hangs.
Comment 4 poma 2016-01-22 14:52:13 UTC
Oh, and I thought that this only applies to the nouveau,
https://bugs.freedesktop.org/show_bug.cgi?id=93795
Comment 5 poma 2016-01-22 15:08:16 UTC
DRI3 enablement on the nouveau does -not- cause the breakage, but GL(X) compositing itself.
Interesting, ain't.

/etc/X11/xorg.conf.d/nouveau-dri3.conf 
Section "Device"
    Identifier  "nvidia0"
    Driver      "nouveau"
    Option      "DRI" "3"
EndSection

xfwm4 --version
	This is xfwm4 version 4.12.3git.a64b743.20151126 (revision a64b743.20151126) for Xfce 4.12
	Released under the terms of the GNU General Public License.
	Compiled against GTK+-2.24.28, using GTK+-2.24.29.

	Build configuration and supported features:
	- Startup notification support:                 Yes
	- XSync support:                                Yes
	- Render support:                               Yes
	- Xrandr support:                               Yes
	- Xpresent support:                             No
	- Embedded compositor:                          Yes
	- Epoxy support:                                Yes
	- KDE systray proxy (deprecated):               No


SW:
xfwm4-4.12.3-22.3.glx.20151126.gita64b743.fc24.x86_64
xorg-x11-drv-nouveau-1.0.12-1.fc24.x86_64
mesa-dri-drivers-11.2.0-0.devel.6.5e3edd4.fc24.x86_64
xorg-x11-server-Xorg-1.18.0-2.fc24.x86_64
kernel-modules-4.5.0-0.rc0.git8.1.fc24.x86_64
Comment 6 poma 2016-01-22 18:42:04 UTC
(In reply to Michel Dänzer from comment #2)
> Can you try if
> http://cgit.freedesktop.org/xorg/xserver/commit/
> ?id=25eca80265654cfbf8768024e027426fedeb0918 helps?

FTR
I tested with this commit, and as for the nouveau it's business as usual, no change.

bye
Comment 7 Michel Dänzer 2016-01-27 08:00:56 UTC
It might be the kernel regression discussed in http://lists.freedesktop.org/archives/dri-devel/2016-January/098823.html and followups.
Comment 8 Harald Judt 2016-04-24 09:26:42 UTC
This is no longer reproducible with linux-4.5, so I am closing this. Thanks for looking into this.


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.