Re: 2.6.17-mm2 hrtimer code wedges at boot?

[Roman Zippel <zippel@linux-m68k.org>]

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