From owner-freebsd-current@FreeBSD.ORG Fri May 11 03:14:31 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 3FBC616A403 for ; Fri, 11 May 2007 03:14:31 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by mx1.freebsd.org (Postfix) with ESMTP id 1B26A13C480 for ; Fri, 11 May 2007 03:14:31 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l4B3EUsT021172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 10 May 2007 20:14:30 -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 l4B3ETlP012023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 10 May 2007 20:14:30 -0700 Message-ID: <4643DF94.8010508@u.washington.edu> Date: Thu, 10 May 2007 20:14:28 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 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> In-Reply-To: <20070510211655.GA67752@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.10.195834 X-Uwash-Spam: Gauge=XI, Probability=11%, Report='URI_HOSTNAME_CONTAINS_EQUALS 1, __CT 0, __CTE 0, __CT_TEXT_PLAIN 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 03:14:31 -0000 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. 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? Thanks, -Garrett