[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.0902261434390.3111@localhost.localdomain>
Date: Thu, 26 Feb 2009 14:40:09 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: john stultz <johnstul@...ibm.com>
cc: Thomas Gleixner <tglx@...utronix.de>,
Jesper Krogh <jesper@...gh.cc>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Len Brown <len.brown@...el.com>
Subject: Re: Linux 2.6.29-rc6
On Thu, 26 Feb 2009, john stultz wrote:
>
> I'll kick up some of my own testing between these two releases to see if
> I can't find something similar.
Since the PIT timer read is possibly hw-dependent, it might be that you
can't necessarily reproduce it on some random hardware.
How sensitive is ntpd to (stable) drift? IOW, if we get the calibration
wrong, the TSC should still hopefully be very _stable_, it's just that the
initial guesstimate for the frequency is off and ntp would have to correct
for that.
The easiest way to test might be to just force a 1000ppm estimation error
with something like this total hack (indented just so that nobody would
ever apply this by mistake):
arch/x86/kernel/tsc.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 599e581..b80a0c4 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -350,6 +350,10 @@ static unsigned long quick_pit_calibrate(void)
delta = (t2 - t1)*PIT_TICK_RATE;
do_div(delta, QUICK_PIT_ITERATIONS*256*1000);
printk("Fast TSC calibration using PIT\n");
+
+ /* HACK! */
+ delta -= delta >> 10;
+
return delta;
}
failed:
which wouldn't be hardware-dependent.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists