KDE Plasma hangs after login

V1del · 2023-10-12 13:26:51

I'll merge this into the other thread momentarily...

Based on this fresher look on things. both system settings and dolphin will eventually interact with solid which will interact with udisks which will die a horrible death. Pick some other Qt application that has no relation to these things, e.g. pavucontrol-qt or whatever. Can either of you start those normally?

zord · 2023-10-12 13:48:05

V1del wrote:

Based on this fresher look on things. both system settings and dolphin will eventually interact with solid which will interact with udisks which will die a horrible death. Pick some other Qt application that has no relation to these things, e.g. pavucontrol-qt or whatever. Can either of you start those normally?

Thanks for picking up this issue.

Unfortunately, I can't start any Qt apps at the moment since I don't have a desktop. The view in ctrl+alt+F2 is just a frozen image of whatever was on the screen previously. Trying anyway gives the same error as when I tried qtdiag-qt5 earlier, unsurprisingly since that seems to mean that Qt isn't working at the moment.

V1del · 2023-10-12 13:51:59

if you try that from the tty you get the error because you are in a tty and not in a graphical session.

When you are in the broken plasma session, can you use krunner (alt+F2) to invoke other programs (e.g. a terminal/konsole to run qt5-diag in)

seth · 2023-10-12 14:06:30

Did you try

swiotlb=force

- https://wiki.archlinux.org/title/Kernel_parameters

zord · 2023-10-12 14:29:06

I seem to not be able to even get into a broken plasma session now. Several tries all lead to the black screen.
Setting the

swiotlb=force

kernel parameter seemed to lead to multiple attempts at starting the desktop, the screen switching between the black screen and the one always seen at ctrl+alt+F1. After a minute or so it stopped at the login screen tty2. When looking in a task manager like btop I see that there are no kde processes running, which they did in my earlier attempts. Here is the journalctl from this boot https://0x0.st/H49X.txt.

Alarg · 2023-10-12 14:35:36

V1del wrote:

Based on this fresher look on things. both system settings and dolphin will eventually interact with solid which will interact with udisks which will die a horrible death. Pick some other Qt application that has no relation to these things, e.g. pavucontrol-qt or whatever. Can either of you start those normally?

It won't do. I can't start krunner while the desktop is frozen, only when it unfreezes. If I wait, krunner pops up but is unresponsive until the desktop unfreezes.

EDIT: I seem to have 'stack smashing detected' the same way that it's written in bug report. Will try downgrading the package and seeing how it works out.

Last edited by Alarg (2023-10-12 14:38:12)

seth · 2023-10-12 14:40:06

SDDM fails because

Oct 12 16:14:41 teething-problems kernel: NVRM: 0000:01:00.0: Failed to create a DMA mapping!
Oct 12 16:14:41 teething-problems kernel: NVRM: GPU 0000:01:00.0: Failed to copy vbios to system memory.
Oct 12 16:14:41 teething-problems kernel: NVRM: GPU 0000:01:00.0: RmInitAdapter failed! (0x30:0xffff:976)
Oct 12 16:14:41 teething-problems kernel: NVRM: GPU 0000:01:00.0: rm_init_adapter failed, device minor number 0
Oct 12 16:14:48 teething-problems kernel: NVRM: GPU 0000:01:00.0: RmInitAdapter failed! (0x25:0x65:1470)
Oct 12 16:14:48 teething-problems kernel: NVRM: GPU 0000:01:00.0: rm_init_adapter failed, device minor number 0

nvidia likes swiotlb even less than nouveau.

Until https://bugs.archlinux.org/task/79760 is fixed, downgrading udisks and libblockdev seems the only viable mitigation

Alarg · 2023-10-12 15:06:06

Downgrading both indeed seem to fix this issue! Thanks for your help everyone!

zord · 2023-10-12 16:30:03

No such luck for me I'm afraid. After downgrading libblockdev to 2.28-4 and udisks2 to 2.9.4-4 and rebooting (twice), I am still seeing the same situation.
The current log https://0x0.st/H4pm.txt shows no coredump and no stack smashing, so those specific problems seem to have been solved at least.

The only errors left that I have any idea about are those like

Oct 12 18:12:25 teething-problems kernel: i915 0000:00:02.0: [drm] *ERROR* Failed to probe lspcon
Oct 12 18:12:25 teething-problems kernel: i915 0000:00:02.0: [drm] *ERROR* LSPCON init failed on port D

I have set a kernel parameter for enabling nvidia DRM. The result of

cat /proc/cmdline

is

BOOT_IMAGE=/vmlinuz-linux root=UUID=a969492a-874b-4996-8fd7-6a5035989e7b rw loglevel=3 quiet nvidia_drm.modeset=1

but I have had it like that since the beginning so unless something changed in the Nvidia drivers I don't know if this is relevant.

V1del · 2023-10-12 16:57:14

