Bug 1224342

Created attachment 874919 [details]
journalctl -r as user. Output from current session.

Operating System: openSUSE Tumbleweed 20240514
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.0
Kernel Version: 6.8.9-1-default (64-bit)
Graphics Platform: X11
Processors: 12 × AMD Ryzen 5 5600G with Radeon Graphics
Memory: 62.2 GiB of RAM
Graphics Processor: AMD Radeon Pro W5500
Product Name: X570 Phantom Gaming 4


currently installing all mesa info and debugpackages in the hope of a more meaningful output.

So this issue does not happen with original TW version? Package sources should be 100% the same, just that codecs are enabled during build for radeon drivers. Probably the reason why you're using it.

Mesa.spec
[...]
# Possible patent issues, see
# https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15258
# for more details
%if 0%{?BUILD_ORIG}
%define video_codecs 1
%else
%define video_codecs 0
%endif
[...]
%if %{video_codecs}
            -Dvideo-codecs=all \
%endif
[...]

Stack points to radeonsi_dri.so

I would have expected only differences in behaviour in

radeonsi_drv_video.so (libva driver/VAAPI)
libvdpau_radeonsi.so
libvulkan_radeon.so

(In reply to Stefan Dirsch from comment #3)
> So this issue does not happen with original TW version? Package sources
> should be 100% the same, just that codecs are enabled during build for
> radeon drivers. Probably the reason why you're using it.
> 
> Mesa.spec
> [...]
> # Possible patent issues, see
> # https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15258
> # for more details
> %if 0%{?BUILD_ORIG}
> %define video_codecs 1
> %else
> %define video_codecs 0
> %endif
> [...]
> %if %{video_codecs}
>             -Dvideo-codecs=all \
> %endif
> [...]

Yes, using this version due to the very same reasons that you use some codecs. (Running besides other a dvb-t/dvb-s installation on this system, hence the issue arises with codecs (less than years ago). 
I will still need some time because I requested the system to download the related debug-info files (please advise if I should also install debug-source) so I can give you maybe a better output. BTW, this is multiple times in a row in the journal. Seems however all identical.
Once the downloads finish (I am on a proud 100mb/s dsl copper line) I will then install the "original cast version" of TW, then I will report back on the result here. Thank you for your patience. 

P.S. I thank you for this ultrafast reply, notice and very appreciated.

Yes, installing also debug-source packages would be useful. Then we could see where the crash exactly happens.

But take your time!

Created attachment 874929 [details]
first coredump (with all debug-info and src installed) to appear in log

there will be two output the first dump and the second given in two attachments, this is the first.

Created attachment 874930 [details]
second dump

Now the problem arises when the second user opens a session. The first user opens and works. When opening a second one and switching to it the crash arrives. Plasma does not start, background picture is not loaded, programs have to be started in cli (I had yakuake as dropdown installed, made it easy). Taskbar etc, desktop all not functional. 

I noticed also that firefox during the last session crashed very often, but currently it did not happen, so I am unsure if it is related. I will now try to install the mesa from TW (without codecs activated) and report back if it crashes as well or not. 
(will take a while but I hope you are patient. ;-)

Created attachment 874931 [details]
the current Firefox crashes too, I think it is related so I post the output and the CLI feedback.

the feedback you get during the crash seems mesa related and is: 
entropy@silversurfer:~> firefox
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
kf.i18n: KLocalizedString: Using an empty domain, fix the code. msgid: "Mozilla Firefox" msgid_plural: "" msgctxt: ""
ExceptionHandler::GenerateDump cloned child 19131
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
Failed to open curl lib from binary, use libcurl.so instead
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Errore di bus (core dump creato)

(In reply to Stakanov Schufter from comment #10)
and yes, all this happens only in the user that is opened as "second session", if you open it as first one it does not do it.

I have now installed all mesa from TW, but the system is very unstable when a second user is opened with plenty coredump, firefox does, but at least opens, the kmail crashes with coredump, plasmashell gives coredump. 
So the second user starts now, but soon after opening firefox the coredump begins, a few times plasma can recover from it but finally screens remain blacked and Plasma goes down.

Created attachment 874934 [details]
numerous crashes as soon as the second user uses firefox (and also during startup of the second user)

important to know, this output was with a system "only Tumbleweed, no packman at all, so I will change the title accordingly).

Hmm. So now you changed the issue from having issues with a single user/multi monitor setup with Packman-Mesa to one with having logged in various users in separate sessions with regular Mesa of TW? Honestly I'm not happy with that.

I asked you to test if you could reproduce the original issue with regular TW Mesa.

(In reply to Stefan Dirsch from comment #14)
> Hmm. So now you changed the issue from having issues with a single
> user/multi monitor setup with Packman-Mesa to one with having logged in
> various users in separate sessions with regular Mesa of TW? Honestly I'm not
> happy with that.

Me neither, as being previously affected by Mesa bug on Radeon, I am now extremely carefull before I upgrade. Being a multi monitor user this caught my attention but now I am not sure if this is a multi monitor or multi user issue. 

I second Stefans sentiment of not being happy. What is the real issue here multi monitor or multi user?

(In reply to Stefan Dirsch from comment #15)
> I asked you to test if you could reproduce the original issue with regular
> TW Mesa.

Please be patient as I will be patient on this sentence too. 
Let us determine one thing: 
I have a problem described in this bug. 
I have it when the updates of PM were applied. 
I followed your request and installed the original Mesa Drivers from Tumbleweed. The issue was as described. So, I did NOT change the issue in a multi user from a multimonitor system but I did apply what you asked for. Not being sure that the I completely eliminated all PM related stuff, I did a complete deactivation of all Packman repos, and did a zypper dup --allow vendor change. 
Now with the system completely guaranteed in the new asset, while before it was already impossible to work with one user(with the Packman drivers), here we have that I write you from a "one user open" session, that allows me to use firefox. And it displays the background and the system is usable and can be shut down. 

Now if I open a second user, I will experience already a part of crashes. But still it seems usable. (I did not try for how long). Once I do open Firefox in this user, to e.g. post the output of the journal, then the firefox enters in a loop of crashes were the crash repreats constantly. Plasma crashes too, apparently for what I understood even akonadi crashes (I think I have seen the core dump) and the whole system becomes unresponsive to the request of closing this user or restarting / rebooting. But also the first original user now is haunted by the crash of firefox and proves to be unable to shutdown/reboot. 

So then you have to go Alt+CTRl+F1 and do a ctrl+alt+canc or login as root and reboot forcibly with shutdown -r now. 

Please note that I do not "change" anything but I do simply describe a reproducible behaviour, in a machine prepared according your indications and in the settings you have as of above. 

It comes now naturally to ask: is this user home maybe "compromised" by some crash or file error. Well no, I can exclude this, because if you choose user A, then logout then login user B, the new user will work. If you log out and then login in as A, even A will work. But if in any combination you work with two users open in X (I did not try in Wayland, can if you deem useful of course)) and perform actions like opening the browser in any of these users this will compromise the whole system behaviour like described. 

So: with Packman no show even with one user and right from login, with crashing monitors (in random order, that is monitor 1 goes dark, returns, monitor3 goes then returns etc. until finally all is gone and the usage can be done only via CLI and you cannot logout or shutdown.

With pure TW (no codecs at all) we have the last attachment and the behaviour as explained. 

Please not that I do not change things here intentionally or try to raise attention or whatever. I have a problem, I follow your indications and tell you the outcome. Fair enough?

(In reply to Togan Muftuoglu from comment #16)
> (In reply to Stefan Dirsch from comment #14)
> > Hmm. So now you changed the issue from having issues with a single
> > user/multi monitor setup with Packman-Mesa to one with having logged in
> > various users in separate sessions with regular Mesa of TW? Honestly I'm not
> > happy with that.
> 
> Me neither, as being previously affected by Mesa bug on Radeon, I am now
> extremely carefull before I upgrade. Being a multi monitor user this caught
> my attention but now I am not sure if this is a multi monitor or multi user
> issue. 
> 
> I second Stefans sentiment of not being happy. What is the real issue here
> multi monitor or multi user?

well, this is what I do not understand. I am found out that it is triggered now(!) by having two users open but that is now that I have eliminated the packman files. 
So with packman it was an issue already with one user. With TW pure, it is triggered when you open a second user contemporarily, otherwise the session remain stable. 
So how would you define it? Multi monitor or multi user?

Ok. Understood.

Not sure how reliably hardware-accelerated GL should work nowadays when being run in parallel by different users accessing the same GPU. I haven't tried this for years now. I thought it would not work at all. I'm wondering if this worked for you before or it if is a regression.

For now I would stay with TW Mesa and use a single-user setup. Yesterday I updated mesa to 24.0.7. It may include fixes for regressions.

(In reply to Stefan Dirsch from comment #19)
> Ok. Understood.
> 
> Not sure how reliably hardware-accelerated GL should work nowadays when
> being run in parallel by different users accessing the same GPU. I haven't
> tried this for years now. I thought it would not work at all. I'm wondering
> if this worked for you before or it if is a regression.
> 
> For now I would stay with TW Mesa and use a single-user setup. Yesterday I
> updated mesa to 24.0.7. It may include fixes for regressions.

I am not sure if I expressed myself right. I am not using the hardware with two users in the same moment. I have to user sessions open and I am shifting from one to the other (when needed) with Ctrl+Alt+Fn

In these conditions with the last mesa updates the desktops are stable (as long as you do not use ANY browser!) 
Using FF in this setting = plasma is gone, black background, not logout. 
Using Opera: getting a white window and the program crashes in loop, that is - crash, white window - crash, white window etc. Seems a blinking ad. 
When using a one user session no issues. And of course plasma does not work. 
I will try today with Vivaldi... one never knows.

Created attachment 874955 [details]
Mesa crashes multiple times without user interaction right after login.

This is the situation now with 24.0.7
The system is much more instable, when switching to a session (opening it) of a second user, the crashes are multiple at once, no interaction necessary, seems a disco from the 70th really. 
I put the output of these multiple dumps in the journal that produced in less than 1 minute of "usage". 
Definitely just a "one user system" now.

@stefan

Based upon your change of the bug title, I assume this happens not with two monitor setups but two Xsessions are running. 

So a single user with two monitors shouldn't be affected.

Am I understanding this correctly, or missing something?

@stakanov

If you have one session only and only one session does it crash also?


Thanks to both in advance

(In reply to Togan Muftuoglu from comment #22)
> @stefan
> 
> Based upon your change of the bug title, I assume this happens not with two
> monitor setups but two Xsessions are running. 
> 
> So a single user with two monitors shouldn't be affected.
> 
> Am I understanding this correctly, or missing something?

This is my understanding, yes.

Looks like there are kernel related issues as well

https://www.reddit.com/r/openSUSE/comments/1cu63ye/opensuse_tw_kernel_688_more_stable_than_689/

https://gitlab.freedesktop.org/drm/amd/-/issues/3343

@stakanov did you try with 6.8.8 kernels? Is the issue still present if you use 6.8.8 kernel?

(In reply to Togan Muftuoglu from comment #22)
> @stefan
> 
> Based upon your change of the bug title, I assume this happens not with two
> monitor setups but two Xsessions are running. 
> 
> So a single user with two monitors shouldn't be affected.
> 
> Am I understanding this correctly, or missing something?
> 
> @stakanov
> 
> If you have one session only and only one session does it crash also?
> 
> 
> Thanks to both in advance

My monitor is a three monitor system with the main monitor (central) on DP and the two others on HDMI with DP adapter. Until recently that worked fine, workspace is "connected" thus the mouse pointer flows from on to the other monitor. 
I am opening in this condition one single user: no problem, not even when using FF. 
I am opening (with the first user open and using firefox) a new users session via "switch user", the news session will now go down with flicker and crashes (as the attachment posted). 
When I am loging out completely the first user and only then I open the other user, no problem too, works as expected. 
I am having currently:entropy@silversurfer:~> uname -a
Linux silversurfer.fritz.box 6.8.9-1-default #1 SMP PREEMPT_DYNAMIC Fri May 10 08:51:14 UTC 2024 (d3445e0) x86_64 x86_64 x86_64 GNU/Linux

I can try to go back to 6.8.8 (where I had no issues afaik). 
However for tasks I have to do tonight I can do this only very late or tomorrow, so you will have the answer on your 6.8.8 question tomorrow. 
Hope that helps. 

(Thought about to rename the bug in highlander problem, (since there can be only one ;-) ) SCNR

O.K.there seems to be no way to install the kernel 6.8.8 (it is there but the system forces in yast automatically the higher kernel version). If you have an idea how to force the kernel downgrade I am taker. 

Currently it is not even possible to taboo the higher kernel version (I think because of the firmware installed?). 
Waiting for some input.

I don't know whether this helps, but here you can find a kernel 6.8.7.

https://download.opensuse.org/history/20240425/tumbleweed/repo/oss/x86_64/

I suggest to download kernel-default* packgages and install them manually via

 rpm -hiv ...

if YaST/zypper cannot be used.

entropy@silversurfer:~> uname -a
Linux silversurfer.fritz.box 6.8.8-1-default #1 SMP PREEMPT_DYNAMIC Mon Apr 29 05:24:46 UTC 2024 (5cd3298) x86_64 x86_64 x86_64 GNU/Linux


Ich habe jetzt gesehen das ich beim Booten auch 6.8.8-1-default auswählen kann. Uns siehe da, alles funktioniert, habe zwei user offen, alle Browser der Welt, benutzte Opera, FF, auf beiden, keine Crash-Orgie und keine Probleme.

(In reply to Stakanov Schufter from comment #28)
> entropy@silversurfer:~> uname -a
> Linux silversurfer.fritz.box 6.8.8-1-default #1 SMP PREEMPT_DYNAMIC Mon Apr
> 29 05:24:46 UTC 2024 (5cd3298) x86_64 x86_64 x86_64 GNU/Linux
> 
> 
> Ich habe jetzt gesehen das ich beim Booten auch 6.8.8-1-default auswählen
> kann. Uns siehe da, alles funktioniert, habe zwei user offen, alle Browser
> der Welt, benutzte Opera, FF, auf beiden, keine Crash-Orgie und keine
> Probleme.

Sorry, that should have been in English. I have notice that I can select during boot also 6.8.8-1-default and surprise surprise, all works O.K., two users open contemporarily using firefox, opera, no crash-orgy, no problems.

(In reply to Stakanov Schufter from comment #29)
> (In reply to Stakanov Schufter from comment #28)
> > entropy@silversurfer:~> uname -a
> > Linux silversurfer.fritz.box 6.8.8-1-default #1 SMP PREEMPT_DYNAMIC Mon Apr
> > 29 05:24:46 UTC 2024 (5cd3298) x86_64 x86_64 x86_64 GNU/Linux
> > 
> > 
> > Ich habe jetzt gesehen das ich beim Booten auch 6.8.8-1-default auswählen
> > kann. Uns siehe da, alles funktioniert, habe zwei user offen, alle Browser
> > der Welt, benutzte Opera, FF, auf beiden, keine Crash-Orgie und keine
> > Probleme.
> 
> Sorry, that should have been in English. I have notice that I can select
> during boot also 6.8.8-1-default and surprise surprise, all works O.K., two
> users open contemporarily using firefox, opera, no crash-orgy, no problems.

So looks like a kernel regression rather than Mesa issue to me. Of course Stefan's perspective would be more usefull than mine.

(In reply to Togan Muftuoglu from comment #30)
> (In reply to Stakanov Schufter from comment #29)
> > (In reply to Stakanov Schufter from comment #28)
> > > entropy@silversurfer:~> uname -a
> > > Linux silversurfer.fritz.box 6.8.8-1-default #1 SMP PREEMPT_DYNAMIC Mon Apr
> > > 29 05:24:46 UTC 2024 (5cd3298) x86_64 x86_64 x86_64 GNU/Linux
> > > 
> > > 
> > > Ich habe jetzt gesehen das ich beim Booten auch 6.8.8-1-default auswählen
> > > kann. Uns siehe da, alles funktioniert, habe zwei user offen, alle Browser
> > > der Welt, benutzte Opera, FF, auf beiden, keine Crash-Orgie und keine
> > > Probleme.
> > 
> > Sorry, that should have been in English. I have notice that I can select
> > during boot also 6.8.8-1-default and surprise surprise, all works O.K., two
> > users open contemporarily using firefox, opera, no crash-orgy, no problems.
> 
> So looks like a kernel regression rather than Mesa issue to me. Of course
> Stefan's perspective would be more usefull than mine.

Thank you for the time invested in this. Very appreciated. Sorry for not having caught the reason earlier.

(In reply to Stakanov Schufter from comment #31)
> (In reply to Togan Muftuoglu from comment #30)
> > (In reply to Stakanov Schufter from comment #29)
> > > (In reply to Stakanov Schufter from comment #28)
> > > > entropy@silversurfer:~> uname -a
> > > > Linux silversurfer.fritz.box 6.8.8-1-default #1 SMP PREEMPT_DYNAMIC Mon Apr
> > > > 29 05:24:46 UTC 2024 (5cd3298) x86_64 x86_64 x86_64 GNU/Linux
> > > > 
> > > > 
> > > > Ich habe jetzt gesehen das ich beim Booten auch 6.8.8-1-default auswählen
> > > > kann. Uns siehe da, alles funktioniert, habe zwei user offen, alle Browser
> > > > der Welt, benutzte Opera, FF, auf beiden, keine Crash-Orgie und keine
> > > > Probleme.
> > > 
> > > Sorry, that should have been in English. I have notice that I can select
> > > during boot also 6.8.8-1-default and surprise surprise, all works O.K., two
> > > users open contemporarily using firefox, opera, no crash-orgy, no problems.
> > 
> > So looks like a kernel regression rather than Mesa issue to me. Of course
> > Stefan's perspective would be more usefull than mine.
> 
> Thank you for the time invested in this. Very appreciated. Sorry for not
> having caught the reason earlier.

Well, having been hit by Mesa made me cautius. At least we all know the reason now. Let's hope kernel team would find a fix soon.

At no time it was obvious to me, that we have a kernel issue here.

TW is already moving to 6.9.x kernel, the update is on its way.
Could you try the kernel in OBS Kernel:stable repo?
  http://download.opensuse.org/repositories/Kernel:/stable/standard/

(In reply to Takashi Iwai from comment #34)
> TW is already moving to 6.9.x kernel, the update is on its way.
> Could you try the kernel in OBS Kernel:stable repo?
>   http://download.opensuse.org/repositories/Kernel:/stable/standard/

I can confirm that 

entropy@silversurfer:~> uname -a
Linux silversurfer.fritz.box 6.9.1-1.g0c0b0b5-default #1 SMP PREEMPT_DYNAMIC Fri May 17 11:59:46 UTC 2024 (0c0b0b5) x86_64 x86_64 x86_64 GNU/Linux


fixes the issue for me. So once the update is out, I will try, confirm, and then this can be closed.

(In reply to Stakanov Schufter from comment #35)
> (In reply to Takashi Iwai from comment #34)
> > TW is already moving to 6.9.x kernel, the update is on its way.
> > Could you try the kernel in OBS Kernel:stable repo?
> >   http://download.opensuse.org/repositories/Kernel:/stable/standard/
> 
> I can confirm that 
> 
> entropy@silversurfer:~> uname -a
> Linux silversurfer.fritz.box 6.9.1-1.g0c0b0b5-default #1 SMP PREEMPT_DYNAMIC
> Fri May 17 11:59:46 UTC 2024 (0c0b0b5) x86_64 x86_64 x86_64 GNU/Linux
> 
> 
> fixes the issue for me. So once the update is out, I will try, confirm, and
> then this can be closed.

There is a good thing and a bad thing. The good thing is: with the above kernel the system worked and was stable in all condition. 

The bad thing: 
Linux silversurfer.fritz.box 6.8.9-1-vanilla #1 SMP PREEMPT_DYNAMIC Fri May 10 08:51:14 UTC 2024 (d3445e0) x86_64 x86_64 x86_64 GNU/Linux
breaks the system as soon as you open a new user, so you return to the former problem. It does this no matter what, whether you have packman mesa, TW mesa installed, no difference. I tried to remove all codecs from packman but the vanilla kernel MUST be different from the aforementioned that worked. 

Now this is a good thing, because if you can compare in what they differ...you find what is wrong with certainty. Waiting for your feedback. 

P.S. during change of repo the system claimed that the working kernel had to be uninstalled because "not compatible" with the vanilla one.

As already mentioned, TW is going to update to 6.9.x soon, and 6.8.x is already discontinued.  So just skip 6.8.9 and update to 6.9.1 once when available on TW.

(In reply to Takashi Iwai from comment #37)
> As already mentioned, TW is going to update to 6.9.x soon, and 6.8.x is
> already discontinued.  So just skip 6.8.9 and update to 6.9.1 once when
> available on TW.

ah, I thought it WAS already out and 6.8.9.1.1 but that was of course my error. Sorry. 
So I am going to wait. Sorry I "mis-kerneled" the situation.