From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57759) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgPi3-0006TF-B9 for qemu-devel@nongnu.org; Sat, 25 May 2013 21:25:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UgPhw-0003XE-8D for qemu-devel@nongnu.org; Sat, 25 May 2013 21:25:19 -0400 Sender: fluxion Date: Sat, 25 May 2013 20:23:17 -0500 From: mdroth Message-ID: <20130526012317.GB1577@vm> References: <94065BAF-4476-4709-A494-37E4A43884D3@profihost.ag> <20130524100242.39ec0b73@redhat.com> <20130524112152.32ce478a@redhat.com> <519FC9C3.7070803@profihost.ag> <519FDDAA.4010801@profihost.ag> <20130524220909.GA6241@vm> <519FE5C6.5070509@profihost.ag> <20130524223217.GB6241@vm> <51A09BFE.4020003@profihost.ag> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51A09BFE.4020003@profihost.ag> Subject: Re: [Qemu-devel] [Qemu-stable] qmp commands get rejected List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Priebe Cc: aliguori@us.ibm.com, Luiz Capitulino , "qemu-stable@nongnu.org" , Dietmar Maurer , qemu-devel On Sat, May 25, 2013 at 01:09:50PM +0200, Stefan Priebe wrote: > Am 25.05.2013 00:32, schrieb mdroth: > >On Sat, May 25, 2013 at 12:12:22AM +0200, Stefan Priebe wrote: > >>Am 25.05.2013 00:09, schrieb mdroth: > >>>>>>>I would try to create a small example script. > >>>>>> > >>>>>>I use qmp-shell and other little scripts very often. > >>>>>> > >>>>>>>Am this be due to the fact that I don't wait for the welcome banner > >>>>>>>right now? > >>>>>> > >>>>>>If you're not reading from the socket, then you'll get the banner back > >>>>>>when > >>>>>>you read your first response. But qom-set shouldn't fail because of that. > >>>> > >>>>I can workaround it by adding this patch: > >>>>diff --git a/monitor.c b/monitor.c > >>>>index 62aaebe..9997520 100644 > >>>>--- a/monitor.c > >>>>+++ b/monitor.c > >>>>@@ -4239,7 +4239,8 @@ static int monitor_can_read(void *opaque) > >>>> static int invalid_qmp_mode(const Monitor *mon, const char *cmd_name) > >>>> { > >>>> int is_cap = compare_cmd(cmd_name, "qmp_capabilities"); > >>>>- return (qmp_cmd_mode(mon) ? is_cap : !is_cap); > >>>>+// return (qmp_cmd_mode(mon) ? is_cap : !is_cap); > >>>>+ return ((is_cap > 0) ? 0 : (qmp_cmd_mode(mon) ? is_cap : !is_cap)); > >>>> } > >>> > >>>I think this is unrelated to your original issue. If you issue > >>>'qmp_capabilities' command more than once you will get CommandNotFound, > >>>and that behavior seems to be present even with v1.3.0. This patch seems > >>>to be masking the problem you're having (which seems to be state from > >>>previous monitor sessions/connections leaking into subsequent ones). > >> > >>That sounds reasonable. I'm using proxmox / PVE which does a lot of > >>qmp queries in the background. So i might see situations where X > >>connections in parallel do qmp queries. > >> > >>>It's possible the GSource-based mechanism for handling I/O for chardev > >>>backends is causing a difference in behavior. Still not sure exactly > >>>what's going on though. > >>Can i revert some patches to test? > > > >I think somewhere prior to this one should be enough to test: > > > >2ea5a7af7bfa576a5936400ccca4144caca9640b > > YES! I used 2ea5a7af7bfa576a5936400ccca4144caca9640b~1 for my tests > and this works absoluty fine. Turns out the real culprit was a few commits later: 9f939df955a4152aad69a19a77e0898631bb2c18 I've sent a workaround this fixes things for QMP, but we may need a more general fix. Please give it a shot and see if it fixes your issues: http://article.gmane.org/gmane.comp.emulators.qemu/213106 > > Stefan >