Il 28/10/2013 07:58, Matthew Anderson ha scritto:
> Hi Alex,
>
> I've been doing some testing with the latest git version and so far I haven't
> seen a guest freeze in the same circumstances as before.
>
> A weird thing that has been happening is the RTC timer stopping after a live
> migration. This happened in both 1.6.1 and the 1.6.50 git build. To replicate
> the issue I was migrating to/from the same machine and anywhere between 1 and
> 3 migrations the guest clock would stop. Connecting to the VNC console would
> not get it running again. I've tried to replicate the issue with the HPET
> enabled but the guest clock works flawlessly with it enabled.
Please try this:
(1) reproduce it with migration to file + restore from file
to save, from QEMU monitor:
migrate exec:cat>migr.ckp
to restore, from command line:
... -incoming 'exec:cat migr.ckp'
(2) If the RTC stops after restoring, compress migr.ckp and place it
somewhere I can download it.
Thanks,
Paolo
> Guest VM is Windows 2008R2. Host is Ubuntu 13.04 (kernel 3.8.0-25-generic)
> Command line -
> /usr/local/bin/qemu-system-x86_64 -enable-kvm -nodefconfig -nodefaults
> -daemonize -usb -chardev
> socket,id=charmonitor,path=/var/run/based1/monitor/525ce3d009c437d678000002.monitor,server,nowait
> -mon chardev=charmonitor,id=monitor,mode=control -chardev
> socket,path=/var/run/based1/ga/525ce3d009c437d678000002.guestagent,server,nowait,id=qga0
> -device virtio-serial -device
> virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -pidfile
> /var/run/based1/pid/525ce3d009c437d678000002.pid -vga cirrus -vnc 0.0.0.0:1
> -M pc-i440fx-1.6 -m 1024 -smp sockets=1,cores=1,threads=1 -cpu
> qemu64,+vme,+dts,+acpi,+dtes64,+vmx,+smx,+ssse3,+sse4_1,+sse4_2,+tpr_shadow,+vnmi,+flexpriority,+ept,+vpid,hv_relaxed,hv_spinlocks=0xffff,hv_vapic
> -rtc base=utc,driftfix=slew --no-hpet -drive
> aio=native,file=rbd:sata/525ce3d009c437d678000003,if=virtio,id=disk-525ce3d009c437d678000005,format=raw,cache=writeback,media=disk,index=0,addr=0xa
> -netdev
> tap,id=netdev-5264b6d46e53c81719000236,vhost=off,ifname=tap2,script=no,do
w
nscript=no -device
virtio-net-pci,netdev=netdev-5264b6d46e53c81719000236,id=interface-5264b6d46e53c81719000236,mac=9a:a5:63:64:6f:76,bus=pci.0,addr=0xb
-incoming tcp:0:3004
>
> Thanks
> -Matt
>
>
> -----Original Message-----
> From: Alex Bligh [mailto:a...@alex.org.uk]
> Sent: Tuesday, 22 October 2013 5:36 PM
> To: Xiexiangyou; Matthew Anderson
> Cc: Stefan Hajnoczi; qemu-devel@nongnu.org; Alex Bligh
> Subject: Re: [Qemu-devel] BUG: RTC issue when Windows guest is idle
>
>
>
> --On 22 October 2013 08:28:08 +0000 Xiexiangyou <xiexiang...@huawei.com>
> wrote:
>
>> Hi:
>>
>> I have run windows2008r2 guest with qemu-1.5.1/1.6(I have not test the
>> the newer version) for long time, the issue (guest in hangup state)
>> will come out.When guest in hangup state, QEMU main thread is blocked
>> in g_poll loop.
>>> 398c398,399
>>> < uint32_t timeout = UINT32_MAX;
>>> ---
>>>> /* uint32_t timeout = UINT32_MAX; */
>>>> uint32_t timeout = 1000;
>>>
>> It seems can fix the problem, and rtc/hpet interrupt can inject into
>> guest again because of the "timeout", and guest will wake up . But
>> maybe the issue is also exist, because during the time before timeout
>> , guest also will lose rtc/hpet ticks.
>
> I do not think that is the correct fix for 1.5.1/1.6; what you are basically
> doing is limiting the wait in the mainloop to one second (1.5.1/1.6 are in
> milliseconds); however, I believe there may be other code that looks for
> infinite timeouts. Either there is some other bug that this is masking (in
> which case it may or may not be fixed in master / 1.7), or its a bug in the
> timer stuff in 1.5.1/1.6 (which would not surprise me) which is likely to
> have been fixed in master / 1.7.
>
> --
> Alex Bligh
>
>
