From owner-svn-src-all@FreeBSD.ORG  Wed Apr 13 22:27:47 2011
Return-Path: <owner-svn-src-all@FreeBSD.ORG>
Delivered-To: svn-src-all@freebsd.org
Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28])
	by hub.freebsd.org (Postfix) with ESMTP id 1E2471065673;
	Wed, 13 Apr 2011 22:27:47 +0000 (UTC)
	(envelope-from jkim@FreeBSD.org)
From: Jung-uk Kim <jkim@FreeBSD.org>
To: Dimitry Andric <dim@freebsd.org>
Date: Wed, 13 Apr 2011 18:27:36 -0400
User-Agent: KMail/1.6.2
References: <201104122349.p3CNn7kK039179@svn.freebsd.org>
	<4DA6189A.5040200@FreeBSD.org> <4DA61A70.8040609@FreeBSD.org>
In-Reply-To: <4DA61A70.8040609@FreeBSD.org>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201104131827.39373.jkim@FreeBSD.org>
Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org,
	src-committers@freebsd.org
Subject: Re: svn commit: r220584 - in head/sys: amd64/amd64 i386/i386
X-BeenThere: svn-src-all@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SVN commit messages for the entire src tree \(except for &quot;
	user&quot; and &quot; projects&quot; \)" <svn-src-all.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-all>,
	<mailto:svn-src-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-src-all>
List-Post: <mailto:svn-src-all@freebsd.org>
List-Help: <mailto:svn-src-all-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-all>,
	<mailto:svn-src-all-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 22:27:47 -0000

On Wednesday 13 April 2011 05:49 pm, Dimitry Andric wrote:
> On 2011-04-13 23:41, Dimitry Andric wrote:
> ...
>
> > But I don't really see why, yet. :)  With r220532, it worked
> > fine.
>
> Ah, I failed to notice the commit that came before, r220583.
> Apparently, it can happen (at least in a VM environment) that the
> DELAY(1000) in this fragment from cpu_est_clockrate():
>
>                  wrmsr(MSR_MPERF, 0);
>                  wrmsr(MSR_APERF, 0);
>                  tsc1 = rdtsc();
>                  DELAY(1000);
>                  mcnt = rdmsr(MSR_MPERF);
>                  acnt = rdmsr(MSR_APERF);
>                  tsc2 = rdtsc();
>                  intr_restore(reg);
>                  perf = 1000 * acnt / mcnt;
>
> will still read 0 from MSR_MPERF, leading to a division by zero. 
> Maybe just fallback to the second method in the 'else' branch then?

That means your VM has broken CPUID support.  To get there, it has to 
meet two conditions, i.e., TSC is invariant and it has APERF/MPERF 
MSRs.  A simple workaround is setting "machdep.disable_tsc=1" 
tuanable from loader but your VM is the real culprit here.

Jung-uk Kim