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.
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?