Bug 79381

Summary: Microsoft Surface Pro2 w/Type Cover2 incorrect LID state
Product: ACPI Reporter: Keith Amidon (camalot)
Component: Config-HotplugAssignee: Lan Tianyu (tianyu.lan)
Status: CLOSED WILL_NOT_FIX    
Severity: normal CC: gih, nick, tianyu.lan
Priority: P1    
Hardware: x86-64   
OS: Linux   
Kernel Version: 3.16-rc3 Tree: Mainline
Regression: No
Attachments: acpidump log
dmesg
dmesg w/ec.c patch
dmesg w/ec.c patch & no suspend (system in single-user mode)

Description Keith Amidon 2014-07-02 02:59:44 UTC
On my Microsoft Surface Pro2 w/Type Cover2 I see incorrect LID state as shown by the command:

    cat /proc/acpi/button/lid/LID0/state

Here is a typical sequence showing a problem:

1. Boot the system with the type cover open
2. cat /proc/acpi/button/lid/LID0/state
state:      open
3. Close the cover, the system suspends
4. Open the cover, the system remains suspended
5. Press the power button and the system resumes
6. cat /proc/acpi/button/lid/LID0/state
state:      closed
7. System suspends again after 10-15 seconds, I think because Gnome knows the system is on battery power and thinks the lid is closed.

After this point I can resume the system but nothing I do seems to make it realize the lid is now open.  It will re-suspend again shortly thereafter unless I put it in the dock.

I looked at dmesg logs during this and didn't see anything obvious indicating the source of the problem.  There were no ACPI related messages during suspend/resume.  The following messages during initial boot looked like they could indicate problems, although they may be unrelated:

Jul 01 17:49:23 kea-tablet kernel: ACPI Error: [\SB__.IADP] Namespace lookup failure, AE_NOT_FOUND (20140424/psargs-359)
Jul 01 17:49:23 kea-tablet kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._Q41] (Node ffff880217040b90), AE_NOT_FOUND (20140424/psparse-536)

and

Jul 01 17:49:23 kea-tablet kernel: ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
Jul 01 17:49:23 kea-tablet kernel: input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input11
Jul 01 17:49:23 kea-tablet kernel: [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
Jul 01 17:49:23 kea-tablet kernel: ACPI Warning: SystemIO range 0x000000000000f040-0x000000000000f05f conflicts with OpRegion 0x000000000000f040-0x000000000000f04f (\_SB_.PCI0.SBUS.SMBI) (20140424/utaddress-258)
Jul 01 17:49:23 kea-tablet kernel: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver



A second problem, less serious, is that if I boot the system while it is in the dock and with the cover closed "cat /proc/acpi/button/lid/LID0/state" shows that the state is open.  This is inconvenient since gdm then puts the login screen on the display that is hidden behind the cover instead of the external monitor that is attached to the dock.
Comment 1 Lan Tianyu 2014-07-02 03:13:37 UTC
Hi, could you attach the output of acpidump?
Comment 2 Keith Amidon 2014-07-02 03:49:15 UTC
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.
Comment 3 Lan Tianyu 2014-07-04 02:37:44 UTC
Could you attach the output of dmesg after doing 7 steps in the description?
Comment 4 Keith Amidon 2014-07-04 14:23:27 UTC
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.
Comment 5 Lan Tianyu 2014-07-07 02:35:11 UTC
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>
Comment 6 Keith Amidon 2014-07-07 05:38:12 UTC
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
Comment 7 Keith Amidon 2014-07-07 05:42:15 UTC
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.
Comment 8 Lan Tianyu 2014-07-07 05:56:11 UTC
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.
Comment 9 Keith Amidon 2014-07-07 17:25:01 UTC
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.
Comment 10 Keith Amidon 2014-07-08 00:40:59 UTC
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
Comment 11 Lan Tianyu 2014-07-08 03:13:20 UTC
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)
            }
Comment 12 Keith Amidon 2014-07-08 22:05:05 UTC
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?
Comment 13 Keith Amidon 2014-07-09 15:42:07 UTC
The systemd change from comment 12 did prevent automatic re-suspends due to the lid status, so it works around this issue.
Comment 14 molecular 2015-03-17 14:21:09 UTC
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?