On 16 August 2016 at 18:41, Nerijus Baliūnas <neri...@users.sourceforge.net> wrote: > 2016-08-16 20:26, Peter Maydell rašė: >>> >>> Yes, it still hangs: >>> >>> # gdb /usr/bin/qemu-system-alpha >>> (gdb) r -S -no-user-config -nodefaults -nographic -M none -qmp >>> unix:/var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait >>> -pidfile >>> /var/lib/libvirt/qemu/capabilities.pidfile >>> Starting program: /usr/bin/qemu-system-alpha -S -no-user-config >>> -nodefaults >>> -nographic -M none -qmp >>> unix:/var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait >>> -pidfile >>> /var/lib/libvirt/qemu/capabilities.pidfile >>> [Thread debugging using libthread_db enabled] >>> Using host libthread_db library "/lib64/libthread_db.so.1". >>> [New Thread 0x7fffc9708700 (LWP 13010)] >>> ^C >> >> >> Has it actually hung, or is it just waiting for you to talk >> QMP protocol to it on the socket ? > > > Probably hung, because the same command launches on another PC, > process is running and the shell returns.
Even with -daemonize not supplied? It shouldn't return you to the shell prompt if you don't pass that option! >> I think what is happening here is that libvirt starts these >> QEMU processes to query them for what they support. What should >> happen is that QEMU is started, libvirt talks QMP protocol to >> them and then stops the QEMU processes when it's found out the >> answers to its questions. I think we need to somehow get a >> log of what libvirt is doing on the QMP socket to find out >> whether this bug is in QEMU (eg libvirt asks it to do something >> and it hangs) or in libvirt (eg libvirt doesn't tell >> QEMU to quit). > > > Yes, but as I wrote above, the command runs on another PC > even without libvirt. So most probably something wrong with qemu. Does the same binary work on one PC and not on the other? (not just the same command). thanks -- PMM