Re: [PATCH]time run too fast after S3

[john stultz <johnstul@us.ibm.com>]

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?

thanks
-john