Bug 495765

Created attachment 175497 [details]
journalctl last 100 lines from previous boot that locked up system

> upon resume it shows login screen

Can you confirm whether it actually is the *login* screen or the *lock* screen? I ask because if it's the login screen, that means the whole session crashed.

Also, do you have multiple screens? If so, what model of screen is/are the external one(s)?

Hi it is at the SDDM locked screen, just waiting to enter my password. 
I do have multiple screens using the lenovo dock with displaylink and evdil but this crash also happens if not docked.

My power settings are set to close lid SLEEP and goes to SLEEP after 10 mins if not on power.

I have screen locking after 15 mins and also lock screen after wake up from sleep.

I should add, it does not happen when docked as its getting power and would never go to sleep, so only when not on power would this happen.

To clarify, SDDM is the *login* screen, not the *lock* screen.

(In reply to Nate Graham from comment #5)
> To clarify, SDDM is the *login* screen, not the *lock* screen.

Its the SDDM Locked screen.

Just waiting for a password to be entered and after that I should see all my still running apps still there. So not a login to a fresh desktop. The lock screen and login screen look identical. In both cases I have my username already in place, just waiting for the password.

There is no such thing as the "SDDM lock screen". SDDM is the *login* screen; KScreenlocker is the *lock* screen.

These are technical details, so it's okay if you don't know them. But if you're going to mention things by their technical names, it would be good to use the right ones so that people who do know the technical names aren't confused. :) 

Sounds like it's the lock screen after all.

Ah ok I didnt now that, they look the mirror image of each other. But yes looking at a journal logs and locking the computer and unlocking its showing kscreenlocker, same if I sleep and wake up. 

Nov 09 11:16:46 arhclinuxT14 kscreenlocker_greet[4984]: pam_systemd_home(kde:auth): New sd-bus connection (system-bus-pam-systemd-home-4984) opened.
Nov 09 11:16:54 arhclinuxT14 kscreenlocker_greet[4984]: Failed to write to the pipe: Bad file descriptor.
Nov 09 11:17:43 arhclinuxT14 rtkit-daemon[1006]: Supervising 14 threads of 5 processes of 1 users.
Nov 09 11:17:43 arhclinuxT14 rtkit-daemon[1006]: Supervising 14 threads of 5 processes of 1 users.

> kscreenlocker_greet[4984]: Failed to write to the pipe: Bad file descriptor

That seems related, and bad.

That does appear each time even when successful resume from sleep. This is a rare, but annoying issue, so since posting this its only happened once. This time docked to Lenovo displaylink with two external screens but also happens if undocked not powered.

When I came to wake up the laptop the fans were at high spin rate but again no response at all even from laptops built in keyboard.
Looking at the logs it seems I put the machine to sleep and either I knocked the mouse but it looked to have tried to resume at about 4:25PM says it succesfully resumed but logs stop recording after about a few minuets. I tried to wake it the next day.

I did see in last log the network manager showing this. (sleeping: no  enabled: yes) which seems odd, is that a power setting in that it never network cards dont go to sleep if on power?

Nov 10 11:22:12 arhclinuxT14 systemd-logind[593]: The system will suspend now!
Nov 10 11:22:12 arhclinuxT14 NetworkManager[590]: <info>  [1731198132.0923] manager: sleep: sleep requested (sleeping: no  enabled: yes)

Created attachment 175771 [details]
Last unsuccesful resume Nov 11th

I believe this might be the same issue that happens on my desktop computer, I would resume from sleep and the lock screen would be completely frozen and I can't do anything with my computer, can't even switch to a tty, so I always just pressed the power button which made so I can't provide any logs since they get wiped off.
This is completely random, and isn't exactly reproducible, but every single time it got frozen it was suspended for a short period of 30 minutes to 1 hour long and always on the evening or at night.
Since my motherboard has built-in wifi from mediatek, I need to use a systemd script to power off the module so my PC doesn't freeze upon resume since the 6.11 kernel version, in my amd laptop or when using another DE this issue hasn't happened yet and it's the same script, so I would like to think it's not from there.

