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 Reproducible: Always 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. Actual Results: plasmashell freezes Expected Results: Normal system operation. I have opened a bug in Fedora on this... https://bugzilla.redhat.com/show_bug.cgi?id=1217844 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? http://static.davidedmundson.co.uk/blog/plasma_addons_update/systemmonitor.png
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 > 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? 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 please
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 ---------- Section "Device" Identifier "My fancy GPU" Driver "intel" # "radeon" in case you use, well, the radeon driver... Option "DRI" "3" EndSection ------------ / snip --------------------------------- NOTICE that you may already have a GPU config snippet. In that case please just add the Option "DRI" "3" there.
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. ========================== Version ======= 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 Build Options ============= KWIN_BUILD_DECORATIONS: yes KWIN_BUILD_TABBOX: yes KWIN_BUILD_ACTIVITIES: yes HAVE_WAYLAND: yes HAVE_WAYLAND_EGL: yes HAVE_WAYLAND_CURSOR: yes HAVE_XKB: yes HAVE_INPUT: yes HAVE_DRM: yes HAVE_GBM: yes HAVE_X11_XCB: yes X11 === 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 Decoration ========== Plugin: org.kde.breeze Theme: Blur: 0 onAllDesktopsAvailable: true alphaChannelSupported: true closeOnDoubleClickOnMenu: false decorationButtonsLeft: 0, 2 decorationButtonsRight: 6, 3, 4, 5 borderSize: 3 gridUnit: 10 font: Oxygen-Sans,10,-1,0,50,0,0,0,0,0 smallSpacing: 2 largeSpacing: 10 Options ======= focusPolicy: 0 nextFocusPrefersMouse: false clickRaise: true autoRaise: false autoRaiseInterval: 0 delayFocusInterval: 0 shadeHover: false shadeHoverInterval: 250 separateScreenFocus: false placement: 4 focusPolicyIsReasonable: true borderSnapZone: 10 windowSnapZone: 10 centerSnapZone: 0 snapOnlyWhenOverlapping: false rollOverDesktops: true focusStealingPreventionLevel: 1 legacyFullscreenSupport: false operationTitlebarDblClick: 5000 operationMaxButtonLeftClick: 5000 operationMaxButtonMiddleClick: 5015 operationMaxButtonRightClick: 5014 commandActiveTitlebar1: 0 commandActiveTitlebar2: 30 commandActiveTitlebar3: 2 commandInactiveTitlebar1: 4 commandInactiveTitlebar2: 30 commandInactiveTitlebar3: 2 commandWindow1: 7 commandWindow2: 8 commandWindow3: 8 commandWindowWheel: 31 commandAll1: 10 commandAll2: 3 commandAll3: 14 keyCmdAllModKey: 16777251 showGeometryTip: false condensedTitle: false electricBorderMaximize: true electricBorderTiling: true electricBorderCornerRatio: 0.25 borderlessMaximizedWindows: false killPingTimeout: 5000 hideUtilityWindowsForInactive: true inactiveTabsSkipTaskbar: false autogroupSimilarWindows: false autogroupInForeground: true compositingMode: 1 useCompositing: true compositingInitialized: true hiddenPreviews: 1 unredirectFullscreen: false glSmoothScale: 2 colorCorrected: false xrenderSmoothScale: false maxFpsInterval: 16666666 refreshRate: 0 vBlankTime: 6000000 glStrictBinding: true glStrictBindingFollowsDriver: true glCoreProfile: false glPreferBufferSwap: 101 glPlatformInterface: 1 Screen Edges ============ desktopSwitching: false desktopSwitchingMovingClients: false cursorPushBackDistance: 1x1 timeThreshold: 150 reActivateThreshold: 350 actionTopLeft: 0 actionTop: 0 actionTopRight: 0 actionRight: 0 actionBottomRight: 0 actionBottom: 0 actionBottomLeft: 0 actionLeft: 0 Screens ======= Multi-Head: no Active screen follows mouse: no Number of Screens: 1 Screen 0: --------- Name: DVI-D-1 Geometry: 0,0,1920x1080 Refresh Rate: 60 Compositing =========== 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 Driver: Unknown 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 Loaded Effects: --------------- zoom slidingpopups kwin4_effect_login slide screenshot minimizeanimation kwin4_effect_translucency kwin4_effect_windowaperture desktopgrid kwin4_effect_maximize kwin4_effect_fade presentwindows highlightwindow kwin4_effect_dialogparent blur contrast logout dashboard startupfeedback screenedge kscreen Currently Active Effects: ------------------------- blur contrast Effect Settings: ---------------- zoom: zoomFactor: 1.2 mousePointer: 0 mouseTracking: 0 enableFocusTracking: false followFocus: true focusDelay: 350 moveFactor: 20 targetZoom: 1 slidingpopups: fadeInTime: 150 fadeOutTime: 250 kwin4_effect_login: slide: screenshot: minimizeanimation: kwin4_effect_translucency: kwin4_effect_windowaperture: desktopgrid: zoomDuration: 300 border: 10 desktopNameAlignment: 0 layoutMode: 0 customLayoutRows: 2 usePresentWindows: true kwin4_effect_maximize: kwin4_effect_fade: presentwindows: layoutMode: 0 showCaptions: true showIcons: true doNotCloseWindows: false ignoreMinimized: false accuracy: 20 fillGaps: true fadeDuration: 150 showPanel: false leftButtonWindow: 1 rightButtonWindow: 2 middleButtonWindow: 0 leftButtonDesktop: 2 middleButtonDesktop: 0 rightButtonDesktop: 0 highlightwindow: kwin4_effect_dialogparent: blur: blurRadius: 12 cacheTexture: true contrast: logout: useBlur: true dashboard: brightness: 0.5 saturation: 0.5 blur: false startupfeedback: type: 1 screenedge: kscreen:
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[1741]: 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 https://bbs.archlinux.org/viewtopic.php?id=202164&action=new/ > starting Plasma, along with a good bit of a wait for the progress bar to > complete: 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 > https://bbs.archlinux.org/viewtopic.php?id=202164&action=new/ > > > 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: http://lists.opensuse.org/opensuse-factory/2015-11/msg00574.html http://lists.opensuse.org/opensuse-factory/2015-11/msg00654.html 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.