Created attachment 1563424 [details] Output of lshw -short Description of problem: I upgraded from F29 to F30 (and have updated to the latest files using dnf) using the system upgrade plugin in dnf. It seemed to work okay, though I mostly left it unattended and came back to a finished, rebooted system. I had previously been using KDE for years on fedora; now, when I login, the entire desktop freezes after a minute or so. The mouse doesn't work. Windows are half-drawn and frozen. This also happens when I try to start plasma with a dummy test account that I created a few years ago. It's a bare-bones KDE setup. I created a default panel and it froze, too. Gnome seemed to work okay, though I don't like it. I've been using lxqt as a KDE substitute in the meantime, and it has been stable. I've attached the output of lshw -short. Version-Release number of selected component (if applicable): How reproducible: Every time I login. Steps to Reproduce: 1.Login with plasma as the desktop. 2. 3. Actual results: Freezes. Expected results: Works normally. Additional info: This is difficult to diagnose. I have to hit the power button on my PC when it freezes.
Someone on fedoraforum just posted that they saw lockups that were related to the volume being unmuted. While muted, it didn't lock up for him. No idea if it might be related to my symptoms. I generally keep my volume unmuted. Maybe at some point I can try to quickly mute it when I start up before it locks up.
For test I downgrade plasma-workspace 30 to plasma-workspace 29 ( plasma-workspace-5.14.5.1-1.fc29.x86_64 ) and now no freeze and no hang. If that can help to solve this problem.
May-be the startkde.patch is wrong ?
Do you have any evidence that startkde.patch is an issue, or just speculating?
I don't know but I see that since this patch is in plasma-workspace my kde freeze
That patch has been in plasma-workspace for a very long time, doubtful
Ok Rex, but startkde.patch has been changed between the two version. diif between these two version : --- "/home/dominique/T\303\251l\303\251chargements/startkde.patch" 2019-05-08 06:06:35.064938338 +0200 +++ "/home/dominique/Mod\303\250les/startkde.patch" 2019-05-08 06:07:48.284504156 +0200 @@ -1,55 +1,6 @@ diff -up plasma-workspace-5.12.5/startkde/startkde.cmake.startkde plasma-workspace-5.12.5/startkde/startkde.cmake ---- plasma-workspace-5.12.5/startkde/startkde.cmake.startkde 2018-05-01 08:03:40.000000000 -0500 -+++ plasma-workspace-5.12.5/startkde/startkde.cmake 2018-05-06 21:12:49.592504191 -0500 -@@ -161,48 +161,6 @@ for prefix in `echo $scriptpath`; do - done - done - --# Activate the kde font directories. --# --# There are 4 directories that may be used for supplying fonts for KDE. --# --# There are two system directories. These belong to the administrator. --# There are two user directories, where the user may add her own fonts. --# --# The 'override' versions are for fonts that should come first in the list, --# i.e. if you have a font in your 'override' directory, it will be used in --# preference to any other. --# --# The preference order looks like this: --# user override, system override, X, user, system --# --# Where X is the original font database that was set up before this script --# runs. -- --usr_odir=$HOME/.fonts/kde-override --usr_fdir=$HOME/.fonts -- --if test -n "$KDEDIRS"; then -- kdedirs_first=`echo "$KDEDIRS"|sed -e 's/:.*//'` -- sys_odir=$kdedirs_first/share/fonts/override -- sys_fdir=$kdedirs_first/share/fonts --else -- sys_odir=$KDEDIR/share/fonts/override -- sys_fdir=$KDEDIR/share/fonts --fi -- --# We run mkfontdir on the user's font dirs (if we have permission) to pick --# up any new fonts they may have installed. If mkfontdir fails, we still --# add the user's dirs to the font path, as they might simply have been made --# read-only by the administrator, for whatever reason. -- --test -d "$sys_odir" && xset +fp "$sys_odir" --test -d "$usr_odir" && (mkfontdir "$usr_odir" ; xset +fp "$usr_odir") --test -d "$usr_fdir" && (mkfontdir "$usr_fdir" ; xset fp+ "$usr_fdir") --test -d "$sys_fdir" && xset fp+ "$sys_fdir" -- --# Ask X11 to rebuild its font list. --xset fp rehash -- - # Set a left cursor instead of the standard X11 "X" cursor, since I've heard - # from some users that they're confused and don't know what to do. This is - # especially necessary on slow machines, where starting KDE takes one or two +--- plasma-workspace-5.12.5/startkde/startkde.cmake.startkde 2018-05-01 08:03:40.000000000 -0500 ++++ plasma-workspace-5.12.5/startkde/startkde.cmake 2018-05-06 21:12:49.592504191 -0500 @@ -279,22 +237,21 @@ if test $? -ne 0; then # Startup error echo 'startkde: Could not sync environment to dbus.' 1>&2 @@ -96,8 +47,8 @@ break fi diff -up plasma-workspace-5.12.5/startkde/startplasma.cmake.startkde plasma-workspace-5.12.5/startkde/startplasma.cmake ---- plasma-workspace-5.12.5/startkde/startplasma.cmake.startkde 2018-05-01 08:03:40.000000000 -0500 -+++ plasma-workspace-5.12.5/startkde/startplasma.cmake 2018-05-06 21:11:54.749023404 -0500 +--- plasma-workspace-5.12.5/startkde/startplasma.cmake.startkde 2018-05-01 08:03:40.000000000 -0500 ++++ plasma-workspace-5.12.5/startkde/startplasma.cmake 2018-05-06 21:11:54.749023404 -0500 @@ -140,7 +140,8 @@ if test $? -ne 0; then exit 1 fi @@ -126,25 +77,25 @@ break fi diff -up plasma-workspace-5.12.5/startkde/startplasmacompositor.cmake.startkde plasma-workspace-5.12.5/startkde/startplasmacompositor.cmake ---- plasma-workspace-5.12.5/startkde/startplasmacompositor.cmake.startkde 2018-05-01 08:03:40.000000000 -0500 -+++ plasma-workspace-5.12.5/startkde/startplasmacompositor.cmake 2018-05-06 21:11:54.749023404 -0500 +--- plasma-workspace-5.12.5/startkde/startplasmacompositor.cmake.startkde 2018-05-01 08:03:40.000000000 -0500 ++++ plasma-workspace-5.12.5/startkde/startplasmacompositor.cmake 2018-05-06 21:11:54.749023404 -0500 @@ -3,6 +3,8 @@ # DEFAULT Plasma STARTUP SCRIPT ( @PROJECT_VERSION@ ) # - + +qdbus=qdbus-qt5 + # We need to create config folder so we can write startupconfigkeys if [ ${XDG_CONFIG_HOME} ]; then configDir=$XDG_CONFIG_HOME; @@ -120,12 +122,12 @@ fi - + # Get a property value from org.freedesktop.locale1 queryLocale1() { - qdbus --system org.freedesktop.locale1 /org/freedesktop/locale1 "$1" + $qdbus --system org.freedesktop.locale1 /org/freedesktop/locale1 "$1" } - + # Query whether org.freedesktop.locale1 is available. If it is, try to # set XKB_DEFAULT_{MODEL,LAYOUT,VARIANT,OPTIONS} accordingly. -if qdbus --system org.freedesktop.locale1 >/dev/null 2>/dev/null; then @@ -154,7 +105,7 @@ if [ -z "${XKB_DEFAULT_MODEL}" -a -z "${XKB_DEFAULT_LAYOUT}" -a \ @@ -175,7 +177,7 @@ fi export XDG_DATA_DIRS - + # Make sure that D-Bus is running -if qdbus >/dev/null 2>/dev/null; then +if $qdbus >/dev/null 2>/dev/null; then
yes, the patch is much smaller now (the changes we patched were incorporated upstream). The primary purpose of startkde.patch now is to ensure that startup scripts use 'qdbus-qt5' binary instead of 'qdbus' (which can be ambiguous, qt4 or qt5 version?)
So, based on descriptions of initial comments, half-drawn windows and the mouse not moving, one primary explanation for that is drivers (video/mouse). Newer plasma versions may tickle those driver bugs differently. Basing that on initial attachment that includes: /0/100/3/0 display GF106 [GeForce GTS 450] Triaging to mesa (nouveau)
One possible thing to try to mitigate this, run: kcmshell5 qtquicksettings and try setting Render Loop: basic and see if that helps any
(In reply to Rex Dieter from comment #10) > One possible thing to try to mitigate this, run: > kcmshell5 qtquicksettings > > and try setting > Render Loop: basic > > and see if that helps any I did that and am now running KDE. It's been a good five minutes with no lock-up, so it looks to me that this solved my problem. Thanks. If there's anything else you'd like me to try, let me know.
It's now been a good half hour with KDE and no lock-ups. I assume "Render Loop: basic" is non-optimal in some sense, but it's at least stable and running well. Thanks again.
OK, triaging this back to qt5-qtdeclarative. Possible we can patch the code to use 'basic' when used on nouveau
Looks like Qt upstream already did that (linking some related upstream bugs). I'll pull in a minimal fix into qt5-qtbase shortly.
Excellent. Thanks.
qt5-qtbase-5.12.1-6.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-f43ed18461
I install qt5-qtbase-5.12.1-6.fc30 and now no problem, no freeze. Thank for this upgrade.
qt5-qtbase-5.12.1-6.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-f43ed18461
qt5-qtbase-5.12.1-6.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1701480 has been marked as a duplicate of this bug. ***
*** Bug 1701037 has been marked as a duplicate of this bug. ***
*** Bug 1701501 has been marked as a duplicate of this bug. ***
*** Bug 1714736 has been marked as a duplicate of this bug. ***
qt5-qtbase-5.12.1-6.fc30 did not fix the issue, but the recipe from comment #10 did the trick. Just FYI.