My specs are:
CPU: 7800X3D
GPU: RX 7900 XTX
Motherboard: Asus B650M-plus wifi
OS: Arch linux
Kernel: 6.12.1
KDE: 6.2.4
Applications: 24.08.3
Screens: LG C3 TV and Gigabyte G27Q

Could it be this driver issue:
https://gitlab.freedesktop.org/drm/amd/-/issues/2362
https://github.com/ROCm/ROCK-Kernel-Driver/issues/174

It was recently fixed:
https://gitlab.freedesktop.org/agd5f/linux/-/commit/2965e6355dcdf157b5fafa25a2715f00064da8bf
with a beautiful blog of the 1 year fixing process:
https://nyanpasu64.gitlab.io/blog/amdgpu-sleep-wake-hang/

Please report again after you can use Linux 6.14.

I think I encountered it myself, so I should be able to confirm this as well.

It happens when you have a high memory usage at the moment you suspended.

OK great news, it does sound very similar. Currently running kernel 6.13.5 so will continue to monitor and check when 6.14 is release the problem goes away.
I might also monitor RAM usage and see when its running high, I causes it to not resume.

Not at kernel 6.14 yet, but is still happening, what is weird is nothing is being reported in the journalctl still. Just stops.
Attached is a recent freeze as of 5th April. (Just held power button to reboot it)
Will still wait till 6.14. I wonder if I need to update hardware firmware using fwupd, only I am hesitant due to the boot drive changing and having to troubleshoot booting it again.

Created attachment 180018 [details]
last 100 lines of journalctl boot, last line shows nothing indicating an issue.

Same thing happens on my installation. 

Operating System: Fedora 41 
KDE Plasma Version: 6.3.4
KDE Frameworks Version: 6.12.0
Qt Version: 6.8.2
Kernel Version: 6.13.9 (64 bit)
Graphics Platform: Wayland
Processors: 32 × AMD Ryzen 9 9950X 16-Core Processor
Memory: 30.4 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 4080 SUPER/PCIe/SSE2
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: X870 AORUS ELITE WIFI7
System Version: Default string-CF-WCP-ADO


STEPS TO REPRODUCE
1. Put the PC to sleep
2. Wake the device up
3. The login screen shows the clock and the wallpaper, no login boxes.
4. Typing in the password blind will unlock the session in 15 seconds.

This happens every 2-3 suspends, not always.
It doesn't happen when I switch to my AMD GPU.
It doesn't happen when I set the kscreenlocker_greet to use software rendering.

It has happened at least since kernel 6.11 and nvidia driver 565

Hi, now this lock up freeze is happening daily, regardless of resume. I just booted up today and in about 30 mins it freezes. It is docked through a Lenovo Docking station. 

-Everything freezes (no applications are running other than Firefox)
- The dual screens go blank and disconnect
-Laptop screen (which is open) just shows desktop no activity, keyboard/mouse on laptop un responsive
- Disconnecting the Lenovo dock does not do anything. 

- I reboot and it then tends to work for rest of the day, but is random.
- I shut down now every day and avoid sleep resume.

I have exported the last journalctl file if you need it but its the same as previous attachments.

Current Hardware/Software

Operating System: Arch Linux 
KDE Plasma Version: 6.3.3
KDE Frameworks Version: 6.12.0
Qt Version: 6.8.3
Kernel Version: 6.13.8-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 PRO 6650U with Radeon Graphics
Memory: 30.1 GiB of RAM
Graphics Processor 1: AMD Radeon Graphics
Graphics Processor 2: AMD Radeon Graphics
Manufacturer: LENOVO
Product Name: 21CGS0VT0B
System Version: ThinkPad T14 Gen 3

