Issue with plasma on wayland with kms in arm-unstable for RPi4

There is some issue with the startup of Plasma in the arm-unstable branch. On startup, I think about the time the compositor is started, often, it hangs. I can press [Ctrl]-Fx and get to a tty, so the “hang” is with Plasma, not the OS.

If I remove my .config directory, it will successfully bring up a desktop.

This is on my UEFI system, but I do not think that is related to this issue.

$ sudo systemctl status

● abbynormal
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Thu 2021-04-08 08:07:03 CDT; 5 days ago
   CGroup: /
           │ ├─user-0.slice 
           │ │ ├─session-4.scope 
           │ │ │ ├─1130 login -- root
           │ │ │ ├─1148 -bash
           │ │ │ └─1175 systemctl status
           │ │ └─user@0.service …
           │ │   └─init.scope 
           │ │     ├─1135 /usr/lib/systemd/systemd --user
           │ │     └─1139 (sd-pam)
           │ └─user-1000.slice 
           │   ├─user@1000.service …
           │   │ ├─background.slice 
           │   │ │ ├─plasma-kactivitymanagerd.service 
           │   │ │ │ └─925 /usr/lib/kactivitymanagerd
           │   │ │ └─plasma-kglobalaccel.service 
           │   │ │   └─922 /usr/bin/kglobalaccel5
           │   │ ├─app.slice 
           │   │ │ ├─dconf.service 
           │   │ │ │ └─900 /usr/lib/dconf-service
           │   │ │ ├─pulseaudio.service 
           │   │ │ │ ├─ 974 /usr/bin/pulseaudio --daemonize=no --log-target=journal
           │   │ │ │ └─1008 /usr/lib/pulse/gsettings-helper
           │   │ │ ├─obex.service 
           │   │ │ │ └─1077 /usr/lib/bluetooth/obexd
           │   │ │ └─dbus.service 
           │   │ │   ├─ 850 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
           │   │ │   └─1074 /usr/lib/kf5/kscreen_backend_launcher
           │   │ └─init.scope 
           │   │   ├─833 /usr/lib/systemd/systemd --user
           │   │   └─837 (sd-pam)
           │   └─session-2.scope 
           │     ├─ 819 lightdm --session-child 12 21
           │     ├─ 845 /usr/bin/startplasma-x11
           │     ├─ 866 /usr/lib/kf5/start_kdeinit
           │     ├─ 867 kdeinit5: Running...
           │     ├─ 868 /usr/lib/kf5/klauncher --fd=10
           │     ├─ 891 /usr/bin/kded5
           │     ├─ 895 /usr/bin/kwin_x11
           │     ├─ 932 /usr/bin/ksmserver
           │     ├─ 951 /usr/lib/org_kde_powerdevil
           │     ├─ 953 /usr/bin/plasmashell
           │     ├─ 955 /usr/bin/xembedsniproxy
           │     ├─ 958 /usr/bin/kaccess
           │     ├─ 960 /usr/lib/polkit-kde-authentication-agent-1
           │     ├─ 962 /usr/bin/gmenudbusmenuproxy
           │     ├─ 970 /usr/lib/DiscoverNotifier
           │     ├─ 973 /usr/bin/mntray --delay
           │     ├─1090 [kdeinit5] desktop local:/run/user/1000/klauncherPgqPAW.1.slave-socket local:/run/user/1000/plasmashellWbjLcO.1.slave-socket
           │     ├─1093 [kdeinit5] file local:/run/user/1000/klauncherPgqPAW.1.slave-socket local:/run/user/1000/kio_desktopeaxENb.1.slave-socket
           │     ├─1102 [kdeinit5] file local:/run/user/1000/klauncherPgqPAW.1.slave-socket local:/run/user/1000/plasmashellUSdQeo.2.slave-socket
           │     ├─1111 [kdeinit5] file local:/run/user/1000/klauncherPgqPAW.1.slave-socket local:/run/user/1000/kded5EIRvXb.1.slave-socket
           │     └─1112 [kdeinit5] file local:/run/user/1000/klauncherPgqPAW.1.slave-socket local:/run/user/1000/kded5lxJroE.2.slave-socket
           │ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 30
             │ └─377 @usr/bin/haveged -w 1024 -v 1 --Foreground
             │ └─1030 /usr/lib/PackageKit/packagekitd
             │ └─386 /usr/lib/systemd/systemd-networkd
             │ └─379 /usr/lib/systemd/systemd-udevd
             │ └─618 /usr/lib/systemd/systemd-homed
             │ └─665 /usr/lib/polkit-1/polkitd --no-debug
             │ └─982 /usr/lib/rtkit-daemon
             │ └─627 /usr/bin/chronyd
             │ └─658 /usr/lib/iwd/iwd
             │ └─651 /usr/lib/accounts-daemon
             │ ├─644 /usr/bin/lightdm
             │ └─650 /usr/lib/Xorg :0 -seat seat0 -auth /run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
             │ └─378 /usr/lib/systemd/systemd-journald
             │ └─638 sshd: /usr/bin/sshd -D [listener] 0 of 10-100 startups
             │ └─615 /usr/bin/NetworkManager --no-daemon
             │ ├─767 /usr/lib/systemd/systemd-userdbd
             │ ├─768 systemd-userwork
             │ ├─769 systemd-userwork
             │ └─770 systemd-userwork
             │ └─642 /usr/bin/python3 /usr/bin/argononed
             │ └─949 /usr/lib/upowerd
             │ └─935 /usr/lib/udisks2/udisksd
             │ └─614 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
             │ └─getty@tty2.service 
             │   └─1129 /sbin/agetty -o -p -- \u --noclear tty2 linux
               └─622 /usr/lib/systemd/systemd-logind

