lkml.org 
[lkml]   [2015]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v2] alarmtimer: fix unexpected rtc interrupt when system resume from S3
    From
    On Wed, Nov 4, 2015 at 9:50 PM,  <zhuo-hao.lee@intel.com> wrote:
    > From: zhuo-hao <zhuo-hao.lee@intel.com>
    >

    If you could, please CC me on future submissions? I need to add an
    entry to MAINTAINERS for alarmtimers. :)

    > Before the system go to suspend (S3), if user create a timer with clockid
    > CLOCK_REALTIME_ALARM/CLOCK_BOOTTIME_ALARM and set a "large" timeout value
    > to this timer. The function alarmtimer_suspend will be called to setup
    > a timeout value to RTC timer to avoid the system sleep over time. However,
    > if the system wakeup early than RTC timeout, the RTC timer will not be cleared.
    > And this will cause the hpet_rtc_interrupt come unexpectedly until the RTC
    > timeout. To fix this problem, just adding alarmtimer_resume to cancel the
    > RTC timer.

    So conceptually the patch makes sense, though I'm not totally sure I
    understand the failure you describe.

    We have some alarmtimer set for 2 hours from now.
    We suspend, and the alarmtimer code sets an rtctimer to wake us up in
    2 hours week.
    We resume a few minutes later due to user interaction or other
    wakeups, but the rtctimer is still set.
    A little less then two hours later (while the system has been awake
    the whole time), the RTC hardware fires and we run the rtctimer.
    ???? Something problematic here w/ the hpet_rtc_interrupt?
    The alarmtimer's hrtimer fires as normal.


    Again, your fix seems reasonable, but I also feel like when the RTC
    hardware spuriously fires and we trigger the rtctimer logic, there
    shouldn't be any real problems there. So I want to make sure we're not
    covering up some underlying issue w/ this fix.

    thanks
    -john


    \
     
     \ /
      Last update: 2015-11-13 22:01    [W:5.151 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site