It so happens that sometimes, mainly when resuming firstly from a sleep session, the computer will refuse to go into sleep when a suspend operation is issued anew. The computer freezes for a moment, then gives back control. STEPS TO REPRODUCE (This doesn't happen consistently) 1. Put the computer in sleep mode 2. Wake the computer up 3. Ask immediately or after 1-2 minutes the system to sleep again 4. Witness the phenomenon OBSERVED RESULT The computer freezes for a moment, then gives back control, having failed entering sleep mode EXPECTED RESULT The computer should be able to go back to sleep immediately. This works flawlessly on Windows on the same machine. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.2.5-zen1-1-zen #1 ZEN SMP PREEMPT KDE Plasma Version: 5.16.4-1 KDE Frameworks Version: 5.60 Qt Version: 5.13.0 ADDITIONAL INFORMATION [lun. août 5 17:46:17 2019] PM: suspend entry (deep) [lun. août 5 17:46:17 2019] Filesystems sync: 0.180 seconds [lun. août 5 17:46:17 2019] Freezing user space processes ... [lun. août 5 17:46:37 2019] Freezing of tasks failed after 20.003 seconds (1 tasks refusing to freeze, wq_busy=0): [lun. août 5 17:46:37 2019] file.so D 0 >>>>>7838<<<< 1333 0x00004084 [lun. août 5 17:46:37 2019] Call Trace: [lun. août 5 17:46:37 2019] ? __schedule+0x27f/0x710 [lun. août 5 17:46:37 2019] ? request_wait_answer+0x12a/0x270 [fuse] [lun. août 5 17:46:37 2019] schedule+0x8c/0x220 [lun. août 5 17:46:37 2019] request_wait_answer+0x12a/0x270 [fuse] [lun. août 5 17:46:37 2019] ? wait_woken+0x70/0x70 [lun. août 5 17:46:37 2019] ? wait_woken+0x70/0x70 [lun. août 5 17:46:37 2019] fuse_simple_request+0x228/0x290 [fuse] [lun. août 5 17:46:37 2019] fuse_dentry_revalidate+0x1b5/0x390 [fuse] [lun. août 5 17:46:37 2019] ? __switch_to_asm+0x34/0x70 [lun. août 5 17:46:37 2019] ? __switch_to_asm+0x40/0x70 [lun. août 5 17:46:37 2019] ? __switch_to_asm+0x34/0x70 [lun. août 5 17:46:37 2019] ? __switch_to_asm+0x40/0x70 [lun. août 5 17:46:37 2019] lookup_fast+0x280/0x320 [lun. août 5 17:46:37 2019] path_lookupat.isra.0+0x159/0x610 [lun. août 5 17:46:37 2019] filename_lookup+0xc2/0x1d0 [lun. août 5 17:46:37 2019] vfs_statx+0xad/0x130 [lun. août 5 17:46:37 2019] __se_sys_statx+0x5a/0xa0 [lun. août 5 17:46:37 2019] do_syscall_64+0x5f/0x1d0 [lun. août 5 17:46:37 2019] ? page_fault+0x8/0x30 [lun. août 5 17:46:37 2019] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [lun. août 5 17:46:37 2019] RIP: 0033:0x7f54701c6894 [lun. août 5 17:46:37 2019] Code: Bad RIP value. [lun. août 5 17:46:37 2019] RSP: 002b:00007fffe08ec2d0 EFLAGS: 00000246 ORIG_RAX: 000000000000014c [lun. août 5 17:46:37 2019] RAX: ffffffffffffffda RBX: 0000558b958548b0 RCX: 00007f54701c6894 [lun. août 5 17:46:37 2019] RDX: 0000000000000000 RSI: 0000558b9585a4d8 RDI: 00000000ffffff9c [lun. août 5 17:46:37 2019] RBP: 00007fffe08ec3c0 R08: 00007fffe08ec3c0 R09: 00000000ffffff9c [lun. août 5 17:46:37 2019] R10: 0000000000000fff R11: 0000000000000246 R12: 0000558b9585a4d8 [lun. août 5 17:46:37 2019] R13: 0000000072a67077 R14: 00007fffe08ec3b0 R15: 0000558b95854898 [lun. août 5 17:46:37 2019] OOM killer enabled. [lun. août 5 17:46:37 2019] Restarting tasks ... done. [lun. août 5 17:46:37 2019] PM: suspend exit Upon investigating kernel's OoM reported culprit PID: $ps aux | grep -i 7838 >>>>7838<<<< 0.0 0.0 109760 17016 ? D août09 0:00 file.so [kdeinit5] file local:/run/user/1000/klauncherquTPQa.1.slave-socket local:/run/user/1000/kded5zUkbGw.41.slave-socket With regards, Thanks for your work. Darkeox099
This is a long-known and still unfixed bug in the Linux kernel. See https://lists.debian.org/debian-kernel/2011/10/msg00412.html for why this happens. A workaround would be to unmount all FUSE filesystems before attempting to suspend.