Lock screen crashes or freezes on KDE Rocky 9

My lock screen is freezing or crashing whether from the idle timeout at the desktop or I lock the screen manually. This used to work reliably up until a week or two ago.

I could not determine any records in /var/log/messages or /var/log/Xorg.*.log that might be of interest

I’m using X11 display manager to solve login screen lag: Solved: Desktop/Mouse incredibly slow after upgrading

X/KDE does not appear to crash, it’s still in a graphic mode when I switch to it ie. CTRL+F2, it’s just the lock screen never displays.

I’m on an NVIDIA 1050 which I recall something about support not being great for it? Are there perhaps legacy drivers for it?

Fwiw KDE Connect has always crashed on KDE login for me. I have no idea if that’s related.

I probably don’t know enough to assist here, but what graphic drivers are being used?

You can try doing:

lsmod | grep -i nvidia

if no results:

lsmod | grep -i nouv

this will determine for us if you have the nvidia driver in use or the nouveau one which should be the one by default unless configured otherwise. If it does happen to be the nvidia driver, then we’ll need to know how you installed it - using epel or rpmfusion or from NVidia’s website.

The Xorg logs should also show which driver is being used just in case it’s using for example vesa.

I have a laptop with NVidia 1050GTX and the NVidia drivers work fine on that, at least the ones I use on Fedora 41 from rpmfusion, so they should also work on your install with Rocky if you did install them.

1 Like

With GDM & GNOME, the default is Wayland for Nouveau and also for latest version(s) of NVidia’s proprietary driver. (GDM auto-disables Wayland on earlier versions of proprietary – and probably on current ELRepo version still.) Despite that user can choose a X11 (GNOME) session.

You do use X11, but is it “just” the KDE session, or also the DM?


The 1050 has Pascal architecture. The options are the open source Nouveau that is included in Rocky and the NVidia proprietary driver (available on NVidia’s CUDA repo, ELRepo, and RPM Fusion). NVidia’s CUDA repo has also “open” driver, but that does not support older than Turing. The latest NVidia’s proprietary driver does support Pascal, so no need for legacy (version 470?).

Thanks for replies

DisplayServer=x11 is set in /etc/sddm.conf and the login screen shows “Desktop: Plasma (X11)” in the bottom-left, which is correct for me.

Here’s my details:

# lsmod | grep -i nvidia
nvidia_uvm           3956736  0
nvidia_drm            143360  45
nvidia_modeset       1552384  134 nvidia_drm
nvidia              89911296  1493 nvidia_uvm,nvidia_modeset
drm_kms_helper        274432  2 nvidia_drm
drm                   782336  49 drm_kms_helper,nvidia,nvidia_drm
video                  73728  2 asus_wmi,nvidia_modeset

Nothing from lsmod | grep -i nouv

Xorg.0.log:

[     9.379] (**) OutputClass "nvidia" setting /dev/dri/card0 as PrimaryGPU
[     9.380] (--) PCI:*(1@0:0:0) 10de:1d01:1043:85f4 rev 161, Mem @ 0xf6000000/16777216, 0xe0000000/268435456, 0xf0000000/33554432, I/O @ 0x0000e000/128, BIOS @ 0x????????/131072
[     9.380] (II) "glx" will be loaded. This was enabled by default and also specified in the config file.
[     9.380] (II) LoadModule: "dbe"
[     9.380] (II) Module "dbe" already built-in
[     9.380] (II) LoadModule: "extmod"
[     9.380] (II) Module "extmod" already built-in
[     9.380] (II) LoadModule: "glx"
[     9.381] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so
[     9.390] (II) Module glx: vendor="X.Org Foundation"
[     9.390]    compiled for 1.20.11, module version = 1.0.0
[     9.390]    ABI class: X.Org Server Extension, version 10.0
[     9.390] (II) LoadModule: "nvidia"
[     9.390] (II) Loading /usr/lib64/xorg/modules/drivers/nvidia_drv.so
[     9.399] (II) Module nvidia: vendor="NVIDIA Corporation"
[     9.399]    compiled for 1.6.99.901, module version = 1.0.0
[     9.399]    Module class: X.Org Video Driver
[     9.399] (II) NVIDIA dlloader X Driver  570.124.06  Wed Feb 26 01:44:32 UTC 2025
[     9.399] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs

dnf list installed | grep -i nvidia

