Red Hat Bugzilla – Bug 906549
[abrt] qemu-system-x86-1.2.2-2.fc18: vnc_dpy_resize: Process /usr/bin/qemu-kvm was killed by signal 6 (SIGABRT)
Last modified: 2013-09-03 13:34:14 EDT
Description of problem:
Testing a kernel patch in qemu.
Version-Release number of selected component:
cmdline: /usr/bin/qemu-kvm -name f18 -S -M pc-1.2 -enable-kvm -m 2048 -smp 8,sockets=8,cores=1,threads=1 -uuid de99c39b-0392-3b73-effa-2058e7827eee -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/f18.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -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=0x5 -drive file=/var/lib/libvirt/images/f18.img,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:99:98:03,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
var_log_messages: Jan 31 16:07:49 ergine abrt: Saved core dump of pid 4291 (/usr/bin/qemu-kvm) to /var/spool/abrt/ccpp-2013-01-31-16:07:40-4291 (2736922624 bytes)
Thread no. 1 (9 frames)
#6 vnc_dpy_resize at ui/vnc.c:564
#7 dpy_resize at /usr/src/debug/qemu-kvm-1.2.0/console.h:249
#8 vga_draw_graphic at /usr/src/debug/qemu-kvm-1.2.0/hw/vga.c:1695
#9 vga_update_display at /usr/src/debug/qemu-kvm-1.2.0/hw/vga.c:1904
#11 vnc_refresh at ui/vnc.c:2596
#12 qemu_run_timers at qemu-timer.c:393
#14 qemu_run_all_timers at qemu-timer.c:450
#15 main_loop_wait at main-loop.c:502
#16 main_loop at /usr/src/debug/qemu-kvm-1.2.0/vl.c:1643
Created attachment 691249 [details]
Created attachment 691250 [details]
Created attachment 691251 [details]
Created attachment 691252 [details]
Created attachment 691253 [details]
Created attachment 691254 [details]
Created attachment 691255 [details]
Created attachment 691256 [details]
Created attachment 691257 [details]
Created attachment 691258 [details]
Gerd, does that backtrace ring any bells? I couldn't find anything obvious in git logs that might fix this.
It doesn't seem to be accumulating many dupes either so not high priority either
Adam, when does this happen? Any chance this is the switch from text mode to graphics mode? Does it happen on every boot or now and then?
Cole, is the threaded vnc server enabled in the fedora package?
(In reply to comment #12)
> Cole, is the threaded vnc server enabled in the fedora package?
Yep, it's on by default for qemu 1.2 AFAICT
(In reply to comment #12)
> Adam, when does this happen? Any chance this is the switch from text mode
> to graphics mode? Does it happen on every boot or now and then?
I was being a little obtuse, sorry. The patches I was testing:
The emulated cirrus does appear to support 32bpp, at least from a casual read, which is _lovely_ because 24bpp is a slow path in X (and also a constant source of bugs). But when I tried it, it exploded, so either I'm mistaken about the conclusion or mistaken in the implementation.
Still, the guest shouldn't be able to crash the hv.
(In reply to comment #14)
> (In reply to comment #12)
> > Adam, when does this happen? Any chance this is the switch from text mode
> > to graphics mode? Does it happen on every boot or now and then?
> I was being a little obtuse, sorry. The patches I was testing:
Does it crash with the kernel alone or do you need X too to trigger?
> The emulated cirrus does appear to support 32bpp, at least from a casual
> read, which is _lovely_ because 24bpp is a slow path in X (and also a
> constant source of bugs). But when I tried it, it exploded, so either I'm
> mistaken about the conclusion or mistaken in the implementation.
[ sort-of unrelated side note ]
Any plans to add drm support for the qemu standard vga (-vga std) ?
You'll don't suffer cirrus limitations then.
I've hacked up a driver, it's classic fbdev not drm though:
> Still, the guest shouldn't be able to crash the hv.
> Any plans to add drm support for the qemu standard vga (-vga std) ?
Given lack of response, closing