Messages in this thread | | | Date | Thu, 6 Jul 2006 02:37:25 +0200 (CEST) | From | Roman Zippel <> | Subject | Re: 2.6.17-mm2 hrtimer code wedges at boot? |
| |
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/
| |