Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0

Daniel Braniss danny at cs.huji.ac.il
Sun Apr 8 09:34:14 UTC 2012


> On Thu, 2012-03-22 at 18:13 +0200, Volodymyr Kostyrko wrote:
> > Andriy Gapon wrote:
> > > on 22/03/2012 17:33 Volodymyr Kostyrko said the following:
> > >> Andriy Gapon wrote:
> > >>> on 22/03/2012 15:19 Mike Tkachuk said the following:
> > >>>> kern.eventtimer.periodic: 0
> > >>>
> > >>> It might make sense to try 1 here.
> > >>> Also you could attempt to involve mav@ directly - here is an author of the code
> > >>> and an expert on it.
> > >>
> > >> Better ask before setting as this doubles hpet0 (with HPET) or cpu0:timer (with
> > >> LAPIC) interrupt rate for me.
> > >
> > > Does it make your system unusable?
> > > Are you comparing with pre-eventtimers version of FreeBSD?
> > 
> > In short term - no. Haven't tested it thoroughly. Results are the same 
> > (double interrupt rate according to `systat 1 -v`) for:
> >   * i386 and amd64 9-STABLE;
> >   * amd64 9.0.
> > 
> > As everything related to timing/freq/acpi can be unpredictive I wouldn't 
> > recommend this to anyone. I own at least two Intel CPU's failing 
> > somewhere near timing/apic when loading cpufreq and enabling powerd.
> > 
> 
> I'm not sure I understand that advice.  We have someone whose system is
> failing (time stops counting) when using the new event timer code.  The
> recommendation is to set kern.eventtimer.periodic=1, which as I
> understand it makes the new code work more like it did before.  That
> seems to be a reasonable attempt to work around the problem.  
> 
> If it works, the system becomes 100% more usable than it is now, even if
> that comes at the cost of timers interrupting twice as fast as they did
> in previous OS releases.  It also generates another datapoint that might
> somehow help track down why the event timer code has trouble on some
> hardware.  Enough such datapoints may eventually lead to an "aha -- it
> happens on all systems that have the xyz chipset."

Just a me too:
but it was running 8.2-stable!
since it's a production machine, I had no choice but to reboot it.
Also the BIOS time got stuck, so I had to fix the time manualy! ntpd doesn't 
like
to advance past a certain delta.

cheers,
	danny





More information about the freebsd-stable mailing list