Hi Chris, just to make sure I understand (from a kernel perspective), can you confirm that `echo mem > /sys/power/state` is also fast at reaching the suspend state?
In that case it would be interesting to check if there's a delay at detecting the state of the lid switch. For this, could you run the following command in a bash session: $ while :; do echo `date` - `cat /proc/acpi/button/lid/LID0/state`; sleep 1; done Close the lid, re-open it and you should notice something like this: Thu May 16 17:50:42 CEST 2019 - state: open Thu May 16 17:50:43 CEST 2019 - state: open Thu May 16 17:50:44 CEST 2019 - state: open Thu May 16 17:50:45 CEST 2019 - state: closed Thu May 16 17:50:46 CEST 2019 - state: closed Thu May 16 17:50:47 CEST 2019 - state: closed Thu May 16 17:50:48 CEST 2019 - state: open Thu May 16 17:50:49 CEST 2019 - state: open Thu May 16 17:50:50 CEST 2019 - state: open ^C Note that I have set the "lid close action" to do nothing, in this way we can better isolate the problem. Thanks. -- 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
