Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0
freebsd at damnhippie.dyndns.org
Thu Mar 22 16:34:41 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."
More information about the freebsd-stable