On Thu, 22 Nov 2012 18:09:44 +0100 Jan Kiszka <[email protected]> wrote:
> On 2012-11-22 18:07, Paolo Bonzini wrote: > > Il 22/11/2012 17:58, Luiz Capitulino ha scritto: > >>>>> It seems like mon->mc->command_mode is set wrong, looking at > >>>>> qmp_cmd_mode and its callers. Luiz may have more ideas. > >>>> > >>>> Checking. What I've just found is that qmp_capabilites will fail if the > >>>> VM is stopped (!?). > >>> > >>> It's a regression somewhere. I doubt it's qmp, but could be. > >>> > >>> Here are the symptoms, Doc: > >>> > >>> 1. Start qemu and stop it right away. Connect to the QMP socket and you > >>> won't get qmp's greeting > >>> > >>> 2. Start qemu, connect to the QMP socket and run the qmp_capabilities > >>> command. Then stop qemu and disconnect from the qmp socket and connect > >>> again: you'll see you're still in the previous session > >>> > >>> I do not get this with qemu 1.0. > >>> > >>> Dietmar got this because the suspend command automatically stops the VM > >>> after migration... > >>> > >>> Bisecting... > >> > >> Didn't try to understand what's wrong with it, but bisect brings: > >> > >> commit ac4119c023c72b15f54238af43e4a178fcf41494 > >> Author: Jan Kiszka <[email protected]> > >> Date: Fri Oct 12 09:52:49 2012 +0200 > >> > >> chardev: Use timer instead of bottom-half to postpone open event > >> > >> As the block layer may decide to flush bottom-halfs while the machine > >> is > >> still initializing (e.g. to read geometry data from the disk), our > >> postponed open event may be processed before the last frontend > >> registered with a muxed chardev. > >> > >> Until the semantics of BHs have been clarified, use an expired timer to > >> achieve the same effect (suggested by Paolo Bonzini). This requires to > >> perform the alarm timer initialization earlier as otherwise timer > >> subsystem can be used before being ready. > >> > >> Signed-off-by: Jan Kiszka <[email protected]> > > > > Ouch, in retrospect it actually makes sense since this patch uses a > > vm_clock timer. Elementary, Watson... :) > > > > I don't think there is a fix, short of reverting this commit. > > We have more timers than the one based on vm_clock. Does this help? It helps to the point of fixing the issue to me :) Thanks! Tested-by: Luiz Capitulino <[email protected]> > > diff --git a/qemu-char.c b/qemu-char.c > index 88f4025..242b799 100644 > --- a/qemu-char.c > +++ b/qemu-char.c > @@ -134,9 +134,9 @@ static void qemu_chr_fire_open_event(void *opaque) > void qemu_chr_generic_open(CharDriverState *s) > { > if (s->open_timer == NULL) { > - s->open_timer = qemu_new_timer_ms(vm_clock, > + s->open_timer = qemu_new_timer_ms(rt_clock, > qemu_chr_fire_open_event, s); > - qemu_mod_timer(s->open_timer, qemu_get_clock_ms(vm_clock) - 1); > + qemu_mod_timer(s->open_timer, qemu_get_clock_ms(rt_clock) - 1); > } > } > > Jan >
