Messages in this thread | | | Date | Thu, 23 Oct 2003 19:10:19 -0700 | From | George Anzinger <> | Subject | Re: [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/
| |