Bug 206843

Summary:	Lid close event not detected
Product:	ACPI	Reporter:	Vyacheslav Dikonov (sdiconov)
Component:	Power-Lid	Assignee:	Hans de Goede (jwrdegoede)
Status:	CLOSED CODE_FIX
Severity:	normal	CC:	rui.zhang
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	5.4.24	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	ACPI table dump (made by running acpidump -o DSDT.dat)

Description Vyacheslav Dikonov 2020-03-13 13:22:08 UTC

After recent upgrade from 4.19.43 to 5.4.24 I noticed that my laptop (Macbook 17" late 2011) does not detect the event of closig the lid anymore and fails to suspend.

Observed facts:
1) sudo cat /proc/acpi/button/lid/LID0/state ALWAYS yields "open" even when the lid is closed.

2) running the command "systemctl suspend" and subsequent waking up cures the problem. /proc/acpi/button/lid/LID0/state begins to report "closed" when appropriate. UNTIL a full reboot. The hardware sensor is OK.

3) Any manipulations with HandleLidSwitch* in /etc/systemd/logind.conf have no effect.

Comment 1 Vyacheslav Dikonov 2020-04-20 08:57:31 UTC

This bug is still present in kernel 5.4.31. Kernels 4.x woked well. The hardware lid sensor is OK and works stable after running "systemctl suspend" manually on each reboot.

Comment 2 Vyacheslav Dikonov 2020-04-20 09:02:36 UTC

NB! An affected notebook can easily be closed, put into a soft plush (and thus thermal insulating) case and left there by a user assuming that the computer sleeps. The result is an EXTREMELY hot running computer posing a risk of fire and eventual human casualties.

Comment 3 Zhang Rui 2020-06-29 14:05:29 UTC

re: 1) sudo cat /proc/acpi/button/lid/LID0/state ALWAYS yields "open" even when the lid is closed.
can you run git bisect to find out which commit introduces this problem?

Comment 4 Zhang Rui 2020-06-29 14:09:47 UTC

hmm, I've seem quite some updates from Hans, maybe he has more ideas on this, without bisecting.

Comment 5 Hans de Goede 2020-06-29 15:40:43 UTC

Vyacheslav, can you attach an acpidump of your macbook please?

Comment 6 Vyacheslav Dikonov 2020-07-01 20:27:13 UTC

Created attachment 290041 [details]
ACPI table dump (made by running acpidump -o DSDT.dat)

I am running kernel 5.5.17-un-def-alt1 (ALTLinux Sisyphus standard built) now.
The dump was made using this kernel.

Comment 7 Vyacheslav Dikonov 2020-07-01 20:32:25 UTC

It appears that the bug no longer manifests itself with kernel 5.5.17.

Comment 8 Hans de Goede 2020-07-02 17:49:08 UTC

(In reply to Vyacheslav Dikonov from comment #7)
> It appears that the bug no longer manifests itself with kernel 5.5.17.

Thank you for letting us know about this, I guess that means that this bug can be closed now ?

Comment 9 Vyacheslav Dikonov 2020-07-03 11:16:41 UTC

I am not sure. Has the reason been found? It can still happen that my hw is OK now, but some other hw is still affected.

Maybe, if several versions of the kernel turn out to be bug-free, we can deem the problem to be self-resolved.

Comment 10 Hans de Goede 2020-07-03 11:47:25 UTC

(In reply to Vyacheslav Dikonov from comment #9)
> I am not sure. Has the reason been found? It can still happen that my hw is
> OK now, but some other hw is still affected.

You are/were the only reporter of this problem. No one else has seen/reported this.

So lets close this, we can always re-open it later if necessary.