Created attachment 750554 [details] Xorg.0.log Description of problem: When running Fedora 19 Beta RC2 in KVM and QXL display driver and Spice server are selected in virt-manager, X crashes on start. This only occurs on i386. Reproduced on 2 different computers. [ 5.683] (EE) qxl(0): mmap failure: Invalid argument [ 5.687] (EE) qxl(0): mmap failure: Invalid argument [ 5.687] (EE) [ 5.687] (EE) Backtrace: [ 5.696] (EE) 0: /usr/bin/X (OsLookupColor+0x136) [0x80b6196] [ 5.697] (EE) 1: ? (?+0x136) [0xb7797541] [ 5.697] (EE) 2: /usr/lib/xorg/modules/drivers/qxl_drv.so (_init+0x4248) [0xb6d17f68] [ 5.697] (EE) 3: /usr/lib/xorg/modules/drivers/qxl_drv.so (_init+0x5edc) [0xb6d1b87c] [ 5.697] (EE) 4: /usr/lib/xorg/modules/drivers/qxl_drv.so (_init+0xbfea) [0xb6d27b4a] [ 5.697] (EE) 5: /usr/lib/xorg/modules/drivers/qxl_drv.so (_init+0x13e09) [0xb6d374b9] [ 5.698] (EE) 6: /usr/bin/X (dixDestroyPixmap+0x15e6) [0x8078486] [ 5.698] (EE) 7: /usr/bin/X (SendErrorToClient+0x3dd) [0x807a73d] [ 5.698] (EE) 8: /usr/bin/X (_init+0x4661) [0x806c651] [ 5.700] (EE) 9: /lib/libc.so.6 (__libc_start_main+0xf3) [0xb725b963] [ 5.700] (EE) 10: /usr/bin/X (_start+0x21) [0x80687ea] [ 5.700] (EE) [ 5.700] (EE) Segmentation fault at address 0x0 Version-Release number of selected component (if applicable): Host: virt-manager-0.10.0-0.4.gitb68faac8.fc19.noarch libvirt-1.0.5-3.fc19.x86_64 libvirt-client-1.0.5-3.fc19.x86_64 libvirt-daemon-1.0.5-3.fc19.x86_64 libvirt-daemon-config-network-1.0.5-3.fc19.x86_64 libvirt-daemon-config-nwfilter-1.0.5-3.fc19.x86_64 libvirt-daemon-driver-interface-1.0.5-3.fc19.x86_64 libvirt-daemon-driver-libxl-1.0.5-3.fc19.x86_64 libvirt-daemon-driver-lxc-1.0.5-3.fc19.x86_64 libvirt-daemon-driver-network-1.0.5-3.fc19.x86_64 libvirt-daemon-driver-nodedev-1.0.5-3.fc19.x86_64 libvirt-daemon-driver-nwfilter-1.0.5-3.fc19.x86_64 libvirt-daemon-driver-qemu-1.0.5-3.fc19.x86_64 libvirt-daemon-driver-secret-1.0.5-3.fc19.x86_64 libvirt-daemon-driver-storage-1.0.5-3.fc19.x86_64 libvirt-daemon-driver-uml-1.0.5-3.fc19.x86_64 libvirt-daemon-driver-xen-1.0.5-3.fc19.x86_64 libvirt-daemon-kvm-1.0.5-3.fc19.x86_64 libvirt-gconfig-0.1.6-1.fc19.x86_64 libvirt-glib-0.1.6-1.fc19.x86_64 libvirt-gobject-0.1.6-1.fc19.x86_64 libvirt-python-1.0.5-3.fc19.x86_64 Guest: xorg-x11-drv-qxl-0.1.1-0.7.20130514git77a1594.fc19.i686 (Fedora 19 fully updated) xorg-x11-drv-qxl-0.1.1-0.4.20130312gita474a71.fc19.i686 (Fedora 19 RC2) xorg-x11-server-Xorg-1.14.1-2.fc19.i686 kernel-PAE-3.9.2-301.fc19.i686 How reproducible: 100% Steps to Reproduce: 1. Select QXL as Video adapter and Spice as display in virt-manager 2. Run i686 install DVD or installed system in KVM Actual results: X crashes on start.
Created attachment 750555 [details] dmesg
Created attachment 750556 [details] journalctl -a
Proposing as a Beta blocker: "The release must install and boot successfully as a virtual guest in a situation where the virtual host is running the previous stable Fedora release. " http://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria Please note that the default option in virt-manager is VNC+Cirrus, which means the default virt-manager behavior is not affected, only if you switch to QXL manually.
Discussed at 2013-05-20 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-20/f19beta-blocker-review-7.2013-05-20-16.07.log.txt . This is rejected as a blocker. It seems like a bad bug, but we took a couple of things into consideration. One, KVM/libvirt virtualization is not supported on 32-bit hosts (there are very few 32-bit CPUs which have hardware VT support at all). 64-bit hosts, obviously, can host 64-bit guests just fine. So there really isn't much of a reason to run a 32-bit guest, or a 32-bit OS on a 64-bit guest: the very obvious 'workaround' is 'just use the 64-bit Fedora'. Two, there's another reasonably simple workaround: use cirrus or vga instead of qxl. It's slower and suckier, but it does appear to work. On balance it's also rejected as a freeze exception bug, for fear of somehow breaking the much more important 64-bit guest case with a fix. As a side note, it would be useful to know if you're actually using a 32-bit guest here, or running 32-bit Fedora on a 64-bit guest (which would be the recommended config).
FWIW, I just booted Beta RC2 32-bit netinst ISO in a 64-bit KVM on an F19 host, using qxl/SPICE, and it's running anaconda fine.
Interesting. We have tested 3 different _clean_ F19 installations (64b KVM of course), it crashes on all of them. But it doesn't crash for Martin, who has an upgraded F19 system. I suppose, Adam, you also have an upgraded system, right? That would suggest it's somehow connected new a clean configuration or there's missing some package that is present in upgraded systems.
Yeah, I was testing on an upgraded host. In addition to your suspects, could be to do with the machine definition itself; they tweak the defaults over time, I'm using a machine I created a long time ago.
I've managed to reproduce this, it is fixed by using upstream qemu (specifically the important bit is bb1fadc444ff967554c41d96cb9dde110e8aece9), so now the question is if there is going to be a rebase of qemu for f19 or should I backport it (it will have to be a partial rewrite of the patch to avoid bringing in all the migration.c cleanup). Paolo, what do you think? Alon
(In reply to Alon Levy from comment #8) > I've managed to reproduce this, it is fixed by using upstream qemu > (specifically the important bit is > bb1fadc444ff967554c41d96cb9dde110e8aece9), so now the question is if there > is going to be a rebase of qemu for f19 or should I backport it (it will > have to be a partial rewrite of the patch to avoid bringing in all the > migration.c cleanup). > > Paolo, what do you think? > > Alon sorry, wrong bz.
Created attachment 752247 [details] Serial console output for F18 Beta RC4 x86_64 liveCD on RHEL6.4 host with spice+qxl The same problem happens to me even with x86_64 DVD or LiveCD image (F19 Beta RC4). I am using RHEL6.4 host. F18 works fine in the same VM. Host: $ rpm -qa | grep virt libvirt-0.10.2-18.el6_4.5.x86_64 virt-what-1.11-1.2.el6.x86_64 virt-manager-0.9.0-18.el6.x86_64 libvirt-client-0.10.2-18.el6_4.5.x86_64 python-virtinst-0.600.0-15.el6.noarch virt-top-1.0.4-3.15.el6.x86_64 virt-viewer-0.5.2-18.el6_4.2.x86_64 python27-python-virtualenv-1.7.2-2.el6_3.noarch virtio-win-1.6.3-3.el6.noarch libvirt-python-0.10.2-18.el6_4.5.x86_64
This commit by airlied looks significant: http://permalink.gmane.org/gmane.linux.redhat.fedora.extras.cvs/968226 in particular, it seems to have added the "mmap failure" string, which is apparently what we're hitting here.
okay I'll take a look today, didn't think 32-bit was a thing any more :-)
Looks like two bugs in one, please split the RHEL6.4 bug out from the 32-bit one, they are not the same thing.
xorg-x11-drv-qxl-0.1.1-0.8.20130514git77a1594.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/xorg-x11-drv-qxl-0.1.1-0.8.20130514git77a1594.fc19
Created attachment 753821 [details] dmesg with update xorg-x11-drv-qxl-0.1.1-0.8.20130514git77a1594.fc19 xorg-x11-drv-qxl-0.1.1-0.8.20130514git77a1594.fc19 does not work for me. X still crashes, dmesg and X.log attached.
Created attachment 753822 [details] X.log with update xorg-x11-drv-qxl-0.1.1-0.8.20130514git77a1594.fc19
Oh, my bad, sorry - I didn't realize I have to update this package in guest, not on host. After updating the package in guest, it works okay with qxl and spice, thank you.
Package xorg-x11-drv-qxl-0.1.1-0.8.20130514git77a1594.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xorg-x11-drv-qxl-0.1.1-0.8.20130514git77a1594.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-9445/xorg-x11-drv-qxl-0.1.1-0.8.20130514git77a1594.fc19 then log in and leave karma (feedback).
xorg-x11-drv-qxl-0.1.1-0.8.20130514git77a1594.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.