From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37876) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ug0Du-0004ZN-2U for qemu-devel@nongnu.org; Fri, 24 May 2013 18:12:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ug0Dm-0007Js-JH for qemu-devel@nongnu.org; Fri, 24 May 2013 18:12:30 -0400 Received: from mail-ph.de-nserver.de ([85.158.179.214]:56053) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ug0Dm-0007Jk-8P for qemu-devel@nongnu.org; Fri, 24 May 2013 18:12:22 -0400 Message-ID: <519FE5C6.5070509@profihost.ag> Date: Sat, 25 May 2013 00:12:22 +0200 From: Stefan Priebe MIME-Version: 1.0 References: <519EFFA9.3070100@profihost.ag> <20130524092356.2f16521d@redhat.com> <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> In-Reply-To: <20130524220909.GA6241@vm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-stable] qmp commands get rejected List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: mdroth Cc: "qemu-stable@nongnu.org" , qemu-devel , Dietmar Maurer , Luiz Capitulino 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? Stefan