qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] QEMU 2.0 RC with Spice


From: Rick Vernam
Subject: Re: [Qemu-devel] QEMU 2.0 RC with Spice
Date: Wed, 16 Apr 2014 10:44:36 -0500
User-agent: KMail/4.12.3 (Linux/3.12.17; KDE/4.12.3; x86_64; ; )

On Wednesday 16 April 2014 07:12:16 Richard Vernam wrote:
> On Apr 16, 2014 3:07 AM, "Dr. David Alan Gilbert" <address@hidden>
> 
> wrote:
> > * Rick Vernam (address@hidden) wrote:
> > > On Tuesday 15 April 2014 19:25:22 Rick Vernam wrote:
> > > > Looks like it's in Spice:
> > <snip old backtrace without symbols>
> > 
> > > > I'll see if I can build spice with debugging symbols and what not and
> 
> write
> 
> > > > back with findings. Are others have problems with Qemu 2.0 RCs &
> 
> Spice?
> 
> > > > Here is how I started qemu with gdb:
> > > > 
> > > > QEMU_AUDIO_DRV=spice
> > > > TMPDIR=/home/rick/qemu/hds gdb --args
> 
> /usr/local/bin/qemu-system-x86_64 -cpu
> 
> > > > host -enable-kvm \ -m 1536 -name Win7Pro64 -localtime -no-fd-bootchk
> 
> -smp
> 
> > > > cores=4 \
> > > > -pidfile /home/rick/qemu/hds/win7pro64.pid \
> > > > -drive
> 
> file=/home/rick/qemu/hds/win7pro64.qed,if=virtio,index=0,snapshot=on
> 
> > > > \ -vga qxl \
> > > > -net nic,model=virtio -net user \
> > > > -device
> 
> virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5
> 
> > > > \ -chardev spicevmc,name=vdagent,id=vdagent \
> > > > -device
> 
> virtserialport,nr=1,bus=virtio-serial0.0,chardev=vdagent,name=com.redhat.sp
> 
> > > > ice.0 \ -spice port=1247,disable-ticketing \
> > > > -monitor telnet:localhost:12471,server,nowait \
> > > > -drive if=none,id=cd,file=/dev/sg1 \
> > > > -device virtio-scsi-pci,id=scsi \
> > > > -device scsi-generic,drive=cd \
> > > > -balloon virtio \
> > > > -soundhw hda \
> > > > -device usb-ehci
> > > > 
> > > > 
> > > > Thanks,
> > > > -Rick
> > > > 
> > > > On Tuesday 15 April 2014 15:22:04 Dr. David Alan Gilbert wrote:
> > > > > * Rick Vernam (address@hidden) wrote:
> > > > > > I have been trying out the 2.0 RCs, and I've noticed that when I
> 
> use
> 
> > > > > > spice
> > > > > > qemu aborts when I reboot the VM.  This occurs on Win XP guest,
> 
> Win 7
> 
> > > > > > (64-bit) guest and Win 8 (64-bit) guest.
> > > > > > Is this something that anybody else experiences?
> > > > > > I don't care to divert anybody's energy if this a spice thing -
> 
> how best
> 
> > > > > > to
> > > > > > determine this?
> > > > > 
> > > > > You say qemu aborts; can you get a backtrace and the abort message?
> > > > > 
> > > > > Dave
> > > > > --
> > > > > Dr. David Alan Gilbert / address@hidden / Manchester, UK
> > > 
> > > sorry, for top posting my last response.  and also sorry for not
> 
> noticing that I had let the binaries get stripped previously.
> 
> > > Here with qemu-system-x86_64 not stripped, and spice lib not stripped:
> > > 
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x00007ffff211eae5 in spice_char_device_write_to_device
> 
> (dev=0x55555687bcf0) at char_device.c:443
> 
> > > 443         sif = SPICE_CONTAINEROF(dev->sin->base.sif,
> 
> SpiceCharDeviceInterface, base);
> 
> > > (gdb) bt
> > > #0  0x00007ffff211eae5 in spice_char_device_write_to_device
> 
> (dev=0x55555687bcf0) at char_device.c:443
> 
> > > #1  0x00007ffff211fd81 in spice_char_device_start (dev=0x55555687bcf0)
> 
> at char_device.c:798
> 
> > > #2  0x00007ffff2171f95 in spice_server_vm_start (s=0x5555561d4360) at
> 
> reds.c:4520
> 
> > > #3  0x00005555556a1119 in qdev_reset_one (dev=<optimized out>,
> 
> opaque=<optimized out>) at hw/core/qdev.c:240
> 
> > > #4  0x00005555556a0958 in qbus_walk_children (bus=0x5555567576a0,
> 
> pre_devfn=0x0, pre_busfn=0x0, post_devfn=0x5555556a1100 <qdev_reset_one>,
> post_busfn=0x55555569f060 <qbus_reset_one>, opaque=0x0) at
> hw/core/qdev.c:369
> 
> > > #5  0x00005555556a0878 in qdev_walk_children (dev=0x55555677c0b0,
> 
> pre_devfn=0x0, pre_busfn=0x0, post_devfn=0x5555556a1100 <qdev_reset_one>,
> post_busfn=0x55555569f060 <qbus_reset_one>, opaque=0x0) at
> hw/core/qdev.c:403
> 
> > > #6  0x00005555556a0958 in qbus_walk_children (bus=0x5555567459c0,
> 
> pre_devfn=0x0, pre_busfn=0x0, post_devfn=0x5555556a1100 <qdev_reset_one>,
> post_busfn=0x55555569f060 <qbus_reset_one>, opaque=0x0) at
> hw/core/qdev.c:369
> 
> > > #7  0x00005555557d717a in qemu_devices_reset () at vl.c:1867
> > > #8  qemu_system_reset (address@hidden) at vl.c:1880
> > > #9  0x00005555555f9e2f in main_loop_should_exit () at vl.c:2015
> > > #10 main_loop () at vl.c:2055
> > > #11 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized
> 
> out>) at vl.c:4507
> 
> > > Thanks, and what can I do to provide more info?
> > 
> > I don't know much about spice; I've added address@hidden to cc who
> 
> knows spice.
> 
> > Can you clarify a bit more about which spice version you're using and
> 
> anything else
> 
> > about your setup that might be relevant.
> > 
> > Dave
> > --
> > Dr. David Alan Gilbert / address@hidden / Manchester, UK
> 
> Spice is 0.12.4 via Gentoo, which makes me wonder if gentoo is applying any
> patches over vanilla spice.  If they are, I'll grab vanilla spice.
> 
> This happens during reboot, seemingly right at the transition between
> shutting down and starting back up; and so I wonder if it crashes during
> shutdown too, and I just didn't notice since I was shutting down anyway.
> I'll check on this as well.

I grabbed spice from spice-space, configured like so (copied verbatim from how 
gentoo was running configure):
./configure --prefix=/usr --build=x86_64-pc-linux-gnu 
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info 
--datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib 
--libdir=/usr/lib64 --disable-silent-rules --disable-dependency-tracking 
--disable-static --disable-tunnel --enable-client --without-sasl 
--disable-smartcard --disable-gui --disable-static-linkage

I only influenced the CFLAGS by adding a -g3 & -march=native, which is first 
gen i7.
Crash is the same...
This only happens on guest system reboot - qemu exits normally on guest system 
shutdown.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]