Suspend not working any more on qzed's 5.2.5 build

[shadowrylander]

Hello!
     I am using @qzed's latest 5.2.5 release 1 build, and I seem to have lost the ability to suspend my device; I close the lid, then pull it open a while later, and it's just as warm as when it started, instead of freezing cold, waking up a bit too quickly to have been suspended at all. I haven't changed anything kernel-related since I installed the build (does undocking and redocking for the first time since I installed the kernel count?), and I know the powerbutton isn't being pressed, as it's just sitting on my desk. In addition, how do I get the kernel logs related to whether it was suspended or not?
Any help on the matter would be greatly appreciated!

P.S. : WiFi module seems to disconnect when the lid is closed, and disappearing from the settings entirely at times, forcing me to reboot. Do I open a new issue for this? Bluetooth disconnects on lid close as well, though doesn't disappear from the settings.

[qzed]

For now just from the sleep script, maybe we can find something there.

[shadowrylander]

@qzed @tmarkov Sorry; academics again. Also, I can't seem to make heads or tails of the logs; is there a way to remove anything unnecessary from it? Or should I just use pastebin or similar? Also, is there any sensitive information I should be worried about in it?

[alturismo]

@qzed may a question as i reverted to 5.1.x kernel, i have the suspend / wifi issue with all newer kernels, as the rest is sorted (keyboard, touch) and here only wifi suspend is left, rather open a new issue or keep this one and i start to look for some debugs ?

[qzed]

@shadowrylander You can just pastebin the whole thing (or upload it as file here), better to have too much than too little. We'll probably only need the part involving suspend, so you could check what's all reported by journalctl before and just upload the parts that are being printed when you try to suspend and resume.

[qzed]

@alturismo Please open a new issue or have a look at the other wifi issues (I currently don't have an overview over that topic, so not sure if there's already one that fits your description).

[shadowrylander]

@qzed Thanks! Here you go; sorry, there are sync program folder scans in between! logs.txt

[qzed]

@shadowrylander Looks like syncthing is the problem:

Oct 04 19:08:49 surface kernel: Freezing user space processes ... 
Oct 04 19:08:49 surface kernel: Freezing of tasks failed after 20.003 seconds (1 tasks refusing to freeze, wq_busy=0):
Oct 04 19:08:49 surface kernel: syncthing       D    0  3281      1 0x00004324
Oct 04 19:08:49 surface kernel: Call Trace:
Oct 04 19:08:49 surface kernel:  __schedule+0x2bb/0x660
Oct 04 19:08:49 surface kernel:  schedule+0x2d/0x90
Oct 04 19:08:49 surface kernel:  request_wait_answer+0xa3/0x210
Oct 04 19:08:49 surface kernel:  ? wait_woken+0x80/0x80
Oct 04 19:08:49 surface kernel:  __fuse_request_send+0x69/0x90
Oct 04 19:08:49 surface kernel:  fuse_request_send+0x29/0x30
Oct 04 19:08:49 surface kernel:  fuse_simple_request+0xdd/0x1a0
Oct 04 19:08:49 surface kernel:  fuse_do_getattr+0xe3/0x300
Oct 04 19:08:49 surface kernel:  fuse_perm_getattr+0x26/0x30
Oct 04 19:08:49 surface kernel:  fuse_permission+0x100/0x150
Oct 04 19:08:49 surface kernel:  inode_permission+0xd8/0x1a0
Oct 04 19:08:49 surface kernel:  link_path_walk.part.42+0x29e/0x540
Oct 04 19:08:49 surface kernel:  path_lookupat.isra.45+0x93/0x220
Oct 04 19:08:49 surface kernel:  filename_lookup.part.61+0xa0/0x170
Oct 04 19:08:49 surface kernel:  ? __check_object_size+0x166/0x192
Oct 04 19:08:49 surface kernel:  ? strncpy_from_user+0x57/0x1b0
Oct 04 19:08:49 surface kernel:  user_path_at_empty+0x3e/0x50
Oct 04 19:08:49 surface kernel:  vfs_statx+0x76/0xe0
Oct 04 19:08:49 surface kernel:  __do_sys_newlstat+0x3d/0x70
Oct 04 19:08:49 surface kernel:  ? __secure_computing+0x3e/0xd0
Oct 04 19:08:49 surface kernel:  ? syscall_trace_enter+0x196/0x2b0
Oct 04 19:08:49 surface kernel:  __x64_sys_newlstat+0x16/0x20
Oct 04 19:08:49 surface kernel:  do_syscall_64+0x5a/0x140
Oct 04 19:08:49 surface kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
Oct 04 19:08:49 surface kernel: RIP: 0033:0x4abb90
Oct 04 19:08:49 surface kernel: Code: Bad RIP value.
Oct 04 19:08:49 surface kernel: RSP: 002b:000000c4227bb8a0 EFLAGS: 00000202 ORIG_RAX: 0000000000000006
Oct 04 19:08:49 surface kernel: RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000004abb90
Oct 04 19:08:49 surface kernel: RDX: 0000000000000000 RSI: 000000c422020928 RDI: 000000c422041a10
Oct 04 19:08:49 surface kernel: RBP: 000000c4227bb908 R08: 0000000000000000 R09: 0000000000000000
Oct 04 19:08:49 surface kernel: R10: 0000000000000000 R11: 0000000000000202 R12: ffffffffffffffff
Oct 04 19:08:49 surface kernel: R13: 000000000000008c R14: 000000000000008b R15: 00000000000000aa
Oct 04 19:08:49 surface kernel: OOM killer enabled.
Oct 04 19:08:49 surface kernel: Restarting tasks ... done.
Oct 04 19:08:49 surface systemd-sleep[3209]: Failed to suspend system. System resumed again: Device or resource busy

In the logs, it looks like the device is trying to suspend multiple times, but each time is blocked by syncthing.

[shadowrylander]

I thought so too at first, but then remembered that, for some reason, it only stops suspending when bluetooth is active, and as far as I know, syncthing and bluetooth do not interact with each other. Syncthing works regardless of whether bluetooth on on or not.

[shadowrylander]

So I have no idea what's happening.

[shadowrylander]

UPDATE: Actually, now it's starting to happen even with Bluetooth off; I think trying to shut off Syncthing from the sleep script might work. I'll test it with Bluetooth on to see if it still suspends, as that may be the real culprit here.

[masenocturnal]

I am not able to suspend either, SB running 19.04 however I don't have syncthing installed. Not sure if this is a generic issue or one related to syncthing ?

$ uname -a Linux esd01 5.3.10-surface #1 SMP Sun Nov 10 20:33:54 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

[shadowrylander]

Apparently upgrading to Ubuntu 19.10 fixed the issue; not entirely sure why. Should I mark this issue as solved, then?