[lkml]   [2007]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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 .
    > 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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-09-22 07:41    [W:0.036 / U:15.892 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site