dnf-plugin-nvidia.noarch                       2.2-2.el9                           @cuda-rhel9-x86_64     
kmod-nvidia-latest-dkms.x86_64                 3:570.124.06-1.el9                  @cuda-rhel9-x86_64     
libnvidia-cfg.x86_64                           3:570.124.06-1.el9                  @cuda-rhel9-x86_64     
libnvidia-ml.x86_64                            3:570.124.06-1.el9                  @cuda-rhel9-x86_64     
nvidia-driver.x86_64                           3:570.124.06-1.el9                  @cuda-rhel9-x86_64     
nvidia-driver-libs.x86_64                      3:570.124.06-1.el9                  @cuda-rhel9-x86_64     
nvidia-kmod-common.noarch                      3:570.124.06-1.el9                  @cuda-rhel9-x86_64     
nvidia-libXNVCtrl.x86_64                       3:570.124.06-1.el9                  @cuda-rhel9-x86_64     
nvidia-libXNVCtrl-devel.x86_64                 3:570.124.06-1.el9                  @cuda-rhel9-x86_64     
nvidia-modprobe.x86_64                         3:570.124.06-1.el9                  @cuda-rhel9-x86_64     
nvidia-persistenced.x86_64                     3:570.124.06-1.el9                  @cuda-rhel9-x86_64     
nvidia-settings.x86_64                         3:570.124.06-1.el9                  @cuda-rhel9-x86_64     
nvidia-xconfig.x86_64                          3:570.124.06-1.el9                  @cuda-rhel9-x86_64     
xorg-x11-nvidia.x86_64                         3:570.124.06-1.el9                  @cuda-rhel9-x86_64

I’m using Wayland and KDE 6. I’ve turned off hybridization because I can’t wake up the screen forcing a power off reboot.

It’s the last issue I have to resolve and it started about 2 weeks ago.

Just for me… see if you can repeat the success I’ve had at dealing with complex issues by using WARP. Should be enough free goes in it for your issue.

It’s clearly had training on Red Hat’s database. Well what ever they did, it knows Linux inside out.

Ask it to document what it has done. I’ve given WARP an Obsidian vault. It has a start file that is loaded by bash so it knows about our ongoing work together. I just type “write to your vault…”. It remember nothing between session unless you help it out. He’s called “Mate” and he ends his final prompt with “and then”. Trust me, hugely amusing and the most useful and helpful AI + interface I’ve tried.

Do AI versus a forum of experienced users. Using the two together you can solve problems fast. Use the experienced users to provide clues to the AI.

I’m betting you will be sold after fixing one issue.

I’ll have a go at fixing the issue I’m having and post the outcome.

www.warp.dev

Sleep Mode Troubleshooting Guide

This guide provides a systematic approach to diagnosing and resolving sleep mode issues in Linux systems, particularly focusing on problems where devices fail to wake the system from sleep.

Table of Contents

  1. Hardware Identification
  2. Session Information
  3. System Logs
  4. Power Management Settings
  5. ACPI Settings
  6. USB Configurations
  7. Wakeup Settings
  8. Implementing Solutions
  9. Testing and Verification

Hardware Identification

Start by identifying the hardware components of your system, particularly graphics cards and USB devices.

Graphics Hardware

# List all PCI devices, focusing on graphics cards
lspci | grep -i vga

This command shows all graphics cards in your system. The output helps identify whether you’re using NVIDIA, AMD, or Intel graphics, which may influence sleep behavior differently.

USB Devices

# List all USB devices
lsusb

This lists all USB devices connected to your system, showing vendor and product IDs (e.g., Logitech devices will show as vendor ID 046d).

# List USB controllers
lspci | grep -i usb

This shows USB controllers, which are often part of the wakeup chain and need to be configured properly for devices to wake the system.

Session Information

Identify the display server, desktop environment, and relevant services.

# Check display server type (Wayland or X11)
echo $XDG_SESSION_TYPE

# Check desktop environment
echo $DESKTOP_SESSION

# Check if power-profiles-daemon is running
systemctl status power-profiles-daemon.service

Understanding your session type is important because:

  • Wayland and X11 handle power management differently
  • Different desktop environments (KDE, GNOME, etc.) use different sleep management approaches
  • Power profile services can affect sleep behavior

System Logs

Examine system logs for clues about sleep-related issues.

Kernel Messages

# Check kernel messages related to power management
dmesg | grep -i "acpi\|power\|sleep\|suspend\|keyboard" | tail -n 20

This shows recent kernel messages related to power management. Look for:

  • Error messages during suspend/resume
  • Missing drivers or unsupported hardware
  • ACPI events that might interrupt sleep

Systemd Journal

# Check suspend/resume errors in journal
journalctl -b -p err..emerg | grep -i "sleep\|suspend\|wake\|resume"

This shows error-level messages related to sleep events.

