Description of problem: Testing a kernel patch in qemu. Version-Release number of selected component: qemu-system-x86-1.2.2-2.fc18 Additional info: backtrace_rating: 4 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 crash_function: vnc_dpy_resize executable: /usr/bin/qemu-kvm kernel: 3.7.4-204.fc18.x86_64 remote_result: NOTFOUND uid: 107 var_log_messages: Jan 31 16:07:49 ergine abrt[16267]: Saved core dump of pid 4291 (/usr/bin/qemu-kvm) to /var/spool/abrt/ccpp-2013-01-31-16:07:40-4291 (2736922624 bytes) Truncated backtrace: 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] File: backtrace
Created attachment 691250 [details] File: build_ids
Created attachment 691251 [details] File: cgroup
Created attachment 691252 [details] File: core_backtrace
Created attachment 691253 [details] File: dso_list
Created attachment 691254 [details] File: environ
Created attachment 691255 [details] File: limits
Created attachment 691256 [details] File: maps
Created attachment 691257 [details] File: open_fds
Created attachment 691258 [details] File: proc_pid_status
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: http://ajax.fedorapeople.org/patches/0001-drm-cirrus-Enable-32bpp.patch http://ajax.fedorapeople.org/patches/0002-drm-cirrus-Believe-the-hypervisor-about-VRAM-size.patch 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: > > http://ajax.fedorapeople.org/patches/0001-drm-cirrus-Enable-32bpp.patch > http://ajax.fedorapeople.org/patches/0002-drm-cirrus-Believe-the-hypervisor- > about-VRAM-size.patch 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: https://www.kraxel.org/cgit/linux/commit/?h=bochsfb&id=95d2e2040906bc2b09d7a0d8009f75810c668e57 > Still, the guest shouldn't be able to crash the hv. Indeed.
> Any plans to add drm support for the qemu standard vga (-vga std) ? FYI: http://git.qemu.org/?p=qemu.git;a=blob;f=docs/specs/standard-vga.txt
Given lack of response, closing