Problem recap: Under VMWare 5.0 (and 5.5) running on Windows XP Pro sp2, and FreeBSD 6-STABLE running as the guest OS, the system clock for the guest OS runs at exactly 1/2 the rate of the host OS's system clock.
This problem could be worked around by setting hint.apic.0.disabled=1 in /boot/loader.conf Other attempts at working around the problem, including setting kern.hz to something lower than the default 1000 (such as the old default, 100), did not work. Update -- After an upgrade to VMWare 5.5.1 build-19175 and a fresh build of RELENG_6 last week, I've found that setting kern.hz to a lower rate is sufficient to address the problem. Disabling the APIC device is no longer necessary. So, in /boot/loader.conf, I've got: kern.hz=200 and that seems to do the trick. Kudos to whoever made the relevant improvements. For what it's worth, I've experimented with the setting, and found that with the appropriate vmware-guestd installed and running in the FreeBSD 6 guest, the clocks stay properly synched up to kern.hz=596, and from there the guest:host system clockrate ratio degrades more or less linearly from 1:1 to 1:2 as kern.hz is increased from 596 to 1000 (this on a 2.4Ghz p4, ymmv). Logs show the occasional expected error "calcru: runtime went backwards [...] (vmware-guestd)" regardless of kern.hz setting, though they appear to increase in frequency as the kern.hz rate increases, and increase dramatically as the rate of 596 is approached and passed. Anyhoo, my question now is: Why was kern.hz (which I'm guessing is an interrupt frequency for a programmable hardware timer) increased from a default 100 to a default 1000 in FreeBSD 6? And more concretely, should I set this rate as high as I reasonably can? _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
