KDE on X system hang

Lone_Wolf · 2024-05-08 14:52:31

My GF uses archlinux and does run pacman -Syu daily, but relies on me for support.

The pc has an intel processor with integrated graphics, one vga screen and runs KDE plasma on X using modesetting .
Power settings for screen are set to dimming after 5 minutes and shutting off the screen after 10.
KDE Screenlocker is set to engage just before the screen shuts of.

Lat week she called me reporting the pc didn't respond when she wanted to shut it down . Turned out that the gui/mouse were not functioning as expected, but kernel & keyboard still worked.
Using CTRL+ALT+F2 , root login , poweroff the pc was shut down.

The programs she uses most frequently are firefox & thunderbird. I asked here to close both before leaving the pc alone for a while, this didn't prevent the hang .

Yesterday I looked at logs ( see http://0x0.st/X8PX.txt ) and found powerdevil had problems with ddcutil (timestamp "mei 06 17:15:45" )
A quick DDG search showed powerdevil often has problems with ddcutil.

Powerdevil uses ddcutil if it is present upon buildtime and the pc of my gf isn't setup for clean chroot building.
As a temp solution I downgraded powerdevil to 6.0.3-1 and added it to IgnorePkg in pacman.conf .

I can build a powerdevil-no-ddcutil in a clean chroot on my desktop and install that on her system , but plasma changes often and I'd rather keep her system setup simple and updatable by her.

Please advise on how to continue.

Lone_Wolf · 2024-05-09 22:42:18

(title changed)

I heard from my GF and downgrading powerdevil hasn't helped.
ddcutil last update was before the problems started.

Around the timestamp of the powerdevil messages there are also messages from kscreenlocker .

mei 06 17:27:19 mika kscreenlocker_greet[1952]: qt.virtualkeyboard.hunspell: Hunspell dictionary is missing for "nl_NL". Search paths QList("/usr/share/qt6/qtvirtualkeyboard/hunspell", "/usr/share/hunspell", "/usr/share/myspell/dicts")

mei 06 17:29:45 mika dbus-daemon[382]: [system] Activating via systemd: service name='org.freedesktop.home1' unit='dbus-org.freedesktop.home1.service' requested by ':1.59' (uid=1000 pid=1952 comm="/usr/lib/kscreenlocker_greet --graceTime 5000 --ks")
mei 06 17:29:45 mika dbus-daemon[382]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.home1.service': Unit dbus-org.freedesktop.home1.service not found.

mei 06 17:58:48 mika kscreenlocker_greet[2056]: qt.virtualkeyboard.hunspell: Hunspell dictionary is missing for "nl_NL". Search paths QList("/usr/share/qt6/qtvirtualkeyboard/hunspell", "/usr/share/hunspell", "/usr/share/myspell/dicts")

mei 06 18:12:46 mika dbus-daemon[382]: [system] Activating via systemd: service name='org.freedesktop.home1' unit='dbus-org.freedesktop.home1.service' requested by ':1.61' (uid=1000 pid=2056 comm="/usr/lib/kscreenlocker_greet --graceTime 5000 --ks")
mei 06 18:12:46 mika dbus-daemon[382]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.home1.service': Unit dbus-org.freedesktop.home1.service not found.

that service is found at usr/share/dbus-1/system-services/org.freedesktop.home1.service and belongs to systemd .
systemd-homed is NOT used at all on the system, no idea why kscreenlocker wants it but it's the obvious next candidate to look at.

seth · 2024-05-10 07:40:42

If you assume the problem is the DDC I'd disable dimmign and see whether that makes the issue go away.
Though

mei 06 16:27:51 mika kernel: DMI: Acer Aspire X3990/Aspire X3990, BIOS P01-B0                 05/21/2011

Does the backlight control hinge on DDC at all??

Turned out that the gui/mouse were not functioning as expected, but kernel & keyboard still worked.

Does the mouse still move? Tried to suspend the compositor? (SHIFT+alt+F12)

Also check the xorg log for
1. errors
2. presence of the xf86-video-intel driver (instead of modesetting) - despite being an older sandybridge, one might fare better than the other.
(The ability to switch the VT suggests it's more a KDE/X11 problem than a kernel or DDC one)

Lone_Wolf · 2024-05-14 10:49:04

Disabling dimming hasn't helped .

After 10 minutes of inactivity the screen should shut down and turn black, but occasionally it turns blue instead.

The mouse cursor comes back when it is moved, but clicking has no effect.
Neither do keys like alt-tab , space, ESC and such .

I'll look into getting X log.

seth · 2024-05-14 11:32:01

occasionally it turns blue … mouse cursor comes back when it is moved

That sounds more like either plasma crashed or the screenlocker blocks input.
In case of plasma, DPMS might cause the monitor to unregister, kscreen resizes the desktop to a 0x0 square and that probably triggers a lot of bugs.
You'd find that in the system journal and of course can check the running processes from the console.

zpg443 · 2024-05-14 17:36:11

I had this issue, and same config (X with Intel integrated graphics), and was able to make it go away by going to KDE system settings, and disabling all screen power down settings, including any suspends. I waited for a few days and a system update, then re-enabled the settings. No more issue.

Last edited by zpg443 (2024-05-14 17:37:34)

Lone_Wolf · 2024-05-16 09:20:47

I have now observed the problem myself.
The shutting down of the screen works every time and it also comes back when mouse is moved.
The screen then sometimes shows the mouse cursor but not the background.

One time this happened :
- switch to konsole
log in as root
run a few simple commands
alt+F1 to switch back to the graphics session

Notice the normal background and the password input window are present
In the left corner a symbol for virtual keyboard is shown ! (no log from this, sorry)

logs from 2 separate occurences
journal + x log http://0x0.st/XPz2.txt http://0x0.st/XPz_.txt

journal + x log + x error http://0x0.st/XPzp.txt http://0x0.st/XPzf.txt http://0x0.st/XPzO.txt

The journals don't give new information , but the xorg logs do.

from http://0x0.st/XPzf.txt

[  5972.425] (**) Option "fd" "27"
[  5972.425] (II) event1  - Power Button: device removed
[  5972.426] (**) Option "fd" "30"
[  5972.426] (II) event0  - Power Button: device removed
[  5972.427] (**) Option "fd" "31"
[  5972.427] (II) event2  - Lite-On Technology Corp. USB Multimedia Keyboard: device removed
[  5972.427] (**) Option "fd" "32"
[  5972.427] (II) event3  - Lite-On Technology Corp. USB Multimedia Keyboard System Control: device removed
[  5972.428] (**) Option "fd" "33"
[  5972.428] (II) event4  - Lite-On Technology Corp. USB Multimedia Keyboard Consumer Control: device removed
[  5972.428] (**) Option "fd" "34"
[  5972.428] (II) event5  - Lite-On Technology Corp. USB Multimedia Keyboard: device removed
[  5972.429] (**) Option "fd" "35"
[  5972.429] (II) event6  - Logitech USB Optical Mouse: device removed
[  5972.430] (II) AIGLX: Suspending AIGLX clients for VT switch

The timestamps do match waking up the screen by moving the mouse and only seeing the mouse poiinter.
No idea how to interpret that atm.

seth · 2024-05-16 14:34:55

Device "removal" on VT switches is perfectly normal

journal + x log + x error http://0x0.st/XPzf.txt http://0x0.st/XPzf.txt http://0x0.st/XPzO.txt

The first two are the same file.

mei 15 13:27:15 mika login[426]: ROOT LOGIN ON tty1
…
mei 15 13:28:02 mika login[585]: LOGIN ON tty1 BY thea
…
mei 15 13:28:20 mika kwin_x11[709]: GPU class:                              SandyBridge
…
mei 15 14:47:54 mika plasmashell[744]: qrc:/plasma/DefaultToolTip.qml:25:5: QML RowLayout: Layout polish loop detected for QQuickRowLayout(0x6359550bfbf0, id="mainLayout", parent=0x6359550b9610, geometry=-46,-10 360x75). Aborting after two iterations.
mei 15 14:47:54 mika kwin_x11[709]: kwin_scene_opengl: 0x6: GL_INVALID_VALUE in glTexStorage2D(width, height or depth < 1)
mei 15 14:47:54 mika kwin_x11[709]: kwin_scene_opengl: Invalid framebuffer status:  "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
mei 15 14:47:54 mika kwin_x11[709]: kwin_effect_blur: Failed to create an offscreen framebuffer
…
mei 15 15:06:49 mika login[2161]: ROOT LOGIN ON tty2
…
mei 15 15:07:07 mika systemd-logind[383]: The system will power off now!

root logged in, thea logged in, kwin started
~80 minutes later kwin tries to allocate a zero-size texture
~20 minutes later root logs in on TTY2 and
~20 seconds later shuts down the system

There's no crash (before the shutdown) and no real kscreen action.

seth wrote:

Tried to suspend the compositor? (SHIFT+alt+F12)

If you cannot replicate the problem w/ the compositor disabled, try xf86-video-intel (and mesa-amberor enforcing the iris driver, https://wiki.archlinux.org/title/Intel_ … ecent_GPUs )

If you can replicate this and can still switch the VT, don't shutdown the system, but see whether kwin still responds eg. to dbus calls.

qdbus org.kde.KWin /KWin supportInformation

Lone_Wolf · 2024-05-17 08:37:24

The first two are the same file.

Corrected, the journal is at http://0x0.st/XPzp.txt

root logged in, thea logged in, kwin started
~80 minutes later kwin tries to allocate a zero-size texture
~20 minutes later root logs in on TTY2 and
~20 seconds later shuts down the system

The log in to TTY2 is just AFTER the issue presents itself .

seth · 2024-05-17 11:35:28

mei 15 15:09:09 mika systemd-logind[388]: New session 1 of user root.
mei 15 15:14:42 mika systemd-logind[388]: New session 3 of user thea.
---------
mei 15 15:15:01 mika kwin_x11[780]: kf.config.core: "\"fsrestore1\" - conversion of \"0,0,0,0\" to QRect failed"
mei 15 15:15:01 mika kwin_x11[780]: kf.config.core: "\"fsrestore2\" - conversion of \"0,0,0,0\" to QRect failed"
---------
mei 15 17:31:01 mika kwin_x11[780]: kwin_scene_opengl: 0x1: GL_INVALID_VALUE in glTexStorage2D(width, height or depth < 1)
mei 15 17:31:01 mika kwin_x11[780]: kwin_scene_opengl: Invalid framebuffer status:  "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
mei 15 17:31:01 mika kwin_x11[780]: kwin_effect_blur: Failed to create an offscreen framebuffer
mei 15 17:31:08 mika systemd[665]: Started Konsole - Terminal.
mei 15 17:35:42 mika systemd[665]: Started Systeeminstellingen - Systeeminstellingen.
--------------
mei 15 17:39:33 mika systemd-logind[388]: New session 5 of user root.
mei 15 17:55:37 mika systemd-logind[388]: New session 7 of user thea.
--------------
mei 15 17:55:41 mika kwin_x11[7006]: kf.config.core: "\"fsrestore1\" - conversion of \"0,0,0,0\" to QRect failed"
mei 15 17:55:41 mika kwin_x11[7006]: kf.config.core: "\"fsrestore2\" - conversion of \"0,0,0,0\" to QRect failed"

The root login at 17:39 is to investigate/deal w/ the problem that occurred somewhen around 17:31 ?

There's nothing in the journal, esp. nothing from kscreen but w/ the circumstances and symptoms kwin trying to create a null sized blur(?) texture and when the session starts to restore a null rect my best guess as to what happens is that
1. dpms activates
2. the output somehow unregisters (common w/ TVs, not so much w/ eDPs?)
3. kscreen removes the output
4. you're left w/ no output and a 0x0 root window
5. stuff™ loses its shit

If that's true
1. "xset dpms force off" and keeping your hands of the system for enough time to facilitate the shit losing part (give it 30s) would be able to trigger this
2. disabling kscreen in "kcmshell6 kded" might be able to avoid it (if this is a notebook that's always gonna be attached to that one display only there should be no downsides)

Lone_Wolf · 2024-05-18 20:00:09

there was no problem visible at 17:31 .

The system is a standard desktop minitower with only one screen attached (which never changes) so I doubt kscreen adds anything of value .

It will be several days atleast before I can investigate further / change settings.

V1del · 2024-05-22 19:14:36

FWIW symptoms sound like they might be related to https://bugs.kde.org/show_bug.cgi?id=478556 -- while I'm not sure whether the general logistics would apply to a top level window like kscreenlock, chances are this is related, and would get fixed by 6.0.5

Lone_Wolf · 2024-06-27 09:55:31

I had time to check the comp again and updates have reduced the frequency but didn't solve the issue.

I proposed disabling the screenlocker to verify if that's causing it, but she opposed that.
While i was there it did happen again, but there was little time to investigate it further.

Tried CTRL+ALT+F2 followed by ALT+F1 : no change, still just a mouse cursor

This however worked :
CTRL+ALT+F2
login as root
ALT+F! : greeted by the screenlocker screen
It showed virtual keyboard in the left corner with 2 characters filled in the password field
removing those 2 chars and typing the password unlocked the graphical session .

So it appears there is a workaround for this issue :
switch to tty
USE the keyboard in tty
switch back to graphical environment

The physical keyboard used is a simple dell usb keyboard (US Intenational) without any extra keys that came with her previous computer and never has given issues.

seth · 2024-06-27 14:50:47

I proposed disabling the screenlocker to verify if that's causing it, but she opposed that.

You're seeing a corrupted texture, the mouse cursor is rendered directly into the framebuffer so it could be kwin or the screenlocker.

seth wrote:

seth wrote:
Tried to suspend the compositor? (SHIFT+alt+F12)

As for the trigger:

speculating seth wrote:

"xset dpms force off" and keeping your hands of the system for enough time to facilitate the shit losing part (give it 30s) would be able to trigger this

Lone_Wolf · 2024-07-13 12:35:42

Suspending the compositor didn't change this, also xset dpms force off didn't trigger it.

I have since found that another system I maintain has the same symptoms.

One system has an intel processor with integraded intel gpu from approx 2014 , the other is a ryzen system with a integrated amd gpu from around 2020.
Both never had issues before plasma 6 .

Not long ago I did stumble on posts of people with the same issue where someone claimed that this was related to plasma 5 theme settings not converted properly to plasma 6.
Proposed solution was to clear all k* files in ~/.cache , then switch to default kde6 theme
restart kde, switch back to kde5 theme, restart kde and check if it's solved.

Unfortunately I can't find those posts anymore and the poster didn't mention which kde5 theme they used.

For now both users indicate they are afraid of evil maid scenario (although they didn't use those words) and against disabling kscreenlocker.
They are ok with the workaround of switching to tty and back to graphical .

seth · 2024-07-14 22:30:43

Unfortunately I can't find those posts anymore

https://bbs.archlinux.org/viewtopic.php?id=293631 but I somewhat doubt that such client bug could be overcome by switching the framebuffer forth and back

For now both users indicate they are afraid of evil maid scenario

slock, i3lock, xscreensaver, …

Arch Linux

#1 2024-05-08 14:52:31

KDE on X system hang

#2 2024-05-09 22:42:18

Re: KDE on X system hang

#3 2024-05-10 07:40:42

Re: KDE on X system hang

#4 2024-05-14 10:49:04

Re: KDE on X system hang

#5 2024-05-14 11:32:01

Re: KDE on X system hang

#6 2024-05-14 17:36:11

Re: KDE on X system hang

#7 2024-05-16 09:20:47

Re: KDE on X system hang

#8 2024-05-16 14:34:55

Re: KDE on X system hang

#9 2024-05-17 08:37:24

Re: KDE on X system hang

#10 2024-05-17 11:35:28

Re: KDE on X system hang

#11 2024-05-18 20:00:09

Re: KDE on X system hang

#12 2024-05-22 19:14:36

Re: KDE on X system hang

#13 2024-06-27 09:55:31

Re: KDE on X system hang

#14 2024-06-27 14:50:47

Re: KDE on X system hang

#15 2024-07-13 12:35:42

Re: KDE on X system hang

#16 2024-07-14 22:30:43

Re: KDE on X system hang

Board footer