...should they be changed to 200? Or perhaps file should be readable?
root@amd:/sys/class/rtc/rtc0# cat wakealarm

root@amd:/sys/class/rtc/rtc0# echo 132719 > wakealarm

root@amd:/sys/class/rtc/rtc0# ls -al wakealarm

-rw-r--r-- 1 root root 0 Sep 20 12:30 wakealarm

root@amd:/sys/class/rtc/rtc0# cat wakealarm

root@amd:/sys/class/rtc/rtc0# cat wakealarm

root@amd:/sys/class/rtc/rtc0# 
...standard PC with reasonably recent kernel...

									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

Hmm, something is definitely wrong in here. I sometimes _do_ get

something back.
root@amd:~# s2ram

Switching from vt9 to vt1
switching back to vt9

root@amd:~#

root@amd:~#

root@amd:~# cd /sys/class/rtc/rtc0

root@amd:/sys/class/rtc/rtc0# ls

date  dev  device@  name  power/  since_epoch  subsystem@  time

uevent  wakealarm

root@amd:/sys/class/rtc/rtc0# cat wakealarm

2051629528

root@amd:/sys/class/rtc/rtc0# cat power/wakeup 
root@amd:/sys/class/rtc/rtc0# cat wakealarm

2051629528

root@amd:/sys/class/rtc/rtc0# date +%s

1190285030

root@amd:/sys/class/rtc/rtc0# echo 1190285050 > wakealarm

root@amd:/sys/class/rtc/rtc0# s2ram

Switching from vt9 to vt1
switching back to vt9

root@amd:/sys/class/rtc/rtc0#

root@amd:/sys/class/rtc/rtc0#

root@amd:/sys/class/rtc/rtc0# cat wakealarm

root@amd:/sys/class/rtc/rtc0# cat wakealarm

root@amd:/sys/class/rtc/rtc0# date +%s

1190285229

root@amd:/sys/class/rtc/rtc0# cat wakealarm

root@amd:/sys/class/rtc/rtc0# 
Also, is there some documentation for wakealarm?
sh-3.1$ cd Documentation/

sh-3.1$ grep -ri wakealarm .
...is it time in seconds? In UTC? In whatever timezone rtc clocks are

