Suspend issue with latest Manjaro 4.17.0-1

I am having issue with suspend when lid of laptop is closed.

 systemd-inhibit
 Who: PowerDevil (UID 1000/whitewalker, PID 961/org_kde_powerde)
What: handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch
 Why: KDE handles power events
Mode: block

 Who: ModemManager (UID 0/root, PID 415/ModemManager)
What: sleep
 Why: ModemManager needs to reset devices
Mode: delay

 Who: NetworkManager (UID 0/root, PID 417/NetworkManager)
What: sleep
 Why: NetworkManager needs to turn off networks
Mode: delay

 Who: Screen Locker (UID 1000/whitewalker, PID 864/ksmserver)
What: sleep
 Why: Ensuring that the screen gets locked before going to sleep
Mode: delay

 Who: UPower (UID 0/root, PID 779/upowerd)
What: sleep
 Why: Pause device polling
Mode: delay

following this link 'http://www.freedesktop.org/wiki/Software/systemd/inhibit/' it seems 'systemd-inhibit' is prevented from reacting to event as the mode is set to 'block'.
In my understanding the error I am getting when closing the lid of my laptop 'acpi device:40: Cannot transition to power state D3hot for parent in (unknown)' is probably explained due to the block.

How can I unblock and allow systemd-inhebit to react to lid close and put my laptop to sleep ?

reading this I tried to modify logind but to no avail https://wiki.archlinux.org/index.php/Power_management#Power_management_with_systemd

When clicking on the suspend key (Fn + F1) it works as expected. I can wake up my laptop. If I do it a second time, I am getting a black screen when trying waking up the laptop. I know its up and the keyboard is responding. The screen is simply black. This is definitely a show stopper.

I have put debug on systemd and got more data. We see when the lid is closed and when the lid is open.

