calcru: runtime went backwards

I'm seeing messages like this on the console. What does it mean?

Code:
calcru: runtime went backwards from 54 usec to 43 usec for pid 758 (devd)
calcru: runtime went backwards from 136 usec to 109 usec for pid 349 (dhclient)
calcru: runtime went backwards from 504 usec to 401 usec for pid 333 (dhclient)
calcru: runtime went backwards from 11672 usec to 9293 usec for pid 333 (dhclient)
calcru: runtime went backwards from 196 usec to 156 usec for pid 179 (adjkerntz)
calcru: runtime went backwards from 755 usec to 601 usec for pid 21 (swi6: task queue)
calcru: runtime went backwards from 102 usec to 81 usec for pid 9 (thread taskq)
calcru: runtime went backwards from 1621 usec to 1291 usec for pid 19 (swi5: +)
calcru: runtime went backwards from 17 usec to 14 usec for pid 17 (swi1: net)
calcru: runtime went backwards from 16892 usec to 13878 usec for pid 0 (swapper)
 
It means that your system time went back, confusing a number of applications. Do you use an NTP server (or a pool of NTP servers) that's unreliable? I've had messagers like these when I used the *.pool.ntp.org servers, some of which were grossly inaccurate.
 
I've seen suggestions to change the kern.timecounter value to either TSC or i8254. Try one or the other and see if that fixes the problem:

sysctl kern.timecounter.hardware=TSC or
sysctl kern.timecounter.hardware=i8254

If you're happy with either of them, put it in sysctl.conf(5).
 
Common enough problem, one solution to which is to set kern.hz in
your /boot/loader.conf file to something less than 1000. kern.hz="100" is usually recommended.
 
I have also seen in on some older FreeBSD releases before. What version are you running?
 
I have the same problem with FreeBSD 7 amd64 on my Dual Opteron 2xx system (Can't remember mainboard), the problem seems to occur if the NIC (bge driver) is used heavily or if the CPU is used heavily.
What mainboard/CPU are you using?

Using a different timecounter does not help, I haven't tried setting kern.hz to 100 yet, I'll try that.
I sort of gave up and was planning on installing OpenSolaris ...

I have also seen in on some older FreeBSD releases before. What version are you running?

Yes, most of what I could find was for FreeBSD 5 ... Not a lot on FreeBSD 6 and 7.
 
Carpetsmoker said:
I have the same problem with FreeBSD 7 amd64 on my Dual Opteron 2xx system (Can't remember mainboard), the problem seems to occur if the NIC (bge driver) is used heavily or if the CPU is used heavily.
What mainboard/CPU are you using?

Using a different timecounter does not help, I haven't tried setting kern.hz to 100 yet, I'll try that.
I sort of gave up and was planning on installing OpenSolaris ...



Yes, most of what I could find was for FreeBSD 5 ... Not a lot on FreeBSD 6 and 7.

AMD processors have a similar feature to EIST (Speedstep) built into them (forgot what it's called). See if you can disable it in the BIOS. EIST basically lowers the CPU's multiplier (and subsequently its operating frequency) when not under heavy load to save power.

It looks like FreeBSD isn't dealing well with the change in frequencies.
 
Well, I noticed a death, but it was on TV

ph0enix said:
It looks like FreeBSD isn't dealing well with the change in frequencies.
Purely out of curiosity, are there any effects besides the messages? I've seen them plenty of times and never noticed any deaths or maimings.
 
fronclynne said:
Purely out of curiosity, are there any effects besides the messages? I've seen them plenty of times and never noticed any deaths or maimings.

In my case, it freezes the system, sometimes it comes out of the freeze after some times, sometimes not.
 
fronclynne said:
Purely out of curiosity, are there any effects besides the messages? I've seen them plenty of times and never noticed any deaths or maimings.

No, I didn't notice any special effects.
 
FYI:
I just noticed these since disabling EIST:

CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (3006.83-MHz K8-class CPU)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
cpu0: <ACPI CPU> on acpi0
est: CPU supports Enhanced Speedstep, but is not recognized.
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
est: CPU supports Enhanced Speedstep, but is not recognized.
p4tcc1: <CPU Frequency Thermal Control> on cpu1
cpu2: <ACPI CPU> on acpi0
est: CPU supports Enhanced Speedstep, but is not recognized.
p4tcc2: <CPU Frequency Thermal Control> on cpu2
cpu3: <ACPI CPU> on acpi0
est: CPU supports Enhanced Speedstep, but is not recognized.
p4tcc3: <CPU Frequency Thermal Control> on cpu3

...I'm not sure if it hurts anything
 
There's no option to disable EIST, no mention of it in dmesg ... I suspect my mainboard doesn't even support this feature.

I set kern.hz="100", so far it *seems* to have solved the problem, but more extensive testing is required to be 100% sure.


What does kern.hz actually do? And why did it (probably) fix my problem?
 
I am running FreeBSD 7.1 x64 (amd) under VMWare.
I have set kern.hz=100, set BIOS to GMT (there are no other otpions in BIOS to configure) and I still have this problem.

What else can I try?
 
Alpinweis said:
What else can I try?
Did you first try to add debug.acpi.disabled="timer" to /etc/loader.conf as suggested DutchDaemon's second link?


Carpetsmoker said:
What does kern.hz actually do?
I guess it's either the PIT or the ACPI. The PIT is usually used to manage timeslices for multitasking (i.e. the PIT is interrupting the CPU 1000 times every second).

But I think FreeBSD uses APIC for SMP and it seems there are problem with it.

I can't understand why FreeBSD uses 1000Hz by default. AFAIK, most OS use 100Hz.
 
Beastie said:
I can't understand why FreeBSD uses 1000Hz by default. AFAIK, most OS use 100Hz.

It decreases general latency, and on cheap desktop sort of hardware it may be problematic.
 
Carpetsmoker said:
I set kern.hz="100", so far it *seems* to have solved the problem, but more extensive testing is required to be 100% sure.

Great... thanks for confirming it's one of the possible fixes for future victims.
 
I have kern.hz set to 100 but it doesn't fix the problem on my Asus EEE PC 1000 laptop. I also tried the other time sources to no avail.
 
I'll show you a hardcoded maximum

Back in the days of the amd k6-iii[1], my experience was that about one third of the boards (sample size was about 6, though, so don't try to read any narrow trends into this) would give this error message, no matter what kern.hz was set to[2]. At least one never gave the error, and the final portion would cease (or almost never[3]) at around kern.hz=250.

I attribute at least some of the problem to flaky clocks, for which there seem[ed|s] to be no real cure.


[1] Actually somewhat after, since I got a pile of them second-hand for nothing

[2] Truth be told, I never tried values < 100, which makes me wonder if there's a hardcoded minimum or maximum . . .

[3] Maybe once or twice when building world at -j2
 
trev said:
Strange - my ASUS EEEPC 701 netbook doesn't have any issues with FreeBSD 7.1-STABLE i386.

My Asus EEE PC 701 has no problems with 7.1-STABLE either, but my 1000 with 8.0-CURRENT does.
 
I set kern.hz="100", so far it *seems* to have solved the problem, but more extensive testing is required to be 100% sure.

It helped a bit, the system didn't freeze as often, but didn't fix the problem after all.
Reinstalling the system with i386 ``solved'' the problem though ...
 
running freebsd 8 rc3 in microsoft hyperv. i had the same problems as described. setting the following worked for me.
# sysctl kern.timecounter.hardware=TSC
 
Back
Top