On 10/15/2013 04:18 PM, Xiexiangyou wrote: > Thanks for your reply :-) > The QEMU version is 1.5.1,and the KVM version is 3.6 > > QEMU command: > /usr/bin/qemu-kvm -name win2008_dc_5 -S -machine pc-i440fx-1.5,accel=kvm,usb=off -m 2048 -realtime mlock=off -smp 4,maxcpus=64,sockets=16,cores=4,threads=1 -uuid 13e08e3e-cd23-4450-8bd3-60e7c220316d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win2008_dc_5.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,clock=vm,driftfix=slew -no-hpet -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/dev/vmdisk/win2008_dc_5,if=none,id=drive-scsi0-0-0-0,format=qcow2,cache=none,aio=native -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:16:49:23,bus=pci.0,addr=0x3 -chardev socket,id=charchannel0,path=/var/run/libvirt/qem u/win2008_dc_5.extend,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.1 -chardev socket,id=charchannel1,path=/var/run/libvirt/qemu/win2008_dc_5.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0 -vnc 0.0.0.0:4 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 > > (gdb) bt > #0 0x00007f9ba661a423 in poll () from /lib64/libc.so.6 > #1 0x000000000059460f in os_host_main_loop_wait (timeout=4294967295) at main-loop.c:226 > #2 0x00000000005946a4 in main_loop_wait (nonblocking=0) at main-loop.c:464 > #3 0x0000000000619309 in main_loop () at vl.c:2182 > #4 0x000000000061fb5e in main (argc=54, argv=0x7fff879830c8, envp=0x7fff87983280) at vl.c:4611 > > Main thread's strace message: > # strace -p 6386 > Process 6386 attached - interrupt to quit > restart_syscall(<... resuming interrupted call ...> > > cpu thread's strace message: > # strace -p 6389 > Process 6389 attached - interrupt to quit > rt_sigtimedwait([BUS USR1], 0x7f9ba36fbc00) = -1 EAGAIN (Resource temporarily unavailable) > rt_sigpending([]) = 0 > ioctl(17, 0xae80, 0) = 0 > ioctl(17, 0xae80, 0) = 0 > ioctl(17, 0xae80, 0) = 0 > ioctl(17, 0xae80, 0) = 0 > ioctl(17, 0xae80, 0) = 0 > ioctl(17, 0xae80, 0) = 0 > ioctl(17, 0xae80, 0) = 0 > ioctl(17, 0xae80, 0) = 0 > ioctl(17, 0xae80, 0) = 0 > ioctl(17, 0xae80, 0) = 0 > ioctl(17, 0xae80, 0) = 0 > ioctl(17, 0xae80, 0) = 0 > ioctl(17, 0xae80, 0) = 0 > ioctl(17, 0xae80, 0) = 0 > ... > > Thanks! > --xie > > -----Original Message----- > From: Paolo Bonzini [mailto:paolo.bonzini@xxxxxxxxx] On Behalf Of Paolo Bonzini > Sent: Tuesday, October 15, 2013 7:52 PM > To: Xiexiangyou > Cc: qemu-devel@xxxxxxxxxx; qemu-devel-request@xxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; Huangpeng (Peter); Luonengjun > Subject: Re: [RFH] Qemu main thread is blocked in g_poll in windows guest > > Il 15/10/2013 12:21, Xiexiangyou ha scritto: >> Hi all: >> >> Windows2008 Guest run without pressure for long time. Sometimes, it >> stop and looks like hanging. But when I connect to it with VNC, It >> resume to run, but VM's time is delayed . When the vm is hanging, I >> check the main thread of QEMU. I find that the thread is blocked in >> g_poll function. it is waiting for a SIG, However, there is no SIG . >> >> I tried the clock with "hpet" and "no hpet", but came out the same >> problem. Then I upgrade the glibc to newer, it didn't work too. I'm >> confused. Is the reason that VM in sleep state and doesn't emit the >> signal. I set the windows 's "power option", enable/disable the >> "allow the wake timers", I didn't work. >> >> Is anybody have met the same problem before, or know the reason. Your >> reply will be very helpful. > > This post is missing a few pieces of information: > > * What version of QEMU is this? > > * What is the command line? > > * How do you know g_poll is waiting for a signal and not for a file > descriptor? > > * What is the backtrace of the main thread? What is the backtrace of > the VCPU thread? > > etc. > > Paolo > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > Hello, To revive this thread - I have exactly the same problem on freshly migrated virtual machines. The guest operating system is almost always Linux, bug impact ratio is very low, about one per tens of migrations. VM 'uptime', mean non-interruptible emulator state existence including migrations tends to be relatively old (> 1 month). Due to feature stabilization status in the recent releases, I am preferring to stick to the 1.1.2 (though bug probably presented in much newer versions of emulator as well). -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
