Re: Linux 2.6.29-rc6

[john stultz <johnstul@us.ibm.com>]

On Wed, 2009-03-04 at 10:57 -0800, John Stultz wrote:
> On Wed, 2009-03-04 at 19:36 +0100, Jesper Krogh wrote:
> > jk@quad12:~$ python drift-test.py 10.192.96.19
> > 04 Mar 19:27:10         offset: -0.157696       drift: -693.0 ppm
> > 04 Mar 19:28:10         offset: -0.195134       drift: -625.098360656 ppm
> > 04 Mar 19:29:10         offset: -0.232579       drift: -624.595041322 ppm
> > 04 Mar 19:30:10         offset: -0.270021       drift: -624.408839779 ppm
> > 04 Mar 19:31:11         offset: -0.307461       drift: -621.727272727 ppm
> > 04 Mar 19:32:11         offset: -0.344903       drift: -622.185430464 ppm
> > 04 Mar 19:33:11         offset: -0.382345       drift: -622.491712707 ppm
> > 04 Mar 19:34:11         offset: -0.419794       drift: -622.727488152 ppm
> > 04 Mar 19:35:11         offset: -0.457239       drift: -622.89626556 ppm
> 
> 
> Yea, so from this and the settled ntpdc -c kerninfo data before, we can
> see that the drift is further out then the 500ppm NTP can handle.
> 
> So with that at least confirmed, we can focus back on to the fast-pit
> tsc calibration code.
> 
> Ingo, Thomas: I'm missing a bit of the context to that patch, other then
> just speeding up boot times, was there other rational for moving away
> from the ACPI PM timer based calibration?
> 
> Could we maybe add a quick test that the pit reads actually take the
> assumed 2us max? Doing this maybe via the HPET/ACPI PM?

Hey Jesper,

	Here's a very-hackish patch to see if the approach I'm considering
might fix the issue you're hitting. Could you apply it, boot the kernel
a few times and send me the following segments of the dmesg for each of
those boots (the example below is from my test box)? 

tsc delta: 44418024
ref_freq: 3000100  pit_freq: 3000384
TSC: Fast PIT calibration matches PMTIMER.
TSC: PIT calibration matches PMTIMER. 1 loops
Detected 3000.045 MHz processor.

I'm trying to see how regular the mis-calculation is, as well as see how
well the alternate calibration method does to handle this on your
hardware.

Its likely the fat pit calibration can be better integrated with the
other calibration methods, so this probably isn't anything close to what
the actual fix will look like.

Ingo, Thomas: On the hardware I'm testing the fast-pit calibration only
triggers probably 80-90% of the time. About 10-20% of the time, the
initial check to pit_expect_msb(0xff) fails (count=0), so we may need to
look more at this approach.

thanks
-john