Bug 1921523
| Summary: | sddm-greeter crashes in VMware Fusion or VMware Workstation when hypervisor 3D acceleration is enabled | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Neal Gompa <ngompa13> | ||||||||
| Component: | mesa | Assignee: | Adam Jackson <ajax> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 33 | CC: | ajax, aleixpol, bskeggs, caillon+fedoraproject, cpowell, igor.raits, jglisse, jgrulich, kde-sig, lyude, me, m, nixuser, pierluigi.fiorini, rclark, rdieter, rhughes, rstrode, sergio, tstellar | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | mesa-20.3.4-2.fc33 | Doc Type: | If docs needed, set a value | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2021-02-26 01:08:53 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
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. |
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.