On Dec 2, 2010, at 10:17 PM, [email protected] (Mike S) wrote:
is it possible to restart the Linux kernel without a full reboot
(avoiding BIOS initialization)
At 02:17 AM 12/3/2010, Christian Vogel wrote...
It's called "kexec".
Thanks. I'll try it in a bit.
At 02:22 AM 12/3/2010, Hal Murray wrote...
The problem is in the TSC calibration routine. If you patch the
source code
to call it multiple times and print each answer, you will get various
answers.
Thanks.
Somebody "cleaned up" the Linux timekeeping code a year or two
ago. Scan
your /var/log/messages for something like:
Nov 7 08:40:13 shuksan klogd: Detected 2792.933 MHz processor.
and/or
Nov 7 08:40:14 shuksan klogd: Switching to clocksource tsc
Looks like you've got it!
[ 0.000000] Detected 2410.978 MHz processor.
[ 0.912030] Switching to clocksource tsc
There are now several possible clock sources.... Look in
<kernel-sources>
/Documentation/kernel-parameters.txt and search for clocksource
You're a fount of good info. Something else to play with:
clocksource= [X86-64] hpet,tsc
At 02:23 AM 12/3/2010, Kasper Pedersen wrote...
http://n1.taur.dk/permanent/testpmt.c
this bit of code will compare the timekeeping clock to the
PMTimer, which runs off of plain 14.31818MHz/4. It gives you
the frequency offset (in ppm) in a few seconds, and provided
ntpd is not started on boot, gives you the scaling error.
NTP is running, and testpmt cranks out numbers at several per second.
They're mostly in the low 32's. The clocksource is tsc, and ntptime is
adjusting -6 ppm. So, tsc and PMT apparently differ by 38 ppm (or maybe
26, not sure how the signs work).
there is this patch: http://n1.taur.dk/timefix2.patch
With a good* 14.31818MHz, running the clock off of acpi_pm is now
good. With hpet there's another bug, causing a 60e-9 offset.
I'm running ARM64 (aka X86-64), acpi_pm appears not to be an option,
according to
http://www.kernel.org/doc/Documentation/kernel-parameters.txt Does the
kernel really calculate based on 14.318180? I find this in dmesg:
"[0.904194] hpet0: 3 comparators, 32-bit 14.318180 MHz counter" Is that
because mine is being measured wrong, someone chose the wrong rounding
(sb 14.318182), or a granularity limitation of HPET? The proper
frequency is a repeating decimal 14.31818181818... (= 4.5 MHz / 286 *
455 / 2 * 4). To a time nut, the difference is 127 ppb.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