Mai 13 17:45:57 redmoon systemd-logind[412]: Got message type=signal sender=:1.1 
destination=n/a path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager 
member=UnitRemoved cookie=369 reply_cookie=0 signature=so error-name=n/a error- 
message=n/a
**Mai 13 17:46:20 redmoon systemd-logind[412]: Lid closed.**
Mai 13 17:46:20 redmoon systemd-logind[412]: device-enumerator: scan all dirs
Mai 13 17:46:20 redmoon systemd-logind[412]:   device-enumerator: scanning /sys/bus
Mai 13 17:46:20 redmoon systemd-logind[412]:   device-enumerator: scanning /sys/class
Mai 13 17:46:20 redmoon org_kde_powerdevil[951]: powerdevil: Suspend session triggered with 
QMap(("Explicit", QVariant(bool, true))("Type", QVariant(uint, 0)))
Mai 13 17:46:20 redmoon systemd-logind[412]: Refusing operation, handle-lid-switch is inhibited.
Mai 13 17:46:20 redmoon systemd-logind[412]: device-enumerator: scan all dirs
Mai 13 17:46:20 redmoon systemd-logind[412]:   device-enumerator: scanning /sys/bus
Mai 13 17:46:20 redmoon systemd-logind[412]:   device-enumerator: scanning /sys/class
Mai 13 17:46:20 redmoon systemd-logind[412]: Refusing operation, handle-lid-switch is inhibited.
Mai 13 17:46:20 redmoon kernel: pci_bus 0000:01: Allocating resources
Mai 13 17:46:20 redmoon kernel: pcieport 0000:00:1c.0: bridge window [io  0x1000-0x0fff] to [bus 
01] add_size 1000
Mai 13 17:46:20 redmoon kernel: pcieport 0000:00:1c.0: bridge window [mem 0x00100000- 
0x000fffff 64bit pref] to [bus 01] add_size 200000 add_align 100000
Mai 13 17:46:20 redmoon kernel: pcieport 0000:00:1c.0: bridge window [mem 0x00100000- 
0x000fffff] to [bus 01] add_size 200000 add_align 100000
Mai 13 17:46:20 redmoon kernel: pci_bus 0000:02: Allocating resources
Mai 13 17:46:20 redmoon kernel: pcieport 0000:00:1c.3: bridge window [io  0x1000-0x0fff] to [bus 
02] add_size 1000
Mai 13 17:46:20 redmoon kernel: pcieport 0000:00:1c.3: bridge window [mem 0x00100000- 
0x000fffff 64bit pref] to [bus 02] add_size 200000 add_align 100000
Mai 13 17:46:20 redmoon kernel: pci_bus 0000:03: Allocating resources
Mai 13 17:46:20 redmoon kernel: pcieport 0000:00:1c.4: bridge window [io  0x1000-0x0fff] to [bus 
03] add_size 1000
Mai 13 17:46:20 redmoon kernel: pcieport 0000:00:1c.4: bridge window [mem 0x00100000- 
0x000fffff 64bit pref] to [bus 03] add_size 200000 add_align 100000
   Mai 13 17:46:20 redmoon kernel: pcieport 0000:00:1c.0: BAR 14: assigned [mem 0xdf200000- 
   0xdf3fffff]
   Mai 13 17:46:20 redmoon kernel: pcieport 0000:00:1c.0: BAR 15: assigned [mem 0xdf400000- 
   0xdf5fffff 64bit pref]
   Mai 13 17:46:20 redmoon kernel: pcieport 0000:00:1c.3: BAR 15: assigned [mem 0xdf600000- 
   0xdf7fffff 64bit pref]
   Mai 13 17:46:20 redmoon kernel: pcieport 0000:00:1c.4: BAR 15: assigned [mem 0xdf800000- 
   0xdf9fffff 64bit pref]
   Mai 13 17:46:20 redmoon kernel: pcieport 0000:00:1c.0: BAR 13: assigned [io  0x2000-0x2fff]
   Mai 13 17:46:20 redmoon kernel: pcieport 0000:00:1c.3: BAR 13: assigned [io  0x3000-0x3fff]
   Mai 13 17:46:20 redmoon kernel: pcieport 0000:00:1c.4: BAR 13: assigned [io  0x4000-0x4fff]
   Mai 13 17:46:20 redmoon kernel: acpi device:40: Cannot transition to power state D3hot for 
  parent  in (unknown)
 **Mai 13 17:46:29 redmoon systemd-logind[412]: Lid opened.**
 Mai 13 17:46:29 redmoon kernel: pci_bus 0000:01: Allocating resources
 Mai 13 17:46:29 redmoon kernel: pci_bus 0000:02: Allocating resources
 Mai 13 17:46:29 redmoon kernel: pci_bus 0000:03: Allocating resources
 Mai 13 17:46:29 redmoon kernel: acpi device:40: Cannot transition to power state D3hot for parent 
 in 
 (unknown)
 Mai 13 17:46:29 redmoon systemd[1]: systemd-journald.service: Got notification message from 
 PID 
325 (WATCHDOG=1)

4.17 is still pre-release. Check with 4.16.

Thank you for replying.
I did try 4.14 and still the same issue. I am thinking possibly a KDE bug ?
I have been using Manjaro for the past year on the same laptop and no issue. Since latest update (KDE) I have the issue. This is why I am incline to believe this is possibly a KDE bug.
Also, this is a fresh install from last week. No Upgrade.

PS: systemctl suspend works great.

Anyone ? This issue is really annoying. I have been trying to find a fix for a couple of days but to no avail. If no fix, I may have to switch which is something I definitely dont want to do. I like Manjaro and want to keep using Manjaro. Could it be something I am doing ?
The machine suspend anyother way but when closing the lid.

What changed in the "lastest update" ? Look in /var/log/pacman.log

Have you tired switching up to testing to see if it has already been resolved?

Thank you for taking the time.
It seems (could be wrong) that I may be one the few having this issue. After scouring the internet for the past days, I found very little as far as a potential bug or other people having this same issue.
So I am uncertain if moving to unstable would make any difference. I will give it a try as soon as I have some time. Unfortunately, this is my work machine and my only machine. It does make it harder to have to upgrade or do a fresh install of the system.

No, on testing would be more soundly as the unstable is not quite for a work machine but rather for experiments.

Watchdog seems to have a negative effect on many systems for some reason, so, this might help

inxi -Fxcz0

As @jonathon requested post the section of /var/pacman.log containing the specific update than created the issue. Was this Plasma 5.12.4 -> 5.12.5 ? Did you apply your .pacnew files?

What is the output of sudo systemctl suspend ?

