Uwe Klein <[EMAIL PROTECTED]> writes: >Unruh wrote: >> >> Under Linux support is a mess. For example if you turn on an interrupt, the >> system returns immediately even though the conditions of the interrupt have >> not been met. Some bug in the code. >> >could you be more specific?
Sure bugzilla.kernel.org bug 11112 On more recent systems (eg systems with HPET) the kernel code was not cleaning up old interrupt information when the intrrupt UIE ( the update interrupt which tell the rtc to issue an interrupt once per second just when the seconds marker was turning over in the rtc) was switched on. This meant that the interrupt was retured immediately. The usual way of reading the rtc for accurate work was to switch on the UIE, and then do a select() or a read() on the /dev/rtc fd, and wait for the update. However, it returned immediately meaning that the first select/read after the UIE was turned on returned immediately and not when the rtc updated. Ie, the time would be out by up to a second. Now if you did not care whether or not the rtc was accurate, that is ok. However if you wanted to set or read the rtc accurately, that is terrible. Here you discipline your computer to within 1 microsecond, and you cannot discipline your rtc to better than a second. I discovered this about 2 years ago while trying to understand chrony, but at that time thought it is was just some weirdness with the rtc I did not understand. Last week, when a new computer could not run chrony at all, I looked into it further, and discovered the above bug in the rtc driver (the hpet and also the new rtc-cmos drivers). (There was also a further bug in the hpet glue and the Mandriva kernel setup which was why chrony was not working, but that is another story). Note that there are now kernel fixes for the bug which will probably make it into the 2.6.28 kernel. In the meantime, make sure that if you want to accurately read the rtc, do a select or read twice-- the second one will be at the update boundary (well on an hpet system, that is not clear either. It seems that the rtc situation is a bit of a mess these days caused by very bad hpet/bios behaviour.) >uwe _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions