lkml.org 
[lkml]   [2003]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [pm] fix time after suspend-to-*
    john stultz wrote:
    > On Thu, 2003-10-23 at 16:09, George Anzinger wrote:
    >
    >>john stultz wrote:
    >>
    >>>On Thu, 2003-10-23 at 13:23, George Anzinger wrote:
    >>>
    >>>>I lost (never saw) the first of this thread, BUT, if this is 2.6, I strongly
    >>>>recommend that settimeofday() NOT be called. It will try to adjust
    >>>>wall_to_motonoic, but, as this appears to be a correction for time lost while
    >>>>sleeping, wall_to_monotonic should not change.
    >>>
    >>>While suspended should the notion monotonic time be incrementing? If
    >>>we're not incrementing jiffies, then uptime isn't being incremented, so
    >>>to me it doesn't follow that the monotonic time should be incrementing
    >>>as well.
    >>
    >>Uh, not moving jiffies? What does this say about any timers that may be
    >>pending? Say for cron or some such? Like I said, I picked up this thread a bit
    >>late, but, seems to me that if time is passing, it should pass on both the
    >>jiffies AND the wall clocks.
    >
    >
    > My understanding is that we are suspending the box (ie: putting your
    > laptop to sleep/hybernate), so for all practical purposes the box is off
    > waiting until it is woken up. During that time I don't believe we
    > receive timer interrupts. When we are woken up, we should update the
    > system time and continue, but as the box wasn't running during the
    > interim we shouldn't be increasing the notion of monotonic time.
    >
    >
    >>>It may very well be a POSIX timers spec issue, but it just strikes me as
    >>>odd.
    >>
    >>The spec thing would relate to any sleeps or timers that are pending. The spec
    >>would seem to say they should complete somewhere near the requested wall time,
    >>but NEVER before. By not moving jiffies, I think they will be a bit late. Now,
    >>if they were to complete during the sleep, well those should fire at completion
    >>of the sleep. If the are to complete after the sleep, then, it seems to me,
    >>they should fire at the requested time.
    >
    >
    > Hmmm. That last sentence gives me pause. I guess it comes down to how
    > you request your timer expiration: in wall time or system time. I
    > always thought it was in system time, but you know this stuff better
    > then I, so I'll defer.

    The request can be on the wall clock or on clock_monotonic. Still, we went
    round and round about how a tick on one should be a tick on the other. My
    understanding is that the pm_timer was put in the ACPIC to handle this, but then
    I don't know how far down power is going, nor for how long. I would think at
    some point the discontinuity would be large enough that one would want some user
    service to run and "fix" all the broken time assumptions. Some sort of a soft
    reboot that would kick the ntp code, cron and so on, much as is done at boot.


    --
    George Anzinger george@mvista.com
    High-res-timers: http://sourceforge.net/projects/high-res-timers/
    Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

    ps, long week end, out till Tuesday...

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:58    [W:6.167 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site