What are the contents of ~/.config/powermanagementprofilesrc ?

Do you have multiple monitors? If so this setting could be blocking the suspend.

[AC][HandleButtonEvents]
...
triggerLidActionWhenExternalMonitorPresent=false

EDIT :

Testing this now on my laptop and I experience the same issue, laptop lid close is not initiating suspend.

Manual systemd suspend works.

sudo systemctl suspend

But powerdevil is blocking lid close suspend, which systemd is honoring.

$ systemd-inhibit --list
...
     Who: PowerDevil (UID 1000, PID 1365/org_kde_powerde)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch
     Why: KDE handles power events
    Mode: block
...

Testing on a second laptop and suspend works with lid close, strange.

@sueridgepipe
this is a fresh install. No update and no pacnew files.
I don't have any monitor. I am using my laptop DELL E7440 with the built in display.
I will provide the rest of the required data as soon as I have time. I am at the moment at work :slight_smile:

1 Like

Okay got somewhere, I think.

When I try to lid close suspend I get these messages in dmesg

[  917.065478] atkbd serio0: Unknown key pressed (translated set 2, code 0x97 on isa0060/serio0).
[  917.065483] atkbd serio0: Use 'setkeycodes e017 <keycode>' to make it known.
[  917.069499] atkbd serio0: Unknown key released (translated set 2, code 0x97 on isa0060/serio0).
[  917.069504] atkbd serio0: Use 'setkeycodes e017 <keycode>' to make it known.

Doing a bit of searching it seems to be related to hardware specific rfkill, I think.

https://github.com/systemd/systemd/issues/5047

Anyway if I disconnect wifi, then attempt a lid close suspend, it now works for me.

Standard onboard intel wifi adapter.

$ inxi -Nx
Network:   Card-1: Intel Wireless 3160 driver: iwlwifi v: kernel bus ID: 03:00.0
$ hwinfo --wlan
11: PCI 300.0: 0282 WLAN controller
 ...
  Model: "Intel Dual Band Wireless AC 3160"
  Vendor: pci 0x8086 "Intel Corporation"
  Device: pci 0x08b3 "Wireless 3160"
  SubVendor: pci 0x8086 "Intel Corporation"
  SubDevice: pci 0x8070 "Dual Band Wireless AC 3160"
  Revision: 0x83
  Driver: "iwlwifi"
  Driver Modules: "iwlwifi"
  Device File: wlp3s0
...

The wifi adapter in my other laptop, where lid close suspend works, is

$ inxi -Nx
Network:   Card-1: Broadcom Limited BCM4352 802.11ac Wireless Network Adapter driver: wl v: kernel bus ID: 07:00.0
...

@zongo, do you get the same behaviour if you disable wifi before lid close ?

I always power button suspend so I have no idea if this issue was recently introduced or something that has been around for a while on my system.

EDIT :

Power button suspend does not trigger the atkbd serio0 dmesg errors.

Don't know enough to explain why one suspend trigger (ie power button) works, and another suspend trigger (ie lid close) seemingly works differently and fails.

:confused:

1 Like

@sueridgepipe
Thanks for the investigation. I never thought that could be due to the wifi. I will check that as soon as I am off work and will report back to you.
Again thank you very much as it seems the same on my side where all other suspend triggers work for me but the lid.
PS: I never had this prior to running the latest update. Hence the fresh install I did two weeks ago just after getting the issue.

I tried downgrading systemd back to 238.51, which was updated for me in unstable branch about a month ago.

[2018-04-10] [ALPM] upgraded systemd (238.51-1.1 -> 238.76-1)

Didn't help though.

hmm good to know. So, the issue may not be coming from the upgrade. What I noticed at the begining of my investigation is PowerDevil was being block. Reported by systemd-inhibit. Probably causing the problem and seeing this in the logs
acpi device:40: Cannot transition to power state D3hot for parent in (unknown)
There is one other difference in my case between before (with no issue) and now (with the issue)
I put a new battery in my laptop. Could that be the cause ?

I don't think this means that Powerdevil is blocking suspend, I think this basically means that systemd recognizes that KDE is responsible for handling the different types of suspend / hibernation.

Systemd thus does nothing, assuming KDE (ie powerdevil) will handle these.

