Bug 79381

Hi, could you attach the output of acpidump?

Created attachment 141881 [details]
acpidump log

This was taken after booting my Surface Pro2 with the Type Cover2 closed while in the dock.  I had not suspended/resumed at all.

Could you attach the output of dmesg after doing 7 steps in the description?

Created attachment 142061 [details]
dmesg

Dmesg for the full scenario:

Jul 01 17:50:37 kea-tablet kea-comment: Boot complete with cover open
Jul 01 17:51:04 kea-tablet kea-comment: Gnome control panel allows modifying built-in display, everything normal.
Jul 01 17:51:14 kea-tablet kea-comment: Suspending using power switch with cover open.
Jul 01 17:51:43 kea-tablet kea-comment: Resume complete using power switch with cover still open.
Jul 01 17:52:05 kea-tablet kea-comment: Display control panel still allows modifying display.
Jul 01 17:52:20 kea-tablet kea-comment: Waiting for a minute to see if auto-suspend occurs.
Jul 01 18:02:10 kea-tablet kea-comment: Now trying closing the cover
Jul 01 18:02:36 kea-tablet kea-comment: Resume complete after opening cover and pressing power button
Jul 01 18:02:51 kea-tablet kea-comment: Display control panel won't allow changing display
Jul 01 18:03:10 kea-tablet kea-comment: Re-suspend happened after finished typing previous comment
Jul 01 18:04:43 kea-tablet kea-comment: Re-suspend happened again, same situation
Jul 01 18:05:23 kea-tablet kea-comment: Re-suspend happened again, shutting down now.

The LID status was open until after the "Resume complete after opening cover and pressing power button" step and then stayed closed.

Could you apply the following patch and provide the output of dmesg after system resume? Thanks.

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 5492798..2ad8a0e 100644
lanlty@bee:/c/lanlty/kernel/linux-pm$ git diff drivers/acpi/ec.c 
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index ad11ba4..0708d71 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -27,7 +27,7 @@
  */
 
 /* Uncomment next line to get verbose printout */
-/* #define DEBUG */
+#define DEBUG
 #define pr_fmt(fmt) "ACPI : EC: " fmt
 
 #include <linux/kernel.h>

Created attachment 142221 [details]
dmesg w/ec.c patch

I tried to reproduce the same scenario as the previously attached scenario but the behavior was slightly different.  It seemed like the suspend on cover close was significantly delayed.  The sequence of actions I took (also captured in the log) was:

Jul 06 22:28:50 kea-tablet kea-comment: Booted laptop with lid open
Jul 06 22:28:53 kea-tablet kea-comment: exec:  cat /proc/acpi/button/lid/LID0/state\m
Jul 06 22:28:53 kea-tablet kea-comment: state:      open
Jul 06 22:29:06 kea-tablet kea-comment: Closing cover
Jul 06 22:29:21 kea-tablet kea-comment: Laptop did not suspend
Jul 06 22:29:25 kea-tablet kea-comment: exec:  cat /proc/acpi/button/lid/LID0/state\m
Jul 06 22:29:25 kea-tablet kea-comment: state:      closed
Jul 06 22:29:40 kea-tablet kea-comment: Waiting to see if there is a delayed suspend
Jul 06 22:30:32 kea-tablet kea-comment: Still no suspend, trying closing cover again
Jul 06 22:30:46 kea-tablet kea-comment: Still didn't suspend
Jul 06 22:30:55 kea-tablet kea-comment: exec:  cat /proc/acpi/button/lid/LID0/state\m
Jul 06 22:30:55 kea-tablet kea-comment: state:      closed
Jul 06 22:31:11 kea-tablet kea-comment: Suspend immediately after dumped lid state
Jul 06 22:31:17 kea-tablet kea-comment: Resume complete after opening cover and pressing power button
Jul 06 22:31:19 kea-tablet kea-comment: exec:  cat /proc/acpi/button/lid/LID0/state\m
Jul 06 22:31:19 kea-tablet kea-comment: state:      closed
Jul 06 22:31:30 kea-tablet kea-comment: Wait for another suspend
Jul 06 22:31:57 kea-tablet kea-comment: Resume complete after pressing power button

I should maybe clarify in comment 6 that I was typing all comments into the log using the cover keyboard, so at those times the cover was always open. That is, I would close the cover to try to suspend then re-open it.  In all cases where the LID state as reported "closed" the cover was actually open.

Could you make system not suspend when LID closes? And then provide the output of dmesg after closing and opening LID.

So far, I don't find the EC event for LID opening and there are some events for LID closing in the log.

Created attachment 142311 [details]
dmesg w/ec.c patch & no suspend (system in single-user mode)

Here's the new log with no suspend happening.  I achieved this by booting into single user mode.  I tried opening and closing the cover a few more times in case that helps.  The sequence of actions (also captured in the log) was:

