Upgrade to 6.5.3 causes error relating to high-resolution timer device

[eurgain]

Hello, All

I have just upgraded to 6.5.3 on an OpenSUSE 11.1 host - amd64. Now, evert time I start or resume a VM, I get an error dialog that says: "The host high-resolution timer device (/dev/rtc) is not availabe (Permission Denied).", with a reference to VMWare info ID=34.

The referenced page is not really helpful. On a temporary basis, I have made sure that /dev/rtc0 (symlinked to /dev/rtc) is world read and writable, but this makes no difference.

The oddest thing is that I have never seen this message before the upgrade.

As far as operation of the VM is concerned, a scanner device is not now working reliably, which is particularly annoying since it is the VM's main task.

The machine runs standard OpenSUSE 11.1 AMD-64 (not officially supported but working until now), on a quad-core Core2 with4G ram.

Any thoughts?

A

[sefsinc]

I'm on ubuntu 9.04

[jsa]

Above I posted that I did see this message but did not see any ill effects.

I spoke too soon. I do have high CPU utilization, which seemed manageable until more than one VM was running.

I was about to try the /sys/class/rtc/max_user_freq trick, when I noticed I was still running nohpet on the command line due to vmware problems of several releases ago. So I removed nohpet and left /sys/class/rtc/max_user_freq at 64.

The system seems very stable. No message, no high CPU utilization.

In fact, with two VMs idling, cpu utilization is less than 1% on both cores.

So is it possible hpet was missing from the kernels of folks having problems?

If you don't see something like "Time: hpet clocksource has been installed" in your boot.msg (bootstrap.log) perhaps you have to force that on for this release.

Again, I am using a somewhat dated kernel 2.6.22 on a Dell core .

[sefsinc]

What operating system are you running? What are you saying? That you solved the problem? If so how.

Thanks.

[jsa]

What operating system are you running? What are you saying? That you solved the problem? If so how.

Thanks.

That machine is OpenSuse 10.3.

It had nohpet in the /boot/grub/menu.lst file. I removed it, which on suse means that hpet will be used.

Prior versions of Vmware (5.2 era IIRC) had problems with some dual core machines when hpet was used so I had previously turned that off.

I turned it back on and I see no more error messages. So my suggestion to ubuntu users is try adding

hpet in the boot command line just in case ubuntu does not normally use hpet. All it costs is a reboot

to try.

Also if you are having a problem with a DELL machine you may want to read this thread on Launchpad.

https://bugs.launchpad.net/ubuntu/source/linux/bug/348694

There is a new bios.

[djaquays]

So.. I'm using Suse Enterprise Desktop 10sp2 with the latest kernel (2.6.16.60-0.42.5) and receive this error. You'll see from my boot.msg that hpet is also enabled.

<6>hpet0: at MMIO 0xfed00000 (virtual 0xf8800000), IRQs 2, 8, 0, 0
<6>hpet0: 4 64-bit timers, 14318180 Hz
<4>Using HPET for base-timer

Also, SLED10sp2 does not have a max_user_freq file and infact, no /sys/class/rtc directory at all, though, perhaps just creating one would work, I haven't tried it yet.

[sefsinc]

In /boot/grub on my system I have a file called menu.lst

In it are some entries that look like this

title Ubuntu 9.04, kernel 2.6.28-15-generic

uuid c53e9d5a-14f5-4c64-8f72-4fc167d5551e

kernel /boot/vmlinuz-2.6.28-15-generic root=UUID=c53e9d5a-14f5-4c64-8f72-4fc167d5551e ro splash quiet

initrd /boot/initrd.img-2.6.28-15-generic

quiet

If I wanted to add hpet to the boot command line would it be to the above like so?

title Ubuntu 9.04, kernel 2.6.28-15-generic

uuid c53e9d5a-14f5-4c64-8f72-4fc167d5551e

kernel /boot/vmlinuz-2.6.28-15-generic root=UUID=c53e9d5a-14f5-4c64-8f72-4fc167d5551e ro splash quiet HPET

initrd /boot/initrd.img-2.6.28-15-generic

quiet

Thanks

[jsa]

Lower case hpet

Case matters.

[Neilly]

For the SLED/SLES/openSUSE users the location of the max_user_freq file is /sys/devices/platform/rtc_cmos/rtc/rtc0

