Suspend issue with latest Manjaro 4.17.0-1

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.

spoke too soon. I believe its suspending now but do that 3 or 4 times and I get a black screen and I have to hard reset (reboot) the laptop.
so symptoms are different from the original issue i guess. This is kicking my ass.

More troubleshooting done. Apologies as I am throwing all of this in a very disorderly fashion.
I have removed tlp and tlp-rdw. Rebooted the machine.
Closing the lid now suspends the laptop correctly. Tested 5 times and it worked. Also, I do not have the black screen anymore when resuming. I don't know if there is any relation with TLP and the black screen.
using the keys Fn + F1 (suspend) works. No black screen when resume from suspend.
Tested on kernel 4.9 and 4.14.

PS: Since removing TLP and TLP-rdw my laptop seems to be quiter (fan not running wild) and no overheating (just noticed now. would probably need more time to test). Anyone can confirm ?

PS: Since removing TLP and dependencies, the wifi and bluetooth stay on even when on suspend. I mean when resuming, the laptop does not have to reconnect to the wifi network. Same for Bluetooth.

2 Likes

Forum kindly sponsored by