Date: Thu, 10 May 2007 13:28:16 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Darren Reed <darrenr@hub.freebsd.org> Cc: hackers@freebsd.org Subject: Re: Experiences with 7.0-CURRENT and vmware. Message-ID: <20070510132153.A91312@fledge.watson.org> In-Reply-To: <20070510111326.GA94093@hub.freebsd.org> References: <20070510111326.GA94093@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 10 May 2007, Darren Reed wrote: > I'm using FreeBSD 7.0-CURRENT under vmware and there are a few issues. Generally speaking, I would suggest sending this post to current@, not hackers@, since your comments largely have to do between differences between -STABLE and -CURRENT, making it ideal fodder for the mailing list dedicated to -CURRENT development. > 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. > 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@ might help resolve that. > 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? 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). 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 was recently a rather large overhaul of the if_em driver in 7.x--I suggest e-mailing Jack Vogel (jfv) who is bother a FreeBSD committer and the Intel employee responsible for the if_em driver. He may rightly point out that this isn't real hardware, rather, virtual hardware, and therefore not supported by Intel, but it might also be that the new version of the driver contains a bug, there's an ACPI issue of some sort, etc. > Apart from these two issues (which are very central ones :-(), I'm using > FreeBSD in a 64bit vmware workstation environment quick successfully and ZFS > is quite happy with all the kva :-) ZFS and zpools are working just as I > expect, even if a bit slower due to vmware but I'm not cranking out > benchmarks here. > > Oh, and how do I fix ssh/rsh to do passwordless sessions? I'm trying to > setup cron jobs to automate various tasks but there's this small hurdle > called a password prompt that I can't seem to get rid of :-/ 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. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070510132153.A91312>