Description of problem:
I opened Totem and it showed a list of video files that could be played. I clicked on one of them to start playing, it played just a couple of frames (~ 1 second) and then it crashed immediately.
Any attempt to play a video (no matter what format) lead to the same result.
Version-Release number of selected component:
cmdline: /usr/bin/totem --gapplication-service
dso_list: /usr/bin/totem totem-1:43.beta-1.fc37.x86_64 (Fedora Project) 1661077387
runlevel: N 5
Potential duplicate: bug 1937212
Created attachment 1908902 [details]
Created attachment 1908903 [details]
Created attachment 1908904 [details]
Created attachment 1908905 [details]
Created attachment 1908906 [details]
Created attachment 1908907 [details]
Created attachment 1908908 [details]
Created attachment 1908909 [details]
Created attachment 1908910 [details]
Created attachment 1908911 [details]
Proposed as a Blocker for 37-final by Fedora user lruzicka using the blocker tracking app because:
Gnome Videos do not work, which violates the Basic Functionality Criterion.
Also proposing as a Beta FE - Totem is on the live images, and we can't fix those with an update.
+5 in https://pagure.io/fedora-qa/blocker-review/issue/883 , marking accepted Beta FE.
Assigning to X11 nouveau driver as that's the best way to get the right folks CC:ed on driver specific problems.
Would be nice to know if the problem also happens with `gtk3-demo`'s "OpenGL Area" test, or with the versions of totem on Flathub, whether the stable release:
or the beta version:
*** Bug 2123201 has been marked as a duplicate of this bug. ***
*** Bug 2119921 has been marked as a duplicate of this bug. ***
*** Bug 2119192 has been marked as a duplicate of this bug. ***
(In reply to Adam Williamson from comment #13)
> +5 in https://pagure.io/fedora-qa/blocker-review/issue/883 , marking
> accepted Beta FE.
Also happens in F36 FWIW.
Discussed during 2022-09-06 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2022-09-06/f37-blocker-review.2022-09-06-16.00.html . Accepted as a Final blocker as a violation of the "basic functionality" criterion in the case that you have affected NVIDIA hardware.
We did note Bastien's point that this affects F36 too, and there's a general feeling that if this turns out to be technically difficult to fix, we'll be open to waiving it as a blocker later. But for now it's on the list.
Could we get some more details about the hardware in use and maybe even a kernel log (preferably after totem crashed)?
I'll try to trigger this issue on my end here.
seems like it's nouveau's broken multithreading support, which is already fixed upstream: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10752
But given the size of that Merge Request I am not so sure I feel comfortable enough letting Fedora 36 users use it and I'd prefer some more/longer regression testing, especially on very old hardware (pre GeForce 8000 series).
It might be reasonable enough to pick those patches for Fedora 37. They should get in normally via an upgrade to mesa-22.3.
*** Bug 2115478 has been marked as a duplicate of this bug. ***
The bug reports in F36 seem fairly recent though:
The oldest one is from August. Is this a regression in Fedora 36?
(In reply to Bastien Nocera from comment #23)
> The bug reports in F36 seem fairly recent though:
> The oldest one is from August. Is this a regression in Fedora 36?
don't think so. Multithreading was always a hit or miss in Nouveau, but fixing it wasn't trivial. Now that it's merged I expect quite a lot of bugs to get resolved after the fix reaches users. Though "Multithreading" here means using using multiple OpenGL contexts.
Normally I'd like to get those patches backported to fix bugs in older releases as well, but given it affects all Nvidia GPUs and the fix is quite huge overall I'd like to wait some time to make sure there are no severe regressions coming out of it.
So, this is currently an F37 Final blocker, which means we do need the multithreading stuff backported. Pete seems to be building mesa lately, so CCing him. Can we please get this taken care of? Or if you don't think it's a good idea, please say so and we can re-consider blocker status?
(In reply to Adam Williamson from comment #25)
> So, this is currently an F37 Final blocker, which means we do need the
> multithreading stuff backported. Pete seems to be building mesa lately, so
> CCing him. Can we please get this taken care of? Or if you don't think it's
> a good idea, please say so and we can re-consider blocker status?
For Fedora 37 it's probably fine as we still got some time left until the release and people could complain if they are bugs. Upstream is pretty quiet so I am getting more confident here. The Merge Request should apply pretty cleanly on top of mesa-22.2, but if there are any issues I am here to help out.
And in case there are regressions you know who to ping.
Hi Adam, thanks for adding me to CC.
I am not sure I fully understand what is going on here: Is Karol saying that it is too risky to ship in other distros (upstream 22.2 branch), but is OK for Fedora? I don't understand the logic here.
I am fine with backporting all this work but I don't want to do it myself. Karol, can you look into doing the backport downstream if you don't want to do it upstream? You could do a PR or ask ajax to add you to mesa's committers list or maybe both. Thanks!
(In reply to Pete Walter from comment #27)
> Hi Adam, thanks for adding me to CC.
> I am not sure I fully understand what is going on here: Is Karol saying that
> it is too risky to ship in other distros (upstream 22.2 branch), but is OK
> for Fedora? I don't understand the logic here.
> I am fine with backporting all this work but I don't want to do it myself.
> Karol, can you look into doing the backport downstream if you don't want to
> do it upstream? You could do a PR or ask ajax to add you to mesa's
> committers list or maybe both. Thanks!
I am fine with doing the backport. I just don't want to make the decision. People should be aware, that this MR changes the entire nouveau mesa driver and I'd prefer to get more testing before I can be confident enough about those changes.
It's not up to me to decide whether Fedora 37 is a place where we get more heavy testing with those changes or not.
Right, I don't want to be the one deciding it either :)
FEDORA-2022-bb8169c509 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-bb8169c509
Karol, I see you pushed the backport to git but have not done a built yet. I am doing a mesa build for an unrelated fix so I am going to include your backport as well.
FEDORA-2022-bb8169c509 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.
FEDORA-2022-fba57a21ae has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-fba57a21ae
Re-opening as this is filed against 37.
FEDORA-2022-fba57a21ae has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-fba57a21ae`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-fba57a21ae
See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I can confirm that the above build works for me -> I can play videos normally.
FEDORA-2022-fba57a21ae has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.