Who: PowerDevil (UID 1000, PID 1350/org_kde_powerde)
What: handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch

KDE is initiating close lid suspend, but is failing on my system due to hardware related rfkill key sequence not being recognized. Disconnet wifi and this rfkill sequence is not required, thus suspend completes successfully.

The real question is what are the differences between lid close suspend and power button suspend. Why does one fail and the other not fail? This confuses me.

To test if this is a recent KDE regression you could always re-install from an older ISO to see if the issue still exists with an older package snapshot. If this is your daily driver system then this option may not be feasible.

Similar issue here: Resume from Suspension broken in recent kernels

I'm not 100% sure but I remember Phoronix talking about something handling lid suspend in recent months(though for it to be affecting Manjaro now seems a bit of a delay). Might have been systemd or libinput.

I am back home now.
I disabled the wifi: Hardware disabled. I have a switch on the side. Closing the lid still does not allow me to suspend. You will find the same error message from dmesg below.

Hmm, this makes me wonder now as I have the same wifi as you (Intel) but not the same model.

 Hardware Class: network
  Model: "Intel Dual Band Wireless-AC 7260"
  Vendor: pci 0x8086 "Intel Corporation"
  Device: pci 0x08b1 "Wireless 7260"
  SubVendor: pci 0x8086 "Intel Corporation"
  SubDevice: pci 0x4470 "Dual Band Wireless-AC 7260"
 [87263.466803] iwlwifi 0000:02:00.0: RF_KILL bit toggled to disable radio.
[87263.466807] iwlwifi 0000:02:00.0: reporting RF_KILL (radio disabled)
[87263.470872] wlp2s0: deauthenticating from 24:65:11:2e:c5:f8 by local choice (Reason: 3=DEAUTH_LEAVING)
[87263.525787] systemd-journald[320]: Successfully sent stream file descriptor to service manager.
[87280.394505] pci_bus 0000:01: Allocating resources
[87280.394531] pci_bus 0000:02: Allocating resources
[87280.394600] pci_bus 0000:03: Allocating resources
[87280.399954] acpi device:40: Cannot transition to power state D3hot for parent in (unknown)
[87294.030953] pci_bus 0000:01: Allocating resources
[87294.030969] pci_bus 0000:02: Allocating resources
[87294.031034] pci_bus 0000:03: Allocating resources
[87294.035417] acpi device:40: Cannot transition to power state D3hot for parent in (unknown)
[87313.744195] systemd-journald[320]: Sent WATCHDOG=1 notification.
[87373.747406] systemd-journald[320]: Successfully sent stream file descriptor to service manager.
[87394.391100] pci_bus 0000:01: Allocating resources
[87394.391118] pci_bus 0000:02: Allocating resources
[87394.391187] pci_bus 0000:03: Allocating resources
[87394.395935] acpi device:40: Cannot transition to power state D3hot for parent in (unknown)
[87402.976428] systemd-journald[320]: Sent WATCHDOG=1 notification.
[87402.994221] pci_bus 0000:01: Allocating resources
[87402.994236] pci_bus 0000:02: Allocating resources
[87402.994301] pci_bus 0000:03: Allocating resources
[87402.998357] acpi device:40: Cannot transition to power state D3hot for parent in (unknown)

upower yield some interesting results. Basically the action hybrid sleep is not be honored.

[22:43:58.153]  daemon changed:
  daemon-version:  0.99.7
  on-battery:      no
  lid-is-closed:   yes
  lid-is-present:  yes
  critical-action: HybridSleep

[22:44:12.073]  daemon changed:
  daemon-version:  0.99.7
  on-battery:      no
  lid-is-closed:   no
  lid-is-present:  yes
  critical-action: HybridSleep

Please provide more detailed system info.

inxi -Fxzc0
acpi --everything

Kernel 4.9 lid close suspend works for me, where 4.14 and 4.16 fails, but I think we have different issues.

I would try kernel 4.9 and even 4.4 to confirm if this is a kernel regression.

I have downgraded to kernel 4.9 but unfortunately I am still faced with the issue. Lid does not trigger the suspend function.
4.4 - no dice as well.
I am at lost on how to investigate further. UPower seems to be responding as expected but not triggering the suspend or actually in my case the hybrid-sleep.

