Messages in this thread | | | Date | Mon, 22 Nov 2004 10:54:24 -0800 | From | George Anzinger <> | Subject | Re: [PATCH]time run too fast after S3 |
| |
john stultz wrote: > On Mon, 2004-11-22 at 01:15, Li Shaohua wrote: > >>after resume from S3, 'date' shows time run too fast. Here is a patch. > > [snip] > >>diff -puN arch/i386/kernel/time.c~wall_jiffies arch/i386/kernel/time.c >>--- 2.6/arch/i386/kernel/time.c~wall_jiffies 2004-11-22 17:04:42.720038352 +0800 >>+++ 2.6-root/arch/i386/kernel/time.c 2004-11-22 17:06:21.373040816 +0800 >>@@ -343,12 +343,13 @@ static int timer_resume(struct sys_devic >> hpet_reenable(); >> #endif >> sec = get_cmos_time() + clock_cmos_diff; >>- sleep_length = get_cmos_time() - sleep_start; >>+ sleep_length = (get_cmos_time() - sleep_start) * HZ; >> write_seqlock_irqsave(&xtime_lock, flags); >> xtime.tv_sec = sec; >> xtime.tv_nsec = 0; >> write_sequnlock_irqrestore(&xtime_lock, flags); >>- jiffies += sleep_length * HZ; >>+ jiffies += sleep_length; >>+ wall_jiffies += sleep_length; >> return 0; >> } > > > I'm not all that familiar w/ the suspend code, but yea, this looks like > an improvement. The previous code was wrong because they are setting > xtime themselves, and then updating only jiffies. At the next timer > interrupt, the difference between jiffies and wall_jiffies would then be > added to xtime again. > > Why they don't just use do_settimeofday() for all of this is a mystery > to me. Are we wanting to pretend timer ticks arrived while we were > suspended?
I think that this way the uptime and start times of init and friends will be much more correct. settimeofday() would move those around. So, the short answer is, yes.
-- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/
- 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/
| |