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

[agodber]

I have this same exact error on Ubuntu 8.04.3, uname -a:

Linux fiz 2.6.24-24-generic #1 SMP Tue Aug 18 17:04:53 UTC 2009 i686 GNU/Linux

I am in a group that can write to /dev/rtc and I can touch /dev/rtc. Even changing ownership of /dev/rtcto my user and primary group I still get this same error.

Austin

[oznet]

Same problem here with Ubuntu Jaunty 9.04 64-bit host. I did not see this error with 6.5.2.

If the permissions on /dev/rtc are wrong I see this:

/dev/vmmon\[6911]: /dev/rtc open failed: -13

Which is weird because the permissions are the same as they were when I was using 6.5.2. Was 6.5.2 not using /dev/rtc or maybe just not showing the error?

If I fix the permissions on /dev/rtc then I get this error:

/dev/vmmon\[5563]: /dev/rtc enable interrupt failed: -13

In any case it does not work.

[Tom2k8]

I'm facing the same issue on a 64 bit computer running OpenSuSE 11.0.

This is the output of the command 'uname -a':

Linux linux-1vmb 2.6.25.20-0.5-default #1 SMP 2009-08-14 01:48:11 +0200 x86_64 x86_64 x86_64 GNU/Linux

The error message only came up once and then no more.

I've also browsed the logfile of my session and regarding the error message (searching for "timer") I've included a short excerpt of the logs.

Aug 27 12:41:21.386: vcpu-0| Guest: vmdesched:driver:vmdesched Descheduled Time Accounting Service loaded

Aug 27 12:41:27.237: vcpu-0| MKS Backdoor get pointer: first time, notify tools are running

Aug 27 12:41:31.792: vcpu-0| Msg_Hint: msg.hostlinux.rtcopen7 (sent)

Aug 27 12:41:31.792: vcpu-0| The host high-resolution timer device (/dev/rtc) is not available (Permission denied). Without this device, the guest operating system can fail to keep time correctly. For more information, see .

Aug 27 12:41:31.792: vcpu-0|

-

---

Aug 27 12:41:31.875: vmx| Could not accept connection on 115: Resource temporarily unavailable

Maybe this can help us.

[jsa]

Have you tried booting Opensuse HOST with "nohpet" on the end of the command line?

[sefsinc]

Same problem here.

[fgouget]

So I upgraded from VMware 6.5.2 to 6.5.3 on a Debian Testing 64bit host and I'm getting the same message.

I also tried making /dev/rtc0 world-readable and world-writable to no avail...

[cdc1]

Read the VMware Knowledge Base article referred to in the message. That article explains what needs to be done to correct the issue in most cases.

[oznet]

This is definitely a change from 6.5.2 to 6.5.3. I reinstalled 6.5.2 and I no longer get rtc errors in the log. Upgrade to 6.5.3 and the error appears.

[fgouget]

> Read the VMware Knowledge Base article referred to in the message.

You mean this one?

It seems to be based on the premise that /dev/rtc is not available which, as far as I can see, is not the case here.

$ ls -l /dev/rtc /dev/rtc0

lrwxrwxrwx 1 root root 4 Aug 28 18:11 /dev/rtc -> rtc0

crw-rw---- 1 root root 254, 0 Aug 28 18:11 /dev/rtc0

And:

CONFIG_HPET_EMULATE_RTC=y

CONFIG_RTC_LIB=y

CONFIG_RTC_CLASS=y

CONFIG_RTC_HCTOSYS=y

CONFIG_RTC_HCTOSYS_DEVICE="rtc0"

CONFIG_RTC_INTF_SYSFS=y

CONFIG_RTC_INTF_PROC=y

CONFIG_RTC_INTF_DEV=y

CONFIG_RTC_DRV_CMOS=y

$ dmesg | grep rtc

http:// 1.049180 pnp: the driver 'rtc_cmos' has been registered

http:// 1.049180 rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0

http:// 1.049180 rtc0: alarms up to one month

http:// 1.049180 rtc_cmos 00:04: driver attached

http:// 1.049180 rtc_cmos 00:04: setting system clock to 2009-08-28 16:11:20 UTC (1251475880)

Finally, according to lsof besides VMware no process is using /dev/rtc.

The article also states that the HZ trick is not needed if the kernel is 2.6.x because these already have a high enough HZ. Well, I'm running Debian's stock 2.6.26 kernel and HZ is 250. So it's not very high, but it's the same kernel that VMware 6.5.2 was running on and it did not complain at the time.

Also note that I did not notice any special slowness issue so far. My question is more:

Why am I getting this new warning with 6.5.3?

Why does it say it gets a permission denied error even when I make the device world readable and world writable?

There's been HPET issues in the past. Could this be one in disguise?

[cdc1]

Well, that's a bummer. I just finished trying this out on a Linux system I installed explicitly for trying this out. Nothing in that KB article helps (I recompiled a kernel after increasing the #define "HZ" line in the asm/param.h file, on the off chance it "might" help, but it didn't work.) Even adding 'rtc.startConnected = FALSE' into the vmx file for my VM had no affect on this message.

[jsa]

Would someone who has 6.5.3 installed please try nohpet on the boot command line and see if the message goes away?

It wouls save me having to install 6.5.3 just to roll it back again.

[cdc1]

Adding nohpet at the boot command line had no affect on my system (Ubuntu 9.04 32bit).

[jsa]

Thanks for testing that.

[jsa]

For the record, on OpenSuse 10.3 with a 2.6.22 kernel I get this message once upon booting each machine.

I then uncheck Synchronize time in Vmware tools, and I never see the message again.

Nor do I see any slowness in VMs.

Its a Core 2 Duo laptop, and it seemsto work as reliably now as it did before.

[patrickjchase]

This appears to be an issue with the 6.5.3 modules - They aren't properly acquiring CAP_SYS_RESOURCE on kernel 2.6.29, which means that the RTC interrupt rate is limited to the value in /sys/class/rtc/rtc0/max_user_freq (typically 64).

It may be possible to patch the modules and/or the install scripts to get around this, but as an interim workaround you can add this line to /etc/rc.d/rc.local:

echo "1024" > /sys/class/rtc/rtc0/max_user_freq

Note that this will basically allow all processes on your system (regardless of whether they hold CAP_SYS_RESOURCE) to get RTC interrupts at up to 1 kHz.

[sefsinc]

Do you think VMWare will fix this bug?

Thanks.

[patrickjchase]

There are a couple ways to look at this:

1. CAP_SYS_RESOURCE is a rather dangerous thing, because it allows a process that holds it to violate basically all system resource constraints, not just RTC interrupt frequency. A "purist" take on this is that if you really do want a process like VMware to get 1 kHz RTC interrupts then you should explicitly allow that, which is what /sys/class/rtc/rtc0/max_user_freq does.

2.vmware is lazy: I can't help but notice that the calls to cap_raise() were a source of build failures for vmmon on 2.6.29+. I'd like to think that they stopped grabbing CAP_SYS_RESOURCE because of a principled decision that it was a bad thing to do, but I suspect that some overworked engineer did it because it was simply the quickest way to address those pesky compile errors (which would be a shame if true, because the "real" fix was easy - see krellan's 6.5.2 patch for details).

This would actually be pretty easy to add back in - It's a ~10-line change to hostif.c. I can give you a patch if you want.

Also, if you're on a distro like Fedora that sets CONFIG_HZ to 1000 by

default, then you're not losing (much of) anything by having /dev/rtc

disabled.Have a look at /lib/modules/`uname -r`/build/.config if you're unsure.

-- Patrick