Messages in this thread | | | Subject | Re: 2.6.17-mm2 hrtimer code wedges at boot? | From | john stultz <> | Date | Wed, 05 Jul 2006 17:56:11 -0700 |
| |
On Thu, 2006-07-06 at 02:37 +0200, Roman Zippel wrote: > Hi, > > On Wed, 5 Jul 2006, Valdis.Kletnieks@vt.edu wrote: > > [ 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.
Dang! You beat me to the analysis :) I think we're on the same page here.
> I have to run some tests and later this week there should be a new patch > compensating for this.
Look forward to it.
> 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.
Yep, agreed.
thanks -john
- 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/
| |