I've used Nobara for over a year and a half, and most things worked well except suspend: waking the laptop from sleep consistently caused a kernel panic. I worked around that by locking the screen instead, but about a month ago the system began panicking even after simply locking the screen and turning off the display. Within a few minutes, the Caps Lock LED starts blinking. I also sometimes get a panic at the LUKS unlock screen if I don't enter my password within 5–10 seconds.
I tested CachyOS and PikaOS, but the behavior is identical across all three distributions. I'm currently using KDE Plasma on a dual-boot Acer Nitro 5 with a Ryzen 7 7735HS, integrated Radeon 680M graphics, an RTX 4060, 32 GB of RAM, and an external Acer monitor connected over HDMI. Linux and Windows are installed on separate SSDs, and the NVIDIA driver is version 595.84.
I tried checking the previous boot's kernel log, but it contained little useful information. I also disabled NVIDIA runtime power management, enabled the NVIDIA suspend/resume services, enabled video-memory preservation, confirmed NVIDIA DRM modesetting and fbdev support, disabled PCIe ASPM, ran four full Memtest passes without errors, reseated the RAM, disabled BIOS Fast Boot, and updated the BIOS.
One log entry does show kscreenlocker crashing inside libQt6Qml.so.6.9.2. Could the screen locker or KDE be triggering this, or is the LUKS prompt behavior more suggestive of an SSD, GPU, or hardware problem? What other troubleshooting steps should I try before giving up on Linux?
4 Answers
Since this is an RTX 4060 laptop, try the open NVIDIA DKMS driver package if it is available for your distribution, and compare it with the proprietary driver. Also test with the NVIDIA GPU disabled or with the integrated Radeon graphics only. That A/B test can quickly show whether GPU power management, HDMI output, or suspend-related NVIDIA code is involved.
A panic while sitting at the LUKS unlock prompt points beyond ordinary KDE screen locking. Try booting a current live USB and leave it idle at the boot or unlock stage to see whether the same failure occurs. If it still happens from a live environment, test each SSD independently and check the drive’s SMART/NVMe health data. A failing drive or controller could explain crashes that occur before the installed system is fully running.
A clean installation may be useful, but switching distributions alone does not necessarily remove every underlying cause—especially if you reuse the same kernel parameters, home configuration, bootloader settings, or NVIDIA setup. Before reinstalling again, test a live system with default parameters and no custom NVIDIA power-management tweaks, then add changes back one at a time.
The kscreenlocker crash is worth investigating first. Temporarily disable automatic screen locking and test whether the machine still panics when the display turns off. If the crashes stop, the problem may be in KDE’s screen-locking stack or Qt rather than the kernel itself. You could also try another desktop session or a different lock-screen configuration to narrow it down.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures