Messages in this thread | | | Subject | Re: [PATCH]time run too fast after S3 | From | john stultz <> | Date | Mon, 22 Nov 2004 10:33:25 -0800 |
| |
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/
| |