However this will not help you - I changed the value from 64 to 1024 and still get the message from vmware that "/dev/rtc" is not accessible due to a permissions problem. The permissions on /dev/rtc are 777. This is a symbolic link to /dev/rtc0 which is a character device with permissions of 444 (read only for everyone). I tried changing the permissions to 666 and this also does not resolve the error message. Note that the error message does not show up right away when starting the vm - for me it displays only after I enter my login credentials in the vm (win xp).

So no solution yet ...

Cheers,

Ron

[AnthonySowden]

I get the same error (Permission Denied for /dev/rtc).

This error only started for me with WS 6.5.3. I use a 2.6.30 kernel, Linux host, Windows XP guests.

I think the error occurs when a guest needs to increase the interrupt rate. My Windows XP guests run without error, but when I start Firefox in one of the guests I get the error. I think this is because Firefox tries to set up a Windows high speed multimedia interrupt, which in turn causes VMware to try to up the interrupt rate in the host. Obviously, if you have other programs that set up timers in Windows you'll get the error at different times. For Linux guests, it will depend on your kernel version and configuration.

I don't think the error is anything to do with the host /dev/rtc file (link or otherwise). My experience is that no changes to this file make any difference.

I tried patrickchase's suggestion of upping the value of /sys/class/rtc/rtc0/max_user_freq from 64 to 1024. This may fix things for some people, but not me. Maybe Firefox needs a higher value? It's tedious to test because it seems that once you've had the error it doesn't happen (or is not reported) again, until you restart the virtual machine.

Anthony

[djaquays]

The best solution at this point seems to be to downgrade to 6.5.2. It's obviously not the long term answer, but it's better than dealing with the issues created by the timers not working properly.

[ronnieredd]

Same issue with permission denied - ubuntu 9.04, any bsd, linux or windows guests.

Workaround:

Make sure workstation is closed first!

Changed permissions on /dev/rtc to 666 (everyone can r/w)

The first time I did it, ws was open and it immediately froze the host. Upon reboot those permissions were not kept.

This workaround is probably not the safest as anyone can do /dev/rtc

The suggested rollback to 6.5.2 is probably the best advise unless there's some feature or bug fix you need in 6.5.3

[sefsinc]

The million dollar question is what are the side effects, implications of this?

I have not realized any as yet.

Please comment.

Thanks

[miza]

same here on Ubuntu 9.04/64.

/dev/vmmon .. : /dev/rtc enable interrupt failed: -13

and high CPU load

further the desktop integration between my XP-VM-session in full screen mode and native Gnome appears to be jaggy and sloppy.

for instance I keep hitting &lt;ctrl&gt; in order to locate the mouse pointer.

Sometimes the menu bar in full screen mode also gets messed up - only closing vmware and reopening does help.

Michael.

[miza]

ok, similar show with 6.5.2 (still under Ubuntu 9.04/64):

Sep 10 18:12:31 thing kernel: .. hpet1: lost 1 rtc interrupts

Sep 10 18:12:34 thing kernel: .. hpet1: lost 1 rtc interrupts

Sep 10 18:12:43 thing kernel: .. hpet1: lost 1 rtc interrupts

Sep 10 18:12:45 thing kernel: .. hpet1: lost 1 rtc interrupts

and so on ...

Installed 6.5.1 now, had to rebuild the kernel modules, but there's silence in syslog since then.

I didn't see the version history to check what's been fixed from 6.5.1 to 6.5.2 and 6.5.3 but til now this works better for me! 😕

(knock on wood)

Michael.

[jsa]

We were able to solve the high CPU utilization in at least one Ubuntu 9.04/64 installation by adding

hpet

to the end of the first menu.lst kernel in the /boot/grub directory.

You can manually type it in at boot time to try it out.

You still get occasional (once per session) pop-ups, but no swamping of your CPU.

[IntergalacticWa]

Has there been any official word from VMware about this?

I expect better quality from an expensive product such as this.

[jragle]

Having this same problem on Fedora 11 (kernel 2.6.30.9) running Workstation 6.5.3.

-Jamin Ragle

---

VCP, Linux System Administrator, All around great guy.

[IntergalacticWa]

And now that Workstation 7 has been released, I guess this means this will never get fixed in 6?

Gee, thank you VMware for giving me another reason to switch to VirtualBox.

[djaquays]

You may want to look again. Look at release dates for prior versions of workstation. 4.5 still had updates after 5 was released which still had updates after 6.0 was released.

VirtualBox comes with it's own cons. There are no magic bullets, software comes with issues.