2

I have an HP x2 Detachable Notebook (model 10-p018wm) on which I've installed Fedora 29. Pretty much everything about the notebook works: the touchscreen is recognized, the WiFi works, and the media keys work. However, I can't get it to properly suspend to RAM. I have configured in KDE to have it suspend when the power button is pushed, and when the lid is closed. Yet after about a minute, the screen lights up, and it awakens. I have tried changing the configurations in /etc/systemd/logind.conf to handle the lid (i.e. setting HandleLidSwitch=suspend and HandleLidSwitchDocked=suspend), but that doesn't work.

Interestingly, when I boot up the notebook, log in to KDE, and press the power button, it seems to suspend for a while. Yet when I try closing the lid, it will wake up after about a minute.

I had thought that it was due to the WiFi spontaneously turning on and off. But after disabling the kernel modules (iwlmvm and iwlwifi) that doesn't seem to be the case. I also tried disabling bluetooth (both the kernel modules and the systemd service), but that didn't work, either.

Here are some of the facts. The notebook is UEFI-based, running kernel 5.0.8-200.fc29. The contents of my /etc/default/grub file are as follows:

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rhgb quiet initcall_debug no_console_suspend"
GRUB_DISABLE_RECOVERY="true"

I put in the "initcall_debug" and "no_console_suspend" parts so that I could see what exactly is going on during pre-suspension and post-suspension. Here's a journal log of when I pressed the power button, a log of when I closed the lid, and a log for when I tried pushing the power button after closing and then opening the lid.

Edit #1: I guess I should mention that the contents of /proc/acpi/wakeup is empty; when I use the cat /proc/acpi/wakeup command, I only get the line Device S-state Status Sysfs node.

Edit #2: Here's the output from using echo 1 | sudo tee /sys/power/pm_debug_messages in suspending:

kernel: ACPI: \_PR_.CPU0: LPI: Device not power manageable
kernel: ACPI: \_PR_.CPU1: LPI: Device not power manageable
kernel: ACPI: \_PR_.CPU2: LPI: Device not power manageable
kernel: ACPI: \_PR_.CPU3: LPI: Device not power manageable
kernel: ACPI: \_SB_.PCI0.SEC0: LPI: Device not power manageable
kernel: ACPI: \_SB_.PCI0.SDHB: LPI: Constraint not met; min power state:D3hot current power state:D0
kernel: ACPI: \_SB_.PCI0.SDHB: LPI: Constraint not met; min power state:D3hot current power state:D0

Also, here's the output from lspci -vv.

  • I have the same model, and the same issue. One additional debugging trick is to use echo 1 | sudo tee /sys/power/pm_debug_messages ; on my model this shows LPI: Device not power manageable for a couple of devices including the CPU and PCI bus. Going to investigate more. – F.X. May 11 at 13:49
  • Also, /sys/power/mem_sleep only contains s2idle, so it would appear that there is no support for deeper sleep modes than the basic, default mode. – F.X. May 11 at 21:54
  • Thank you for the comments, @F.X. Which distro are you using? In my situation, /sys/power/mem_sleep says the same thing. I think I've narrowed it down to something related to a few components: the intel_atomisp2_pm module, the hid_elan module, and the XHC1 component. – Ertain May 12 at 16:00
  • Arch Linux, using the default kernel (5.0.13). After more investigation, this seems to be related to the new low power sleep states (S0ix) that are supported by Windows 10, which means that the ACPI doesn't expose the S3 (sleep-to-RAM) state at all. – F.X. May 12 at 16:51
  • I was wondering about the S0ix stuff. Guess it's going to be a while before S0ix capabilities are properly supported in this model. (BTW, for more information on such power states in the kernel, see the 01.org post here.) – Ertain May 12 at 17:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.