On Thu, 22 Nov 2012 14:33:24 -0200 Luiz Capitulino <[email protected]> wrote:
> On Thu, 22 Nov 2012 14:24:14 -0200 > Luiz Capitulino <[email protected]> wrote: > > > > 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]>
