qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] BUG: RTC issue when Windows guest is idle


From: Matthew Anderson
Subject: Re: [Qemu-devel] BUG: RTC issue when Windows guest is idle
Date: Wed, 16 Oct 2013 14:56:12 +0000

Hi Xiangyouxie,

I personally haven't tried to solve the problem as yet but I've been in contact 
with Anders Fudali who was able to find the issue with the help of one of his 
developers. 

See below for his comments. I've love to hear from any of the devs that can 
explain the issue further because as far as I know it's still an issue although 
I haven't with tried any releases past 1.4.1.

----------------------------------------

We use QEMU-1.4.2 and Kernel-3.8.8 on our host machines. During the latest 
"RTC-freeze" we managed to strace the affected QEMU-process and one of our 
developers figured out that a file descriptor selector loops with a NULL value 
for timeout... we adjusted the source code for the file: main-loop.c and 
replaced UINT32_MAX with the value: 1000, see the diff below:

398c398,399
<     uint32_t timeout = UINT32_MAX;
---
>     /* uint32_t timeout = UINT32_MAX; */
>     uint32_t timeout = 1000;

I'm not sure IF this might have some other undesirable effects or consequence 
and why only Windows guests seems to be affected, but we've been running with 
this "fix" for > 3 days now and haven't seen the problem since.

Thought to share this with you.

Regards

Anders Fudali

------------------------------

From: Xiexiangyou [mailto:address@hidden 
Sent: Tuesday, 8 October 2013 5:39 PM
To: Matthew Anderson
Cc: address@hidden
Subject: Re: [Qemu-devel] BUG: RTC issue when Windows guest is idle

Hi:
         I have met the same bug that windows2008 guest stop receive the RTC 
ticks when it in idle status by fortuitous.
When vnc connect, guest will resume to receive RTC ticks and the time run fast 
because of the coalesced timer

HPET is diabled, and RTC is set "catchup", as following: 
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup' track='guest'/>
    <timer name='hpet' present='no'/>
  </clock>

My kvm module is version3.6. Should I upgrade it to latest version. Any 
suggestion is welcome !

Thanks! 

--xiangyouxie                                             

On Thu, Feb 21, 2013 at 06:16:10PM +0000, Matthew Anderson wrote:
> If this isn't the correct list just let me know,
> 
> I've run into a bug whereby a Windows guest (tested on Server 2008R2 and 
> 2012) no longer receives RTC ticks when it has been idle for a random amount 
> of time. HPET is disabled and the guest is running Hyper-V relaxed timers 
> (same situation without hv_relaxed). The guest clock stands still and the 
> qemu process uses very little CPU (<0.5%, normally it's >5% when the guest is 
> idle) . Eventually the guest stops responding to network requests but if you 
> open the guest console via VNC and move the mouse around it comes back to 
> life and QEMU replays the lost RTC ticks and the guest recovers. I've also 
> been able to make it recover by querying the clock over the network via the 
> net time command, you can see the clock stand still for 30 seconds then it 
> replays the ticks and catches up.
> 
> I've tried to reproduce the issue but it seems fairly illusive, the only way 
> I've been able to reproduce it is by letting the VM's idle and waiting. 
> Sometimes it's hours and sometimes minutes. Can anyone suggest a way to 
> narrow the issue down?
> 
> Qemu command line is-
> /usr/bin/kvm -name SQL01 -S -M pc-0.14 -cpu qemu64,hv_relaxed -enable-kvm -m 
> 2048 -smp 2,sockets=2,cores=1,threads=1 -uuid 
> 5f54333b-c250-aa72-c979-39d156814b85 -no-user-config -nodefaults -chardev 
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/iHost-SQL01.monitor,server,nowait
>  -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime 
> -no-hpet -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 
> -drive 
> file=/mnt/gluster1-norep/iHost/SQL01.qed,if=none,id=drive-virtio-disk0,format=qed,cache=writeback
>  -device 
> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0
>  -drive 
> file=/mnt/gluster1-norep/iHost/SQL01-Data.qed,if=none,id=drive-virtio-disk2,format=qed,cache=writeback
>  -device 
> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk2,id=virtio-disk2
>  -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device 
> ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 -netdev 
> tap,fd=29,id=hostnet0,vhost=on,vhostfd=39 -device 
> virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:2c:8d:23,bus=pci.0,addr=0x3
>  -chardev pty,id=charserial0 -device 
> isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 
> 127.0.0.1:22 -vga cirrus -device 
> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4
> 
> Environment is -
> Mainline 3.7.5 and 3.8.0
> Qemu 1.2.2, 1.3.1 and 1.4.0





reply via email to

[Prev in Thread] Current Thread [Next in Thread]