Hi,

During testing of the Jessie d-i RC1 CD build, I installed lots and
lots of different variations of virtual systems using KVM. All the
others worked OK given sufficient packages (access to a mirror, etc.),
but installing Gnome on i386 left me with a failure. Installation was
successful, but on boot the virtual system fails to show an X login.

Instead of seeing a gdm prompt, I get several seconds of black screen
followed by an "Oh no! Something has gone wrong." message. Rebooting
into single-user mode, I grabbed /var/log/messages (attached). This
failure is easily repeatable, every boot.

(I don't know for definite which package is to blame, but gnome-shell
looks a likely candidate from the log. Please feel free to reassign as
appropriate, obviously!)

The following system information is from the host, not the VM...

Hello,
tried to reproduce it by following steps:
- installed on amd64 host with qemu-system-i386 [1] and CD1 [2]
  and network mirror with Gnome desktop and ssh server.
- got the same message "Oh no! Something has gone wrong." (see attached picture)



Tried to debug into the issue:

# start VM without X by adding in grub "3" to the kernel parameters
# ssh into the VM

root@debian:~# apt-get update
root@debian:~# apt-get install gdb gnome-shell-dbg libglib2.0-0-dbg libgtk-3-0-dbg libllvm3.5-dbg libgl1-mesa-dri-dbg libcogl20-dbg libclutter-1.0-dbg dpkg-dev
root@debian:~# dpkg-reconfigure x11-common  # allow every user to start the X server

benutzer@debian:~$ apt-get source gnome-shell
benutzer@debian:~$ apt-get source libmutter0e
benutzer@debian:~$ apt-get source libllvm3.5
benutzer@debian:~$ X :0&
benutzer@debian:~$ export DISPLAY=:0




benutzer@debian:~$ gdb --args /usr/bin/gnome-shell --replace
(gdb) run
    ...
    Gjs-Message: JS LOG: Failed to launch ibus-daemon: Kindprozess »ibus-daemon« konnte nicht ausgeführt werden (Datei oder Verzeichnis nicht gefunden)

    (gnome-shell:1020): mutter-WARNING **: STACK_OP_RAISE_ABOVE: window 0x4f00800016 not in stack
    ...
    (gnome-shell:1020): mutter-WARNING **: STACK_OP_RAISE_ABOVE: window 0x4f00800016 not in stack
    ...
    LLVM ERROR: Do not know how to split the result of this operator!
    ...
    [Inferior 1 (process 1020) exited with code 01]




benutzer@debian:~$ gdb --args /usr/bin/gnome-shell --replace
(gdb) directory gnome-shell-3.14.2/src:mutter-3.14.2/src/core:mutter-3.14.2/src/meta:glib2.0-2.42.1/glib:llvm-toolchain-3.5-3.5/lib/Support
(gdb) set height 0
(gdb) set width 0
(gdb) b llvm::report_fatal_error
(gdb) run

