Alright, the fact that `echo mem > /sys/power/state` is fast means that the delay issue is not in the "suspend" path and we also know that it's not even in the detection path (/proc/acpi/button/lid/LID0/state). So the delay must be somewhere between the detection of the event and the delivery of the proper suspend action, that should be driven by systemd, more exactly systemd-logind.
At this point I think it would interesting to take a look at journalctl, more exactly the timestamps and messages around a line like "systemd- logind[...]: Lid closed.". This should give us an idea how fast systemd detected the event and how fast it processed it. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1829399 Title: Lid switch triggered suspend takes much longer than UI triggered suspend Status in linux package in Ubuntu: Incomplete Bug description: IBM T460 5.0.0-13-generic #14-Ubuntu SMP Mon Apr 15 14:59:14 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux When triggering a suspend even from the lid switch of my Lenovo T460 it takes 30 seconds to reach suspend state. Several others with different models of Lenovo laptops have also reproduced this issue. It seems this is isolated to the lid switch as UI triggered suspend (alt+power icon) is far faster. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1829399/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp