llvmpipe i386 crashes when running on qemu64 cpu

[Norbert]

STEPS TO REPRODUCE:
   1. Install Ubuntu 14.04.2 LTS or Ubuntu 14.10 or Ubuntu 15.04 with all updates (it is a host system).
   2. Download one (or all) isos:
      * Ubuntu 14.0.4.2 i386 iso (ubuntu-14.04.2-desktop-i386.iso, MD5SUM = a8a14f1f92c1ef35dae4966a2ae1a264).
      * Ubuntu 14.10 i386 iso (ubuntu-14.10-desktop-i386.iso, MD5SUM = 4a3c4b8421af51c29c84fb6f4b3fe109)
      * Ubuntu 15.04 i386 iso (ubuntu-15.04-desktop-i386.iso, MD5SUM = 6ea04093b767ad6778aa245d53625612)
   3. Boot one (or all) isos with as QEMU-KVM guest with the following commands:
      * sudo kvm -m 1536 -cdrom ubuntu-*-desktop-i386.iso
      * sudo kvm -m 1536 -cdrom ubuntu-*-desktop-i386.iso -vga std
      * sudo kvm -m 1536 -cdrom ubuntu-*-desktop-i386.iso -vga vmware
      * or from usb-creator-gtk via "Test disk" button
   4. Click on "Try Ubuntu"

EXPECTED RESULTS:
    ISO is booted to Unity desktop, user can test and use it.

ACTUAL RESULTS:
   In 14.04 and 14.10 guests can see empty purple desktop or purple desktop with two shortcuts ("Examples" and "Install Ubuntu ...").
   15.10 guest does not boot or boot to safe graphic mode (it is bug 1437740).

The reason for this is that unity requires gfx acceleration which is done via llvmpipe on non accelerated gfx chipsets (as VMs use by default). The error message is hidden away but is:

LLVM ERROR: Do not know how to split the result of this operator!

The cause is that KVM VMs by default use the qemu64 cpu model which seems to be inconsistent in some way between claimed features and actual results when using those features. A work-around for running i386 isos is to use a cpu model like core2duo or kvm64.

This bug should be confirmed and fixed.
Users may want to run Ubuntu in QEMU/KVM, not just VirtualBox.

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Norbert (nrbrtx)]

apport information

[Serge Hallyn (serge-hallyn)]

Thanks for reporting this bug.

I cannot reproduce this (on my 15.04 host). Can you show exactly how it fails,
showing both the terminal output and attaching (a)
screenshot(s)?

 status: incomplete

[Norbert (nrbrtx)]

It still does not boot to Unity.
If you can imagine black QEMU-KVM window - that is a screenshot.
What logs do you want?

[Serge Hallyn (serge-hallyn)]

Do you get any output on the console where you ran the kvm command?

If you run kvm with "-vnc :1" and then run "gvncviewer localhost:1", does that work better?

Assuming it still breaks under vnc, then, again using gvncviewer, at the top left you can choose "send key -> ctrl-alt-f2". Please do that, then look at the end of /var/log/syslog. Is anything interesting there?

Which window manager are you using on the host? (I vaguely recall the SDL library in the past has had some trouble in certain window managers)

[Stefan Bader (smb)]

I can reproduce this on a Trusty/14.04 host when using the i386 isos. The amd64 isos work. Also the i386 isos seem to work when not using kvm directly, but through libvirt. The main difference would be that this uses a VNX display instead of direct graphics using SDL (I believe).

[Norbert (nrbrtx)]

Bug exists with Ubuntu 12.04.5 LTS host and Ubuntu 15.10 alpha guest.

[Chris J Arges (arges)]

Building from upstream allows me to get to get to the purple login screen when clicking 'Try Ubuntu' (not sure why it doesn't automatically login). So perhaps something has changed upstream?

[Stefan Bader (smb)]

Finally with a little help on debugging unity, I think I see what is going on. The obvious part seemed to be that compiz seems to fail starting. Which turns out to be LLVM-pipe bailing with an obscure error message:

LLVM ERROR: Do not know how to split the result of this operator!

This made me think about the emulated CPU, even more because Xen HVM guests do work with the i386 isos. And really this is the actual problem! So one quick work-around is to force qemu to use a different CPU type. In my test I used the Wily i386 iso and changed the CPU type from the default (QEMU Virtual CPU v2.0.0) into core2duo. And suddenly the live session works.

So next, what is the difference. Beside of name, model, and stepping, it seems the cpuid flags:

Core(TM)2 Duo CPU (emulated) QEMU Virtual CPU v2.0.0
model 15 model 6
stepping 11 stepping 3
cpuid level 10 cpuid level 4

ore(TM)2 Duo CPU (emulated) QEMU Virtual CPU v2.0.0
model 15 model 6
stepping 11 stepping 3
cpuid level 10 cpuid level 4
 --> fpu vme de pse tsc msr pae mce
 fpu de pse tsc msr pae mce <--
 --> cx8 apic sep mtrr pge mca cmov
 cx8 apic sep mtrr pge mca cmov <--
 --> pat pse36 clflush mmx fxsr sse
     pse36 clflush mmx fxsr sse <--
 --> sse2 ss syscall nx lm
 sse2 syscall nx lm <--
 --> constant_tsc pni vmx ssse3
                         pni vmx <--
 --> cx16 x2apic hypervisor
 cx16 x2apic popcnt hypervisor <--
 --> lahf_lm vnmi ept
 lahf_lm vnmi ept <--

So QEMU CPU misses: vme, pat, ss, constant_tsc, and ssse3 but has popcnt. A different host running Xen was also missing ss, constant_tsc, ssse3, and popct. But it had vme and pat and was working with the i386 iso.
That sounds a bit like either vme or pat missing could cause the i386 build of llvmpipe to fail while the exact same cpuid configuration works with the amd64 version of llvmpipe.

[Stefan Bader (smb)]

Maybe not exactly the cpuid flags seen but in a weird way how qemu builds some structures. I have to dig more there. But it is strange that qemu64 (which is the default cpu type if nothing else is specified) is defined as something based on a AMD cpu, while all of qemu32, kvm64, and kvm32 use a Intel base.

[Stefan Bader (smb)]

Since a simple work-around exists I think the importance can be lowered.

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1448985

[Thomas Huth (th-huth)]

Looking through old bug tickets... can you still reproduce this issue with the latest upstream version of QEMU? Or could we close this ticket nowadays?

[Stefan Bader (smb)]

Since we no longer produce i386 images, this would be hard to reproduce. I could imagine the issue still exists but nobody is or will care. Essentially a difference of what features are reported via cpuid and what actually is implemented in the cpu emulation. Will close at least the Ubuntu side.

[Launchpad Janitor (janitor)]

[Expired for QEMU because there has been no activity for 60 days.]