When the laptop is suspended from either console using 'systemd suspend' or a DE interface (the lid stays open), and subsequently resumed, the lid state is always "open". This means that neither systemd nor upower detects lid close/open events. In addition, /proc/acpi/buttons/lid/LID/state always reports "state: open" even when the lid is actually closed. On the other hand, if the suspend was performed using the lid switch (closing the lid) the lid state is properly reported after resume. The laptop is HP Elitebook 2530p running archlinux x86_64 with systemd (udev) 198 and vanilla kernel 3.8.2, 3.8.3, 3.8.4. Also, I can reproduce this issue with two BIOSes: F.13 and F.22 from HP. I'm sorry that I can't provide any more debug info... Thank you, Leonid.
Please attach the output of acpidump. Could you test this issue on the newest kernel?
Here is the acpidump output (acpidump.out). Regarding the kernel, I am on 3.8.4. Do you mean 3.9-rc4? Thanks, L.
Created attachment 96471 [details] acpidump(8) output
(In reply to comment #0) > When the laptop is suspended from either console using 'systemd suspend' or a > DE interface (the lid stays open), and subsequently resumed, the lid state is > always "open". This means that neither systemd nor upower detects lid > close/open events. Do you mean system resume just after being suspended? > In addition, /proc/acpi/buttons/lid/LID/state always reports > "state: open" even when the lid is actually closed. > How do you get this since the system is suspended when lid is closed. I mean 3.9-rc4.
I'm sorry if I was ambiguous in my original post... First, my hardware doesn't support resume on lid open -- I have to press power button to resume. Also, after _cold boot_, lid ACPI events are properly generated. Now, two suspend scenarios are possible: (1) Suspend is performed via 'systemd suspend' _not_ using lid (which physically stays _open_). The system does not spontaneously resume. However, after resume (when I press the power button), the lid state is always 'open', and _no_ lid ACPI events are generated by the kernel (I ran 'cat /proc/acpi/buttons/lid/LID/state' in a loop and upower --monitor-detail, while opening and closing the lid -- no state change). Note, that systemd also does not detect lid events. (2) Suspend is performed by closing the lid (via systemd-logind). Again, there are no spontaneous resumes. In contrast to case (1), after resuming the system, lid state is properly reported. In both cases, there are no errors in syslog/journal... I'll test -rc4 as soon as I build it :)
(In reply to comment #5) > I'm sorry if I was ambiguous in my original post... > > First, my hardware doesn't support resume on lid open -- I have to press > power > button to resume. Could you the /proc/acpi/wakeup to check the lid wakeupable has been enabled? > Also, after _cold boot_, lid ACPI events are properly > generated. cold boot? cool reboot the machine, right? after reboot, you lid can produce acpi event? You can use acpi_listen to catch the lid event. > > Now, two suspend scenarios are possible: > (1) Suspend is performed via 'systemd suspend' _not_ using lid (which > physically stays _open_). The system does not spontaneously resume. However, > after resume (when I press the power button), the lid state is always 'open', > and _no_ lid ACPI events are generated by the kernel (I ran 'cat > /proc/acpi/buttons/lid/LID/state' in a loop and upower --monitor-detail, > while > opening and closing the lid -- no state change). Note, that systemd also does > not detect lid events. Since you have not closed or opened the lid, the lid state should be always open and there is no lid event. I don't see what's wrong. > > (2) Suspend is performed by closing the lid (via systemd-logind). Again, > there > are no spontaneous resumes. In contrast to case (1), after resuming the > system, > lid state is properly reported. Could you try to close lid physically to test? lid state comes from bios. > > In both cases, there are no errors in syslog/journal... > > I'll test -rc4 as soon as I build it :)
> Could you the /proc/acpi/wakeup to check the lid wakeupable has been enabled? My laptop can't wakeup using lid -- I have to press power button. $ cat /proc/acpi/wakeup Device S-state Status Sysfs node LANC S0 *enabled pci:0000:00:19.0 HDEF S4 *disabled pci:0000:00:1b.0 RP02 S5 *disabled pci:0000:00:1c.1 WNIC S5 *disabled pci:0000:02:00.0 USB1 S0 *enabled pci:0000:00:1d.0 USB2 S0 *enabled pci:0000:00:1d.1 USB3 S0 *enabled pci:0000:00:1d.2 USB4 S0 *enabled pci:0000:00:1a.0 USB5 S0 *enabled pci:0000:00:1a.1 USB6 S0 *enabled pci:0000:00:1a.2 U6RM S0 *disabled EHC1 S0 *enabled pci:0000:00:1d.7 EHC2 S0 *enabled pci:0000:00:1a.7 PCIB S5 *disabled pci:0000:00:1e.0 HST1 S5 *disabled > cold boot? cool reboot the machine, right? after reboot, you lid can produce > acpi event? You can use acpi_listen to catch the lid event. Yes, sorry for "cold", I meant either boot or reboot. I used upower, systemd and watched /proc/acpi/buttons/lid/LID/state directly (cat to a file). > I don't see what's wrong. After resume (remember, we DID NOT use lid to suspend) linux does not generate ANY lid events. The kernel always shows that lid is OPEN (/proc/acpi/buttons/lid/LID/state does not reflect actual lid state). Closing the lid has NO effect. > Could you try to close lid physically to test? lid state comes from bios. If the suspend is triggered using lid, after resume lid state is properly reported by the kernel. That's CONTRARY to the above case.
(In reply to comment #7) > > cold boot? cool reboot the machine, right? after reboot, you lid can > produce > > acpi event? You can use acpi_listen to catch the lid event. > > Yes, sorry for "cold", I meant either boot or reboot. I used upower, systemd > and watched /proc/acpi/buttons/lid/LID/state directly (cat to a file). > Please use acpi_listen to test, because it actually catchs acpi lid event which has different code path with lid state and come from gpe interrupt. Please attach "grep . /sys/firmware/acpi/interrupts/*." and dmesg after open/close lid. For LID state, it come from a gpio pin From bios's ACPI table DSDT. Device (LID) { Name (_HID, EisaId ("PNP0C0D")) Method (_LID, 0, NotSerialized) { Store (0x00, Local0) Store (0x00, LIDS) If (And (GPL0, 0x2000)) { Store (0x01, Local0) Store (0x01, LIDS) } Return (Local0) } } Field (GPIO, ByteAcc, NoLock, Preserve) { Offset (0x0C), GPL0, 32, Offset (0x2C), GIV, 32, Offset (0x38), GPL2, 32 } _LID returns LID state and "GPL0" determine the return value. The /proc/acpi/buttons/lid/LID/state just expose the return value. So lid state totally depends on the gpio pin. > > I don't see what's wrong. > > After resume (remember, we DID NOT use lid to suspend) linux does not > generate > ANY lid events. > In this case, do you close and open the lid physically? From your descriptor, you press the power button to make system resume and during this procedure without any lid operation, right? If you do lid operation, there should be a lid event, use acpi_listen to catch the event. And compare the output of "grep . /sys/firmware/acpi/interrupts/*." before and after. > The kernel always shows that lid is OPEN (/proc/acpi/buttons/lid/LID/state > does > not reflect actual lid state). Closing the lid has NO effect. I just said this comes from gpio pin. I have not idea about this since this totally comes from hardware. > > > Could you try to close lid physically to test? lid state comes from bios. > > If the suspend is triggered using lid, after resume lid state is properly > reported by the kernel. That's CONTRARY to the above case. In this case, the lid state always is "open".
ping...
I was travelling in the past 2 weeks, so I apologize for disappearing. In the meantime I checked 3.8.8 and 3.9rc8 -- and the lid state _is_ properly reported after resume (even by monitoring the lid file in /proc)... Not sure what actually solved the issue, but sorry for the noise. Thanks.
Ok. So this bug is already fixed. So close it. But if you can find which commit fix it, that will be great. Thanks.