Problems caused by resume from sleep

Ask Fedora
,
1

I’m running Fedora 38 on a Dell XPS 15 7590. This has, for about a week, been showing the following symptoms if I close the lid and re-open it later:

  • Wifi will sometimes be disabled; trying to restart services has no effect.
  • Graphical applications won’t start; I click on the icon, see a spinner for a few seconds, and that’s it.
  • The power menu only contains the option to log out and that doesn’t do anything when clicked.
  • The Systemd GNOME plugin (Systemd Manager - GNOME Shell Extensions) will no longer be capable of starting or stopping services, though it will reflect the state of services started and stopped with systemctl.

Rebooting fixes it until the next time the lid is closed.
Any suggestions for how to investigate this would be welcome - thanks.

2

From Dell XPS 15 7590 specs (PDF)

  • WiFi sometimes disabled:

Intel® Killer™ Wi-Fi 6 AX1650 – see Product Brief (PDF) link at:

Support for Wi-Fi network and Bluetooth® Low Energy Human Interface Device (HID) connectivity in the platform’s UEFI (Unified Extensible Firmware Interface) environment during its boot stage. This capability enables use cases like OS recovery over Wi-Fi and Bluetooth® Low Energy-based
keyboard and mouse connectivity in this pre-boot environment.

Features like this are often problematic because Linux drivers can get out-of-sync with the UEFI provided firmware. Make sure you have installed Dell’s latest firmware and all Fedora updates.
Dell systems are supported by the fwupd package.
Note that a) Linux systems differ in package management and GUI environments, but generally very similar at the underlying layers, b) Arch Linux usually has excellent documentation. Fedora has:

% dnf info fwupd
Last metadata expiration check: 0:28:48 ago on Fri May 19 09:17:32 2023.
Installed Packages
Name         : fwupd
Version      : 1.8.15
Release      : 1.fc38
Architecture : x86_64
Size         : 5.8 M
Source       : fwupd-1.8.15-1.fc38.src.rpm
Repository   : @System
From repo    : updates
Summary      : Firmware update daemon
URL          : https://github.com/fwupd/fwupd
License      : LGPLv2+
Description  : fwupd is a daemon to allow session software to update device firmware.

For the other problems, if updating does not solve them, you need to learn how to use journalctl. It can be used to display log entries for the current of some previous boot. You can try the older kernels to see if one does not have the problem, then compare log messages between working and failing.

I think other users are seeing similar problems, so please let us know what works for you so others can benefit (sharing is the Linux superpower!).

3

Thanks for the info. My firmware is up to date, as expected:

Devices with no available firmware updates: 
 • Thunderbolt host controller
Devices with the latest available firmware version:
 • PC601 NVMe SK hynix 512GB
 • System Firmware
 • UEFI dbx
No updates available

I am (somewhat) familiar with journalctl, but what should I be looking for? I am not certain what systems might cause the issues I have described. Meanwhile, I can try booting to 6.2.13 which is the earliest I have.

It’s interesting to hear that others have noticed similar problems. If you happen to know of any suitable threads I could watch I’d appreciate it if you would let me know - I have tried looking but couldn’t see anything.

4

Run dnf list kernel\*. This will show you which kernels are available and which are installed. If 2.6.13 doesn’t work, try the rescue kernel. – probably 6.2.6-300 (isted as “installed” here).
Then you can try a 6.1 long-term service (LTS) kernel from kwixart’s copr repository.

As usual Arch Linux has good documentation for suspend and habiernate(last edited on 3 May 2023, at 06:48.) – in [Section 6.2 Troubleshooting] there is:

Suspend/hibernate does not work, or does not work consistently

There have been many reports about the screen going black without easily viewable errors or the ability to do anything when going into and coming back from suspend and/or hibernate. These problems have been seen on both laptops and desktops. This is not an official solution, but switching to an older kernel, especially the LTS-kernel, will probably fix this.

Also problem may arise when using hardware watchdog timer (disabled by default, see RuntimeWatchdogSec= in systemd-system.conf(5) § OPTIONS). Bugged watchdog timer may reset the computer before the system finished creating the hibernation image.

Sometimes the screen goes black due to device initialization from within the initramfs. Removing any modules you might have in Mkinitcpio#MODULES, removing the kms hook and rebuilding the initramfs can possibly solve this issue, specially graphics drivers for early KMS. Initializing such devices before resuming can cause inconsistencies that prevents the system resuming from hibernation. This does not affect resuming from RAM. Also, check the blog article best practices to debug suspend issues.

Moving from the ATI video driver to the newer AMDGPU driver could also help to make the hibernation and awakening process successful.

After upgrading to kernel 4.15.3, resume may fail with a static (non-blinking) cursor on a black screen. Blacklisting the module nvidiafb might help. [5]

Laptops with Intel CPU that load intel_lpss_pci module for touchpad, may face kernel panic on resume (blinking caps lock) [6]. The module needs to be added to initramfs as:

/etc/mkinitcpio.conf

MODULES=(... intel_lpss_pci ...)

Then regenerate the initramfs.

Lots to explore here. Happy hunting.

5

I tried the kernel mentioned, and also 6.2.9-300; both of these kernels showed the same symptoms. Running dmesg after a failed resume gave me this:

[10039.106057] Restarting tasks ... done.
[10039.112241] random: crng reseeded on system resumption
[10039.430591] PM: suspend exit
[10039.430648] PM: suspend entry (s2idle)
[10039.442944] Filesystems sync: 0.012 seconds
[10039.445723] Freezing user space processes
[10039.447806] Freezing user space processes completed (elapsed 0.002 seconds)
[10039.447808] OOM killer disabled.
[10039.447809] Freezing remaining freezable tasks
[10039.449160] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[10039.449163] printk: Suspending console(s) (use no_console_suspend to debug)
[10042.346998] PM: suspend devices took 2.898 seconds
[10042.384694] ACPI: EC: interrupt blocked
[10042.385661] intel_pch_thermal 0000:00:12.0: CPU-PCH is cool [42C]
[10042.438836] ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20221020/exsystem-141)
[...repeat...]
[14805.139083] ACPI: EC: interrupt unblocked
[14805.145086] ACPI Warning: Time parameter 250 us > 100 us violating ACPI spec, please fix the firmware. (20221020/exsystem-141)
[...repeat...]
[14808.228785] PM: resume devices took 0.295 seconds
[14808.229820] OOM killer enabled.
[14808.229823] Restarting tasks ... done.
[14808.246477] random: crng reseeded on system resumption
[14808.267258] ata3: SATA link down (SStatus 4 SControl 300)
[14808.335623] PM: suspend exit
[14808.633449] rfkill: input handler disabled
[14808.644492] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
[14822.535314] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7

…not that that helps me, but perhaps someone else might be able to make something of it.

6

This should have been fixed by a firmware update from Dell. You can install updates in Fedora using fwupd (dnf install fwupd then fwupdtool --help).

7

Unfortunately I’m still seeing all the firmware listed as being up to date. This time, though, with an additional public key failure:

Loading…                 [*******************                    ]18:49:16.703 FuPluginIntelMe      failed to get public key using /fpf/OemC
red: generic failure [0xb]
Loading…                 [************************************** ]
Devices with no available firmware updates: 
 • Thunderbolt host controller
Devices with the latest available firmware version:
 • PC601 NVMe SK hynix 512GB
 • System Firmware
 • UEFI dbx
No updates available for remaining devices
8

This eventually resolved, somehow…
I think it’s related to:

…where the firmware settings changed.
Since then, I’ve not seen any of the behaviour mentioned in this thread. The touchscreen, which I had disabled, has also re-enabled itself.