Date: Sun, 08 Apr 2012 12:34:02 +0300 From: Daniel Braniss <danny@cs.huji.ac.il> To: Ian Lepore <freebsd@damnhippie.dyndns.org> Cc: Volodymyr Kostyrko <c.kworr@gmail.com>, Tkachuk <mike@tkachuk.name>, freebsd-stable@freebsd.org, Andriy Gapon <avg@freebsd.org>, Mike@FreeBSD.ORG Subject: Re: Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0 Message-ID: <E1SGoVX-000EYm-90@kabab.cs.huji.ac.il> In-Reply-To: <1332434072.8403.79.camel@revolution.hippie.lan> References: <1977769407.20120322151934@tkachuk.name> <4F6B4030.5090907@FreeBSD.org> <4F6B4631.8020006@gmail.com> <4F6B4B93.7020309@FreeBSD.org> <4F6B4FAB.1020202@gmail.com> <1332434072.8403.79.camel@revolution.hippie.lan>
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." 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1SGoVX-000EYm-90>