The suggestion below is almost self-explanatory. Since calibrate_tsc
now returns 2^28 * (nS/TSC), and you want/need 2^32 * (nS/TSC) ......
I don't have a PPS to test with (and built it without CONFIG_NTP_PPS), but
I can check the phase fairly accurately against the cmos rtc and getting
the same results as with normal kernel.
I'm wondering if you can't dispense with the 2^28 normalization (vs 2^32)
alltogether. What's the rationale for that?
>
> Feedback is welcome. I hope to be able to finish the nanokernel soon
> to return to other projects (like my tax declaration 8-().
We need a kernel module to do the taxes for us. Then uncle sam can just
audit the kernel list and not bother us about it.
One other little detail. In kernel/time.c, around line 311, PPS_FAVG is
used even though it's only defined inside an #ifdef CONFIG_NTP_PPS
conditional. I just defined it outside the #ifdef for this compile.
--Robert
========================================================================
--- linux/arch/i386/kernel/time.c Tue Feb 23 01:05:13 1999
+++ linux/arch/i386/kernel/time.c Tue Feb 23 02:02:50 1999
@@ -160,7 +160,7 @@
"0" (eax));
/* our adjusted time offset in nanoseconds */
- return nanodelay_at_last_interrupt + (edx >> 4);
+ return nanodelay_at_last_interrupt + (edx << 4);
}
#endif
@@ -732,7 +732,7 @@
dodgy_tsc();
if (boot_cpu_data.x86_capability & X86_FEATURE_TSC) {
-#if 1
+#if 0
printk("TSC calibration is broken, sorry (Fix it if you can)\n");
#else
use_tsc = 1;
@@ -742,8 +742,12 @@
do_get_exact_timeval = do_gettimeofday;
do_get_exact_timespec = do_clock_gettime;
exact_nanotime_quotient = calibrate_tsc();
+ /*
+ * exact_nanotime_quotient is 2^28 * number of ns/TSC
+ * normalize it to 2^32 * nS/TSC and convert to uS
+ */
exact_microtime_quotient =
- (exact_nanotime_quotient / 1000) >> 4;
+ (exact_nanotime_quotient / 1000) << 4;
printk("quotients: micro=%ld, nano =%ld\n",
exact_microtime_quotient, exact_nanotime_quotient);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/