This process does not continue on a successful desktop startup, so maybe related?

           │     ├─1090 [kdeinit5] desktop local:/run/user/1000/klauncherPgqPAW.1.slave-socket local:/run/user/1000/plasmashellWbjLcO.1.slave-socket

$ sudo pstree

        |          |-4*[]
        |          `-klauncher---2*[{klauncher}]
        |         |-lightdm-+-startplasma-x11---{startplasma-x11}
        |         |         `-2*[{lightdm}]
        |         `-2*[{lightdm}]
        |         `-2*[{python3}]
        |         |-dbus-daemon
        |         |-dconf-service---2*[{dconf-service}]
        |         |-kactivitymanage---5*[{kactivitymanage}]
        |         |-kglobalaccel5---2*[{kglobalaccel5}]
        |         |-kscreen_backend---2*[{kscreen_backend}]
        |         |-obexd
        |         `-pulseaudio-+-gsettings-helpe---3*[{gsettings-helpe}]
        |                      `-{pulseaudio}

This is in addition to the random hangs with Xorg and terrible Wayland performance issues.

I now see an update involving several KDE packages. I will update and report back.

After applying the updates, my issue of the desktop failing to start has not occurred again after multiple reboots. So I think that issue has been resolved. Not enough time to know if the random hangs have been resolved on x11, they were infrequent.

However, Plasma on Wayland continues to be mostly unusable.

These are the error generated when my system hangs:

[  102.113091] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:74:crtc-3] flip_done timed out
[  102.113091] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:74:crtc-3] flip_done timed out

These occur with both x11 and wayland, but much more frequently with wayland.

Edit: Seems some folks at Red Hat are aware. Does not look like this is Plasma related.

Edit 2:This issue has existed before and with different hardware. So pretty sure the fix will come from the kernel updates.

why stop update kernel?

I am using UEFI which requires 5.12 for wifi, so I can not downgrade the kernel. I switched to fkms which works without errors.

5.10 5.11 5.12 kms all failed with plasma.

I believe this is related. Maybe when they figure out the problem it will be fixed. At the moment it appears to be a firmware issue.

Hmm, that one is for fkms… which works for me. But then, I am using 1080p and not 4K for this install.

Whatever the issue, it is somehow related to mouse movement. If you do not move the mouse and use just the keyboard, plasma runs fine on wayland, no errors.

