Bug 555727 - Time drift in win2k3-64bit and win2k8-64bit smp guest
Summary: Time drift in win2k3-64bit and win2k8-64bit smp guest
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kvm
Version: 5.5
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Gleb Natapov
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 523457 (view as bug list)
Depends On:
Blocks: 518493 577266 601564
TreeView+ depends on / blocked
 
Reported: 2010-01-15 10:46 UTC by Qunfang Zhang
Modified: 2018-12-01 16:28 UTC (History)
9 users (show)

Fixed In Version: kvm-83-165.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 601564 (view as bug list)
Environment:
Last Closed: 2011-01-13 23:33:52 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
drift time.exe (419.92 KB, application/x-ms-dos-executable)
2010-01-15 10:46 UTC, Qunfang Zhang
no flags Details
ntp-setup.exe (2.81 MB, application/x-ms-dos-executable)
2010-01-15 10:47 UTC, Qunfang Zhang
no flags Details
win2k3-64bit guest time drift result in kvm-140 (9.17 KB, text/plain)
2010-01-15 10:50 UTC, Qunfang Zhang
no flags Details
win2k8-64 guest time drift. (8.87 KB, text/plain)
2010-01-15 10:51 UTC, Qunfang Zhang
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:0028 0 normal SHIPPED_LIVE Low: kvm security and bug fix update 2011-01-13 11:03:39 UTC

Description Qunfang Zhang 2010-01-15 10:46:19 UTC
Created attachment 384565 [details]
drift time.exe

Description of problem:
Running the drift_time.exe(attachment) inside win2k3-64bit and win2k8-64bit smp guest,time drift in guest.

Version-Release number of selected component (if applicable):
kvm-83-140.el5

How reproducible:
100%

Steps to Reproduce:
1.Boot a win2k3-64bit or win2k8-64bit smp guest:
 /usr/libexec/qemu-kvm -no-hpet -usb -rtc-td-hack -smp 2 -m 2G -drive file=/mnt/win28k-64.qcow2,if=ide -net nic,vlan=0,macaddr=10:1a:4a:10:20:80,model=rtl8139 -net tap,vlan=0,script=/etc/qemu-ifup -cpu qemu64,+sse2 -uuid bf91f133-299e-49fe-a09d-32fcdd4b94e4 -boot c -monitor stdio -vnc :10
2.Install ntp-setup.exe in guest.(will be attached.)
3.Sync guest's time with ntpserver:clock.redhat.com
#ntpdate -b clock.redhat.com
4.Running the drift_test.exe (in the bug attachment) inside guest.
5.Check the time in guest's command prompt:
#ntpdate -b -q clock.redhat.com
6.Check the time in guest's command prompt after 10 minutes.
#ntpdate -b -q clock.redhat.com
  
Actual results:
Time drift in guest.I test it on Intel and AMD host.Paste the result here:
-----------------------------------------------------------
|          |       AMD host        |       Intel host     |
-----------------------------------------------------------
| Guest    |   up      |    smp    |    up    |    smp    |
-----------------------------------------------------------
|win2k3-32 |   OK      |   OK      |   OK     |    OK     |
-----------------------------------------------------------
|win2k3-64 |   OK      |5sec/10min |   OK     | 8sec/10min|
-----------------------------------------------------------
|win2k8-32 |   OK      |   OK      |   OK     |    OK     |
-----------------------------------------------------------
|win2k8-64 |   OK      |5sec/10min |   OK     | 4sec/10min|
-----------------------------------------------------------
|win2k8-R2 |   OK      |   OK      |   OK     |    OK     |     
-----------------------------------------------------------
| win7-32  |   OK      |   OK      |   OK     |    OK     |
-----------------------------------------------------------
| win7-64  |   OK      |   OK      |   OK     |    OK     |
-----------------------------------------------------------

Expected results:
No time drift in guest.

Additional info:
1.This issue only happened on win2k3-64 and win2k8-64 *smp* guest, for up guest this issue does not exist.
2.Host info :
Intel host:(4 cpu,here only list one)
processor	: 3
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Intel(R) Core(TM)2 Quad CPU    Q9550  @ 2.83GHz
stepping	: 10
cpu MHz		: 2826.238
cache size	: 6144 KB
physical id	: 0
siblings	: 4
core id		: 3
cpu cores	: 4
apicid		: 3
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm
bogomips	: 5652.48
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:


AMD host:
processor	: 3
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 2
model name	: AMD Phenom(tm) 9600B Quad-Core Processor
stepping	: 3
cpu MHz		: 1200.000
cache size	: 512 KB
physical id	: 0
siblings	: 4
core id		: 3
cpu cores	: 4
apicid		: 3
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc pni cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy altmovcr8 abm sse4a misalignsse 3dnowprefetch osvw
bogomips	: 4587.44
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate [8]

