lkml.org 
[lkml]   [2004]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH]time run too fast after S3
From
Date
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

-
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/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.745 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site