Bug 360443

Summary:	Kwin freezes -- mouse moves but nothing else works
Product:	[Plasma] kwin	Reporter:	Raman Gupta <rocketraman>
Component:	general	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED NOT A BUG
Severity:	normal	CC:	bastian.beischer
Priority:	NOR
Version First Reported In:	5.5.5
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	Xorg.0.log Output of KWin supportInformation

Description Raman Gupta 2016-03-12 17:57:02 UTC

I came back to my computer this morning and the mouse was moving, but the rest of the desktop was frozen. Mouse clicks did not do anything. No keyboard input worked, including Alt-Tab or anything else.

I was able to switch to a different VT with Ctrl-Alt-F2. I was able to restore correct operation by running:

DISPLAY=:0 kwin_x11 --replace

I have multiple (3) monitors.

There were no errors in /var/log/Xorg.0.log, except for something libinput related about removing a device:

...
[   205.216] (II) RADEON(0): Modeline "1680x1050"x0.0  119.00  1680 1728 1760 1840  1050 1053 1059 1080 +hsync -vsync (64.7 kHz e)
[ 10638.376] (II) config/udev: Adding input device 34:FC:EF:46:C0:C9 (/dev/input/event15)
[ 10638.376] (**) 34:FC:EF:46:C0:C9: Applying InputClass "evdev keyboard catchall"
[ 10638.376] (**) 34:FC:EF:46:C0:C9: Applying InputClass "libinput keyboard catchall"
[ 10638.376] (**) 34:FC:EF:46:C0:C9: Applying InputClass "system-keyboard"
[ 10638.376] (II) Using input driver 'libinput' for '34:FC:EF:46:C0:C9'
[ 10638.376] (**) 34:FC:EF:46:C0:C9: always reports core events
[ 10638.376] (**) Option "Device" "/dev/input/event15"
[ 10638.376] (**) Option "_source" "server/udev"
[ 10638.376] (II) input device '34:FC:EF:46:C0:C9', /dev/input/event15 is tagged by udev as: Keyboard
[ 10638.376] (II) input device '34:FC:EF:46:C0:C9', /dev/input/event15 is a keyboard
[ 10638.389] (**) Option "config_info" "udev:/sys/devices/virtual/input/input18/event15"
[ 10638.389] (II) XINPUT: Adding extended input device "34:FC:EF:46:C0:C9" (type: KEYBOARD, id 14)
[ 10638.389] (**) Option "xkb_model" "logiultraxc"
[ 10638.389] (**) Option "xkb_layout" "us"
[ 10638.389] (**) Option "xkb_options" "terminate:ctrl_alt_bksp,compose:ralt"
[ 10638.390] (II) input device '34:FC:EF:46:C0:C9', /dev/input/event15 is tagged by udev as: Keyboard
[ 10638.390] (II) input device '34:FC:EF:46:C0:C9', /dev/input/event15 is a keyboard
[ 22854.288] (II) config/udev: removing device 34:FC:EF:46:C0:C9

Unplugging and replugging the keyboard and mouse (actually switching the KVM they are attached to away and then back) did not help. I will attach the complete Xorg.0.log.

I use the open source Radeon driver (radeonsi) with a 7950 SI card.

Note that I don't have any screen blanking or screen savers enabled because of a different issue that monitors don't wake back up.

Reproducible: Sometimes




There are more debugging tips in this bugzilla: https://bugs.kde.org/show_bug.cgi?id=338999 but I needed to get back to work and didn't try them all. Will try next time it happens.

Comment 1 Raman Gupta 2016-03-12 18:00:01 UTC

Created attachment 97860 [details]
Xorg.0.log

Xorg.0.log for when the freeze happened.

It happened some time after timestamp 205.216 and some time before timestamp 55907.305 (which is when I switched the KVM away and back), but I don't know specifically when because I was AFK.

Comment 2 Thomas Lübking 2016-03-13 09:09:03 UTC

The keyboard was still working (you used it to switch to VT2 ...)

