calcru: time went backwards

[Mike Andrews]

On Fri, 18 Apr 2008, Jeremy Chadwick wrote:

> On Fri, Apr 18, 2008 at 04:51:50PM +0300, Pertti Kosunen wrote:
>> Larry Rosenman wrote:
>>> On Tue, 15 Apr 2008, Jeremy Chadwick wrote:
>>>> And what the FAQ doesn't cover is here:
>>>>
>>>> http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues
>>>>
>>>> * EIST (Intel SpeedStep) incompatibilities with Supermicro PDSMI+
>>>> motherboards (and possibly others)
>>>>    * Symptom: kernel outputs messages like kernel: calcru: negative
>>>> runtime of -XXXXX usec for pid XX
>>>>    * Workaround: Disable the EIST feature in the BIOS. You can still
>>>> achieve ACPI-based processor
>>>>      frequency throttling by using powerd(8).
>>>>    * Reference:
>>>> http://lists.freebsd.org/pipermail/freebsd-questions/2006-October/133253.html
>>> What I find interesting is I hadn't seen these until this kernel update :(
>>
>> Same problem here with Tyan Toledo i3000R (S5191) motherboard if cpufreq
>> module is loaded.
>>
>> 7.0-RELEASE (AMD64) didn't have this problem.
>
> Are you absolutely positive about this (re: amd64 not having the
> problem)?  I can reproduce the issue documented in my Wiki page on i386
> or amd64.  The piece that seems to cause it, at least in the case of the
> PDSMI+, is EIST being enabled in the BIOS.

For what it's worth, I've got five Supermicro PDSMI+ and one PDSMA+ in 
production, all running amd64, and starting from when I moved from 
6.2-STABLE to 7.0-BETA, and continuing through last week's 7.0-STABLE, I 
started seeing "calcru: runtime went backwards"... messages for about 2-3 
minutes after a reboot, then they'd go away on their own.  Disabling EIST 
in the BIOS two days ago made the problem go away on all six systems.

The systems are using the ACPI-fast timecounter (the default) except the 
PDSMA+ uses TSC because it's faster for MySQL...  switching between the 
two didn't make any difference.  I figured the reason the errors went away 
3 minutes after boot was due to ntpd beating the clock into behaving.  I 
also don't have the cpufreq module loaded.

In my case the error messages seemed pretty harmless and the systems have 
been running great for a long time...  both before and after toggling 
EIST... I only mention it because in my case, it was a slightly different 
message (always "runtime went backwards" not "negative runtime"), and it 
did affect 7.0-RELEASE/amd64 for me, and maybe that'll help someone narrow 
it down...