Re: [PATCH]time run too fast after S3

[George Anzinger <george@mvista.com>]

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/