chrony reads a kernal timing parameter (CONFIG_HZ) for its operation. If gentoo-sources kernel is set to the default 200, chrony exits with an error. Changing it to 100 and its fine. This is something introduced between r2 (which worked) and r4/r5 which dont work. If this feature breaks chrony, it might break other packages as well, or is the problem just chrony? So I raised the bug here to get something started on it. Doesnt affect ntpd though. Reproducible: Always Steps to Reproduce: 1. set "timer frequency" in general to a value other than 100 (default is 200) 2. compile kernel and install 3. Actual Results: any attempt to start chrony fails with an error message in the logs to do with hz log: May 14 19:26:21 [chronyd] chronyd version V1_19 starting May 14 19:26:21 [chronyd] Fatal error : Can't determine hz (txc.tick=5000 txc.freq=0 (0.00000000) txc.offset=0) Expected Results: chrony should run with any reasonable value for CONFIG_HZ Short term: Set the default value to 100, with a warning that it might effect packages like chrony Long term: fix chrony or kernel, wherever the fault lies.
well, this is not a kernel bug, it is a chrony bug which they claimed to have fixed on version 1.17 - From the HELP file in chrony-1.19.tar.gz * Include support for systems with HZ!=100 (HZ is the timer interrupt frequency). I'll hand this over to vapier since he last touched the package in portage. Jay
Using "linux_hz 200" in chrony.conf (as mentioned in the documentation) doesn't solve the problem here (2.4.20-gentoo-r5). It seems chrony itself needs some work.
could you perhaps test out 1.19.99.2 and see if that fixes it ? to be honest ive never used chrony before ... adding wmertens because he seems to know about this package ;)
Better, seems to get further before dieing Jul 18 22:40:25 [chronyd] chronyd version V1_19_99_2 starting Jul 18 22:40:25 [chronyd] Initial txc.tick=5000 txc.freq=0 (0.00000000) txc.offset=0 => hz=256 shift_hz=8 Jul 18 22:40:25 [chronyd] Linux kernel major=2 minor=4 patch=20 Jul 18 22:40:25 [chronyd] calculated_freq_scale=1.00000000 freq_scale=1.00000000 Jul 18 22:40:25 [chronyd] Unexpected condition [adjtimex failed for set_frequency, freq_ppm=4.4065e+04 scaled_freq=3.3268e+01 required_tick=4078] at sys_linux.c:453, core dumped Use a gentoo-sources-2.4.20-r5 kernel with a CONFIG_HZ of 200, running in a vmware virtual machine (100 runs ok).
Created attachment 19038 [details, diff] Patch to enable chrony to auto-detect 200 HZ clock The problem is that chrony can only autodetect HZ=100 or powers of 2 (128,256,...). You can either apply the attached patch (against chrony 1.20) or add the line linux_hz 200 to /etc/chrony/chrony.conf. (Note: 1.20 ebuild can be made by simply copying 1.19 ebuild and patches to 1.20 files)
Dang, I only looked at the title of this bug and presumed it fixed. I'll fix it in 1.20-r1, but now I'm too tired. Is the author aware of this problem? Cheers, Wout.
I don't think that the author really is aware of this issue, as it seems to exist since the dark ages (CONFIG_ABACUS no power of 2); thus, I dropped a message today -- but I'm no too eager that this is going to be fixed, as I have notified him about this problem a couple of times. Besides that, the same problem seems to appear with the 2.6.x kernel series. Using 2.4.x, I got used to set CONFIG_HZ to 256 or 512 (or whatever else does work). But when I recently installed 2.6.x, chrony wetted its pants again. Unfortunately, the CONFIG_HZ switch seems to have vanished in the new kernel series. If this is true (and I am not too stupid to find it), this issue ought to be fixed soon...
Since this issue is continuously being ignored for over a year now, I would suggest to - CLOSE the bug, if the problem doesn't exist anymore *or* - WONTFIX it, if noone cares.
Sorry about that. I'll look at it this weekend and decide to patch/ignore.
Ok, that was an extremely long weekend ;-) Anyway, Alexander, your patch looks really good, and it's in 1.20-r1 now. Sorry for the extreme delays.
I've just commited chrony-1.21 (it's package.masked). I dropped the patch from this bugreport. My problem is (with or without the patch) chrony fails to start, if linux_hz is set to something else than 100. (Otherwise it works well, even with different Timer frequency settings for the kernel.) Is someone able to help with this? What is needed here? Is linux_hz just deprecated and shouldn't be used?
OK, 3 1/2 years - someone send this upstream... http://chrony.sunsite.dk/