# Check all suspend/resume events
journalctl -b | grep -i "resume\|suspend\|wake" | tail -n 30

This shows recent sleep-related events, which can help identify when sleep is triggered and what happens during wake attempts.

Power Management Settings

Examine power management configurations.

Desktop Environment Settings

For KDE:

# List KDE power management settings
cat ~/.config/powermanagementprofilesrc

For GNOME:

# Check GNOME power settings
gsettings list-recursively org.gnome.settings-daemon.plugins.power

These settings show how your desktop environment handles sleep events, including:

  • Timeouts before sleep
  • Button events that trigger sleep
  • What devices can wake the system

Systemd Logind Settings

# View logind configuration
cat /etc/systemd/logind.conf | grep -v "^#" | grep -v "^$"

The logind configuration controls system-wide power management behavior. Important settings include:

  • HandleLidSwitch
  • HandlePowerKey
  • IdleAction

ACPI Settings

Advanced Configuration and Power Interface (ACPI) settings are crucial for sleep mode functionality.

# Check devices that can wake the system
cat /proc/acpi/wakeup

This output shows all ACPI devices that can potentially wake your system, with their current status (enabled/disabled). Look for devices like:

  • LID (laptop lid)
  • PWRB (power button)
  • USB and USBn (USB controllers)
  • XHCn (USB 3.0 controllers)

For each device, it shows:

  • Device name
  • Status (enabled/disabled)
  • PCI device path (if applicable)

USB Configurations

USB settings are particularly important for keyboard and mouse wake issues.

USB Wakeup Status

