From owner-freebsd-current@FreeBSD.ORG Fri May 11 07:45:35 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BFE6E16A403 for ; Fri, 11 May 2007 07:45:35 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) by mx1.freebsd.org (Postfix) with ESMTP id 9BC1813C469 for ; Fri, 11 May 2007 07:45:35 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l4B7jYBl010517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2007 00:45:35 -0700 X-Auth-Received: from [192.168.10.45] (c-67-187-164-17.hsd1.ca.comcast.net [67.187.164.17]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l4B7jYml010573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 May 2007 00:45:34 -0700 Message-ID: <46441F1B.9000707@u.washington.edu> Date: Fri, 11 May 2007 00:45:31 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Kris Kennaway References: <20070510111326.GA94093@hub.freebsd.org> <20070510132153.A91312@fledge.watson.org> <20070510125445.GA5460@hub.freebsd.org> <20070510194144.GA66798@xor.obsecurity.org> <20070510204448.GB73840@hub.freebsd.org> <20070510211655.GA67752@xor.obsecurity.org> <4643DF94.8010508@u.washington.edu> <20070511031848.GA81680@xor.obsecurity.org> <4643E1E2.1060702@u.washington.edu> <20070511033014.GA82291@xor.obsecurity.org> In-Reply-To: <20070511033014.GA82291@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.5.11.2334 X-Uwash-Spam: Gauge=XI, Probability=11%, Report='URI_HOSTNAME_CONTAINS_EQUALS 1, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_BADTHINGS 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: current@freebsd.org Subject: Re: Experiences with 7.0-CURRENT and vmware. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2007 07:45:35 -0000 Kris Kennaway wrote: > On Thu, May 10, 2007 at 08:24:18PM -0700, Garrett Cooper wrote: >> Kris Kennaway wrote: >>> On Thu, May 10, 2007 at 08:14:28PM -0700, Garrett Cooper wrote: >>>> Kris Kennaway wrote: >>>>> On Thu, May 10, 2007 at 08:44:48PM +0000, Darren Reed wrote: >>>>>> On Thu, May 10, 2007 at 03:41:44PM -0400, Kris Kennaway wrote: >>>>>>> On Thu, May 10, 2007 at 12:54:45PM +0000, Darren Reed wrote: >>>>>> ... >>>>>>>> In another reply it was "hint.apic.0.disabled=1". >>>>>>>> My current loader.conf: >>>>>>>> >>>>>>>> vm.kmem_size=536870912 >>>>>>>> vm.kmem_size_max=536870912 >>>>>>>> unset acpi_load >>>>>>> acpi_load="NO" to disable the module >>>>>>> >>>>>>>> hint.acpi.0.disabled=1 >>>>>>>> hint.apci.0.disabled=1 >>>>>>> dunno what apci does :) >>>>>>> >>>>>>>> hint.acpi.0.disabled="1" >>>>>>> This is the one that should work. Can you confirm that you see it in >>>>>>> the loader environment by doing 'show'? >>>>>> ok. I modified my loader.conf to be: >>>>>> >>>>>> hint.acpi.0.disabled="1" >>>>>> vm.kmem_size=536870912 >>>>>> vm.kmem_size_max=536870912 >>>>>> vfs.zfs.arc_max=402653184 >>>>>> >>>>>> and now ACPI is didsabled when the kernel boots :-) >>>>>> >>>>>> Is it possible for parsing errors of this file to generate errors? >>>>>> And maybe pause for a few seconds so they can be read? >>>>> I guess all things are possible with forth. >>>>> >>>>>> When I was modifying the loader.conf, I was looking for errors on >>>>>> bootup but regarding getting acpi vs apci vs apic right, I never >>>>>> saw any. My experience also tells me that errors seem to quietly >>>>>> stop the rest of the file being parsed or...? >>>>>> >>>>>>>> # sysctl kern.timecounter.hardware="ACPI-fast" >>>>>>>> kern.timecounter.hardware: ACPI-safe >>>>>>>> sysctl: kern.timecounter.hardware: Invalid argument >>>>>>> kern.timecounter.choice >>>>>> When I tried to set this with sysctl, I got told it was read-only. >>>>>> The next step was to put it in loader.conf but now ACPI *is* disabled :) >>>>> Sorry, .hardware was the correct one. I don't know why you are unable >>>>> to set it at runtime: >>>>> >>>>> xor# sysctl kern.timecounter.hardware=TSC >>>>> kern.timecounter.hardware: ACPI-fast -> TSC >>>>> xor# sysctl kern.timecounter.hardware=ACPI-fast >>>>> kern.timecounter.hardware: TSC -> ACPI-fast >>>>> >>>>> Kris >>>> I'm not sure why but it isn't settable with VMWare 1.03 server either. >>> Maybe there are no other valid choices provided by vmware. >>> >>>> I gave the Intel ACPI one a shot though and I haven't seen any adverse >>>> effects.. yet. It is true that the higher the number, the faster the >>>> synchronization or the inverse? >>> It's a "quality factor" that tries to estimate and rank the various >>> properties of time counters (higher = better). >> Basically sample rate? > > I think things like accuracy, query cost, stability. > > Kris > Clock skew is a really big issue with VMWare and multiple cores. I'm running amd64, and I've noticed that if I don't sync the clocks regularly and run CPU intensive compiles, the clocks will skew a lot (10~30 minutes if running buildworld over a 1.5 hour period), and when I try and reboot the machine it fails to notify the running daemons that they need to be killed. For now I'm switching my VM back to single core, but it should be noted that this is a big issue and multicore vmware should not be tried (at least with FreeBSD, as much as other OSes), because of the realtime clock syncing problem. -Garrett