using? It does not seem to work for me :-(.

								Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

No, mode 644 is fine.  No reason to prevent "other" people from

reading the alarm time (is there?) and if you write a legal value,
At which point I'd expect
# echo $?
would indicate the write failed.  That's a LONG time in the
Yeah, well a "standard PC" is chock full of fairly bizarrely

glitchey hardware.  Clocks and timers have more than their
OK, in that situation you've definitely got some buglike behavior.

My question is:  how to fix it?
The problem is that the RTC is reporting an alarm value with some

fields flagged as "wildcard" -- e.g. day/month/year "out of range"

so the hardware ignores those fields.  This is very common on PC

based RTCs, and much less common on embedded systems.  (Which for

some reason don't tend to cheap out on full date specs like PCs.)
And those cause date reports to look like garbage; /proc/driver/rtc

would show "**" in those fields, rather than trying to display the

canonical "seconds since POSIX epoch" value.  But the wakealarm code

just calls rtc_tm_to_time(), which doesn't validate its fields and

so will gladly spew the garbage you saw.  (On PCs especially.  This

code was originally tested on sane embedded hardware.)
Now, in the /dev/rtcX code there's some code working with a similar

problem:  ioctl(RTC_ALM_SET) morphs partial alarm dates into valid

form before passing them down.  This needs the same kind of fix,

but going in the other direction -- and not always kicking in.  That

could go into either the wakealarm display code, or rtc_read_alarm(),

or maybe someplace else.
I'm not sure which fix would be best; maybe Alessandro has an opinion.
I'd lean towards just fixing the wakealarm display code, except that

would force anyone using that other routine to know about this rude

"wildcard" convention, which is rather hardware-specific... and that's

not really aligned with the goal of an RTC framework that "just works"
That is, 20 seconds from "now" modulo timezone offsets.
Better might be
	echo $(( $(cat since_epoch) ...
[ message continues ]

Hi!
Sorry for long delay. I got rtc wakeup to work... once per boot. On
It seems to be working now, not sure what changed.
rtc-sysfs.c: why this?
        if (alarm > now) {

                /* Avoid accidentally clobbering active alarms; we

can't

                 * entirely prevent that here, without even the

minimal

                 * locking from the /dev/rtcN api.

                 */

                retval = rtc_read_alarm(rtc, &alm);

                if (retval < 0)

                        return retval;

                if (alm.enabled)

                        return -EBUSY;
                alm.enabled = 1;
People should not be "accidentally" writing to sysfs files...

									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

There were some patches from Mark Lord to update the wildcarding,

and to hibernation to work better with ACPI.  I still don't think

the wildcarding is done quite right; there are some date-wrap cases
It's not an issue of accidental writes, it's an issue of there being

no other synchronization for setting those alarms.  Remember that both

RTC_WKALM_SET and RTC_ALM_SET ioctls can set that same alarm, and so

could a different userspace activity ...
If there's no alarm set, it's clear that changing the (single) alarm

can't cause event lossage.  But if an alarm *is* set it sure seems

that changing it would discard an event that something was expecting,

and thus cause breakage.
As written, this allows one userspace activity to clobber another if

it does so explicitly, by first disabling the other one and then

setting its own alarm.  But the idea is to minimize "accidents" like
Evidently the alarm isn't being disabled then...
I think the issue there is that the alarm isn't acting as a one-shot

event.  There are some model questions lurking there ... if the RTC

has a sane alarm model, "fire at YYYY-MM-DD at HH:MM:SS", then it's

naturally one-shot.
But if the YYYY-MM-DD part is a wildcard (or equivalently, ignored)

at the hardware level, that model is awkward.  You can't easily look

at such alarms and know if they already triggered -- especially after

hibernation.  With respect to rtc-cmos, it'd always be practical to

disable the alarm after it triggers while the system is running.

(Not currently done, pending resolution of such issues.)  And there's

an ACPI flag -- currently ignored by Linux, or maybe trashed -- to

report whether the system wakeup was triggered by an alarm; that

could be read, and used to disable the alarm.
I think the right thing to do there is just insist that in the RTC

framework, alarms should always follow the one-shot model.
- Dave

-

We have 3 interfaces to one hardware resource. I do not think kernel

should try to arbitrate it here. There's just one alarm clock with
I do not believe current interface has any users. ...or any users that
I think we should just remove the 'avoid-clobber' logic. If userland

wants to somehow arbitrate access, it can.
Now, if we want to provide "nice" interface for timed sleep, I think

we can. Actually, I'd like to use normal select() as such an

interface, and enable kernel to automatically detect when it can sleep

and when it has to wake up.
								Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

Having three interfaces is bad enough ... ensuring that none of
I had earlier pointed out a different issue, whereby "oneshot"

semantics weren't consistently followed.  I've been working on

some patches to address that.  The ACPI bits still need work,
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That's the issue addressed by those patches.  (Specific to rtc-cmos,
There's the "rtcwake" thing.  That got merged into util-linux-ng, but

I happened to notice its setup_alarm() is calling gmtime() instead

of localtime() ... my suspicion is that the uClibc version I was using

had some timezone bugs, or else there's some other bug lurking in the

vicinity of dual-bootiness.
Note that "wakealarm" is not intende to be a "timed sleep" interface

at all ... it's just to set the wakealarm.  Something else is in charge

of putting the system to sleep, such as "echo mem > /sys/power/state"

or some GUI thing hooked up to logic that knows about how to make frame

buffers recover.
- Dave

-

They can be used safely. You just have to pick one and stay with

it. (And no, no-clobber hack does not help here. Or do you have

specific application where no-clobber hack helps?)
Anyway, with wildcarded dates, no-clobber is a problem -- because you

need to kill the alarm after you waken up, or it will repeat.

								Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

And I've started to fix that problem.  Alarms need to

act only in oneshot mode for other reasons too.
- Dave

--

...
This is really a non-issue in practice.  The thing requires root access,

and there's only a single user at most for it on a given system.
This is used by media boxes to power off (or suspend) between recording times.

And similar stuff.
It might be nice to fix it all, but the current state really isn't hurting anything.
Cheers

-

Exactly. If you wanted arbitration, just create "rtcd", and make users

talk to it over sockets or something. Actually openmoko has neod,

which does that iirc.

								Pavel
--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

On Thu, 29 Nov 2007 10:10:12 -0800
 /me agrees.
-- 
 Best regards,
 Alessandro Zummo,

  Tower Technologies - Torino, Italy
  http://www.towertech.it
-

On Thu, Nov 29, 2007 at 00:26:47 +0100, Pavel Machek wrote:
It would be nice if you mention the differences to the old

/proc/acpi/alarm, to help users who want to migrate. Something like in

http://lkml.org/lkml/2007/6/19/264.
Regards,

Tino

-

Yep, agreed. I was confused by fact that it does not give invalid
								Pavel
--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

I stand corrected.  What it should do -- and does -- in that case

involves disabling the alarm, then succeeding.
-