> 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 mig
Andriy Gapon wrote:
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.
What exactly you wouldn't recommend?
Let's not introduce unrelated
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
on 22/03/2012 18:13 Volodymyr Kostyrko said the following:
> 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 h
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 co
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
>>
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 H
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.
--
Andriy Gapon
___
freebsd-stabl
Hello Ian,
I'm also facing same problem, just updated to esxi 5 update1, will
see if it changes anything.
It really looks like an esxi problem but I did not experienced it
with FreeBSD 8
Here is the output of requested commands:
sysctl kern.timecounter
kern.timecounter.tick: 1
ker
On 3/12/2012 0:01, Ian Lepore wrote:
> It seems unlikely to me that ntpd and the vm tools would be fighting in
> a way that caused this symptom. The way ntpd affects timing is to step
> the clock (which gets logged), or to numerically steer the kernel's
> timekeeping routines. The steering is cl
On 03/10/12 08:56, Adam Strohl wrote:
> On 3/10/2012 17:10, Bjoern A. Zeeb wrote:
>> On 10. Mar 2012, at 08:07 , Adam Strohl wrote:
>>
>>> I've now seen this on two different VMs on two different ESXi servers
>>> (Xeon based hosts but different hardware otherwise and at different
>>> facilities):
>
On Sat, 2012-03-10 at 15:07 +0700, Adam Strohl wrote:
> I've now seen this on two different VMs on two different ESXi servers
> (Xeon based hosts but different hardware otherwise and at different
> facilities):
>
> Everything runs fine for weeks then (seemingly) suddenly/randomly the
> clock ST
On 3/10/2012 17:10, Bjoern A. Zeeb wrote:
On 10. Mar 2012, at 08:07 , Adam Strohl wrote:
I've now seen this on two different VMs on two different ESXi servers (Xeon
based hosts but different hardware otherwise and at different facilities):
Everything runs fine for weeks then (seemingly) sudde
On 10. Mar 2012, at 08:07 , Adam Strohl wrote:
> I've now seen this on two different VMs on two different ESXi servers (Xeon
> based hosts but different hardware otherwise and at different facilities):
>
> Everything runs fine for weeks then (seemingly) suddenly/randomly the clock
> STOPS.
Apa
14 matches
Mail list logo
