On Tuesday 17 June 2008, Karel Zak wrote: > I think we have two issues here. > > 1) hwclock(8) always reads the hardware clock, although, for example: > > hwclock --systohc --noadjfile --utc > > needn't any data from the hardware clock. This problem has been > reported by Uwe. Right, and this seems to be fixed by the patch you sent earlier. > > (*) One issue is a mechanism that's specific to the PC/AT > > clone RTCs: waiting for "exactly" 1/2 second after > > the clock rolls over before setting the clock, since > > 2) IMHO this is a separate issue. > > > those RTCs wait a half second. If someone has time > > to work such issues: that 1/2 second delay should > > (a) obviously not be attempted if the clock can't > > even be read, but also (b) should not be required, > > since most RTCs don't have those PC/AT semantics. > > ad (b) - is there any way how to differ between "modern" RTCs and > PC/AT style RTC? You mean, how can userspace tell what kind of RTC it's got? Today, it can't ... although some experimentation could tell if there is such a delay. (Set RTC, observe when it takes effect... evidently "chrony' does some of that.) My preferred solution would make this delay become explicit in /etc/adjtime and the command line. For full backwards compatibility to the "PC-specific" model, default to 500msec if it's not listed in /etc/adjtime. Intelligent installers (or distros) would set it to 0 msec on most non-PC hardware. - 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