From owner-freebsd-stable@FreeBSD.ORG Mon Mar 19 06:26:39 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8480A106566C; Mon, 19 Mar 2012 06:26:39 +0000 (UTC) (envelope-from adams-freebsd@ateamsystems.com) Received: from fss.sandiego.ateamservers.com (fss.sandiego.ateamservers.com [69.55.229.149]) by mx1.freebsd.org (Postfix) with ESMTP id 656228FC0A; Mon, 19 Mar 2012 06:26:39 +0000 (UTC) Received: from [192.168.15.220] (unknown [118.175.84.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by fss.sandiego.ateamservers.com (Postfix) with ESMTPSA id 9F639B9066; Mon, 19 Mar 2012 02:20:31 -0400 (EDT) Message-ID: <4F66D033.9050103@ateamsystems.com> Date: Mon, 19 Mar 2012 13:20:35 +0700 From: Adam Strohl Organization: A-Team Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Steve Wills References: <4F5B0BB5.5010406@ateamsystems.com> <6D0B99CE-AE11-4250-A8D9-EF66E03E19BB@lists.zabbadoz.net> <4F5B5DAB.3010905@ateamsystems.com> <4F662B38.4030700@FreeBSD.org> In-Reply-To: <4F662B38.4030700@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , FreeBSD-Stable ML Subject: Re: Time Clock Stops in FreeBSD 9.0 guest running under ESXi 5.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 06:26:39 -0000 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 clamped at 500 ppm; to make the > clock appear to stop it would have to steer at 1e6 ppm. I've always > assumed that VM guest services daemons that handle timekeeping use the > same ntp_adjtime() interface to the kernel timekeeping that ntpd itself > uses, so the same steering limits would apply. An excellent point. > > If it happens again, interesting data might be found in the output of: > > sysctl kern.timecounter > sysctl kern.eventtimer > vmstat -i > ntpdc -c kerninfo > Will do, I know there was nothing in dmesg, I will definitely check all of this though if/when it happens again. I just brought up another ESXi 5.0 host with FreeBSD 9.0 VMs (created from dump/restore from the existing ones), so there is an increased chance of me seeing this hopefully and getting to the bottom of it. Or it never happens again :P On 3/19/2012 1:36, Steve Wills wrote: > I've experienced something similar once or twice with ESXi 5.0. The > second time it happened, I found that kern.timecounter.tc.HPET.counter > stopped changing. I was told on IRC that this indicated a "hardware" > problem, which I took to indicate a possible bug in ESXi. I haven't > upgraded to ESXi 5.0 Update 1 yet to see if that changes anything. > Rebooting of course fixed it, it has been a while since this happened > and it hasn't happened again since so I haven't pursued it. Just another > data point, hope it hopes. Thanks for the info! I didn't realize there was an update out already for 5.0 (I don't see it on VMWare's site).