Re: 2.6.17-mm2 hrtimer code wedges at boot?

From: Roman Zippel
Date: Wed Jul 05 2006 - 20:36:13 EST


Hi,

On Wed, 5 Jul 2006, Valdis.Kletnieks@xxxxxx 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/