[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] broken HMP command: info mtree
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] broken HMP command: info mtree |
Date: |
Fri, 12 Feb 2016 14:49:11 +0000 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Fri, Feb 12, 2016 at 02:27:23PM +0100, Igor Mammedov wrote:
> On Fri, 12 Feb 2016 14:08:32 +0100
> Paolo Bonzini <address@hidden> wrote:
>
> > On 12/02/2016 12:17, Daniel P. Berrange wrote:
> > > On Fri, Feb 12, 2016 at 12:15:26PM +0100, Igor Mammedov wrote:
> > >> On Thu, 11 Feb 2016 16:35:39 +0100
> > >> Igor Mammedov <address@hidden> wrote:
> > >>
> > >>> executing 'info mtree' from monitor prompt causes infinite loop
> > >>> printing it over and over.
> > >>>
> > >>> to reproduce build current master adn run:
> > >>>
> > >>> qemu-system-x86_64 -monitor stdio
> > >>>
> > >>> and then execute 'info mtree' in monitor prompt
> > >>
> > >> it bisects to:
> > >>
> > >> commit 9894dc0cdcc397ee5b26370bc53da6d360a363c2
> > >> Author: Daniel P. Berrange <address@hidden>
> > >> Date: Tue Jan 19 11:14:29 2016 +0000
> > >>
> > >> char: convert from GIOChannel to QIOChannel
> > >>
> > >> In preparation for introducing TLS support to the TCP chardev
> > >> backend, convert existing chardev code from using GIOChannel
> > >> to QIOChannel. This simplifies the chardev code by removing
> > >> most of the OS platform conditional code for dealing with
> > >> file descriptor passing.
> > >>
> > >> Signed-off-by: Daniel P. Berrange <address@hidden>
> > >> Message-Id: <address@hidden>
> > >> Signed-off-by: Paolo Bonzini <address@hidden>
> > >>
> > >>
> > >> build with:
> > >> ./configure --target-list=x86_64-softmmu --enable-debug
> > >> on RHEL72ish host
> > >>
> > >> monitor output has to be stdio
> > >
> > > Sigh, so much pain from the chardev code. I'll investigate and send a
> > > suitable patch asap.
> >
> > Hmm, I cannot reproduce this though.
> Perhaps I'm affected because my stdout goes via remote ssh session.
>
> It looks like monitor tries to flush buffer but succeeds only partially
> and returns with EAGAIN and on the next flush attempt it tries to
> flush the same buffer again from the first byte again
Yes, it turned out to need a moderately slow console like a distant
ssh connection to trigger the EGAIN situation. I've just sent a patch.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|