https://bugzilla.novell.com/show_bug.cgi?id=662093
https://bugzilla.novell.com/show_bug.cgi?id=662093#c2
Samuel Kvasnica changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |ASSIGNED
InfoProvider|samuel.kvasnica@ims.co.at |
--- Comment #2 from Samuel Kvasnica 2011-01-30 14:36:45 UTC ---
Ok, finally got some more data, I tried several things:
1. I can observe this on 3 systems having totally different hardware, vendors
and hardware generations/age. All systems had no clock drift on 2.6.31.
2. I tried to compile the 2.6.34.7 pvops vanilla kernel, drift is present as
well.
3. The drift is always of the order of a second per day but can be positive or
negative. No matter if I set clock=pit, clocksource=jiffies or whatever on DomU
boot.
4. The clock visible by user in Dom0 is absolutely stable (and theres ntp
running)
5. (This is very important:) If the Dom0 was already running a while and I
start a domU later (or I restarted it), it does not start to drift from zero
but from an existing offset which seems to exist and drift somewhere in dom0
!!!
I.e. if I start a domain, the clock is 20seconds off from the very beginning
after boot and starts to drift from here. Now the difference between pvops and
suse kernel: if I correct the domU time manually in pvops, it remains corrected
and drifts away from zero as usual. If I manually correct the time in suse
kernel, within a second it will be overwritten by the full offset time.
So my conclusion is, there is some broken drifting clock in Dom0 or in
hypervisor (which is not visible by user in Dom0) which gets copied to DomU at
least during domU boot and for suse kernel also periodically while domain is
running.
OMFG, what a terrible mess !!!
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.