Comment 1 Qunfang Zhang 2010-01-15 10:47:53 UTC
Created attachment 384566 [details]
ntp-setup.exe

Attach the ntp-setup.exe to install in guest.

Comment 2 Qunfang Zhang 2010-01-15 10:50:03 UTC
Created attachment 384568 [details]
win2k3-64bit guest time drift result in kvm-140

Attached the time drift log during 10 minutes for win2k3-64 guest.

Comment 3 Qunfang Zhang 2010-01-15 10:51:01 UTC
Created attachment 384569 [details]
win2k8-64 guest time drift.

Attach the time drift log during 10 minutes of win2k8-64 guest.

Comment 9 Dor Laor 2010-03-17 11:13:46 UTC
*** Bug 523457 has been marked as a duplicate of this bug. ***

Comment 12 Qunfang Zhang 2010-04-02 02:36:11 UTC
Re-test the bug on kvm-83-165.el5, and this problem does not exist.

Intel host:
------------------------------------
| Guest    |    up     |   smp     |
------------------------------------
|win2k3-32 |     OK    |    OK     |
------------------------------------
|win2k3-64 |     OK    |    OK     |
------------------------------------
|win2k8-32 |     OK    |    OK     |
------------------------------------
|win2k8-64 |     OK    |    OK     |  
------------------------------------
|win2k8-R2 |     OK    |    OK     |     
------------------------------------
| win7-32  |     OK    |    OK     |
------------------------------------
| win7-64  |     OK    |    OK     |
------------------------------------

And also test rhel5.4-64bit guest, no time drift.



AMD host:

------------------------------------
| Guest    |    up     |   smp     |
------------------------------------
|win2k3-64 |     OK    |    OK     |
------------------------------------
|win2k8-64 |     OK    |    OK     |
------------------------------------

Comment 13 Zofbi Wain 2010-07-03 11:34:19 UTC
The problem still exists on kvm-83-164.12 with win2k3-32 guest (smp2, -rtc-td-hack, /usepmtimer boot.ini option). 

The drift_time.exe output looks like this:

Minimum period is 1 ms.
alarm_handler called, interrupt rate =   1003.78 interrupts/second
alarm_handler called, interrupt rate =    997.51 interrupts/second
alarm_handler called, interrupt rate =    997.51 interrupts/second
alarm_handler called, interrupt rate =    997.51 interrupts/second
alarm_handler called, interrupt rate =   1845.11 interrupts/second
alarm_handler called, interrupt rate =    997.51 interrupts/second
alarm_handler called, interrupt rate =   1491.60 interrupts/second
alarm_handler called, interrupt rate =   1612.14 interrupts/second
alarm_handler called, interrupt rate =    997.51 interrupts/second
alarm_handler called, interrupt rate =   1213.70 interrupts/second
alarm_handler called, interrupt rate =   1000.64 interrupts/second
alarm_handler called, interrupt rate =   1256.71 interrupts/second

I would like to test it on kvm-83-165.el5, could you give me a pointer to the src.rpm package?

Comment 14 Dor Laor 2010-07-04 08:11:50 UTC
Having more interrupts/sec actually says time compensation does work.
The fix should be in kvm-83-164.el5_5.3

Comment 15 Gleb Natapov 2010-07-04 08:21:29 UTC
(In reply to comment #13)
> The problem still exists on kvm-83-164.12 with win2k3-32 guest (smp2,
> -rtc-td-hack, /usepmtimer boot.ini option). 
> 
> The drift_time.exe output looks like this:
> 
> Minimum period is 1 ms.
> alarm_handler called, interrupt rate =   1003.78 interrupts/second
> alarm_handler called, interrupt rate =    997.51 interrupts/second
> alarm_handler called, interrupt rate =    997.51 interrupts/second
> alarm_handler called, interrupt rate =    997.51 interrupts/second
> alarm_handler called, interrupt rate =   1845.11 interrupts/second
> alarm_handler called, interrupt rate =    997.51 interrupts/second
> alarm_handler called, interrupt rate =   1491.60 interrupts/second
> alarm_handler called, interrupt rate =   1612.14 interrupts/second
> alarm_handler called, interrupt rate =    997.51 interrupts/second
> alarm_handler called, interrupt rate =   1213.70 interrupts/second
> alarm_handler called, interrupt rate =   1000.64 interrupts/second
> alarm_handler called, interrupt rate =   1256.71 interrupts/second

This output is irrelevant. Does wallclock drift or does it not? (and win2k3-32 does not have the problem this BZ fix anyway).

Comment 17 Golita Yue 2010-11-17 04:55:14 UTC
According to #comment 12,
This bug was verified in fixed version kvm-83-165.el5.

Comment 20 errata-xmlrpc 2011-01-13 23:33:52 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0028.html


Note You need to log in before you can comment on or make changes to this bug.