I have a high end IBM system with 4 HT CPUs, am running xen-unstable with only Dom0 active, and I get lots of "Timer ISR/n: Time went backwards" messages. This is a short segment from dmesg: Timer ISR/1: Time went backwards: -259000 4465110000000 9741000 4465120000000 Timer ISR/6: Time went backwards: -224000 4465110000000 9776000 4465120000000 Timer ISR/6: Time went backwards: -159000 4465110000000 9841000 4465120000000 Timer ISR/3: Time went backwards: -145000 4465110000000 9856000 4465120000000 Timer ISR/1: Time went backwards: -161000 4465110000000 9839000 4465120000000 Timer ISR/1: Time went backwards: -51000 4465110000000 9950000 4465120000000 Timer ISR/6: Time went backwards: -25000 4465110000000 9976000 4465120000000 Timer ISR/3: Time went backwards: -40000 4465110000000 9961000 4465120000000 Timer ISR/7: Time went backwards: -9951000 4469140000000 49000 4469150000000 Timer ISR/2: Time went backwards: -9944000 4470150000000 56000 4470160000000 Timer ISR/6: Time went backwards: -9953000 4470550000000 47000 4470560000000 Timer ISR/5: Time went backwards: -9951000 4474600000000 49000 4474610000000 I looked at the archives and noticed this was reported when running under VMware, but I see this happening with only xen and dom0. The system has a Cyclone timer, and I am looking at using the Cyclone timer to avoid the TSC drift, but while it is easy to add to xen, all the cyclone support has been removed from linux. Are there any plans to restore Cyclone or HPET support to linux, and add it to xen, to eliminate this kind of problem? I have some prototype cyclone code added to xen, but have not done anything to Linux yet. -- Don Fry brazilnut@us.ibm.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> I have a high end IBM system with 4 HT CPUs, am running > xen-unstable with only Dom0 active, and I get lots of "Timer > ISR/n: Time went backwards" messages. This is a short > segment from dmesg:> The system has a Cyclone timer, and I am looking at using the > Cyclone timer to avoid the TSC drift, but while it is easy to > add to xen, all the cyclone support has been removed from linux.TSC drift? Are all the CPUs not running off the same bus clock on this system? It sounds like Xen just really isn''t happy on this platform. If you look at the Xen boot messages (''xm dmesg'') does it look like it''s identified the CPU frequecies and local APIC (bus) clock correctly? ian> I have some prototype cyclone code added to xen, but have not > done anything to Linux yet. > > -- > Don Fry > brazilnut@us.ibm.com > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 5 Apr 2005, at 00:40, Don Fry wrote:> I have a high end IBM system with 4 HT CPUs, am running xen-unstable > with only Dom0 active, and I get lots of "Timer ISR/n: Time went > backwards" messages. This is a short segment from dmesg:The errors are coming from the per-vcpu timer interrupt that is only used in SMP guest builds. I can well imagine there are some ''latent correctness issues'' around that code. :-) If you get messages starting ''Timer ISR: Time went backwards'' then that would be morew worrying.> I looked at the archives and noticed this was reported when running > under VMware, but I see this happening with only xen and dom0.That was a different issue, most likely.> Are there any plans to restore Cyclone or HPET support to linux, and > add > it to xen, to eliminate this kind of problem? > > I have some prototype cyclone code added to xen, but have not done > anything to Linux yet.Do HPET/Cyclone actually give greater long-term accuracy than the legacy PIT? The only thing we use the non-local-APIC timer for is to track wallclock time, so if the timers are driven off the same crystal then it doesn''t seem there will be a win. As I recall the HPET allows you to do things like set events to a precision of picoseconds, but it wasn''t clear to me it was actually any more accurate than the PIT. :-) And we can always accumulate the lost precision in setting the PIT registers and periodically add it into the wallclock time. I have no problem with HPET/Cyclone code in Xen *if* it buys us anything. -- Keir> -- > Don Fry > brazilnut@us.ibm.com > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 5 Apr 2005, at 09:28, Keir Fraser wrote:>> I have a high end IBM system with 4 HT CPUs, am running xen-unstable >> with only Dom0 active, and I get lots of "Timer ISR/n: Time went >> backwards" messages. This is a short segment from dmesg: > > The errors are coming from the per-vcpu timer interrupt that is only > used in SMP guest builds. I can well imagine there are some ''latent > correctness issues'' around that code. :-) If you get messages starting > ''Timer ISR: Time went backwards'' then that would be more worrying.Okay, I''ve fixed up the timer code for SMP quite a bit. In particular, secondary cpus were updating shared time information with no locks held. I expect that with the current unstable repository you will no longer see the time-went-backwards messages. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel