Created attachment 1751574 [details] sddm-greeter coredump Description of problem: After updating to sddm-0.19.0-3.fc33, I am no longer able to login to my Plasma session if I have VMware configured to have accelerated 3D support enabled (which is the default for VMware when creating Fedora VMs). If I disable accelerated 3D support, then it falls back to LLVMpipe and everything works. Version-Release number of selected component (if applicable): 0.19.0-3.fc33 How reproducible: Always Steps to Reproduce: 1. Install Fedora 33 in VMware 2. Apply sddm-0.19.0-3.fc33 update 3. Reboot Actual results: System boots to a black screen (greeter crashes in the background) Expected results: System boots into SDDM, allowing login Additional info: ABRT refused to report this, saying server reported "invalid uReport" or some such, so I've attached a coredump to this for manual evaluation.
Filed issue upstream, just in case.
I can confirm the described behavior here.
[ 13.630969] QSGRenderThread[993]: segfault at 0 ip 0000000000000000 sp 00007f4203ffea68 error 14 in sddm-greeter[55a60778e000+14000] [ 13.630987] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. but if I start my vm with kdm , error appears every where , so I deduce the problem is not on sddm itself is in kde or Qt5
Created attachment 1757181 [details] sddm-greeter coredump on Rawhide I've added a new coredump from a Rawhide run where I have all the debuginfo installed.
Created attachment 1757182 [details] gdb backtrace output from the coredump on Rawhide I've attached the full output from gdb when attempting to get a backtrace from the coredump. From the log, the backtrace seems to indicate that this *might* be a Qt problem? (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00007ff559e5c9c6 in QGLXContext::makeCurrent (this=this@entry=0x55e8b69b80b0, surface=0x55e8b7145fb0) at qglxintegration.cpp:611 #2 0x00007ff56d584c8e in QOpenGLContext::makeCurrent (this=0x55e8b6becbf0, surface=0x55e8b69a1fc0) at kernel/qopenglcontext.cpp:992 #3 0x00007ff56e2d3a58 in QSGRenderThread::run (this=0x55e8b71b0ce0) at scenegraph/qsgthreadedrenderloop.cpp:1035 #4 0x00007ff56cf78751 in QThreadPrivate::start (arg=0x55e8b71b0ce0) at thread/qthread_unix.cpp:329 #5 0x00007ff56c608269 in start_thread (arg=0x7ff53ee28640) at pthread_create.c:473 #6 0x00007ff56cb89663 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
This is with qt5-qtbase-5.15.2-13.fc34, for reference.
Some further digging and step-by-step checking of the graphics stack has led me to identify that the culprit is Mesa. Starting from Fedora 33 GA and upgrading everything *except* mesa results in a working system. Then, stepping through the Bodhi updates, I pinpointed the update that broke everything: the update to mesa-20.3.3-3.fc33. On mesa-20.2.6-1.fc33[1], it works correctly and SDDM loads, but once updated to mesa-20.3.3-3.fc33[2], it crashes as reported. [1]: https://bodhi.fedoraproject.org/updates/FEDORA-2020-f04e9f1683 [2]: https://bodhi.fedoraproject.org/updates/FEDORA-2021-cd899639ab
This is also still happening on Mesa 21~rc2 in F34 and Rawhide. :(
(In reply to Neal Gompa from comment #7) > Some further digging and step-by-step checking of the graphics stack has led > me to identify that the culprit is Mesa. > > Starting from Fedora 33 GA and upgrading everything *except* mesa results in > a working system. > > Then, stepping through the Bodhi updates, I pinpointed the update that broke > everything: the update to mesa-20.3.3-3.fc33. > > On mesa-20.2.6-1.fc33[1], it works correctly and SDDM loads, but once > updated to mesa-20.3.3-3.fc33[2], it crashes as reported. > > [1]: https://bodhi.fedoraproject.org/updates/FEDORA-2020-f04e9f1683 > [2]: https://bodhi.fedoraproject.org/updates/FEDORA-2021-cd899639ab It seems worth exploring whether a downgrade from 20.3.3 -> 20.2.6 is even possible, and if the problem goes away after doing so. Any thoughts on such a process?
(In reply to Christopher Powell from comment #9) > (In reply to Neal Gompa from comment #7) > > Some further digging and step-by-step checking of the graphics stack has led > > me to identify that the culprit is Mesa. > > > > Starting from Fedora 33 GA and upgrading everything *except* mesa results in > > a working system. > > > > Then, stepping through the Bodhi updates, I pinpointed the update that broke > > everything: the update to mesa-20.3.3-3.fc33. > > > > On mesa-20.2.6-1.fc33[1], it works correctly and SDDM loads, but once > > updated to mesa-20.3.3-3.fc33[2], it crashes as reported. > > > > [1]: https://bodhi.fedoraproject.org/updates/FEDORA-2020-f04e9f1683 > > [2]: https://bodhi.fedoraproject.org/updates/FEDORA-2021-cd899639ab > > It seems worth exploring whether a downgrade from 20.3.3 -> 20.2.6 is even > possible, and if the problem goes away after doing so. Any thoughts on such > a process? It worked in my VMs, so it's possible. But I'd rather have this properly fixed, since it also affects Mesa 21 in Fedora 34/Rawhide...
Nice catch , I can confirm I downgrade to mesa-20.2.3-2.fc34 and 3D acceleration starts to work again
This is still happening with mesa-21~rc5. :(
FEDORA-2021-e7e5787903 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-e7e5787903
FEDORA-2021-e7e5787903 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-e7e5787903` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e7e5787903 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-e7e5787903 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.