From owner-freebsd-current@FreeBSD.ORG Fri May 11 03:18:49 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 C458516A400 for ; Fri, 11 May 2007 03:18:49 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id B166213C46E for ; Fri, 11 May 2007 03:18:49 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 5C4D41A3C19; Thu, 10 May 2007 20:19:34 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id F3F3D513C6; Thu, 10 May 2007 23:18:48 -0400 (EDT) Date: Thu, 10 May 2007 23:18:48 -0400 From: Kris Kennaway To: Garrett Cooper Message-ID: <20070511031848.GA81680@xor.obsecurity.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4643DF94.8010508@u.washington.edu> User-Agent: Mutt/1.4.2.2i 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:18:49 -0000 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). Kris