Bug 206843 - Lid close event not detected
Summary: Lid close event not detected
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Lid (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Hans de Goede
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-13 13:22 UTC by Vyacheslav Dikonov
Modified: 2020-07-03 11:47 UTC (History)
1 user (show)

See Also:
Kernel Version: 5.4.24
Subsystem:
Regression: No
Bisected commit-id:


Attachments
ACPI table dump (made by running acpidump -o DSDT.dat) (189.69 KB, text/plain)
2020-07-01 20:27 UTC, Vyacheslav Dikonov
Details

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.

Note You need to log in before you can comment on or make changes to this bug.