Re: Experiences with 7.0-CURRENT and vmware.

On Thu, 10 May 2007, Darren Reed wrote:

>>> First, time. hint.hw.acpi.disabled="1" This appears to make _no_ 
>>> difference to time keeping on FreeBSD 7 and nor does it seem to have any 
>>> impact on ACPI being loaded.  Do I need to recompile a new kernel without 
>>> it or is there a new way to disable ACPI?
>>
>> Have you tried hint.acpi.0.disabled=1 instead?  This is what appears in 
>> acpi(4), and is what is used in various existing boot loader bits when I 
>> grep around.
>
> In another reply it was "hint.apic.0.disabled=1".

That would be to disable the APIC, but you asked about disabling ACPI.

> My current loader.conf:
>
> vm.kmem_size=536870912
> vm.kmem_size_max=536870912
> unset acpi_load
> hint.acpi.0.disabled=1
> hint.apci.0.disabled=1
> hint.acpi.0.disabled="1"
> hint.apci.0.disabled="1"
> vfs.zfs.arc_max=402653184
>
> Booting with this gives me:
> kernel: Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000
>
> and ACPI enabled.

When I put:

   hint.acpi.0.disabled="1"

into my device.hints, ACPI isn't loaded, and "sysctl hw.acpi" returns that the 
node isn't present.  Could you try doing exactly that, and test to see if 
"sysctl hw.acpi" returns anything or not?  When I do this, the ACPI 
timecounter disappears, and Parallels (what I use for virtualization) switches 
to TSC from the ACPI timer.

>>> I should add that FreeBSD 6, with the same setting, is no better and that
>>> I need to run ntpdate every 5-10 minutes via crontab in order to keep good
>>> time (timekeeping is *really* bad.)  In one instance, i was watching
>>> "zpool iostat 1" and it appeared like the rows were muching up at a rate
>>> of 2 a second for a minute or so. How do I disable TSC timekeeping?
>>> (NetBSD has this disabled by default in their kernels.)  Or is there
>>> somethign else I must do?
>>
>> kern.timecounter.hardware: ACPI-fast
>> kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-1000000)
>>
>> I believe you can simply set kern.timecounter.hardware=APCI-fast and it
>> will do what you expect.  An interesting question is why it selects what is
>> arguably the wrong one; a post to current_at_ might help resolve that.
>
> Hmm.
>
> # sysctl kern.timecounter.hardware="ACPI-fast"
> kern.timecounter.hardware: ACPI-safe
> sysctl: kern.timecounter.hardware: Invalid argument
>
> Or is this a loader.conf setting?

Sorry, you need to set kern.timecounter.choice to set it, I had it backwards.

>>> Second, networking. Prior to FreeBSD-7, the driver to use inside vmware 
>>> workstation was lnc.  It has worked and contiues to work great.  No 
>>> problemo. FreeBSD-7 uses the "em" driver.  To put it simply, it sucks in 
>>> comparison.  When things really get bad I start seeing "em0: watchdog 
>>> timeout" messages on the console.  I looked and I don't see a lnc driver 
>>> anywhere.  Is there another alternative (le?) driver that I can use in 
>>> place of em, if so, how?
>>
>> Has VMware changed what network hardware they emulate, and/or does VMware 
>> offer options about what virtual hardware to expose?
>
> I don't believe so.  It still probes as pcn under NetBSD.
>
>> The if_em driver is for Intel ethernet cards; historically VMware has 
>> exposed a Lance ethernet device supported by the lnc(4) device driver; now 
>> that driver has indeed been replaced with le(4).
>
> Right.  I believe it still is lance, but somehow em is showing up.

That's pretty odd.  What appears in pciconf -lv?

>> But if if_em is probing, it suggests a VMware change rather than a FreeBSD 
>> change, which you may be able to revert by telling it to expose a 
>> Lance-style device as opposed to an Intel device.
>
> There's no way to choose the type of card vmware emulates.
>
>> Generally speaking, this would be a discouraged configuration, but you will 
>> probably need to frob two settings: first, PermitEmptyPasswords in 
>> sshd_config, and second, force non-PAM validation by setting UsePAM to 
>> false. Instead of doing this, I would advise instead setting up an SSH key 
>> for the account, and not set a passphrase on the SSH key.  This doesn't 
>> require any changing of the global sshd configuration and should offer most 
>> of the same benefits.
>
> btw, there are instances where you can be promopted 6 times for a password 
> when logging in with ssh, 3 times with "Password:" prompt and another three 
> with "root_at_hostname's password:" promopt.

That's probably SSH trying PAM and then SSH password authentication.  Have you 
enabled SSH PasswordAuthentication in sshd_config as well as PAM?

Robert N M Watson
Computer Laboratory
University of Cambridge