3

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.

Ertain
  • 43
  • 6
  • 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 '19 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 '19 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 '19 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 '19 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](https://01.org/blogs/qwang59/2018/how-achieve-s0ix-states-linux).) – Ertain May 12 '19 at 17:06
  • The main issue with LPI is that I can make the laptop go S0i3 from time to time, but I haven't yet figured a way to make it do that consistently when I _want_ it to stay idle. Also, I tried adding the S3 state to the ACPI by guessing the register values, but I've only been hard-crashing the machine for now. – F.X. May 12 '19 at 17:25
  • When I make the notebook suspend without closing the lid (i.e. pressing the power button, or manually making it suspend), it'll stay suspended for a while (I've seen it suspend for over 45 minutes). It may have something to do with the lid opening and closing mechanism, or even something with the keyboard/trackpad peripheral. – Ertain May 12 '19 at 17:41
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/93556/discussion-between-ertain-and-f-x). – Ertain May 12 '19 at 19:23

0 Answers0