From owner-svn-src-all@FreeBSD.ORG Wed Apr 13 22:33:12 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D5EB106566C; Wed, 13 Apr 2011 22:33:12 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5375F8FC1B; Wed, 13 Apr 2011 22:33:12 +0000 (UTC) Received: by pvg11 with SMTP id 11so509321pvg.13 for ; Wed, 13 Apr 2011 15:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8CRJjfKZGWa38j7BDGDJA3Ngs+n3twg4GDFgUITCHms=; b=iRG09tqT8XlzUPoepGpi+/nx8UIw61UlxyMSEzoy+WQdZe1eJipxSVHbC/wyddP2Py NRta0KyWWwH9FY9lMpOwzAEsLVJVCpsPyjKqU5V2AfRmpqxxyWb3UDC2yOMSMe9QFiVp Mh4rZhfvHTVIss0qom/zSxA0DXJKIRU2K+a9Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xyXf7KuZryB02xBze3rk922CRbVneQGmQymgCrcJI8iFxTkZdhPzqeZIwyztevH/K/ rabLwXxmsejchQ7L2XzHcEadehsr6/r6cPxNNkf+kwWD5a/X3OMz80sE0nGsK3RZrkWc MroFc7kGuhTQ0njW65w9crV68nlBTZ0FJ4Cmw= MIME-Version: 1.0 Received: by 10.142.237.20 with SMTP id k20mr27010wfh.170.1302733991682; Wed, 13 Apr 2011 15:33:11 -0700 (PDT) Received: by 10.68.42.3 with HTTP; Wed, 13 Apr 2011 15:33:11 -0700 (PDT) In-Reply-To: <201104131827.39373.jkim@FreeBSD.org> References: <201104122349.p3CNn7kK039179@svn.freebsd.org> <4DA6189A.5040200@FreeBSD.org> <4DA61A70.8040609@FreeBSD.org> <201104131827.39373.jkim@FreeBSD.org> Date: Wed, 13 Apr 2011 15:33:11 -0700 Message-ID: From: Garrett Cooper To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Dimitry Andric 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 " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 22:33:12 -0000 On Wed, Apr 13, 2011 at 3:27 PM, Jung-uk Kim wrote: > 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. :) =A0With 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(): >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wrmsr(MSR_MPERF, 0); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wrmsr(MSR_APERF, 0); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tsc1 =3D rdtsc(); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DELAY(1000); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mcnt =3D rdmsr(MSR_MPERF); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0acnt =3D rdmsr(MSR_APERF); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tsc2 =3D rdtsc(); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0intr_restore(reg); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0perf =3D 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. =A0To get there, it has to > meet two conditions, i.e., TSC is invariant and it has APERF/MPERF > MSRs. =A0A simple workaround is setting "machdep.disable_tsc=3D1" > tuanable from loader but your VM is the real culprit here. VMware ESXi lies on multiple fronts in this area I've discovered lately at $WORK, in particular the SMBIOS / FreeBSD are calling CPUID which is returning info based on the host processor instead of the emulated guest processor, which in turn is causes minor problems in our software. Example being that the host processor is a Intel Woodcrest CPU (this is what an in-house tool and FreeBSD reports) instead of a Pentium Pro emulated CPU (that's what dmidecode reports and that's what ESXi emulates). Wasn't happy about this breakage and someone should probably talk to VMware about fixing their emulation software so that it tells a consistent story across the board. Thanks, -Garrett