You are not logged in.

#1 2017-11-30 01:39:22

luser
Member
Registered: 2016-08-27
Posts: 114

[Resolved] QQmlThread prevents suspend

I am running Arch with the standard or the lts kernel and Plasma. When I try to suspend on either my Lenovo x250 laptop or my DELL 3420 desktop, the first time I try it, it fails. Here is what the system log looks like:

Nov 29 15:52:02 RANDOM7 kernel: PM: Syncing filesystems ... done.
Nov 29 15:52:02 RANDOM7 kernel: PM: Preparing system for sleep (freeze)
Nov 29 15:52:02 RANDOM7 kernel: Freezing user space processes ... 
Nov 29 15:52:02 RANDOM7 kernel: Freezing of tasks failed after 20.007 seconds (1 tasks refusing to freeze, wq_busy=0):
Nov 29 15:52:02 RANDOM7 kernel: QQmlThread      D    0  1637   1011 0x00000104
Nov 29 15:52:02 RANDOM7 kernel: Call Trace:
Nov 29 15:52:02 RANDOM7 kernel:  __schedule+0x239/0x890
Nov 29 15:52:02 RANDOM7 kernel:  schedule+0x3d/0x90
Nov 29 15:52:02 RANDOM7 kernel:  fanotify_handle_event+0x2a4/0x2e0
Nov 29 15:52:02 RANDOM7 kernel:  ? wait_woken+0x80/0x80
Nov 29 15:52:02 RANDOM7 kernel:  fsnotify+0x298/0x4d0
Nov 29 15:52:02 RANDOM7 kernel:  security_file_open+0x8a/0x90
Nov 29 15:52:02 RANDOM7 kernel:  do_dentry_open+0xeb/0x2e0
Nov 29 15:52:02 RANDOM7 kernel:  vfs_open+0x4e/0x80
Nov 29 15:52:02 RANDOM7 kernel:  path_openat+0x51e/0x13a0
Nov 29 15:52:02 RANDOM7 kernel:  do_filp_open+0x9b/0x110
Nov 29 15:52:02 RANDOM7 kernel:  ? __seccomp_filter+0x32/0x1f0
Nov 29 15:52:02 RANDOM7 kernel:  ? __check_object_size+0xaf/0x1b0
Nov 29 15:52:02 RANDOM7 kernel:  do_sys_open+0x1ba/0x250
Nov 29 15:52:02 RANDOM7 kernel:  ? do_sys_open+0x1ba/0x250
Nov 29 15:52:02 RANDOM7 kernel:  SyS_openat+0x14/0x20
Nov 29 15:52:02 RANDOM7 kernel:  do_syscall_64+0x54/0xc0
Nov 29 15:52:02 RANDOM7 kernel:  entry_SYSCALL64_slow_path+0x25/0x25
Nov 29 15:52:02 RANDOM7 kernel: RIP: 0033:0x7f7697267840
Nov 29 15:52:02 RANDOM7 kernel: RSP: 002b:00007f767c9d6690 EFLAGS: 00000293 ORIG_RAX: 0000000000000101
Nov 29 15:52:02 RANDOM7 kernel: RAX: ffffffffffffffda RBX: 0000000000000021 RCX: 00007f7697267840
Nov 29 15:52:02 RANDOM7 kernel: RDX: 0000000000080000 RSI: 00007f7668294838 RDI: ffffffffffffff9c
Nov 29 15:52:02 RANDOM7 kernel: RBP: 00007f7668294838 R08: 0000000000000000 R09: 0000000000000060
Nov 29 15:52:02 RANDOM7 kernel: R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000080000
Nov 29 15:52:02 RANDOM7 kernel: R13: 00007f76682eb470 R14: 00007f767c9d6738 R15: 00007f76682eb490
Nov 29 15:52:02 RANDOM7 kernel: OOM killer enabled.
Nov 29 15:52:02 RANDOM7 rtkit-daemon[1073]: The canary thread is apparently starving. Taking action.
Nov 29 15:52:02 RANDOM7 rtkit-daemon[1073]: Demoting known real-time threads.
Nov 29 15:52:02 RANDOM7 rtkit-daemon[1073]: Successfully demoted thread 1049 of process 1049 (/usr/bin/pulseaudio).
Nov 29 15:52:02 RANDOM7 rtkit-daemon[1073]: Demoted 1 threads.
Nov 29 15:52:02 RANDOM7 kernel: Restarting tasks ... done.
Nov 29 15:52:02 RANDOM7 kernel: thermal thermal_zone3: failed to read out thermal zone (-5)
Nov 29 15:52:02 RANDOM7 systemd[1]: systemd-suspend.service: Main process exited, code=exited, status=1/FAILURE
Nov 29 15:52:02 RANDOM7 systemd[1]: systemd-suspend.service: Failed with result 'exit-code'.
Nov 29 15:52:02 RANDOM7 systemd[1]: Failed to start Suspend.
Nov 29 15:52:02 RANDOM7 systemd[1]: Dependency failed for Suspend.
Nov 29 15:52:02 RANDOM7 systemd[1]: suspend.target: Job suspend.target/start failed with result 'dependency'.
Nov 29 15:52:02 RANDOM7 systemd[1]: sleep.target: Unit not needed anymore. Stopping.
Nov 29 15:52:02 RANDOM7 systemd[1]: Stopped target Sleep.
Nov 29 15:52:02 RANDOM7 systemd[1]: tlp-sleep.service: Unit not needed anymore. Stopping.
Nov 29 15:52:02 RANDOM7 systemd[1]: Stopping TLP suspend/resume...
Nov 29 15:52:02 RANDOM7 systemd-logind[425]: Operation 'sleep' finished.

