lid state broken

MajinJoko · 2013-08-16 14:59:25

Hi guys,

my laptop used to go to suspend when I closed the lid.
From some days this does not happen anymore, but I did't change any configuration in systemd or gnome 3.

I was debugging a bit, and as far as I can see now the status of the lid is always:

# cat /proc/acpi/button/lid/LID0/state 
state:      open

even if this command is run with some delay with the lid closed.

Thus, I am just wondering whether the problem is related to something else.
My system is a stable 64bit up to date installation.
My current kernel is: 3.10.6-2-ARCH. Anyway, even if I downgrade to 3.9.9-1-ARCH, the lid status is always set to "open".

If it matters, suspension and hibernation works if I use the gnome menu or pm scripts.

Any hint?
Thanks.

ewaller · 2013-08-16 15:31:41

You might mention the make and model of your laptop.

Any chance it is a hardware problem?
Have you tried it using an operating system from the USA's Pacific Northwest?

MajinJoko · 2013-08-16 16:45:52

It is a Samsung Serie 5 Ultra, NP530U3C-A07IT, Intel Core i7 3517U, RAM 8 GB, HDD 500 GB + ExpressCache 24 GB, 13.3" HD LED.

The big problem is that the suspend on lid close used to work until a few weeks ago..

Trilby · 2013-08-16 17:27:41

You have disabled lid switch handling in /etc/systemd/logind.conf, right?

If not, that would explain these symptoms: the switch might work, but if systemd handles it, the laptop would never be away to run that cat command while the lid was closed - so even with a sleep N && cat ... it would still return open.

EDIT: I believe the change to have logind handle these by default was relatively recent (though a few weeks does sound more recent, but that would be influenced by how often you update).

Last edited by Trilby (2013-08-16 17:28:43)

MajinJoko · 2013-08-16 18:53:01

Trilby wrote:

You have disabled lid switch handling in /etc/systemd/logind.conf, right?
If not, that would explain these symptoms: the switch might work, but if systemd handles it, the laptop would never be away to run that cat command while the lid was closed - so even with a sleep N && cat ... it would still return open.
EDIT: I believe the change to have logind handle these by default was relatively recent (though a few weeks does sound more recent, but that would be influenced by how often you update).

I haven't changed logind.conf, but if your analysis is correct, this leads to another question: why this laptop doesn't go to suspend anymore when the lid is closed?
Is something changed with systemd? Should I install some other package to get this behaviour back?

Last edited by MajinJoko (2013-08-16 18:53:41)

Trilby · 2013-08-16 19:04:28

*confused*

You say my analysis is correct ... then you say the opposite.

If it does not suspend when the lid is closed - then my analysis is *not* correct.

Something did change with systemd recently to handle such events without the need for other tools (for most hardware). But if the lid used to put the system to sleep, but no longer does, then this is not really the case.

Can we re-evaluate the starting assumptions in the OP? You believe the lid switch is not working, right? What are your reasons for suspecting this? I gather one reason is that the machine used to suspend when the lid was closed, now it doesn't ... correct? How do you verify that it is not suspended? Are there LED indicators, do you ssh in? How had you previously configured it to respond to the lid switch to trigger a suspend? Is there clear/unambiguous reason to assume that this is due to the lid switch not being detected versus some other part of the suspend process failing?

Last edited by Trilby (2013-08-16 19:05:34)

MajinJoko · 2013-08-17 07:31:38

Trilby wrote:

Can we re-evaluate the starting assumptions in the OP? You believe the lid switch is not working, right? What are your reasons for suspecting this?

The only reason I suspect this is because the state of the Lid is always reported as "Open", even if the lid is closed (but the machine is not suspended).
Actually, investigating further I found out that dmesg reports the lid:

[    2.838658] input: Lid Switch as /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input3
[    2.838686] ACPI: Lid Switch [LID0]

I also change my logind.conf:

[Login]
HandleLidSwitch=suspend
LidSwitchIgnoreInhibited=yes

Unfortunately, non only the system does not suspend, but also the journalctl doesn't show any line reporting the closure of the lid.

