---
On Aug 3, 2012, at 3:59 AM, Adam Strohl wrote:
> Doh, correct URL for the forum post is:
> http://forums.freebsd.org/showthread.php?t=31929&page=2
>
> On 8/3/2012 14:38, Adam Strohl wrote:
>> Just a heads up on the original issue, which is FreeBSD's timer/clock
>> stopping under ESXi 5.0
Doh, correct URL for the forum post is:
http://forums.freebsd.org/showthread.php?t=31929&page=2
On 8/3/2012 14:38, Adam Strohl wrote:
Just a heads up on the original issue, which is FreeBSD's timer/clock
stopping under ESXi 5.0 and some later versions of VMware Workstation.
I've gotten a few di
Just a heads up on the original issue, which is FreeBSD's timer/clock
stopping under ESXi 5.0 and some later versions of VMware Workstation.
I've gotten a few direct messages that this thread ranks high on Google
but people are missing the solution. A few months ago I found this
forum posting
> 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
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. In the first case I saw a jump backwards of about 15
minut
18 matches
Mail list logo