Greetings from Philadelphia, USA! I experience a similar problem as well. It seems to be triggered by my PC sleeping. If it switch to a virtual terminal and kill kscreenlocker, I can then switch back to GUI and successfully login. Forgive my ignorance, but I speculate that there's more than one screen lock or maybe it's a screen lock and the login SDDM are being presented.

Typical scenario:
1) Sleep PC
2) Wake PC the next day
3) The gui asks for my password. Enter it and press RETURN. Nothing happens. It's like the RETURN press didn't even happen.
4) Switch to a virtual terminal and kill kscreenlocker
5) Switch back to GUI and successfully login

On very rare occasions I experience a total hang of the GUI like someone else mentioned.

My setup:
- Linux kernel 6.14.3
- NixOS 24.11
- KDE Plasma 6.2.5
- Wayland

I experienced this last year when I was using Tuxedo OS as well. I forget which KDE Plasma 6 version it was...

I regularly contribute funds to the KDE project. You should too! It's the best desktop and app ecosystem bar none!

https://kde.org/donate/

(In reply to jkotran from comment #20)
> Greetings from Philadelphia, USA! I experience a similar problem as well. It
> seems to be triggered by my PC sleeping. If it switch to a virtual terminal
> and kill kscreenlocker, I can then switch back to GUI and successfully
> login. Forgive my ignorance, but I speculate that there's more than one
> screen lock or maybe it's a screen lock and the login SDDM are being
> presented.
> 
> Typical scenario:
> 1) Sleep PC
> 2) Wake PC the next day
> 3) The gui asks for my password. Enter it and press RETURN. Nothing happens.
> It's like the RETURN press didn't even happen.
> 4) Switch to a virtual terminal and kill kscreenlocker
> 5) Switch back to GUI and successfully login

I had the same issue several times with external monitor and power connected. Just an idle-timeout kicking in, when asking for the password after a next keypress. I had to kill the kscreenlocker as well.
For me it's not an AMD-related issue since my laptop runs on Intel-CPU with integrated Intel graphics.

I experience the same problem.
On an integrated Intel graphics laptop with an external monitor connected from usb-c to display port.

After resume from sleep it takes about 20s/30s for the system to be responsive.
Journactl -b shows the following line after a jump in timestamps suggesting that this may be the culprit:
kwin_wayland_drm: The main thread was hanging temporarily!

(In reply to Marc from comment #22)
> I experience the same problem.
> On an integrated Intel graphics laptop with an external monitor connected
> from usb-c to display port.
> 
> After resume from sleep it takes about 20s/30s for the system to be
> responsive.
> Journactl -b shows the following line after a jump in timestamps suggesting
> that this may be the culprit:
> kwin_wayland_drm: The main thread was hanging temporarily!

This sounds like a different bug. In the original report, the user waited 10 minutes, but the system was still unresponsive. Please report this as a new bug, if there isn't a report already. Thanks.

(In reply to TraceyC from comment #23)
> (In reply to Marc from comment #22)
> > I experience the same problem.
> > On an integrated Intel graphics laptop with an external monitor connected
> > from usb-c to display port.
> > 
> > After resume from sleep it takes about 20s/30s for the system to be
> > responsive.
> > Journactl -b shows the following line after a jump in timestamps suggesting
> > that this may be the culprit:
> > kwin_wayland_drm: The main thread was hanging temporarily!
> 
> This sounds like a different bug. In the original report, the user waited 10
> minutes, but the system was still unresponsive. Please report this as a new
> bug, if there isn't a report already. Thanks.

Thanks, done. I found a bug report that more closely resembles what I experience:
https://bugs.kde.org/show_bug.cgi?id=470062

Hi all,

Can someone let me know what precisely starts the kscreenlocker_greet process? For me the problem is there's a redundant kscreenlocker_greet process after PC sleep. If I kill the redundant process, I can successfully login.

Best,

Joe Kotran