Re: 2.6.0 "Losing too many ticks!"

[Albert Cahalan <albert@users.sf.net>]

William Lee Irwin III writes:
> On Wed, Dec 24, 2003 at 07:49:06PM +0100, Giacomo Di Ciocco wrote:

>> today i found a problem when upgrading the kernel of this box from
>> 2.2.20 to 2.6.0, i tried to enable/disable ACPI support in the bios
>> and in the kernel but nothing was resolved. [...]
>> Dec 24 16:36:31 xmas kernel: Losing too many ticks!
>> Dec 24 16:36:31 xmas kernel: TSC cannot be used as a timesource. (Are you
>> running with SpeedStep?)
>> Dec 24 16:36:31 xmas kernel: Falling back to a sane timesource.
>> Contact me for more informations. (or tell me to post it here)
>
> This is not particularly harmful. It just means the kernel
> has detected some variation in the processor's clock speed
> and is using a time source that doesn't change speed along
> with the processor's clock speed.

I sure wouldn't bet on that. More likely, he's simply
losing ticks. He has a Duron processor, which is
highly unlikely to be hooked up to some crummy
speed-changing hardware.

I had a 1 GHz Pentium III box with the same problem.
Linux would give up on the perfectly-correct 1 GHz
clock source in favor of trying, and failing, to
count 1 kHz ticks from the crummy old PIT hardware.
Time loss got so bad that NTP would simply give up.
IDE activity may have had something to do with it.

In his case, maybe ACPI polls something while
interrupts are off.