Jul 07 10:08:41 kea-tablet kea-comment: Finished booting into single-user mode with cover open
Jul 07 10:08:46 kea-tablet kea-comment: exec:  cat /proc/acpi/button/lid/LID0/state\m
Jul 07 10:08:46 kea-tablet kea-comment: state:      open
Jul 07 10:08:58 kea-tablet kea-comment: Closing cover for 30 seconds
Jul 07 10:09:35 kea-tablet kea-comment: Cover opened
Jul 07 10:09:41 kea-tablet kea-comment: exec:  cat /proc/acpi/button/lid/LID0/state\m
Jul 07 10:09:41 kea-tablet kea-comment: state:      closed
Jul 07 10:09:50 kea-tablet kea-comment: Waiting for another minute to see what happens
Jul 07 10:10:58 kea-tablet kea-comment: Waiting for another minute to see what happens
Jul 07 10:11:03 kea-tablet kea-comment: exec:  cat /proc/acpi/button/lid/LID0/state\m
Jul 07 10:11:03 kea-tablet kea-comment: state:      closed
Jul 07 10:11:57 kea-tablet kea-comment: exec:  cat /proc/acpi/button/lid/LID0/state\m
Jul 07 10:11:57 kea-tablet kea-comment: state:      closed
Jul 07 10:12:04 kea-tablet kea-comment: No suspend occurred.
Jul 07 10:13:02 kea-tablet kea-comment: No going to try closing and opening cover 5 times, with a 5 second wait in closed state each time
Jul 07 10:13:08 kea-tablet kea-comment: Closing #1
Jul 07 10:13:20 kea-tablet kea-comment: exec:  cat /proc/acpi/button/lid/LID0/state\m
Jul 07 10:13:20 kea-tablet kea-comment: state:      closed
Jul 07 10:13:24 kea-tablet kea-comment: Closing #2
Jul 07 10:13:36 kea-tablet kea-comment: exec:  cat /proc/acpi/button/lid/LID0/state\m
Jul 07 10:13:36 kea-tablet kea-comment: state:      closed
Jul 07 10:13:42 kea-tablet kea-comment: Closing #3
Jul 07 10:13:54 kea-tablet kea-comment: exec:  cat /proc/acpi/button/lid/LID0/state\m
Jul 07 10:13:54 kea-tablet kea-comment: state:      closed
Jul 07 10:13:58 kea-tablet kea-comment: Closing #4
Jul 07 10:14:10 kea-tablet kea-comment: exec:  cat /proc/acpi/button/lid/LID0/state\m
Jul 07 10:14:10 kea-tablet kea-comment: state:      closed
Jul 07 10:14:13 kea-tablet kea-comment: Closing #5
Jul 07 10:14:25 kea-tablet kea-comment: exec:  cat /proc/acpi/button/lid/LID0/state\m
Jul 07 10:14:25 kea-tablet kea-comment: state:      closed

One other change compared to previous runs was that I upgraded to the rc4 kernel before taking these logs.

I'm not sure if this is important, but one thing I noticed that makes this especially annoying is that the LID state seems to be updated even when the laptop is suspended.  For example:

1. Boot laptop with cover open.
2. Lid state is open
2. Manually suspend laptop using power switch.
3. Close lid
4. Open lid
5. Manually unsuspend laptop using power switch
6. Lid state is closed and stays that way
7. When on battery the system will suspend shortly after resume

From the log, there is still no EC event for LID open.

From ACPI tables, the LID status depends on EC event for LID open and close. When there is LID event, bios code will change LID status. But don't find EC event for LID open event. Even when close LID without system suspend. This maybe caused by firmware or hardware issue. So far, don't find what can be done in the kernel side. Please try new Bios or EC firmware. 


            Method (_Q36, 0, NotSerialized)  // _Qxx: EC Query
            {
                Store (Zero, LIDS) <=== Mark close
                Store (0x36, DBG8)
                Notify (LID0, 0x80)
            }

            Method (_Q37, 0, NotSerialized)  // _Qxx: EC Query
            {
                Store (One, LIDS) <=== Mark open
                Store (0x37, DBG8)
                Notify (LID0, 0x80)
            }

So I did a few follow-up checks in Windows:

1. There was a firmware update.  I installed it, but unfortunately
   it didn't fix the problem under Linux.
2. The behavior in Windows is that closing the lid causes the 
   laptop to suspend but opening the lid, but itself, doesn't 
   unsuspend the laptop, you have to press the power button.

I wonder if Windows doesn't pay attention to the actual state recorded in ACPI but just locks for the close event and suspends.  That would explain the broken hardware.

I found that in recent GNOME releases on systemd-based distrubutions at least the suspend on lid close is handled by systemd-logind.  Adding this line to `/etc/systemd/logind.conf` should prevent the lid status from triggering changes to the device:

    HandleLidSwitch=ignore

Hopefully this will work around the issue for now.  I'd still like to get this fixed at some point as it would be preferable to have the laptop suspend when the lid is closed.

Does anyone know of tools I can run in Windows that would help figure out what Windows is doing so we can see whether there is somethign we can do to fix the behavior in Linux?

The systemd change from comment 12 did prevent automatic re-suspends due to the lid status, so it works around this issue.

I'm also experiencing the issue.

no Lid open event is ever caught.

After power cycle (with open lid) I can receive exactly one Lid close event, then the Lid is closed forever.

I would love to be able to use lid events for suspending my beloved machine.

Does anyone have a solution?