Re: Experiences with 7.0-CURRENT and vmware.

On Fri, May 11, 2007 at 12:45:31AM -0700, Garrett Cooper wrote:
> 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.

Didn't someone else address this upthread?

Kris