I'm running VMware Server 1.0.6 on a CentOS 5.2 host and am having some clock difficulties.
Host OS is x86_64 running on 1.9 GHz AMD Sempron, nVidia chipset.
Guest OS's are 32-bit FreeBSD (clock works fine after disabling ACPI, setting the clock source to the PIT, and running the guest tools), WinXP (unknown clock status), and i686 CentOS 5.2 (here is the problem).
I've tried pretty much everything to try to fix it. I have host.cpukHz, host.noTSC, and ptsc.noTSC set in /etc/vmware/config. I've booted my kernel with noapic, nosmp, noacpi, divider=10. Sadly, I hit the clocksource=pit with divider bug, so I have not been able to boot with both that and divider=10, although clocksource=pit without a divider also does not work. I even built a custom kernel with SMP and APIC disabled, CPU_HZ=100, and booted with clocksource=pit noacpi, and it also gains time.
Could anyone provide a recommendation as to what I can do to fix this problem?
On Tue, Aug 19, 2008 at 5:55 PM, Michael Ekstrand michael@elehack.net wrote:
I'm running VMware Server 1.0.6 on a CentOS 5.2 host and am having some clock difficulties.
Host OS is x86_64 running on 1.9 GHz AMD Sempron, nVidia chipset.
Guest OS's are 32-bit FreeBSD (clock works fine after disabling ACPI, setting the clock source to the PIT, and running the guest tools), WinXP (unknown clock status), and i686 CentOS 5.2 (here is the problem).
I've tried pretty much everything to try to fix it. I have host.cpukHz, host.noTSC, and ptsc.noTSC set in /etc/vmware/config. I've booted my kernel with noapic, nosmp, noacpi, divider=10. Sadly, I hit the clocksource=pit with divider bug, so I have not been able to boot with both that and divider=10, although clocksource=pit without a divider also does not work. I even built a custom kernel with SMP and APIC disabled, CPU_HZ=100, and booted with clocksource=pit noacpi, and it also gains time.
Could anyone provide a recommendation as to what I can do to fix this problem?
I understand you built a 100Hz kernel, but *just in case*, you might want to try CentOS-supplied 100Hz kernel (kernel-vm) available from:
http://people.centos.org/tru/kernel-vm/
Also, enable time sync with host if that has not been done.
Akemi
"Akemi Yagi" amyagi@gmail.com writes:
On Tue, Aug 19, 2008 at 5:55 PM, Michael Ekstrand michael@elehack.net wrote:
I'm running VMware Server 1.0.6 on a CentOS 5.2 host and am having some clock difficulties.
Host OS is x86_64 running on 1.9 GHz AMD Sempron, nVidia chipset.
Guest OS's are 32-bit FreeBSD (clock works fine after disabling ACPI, setting the clock source to the PIT, and running the guest tools), WinXP (unknown clock status), and i686 CentOS 5.2 (here is the problem).
I've tried pretty much everything to try to fix it. I have host.cpukHz, host.noTSC, and ptsc.noTSC set in /etc/vmware/config. I've booted my kernel with noapic, nosmp, noacpi, divider=10. Sadly, I hit the clocksource=pit with divider bug, so I have not been able to boot with both that and divider=10, although clocksource=pit without a divider also does not work. I even built a custom kernel with SMP and APIC disabled, CPU_HZ=100, and booted with clocksource=pit noacpi, and it also gains time.
Could anyone provide a recommendation as to what I can do to fix this problem?
I understand you built a 100Hz kernel, but *just in case*, you might want to try CentOS-supplied 100Hz kernel (kernel-vm) available from:
Just tried it, and it doesn't seem to work. I used the following parameters:
nosmp noapic nolapic noacpi clocksource=pit
Also, enable time sync with host if that has not been done.
Already done, and was active throughout the problems described above.
I seem to remember seeing somewhere or another something about a different set of timing devices available on 64-bit vs. 32-bit. When I was previously using 32-bit Debian Etch as the host OS on this same hardware with an upgraded (2.6.22) kernel, I had no noticable timing problems on the FreeBSD guest (didn't run Linux guests enough to notice anything). After switching to 64-bit CentOS host OS, the FreeBSD guest clock started running fast, but it responded to adjustments and keeps in line with the setup described above. Is it possible that running the 64-bit host environment is what is causing my problems? Are there host options I can tweak to try to improve the situation?
- Michael
On Wed, Aug 20, 2008 at 5:37 AM, Michael Ekstrand michael@elehack.net wrote:
"Akemi Yagi" amyagi@gmail.com writes:
I understand you built a 100Hz kernel, but *just in case*, you might want to try CentOS-supplied 100Hz kernel (kernel-vm) available from:
Just tried it, and it doesn't seem to work. I used the following parameters:
nosmp noapic nolapic noacpi clocksource=pit
Also, enable time sync with host if that has not been done.
Already done, and was active throughout the problems described above.
I seem to remember seeing somewhere or another something about a different set of timing devices available on 64-bit vs. 32-bit.
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
will show you available options. It is different between 32-bit and 64-bit.
was previously using 32-bit Debian Etch as the host OS on this same hardware with an upgraded (2.6.22) kernel, I had no noticable timing problems on the FreeBSD guest (didn't run Linux guests enough to notice anything). After switching to 64-bit CentOS host OS, the FreeBSD guest clock started running fast, but it responded to adjustments and keeps in line with the setup described above. Is it possible that running the 64-bit host environment is what is causing my problems? Are there host options I can tweak to try to improve the situation?
On the *host* side, you can try disabling power management and other things. For example:
apm=off acpi=off noapic
Akemi
- Michael
On Wed, Aug 20, 2008 at 07:37:25AM -0500, Michael Ekstrand wrote:
"Akemi Yagi" amyagi@gmail.com writes:
On Tue, Aug 19, 2008 at 5:55 PM, Michael Ekstrand michael@elehack.net wrote:
I'm running VMware Server 1.0.6 on a CentOS 5.2 host and am having some clock difficulties.
Host OS is x86_64 running on 1.9 GHz AMD Sempron, nVidia chipset.
Guest OS's are 32-bit FreeBSD (clock works fine after disabling ACPI, setting the clock source to the PIT, and running the guest tools), WinXP (unknown clock status), and i686 CentOS 5.2 (here is the problem).
I've tried pretty much everything to try to fix it. I have host.cpukHz, host.noTSC, and ptsc.noTSC set in /etc/vmware/config. I've booted my kernel with noapic, nosmp, noacpi, divider=10. Sadly, I hit the clocksource=pit with divider bug, so I have not been able to boot with both that and divider=10, although clocksource=pit without a divider also does not work. I even built a custom kernel with SMP and APIC disabled, CPU_HZ=100, and booted with clocksource=pit noacpi, and it also gains time.
Could anyone provide a recommendation as to what I can do to fix this problem?
I understand you built a 100Hz kernel, but *just in case*, you might want to try CentOS-supplied 100Hz kernel (kernel-vm) available from:
Just tried it, and it doesn't seem to work. I used the following parameters:
nosmp noapic nolapic noacpi clocksource=pit
IIRC clocksource=pit should not be used on modern kernels..
Can you try clocksource=acpi_pm ? with tools.synctime = "true" flag in your vmx file.
(if it's available in your kernel).
There was some nice summary about different clocksource= options etc and in what kernels do they work.. just can't remember the url now.
-- Pasi
Pasi Kärkkäinen pasik@iki.fi writes:
On Wed, Aug 20, 2008 at 07:37:25AM -0500, Michael Ekstrand wrote:
"Akemi Yagi" amyagi@gmail.com writes:
On Tue, Aug 19, 2008 at 5:55 PM, Michael Ekstrand michael@elehack.net wrote:
I'm running VMware Server 1.0.6 on a CentOS 5.2 host and am having some clock difficulties.
Host OS is x86_64 running on 1.9 GHz AMD Sempron, nVidia chipset.
Guest OS's are 32-bit FreeBSD (clock works fine after disabling ACPI, setting the clock source to the PIT, and running the guest tools), WinXP (unknown clock status), and i686 CentOS 5.2 (here is the problem).
I've tried pretty much everything to try to fix it. I have host.cpukHz, host.noTSC, and ptsc.noTSC set in /etc/vmware/config. I've booted my kernel with noapic, nosmp, noacpi, divider=10. Sadly, I hit the clocksource=pit with divider bug, so I have not been able to boot with both that and divider=10, although clocksource=pit without a divider also does not work. I even built a custom kernel with SMP and APIC disabled, CPU_HZ=100, and booted with clocksource=pit noacpi, and it also gains time.
Could anyone provide a recommendation as to what I can do to fix this problem?
I understand you built a 100Hz kernel, but *just in case*, you might want to try CentOS-supplied 100Hz kernel (kernel-vm) available from:
Just tried it, and it doesn't seem to work. I used the following parameters:
nosmp noapic nolapic noacpi clocksource=pit
IIRC clocksource=pit should not be used on modern kernels..
Can you try clocksource=acpi_pm ? with tools.synctime = "true" flag in your vmx file.
(if it's available in your kernel).
I tried, and the clock still gains time. Just took a few minutes for it to gain a second or two. I'll try disabling host power management sometime here when I feel like rebooting.
- Michael
Michael Ekstrand michael@elehack.net writes:
I tried, and the clock still gains time. Just took a few minutes for it to gain a second or two. I'll try disabling host power management sometime here when I feel like rebooting.
Disabling ACPI and APM in the host OS had the unfortunate result of causing it to cease to communicate with the SATA chipset. Therefore, that solution did not work.
I have, however, found a combination that seems to be stable. I disabled Cool & Quiet in BIOS -- evidently setting the CPU frequency governor to `performance' was not adequate. Combining this with the el5vm kernel with "noacpi nosmp noapic nolapic clocksource=pit" in the guest seems to work.
- Michael