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:
pgpMfQwTN2tNE.pgp
Description: PGP signature
- Follow-Ups:
- Re: 2.6.17-mm2 hrtimer code wedges at boot?
- From: john stultz <[email protected]>
- Re: 2.6.17-mm2 hrtimer code wedges at boot?
- References:
- Re: 2.6.17-mm2 hrtimer code wedges at boot?
- From: Roman Zippel <[email protected]>
- Re: 2.6.17-mm2 hrtimer code wedges at boot?
- From: Daniel Walker <[email protected]>
- Re: 2.6.17-mm2 hrtimer code wedges at boot?
- Prev by Date: Re: 2.6.17-mm2 hrtimer code wedges at boot?
- Next by Date: Re: [RFC] Apple Motion Sensor driver
- Previous by thread: Re: 2.6.17-mm2 hrtimer code wedges at boot?
- Next by thread: Re: 2.6.17-mm2 hrtimer code wedges at boot?
- Index(es):
 |