qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Martin Kletzander <mkletzan@redhat.com>
To: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: Michael Tokarev <mjt@tls.msk.ru>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] qemu segfauls with spiceport chardev and isa-serial
Date: Tue, 4 Feb 2014 07:05:24 +0100	[thread overview]
Message-ID: <20140204060524.GA5718@wheatley> (raw)
In-Reply-To: <CAEgOgz7kCuxhYKguwwY8qp=PEkPyH6ixh_HHmjb9F219QjYHRA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6552 bytes --]

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
> <dgilbert@redhat.com> 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:
> >>
> >
> > <snipped boring threads in poll>
> >
> >> 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=<optimized out>, cond=<optimized out>, 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.

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=<optimized out>) at main-loop.c:234
> >> #8  main_loop_wait (nonblocking=<optimized out>) at main-loop.c:483
> >> #9  0x00007fee3db61501 in main_loop () at vl.c:2018
> >> #10 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4410
> >
> >
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> >

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2014-02-04  6:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-03 16:04 [Qemu-devel] qemu segfauls with spiceport chardev and isa-serial Martin Kletzander
2014-02-03 18:45 ` Dr. David Alan Gilbert
2014-02-04  1:40   ` Peter Crosthwaite
2014-02-04  6:05     ` Martin Kletzander [this message]
2014-02-05 10:43       ` Martin Kletzander
2014-02-05  9:35     ` Dr. David Alan Gilbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140204060524.GA5718@wheatley \
    --to=mkletzan@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=mjt@tls.msk.ru \
    --cc=peter.crosthwaite@xilinx.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).