Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Found this issue during verifying bug 851143. Boot guest with vnc+qxl, guest aborted. I check the log of 864345, not the same and can not tell if they are the same issue. Please point it if it's a duplicate or need to change the component to spice-server or something else.
Version-Release number of selected component (if applicable):
spice-server-0.12.0-2.el6.x86_64
qemu-kvm-0.12.1.2-2.334.el6.x86_64.rpm
How reproducible:
Always.
Steps to Reproduce:
1.Boot guest with vnc and qxl:
/usr/libexec/qemu-kvm -S -M rhel6.3.0 -cpu Penryn -enable-kvm -m 2048 -smp 1,sockets=1,cores=1,threads=1 -name SF-VM1 -uuid c51aafca-18b1-4f65-aa09-38632e9d027f -smbios type=1,manufacturer="Red Hat",product="RHEV Hypervisor",version=6Server-6.3.0.3.el6,serial=44454C4C-4C00-1050-8043-B1C04F4A4C31_00:10:18:5D:BA:D4,uuid=c51aafca-18b1-4f65-aa09-38632e9d027f -nodefconfig -monitor stdio -rtc base=localtime,clock=host,driftfix=slew -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,serial= -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/home/RHEL-Server-6.4-64-virtio.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,serial=60137e34-ef49-4bed-8a67-7f90d1425414,cache=none,werror=stop,rerror=stop,aio=threads -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 -netdev tap,script=/etc/qemu-ifup,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:b6:62:8f,bus=pci.0,addr=0x3 -chardev socket,id=charchannel0,path=/tmp/foo,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm -chardev pty,id=charconsole0 -device virtconsole,chardev=charconsole0,id=console0 -device usb-tablet,id=input0 -vnc :10 -k en-us -vga qxl -global qxl-vga.vram_size=67108864 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
2. #vncviewer $host_ip:10
3.
Actual results:
After step 3:
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffe7fff700 (LWP 30871)]
0x00007ffff57468a5 in raise () from /lib64/libc.so.6
(gdb)
(gdb) bt
#0 0x00007ffff57468a5 in raise () from /lib64/libc.so.6
#1 0x00007ffff5748085 in abort () from /lib64/libc.so.6
#2 0x00007ffff5fa0c15 in spice_logv (log_domain=0x7ffff601cd7c "SpiceWorker", log_level=SPICE_LOG_LEVEL_ERROR,
strloc=0x7ffff601ea28 "red_worker.c:10711", function=0x7ffff6020360 "handle_dev_update",
format=0x7ffff6017c18 "assertion `%s' failed", args=0x7fffe7ffe980) at log.c:109
#3 0x00007ffff5fa0d4a in spice_log (log_domain=<value optimized out>, log_level=<value optimized out>,
strloc=<value optimized out>, function=<value optimized out>, format=<value optimized out>) at log.c:123
#4 0x00007ffff5f8105e in handle_dev_update (opaque=0x7fff500008c0, payload=<value optimized out>) at red_worker.c:10711
#5 0x00007ffff5f5eca7 in dispatcher_handle_single_read (dispatcher=0x7ffff88a41e8) at dispatcher.c:139
#6 dispatcher_handle_recv_read (dispatcher=0x7ffff88a41e8) at dispatcher.c:162
#7 0x00007ffff5f7f86e in red_worker_main (arg=<value optimized out>) at red_worker.c:11782
#8 0x00007ffff773c851 in start_thread () from /lib64/libpthread.so.0
#9 0x00007ffff57fc90d in clone () from /lib64/libc.so.6
Expected results:
Additional info:
Does the assert happen after the guest switches from vga to using qxl driver? what guest are you using? conversely, do you see this just booting into seabios?
(In reply to comment #4)
> Does the assert happen after the guest switches from vga to using qxl
> driver? what guest are you using? conversely, do you see this just booting
> into seabios?
1) Yes, this issue doesn't happens with '-vga std', and after I switch to qxl, the assert happens.
2) I use a rhel6.3-64 guest. Tried a win2012 guest just now, don't hit this issue.
3) I see this problem when the guest nearly finishes boot up and tries to start X windows. And If I use init=3 to boot guest, will not hit this problem.
Comment 7Christophe Fergeau
2012-11-23 11:27:06 UTC
This one is easy to reproduce on a RHEL 6.4, also happens with qemu from git.
I reproduced with a f17 guest, this occurs during boot when X would start (I haven't checked that X actually starts at this point)
The assert happens after an attempt at QXL_IO_MEMSLOT_ADD_ASYNC (first one), upon completion of the async operation, it calls into qxl_send_events which asserts on assert(qemu_spice_display_is_running(&d->ssd));
qxl->mode is still QXL_MODE_VGA at this point.
I don't know exactly what should happen/not happen when using qxl with vnc, so I can investigate further, but I'll need some guidance.
(In reply to comment #7)
The assertion on comment #0 is not the same, being triggered in handle_dev_update.
Maybe we do not need that qemu_spice_display_is_running assert ("your" assert).
qemu_spice_display_is_running(ssd), just verifies that spice display has been started, which when using VNC is false.
But the problem in comment #0, IIUC, is that qemu-kvm asks the spice-worker to do an update_area. The qxl device should not ask spice worker to do that when spice is not used. I think VNC defines a dummy spice-worker, that should not be sent an update_area request. I think VNC should be the one that gets the update_area call in such a case.
Comment 10Christophe Fergeau
2012-11-26 14:34:20 UTC
Hmm my bad, with spice-server 0.12-1 I hit this bug with the trace in comment #1, but it's gone with spice-server 0.12-4, I hit a different assert in qxl_send_events. May be related to #867405
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHBA-2013-0527.html