Message-Id: <200709212238.05130.david-b@pacbell.net>
Date:	Fri, 21 Sep 2007 22:38:04 -0700
From:	David Brownell <david-b@...bell.net>
To:	Pavel Machek <pavel@....cz>
Cc:	rtc-linux@...glegroups.com,
	kernel list <linux-kernel@...r.kernel.org>,
	Alessandro Zummo <alessandro.zummo@...ertech.it>
Subject: Re: RTC wakealarm write-only, still has 644 permissions

On Thursday 20 September 2007, Pavel Machek wrote:
> Hi!
> 
> > ...should they be changed to 200? Or perhaps file should be readable?

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,
that will work.  So $SUBJECT is no problem at all.


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

At which point I'd expect

# echo $?

would indicate the write failed.  That's a LONG time in the
past (January 2, 1970), so that setting would be rejected.


> > 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 

The alarm isn't set; so no value gets displayed.


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

Yeah, well a "standard PC" is chock full of fairly bizarrely
glitchey hardware.  Clocks and timers have more than their
fair share, or x86_64 NOHZ support would be merged by now!


> 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

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"
without needing to know about such quirks.


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

That is, 20 seconds from "now" modulo timezone offsets.

Better might be

	echo $(( $(cat since_epoch) + 20 )) > wakealarm

which has no timezone offset issues.


> 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 

There's some wierdness related to ACPI, that crept in sometime
late in 2.6.21 (or thereabouts) ... where the RTC wake mechanism
got broken by redefining the pm_ops functions, for hibernation
at least.

That MIGHT be related to what you observe here ... unclear what
that was supposed to show.  If the RTC alarm woke that system
after 20 seconds, that's what you requested and all is fine.  If
not, and you had to wake it by hand, then you're seeing that issue
with the redefinition of hibernation ops having borked the RTC wake
mechanism interactions with ACPI.

In both cases, I'd expect that the result is that no alarm is
pending any more, so there's nothing to display.


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

... which BTW should be what the "since_epoch" file shows,
other than the timezone offsets on some system RTCs.


> root@amd:/sys/class/rtc/rtc0# cat wakealarm 
> root@amd:/sys/class/rtc/rtc0# 
> 
> Also, is there some documentation for wakealarm?

"git show 3925a5ce44330767f7f0de5c58c6a797009f0f75" has some.


> 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 :-(.

Time in seconds since the POSIX epoch.  Same units as "since_epoch",
which has even less documentation...


Are you sure it's not working?  Other than the two issues I noted
above -- borkage w.r.t. ACPI (which wasn't necessarily shown in your
scripts above), and with wildcarding -- it looked to be correct.

- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists