You are not logged in.
I configure laptop to enter S3 state on lid closing, but still I wait about 5-20 seconds after closing lid before it really enters sleep.
Sleep itself works flawlessly: it is instant if you enter it from console or X-terminal.
So the problem is "lid closed" acpi event. It is sent only after this terrible delay!
Why does this happen?
Last edited by eruditorum (2012-12-11 17:30:51)
Offline
You need to provide more information. Like at the very very least, what harware you are using and how you are triggering sleep on lid close.
Offline
How I use lid to put laptop into sleep:
from /etc/acpi/handler.sh:
button/lid)
case "$3" in
close)
echo mem >/sys/power/state
;;
open)
#This will never work!
;;
esac
;;
from /etc/systemd/logind.conf:
HandleLidSwitch=ignore
If I disable handling lid switch by acpi daemon and give this work to systemd with "HandleLidSwitch=sleep" the latency won't go away.
Last edited by eruditorum (2012-11-23 23:41:38)
Offline
hehe, I just got my new Samsung Series 9 900x4d today, installed Arch just a few hours ago and noticed the same problem about 30 minutes ago. Then I look in the Arch Linux forums and someone posted about it.
I'm using systemd's HandleLidSwitch functionality btw.
@eruditorum: by hardware we mean your laptops' manufactor and model number (I'm guessing Samsung... ).
Last edited by 65kid (2012-11-23 23:11:25)
Offline
Samsung Series 3 laptop
~ > dmesg|grep LID
541:[ 0.997323] ACPI: Lid Switch [LID0]
Last edited by eruditorum (2012-11-25 10:54:11)
Offline
I recall seeing this issue recently on these forums. I am not certain, but I do think that it was also a Samsung machine.
Offline
Yes, here it is: https://bbs.archlinux.org/viewtopic.php … 05#p885705
Offline
Well the thread isn't recent even if it was seen recently...
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
In addition, it seems that delay is different every time (on AC, on battery) but still stays in 5-20 seconds range.
Also in Windows delay existed, but was probably two times shorter (2-10 seconds).
Last edited by eruditorum (2012-11-25 09:50:09)
Offline
I am fairly certain I had seen a different, active thread that mentioned something similar (or rather, the same). I cannot find it though, and I don't think that a solution was ever found. Sorry I cannot be of more help. It sounds like a hardware issue honestly. I have read that microsofts implementation of acpi is kinda half assed, so it lets errors go undetected, leading to inconsistencies in the dsdt. Maybe this has something to do with it? I have to imagine that a system that is not getting the lid close call (but eventually gets it) is getting a delayed signal, not a delayed detection. This would seem especially probably seeing that it is fairly common among a certain brand of machine.
Offline
[fix]
After latest systemd update delay became some practically constant and small amount of time (about 10 seconds.)
Last edited by eruditorum (2012-12-11 17:30:02)
Offline
hehe, I just got my new Samsung Series 9 900x4d today, installed Arch just a few hours ago and noticed the same problem about 30 minutes ago. Then I look in the Arch Linux forums and someone posted about it.
I'm using systemd's HandleLidSwitch functionality btw.
@eruditorum: by hardware we mean your laptops' manufactor and model number (I'm guessing Samsung... ).
Hi,
I got the same laptop a few months ago. I've tried installing Ubuntu 12.04LTS on it, but the laptop runs too hot. I think an official bug report has been posted.
How does it perform running Arch linux? I'm probably not linux-proficient enough to run Arch, but it's worth a try.
Thanks.
Offline