Hi,
On Wed, 28 Jun 2006, Roman Zippel wrote:
> Frequency changes are IMO currently the most likely reason for this
> behaviour. If the cpu speeds down too much, the adjustment code might
> actually attempt to go backwards in time, the old adjustment code might
> have survived that, because it reacts slower to changes.
> The patch below should prevent this.
Hmm, I've run some simulations and I found that it actually needed some
extreme frequency differences to trigger a negative multiplier, but even
then it recovered very quickly from it.
Valdis, could you please add a call to the function below in
__get_realtime_clock_ts() when the problem triggers to print the complete
internal clock state.
Thanks.
bye, Roman
---
kernel/timer.c | 7 +++++++
1 file changed, 7 insertions(+)
Index: linux-2.6-mm/kernel/timer.c
===================================================================
--- linux-2.6-mm.orig/kernel/timer.c 2006-06-28 13:30:30.000000000 +0200
+++ linux-2.6-mm/kernel/timer.c 2006-06-28 13:34:43.000000000 +0200
@@ -789,6 +789,13 @@ u64 current_tick_length(void)
#include <linux/clocksource.h>
static struct clocksource *clock; /* pointer to current clocksource */
+void printk_clock_info(void)
+{
+ printk("clock %s: m:%u,s:%u,cl:%Lu,ci:%Lu,xn:%Lu,xi:%Lu,e:%Ld\n",
+ clock->name, clock->mult, clock->shift, clock->cycle_last, clock->cycle_interval,
+ clock->xtime_nsec, clock->xtime_interval, clock->error);
+}
+
#ifdef CONFIG_GENERIC_TIME
/**
* __get_nsec_offset - Returns nanoseconds since last call to periodic_hook
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
