On Thursday 20 September 2007, Pavel Machek wrote:
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.
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.
The alarm isn't set; so no value gets displayed.
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!
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.
That is, 20 seconds from "now" modulo timezone offsets.
Better might be
echo $(( $(cat since_epoch) + 20 )) > wakealarm
which has no timezone offset issues.
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.
... which BTW should be what the "since_epoch" file shows,
other than the timezone offsets on some system RTCs.
"git show 3925a5ce44330767f7f0de5c58c6a797009f0f75" has some.
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
-