Edit: Well, I rebooted and the issue returned, wonky issue.
@Rip2 I am pretty sure kms and plasma worked on 5.10. I will do more testing this weekend.

Edit 2: I did a quick test, switching to 4K@60 and 5.10 + kms + wayland, and it is indeed broken. I know at one time it worked, back when 5.10 was mainline or rc. And tests performed better with wayland than x11. So many configurations, I have lost track. :slight_smile:

I am used to once something hits the kernel, it continues to work. Once in a while there is a regression but it is quickly fixed. This up/down on kms is a new experience for me. I wonder if the RPi4 is fundamentally a broken design, and that is the cause? Are the other SoC boards equally up/down with their hardware drivers?

Here is another thread looking like the same issue opened last September and they have been actively discussing it lately. Last post was 3 hours ago.

I have the exact issue as the OP, but my wait is not as long, possibly because I currently specify the hdmi_mode and hdmi_group and not relying on EDID. But I currently have these errors, even at 1080p.

I do overclock, and I set arm_freq=1800 and v3d_freq=600. I have hdmi_enable_4kp60=1 which sets the core_freq to 550. I’ll try core_freq=600 and core_freq_min=600 and see if that makes a difference.

A little more testing with 5.10.25-3 and kms, something is very broke. If you use EDID or specify your monitor settings, does not matter, 4K@30 or 4K@60. If I setup for 4K@60 and wait for a couple of minutes on boot, 4K@30 will eventually show up with my Dell monitor. However, if I setup for 4K@30, it does not.

I do not even get the rainbow if I setup for 4K@60 with kms, and the kernel is not even loaded at that point. In my mind, kms or fkms should not matter at that point… but it seems to. The performance gain with kms is minimal over fkms, nowhere near worth the effort spent. I switched to back to fkms a little while back with 4K, so I guess that is how I lost contact with these issues.

And now with these DRM errors showing up even at 1080p… just wow, I give up on kms.

As I understand it from memory reading in the past is fkms uses firmware the pi foundation provides for the monitors and kms bypasses their firmware and uses what the kernel and mesa provides. I know here I can not use my Vizio tv and boot with kms but there is no issue booting with kms on an old Gateway computer monitor I have.

At 1080p with kms, no trouble booting and mostly no trouble once booted, with x11. An occasional drm error is about it, and it is a recent development. However, with wayland, the drm errors are so frequent, it is not usable.

And now I am concerned about the fkms errors being reported with 4K. With fkms, I thought I had a safe space. :smiley:

It seems to me this is not a single issue, but several issues, all intermingled. My guess is, this is going to take a while before this is resolved.

In trying to put my system back into a working state… when lightdm starts, I have 4K@60 according to my monitor. But once I login with Plasma on x11, it switches to 4K@30. This could have been they way I have been running for a while now, not sure. I do not normally check the monitor scan rate. No clue why it would start at 60Hz, only to fall back to 30Hz, as both lightdm and plasma are on x11 and should find the same driver/screen/monitor setup.

Edit: Ah, just Plasma being helpful, Display Configuration has the 60Hz option.

Today’s arm-testing updates did not do much to help the situation. I removed vulkan-broadcom and vulkan-mesa-layers since these are of no use to me. And upon reboot, I then had to remove the overclocking of the gpu or I would get a black screen on reboot with fkms. Plasma with kms is still bad.

Note: This is with kms + plasma + wayland + 1080p monitor

Further observation of the drm hanging issue, specifically the mouse movements. It not just movement, it is when the mouse moves over compositor effects, ie: window shadows. Mouse movements within a window do not prompt the drm errors.

I also find the number of drm errors are significantly decreased when gpu overclocking is disabled. And rather than drm errors each time, now I usually see “colored bands of static” type artifacts instead, when the mouse cursor crosses shadows.

Edit: It seems KDE has removed the check box to disable the compositor.

Looks like there is a Support the 4k @ 60Hz modes PR submitted:

Support the 4k @ 60Hz modes

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.