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

[Xen-users] RE: [Xen-devel] Xen 4 TSC problems

It’s very unlikely this is a problem with TSC. It is most likely a Xen (or possibly a PV Linux) problem where a guest (or dom0) either “goes out to lunch” for a long period, or some other timer gets stuck.  The “clocksource tsc unstable” message is a side effect of this... it’s very likely the TSC that IS stable and correct and the other clocksource (pvclock) has lost/gained 50 minutes!


Mark Adams cc’ed and his original xen-devel posting below.  The fact that two different users (possibly on the same processor/system type?) have submitted the message with a delta so similar would lead me to believe there is some timer that is “wrapping”.  And since pvclock is usually the clocksource for dom0, and pvclock is driven! by Xen’s “system time”, a reasonable guess is that the timer that is wrapping is in Xen itself.


Mark’s delta = -2999660303788 ns

Your delta = -2999660334211 ns


Googling, I see the HPET wraparound is ~306 seconds and this delta is about 3000 seconds, so that may be a bad guess.


Keir, any thoughts on this?  Do you recall any post-4.0 patches that may have fixed this?









From: Olivier Hanesse [mailto:olivier.hanesse@xxxxxxxxx]
Sent: Wednesday, February 23, 2011 3:50 AM
To: xen-devel@xxxxxxxxxxxxxxxxxx! m; Xen Users
Subject: [Xen-devel] Xen 4 TSC problems




I've got an issue about time keeping with Xen 4.0 (Debian squeeze release). 


My problem is here (hopefully I amn't the only one, so there might be a bug somewhere) : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599161#50

After some times,  I got this error : Clocksource tsc unstable (delta = -2999660334211 ns). It has happened on several servers. 


Looking at the output of "xm debug-key s;"


(XEN) TSC has constant rate, deep Cstates possible, so not reliable, warp=2850 (count=3)


I am using a "Intel(R) Xeon(R) CPU L5420  @ 2.50GHz", which has the "constant_tsc", but not the "nonstop_tsc" one.

On other systems with a newer cpu with "nonstop_tsc", I don't have this issue (systems are running the same distros with same config).


I tried to boot with "max_cstate=0", but nothing changed, my TSC isn't reliable and after some times, I will got the "50min" issue again.


I don't unders! tand how a system can do a jump of "50min" in the future. Why 50min ? it is not 40min, not 1 hour, it is always 50min.

I don't know how to make my TSC "reliable" (I already disable everything about Powerstate in BIOS Settings).


Any ideas ?





Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.