Re: 2.6.17-mm2 hrtimer code wedges at boot?

From: Valdis.Kletnieks@vt.edu
To: Daniel Walker <dwalker@mvista.com>
Cc: Roman Zippel <zippel@linux-m68k.org>,
	john stultz <johnstul@us.ibm.com>, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org
Subject: Re: 2.6.17-mm2 hrtimer code wedges at boot?
Date: Sun, 02 Jul 2006 22:20:51 -0400	[thread overview]
Message-ID: <200607030220.k632KqmK027679@turing-police.cc.vt.edu> (raw)
In-Reply-To: Your message of "Sun, 02 Jul 2006 18:56:22 PDT." <1151891783.5922.4.camel@c-67-180-134-207.hsd1.ca.comcast.net>

[-- Attachment #1: Type: text/plain, Size: 976 bytes --]

On Sun, 02 Jul 2006 18:56:22 PDT, Daniel Walker said:

> I was reviewing these new ntp adjustment functions, and it seems like it
> would be a lot easier to just switch to a better clocksource. These new
> functions seems to compensate for a clock that has a high rating but is
> actually quite poor..

It is indeed poor - a few -mm's ago I tripped over a bug that kept it from
recognizing the PM timer clocksource, and it refused to NTP sync because
the clock drift was well outside the 500 ppm that NTP wants.  All the same,
it's *one* thing for a clock to be drifting 10 seconds per hour.  It's
something else to totally explode when handed a drifting clock.

Currently, the kernel is build with CONFIG_RTC=m, and the clock starts
behaving as soom as rc.sysinit modprobes it.  Questions this raises:

1) What's up with *that*?
2) Anybody want to place bets that building with CONFIG_RTC=y will make
the clock work right off the bat?
3) Is that a fix, or just wallpaper? :)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]