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.
> >
> > [EMAIL PROTECTED]:/sys/class/rtc/rtc0# cat wakealarm
> > [EMAIL PROTECTED]:/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.
> > [EMAIL PROTECTED]:/sys/class/rtc/rtc0# ls -al wakealarm
> > -rw-r--r-- 1 root root 0 Sep 20 12:30 wakealarm
> > [EMAIL PROTECTED]:/sys/class/rtc/rtc0# cat wakealarm
> > [EMAIL PROTECTED]:/sys/class/rtc/rtc0# cat wakealarm
The alarm isn't set; so no value gets displayed.
> > [EMAIL PROTECTED]:/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.
>
> [EMAIL PROTECTED]:~# s2ram
> Switching from vt9 to vt1
>
>
> switching back to vt9
> [EMAIL PROTECTED]:~#
> [EMAIL PROTECTED]:~#
> [EMAIL PROTECTED]:~# cd /sys/class/rtc/rtc0
> [EMAIL PROTECTED]:/sys/class/rtc/rtc0# ls
> date dev device@ name power/ since_epoch subsystem@ time
> uevent wakealarm
> [EMAIL PROTECTED]:/sys/class/rtc/rtc0# cat wakealarm
> 2051629528
> [EMAIL PROTECTED]:/sys/class/rtc/rtc0# cat power/wakeup
>
> [EMAIL PROTECTED]:/sys/class/rtc/rtc0# cat wakealarm
> 2051629528
> [EMAIL PROTECTED]:/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.
> [EMAIL PROTECTED]:/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.
> [EMAIL PROTECTED]:/sys/class/rtc/rtc0# s2ram
> Switching from vt9 to vt1
>
>
> switching back to vt9
> [EMAIL PROTECTED]:/sys/class/rtc/rtc0#
> [EMAIL PROTECTED]:/sys/class/rtc/rtc0#
> [EMAIL PROTECTED]:/sys/class/rtc/rtc0# cat wakealarm
> [EMAIL PROTECTED]:/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.
> [EMAIL PROTECTED]:/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.
> [EMAIL PROTECTED]:/sys/class/rtc/rtc0# cat wakealarm
> [EMAIL PROTECTED]:/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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
