Sorry for the late reply. Unfortunately, when it gets stuck(block at the windows welcome screen), there are no any error messages print out, with cpu usage 9%. I'm not quite sure whether the QEMU monitor is still work
Here is some more infomation: 1. QEMU command-line: qemu-system-x86_64 -enable-kvm -full-screen -soundhw hda -soundhw ac97 -m 2816 -smp 2,sockets=1,cores=2,threads=1 -vga qxl -localtime -rtc clock=vm,base=localtime -net nic,addr=0x03,model=virtio,macaddr=C0:B1:A2:83:84:18 -net tap,ifname=b908v -device nec-usb-xhci,id=ehci -device nec-usb-xhci,id=ehci2 -boot d -smbios type=1,manufacturer=microcloud,product=cloudbox,version=2015,serial=microcloud,uuid=1f8e6f8e-5b74-4780-89c1-464dc1e7f319 -usbdevice tablet -display gtk -cpu host -drive file=/pcvdata/vmtogo/user_images/9cc7-9ebee790f514a6dab92.img,cache=writeback,serial=9cc7-9ebee790f514a6dab92 -drive file=/pcvdata/vmtogo/pri_desk/updbcc7-9ebee790f514a6dab92.img,cache=writeback,snapshot=off,serial=pridisk -device virtio-serial,id=ser0 -chardev socket,path=/tmp/virtio10280,server,nowait,id=virtio10280 -device virtserialport,bus=ser0.0,chardev=virtio10280,name=com.microcloud.0 -device virtio-serial,id=ser1 -chardev spicevmc,id=vdagent,name=vdagent -device virtserialport,bus=ser1.0,chardev=vdagent,name=com.redhat.spice.0 -chardev socket,path=/tmp/monitor10280,server,nowait,id=monitor10280 -mon chardev=monitor10280,mode=readline -serial /dev/ttyS0 2. GDB info: The 3rd thread missing as mentioned earlier (gdb) info threads Id Target Id Frame * 1 LWP 21315 "qemu-system-x86" 0x00007f9a24739c8b in ppoll () from /lib/libc.so.6 2 LWP 21316 "qemu-system-x86" 0x00007f9a2473fee9 in syscall () from /lib/libc.so.6 3 LWP 21369 "qemu-system-x86" 0x00007f9a2473b697 in ioctl () from /lib/libc.so.6 4 LWP 21370 "qemu-system-x86" 0x00007f9a2473b697 in ioctl () from /lib/libc.so.6 5 LWP 21371 "qemu-system-x86" 0x00007f9a24739b9d in poll () from /lib/libc.so.6 6 LWP 21373 "threaded-ml" 0x00007f9a24739b9d in poll () from /lib/libc.so.6 7 LWP 21374 "qemu-system-x86" 0x00007f9a24a11e1d in pthread_cond_wait () from /lib/libpthread.so.0 8 LWP 21375 "qemu-system-x86" 0x00007f9a24a11e1d in pthread_cond_wait () from /lib/libpthread.so.0 2017-10-19 21:29 GMT+08:00 Stefan Hajnoczi <stefa...@gmail.com>: > On Thu, Oct 19, 2017 at 05:32:10PM +0800, Wahaha Huang wrote: > > Hi there, > > I'm a newbie of qemu(2.10.0), when i start a vm from qemu, it sometimes > get > > stuck, > > Please post your QEMU command-line and describe the behavior when it > gets stuck. > > Are there any error messages? Does the QEMU monitor still work? Is the > QEMU process running at 100% CPU? etc > > > through gdb debugging, i found aio_worker thread(list below) missing when > > vm get stuck, > > but i don't know why, does anybody has further idea about this? > > Worker threads are temporary threads. If there is no work to do then > they terminate. New worker threads are started as needed. Therefore > you can't assume that a specific number of worker threads exists. > > > (gdb) info threads > > > > > > Id Target Id Frame > > > > > > 1 LWP 25451 "qemu-system-x86" 0x00007fc62081dc8b in ppoll () from > > >> /lib/libc.so.6 > > > > > > 2 LWP 25452 "qemu-system-x86" 0x00007fc620823ee9 in syscall () > from > > >> /lib/libc.so.6 > > > > > > * 3 LWP 25495 "qemu-system-x86" 0x00007fc620af8e80 in ?? () from > > >> /lib/libpthread.so.0 > > > > > > 4 LWP 25496 "qemu-system-x86" 0x00007fc62081f697 in ioctl () from > > >> /lib/libc.so.6 > > > > > > 5 LWP 25497 "qemu-system-x86" 0x00007fc62081f697 in ioctl () from > > >> /lib/libc.so.6 > > > > > > 6 LWP 25498 "qemu-system-x86" 0x00007fc62081db9d in poll () from > > >> /lib/libc.so.6 > > > > > > 7 LWP 25500 "threaded-ml" 0x00007fc62081db9d in poll () from > > >> /lib/libc.so.6 > > This looks like PulseAudio. I suggest disabling audio and checking if > the hang still occurs. > > > > > > > 8 LWP 25501 "qemu-system-x86" 0x00007fc620af5e1d in > pthread_cond_wait > > >> () from /lib/libpthread.so.0 > > > > > > 9 LWP 25502 "qemu-system-x86" 0x00007fc620af5e1d in > pthread_cond_wait > > >> () from /lib/libpthread.so.0 > > > > > > (gdb) bt > > > > > > #0 0x00007fc620af8e80 in () at /lib/libpthread.so.0 > > > > > > #1 0x00007fc620af8f5f in () at /lib/libpthread.so.0 > > > > > > #2 0x00007fc620af906f in sem_timedwait () at /lib/libpthread.so.0 > > > > > > #3 0x000055b66332e585 in qemu_sem_timedwait (sem=0x55b664e6c868, > > >> ms=10000) at util/qemu-thread-posix.c:289 > > > > > > #4 0x000055b6633279b6 in worker_thread (opaque=0x55b664e6c7f0) at > > >> util/thread-pool.c:102 > > > > > > #5 0x00007fc620aef767 in () at /lib/libpthread.so.0 > > > > > > #6 0x00007fc62082985f in clone () at /lib/libc.so.6 > > This is a worker thread waiting for more work to do. It's normal. >