Breakpoint 1, llvm::report_fatal_error (Reason=0xb2889a04 "Do not know how to split the result of this operator!\n", GenCrashDiag=true) at /build/llvm-toolchain-3.5-Ypkkuu/llvm-toolchain-3.5-3.5/lib/Support/ErrorHandling.cpp:60
60      void llvm::report_fatal_error(const char *Reason, bool GenCrashDiag) {
(gdb) bt
#0  llvm::report_fatal_error (Reason=0xb2889a04 "Do not know how to split the result of this operator!\n", GenCrashDiag=true) at /build/llvm-toolchain-3.5-Ypkkuu/llvm-toolchain-3.5-3.5/lib/Support/ErrorHandling.cpp:60
#1  0xb1b31861 in llvm::DAGTypeLegalizer::SplitVectorResult (this=0xbfffe0b0, N=0x90ff620, ResNo=0) at /build/llvm-toolchain-3.5-Ypkkuu/llvm-toolchain-3.5-3.5/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp:555
#2  0xb1b15cb3 in llvm::DAGTypeLegalizer::run (this=0xbfffe0b0) at /build/llvm-toolchain-3.5-Ypkkuu/llvm-toolchain-3.5-3.5/lib/CodeGen/SelectionDAG/LegalizeTypes.cpp:255
#3  0xb1b16476 in llvm::SelectionDAG::LegalizeTypes (this=0x8e8e7e0) at /build/llvm-toolchain-3.5-Ypkkuu/llvm-toolchain-3.5-3.5/lib/CodeGen/SelectionDAG/LegalizeTypes.cpp:1113
#4  0xb1bc58ed in llvm::SelectionDAGISel::CodeGenAndEmitDAG (this=0x8e8e678) at /build/llvm-toolchain-3.5-Ypkkuu/llvm-toolchain-3.5-3.5/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:687
#5  0xb1bc5e39 in llvm::SelectionDAGISel::SelectBasicBlock (this=0x8e8e678, Begin=..., End=..., HadTailCall=@0x8f5c74c: false) at /build/llvm-toolchain-3.5-Ypkkuu/llvm-toolchain-3.5-3.5/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:604
#6  0xb1bc8e07 in llvm::SelectionDAGISel::SelectAllBasicBlocks (this=0x8df8d30, Fn=...) at /build/llvm-toolchain-3.5-Ypkkuu/llvm-toolchain-3.5-3.5/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1239
#7  0xb1bca381 in llvm::SelectionDAGISel::runOnMachineFunction (this=0x8e8e678, mf=...) at /build/llvm-toolchain-3.5-Ypkkuu/llvm-toolchain-3.5-3.5/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:451
#8  0xb1debc3c in (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction (this=0x8e8e678, MF=...) at /build/llvm-toolchain-3.5-Ypkkuu/llvm-toolchain-3.5-3.5/lib/Target/X86/X86ISelDAGToDAG.cpp:168
#9  0xb1f4a188 in llvm::MachineFunctionPass::runOnFunction (this=0x8e8e678, F=...) at /build/llvm-toolchain-3.5-Ypkkuu/llvm-toolchain-3.5-3.5/lib/CodeGen/MachineFunctionPass.cpp:33
#10 0xb195e4b2 in llvm::FPPassManager::runOnFunction (this=0x90039d0, F=...) at /build/llvm-toolchain-3.5-Ypkkuu/llvm-toolchain-3.5-3.5/lib/IR/LegacyPassManager.cpp:1545
#11 0xb195e56f in llvm::legacy::FunctionPassManagerImpl::run (this=0x9005528, F=...) at /build/llvm-toolchain-3.5-Ypkkuu/llvm-toolchain-3.5-3.5/lib/IR/LegacyPassManager.cpp:1494
#12 0xb195e64f in llvm::legacy::FunctionPassManager::run (this=0x90023b0, F=...) at /build/llvm-toolchain-3.5-Ypkkuu/llvm-toolchain-3.5-3.5/lib/IR/LegacyPassManager.cpp:1412
#13 0xb280574d in llvm::JIT::jitTheFunctionUnlocked (this=0x9025e98, F=0x8f15798) at /build/llvm-toolchain-3.5-Ypkkuu/llvm-toolchain-3.5-3.5/lib/ExecutionEngine/JIT/JIT.cpp:493
#14 0xb2805cff in llvm::JIT::runJITOnFunctionUnlocked (this=0x9025e98, F=0x8f15798) at /build/llvm-toolchain-3.5-Ypkkuu/llvm-toolchain-3.5-3.5/lib/ExecutionEngine/JIT/JIT.cpp:472
#15 0xb2805f0f in llvm::JIT::getPointerToFunction (this=0x9025e98, F=0x8f15798) at /build/llvm-toolchain-3.5-Ypkkuu/llvm-toolchain-3.5-3.5/lib/ExecutionEngine/JIT/JIT.cpp:529
#16 0xb1832c17 in llvm::ExecutionEngine::getPointerToGlobal (this=0x9025e98, GV=0x8f15798) at /build/llvm-toolchain-3.5-Ypkkuu/llvm-toolchain-3.5-3.5/lib/ExecutionEngine/ExecutionEngine.cpp:557
#17 0xb18349a0 in LLVMGetPointerToGlobal (EE=0x9025e98, Global=0x8f15798) at /build/llvm-toolchain-3.5-Ypkkuu/llvm-toolchain-3.5-3.5/lib/ExecutionEngine/ExecutionEngineBindings.cpp:337
#18 0xb37753cf in gallivm_jit_function (gallivm=0x91760c8, func=0x8f15798) at ../../../../../src/gallium/auxiliary/gallivm/lp_bld_init.c:594
#19 0xb39df1b4 in generate_variant (lp=<optimized out>, key=<optimized out>, shader=<optimized out>) at ../../../../../../src/gallium/drivers/llvmpipe/lp_state_fs.c:2634
#20 llvmpipe_update_fs (lp=0x808c000) at ../../../../../../src/gallium/drivers/llvmpipe/lp_state_fs.c:3166
#21 0xb39d7e01 in llvmpipe_update_derived (llvmpipe=0x808c000) at ../../../../../../src/gallium/drivers/llvmpipe/lp_state_derived.c:186
#22 0xb39b6fa4 in llvmpipe_draw_vbo (pipe=0x808c000, info=0xbffff074) at ../../../../../../src/gallium/drivers/llvmpipe/lp_draw_arrays.c:70
#23 0xb36904dd in cso_draw_vbo (cso=0x81dbfd8, info=0xbffff074) at ../../../../../src/gallium/auxiliary/cso_cache/cso_context.c:1428
#24 0xb36905d0 in cso_draw_arrays_instanced (cso=0x81dbfd8, mode=6, start=0, count=4, start_instance=0, instance_count=1) at ../../../../../src/gallium/auxiliary/cso_cache/cso_context.c:1465
#25 0xb35a9536 in draw_quad (st=<optimized out>, st=<optimized out>, color=<optimized out>, num_instances=<optimized out>, z=inf, y1=<optimized out>, x1=<optimized out>, y0=<optimized out>, x0=<optimized out>) at ../../../../src/mesa/state_tracker/st_cb_clear.c:206
#26 clear_with_quad (clear_buffers=<optimized out>, ctx=<optimized out>) at ../../../../src/mesa/state_tracker/st_cb_clear.c:347
#27 st_Clear (ctx=0x8198b78, mask=18) at ../../../../src/mesa/state_tracker/st_cb_clear.c:512
#28 0xb346585d in _mesa_Clear (mask=16640) at ../../../../src/mesa/main/clear.c:226
#29 0xb65425e5 in _cogl_framebuffer_gl_clear (framebuffer=0x821c608, buffers=3, red=1, green=1, blue=1, alpha=1) at ./driver/gl/cogl-framebuffer-gl.c:977
#30 0xb658229b in _cogl_framebuffer_clear_without_flush4f (framebuffer=0x821c608, buffers=3, red=1, green=1, blue=1, alpha=1) at ./cogl-framebuffer.c:238
#31 0xb6582c13 in cogl_framebuffer_clear4f (framebuffer=0x821c608, buffers=3, red=1, green=1, blue=1, alpha=1) at ./cogl-framebuffer.c:388
#32 0xb6582f19 in cogl_framebuffer_clear (framebuffer=0x821c608, buffers=3, color=0xbffff388) at ./cogl-framebuffer.c:457
#33 0xb6552da5 in cogl_clear (color=0xbffff388, buffers=3) at ./cogl.c:94
#34 0xb6ffac7b in _clutter_stage_do_pick (stage=0x821b530, x=512, y=384, mode=(unknown: 2995296772)) at ./clutter-stage.c:1541
#35 0xb6fd1184 in _clutter_input_device_update (device=0x81d3ad0, sequence=0x0, emit_crossing=1) at ./clutter-input-device.c:886
#36 0xb6fdb4d0 in _clutter_process_event_details (context=<optimized out>, event=<optimized out>, stage=<optimized out>) at ./clutter-main.c:2558
#37 _clutter_process_event (event=0x8894e00) at ./clutter-main.c:2752
#38 0xb6ff6e42 in _clutter_stage_process_queued_events (stage=0x821b530) at ./clutter-stage.c:1082
#39 0xb6fdce2a in master_clock_process_events (master_clock=<optimized out>, stages=<optimized out>) at ./clutter-master-clock.c:372
#40 clutter_clock_dispatch (source=0x868bd80, callback=0x0, user_data=0x0) at ./clutter-master-clock.c:589
#41 0xb6c44da4 in g_main_dispatch (context=<optimized out>) at /build/glib2.0-EvFudu/glib2.0-2.42.1/./glib/gmain.c:3111
#42 g_main_context_dispatch (context=0x0) at /build/glib2.0-EvFudu/glib2.0-2.42.1/./glib/gmain.c:3710
#43 0xb6c450c9 in g_main_context_iterate (context=0x8070958, block=150325068, block@entry=1, dispatch=1, self=<optimized out>) at /build/glib2.0-EvFudu/glib2.0-2.42.1/./glib/gmain.c:3781
#44 0xb6c45479 in g_main_loop_run (loop=0x822fe88) at /build/glib2.0-EvFudu/glib2.0-2.42.1/./glib/gmain.c:3975
#45 0xb78e1b3a in meta_run () at core/main.c:473
#46 0x0804994a in main (argc=1, argv=0xbffff6f4) at main.c:463
(gdb) print N
$1 = (llvm::SDNode *) 0x90ff620
(gdb) print *N
$2 = {<llvm::FoldingSetImpl::Node> = {NextInFoldingSetBucket = 0x8e08c29}, <llvm::ilist_node<llvm::SDNode>> = {<llvm::ilist_half_node<llvm::SDNode>> = {Prev = 0x90ffff8}, Next = 0x8fb86a0}, NodeType = 38, OperandsNeedDelete = 0, HasDebugValue = 0, SubclassData = 0, NodeId = 0, OperandList = 0x90ff650, ValueList = 0x8e8eab0, UseList = 0x8e03604, NumOperands = 2, NumValues = 1, debugLoc = {LineCol = 0, ScopeIdx = 0}, IROrder = 99}

SelectionDAGNodes.h:
    class SDNode : public FoldingSetNode, public ilist_node<SDNode> {
      unsigned getOpcode()  const { return (unsigned short)NodeType; }

ISDOpcodes.h:
    namespace llvm {
      namespace ISD {
        enum NodeType {
          INTRINSIC_WO_CHAIN,

(gdb) print (int)llvm::ISD::INTRINSIC_WO_CHAIN
$5 = 38



The error message is thrown because in the switch statement
in llvm::DAGTypeLegalizer::SplitVectorResult
is no case llvm::ISD::INTRINSIC_WO_CHAIN.
This switch statement evaluates the NodeType of the variable N.

Hope this helps someone with more knowledge that area.

Kind regards,
Bernhard




[1] qemu-system-i386 --enable-kvm -m 1G -drive file=debian-jessie-i386-gnome-install.qemu.img,cache=writeback -redir tcp:2222::22 -net nic -net user -cdrom debian-jessie-DI-rc1-i386-CD-1.iso
[2] http://cdimage.debian.org/cdimage/jessie_di_rc1/i386/jigdo-cd/debian-jessie-DI-rc1-i386-CD-1.jigdo

Hello,
came across launchpad bug #1360241 [1] which discusses the same error.
There it comes from ubuntu-ui-toolkit tests.

There they did revert their mesa package to depend on llvm-3.4 instead
of llvm-3.5.

So did I and recompiled mesa to use llvm-3.4 (see attached patch).
And with these packages installed the error message was gone and the login
screen is shown and a login possible.

Going back to current jessie packages depending on llvm-3.5 lead to
getting the error message again.


Kind regards,
Bernhard

[1] https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.5/+bug/1360241




Rebuilding the mesa packages:

root@debian:/home/benutzer# apt-get install debhelper quilt pkg-config libdrm-dev libx11-dev x11proto-gl-dev libxxf86vm-dev libexpat1-dev libxfixes-dev libxdamage-dev libxext-dev libvdpau-dev autoconf automake libtool x11proto-dri2-dev x11proto-dri3-dev x11proto-present-dev libx11-xcb-dev libxcb-dri2-0-dev libxcb-glx0-dev libxcb-xfixes0-dev libxcb-dri3-dev libxcb-present-dev libxcb-randr0-dev libxcb-sync-dev libxshmfence-dev libudev-dev flex bison llvm-3.4-dev libelf-dev libwayland-dev libclang-3.4-dev libclc-dev

benutzer@debian:~$ mkdir mesa; cd mesa
benutzer@debian:~/mesa$ apt-get source libgl1-mesa-dri
benutzer@debian:~/mesa$ cd mesa-10.3.2
benutzer@debian:~/mesa/mesa-10.3.2$ patch -p1 --dry-run < ../switch-to-3.4.patch    # change llvm 3.5 to 3.4 like https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.5/+bug/1360241
benutzer@debian:~/mesa/mesa-10.3.2$ dpkg-buildpackage -b

root@debian:/home/benutzer/mesa# dpkg -i libegl1-mesa_10.3.2-1_i386.deb libegl1-mesa-drivers_10.3.2-1_i386.deb libgbm1_10.3.2-1_i386.deb libgl1-mesa-dri_10.3.2-1_i386.deb libgl1-mesa-dri-dbg_10.3.2-1_i386.deb libgl1-mesa-glx_10.3.2-1_i386.deb libglapi-mesa_10.3.2-1_i386.deb libopenvg1-mesa_10.3.2-1_i386.deb libwayland-egl1-mesa_10.3.2-1_i386.deb libxatracker2_10.3.2-1_i386.deb
    #reboot, error is gone

root@debian:/home/benutzer# apt-get install --reinstall libegl1-mesa libegl1-mesa-drivers libgbm1 libgl1-mesa-dri libgl1-mesa-dri-dbg libgl1-mesa-glx libglapi-mesa libopenvg1-mesa libwayland-egl1-mesa libxatracker2
    #reboot, error is visible again

Hello,
first a question about this merging with bug #770130 and #776911.
These bugs seem to happen on real hardware with some intel
graphics card and giving an error:
    "*ERROR* pipe A underrun".

But bug #775235 was explicitly opened by Steve McIntyre to be
run inside a i386 KVM and gives an error:
    "LLVM ERROR: Do not know how to split the result of this operator!"

Therefore I wonder if these should really be merged?

----------------

Second I searched a little bit further and came across
this patch discussion: https://freedesktop.org/patch/34445/

This is the start of the patch description by Maarten Lankhorst:
    This fixes a crash when llvmpipe tries to use sse instructions,
    but llvm detects a cpu that doesn't support them.

    Fixes for example piglit/bin/amd_seamless_cubemap_per_texture -fbo -auto
    on i386 when run inside "qemu -cpu qemu32", which would otherwise error with:
    "LLVM ERROR: Do not know how to split the result of this operator!"

Looks very similiar to our issue here.
Therefore I build a own local build of libgl1-mesa-dri and that was
successfully solving the issue inside the i386 KVM.

Unfortunately I cannot find this patch ever applied upstream.
The discussion reads (as far as I could follow) that there are
probably better ways to detect CPU features.
Also cannot say which impact it would have on every other systems.

----------------

Did some additional starts of the VM (with debian built packages) to verify:
    qemu-system-i386 -cpu core2duo               works
    qemu-system-i386 -cpu pentium2               works
    qemu-system-i386 --enable-kvm -cpu host      works
    qemu-system-i386 --enable-kvm -cpu kvm32     works
    qemu-system-i386 --enable-kvm -cpu qemu32    fails
    qemu-system-i386 --enable-kvm                fails
    qemu-system-x86_64 --enable-kvm              fails

Unfortunately "qemu32" seems to be the default.



Kind regards,
Bernhard



These steps should make a local build of libgl1-mesa-dri with the mentioned patch applied:
    mkdir mesa; cd mesa
    apt-get source libgl1-mesa-dri
    cd mesa-10.3.2/
    wget "https://freedesktop.org/patch/34445/raw/" -O debian/patches/08_gallivm_force_sse_instructions_for_llvm_3.5+.patch
    echo 08_gallivm_force_sse_instructions_for_llvm_3.5+.patch >> debian/patches/series
    # install build dependencies
    dpkg-buildpackage -b
    cd ..
    su
        dpkg -i libgl1-mesa-dri_10.3.2-1_i386.deb libgl1-mesa-dri-dbg_10.3.2-1_i386.deb

...
for the second one.

    S

...
for the second one.

    S

Just installed jessie on a Dell Latitude D505 and got the symptoms
described here (getting the "Oops" screen from attempting to log in via
gdm3, and seeing the underrun errors in the logs)

Tried rebuilding mesa with llvm-3.4 (hence the ~hands.1 version) but that
did not help.  I suppose it's possible that I somehow failed to build
the packages, but this is a clean machine, it doesn't have llvm-3.5
installed, and I just ran debuild after installing packages until the
build-depends were satisfied.

Anyway, doing this did not solve the problem.

However, I note that even with the standard packages it was possible to
get Gnome running via startx from the text console.  I also note that
installing lightdm and running from there solves the problem (only tested
with my recompiled mesa packages, but since they are exhibiting the bug
I'd guess that would also be true for the standard packages -- I'm about
to reinstall this machine so I can confirm that later if necessary)

So, in my case this bug seems to be something specific about the way
that gdm3 runs things, since other things manage to start Gnome.

Hints about where gdm3 might be logging what happened would be useful.

Hello Philip,
probably your case is more an example for the problem described in bugs
#770130 and #776911.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770130
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776911

When you rebuilt your mesa packages did you apply the patch mentioned in
message 15? And was package llvm-3.4-dev installed? If not, I would
assume that your rebuilt packages are also using llvm-3.5.

I have only tested both patches (message 15 and message 32) if they help
with the error "LLVM ERROR: Do not know how to split the result of this
operator!" inside a qemu VM.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775235#15
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775235#32

If they could help with the "underrun" error on real hardware, as in
your case, I cannot say.

Kind regards,
Bernhard

Bernhard Übelacker <bernhardu@vr-web.de> writes:

As I said, only the 3.4 versions of the llvm packages were installed, so
I'm certain that I did not use the 3.5 version.

That being the case, yes I did use the patch (well, I applied the same
trivial edits) since otherwise the Build-Deps would have insisted on 3.5

If you're pointing at the other bugs because you think they might
contain a fix for my problem, well the simplest fix for me is to avoid
gdm3.

I only posted to the bug because I saw no mention of the fact that one
can get things working by avoiding gdm3 in any of these bugs, which
seemed like it might be relevant.  The fact that llvm-3.4 didn't help me
is just an extra detail really.

If anyone would like me to run any extra tests, feel free to ask.

Cheers, Phil.

Please stop mixing up unrelated bugs.  The intel driver doesn't use
llvm.

Cheers,
Julien

Anything that crashes GNOME Shell (via an assertion failure or any
other reason) has the same superficial symptom: the "fail whale"
(oops, something has gone wrong) from gnome-session.
As a result, #775235, #770130/#776911, and #780413 all have the same
superficial symptom, but I suspect their root causes differ (particularly
#775235 and the others), and they can only be distinguished easily
by log messages in syslog / the systemd Journal.

Reasons I think this is the same thing as #770130/#776911 and perhaps #780413:

* all involve approximately decade-old Intel graphics (Eric on #770130: 830M;
  Rafal on #776911: 852GM/855GM; Philip: 855GM; me on #780413: 865G)

* Eric, Rafal and Philip all report "*ERROR* pipe A underrun"
  whereas I get a different symptom for #780413 ("GPU HANG"),
  which is why I haven't merged #780413 with the others

You seem to be running systemd as pid 1, so the catch-all answer is
"in the journal" (available via either journalctl or the traditional
syslog interface).

Could you please look in the journal and see whether you are getting
an assertion failure something like this?

  May 17 01:20:15 debian gnome-session[952]: (gnome-shell:1092):
  Cogl-ERROR **: Failed to create texture 2d due to size/format
  constraints

(systemd blames it on gnome-session because it comes out of gnome-session's
stderr, which is inherited by gnome-shell - but the message is really
from gnome-shell)

My prediction is that you will. You'd typically see several iterations
of that, before gnome-session gives up hope of successfully starting
gnome-shell and displays the fail-whale instead.

That's interesting. I could only reproduce something similar on #780413
by starting the "real login" version of GNOME Shell; I only tried going
via gdm, but gdm's login screen *is* (a special configuration of)
GNOME Shell (in particular, it is the same from a graphics/compositing/3D
point of view AIUI); so if GNOME Shell is going to crash like this, it's
rather surprising that gdm's login screen does not already do the same before
we could even log in.

I'll try with startx or lightdm on my 865M hardware at some point.
It's possible that the way to reproduce this bug is something like "run
an accelerated compositing environment (GNOME Shell) on one VT, and then
try to run *another* accelerated compositing environment on another VT"?
If that was the case, then something like gdm -> xfce would work because
gdm's Shell was the first composited environment running and xfce isn't
composited; and lightdm -> GNOME Shell would also work because GNOME Shell
was the first composited environment running; but gdm -> GNOME Shell
would not.

Suggesting lightdm provides a workaround for this older hardware,
if nothing else.

We're pointing at the unsolved bugs because they sound more like what you're
experiencing than the solved #775235 does, and we hope that your additional
information might give someone enough clues to solve them.

From a purely practical point of view, if your hardware is this old,
you might well be better off with lightdm or another non-compositing *DM
instead of gdm, and/or GNOME Flashback or a non-GNOME environment instead
of GNOME Shell. On the i865M where I could reproduce #780413,
I was previously using wheezy's GNOME fallback environment (for
which GNOME Flashback is the closest equivalent in jessie), until I
retired it in favour of a second-hand Thinkpad running wheezy's
GNOME Shell.

Perhaps the jessie release notes should recommend GNOME Flashback
as the upgrade path for GNOME on hardware older than some arbitrary cutoff?
Anything with x86-64, and even the more recent 32-bit chipsets (e.g. whatever
is in the Thinkpad X60s), should be fine for GNOME; but older than that is,
realistically, not going to be tested by most developers any more.

    S

Hi Simon,

Thanks for the detailed response.

Simon McVittie <smcv@debian.org> writes:

...

Yes -- I thought I'd looked there, but it turns out there was enough
other stuff splurged into the journal that I'd missed the needle in that
haystack.

Exactly that -- occuring twice.

I see two of those errors, then it bails out with an Unrecoverable error.

...

Definitely -- I was aproaching this as a test of what happens if one
just goes with the defaults.  I wasn't really expecting it to be a good
idea, but its a bit of a shame when it fails so completely that one
cannot even get to a browser (so a newbie with just one computer would
then be forced to give up Debian right there).

Having just tried Flashback, I think I'd have to recommend XFCE (or LXDE)
on that hardware.

... and also will be depressingly slow when compared to the more svelt
alternatives we have available.

BTW I just upgraded back to the standard mesa packages, and can confirm
that lightdm is able to launch Gnome on this machine with the normal
packages.

Cheers, Phil.

control: severity -1 wishlist
control: forwarded -1 https://freedesktop.org/patch/34445
control: retitle -1 mesa: use llvm's getCPUTargetFeatures() instead of
getHostCPUName()

It turns out that mesa uses llvm's getHostCPUName(), and qemu i386 by
default (correctly) reports itself as pentium2, which is assumed
non-sse2. gnome-shell uses a mesa feature that requires sse2, so it
fails at startup on qemu i386.

On llvm trunk they've implemented getCPUTargetFeatures(), which can be
used to check for specific cpu features like sse2, and that is the
long term solution to the problem:
https://llvm.org/bugs/show_bug.cgi?id=23201

In the meantime, the problem can be worked around by using a
non-default qemu cpu options.  Some examples:

$ qemu -cpu pentium3 test.img
$ kvm -cpu host test.img

Since there workarounds are straightforward I am reducing the severity.

Best wishes,
Mike

Dear Customer,



Your parcel was successfully delivered January 24 to USPS Station, but our courier cound not contact you.



Download postal receipt attached to e-mail!



Most sincerely,

Johnny Parks,

USPS Chief Operation Agent.

Hello,

Good morning,

We have gone through your samples from a partner and Here is our  Order
List. Please do bear in mind that we are very much in  need of this
order, quote your competitive prices.

Kindly send the Order confirmation.

Your early reply will be much appreciated.

Best Regards,

Maryanah Erwin.

PT FINDORA INTERNUSA

Jln Pahlawan 66 Kec. Arjawinangun

45162 CIREBON West-Java INDONESIA

tel : +62 231 357334

fax: +62 231 357260

email: marketing@findora.com

Hello,

Good morning,

We have gone through your samples from a partner and Here is our  Order
List. Please do bear in mind that we are very much in  need of this
order, quote your competitive prices.

Kindly send the Order confirmation.

Your early reply will be much appreciated.

Best Regards,

Maryanah Erwin.

PT FINDORA INTERNUSA

Jln Pahlawan 66 Kec. Arjawinangun

45162 CIREBON West-Java INDONESIA

tel : +62 231 357334

fax: +62 231 357260

email: marketing@findora.com

Hello,

Good morning,

We have gone through your samples from a partner and Here is our  Order
List. Please do bear in mind that we are very much in  need of this
order, quote your competitive prices.

Kindly send the Order confirmation.

Your early reply will be much appreciated.

Best Regards,

Maryanah Erwin.

PT FINDORA INTERNUSA

Jln Pahlawan 66 Kec. Arjawinangun

45162 CIREBON West-Java INDONESIA

tel : +62 231 357334

fax: +62 231 357260

email: marketing@findora.com

It looks like the src/gallium/auxiliary/gallivm/lp_bld_misc.cpp file
in mesa was heavily updated for managing newer llvm versions, even if
mesa is still using getHostCPUName and still not getCPUTargetFeatures.

Michael, do you think there is still something to do in mesa?

Steve and Bernhard, are you still able to reproduce the original issue?