Date: Thu, 22 Mar 2012 10:34:32 -0600 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: Volodymyr Kostyrko <c.kworr@gmail.com> Cc: Mike, freebsd-stable@freebsd.org, Andriy Gapon <avg@freebsd.org>, Tkachuk <mike@tkachuk.name> Subject: Re: Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0 Message-ID: <1332434072.8403.79.camel@revolution.hippie.lan> In-Reply-To: <4F6B4FAB.1020202@gmail.com> References: <1977769407.20120322151934@tkachuk.name> <4F6B4030.5090907@FreeBSD.org> <4F6B4631.8020006@gmail.com> <4F6B4B93.7020309@FreeBSD.org> <4F6B4FAB.1020202@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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." -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1332434072.8403.79.camel>