So, it looks like QQmlThread is causing trouble on both my laptop and my desktop according to the logs. The fragment shown is from my laptop, but QQmlThread hangs the suspend process on both systems.

pstree shows that QQmlThread is being called by krunner, kwin_x11, and plasmashell.

        │          ├─ksmserver─┬─autokey-gtk─┬─5*[{autokey-gtk}]
        │          │           │             ├─{gdbus}
        │          │           │             └─{gmain}
        │          │           ├─baloo_file───{QDBusConnection}
        │          │           ├─krunner─┬─{QDBusConnection}
        │          │           │         ├─{QQmlThread}
        │          │           │         └─{QXcbEventReader}
        │          │           ├─kwin_x11─┬─{QDBusConnection}
        │          │           │          ├─{QQmlThread}
        │          │           │          ├─{QXcbEventReader}
        │          │           │          └─{kwin_x11}
        │          │           ├─plasmashell─┬─konsole─┬─bash───pstree
        │          │           │             │         ├─{QDBusConnection}
        │          │           │             │         └─{QXcbEventReader}
        │          │           │             ├─{KCupsConnection}
        │          │           │             ├─{QDBusConnection}
        │          │           │             ├─2*[{QQmlThread}]
        │          │           │             ├─{QQuickPixmapRea}
        │          │           │             ├─{QXcbEventReader}
        │          │           │             └─{plasmashell}

I have been able to make suspend work using the lts kernel. Even the lts kernel was not working with my original mkinitcpio.conf, but by adjusting my mkinitcpio.conf to put more modules in the modules section and fewer in the hooks section, suspend WAS working on my laptop with the lts kernel but apparently not reliably on the first try. It's the same with the desktop.

I've only been using Linux for a little over a year, and I've reached the point where I don't know what the smart thing is to do next to resolve this. Any suggestions regarding how to figure out whether it's krunner, plasmashell, kwin_x11, or the kernel itself? I would have thought that the lts kernel would be less likely the cause of the issue as comared with the KDE software, but of course that's not an expert opinion.

Last edited by luser (2017-12-13 19:12:20)


luser: an epithet applied by Windows users to linux users

Offline

#2 2017-11-30 09:38:23

seth
Member
Registered: 2012-09-03
Posts: 51,052

Re: [Resolved] QQmlThread prevents suspend

The thread is waiting for some I/O response, this should be indicated by a "D" in the process list (could identify the offending process, check "ps fax", the STAT column should tell you)

Offline

#3 2017-11-30 21:17:42

luser
Member
Registered: 2016-08-27
Posts: 114

Re: [Resolved] QQmlThread prevents suspend

Seth, thanks for taking the time to respond.

Since it always fails on the first attempt after a reboot, yet works after first the attempt fails,
and because QQmlThread seems to be causing the hang, I did the following:

1) rebooted
2) ran ps fax
3) captured the info pertaining to processes running QQmlThread
4) attempted to suspend, waited for login screen
5) logged in again after fail
6) ran ps fax
7) captured the info pertaining to processes running QQmlThread