Please attach the output of "qdbus org.kde.KWin /KWin supportInformation" and next time this happens, check whether suspending the compositor (SHIFT+Alt+F12) is sufficient to resolve the state.

> Note that I don't have any screen blanking or screen savers enabled because of a different issue that monitors don't wake back up.

Does the session still lock?
Do the monitors turn into power saving or do you turn them off or does "any screen blanking" indeed mean you're keeping them active all the time?

Comment 3 Raman Gupta 2016-03-13 19:29:05 UTC

Created attachment 97874 [details]
Output of KWin supportInformation

Comment 4 Raman Gupta 2016-03-13 19:36:38 UTC

(In reply to Thomas Lübking from comment #2)
> Please attach the output of "qdbus org.kde.KWin /KWin supportInformation"

Done

> and next time this happens, check whether suspending the compositor
> (SHIFT+Alt+F12) is sufficient to resolve the state.

I will do that. It was fine this morning.

> > Note that I don't have any screen blanking or screen savers enabled because of a different issue that monitors don't wake back up.
> 
> Does the session still lock?
> Do the monitors turn into power saving or do you turn them off or does "any
> screen blanking" indeed mean you're keeping them active all the time?

The monitors do go into standby on their own, but don't always come out of standby (usually just one of them, the other two are fine). The session does not lock, so it seems to be a different issue. Right now, yes, I'm keeping them active all the time by turning off all the power saving options (`xset q` shows "DPMS is Disabled"). I have a feeling it might be a hardware issue because when it happens, because even a reboot does not fix it -- the same issue manifests even at the BIOS config screen, until the monitor is unplugged and replugged.

Comment 5 Thomas Lübking 2016-03-13 20:57:01 UTC

> OpenGL version string: 4.1 (Core Profile) Mesa 11.1.0 (git-525f3c2)
> OpenGL platform interface: EGL

Does it also happen with the GLX backend?

About the other thing, and to be very clear: the monitors illuminate your office all night long?
They do not turn off? Neither by dpms (ok, you clarified that ;-) nor by some power button on the monitor?

Comment 6 Raman Gupta 2016-03-13 21:39:51 UTC

(In reply to Thomas Lübking from comment #5)
> > OpenGL version string: 4.1 (Core Profile) Mesa 11.1.0 (git-525f3c2)
> > OpenGL platform interface: EGL
> 
> Does it also happen with the GLX backend?

Whoa, I enabled EGL a while ago when I read this blog post by Martin: http://blog.martin-graesslin.com/blog/2015/08/should-we-target-egl-as-the-default/ and then promptly forgot about it :-) That explains another issue I have been having too (repainting in Chrome, Intellij IDEA, and the taskbar, but only after a while), as rereading the comments, someone else reported the same thing (https://blog.martin-graesslin.com/blog/2015/08/should-we-target-egl-as-the-default/#comment-69540).

That being said, I'm willing to leave it on EGL to debug if this happens again, if you think that would be helpful to the KDE project. I'll try to repro again on EGL and if I can, then I'll switch to GLX to see if it continues to happen.

> About the other thing, and to be very clear: the monitors illuminate your
> office all night long?
> They do not turn off? Neither by dpms (ok, you clarified that ;-) nor by
> some power button on the monitor?

Correct, the way I have them set currently is that they illuminate my office all night long.

Comment 7 Thomas Lübking 2016-03-13 23:07:44 UTC

Let's say keeping around the EGL context next to the mass amount of GLX contexts (which afaik QtQuick windows still are) is not making things simpler for the OpenGL driver ;-)


---
Turning the monitor off and on (w/ the power button on the panel) isn't sufficient?

Comment 8 Raman Gupta 2016-03-13 23:30:27 UTC

(In reply to Thomas Lübking from comment #7)
> Let's say keeping around the EGL context next to the mass amount of GLX
> contexts (which afaik QtQuick windows still are) is not making things
> simpler for the OpenGL driver ;-)

Makes sense. Is it worth trying to understand if EGL is part of the problem here, and why? Or should I just switch to GLX and see if the problem happens again?

> ---
> Turning the monitor off and on (w/ the power button on the panel) isn't
> sufficient?

Two reasons: 1) Kwin/plasma starts doing weird things when I start turning monitors on and off and as I recall, windows don't always go back to where they were when everything is on again, and 2) The monitors don't always wake up from an off state either.

Comment 9 Martin Flöser 2016-03-14 15:45:37 UTC

yes please try whether it still happens with GLX. Also give a try to use an OpenGL 2 (compat) instead of a core profile. Similar argument: Qt doesn't use a core context so it might be better to also use a compat context in KWin.

Comment 10 Thomas Lübking 2016-03-14 16:15:43 UTC

(In reply to Raman Gupta from comment #8)

> Two reasons: 1) Kwin/plasma starts doing weird things when I start turning
> monitors on and off and as I recall, windows don't always go back to where
> they were when everything is on again



That one might be resolved with Qt 5.6

Comment 11 Raman Gupta 2016-03-14 16:23:22 UTC

(In reply to Martin Gräßlin from comment #9)
> yes please try whether it still happens with GLX.

So far it hasn't happened again even with EGL... too bad (sort of) this wasn't easier to reproduce :-(

> Also give a try to use an
> OpenGL 2 (compat) instead of a core profile. Similar argument: Qt doesn't
> use a core context so it might be better to also use a compat context in
> KWin.

Ok, this means changing the "Rendering backend" in the compositor settings to "OpenGL 2.0" right? So to summarize, the desired setting should be "OpenGL 2.0" with "GLX" for maximum compatibility with QT.

Comment 12 Thomas Lübking 2016-03-14 16:27:41 UTC

(In reply to Raman Gupta from comment #11)

> So to summarize, the desired setting should be
> "OpenGL 2.0" with "GLX" for maximum compatibility with QT.

Bingo.
(Though I consider crossing of EGL & GLX far worse reg. sync races than GL2 & GL3)

Comment 13 Bastian Beischer 2016-07-14 12:59:49 UTC

I'm suffering from random freezes in kwin which match the subject of this bug report as well.

I have an Intel GPU and I'm using driver version 26f8ab5 (SHA1 from Intel Driver git repository). My laptop is a Lenovo W520. I'm using "OpenGL 2.0" and "GLX" in compositor settings.

I'm using Qt 5.7 and KDE Plasma 5.7.1. I was able to attach with gdb to kwin_x11 last time the desktop froze (mouse is still moving but nothing is "clickable"):

(gdb) bt
#0  0x00007f1756d8c6cd in poll () from target:/usr/lib/libc.so.6
#1  0x00007f1755eee8e0 in ?? () from target:/usr/lib/libxcb.so.1
#2  0x00007f1755ef039f in ?? () from target:/usr/lib/libxcb.so.1
#3  0x00007f1755ef04b2 in xcb_wait_for_reply () from target:/usr/lib/libxcb.so.1
#4  0x00007f175217e727 in _XReply () from target:/usr/lib/libX11.so.6
#5  0x00007f174c82ea5a in ?? () from target:/usr/lib/libGL.so.1
#6  0x00007f174c82edb7 in ?? () from target:/usr/lib/libGL.so.1
#7  0x00007f172d15844a in ?? () from target:/usr/lib/xorg/modules/dri/i965_dri.so
#8  0x00007f172d158981 in ?? () from target:/usr/lib/xorg/modules/dri/i965_dri.so
#9  0x00007f172d15994a in ?? () from target:/usr/lib/xorg/modules/dri/i965_dri.so
#10 0x00007f172cf38933 in ?? () from target:/usr/lib/xorg/modules/dri/i965_dri.so
#11 0x00007f174f6da731 in KWin::GLVertexBuffer::draw(QRegion const&, unsigned int, int, int, bool) () from target:/usr/lib/libkwinglutils.so.8
#12 0x00007f174f6dab97 in KWin::GLVertexBuffer::render(QRegion const&, unsigned int, bool) () from target:/usr/lib/libkwinglutils.so.8
#13 0x00007f174f6dac3a in KWin::GLVertexBuffer::render(unsigned int) () from target:/usr/lib/libkwinglutils.so.8
#14 0x00007f1756948ff1 in ?? () from target:/usr/lib/libkwin.so.5
#15 0x00007f175694ecd5 in KWin::SceneOpenGL::paintBackground(QRegion) () from target:/usr/lib/libkwin.so.5
#16 0x00007f1756935c98 in ?? () from target:/usr/lib/libkwin.so.5
#17 0x00007f1756948f43 in ?? () from target:/usr/lib/libkwin.so.5
#18 0x00007f17569372a4 in ?? () from target:/usr/lib/libkwin.so.5
#19 0x00007f175696132f in KWin::EffectsHandlerImpl::paintScreen(int, QRegion, KWin::ScreenPaintData&) () from target:/usr/lib/libkwin.so.5
#20 0x00007f1753bd82ef in KWin::Effect::paintScreen(int, QRegion, KWin::ScreenPaintData&) () from target:/usr/lib/libkwineffects.so.8
#21 0x00007f17569612da in KWin::EffectsHandlerImpl::paintScreen(int, QRegion, KWin::ScreenPaintData&) () from target:/usr/lib/libkwin.so.5
#22 0x00007f1753bd82ef in KWin::Effect::paintScreen(int, QRegion, KWin::ScreenPaintData&) () from target:/usr/lib/libkwineffects.so.8
#23 0x00007f17569612da in KWin::EffectsHandlerImpl::paintScreen(int, QRegion, KWin::ScreenPaintData&) () from target:/usr/lib/libkwin.so.5
#24 0x00007f1756936f46 in ?? () from target:/usr/lib/libkwin.so.5
#25 0x00007f175694f988 in KWin::SceneOpenGL::paint(QRegion, QList<KWin::Toplevel*>) () from target:/usr/lib/libkwin.so.5
#26 0x00007f1756926ffb in KWin::Compositor::performCompositing() () from target:/usr/lib/libkwin.so.5
#27 0x00007f1754439303 in QObject::event(QEvent*) () from target:/usr/lib/libQt5Core.so.5
#28 0x00007f17550ece3c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from target:/usr/lib/libQt5Widgets.so.5
#29 0x00007f17550f45b1 in QApplication::notify(QObject*, QEvent*) () from target:/usr/lib/libQt5Widgets.so.5
#30 0x00007f175440cc80 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from target:/usr/lib/libQt5Core.so.5
#31 0x00007f175446051e in QTimerInfoList::activateTimers() () from target:/usr/lib/libQt5Core.so.5
#32 0x00007f175445e4a8 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from target:/usr/lib/libQt5Core.so.5
#33 0x00007f173d5510fd in ?? () from target:/usr/lib/libQt5XcbQpa.so.5
#34 0x00007f175440b0da in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from target:/usr/lib/libQt5Core.so.5
#35 0x00007f17544135cc in QCoreApplication::exec() () from target:/usr/lib/libQt5Core.so.5
#36 0x00007f17572754b5 in kdemain () from target:/usr/lib/libkdeinit5_kwin_x11.so
#37 0x00007f1756cce741 in __libc_start_main () from target:/usr/lib/libc.so.6
#38 0x0000000000400769 in _start ()

Killing kwin_x11 (with -9) and restarting it fixes the desktop.

Comment 14 Thomas Lübking 2016-07-14 13:24:46 UTC

looks like a bug in the intewl driver (where the original report was EGL on radeon, it's only the same symptom)

could be a dead lock, run "thread apply all bt" to dump all threads.
Also you best install debug symbols for mesa (and intel-dri) to see which GL call is lingering around there.
I doubt this came with an update of KWin but rather the kernel or mesa or the intel driver.
Maybe a reconfiguration (uxa/sni/glamor or using)

Please open a new bug in any case, you're wrong here ;-)

Comment 15 Raman Gupta 2016-08-07 18:59:56 UTC

I haven't had this happen again with the OpenGL 2.0 with GLX backend, so I'm going to close this for now. Thanks!