Re: 2.6.17-mm2 hrtimer code wedges at boot?

[Roman Zippel]

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