(As this thread says: https://bbs.archlinux.org/viewtopic.php?id=157526 , I think I should see something like

feb 05 14:00:45 vaiopro13 systemd-logind[407]: Lid closed.
feb 05 14:00:56 vaiopro13 systemd-logind[407]: Lid opened.

which I DON'T SEE)

Trilby wrote:

I gather one reason is that the machine used to suspend when the lid was closed, now it doesn't ... correct? How do you verify that it is not suspended? Are there LED indicators, do you ssh in?

Oh, this is pretty simple: the led changes and - most of all - you need to press the power button to wake up the system (this Samsung ultrabook doesn't wake up when you open the lid, but this behaviour was the same with windows 8 pre-installed).

Trilby wrote:

How had you previously configured it to respond to the lid switch to trigger a suspend?

Actually, I didnt. I was pretty sure it was Gnome that suspended my laptop on lid close (but now this "setting" has disappeared from gnome-tweak).

Trilby wrote:

Is there clear/unambiguous reason to assume that this is due to the lid switch not being detected versus some other part of the suspend process failing?

As I wrote below, the state of the lid is always "open" and the log does not report a line about the lid state change.
Is this enough?
Something "broke" the supend-on-lid-close, and I would like to get it back, therefore I started investigating from the simplest aspects..

Last edited by MajinJoko (2013-08-17 07:40:54)

Trilby · 2013-08-17 12:01:18

Thanks for the breakdown. That does seem the lid switch stopped responding - my skepticism was only to ensure we didn't go down the wrong path. What about ewallers suggestion of trying another os (or even another distro) to see if it is hardware specific or arch related?

MajinJoko · 2013-08-17 12:51:53

Trilby wrote:

Thanks for the breakdown.

Thank you for your help.

Trilby wrote:

That does seem the lid switch stopped responding - my skepticism was only to ensure we didn't go down the wrong path. What about ewallers suggestion of trying another os (or even another distro) to see if it is hardware specific or arch related?

Just tried with a ubuntu live usb, the /proc/acpi/[..]/state is the same as Arch.
I will try, in the next few days, to install Windows 7 and check if it is able to identify whether the lid is open or not.

I can't say if it is relevant, but when I close the lid, the screen turns off, like the physical switch is still working..

MajinJoko · 2013-08-19 20:29:53

found this: https://bugs.launchpad.net/ubuntu/+sour … bug/986724

very interesting..

bazmonkey · 2013-08-21 00:28:57

FWIW, I have a 5 Ultra as well (NP540U3C), kept up-to-date daily, and in recent days lost suspend on lid closing and brightness upon AC state. I have not investigated yet but will inform of any findings.

MajinJoko · 2013-08-21 07:50:01

bazmonkey wrote:

FWIW, I have a 5 Ultra as well (NP540U3C), kept up-to-date daily, and in recent days lost suspend on lid closing and brightness upon AC state. I have not investigated yet but will inform of any findings.

This is enough for me to rule out a hardware problem. Thanks for the info.

bazmonkey · 2013-08-23 05:35:16

After finding this I tried out:
http://askubuntu.com/questions/197874/s … -by-kernel

Turning off the laptop, hitting the battery reset button for 5 sec., and booting back up (ya gotta put in your AC adapter after the battery reset to get it to boot it seems, not sure why), everything is working fine again. I can't get acpi_listen to catch the lid state... because the laptop suspends :-)

It's just a temp fix according to the folks there... I still have no idea what causes this to happen in the first place. After leaving my laptop on accidentally and putting it away several times this last week, I'll take the temp fix! On the plus side, it appears the powers that be are aware of the issue.

bazmonkey · 2013-08-30 23:05:32

The latest kernel update today seems to have fixed this issue for me. My lid state and AC events are functioning over multiple suspends and reboots.

MajinJoko · 2013-09-01 16:08:32

unfortunately I still need to perform the "battery reset" to get it working (even with the newest kernel).

thanks for the feedback.

frigaut · 2013-10-17 11:18:19

Same issue here on a np900x3f.
worked for a while (2 days), then failed. Now is failing consistently.
As noticed above, screen switches off when closing the lid though (was attributed to "hardware detection" working? but then, can't we hack this and implement a workaround for the suspend issue?).

MajinJoko · 2013-10-17 15:40:48

frigaut wrote:

As noticed above, screen switches off when closing the lid though (was attributed to "hardware detection" working? but then, can't we hack this and implement a workaround for the suspend issue?).

My fear this is something far from being possibly "noticed" at a kernel level.

It seems that pressing the reset-battery-button (the pinhole in the back of the laptop) and then charging the laptop restore the suspend-on-lid-close functionality..

frigaut · 2013-10-17 22:23:41

MajinJoko wrote:

It seems that pressing the reset-battery-button (the pinhole in the back of the laptop) and then charging the laptop restore the suspend-on-lid-close functionality..

Yes, I've seen that, thanks. Didn't try it though, as it is also reported that this is not a long term solution, and the issue comes back after a while (hours to days). So for now I've just associated a key to suspend, and I am suspending manually before close lid. Not a big problem for me; otherwise a great laptop.

CREED0R · 2013-10-25 08:36:26

Just wanna add that I too got a Samsung Series 9 (August '13) and lost suspend on lid close couple of weeks ago.
I update quite frequently but suspend on lid did not restore and so far I haven't investigated this any further, since it's just one of the many problems I got with this laptop and recent kernel/systemd versions.

frigaut · 2013-10-25 12:45:54

@CREEDOR: As far as I understand, this is NOT going to be fixed by a kernel upgrade, because it can't :-) Again, as far as I understand, this is a firmware problem. Windows may have a work around, don't know.
I haven't had any issues recently, and most things are working great in fact. What problem(s) did you have?

CREED0R · 2013-10-25 13:55:29

Well, how can this be a firmware problem? It worked with the 3.10 Kernel. Lost that feature when I upgraded to 3.11 (via the linux-git AUR package) and upgraded systemd.

Last edited by CREED0R (2013-10-25 13:56:24)

frigaut · 2013-10-25 21:46:45

That'll be a coincidence. You can restore that functionality by powering down the laptop and clicking on the battery disconnect switching on the back of the laptop, as documented in a number of threads, this one included. I've lost myself the lid detection only a few days after using this laptop, and I don't think it was coincident with a kernel upgrade.
[sorry I keep editing this thing]
I mean: If you follow this thread, you can see that pushing the battery reset hardware button can restore lid detection, which then works for a while but eventually fail again, independently of any kernel upgrade (except in your case, that's why I'm inclined toward a coincidence). That doesn't look like a kernel issue to me. That said, I can be wrong :-)

Last edited by frigaut (2013-10-25 21:53:29)

adb · 2013-12-29 11:36:47

Same issue on ThinkPad X1 Carbon, but dmesg doesn't register the lid either, nor does acpi_listen, nor does system journal.

Arch Linux

#1 2013-08-16 14:59:25

lid state broken

#2 2013-08-16 15:31:41

Re: lid state broken

#3 2013-08-16 16:45:52

Re: lid state broken

#4 2013-08-16 17:27:41

Re: lid state broken

#5 2013-08-16 18:53:01

Re: lid state broken

#6 2013-08-16 19:04:28

Re: lid state broken

#7 2013-08-17 07:31:38

Re: lid state broken

#8 2013-08-17 12:01:18

Re: lid state broken

#9 2013-08-17 12:51:53

Re: lid state broken

#10 2013-08-19 20:29:53

Re: lid state broken

#11 2013-08-21 00:28:57

Re: lid state broken

#12 2013-08-21 07:50:01

Re: lid state broken

#13 2013-08-23 05:35:16

Re: lid state broken

#14 2013-08-30 23:05:32

Re: lid state broken

#15 2013-09-01 16:08:32

Re: lid state broken

#16 2013-10-17 11:18:19

Re: lid state broken

#17 2013-10-17 15:40:48

Re: lid state broken

#18 2013-10-17 22:23:41

Re: lid state broken

#19 2013-10-25 08:36:26

Re: lid state broken

#20 2013-10-25 12:45:54

Re: lid state broken

#21 2013-10-25 13:55:29

Re: lid state broken

#22 2013-10-25 21:46:45

Re: lid state broken

#23 2013-12-29 11:36:47

Re: lid state broken

Board footer