[LAU] rtc/rtc0 + permissions + frequencies + udev

[james morris]

I've been struggling with setting up the real-time-clock. It's taken me
a long time to find the right information. And I'm still having
problems with udev though.

Here's a messy jumbled collection of stuff I've found out:


Firstly, setting the frequency of the real-time-clock:

from linux-2.6.31.6/Documentation/rtc.txt:

Linux has two largely-compatible userspace RTC API families you may
need to know about:

    *   /dev/rtc ... is the RTC provided by PC compatible systems,
        so it's not very portable to non-x86 systems.

    *   /dev/rtc0, /dev/rtc1 ... are part of a framework that's
        supported by a wide variety of RTC chips on all systems.

...
        Old PC/AT-Compatible driver:  /dev/rtc
...
Programming and/or enabling interrupt frequencies greater than 64Hz is
only allowed by root. This is perhaps a bit conservative, but we don't
want
an evil user generating lots of IRQs on a slow 386sx-16, where it might
have
a negative impact on performance. This 64Hz limit can be changed by
writing
a different value to /proc/sys/dev/rtc/max-user-freq. Note that the
...
        New portable "RTC Class" drivers:  /dev/rtcN
        --------------------------------------------
(( ie what I have, and probably others do too if they're running a new
kernel ))

Because Linux supports many non-ACPI and non-PC platforms, some of which
have more than one RTC style clock, it needed a more portable solution
than expecting a single battery-backed MC146818 clone on every system.
Accordingly, a new "RTC Class" framework has been defined.  It offers
three different userspace interfaces:

    *   /dev/rtcN ... much the same as the older /dev/rtc interface

*****-> /sys/class/rtc/rtcN ... sysfs attributes support readonly
*****-> access to some RTC attributes

    *   /proc/driver/rtc ... the first RTC (rtc0) may expose itself
        using a procfs interface.  More information is (currently) shown
        here than through sysfs.

------------------------

sysctl dev.rtc.max-user-freq no longer exists in the kernel
https://bugzilla.redhat.com/show_bug.cgi?id=431163

basically telling us what I missed first time round in the kernel rtc
docs, namely: max-user-freq is now located here:

/sys/class/rtc/rtc0/max-user-freq

and to set (until next reboot):

sudo echo 2048 > /sys/class/rtc/rtc0/max-user-freq


Finally, How to set the RTC max_user_freq in newer kernels (permanently):
http://www.ralree.com/2009/07/19/how-to-set-the-rtc-max_user_freq-in-newer-kernels/

"I found out today how to set the real time clock max frequencies in
Ubuntu since they removed the possibility to do it from sysutil.conf
from newer kernels. Add the following to your /etc/rc.local or another
startup script:"

sudo echo 2048 >/sys/class/rtc/rtc0/max_user_freq
sudo echo 2048 >/proc/sys/dev/hpet/max-user-freq

I only needed the first of these - /proc/sys/dev/hpet does not exist on
my system.

***********************************************

Secondly doing all that is not bloody good if when you do ll /dev/rtc*
you discover /dev/rtc0 is not a member of the audio group:

lrwxrwxrwx 1 root root       4 2009-12-15 14:49 /dev/rtc -> rtc0
crw-rw---- 1 root root  254, 0 2009-12-15 14:49 /dev/rtc0

Chances are you're running udev, so don't think you can simply:
sudo chgrp audio /dev/rtc0

This is where I've not quite discovered a solution which does not get
blasted away by a Debian (testing) udev update (so if you know how to do
it let us know):

do:
sudo nano /lib/udev/rules.d/85-hwclock.rules

and add the following line:
KERNEL=="rtc0", GROUP:="audio"

Again it took quite a lot of digging around to find that. Most
information points to other locations. For example adding the above line
to /etc/udev/udev.conf does not work. I had previously added a file
containing the above line to /etc/udev/rules.d but as stuff in there is
auto-generated... I'm 75% sure it was deleted on a udev update.

Now I no longer get
/dev/rtc: permission denied

Hooray!

James.