From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38115) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAzxM-0006LP-RM for qemu-devel@nongnu.org; Wed, 05 Feb 2014 05:43:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WAzxH-00037S-Qq for qemu-devel@nongnu.org; Wed, 05 Feb 2014 05:43:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:7329) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAzxH-000376-Ii for qemu-devel@nongnu.org; Wed, 05 Feb 2014 05:43:43 -0500 Date: Wed, 5 Feb 2014 11:43:39 +0100 From: Martin Kletzander Message-ID: <20140205104339.GB5525@wheatley> References: <20140203160455.GC13707@wheatley> <20140203184509.GA18504@work-vm> <20140204060524.GA5718@wheatley> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ADZbWkCsHQ7r3kzd" Content-Disposition: inline In-Reply-To: <20140204060524.GA5718@wheatley> Subject: Re: [Qemu-devel] qemu segfauls with spiceport chardev and isa-serial List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Michael Tokarev , "Dr. David Alan Gilbert" , "qemu-devel@nongnu.org Developers" --ADZbWkCsHQ7r3kzd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Feb 04, 2014 at 07:05:24AM +0100, Martin Kletzander wrote: > On Tue, Feb 04, 2014 at 11:40:41AM +1000, Peter Crosthwaite wrote: > > On Tue, Feb 4, 2014 at 4:45 AM, Dr. David Alan Gilbert > > wrote: > > > (cc'ing in Peter Crosthwaite and Michael Tokarev due to a serial fifo change > > > - see below!) > > > > > > * Martin Kletzander (mkletzan@redhat.com) wrote: > > >> Hello, > > > > > > Hi Martin, > > > I don't know about your spice warnings that triggered this but looking > > > down the backtrace I can see something odd: > > > > > >> current HEAD (2f61120c10da9128357510debc8e66880cd2bfdc) segfaults when > > >> I'm trying to do the following: > > >> > > >> I add this to qemu's command-line: > > >> > > >> -chardev spiceport,id=charserial0,name=org.qemu.console.serial.0 \ > > >> -device isa-serial,chardev=charserial0,id=serial0 > > >> > > >> and then use spicy to connect to that machine. That spits out the > > >> following error: > > >> > > >> GSpice-Message: main channel: opened > > >> port 0x7f74182366e0 org.qemu.console.serial.0: opened > > >> > > >> (spicy:32386): GSpice-WARNING **: incomplete link header (-104/16) > > >> > > >> (spicy:32386): GSpice-WARNING **: incomplete link header (-104/16) > > >> GSpice-Message: main channel: closed > > >> > > >> I can see that the console works when the window flashes, so there was > > >> some communication done (Im running the kernel inside with > > >> "console=tty0 console=ttyS0,115200n8" as suggested here: > > >> > > >> http://lists.freedesktop.org/archives/spice-devel/2014-January/015919.html > > >> > > >> The full command-line with backtrace of all the threads (with > > >> abort()-ing thread being thread #1 follows. Let me know if I can help > > >> anyhow. > > >> > > >> Thanks, > > >> Martin > > >> > > >> Command-line: > > >> > > >> qemu-system-x86_64 -name rhel7 -S -machine \ > > >> pc-i440fx-1.7,accel=kvm,usb=off,dump-guest-core=off -cpu SandyBridge \ > > >> -m 4101 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid \ > > >> f49fa544-f21d-4267-8958-d82570644f39 -no-user-config -nodefaults \ > > >> -chardev \ > > >> socket,id=charmonitor,path=/var/lib/libvirt/qemu/rhel7.monitor,server,nowait \ > > >> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc \ > > >> -no-shutdown -boot strict=on -device \ > > >> piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device \ > > >> virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive \ > > >> if=none,id=drive-ide0-0-0,readonly=on,format=raw -device \ > > >> ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive \ > > >> file=/home/nert/.config/libvirt/images/rhel7.img,if=none,id=drive-virtio-disk0,format=qcow2 \ > > >> -device \ > > >> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \ > > >> -netdev tap,fd=20,id=hostnet0,vhost=on,vhostfd=21 -device \ > > >> virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:42:be:45,bus=pci.0,addr=0x3 \ > > >> -chardev spiceport,id=charserial0,name=org.qemu.console.serial.0 \ > > >> -device isa-serial,chardev=charserial0,id=serial0 -device \ > > >> usb-tablet,id=input0 -vnc 127.0.0.1:0 -spice \ > > >> port=5901,tls-port=5902,addr=127.0.0.1,disable-ticketing,x509-dir=/etc/pki/libvirt-spice,seamless-migration=on \ > > >> -device \ > > >> qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 \ > > >> -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 > > >> > > >> Backtrace: > > >> > > > > > > > > > > > >> Thread 1 (Thread 0x7fee3da66980 (LWP 32022)): > > >> #0 0x00007fee344f1f4e in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 > > >> #1 0x00007fee344f369f in __GI_abort () at abort.c:89 > > >> #2 0x00007fee3de72baa in fifo8_pop (fifo=fifo@entry=0x7fee3fc28700) at util/fifo8.c:45 > > > > > > fifo8_pop is aborting because the fifo is empty: > > > if (fifo->num == 0) { > > > abort(); > > > } > > > > > > which seems fair enough > > > > > >> #3 0x00007fee3dc0c110 in serial_xmit (chan=, cond=, opaque=0x7fee3fc286a0) > > >> at hw/char/serial.c:228 > > > > > > s->tsr = fifo8_is_full(&s->xmit_fifo) ? > > > 0 : fifo8_pop(&s->xmit_fifo); > > > > > > Hmm, now I don't know anything about the tsr stuff; but that calls > > > fifo8_pop whenever the fifo isn't *full* - i.e. it still gets called if empty. > > > > > > I think the change here comes from Peter's 8e8638fa87ff04 'char/serial: Use generic Fifo8' > > > changeset from June which did: > > > > > > - s->tsr = fifo_get(s,XMIT_FIFO); > > > - if (!s->xmit_fifo.count) { > > > + s->tsr = fifo8_is_full(&s->xmit_fifo) ? > > > + 0 : fifo8_pop(&s->xmit_fifo); > > > + if (!s->xmit_fifo.num) { > > > > > > which makes me think (without having looked at the old data structure > > > properly) if that should be fifo8_is_empty ? > > > (The old serial fifo_get routine returned 0 if empty rather than aborting). > > > > > > > Hi Dave, > > > > Yes that does looks suss. My bad. Can you confirm your theory by > > making the proposed change? does it fix the bug? > > > > --- a/hw/char/serial.c > > +++ b/hw/char/serial.c > > @@ -225,7 +225,7 @@ static gboolean serial_xmit(GIOChannel *chan, > > GIOCondition cond, void > > > > if (s->tsr_retry <= 0) { > > if (s->fcr & UART_FCR_FE) { > > - s->tsr = fifo8_is_full(&s->xmit_fifo) ? > > + s->tsr = fifo8_is_empty(&s->xmit_fifo) ? > > 0 : fifo8_pop(&s->xmit_fifo); > > if (!s->xmit_fifo.num) { > > s->lsr |= UART_LSR_THRE; > > > > I wish I went one line up the stack, this makes sense. I changed this > line to what you suggested and indeed this fixes the crash. > > I'm still unable to use the console (spicy shows a window which it > shouldn't AFAIK), but that's a whole another story unrelated to this > problem. > Trying a bit more I've found out this might not be the whole fix which is needed. When I'm trying to write to it in the guest, the process in the guest freezes, I'm trying to isolate the issue at the moment and will keep you posted if I'll find anything more. Martin > Thanks for finding that out, > Martin > > > Regards, > > Peter > > > > > Dave > > > > > >> #4 0x00007fee3d1a8957 in g_main_dispatch (context=0x7fee3fa49470) > > >> at /var/tmp/portage/dev-libs/glib-2.38.2/work/glib-2.38.2/glib/gmain.c:3066 > > >> #5 g_main_context_dispatch (context=context@entry=0x7fee3fa49470) > > >> at /var/tmp/portage/dev-libs/glib-2.38.2/work/glib-2.38.2/glib/gmain.c:3642 > > >> #6 0x00007fee3dccdde7 in glib_pollfds_poll () at main-loop.c:189 > > >> #7 os_host_main_loop_wait (timeout=) at main-loop.c:234 > > >> #8 main_loop_wait (nonblocking=) at main-loop.c:483 > > >> #9 0x00007fee3db61501 in main_loop () at vl.c:2018 > > >> #10 main (argc=, argv=, envp=) at vl.c:4410 > > > > > > > > > -- > > > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK > > > --ADZbWkCsHQ7r3kzd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJS8hXbAAoJEAgfwp8kF4bdnswP/jj9hymxF4TJLuMAFWpd8aSi 0Ocegr8jTLZvrgTmi7Bnc4GvyZphT9Q5Vc/TML69JrsS09FOVtxSrIgmhoXbVuXg y5G8odA5yJLrv3G6IoRxrACT5zQCnrdBJD0ACQKgQsZWxw/kWwMD/adQyz9IaYB0 qAfXgS1hYvD7BDn35mia+bX4Efwm/gSInAWmPsiW1j9fgwRGZBy2zS358Okbb3F0 dXMzuJz6Hs8lwQkYdV/NQz5abzOeRtNHCJp/Y3e3Q/j8MgApWbu/P98Ml//OBtNt vbVLTAOyO8VFoj3VsdsT2oY2eB8iGxBX5q1sI8H3g8JzqZQ7n0EihXYyGsvPRfM6 lkxP/YyYA9f8eYd0md9U/mQ7WYcP8gxtkC+6th98wHia+lq3gEEct2c2T++XDuQh mUs7JdLhnhlC6fLyK0JdmEqnfJi5K4QkG/XQQmHn7NeV0jS76I+QjiYV0cJgFqUv gM289fH2yeHty0jL3TIHhhKgpboOmNvXI0VigWYjBtm9tvlXupPApYFBWnYbTJO+ ESkfmsXBt39rd2UWuAhHfVwzM0dN5D1Xh+R0gi8GJXs8GmLUulLQ8EZ9btrTTHMO ctkCj0lXaO522vIu1dSXF6UeQgSHcH2IYtt8FemEDg/fRm5/4v+i1gqY6Y7byQfe jTWArvS/6S+V8cDPR8WF =Q9Ls -----END PGP SIGNATURE----- --ADZbWkCsHQ7r3kzd--