Plasma screen freezes at random times. You can move the mouse pointer around, but nothing else works. The system is still running and I'm able to ssh in from another system. To recover I need to kill and restart plasmashell
Steps to Reproduce:
Happens during normal use... haven't been able to pinpoint the exact cause. If I walk away from the system and return after an hour or so it sometimes is frozen. If I'm using the browser it sometimes freezes, if I'm using qmmp or another app, it sometimes freezes. I happens several times a day... this has been happening since May.
Normal system operation.
I have opened a bug in Fedora on this...
Other users have put extra symptoms into this bug... I do not want to obfuscate the issue I have been experiencing. This issue is to deal specifically with the Plasmashell freeze.
Created attachment 95053 [details]
gdb plasmashell freeze - after sitting overnight
This was captured from a freeze which occurred overnight.
To be clear, does krunner (ALT-F2) still work when this happens?
(I'm guessing yes, but thought it would be good to explicitly have that detail mentioned)
I experience regular freezes of plasmashell too. It happens a few times a day. I don't know if it is the same issue, but the symptoms look very similar. I'll attach a gdb backtrace of plasmashell.
When it happens: the panel doesn't respond to clicks anymore, the clock in the panel isn't updated, right-clicks on the desktop gives no response, my note widgets on the desktop don't respond anymore. But Alt-F2 still results in a still working Krunner and I can fully use all applications that were running.
This is on Fedora 22, X86_64, plasma-workspace-5.4.2-4.fc22.x86_64 (from updates-testing).
Created attachment 95103 [details]
plasmashell backtrace after it froze
(In reply to Rex Dieter from comment #3)
> (I'm guessing yes, but thought it would be good to explicitly have that
> detail mentioned)
Yes Rex, you are correct (and thanks BTW for providing that info).
(In reply to Gerd v. Egidy from comment #4)
> I experience regular freezes of plasmashell too. It happens a few times a
> day. I don't know if it is the same issue, but the symptoms look very
> similar. I'll attach a gdb backtrace of plasmashell.
I agree it appears to be the same problem.
>#0 0x00007fa6d92c2198 in QQuickShaderEffectSource::updatePaintNode(QSGNode*, QQuickItem::UpdatePaintNodeData*) (this=0x68013b0, oldNode=0x6f2d920)
Do you guys by any chance have the system load viewer plasmoid that looks like this?
More specifically, with it set to "Compact Bar" which has the gradients.
(In reply to David Edmundson from comment #9)
> More specifically, with it set to "Compact Bar" which has the gradients.
No, I have never used that plasmoid... and I have never had an issue with things not being displayed properly. This issue is only involves the freezing of the desktop.
Answered question, removing NEEDSINFO tag.
@David: I'm using the system load viewer with "Compact Bar". The load viewer just wastes too much space without it.
And it froze again just 5 minutes ago...
Maybe the issues Gerald and I'm experiencing are two different issues? Or maybe Gerald is using some other plasmoid which uses gradients.
But just to test it, I've switched the system load viewer to "Bar" and will run it like that for a few hours. I'll then report back if it keeps freezing that often.
Created attachment 95105 [details]
backtrace of the feeze some minutes ago (system load viewer was still on "compact bar")
Gerd. v. Egidy - yours is bug 348385
Lets track that there. (there's a QML file I need someone to run to get some info)
Gerald Cox - yours is something else. Not something I've seen before
>You can move the mouse pointer around, but nothing else works
Can you still drag windows around?
(In reply to David Edmundson from comment #14)
> Gerd. v. Egidy - yours is bug 348385
> Lets track that there. (there's a QML file I need someone to run to get some
> Gerald Cox - yours is something else. Not something I've seen before
> >You can move the mouse pointer around, but nothing else works
> Can you still drag windows around?
No and the clock doesn't update either.
I have you can't move windows, then it's (probably) not just plasmashell freezing, but at least kwin too and possibly more.
can I have the output of:
qdbus org.kde.KWin /KWin supportInformation
Won't be able to respond to this request until I return state side mid November. Regarding Rex's comments regarding Kwin... Using it with LXQt with no issues.
> Regarding Rex's comments regarding Kwin... Using it with LXQt with no issues.
Thanks, but largely irrelevant here
(In reply to Rex Dieter from comment #19)
> Thanks, but largely irrelevant here
Actually not - the fedora bug (and the one backtrace here) seems to point a deadlock in dri3 which is
a) an upstream bug (affecting every GL client)
b) somewhat supported by a "no problem with far less GL contexts" claim
If plasmashell (or kwin for that matter) *hangs* (doesn't leave _xcb_conn_wait) in
Thread 1 (Thread 0x7fe8a2067900 (LWP 1502)):
#0 0x0000003eafef72fd in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x0000003eb420a182 in _xcb_conn_wait (__timeout=-1, __nfds=1, __fds=0x7fffac1a68d0) at /usr/include/bits/poll2.h:46
#2 0x0000003eb420a182 in _xcb_conn_wait (c=c@entry=0x1d88460, cond=cond@entry=0x494f578, vector=vector@entry=0x0, count=count@entry=0x0) at xcb_conn.c:459
#3 0x0000003eb420bd49 in xcb_wait_for_special_event (c=c@entry=0x1d88460, se=0x494f550) at xcb_in.c:744
#4 0x0000003373649e72 in dri3_find_back (c=c@entry=0x1d88460, priv=priv@entry=0x48d0600) at dri3_glx.c:1263
#5 0x000000337364ac8f in dri3_get_buffers (driDrawable=<optimized out>, loaderPrivate=0x48d0600, buffer_type=dri3_buffer_back, format=4099) at dri3_glx.c:1289
#6 0x000000337364ac8f in dri3_get_buffers (driDrawable=<optimized out>, format=4099, stamp=0x48ac330, loaderPrivate=0x48d0600, buffer_mask=<optimized out>, buffers=0x7fffac1a6b70) at dri3_glx.c:1466
#7 0x00007fe8927e5a33 in dri2_allocate_textures (statts_count=<optimized out>, statts=<optimized out>, images=<optimized out>, drawable=<optimized out>) at dri2.c:279
#8 0x00007fe8927e5a33 in dri2_allocate_textures (ctx=0x29ab710, drawable=0x48ac330, statts=0x4a6bea8, statts_count=2) at dri2.c:402
#9 0x00007fe8927e2bec in dri_st_framebuffer_validate (stctx=<optimized out>, stfbi=<optimized out>, statts=0x4a6bea8, count=2, out=0x7fffac1a6d00) at dri_drawable.c:83
#10 0x00007fe8927193fe in st_framebuffer_validate (stfb=0x4a6ba60, st=st@entry=0x2a55a50) at state_tracker/st_manager.c:200
#11 0x00007fe89271a979 in st_manager_validate_framebuffers (st=st@entry=0x2a55a50) at state_tracker/st_manager.c:867
#12 0x00007fe8926e7657 in st_validate_state (st=st@entry=0x2a55a50) at state_tracker/st_atom.c:181
#13 0x00007fe8926ee3b1 in st_Clear (ctx=0x2a0c3d0, mask=50) at state_tracker/st_cb_clear.c:469
That's like https://bugs.freedesktop.org/show_bug.cgi?id=84252#c58 and thus either in some common MESA code or xcb/X11 as M. Dänzer pointed out.
==> I'd suggest to try disabling dri3
---------- snip /etc/X11/xorg.conf.d/20-gpu.conf ----------
Identifier "My fancy GPU"
Driver "intel" # "radeon" in case you use, well, the radeon driver...
Option "DRI" "3"
------------ / snip ---------------------------------
NOTICE that you may already have a GPU config snippet. In that case please just add the
Option "DRI" "3"
obviously it'd better be
Option "DRI" "2"
... sorry :-P
(In reply to Thomas Lübking from comment #20)
> ==> I'd suggest to try disabling dri3
Thanks, I will do that when I return home and report the results here with the kwin information requested above.
qdbus org.kde.KWin /KWin supportInformation
KWin Support Information:
The following information should be used when requesting support on e.g. http://forum.kde.org.
It provides information about the currently running instance, which options are used,
what OpenGL driver and which effects are running.
Please post the information provided underneath this introductory text to a paste bin service
like http://paste.kde.org instead of pasting into support threads.
KWin version: 5.4.2
Qt Version: 5.5.1
Qt compile version: 5.5.0
XCB compile version: 1.11
Operation Mode: X11 only
Vendor: Fedora Project
Vendor Release: 11799902
Protocol Version/Revision: 11/0
SHAPE: yes; Version: 0x11
RANDR: yes; Version: 0x14
DAMAGE: yes; Version: 0x11
Composite: yes; Version: 0x4
RENDER: yes; Version: 0xb
XFIXES: yes; Version: 0x50
SYNC: yes; Version: 0x31
GLX: yes; Version: 0x0
decorationButtonsLeft: 0, 2
decorationButtonsRight: 6, 3, 4, 5
Active screen follows mouse: no
Number of Screens: 1
Refresh Rate: 60
Compositing is active
Compositing Type: OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN (DRM 2.43.0, LLVM 3.7.0)
OpenGL version string: 3.0 Mesa 11.0.3 (git-b4bfea0)
OpenGL platform interface: GLX
OpenGL shading language version string: 1.30
GPU class: Unknown
OpenGL version: 3.0
GLSL version: 1.30
Mesa version: 11.0.3
Linux kernel version: 4.2.5
Direct rendering: Requires strict binding: yes
GLSL shaders: yes
Texture NPOT support: yes
Virtual Machine: no
OpenGL 2 Shaders are used
Painting blocks for vertical retrace: no
Currently Active Effects:
Also have/had this problem; seem to have solved it permanently with "export LIBGL_DRI3_DISABLE=1" entered into a terminal? Not entirely certain if that method itself is permanent, but the effect seems to have persisted through a couple test reboots.
I'm running a Radeon 6670 with the OSS drivers that ship normally with Tumbleweed.
My steps to reproduce were fairly simple:
Try to start YaST Control Center (supplied with openSUSE Tumbleweed), as that would cause the freeze reliably, whereas Firefox would intermittently hang up Plasma for no clear reason.
Not sure if this is related, but I get the following in my logs as well when starting Plasma, along with a good bit of a wait for the progress bar to complete:
kernel: [ 73.037371] QXcbEventReader: segfault at 7f2f92909e29 ip 00007f2f92909e29 sp 00007f2f905b5ea0 error 14 in icudt56l.dat[7f2f92db8000+17e3000]
Hope this helps a little. Will chime back in if the freezes resurface.
(In reply to J from comment #24)
> Not entirely certain if that method itself is permanent
No. It applies to the shell your entered it to and usually subshells.
You'd have to add it to eg. /etc/profile
> Not sure if this is related, but I get the following in my logs as well when
something crashed. Unfortunately "QXcbEventReader" is a bit unspecific - it's however unlikely the cause of later stalls. Also see
> starting Plasma, along with a good bit of a wait for the progress bar to
Can you translate that to "seconds"?
(In reply to Thomas Lübking from comment #25)
> (In reply to J from comment #24)
> > Not entirely certain if that method itself is permanent
> No. It applies to the shell your entered it to and usually subshells.
> You'd have to add it to eg. /etc/profile
> > Not sure if this is related, but I get the following in my logs as well when
> something crashed. Unfortunately "QXcbEventReader" is a bit unspecific -
> it's however unlikely the cause of later stalls. Also see
> > starting Plasma, along with a good bit of a wait for the progress bar to
> > complete:
> Can you translate that to "seconds"?
Will do, thanks.
As regards delays, well into 15+ seconds. I think it's maybe not KDE and maybe *is* SDDM or something low-level like that - I installed the beta 5.5 version of Plasma/KF5/Apps/Qt5 (which had a black desktop, but I digress) earlier and the startup pause was effectively identical.
Based on my research last night, I wondering if DRI3 is messing up XCB's event handling and causing this irrevocable halt condition, a problem exacerbated when you have something like Firefox *and* another program like System Log Viewer running - they both jam into the doorway.
Either I got lucky last night or that export flag *did* work - because general performance and visual responsiveness drastically improved after entering it and nothing I could do would seize up the desktop.
Hope this helps clarify a little - much of it is lower level than I'm comfortable with poking at my knowledge level.
Exporting environments does especially *not* impact running processes.
Did you maybe also update MESA or kernel?
(In reply to Thomas Lübking from comment #27)
> Exporting environments does especially *not* impact running processes.
> Did you maybe also update MESA or kernel?
Updates for both pre-date these issues, which is why it was such _odd_ behavior. MESA and the kernel both were semi-recently updated.
Here's links to the last two snapshot update changelogs in chronological order if you want to see what overall changes were made systemwide:
I've since added the flag to /etc/profile.d, and also switched a repo over to the latest available version of Qt5. Have not had a freeze occur so far, but it's been extremely random and spurious.
We haven't had any feedback on this issue for about a year now. The last comments indicate that updating drivers might have fixed the problem. So I'm setting to upstream.
In case you are still experiencing this issue please reopen.