On Wednesday 06 August 2008, Karel Zak wrote: > On Tue, Jul 15, 2008 at 03:34:42PM -0700, David Brownell wrote: > > > > > We can resolve the problem in userspace. I can imagine > > > > > hwclock(8) that reads /sys/class/rtc/rtc0/settime_offset_ms > > > > > > That'd work. Someone would need to provide the kernel patch > > > to define that value, with whatever units are relevant. In > > > most cases the value would be zero, but rtc-cmos would need > > > to export 500 msec. > > > > By the way ... I just happened to be looking at how the > > HPET (available on modern x86 systems, and solidly in the > > Linux "should use" category) interacts with the RTC. > > > > Capsule summary: absolutely nothing keeps the emulated RTC > > IRQs (arch/x86/kernel/hpet.c) in phase with the real RTC. > > > > So any effort to pay attention to that 500 msec delay is > > going to be monitoring the HPET IRQs instead of the real > > RTC signals. The right offset would rarely be 500 msec. > > Does it mean that /sys/class/rtc/rtc0/settime_offset_ms > is nonsense? In general, no ... although in practice it's never needed except for PC-compatible RTCs (as we already discussed). In this specific case, yes ... but the general rule should be that when you need accurate RTC-based timekeeping on x86, don't enable HPET. (Though we *could* enable an hpet=noirq option to at least give us the very precise clocksource ... the trouble comes with trying to use its IRQs.) - Dave > Karel > > -- > Karel Zak <kzak@xxxxxxxxxx> > -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
