Red Hat Bugzilla – Bug 168255
powernow clock instability: warning: many lost ticks.
Last modified: 2007-11-30 17:07:20 EST
Description of problem:
When enabling AMD PowerNow on x86-64 platforms w/out bios HPET timer
support, clock jumps forward and back several seconds or more.
Presumably clock code isn't prepared for cpu frequency changes.
Version-Release number of selected component (if applicable):
rhel4, rhel4-u1 x86-64
Enable PowerNow. Run the system with variable load/and idle. clock will
begin to jump forward and back (symptoms: Warning: many ticks lost
message, screen saver starting after a few seconds, scsi timeout
messages). See attached program which will print large time jumps.
System is a Sun Fire X4100 (x86-64 system which does not provide bios
HPET support. Note that the problem appears masked on systems with
System time should advance smoothly.
Created attachment 118780 [details]
program to print time jumps
Created attachment 118781 [details]
Results showing time jumps
This is a known issue and a fix has been proposed for (late) inclusion in RHEL4
U2. It is not known if this fix is confirmed to go into RHEL4 U2 or U3 due to
testing and QA timelines. Are you willing to assist in testing a beta kernel if
*** This bug has been marked as a duplicate of 158847 ***
This bug is marked as duplicate of private bug #158847 so reopenning this one.
I have BIOS only with AMD Colin'n'Quiet and this make no sense to lost tiks.
I've got these messages from the kernel (just for search):
Losing some ticks... checking if CPU frequency changed.
warning: many lost ticks.
Your time source seems to be instable or some driver is hogging interupts
I'm able to test beta kernel... I'll try to use the one from U2 Beta channel. Or
is there another kernel in place for testing?
no that's the one.
I have the same problem, and I do have the option to turn off PowerNow, but that
does not help any. I still get the problem and the errors.
(With the released WS4 and Beta WS4)
which timesource is being used? (PMTimer, TSC, PIT)
do a "dmesg | grep time.c"
PMTimer is the preferred timekeeing mechanism on AMD systems.
Here: time.c: Using PIT/TSC based timekeeping (2.6.9-11.ELsmp, x86_64 kernel).
dmesg | grep time.c
time.c: Using 1.193182 MHz PIT timer.
time.c: Detected 2600.048 MHz processor.
Linux ori.protect.nssl 2.6.9-17.EL #1 Fri Aug 26 10:54:28 EDT 2005 x86_64 x86_64
With 2.6.9-17.ELsmp it seems to stop loosing the ticks. It seems to solve the
problem completly here (kernel-smp-2.6.9-17.EL.x86_64 still detect PIT/TSC based
timekeeping). Thank you!
Its worth mentioning that dual core SMP powernow support made it into the U2
kernel rather late. This included a PowernNow driver update for dual core SMP
support, as well as a handfull of timer fixes for PMtimer, HPET, TSC and PIT.
You likely need a 2.6.9-22.EL kernel to solve all powernow and/or timekeeping
issues. The 2.6.9-17.EL did not include these timer mods. Also, the timer code
works differently using SMP.
BTW, feedback regarding the 2.6.9-22.EL kernel (and if it does or does not solve
the problem) would be of help.
Running kernel 2.6.9-22.ELsmp with powernow turned on. I still get the messages:
kernel: warning: many lost ticks.
Sep 29 12:33:37 ori kernel: Your time source seems to be instable or some driver
is hogging interupts
Sep 29 12:33:37 ori kernel: rip __do_softirq+0x4d/0xd0
(although, not so frequent.)
does the system keep good time with the .22 kernel regardless of the "lost tick"
Usually the "many lost tick" message is a symptom of another problem. This
message is thrown when the linux kernel corrects for lost ticks (which is what
you want to happen). Point being, an occasional "many lost tick" message is
probably not much to worry about, but if this problem re-occurs very often its a
Well. I have no access to .22 kernel. Even that I have disabled Colin'n'Quiet
(IIRC the name) for all the time and there is no PowerNow setting in the BIOS.
And .17 kernel completly avoid 'lost ticks' messages in my kernel log (even I
have no load on this machine in the current time as its placement has been
postponed due the bugs) and .11 has always the problem (a minute or so after the
boot there is messages about lost ticks in the kernel log). I have no physical
access to the machine at the present time :-(
I'm waiting for U2 but if I'll have an access to testing .22, I'm able to
reboot&test (i'll try to generate some load for .17 though).
AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ on 2.6.9-17.ELsmp x86_64, ASUS A8N-E.
Yes, the system does keep the proper time. I wanted to make sure by giving it
several hours to go wrong if it was going to happen.
Here is the link to the kernel I am using:
After the move from .17kernel to the .22 kernel from URL above, the PIT/TSC
based timekeeping has changed to PM based. No lost ticks yet so all went ok
since .17 here. The bug could be closed now or just after the U2 release (how
long will this take?).
time.c: Using PM based timekeeping.