# Check USB devices with wakeup capability
grep -r "" /sys/bus/usb/devices/*/power/wakeup 2>/dev/null

This shows which USB devices have wakeup enabled or disabled.

Identify Specific USB Devices

# Check manufacturer and product for a specific USB device
cat /sys/bus/usb/devices/[device-id]/manufacturer /sys/bus/usb/devices/[device-id]/product

Replace [device-id] with the device ID shown in the previous command (e.g., 3-1.2).

USB Autosuspend Setting

# Check USB autosuspend setting
cat /sys/module/usbcore/parameters/autosuspend

The autosuspend value (in seconds) determines how quickly USB devices enter low power mode. Lower values may cause wake issues.

Wakeup Settings

This section is critical for resolving the common problem where USB devices (like keyboards) are enabled for wakeup but still don’t wake the system.

Check Complete USB Chain

# For a specific USB device (e.g., 3-1.2.2)
cat /sys/bus/usb/devices/usb3/power/wakeup
cat /sys/bus/usb/devices/3-1/power/wakeup
cat /sys/bus/usb/devices/3-1.2/power/wakeup
cat /sys/bus/usb/devices/3-1.2.2/power/wakeup

The critical insight is that ALL devices in the chain (from root controller to the specific device) must have wakeup enabled for the device to wake the system.

Find USB-to-PCI Relationship

# Find which PCI device corresponds to a USB controller
readlink -f /sys/bus/usb/devices/usb3 | grep -o "pci.*"

This helps map USB controllers to their PCI device entries, which is essential for understanding the complete wakeup chain.

Implementing Solutions

Once you’ve identified that a USB device’s wakeup chain is broken, implement a solution.

Manual Solution (Temporary)

# Enable wakeup for all devices in the chain
echo "enabled" | sudo tee /sys/bus/usb/devices/usb3/power/wakeup
echo "enabled" | sudo tee /sys/bus/usb/devices/3-1/power/wakeup
echo "enabled" | sudo tee /sys/bus/usb/devices/3-1.2/power/wakeup

This enables wakeup immediately but won’t persist after reboot.

Persistent Solution (Using udev)

Create a udev rule file:

sudo tee /etc/udev/rules.d/90-usb-wakeup.rules << 'EOF'
# Enable wakeup for all USB controllers and hubs in the chain for the Logitech receiver
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="046d", ATTR{power/wakeup}="enabled"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="1d6b", ATTR{power/wakeup}="enabled"
# Enable wakeup for the specific path to Logitech devices
ACTION=="add", SUBSYSTEM=="usb", KERNELS=="3-1", ATTR{power/wakeup}="enabled"
ACTION=="add", SUBSYSTEM=="usb", KERNELS=="3-1.2", ATTR{power/wakeup}="enabled"
ACTION=="add", SUBSYSTEM=="usb", KERNELS=="usb3", ATTR{power/wakeup}="enabled"
EOF

Apply the rules:

sudo udevadm control --reload-rules
sudo udevadm trigger

This solution persists across reboots and automatically applies whenever the specified USB devices are connected.

Testing and Verification

After implementing solutions, test and verify that they work.

# Verify wakeup settings
cat /sys/bus/usb/devices/usb3/power/wakeup
cat /sys/bus/usb/devices/3-1/power/wakeup
cat /sys/bus/usb/devices/3-1.2/power/wakeup
cat /sys/bus/usb/devices/3-1.2.2/power/wakeup

All should display “enabled” for proper wakeup functionality.

Finally, test the actual sleep and wake behavior:

  1. Put the system to sleep
  2. Attempt to wake it using the keyboard
  3. If successful, your troubleshooting is complete

Common Problems and Solutions

Keyboard Won’t Wake System

Problem: Keyboard has wakeup enabled but doesn’t wake the system.
Solution: Enable wakeup on ALL parent devices in the USB chain.

System Wakes Immediately After Sleep

Problem: System goes to sleep but wakes immediately.
Solution: Check cat /proc/acpi/wakeup for devices that might be triggering immediate wake. Disable unnecessary wakeup devices.

System Won’t Enter Deep Sleep

Problem: System appears to sleep but power light doesn’t indicate deep sleep.
Solution: Check /sys/power/mem_sleep and modify kernel parameters to enable deeper sleep states.


This troubleshooting guide represents a systematic approach to diagnosing and resolving sleep mode issues. The key insight to remember is that power management in Linux involves multiple layers of configuration, and all layers must be properly configured for sleep and wake functionality to work correctly.

This is the testing process…

Sleep Mode Commands

This document outlines various commands that can be used to put a Linux system into sleep mode for testing purposes. These commands are especially useful for verifying the functionality of USB wakeup settings after making changes to system configurations.

Recommended Commands

Using systemd (Most Common and Recommended)

sudo systemctl suspend

This is the most reliable and universally available method on modern Linux systems with systemd. It will put your computer into sleep mode immediately.

Using pm-utils (If Installed)

sudo pm-suspend

This method requires the pm-utils package to be installed on your system.

Using the Kernel’s Power Management Interface Directly

echo mem | sudo tee /sys/power/state

This method writes directly to the kernel’s power management interface.

Desktop Environment Specific Commands

For GNOME

dbus-send --system --print-reply --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.Suspend boolean:true

For KDE Plasma

qdbus org.kde.Solid.PowerManagement /org/freedesktop/PowerManagement Suspend

Scheduled Sleep Test

If you want to give yourself time to prepare before the system suspends:

sleep 10 && sudo systemctl suspend

This command will wait 10 seconds before suspending the system, giving you time to position your hands over the keyboard to test wakeup functionality.

Testing Procedure

  1. Execute one of the commands above to put the system into sleep mode
  2. Wait until the system is fully suspended (power LED may pulse or change color)
  3. Press a key on your keyboard to test if the system wakes up
  4. If the system wakes successfully, your USB wakeup configuration is working correctly

Troubleshooting

If your system doesn’t wake from keyboard input after sleep:

  • Verify that all USB controllers in the chain have wakeup enabled (refer to SleepModeTroubleShooter.md)
  • Check if the udev rules have been properly applied using sudo udevadm control --reload-rules
  • Consider manually enabling wakeup for all devices in the USB chain as a temporary test

It seems that if I manually lock the screen from the start menu then it’s stable and the password field appears when there’s activity.

So it’s something about the automatic inactivity timeout that feels like it’s failing to launch whatever process handles the password field behaviour.

I’m sure it is the same issue I’m having. You can try…

Scheduled Sleep Test

If you want to give yourself time to prepare before the system suspends:

sleep 10 && sudo systemctl suspend

This command will wait 10 seconds before suspending the system, giving you time to position your hands over the keyboard to test wakeup functionality.

I think the computer is coming out of suspend because I’ve been able to press enough random keys to get a beep.

And I’ve test here waking the computer after 60 seconds via the prompt and still end up with a reboot as the only mean to see the screen.

It doesn’t appear to be a USB wake up issue. And given you use Nvidia and me AMD and no other graphics issues are occurring I doubt it is within that chain.

There are power management controls within KDE as well as the system. I didn’t see issues with that.

My next check will be what files have been updated in the last 3 weeks that are within the command chain for resume.

The same as my issue?

I’m not using sleep, suspend, or hibernate, just a timeout to lock the screeen

Time out… do you display the log on screen or a black screen?

I can display the log on screen, I can’t turn off the monitor and turn it back on. I’m fairly sure the computer wakes OK. Just not the screen.

If we are sharing the same issue, I’m not sure about that but…

Is there anything else we have in common? I’m using a Samsung UHD monitor. It’s possible that requires something unique to wake it up.

What does this tell you…

find /etc/udev/rules.d /usr/lib/udev/rules.d -type f -mtime -30 2>/dev/null

My monitors turn on fine when I type or shake the mouse. My issue is the lock screen with the lock screen background sometimes doesn’t even display or if it does the password field won’t show up on keyboard/mouse activity.

I’m thinking for me it has to do with nvidia drivers. I’m on “nvidia-driver.x86_64 3:570.124.06-1.el9” and it looks like the issues started happening when it upgraded to “nvidia-xconfig.x86_64 3:565.57.01-1.el9”

I just don’t know how to downgrade to that specific version.

$ find /etc/udev/rules.d /usr/lib/udev/rules.d -type f -mtime -30
/usr/lib/udev/rules.d/60-nvidia.rules

$ cat /usr/lib/udev/rules.d/60-nvidia.rules
# Device nodes are created by nvidia-modprobe, which is called by the nvidia
# DDX or other components.
# In case the DDX is not started, the device nodes are never created, so call
# nvidia-modprobe in the udev rules to cover various cases like Wayland, compute
# node without a started display or Optimus laptop.
ACTION=="add|bind", KERNEL=="nvidia", RUN+="/usr/bin/nvidia-modprobe"

# Enable runtime PM for NVIDIA VGA/3D controller devices on driver bind
ACTION=="bind", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x030000", TEST=="power/control", ATTR{power/control}="auto"
ACTION=="bind", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x030200", TEST=="power/control", ATTR{power/control}="auto"

# Disable runtime PM for NVIDIA VGA/3D controller devices on driver unbind
ACTION=="unbind", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x030000", TEST=="power/control", ATTR{power/control}="on"
ACTION=="unbind", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x030200", TEST=="power/control", ATTR{power/control}="on"

If the screen goes to sleep and wakes up with the mouse OK then maybe you are going as far towards suspend/hibernate with the auto sleep timeout as you are when using code?

I’ve spent a few hours going through issues here. I think I’ve rules out the USB wake up and I can’t see this being the graphics drivers.

You and I have a similar issue, if not the same and other people here have no issue. I’d not look for errors in what we DO NOT have in common.

plasmashell --version

rpm -qa | grep -i plasma | sort

plasmashell 6.3.0
kdeplasma-addons-6.3.0-1.el9.x86_64
kde-settings-plasma-40.0-1.el9.noarch
libplasma-6.3.0-1.el9.x86_64
plasma5support-6.3.0-1.el9.x86_64
plasma-activities-6.3.0-1.el9.x86_64
plasma-activities-stats-6.3.0-1.el9.x86_64
plasma-breeze-6.3.0-1.el9.x86_64
plasma-breeze-common-6.3.0-1.el9.noarch
plasma-breeze-qt5-6.3.0-1.el9.x86_64
plasma-breeze-qt6-6.3.0-1.el9.x86_64
plasma-browser-integration-6.3.0-1.el9.x86_64
plasma-desktop-6.3.0-1.el9.x86_64
plasma-desktop-doc-6.3.0-1.el9.noarch
plasma-discover-6.3.0-3.el9.x86_64
plasma-discover-flatpak-6.3.0-3.el9.x86_64
plasma-discover-libs-6.3.0-3.el9.x86_64
plasma-discover-offline-updates-6.3.0-3.el9.x86_64
plasma-discover-packagekit-6.3.0-3.el9.x86_64
plasma-integration-6.3.0-1.el9.x86_64
plasma-integration-qt5-6.3.0-1.el9.x86_64
plasma-lookandfeel-fedora-6.3.0-1.el9.noarch
plasma-milou-6.3.0-1.el9.x86_64
plasma-nm-6.3.0-1.el9.x86_64
plasma-pa-6.3.0-1.el9.x86_64
plasma-systemsettings-6.3.0-1.el9.x86_64
plasma-thunderbolt-6.3.0-1.el9.x86_64
plasma-vault-6.3.0-1.el9.x86_64
plasma-welcome-6.3.0-1.el9.x86_64
plasma-workspace-6.3.0-1.el9.x86_64
plasma-workspace-common-6.3.0-1.el9.x86_64
plasma-workspace-libs-6.3.0-1.el9.x86_64
plasma-workspace-wallpapers-6.3.0-1.el9.noarch
plasma-workspace-wayland-6.3.0-1.el9.x86_64
sddm-wayland-plasma-6.3.0-1.el9.noarch

I’m using an older server mainboard with AMD Epyc, it has no sleep settings in the bios. There maybe some setting I can access via the service network port. I know I have to reset the bios to look in that dark place.

sudo needleinahaypile -on