Hi,
On Wed, 28 Jun 2006, john stultz wrote:
> I agree cpufreq changes could be the source. However, things still
> aren't making sense, since the accumulation is cycle based to begin
> with, so any cpufreq caused drift in time won't be noticed until NTPd
> starts adjusting the output from current_tick_len().
Indeed, AFAICT the clock should just run too fast, that leaves pretty much
only the update function doing something I didn't expect.
> Vladis: I don't want to overwhelm you with patches to try, I think
> Roman's debug patches should help show where the issue is. But if you've
> got the time, try the patch below to quickly see if the cpufreq changes
> are indeed causing the problem.
Another change that might help: Valdis, could you add another call to
printk_clock_info() at the end of update_wall_time() after
clocksource_calculate_interval()?
> Hmm. Yea, while I'm not sure this is the issue at hand, it does look
> like I need to get some of the boot ordering worked out here. Using the
> PIT early on probably isn't the best solution as the 18us access latency
> might not be the best for the transition calibration.
Since it shouldn't be used much I don't think it matters and it could
also be HPET, basically whoever provides the timer interrupt.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
