Bug 73161 - Lid opening not detected after resume on samsung laptop
Summary: Lid opening not detected after resume on samsung laptop
Status: CLOSED PATCH_ALREADY_AVAILABLE
Alias: None
Product: ACPI
Classification: Unclassified
Component: EC (show other bugs)
Hardware: i386 Linux
: P1 normal
Assignee: acpi_ec
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-29 21:47 UTC by Nicolas Porcel
Modified: 2014-04-01 11:29 UTC (History)
2 users (show)

See Also:
Kernel Version: 3.13.7
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments

Description Nicolas Porcel 2014-03-29 21:47:49 UTC
Since the upgrade from kernel 3.13.6 to kernel 3.13.7, the lid opening is not detected after opening the screen to resume. Downgrading solves the problem. It seems to be due to the following patch:

ACPI / EC: Clear stale EC events on Samsung systems
commit ad332c8a45330d170bb38b95209de449b31cd1b4 upstream.

Some precision:
- My laptop is a Samsung N210, running ArchLinux i686
- I have another laptop (a Dell) running the same OS (but in 64 bits) and the lid switch works perfectly
- My power manager is systemd-logind

Test case:
- Start the computer
- Suspend the laptop by closing the lid (other way of suspending doesn't affect the system)
- When the laptop wake-up (after opening the screen), the lid state (cat /proc/acpi/button/lid/LID0/state) is still closed
- This causes the power manager to suspend again the laptop, and suspend it again after the next resume and so on
- In the logs, I can find the following message after the first resume:
ACPI: EC: 1 stale EC events cleared
- Then if I disable the power manager, close the screen for a few seconds and open it, the lid state goes back to open

It seems that the screen opening event is cleared by the function acpi_ec_clear after resume, and the following events are ignored.
Comment 1 Aaron Lu 2014-03-31 06:02:27 UTC
If you revert that commit ad332c8a45330d170bb38b95209de449b31cd1b4, will the problem go away?
Comment 2 Nicolas Porcel 2014-03-31 11:05:27 UTC
(In reply to Aaron Lu from comment #1)
> If you revert that commit ad332c8a45330d170bb38b95209de449b31cd1b4, will the
> problem go away?

I compiled the kernel reverting the commit and the problem is solved. Recompiling the kernel with the patch make the problem reappear.

I used the kernel 3.13.7 with the patches used for the Archlinux custom kernel. I can send the patches if needed, but I am not sure it will be useful.

Thank you
Comment 3 Lan Tianyu 2014-03-31 11:47:33 UTC
I think this bug is the same as the following link.
http://marc.info/?l=linux-acpi&m=139564741817605&w=2
Comment 4 Nicolas Porcel 2014-03-31 16:54:25 UTC
(In reply to Lan Tianyu from comment #3)
> I think this bug is the same as the following link.
> http://marc.info/?l=linux-acpi&m=139564741817605&w=2

Thank you for the link, this is exactly the same bug.
Both of the patches at that link are working for me (although I had to change the product name in the second one):
http://marc.info/?l=linux-acpi&m=139584477217275&w=2
I subscribed to the mailing. Maybe you can transfer me one of the email so I can respond to the thread.
Thank you.
Comment 5 Nicolas Porcel 2014-04-01 11:29:40 UTC
A patch is available and is currently being tested. Here is the link:
https://bugzilla.kernel.org/show_bug.cgi?id=44161#c173

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