Note: the component is a guess for now, I just want to get this bug filed for the Go/No-Go meeting, will investigate more soon. If you boot a 32-bit Fedora 23 Workstation live image - this has been happening ever since we started testing 32-bit, so might well be from F22 or earlier - on a KVM with the CPU model set to 'qemu32' and all other settings default (i.e. QXL/SPICE graphics), it boots to Shell's crash screen ("Oh no! Something has gone wrong.") This doesn't happen if the CPU is set to a 64-bit model like Westmere. We don't know yet if anything like this affects real 32-bit hardware, I've asked jsedlak to test.
I can confirm that it installed on bare metal for me.
OK, not gonna bother proposing as a blocker/FE then, qemu32 is a fairly artificial scenario. Still, I'll look into it.
Happens with VGA/VNC too, so it ain't qxl.
OK, another guess - I see this in the log: gnome-session[1697]: LLVM ERROR: Do not know how to split the result of this operator! If I go to a VT and run gnome-shell from there I get this: current session already has an ibus-daemon. (gnome-shell:3298): mutter-WARNING **: STACK_OP_RAISE_ABOVE: window 0x5a01e00015 not in stack (gnome-shell:3298): Gjs-WARNING **: JS ERROR: could not get remote objects for service org.gnome.SettingsDaemon.Smartcard path /org/gnome/SettingsDaemon/Smartcard: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SettingsDaemon.Smartcard was not provided by any .service files _proxyInvoker/asyncCallback@resource:///org/gnome/gjs/modules/overrides/Gio.js:83 (gnome-shell:3298): mutter-WARNING **: STACK_OP_RAISE_ABOVE: window 0x5a01e00015 not in stack LLVM ERROR: Do not know how to split the result of this operator!
The F23 RC2 workstation i686 live image booted fine from litd-created USB media on my 32-bit P4. FWIW, the graphics adapter is a GeForce 6200 AGP card.
Here's the /proc/cpuinfo for the qemu32 CPU: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 6 model name : QEMU Virtual CPU version 2.4.0.1 stepping : 3 microcode : 0x1 cpu MHz : 3502.620 cache size : 4096 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 4 wp : yes flags : fpu de pse tsc msr pae mce cx8 apic sep pge cmov mmx fxsr sse sse2 pni x2apic popcnt hypervisor bugs : bogomips : 7005.24 clflush size : 32 cache_alignment : 32 address sizes : 36 bits physical, 32 bits virtual power management:
I tried again, both using "Basic Graphics Mode" and adding nomodeset to the boot args. Both times, I was able to get to GNOME shell without issue and the system seems to work fine under light usage.
/proc/cpuinfo from my test machine (omitted the first entry as it's pretty much identical) processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 2.60GHz stepping : 9 microcode : 0x2e cpu MHz : 2605.840 cache size : 512 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 apicid : 1 initial apicid : 1 fdiv_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts cid xtpr bugs : bogomips : 5210.88 clflush size : 64 cache_alignment : 128 address sizes : 36 bits physical, 32 bits virtual power management:
*** Bug 1192017 has been marked as a duplicate of this bug. ***
So I have bad news for you: * This is a core LLVM/llvmpipe issue, which probably affects much more than just gnome-shell. * This probably also affects real hardware without SSE2, and there there is no easy workaround. (For QEMU, you can just use --copy-host-cpu and it should work, assuming of course that the host CPU does SSE2 to begin with.) * This is a regression in LLVM 3.5, it affects Fedora ≥ 21 and RHEL ≥ 7. (According to the Debian bug, this worked fine with LLVM 3.4, and rebuilding mesa against a downgraded LLVM "fixed" it for them.) * The only workaround (other than downgrading LLVM) that Debian has to offer is to change mesa to trust the CPU flags over the CPU model, which fixes things for QEMU, but is of course no help at all for real non-SSE2 hardware.
I'm removing https://bugs.debian.org/776911 which is actually a mixed duplicate of https://bugs.debian.org/775235 (i.e. this bug) and https://bugs.debian.org/770130 (an unrelated issue with Intel GPUs).
Thanks for the info - do we have an actual *upstream* llvm bug report for this, as opposed to just a report from another distro (which is a different downstream)?
There's this one: https://llvm.org/bugs/show_bug.cgi?id=21641 which sounds like the same issue, but what's interesting is that that CPU supports sse2 according to the cpuinfo. But since Mesa takes the CPU family rather than the full list of flags, it might be that it picks a non-sse2 CPU family (something too generic like "athlon"), not sure. (There are really 2 issues at play here: The one that Mesa/llvmpipe does not always recognize SSE2 when available, and the one that LLVM errors when generating the non-SSE2 code.)
Also of interest would be whether this also affects other OpenGL applications (plasma-desktop and other QML 2 applications, OpenGL games, etc.) or whether it's something that gnome-shell specifically does that triggers the bug.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.