You are not logged in.
Pages: 1
Hi guys,
I got a Samsung Series 9 laptop and since my latest system update including the kernel and systemd I lost my "suspend on lid".
This had worked out-of-the-box since day 1 so I never really thought about what actually made it happen. Now on further investigating
why it doesn't work anymore, I came to realize that I have no idea who is actually responsible for suspending and resuming when the lid is closed.
Here's my output
uname:
# uname -a
Linux uknarf 3.11.1-1-ARCH #1 SMP PREEMPT Sat Sep 14 19:30:21 CEST 2013 x86_64 GNU/Linux
acpid is running:
# ps -e | grep acpid
1000 ? 00:00:00 acpid
lsmod:
# lsmod
Module Size Used by
joydev 9663 0
uvcvideo 72804 0
videobuf2_vmalloc 3272 1 uvcvideo
videobuf2_memops 2335 1 videobuf2_vmalloc
videobuf2_core 27797 1 uvcvideo
videodev 110188 2 uvcvideo,videobuf2_core
media 11591 2 uvcvideo,videodev
x86_pkg_temp_thermal 6959 0
intel_powerclamp 8802 0
kvm_intel 129393 0
kvm 379223 1 kvm_intel
crc32_pclmul 3019 0
crc32c_intel 14249 0
btusb 18496 0
bluetooth 308340 1 btusb
ghash_clmulni_intel 4501 0
cryptd 8473 1 ghash_clmulni_intel
coretemp 6326 0
arc4 2000 2
snd_hda_codec_hdmi 30336 1
snd_hda_codec_realtek 37032 1
iwldvm 172354 0
iTCO_wdt 5407 0
iTCO_vendor_support 1929 1 iTCO_wdt
mac80211 453808 1 iwldvm
psmouse 85356 0
samsung_laptop 8593 0
snd_hda_intel 36520 1
i915 610807 2
r8169 58391 0
microcode 13488 0
evdev 10693 18
serio_raw 5041 0
pcspkr 2027 0
snd_hda_codec 148129 3 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel
mii 4027 1 r8169
fan 2753 0
battery 6925 0
intel_agp 10872 1 i915
snd_hwdep 6332 1 snd_hda_codec
iwlwifi 137145 1 iwldvm
intel_gtt 12664 2 i915,intel_agp
snd_pcm 77765 3 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
wmi 8347 0
thermal 8620 0
video 11380 2 i915,samsung_laptop
cfg80211 402729 3 iwlwifi,mac80211,iwldvm
drm_kms_helper 35854 1 i915
rfkill 15698 4 cfg80211,samsung_laptop,bluetooth
snd_page_alloc 7234 2 snd_pcm,snd_hda_intel
drm 235996 3 i915,drm_kms_helper
snd_timer 18718 1 snd_pcm
mei_me 9296 0
snd 59141 9 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_hda_codec,snd_hda_intel
mperf 1267 0
ac 3324 0
mei 61875 1 mei_me
i2c_algo_bit 5391 1 i915
soundcore 5450 1 snd
button 4669 1 i915
i2c_i801 11269 0
shpchp 25457 0
lpc_ich 13112 0
i2c_core 23720 6 drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit,videodev
processor 24917 0
ext4 470412 1
crc16 1359 2 ext4,bluetooth
mbcache 5866 1 ext4
jbd2 83376 1 ext4
sd_mod 30899 3
ahci 22888 2
libahci 21393 1 ahci
ehci_pci 4120 0
libata 171318 2 ahci,libahci
ehci_hcd 48084 1 ehci_pci
xhci_hcd 91419 0
scsi_mod 128695 2 libata,sd_mod
usbcore 178049 5 btusb,uvcvideo,ehci_hcd,ehci_pci,xhci_hcd
usb_common 1648 1 usbcore
acpid handler:
# cat /etc/acpi/handler.sh
#!/bin/bash
# Default acpi script that takes an entry for all actions
case "$1" in
button/power)
case "$2" in
PBTN|PWRF)
logger 'PowerButton pressed'
;;
*)
logger "ACPI action undefined: $2"
;;
esac
;;
button/sleep)
case "$2" in
SLPB|SBTN)
logger 'SleepButton pressed'
;;
*)
logger "ACPI action undefined: $2"
;;
esac
;;
ac_adapter)
case "$2" in
AC|ACAD|ADP0)
case "$4" in
00000000)
logger 'AC unpluged'
;;
00000001)
logger 'AC pluged'
;;
esac
;;
*)
logger "ACPI action undefined: $2"
;;
esac
;;
battery)
case "$2" in
BAT0)
case "$4" in
00000000)
logger 'Battery online'
;;
00000001)
logger 'Battery offline'
;;
esac
;;
CPU0)
;;
*) logger "ACPI action undefined: $2" ;;
esac
;;
button/lid)
case "$3" in
close)
logger 'LID closed'
;;
open)
logger 'LID opened'
;;
*)
logger "ACPI action undefined: $3"
;;
esac
;;
*)
logger "ACPI group/action undefined: $1 / $2"
;;
esac
# vim:set ts=4 sw=4 ft=sh et:
I always thought lid close/open were acpi events that got handled by the acpi-daemon, which in fact is running in my case. But as you can see, my handler script is completely useless.
Funny enough, if I '# systemctrl suspend' on purpose the system goes into suspend and can be woken up by closing and re-opening the lid. It even resumes correctly, so there must
be something that recognizes the lid being opened and resumes the system.
Who does that?
Since the change to systemd I never took the time to get used to it and since the last update also changed systemd I assume it has something to do with systemd?
I've read the logind thing can actually make some trouble, but looking at my logind.conf I don't think that's it:
logind.conf:
# cat /etc/systemd/logind.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# See logind.conf(5) for details
[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
#HandleLidSwitch=suspend
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#IdleAction=ignore
#IdleActionSec=30min
So, do any of you guys have any idea how to restore the "suspend-on-lid" feature? It's really buggin' me that it's not working anymore
and that I have no idea how it actually worked before.
Thanks & Greetings
CREED0R
Last edited by CREED0R (2013-09-20 09:18:06)
Offline
Have you tried to uncomment this line?
#HandleLidSwitch=suspend
■ ■ ■ ■ ■ ■ ■ ■ ■ ■
Offline
here I got some valuable informations:
https://bbs.archlinux.org/viewtopic.php?id=169157
Offline
Hi there,
thanks for your answers!
I've tried to uncomment HandleLidSwitch in the logind.conf, followed by a reboot. But this doesn't change a thing.
What's interesting is, that when I start a youtube video and close the lid, the screen get's black but the music continues.
When I open the lid everything's back to normal, even the wifi connection is still on. Not at all like a couple of days ago, where
closing/opening the lid meant reassociating with the wifi AP...
So bottom line: logind.conf HandleLidSwitch didn't help but something else must recognize the lid close and blank the screen....
-CREED0R
Edit:
Maybe I should mention, that if I press the 'power' button, my laptop shuts down. Which exactly what I want to happen,
so I'm happy with that and this, too, has worked since day 1 and was not changed by the update.
Who shuts down my laptop, when I press the power button? Systemd I guess, but where can I find the place where this is
configured?
I suppose it's this line in the /usr/lib/udev/rules.d/70-power-switch.rules:
SUBSYSTEM=="input", KERNEL=="event*", SUBSYSTEMS=="acpi", TAG+="power-switch"
Am I right?
Edit 2:
NOW it get's really confusing. What's this suppose to mean?
# # cat /etc/systemd/logind.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# See logind.conf(5) for details
[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
HandleLidSwitch=suspend
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#IdleAction=ignore
#IdleActionSec=30min
# loginctl show-session
NAutoVTs=6
KillExcludeUsers=root
KillUserProcesses=no
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
InhibitDelayMaxUSec=5s
HandlePowerKey=poweroff
HandleSuspendKey=suspend
HandleHibernateKey=hibernate
HandleLidSwitch=suspend
IdleAction=ignore
IdleActionUSec=30min
PreparingForShutdown=no
PreparingForSleep=no
This could explain why pressing the power button shuts down the laptop, right?
Last edited by CREED0R (2013-09-20 10:09:10)
Offline
I've tried to uncomment HandleLidSwitch in the logind.conf, followed by a reboot. But this doesn't change a thing
The answer to all your questions is systemd/logind.
This is well documented in the wiki, man pages, and forum posts here. You uncommented the default setting to suspend when the lid switch is activated ... but you didn't change it!
man logind.conf
EDIT: I think I misread, or confused this with a different but similar thread. I was thinking you wanted to disable suspending on lid switch. Sorry for the noise.
Last edited by Trilby (2013-09-20 17:40:17)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Online
I have read the documentation, but I still not seem to get it just yet.
Why should I change the HandleLidSwitch if I want it to suspend on lid close? Leaving the default setting untouched besides uncommenting the option seemed to be the right thing to do.
The problem is, that although it is set to suspend in the logind.conf it doesn't suspend.
When I look at all the other settings, which are still commented and therefore inactive in the logind.conf, I don't get how when I query the current logind-session info, they can be 'active'...
So it's two-fold:
1) The settings in the logind.conf file don't match what the session tells me
2) Although the settings are set to suspend on lid close in the logind.conf as well as in the current session (loginctrl show-session) my laptop still doesn't suspend on lid close.
Last edited by CREED0R (2013-09-20 11:44:06)
Offline
I just tested this on my Series 9 and it doesn't suspend on lid close for me either. I never actually used this, so I didn't really notice it.
You can see acpi events by starting the acpid service and running acpi_listen. On my machine there is no ACPI event when the lid is closed, meaning this is probably a bug in the kernel.
Offline
Yeah, I have also recognized this that acpi_listen doesn't register the lid close event but didn't know how to process that information.
This being a kernel bug never occured to me since I thought I'm doing something wrong ^^.
Thanks, guess I ... just wait? 'till it gets fixed ?
Edit:
Wait wait wait... how can this be a kernel bug? The last kernel I used, was from the AUR 'linux-git' package. So I've been using the unstable 3.11.
Now that it has become stable I upgraded to the mainline 3.11 kernel from the official Arch repos.
I actually changed back now, to the 3.11-1-dirty one and the problem still exists, although it didn't before. So I don't know if they introduced a
new bug or whether it's systemd. Because that changed too and now I'm using the (supposed to be) working kernel with the new systemd version
and it doesn't work. Maybe I'm reversing the systemd update too, just to be sure what's causing what here ...
Edit #2:
Okay, nevermind. I backrolled everything to the setup that I thought existed before, which means: linux-git, linux-firmware-git and systemd-204.
But even with my old setup it doesn't suspend on lid close, which - I am 100% - it did before, because I use suspend on lid close nearly
10 times a day and everytime the wifi reassoc had to happen, which is my indicator that the system really suspended.
Now I'm back to current setup, linux, linux-firmware and systemd-207 all from the official repos and waiting for some magical patch to happen ^^
Last edited by CREED0R (2013-09-20 12:28:17)
Offline
Hello, first post here. I'm not an arch user but I have some info that might be useful. If you press the battery disconnect button on the bottom of the Series9 while the laptop is not on the power, the suspend on lid close returns for some time, until it get's lost again a few days later. When in the state of suspend-on-lid not working, in my case, it also ignores the power adapter, and if booted in uefi mode, the keyboard backlight doesn't work.
I'm running ubuntu on it now btw.
Offline
Pages: 1