PS: The suspend works in a terminal. I will use that workaround for the moment until a miracle happens :slight_smile:

inxi -Fxzc0
System:    Host: redmoon Kernel: 4.17.0-1-MANJARO x86_64 bits: 64 compiler: gcc v: 7.3.1 
           Desktop: KDE Plasma 5.12.5 tk: Qt 5.10.1 Distro: Manjaro Linux 17.1.10 Hakoila 
Machine:   Type: Laptop System: Dell product: Latitude E7440 v: 00 serial: N/A 
           Mobo: Dell model: 03HFCG v: A00 serial: N/A UEFI: Dell v: A25 date: 02/01/2018 
Battery:   ID-1: BAT0 charge: 53.3 Wh condition: 53.3/53.3 Wh (100%) model: LGC-LGC6.2 DELL 0D47W43 
           status: Full 
CPU:       Topology: Dual Core model: Intel Core i7-4600U bits: 64 type: MT MCP arch: Haswell rev: 1 
           L2 cache: 4096 KiB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 21556 
           Speed: 798 MHz min/max: 800/3300 MHz Core speeds (MHz): 1: 798 2: 798 3: 799 4: 798 
Graphics:  Card-1: Intel Haswell-ULT Integrated Graphics driver: i915 v: kernel bus ID: 00:02.0 
           Display: x11 server: X.Org 1.19.6 driver: intel unloaded: fbdev,modesetting,vesa 
           resolution: 1920x1080~60Hz 
           OpenGL: renderer: Mesa DRI Intel Haswell Mobile v: 4.5 Mesa 18.0.3 direct render: Yes 
Audio:     Card-1: Intel Haswell-ULT HD Audio driver: snd_hda_intel v: kernel bus ID: 00:03.0 
           Card-2: Intel 8 Series HD Audio driver: snd_hda_intel v: kernel bus ID: 00:1b.0 
           Sound Server: ALSA v: k4.17.0-1-MANJARO 
Network:   Card-1: Intel Ethernet Connection I218-LM driver: e1000e v: 3.2.6-k port: f080 bus ID: 00:19.0 
           IF: eno1 state: down mac: <filter> 
           Card-2: Intel Wireless 7260 driver: iwlwifi v: kernel bus ID: 02:00.0 
           IF: wlp2s0 state: up mac: <filter> 
           IF-ID-1: tun0 state: unknown speed: 10 Mbps duplex: full mac: N/A 
Drives:    HDD Total Size: 238.47 GiB used: 8.41 GiB (3.5%) 
           ID-1: /dev/sda model: SAMSUNG_SSD_PM85 size: 238.47 GiB 
Partition: ID-1: / size: 216.57 GiB used: 8.41 GiB (3.9%) fs: ext4 dev: /dev/dm-0 
           ID-2: swap-1 size: 17.13 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/dm-1 
Sensors:   System Temperatures: cpu: 46.0 C mobo: 30.0 C sodimm: 27.0 C 
           Fan Speeds (RPM): cpu: 0 
Info:      Processes: 283 Uptime: 23h 25m Memory: 15.58 GiB used: 1.00 GiB (6.4%) Init: systemd Compilers: 
           gcc: 7.3.1 Shell: bash v: 4.4.19 inxi: 3.0.07 

acpi --everything
Battery 0: Full, 100%
Battery 0: design capacity 7200 mAh, last full capacity 7200 mAh = 100%
Adapter 0: on-line
Thermal 0: ok, 25.0 degrees C
Thermal 0: trip point 0 switches to mode critical at temperature 107.0 degrees C
Cooling 0: Processor 0 of 3
Cooling 1: Processor 0 of 3
Cooling 2: x86_pkg_temp no state information available
Cooling 3: Processor 0 of 3
Cooling 4: intel_powerclamp no state information available
Cooling 5: Processor 0 of 3

@bogdancovaciu
I tried your suggestion and no dice. Thanks for taking the time.

Ok, I have got some news. This work regardless of the kernel version.
I have change the critical action in upower from hybrid-sleep to suspend and it seems that now it does suspend.
I have tested it a couple of times and I can suspend and resume. I am quite happy if this seems to be a stable work-around.
I think there might be an issue with KDE 'per activity power management' and the configuration within upower.conf.

Forum kindly sponsored by