You have a problem in i915. Post your xorg.log/try removing xf86-video-intel if you have that installed.

seth · 2023-10-12 19:53:19

According to the journal kwin_x11 runs on the nvidia chip, but

Oct 12 18:13:16 teething-problems dropbox[1352]: libGL error: dlopen /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so failed (/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
Oct 12 18:13:16 teething-problems dropbox[1352]: libGL error: dlopen ${ORIGIN}/dri/swrast_dri.so failed (${ORIGIN}/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
Oct 12 18:13:16 teething-problems dropbox[1352]: libGL error: dlopen /usr/lib/dri/swrast_dri.so failed (/usr/lib/libdrm_intel.so.1: undefined symbol: drmCloseBufferHandle)
Oct 12 18:13:16 teething-problems dropbox[1352]: libGL error: unable to load driver: swrast_dri.so
Oct 12 18:13:16 teething-problems dropbox[1352]: libGL error: failed to load driver: swrast

smells a lot like xf86-video-intel.

The Xorg log might still be interesting - primarily to see the used drivers, where the outputs are attached when whether there's maybe an nvidia-settings generated xorg conf…

zord · 2023-10-13 06:55:03

Thank you both for you efforts so far. Here is my Xorg log: https://0x0.st/H4Wv.txt

Next, I removed xf86-video-intel, which didn't seem to make a difference (same frozen black screen on startup). Here are the journalctl https://0x0.st/H4Ww.txt and Xorg logs https://0x0.st/H4Wx.txt for the boot without xf86-video-intel.

There was an nvidia-settings generated xorg.conf. Interestingly, when I simply removed this config file, the desktop loaded (yay), but the original problem with certain apps appearing as empty frames remained. I tried launching pavucontrol-qt and can report that behaves in the same broken way, and there is no error message in the terminal it was launched from. For completeness, here are the journal https://0x0.st/H4WY.txt and Xorg https://0x0.st/H4Wg.txt logs from the boot without the xorg.conf.

seth · 2023-10-13 07:07:17

Interestingly, when I simply removed this config file, the desktop loaded (yay)

Because there're no outputs attached to the nvidia chip and you require the IGP in some capacity to display anything.

the original problem with certain apps appearing as empty frames remained

What original issue? What "certain apps"? Is this somehow audio specific?

zord · 2023-10-13 11:46:49

seth wrote:

What original issue? What "certain apps"? Is this somehow audio specific?

Apologies for the confusion. The issue I was referring to is that certain apps don't start properly, they remain as transparent frames. Examples of apps affected in this way include System Settings, Dolphin, and pavucontrol-qt. Other apps like Firefox and Alacritty work as expected. I brought up pavucontrol-qt specifically as V1del suggested it as a Qt app that does not interact with udisks.

Also, a clarification. I have not used

nvidia-settings

My xorg.conf was generated by running

nvidia-xconfig

Based on the wiki it seems like the distinction matters.

seth · 2023-10-13 12:54:26

Based on the wiki it seems like the distinction matters.

No, doesn't. Same thing under the hood.

What do those windows look like when you suspend the compositor? (SHIFT+Alt+F12)
Please run "xwininfo", click one of the windows and post the output - ideally on a new thread as that's off topic for even the symptoms of this one.

zord · 2023-10-13 14:52:07

I started a new thread in https://bbs.archlinux.org/viewtopic.php?id=289524, but for anyone who finds this thread in a future search; suspending the compositor makes all apps behave as expected again. This is still the case even if the compositor is resumed but the problem reappears on every boot.
Thanks a ton for your help so far everyone. I guess this topic should be marked as solved now.

Arch Linux

#26 2023-10-12 13:26:51

Re: KDE Plasma hangs after login

#27 2023-10-12 13:48:05

Re: KDE Plasma hangs after login

#28 2023-10-12 13:51:59

Re: KDE Plasma hangs after login

#29 2023-10-12 14:06:30

Re: KDE Plasma hangs after login

#30 2023-10-12 14:29:06

Re: KDE Plasma hangs after login

#31 2023-10-12 14:35:36

Re: KDE Plasma hangs after login

#32 2023-10-12 14:40:06

Re: KDE Plasma hangs after login

#33 2023-10-12 15:06:06

Re: KDE Plasma hangs after login

#34 2023-10-12 16:30:03

Re: KDE Plasma hangs after login

#35 2023-10-12 16:57:14

Re: KDE Plasma hangs after login

#36 2023-10-12 19:53:19

Re: KDE Plasma hangs after login

#37 2023-10-13 06:55:03

Re: KDE Plasma hangs after login

#38 2023-10-13 07:07:17

Re: KDE Plasma hangs after login

#39 2023-10-13 11:46:49

Re: KDE Plasma hangs after login

#40 2023-10-13 12:54:26

Re: KDE Plasma hangs after login

#41 2023-10-13 14:52:07

Re: KDE Plasma hangs after login

Board footer