SDDM 0.20.0_3 freezing after screenlock on RELEASE-14.1

J

jsteward

I'm gradually being driven crazy by the occasional freeze of SDDM (or KDE screenlocker?) It would occasionally stop responding after I leave the seat for some time and come back to unlock the session. I can still move the (KDE-themed) mouse pointer, but the clock on the lockscreen would have stopped ticking. I've checked /var/log/messages and there's nothing related to SDDM, only some messages from kscreenlocker_greet that is apparently benign (PR 270595):

Code: 
Jun 26 15:02:09 <redacted> kscreenlocker_greet[77557]: in _pam_exec(): pam_sm_setcred: pam_get_authtok(): authentication token not available
Jun 26 15:12:14 <redacted> kscreenlocker_greet[65017]: in _pam_exec(): pam_sm_setcred: pam_get_authtok(): authentication token not available

Here are some general information about the system (FreeBSD version, GPU model, package for the GPU driver and SDDM). The drm i915 driver is built from the local ports tree for UHD 770, but the rest of the system should be running -quarterly.

Code: 
$ uname -a
FreeBSD <redacted> 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64
$ pciconf -lv | grep -B 4 VGA
vgapci0@pci0:0:2:0:     class=0x030000 rev=0x0c hdr=0x00 vendor=0x8086 device=0x4690 subvendor=0x1043 subdevice=0x8694
    vendor     = 'Intel Corporation'
    device     = 'Alder Lake-S GT1 [UHD Graphics 770]'
    class      = display
    subclass   = VGA
$ pkg info -A drm-61-kmod sddm
drm-61-kmod-6.1.92:
        FreeBSD_version: 1401000
        build_timestamp: 2024-06-18T10:09:11+0000
        built_by       : poudriere-git-3.4.1_1
        port_checkout_unclean: no
        port_git_hash  : 1c135509e
        ports_top_checkout_unclean: no
        ports_top_git_hash: 1c135509e
        repo_type      : binary
        repository     : Poudriere
sddm-0.20.0_3:
        FreeBSD_version: 1400097
        build_timestamp: 2024-06-11T06:37:45+0000
        built_by       : poudriere-git-3.4.1-30-g79e3edcd
        cpe            : cpe:2.3:a:sddm_project:sddm:0.20.0:::::freebsd14:x64:3
        port_checkout_unclean: no
        port_git_hash  : b3aa1ea86
        ports_top_checkout_unclean: no
        ports_top_git_hash: 492f5a54a
        repo_type      : binary
        repository     : FreeBSD

Would appreciate any ideas on how to fix this and don't hesitate to ask for more info! Thanks :)
 
The session default in sddm is plasma5-wayland.
You must choose the x11 session (drop-down menu in bottom left of the sddm screen)
 
tuxador said:
The session default in sddm is plasma5-wayland.
You must choose the x11 session (drop-down menu in bottom left of the sddm screen)
Click to expand...
Thanks, I forgot to say this: I’m using X11 since somehow Wayland doesn’t work and I didn’t bother to figure out why.

I’m not having trouble logging in—that works fine (e.g. after I boot the system, or after I restart SDDM after the freeze). The trouble is after locking the desktop with Super-L, or leaving it to automatically lock after a timeout. Thanks!
 
I am also having this issue. At one point from a fresh install I was having no issues on resume, but now the issue has cropped up for me. I too am using X11 instead of wayland.

For me, locking the desktop with Super-L works fine, it's only after starting the machine back up after a Suspend that I have the issue.
 
I believe my issue is because I had ZFS backups from another system that were accidentally getting mounted over top of my root filesystem. Fixing the mountpoint of those backups to be none, now my system correctly resumes from suspend.
 
jsteward said:
… clock on the lockscreen would have stopped …
Click to expand...

Reproducible with FreeBSD in safe mode?

Is ck-unlock-session a workaround?

jsteward said:
… Alder Lake-S GT1 [UHD Graphics 770] …
Click to expand...

No comparable problem with old-ish NVIDIA hardware and packages from latest on CURRENT.

Code: 
% pkg iinfo nvidia sddm
nvidia-driver-470-470.161.03_1
nvidia-settings-535.146.02_1
nvidia-xconfig-525.116.04
plasma5-sddm-kcm-5.27.11
sddm-0.21.0
sddm-freebsd-black-theme-1.3
% uname -aKU
FreeBSD mowa219-gjp4-zbook-freebsd 15.0-CURRENT FreeBSD 15.0-CURRENT main-n271248-e82cee21ba3b GENERIC amd64 1500020 1500020
%

I can't find anything matching your symptom in GitHub for drm-kmod.
 
I am having the exact same issue with Plasma5-X11. Every once in a while, when want to unlock the screen, I do not get a window to type in my password. My workaround so far is to switch to a console (ctrl-alt-F2) and reset SDDM. This of course kills my session :(. ck-unlock-session does not help either.

Did you find a solution to the problem yet or do you have a better workaround?
 
Thanks for asking.

Actually, the behavior is like that originally described by the OP. That's the reason why I'm attaching my post to this thread and not opening a new one.

When the problem occurs, I just get the image of the screen saver, but there is no field to type in the password to unlock the screen. I can move the mouse. Keyboard also works, so I can change to a virtual console.

On ttyv0 I can see the following message (I am not sure if it is related with the problem):

Code: 
kscreenlocker_greeter [61045]: in _pam_exe(): pam_sm_setcred: pam_get_authtok(): authentication token not available

Most of the time I can unlock the screen normally. The problem happens roughly one in five times.
 
… _pam_exe() …
Click to expand...

Typo? I think, that's a match for 270595, which was not a bug.

… The problem happens roughly one in five times.
Click to expand...

To the best of my recollection, I never encountered the problem.

What's your graphics hardware, and driver?

Also, please:

freebsd-version -kru ; uname -aKU

pkg -vv | grep -B 1 -e url -e priority

pkg prime-origins | sort -u
 
You must log in or register to reply here.
Back
Top