Ticket #2156 (closed defect: fixed)

Opened 5 years ago

Last modified 5 years ago

rtctest.c does not exit with stable-tracking kernel

Reported by: lindi Owned by: balajirrao
Priority: normal Milestone:
Component: kernel Version: unspecified
Severity: normal Keywords:
Cc: werner@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible:

Description

Steps to reproduce:
1) build and boot stable-tracking kernel
2) modprobe rtc-s3c
3) gcc -o rtctest rtctest.c
4) ./rtctest

Expected results
4) rtctest prints debug texts and exits

Actual results
4) rtctest prints the following but does not exit

                        RTC Driver Test Example.


...Update IRQs not supported.


Current RTC date/time is 3-12-2008, 15:48:00.
Alarm time now set to 15:48:20.
Waiting 5 seconds for alarm...

More info:
1) rtctest.c is extracted from Documentation/rtc.txt and attached to this bug report.


Attachments

rtctest.c (5.6 KB) - added by lindi 5 years ago.

Change History

Changed 5 years ago by lindi

comment:1 Changed 5 years ago by andy

Can you try this with andy-tracking kernel? This has Balaji's changes to pcf50633 and the rtc on there. Stable-tracking isn't representative of what we will fork to make the new stable since it lacks a bunch of stuff in andy-tracking.

comment:2 Changed 5 years ago by andy

Duh reading your original post again: the s3c rtc is not used on GTA02, it's the one in the PMU that is used.

comment:3 Changed 5 years ago by lindi

rmmod rtc-s3c does not change the result of the test. I'll try arrange time to test andy-tracking kernel too. Does rtctest.c work there for you?

comment:4 Changed 5 years ago by andy

I don't have a GTA02 where I am right now to test it, I'll try it tomorrow.

You can get a quick and dirty binary of andy-tracking kernel http://people.openmoko.org/andy.

comment:5 in reply to: ↑ description Changed 5 years ago by balajirrao

  • Cc werner@… added
  • Status changed from new to accepted
  • Component changed from System Software to Distro
  • Owner changed from openmoko-kernel to balajirrao

I've seen this. The program uses ALM_SET to set the alarm. In the kernel sources you might observe ALM_SET is setting wkday to -1. This results in the wkday register in pcf50633 being set wrongly and hence your rtctest works only on one day of the week (in my case, on Friday).

The comment in the sources (drivers/rtc/rtc-dev.c) says WKALM_SET be used instead. Werner's wkalarm uses this - http://svn.openmoko.org/developers/werner/wkalrm/wkalrm.c and it worked fine when I tried it last time.

I don't know why ALM_SET doesn't work. Werner, can you help us with this ?

comment:6 Changed 5 years ago by balajirrao

  • Component changed from Distro to System Software

Sorry, changed Component to Distro by mistake. Fixed it.

comment:7 Changed 5 years ago by lindi

balajirrao, thanks a lot for your observations. I can have my phone wake up from suspend when I use WKALM_SET. With the above code I can now just say

 rtcwake `date +%s -d "now + 3 hours"` && susp && alarm

to have my phone sleep for 3 hours and then notify me :-)

rtcwake.c:

#include <stdio.h>
#include <linux/rtc.h>
#include <sys/ioctl.h>
#include <sys/time.h>
#include <sys/types.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <errno.h>
#include <assert.h>
#include <time.h>

int main(int argc, char **argv) {
    int fd, ret;
    struct rtc_wkalrm wkalrm;

    assert(argc == 2);

    fd = open("/dev/rtc0", O_RDONLY);
    assert(fd);

    {   
        struct tm *tm;
        time_t secs;

        secs = atol(argv[1]);
        assert(secs > 86400*365*(2000-1970));
        assert(secs < 86400*365*(2030-1970));
        tm = gmtime(&secs);
        assert(tm);

        wkalrm.time.tm_sec = tm->tm_sec;
        wkalrm.time.tm_min = tm->tm_min;
        wkalrm.time.tm_hour = tm->tm_hour;
        wkalrm.time.tm_mday = tm->tm_mday;
        wkalrm.time.tm_mon = tm->tm_mon;
        wkalrm.time.tm_year = tm->tm_year;
        wkalrm.time.tm_wday = tm->tm_wday;
        wkalrm.time.tm_yday = tm->tm_yday;
        wkalrm.time.tm_isdst = tm->tm_isdst;
    }

    wkalrm.enabled = 1;
    ret = ioctl(fd, RTC_WKALM_SET, &wkalrm);
    assert(ret != -1);

    return 0;
}

comment:8 Changed 5 years ago by werner

Balaji, you gave me a good riddle there ;-)

wkalrm works more by accident - it just sends back the value it has
read. So as long as your alarm occurs on the same day, you're fine.
If not ... you'll have a good excuse for showing up late at work :-)

Further investigation on the kernel side shows that RTC_ALM_SET uses
a value of -1 to indicate that the field should be ignored. However,
we don't recognize this special value and just try to convert it into
BCD, apparently yielding Friday.

There are several ways of dealing with this. We could just handle a
tm_wday of -1 as "ignore", but that would still require applications
using RTC_WKALM_SET to set this field, which probably isn't something
we should expect them to do.

I posted a patch to openmoko-kernel that just unceremoniously ignores
tm_wday. This follows the example of mktime(3) that also ignores the
redundant fields tm_wday and tm_yday. We were already ignoring the
latter.

comment:9 Changed 5 years ago by balajirrao

Werner, thank you for the patch! I'll test it now.

comment:10 Changed 5 years ago by lindi

Hmm, what's the status of this bug? At least short sleeps with RTC_WKALM_SET still work reliably but I don't know if I should test extensively long sleeps (several days) or not.

comment:11 Changed 5 years ago by werner

If you could give it a try with the version using RTC_ALM_SET, that
would be nice. If it's okay, then we can close it. Seems that Balaji
hasn't found any trouble.

  • Werner

comment:12 Changed 5 years ago by andy

  • Status changed from accepted to closed
  • Resolution set to fixed

Seems it's fixed.

Note: See TracTickets for help on using tickets.