This is what shows before the failed suspend attempt:

  890 ?        Sl     0:00 /usr/bin/kwalletd5 --pam-login 15 18
  922 ?        S      0:00 /usr/lib/kf5/start_kdeinit --kded +kcminit_startup
  923 ?        Ss     0:00 kdeinit5: Running...
  924 ?        Sl     0:00  \_ /usr/lib/kf5/klauncher --fd=9
  929 ?        Sl     0:00  \_ kded5 [kdeinit5]
  964 ?        Sl     0:00  \_ /usr/bin/ksmserver
  985 ?        Sl     0:01  |   \_ kwin_x11 -session 10a18e8544000151063092900000010490005_1512074576_916945
  989 ?        SNl    0:00  |   \_ /usr/bin/baloo_file
  990 ?        Sl     0:00  |   \_ /usr/bin/krunner
  991 ?        Sl     0:03  |   \_ /usr/bin/plasmashell
  993 ?        Sl     0:00  |   \_ /usr/lib/polkit-kde-authentication-agent-1
  994 ?        Sl     0:00  |   \_ /usr/bin/xembedsniproxy
 1142 ?        Sl     0:00  |   \_ /usr/bin/python /usr/bin/autokey-gtk
  999 ?        Sl     0:00  \_ /usr/lib/org_kde_powerdevil -session 10a18e8544000151063093000000010490009_1512074576_847264
 1111 ?        Sl     0:00  \_ /usr/bin/kgpg -session 10a18e8544000151063093100000010490010_1512074576_847303
 1116 ?        Sl     0:00  \_ /usr/bin/konsole -session 10a18e8544000151207452100000009680024_1512074576_847467
 1133 pts/0    Ss     0:00  |   \_ /bin/bash
 1269 pts/0    R+     0:00  |       \_ ps fax
 1156 ?        Sl     0:00  \_ desktop.so [kdeinit5] desktop local:/run/user/1000/klauncherMTJ924.1.slave-socket local:/run/user/1000/plasmashellMTJ991.1.slave-socket
 1159 ?        S      0:00  \_ file.so [kdeinit5] file local:/run/user/1000/klauncherMTJ924.1.slave-socket local:/run/user/1000/kio_desktophX1156.1.slave-socket
 1160 ?        S      0:00  \_ trash.so [kdeinit5] trash local:/run/user/1000/klauncherMTJ924.1.slave-socket local:/run/user/1000/plasmashellLhX991.2.slave-socket
 1161 ?        S      0:00  \_ file.so [kdeinit5] file local:/run/user/1000/klauncherMTJ924.1.slave-socket local:/run/user/1000/plasmashellnnS991.3.slave-socket
 1186 ?        S      0:00  \_ file.so [kdeinit5] file local:/run/user/1000/klauncherMTJ924.1.slave-socket local:/run/user/1000/plasmashellTik991.4.slave-socket
 1188 ?        S      0:00  \_ trash.so [kdeinit5] trash local:/run/user/1000/klauncherMTJ924.1.slave-socket local:/run/user/1000/plasmashellTwZ991.5.slave-socket
 1199 ?        S      0:00  \_ file.so [kdeinit5] file local:/run/user/1000/klauncherMTJ924.1.slave-socket local:/run/user/1000/plasmashelljdT991.6.slave-socket

This is what it looked like after:

  890 ?        Sl     0:00 /usr/bin/kwalletd5 --pam-login 15 18
  922 ?        S      0:00 /usr/lib/kf5/start_kdeinit --kded +kcminit_startup
  923 ?        Ss     0:00 kdeinit5: Running...
  924 ?        Sl     0:00  \_ /usr/lib/kf5/klauncher --fd=9
  929 ?        Sl     0:00  \_ kded5 [kdeinit5]
  964 ?        Sl     0:00  \_ /usr/bin/ksmserver
  985 ?        Sl     0:04  |   \_ kwin_x11 -session 10a18e8544000151063092900000010490005_1512074576_916945
  989 ?        SNl    0:00  |   \_ /usr/bin/baloo_file
  990 ?        Sl     0:00  |   \_ /usr/bin/krunner
  991 ?        Sl     0:04  |   \_ /usr/bin/plasmashell
  993 ?        Sl     0:00  |   \_ /usr/lib/polkit-kde-authentication-agent-1
  994 ?        Sl     0:00  |   \_ /usr/bin/xembedsniproxy
 1142 ?        Sl     0:01  |   \_ /usr/bin/python /usr/bin/autokey-gtk
  999 ?        Sl     0:00  \_ /usr/lib/org_kde_powerdevil -session 10a18e8544000151063093000000010490009_1512074576_847264
 1111 ?        Sl     0:00  \_ /usr/bin/kgpg -session 10a18e8544000151063093100000010490010_1512074576_847303
 1116 ?        Sl     0:02  \_ /usr/bin/konsole -session 10a18e8544000151207452100000009680024_1512074576_847467
 1133 pts/0    Ss     0:00      \_ /bin/bash
 1609 pts/0    R+     0:00          \_ ps fax

