| Re: [chrony-dev] Chrony freezing |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On Wed, Nov 11, 2009 at 12:28:32PM -0800, Bill Unruh wrote:
> rtc_linux.c:877 is exactly that second read from the rtc which I have had
> trouble with in the past hanging.
It looks like the rtc device stopped providing data, possibly a kernel
bug.
> Thus, this section seems to be suffering from a cleft stick. If one only does
> a single read from the rtc, it interrupts immediately instead of on the second
> as it should on most systems. If I do the double read, it hangs on sometimes
> on some systems (this particular hang seems to be occuring after I do a
> chronyc cyclelogs, but only sometimes, not always. Ie, this problem with the
> rtc seems to be sporadic and flakey)
Hm, I don't think there should be any double reading. Here, the second
read makes chrony unresponsive until the next second as the read
blocks. That's not good.
> Is it possible to do a timeout on a read so that if it has not returned in a
> second say, that read is abandoned?
It's better to not use any blocking reads, read only when select()
says it's ready.
> Also it would probably be a good idea to put a nortc
> keyword into /etc/chrony.conf, so that if one has one of these flakey systems,
> once can switch off all rtc use for that system.
Removing rtcfile command will disable using rtc.
> Ideally, getting the kernel people to fix rtc even with the hpet system, would
> be a good idea. (the problem is that under hpet, the rtc interrupt is routed
> to the non-maskable interrupt I believe, and it seems that is difficult to use for the
> rtc.)
> However it may be a while and chrony is still being left as flakey on the
> older kernels.
Is it better on recent kernels?
--
Miroslav Lichvar
---
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.