Re: [PATCH]time run too fast after S3

[George Anzinger]

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@xxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/