On Thursday 07 August 2008, Alain Guibert wrote: > Hello David, > > On Wednesday, August 6, 2008 at 17:19:49 -0700, David Brownell wrote: > > > in practice [/sys/class/rtc/rtc0/settime_offset_ms is] never needed > > except for PC-compatible RTCs (as we already discussed). > > You proposed that in the absence of the settime_offset_Ns information, > hwclock should consider it to be zero. There is a problem with this > approach: hwclock would misbehave on PC-compatible RTCs with today's and > older kernels. It misbehaves on lots of hardware already. I guess whoever implements such stuff gets to choose whose hardware will break on old systems. I'd care mostly that it works on new/sane systems. > > 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. > > Do you mean that we would then get the UIE directly from the RTC? Fine! Yeah, but it's a mess. I didn't go that route, since the RTC IRQs are supposed to be available through ACPI. See http://bugzilla.kernel.org/show_bug.cgi?id=11153 The patch in comment #18 keeps breaking because of ACPI braindamage; see the "blocked by 11312" stuff. Not on *all* hardware; sigh. > Another approach could be to only disable UIE emulation, and arrange > ioctl(RTC_UIE_ON) to return -1/EINVAL. Then hwclock automatically > fallbacks to the --nointerrupt mode, busy looping around RTC_RD_TIME > until the time changes. This tick detection method is less elegant, and > a little bit less accurate than a proper UIE, but the user would gain a > fully featured HPET for the price. Or, the patch I mention above ... if ACPI doesn't break it on your HW. - Dave -- 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
