Re: 2.6.17-mm2 hrtimer code wedges at boot?

[Roman Zippel <zippel@linux-m68k.org>]

Hi,

On Wed, 5 Jul 2006, Valdis.Kletnieks@vt.edu wrote:

> I'll bite - what *am* I using as a timesource for those first 4 seconds? :)

Jiffies and the first few adjustments are fine, it just compensates for 
the initial difference between NSEC_PER_JIFFY and TICK_NSEC.

> [   29.528533] Time: tsc clocksource has been installed.
> [   29.552855] clock changed at -296333 (4294314460971008)
> [   29.577109] clock tsc: m:2628985,s:22,cl:47171945132,ci:1595166,xn:0,xi:4193667486510,e:0
> [   29.601869] big adj at -296332 (4294314460971008,-16,-25522656,-11031712)
> [   29.626688] clock tsc: m:2628985,s:22,cl:47288392250,ci:1595166,xn:148610636380190,xi:4193667486510,e:-76300711936
> [   29.652263] big adj at -296331 (4294314460971008,512,816724992,737704960)
> [   29.677968] clock tsc: m:2628969,s:22,cl:47368150550,ci:1595166,xn:358292745604602,xi:4193641963854,e:1193037240320

Ok, I see now the problem, the last cycle value is always at least 50 
times incremented between adjustments and that also means any error 
adjustment is applied at least 50 times, which quickly gets out of 
control.
Is it possible that your console output is really slow? Otherwise I can't 
explain these numbers, everything looks initialized fine for a 1.6GHz 
clock, but it seems to take ages to print a single line.
I have to run some tests and later this week there should be a new patch 
compensating for this.

John, now I also know why your version survived this, it did the error 
correction in the update loop, this kept error small, but it also caused 
the time to jump around, since it changed the multiplier in the past.

bye, Roman
-
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/