The three processes that call QQmlThread are krunner, plasmashell, and kwin_x11. The most significant difference before and after is that there are no slave-sockets showing after, but I'm not at all sure this has anything to do with the suspend failure.

I did verify that it would suspend after, and I also have the complete output of ps fax before and after. There were no processes listed with a D status in any case.

If this sheds any light, or if you have any further suggestions, let me know. I'm still pretty much in the dark here.


luser: an epithet applied by Windows users to linux users

Offline

#4 2017-12-01 08:41:56

seth
Member
Registered: 2012-09-03
Posts: 51,052

Re: [Resolved] QQmlThread prevents suspend

env | grep GLIB

You should be able to kill krunner and plasmashell (latter one kills your desktop, keep a konsole around ;-) to isolate the problem (killing the WM is nasty, but if the issue remains w/o the former two that's probably indication enough)

Offline

#5 2017-12-13 06:29:57

luser
Member
Registered: 2016-08-27
Posts: 114

Re: [Resolved] QQmlThread prevents suspend

Hi,

Thanks for responding. As it happens, for one of my machines the issue was resolved with a pacman update, but the DELL still has the problem with both the arch linux and the lts kernels.

I disabled krunner by removing its desktop file from /etc/xdg/autostart, but trying suspend failed. So, I rebooted (since I would expect suspend to work on the second try) and then used the system monitor to kill plasmashell. Then in a terminal (already open) I used:

systemctl suspend

and the system still failed to suspend, again due to QQmlThread, which leaves only kwin_x11. It's late, and before I attempt to run without kwin_x11, I'm going to get some sleep. Perhaps it's already  a good enough indication of where the problem is. . . but I'm not sure what to do next, if it is the fault of kwin_x11. Maybe it's interacting with something else on my system?

I found that using

#echo mem > /sys/power/state

puts the system to sleep right away even with krunner and plasmashell both running. That has to be done as root, but the systemctl command is done as a user.

By the way,

env | grep GLIB

returned nothing. Not sure why you mentioned it?

Last edited by luser (2017-12-13 08:04:55)


luser: an epithet applied by Windows users to linux users

Offline

#6 2017-12-13 09:22:43

seth
Member
Registered: 2012-09-03
Posts: 51,052

Re: [Resolved] QQmlThread prevents suspend

There sees a bug with QtQuick when not using the glib event dispatcher.

KWin has QML in some compositor features (eg. the buttons in presentwindows/showdesktop effects) and otherwise is several decorations using the aurorae engine (themes you can download from the web, afair the breeze decoration should not use qml)

Offline

#7 2017-12-13 19:11:29

luser
Member
Registered: 2016-08-27
Posts: 114

Re: [Resolved] QQmlThread prevents suspend

KWin has QML in some compositor features (eg. the buttons in presentwindows/showdesktop effects) and otherwise is several decorations using the aurorae engine

This got me looking at qt and kwin related apps I've installed, and I noticed that while I was running kwin 5.11.4-1, the latest package was listed as 5.11.4-2. . . I updated my mirrorlist not that long ago, but clearly not recently enough, because when I did, more packages were picked up, and this seems to have resolved the issue with both the arch kernel and the lts kernel.

So, the moral of this sad tale is, when something seems slightly amiss, update your mirrorlist and run pacman -Syyu before posting your problem and wasting anyone's time. I've just installed and configured reflector on 3 machines, so this kind of thing should not happen again for me.

Thanks, Seth, for interacting and nudging my brain out of the loops it was stuck in.

Last edited by luser (2017-12-14 19:32:36)


luser: an epithet applied by Windows users to linux users

Offline

Board footer

Powered by FluxBB